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

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

Почему нельзя начинать с «оптимизируем всё»

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

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

Признаки: как понять, что процесс сбоит

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

• Повторяющиеся ошибки одного типа. Если менеджеры регулярно путают версии договоров, логисты отправляют не те партии, а бухгалтерия каждый месяц пересчитывает одни и те же расхождения — процесс не предусматривает защиту от ошибки (пока-йоке) или ответственность размыта.
• Ручные обходные пути (workarounds). Сотрудники ведут параллельные таблицы в Excel, дублируют данные в мессенджерах, хранят «свои» версии шаблонов. Это значит, что официальный процесс не удобен или не покрывает реальные сценарии.
• Длительное время цикла без очевидной причины. Заявка висит в статусе «на согласовании» 3 дня, хотя сами согласующие тратят по 15 минут. Причина — в очереди, в отсутствии SLA, в неясных критериях принятия решения.
• Высокая доля переработок и возвратов. Производство переделывает 15% продукции, поддержка переоткрывает 30% тикетов, продажи перевыставляют счета. Каждый возврат — удвоенные затраты на тот же этап.
• Жалобы клиентов на одно и то же. «Долго жду ответа», «пришло не то», «никто не перезвонил» — если тема повторяется, проблема в процессе, а не в конкретном сотруднике.
• Рост затрат при статичном объёме. Обработка одного заказа стоит дороже в этом квартале, чем в прошлом, хотя объём не вырос. Часто это признак накопленного технического долга в процессе: лишние согласования, дублирование проверок, ручная работа там, где давно можно автоматизировать.

Соберите такие сигналы минимум за 2–3 недели. Просите руководителей направлений прислать «топ-3 боли, которые едят время команды». Это даст исходный список кандидатов на оптимизацию.

Методы выявления: от быстрой диагностики к глубокому анализу

Выбор метода зависит от масштаба задачи и доступных ресурсов. Часто лучше начать с лёгкого формата, а потом углубиться в проблемные зоны.

1. Прогулка по процессу (Gemba walk) — 1–2 дня

Лидер или аналитик физически проходит путь заявки/заказа/документа от входа до выхода. Не по схеме в Visio, а по факту: садится рядом с сотрудником, смотрит, как он работает в системе, какие окна открывает, куда звонит, какие бумажки держит в руках. Цель — увидеть реальные действия, а не описанные в регламенте. Записывайте: время на операцию, ожидания, переключения контекста, ручные переносы данных, моменты неопределённости («а куда теперь нажать?»).

2. Интервью с исполнителями — 3–5 дней

Короткие беседы (20–30 мин) с людьми, которые процесс выполняют каждый день. Вопросы: «Какой шаг самый долгий?», «Где чаще всего ошибаетесь?», «Что бы вы убрали в первую очередь?», «Какие исключения не описаны в инструкции?». Важно: не спрашивайте «как улучшить?» — исполнители часто предлагают локальные удобства, а не системные изменения. Спрашивайте о боли и фактах.

3. Анализ данных по воронке процесса — 1–2 недели

Если процесс оцифрован (CRM, ERP, BPM, трекер задач), выгрузите метрики за 3–6 месяцев:
Lead time (общее время от входа до выхода), Cycle time (чистое время работы без ожиданий), Rework rate (доля возвратов на предыдущие этапы), Bottleneck stage (этап с наибольшим накоплением WIP — work in progress), First pass yield (доля единиц, прошедших без возвратов с первого раза). Столбчатая диаграмма по этапам сразу покажет, где «застревает» поток.

4. Value Stream Mapping (Карта потока создания ценности) — 1–2 недели

Полноценная визуализация текущего состояния (Current State Map) с указанием времени цикла, времени ожидания, % качественного прохождения, количества людей и систем на каждом этапе. Потом рисуется целевое состояние (Future State Map). Метод даёт системную картину, но требует подготовки модератора и вовлечения заинтересованных сторон. Для первой волны оптимизации часто избыточен — начните с пунктов 1–3.

Критерии приоритизации: что брать в работу первой

Список кандидатов обычно получается длинным. Используйте матрицу приоритизации по двум осям: Влияние на бизнес-метрику (высокое/среднее/низкое) и Усилия на изменение (низкие/средние/высокие). В первую очередь берите квадрант «Высокое влияние — Низкие усилия» (Quick wins). Примеры: убрать лишнее согласование, настроить авторассылку вместо ручного уведомления, внедрить чек-лист на этапе с высоким rework rate.

Дополнительные фильтры для принятия решения:

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

Пример простой таблицы оценки

