Gemba walk: зачем руководителю идти туда, где происходит работа
Gemba walk часто переводят слишком просто: руководитель должен выйти «на место». Формально верно. Но если руководитель просто прошёлся по офису или цеху, посмотрел на людей и задал пару вопросов, это ещё не Gemba.
Gemba — это место, где создаётся ценность или возникает проблема. Walk — это не инспекция ради замечаний, а способ увидеть фактическую работу. Не презентацию, не регламент, не отчёт, а то, как процесс выполняется на самом деле.
Что нужно увидеть
На месте видно то, что редко попадает в отчёт:
- где человек ждёт информацию;
- где данные переписывают вручную;
- где система неудобна и её обходят;
- где клиентский запрос теряется между ролями;
- где сотрудник исправляет чужие ошибки;
- где запас, очередь или повторная работа считаются нормой.
В кабинете это часто выглядит как «нужно ускорить отдел». На месте оказывается, что отдел половину времени ждёт согласование, уточняет неполные данные или исправляет входящий брак.
Чем Gemba walk не является
Это не внезапная проверка дисциплины. Если люди воспринимают обход как охоту за виноватыми, они покажут руководителю безопасную версию процесса.
Это не замена аудиту. Один обход не доказывает, что проблема устроена именно так всегда. Он даёт гипотезы, вопросы и точки для проверки.
Это не прогулка ради присутствия. Если после обхода ничего не меняется, люди быстро понимают, что это очередной управленческий ритуал.
Какие вопросы задавать
Хорошие вопросы должны прояснять процесс, а не ловить человека.
Например:
- С чего начинается эта работа?
- От кого вы получаете входные данные?
- Что чаще всего приходит не так?
- Где приходится ждать?
- Какие исключения повторяются?
- Что вы исправляете вручную?
- Что мешает сделать работу правильно с первого раза?
- Как вы понимаете, что результат принят?
Плохой вопрос звучит как обвинение: «Почему вы так делаете?» Хороший вопрос помогает увидеть систему: «Что в процессе приводит к такому действию?»
Что делать после обхода
После Gemba walk нужно отделить наблюдение от вывода.
Наблюдение: «Сотрудник трижды переносит данные из письма в таблицу и потом в систему».
Плохой вывод: «Нужно быть внимательнее».
Рабочий вывод: «В процессе есть ручная передача данных между каналами. Надо проверить источник, формат, владельца данных и возможность убрать повторный ввод».
Дальше нужны приоритеты. Не каждое наблюдение требует немедленного проекта. Иногда достаточно уточнить правило, убрать лишнее согласование или изменить форму заявки.
Полезно фиксировать не только проблему, но и место в потоке. Где именно возникает ожидание? Кто передаёт данные? Кто принимает результат? Как человек понимает, что можно двигаться дальше?
Без этой привязки обход превращается в список впечатлений. С привязкой к процессу он становится материалом для изменения: можно увидеть повторяющиеся задержки, лишние передачи, ручные проверки и точки, где ответственность размыта.
Вывод
Gemba walk нужен руководителю не для контроля присутствия, а для проверки реальности.
Он показывает, где процесс отличается от схемы, где люди компенсируют слабость системы и где управленческое решение должно опираться на факты, а не на впечатления.
Если процесс на бумаге выглядит лучше, чем в работе
2П помогает пройти фактический поток работы, зафиксировать расхождения и превратить наблюдения в понятные решения по процессу.