Диагностика процессов перед внедрением ERP

Обезличенный практический кейс диагностики процессов перед внедрением ERP: исходная ситуация, анализ, находки и проектирование целевого контура.

Отрасль

Торгово-производственная компания.

Тип проекта

Предпроектная диагностика перед выбором и внедрением ERP.

Исходная ситуация

Компания выросла из небольшого бизнеса.

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

Руководство рассматривало внедрение ERP как способ создать единое информационное пространство.

Проблема

Требования к системе формировались как перечень желаемых функций:

продажи;

закупки;

склад;

производство;

финансы;

отчётность.

Однако не было согласованного ответа на вопросы:

где начинается и заканчивается каждый процесс;

кто отвечает за переход объекта между состояниями;

какой источник данных является основным;

как обрабатываются исключения;

какие действия действительно необходимы;

какие операции появились из-за недостатков текущей системы.

При прямом переносе существующей работы в ERP новая система закрепила бы старые проблемы.

Ограничения

отсутствие полной документации;

разные представления подразделений;

ограниченный бюджет;

необходимость продолжать текущую работу;

зависимость от нескольких ключевых сотрудников;

отсутствие достоверной статистики по времени операций.

Как проводился анализ

1. Определение сквозных объектов

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

2. Моделирование состояний

Для каждого объекта определялись состояния и переходы.

3. Интервью по конкретным ситуациям

Участников просили описывать не «как работает процесс вообще», а последние реальные случаи: обычный, срочный, ошибочный, отменённый и неполный.

4. Сопоставление данных

Проверялись расхождения между системой, таблицами и фактическими остатками.

5. Выявление ручных обходов

Фиксировались повторный ввод, ручные реестры, неформальные согласования, дублирование документов и зависимость от личной памяти.

Что было обнаружено

Отсутствовал единый статус заказа

Продажи, склад и производство использовали разные признаки готовности.

Планирование опиралось на неполные данные

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

Закупка реагировала на дефицит

Потребность формировалась после появления проблемы, а не из согласованного плана.

Таблицы выполняли роль интеграции

Они связывали подразделения, но не обеспечивали контроль версий и ответственности.

Контроль дублировал последствия

Дополнительные проверки были введены вместо устранения причин ошибок.

Какое решение спроектировали

Была сформирована целевая модель:

единые состояния заказа;

сквозной идентификатор;

правила переходов;

ответственность за каждый переход;

источник истины для критичных данных;

разделение планового, доступного и подтверждённого количества;

обработка исключений;

управленческие события;

требования к интеграциям;

приоритеты этапов.

Проект ERP был разделён на этапы.

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

Результат

Результатом диагностики стали:

границы проекта;

карта фактических процессов;

модель объектов и состояний;

перечень источников данных;

список критичных разрывов;

требования к первому этапу;

перечень процессов, которые необходимо изменить до автоматизации.

Полученные уроки

ERP не создаёт процесс, если организация не определила его правила.

Перечень функций не заменяет архитектуру.

Таблицы и мессенджеры необходимо рассматривать как часть фактической системы.

Исключения должны проектироваться вместе с основным маршрутом.

Первый этап должен создавать единый управляемый контур, а не максимальное количество модулей.

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

названия организаций;

внутренние документы;

финансовые показатели;

персональные данные;

конкретные параметры инфраструктуры.

Вывод

Диагностика перед ERP снижает риск автоматизации несогласованных процессов.

Её задача — определить не только необходимые функции, но и архитектуру работы предприятия.