Переход на интеллектуальные отечественные ERP:
как это сделать правильно

При любом корпоративном внедрении ERP, как правило, мы имеем следующие важные вводные:

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

Соответственно, критически важно на протяжении всего жизненного цикла обеспечить внутри команды исполнителя и заказчика следующее:

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

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

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

Для поддержки этой комплексной методологии внедрения использовался соответствующий инструментарий, который в сегодняшней ситуации должен быть трансформирован. Так, если раньше для проектного управления преимущественно применялись такие продукты, как Jira, Confluence, Trello, развитый MS Project, то теперь мы учимся работать в альтернативных средах — например, с помощью YouGile, Comindware, Yandex Tracker, GanttPRO, ProjectLibre, «МегаПлан». Для внутренних проектов в своей компании мы используем собственный инструмент Service Management System, который сочетает возможности для ведения проектов по практикам Waterfall и Agile с технологическими инструментами DevOps, полностью независимыми от зарубежных санкций.

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

Зато выбор платформы ERP стал заметно проще: по сути, это может быть «1С» или «Галактика».

Каждый из этих програм­мных продуктов умеет работать на импортонезависимых ОС и СУБД. Но, к сожалению, большая часть ИТ-специалистов на практике не умеют работать с таким ПО. Да и сам софт требует серьезной доработки под ряд задач, например обеспечения режима inmemory для больших и сложных отчетов. Но, повторюсь, и эта задача решаема в текущих реалиях, скажем, через отечественный ClickHouse от «Яндекса», подключаемый к 1С ERP. Однако пока такие решения нельзя назвать отраслевым стандартом — он требует доработки под каждого заказчика. Но это вполне действенное решение.

Итак, для успешного внедрения ERP вашей команде необходимо владеть следующими практическими навыками (помимо стандартных по ведению проектов):

• Уметь сочетать методики Waterfall и Agile, уметь работать с инструментами ведения проектной деятельности.
• Быть способной настроить инструменты DevOps и организовать разработку и передачу ее результатов в соответствии с каждой из этих методологий.
• Быть способной выстроить грамотные коммуникации с заказчиками (это важно, поскольку топов интересуют глобальные сроки и результаты проектов — они отслеживают план-график подрядчика, тогда как конечные пользователи скорее работают с пользовательскими историями).
• Владеть актуальными знаниями об импортонезависимых продуктах и знать, как с ними работать.

Что же делать, если необходимо в кратчайшие сроки перейти от иностранных продуктов к отечественным? Рассмотрим два варианта: либо все продукты без исключения иностранные, либо ERP —– отечественная, а остальное — иностранное (вариант, когда уже все ПО отечественное, не рассматриваем).

Начнем с последнего: все иностранное, кроме ERP. В этом случае план действий должен быть такой:

1. Прогнозируем сроки, в которые необходимо перейти от иностранных серверов приложений, терминалов и СУБД — к отечественным.
2. Оцениваем окружение на отечественном ПО, достаточное для обеспечения непрерывности бизнеса (и не только серверов приложений, СУБД и терминальных сессий, но и всего офисного окружения — аналогов MS Office, таких как OpenOffice или LibreOffice).
3. Параллельно определяем сроки и трудозатраты на тестирование текущих ERP-продуктов в отечественном окружении.
4. Согласовываем с бизнес-заказчиком приоритеты и критичность по проверке функционала. Определяем функционал, от которого в случае какого-либо ЧП можно отказаться или подождать «реанимации» под новые серверы СУБД и приложений (для 1С-решений предпочтительна связка Astra Linux и PostgresPro).
5. Дорабатываем нагрузочные и сценарные тесты, параллельно разворачивая испытательный стенд на отечественном ПО.
6. Выполняем нагрузочные и сценарные тесты, при необходимости адаптируя код ПО (как правило, это касается только учетных систем, но иногда есть выходы и на поставщиков СУБД).
7. Планируем и проводим масштабную миграцию с серверов зарубежного ПО на отечественные. Как правило, этот процесс занимает один-два дня. Если же такой простой бизнеса неприемлем, рекомендуется написать правила обмена между своими конфигурациями: пока бизнес продолжает вести учет на старых серверах с иностранным ПО, все изменения копятся на узлах обмена (применительно к «1С», в «Галактике» — похожие принципы). Далее, после готовности серверов с отечественным ПО накопившиеся данные обменом переносятся со «старых» серверов на новые, и с этого момента пользователи начинают работать уже на отечественных серверах.
8. Рекомендуется на ближайшие пару быстрых закрытий и весь период между ними усилить поддержку всех ИТ-служб: потребуется помощь пользователям в освоении новых продуктов, да и вероятность внештатных сбоев в этот период велика.

Если же все ПО иностранное, то написанное выше будет по-прежнему актуально, однако на начальных этапах необходимо сделать следующее:

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

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

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