02 Декабря 2025 10:00 02 Дек 2025 10:00 |

Поделиться

Алексей Коровин, NDBC: Порядок рождается из управляемости, а не из наличия программы

«ERP — это результат. BPM — это путь к результату»

CNews: Сегодня почти в каждой компании внедрена ERP, а многие уже начали автоматизацию процессов в BPM. Но руководители по-прежнему сталкиваются с плавающими сроками, неравномерной нагрузкой и отсутствием предсказуемости. Почему сама по себе автоматизация не решает этих проблем?

Алексей Коровин: Потому что автоматизация не меняет правила работы. Если в компании не определено, кто принимает решения, по какой логике движется работа, какие сроки обязательны, что считается результатом, то ERP лишь фиксирует последствия, а BPM визуализирует хаос. Порядок рождается из управляемости, а не из наличия программы.

CNews: Часто можно услышать фразу «у нас всё описано и автоматизировано». Но на практике работа идёт «как договоримся». Почему?

Алексей Коровин: Описать — не значит сделать управляемым. ERP отвечает на вопрос «Что произошло?» (данные, документы, проводки), а BPM отвечает на вопрос «Как это должно происходить?» (последовательность действий, роли, сроки). Но ни одна из этих систем сама не определяет, какой способ выполнения работы считается правильным. Это решается до автоматизации.

«Самая частая ошибка — начинать внедрение с выбора системы»

CNews: Где компании чаще всего ошибаются при попытке «внедрить порядок»?

Алексей Коровин: Организации часто начинают автоматизацию с решения вопроса, какую систему выбрать или как настроить маршруты. Однако правильный порядок обратный:

1. Какой процесс считаем правильным — описанный в деталях.
2. Кто отвечает за этот процесс на уровне результата.
3. Какие правила обязательны для всех подразделений и филиалов.

И только после этого внедряем BPM и ERP. Если поменять последовательность, автоматизация закрепит то, что есть. А то, что есть, в большинстве случаев неуправляемо.

CNews: Как компании приходят к этому пониманию?

Алексей Коровин: Через пошаговый управляемый проект изменений — не через «внедрение системы».

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

Затем проектируется целевая модель — с понятными ролями, порядком действий и исключениями. Так все сотрудники начинают работать по единому стандарту.

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

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

Эта логика описана в материале NDBC и включает такие практики, как «Приведение к стандарту», «Модель компании», Lean PMO, постоянное управление изменениями.

«Проблема не в системе. Проблема в том, что процесс живет в головах людей»

CNews: Как понять, что компания работает не по процессу, а по личным договорённостям?

Алексей Коровин: Есть четыре характерных признака:

1. Новые сотрудники «учатся месяцев пять» — потому что обучение идёт через людей, а не через процесс.
2. Сроки «плавают», и никто не может объяснить, почему.
3. Два отдела делают одинаковую задачу по-разному.
4. Претензии «кто должен был сделать» появляются чаще, чем результат.

Это не проблемы мотивации. Это отсутствие общей модели работы.

CNews: Какие изменения происходят после внедрения управляемого процесса в BPM и настройки ERP под него?

Алексей Коровин: Самые заметные — три. Первое: раньше работа выполнялась «через знакомства и переписку», а после перехода на исполняемую модель она начинает двигаться по маршруту. Сроки перестают «плавать» и становятся стабильнее.

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

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

Это и есть управляемость.

CNews: Как сформулировать главный вывод для топ-менеджеров?

Алексей Коровин: Системы не наводят порядок, они усиливают то, что есть.
Если внутри компании нет согласованных правил работы — ERP и BPM закрепят хаос. Если правила есть, процесс понятен и управляется — ERP и BPM масштабируют эффект.

«Цифровизация работает только там, где есть единое понимание процесса»

CNews: Вероятны ли ситуации, когда внедрение BPM без предварительного проектирования процесса только усугубляет ситуацию? Что именно идёт не так?

Алексей Коровин: Да, такие ситуации случаются регулярно: если просто «заводить» текущий хаотичный порядок в BPM без проектирования целевой модели, система лишь фиксирует и усиливает существующий бардак вместо того, чтобы его убрать. В результате задачи начинают копиться, сотрудники обходят формальные маршруты через почту и мессенджеры, а руководитель впервые видит в отчётах реальный масштаб хаоса, который раньше был спрятан в личных договорённостях.

Основной ошибкой является перепутанная последовательность: сначала выбирают платформу и рисуют маршруты, а уже потом пытаются договориться о том, как «правильно» работать, и кто за что отвечает, из-за чего ERP лишь фиксирует последствия, а BPM визуализирует несогласованные правила разных отделов.

CNews: По практике, кто чаще всего противится изменениям: исполнители, средний менеджмент или ИТ? Что больше всего не устраивает сотрудников?

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

Исполнителей больше всего пугает потеря привычной гибкости «решить вопрос по-своему», рост прозрачности и измеримости работы, а также риск, что система покажет реальную загрузку и качество выполнения задач по объективным метрикам.

Среднему менеджменту болезненно переходить от личных договорённостей к работе по формальному процессу с жёсткими сроками и SLA, потому что исчезает возможность «договориться задним числом» и становится видно, кто действительно управляет, а кто только перекладывает ответственность. ИТ-подразделения сопротивляются не идее BPM как таковой, а риску получить плохо сформулированные требования и «ответственность за всё», хотя система лишь отражает управленческие решения, которые должны быть приняты до автоматизации.

