Путь от хаоса к процессной зрелости

Операционные:

• Процессы не описаны нигде — знания уходят вместе с сотрудниками. Увольнение одного человека может парализовать целое направление на недели
• Онбординг новичка = «посиди рядом с Петей, он покажет». Нет ни одного документа, по которому человек может разобраться самостоятельно. Срок выхода на полную продуктивность — 3–6 месяцев вместо возможных 2–4 недель
• Одна и та же ошибка повторяется раз за разом: пересортица на складе, потеря заявки, неправильный расчёт скидки. Каждый раз «разбираемся», но системно ничего не меняется
• «Тушение пожаров» как основной стиль управления — руководители тратят 60–70% времени на реактивное решение проблем, а не на развитие

Управленческие:

• Руководство принимает решения «на ощущениях» — нет данных, чтобы понять, где именно теряются деньги и время
• Невозможно делегировать: «проще сделать самому, чем объяснять». За этой фразой скрывается отсутствие описанного процесса
• Зависимость от «незаменимых» людей — в каждом отделе есть 1–2 человека, без которых всё встаёт. Это не ценные кадры, это single point of failure
• Попытки описать процессы уже были: в Excel, Visio, Word или даже на флипчарте. Файлы устарели через месяц и лежат мёртвым грузом на корпоративном диске

Клиентские:

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

Лакмусовая бумажка: задайте трём сотрудникам из разных отделов вопрос «как у нас работает процесс [X]?» Если получите три разных ответа — вы на этом этапе.

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

Аргумент 1: Скрытые потери (самый сильный)

«Мы теряем до 30% рабочего времени на переделки, ожидания и согласования — и просто не видим этого. При ФОТ отдела в 5 млн/мес это 1,5 млн/мес, утекающих в никуда. За год — 18 млн рублей. Достаточно описать 2–3 ключевых процесса, чтобы начать это видеть и менять.»

Аргумент 2: Bus factor

«Если завтра [имя ключевого сотрудника] уйдёт, мы потеряем [критичный процесс]. У нас нет ни одного документа, который позволит восстановить его работу. Это не вопрос лояльности — это вопрос управления рисками.»

Аргумент 3: Потолок роста

«Мы не можем масштабироваться, потому что не можем воспроизвести то, что работает. Каждый новый филиал/отдел/сотрудник — это рулетка. Компании с описанными процессами открывают новые точки за 2–3 месяца, мы — за 6–8.»

Аргумент 4: Конкуренты

«[Конкурент X] уже описал свои процессы и масштабируется быстрее нас. Через год разрыв будет критичным. Это не про модную методологию — это про выживание на рынке.»

Как подавать:

• Не проси «внедрить BPM» — проси пилотный проект на 2–4 недели с одним процессом
• Покажи ROI заранее: «Опишем процесс обработки заявок, найдём узкие места, ожидаемый эффект — сокращение цикла на 20–30%»
• Приведи конкретный пример недавнего провала: сорванный дедлайн, потеря клиента, дорогая ошибка — и покажи, что причина в отсутствии описанного процесса
• Не говори «оптимизация» (звучит абстрактно) — говори «прозрачность» и «управляемость»

Шаг 1. Признать проблему (1–2 дня)

Проведите честную сессию с руководством и ключевыми сотрудниками. Задайте три вопроса:

1. «Какие процессы у нас чаще всего ломаются?» — запишите все ответы
2. «Где мы теряем больше всего времени и денег?» — зафиксируйте суммы, даже приблизительные
3. «Что произойдёт, если [ключевой сотрудник] уйдёт завтра?» — это обычно отрезвляет

Результат: список из 5–10 проблемных зон, ранжированный по боли.

Шаг 2. Выбрать один процесс-пилот (1 день)

Критерии выбора:

• ✅ Частый и болезненный — выполняется минимум несколько раз в неделю
• ✅ Понятный — участники могут его описать словами за 5–10 минут
• ✅ Кросс-функциональный — задействует 2–3 отдела (тут больше всего проблем на стыках)
• ❌ НЕ самый сложный — пилот должен быть победой, а не провалом

Хорошие кандидаты: обработка входящей заявки, согласование договора, онбординг нового сотрудника, обработка рекламации, процесс закупки.

Шаг 3. Назначить драйвера (сразу)

Конкретный человек, для которого это не «в нагрузку к основной работе». Идеальный профиль: средний менеджмент, 2–5 лет в компании, понимает боли изнутри, имеет авторитет у коллег. Выделите ему минимум 4–6 часов в неделю на эту задачу.

Шаг 4. Описать as-is — как процесс работает сейчас (3–5 дней)

1. Интервью с участниками (1–2 дня) — поговорите с каждым, кто участвует в процессе. Ключевые вопросы: «Откуда к тебе приходит задача? Что ты с ней делаешь? Кому передаёшь? Где чаще всего застревает? Что бесит?»
2. Нарисовать схему (1 день) — откройте Storm, возьмите шаблон похожего процесса и адаптируйте. Не гонитесь за идеальной нотацией — главное зафиксировать реальный поток работы
3. Валидация (1 день) — покажите схему участникам: «Это правда так работает?» Обычно на этом этапе вскрываются 2–3 неочевидных ответвления и исключения
4. Разметить боли — прямо на схеме отметьте: где задержки, где ошибки, где дублирование работы, где ручной труд вместо автоматизации

Шаг 5. Посчитать потери (1–2 дня)

Для каждой боли на схеме посчитайте:

• Время: сколько часов в неделю теряется на этом участке?
• Деньги: часы × ставку сотрудника = стоимость потерь
• Частота: сколько раз в месяц это происходит?
• Влияние: к чему приводит (срыв сроков, потеря клиента, переделка)?

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

Шаг 6. Презентовать результат руководству (1 день)

Покажите три вещи: схему процесса as-is, карту болей на ней и цифры потерь. Попросите мандат на следующий шаг — оптимизацию этого процесса и описание ещё 2–3 смежных.

Текущая реальность: за процессы не отвечает никто. Каждый отдел — это феодальное княжество со своими правилами. Сквозной процесс (от заявки клиента до отгрузки) — ничей. Когда что-то ломается на стыке отделов, начинается поиск виноватых вместо поиска решений.

