Однажды мне поставили задачу, которая казалась технически простой: разработать процесс управления ТМЦ на основе статистики ERP-системы. Тысячи записей, движения товаров, транзакции — всё это уже было внутри системы. Нужно было только «прочитать» данные правильно и превратить их в управляемый, измеримый процесс. Я так и сделал. Свёл основную массу перемещений в классифицированные потоки, нашёл закономерности, выстроил логику. Часть процессов поддалась чёткой формализации и контролю — и вот здесь я впервые почувствовал реальную силу data-driven подхода.
Граница, где данные заканчиваются
Но примерно в этот момент я «отошёл от дерева» и посмотрел на лес. И увидел проблему, о которой никто не предупреждал. Часть процессов в организации не принадлежит организации. Поставщики услуг, логистические партнёры, подрядчики — у каждого своя система, свои KPI, свои цели. Когда вы оптимизируете внутренний процесс «до блеска», а на входе или выходе стоит внешний партнёр с другой логикой работы — ваши таблицы начинают «плыть» при первом же реальном отчёте.
Это не баг аналитики. Это фундаментальное ограничение любого data-driven проекта: вы можете оптимизировать только то, чем владеете. Всё остальное решается не алгоритмами, а договорами, переговорами и управлением стейкхолдерами.
Почему это особенно важно сейчас
Сегодня рынок process mining — анализа бизнес-процессов на основе данных ERP и корпоративных систем — растёт с темпом около 45% в год. Компании массово инвестируют в Celonis, SAP Process Mining, IBM и аналоги — инструменты, которые умеют «читать» event logs и находить узкие места в процессах.
Но исследование Deloitte (2025) фиксирует ту же проблему, которую я нащупал вручную 12 лет назад: самые болезненные отклонения процессов находятся именно на границах систем — там, где внутренние данные встречаются с внешними партнёрами, подрядчиками и поставщиками.
Иными словами, process mining не заменяет работу с поставщиками и договорную аналитику — он лишь точнее показывает, где именно эта граница проходит.
Сколько стоит «самодельный велосипед»
Размышляя прошлый раз по этой теме, я пришел к выводу, который помню до сих пор: «раз вы начали собирать велосипед, подумайте в следующий раз над его покупкой». Это был вывод о стоимости времени на эмпирические решения.
Сегодня этот вывод стал ещё актуальнее:
• Инструменты process mining позволяют автоматически обнаруживать реальные процессы из логов ERP — без ручного картирования.
• BI-интеграция с ERP даёт возможность строить дашборды, которые обновляются в реальном времени, а не раз в квартал.
• AI-компоненты в современных ERP-аналитиках предсказывают отклонения до того, как они стали проблемой.
Но всё это работает только внутри периметра ваших данных. За его пределами — всё та же договорная работа и управление интересами.
Три урока из «провала в данные»
За этим проектом — и за многими похожими после него — я вижу три практических вывода для любого аналитика:
1. Формализуй процесс до начала анализа данных. Если процесс не описан однозначно — данные покажут «что происходит», но не «почему» и «что с этим делать».
2. Определи границы владения. Перед тем как строить оптимизацию, задай вопрос: кто управляет каждым шагом процесса? Если чужой — договор важнее алгоритма.
3. Не смешивай математику и прагматику. Данные говорят правду о том, что измеряется. Но они молчат о политике, интересах и мотивации людей — без этого контекста даже идеальная модель останется на бумаге.
Кольт, как говорят, «уравнял всех». Данные тоже уравнивают: они одинаково доступны умному и глупому. Разница — в том, кто умеет задать правильный вопрос и понять, где заканчиваются цифры и начинается живая организация.