В этой статье я хотел бы поделиться опытом компании RedSys в области реализации и управления проектами системной интеграции. Надеюсь, читателям он покажется в чем-то интересным или даже полезным. Под интеграционными я имею в виду не проекты по интеграции таких инфраструктурных элементов, как сети, серверы и СХД, а те, в которых необходимо реализовать некий набор сквозных бизнес-процессов, отвечающих специфическим требованиям данной организации. Бизнес-процессов, которые базируются на множестве нередко разнородных, прикладных систем и источников данных. В тексте статьи вы не найдете наименований каких-либо платформ, вендоров, описаний технологий, технических деталей и архитектурных решений. Вы не увидите также ни одного упоминания реальных заказчиков, что позволит нам сконцентрироваться на сути выбранных для рассмотрения аспектов: с чего начинать, как принимать решения, оценивать риски и т. д.

Проекты, в которых присутствует интеграционный аспект, считаются одними из наиболее сложных. Связано это с тем, что решение, созданное в ходе такого проекта всегда уникально, а это значит, что подход к реализации и управлению подобными проектами также должен быть индивидуальным. Если мы еще вспомним, что обязаны уложиться в отведенные сроки, бюджет и обеспечить требуемое качество, то становится очевидно, что браться за реализацию таких проектов можно только при наличии высококвалифицированной команды и качественной поддержки проекта на всех уровнях и этапах.

Важность пресейла

Запуск проекта может быть инициирован как заказчиком, так и интегратором, но в любом случае начинается интеграционный проект с этапа пресейла, на котором стороны должны разобраться в том, что же действительно хочет заказчик и какие системы предстоит интегрировать. Немаловажно также оценить требования к документированию: например, подготовка документации с учетом ГОСТа или в соответствии с ГОСТом — это, как говорится, две большие разницы. Более того, на этом этапе можно оценить реальную заинтересованность клиента и его фактическую готовность к планируемому проекту. Пресейл предшествует подписанию контракта, и заказчик в принципе может проводить подобные работы одновременно с несколькими потенциальными подрядчиками. Мы убеждены, что на стороне интегратора в пресейле, вместе с сейлами должны быть задействованы технические специалисты, причем именно те, которым впоследствии придется участвовать в реализации проекта.

Ответственность этой работы сложно переоценить, поскольку в результате нужно принять единственно верное решение, оперативно изучив большой и в то же время далеко не полный объем информации, проведя ряд исследований, очень часто сталкиваясь с необходимостью применения новых технологий, сервисов и приложений. И все это в условиях крайне ограниченного времени: обычно не более двух недель плотной работы команды из трех человек. Ошибки на этом этапе могут иметь катастрофические последствия как для исполнителя, который понесет финансовые и репутационные потери, так и для заказчика, который не сможет в желаемые сроки решить свои задачи.

Следует отметить, что на этом этапе активную роль должен играть и заказчик, который нередко не до конца представляет, что ему по-настоящему нужно, а что носит факультативный характер. Выделение для этой цели специалистов заказчика на долговременной основе поможет ему лучше понимать требования проекта и не пытаться, как иногда бывает, просто выторговывать максимальное снижение цены в ущерб качеству или производительности создаваемого решения. Активное включение заказчика в работу на этапе пресейла создает предпосылки для последующего формирования совместной с подрядчиком команды, которая будет участвовать в проектировании, реализации и внедрении системы.

Полностью полагаться на системного интегратора не следует: никто лучше штатных функциональных и технических специалистов заказчика, не знает всю специфику и особенности его бизнес-процессов. Такие сотрудники обычно загружены текущей работой, и добиться их привлечения на этапе пресейла бывает непросто, но чем раньше они подключатся к совместной работе, тем лучше для проекта. Не исключено, что в процессе совместной работы на этапе пресейла придет осознание того, что организация не готова к реализации проекта. Такого вывода бояться не стоит,: лучше будет и для заказчика, и для интегратора понять это в самом начале и принять правильное решение, которое позволит всем не потерять свои деньги, а подрядчику еще и не поставить под сомнение свою репутацию.

Интегратору следует предварительно обобщить всю предысторию работы с данным клиентом (при ее наличии, разумеется): были ли успешные продажи и по каким позициям (услуги, лицензии, оборудование), как возник запрос на данный проект, с кем из руководства заказчика можно контактировать напрямую в ходе пресейла (первые лица, ИТ-руководство, начальники функциональных подразделений). Полезно также иметь полное представление о конкурентной среде. Зная все это, вы сможете понять возможный уровень поддержки проекта, оценить реальную заинтересованность клиента и его фактическую готовность к нему.

Редко какой интеграционный проект может быть выполнен в соответствии с жестко прописанным техзаданием: всегда возникают нюансы, которые трудно было спрогнозировать на ранних этапах. Поэтому при написании технического задания заказчик и исполнитель должны договориться о подходе, который позволит решать подобные проблемы альтернативными средствами или же вносить коррективы в функциональность конечного решения, необходимость в которых была выявлена уже в ходе выполнения проекта (скажем, изменилась нормативная база).

