Процессы, которые работают

Введение. История, которая начинается так же, как ваша

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

«Я не понимаю, зачем мы это делаем».
«Нынешний процесс меня вполне устраивает».
«У меня слишком много дел, чтобы заниматься этим прямо сейчас».
«Как это повлияет на мою работу?».

Знакомо? Если да — вы не одиноки. За 20 лет работы на заводах, в логистике и IT я слышал это тысячи раз. И знаете что? Это не нытьё. Это точное отражение реальных страхов.

А вот чего вы, возможно, не замечаете: на каждую открытую жалобу приходится ещё двое молчаливых саботажников. Они делают вид, что работают по-новому, но при первой возможности возвращаются к старым привычкам.

Худшее, что можно сделать — сказать себе: «Они это переживут» или «Это просто обычное нытьё».

Цифра, которую стоит держать в голове:

• Оценки консалтинговых компаний сходятся в одном: большинство программ изменений — от половины до двух третей — не достигают поставленных целей. Точные проценты зависят от методики подсчёта, поэтому не стоит верить одной цифре; важен масштаб проблемы.
• Причина №1 — не технология, не бюджет, а отсутствие управления изменениями (OCM).

Эта книга — не про Visio и BPMN. Она про то, как соединить жёсткое (правильное описание процессов) и мягкое (работа со страхами, политика, быстрые победы).

Я написал её для тех, кто устал от провалов. И кто готов наконец сделать так, чтобы процесс жил, а не пылился на полке.

Часть 1. Анатомия процесса: от хаоса к иерархии

«Если вы не можете описать процесс простыми словами, вы его не понимаете».

Глава 1. Почему нельзя нарисовать процесс одной схемой

Я часто вижу одну и ту же ошибку. Аналитик садится за компьютер, открывает Visio и начинает рисовать одну большую блок-схему. Роли, десятки ромбиков, сотни стрелок. Через три дня получается монстр, который не помещается на экран. При печати на A3 стрелки превращаются в паутину.

Результат: документ, который никто не читает. Потому что он не отвечает ни на один практический вопрос.

Выход — разбить процесс на уровни. Не на два, а на шесть. Каждый уровень для своей аудитории.

Глава 2. Шесть уровней процесса

Я использую классическую иерархию APQC PCF, но адаптированную под реалии заводов и офисов.

Уровень 1. Организация / Функциональная область

Самая верхняя категория. Ответ на вопрос: «Кто в принципе отвечает за эту зону?»

Примеры:

• Финансы
• Производство
• Управление персоналом
• IT
• Продажи

Для кого: CEO, функциональные директора.

Уровень 2. Процессная область (группа процессов)

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

Пример для производственной функции:

• Планирование производства
• Обеспечение материалами
• Производственный контроль

Пример для IT:

• Управление инцидентами
• Управление изменениями
• Управление мощностями

Для кого: руководители среднего звена, владельцы процессов.

Уровень 3. Процесс

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

Примеры:

• «Процесс замены бракованной детали»
• «Процесс найма рабочего на конвейер»
• «Процесс согласования закупки»

Для кого: менеджеры процессов, аналитики.

Уровень 4. Задание (Activity / Sub-process)

Это ключевой уровень для согласования. На нём процесс разбивается на 5–7 крупных этапов. Именно этот уровень попадает в SIPOC.

Пример для процесса «Закрытие наряда на выполнение работ»:

1. Принять наряд от мастера
2. Проверить комплектность
3. Согласовать с кладовщиком
4. Внести в систему
5. Передать в бухгалтерию

Для кого: все участники процесса (для общего понимания).

Уровень 5. Задача (Task)

Каждый этап уровня 4 детализируется в виде блок-схемы (дороги, роли, ветвления). Здесь появляются конкретные роли и условия.

Пример для этапа «Проверить комплектность»:

• Кладовщик сверяет наряд с фактическими остатками → если расхождение >5% → эскалация мастеру → иначе подпись.

Для кого: исполнители, разработчики систем.

Уровень 6. Процедура / Рабочая инструкция (SOP)

Это не «уровень процесса» в строгом BPM-смысле, а обязательное приложение. Процесс отвечает на вопрос «что?», процедура — на вопрос «как именно, на какие кнопки нажимать?».

Пример:
«1. Откройте экран „Складской учёт“ → 2. Нажмите F2 → 3. Введите код материала → 4. Нажмите „Списать“…»

Для кого: новые сотрудники, операторы, технические писатели.

Почему важно не путать уровни

