Вы нашли проблему в процессе. Например, заявки на согласование возвращают на доработку в 30% случаев. Причина вроде очевидна — «менеджеры невнимательно заполняют поля». Вы проводите обучение. Пишете инструкцию. Добавляете напоминалку. Через месяц — снова 30% возвратов. Знакомая ситуация?

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

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

🔍 Инструмент 1. «5 почему» (самый простой и недооценённый) Берёте проблему и задаёте вопрос «почему?» пять раз подряд. Не додумывайте — отвечайте на основе фактов. Пример: Заявки возвращают на доработку.

Почему возвращают? → Потому что не заполнено поле «ИНН». Почему его не заполняют? →  Потому что менеджер не знает ИНН клиента. Почему не знает? →  Потому что ИНН не приходит из CRM при создании заявки. Почему не приходит? → Потому что интеграция CRM с системой клиентов работает только в одну сторону. Почему так настроили? → Потому что при проектировании не учли, что ИНН нужен на старте процесса. Корневая причина: проблема в архитектуре интеграции, а не в невнимательности менеджеров. Обучение тут не поможет, надо дорабатывать интеграцию. Главное правило: не останавливайтесь на первом же ответе. Обычно он лежит на поверхности и ведёт не туда.

🐟 Инструмент 2. Диаграмма Исикавы («рыбий скелет») Помогает, когда у проблемы несколько возможных причин, и вы не хотите пропустить ни одну. Как строить: Справа — «голова»: формулировка проблемы (например, «Заявки возвращают на доработку»). Слева — «хребет»: основные категории причин (Люди, Процессы, Технологии, Данные). К каждой категории добавляете конкретные причины — как кости к хребту. Пример для офисного процесса «Заявки возвращают на доработку»: Люди → Новички не знают правил, текучка, нет ответственности Процессы → Маршрут согласования слишком сложный, нет проверки перед отправкой Технологии → CRM не подтягивает ИНН, нет обязательных полей Данные → ИНН клиента хранится в другой системе, справочник устарел

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

📊 Инструмент 3. Анализ потока (а не только событий) Иногда мы концентрируемся на отдельных сбоях, но не видим картину целиком. Вопросы для анализа: На каком шаге процесса происходит больше всего возвратов? Как долго задача находится в статусе «на доработке»? Есть ли шаги, которые можно пропустить без потери качества?

Пример: Вы посмотрели статистику по 100 заявкам и увидели, что 80% возвратов происходит на шаге «проверка юристом». А юрист в 90% случаев возвращает из-за одной и той же опечатки в реквизитах. Корневая проблема не в «невнимательности менеджеров», а в том, что эта опечатка возникает из-за ручного ввода и её никто не проверяет до отправки юристу. Решение: добавить простую форму проверки реквизитов перед отправкой.

🎯 Что делать прямо сейчас Возьмите одну проблему, которая возвращается к вам чаще других. Не пытайтесь внедрить все три инструмента сразу. Начните с «5 почему» — это займёт 10 минут, а результат часто удивляет. Запишите корневую проблему. Проверьте: «Если мы уберём эту причину, проблема исчезнет или только уменьшится?» Если уменьшится — вы не докопались, копайте дальше.

А вы сталкивались с ситуацией, когда долго боролись со следствием, а потом оказалось, что причина была совсем в другом месте? 👇