Отчёт A3 должен показывать, почему команда предлагает то или иное изменение. Что происходит сейчас? Чем вызвано расхождение с желаемым состоянием? Почему предложенная мера поможет? Заполненная страница полезна только тогда, когда между этими ответами есть логическая связь.
Разместите факты и предлагаемые изменения рядом в общем пространстве для обсуждения проблемы. Разберём пример команды, которая организует обучение: заявки постоянно возвращаются от специалистов по планированию к сотрудникам, которые их принимают, потому что важной информации не хватает или она непонятна.
Начните с проблемы, а не с заполнения бланка
Lean Enterprise Institute описывает A3 как нечто большее, чем лист бумаги: текущая ситуация, анализ, контрмеры, ответственность и данные о результатах становятся частью совместного решения проблемы.
Представьте команду, которая получает заявки на обучение из нескольких отделов. Сотрудники по приёму регистрируют заявку и передают её специалистам по планированию. Те назначают тренера и согласуют дату. Часть заявок приходится возвращать: непонятно, утверждена ли предложенная дата, для кого проводится занятие или кто может ответить на вопросы.
«Нам нужна более удобная форма заявки» — уже решение. Возможно, оно верное, но саму проблему не описывает. Полезнее начать так: по части поступивших заявок нельзя назначить тренера, поскольку неясны состав участников, статус даты или контакт для принятия решения; из-за этого заявки приходится передавать между командами повторно.
Ограничьте анализ так, чтобы ситуацию можно было наблюдать: одна услуга обучения, передача от приёма к планированию и определённый период. У задачи «наладить коммуникацию во всей организации» нет практических границ для такого A3.
Покажите текущее состояние с помощью журнала заявок
Нарисуйте существующий путь: заявка получена → сотрудники по приёму готовят информацию → специалисты по планированию проверяют её → тренер назначен. Добавьте обратную стрелку от планирования к приёму и фиксируйте, почему заявка по ней возвращается.
В таблице ниже показано, какие подробности стоит записывать. Прежде чем выбирать меру, замените эти примеры наблюдениями по выбранной услуге.
| Пример заявки | Что получает команда планирования | Причина возврата | Что выяснить |
|---|---|---|---|
| R01 | Дата указана, но её статус согласования отсутствует. | Непонятно, можно ли резервировать время тренера. | Дату уже подтвердили, но не записали это, или она ещё ждёт согласования? |
| R02 | Указано «обучение команды», но неясно, для кого оно предназначено. | Нельзя выбрать подходящего тренера. | Была ли информация об участниках при приёме заявки? Где она сохранилась? |
| R03 | Заявка заполнена, но не указан человек, который может разрешить конфликт дат. | Уточнение отправляют через сотрудников по приёму. | Кто вправе принять решение? Можно ли обратиться к нему напрямую? |
Считайте отдельно заявки и случаи уточнения. Одна заявка, возвращённая трижды, — это одна затронутая заявка и три возврата. Если смешать эти величины, масштаб проблемы будет выглядеть по-разному в зависимости от того, кто готовит отчёт.
Разделяйте также ожидание ответа и время самой проверки заявки. Более длительная передача между командами не обязательно означает, что специалисту нужно больше времени на проверку. Непонятная информация и перегруженная очередь могут требовать разных мер.
Отделите причины от правдоподобных объяснений
Команда может быстро решить, что заявители невнимательны или что сотрудников по приёму нужно дополнительно обучить. Без изучения работы это слишком удобные объяснения. Проследите возвращённую заявку от исходной отправки через все копии, сообщения и передачи между сотрудниками.
Для R01 возможны две причины. Дату могли согласовать, но потерять этот статус при копировании данных в сообщение для планирования. Или согласования ещё нет, а обязательное поле даты подталкивает человека указать временное значение. Одинаковый видимый пробел возникает по разным причинам.
| Возможная причина | Какие данные её подтверждают | Как это влияет на выбор меры |
|---|---|---|
| Необходимая информация теряется при передаче. | В исходной заявке данные есть, а в версии для планирования их нет. | Сохранить информацию при передаче, а не запрашивать её у заявителя ещё раз. |
| Заявку передают до принятия решения. | В исходной записи и переписке дата остаётся несогласованной. | Явно обозначить готовность заявки и предварительный статус даты; ещё одно обязательное поле может не помочь. |
| Команды по-разному понимают, когда заявка «готова». | Обе команды следуют своим инструкциям, но те требуют разной информации. | Согласовать условие передачи вместо поиска виноватой команды. |
В материале Lean Enterprise Institute о мышлении A3 подчёркиваются исследование и логическая связь фактов, проблемы и контрмер. В нашем случае важнее наблюдать передачу заявки, чем за одну встречу заполнить ответами все поля.
Выберите меру, которая отвечает найденной причине
Допустим, наблюдение показало, что команды используют разные критерии готовности, а предварительные даты нельзя отличить от подтверждённых. Тогда целевая мера — определить сведения, необходимые для планирования, и явно указывать статус даты.
В пробном процессе при передаче заявки можно указывать участников обучения, желаемую дату со статусом «подтверждена» или «предварительная» и человека, уполномоченного разрешать разногласия. Неготовые заявки должны оставаться заметными как требующие уточнения, а не попадать в одну очередь с готовой работой.
Это не означает, что нужно отклонять любую неполную заявку. Обсуждение обучения вполне может начинаться до выбора даты. Изменение должно помогать отличать предварительный запрос от заявки, по которой уже можно назначить тренера, а не заставлять людей придумывать ответы ради отправки формы.
Сравните эту меру с заменой всей системы. Новая программа может воспроизвести то же неясное правило готовности. Если нет данных о том, что нынешние инструменты мешают правильно передать заявку, сначала проверьте более понятное правило, а не делайте замену ПО центральной задачей A3.
Определите условия проверки и показатели
Запишите, кто будет поддерживать правило передачи, какие заявки войдут в пробный период, когда команды рассмотрят результаты и при каких условиях изменят или остановят проверку. Сохраните границы услуги и правила подсчёта, использованные для исходного состояния.
Один из полезных показателей — доля поступивших заявок, возвращённых из-за недостающей или неоднозначной информации при передаче. Явно задайте числитель и знаменатель: количество затронутых заявок, делённое на все поступившие заявки в выбранной группе за выбранный период. Повторные возвраты считайте отдельно; также фиксируйте время до решения о планировании.
Следите и за другой стороной передачи. Если возвратов стало меньше только потому, что сотрудники по приёму теперь держат заявки у себя неопределённо долго, услуга могла не улучшиться. Записывайте ожидание на этапе приёма и дополнительную работу по подготовке заявки. Нельзя объявлять успех по одному локальному показателю, если задержка просто переместилась.
Оставьте область результатов пустой, пока не появятся наблюдения. В A3 можно написать «проверка предложена» и показать планируемые показатели. Прогноз должен находиться рядом с предлагаемой мерой, а не в поле «результаты».
Разложите логику A3 на доске Boardmix
В левой части доски Boardmix разместите текущее состояние: путь заявки, стрелку возврата и журнал. В центре — анализ причин, связав каждое возможное объяснение с подтверждающими или пока отсутствующими данными. Справа расположите выбранную меру и план её проверки.
В примере с обучением свяжите неясный статус даты с предложением разделять подтверждённые и предварительные даты. Разные правила готовности — с общим условием передачи. Не соединяйте каждую причину с каждым изменением: иначе станет непонятно, какое предложение решает конкретную проблему.
Откройте доску Boardmix и обсудите реальные примеры из приёма и планирования. При необходимости обезличьте данные заявок. Укажите ответственного за A3, не создавая впечатления, что он руководит всеми участвующими командами.
Если проверка покажет, что даже понятные заявки ждут из-за отсутствия свободных тренеров, сохраните этот вывод. Он меняет следующую проблему для исследования. A3 должен показывать, почему команда пересмотрела своё понимание, а не защищать первоначальное объяснение вопреки наблюдениям.