Ошибка, которая убивает внедрение: дать оператору уровень 4 (этапы) без процедур — он скажет «я не знаю, что нажимать». Дать директору уровень 6 — он утонет в деталях.

Правило:

• Руководителю → уровни 1–2
• Владельцу процесса → уровень 3
• Аналитику → уровни 4–5
• Исполнителю → уровень 5 + уровень 6 (процедуры)

Глава 3. Процесс vs процедура: закрепляем на примере

Приготовление пиццы:

Видите разницу? Процесс говорит что. Процедура — как. И они не заменяют друг друга.

Итог части 1: Прежде чем внедрять — опишите процесс на всех уровнях. И никогда не давайте оператору схему с ромбиками без пошаговой инструкции.

Часть 2. SIPOC: ваш первый лист согласования за 90 минут

«Если вы не можете объяснить процесс на одной странице, вы не можете его внедрить».

Глава 4. Что такое SIPOC и откуда он взялся

SIPOC — акроним:

• Suppliers (поставщики) — кто даёт входы
• Inputs (входы) — что нужно для запуска
• Process (процесс) — 5–7 основных этапов
• Outputs (выходы) — что производим
• Customers (клиенты) — кто получает выходы

Инструмент появился в TQM 1980-х, затем стал стандартом Lean Six Sigma. Почему он до сих пор не потерял актуальность? Потому что отвечает на 5 вопросов, которые убивают недопонимание на старте.

Глава 5. Каждый компонент — на примере

Поставщики (S)

Это кто или что предоставляет входные данные. Важно: не путайте поставщика с входом. Поставщик — сущность.

Пример для процесса «Замена бракованной детали на складе»:

• Кладовщик (роль)
• Система учёта (система)
• Смежный процесс «Приёмка материалов» (другой процесс)

Ошибка, которую я исправляю: не включайте в поставщиков роли, которые выполняют процесс. Повар — не поставщик для пиццы, повар — исполнитель.

Входы (I)

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

Процесс (P)

Только уровень 4. Не скатывайтесь в детали. «Позвонить, уточнить адрес, проверить наличие» — это не SIPOC, это блок-схема. В SIPOC это один этап: «Обработать заказ».

Выходы (O)

Конкретные, измеримые продукты или услуги. «Отчёт» — плохо. «Подписанный отчёт с актом сверки» — хорошо.

Клиенты (C)

Тот, кто использует выход. Может быть внутренним или внешним. Важно различать конечного клиента (платит деньги) и промежуточного (следующий процесс). Для SIPOC на высоком уровне указывайте конечного, если это возможно. Иначе указывайте всех, но с пометкой «внутренний».

Глава 6. Приготовление пиццы: правильный SIPOC

Важное примечание: SIPOC не показывает обратную связь (например, клиент вернул пиццу). Для итеративных процессов нужна дополнительная схема. Но для 80% процессов SIPOC достаточно.

Глава 7. Как построить SIPOC за 90 минут (пошагово)

1. Соберите 3–7 человек, кто реально работает в процессе. Без них — не начинайте.
2. Определите границы: где начинается и где заканчивается.
3. Заполните колонку P (4–7 этапов, глаголы).
4. Заполните O и C (выходы и клиенты).
5. Заполните I и S (входы и поставщики).
6. Проверка: каждый вход → поставщик, каждый выход → клиент.

Совет: не делайте SIPOC в одиночку. Это командный инструмент. Если вы нарисовали его один — перерисуйте с командой.

Глава 8. Три главные ценности SIPOC (на основе 100+ проектов)

1. Согласование на старте. Выявляются скрытые поставщики и клиенты, о которых аналитик не подумал.
2. База для улучшений. Пока вы не нарисовали SIPOC, вы не имеете права обсуждать коренные причины проблем (моя любимая цитата от шестисигмовца).
3. Обучение. Новый сотрудник смотрит на SIPOC и понимает: откуда берутся данные, куда идёт результат.

Итог части 2: SIPOC — это не диаграмма, а способ договориться. Используйте его до того, как начнёте детальное моделирование.

Часть 3. Пять шагов к принятию процесса

«Люди не сопротивляются изменениям. Люди сопротивляются тому, чтобы их меняли».

Глава 9. Шаг 1. Коммуникация: начинайте с «Почему»

Самый первый вопрос человека: «Почему?».

Если вы ответите: «Потому что руководство так решило» — сопротивление гарантировано.

Как правильно

Оцените текущее состояние. Проведите короткие интервью (по 15 минут) с 5–10 сотрудниками, которых затронут изменения. Спросите:

• Что вам нравится в текущем процессе?
• Что раздражает?
• Если бы вы могли изменить одну вещь — что бы это было?
• О чём вы беспокоитесь, когда слышите о новых процессах?

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

Принцип Саймона Синека (и моя доработка)

«Люди покупают не то, что вы делаете, а зачем вы это делаете».

Плохая коммуникация: «С понедельника все заявки через новый портал. Инструкция в приложении».

Хорошая коммуникация: «Мы запускаем новый портал заявок, потому что наши клиенты жалуются на долгие ответы. Это наш шанс показать, что мы их слышим. А для вас это значит — вы перестанете терять время на переписки „где моя заявка?“».

WIIFM (What’s In It For Me) — для каждой роли

Политический аспект (важная доработка)

Сопротивление часто идёт не снизу, а сбоку или сверху. Директор склада может бояться потерять влияние, если новый процесс передаст учёт в ERP. Начальник цеха — потерять премию, если KPI станут прозрачными.

Что делать: Составьте карту влияния. Кто формально и неформально влияет на процесс? Поговорите с ними наедине до официального запуска. Найдите их WIIFM — иногда это сохранение статуса, иногда премия за успех пилота. Договоритесь.

Непрерывная коммуникация

Правило: если новостей нет — скажите «новостей нет». Тишина рождает слухи.

Глава 10. Шаг 2. Вовлечение: сделайте их соавторами

Никто не понимает процесс лучше, чем те, кто в нём работает. Если вы не привлечёте их — они будут саботировать.

Совместное моделирование

Соберите 5–7 человек из разных ролей. Дайте стикеры. Попросите каждого нарисовать процесс так, как он его видит. Результат удивит: окажется, что у всех разная картина. Это и есть корень проблем.

Затем вместе нарисуйте SIPOC, разложите по уровням, предложите улучшения.

Феномен: когда люди участвуют в создании, они берут ответственность.

RACI / RASCI как инструмент вовлечения

RASCI (добавляет S — Support):

• Responsible (делает)
• Accountable (отвечает) — один человек
• Support (помогает)
• Consulted (консультирует)
• Informed (информируется)

Создавайте RASCI вместе с командой. Не назначайте роли в кабинете. Обсуждайте. Пусть люди сами скажут: «Я здесь Support, а не Responsible».

Предупреждение: RASCI не работает для процессов с >15 ролями. Для больших — сначала выделите подпроцессы.

Глава 11. Шаг 3. Упрощение: уберите лишнее, автоматизируйте остальное

Вы не сможете внедрить плохой процесс, даже если у вас лучшая в мире коммуникация.

Бережливое совершенствование (Lean) — виды потерь

Классические 7 видов «муда»:

1. Транспортировка
2. Запасы
3. Лишние перемещения (движение людей)
4. Ожидание
5. Перепроизводство
6. Излишняя обработка
7. Дефекты

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

Также помните про мура (неравномерность) и мури (перегрузку). Иногда процесс страдает не от лишних шагов, а от того, что в пятницу заявок в 10 раз больше, чем в понедельник.

Пользовательские истории

Вместо технических требований — истории с точки зрения пользователя:

«Как оператор склада, я хочу видеть остатки на одном экране, чтобы не бегать между системами».

Собирайте их на воркшопах. Они станут основой для автоматизации.

Когда автоматизировать, а когда — нет

Автоматизировать в первую очередь:

• Передачу данных между системами
• Уведомления и эскалации
• Рутинные проверки (формат, заполненность)

Не автоматизировать:

• Творческие задачи
• Сложные решения, требующие контекста
• Коммуникацию с клиентом в нестандартных ситуациях

Золотое правило: сначала оптимизируйте вручную, потом автоматизируйте. Автоматизация плохого процесса сделает его быстро плохим.

Глава 12. Шаг 4. Обучение: не галочка, а погружение

Компании тратят миллионы на ERP, а на обучение выделяют два часа и PDF. Результат — через месяц все возвращаются к старому.

Что должно быть в обучении

1. Почему (повтор коммуникации)
2. Как устроен процесс (уровни 4 и 5)
3. Как мне это делать (уровень 6 — пошаговые инструкции с картинками)

Форматы (минимальный набор)

• Видео 2–3 минуты (обзор)
• Пошаговая инструкция с картинками (PDF или Wiki)
• Живая демонстрация 30 минут
• Песочница / тестовый контур

Just-in-time или перевёрнутый класс?

Для простых процессов — обучение за 2–3 дня до запуска.
Для сложных (например, SAP) — «перевёрнутый класс»: видео за 2 недели, а за 2 дня до запуска — практика в песочнице и ответы на вопросы.