«Когда процесс становится исполняемым — зависимость от отдельных людей исчезает»

CNews: Сколько времени занимает переход от «процессов в головах» к работающей управляемой модели, где ERP и BPM уже приводят к измеримым результатам?

Алексей Коровин: Для одной ключевой цепочки в средней компании реальный горизонт занимает примерно три-шесть месяцев: от старта диагностики до достижения устойчивых, измеримых результатов в ERP и BPM.

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

Если речь о портфеле взаимосвязанных процессов (например, поддержке, продажах, логистике, закупках), реалистичный срок — шесть-девять месяцев до того момента, когда зависимость от отдельных людей снижается, а сроки и качество становятся предсказуемыми по всем цепочкам.

CNews: Какие метрики используют на этапе диагностики реальной работы? Какое среднее время выполнения задачи или процент просроченных дедлайнов? Есть ли конкретные примеры в цифрах, как эти показатели меняются при вдумчивом и последовательном внедрении BPM?

Алексей Коровин: На диагностике смотрят целый набор метрик: сквозное время прохождения ключевых задач, долю просроченных SLA, количество возвратов и переделок, число ошибок на 100 операций, долю ручных эскалаций и зависимость результата от конкретных людей или подразделений. Отдельно анализируют время до первого отклика клиенту или внутреннему заказчику, количество «петель» в процессе (возвраты по маршруту) и долю задач, которые проходят мимо учётных систем в почту и мессенджеры.

CNews: Как интегрируют BPM с существующими ERP-системами, например с «1С»? Через API, коннекторы или ручную настройку? Сколько времени уходит на это?

Алексей Коровин: Базовый сценарий — интеграция через стандартные API и веб-сервисы ERP. В случае «1С» обычно используются REST или OData, регламентный обмен документами и справочниками, для других ERP — готовые коннекторы, сервисы и очереди сообщений, которые инициируются из BPM.

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

По срокам, для типового контура, например, «BPMSoft — 1С» по ограниченному набору сущностей, разумный диапазон занимает около трёх-шести недель до «боевого» запуска с учётом тестирования и корректировки модели процесса.

В проектах NDBC на low-code платформе BPMSoft мы обычно начинаем с минимально жизнеспособного контура интеграции — нескольких ключевых сущностей и простого маршрута, и уже по мере стабилизации расширяем охват. Такой подход позволяет ИТ и бизнесу быстро увидеть эффект от сквозного процесса и одновременно снизить риски для существующей ERP.

В более сложных сценариях сквозной интеграции с ERP и внешними сервисами, как в фарм-логистике или при построении дорожной карты для крупного холдинга, требуется два-три месяца, потому что параллельно выстраиваются и процессы, и интеграционная архитектура.На примере BPMSoft для нас важно сочетание двух составляющих: гибкой модели процессов и нормальной «технической приземленности» — наличия API, очередей сообщений, стандартных механизмов обмена. За счёт этого платформа не конфликтует с уже работающей ERP, а становится надстройкой, в которой живёт процесс, тогда как учёт и финансовый результат остаются в профильных системах.

CNews: Вы сказали, что «обучение занимает месяцев пять», а сколько времени действительно в среднем занимает адаптация новичков в компаниях без стандартизированных процессов по данным NDBC? Как этот срок сокращается после исполнения в BPM?

Алексей Коровин: В компаниях без стандартизированных процессов и единой модели работы адаптация новичков действительно занимает порядка четырех-шести месяцев до состояния «можно работать без постоянного наставника.

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

После перехода к исполняемой модели в BPM и настройке ERP под этот процесс срок адаптации заметно сокращается, потому что у новичка появляется один прозрачный маршрут, понятные статусы, шаблоны задач и встроенные проверки качества.

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

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

«Главное — не купить систему, а сформировать единый способ работы»

CNews: Вы говорите про снижение операционного риска. Как вы его измеряете — например, число ошибок на 100 задач? Какие цифры в реальных проектах NDBC: сколько было и сколько стало?

Алексей Коровин: Операционный риск измеряется набором показателей: числом ошибок и инцидентов на заданный объём операций (например, на 100 заказов или отгрузок), долей задач с нарушением сроков, количеством эскалаций и ручных вмешательств, а также финансовыми последствиями в виде штрафов, списаний и возвратов.

Отдельно оценивается зависимость результата от конкретных сотрудников: если ключевые этапы выполняют один-два специалиста, то даже при небольшом количестве ошибок это считается высоким операционным риском.

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

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

В обоих случаях ключевую роль сыграло не только внедрение BPMSoft как платформы, но и создание управляемого процесса поверх неё: понятные зоны ответственности, единые правила по исключениям и прозрачные SLA. Платформа здесь выступает инструментом исполнения, а управляемость возникает за счёт того, как именно этот инструмент настроен.

Крупный холдинг, для которого на базе BPMSoft была построена дорожная карта из 12 направлений бизнес-процессов и целевая архитектура, снизил риск «узких мест» и непрозрачных зон в ИТ-ландшафте за счёт создания единых стандартов и согласованных правил управления.

Поделиться

Подписаться на новости Короткая ссылка