Большинство операционных потерь в подразделениях не видно в отчётах — они скрыты в привычных действиях: ожидании согласований, повторном вводе данных, нечётких переходах между этапами. Главный ориентир при поиске — разделение любого процесса на действия, создающие ценность для клиента (внутреннего или внешнего), и всё остальное. Начните с наблюдения за реальной работой, а не с изучения регламентов: в регламентах фиксируется «как должно быть», а потери живут в разнице с «как есть на самом деле».
- Что считать операционными потерями в офисной и сервисной среде
- Три основных источника данных о потерях
- 1. Гемба-уок (наблюдение на месте)
- 2. Анализ цифровых следов (process mining / лог-анализ)
- 3. Структурированные интервью и самооценка команд
- Пошаговый алгоритм поиска потерь в подразделении
- Типичные слепые зоны: где потери не видны даже внимательным руководителям
- Приоритизация: что устранять первой, а что оставить на потом
- Типичные ошибки при поиске и устранении потерь
- Сценарии: как действовать в типичных ситуациях
- Практический следующий шаг на этой неделе
- FAQ
- Нужен ли специальный софт для поиска потерь?
- Как отличить потерю от необходимого контроля/проверки?
- Что делать, если потери на стыке двух подразделений, а соседний руководитель не хочет сотрудничать?
- Как часто нужно повторять поиск потерь?
- Стоит ли нанимать внешнего консультанта по lean/операционному совершенствованию?
Что считать операционными потерями в офисной и сервисной среде
Классификация потерь (муда) из lean-производства адаптируется под работу подразделений без потери сути. Вне цеха потери носят информационный, коммуникативный и когнитивный характер, но их экономическая природа та же — потребление ресурсов без создания ценности.
- Ожидание — простой сотрудника или задачи: согласование у руководителя, ответ от смежного отдела, доступ к системе, поставка материалов.
- Лишние перемещения — физические (ходьба к принтеру, архиву, другому этажу) и виртуальные (переключение между системами, поиск файлов в общих папках, копирование данных из Excel в 1С).
- Лишние операции — дублирование ввода, заполнение полей, которые никто не использует, создание отчётов «на всякий случай», избыточные уровни согласования.
- Дефекты и переделки — ошибки в заявках, неверные спецификации, возврат задач на доработку, несовпадение версий документов.
- Избыточное производство — подготовка аналитики, которую не читают, печать архивных копий «на случай проверки», рассылка информационных писем без целевого действия.
- Избыточные запасы — накопление необработанных заявок в очереди, старые версии шаблонов, неактуальные базы знаний, заказы на закупку «на запас».
- Неиспользуемый талант — высококвалифицированные сотрудники тратят время на рутинный ввод данных, экспертиза не задействована в улучшении процессов.
- Лишняя транспортная перемешка (в информационном виде) — передача задачи через несколько посредников, когда можно передать напрямую исполнителю.
Практический критерий: если действие можно убрать, и результат для клиента не ухудшится — это потеря. Если убрать нельзя сегодня из-за ограничений системы или регулятора — это необходимое неценностное действие, над которым работают отдельно.
Три основных источника данных о потерях
Ни один метод не даёт полной картины. Комбинируйте их в зависимости от зрелости процессов и доступности данных.
1. Гемба-уок (наблюдение на месте)
Самый достоверный способ увидеть потери — пойти туда, где работа происходит, и смотреть без оценки. Не интервьюируйте, а наблюдайте: как сотрудник открывает утро, где ищет информацию, сколько раз прерывается, как передаёт задачу коллеге.
Алгоритм короткого гемба-уока (30–40 минут на одно рабочее место):
- Договоритесь с руководителем и сотрудником: цель — понять процесс, а не оценить человека.
- Сядьте рядом, не мешайте. Записывайте хронологию: время, действие, инструмент, ожидание, переключение контекста.
- Обратите внимание на: паузы (смотрит в монитор, ждёт загрузки), переключения окон, обращения к коллегам за уточнением, ручной перенос данных, поиск шаблонов/инструкций.
- Зафиксируйте 5–7 повторяющихся паттернов. Это и есть кандидаты в потери.
Пример: менеджер по закупкам 12 минут в час переключается между почтой, 1С и порталом поставщика, копируя номера заказов вручную. Это лишние перемещения и лишние операции. Автоматизация обмена данными или простой макрос уберут потерю.
2. Анализ цифровых следов (process mining / лог-анализ)
Если процессы проходят через информационные системы (BPM, CRM, ServiceDesk, ERP), выгружайте журналы событий. Простой SQL-запрос или встроенная аналитика покажут:
- Среднее и медианное время на каждом этапе — выбросы указывают на заторы.
- Количество возвратов задачи на предыдущие этапы — индикатор дефектов или нечётких критериев приёмки.
- Количество параллельных активных задач на исполнителе — признак мультитаскинга и потерь на переключение контекста.
- Процент задач, закрытых по таймауту или эскалации — маркер проблемных зон.
Не нужен дорогой process mining: выгрузка в CSV и сводная таблица в Excel часто достаточно для первичной диагностики.
3. Структурированные интервью и самооценка команд
Сотрудники знают свои потери лучше любого аудитора. Но открытый вопрос «что мешает работать?» вызовет жалобы на зарплату и коллег. Используйте структурированный опросник по категориям потерь:
- «На каком этапе задачи чаще всего висит в ожидании и почему?»
- «Какие действия вы повторяете каждую неделю и считаете бессмысленными?»
- «Где вам приходится уточнять то, что должно быть очевидно из задачи?»
- «Какие отчёты вы готовите, и кто их реально использует для решений?»
Проведите анонимный опрос в команде, затем соберите группу на 45 минут для кластеризации ответов. Люди сами выделят системные проблемы от личных недовольств.
Пошаговый алгоритм поиска потерь в подразделении
Примените этот цикл к одному сквозному процессу (например, «от заявки к оплате», «от инцидента к закрытию», «от идеи к внедрению»). Не пытайтесь охватить всё сразу.
- Определите границы процесса — вход (триггер), выход (результат для клиента), ключевые этапы. Нарисуйте схему текущего состояния (as-is) на доске или в Miro вместе с командой.
- Соберите базовую метрику — lead time (время от входа до выхода), % времени активной работы vs ожидание, количество передач между ролями. Без базы не измерите улучшение.
- Проведите 3–5 гемба-уоков по разным ролям процесса. Зафиксируйте потери по классификации выше.
- Проанализируйте системные логи за последние 1–3 месяца. Найдите этапы с наибольшим разбросом времени и частыми возвратами.
- Проведите структурированный опрос команды по 4–5 вопросам выше. Сравните с наблюдениями и данными — совпадения подтверждают системность потери.
- Кластеризуйте найденные потери по матрице: влияние на lead time / качество / затраты × сложность устранения (быстро / средне / проектно).
- Выберите 1–2 быстрых выигрыша (quick wins) — потери в квадранте «высокое влияние, низкая сложность». Реализуйте за 1–2 недели.
- Зафиксируйте эффект по тем же метрикам. Обновите схему процесса (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 дня:
- Нарисуйте схему as-is с командой (30 мин).
- Сделайте 2 гемба-уока по ключевым ролям (1.5 часа).
- Выгрузите логи по процессу за последний месяц и посчитайте lead time, % ожидания, количество возвратов (1 час).
- Соберите 5 ответов на структурированные вопросы от исполнителей (асинхронно в форме).
- На планерке в пятницу выложите найденные потери на доску, проголосуйте за 1 быстрый выигрыш, начните устранять в понедельник.
Главное — не останавливаться на диагностике. Диагностика без действия создаёт иллюзию работы. Даже устранение одной малой потери каждую неделю даёт накопляющийся эффект, который через квартал становится заметен в отчётах и нагрузке команды.
FAQ
Нужен ли специальный софт для поиска потерь?
Нет. Для старта достаточно блокнота, таймера, доступа к выгрузкам из текущих систем (Excel/CSV) и доски для визуализации. Process mining и BPM-платформы полезны при масштабе 50+ человек в процессе или сложных ветвлениях, но не заменяют наблюдение и разговор с людьми.
Как отличить потерю от необходимого контроля/проверки?
Задайте вопрос: «Если мы уберём это действие, что случится с результатом для клиента и с рисками для компании?». Если риск реальный и неснижаемый другими способами — это необходимое неценностное действие. Работайте над тем, чтобы сделать его быстрее/дешевле (чек-листы, автоматические валидации, делегирование ниже по квалификации).
Что делать, если потери на стыке двух подразделений, а соседний руководитель не хочет сотрудничать?
Начните с своей стороны: устраните потери, которые зависят только от вас (подготовка полного пакета документов, чёткие критерии приёмки задачи, шаблоны запросов). Покажите результат в цифрах — сокращение времени цикла на вашем участке. Часто это мотивирует соседа присоединиться. Если нет — эскалируйте общую метрику lead time общему руководителю с предложением совместного гемба-уока.
Как часто нужно повторять поиск потерь?
Операционно — еженедельно на планерке разбирать 1–2 возникшие заторы. Глубоко — раз в квартал полный цикл по ключевому процессу. Триггеры для внепланового цикла: рост lead time > 20%, внедрение новой системы, реорганизация, массовый уход ключевых сотрудников.
Стоит ли нанимать внешнего консультанта по lean/операционному совершенствованию?
Смысл есть в двух случаях: (1) внутренней компетенции нет и нет времени её вырастить — тогда консультант обучает ваших людей, делая первый проект вместе; (2) нужен свежий взгляд на заезженные процессы, где «все знают, что нельзя изменить». Ошибка — нанимать консультанта «сделать за нас» без передачи навыков команде.