Кого искать — драйвер BPM-инициативы:

На этом этапе вам нужен один человек — драйвер. Не консультант, не новый сотрудник, а кто-то изнутри компании. Вот его портрет:

• Уровень: средний менеджмент (руководитель отдела, старший специалист, проджект-менеджер). Линейный сотрудник не имеет рычагов, топ-менеджер — слишком далёк от деталей
• Стаж в компании: 2–5 лет. Меньше — не понимает контекст. Больше — привык к хаосу и не замечает его
• Мотивация: лично страдает от хаоса. Тот, кто разгребает последствия, когда процесс ломается. Ищите среди тех, кто чаще всего говорит «а почему у нас это так работает?!»
• Навыки: умеет разговаривать с людьми из разных отделов, способен визуализировать логику (не обязательно в BPMN — хотя бы на салфетке), доводит дела до конца
• Время: минимум 4–6 часов в неделю. Если «в нагрузку к основной работе» — ничего не получится

Кого ещё вовлечь:

• «Знатоки процесса» — 2–3 человека, которые лучше всех понимают, как что работает на самом деле (не как задумывалось, а как есть). Обычно это люди, к которым все ходят с вопросами
• Спонсор — руководитель уровня директора, который даст мандат и защитит инициативу от «у нас сейчас другие приоритеты». Достаточно 30 минут его времени в неделю

Как мотивировать:

• Не продавайте «BPM» — продавайте решение конкретной боли: «мы наконец перестанем каждый месяц разбираться с пересортицей»
• Покажите, что это временный проект: «нам нужно 2–4 недели, чтобы описать один процесс и показать результат»
• Дайте инструмент, который не требует обучения — Storm Personal бесплатен, работает в браузере, можно начать за 5 минут

Ключевой вопрос этого этапа: «Кто в компании больше всех страдает от хаоса и при этом имеет энергию что-то менять?»

Ловушка 1: «Опишем ВСЕ процессы сразу»

Типичная ошибка амбициозного руководителя. Создаётся комитет, выделяется бюджет, нанимаются консультанты — и через 6 месяцев проект умирает под собственным весом. Почему: объём парализует команду, результат не виден месяцами, люди теряют мотивацию. Что делать: начните с одного процесса. Покажите результат за 2–4 недели. Масштабируйте на основе успеха, а не амбиций.

Ловушка 2: «Начнём с самого сложного процесса»

Логика кажется здравой: «решим главную проблему — остальное приложится». Но на практике сложный процесс = множество участников, политические барьеры, запутанная логика. Пилот проваливается — и вся инициатива BPM дискредитирована. Что делать: выбирайте процесс болезненный, но простой — 5–15 шагов, 2–3 участника, понятный результат. Первая победа важнее первого подвига.

Ловушка 3: «Опишем как ДОЛЖНО быть» (to-be вместо as-is)

Команда рисует «процесс мечты», минуя этап описания реальности. Итог: красивая схема, которая не имеет отношения к тому, как компания работает. Её невозможно внедрить, потому что никто не понимает, что именно нужно менять. Что делать: сначала честный as-is (как работает на самом деле, со всеми костылями), потом — to-be. Разрыв между ними и есть план изменений.

Ловушка 4: «Поручим это стажёру / аналитику без полномочий»

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

Ловушка 5: «Visio / Excel / Word хватит»

Файл на рабочем столе = мёртвый артефакт. Нет совместного доступа, нет версионирования, нет обновлений. Через 2 месяца файл устаревает, через 6 — его невозможно найти. Что делать: используйте живой инструмент с совместным доступом. В Storm процесс всегда актуален, доступен по ссылке и обновляется в реальном времени.

Ловушка 6: «Процессы — это для больших компаний»

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

Без метрик невозможно доказать прогресс. Вот что нужно замерить до начала работы — чтобы через 4–6 недель показать разницу:

Базовые метрики (обязательные):

Качественные индикаторы:

• «А кто знает, как это работает?» — частота таких запросов в неделю. На этапе «Осознание» это 5–10 раз. После описания процесса — стремится к нулю
• Bus factor — количество процессов, которые знает только один человек. Посчитайте честно: если Петя уйдёт, что встанет?
• Повторяющиеся ошибки — одна и та же ошибка третий раз? Значит, процесс не описан или описан плохо
• Время на «тушение пожаров» — попросите руководителей 2 недели записывать, сколько часов они тратят на реактивное решение проблем. Обычно это 50–70% рабочего времени

Как считать ROI на этом этапе:

Формула: (Сэкономленные часы × Ставка часа) − Затраты на описание

Пример: описание одного процесса заняло 40 часов (1 неделя драйвера). Найденные потери — 15 часов/неделю на ручные операции. Ставка часа — 1500 ₽. ROI: 15 × 1500 = 22 500 ₽/неделю экономии = 90 000 ₽/мес. Окупаемость — менее 1 месяца.

Политические:

• Схему as-is посмотрели, похвалили — и ничего не произошло. «Красиво, но сейчас не до этого» — и материалы этапа 1 ложатся на полку
• Руководители отделов не приходят на встречи по сквозному процессу или присылают вместо себя стажёра: процесс ничей, а чужая инициатива на своей территории читается как ревизия
• На планёрке у генерального все кивнули, но на реальной встрече вас встречает перекрёстный допрос: «Вы не знаете наш бизнес — чем вы нам поможете? Только сломаете»
• Инициатива держится на одном энтузиасте: он ушёл в отпуск — тема умерла на две недели

Ресурсные:

• Руководство просит «сначала покажите результат», не давая ни часа выделенного времени и ни рубля бюджета — замкнутый круг
• Устное «да, занимайтесь» есть, но при попытке назначить интервью с участниками процесса выясняется, что «у людей горит квартал»
• Заявка на инструмент вязнет в закупках и ИБ: «заполните опросник на 40 пунктов, вернёмся через два месяца» — хотя речь о сумме меньше одного корпоратива
• Вместо решения вам заказывают всё новые материалы: «подготовьте презентацию для правления» — уже третью за полгода

Культурные:

