В последние годы на фоне таких актуальных тем, как цифровая трансформация, большие данные, искусственный интеллект, машинное обучение и облачные вычисления, вопросы внедрения и развития ERP-решений как бы ушли на второй план. Тем не менее возможность бесшовной, сквозной интеграции функций и данных, стандартизация бизнес-процессов в разных регионах и подразделениях, обеспечиваемые ERP-системами, делают их фундаментальным активом множества компаний.
Большинство проектов по внедрению ERP реализуется с использованием линейного, последовательного «водопадного» (waterfall) подхода. Иногда при этом проект, включающий длительные этапы проектирования, разработки спецификаций и проектной документации, растягивается на несколько лет, а его результат не соответствует реальным изначальным желаниям руководства. Не говоря уже о том, что такие пожелания в условиях набирающей обороты стратегии цифровой трансформации могут в ходе проекта существенно меняться. Не удивительно, что все больше внимания привлекает возможность перехода от статичной методологии waterfall к более гибкой и динамичной Agile, хорошо зарекомендовавшей себя в проектах заказной разработки ПО.
Достоинства Agile
Подход Agile позволяет разбить весь объем функциональности ERP-системы на наборы функций, которые небольшие команды могут реализовывать в так называемых спринтах — коротких этапах длительностью
Для быстрой фиксации результатов внедрение происходит в несколько волн. Комплексные команды от восьми до десяти человек, включающие представителей бизнеса, ИТ-департамента и системного интегратора, полностью проектируют, разрабатывают и тестируют свою подсистему. В компании Amazon, например, придерживаются так называемого «принципа одной-двух пицц»: если для завтрака команде требуется более одной-двух пицц, то нужно разделить команду на две.
Контрольное функциональное и пользовательское тестирования проводятся с регулярной периодичностью, а не только один раз по окончании всего waterfall-проекта, что приводит к повышению качества системы и способствует автоматизации тестирования. Нефункциональная работа (например, миграция данных, обучение персонала и развертывание системы) менее подвержена влиянию Agile-подхода, хотя определенная координация между функциональными и нефункциональными командами все же необходима.
Специалисты компании «Гигабайт», занимающейся внедрением ERP-систем «1С», считают, что Agile-методы являются идеальными для средних компаний — производственных и торговых предприятий с численностью сотрудников
Еще один внедренец систем «1С» — компания «1С-Рарус НН» — успешно использовала методологию Agile в проекте по внедрению ERP-системы в группе «Росполихим». Функциональность в системе реализовывалась поэтапно с демонстрацией в конце каждого этапа минимально жизнеспособного продукта. На первом этапе был запущен блок отгрузок, затем производство и склад. Благодаря постоянному получению обратной связи со стороны бизнес-подразделений заказчика подрядчику удалось контролировать риски и управлять ими на самых ранних стадиях проекта.
Директор департамента корпоративных информационных систем ALP Group Светлана Гацакова отмечает недостатки традиционного подхода к внедрению, которые могут быть преодолены с помощью Agile. Сегодня при внедрении ERP-систем практически невозможно точно определить функциональность решения в начале проекта, и потом ее не менять. Среда, в которой действует предприятие, меняется так быстро и по столь различным направлениям, что за время создания комплексного ERP-решения (и даже только техзадания на него) одни задачи теряют актуальность, другие трансформируются, а третьи (которых вообще не было на старте проекта) выходят на уровень первостепенной важности. В этих условиях формальное соблюдение ТЗ неизбежно ведет к тому, что создаваемая с таким трудом система устаревает еще до завершения проекта или вообще оказывается мертворожденной. Такое ERP-решение не нужно ни заказчику, ни добросовестному исполнителю.
Проблемы Agile
Руководитель проектов отделения ERP-систем компании «ФОРС — Центр разработки» Андрей Жилин отмечает, что далеко не все российские компании готовы полностью доверять такому подходу при внедрении ERP-систем, поскольку в нем не учитываются юридические и бухгалтерские реалии проектной деятельности. Особенно в случаях, где есть заказчик и внешний подрядчик, которые не понимают, как юридически оформить Agile-проект. Как в рамках договора указать «гибкую» разработку, как оговорить в юридических терминах то, что с течением времени и в зависимости от ситуации в компании или на рынке рамки, сроки и стоимость работ могут быть изменены? К этому стоит добавить, что к «гибкому» подходу не готовы компании и организации с госбюджетным финансированием, в которых цели и график выполнения проекта утверждаются в самом начале, а его оплата может быть привязана только к заранее оговоренным этапам, а не к каким-то эфемерным спринтам.
Главный, по мнению Светланы Гацаковой, риск применения agile-подхода — его потенциально неумеренная адаптивность. Если вместо интенсивного движения по основным линиям развития создаваемого решения фактическим содержанием работ станет бесконечная шлифовка функциональности, созданной и предоставленной пользователям в ходе ранее выполненных спринтов, проект может превратиться в долгострой.
В своем блоге ИТ-директор Qurate Retail Group Дмитрий Герзон напоминает, что концепция ERP-системы родилась в свое время как антитеза использованию в компаниях набора лучших в своем классе бизнес-приложений разных вендоров. Такая система должна развертываться как единое целое. Ключевое для методологии Agile понятие минимально жизнеспособного продукта (MVP) трудно применимо для ERP-системы, содержащей предварительно интегрированную архитектуру бизнес-процессов. «Такая система — это „цифровой близнец“ вашей компании, — объясняет Дмитрий Герзон. — Можете ли вы представить себе, что, скажем, бухгалтерия станет вашим единственным полнофункциональным подразделением, а остальное вы добавите позже? Вы покупаете ERP, потому что хотите, чтобы большинство ваших процессов были предварительно интегрированы. Выбрать один сквозной процесс для MVP-реализации, оставив остальные процессы в унаследованной среде, практически невозможно. Как только вы принимаете решение о внедрении новой ERP-системы, все процессы должны быть запущены, и это делает внедрение ERP-системы единым большим проектом. Небольшой команде численностью
Тем не менее, по его мнению, если Agile-методология и применяется, то все ERP-внедрения используют гибридный подход с проектированием и тестированием по модели водопада в начале и в конце проекта и спринтами на промежуточных этапах. Эксперты компании «Гигабайт» признают, что две методологии внедрения — Agile и waterfall — на самом деле обычно сочетаются. После обследования намечаются функциональные блоки автоматизации, а затем идет работа по каждому из этих блоков. В этом случае сохраняются некоторые процессы моделирования и проектирования, но в упрощенном виде, и заказчик получает видимый результат быстрее, чем при традиционной водопадной модели. Объем проектной документации при этом может быть сокращен (например, можно не писать модели «как есть», только «как будет», не составлять подробных технических заданий на доработки, а давать только их концептуальное описание и т. д.).
Как найти компромисс
Обозреватель ERP News Пандора О’Хара отмечает, что именно поэтому многие предприятия для интеграции Agile-методологии в развертывание ERP отдают предпочтение гибридным подходам, таким как Scaled Agile Framework (SAFe), позволяющим использовать Аgile-методологии в больших командах размером более 50 человек. Вместо двухнедельных спринтов SAFe разбивает развертывание на более продолжительные «волны функциональности». Гибридные подходы начинаются с последовательных этапов, принятых в методологии водопада, но позже используют методологию Agile в процессе разработки на этапе тестирования.
В компании Infosys, по словам ее ведущего консультанта Санджая Талати, для крупных облачных Agile-внедрений ERP применяется собственная методология Agile Cloud Implementation Framework (ACIF), которая использует инструменты инспектирования и адаптации, позволяющие сократить расходы на разработку и время вывода продукта на рынок. ACIF состоит из четырех ключевых этапов: разработка стратегии, проектирование, выполнение и стабилизация.
Один из главных упреков в адрес Agile-внедрения ERP состоит в том, что заказчик рискует получить в результате не ту систему, о которой договаривались с подрядчиком на старте проекта. Как если бы, начиная проект по выпуску нефтеналивного танкера, в результате на выходе получали бы круизный лайнер. Как ни удивительно, сегодня, когда многие компании ведут цифровую трансформацию своего бизнеса, подобный результат для некоторых из них вполне приемлем и даже желателен. Эксперты McKinsey считают, что ERP-системы не могут оставаться «неприкасаемыми» в ходе цифровой трансформации. А традиционный, зачастую сложный подход к трансформации самой ERP-системы должен быть радикально пересмотрен и, по возможности, адаптирован, с тем чтобы включить в него Agile-подходы. Ведь сегодня три четверти проектов по трансформации ERP не укладываются в график или в рамки бюджета, а две трети демонстрируют отрицательную отдачу от инвестиций.
Хотя многие ИТ-специалисты убеждены, что гибкий подход несовместим с ERP, опыт McKinsey по внедрению гибких практик в самых разных ситуациях говорит об обратном: Agile может быть успешно применен к трансформации ERP-систем, с измеримо лучшими результатами. Данная методология просто должна быть адаптирована к уникальным требованиям подобных сложных решений.
Миф о том, что Agile-методология не может быть применена к внедрению ERP, основан, как полагают в McKinsey, на нескольких ошибочных представлениях. Они состоят в том, что внедрение ERP слишком большое и сложное дело, чтобы управляться и осуществляться небольшими гибкими командами. Еще одно представление базируется на том, что ERP является стандартизированным ПО, и что, следовательно, Agile-подход, который предназначен для постоянно меняющихся или заранее неизвестных требований, не является необходимым или применимым. Говорят также, что ERP-решение невозможно демонстрировать конечным пользователям инкрементно, так как они не смогут по настоящему оценить его качество, прежде чем система будет полностью построена и интегрирована.
На самом деле Agile предполагает более быстрый темп и большую прозрачность работ, что облегчает руководителям принятие своевременных и критически важных решений. Вопреки распространенному мнению, Agile не означает «без планирования» — Agile заменяет длинные, непрозрачные фазы проекта двух-трехнедельными спринтами, позволяющие менеджерам отслеживать результаты, динамику исполнения и возникающие проблемы.
Некоторые Agile-практики могут быть непосредственно применены в ERP-внедрениях без какой-либо адаптации. Однако ряд из них необходимо дополнительно адаптировать. Например, в отличие от принятого в Agile акцента на создание минимально жизнеспособного продукта, весь объем проекта должен быть заранее оговорен на высоком уровне с тем, чтобы сформулировать четкие критерии его успеха. В то же время, следует сохранить возможность для групп уточнять детальный объем проекта и устанавливать приоритеты по мере его развития.
Для обеспечения согласованной разработки необходимо больше, чем в случае обычной Agile-реализации, поработать над бизнес-процессами и архитектурой с тем, чтобы работу можно было распределить между небольшими командами. Необходимы прочные связи между Agile-командами, реализующими отдельные функции, и «сквозными» командами, которые не являются функциональными, например, с командой по миграции данных, командой по интеграции или командой по изменениям, которые осуществляют поддержку функциональных команд. Деятельность всех команд должна быть синхронизирована таким образом, чтобы они работали в одном ритме и вместе преодолевали финишную черту. Версии ПО, «готового к продуктивной эксплуатации», не могут развертываться так же часто, как в случае типичной Agile-разработки. Важно отметить, что в Agile-адаптированном внедрении, если его сравнивать с традиционным подходом waterfall, ускоряются начальные этапы, а большая часть времени тратится на более поздние этапы, сконцентрированные на обеспечении искомой функциональности.
