Разрыв между ERP и реальным процессом: почему BI показывает не то

ERP показывает процесс таким, каким он зарегистрирован в системе: документ создан, статус изменён, операция проведена. Реальная работа сложнее. Между этими событиями возникают ожидания, ручные согласования, обходные действия и исключения, которые могут не оставлять полноценного цифрового следа.

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

Дело не в том, что BI «врёт». Чаще он честно повторяет то, что видит в источнике. ERP фиксирует норматив — то, как процесс должен идти и как его принято отражать в системе. Реальный процесс почти всегда сложнее: с исключениями, обходами и ручными решениями, которые остаются вне ERP. Если BI строится поверх ERP без сопоставления с фактическим маршрутом, он становится зеркалом системы, а не отражением операционной реальности.

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

Почему фактический процесс расходится с нормативным маршрутом ERP

ERP задаёт эталон: какие шаги должны быть, в каком порядке и какие статусы допускаются. Но реальная работа почти всегда идёт сложнее. Клиент просит отгрузить заказ частями, поставщик переносит срок, коммерция меняет цену после подтверждения заказа, производство перестраивает очередь под срочный контракт, логистика отправляет через другой склад, финансы задерживают закрывающие документы.

В системе такие исключения часто не отражаются как отдельные события. Их прячут внутри одного статуса, закрывают ручной правкой или согласовывают в мессенджере. Иногда исключение всё же фиксируется, но так, что его невозможно выделить аналитически: в комментарии, приложенном файле или переписке.

В итоге в отчёте получается идеальная цепочка. Когда BI строит показатели по статусам ERP, он наследует этот нормативный маршрут. Попытка найти, где именно теряется время, упирается в ответ: «в системе задержки нет». В реальности она есть, но находится между статусами — в ожидании решения, ручном согласовании или параллельной ветке, которую ERP не фиксирует.

Событие в ERP не равно шагу процесса

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

Между «заказ создан» и «заказ подтверждён» могут быть кредитный контроль, сверка лимитов, проверка реквизитов или переподписание договора. Между «отгрузка оформлена» и «доставлено» — ожидание окна доставки, отказ клиента, возврат на склад или доукомплектация.

С точки зрения процесса это разные ветви с разными причинами и последствиями. С точки зрения ERP они могут выглядеть одинаково: один статус, одна дата, одна сумма. BI формально посчитает время прохождения процесса (lead time) и конверсию по документам, но управленческая логика останется за кадром. Так появляются отчёты, которые хорошо объясняют прошлое, но мало помогают принять решение в понедельник утром.

Если коротко: ERP ведёт учёт, а процесс требует следов поведения. Пока команда не договорилась, что считать событием процесса и где оно должно фиксироваться, BI будет считать «то, что есть», а не «то, что нужно».

Почему BI не видит потери на стыках между функциями

Заметная часть потерь возникает не внутри одного отдела, а на стыках: между коммерцией и производством, производством и складом, складом и доставкой, отгрузкой и оплатой. В ERP у каждого блока своя картина мира и свой набор статусов. BI может собрать эти статусы в один отчёт, но это ещё не значит, что он восстановит единый маршрут процесса.

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

Если эта цепочка не восстановлена, BI превращается в витрину параллельных показателей, а не в инструмент управления сквозным процессом. Парадокс в том, что отчётов может быть много, и все они будут правильными. Просто каждый отвечает на свой вопрос. На совещании это быстро превращается в спор отчётов вместо поиска причины.

Исключения превращаются в «грязные данные» и уходят в тень

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

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

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

Почему сквозному KPI нужен владелец

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

Тогда и разрыв между ERP и реальным процессом остаётся без хозяина. Продажи объясняют свою часть через воронку, склад — через отгрузки, финансы — через дебиторскую задолженность. Сквозной KPI красный, но никто не отвечает за то, чтобы разобраться, что именно стоит за отклонением: исключения, возвраты, пересогласования, отсутствие системных следов или разные определения одного и того же показателя.

Назначить владельца метрики не значит повесить на одного человека ответственность за весь процесс. Его задача — закрепить определение KPI, источники данных, основные сценарии, пороги и порядок действий при отклонении. Без этого даже корректный сквозной показатель рискует остаться просто отчётностью.

Как сделать пять разрывов между ERP и реальным процессом видимыми

В реальной работе проблема обычно складывается из пяти разрывов, которые усиливают друг друга: нормативный маршрут в ERP отличается от фактического, события в системе не совпадают с реальными шагами процесса, BI не видит потери на стыках, исключения списываются на качество данных, а сквозной KPI остаётся без владельца.

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

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

Когда такой разрыв найден, у команды появляется выбор. Можно добавить системный след — новый статус, обязательное поле, отдельный документ или интеграцию с сервисом согласования. Можно формализовать исключение как отдельный сценарий и считать его отдельно: например, заказы с изменением цены после подтверждения, отгрузки с частичной комплектацией или платежи с переносом срока. Можно оставить процесс как есть, но тогда важно честно признать, что этот участок не измеряется автоматически и в сквозном KPI остаётся ручной слой с понятным владельцем.

В этой логике задача BI не в том, чтобы «сделать красиво», а в том, чтобы сделать процесс видимым. После того как фактический маршрут и его события определены, один экран уже может показать этапы, долю исключений, время ожидания решений и потери на стыках. Тогда вопрос «почему BI показывает не то» постепенно исчезает: система начинает отражать не только то, что удобно хранить в ERP, но и то, что компания договорилась считать фактом реального процесса.

BI не исправляет разрыв между системой и процессом автоматически. Сначала важно описать реальные события, исключения и зоны ответственности, а затем связать их с данными ERP. Тогда аналитика начинает отражать работу бизнеса, а не только движение документов.