• Команда воспринимает описание процессов как бюрократию и слежку: «ещё одна бумажка», «теперь каждый шаг будут контролировать»
• Скепсис после прошлых волн изменений: «мы уже внедряли Lean / ISO / CRM — где результат?» Люди не против улучшений — они против очередной кампании
• Нет единого понимания, что такое «внедрить процессный подход»: для одних это регламенты, для других — автоматизация, для третьих — модное слово с конференции

Лакмусовая бумажка: попросите у руководителя 4–6 часов в неделю одного сотрудника и 2 недели на пилот. Если ответ «давайте после квартала» звучит уже второй квартал подряд — вы на этом этапе.

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

Аргумент 1: Потери уже посчитаны — вот они

«На процессе обработки заявок мы нашли 20 часов потерь в неделю: ручной перенос данных, повторные согласования, ожидание. При ставке 2000 ₽/час это ~160 тыс. ₽/мес, ~2 млн ₽/год — на одном процессе. Прошу 2 недели, одного человека на полдня и 30 минут вашего времени в неделю, чтобы начать возвращать эти деньги.»

Аргумент 2: Стоимость промедления

«Каждый месяц, пока мы „возвращаемся к этому после квартала“, компания теряет те же ~160 тыс. ₽. Отложить — это тоже решение, и у него есть цена.»

Аргумент 3: Дешёвый вход

«Пилот почти ничего не стоит: инструмент — от 1500 ₽ за пользователя в месяц, на группу из 5 человек это 7500 ₽/мес. Если команда из 15 человек сэкономит хотя бы по 30 минут в день на согласованиях и поиске актуальных схем, при ставке 1000 ₽/час это ~165 тыс. ₽/мес. Даже если эффект будет втрое меньше — окупаемость кратная.»

Аргумент 4: Риск управляемый

«Это не трансформация на три года. Один процесс, [имя драйвера] отвечает, через 2 недели — цифры на столе. Не сработает — закрываем, потеряв двухнедельный эксперимент, а не бюджет и не лицо.»

Как подавать:

• Встреча — 30 минут: 10 минут на суть, остальное — работа с возражениями. Не уложитесь в 10 минут — потеряете внимание и доверие
• Изучите собеседника заранее: финансисту — цифры и окупаемость, производственнику — конкретика и сроки, без абстракций
• Избегайте слов «оптимизация», «архитектура процессов», «методология» — говорите «деньги», «сроки», «управляемость»
• Заканчивайте фиксацией: «Я верно понимаю, что мы договорились о пилоте? Завтра пришлю план и согласуем контактное лицо»

Шаг 1. Упаковать результаты этапа 1 в бизнес-кейс (2–3 дня)

Одна страница, пять блоков: что нашли (схема as-is + карта болей), сколько теряем (рубли в месяц), что предлагаем (пилот: один процесс, 2–4 недели), что это стоит (часы драйвера + инструмент), когда окупится. Проверка качества: документ читается за 5 минут и отвечает на вопрос «почему сейчас». Расчёт окупаемости прикиньте заранее — хотя бы в ROI-калькуляторе.

Шаг 2. Разведка стейкхолдеров (2–3 дня, параллельно)

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

Шаг 3. Выбрать спонсора и назначить встречу (до 1 недели на календарь)

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

Шаг 4. Провести встречу-питч (30 минут)

Структура: 10 минут — суть (проблема, цифры, предложение, что нужно от него), 20 минут — возражения. Одна схема as-is с размеченными болями работает лучше презентации на 30 слайдов. Финал — явная фиксация: «Мы договорились о пилоте?» Если да — в течение 2–3 дней выйдите на связь с контактным лицом и запустите работу, пока договорённость не остыла.

Шаг 5. Собрать рабочую группу (3–5 дней)

2–4 человека из отделов, через которые проходит пилотный процесс, — не «назначенные сверху», а те, кто на этапе 1 давал самые содержательные интервью. Каждому — личная выгода: «перестанешь по десять раз в неделю отвечать на одни и те же вопросы». С их руководителями договоритесь о конкретных часах, а не о «поучаствует по возможности».

Шаг 6. Согласовать инструмент без тендера (1 неделя)

Не превращайте выбор в полугодовой проект. Сформулируйте 5–7 критических требований под свою задачу (работа в браузере без установки, комментарии и согласование прямо в схеме, реестр процессов, версии), попробуйте на пилотном процессе бесплатно, посчитайте совокупную стоимость на год. Для ИБ и закупок заранее запросите у вендора пакет документов — это экономит два месяца переписки.

Шаг 7. Зафиксировать мандат письменно (1 день)

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

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

Спонсор (executive champion) — главная роль этапа:

• Уровень: директор или зам генерального — тот, кто может дать бюджет и защитить от «у нас другие приоритеты»
• Мотивация: лично выигрывает от пилота — улучшатся его цифры, его KPI. «Идейная поддержка» без личного интереса не переживёт первый конфликт приоритетов
• Признаки хорошего спонсора: спрашивает «когда результат», а не «зачем это»; публично говорит «это важно» на планёрке; открывает двери к смежным отделам. Цена вопроса — 30 минут его времени в неделю
• Сильный кандидат: новый руководитель направления — ему нужно быстро разобраться в наследстве и показать результат к концу испытательного срока

Драйвер — у вас уже есть с этапа 1. Что меняется: время на инициативу должно стать формальным — 4–6 часов в неделю в календаре, согласованные с его руководителем, а не «в нагрузку». Драйвер без формального времени — первый кандидат на выгорание, и инициатива умрёт вместе с его энтузиазмом.

Группа поддержки — 3–5 союзников из разных отделов:

• Ищите тех, кто страдает от текущего процесса сильнее всех — им изменения выгодны лично, их не надо уговаривать
• HR и ИТ — стратегические альянсы: HR даст каналы коммуникации и поможет с обучением, ИТ поддержит по инфраструктуре и приоритетам
• Самые тяжёлые переговоры обычно с финансами и коммерцией — к ним идите в последнюю очередь, подготовленным и с цифрами

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

Ключевой вопрос этапа: «Чьи KPI улучшатся от результатов пилота — и знает ли этот человек о вашей инициативе?»

