Слухи о необходимости замены импортных программных продуктов ходят еще с 2014 года. Но до 2022 года, кажется, многие организации и их ИТ-директоры воспринимали это скорее, как маркетинговый трюк, а не реальную потребность. Уход большинства зарубежных вендоров из России вызвал панику среди руководства ИТ-индустрии. Что позже превратилось в целый ряд различных проектов: срочные переходы с глобального шаблона SAP на локальную версию, внедрение продуктов 1С, создание кастомных разработок для заполнения возникших пробелов на рынке, а также долгосрочные инициативы по импортозамещению. Все это затронуло многих в нашей области: занимаясь только проектами и продуктами SAP, мы пропустили множество других программных решений и способов их внедрения, которые демонстрируют разнообразие в мире информационных технологий и корпоративных информационных систем (КИС).

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

Поучаствовав в нескольких проектах внедрения 1С решений, а также кастомных разработок и имея более чем 15-ти летний опыт вовлечения в SAP проекты, я бы хотел поделиться результатами сравнения особенностей их реализации. Дальнейший материал будет рассматриваться в контексте следующих проектов: тиражирование SAP ERP, автоматизация закупочной деятельности на базе SAP ERP MM/IM/FM, имплементация 1С ERP, БП и ЗУП, подготовка целевой ИТ-архитектуры на базе 1С ERP, а также реализация кастомного SRM-решения, для которых было критически важно подобрать релевантную модель внедрения и доставить результат точно в срок.

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

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

Если речь зашла о кастомных разработках, было бы полезно освежить знания по гибким методам внедрения программных продуктов – это классические итерационные и спиралевидные модели (многопроходные модели), представленные в настоящее время Agile методологией. Здесь следует вспомнить о матрице Стейси по бизнес и технологической неопределенностям, явно задающей область применения методов Agile. Так, если бизнес-требования статичны и есть строгое понимание того, как они будут технически реализованы, используется каскадная модель внедрения, во всех остальных случаях – методы гибкой разработки (рисунок 3). Стоит также подчеркнуть, что применение гибких методов, к примеру, Agile Scrum, требует полной трансформации проектной команды по сравнению с классической ее организацией в водопадной схеме имплементации. Однако никто вас не сдерживает от применения принципов Agile в проектах внедрения, базирующейся на каскадной модели.

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

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

• подготовка;

• дизайн;

• реализация;

• переход к Промышленной эксплуатации (ПЭ);

• гиперподдержка ПЭ.

Несмотря на активное упоминание ASAP и предоставление акселераторов к ней, представленных готовыми шаблонами документов и списком проектных задач, для российского рынка она не совсем подходила. Практический опыт показ, что более эффективная схема имплементации ERP-системы, назовем ее ADM, включает следующие этапы (рисунок 4):

• подготовка;

• анализ;

• дизайн;

• реализация;

• тест;

• переход к ПЭ;

• гиперподдержка ПЭ.

Преимущества предлагаемой модели ADM в том, что:

• внимание сосредотачивается на требованиях, которые четко выделяются, описываются и приоритизируются на этапе анализа. Все последующие этапы базируются на них. Это важное отличие от модели ASAP, где требования фактически прорабатываются параллельно с проектированием решения, что часто приводило к увеличению объема проекта;

• особый акцент делается на фазе тестирования, которая была специально добавлена и адаптирована под российские условия. Так проверка продукта проводится в ходе непрерывного приемочного тестирования, что тесно связано с классической моделью V-разработки через тестирование.

Модель ADM доказала свою применимость как в проектах внедрения «с нуля», так и тиражирования. Ее основная область применения – имплементация масштабных программных решений классов ERP-ERP3 или их аналогов. Примерами успешного применения ADM служат: тиражирование SAP ERP в алкогольной компании, автоматизация закупочной деятельности на базе SAP ERP MM/IM/FM в крупном международном ретейлере.

Теперь рассмотрим проекты имплементации 1С. Вендором предлагается три технологии внедрения продуктов 1С: технология стандартного внедрения (ТСВ), технология быстрого результата (ТБР) и технология корпоративного внедрения (ТКВ). Следуя информации от 1С, имплементация программных продуктов класса ERP может вестись преимущественно на основе метода 1С: ТКВ. Согласно модели 1С: ТКВ процесс имплементации представим классической спиралевидной моделью, где этап реализации состоит из набора итераций по разработке и настройке программной системы по принципам Agile. Проект внедрения представим фазами (рисунок 5):

