Сквозной процесс идёт через отделы и рвётся на стыках

Большинство компаний управляют отделами и теряют результат на стыках между ними. Клиент оставил заявку, продажи оформили сделку, но склад не увидел команду на отгрузку. Бухгалтерия не выставила счёт. Заказ завис на неделю между тремя подразделениями.

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

Сквозной процесс простыми словами

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

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

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

В международной практике такой поток называют E2E, от английского end-to-end — «от начала до конца». Тот же смысл несут формулировки «сквозное управление бизнес-процессами» и «сквозной бизнес-процесс»: речь об управлении всей цепочкой поперёк функций. Ключевой признак сквозного процесса один. Его результат принадлежит конечному клиенту и считается на выходе всей цепочки. Сумма отчётов подразделений этого не заменяет.

Чем сквозной процесс отличается от функционального

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

Именно так чаще всего устроена и автоматизация: по функциям, поток между ними остаётся несшитым. По данным «СберАналитики», документооборот и обработку заявок автоматизируют 70% компаний, бухгалтерию и финансовый учёт — 55%, HR-процессы — 34%. Каждая из этих функций улучшается сама по себе, а передача заявки и информации между ними остаётся ручной. Автоматизированный документооборот не помогает, если на стыке с бухгалтерией документ всё равно перепечатывают вручную.

Разницу удобно держать в двух колонках:

• Функциональный процесс: цель — эффективность функции; метрика — загрузка и выработка подразделения; отвечает руководитель отдела.
• Сквозной процесс: цель — результат для клиента; метрика — время и качество всего потока; отвечает владелец процесса.

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

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

Андрей Манюхин, консультант по системам управления.

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

Виды сквозных процессов: Order-to-Cash, Procure-to-Pay, Hire-to-Retire

Типовые сквозные процессы удобно узнавать по каркасам E2E, например Order-to-Cash или Procure-to-Pay. Каждый склеивает свою цепочку функций от старта до финансового или кадрового итога. В каждом есть точки, где поток передаётся из звена в звено. Эти каркасы работают как опора: увидев их в своей компании, руководитель понимает, из каких звеньев собран поток и где проходят межфункциональные передачи. Полезно посмотреть, какой из этих каркасов даёт больше всего сбоев, и после начать разбор именно с него.

Заказ до оплаты: цикл Order-to-Cash (O2C)

Order-to-Cash, или O2C, собирает цепочку от получения заказа до поступления денег на счёт. Его этапы: продажи, проверка кредитного лимита, сборка и отгрузка, выставление счёта и контроль оплаты. Заказ здесь минимум трижды переходит между функциями: от продаж к складу, от склада к логистике, от логистики к бухгалтерии. На каждой из этих передач заказ и способен зависнуть.

Закупка до расчёта с поставщиком: Procure-to-Pay (P2P)

Procure-to-Pay, или P2P, тянется от потребности в закупке до расчёта с поставщиком. Заявку на закупку согласуют, выбирают поставщика, оформляют договор, принимают поставку и оплачивают счёт. Поток идёт через инициатора закупки, снабжение, юристов, склад и финансы. Сбой на стыке снабжения и финансов оборачивается просроченной оплатой и штрафом от поставщика.

Наём до увольнения: цикл Hire-to-Retire (H2R)

Hire-to-Retire, или H2R, охватывает весь путь сотрудника от найма до увольнения. В цепочку входят подбор, оформление, адаптация, обучение сотрудника, оценка и расчёт при уходе. Здесь поток передаётся между рекрутингом, кадрами, руководителем и бухгалтерией. Новый сотрудник, который неделями ждёт доступы и оборудование, — типичный симптом разрыва H2R на стыке кадров и IT.

Где сквозной процесс рвётся: стыки между отделами

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

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

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

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

Елена Захарова, руководитель процессного офиса.

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

На стыке функций такую передачу проще делать асинхронно — записывать короткое видео с объяснением статуса и контекста через сервисы вроде Loom или «Глабикс». Тогда следующий отдел принимает работу без общего совещания, а передача больше не зависит от того, удалось ли собрать людей в одно время.

Владелец сквозного процесса

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

Разницу между формальным и настоящим владельцем определяют ресурсы. Формального ответственного лишь фиксируют в регламенте. Настоящий владелец получает ресурсы и право менять ход процесса.

«Владелец процесса — должностное лицо, которое имеет в своём распоряжении выделенные ресурсы, управляет ходом процесса и несёт ответственность за результаты и эффективность процесса»

Владимир Репин, консультант по управлению, член ABPMP Russian Chapter.

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

Автоматизация сквозных процессов

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

Рынок инструментов для этого в России зрелый и импортозамещённый. По данным CNews Analytics, 85–90% новых внедрений приходится на российские BPM-системы. Масштаб денег в сегменте виден по вендорам: топ-10 лидеров заработали на BPM-проектах ₽15,6 млрд в 2024 году. Поверх процессных систем компании добавляют искусственный интеллект: по данным «СберАналитики», 39% российских компаний используют его для автоматизации бизнес-процессов.

Как сшивка именно потока, а не отдельной функции, выглядит на практике, показывает группа компаний «ВОЛМА», производитель строительных материалов. Компания объединила в единой системе на платформе BPMSoft работу с клиентами, от лида до сделки и согласования цены, и закупки, которые прежде жили в разных отделах. В итоге скорость обработки лидов выросла на 40%, а сроки закупочных процессов сократились на 10–20%.

Единая система ускорила сквозной поток, автоматизировав два ключевых процесса:

• обработку лида — цепочку от продаж к ценообразованию и согласованию;
• закупку — цепочку от заявки к оплате поставщику.

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

Метрики сквозного процесса

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

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

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

Сама расшивка потока в самоотчёте компаний даёт измеримый эффект. По данным «СберАналитики», 45% респондентов отметили, что автоматизация ускорила решение типовых задач, а 37% — снижение доли ручных операций. Ручные операции и есть те самые передачи на стыках, где поток чаще всего и застревает.

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

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

Порядок здесь важнее инструмента. Автоматизация без владельца и метрики ускорит отдельные операции, но оставит разрыв на стыке. Владелец без метрики не увидит, где именно теряется время. Метрика без владельца покажет разрыв, но исправлять его будет некому.

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