Ловушка 1: «BPM — это IT-проект»

Инициативу передают в ИТ-департамент — «они же про системы». Почему это провал: ИТ не владеет содержанием процессов и не имеет рычагов менять работу бизнес-подразделений; задача встаёт в общую очередь за CRM и бухгалтерией, а бизнес занимает позицию наблюдателя: «нам сделают». Что делать: держать инициативу на стороне бизнеса, а с ИТ заключить союз: им — понятные требования и стандартный стек, вам — поддержка по инфраструктуре и приоритетам.

Ловушка 2: «Сначала купим систему, потом разберёмся»

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

Ловушка 3: Устное «да» приняли за поддержку

Директор кивнул: «Дело хорошее, занимайтесь». Почему: «да» без бюджета, часов в календаре и даты спроса ничего не стоит — при первом конфликте приоритетов вас отодвинут, и формально никто ничего не нарушит. Что делать: конвертировать согласие в письменный мандат: команда, часы, бюджет, дата презентации результатов. Если фиксировать «неудобно» — поддержки нет.

Ловушка 4: Продавать методологию вместо денег

Питч звучит как доклад: «процессная зрелость», «CBOK», «архитектура процессов». Почему: руководство слышит «дорогая мода» и вежливо ждёт конца встречи — абстракции не выдерживают конкуренции с горящим планом продаж. Что делать: каждое утверждение сводить к деньгам, срокам и рискам. Тест: если фразу нельзя закончить цифрой — вычеркните её.

Ловушка 5: «Наймём консультантов — они внедрят»

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

Ловушка 6: Работать с теми, кто делает вид, что хочет

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

Успех этапа «Продажа» измеряется не количеством схем, а полученным мандатом. Вот что фиксировать:

Качественные индикаторы:

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

Ориентир по конверсии: при должной подготовке — разведка стейкхолдеров, бизнес-кейс на одну страницу, питч в 10 минут — примерно 3 из 4 встреч с руководством заканчиваются согласием на пилот. Если отказов больше, проблема обычно не в идее, а в выборе собеседника или упаковке аргументов.

Методологические:

• Каждый аналитик рисует по-своему: один — в BPMN, второй — блок-схемами, третий — текстом в вики. Свести 15 схем в одну карту процессов невозможно
• Нет правил именования: один и тот же процесс существует как «Обработка заявки», «Заявки клиентов» и «Продажи. Входящие» — три схемы, и непонятно, какая актуальна
• Глубина детализации гуляет: у одного аналитика процесс — 7 блоков, у другого сопоставимый — 70. Читать их рядом невозможно, сравнивать — тем более
• Вопросы «какая нотация, где храним, как версионируем» решаются заново в каждом споре, потому что нигде не записаны

Командные:

• «Мы описали процессы, а дальше что?» — схемы есть, методики анализа нет: команда не умеет находить узкие места, считать стоимость процесса и отличать проблему от нормы
• Знание нотации живёт у одного человека — остальные ходят к нему «проверить стрелочки», а в его отпуск описание останавливается. Учить новичков не по чему: ни стандарта, ни примеров эталонных схем
• Интервью собирают мнения, а не факты: в схемах — «как должно быть по регламенту», а исполнители давно работают иначе, через обходные пути

Управленческие:

• Пилот работает, но остаётся островком порядка в океане хаоса: соседние процессы живут как жили
• Руководство спрашивает «сколько мы сэкономили?» — а метрики «до» никто не зафиксировал, и сравнивать не с чем
• Изменения внедряются «по ощущениям», без проверки гипотез: поменяли процесс — стало хуже, а почему — непонятно
• В схемах путаются типы процессов: основные (создают ценность клиенту), управленческие и поддерживающие свалены в одну кучу — непонятно, с чего начинать оптимизацию

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

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

Аргумент 1: Результат пилота (подставьте свои цифры)

«Пилот дал измеримый результат. Пример: cycle time обработки заявки сократился с 5 до 3,5 дней, переделки — с 12 до 5 случаев в месяц. Семь предотвращённых переделок по ~16 часов при ставке 1 500 ₽/час — это ~170 тыс. ₽ экономии ежемесячно на одном процессе. План — повторить на 3–5 ключевых процессах.»

Аргумент 2: Цена разнобоя

«Без стандартов каждый аналитик рисует по-своему, и схемы придётся переделывать. Переделка одной схемы — 20–40 часов: повторные интервью, перерисовка, пересогласование. На 15 процессах это до 600 часов — квартал работы аналитика, выброшенный в корзину. Соглашение о моделировании занимает два-три дня и снимает проблему до её появления.»

Аргумент 3: Симуляция вместо экспериментов на живых процессах

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

Аргумент 4: Инструменты и обучение окупаются первой же переделкой

«Без версионирования и общего доступа схемы снова расползутся по личным папкам и устареют — как когда-то файлы Visio. Стоимость инструмента — от 1 500 ₽ за пользователя в месяц; одна предотвращённая переделка схемы (30–60 тыс. ₽ времени аналитика) окупает его годовую лицензию.»

Как подавать:

• Не просите «развивать BPM» — просите бюджет под конкретный план: 3–5 процессов за квартал с метриками до/после
• Подпишитесь под цифрами: назовите целевые значения (например, −20–30% cycle time) и дату контрольного замера
• Покажите риск бездействия: без стандартов половину схем придётся переделывать — как в компаниях, где каждый рисовал по-своему
• Говорите «управляемое масштабирование», а не «методология» — второе звучит как расход, первое как контроль

Шаг 1. Зафиксировать соглашение о моделировании (2–3 дня)

Договоритесь и запишите: нотация и рабочее подмножество элементов (15–20 элементов BPMN вместо всей палитры), правила именования (задача = глагол + объект: «Проверить заявку»; процесс — от триггера до результата), уровни детализации и когда какой применять (верхний — 5–7 блоков для руководства, средний — для участников, глубинный — для автоматизации), глоссарий терминов, место хранения и правила версионирования. Не пишите с нуля — возьмите готовый документ «Соглашение о моделировании» и адаптируйте. Результат: стандарт на несколько страниц, который команда приняла, а методолог применяет при ревью каждой схемы.

