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