Быстро внедрить ERP-систему – само по себе неплохо… Можно сократить сроки, сознательно ограничив функциональность первой внедряемой очереди, это нормально. Но не стоит гнаться за скоростью, пренебрегая детальностью проектирования, и не надо экономить на технологичности, увеличивая тем самым риски провала проекта!
Приведем примеры из практики двух наших клиентов, ситуации которых оказались схожи между собой. На предприятиях ранее внедрялось 1C: ERP. Несмотря на то, что в обоих случаях заказчик до нас привлекал не очень опытных консультантов, не имеющих статуса «1С:Центр ERP», тем не менее начинались проекты быстро и руководство было довольно ходом работ. Но затем внедрение зашло в тупик: доработки программы продолжались и продолжались, плановый бюджет проекта давно был превышен, а промышленная эксплуатация никак не начиналась. Представители этих предприятий обратились за советом к экспертам ИТРП.
При анализе ситуации наши специалисты заметили, что проблемы этих двух проектов схожи и явились следствием излишней торопливости консультантов в ущерб технологии, а далее, как снежный ком, начали нарастать бессистемные доработки программы.
Привлеченные консультанты декларировали выполнение проекта в сжатые сроки (основные бизнес-процессы должны были быть автоматизированы примерно за 3 месяца). С одной стороны, такое намерение понравилось заказчику, с другой стороны – ускорение проекта привело к тому, что ряд задач вроде бы выполнен, но поверхностно и формально.
Приведем фрагменты аудиторского анализа от ИТРП по состоянию упомянутых внедрений и покажем, где лежат типовые грабли и как на них не наступать.
Исполнители проекта пытались следовать технологии, например, были предусмотрены документы «Устав проекта», «Журнал рисков», «Журнал запросов на изменения» и пр. Однако содержание этих документов оказалось по большей части шаблонным, их заполняли методом «копи-паст», а затем и вовсе забросили.
Отчет по аудиту проектов «ААА» и «ВВВ», стр.3: В Уставе проекта «ААА» цели определяются как «внедрение 1C:ERP по блокам продажи, закупки, склад, комплектация». Помимо некорректности целеполагания (цель внедрения должна быть внешней по отношению к системе и должна критериально определять улучшения в бизнесе) – следует отметить, что далее контекст Устава относится только к определению работ на начальном этапе функционального моделирования, про стадии реализации настроек и ввода в действие даже не упоминается. Таким образом, речь о достижении каких бы то ни было целей далее в Уставе вообще не идет, приоритеты проекта не специфицированы.
В данном случае, отсутствие ориентиров способствовало тому, что через некоторое время проект сорвался в фрагментарные и необоснованные доработки. Значит ли это, что без правильного Устава проекта результата в итоге не будет? Нет, конечно )) Можно внедрять и вообще без Устава. Однако, когда цели и приоритеты определены документально, то это способствует удержанию проекта в заданных рамках.
Функциональное моделирование выполнялось на скорую руку, крайне поверхностно.
Отчет по аудиту проектов «ААА» и «ВВВ», стр.5: При функциональном моделировании выявлено 9 и 12 функциональных разрывов. Отметим, что на типовых проектах ИТРП при тщательном моделировании в контексте тех же бизнес-процессов выявляется обычно намного больше отклонений от типовых функций. Таким образом, можно предполагать либо очень упрощенные бизнес-процессы, либо (более вероятно) чрезмерно поверхностное моделирование. Значительная часть функций, входящих в бизнес-процесс, при моделировании была пропущена, в том числе: <…>.
По итогам моделирования не сделано никаких выводов, будет ли выполняться доработка для устранения каждого из выявленных разрывов или будет ли изменен бизнес-процесс. Зафиксировано только обобщенное пожелание: по возможности сохранять типовой функционал.
Далее на рассматриваемых проектах было составлено ТЗ по основным функциональным разрывам. ТЗ составлено на достаточно неплохом техническом уровне, замечаний нет. Доработки по первым разделам ТЗ выполнены качественно. Но выполненных доработок оказалось недостаточно, т.к. при попытке начать опытную эксплуатацию стало дополнительно выявляться множество функциональных разрывов, в том числе значительных. И эти разрывы начали затыкать как придется, точнее – по принципу «как можно быстрее». Исполнители проявили излишний пиетет к традициям предприятия по сложившимся бизнес-процессам и по имеющимся формам бумажных документов, начали реализовывать в системе все пожелания всех пользователей в порядке их поступления, без какого-либо анализа этих запросов.
Эти пожелания оформлялись так называемыми «Частными Техническими Заданиями» (ЧТЗ) и сразу передавались программистам на реализацию без какого-либо анализа.
Множество внезапно выявленных потребностей потребовали пересмотра и переделывания уже ранее выполненных доработок.
Например, сначала в программе реализовали функцию «А» в подсистеме управления запасами. Затем вдруг выяснилось, что с учетом специфики управления потоками потребностей надо еще сделать «Б», а для этого придется полностью переделывать «А». А после этого пользователи потребовали запрограммировать функцию «В», причем реализовав «В» оказалось, что «А» и «Б» уже будут вообще не нужны. И так далее…
Причина – поспешное ФМ с непроработанными БП. При нормальном ФМ должны были быть выявлены все основные функциональные разрывы, а это позволило бы спроектировать необходимые доработки с учетом взаимосвязей между ними, т.е. комплексно и системно.
Кроме того, экспертный анализ показал, что по нескольким ЧТЗ целесообразность их реализации вообще крайне сомнительна, т.к. не способствует значимым улучшениям в бизнес-процессах.
Если пользователь захотел некую функцию, то еще не факт, что надо сразу бросаться эту функцию реализовывать. Например, незначительное улучшение юзабилити для единственного пользователя ценой значительных трудозатрат (с сопутствующим расходом бюджета) – вполне может быть отклонено.
Другой источник проблемных доработок: пользователи потребовали «сделать в программе так, как привыкли работать раньше».
Например, для поступления от поставщика необходимых производству материалов к необходимому сроку – в существующем бизнес-процессе производство передает заявки в ОМТС, затем начальник снабжения перегруппировывает заявки по критериям длительности поставки в отдельные документы – задания менеджерам, затем менеджеры запрашивают счета у поставщиков и контролируют по каждому счету объем и срок фактического исполнения поставки. Всю эту модель работы описали в ЧТЗ и начали дорабатывать под нее 1C:ERP. Причем программистам пришлось затронуть типовые объекты, а это сильно затрудняет обновление системы!
Однако при качественном функциональном моделировании следовало обратить внимание заказчика, что в 1C:ERP предлагается более удобная и более эффективная модель обеспечения потребностей материалами, в которой заказы поставщику формируются без промежуточных и без избыточных документов, учитывать в программе счета поставщиков вообще не требуется (для контроля достаточно предоставляемых системой типовых отчетов).
Таким образом, попытка ускорить внедрение за счет «пробегания» стадии функционального моделирования и формального ее выполнения чрезмерно увеличивает риск того, что в итоге проект наоборот затянется на неопределенный срок.
Сокращение состава работ на стадиях ТЗ, программирования, ввода в действие, и даже небольшие недочеты на этих стадиях – не столь критичны, как недоработки на стадии функционального моделирования. Стадия моделирования объективно является, пожалуй, самой важной из всех составляющих проекта! Поэтому рекомендуем уделить этой стадии особое внимание и выполнить функциональное моделирование с максимальной тщательностью, с детальной проработкой всех автоматизируемых функций.
Успехов на ваших проектах!
Автор: Лисин Н.Г, Вепринцев А.Н.