Шаг 2. Обучить команду (1–2 недели, параллельно с шагом 1)

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

Шаг 3. Проанализировать as-is 3–5 ключевых процессов (2–3 недели)

Интервью по принципу «факты, а не мнения»: вместо «долго ли согласуется договор?» — «покажите последние пять договоров и даты по этапам». Замерьте по 20–30 экземплярам: cycle time, время ожидания между шагами, очереди перед операциями. Помните: узкое место — не там, где тяжело работают, а там, где работа дольше всего ждёт. Результат: схемы as-is с метриками и размеченными узкими местами.

Шаг 4. Спроектировать to-be и проверить симуляцией (1–2 недели на процесс)

Уберите лишние согласования, ручные переносы данных между системами, дублирующиеся шаги. Прогоните целевой процесс через DES-симуляцию: что будет с очередями при пиковой нагрузке, хватит ли людей, где вылезет новое узкое место. Гипотезы, не выдержавшие симуляцию, отбрасываются бесплатно — на модели, а не на клиентах. Результат: to-be, под которым стоят цифры, а не мнения.

Шаг 5. Внедрить поэтапно с замером до/после (2–4 недели на процесс)

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

Шаг 6. Собрать базу знаний процессов (старт 2–3 дня, далее постоянно)

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

Шаг 7. Отчитаться руководству (1 день)

Покажите до/после в деньгах по каждому процессу и план следующего этапа. Это ваш входной билет в масштабирование на всю компанию.

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

Владелец процесса (Process Owner):

• Что делает: отвечает за сквозной результат процесса — от триггера до результата, а не за «свой отдел». Утверждает схему, принимает решения об изменениях, отвечает за метрики
• Полномочия: инициирует изменения в том числе в чужих отделах. Участники процесса ему не подчиняются — он координирует их через мандат руководства
• Как выбрать: тот, кто получает результат процесса или больше всех страдает, когда процесс ломается. Признак ошибки — владелец, который узнал о назначении из приказа и не может назвать ни одной метрики своего процесса
• Сколько: по одному на каждый из 3–5 пилотных процессов; один человек может владеть двумя-тремя процессами, не больше

Процессный аналитик (2–3 человека):

• Что делает: интервью с участниками, схемы as-is и to-be, анализ метрик, симуляции
• Портрет: добывает факты, а не мнения — чаще говорит «покажите», чем «как вы считаете»; аккуратен в деталях; базовый BPMN осваивается за одну-две недели
• Как найти: сначала внутри — участники пилота уже знают контекст и методику. Внешний найм оправдан начиная с третьего-четвёртого аналитика

Методолог:

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

Ключевой вопрос этого этапа: «Можете ли вы для каждого описанного процесса назвать владельца — конкретное имя, а не отдел?»

Ловушка 1: «Сначала опишем все процессы, стандарты подождут»

Самый частый сценарий: команда на энтузиазме описывает 15 процессов за квартал, а потом обнаруживает, что каждый рисовал по-своему, и свести их вместе нельзя. Почему: каждая схема, нарисованная без стандарта, — будущая переделка на 20–40 часов: повторные интервью, перерисовка, пересогласование. И уставшие респонденты, которых второй раз разговорить сложнее. Что делать: соглашение о моделировании — до массового описания. Не пишите с нуля: возьмите готовый документ и адаптируйте за 2–3 дня.

Ловушка 2: «BPMN слишком сложный — будем рисовать как удобно»

Почему: «как удобно» у каждого своё — через полгода вместо единого языка вы получите пять диалектов. При этом BPMN создан для бизнес-пользователей, а в повседневной работе достаточно 15–20 элементов нотации. Если команде «слишком сложно» — проблема в обучении, а не в нотации. Что делать: зафиксируйте в соглашении рабочее подмножество элементов и обучите команду — базовый уровень берётся за одну-две недели.

Ловушка 3: «To-be — это как мы себе представляем идеал»

Почему: целевой процесс, придуманный в переговорке без опоры на as-is и цифры, ломается о реальность: людей не хватает, у нового узкого места вырастает очередь, участники тихо возвращаются к старому порядку. Что делать: to-be выводится из анализа узких мест as-is и проверяется симуляцией до внедрения — прогоните пиковую нагрузку, сезонность, рост объёмов. Что не выдержало проверку на модели, не тащите в жизнь.

Ловушка 4: «Описали — внедрили — забыли»

Почему: без владельца и мониторинга процесс деградирует за 3–6 месяцев: люди возвращаются к старым привычкам, схема расходится с реальностью — и доверие ко всем «этим вашим схемам» падает разом. Что делать: у каждого процесса — владелец и дата пересмотра. Критичные процессы пересматривайте ежеквартально, остальные — раз в полгода.

Ловушка 5: «Оптимизируем все пять процессов одновременно»

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

Ловушка 6: «Рисуем по регламентам — быстрее, чем интервью»

Почему: регламенты устаревают и не содержат обходных путей, которыми реально живёт работа. Схема получается аккуратной, но лживой — и спроектированный на её основе to-be не взлетит. Что делать: регламенты — источник гипотез, не фактов. Основные источники — интервью и наблюдение, с обязательной валидацией у исполнителей: «это правда так работает?»

На этом этапе метрики переходят из разряда «желательно» в «обязательно»: без замера «до/после» победа недоказуема, и мандат на масштабирование вам не дадут. Три термина простыми словами: cycle time — календарное время от старта процесса до результата (заявка «делается» 2 часа, а идёт 5 дней — вот эти 5 дней); First Pass Yield (FPY) — доля случаев, когда процесс прошёл с первого раза, без возвратов и переделок; handoffs — передачи работы из рук в руки, каждая из которых означает очередь, потерю контекста и риск ошибки.

Качественные индикаторы:

• Схемы двух разных аналитиков выглядят как нарисованные одной рукой
• Вопрос «а где последняя версия?» исчез — актуальная схема всегда одна, в реестре
• Руководители сами запрашивают схему процесса перед обсуждением изменений — карта стала рабочим инструментом
• Для любого пилотного процесса владелец называется без запинки — имя, а не отдел