Измерение эффективности

• % сотрудников, прошедших обучение
• Средний балл теста (порог 80%)
• Количество обращений в поддержку в первую неделю (чем меньше, тем лучше)

Глава 13. Шаг 5. Управление: процессы не живут сами по себе

Через полгода после запуска процесс часто превращается в хаос. Почему? Потому что у него не было хозяина.

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

Один человек, который отвечает за метрики и улучшения. У него должны быть полномочия:

• Останавливать процесс, если он не работает
• Менять ресурсы
• Требовать отчёты от смежных подразделений

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

KPI для процесса

Выберите 3–5 измеримых показателей:

Предупреждение: метрики не должны стимулировать плохое поведение. Например, «% заявок, решённых на 1-й линии» может заставить операторов «закрывать» сложные проблемы советами перезагрузить компьютер. Всегда добавляйте метрику качества (например, повторные открытия).

Регулярные обзоры (PDCA)

Раз в квартал собирайте владельца и ключевых участников. Пройдите по циклу:

• Plan — что планировали
• Do — что сделали
• Check — какие метрики, какие отклонения
• Act — корректирующие действия

Итог части 3: пять шагов работают только вместе. Пропустите обучение — процесс умрёт. Пропустите владельца — деградирует.

Часть 4. Управление изменениями: как победить сопротивление

«Культура съедает стратегию на завтрак» — Питер Друкер.

Глава 14. Почему люди сопротивляются на самом деле

Организационная инерция. Компания — как танкер: чтобы развернуть, нужно приложить усилие и время.

Конкретные страхи за маской жалоб:

Ваша задача: услышать страх и адресовать именно его, а не спорить с жалобой.

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

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

Глава 15. Четыре рабочие модели OCM

Модель ADKAR (ProSci)

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

• Awareness — осознаёт необходимость
• Desire — хочет участвовать
• Knowledge — знает как
• Ability — может применять
• Reinforcement — видит закрепление

Если человек знает, но не делает — проблема в Desire. Не учите его, а мотивируйте.

8 шагов Коттера

1. Создайте ощущение срочности — покажите, что теряем деньги/клиентов
2. Сформируйте коалицию — найдите влиятельных сторонников
3. Разработайте видение — чёткую картину будущего
4. Донесите видение до всех — используйте все каналы (это шаг 4, а не «привлечь добровольцев»)
5. Устраните барьеры — избавьтесь от старых систем и правил, которые мешают
6. Обеспечьте быстрые победы — первые результаты за 2–4 недели
7. Набирайте обороты — не останавливайтесь после первых побед
8. Встройте в культуру — сделайте новое поведение нормой

Трёхстадийная модель Левина

• Разморозка — разрушаем старые привычки, создаём готовность
• Переход — внедряем, обучаем, поддерживаем
• Замораживание — закрепляем, делаем нормой

Ошибка: замораживают слишком рано, когда процесс ещё сырой. Не спешите.

Модель 7S McKinsey (как использовать)

Жёсткие элементы: Strategy, Structure, Systems
Мягкие: Skills, Style, Staff, Shared Values

Вопросы для аудита процесса:

• Соответствует ли стиль управления (Style) новому процессу? (Если процесс требует автономии, а стиль — тотального контроля — провал)
• Разделяют ли люди ценности (Shared Values), которые лежат в основе изменений?

Глава 16. Семь принципов, которые работают всегда

1. Объясните «почему» (Синек) — не начинайте с «что» и «как».
2. WIIFM для каждой роли — включая негативную мотивацию («иначе ваш отдел закроют»).
3. Конкретно покажите, как изменится работа — скриншоты, демо, кейсы.
4. Найдите неформальных лидеров — добейтесь их поддержки.
5. Коммуникация непрерывна — даже когда новостей нет.
6. Быстрые победы за 2–4 недели — пилот, одна автоматизированная задача, сокращение времени с 3 дней до 1.
7. Закрепите изменения — свяжите с KPI, удалите старые способы (физически закройте доступ к старым формам).

Глава 17. Сквозной кейс: внедрение управления инцидентами

Исходная ситуация: IT-поддержка тонет в хаосе — заявки в email, WhatsApp, устно. SLA не соблюдается. Потери бизнеса от простоев — 500 тыс. руб./мес.

Шаг 0. Срочность (Коттер шаг 1). Показываем цифры: время решения выросло с 4 ч до 2 дней.

Шаг 1. SIPOC с командой за 90 минут. Выявили, что нет поставщика для диагностики — нужна база знаний.