Процесс	Влияние на выручку/маржу/СLA	Трудозатраты на изменение (чел.-дни)	Частота (раз/мес)	Риск бездействия	Приоритет
Согласование договора	Высокое (скорость сделки)	15 (автоматизация маршрута)	120	Потеря сделок, риск комплаенса	1 — Quick win
Месячный закрытый период	Среднее (срок отчётности)	60 (переработка шаблонов, RPA)	1	Штрафы, стресс команды	2 — Проект
Закупка канцелярии	Низкое	5 (каталог в ERP)	30	Минимальный	3 — Отложить

Такой расчёт занимает час, но снимает споры «что важнее» на уровне ощущений.

Типичные ошибки при выборе процессов для оптимизации

• Оптимизация локального оптимума. Ускоряют этап, который не является бутылочным горлышком. Результат: накопление WIP перед следующим этапом, общий lead time не меняется. Всегда ищите constraint (ограничение) по Теории ограничений Голдратта.
• Автоматизация хаоса. Накидывают RPA/BPM/low-code на процесс, где нет чётких правил, есть исключения «на усмотрение менеджера», данные грязные. Получают быстрый робот, который быстро производит ошибки. Сначала — стандарт и чистка данных, потом — автоматизация.
• Игнорирование «теневых» процессов. Официальная схема красивая, а реальная работа идёт в чатах, почте, устных договорилочках. Оптимизируя официальную схему, вы не трогаете 70% реальной нагрузки. Всегда проверяйте: «А как на самом деле?»
• Отсутствие базовых метрик до старта. Начали менять, через месяц не могут доказать, что стало лучше. Зафиксируйте baseline (текущие значения lead time, rework, стоимость операции) до любого вмешательства.
• Попытка сделать «идеально» с первого раза. Перфекционизм убивает пилоты. Запускайте MVP процесса: минимально рабочую версию, соберите обратную связь за 2 недели, итерируйте.

Пошаговый алгоритм: от списка боли к плану пилотов

1. Соберите «длинный список» кандидатов. Опрос руководителей + анализ инцидентов/жалоб + данные по метрикам за полгода. Цель — 15–30 процессов.
2. Проведите экспресс-оценку по матрице Влияние/Усилия. Отсеките явные «низкое влияние / высокие усилия». Останется 5–8 кандидатов.
3. Сделайте Gemba walk или быстрые интервью по каждому кандидату. 1–2 часа на процесс. Подтвердите или опровергните гипотезу о проблеме. Часто оказывается, что «проблема в согласовании» — на самом деле проблема в качестве входящих данных от продаж.
4. Рассчитайте потенциальный эффект в деньгах/часах. Формула: (текущий lead time — целевой) × частота × стоимость часа ожидания/простоя. Или: реворк% × объём × стоимость переработки. Цифры не должны быть точными до копейки, но порядок величины нужен для обоснования ресурсов.
5. Выберите 1–2 пилота. Критерии: высокий эффект, низкие усилия, лояльный спонсор, измеримый результат за 2–4 недели.
6. Определите команду пилота и метрики успеха. Не «улучшить процесс», а «сократить цикл согласования договора с 4 дней до 1.5 дня при сохранении % ошибок ≤ 2%».
7. Запустите, измеряйте, итерируйте. Ежедневные стендапы 10 минут, ретроспектива по итогам спринта (2 недели). Документируйте изменения в регламенте только после стабилизации.
8. Масштабируйте практику. Успешный пилот становится кейсом для следующего процесса. Создайте внутреннюю базу знаний: «Как мы оптимизировали X, какие грабли были, какой шаблон регламента получился».

Сценарии: как действовать в типичных ситуациях

Сценарий А: «У нас нет времени на анализ, горят дедлайны»

Возьмите один самый болевой процесс (по жалобам клиентов или переработкам). Проведите 2-часовый Gemba walk с ключевым исполнителем. Найдите 1–2 очевидных муды (ожидание, лишнее движение, переработка). Уберите их «вручную» (чек-лист, уведомление, удаление лишнего согласующего). Замерьте результат через неделю. Это даст быструю победу и мандат на системную работу.

Сценарий Б: «Процессы не описаны, все работают по-разному»

Не начинайте с написания регламентов «вообще для всех». Выберите 3–5 самых частых сценариев (80% объёма по Парето). Опишите только их — минимально, визуально (схема + таблица RACI). Внедрите через чек-листы в трекере. Остальные сценарии — «как есть» до следующего круга.

Сценарий В: «Топ-менеджмент хочет цифровизацию, а процессы сырой»

