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

Предприятие понимает, что текущие процессы устарели и нужны изменения. Однако при попытке рассчитать стоимость внедрения получается неподъемная сумма. Защитить такой бюджет невозможно, а «костыли» уже не спасают ситуацию.

Внедрение стартовало, но на этапе моделирования застопорилось. Команды тянут одеяло на себя, формируя противоречивые требования. Бюджет раздувается, сроки переносятся, руководство теряет доверие к ИТ-службе, интегратор и заказчик вязнут в согласованиях.

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

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

Собираем единую рабочую группу по всем департаментам: руководитель и ключевой пользователь (обычно, самый инициативный сотрудник). Рисуем основной сквозной процесс организации как трубопровод (например, от заказа, до получения денег). Каждый участок трубы – это отдельный департамент (например, продажи, закупки, склад, производство, наладка и т.д.). Обычно, таких шагов процесса не более 10 (это бизнес-процессы 1го уровня). Такой рисунок показывает ради чего существует организация, визуализирует и фиксирует первую договоренность.

В компании может быть несколько бизнес-образующих сквозных потоков, обычно, их не более трёх. Например:

·        продажа покупной продукции через собственную торговую сеть;

·        выпуск и продажа собственной продукции;

·        оказание услуг.

Если собрать рабочую группу не удаётся или процесс не укладывается в 10 шагов — это сигнал о серьёзных управленческих проблемах. Но решаемых.

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

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

Например, для предприятия, производящего сложные изделия под заказ клиента, основными показателями могут быть:

1. Среднее выполнение заказа основной группы в днях (Скорость).
2. Удовлетворённость клиента (Качество).
3. Маржинальность в процентах (Стоимость).

Отдельно по каждому шагу (бизнес-процессу 1го уровня) проводим встречи с владельцами и ключевыми пользователями этого участка. Каждый шаг демонстрируется «от и до» в тестовой системе. Нужно показать как всё работает в реальности, а не «как должно быть». Выявляются «теневые шаги» — когда данные берутся из личных Excel-файлов, писем, звонков, а не из системы. Все шаги (включая теневые) заносятся в таблицу (так формируется список реальных бизнес-процессов 2го уровня).

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

Выстраиваем логику «внутренний заказчик — внутренний поставщик»: каждый процесс-клиент выдвигает требования к процессу-поставщику.

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

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

На этом этапе мы исключаем из обсуждения эмоции и субъективные оценки. Любой конфликт интересов — например, когда продажам нужна гибкость, а финансам жесткий контроль — фильтруется через призму метрик из Шага 2. Вместо бесконечных споров о том, чей процесс важнее, команда получает объективный арбитраж на основе триады «Скорость — Качество — Стоимость».

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

Всё, что нашли на шагах 1–4, превращается в управленческий документ. Проблемы делим на три блока:

·        быстрые победы (организационные изменения);

·        доработка текущей системы,

·        требования к новой ERP.

Каждое требование оцениваем по матрице «влияние на метрики × стоимость реализации». Формируем план быстрых побед со сроками и ответственными. Считаем экономический эффект.

Далеко не всегда решением становится автоматизация или внедрение новой ERP-системы — иногда достаточно организационных изменений и точечных доработок текущей системы. Но если автоматизация нужна — теперь вы точно знаете зачем, сколько и что получите взамен.

Главная ценность процессного подхода — не в системе, а в том, что команда учится договариваться. Когда требования к ИТ-ландшафту оцениваются через общую метрику, исчезают конфликты, поиск виноватых и бесконечные согласования. Сначала порядок в сквозном процессе, потом — автоматизация. В обратной последовательности вы рискуете получить дорогую систему, в которой никто не работает.

Если узнали себя в одном из сценариев — не ждите, пока проблема станет критической. Обсудить применимость методики к вашей компании можно в рамках первичной консультации — разберём ситуацию и определим, где лежат ваши «быстрые победы».