Реализация и внедрение

Далеко не всегда проектирование и прототипирование создаваемого решения можно проводить в ИТ-инфраструктуре заказчика. Обычно мы на своей площадке моделируем инфраструктуру заказчика, разворачиваем на ней тестовую среду и пытаемся интегрировать те или иные прикладные системы. Несмотря на то что в тестовой среде интеграция проверяется очень тщательно, на этапе внедрения в инфраструктуре заказчика проблемы тем не менее случаются.

Вообще следует помнить, что любой интеграционный проект в силу своей сложности и уникальности несет с собой массу рисков, которые на ранних этапах выявить бывает очень сложно. Поэтому в планах необходимо закладывать определенный запас по срокам и стоимости с расчетом на решение непредвиденных проблем. Кроме этого, в процессе реализации очень часто возникают незапланированные задачи, решение которых может повлечь за собой сдвиг сроков или необходимость в дополнительных расходов. Чтобы иметь возможность оперативного принятия решений и снять у заказчика сомнения в обоснованности дополнительных расходов, очень полезно бывает еще на ранних этапах включить в проектную группу экспертов со стороны заказчика.

Наличие совместной проектной команды, в которой активно участвуют эксперты заказчика, обеспечивает качественную обратную связь с его топ-менеджментом и дает выход на высших руководителей в случае возникновения критически важных проблем. А риски бывают самые разные. Не всегда функционирование программного продукта полностью соответствует текущей документации вендора. Не все интеграционные механизмы поддерживаются в ПО одного и того же вендора. Иногда необходимо использовать недокументированные полезные возможности, для получения доступа к которым потребуется специальное обращение к разработчикам продукта и дополнительное время. Нередко проблемы, которых не было в тестовой среде, возникают после развертывания в ИТ-инфраструктуре заказчика в силу ее большей загруженности или иных особенностей. Да и требования заказчика за время выполнения проекта могут измениться как по объективным, так и по субъективным причинам (не все было учтено на этапах выпуска техзадания и проектирования) — это тоже риск. Последнее случается обычно в тех случаях, когда у заказчика нет опыта проведения такого рода проектов (недостаточный уровень зрелости). В этом случае значительно повысить шансы успешной реализации позволит привлечение к проекту для работы на стороне заказчика экспертов, имеющих необходимый опыт.

Такой шаг повысит уровень зрелости заказчика и заложит хороший фундамент для сопровождения и развития внедренной системы. Кроме того, наличие таких людей позволяет избежать ловушки избыточных ожиданий, в которую иногда попадают специалисты заказчика, далекие от проблематики ИТ и системной интеграции. Вообще мониторинг ожиданий заказчика должен осуществляться исполнителем в ходе всего проекта, при этом системный интегратор должен оставаться максимально открытым и готовым к обсуждению самых острых проблем (а не замалчивать их). Иногда это позволяет находить конструктивный выход из, казалось бы, безвыходных положений путем взаимоприемлемых корректировок техзадания или отдельных функций.

Пожалуй, наиболее ответственный этап проекта — внедрение. Он дополнительно осложняется тем, что интегратор работает в чужой среде и скован жесткими временными рамками, а заказчик должен оперативно обучить своих сотрудников и начать эксплуатировать систему, не ставя под угрозу работу остальных систем и непрерывность своего бизнеса в целом. Здесь особенно важно работать в плотном контакте с системными аналитиками и бизнес-экспертами заказчика, которые вошли в проектную команду еще на самых ранних этапах и хорошо знают особенности внедряемого решения.

Что будет после

Даже после формального завершения проект продолжает жить своей жизнью. Внедренную систему нужно поддерживать. Иногда это делается силами ИТ-департамента заказчика, если у него есть соответствующие специалисты, но очень часто на техподдержкой этим занимается интегратор, выполнявший проект. Это достаточно эффективно, поскольку он лучше кого бы то ни было знает внедренное решение, и именно его целесообразно привлекать на последующие проекты по развитию и расширению функциональности системы. А подобные проекты — скорее правило, чем исключение: на предприятии внедряются новые прикладные системы, появляются новые бизнес-процессы или кардинально модернизируются существующие и т. д. В случае локальных неудач на конкретном проекте, заказчику не стоит менять исполнителей, каждый раз надеясь на чудо. Только в процессе длительной работы на сложном проекте возникает самое ценное с моей точки зрения — совместный опыт и доверие. А если есть доверие, то многие из упомянутых выше проблем теряют свою остроту. Формирование слаженной совместной команды — едва ли не основной фактор успеха: именно она обеспечит соответствие создаваемой системы реальным потребностям бизнеса и завершение проекта в приемлемые сроки, а также смикширует основные риски.

Автор статьи — Владимир Недобой, директор Центра интеграционных решений компании RedSys.

СПЕЦПРОЕКТ КОМПАНИИ REDSYS