Островки эффективности:

• BPM работает в 1–2 подразделениях, остальная компания живёт по-старому. Оптимизированный отдел упирается в соседей: логистика сократила cycle time на треть, но клиент этого не заметил — заказ по-прежнему застревает на стыке с продажами
• «Каждый оптимизировал своё, но целое не стало лучше» — классический признак локальной оптимизации. Метрики отделов зелёные, сквозной результат для клиента не изменился
• Разные команды описывают процессы в разных инструментах и нотациях: у одних живой репозиторий, у других Visio, у третьих — таблицы. Схемы невозможно связать в единую картину

Конфликты на стыках:

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

Управленческие:

• Руководство просит «большую картину» — карту всех процессов компании, — а показать нечего: есть три десятка разрозненных схем без иерархии и связей
• Назрела потребность в процессной архитектуре: понятно, что нужны уровни от общего ландшафта до детальных схем, но непонятно, как их выстроить, не утонув в деталях
• Функциональные руководители воспринимают процессную инициативу как угрозу полномочиям: «кто здесь начальник — я или какой-то владелец процесса?»

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

На этом этапе вы просите не пилот на 2–4 недели, а полномочия, штат и изменение оргструктуры. Разговор снова ведётся на языке руководства — деньги, риски, инвестиции, — но теперь с козырем: на руках измеренные результаты предыдущих этапов.

Аргумент 1: Деньги, замороженные на стыках (самый сильный)

«Сквозной цикл „заявка → отгрузка“ занимает 12 дней, из них чистая работа — 3 дня: остальное время заказ ждёт в очередях между отделами. Сократим ожидание на стыках вдвое — цикл станет 7–8 дней. При 200 заказах в месяц со средним чеком 500 тыс. рублей ускорение цикла на 4 дня высвобождает ~13 млн рублей, замороженных в незавершённых заказах.»

Аргумент 2: Защита уже сделанных инвестиций

«Мы вложили год в оптимизацию логистики и сократили её внутренний цикл на 35%. Но клиент этого не увидел: заказ по-прежнему теряется на стыке с продажами. Без сквозных процессов эффект от уже вложенных денег съедается на границах отделов.»

Аргумент 3: Управляемость

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

Аргумент 4: Риск отката

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

Как подавать:

• Опирайтесь на цифры пилотов: «вот что дал один отдел — вот что даст организация»
• Не просите «создать процессный офис» абстрактно — просите взять под управление 2–3 сквозных процесса с понятными деньгами на стыках
• Будьте честны про сроки: программа на годы, но с результатом по каждому сквозному процессу ежеквартально
• Заручитесь спонсорством первого лица заранее: конфликты процессной горизонтали с функциональной вертикалью без арбитра наверху не решаются

Шаг 1. Выделить 3–5 сквозных процессов (1–2 недели)

Стройте от клиента, а не от оргструктуры: «заявка → отгрузка», «заказ → деньги», «претензия → решение». Для каждого зафиксируйте границы (первое и последнее событие), результат и отделы, которые он пересекает. Результат шага: согласованный с топ-менеджментом список сквозных процессов, ранжированный по деньгам и боли на стыках.

Шаг 2. Построить архитектуру верхнего уровня и реестр (2–4 недели)

Не начинайте с чистого листа — возьмите готовый отраслевой реестр процессов (Шторм Реестры, APQC PCF) и адаптируйте под компанию. Верхний уровень — 8–12 блоков: основные, поддерживающие, управляющие, развитие. Каждый процесс получает карточку в реестре: владелец, статус, версия, метрики. Детально описываются только приоритетные сквозные процессы — остальные живут на верхнем уровне до своей очереди. Результат: реестр, в котором впервые видна вся компания.

Шаг 3. Назначить владельцев сквозных процессов (2–3 недели)

Четыре вопроса для поиска владельца: кому больше всех нужен результат процесса? У кого KPI совпадают с его целевым результатом? Кто отвечает, если результата нет? У кого достаточно полномочий? Закрепите роль документом: задачи, полномочия, граница ответственности с функциональными руководителями. Если один владелец не выделяется, создайте рабочую группу из руководителей задействованных отделов с аналитиком-координатором и эскалацией споров на общего руководителя.

Шаг 4. Создать процессный офис (1–2 месяца)

Стартовый состав: руководитель, процессный архитектор, 1–2 аналитика. Подчинение — напрямую генеральному или операционному директору: офис внутри IT, HR или службы качества перекашивается в специфику «родного» подразделения. Ключевой принцип: офис отвечает за методологию, обучение и целостность архитектуры, но не описывает процессы вместо владельцев. Результат: работающий центр компетенций и утверждённые правила игры.

Шаг 5. Поставить KPI на стыки (2–4 недели)

Замерьте сквозной cycle time — от первого события до результата для клиента, по датам в учётных системах. Отдельно посчитайте, сколько времени заказ лежит между отделами. Введите SLA на передачи и сбалансируйте мотивацию: процессные KPI работают как стоп-фактор — при проваленном сквозном результате премия за локальные показатели выплачивается не полностью. Результат: у отделов впервые появляется общий счёт.

Шаг 6. Связать процессы с оргструктурой и единым инструментом (2–3 недели, далее постоянно)

Каждая задача на схеме получает роль, роль связывается с должностью, должность — с сотрудником: на вопрос «кто это делает?» отвечает система, а не память старожилов. Переведите все команды в единый репозиторий — зоопарк инструментов по отделам разваливает архитектуру. Запустите базовое обучение: руководители и участники ключевых процессов должны читать схемы и видеть свой участок в сквозной цепочке.

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

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

• Кто это: руководитель уровня топ-менеджмента или на ступень ниже, которому больше всех нужен результат процесса целиком. Роль про координацию и сквозной результат, а не «ещё один начальник»
• За что отвечает: границы, целевые метрики, анализ и улучшения, согласование изменений между отделами. Проверка простая: если владелец назначен, а границ, метрик и предложений по улучшениям нет — владельца фактически нет
• Граница с функциональным руководителем: владелец задаёт «что и к какому сроку» (например: «все договоры согласуются за 5 дней»), функциональный руководитель решает «как и кем» — ресурсы, компетенции, качество на своём участке. Разногласия выносятся на процессный комитет
• Если один владелец не выделяется — рабочая группа руководителей задействованных отделов плюс сильный аналитик-координатор, спорные вопросы эскалируются общему руководителю

