Александр Казённов, Руководитель корпоративной практики Департамента корпоративных информационных систем ALP Group.

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

При этом значительно расширился и спектр процессов, которые должна активно поддерживать ERP-система. Это уже не просто учетные функции, но и всесторонняя поддержка менеджмента на основе данных (DDM), непрерывное улучшение и роботизация бизнес-процессов, поддержка трансформации организации (например, переход к внутреннему аутсорсингу по схеме ОЦО, формирование партнерских, отраслевых и региональных кластеров и др.). И все это происходит на фоне значительного ускорения изменений рынков, деловой среды, усиления регулирования и выхода на первый план целого букета новых информационных технологий (импортонезависимые платформы ERP и других бизнес-систем, Big Data, «слабый ИИ» и т.п.). Всё это привело к появлению нового класса бизнес-систем (i-ERP), где учетно-аналитическое ядро ERP и все окружающие ее бизнес-приложения тесно интегрированы друг с другом и опираются на общую технологическую платформу организации.

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

При любом внедрении ERP-системы в крупной организации практически всегда проходит в рамках следующие важных ограничений.

1.  В компании имеются внутренние и внешние (идущие от регуляторов) нормативно-методические документы (НМД) и стандарты по бизнес-процессам, находящиеся в разной степени готовности и детализации. Эти ограничения надо выполнять.
2. Требования к автоматизации динамично меняются — в соответствии с постоянным развитием самой организации, изменения отраслевых норм, появлением новых управленческих моделей и ИТ-инструментов.
3. Круг лиц, принимающих решения по проекту или так или иначе участвующих в процессе внедрения, достаточно широк. Вхождение в этот круг и влияние на создаваемую систему обычно рассматривается как подтверждение статуса, поэтому делегирование полномочий происходит болезненно или вообще буксует.
4. Создаваемое решение должно опираться на набор стандартных или отраслевых рыночных решений класса ERP различной степени готовности для использования тех задач, которые нужны именно в этом проекте, этой организации, на данном этапе её развития.

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

Подчеркну: эти нюансы проекта было важно прорабатывать во все времена. При этом раньше, когда большая часть проектов реализовывалась строго по практикам waterfall, это создавало большой риск получить на выходе никому не нужную систему, весьма далёкую от актуальных на момент окончания внедрения бизнес-процессов, практик менеджмента, потребностей бизнес-подразделений. Чтобы снизить этот риск до приемлемого уровня, на проектах такого класса вводилась (и используется до сих пор) оперативная приёмка промежуточных результатов и проработка требований на следующий участок автоматизации с максимальным прицелом на грядущие требования. Происходила борьба «плюсов» и «минусов». С одной стороны, такая модель управления внедрением негативно сказывалась на бюджете и сроках проекта. С другой – уже на стадии опытной эксплуатации заказчик получал новый работающий функционал, отвечающий актуальным потребностям и процессам. Как правило, реализация изменившихся требований предполагала корректировку плана проекта, из-за чего он становился очень большим и сложным, практически недоступным для оперативного использования. А это снижало эффективность всего подхода. Как и достаточно большая длительность этапов. Проблема становилась все более острой, ведь темп и разнообразие изменений нарастает, это объективная реальность. Нужно было найти решение.

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

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

Но одно дело — выработать идею объединения двух совершенно разных методик управления. И совсем другое — применять его на практике. Для этого нужны инструменты автоматизации. При этом для каждого подхода в отдельности таких инструментов разработано немало, и специалистам они хорошо известны. Для «водопадной» методики — это MS Project и аналогичные инструменты. Для Agile: Jira, Confluence, Trello и др.

Однако попытки совместного применения столь разных инструментов создают огромные практические трудности. Слишком различаются методики управления проектами, слишком сложны и богаты функциями специализированные инструменты, слишком сложна их интеграция, без которой невозможно поддерживать целостное видение проекта и доступ к деталям. Мы нашли единственный выход, хотя и сложный: самостоятельно разработали инструмент и методики, который не только сочетает инструменты для ведения проекта по практикам Waterfall и Agile, но и содержит инструменты DevOps. Теперь мы используем этот инструментарий в проектах внедрения ERP-решений, где заказчик готов применять сочетание Agile и DevOps. Интегрированное решение оказалось действительно удобным: высокая адаптивность уже не затрудняет движение проекта к главным целям, не обрушивает его ресурсную базу, не приводит к неконтролируемому «закапыванию в детали».

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

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

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