• инициация;

• формирование требований к ИС;

далее повторяющиеся этапы согласно спиралевидной схеме имплементации:

• проектирование ИС;

• разработка ИС;

• подготовка к вводу ИС в опытную эксплуатацию (ОЭ) и/или опытно-промышленную эксплуатацию (ОПЭ);

• проведение ОЭ и/или ОПЭ;

• подготовка к вводу ИС в ПЭ;

• проведение ПЭ

и, наконец, завершение проекта.

Несмотря на наличие детально описанной технологии, вариабельности этапов и задач, существование акселераторов, имплементация 1С решений многими ИТ-компаниями зачастую велась произвольным образом. И это было допустимо для проектов в небольших организациях, однако, чревато неудачами в случае крупных и распределенных предприятий. Как оказалось, в технологии 1С: ТКВ, рекомендуемой для крупных проектов, слабо проработаны вопросы миграции, перехода, да и тестирования в целом. Для внедрения масштабных 1С решений, к моему удивлению, идеально подошла методология, используемая в проектах SAP (рисунок 4). В частности, в проекте имплементации 1С ERP, БП и ЗУП в крупную производственную компанию, методология 1С: ТКВ здесь попросту не сработала, а также при подготовке целевой ИТ-архитектуры на базе 1С ERP в крупной оптовой организации, где управляющий комитет не согласился с составом этапов и работ согласно 1С: ТКВ, сведя модель внедрения к схеме ADM.

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

• акцент на построение технической ИТ-архитектуры;

• продолжительный срок реализации проекта;

• реинжиниринг программного продукта, а не процессов заказчика;

• Agile ориентированный подход к организации и выполнению проекта;

• иной состав проектной команды.

В отличие от коробочных программных решений SAP и 1С, в которых функциональное ядро системы уже реализовано, а его донастройка и доработка рассматриваются как «бантики», разработка «с нуля» требует значительных усилий по детальной проработке будущего программного решения: языки программирования для реализации фронтенд и бекенд компонентов системы и/или применение существующих сервисов и технических решений, технологии обеспечения интеграции, системы управления базами данных и др., что по умолчанию увеличивает длительность проекта в разы. Будущий программный продукт определяется набором из функциональных и бизнес-требований. Так как все требования должны быть разработаны «с нуля», актуальной становится потребность в их приоритизации для распределения разработки по времени. Поэтому в моем случае при разработке SRM-системы сильно ощущалась потребность в итерационных и спиралевидных моделях внедрения. Имея опыт имплементации коробочных программ, было принято решение воспользоваться не моделью Agile Scrum, а методологией, близкой к 1С: ТКВ:

• все требования были приоритизированы и сформированы 3-и волны внедрения;

• в рамках каждой волны внедрения этап разработки был разбит на итерации, в рамках которых реализовывалась часть программного продукта с последующей демонстрацией пользователям;

• этапы подготовки и проведения ОЭ и/или ОПЭ были заменены на единую фазу тестирования.

Предлагаемая модель внедрения получалась как гибрид тех, что проиллюстрированы на рисунках 4-5, и включает фазы (рисунок 6):

• подготовка;

• анализ (включая построение ИТ-архитектуры в TO-BE);

далее трижды повторялись этапы согласно спиралевидной схеме имплементации:

• дизайн;

• реализация;

• тест;

• подготовка к ПЭ;

• гиперподдержка ПЭ.

Структура проектной команды также претерпела изменения в виду особенностей кастомной разработки и Agile-ориентированной модели внедрения, появились роли:

• технический архитектор;

• архитектор по данным;

• архитектор по интеграции;

• тестировщики

в дополнение к общепринятым: руководитель проекта, консультанты и разработчики. Если внедрение коробочной ERP-системы в среднем требует 6-12 месяцев, то в нашем случае это был срок только одной из трех волн имплементации.

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

Таблица 1. Отличия проектов внедрения коробочных и кастомных программных решений

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

Вся работа по имплементации ERP-систем основана на выбранной методологии, которая определяет, как будет проходить проект. Все, кто занимается такими активностями, хоть немного знаком с PMBoK: набором основных знаний по управлению проектами. Его главная идея - следовать циклу планирования, выполнения и контроля работ, а также обработке отклонений. Важно правильно выбрать и применить модель жизненного цикла проекта внедрения, чтобы успешно завершать задачи вовремя и избегать проблем. Как сказал Бенджамин Франклин: «Плохая подготовка - путь к неудаче».