Когда компания выбирает подрядчика на крупный ИТ-проект, обычно рассматривается несколько интеграторов. На первом знакомстве отличить одного от другого бывает непросто, а от выбора зависит, как пойдёт проект: сроки, бюджет, качество итоговой архитектуры.
Ниже собраны критерии оценки интегратора на предпроектном этапе, вопросы для подрядчика, что стоит проверить в договоре и какие сигналы должны насторожить. Материал полезно читать после того, как у вас уже сложилось общее представление о том, кто такой системный интегратор и что он делает в проекте. Если такого понимания пока нет, стоит начать оттуда.
На что смотреть при выборе системного интегратора
Ключевые критерии оценки практически не зависят от размера проекта и отрасли заказчика. Меняется только вес каждого пункта в зависимости от конкретной задачи.
Релевантный опыт по масштабу и сложности. Точное совпадение кейса именно в вашей отрасли не обязательно, и его отсутствие не означает, что подрядчик не подходит. Стоит смотреть на два других момента: работал ли интегратор с проектами сопоставимого масштаба (по объёму инфраструктуры, размеру команды, длительности внедрения) и может ли он объяснить, как этот опыт применим к вашей задаче. Если подрядчик просто перечисляет число реализованных проектов, но не связывает один-два из них с вашей ситуацией, это скорее сигнал слабой проработки предложения, чем сильной экспертизы.
Технологический стек и работа с несколькими вендорами. Крупные интеграторы обычно работают с несколькими вендорами по каждому направлению и подбирают конфигурацию под конкретную задачу. Если подрядчик уверенно ведёт разговор только вокруг одной продуктовой линейки, это не всегда минус: за этим может стоять глубокая специализация. Но полезно сразу спросить, почему именно эта линейка и что подрядчик предложит, если по вашей задаче лучше ложится оборудование другого производителя.
Состав проектной команды и ответственность за архитектуру. Полностью «своими силами» крупные проекты почти не делаются: часть работ обычно уходит на привлечённых специалистов или партнёров. Сам факт субподряда недостатком не является. Значимее другое: прозрачно ли подрядчик показывает состав команды на ваш проект, кто со стороны интегратора отвечает за архитектурные решения, кто управляет привлечёнными подрядчиками и как выстроен единый контроль качества. Полезно убедиться, что эти зоны у интегратора чётко определены и подтверждаются именами и ролями. Если ответы уходят в общие формулировки «мы найдём тех, кто сделает», стоит уточнять дальше.
Проектная методология. У крупных интеграторов обычно есть отработанная последовательность работ на комплексный проект: обследование текущей инфраструктуры, проектирование целевой архитектуры, поставка и внедрение, интеграция с существующими системами, обучение сотрудников и переход на техническую поддержку. Подробнее эти этапы разобраны в отдельной статье про системную интеграцию как процесс. При выборе подрядчика полезно попросить показать типовую методологию и посмотреть, как в неё встраивается ваш проект.
Финансовая и юридическая устойчивость. Крупные ИТ-проекты и последующая поддержка обычно растягиваются на длительный срок. Разумно проверить историю подрядчика: сколько компания на рынке, нет ли задолженностей и судебных претензий по крупным контрактам. Задача такой проверки в том, чтобы оценить способность подрядчика выполнять обязательства на протяжении всего срока проекта. Отсекать всех с малейшими замечаниями смысла нет.
Соответствие требованиям регуляторов для проектов, попадающих под них. Если ваш проект работает с определёнными классами информации или инфраструктуры и попадает под отраслевые или регуляторные требования, интегратор должен уметь работать в этих рамках и подтверждать это конкретным опытом, а не общими словами про «делаем в соответствии со всеми требованиями».
SLA и модель поддержки после сдачи. Проект не заканчивается запуском. Поддержка выделяется в отдельный контур услуг с собственным SLA. Стоит заранее выяснить, какой режим поддержки предлагается (круглосуточный, рабочий день, гибридный), какое гарантированное время реакции по классам инцидентов, кто именно будет обслуживать вашу систему и как передаётся ответственность в случае инцидента.
Что учитывать при выборе интегратора в Беларуси
При выборе подрядчика на проект в Беларуси есть несколько моментов, которые полезно проговорить отдельно. Ниже три из них, чаще всего возникающих на практике.
Опыт участия в белорусских закупках. Если ваш проект будет запускаться через государственную закупку, у подрядчика должен быть релевантный опыт работы именно с белорусскими процедурами: от подготовки конкурсной документации до сдачи проекта в соответствии с местными приёмочными нормами.
Персональные данные и регулируемые системы. Если ваш проект работает с персональными данными или попадает в категорию систем со специальными требованиями по защите информации, применимые правила зависят от типа данных, класса системы и роли заказчика. Разумный порядок такой: сначала уточнить, какие именно требования применимы к вашему проекту, потом спрашивать у подрядчика опыт работы в этих рамках.
Ограничения по ПО и оборудованию. Если у вашего проекта есть ограничения на используемое ПО или оборудование, продиктованные политикой заказчика, отраслевыми требованиями или санкционным режимом, запрашивайте у подрядчика опыт работы именно с тем классом продуктов, который вам подходит. Конкретный состав ограничений зависит от проекта и уточняется на предпроектном этапе.
Какие вопросы задать интегратору до начала проекта
Ниже практический чек-лист вопросов, которые полезно задать на предпроектной встрече. Он не заменяет полноценного обсуждения, но помогает быстро понять, насколько подрядчик готов к вашему проекту.
По опыту и портфолио:
- В каких проектах сопоставимого масштаба и сложности вы участвовали за последние 2–3 года?
- Какая часть портфолио соответствует именно тому типу задач, который нам нужен (миграция, построение с нуля, модернизация)?
- С какими решениями по нашему направлению у вас есть практический опыт и по какому принципу вы подбираете стек под конкретный проект?
- Можно ли поговорить с одним-двумя вашими прошлыми заказчиками, у которых была похожая задача?
По команде и модели работы:
- Какой предполагается состав проектной команды со стороны интегратора: сколько инженеров, кто архитектор, кто PM?
- Какие работы вы обычно делаете своими силами, какие с привлечёнными подрядчиками, и как выстроено управление привлечёнными?
- Кто конкретно несёт ответственность за архитектурные решения по нашему проекту и как оформляется приёмка архитектуры?
По договору и приёмке:
- Какие приёмочные тесты и критерии успешной сдачи вы предлагаете зафиксировать в договоре?
- Как в договоре описаны SLA и штрафные санкции за нарушение сроков или простой?
- Какая документация передаётся заказчику после сдачи проекта и как заказчик вправе её использовать в дальнейшем?
По поддержке после сдачи:
- Какой режим поддержки предлагается, какие каналы обращения, какое гарантированное время реакции по классам инцидентов?
- Как устроена процедура эскалации, если стандартный канал не сработал?
Что проверить в договоре
Договор с интегратором задаёт рамку всего проекта: границы работ, ответственность сторон, приёмку, поддержку, условия расторжения. Ниже шесть пунктов, которые стоит внимательно проверить перед подписанием.
Границы ответственности. Полезно, чтобы в договоре было чётко описано, что делает интегратор, что остаётся за заказчиком и что за другими подрядчиками (например, вендором оборудования или сетевым провайдером). Размытые границы часто становятся источником споров по зоне ответственности в ходе проекта.
SLA и штрафные санкции. Одного упоминания «оперативно реагируем» недостаточно. Стоит проверить, зафиксированы ли в договоре конкретные значения: время реакции на инцидент по классам критичности, время восстановления, ответственность подрядчика за простой сверх согласованных значений. Сам состав SLA всегда зависит от конкретной услуги и от того, что заказчик и подрядчик считают приемлемым уровнем сервиса.
Приёмочные тесты и условия сдачи. Как именно будет проверяться, что проект сдан. По каким метрикам, кем, на какой продолжительности испытаний. Расплывчатые формулировки «система работает штатно» на этапе приёмки часто превращаются в затяжные споры.
Передаваемая документация и права заказчика на её использование. Полезно зафиксировать в договоре состав материалов, которые передаются заказчику после сдачи проекта: архитектурные схемы, конфигурации, эксплуатационная документация, регламенты работы. Отдельно стоит проговорить, как заказчик вправе использовать эти материалы в дальнейшем: самостоятельно, при передаче другому подрядчику, при масштабировании или модернизации решения.
Процедура эскалации. Что делать, если через стандартный канал поддержки вопрос не решается за оговорённое время. Кто следующий уровень, за какое время он должен подключиться, куда обращаться дальше. Без прописанной эскалации критичная ситуация зависает на исполнителе первой линии.
Условия выхода из проекта. На каких условиях каждая из сторон может расторгнуть договор, что происходит с уже выполненными работами, с оборудованием, с оплатой. Условия выхода полезно проговорить и зафиксировать до подписания договора. Разбираться в них во время уже возникшего конфликта заметно сложнее.
Что должно насторожить при выборе подрядчика
Есть несколько сигналов, при которых имеет смысл серьёзно взвесить, стоит ли отдавать проект этому подрядчику. Каждый из них по отдельности не всегда критичен, важно смотреть на сочетание.
Портфолио, которое не удаётся раскрыть в деталях. В презентации перечислены крупные заказчики и внушительные проекты, но подрядчик не готов подробно рассказать про конкретный кейс: какая была задача, какие принимались решения, что оказалось сложным, что делали иначе, чем планировали изначально. Отсутствие возможности организовать разговор с прошлым заказчиком само по себе не показатель: у клиентов часто действуют NDA и внутренние ограничения на референсы. Но если и содержательного разбора кейса тоже нет, стоит уточнить, за счёт какой экспертизы подрядчик готов работать с вашим проектом.
Нет проектов сопоставимого масштаба и сложности, при этом подрядчик активно берётся. Компания без опыта крупных внедрений заявляет готовность закрыть многомесячный комплексный проект, но не может внятно объяснить, за счёт чего справится: какая команда собирается, какая методология применяется, какие партнёры привлекаются на недостающую экспертизу.
Непрозрачный состав проектной команды. На вопрос «кто конкретно будет работать по нашему проекту, кто архитектор, кто PM» вы получаете размытые формулировки «наши специалисты подключатся», без имён ролей и зон ответственности. Или отказ показать соотношение своих сотрудников и привлечённых подрядчиков, а также объяснить, как выстроен контроль качества привлечённых.
Одна вендорская линейка без обоснования. Подрядчик уверенно предлагает решение на конкретных продуктах, но не готов объяснить, почему именно они, и не разбирает возможные альтернативы. Без такого обоснования сложно понять, насколько предложенный стек оптимален именно под вашу задачу.
Размытые SLA без конкретики. В договоре или коммерческом предложении фигурируют формулировки «оперативно реагируем», «стараемся минимизировать простой», без времени реакции в часах, без классификации инцидентов, без ответственности за нарушение. После сдачи проекта у вас не будет измеримых обязательств подрядчика.
Отказ проговаривать сложные ситуации. На прямые вопросы про то, что будет при срыве срока, при инциденте с продом, при уходе ключевого инженера, подрядчик отвечает общими словами и не готов обсуждать конкретные сценарии.
Если проект затрагивает несколько ИТ-систем или требует комплексной модернизации инфраструктуры, специалисты «Инком интер» помогут оценить задачу и определить возможный вариант реализации.