Как провести обследование процессов перед ERP, выявить скрытые потери, определить границы проекта и подготовить требования без автоматизации хаоса.
Обезличенный практический кейс диагностики процессов перед внедрением ERP: исходная ситуация, анализ, находки и проектирование целевого контура.
Торгово-производственная компания.
Предпроектная диагностика перед выбором и внедрением ERP.
Компания выросла из небольшого бизнеса.
Учёт и управление распределились между бухгалтерской системой, таблицами, почтой, мессенджерами, бумажными документами и устными договорённостями.
Руководство рассматривало внедрение ERP как способ создать единое информационное пространство.
Требования к системе формировались как перечень желаемых функций:
продажи;
закупки;
склад;
производство;
финансы;
отчётность.
Однако не было согласованного ответа на вопросы:
где начинается и заканчивается каждый процесс;
кто отвечает за переход объекта между состояниями;
какой источник данных является основным;
как обрабатываются исключения;
какие действия действительно необходимы;
какие операции появились из-за недостатков текущей системы.
При прямом переносе существующей работы в ERP новая система закрепила бы старые проблемы.
отсутствие полной документации;
разные представления подразделений;
ограниченный бюджет;
необходимость продолжать текущую работу;
зависимость от нескольких ключевых сотрудников;
отсутствие достоверной статистики по времени операций.
Были выделены клиентский заказ, потребность, закупочный заказ, материал, производственное задание, партия, отгрузка и платёж.
Для каждого объекта определялись состояния и переходы.
Участников просили описывать не «как работает процесс вообще», а последние реальные случаи: обычный, срочный, ошибочный, отменённый и неполный.
Проверялись расхождения между системой, таблицами и фактическими остатками.
Фиксировались повторный ввод, ручные реестры, неформальные согласования, дублирование документов и зависимость от личной памяти.
Продажи, склад и производство использовали разные признаки готовности.
Производство получало изменения позже, чем принимались обязательства перед клиентом.
Потребность формировалась после появления проблемы, а не из согласованного плана.
Они связывали подразделения, но не обеспечивали контроль версий и ответственности.
Дополнительные проверки были введены вместо устранения причин ошибок.
Была сформирована целевая модель:
единые состояния заказа;
сквозной идентификатор;
правила переходов;
ответственность за каждый переход;
источник истины для критичных данных;
разделение планового, доступного и подтверждённого количества;
обработка исключений;
управленческие события;
требования к интеграциям;
приоритеты этапов.
Проект ERP был разделён на этапы.
Первый этап включал только контуры, необходимые для единого заказа и достоверного состояния.
Результатом диагностики стали:
границы проекта;
карта фактических процессов;
модель объектов и состояний;
перечень источников данных;
список критичных разрывов;
требования к первому этапу;
перечень процессов, которые необходимо изменить до автоматизации.
ERP не создаёт процесс, если организация не определила его правила.
Перечень функций не заменяет архитектуру.
Таблицы и мессенджеры необходимо рассматривать как часть фактической системы.
Исключения должны проектироваться вместе с основным маршрутом.
Первый этап должен создавать единый управляемый контур, а не максимальное количество модулей.
названия организаций;
внутренние документы;
финансовые показатели;
персональные данные;
конкретные параметры инфраструктуры.
Диагностика перед ERP снижает риск автоматизации несогласованных процессов.
Её задача — определить не только необходимые функции, но и архитектуру работы предприятия.