Переход от пилота ERP к промышленному внедрению: критические ошибки и решения

Ключевой конфликт: скорость против устойчивости

Цель: зафиксировать ограничения системы и не дать срокам их сломать.

Что происходит: пилот показывает ценность → бизнес требует масштабирования → архитектура не готова → решения принимаются в пользу скорости.

Артефакты:

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

Критерий успеха: ограничения зафиксированы и защищены.

Ключевая ошибка: «сейчас быстро, потом исправим» — это момент появления техдолга.

Как принять решение: можно ли масштабировать

Цель: не запускать систему, которая не выдержит рост.

Что делать: чётко разделить, что проверил пилот, а что осталось гипотезой. Проверить не только «работает ли», но и «ломается ли» при росте данных, пользователей и интеграций.

Артефакты:

• отчёт по пилоту (факты, не презентация);
• список непроверенных сценариев;
• решение Go / No-Go.

Критерий успеха: решение принято осознанно, а не «вроде работает».

Риск: пилот проверил только «happy path», а масштаб ломается на краях.

Какие артефакты должны остаться после пилота ERP

Цель: сохранить знания и не повторять ошибки при масштабировании.

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

Артефакты:

• архитектура AS-IS и TO-BE;
• карта интеграций;
• список узких мест (performance, данные, процессы);
• SLA критичных операций;
• решения по мастер-данным;
• регламент обработки ошибок.

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

Ключевая ошибка: пилот остаётся в головах команды — масштабирование становится лотереей.

Что переносится из пилота, а что выбрасывается

Цель: не тянуть прототипные решения в прод.

Переносится:

• подтверждённые архитектурные решения;
• модель данных;
• устойчивая бизнес-логика.

Выбрасывается:

• временные интеграции;
• ручные процессы;
• обходные решения («костыли»).

Критерий успеха: в прод идёт переосмысленная система, а не пилот.

Риск: «оставим как есть» → техдолг становится частью архитектуры.

Где появляется технический долг

Цель: выявить точки будущей деградации системы.

На практике техдолг возникает:

• в интеграциях без очередей и ретраев;
• в дублировании данных;
• в ручных обходах процессов;
• в «временных» решениях без срока удаления.

Артефакты: реестр техдолга и план устранения.

Критерий успеха: техдолг управляется, а не скрыт.

Ключевая ошибка: недооценка техдолга — он масштабируется быстрее системы.

Что делает архитектор ERP на практике

Архитектор в этот момент не «рисует схемы», а принимает решения:

• останавливает масштабирование при рисках;
• фиксирует запреты на обход архитектуры;
• разделяет пилот и промышленную систему;
• навязывает дисциплину работы с данными.

Если этого нет — система ломается при первом росте.

Как диагностировать готовность к масштабированию

• понятно ли, что пилот НЕ проверил;
• есть ли SLA критичных операций;
• известны ли узкие места;
• зафиксированы ли архитектурные ограничения.

Если хотя бы один ответ «нет» — масштабирование преждевременно.

Альтернативный взгляд

Иногда можно идти быстрее: при низкой цене ошибки и локальном внедрении.

Trade-off: быстрее → больше техдолга; медленнее → выше устойчивость.