ERP системы. Развитие и внедрение

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

Специфика восприятия

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

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

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

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

Отдача на инвестиции

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

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

Особенности проектирования

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

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

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

Взгляд участника: как рушатся отношения. Краткая хронология

Реальные причины разрушения отношений не всегда очевидны для участников проекта. Для них картина нарастающего недоверия и неэффективности взаимодействия может выглядеть примерно следующим образом.

Руководство заказчика предлагает пользователям поучаствовать в автоматизации своих процессов: проработать совместно с консультантами свои требования к системе.

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

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

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

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

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

При этом, чаще всего, и после смены подрядчика повторяется та же картина: материальные потери и нереализованные модификации, тормозящие развитие бизнеса.

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