Процессный офис (центр компетенций BPM):

• Состав на старте: руководитель, процессный архитектор, 1–2 аналитика; по мере роста — методолог-тренер и до 3–5 аналитиков
• Подчинение: напрямую первому лицу — офис внутри IT, HR или службы качества смещает приоритеты в пользу «родного» подразделения
• Роль — сервисная: методология, обучение, аудит архитектуры, поддержка владельцев. Офис, который описывает процессы вместо подразделений, становится узким местом; офис, который только проверяет, — врагом

Спонсор уровня первого лица:

• Спонсора «уровня директора», которого хватало на пилотах, уже недостаточно: перераспределяются полномочия и премии — такое утверждает только генеральный директор или собственник
• Его рабочая функция — арбитраж: спор владельца сквозного процесса с функциональным руководителем решается у него за дни, а не зависает на месяцы

Ключевой вопрос этапа: «Готово ли первое лицо лично разбирать конфликты между процессной горизонталью и функциональной вертикалью?» Если нет — масштабирование лучше отложить, чем провалить.

Ловушка 1: «Процессный офис = отдел контроля»

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

Ловушка 2: «Владельцы процессов = руководители отделов, автоматически»

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

Ловушка 3: «Опишем все процессы до уровня операций»

Амбициозный план: вся компания в детальных схемах до последней кнопки. Почему: детализация растёт быстрее, чем способность её поддерживать, — через полгода половина схем устареет, и вместе с ней умрёт доверие ко всему репозиторию. Что делать: верхний уровень — 8–12 блоков; глубоко описывать только приоритетные сквозные процессы — по необходимости, а не по плану «описать всё».

Ловушка 4: «Оптимизируем каждый отдел — оптимизируется целое»

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

Ловушка 5: «Купим BPMS — и всё заработает само»

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

Ловушка 6: «BPM живёт отдельно от систем компании»

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

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

Базовые метрики (обязательные):

Качественные индикаторы:

• «Это не наш процесс» — частота этой фразы на разборах. Чем ближе к нулю, тем живее институт владельцев
• Спор двух отделов решается за одну встречу со схемой сквозного процесса — или за две недели взаимной переписки?
• Руководство пользуется реестром: топ-менеджеры смотрят статусы и метрики в системе, а не заказывают презентации «о состоянии процессов»
• Изменения начинаются со схемы: перед реорганизацией или автоматизацией сначала обновляется модель процесса — признак, что архитектура стала рабочим инструментом, а не артефактом

Признаки зрелости (вы действительно на этапе 5, если):

• Репозиторий покрывает ключевые сквозные процессы, у каждой схемы есть владелец, новички учатся по схемам, а не «посидев рядом с Петей»
• Метрики процессов собираются автоматически и выведены на дашборды; SLA закреплены и в основном соблюдаются
• Изменения обсуждаются «на схеме»: у команды единый язык, спорят о фактах, а не о том, «как у нас вообще это работает»

Ранние признаки деградации (она уже началась, если):

• Часть описаний устарела: процесс давно выполняется по-другому, а схему никто не обновил. Замечают это обычно не владельцы, а новички, которые честно пробуют работать «по документации»
• Новые продукты и направления запускаются «мимо» процессной архитектуры — договориться в чате быстрее, чем провести изменение через репозиторий
• Дашборды открывают перед отчётом, а не для решений: на отклонение метрики никто не реагирует, пороги не пересматривались с момента настройки
• Команда расслабилась: «мы уже зрелые», ревью процессов переносятся, процессный офис занят поддержкой, а не развитием

Признаки упущенного потенциала:

• «Мы оптимизировали всё очевидное — где следующий рывок?» — низко висящие фрукты собраны, а данных для неочевидных улучшений никто не копит
• Процессные данные не участвуют в стратегических решениях: стратегия обсуждается отдельно, процессы живут отдельно
• AI, process mining, симуляции — «слышали, но непонятно, как применить у нас»

Лакмусовая бумажка: откройте 10 случайных схем из репозитория и спросите владельцев: «Это правда так работает сегодня?» Если хотя бы на три схемы ответ «ну, почти» — деградация уже идёт, просто её пока не измеряют.

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

Аргумент 1: Не режьте то, что работает

«Процессная система — как информационная безопасность: пока она работает, кажется, что она не нужна. Без поддержки процессы деградируют за 6–12 месяцев, и мы откатимся на уровень, в который уже вложили деньги. Посчитаем: процессный офис из 3 человек при ФОТ 200 тыс./мес на человека — это 7,2 млн ₽/год. Повторный проект восстановления — те же деньги на консультантов и внутренние ресурсы плюс 6–9 месяцев потерянного темпа. Поддержка всегда дешевле реанимации.»

Аргумент 2: Данные уже накоплены — пора получать с них отдачу

«За время работы системы мы накопили процессные данные: реальные длительности, очереди, возвраты. Используем мы их на малую долю. Перевод метрик в деньги показывает, где утекает маржа: если согласование договора занимает 6 дней вместо целевых 3, каждый лишний день — это отложенная выручка по каждому контракту. Потери уже измеримы — осталось начать на них системно реагировать.»

Аргумент 3: Репозиторий процессов — готовая база для AI

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

Аргумент 4: Цена самоуспокоенности

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

Как подавать:

• Не просите «сохранить бюджет» абстрактно — покажите 3–5 улучшений за последний год с эффектом в деньгах
• Говорите не «поддержка», а «защита инвестиций» и «отдача с данных»
• Следующий уровень предлагайте как пилот: одна AI-инициатива или одна симуляция изменения с измеримым результатом за квартал

На этапе 5 действия — это не проект с началом и концом, а ритм. У каждой практики есть частота, владелец и проверяемый результат.

Практика 1. Аудит актуальности репозитория (ежеквартально)

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

Практика 2. Цикл непрерывного совершенствования (операционное ревью раз в 1–3 месяца)

