Перейти к содержанию
Все инструменты
Решение проблемСредний

A3 Problem Solving

Строит краткую доказательную историю от текущего состояния через причинный анализ к контрмерам и проверке результата.

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

За одну минуту

A3 обычно связывает:

  1. Контекст: почему вопрос важен и для кого.
  2. Текущее состояние: что происходит, где, когда и в каком масштабе.
  3. Целевое состояние: измеримый результат, граница и дата.
  4. Анализ: проверяемые причинные механизмы, а не ярлыки и вина.
  5. Контрмеры: действия, связанные с причинами и safeguards.
  6. План: владельцы, сроки, зависимости и права решения.
  7. Проверка: outcome-, process-, balancing- и learning-метрики.

Последовательность итеративна: новые данные могут изменить картину, причинную модель или цель.

Лучше всего: для ограниченного измеримого разрыва и совместного цикла улучшения.
Не подходит: когда сначала нужна срочная локализация вреда, вопрос слишком широк или решение уже навязано и не проверяется.

Какую проблему решает

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

Сам лист не доказывает улучшение. Нужны baseline, окно сравнения, данные процесса, побочные эффекты и альтернативные объяснения.

Когда применять

Применяйте A3, когда:

  • повторяющийся разрыв имеет измеримое текущее состояние;
  • разные функции владеют частями причинной системы;
  • контрмере нужна явная цепочка рассуждений;
  • команде нужен коучинг, а не готовый ответ;
  • изменение следует проверить через PDCA/PDSA;
  • обучение и standard work должны пережить проект.

Когда не применять

Не используйте A3:

  • вместо ограничения активного safety-, legal- или финансового инцидента;
  • чтобы сжать сложный портфель на одну страницу;
  • как форму после выбора решения;
  • чтобы назвать человека root cause;
  • если измерение раскрывает персональные данные без полномочий;
  • чтобы приписать эффект по одному сравнению before/after.

Необходимые входные данные

  • ограниченный разрыв, затронутые пользователи и владелец;
  • baseline с определениями и знаменателями;
  • прямое наблюдение работы и исключений;
  • process-, demand-, timing- и качественные данные;
  • причинные гипотезы и опровергающие проверки;
  • safeguards, полномочия и ресурсы follow-up.

Пошаговый процесс

1. Проясните контекст

Опишите назначение, затронутые группы, значимость и срочность без языка решения.

2. Наблюдайте текущее состояние

Покажите процесс, вариацию, частоту и влияние. Определите метрики, отделите факты от интерпретаций.

3. Задайте целевое состояние

Укажите outcome, границу, меру, дату и guardrails. Цель не должна переносить вред в другое место.

4. Анализируйте механизмы

Используйте Root Cause Analysis, Five Whys, Ishikawa или иной уместный метод. Для каждого утверждения запишите подтверждающие и опровергающие данные.

5. Выберите контрмеры

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

6. Спланируйте внедрение

Назначьте владельцев, даты, зависимости, обучение, коммуникации, escalation и stop rules. Отделите тест от rollout.

7. Определите follow-up

Измеряйте outcome, выполнение процесса, balancing effects и различия по затронутым группам. Окно сравнения задайте заранее.

8. Проверьте и изучите

Проведите ограниченное изменение и обновите A3. Примите, адаптируйте или отмените; не переписывайте исходную гипотезу после результата.

9. Стандартизируйте осторожно

При достаточных данных обновите standard work, контроли и обучение. Сохраните исключения, остаточный риск и триггер пересмотра.

Линза AI-автоматизации

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

AI не должен придумывать данные, искать виновных по данным сотрудников, превращать корреляцию в root cause, переписывать гипотезу или одобрять safety-critical решение.

Визуальная модель

Интерактивный пример

14% счетов поставщиков возвращают на исправление. Руководители предлагают переобучить всех. Наблюдение показывает, что большинство ошибок возникает в новом intake-канале с неоднозначным mapping полей.

Рабочий ответ: определите baseline по каналам и target first-pass-valid с guardrails по late payment и нагрузке на поставщика. Проверьте mapping и validation до общего обучения. Сравните с незатронутыми каналами и сохраните исходную гипотезу.

Заметки фасилитатору

  • Владелец A3 думает, coach проверяет доказательность.
  • Используйте схемы и графики, когда они яснее текста.
  • Приглашайте исполнителей и получателей процесса.
  • Не помещайте контрмеры в текущее состояние.
  • Проверяйте логику слева направо и трассировку справа налево.

Ожидаемый результат

  • ограниченная проблема и evidence-based текущее состояние;
  • измеримая цель с safeguards;
  • причинные гипотезы и проверки;
  • контрмеры, связанные с механизмами;
  • план с владельцами и escalation;
  • outcome-, process- и balancing-метрики;
  • версия обучения и решение о стандартизации.

Типичные ошибки

  1. Одностраничный status report вместо рассуждения.
  2. Решение встроено в постановку проблемы.
  3. Человек объявлен root cause.
  4. Список действий не связан с причинностью.
  5. Нет balancing measure.
  6. Исходная гипотеза переписана задним числом.

Чек-лист качества

  • Разрыв, граница, затронутые группы и владелец явны.
  • Метрики текущего состояния имеют определения и знаменатели.
  • Представлены прямые наблюдения и исключения.
  • Цель включает дату и guardrails вреда.
  • Причинные утверждения имеют подтверждающие и опровергающие данные.
  • Контрмеры трассируются к механизмам.
  • Outcome-, process- и balancing-метрики заданы до действия.
  • Записаны обучение, остаточный риск и следующий review.

Шаблон

РазделДанные или решениеМера / проверкаВладелец / дата
КонтекстЦель и пользователиПочему сейчасВладелец
Текущее → цельРазрыв и границаBaseline, target, guardrailsReview
Причина → контрмераМеханизм и данныеТест и balancing measureВладелец действия
Follow-upРезультат и обучениеAdopt / adapt / abandonВладелец стандарта

Проверка знаний

Вопрос: чем контрмера A3 отличается от обычного action item?

Ответ: она связана с проверяемым причинным механизмом и оценивается outcome-, process- и balancing-данными.

Связанные методы

Источники

  1. Lean Enterprise Institute. “A3 Report.” Lean Lexicon (откроется в новой вкладке). Доступ 22 сентября 2026.
  2. John Shook. Managing to Learn. Lean Enterprise Institute, 2008.
  3. Durward K. Sobek II, Art Smalley. Understanding A3 Thinking. Productivity Press, 2008.
  4. Bozena Poksinska et al., 2020. DOI (откроется в новой вкладке). В литературе отмечается ограниченность систематических исследований A3.
  5. Joshua Dunsford, Erica Reimer, 2013. PLOS ONE (откроется в новой вкладке). Прикладной кейс не доказывает универсальный эффект.

Профиль метода

  • Главный результат: краткая версионируемая доказательная история и цикл обучения.
  • Уровень решения: ограниченное операционное или межфункциональное улучшение.
  • Сила данных: устоявшаяся Lean-практика с кейсами; систематические сравнительные данные самого A3 ограничены.
  • Триггер пересмотра: новые baseline-данные, провал гипотезы, побочный эффект, изменение процесса или завершение follow-up.