Шаг 2. Уровни процесса. Прописали уровни 4–5–6. Для приоритизации создали процедуру (SLA: высокий приоритет → 2 часа и т.д.).

Шаг 3. Пять шагов принятия:

• Коммуникация: сессия страхов, WIIFM для пользователей («ваши заявки не потеряются»).
• Вовлечение: назначили двух «чемпионов» из IT.
• Упрощение: убрали двойное логирование (email → Jira вручную), сделали интеграцию.
• Обучение: видео для пользователей, песочница для IT, суперпользователи.
• Управление: владелец — руководитель сервис-деска. KPI: среднее время решения, % повторных открытий (добавлено), соблюдение SLA. Еженедельный разбор просрочек.

Шаг 4. OCM-принципы:

• Быстрая победа: через 2 недели время реакции на высокий приоритет снизилось с 2 ч до 30 мин.
• Закрепление: через 3 месяца автоматическая эскалация при 80% SLA.

Результат через полгода:

• Соблюдение SLA: 40% → 92%
• CSAT: 3,2 → 4,7
• Потерянных заявок: 0

Часть 5. Когда этот подход не работает (честный раздел)

Ни одна книга не должна обещать серебряную пулю. Вот когда описанные методы могут не сработать:

1. Сверхсложные, кросс-функциональные процессы с десятками ролей (например, глобальная цепочка поставок). SIPOC не хватит, нужна архитектура процессов уровня APQC и моделирование в ArchiMate.
2. Отсутствие поддержки на самом верху. Если CEO говорит «да, делайте», но не выделяет ресурсы и не наказывает саботажников — никакой ADKAR не поможет.
3. Токсичная культура «ничего не меняется». Когда три предыдущих проекта провалились, люди перестают верить. Придётся сначала восстановить доверие через серию очень маленьких побед.
4. Жёсткие регуляторные ограничения (например, фармацевтика, авиация). Там процесс должен быть не «удобным», а «аудитируемым». Методы Lean нужно адаптировать.

В этих случаях приглашайте внешнего консультанта (да, я знаю, что это звучит как реклама, но это правда).

Заключение. Ваш личный план действий

Неделя 1. Диагностика

• День 1–2: выберите один самый болезненный процесс.
• День 3: поговорите с 5 людьми, работающими в нём. Спросите о страхах и предложениях.
• День 4: нарисуйте SIPOC с 3–4 участниками за 90 минут.
• День 5: разложите один этап на уровни 5 и 6. Найдите пробелы в процедурах.

Неделя 2. Планирование

• День 1–2: матрица стейкхолдеров (поддержка / нейтрал / против) + их WIIFM.
• День 3: план коммуникации (до, во время, после).
• День 4: назначьте владельца процесса и 3–5 KPI (включите метрику качества).
• День 5: запустите пилот на одной команде или типе заявок. Измерьте результат. Отпразднуйте.

Чек-лист внедрения (повесьте над столом)

До запуска:

• SIPOC согласован с командой
• Процесс описан на уровнях 4 и 5
• Ключевые процедуры (уровень 6) написаны
• Проведены интервью, учтены страхи
• Назначен владелец процесса с полномочиями
• KPI утверждены (включая качество)
• План коммуникации готов
• Обучение проведено, есть суперпользователи

В день запуска:

• Напоминание всем (канал, который точно увидят)
• Горячая линия / чат в первые часы
• Мониторинг первых заявок

После запуска:

• Ежедневные 15-минутки первую неделю
• Еженедельный дайджест с цифрами
• Владелец процесса проводит ежемесячный обзор KPI
• Квартальная ретроспектива с улучшениями

Приложение. Шаблоны, которых вам не хватало

Шаблон SIPOC

Матрица стейкхолдеров (с учётом политики)

План коммуникации (пример)

Метрики успеха внедрения (для вас как руководителя проекта)

• Adoption rate — % сотрудников, реально использующих новый процесс через 4 недели (измеряется по логам системы или опросам).
• Time to stabilize — количество дней от запуска до момента, когда метрики процесса входят в контрольные границы.
• Rework rate — % возвратов на доработку из-за непонимания процесса.

Прощальное слово

Внедрение процессов — это не Visio и не BPM-системы. Это люди. Их страхи, надежды и привычки. И ваше умение соединить жёсткую методологию с мягкой эмпатией.

Большинство проектов внедрения проваливаются. Теперь у вас есть инструменты, чтобы попасть в то меньшинство, у которого получается.

Начинайте с малого. Рисуйте SIPOC. Говорите с людьми. Празднуйте быстрые победы. Закрепляйте изменения.

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

Удачи. Пилите, Шура, пилите.