Сквозной процесс глазами CEO: с чего начать

TL;DR: Эта статья — практический разбор для CEO среднего бизнеса: как использовать концепцию сквозных процессов в управлении, как выстроить ситуационный центр над имеющимися CRM/ERP/WMS и какой путь занимает 2-4 недели от карты процессов до измеримого эффекта. Если нужно базовое определение и теория — см. отдельный материал «Сквозные процессы (E2E): как найти потери».

Зачем CEO нужно понимать этот термин

В консалтинговой и ИТ-литературе термин «сквозной процесс» (или end-to-end, E2E) встречается часто, но трактуется по-разному. На практике это создаёт путаницу: руководитель внедрения CRM считает, что весь процесс продажи уже автоматизирован, операционный директор видит обрывы, финансовый директор объясняет рост DSO «человеческим фактором».

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

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

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

Чтобы CEO видел концепцию на конкретике, разберём процесс «От лида до оплаты» в B2B:

1. Маркетинг получает лид (отдел маркетинга, CRM)
2. Продажи квалифицируют лид (отдел продаж, CRM)
3. Юристы проверяют контрагента (юридический отдел, корпоративная ИС)
4. Продажи готовят коммерческое предложение (отдел продаж, CRM)
5. Юристы согласовывают договор (юридический отдел, DMS)
6. Финансы выставляют счёт (бухгалтерия, ERP)
7. Операции исполняют заказ (производство или склад, ERP/WMS)
8. Логистика отгружает (отдел логистики, WMS/TMS)
9. Бухгалтерия фиксирует оплату и закрывает сделку (ERP)

Девять шагов. Пять отделов. Минимум четыре системы. Каждый отдел отвечает за свой кусок. Никто не отвечает за весь процесс целиком. Сроки и качество стыков между шагами никто не измеряет.

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

Кратко: сквозной vs функциональный

Функциональный процесс работает внутри одного отдела. Сквозной — пересекает несколько отделов и систем, начинается с внешнего события и заканчивается измеримым результатом. Подробное определение, отличия и список 13 базовых сквозных цепочек предприятия мы разобрали в отдельной статье «Сквозные процессы (E2E): как найти потери». Здесь сосредоточимся на практической стороне для CEO.

Большинство компаний к 2026 году уже автоматизировали значительную часть функциональных процессов. CRM в продажах работает, ERP в финансах работает, WMS на складе работает. Каждая система внутри своего отдела показывает зелёные дашборды. А Order-to-Cash в среднем по российскому B2B составляет 47-65 дней при бенчмарке APQC 28-35 дней (источник: APQC Process Classification Framework v7.4, 2024). Разница ровно на стыках между отделами.

Пример из логистики

Один из наших проектов диагностики 2026 года: логистическая компания, таможенный представитель, 200 сотрудников, 600 млн ₽ годовой выручки. Изучали сквозной процесс «Приём нового клиента и первое таможенное оформление».

Регламент компании предписывал прохождение процесса за 5 рабочих дней: регистрация клиента, проработка запроса (товарная номенклатура, оценка рисков, нетарифные меры), назначение оформляющего менеджера, подача декларации, выпуск.

Фактический срок составлял 12 дней. Расхождение в 7 дней объяснялось четырьмя стыками между отделами.

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

Стык 2: клиентский менеджер передаёт запрос декларанту. Передача идёт через корпоративную ИС, но без жёсткого SLA. Декларант видит запрос только когда заходит в систему по своему ритму. Средняя задержка передачи 4 часа в норматив 30 минут.

Стык 3: декларант запрашивает у клиента уточнения по ТНВЭД-кодам. Уточнения идут по электронной почте. Среднее время цикла «вопрос-ответ» 1,5 дня. За 5 рабочих дней процесса успевает пройти 2-3 итерации.

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

Каждый отдельный отдел работал по своему регламенту. У клиентского менеджера, оформляющего менеджера, декларанта были должностные инструкции и KPI. Стыки между ними не имели ни SLA, ни владельца, ни системы измерения.

После диагностики компания установила контракт данных между ролями: что передаётся, в каком формате, с каким SLA. Сценарии нештатных ситуаций описаны явным алгоритмом. Цикл «приём клиента, первое оформление» вернулся к нормативу 5 дней.

Цифры обезличены, имена клиента и систем изменены. Профиль и масштаб типичны для российского среднего бизнеса в логистике.

Где видны сквозные процессы

В большинстве компаний сквозной процесс не виден ни в одной системе целиком.

CRM показывает воронку продаж до этапа «оплата». После оплаты след пропадает. ERP показывает заказы и их финансовый статус. До CRM-этапа след пропадает. WMS показывает движение товара на складе. До и после склада след пропадает.

Чтобы увидеть сквозной процесс целиком, нужен отдельный слой управленческой видимости. Этот слой собирает данные из CRM, ERP, WMS, проектного трекера и складывает их в единую модель: один заказ это одна нить, проходящая через все системы.

Этот слой мы называем Ситуационным центром. Он не заменяет CRM или ERP. Он строится поверх них и показывает то, что не видит ни одна функциональная система: стыки между шагами и время прохождения каждого стыка.

Как начать работать со сквозными процессами

Минимальный путь, который занимает 2-4 недели:

Шаг 1. Выбрать 1-3 ключевых сквозных процесса для своей отрасли. Для большинства компаний это «Заказ-в-деньги» (Order-to-Cash), «Закупка-в-оплату» (Procure-to-Pay), «Найм-в-сотрудника» (Hire-to-Retire). Для проектных компаний добавляется «Запрос-в-результат» (Quote-to-Result).

Шаг 2. Нарисовать карту процесса. Шаги, отделы, системы, документы. На каждом стыке отметить: кто передаёт, кому, в каком формате, по какому SLA. Если SLA нет, это уже разрыв.

Шаг 3. Замерить время прохождения каждого стыка на выборке последних 50-100 случаев. Реальные сроки, не нормативные. Так становятся видны узкие места.

Шаг 4. По 2-3 худшим стыкам зафиксировать контракты данных и SLA. Контракт пишется один раз и подписывается обоими руководителями смежных отделов. Контроль соблюдения встраивается в управленческий дашборд.

Шаг 5. После того как 2-3 стыка устранены, перейти к следующим. Спринтовая модель: 4 недели на стык, после чего ревью и переход к следующему.

В наших проектах диагностики этот путь даёт измеримое снижение операционных потерь на 55-65% за 12 недель работы (медиана по 8 проектам 2024-2026). Полная карта 13 ключевых сквозных процессов компании готовится за 2 недели платной диагностики.

Что почитать дальше

• Сквозные процессы (E2E): как найти потери: базовое определение сквозных процессов, отличие от функциональных, обзор 13 базовых сквозных цепочек предприятия.
• Методика «Стыки дороже систем»: концепция, по которой потери концентрируются на стыках между отделами, а не внутри функций.
• Ситуационный центр для среднего бизнеса: управленческий слой над CRM/ERP/WMS, который делает сквозные процессы видимыми и управляемыми.
• Playbooks для CEO, CFO, COO, CIO: 24 эталонных сценария управления через стыки. Готовый алгоритм решения по каждому типичному инциденту в дашборде.
• Калькулятор потерь на стыках: оценка ваших операционных потерь за 5 минут, без регистрации.

Если в вашей компании Order-to-Cash дольше отраслевого бенчмарка хотя бы на 30%, это не проблема систем. Это проблема невидимых стыков. Они становятся видимыми только тогда, когда их явно нанесли на карту.