Проведите аудит зрелости процессов по простой шкале: 1 — хаос, 2 — есть практики, 3 — описано, 4 — измеряется, 5 — оптимизируется. Цифровизация (BPM, RPA, AI) эффективно накладывается только на уровни 3–4. На 1–2 уровне сначала выводите процессы на 3-й: стандарт, ответственный, метрика. Представьте руководству дорожную карту: «Сначала 3 месяца выводим на уровень 3, потом автоматизируем».

Как проверить, что оптимизация сработала

Не ждите квартального отчёта. Введите операционный контроль:

• Ежедневно/по смене: WIP на этапах (визуальная доска или дашборд), количество возвратов на вход.
• Еженедельно: средний cycle time за неделю, % выполнения SLA, количество инцидентов «не по процессу».
• Ежемесячно: lead time end-to-end, стоимость операции (операционные затраты / объём), eNPS команды по процессу (анонимный опрос: «Насколько удобно работать?»).

Если через 2–3 недели после изменений метрики не сдвинулись или ухудшились — откатитесь, разберитесь, итерируйте. Оптимизация — это цикл PDCA (Plan-Do-Check-Act), а не разовый проект.

Что делать дальше: чек-лист для старта на этой неделе

1. Попросите 3–5 руководителей направлений прислать по 3 главные боли в текущих процессах (формат: «Что болит», «Как часто», «Что ломается»).
2. Соберите единый список, сгруппируйте по процессам.
3. Для топ-5 по частоте упоминаний проверьте данные в системе за последние 3 месяца (lead time, rework, объём).
4. Проведите 2 Gemba walk по самым «больным» процессам.
5. Заполните матрицу приоритизации (Влияние/Усилия) и выберите 1 пилот.
6. Назначьте владельца пилота, согласуйте метрику успеха и дедлайн первого замер (2 недели).

Часто задаваемые вопросы

Нужно ли нанимать внешнего консультанта для аудита процессов?

Не обязательно. Внутренние аналитики или заинтересованные руководители, прошедшие базовое обучение (Lean, Six Sigma Yellow Belt, BPMN), способны провести диагностику уровня «найти быстрые победы и составить бэклог». Консультант полезен, когда: нужен независимый взгляд на системные проблемы, команда застряла на конфликте интересов, требуется методология для масштабной трансформации (внедрение end-to-end процессов по всей компании). Начните сами — вы лучше знаете контекст.

Как отличить проблему процесса от проблемы человека?

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

Стоит ли оптимизировать процессы, которые скоро автоматизируем/заменим системой?

Если внедрение системы подтверждено, закуплено и начнётся через 1–2 месяца — оптимизируйте только критические риски (безопасность, комплаенс, клиентская боль). Остальное — ждите, настраивайте систему под нормальный процесс. Если система «в планах на год» — оптимизируйте сейчас, эффект накопится за месяцы ожидания, а чистый процесс упростит внедрение.

Как работать с процессами, завязанными на подрядчиках/партнёрах?

Включите их в карту процесса как отдельный пул (swimlane). Замеряйте их SLA так же, как внутренние этапы. В контракте пропишите штрафы/бонусы за метрики процесса (время ответа, качество входящих данных), а не только за итоговый результат. Проводите совместные ретроспективы раз в квартал.

Какие инструменты нужны для старта — Excel достаточно?

Для диагностики и пилотов — да, Excel/Google Sheets + Miro/диаграммы в Visio/draw.io + трекер задач (Jira, YouTrack, Яндекс.Трекер) достаточно. Специализированный BPM/Process Mining (Celonis, UiPath Process Mining, ELMA, Bitrix24 процессы) нужен, когда: процессов под контролем > 50, нужна непрерывная аналитика по логам систем, есть команда процессных инженеров. Не покупайте инструмент до того, как выработаете привычку управлять процессами.

Материал носит информационный характер и не заменяет экспертизу по управлению операциями, изменению бизнес-процессов или внедрению систем автоматизации. При принятии решений, влияющих на финансовые результаты, соблюдение регуляторных требований или безопасность персонала, привлекайте квалифицированных специалистов и проводите независимую оценку рисков.

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

Начните с одной конкретной боли, подтверждённой данными и людьми на месте. Уберите одно лишнее согласование, автоматизируйте один ручной перенос данных, введите один чек-лист на этапе с высоким реворком. Измерьте. Если сработало — повторите. Если нет — разберитесь и скорректируйте. Системная зрелость процессами растёт не от принятия стандарта ISO, а от сотен таких маленьких циклов улучшения, запущенных туда, где реально болит.