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

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

• Процессы не описаны нигде — знания уходят вместе с сотрудниками. Увольнение одного человека может парализовать целое направление на недели
• Онбординг новичка = «посиди рядом с Петей, он покажет». Нет ни одного документа, по которому человек может разобраться самостоятельно. Срок выхода на полную продуктивность — 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 месяца.

• Вы описали процесс и видите, что можно улучшить, но не можете продвинуть
• «У нас и так работы по горло, не до ваших схемок»
• Руководство просит «показать результат», не давая ресурсов
• Команда воспринимает BPM как бюрократию и угрозу
• Нет единого понимания: что значит «внедрить процессный подход»
• Инициатива держится на одном энтузиасте
• Попытки «внедрить Lean / Agile / ISO» уже были и провалились — скепсис

• Язык цифр: «На пилотном процессе мы нашли X часов потерь в неделю — вот схема»
• Визуализация: Показать as-is схему со всеми петлями и дублированием
• Кейсы: «Компания Y из нашей отрасли сократила цикл на 40%»
• Quick win: «Дайте мне 2 недели и 1 процесс — покажу измеримый результат»
• Риск бездействия: «Каждый месяц промедления стоит нам X»

1. Подготовить бизнес-кейс — конкретные цифры потерь и прогноз улучшения
2. Провести демо-воркшоп — за 2 часа показать руководству пользу на живом примере
3. Найти союзников — определить стейкхолдеров, которым выгодны изменения
4. Показать quick win — оптимизировать пилотный процесс и замерить результат
5. Сформировать команду — 2-4 человека, кто будет двигать тему дальше
6. Договориться о KPI — как будем измерять успех

Смена парадигмы: Ответственность вертикальная — каждый начальник отвечает за свой отдел. Но процесс идёт горизонтально, пересекая отделы.

Что нужно сделать:

• Определить неформального владельца для пилотного процесса
• Сформировать кросс-функциональную команду из представителей отделов
• Получить спонсора на уровне руководства

Типичные роли:

• Спонсор / executive champion
• Драйвер BPM (с частичным выделением времени)
• Неформальный владелец пилотного процесса
• Кросс-функциональная рабочая группа

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

• «BPM — это IT-проект» — если инициативу отдают в IT, бизнес не будет вовлечён. BPM — это БИЗНЕС-инициатива.
• «Сначала купим систему, потом разберёмся» — инструмент без методологии = дорогая игрушка.
• «Мы уже пробовали Lean/ISO — не работает» — BPM дополняет Lean и Agile, а не заменяет.
• «Давайте наймём консультантов» — внешние дадут методологию, но не компетенцию. Растите своих.
• «Руководство сказало “да”» — устное одобрение ≠ реальная поддержка. Нужен бюджет и время.

• ROI пилотного проекта (сэкономленные часы × стоимость часа vs. затраченные ресурсы)
• Количество стейкхолдеров, публично поддержавших инициативу
• Размер выделенного бюджета
• % рабочего времени, формально выделенного BPM-команде

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

• «Пилот дал результат: [конкретные цифры]. Вот план масштабирования»
• «Нужно инвестировать в инструменты и обучение — вот ROI»
• «Без стандартов каждый отдел будет изобретать своё — потеряем время»
• «Результаты симуляции показывают: оптимизация процесса X даст Y% экономии»

1. Анализ процессов (as-is) — детальный разбор 3-5 ключевых процессов с метриками
2. Проектирование (to-be) — как процессы должны работать; использовать симуляцию для валидации
3. Стандарты описания — договориться о нотации, глубине, правилах именования
4. Обучить команду — BPMN-нотация, инструменты, методология анализа
5. Внедрить изменения — поэтапно, с замером до/после
6. Создать базу знаний — репозиторий процессов с описаниями, метриками, ответственными
7. Измерить и отчитаться — конкретные метрики улучшения для руководства

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

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

• Отвечает за end-to-end результат процесса
• Имеет полномочия инициировать изменения
• Не управляет людьми напрямую — координирует участников
• Назначается для 3-5 пилотных процессов

BPM-команда (зародыш процессного офиса):

• Процессный аналитик (2-3 чел.)
• Методолог — стандарты описания и правила
• Драйвер/руководитель — координация и отчётность

• «Описываем только основные процессы» — управленческие и поддерживающие процессы часто являются причиной проблем в основных.
• «BPMN — слишком сложно» — нотация создана для бизнес-пользователей. Если «слишком сложно» — значит, плохо обучили.
• «Описали — внедрили — забыли» — процесс без мониторинга деградирует за 3-6 месяцев.
• «Оптимизируем всё одновременно» — внедряйте изменения по одному процессу.
• «To-be = наша фантазия» — to-be должен быть реалистичным. Используйте DES-симуляцию для проверки.

• Cycle time (время цикла) пилотных процессов: до/после
• Количество ручных переключений между участниками (handoffs)
• % случаев, когда процесс выполнен с первого раза (First Pass Yield)
• Стоимость выполнения процесса (Process Cost)
• Время простоя / ожидания между шагами
• NPS / удовлетворённость внутренних/внешних клиентов процесса

