С какого модуля начинать внедрение ERP?
Внедрение ERP следует начинать с одного модуля, где есть измеримая потеря и доступные данные: просрочки производства, ручной перенос заказов, расхождение остатков, непрозрачный план-факт или отчётность в таблицах. Первый контур должен быть законченным маршрутом с событием старта, ролями, состояниями, результатом и критериями приёмки.
Надёжнее выбрать один рабочий контур с понятным началом и результатом. Например: заказ принят, обеспечен материалами, прошёл производство и получил рассчитанную фактическую себестоимость. У контура есть участники, входные данные, статусы, документы, интеграции и критерии приёмки.
Как оценить кандидатов на первый запуск
| Критерий | Хороший кандидат | Риск для первого запуска |
|---|---|---|
| Бизнес-потеря | Регулярная ручная работа, задержка или несверяемый результат | Проблема формулируется только как «нужна современная система» |
| Граница процесса | Понятны вход, результат и ответственные роли | Контур зависит от перестройки всей компании |
| Данные | Источники известны, качество можно проверить | Критичные справочники не имеют владельца |
| Приёмка | Есть 5–10 сквозных сценариев и контрольные примеры | Результат оценивается только субъективно |
| Пилот | Можно начать с отдела, площадки или типа заказов | Нужен одновременный переход всех пользователей |
Что зафиксировать до разработки
- Границу. Какое событие запускает процесс и какой проверяемый результат его завершает.
- Роли. Кто создаёт, согласует, исполняет, контролирует и исправляет ошибку.
- Состояния. Какие статусы допустимы, кто их меняет и какие переходы запрещены.
- Данные. Где живут справочники, документы и показатели; кто отвечает за качество.
- Интеграции. Что приходит из 1С, CRM, банка или оборудования и что возвращается обратно.
- Приёмку. Сквозные сценарии, контрольные записи и допустимые исключения.
Это не означает подробное техническое задание на всю ERP. Документ должен быть достаточным, чтобы команда одинаково понимала первый рабочий результат и могла проверить его на данных.
Платформенное ядро и заказная логика
Пользователи, роли, справочники, документы, уведомления, журнал изменений и API не обязательно создавать заново. Их можно взять из платформенного ядра. Заказной остаётся та часть, которая отражает реальные отличия процесса: расчёты, маршруты, правила согласования, формы и интеграции.
Такой подход не отменяет проектирование, но позволяет направить разработку на бизнес-логику, а не на повторное создание базовой инфраструктуры.
Как встроить новый контур в существующий ИТ-ландшафт
До запуска составляют матрицу систем. Для каждого объекта — клиента, товара, заказа, платежа или операции — указывают, где он создаётся, где редактируется, куда передаётся и как сверяется. Двусторонний обмен не назначают по умолчанию: одно поле должно иметь понятного владельца.
Подробные правила идентификаторов, повторов и ошибок разобраны в руководстве по интеграции 1С и CRM без дублей.
Критерии приёмки первого контура
- каждая роль видит только доступные ей данные и действия;
- сквозные сценарии проходят от входного события до результата;
- справочники и документы однозначно сопоставляются с исходными системами;
- повтор операции не создаёт дубли;
- ошибка видна ответственному и может быть обработана;
- контрольный отчёт сходится с первичными данными;
- критичный сценарий не требует параллельной обходной таблицы.
После приёмки фиксируют исходную и новую метрику: длительность цикла, число ручных переносов, незавершённые операции, ошибки или время подготовки отчёта. Следующий контур выбирают уже на основе фактического использования.
Последовательность запуска
- Собрать проблемные участки и оценить кандидатов по частоте, потере, данным и проверяемому результату.
- Выбрать пилотную группу и ограничить границу первого контура.
- Описать роли, состояния, данные, интеграции и сценарии приёмки.
- Собрать рабочую версию на платформенном ядре и тестовых данных.
- Провести сквозную сверку и исправить ошибки процесса, а не только интерфейса.
- Запустить пилот, измерить результат и принять решение о следующем модуле.
Связанные решения: ERP под заказ, управление производством, управленческий учёт и BI-дашборды.
Частые вопросы
Чем ERP под заказ отличается от коробочной ERP?
Коробочная ERP предлагает заранее заданную модель и набор модулей. Заказная система строится вокруг конкретного процесса и может использовать готовое платформенное ядро, но роли, документы, статусы, правила и интеграции настраиваются под компанию.
Нужно ли описывать все процессы до начала разработки?
Для первого запуска достаточно подробно описать выбранный контур и его связи с соседними системами. Остальные процессы фиксируют на уровне границ, чтобы первый модуль не мешал последующему расширению.
Как выбрать первый контур ERP?
Подходит процесс с заметной потерей, доступными данными, ограниченным числом участников и проверяемым результатом. Например, карточка производственного заказа, согласование закупки или управленческая сводка.
Как принять первый контур, если требования будут меняться?
До разработки согласуют несколько сквозных бизнес-сценариев и контрольные данные. Контур принимается, когда роли проходят эти сценарии, результаты сверяются с источниками, ошибки видны ответственным, а критические операции не требуют обходных таблиц.
Что делать с 1С и другими уже работающими системами?
Необязательно заменять их сразу. Для каждой сущности определяют владельца данных и направление обмена. Первый контур может использовать 1С как источник справочников и документов, а новую ERP — как рабочее место процесса.
Выберем первый рабочий контур ERP
Разберём процессы и системы, оценим кандидатов и зафиксируем сценарии, по которым можно принять первую версию.