Основная ошибка на старте — воспринимать переход на новую систему как технический перенос существующей функциональности.

На самом деле переход с УПП — это глубокий рефакторинг как ИТ-архитектуры, так и бизнес-процессов. За годы эксплуатации старая система обрастает лоскутными доработками, ручными операциями и негласными договоренностями. Попытка перенести все это в новую систему «один в один» приводит к тому, что типовые механизмы новой ERP ломаются, а стоимость владения и поддержки системы вырастает в разы.

Успех проекта зависит от того, удастся ли на старте синхронизировать цели разных подразделений:

• ИТ-служба стремится к производительности, безопасности и современным технологиям (иногда уходя в «антицели» — например, внедрение сложных технологических решений там, где они не нужны).
• Бизнес и собственники хотят видеть финансовые результаты, прозрачность и гибкость для масштабирования. Управленческий учет требует максимальной аналитики и высокой скорости изменений.
• Регламентированный учет (бухгалтерия) консервативен, требует стабильности, соответствия законодательству и минимума изменений в коде, чтобы легко обновлять систему.

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

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

• Критичные (войдут в MVP — минимально жизнеспособный продукт): процессы, без которых бизнес остановится (например, отгрузки, сложные импортно-экспортные схемы).
• Средней критичности: процессы, которые временно (на 2–3 месяца) можно перевести на «ручной привод» и автоматизировать во вторую очередь.
• Некритичные: операции, которыми пользуются единицы и которые приносят минимум выгоды. Их стоит исключить из проекта.

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

Проанализировать метаданные: собрать статистику использования документов. Если в УПП есть уникальный самописный документ, но за год его создали всего три раза — переносить его в новую ERP не имеет смысла.

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

При переходе с монолитной УПП на современный ландшафт (ERP, ЗУП, WMS, CRM и др.) возникает риск столкнуться с проблемой «Квартета» из басни Крылова — когда систем и подрядчиков много, но слаженной работы между ними нет.

Риск раздробления бизнес-процессов: если делить функции между разными блоками системы, границы процессов могут размываться.

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

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

Современные ERP-системы гибкие и позволяют реализовать один и тот же процесс разными способами.

На этапе функционального моделирования (который обязательно нужно проводить до написания ТЗ и разработки) процессы компании «примеряются» на типовую функциональность новой системы.

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

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

Перенос данных — один из самых недооцененных этапов. Попытка перенести все накопленные за 10–15 лет данные из УПП «как есть» гарантированно саботирует запуск новой системы.

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

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

Архив как решение: историческую базу УПП переводят в режим «только для чтения» для сдачи старой отчетности и сверки данных за прошлые периоды.