Классический PDCA, замкнутый на данные: зафиксируйте базовую линию метрик до изменения → внедрите → сравнивайте тренд, а не точку (разовый скачок — случайность, устойчивая динамика — результат) → закрепите успешное. Раз в 1–3 месяца — операционное ревью ключевых показателей с обязательными решениями: так устроен обзор метрик разработки в Т-Банке. Отдельно ловите «ложные успехи»: среднее время обработки упало, а доля возвратов на доработку выросла — это не оптимизация, а перекладывание проблемы.

Практика 3. Живой мониторинг KPI (ежедневно или еженедельно — по скорости процесса)

Для каждого ключевого процесса — 5–7 метрик: время цикла, длительность этапов, очереди между шагами, доля возвратов, соблюдение SLA. У каждой метрики — три порога (норма / предупреждение / критично), автоматический алерт и владелец, отвечающий за реакцию. Смысл мониторинга — увидеть отклонение до того, как оно станет инцидентом, а не зафиксировать постфактум в отчёте.

Практика 4. Процессные данные как актив (разбор раз в квартал)

Переводите отклонения в деньги: согласование идёт 6 дней вместо целевых 3 — посчитайте стоимость каждого лишнего дня в отложенной выручке. Помните физику очередей: при загрузке ресурса выше ~70% задержки растут нелинейно — узкие места ищите по загрузке, а не «на глаз» по диаграмме. Перед крупными изменениями прогоняйте сценарии через имитационное моделирование (DES): что будет с очередями, если добавить сотрудника, изменить график, автоматизировать шаг — до того, как потратите деньги.

Практика 5. Управляемые изменения (по каждому изменению)

Значимое изменение процесса — мини-проект с одним и тем же маршрутом: to-be-схема → согласование с владельцем и участниками → внедрение → контрольная точка через 4–8 недель со сравнением метрик «до/после». Описать не означает внедрить: изменение закрыто не когда обновили схему, а когда метрики подтвердили эффект.

Практика 6. AI-оптимизация (один пилот в квартал)

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

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

Зрелый процессный офис:

• Подчиняется первому лицу (генеральному директору или совету директоров), а не ИТ- или операционному директору — иначе неизбежен перекос в сторону одного направления
• Занимается развитием, а не только поддержкой: методология, аудит актуальности, обучение владельцев, пилоты новых практик — симуляции, AI
• Отвечает за доверие к процессным данным: валидирует метрики, следит за полнотой. Метрики, которым не доверяют, никто не использует для управления — и вся система превращается в декорацию

Владельцы процессов с реальными KPI:

Владелец — не строчка в паспорте процесса. Работает только полная тетрада: ответственность + полномочия + ресурсы + мотивация. Уберите любой компонент — роль станет формальной. Метрики процесса входят в систему мотивации владельца; он отвечает за актуальность схемы, интерпретацию отклонений и корректирующие действия по ним.

Процессная культура — каждый сотрудник:

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

Новые компетенции (не обязательно новые люди): аналитик процессных данных — интерпретирует метрики и находит закономерности; специалист по автоматизации и AI — превращает находки в изменения. В средней компании это чаще роли внутри процессного офиса, чем отдельные ставки.

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

Ловушка 1: «Мы уже зрелые — можно расслабиться»

Самая дорогая ловушка этапа: зрелость воспринимается как статус, хотя это скорость — скорость, с которой система обновляется вслед за реальностью. Почему: энтропия работает без выходных: люди меняются, продукты запускаются, схемы устаревают. Без ритма поддержки система деградирует за 6–12 месяцев, и инвестиции этапов 1–4 обнуляются. Что делать: закрепить ритм (квартальный аудит актуальности, операционные ревью) как обязательный, а не «когда будет время»; сделать актуальность репозитория измеряемым KPI процессного офиса.

Ловушка 2: «Дашборды есть — никто не смотрит»

Метрики собираются, панели красивые, но решения по ним не принимаются. Почему: метрика без владельца, порогов и обязательной реакции — это обои. Добавьте «ложные успехи»: показатель улучшается, а пользы нет — среднее время обработки упало, зато выросла доля возвратов на доработку. Что делать: у каждой метрики — владелец и три порога (норма / предупреждение / критично); выход за порог означает действие, а не пометку в отчёте; связанные KPI анализировать вместе, а не радоваться каждому по отдельности.

Ловушка 3: «Изменения без управления изменениями»

Новый продукт запустили, оргструктуру перекроили — а процессная архитектура «узнала» об этом через полгода. Почему: на этом этапе изменение процесса — уже не «поправить схему», а мини-проект: есть участники, риски и эффект, который нужно проверить. Описать не означает внедрить. Что делать: единый маршрут любого изменения — to-be-схема → согласование → внедрение → контрольная точка по метрикам «до/после»; версионирование схем, чтобы всегда было видно, что и когда менялось.

Ловушка 4: «Оптимизируем то, что легко измерить»

Почему: удобная метрика — не значит важная. Команда полирует показатели, которые проще собрать, а реальные проблемы — очереди между отделами, возвраты, простои на стыках — остаются в тени. Что делать: выводить метрики из бизнес-целей: 3–5 стратегических KPI, каскадированных до операционных, а не «что было в выгрузке». И не менять KPI по пять раз в год — сотрудники перестают в них верить и понимать, как их достигать.

Ловушка 5: «AI подождёт» — или наоборот, «AI всё сделает сам»

Две крайности с одинаковым итогом. Почему: «подождём» — конкурент, подключивший AI к процессным данным, наращивает скорость оптимизации, и догонять с каждым кварталом дороже. «Сделает сам» — данные без интерпретации бесполезны: AI усиливает процессного аналитика, но не заменяет его. Что делать: пилоты с измеримой целью — анализ схем, поиск узких мест, подготовка изменений. Ваш описанный репозиторий — готовый контекст для LLM; у тех, кто процессы не описал, этого преимущества просто нет.

На этом этапе измеряются не только сами процессы, но и здоровье системы управления ими — её «пульс». Именно эти метрики показывают, идёт эволюция или тихая деградация:

Качественные индикаторы:

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

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