Развитие ERP-системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Взгляд со стороны: три ключевых проблемы

Проблемы, которые могут привести к описанному выше развитию событий, следующие:

1. Функциональные требования формулируют пользователи

2. Функциональные требования к модификации подменяются описанием модификации

3. Руководство заказчика отказывается от скрупулезной оценки экономического эффекта от каждой модификации.

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

Каковы причины и последствия перечисленных проблем?

Ошибка первая, она же основная: требования формулируются пользователем

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

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

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

Обоснование ошибочности данного решения можно сформулировать следующим образом.

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

Возникающую в результате такого подхода избыточность требований к модификации можно продемонстрировать следующим образом. Предположим, что при описании вариативности реализаций некоторого автоматизируемого бизнес-процесса работает упрощенное правило Парето 20/80 ¹  (используем правило Парето просто как пример закономерности, которую принято применять для описания практически любых несложных экономических закономерностей). В этом случае 20% вариантов реализации (частных случаев) бизнес-процесса составляют 80% всех случаев реализации. 36% вариантов реализации - 96% всех случаев. 49% вариантов реализации - 99% всех случаев.

Представленные цифры наталкивают на мысль, что с точки зрения того, кто платит за модификацию, при определенных условиях может иметь смысл ограничиться автоматизацией, допустим, 36% вариантов реализации. Таким образом, 96% всех реализаций система будет обрабатывать автоматически, оставшиеся же 4% реализации может быть целесообразным оставить для полуавтоматической обработки (по каждому из них пользователь должен будет принимать индивидуальное решение).

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

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

Ошибка вторая, отягчающая: согласовываем "как" вместо "зачем"

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

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

Исключения

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

Описанные проблемы не относятся к "пользователям-исключениям".

Если две ошибки допущены: как искать выход

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

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

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

Если эта работа добросовестно выполнена исполнителем, у заказчика есть возможность разобраться в происхождении несоразмерных сумм, отсечь лишнее, правильно расставить акценты.

Ошибка третья, контрольная: заказчик платит не глядя

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

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

Если заказчик отказался от оценки экономической целесообразности модификаций, остается надеяться только на то, что наш пользователь - счастливое исключение. Такое тоже бывает, но рассчитывать на везение как на системный способ решения проблем все же не стоит.

Все ошибки допущены. Что делать

В заключение хотелось бы описать рекомендации, отвечающие на вопрос "Что делать?", для участников тех проектов, которые уже увязли в подобных проблемах. Поскольку последовательное описание рекомендаций потребовало бы значительного объема, ограничимся краткими тезисами.

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

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

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

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

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

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

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

При анализе текущего процесса мы выясняем следующее: согласно действующим правилам примерно 80% счетов на оплату должны комплектоваться после того, как поступает 100% предоплата по этим счетам. В 16% случаев - достаточно оплаты 70% (VIP-клиенты). В 3% случаев счета уходят на комплектацию после получения гарантийного письма (клиенты с безупречной репутацией).

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

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