Большинство программ улучшения процессов работают в рамках уже существующей структуры — сокращают лишние шаги, ускоряют согласования, автоматизируют рутину. Реинжиниринг бизнес-процессов ставит вопрос иначе: если бы этого процесса не существовало вообще, каким бы мы его спроектировали сегодня, с нуля? Ответ почти никогда не похож на текущий процесс — потому что текущий процесс сложился исторически, под давно устаревшие ограничения (бумажный документооборот, разделение труда столетней давности, недоверие между отделами), а не был спроектирован рационально под сегодняшние возможности и цели.
Метод возник как реакция на разочарование в программах постепенного улучшения качества (TQM, кайдзен) там, где сам процесс был настолько структурно устаревшим, что мелкая шлифовка ничего не меняла по существу — организации годами улучшали процесс на проценты, оставаясь на том же порядке величины по скорости и стоимости. Реинжиниринг предложил другой путь: не улучшать то, что есть, а спроектировать заново с чистого листа, приняв за отправную точку не текущую структуру отделов, а результат, который нужен клиенту.
Не автоматизируйте — уничтожайте. Замена старого процесса компьютером, который делает то же самое быстрее, — не реинжиниринг, а дорогая консервация ошибки.
Происхождение и исследовательская база
Идею впервые сформулировал Майкл Хаммер, профессор MIT, в статье "Reengineering Work: Don't Automate, Obliterate" (Harvard Business Review, июль-август 1990, стр. 104-112). Ключевой пример статьи — отдел оплаты счетов Ford Motor Company: компания сократила число сотрудников отдела с 400 до 5 не покупкой более быстрого софта, а полным пересмотром логики процесса. Раньше три документа — заказ на закупку, накладная о получении товара и счёт поставщика — сверялись вручную по 14 позициям в трёх разных подразделениях; несовпадение хотя бы по одной позиции останавливало оплату. Новый процесс проверял только один факт — реальное поступление товара на склад, зафиксированное при приёмке, — и оплата запускалась автоматически без счёта от поставщика вообще. Ford ориентировался на японского партнёра Mazda, где тот же процесс исторически вела вчетверо меньшая по числу сотрудников команда — это доказывало: дело не в нехватке рабочих рук, а в самой архитектуре процесса.
Похожий, ещё более наглядный случай — кредитный отдел IBM Credit Corporation, который также приводится Хаммером как образцовый пример. Оформление заявки на финансирование компьютерной техники занимало от 6 дней до 2 недель: заявка проходила пять отделов (кредитная проверка, корректировка условий, ценообразование, подготовка контракта, экспедирование) один за другим, каждый — узкий специалист, знающий только свой участок. Проверка показала: реальной работы над заявкой требовалось не больше 90 минут, а остальное время документ просто лежал в очереди на столе очередного специалиста в ожидании, пока до него дойдёт черёд. Решение не потребовало новых специалистов — пять последовательных ролей заменили одним generalist-сотрудником ("deal structurer"), который с помощью единой компьютерной системы, объединившей инструменты всех пяти прежних специалистов, вёл заявку от начала до конца сам. Срок обработки сократился с недели до 4 часов — стократный рост производительности без увеличения штата.
В 1993 году Хаммер и консультант Джеймс Чампи развернули идею в книгу "Reengineering the Corporation: A Manifesto for Business Revolution" — она разошлась многомиллионным тиражом и стала одной из самых влиятельных и одновременно самых спорных управленческих концепций 1990-х: метод массово внедряли крупные корпорации по всему миру, а затем так же массово критиковали за то, что под его вывеской проводились обычные сокращения штата без реального пересмотра логики процессов.
Ключевые идеи и принципы
Принцип: Фундаментальность — вопрос "зачем мы это вообще делаем"
Реинжиниринг начинается не с "как сделать процесс лучше", а с "почему мы вообще так делаем" и "что если бы мы начинали с чистого листа". Команда должна поставить под сомнение даже базовые допущения о процессе — не только правила и процедуры, но и сами исходные предположения, на которых процесс построен. Если ответ на исходный вопрос — только "потому что так было всегда" или "потому что так устроена наша оргструктура", это прямой сигнал, что процесс — кандидат на полную замену, а не на подстройку.
Принцип: Радикальность — переизобретение, а не доработка
Радикальный редизайн в буквальном значении слова "radix" (лат. "корень") — это переделка от корня, а не косметика на поверхности. Он отбрасывает существующие процедуры, роли и организационные границы целиком и придумывает совершенно новый способ выполнения работы — в отличие от улучшения, которое принимает текущую структуру как данность и латает то, что уже есть внутри неё.
Принцип: Кратный результат, а не проценты
Целевой эффект реинжиниринга — не 10-20% ускорение, а изменение в разы или на порядок, как в примерах Ford и IBM Credit выше. Если организации нужно небольшое, предсказуемое улучшение — правильный инструмент обычная оптимизация или кайдзен; реинжиниринг оправдан экономически и организационно только тогда, когда нужен скачок такого масштаба, ради которого стоит пойти на риск временной дестабилизации работающего процесса.
Принцип: Ориентация на процесс, а не на функцию
Организация строится вокруг сквозных процессов, создающих ценность для клиента (например, "от заказа до оплаты" или "от заявки до одобрения кредита"), а не вокруг функциональных отделов, каждый из которых видит только свой узкий участок и формально не отвечает за конечный результат для клиента целиком. Именно разрыв ответственности на границах отделов — источник большинства задержек, показанных в примере IBM Credit.
Принцип: Один ответственный ведёт процесс от начала до конца
Вместо эстафеты между отделами процессом управляет один человек или небольшая команда (так называемый case manager, "хозяин случая") — клиент процесса получает единую точку контакта вместо необходимости самому разбираться, на каком этапе находится его заявка и к кому обращаться дальше. Именно такую роль сыграл "deal structurer" в примере IBM Credit — один человек, ведущий заявку целиком с опорой на объединённую систему инструментов.
Принцип: Информация фиксируется один раз у источника
Данные вводятся один раз тем, кто их производит, и переиспользуются дальше по процессу автоматически — вместо повторного ввода и ручной сверки одних и тех же данных на каждом следующем шаге, как это происходило в отделе оплаты счетов Ford до реинжиниринга.
Ограничения, слепые зоны и критика
Метод в исходном виде игнорирует человеческое измерение изменений. Сам Хаммер в широко цитируемом интервью The Wall Street Journal позже публично признал: "Я недостаточно ценил человеческое измерение. Я усвоил, что это критически важно" — отражая своё инженерное происхождение, он сфокусировался на логике процесса и почти не уделил внимания сопротивлению сотрудников, культуре и коммуникации изменений.
С методом прочно связана статистика "50-70% программ реинжиниринга не достигают заявленных результатов" — но важно понимать её происхождение точно. Сами Хаммер и Чампи в книге 1993 года прямо назвали эту оценку "ненаучной" (unscientific estimate). Два года спустя, в книге "The Reengineering Revolution" (1995, в соавторстве со Стивеном Стэнтоном), Хаммер публично уточнил, что это наблюдение было "искажено и превращено в нормативное утверждение", и добавил: "у реинжиниринга нет присущего ему процента успеха или неудачи". Академическое исследование Марка Хьюза (Journal of Change Management, 2011), проследившее происхождение самых цитируемых версий этой цифры, не нашло достоверных эмпирических данных, которые бы её подтверждали. Использовать эту статистику стоит с осторожностью — как иллюстрацию высокого риска метода, а не как строгий научный факт.
Реинжиниринг рассчитан на процессы, которые действительно сломаны или устарели структурно, как в примерах Ford и IBM Credit — на процессах, которые в целом работают приемлемо, радикальный редизайн создаёт риск и разрушение, несоразмерные возможной выгоде. Метод также плохо совместим с постепенным, низкорисковым стилем изменений — он требует готовности временно дестабилизировать работающий процесс ради кратного результата в будущем, что подходит не каждой организационной культуре и не каждому моменту жизни компании.
Типовые ошибки
Ошибка 1: Реинжиниринг как прикрытие для сокращений.
Компания объявляет "реинжиниринг", а на деле просто сокращает штат в рамках старого процесса — сама логика работы не меняется, экономят только на людях, что и вызвало основную волну критики метода в 1990-х.
Как избежать: Мерить успех показателями самого процесса (цикл, стоимость, качество, сервис), а не числом сокращённых позиций — сокращение штата, если оно случается, должно быть следствием нового процесса, а не его целью.
Ошибка 2: Инкрементальная правка под видом реинжиниринга.
Команда слегка меняет существующий процесс — ускоряет пару шагов, убирает одно согласование — и называет это реинжинирингом, хотя фундаментальный вопрос "зачем мы это делаем" даже не поднимался.
Как избежать: Прежде чем редактировать текущий процесс, явно пройти вопрос "как бы мы спроектировали это с нуля" — если ответ совпадает со старым процессом почти дословно, редизайна не произошло.
Ошибка 3: Автоматизация плохого процесса вместо его пересмотра.
Компания покупает новую систему, которая делает старый неэффективный процесс быстрее, но не меняет саму его логику — именно ошибка, против которой была направлена оригинальная статья Хаммера.
Как избежать: Сначала спроектировать новый процесс, потом подбирать под него технологию — не наоборот.
Ошибка 4: Реинжиниринг всего сразу.
Организация пытается перепроектировать все процессы одновременно — ресурсов и управленческого внимания не хватает ни на один из них, инициатива выдыхается.
Как избежать: Выбрать 1-2 процесса с наибольшим влиянием на клиента и бизнес-результат, довести реинжиниринг до конца на них, только потом переходить к следующим.
Ошибка 5: Отсутствие полномочий пересекать границы отделов.
Команда реинжиниринга подчинена одному функциональному руководителю и не может менять процессы, затрагивающие другие отделы, — редизайн получается половинчатым в границах своей функции.
Как избежать: Обеспечить прямое спонсорство первого лица компании и полномочия команды менять процесс сквозь все затронутые отделы.
Главное, что нужно знать
Реинжиниринг бизнес-процессов — это радикальное перепроектирование процесса с чистого листа ради кратного, а не постепенного улучшения, как показывают классические примеры Ford (400 сотрудников отдела оплаты счетов → 5) и IBM Credit (неделя обработки заявки → 4 часа). Метод оправдан там, где процесс структурно сломан и нужен скачок в разы, а не там, где достаточно точечной оптимизации — для последней лучше подходят кайдзен или обычный проект улучшения. Главный риск метода — использование его как формального прикрытия для сокращений штата без реального пересмотра логики работы, именно это в 1990-х подорвало репутацию реинжиниринга; главное условие успеха — прямые полномочия команды менять процесс сквозь границы отделов, спонсорство первого лица и явный, измеримый целевой результат, зафиксированный до начала работы, а не постфактум.
План внедрения
Месяц 1: выбрать один процесс с наибольшим влиянием на клиента, получить спонсорство первого лица, собрать кросс-функциональную команду с полномочиями менять процесс сквозь отделы.
Месяц 2: зафиксировать болевые точки текущего процесса — ровно настолько, чтобы понять, где реально теряется время/деньги/качество, не увлекаясь подробным картированием ради самого картирования.
Месяц 3: провести редизайн с чистого листа — задать вопрос "как бы мы делали это, если бы начинали сегодня", спроектировать новый процесс, применяя принципы реинжиниринга.
Месяц 4: спроектировать поддерживающую организацию и технологию под новый процесс, подготовить пилотный запуск на ограниченном участке.
Месяц 5: запустить пилот, зафиксировать метрики "было/стало" и убедиться, что улучшение действительно кратное, а не на проценты.
Месяц 6: полностью развернуть новый процесс, провести переобучение сотрудников, управлять сопротивлением явно, не игнорируя его.
Далее: поддержание и обновление — новый процесс должен стать обычной рабочей нормой, а не временным экспериментом, который постепенно откатывается обратно к старому способу работы.
Как реализовать этот план с помощью фрейма «Реинжиниринг бизнес-процессов» в OrgDevTools
Фрейм методики «Реинжиниринг бизнес-процессов» в OrgDevTools собран ровно под шаги плана внедрения выше, а не как абстрактная форма — четыре секции соответствуют четырём ключевым месяцам работы.
Карточка «Болевые точки текущего процесса» — сюда заносятся результаты месяца 2: конкретные проблемы, из-за которых процесс работает плохо (задержки, дублирование, потери на стыках отделов).
Карточка «Новый процесс — с чистого листа» — редизайн из месяца 3: шаги нового процесса, спроектированного заново, а не подправленного старого.
Чек-лист «Применённые принципы реинжиниринга» — шесть классических принципов Хаммера (ориентация на результат, единый ответственный за процесс, фиксация информации один раз у источника и другие) отмечаются по мере того, как они реально заложены в новый дизайн — это самопроверка, что редизайн получился действительно радикальным, а не косметическим.
Таблица «Метрики: было / стало» — заполняется по итогам пилота (месяц 5): кратность улучшения по каждой метрике считается в OrgDevTools автоматически, что сразу видно — достигнут ли кратный результат, ради которого и затевался реинжиниринг, а не разовый процент.
Все данные фрейма автоматически попадают в общий граф связей компании в OrgDevTools — метрики «было/стало» становятся узлами графа с видимым отклонением, а болевые точки и шаги нового процесса — связанными фактами, которые можно увидеть рядом с другими инициативами компании, не только внутри этой рабочей тетради.
