Как находить операционные потери в ежедневной работе подразделений: практическое руководство

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

Содержание
  1. Что считать операционными потерями в офисной и сервисной среде
  2. Три основных источника данных о потерях
  3. 1. Гемба-уок (наблюдение на месте)
  4. 2. Анализ цифровых следов (process mining / лог-анализ)
  5. 3. Структурированные интервью и самооценка команд
  6. Пошаговый алгоритм поиска потерь в подразделении
  7. Типичные слепые зоны: где потери не видны даже внимательным руководителям
  8. Приоритизация: что устранять первой, а что оставить на потом
  9. Типичные ошибки при поиске и устранении потерь
  10. Сценарии: как действовать в типичных ситуациях
  11. Практический следующий шаг на этой неделе
  12. FAQ
  13. Нужен ли специальный софт для поиска потерь?
  14. Как отличить потерю от необходимого контроля/проверки?
  15. Что делать, если потери на стыке двух подразделений, а соседний руководитель не хочет сотрудничать?
  16. Как часто нужно повторять поиск потерь?
  17. Стоит ли нанимать внешнего консультанта по lean/операционному совершенствованию?

Что считать операционными потерями в офисной и сервисной среде

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

  • Ожидание — простой сотрудника или задачи: согласование у руководителя, ответ от смежного отдела, доступ к системе, поставка материалов.
  • Лишние перемещения — физические (ходьба к принтеру, архиву, другому этажу) и виртуальные (переключение между системами, поиск файлов в общих папках, копирование данных из Excel в 1С).
  • Лишние операции — дублирование ввода, заполнение полей, которые никто не использует, создание отчётов «на всякий случай», избыточные уровни согласования.
  • Дефекты и переделки — ошибки в заявках, неверные спецификации, возврат задач на доработку, несовпадение версий документов.
  • Избыточное производство — подготовка аналитики, которую не читают, печать архивных копий «на случай проверки», рассылка информационных писем без целевого действия.
  • Избыточные запасы — накопление необработанных заявок в очереди, старые версии шаблонов, неактуальные базы знаний, заказы на закупку «на запас».
  • Неиспользуемый талант — высококвалифицированные сотрудники тратят время на рутинный ввод данных, экспертиза не задействована в улучшении процессов.
  • Лишняя транспортная перемешка (в информационном виде) — передача задачи через несколько посредников, когда можно передать напрямую исполнителю.

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

Три основных источника данных о потерях

Ни один метод не даёт полной картины. Комбинируйте их в зависимости от зрелости процессов и доступности данных.

1. Гемба-уок (наблюдение на месте)

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

Алгоритм короткого гемба-уока (30–40 минут на одно рабочее место):

  1. Договоритесь с руководителем и сотрудником: цель — понять процесс, а не оценить человека.
  2. Сядьте рядом, не мешайте. Записывайте хронологию: время, действие, инструмент, ожидание, переключение контекста.
  3. Обратите внимание на: паузы (смотрит в монитор, ждёт загрузки), переключения окон, обращения к коллегам за уточнением, ручной перенос данных, поиск шаблонов/инструкций.
  4. Зафиксируйте 5–7 повторяющихся паттернов. Это и есть кандидаты в потери.

Пример: менеджер по закупкам 12 минут в час переключается между почтой, 1С и порталом поставщика, копируя номера заказов вручную. Это лишние перемещения и лишние операции. Автоматизация обмена данными или простой макрос уберут потерю.

2. Анализ цифровых следов (process mining / лог-анализ)

Если процессы проходят через информационные системы (BPM, CRM, ServiceDesk, ERP), выгружайте журналы событий. Простой SQL-запрос или встроенная аналитика покажут:

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

Не нужен дорогой process mining: выгрузка в CSV и сводная таблица в Excel часто достаточно для первичной диагностики.

3. Структурированные интервью и самооценка команд

Сотрудники знают свои потери лучше любого аудитора. Но открытый вопрос «что мешает работать?» вызовет жалобы на зарплату и коллег. Используйте структурированный опросник по категориям потерь:

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

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

Пошаговый алгоритм поиска потерь в подразделении

Примените этот цикл к одному сквозному процессу (например, «от заявки к оплате», «от инцидента к закрытию», «от идеи к внедрению»). Не пытайтесь охватить всё сразу.

  1. Определите границы процесса — вход (триггер), выход (результат для клиента), ключевые этапы. Нарисуйте схему текущего состояния (as-is) на доске или в Miro вместе с командой.
  2. Соберите базовую метрику — lead time (время от входа до выхода), % времени активной работы vs ожидание, количество передач между ролями. Без базы не измерите улучшение.
  3. Проведите 3–5 гемба-уоков по разным ролям процесса. Зафиксируйте потери по классификации выше.
  4. Проанализируйте системные логи за последние 1–3 месяца. Найдите этапы с наибольшим разбросом времени и частыми возвратами.
  5. Проведите структурированный опрос команды по 4–5 вопросам выше. Сравните с наблюдениями и данными — совпадения подтверждают системность потери.
  6. Кластеризуйте найденные потери по матрице: влияние на lead time / качество / затраты × сложность устранения (быстро / средне / проектно).
  7. Выберите 1–2 быстрых выигрыша (quick wins) — потери в квадранте «высокое влияние, низкая сложность». Реализуйте за 1–2 недели.
  8. Зафиксируйте эффект по тем же метрикам. Обновите схему процесса (to-be). Планируйте работу со средними и сложными потерями в бэклог улучшений.