• BPM работает в 1-2 отделах, остальная компания живёт по-старому
• Процессы пересекают границы отделов — на стыках хаос и потери
• «Каждый оптимизировал своё, но целое не стало лучше» (локальная vs. системная оптимизация)
• Потребность в процессной архитектуре: иерархия L0→L1→L2→L3
• Разные команды используют разные инструменты
• Руководство хочет видеть «большую картину» всех процессов
• Политические конфликты: функциональные руководители vs. сквозная ответственность

• «Нам нужна единая процессная архитектура — карта всех процессов компании»
• «Назначение владельцев процессов сократит время принятия решений»
• «Автоматизация повторяющихся операций окупится за N месяцев»
• «Без единой системы разные отделы будут противоречить друг другу»
• «Процессный подход должен стать частью оргструктуры, а не проектом»

1. Построить процессную архитектуру — иерархия всех процессов организации (L0-L3)
2. Назначить владельцев для всех ключевых процессов
3. Создать Процессный офис (BPM CoE) — выделенное подразделение с бюджетом
4. Внедрить единый инструмент — вся организация в одной системе
5. Интегрировать с IT — связать модели процессов с реальными системами
6. Настроить мониторинг — дашборды с метриками процессов
7. Обучить всю организацию — базовая процессная грамотность для всех

Главный сдвиг: Процессное управление становится постоянной функцией в оргструктуре.

Процессный офис / Центр Компетенций BPM (CoE):

• Подчинение: напрямую CEO или COO
• Руководитель процессного офиса
• Процессные аналитики (3-5 чел.)
• Процессный архитектор
• Методолог/тренер

Владельцы процессов (формализованная роль):

• Назначены для всех ключевых процессов
• Включены в KPI
• Имеют формальные полномочия

Организационная трансформация: Переход от функциональной к матричной структуре: вертикаль (отделы) + горизонталь (процессы).

• «Процессный офис = бюрократия» — CoE должен ПОМОГАТЬ подразделениям, а не проверять их.
• «Владелец процесса = ещё один начальник» — роль про КООРДИНАЦИЮ, а не про ВЛАСТЬ.
• «Внедрим BPMS и всё заработает» — автоматизация хаоса = быстрый хаос. Сначала оптимизируйте.
• «Опишем все процессы на L3-L4» — избыточная детализация убивает актуальность.
• «Локальная оптимизация = глобальная» — оптимизация одного отдела может ухудшить общий результат (Theory of Constraints).

• % ключевых процессов, описанных и актуальных
• Количество назначенных владельцев процессов
• Среднее время сквозного процесса (end-to-end cycle time)
• Количество «стыковых» проблем между отделами
• Индекс процессной зрелости организации (CMMI)
• % сотрудников, прошедших базовое обучение

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

• «BPM — не проект с датой окончания, а образ жизни организации»
• «Данные из наших процессов — стратегический актив для принятия решений»
• «Process mining покажет узкие места, которые мы не видим глазами»
• «AI и автоматизация дадут следующий порядок эффективности»
• «Каждый цикл улучшения — это конкурентное преимущество»

1. Регулярный аудит процессов — ежеквартальный пересмотр ключевых процессов
2. Data-driven оптимизация — решения на основе процессных данных
3. Инновационная лаборатория — тестировать AI, RPA, low-code
4. Бенчмаркинг — сравнивать метрики с отраслью
5. Развитие людей — непрерывное обучение, сертификации, конференции
6. Стратегическая связка — процессы как инструмент реализации стратегии
7. Делиться опытом — публиковать кейсы, выступать, строить бренд

Зрелое состояние: Процессное управление — это ДНК организации.

Процессный офис → Стратегическая функция:

• Руководитель — член C-suite (Chief Process Officer)
• Процессная аналитика при стратегических решениях

Процессная культура:

• Любой сотрудник может инициировать улучшение процесса
• Механизмы сбора и реализации предложений по улучшению
• Процессные метрики — часть системы мотивации

Новые роли:

• Process Mining аналитик
• Automation specialist (RPA, AI, low-code)
• Процессный коуч

• «Мы уже зрелые — можно расслабиться» — зрелость требует больше усилий, а не меньше.
• «Process mining всё покажет сам» — данные без интерпретации бесполезны.
• «AI заменит процессных аналитиков» — AI усиливает аналитиков, но не заменяет.
• «Наши процессы лучшие в отрасли» — без бенчмаркинга это самообман.
• «Стратегия — это отдельно, процессы — отдельно» — процессы должны быть инструментом реализации стратегии.

• % процессов, пересмотренных за последний квартал
• Количество инициатив по улучшению от рядовых сотрудников (bottom-up)
• Время от идеи улучшения до внедрения (improvement cycle time)
• ROI от внедрённых улучшений за период
• Индекс процессной зрелости по CMMI (целевой: Level 4-5)
• Количество процессов с подключённым process mining
• % стратегических инициатив, реализованных через процессные изменения