Внедрение 1С:ERP: ошибки, которые приводят к перевнедрению

Перевнедрение 1С:ERP - всегда дорого. Но проект редко проваливается в день запуска. Проблемы закладываются раньше: в целях проекта, выбранной стратегии внедрения, данных и подходе к управлению. Почему жесткий договор не гарантирует целевой результат проекта и как избежать необходимости перевнедрения — в статье Юлии Кравченко, руководителя проектов внедрения 1С компании «ФТО».

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

Проект внедрения ERP редко проваливается в день запуска. Большинство проблем можно предотвратить заранее.

В статье я расскажу о пяти основных ошибках, которые приводят к провалу проектов внедрения.

Ошибка №1. Нет утвержденных целей проекта и критериев успеха

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

Пример: В одном из проектов цель звучала как «внедрить 1С:ERP до конца года». Систему запустили в срок, но на этапе опытной эксплуатации выяснилось, что ключевой заказчик (финансовый директор) ждал от проекта сокращения срока закрытия месяца, а производство - снижения объёма ручных операций по учёту НЗП. Ни того, ни другого в измеримых показателях не зафиксировали. Формально проект был сдан, но уже через полгода начался проект «довнедрения»: пересматривали функциональные границы, меняли отчётность, переобучали пользователей.

Ошибка №2. Неверно определена стратегия внедрения

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

Пример: В группе компаний из 15 юр. лиц за один запуск перевели на 1С:ERP все виды учета, закупки, складскую логистику и расчёт себестоимости. Через месяц после старта «поплыли» три критичных контура: закрытие периода, отгрузка со склада и взаиморасчёты с контрагентами. Разбирались в причинах в режиме пожара. В итоге часть блоков временно вернули в исторические системы, а проект перешёл в фазу «довнедрения» с пересмотром архитектуры.

Ошибка №3. Новая система автоматизирует старые процессы или «воздушные замки»

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

Обязательные вопросы к требованиям на этапе проектирования целевых процессов:

• Какую бизнес-цель поддерживает требование?

• Реализовано ли требование в реальных бизнес-процессах (есть ли нужные данные, ответственные и процедуры)?

• Является ли оно особенностью процесса или следствием ограничения функционала исторической системы?

• Можно ли изменить процесс, а не дорабатывать систему?

• Что произойдет, если вынести доработку в более поздние очереди внедрения?

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

Пример: В одном проекте бизнес настаивал на доработке: возможность менять цену в заказе клиента после его подтверждения. Причина: «Клиенты часто просят пересмотреть цену после согласования, а мы не хотим терять продажи». Требование выглядело обоснованным. Позже выяснилось, что в старой системе не было механизма согласования скидок до подтверждения заказа. В 1С:ERP механизм согласования скидки до подтверждения заказа реализован штатно. Доработка не давала гибкости, а компенсировала отсутствие процесса согласования. Её согласовали, потому что смотрели на неё как на «инструмент для менеджеров», а не как на следствие разорванного процесса. В итоге менеджеры продолжали продавать по одной цене, а оформлять по другой, что создавало ошибки во взаиморасчётах и претензии от клиентов. На этапе перевнедрения доработку убрали, а процесс перестроили.

Ошибка №4. Данные не рассматриваются как основа будущего учета

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

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

НСИ – это базис учёта, планирования, расчётов и управленческой аналитики.

Пример: В одном холдинге миграцию НСИ отложили на финальную фазу проекта. После запуска в системе оказалось по несколько версий одного и того же контрагента, по несколько складов с одинаковым названием и множество дублей номенклатуры. Управленческая отчётность перестала сходиться. Финансовый директор на первом же совещании сказал: «Я не верю этой системе». Дальше - ручные сверки и корректировки, Excel, потеря времени и денег.

Рекомендуем включать в объем проекта на начальных этапах:

• определение эталонных объектов и правил работы с ними,

• моделирование, тестирование и обучение пользователей на реальных НСИ.

Ошибка №5. Не выстроено совместное управление проектом

1С:ERP невозможно качественно внедрить в подходе «подрядчик всё сделает сам, а бизнес подключится на обучении». Для проекта нужен совместный контур управления. В него обычно входят спонсор проекта, руководители проекта со стороны заказчика и интегратора, владелец продукта со стороны заказчика, владельцы бизнес-процессов, ИТ-команда заказчика и ключевые пользователи.

Если заказчик включается эпизодически - согласования начинают подвисать, требования меняются ситуативно, объем разрастается и бюджет заканчивается до внедрения.

Начинать проект имеет смысл только когда:

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

• на стороне заказчика сформирована проектная команда и ее участникам выделено время на проектные задачи,

• утверждена процедура управления изменениями, нет возможности обойти ее требования,

• утверждена отчетность, которая позволяет видеть риски возникновения отклонений по основным параметрам (объем, сроки, бюджет) и причины их возникновения.

Перевнедрение – это всегда дорого. Успех проекта обеспечивается не жестким договором, а совместной работой заказчика и подрядчика на всём протяжении проекта. Своевременные договоренности о бизнес-целях и критериях успеха, выбор управляемой стратегии запуска, совместное управление изменениями и рисками - гарантия качества внедрения 1С:ERP.

Автор: Юлия Кравченко – руководитель проектов внедрения 1С для заказчиков enterprise сегмента. Компания «ФТО». В профессии 15+ лет.