Разбор сбоя не закончен, пока в работе команды ничего не изменилось.

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

Поэтому после любого отклонения мне важно получить ответы не только на вопрос «что произошло?», но и ещё на несколько.

Что должно было предотвратить эту ситуацию — и почему этот барьер не сработал?

Это могла быть нечёткая инструкция, незаметная точка передачи информации, неопределённое право принимать решение, отсутствие времени на проверку или процесс, который держался исключительно на внимательности конкретного сотрудника.

Что именно мы меняем?

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

Кто отвечает за изменение и к какому сроку?

У коллективного решения без владельца обычно нет продолжения. Это не означает, что один человек виноват в произошедшем. Это означает, что у следующего шага должен быть тот, кто доведёт его до результата.

И наконец — как мы поймём, что изменение действительно заработало?

Факт обновления инструкции ещё не говорит о том, что процесс изменился. Важно заранее определить, когда команда вернётся к этому вопросу, что именно проверит и по каким признакам увидит: решение используется в реальной работе, а не существует только в протоколе встречи.

Компактный шаблон такого разбора может выглядеть так:

Что произошло?

Какой защитный барьер не сработал?

Что конкретно мы меняем?

Кто владелец изменения?

К какому сроку оно должно быть внедрено?

Когда и каким способом мы проверим результат?

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

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

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