Типичные слепые зоны: где потери не видны даже внимательным руководителям

Слепая зона Как проявляется Как обнаружить
Скрытое ожидание в «активной» задаче Задача в статусе «В работе», но исполнитель ждёт вводные от другого отдела В системах ввести подстатус «Ожидание вводных» или анализировать активность (клики, логи) внутри задачи
Теневая IT / ручные обходные пути Сотрудники ведут параллельные таблицы в Excel, дублируют данные в мессенджерах Спросите: «Какие таблицы у вас на рабочем столе, которых нет в официальной системе?»
Потери на границах подразделений Каждый отдел оптимизирует свой кусок, но передача задачи теряет 2 дня Сделайте совместный гемба-уок с двумя смежными командами, фокус — на точке передачи
Когнитивная нагрузка от нечётких стандартов Сотрудник каждый раз решает: «Кому отправить?», «Какой шаблон выбрать?», «Какая приоритетность?» Засеките время на принятие рутинных решений. Если > 1 минуты на типовое действие — нужен чек-лист или правило маршрутизации
Регулярные совещания без решения Статус-митинги, где 80% времени — информирование, 20% — согласование следующих шагов Посчитайте стоимость часа совещания (сумма ставок участников) и сравните с количеством принятых решений

Приоритизация: что устранять первой, а что оставить на потом

Не все потери одинаково вредны. Используйте матрицу приоритизации с двумя осями:

  • Влияние на поток — насколько потеря удлиняет lead time, повышает дефектность, раздражает клиента или перегружает узкое место.
  • Усилия на устранение — время, деньги, согласования, изменение систем, обучение.

Четыре квадранта действий:

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

Типичные ошибки при поиске и устранении потерь

  • Борьба с симптомом вместо причины — ускоряют согласование, не устраняя причину частых ошибок в заявках. Результат: быстрее согласовывают дефектные задачи.
  • Автоматизация потерь — переносят бумажный беспорядок в цифровой вид. Сначала упростите процесс, потом автоматизируйте.
  • Игнорирование «необходимых неценностных действий» — пытаются убрать проверки соответствия закону или архивацию. Эти действия не создают ценность клиенту, но обязательны. Работайте над снижением их трудоёмкости, а не устранением.
  • Топ-даун без вовлечения исполнителей — руководитель переписывает регламент в кабинете. Люди продолжают работать по старым схемам, формально заполняя новые поля.
  • Замеры ради замеров — вводят KPI «количество найденных потерь» без привязки к экономическому эффекту. Команда находит мелкие потери, игнорируя системные.
  • Одноразовая акция вместо системы — проводит «неделю потерь», вешает доску улучшений, через месяц доска пустая. Нужен постоянный ритуал: еженедельный разбор 1–2 потерь на планерке.

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

Ситуация Первый шаг Чего не делать
Процесс никогда не описывали, хаос Соберите команду, нарисуйте текущую схему вместе (as-is) за 60 минут Нанимать консультантов писать регламенты «в вакууме»
Есть регламент, но все работают иначе Проведите гемба-уок и сравните с регламентом — найдите расхождения Штрафовать за несоответствие регламенту
Система (ERP/CRM) заставляет делать лишние шаги Выделите технические потери отдельно, согласуйте бэклог доработок с IT Требовать от людей «работать по системе» ценой качества
Руководитель не видит проблем, «всё работает» Покажите цифры: lead time, % переделок, стоимость часа ожидания топ-менеджеров Убеждать словами, не приводя данных
Команда перегружена, нет времени на улучшения Найдите 1 потерю, устранение которой вернёт 30 мин/день каждому — начните с неё Запускать большой проект изменений

Практический следующий шаг на этой неделе

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

  1. Нарисуйте схему as-is с командой (30 мин).
  2. Сделайте 2 гемба-уока по ключевым ролям (1.5 часа).
  3. Выгрузите логи по процессу за последний месяц и посчитайте lead time, % ожидания, количество возвратов (1 час).
  4. Соберите 5 ответов на структурированные вопросы от исполнителей (асинхронно в форме).
  5. На планерке в пятницу выложите найденные потери на доску, проголосуйте за 1 быстрый выигрыш, начните устранять в понедельник.

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

FAQ

Нужен ли специальный софт для поиска потерь?

Нет. Для старта достаточно блокнота, таймера, доступа к выгрузкам из текущих систем (Excel/CSV) и доски для визуализации. Process mining и BPM-платформы полезны при масштабе 50+ человек в процессе или сложных ветвлениях, но не заменяют наблюдение и разговор с людьми.

Как отличить потерю от необходимого контроля/проверки?

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

Что делать, если потери на стыке двух подразделений, а соседний руководитель не хочет сотрудничать?

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

Как часто нужно повторять поиск потерь?

Операционно — еженедельно на планерке разбирать 1–2 возникшие заторы. Глубоко — раз в квартал полный цикл по ключевому процессу. Триггеры для внепланового цикла: рост lead time > 20%, внедрение новой системы, реорганизация, массовый уход ключевых сотрудников.

Стоит ли нанимать внешнего консультанта по lean/операционному совершенствованию?

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

Miracle-Project.ru