Сквозной процесс (End-to-End Process, М. Хаммер)

Сквозной процесс (End-to-End Process) — структурное свойство процесса: он пересекает всю цепочку создания ценности от запроса клиента до результата без разрывов на функциональные границы, в идеале под единой ответственностью процесс-владельца. Противоположность — процесс, раздробленный на изолированные фрагменты, каждый из которых оптимизируется своим отделом без учёта результата для клиента в целом.

Происхождение и исследовательская база

Концепция систематизирована Майклом Хаммером в рамках реинжиниринга бизнес-процессов (Business Process Reengineering) в начале 1990-х — Хаммер утверждал, что традиционная функциональная организация систематически фрагментирует процессы, создавая множество передач между отделами, каждая из которых — источник задержки, потери информации и размытой ответственности.

«Не автоматизируйте, а уничтожайте» — призыв Хаммера полностью пересматривать фрагментированные процессы, а не просто ускорять их существующую, разорванную структуру.

Флагманский реальный кейс самого Хаммера, впервые описанный в статье «Reengineering Work: Don't Automate, Obliterate» (Harvard Business Review, 1990), — IBM Credit Corporation, дочерняя компания IBM, финансирующая покупку компьютеров и услуг клиентами IBM. Заявка на кредит проходила через 5 последовательных отделов (проверка кредитоспособности → согласование условий → расчёт цены → оформление документов → передача заявки). Два старших менеджера лично прошли с одной заявкой весь путь и засекли время — реальная работа над заявкой занимала всего 90 минут, а остальные более 7 дней в среднем уходили на передачу бумаг из отдела в отдел и ожидание в очереди. Решение: вместо 4-5 узких специалистов ввели единую роль «структуратор сделки» (deal structurer) — один человек с доступом к единой компьютерной системе вёл заявку от начала до конца самостоятельно, обращаясь к редким экспертам только в сложных случаях. Результат: время обработки заявки сократилось с 6 дней до 4 часов — это тот самый принцип единого владельца процесса (Принцип 3) и минимизации передач (Принцип 2), применённый буквально.

Более современный и структурный пример того же принципа в совершенно другой отрасли — реорганизация Cleveland Clinic под руководством CEO Тоби Косгроува в 2007 году: вместо традиционных медицинских департаментов (кардиология, кардиохирургия и т.д. как отдельные, слабо связанные подразделения) клиника создала 27 «институтов», организованных вокруг конкретных состояний пациента (например, Heart & Vascular Institute объединил кардиологов, кардиохирургов и смежных специалистов в одну структуру). Пациент с проблемой сердца перестал «передаваться» между отдельными департаментами кардиологии и кардиохирургии — весь путь его лечения вела единая мультидисциплинарная команда одного института. По собственным отчётам клиники, реорганизация сопровождалась ростом вовлечённости персонала, ростом удовлетворённости пациентов и снижением числа жалоб.

Ключевые идеи и принципы

1. Принцип: процесс пересекает функциональные границы целиком.

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

2. Принцип: минимизация передач между отделами.

   Каждая передача (handoff) между функциональными подразделениями — точка риска: задержка, искажение информации, размытие ответственности. Чем меньше передач относительно общего числа шагов процесса, тем более он «сквозной».

3. Принцип: единый процесс-владелец.

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

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

Ограничения, слепые зоны и критика

Типовые ошибки

1. Ошибка 1: оптимизируют отдельные фрагменты процесса без взгляда на целое.

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

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

   Как избежать

   назначать единого владельца сквозного процесса, ответственного за результат целиком, а не за отдельный фрагмент.

2. Ошибка 2: не измеряют число передач между отделами.

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

   Как избежать

   явно картировать и измерять число передач относительно общего числа шагов процесса.

3. Ошибка 3: автоматизируют фрагментированный процесс вместо его пересмотра.

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

   Как избежать

   следовать принципу Хаммера — сначала переосмыслить процесс как единое целое, и только потом автоматизировать.

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

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

   Как избежать

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

