Реинжиниринг бизнес-процессов.

Что это простыми словами

Реинжиниринг — это когда процесс не чинят по кусочкам, а сносят и собирают заново. Не «давайте ускорим согласование на 10%», а «давайте спросим, зачем тут вообще пять согласований». Термин в 1993-м ввели Майкл Хаммер и Джеймс Чампи: фундаментальное переосмысление и радикальное перепроектирование процесса ради скачка в скорости, качестве и издержках — в разы, а не на проценты.

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

Зачем это бизнесу

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

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

Как это работает

Это не формула, а последовательность. Радикальность без управления — хаос, поэтому шаги по порядку:

1. Выбрать процесс, который реально тормозит масштаб (сквозной, межотдельный, тяжёлый)
2. Спросить «зачем», а не «как ускорить»: какие шаги вообще не нужны
3. Спроектировать процесс заново — вокруг данных и результата, а не вокруг оргструктуры
4. Положить на новый процесс ИТ (единая система/база), а не оцифровать старый
5. Замерить эффект: время цикла, стоимость операции, качество — до и после

Пример. Финансирование покупки техники (кейс IBM Credit): заявка шла по цепочке узких специалистов — кредитный аналитик, юрист, прайсинг, оформление, — и согласование занимало в среднем около недели. Хотя сама работа по заявке — полтора часа, остальное съедали передачи бумаги между отделами. Процесс пересобрали: один «дженералист» (deal structurer) с единой системой ведёт сделку целиком. Время согласования упало с дней до часов. Не «ускорили каждого специалиста», а убрали саму эстафету.

Примеры из жизни

• Ford, расчёты с поставщиками. Классика жанра. Раньше отдел вручную сверял накладные, счета и заказы и разросся примерно до 500 человек. Процесс переписали вокруг общей базы данных: оплата идёт по факту поставки, без бумажной сверки счетов. По Хаммеру и Чампи отдел сократился примерно до 125 человек — каноничный учебный кейс BPR.
• IBM Credit (см. выше): цепочка специалистов → один дженералист с системой; дни → часы.
• Российские банки и сервисные компании. При переходе от функциональной оргструктуры (отделы-колодцы) к процессной фактически делают BPR: выстраивают сквозной путь клиента «от заявки до выдачи» поверх единой системы вместо передачи бумаг между подразделениями. Внедряют обычно на BPM-платформах (ELMA365, Битрикс24, отечественный low-code).

Когда это про вас

Честно: малому бизнесу, стартапам и компаниям на ранней стадии реинжиниринг обычно не нужен. Процессы ещё не закостенели — дешевле гибко донастраивать (kaizen, постепенная оптимизация), чем устраивать радикальную ломку. Ломать пока нечего.

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

Грабли и мифы

• Реинжиниринг ≠ автоматизация «как есть». Оцифровали кривой процесс — получили быстрый кривой процесс. BPR требует сначала переосмыслить процесс, и только потом класть на него ИТ. Перепутать эти два шага — самая дорогая ошибка.
• Миф «реинжиниринг = сокращение людей». Цель — скачок эффективности процесса; массовые увольнения иногда следствие, но не самоцель. Подмена цели на «давайте уволим» убивает поддержку проекта изнутри.
• Недооценка масштаба и сопротивления. Заметная доля BPR-проектов в литературе считается неудачными: сопротивление персонала, нет поддержки топ-менеджмента, попытка «переписать всё сразу». Радикальность без управления изменениями = хаос. Лучше один сквозной процесс целиком, чем вся компания разом.