Часто вместо проблемы мы описываем факт: низкий уровень продаж, долгий онбординг, и тд, и тп.
Решить факт невозможно.
Решить можно только проблему.
Вот стартовый шаблон формулировки проблемы.
В [процесс/зона] наблюдается [X — текущее значение метрики за период], а должно быть [Y — стандарт/план], поэтому [владелец проблемы] теряет [Z — измеримый ресурс], что создаёт риск [конкретное последствие при сохранении динамики], {связь между разрывом и потерью ресурса}Он описывает два состояния системы: as is и to be, владельца проблемы и риски и потери, убирает субъективность за счёт точных данных, а не оценочных прилагательных.
Примеры:
— В процессе обработки возвратов доля ручных согласований составила 42% за октябрь, а целевое значение 15%. из-за этого отдел логистики теряет 120 человеко-часов, что создаёт риск срыва SLA по доставке при росте сезонного потока (т.к. логисты занимаются не приоритетными задачами)
— В B2B воронке доля сделок с просроченными этапами составила 28% за 2026-Q1, а должно быть 10%, поэтому отдел продаж теряет 14% конверсии, что создаёт риск дефицита cash flow в следующем отчётном периоде
— При онбординге срок выхода на плановую производительность составляет 115 дней, а должно быть 70 дней; поэтому руководитель отдела RnD теряет 680 часов, что создаёт риск перегрузки наставников и снижения качества обработки клиентских обращений
Обратите внимание, что в шаблоне описания проблемы нет никакого описания (или даже намёка) решения.
Потому что решение всегда выбирается из альтернатив.
UPD: рекомендую посмотреть шаблон Тойоты