5. Ошибка 5: реорганизация меняет оргструктуру, но не меняет систему стимулов и оценки сотрудников.

   Отделы формально объединены в единый сквозной процесс (как в модели «структуратора сделки» или институтов Cleveland Clinic), но сотрудников по-прежнему оценивают и вознаграждают по узким функциональным метрикам своего прежнего отдела — люди продолжают оптимизировать то, за что их измеряют, независимо от новой структуры, и сквозная логика существует только на бумаге.

   Как избежать

   пересматривать систему KPI и вознаграждения одновременно со структурной реорганизацией — метрики должны отражать результат сквозного процесса целиком (как в кейсе IBM Credit — скорость и качество обработки заявки), а не промежуточные шаги внутри бывшего отдела.

План внедрения

1. Месяц 1: картировать текущие ключевые процессы, подсчитать число передач между отделами в каждом.

2. Месяц 2: выявить процессы с наибольшей фрагментацией, назначить единых владельцев.

3. Месяц 3: пересмотреть структуру наиболее фрагментированных процессов, сокращая число передач.

   Далее: Поддержание и обновление — регулярно отслеживать число передач как индикатор фрагментации.

   Параллельно с самой структурой стоит пересматривать систему оценки сотрудников (см. Ошибка 5) — иначе реорганизация останется формальной, как это признал сам Хаммер после первой волны реинжиниринга 1990-х.

Как реализовать этот план с помощью фрейма «Сквозной процесс» в OrgDevTools

Фрейм — не карточки, а настоящий живой калькулятор с двумя числовыми полями на вкладке «Калькулятор»: «Всего шагов процесса» и «Передач между отделами». Соотношение второго к первому вычисляется автоматически в реальном времени и выводится крупным числом — доля передач на шаг, с цветовой индикацией: зелёный ≤20% (близко к сквозному), жёлтый 21-40% (заметная фрагментация), красный >40% (сильно фрагментирован, не сквозной по Хаммеру).

Месяц 1 плана (картировать процессы, подсчитать передачи) — прямое заполнение обоих числовых полей калькулятора; для кейса IBM Credit ДО реинжиниринга это было бы 5 шагов при 4 передачах (80%, глубоко красная зона), а ПОСЛЕ — по сути 1 шаг, 0 передач. Месяц 2 (выявить наиболее фрагментированные процессы) — сравнение доли передач у разных процессов организации, заполняемых как отдельные записи фрейма. Месяц 3 (пересмотр структуры, сокращение передач) — повторный ввод обновлённых чисел после реорганизации, чтобы явно увидеть сдвиг цвета индикатора.

Вердикт на вкладке «Итоги» вычисляется по реальной пороговой формуле, а не по факту заполнения: без чисел — просит их ввести; при доле ≤20% — зелёный вердикт «процесс близок к сквозному»; при 21-40% — жёлтый с точным процентом и предупреждением про риск задержки; выше 40% — красный вердикт, дословно называющий процесс «не являющимся сквозным по Хаммеру». Кнопка «Создать задачу» формирует задачу «Сократить число передач между отделами в процессе» независимо от текущего значения — она не привязана к конкретному проценту.

Книги по теме

М. Хаммер, Дж. Чампи — «Reengineering the Corporation» (1993). Первоисточник концепции сквозного процесса и реинжиниринга.

M. Hammer — «Reengineering Work: Don't Automate, Obliterate» (Harvard Business Review, 1990). Первая публикация кейса IBM Credit Corporation и самой концепции сквозного процесса, за 3 года до книги — источник точных цифр (5 шагов, 90 минут реальной работы, 7 дней ожидания, результат 6 дней → 4 часа).

M. Hammer — «Beyond Reengineering: How the Process-Centered Organization Is Changing Our Work and Our Lives» (1996). Книга, написанная после публичных извинений Хаммера за недооценку человеческого фактора в первой волне реинжиниринга — источник Ошибки 4 и 5 этого документа: структурная реорганизация без реальных полномочий владельца процесса и без пересмотра системы стимулов сотрудников.