Превратите предпочтительный план в устойчивый рабочий путь: подготовьтесь к правдоподобным проблемам до того, как они станут неожиданностями.
За одну минуту
PDPC расширяет план двумя вопросами:
- Что может пойти не так на этом шаге?
- Что мы сделаем, если появится предупреждающий сигнал?
Обычная цепочка выглядит так:
Цель → плановое действие → возможная проблема → контрмера → сигнал и владелец
PDPC — не каталог всех вообразимых отказов. Она фокусирует внимание на правдоподобных нарушениях, способных существенно помешать цели.
Лучше всего для: новых внедрений, миграций, ИИ-пилотов и межфункциональных планов со значимыми исключениями.
Избегайте, когда: нужно расследовать инцидент, количественно оценить широкий портфель рисков или заменить аварийные процедуры.
Проблема, которую решает метод
Планы обычно рисуют как счастливый путь. После запуска проблемы решаются неформально: команда импровизирует под давлением, а пользователи получают непоследовательное восстановление.
PDPC делает работу с исключениями частью плана и привязывает сигналы, профилактику, реакцию и ответственность к конкретному действию.
Когда использовать метод
- решение принято, а внедрение нужно проверить на прочность;
- ИИ-агент пересечёт границу данных, утверждения или действия;
- план зависит от нескольких команд или поставщиков;
- fallback, rollback или эскалация должны быть готовы до запуска;
- редкие случаи способны остановить работу или причинить вред;
- пилоту нужны явные сигналы «продолжить», «удержать» и «остановить».
Начинайте с реального планового пути, иначе дереву исключений не на что опереться.
Когда не использовать метод
- вместо FMEA для всего продукта или процесса;
- для расследования причины прошлого сбоя;
- как список рисков без исполнимых контрмер;
- если у контрмеры нет сигнала и владельца;
- для нечитаемого дерева отдалённых возможностей;
- чтобы обойти формальные требования безопасности, защиты и incident response.
Для причинного расследования используйте анализ первопричин, для системного перспективного анализа отказов — FMEA.
Необходимые входные данные
- выбранная цель и границы внедрения;
- плановые действия и зависимости;
- исполнители и получатели работы;
- данные об инцидентах, исключениях и почти-сбоях;
- обязательные контроли и пределы полномочий;
- сигналы предупреждения и возможности мониторинга;
- владельцы, способные исполнить контрмеры;
- каналы отката, эскалации и коммуникации.
Пошаговый процесс
1. Определите цель и условия успеха
Назовите требуемый результат и условия качества, безопасности и клиентского опыта, которые должны сохраняться.
2. Нарисуйте плановый путь действий
Покажите основную последовательность от подготовки до завершения. Держите шаги на одном уровне и включите передачи или решения, создающие существенный риск.
3. Найдите правдоподобные проблемы
Для каждого шага спросите, что может остановить, задержать или исказить результат. Используйте факты, аналогичный опыт и структурированный challenge. «Системная проблема» недостаточно наблюдаема.
4. Отберите существенные ветви
Сосредоточьтесь на вероятных проблемах, тяжёлых последствиях и трудном восстановлении. Отметьте неизвестное, требующее теста до запуска.
5. Спроектируйте профилактику
Измените план так, чтобы проблема возникала реже: проверьте входы, поменяйте последовательность, ограничьте права, отрепетируйте миграцию или уменьшите объём.
6. Спроектируйте реакцию
Определите действие при провале профилактики: удержание, ручной маршрут, fallback, rollback, эскалация, сообщение пользователю и доказательство восстановления.
7. Назначьте сигналы и владельцев
Каждая контрмера получает наблюдаемый триггер, источник мониторинга, уполномоченного владельца и срок реакции. «Внимательно следить» — не операционный ответ.
8. Испытайте ветви
Проведите настольный сценарий или контролируемую симуляцию. Проверьте, что люди видят сигнал, имеют доступ к fallback, способны использовать полномочия и восстановить доверенное состояние.
9. Встройте в рабочий план
Перенесите утверждённые контрмеры в процедуры, мониторинг, критерии запуска и записи ответственности. PDPC не должна остаться картинкой семинара.
10. Обновляйте во время внедрения
Записывайте, какие ветви сработали, помогли ли меры и какие новые проблемы появились. Обновляйте схему перед следующим этапом.
Ракурс ИИ-автоматизации
Для ИИ-агента отобразите полную цепочку: получение запроса, извлечение разрешённых данных, генерация или классификация, валидация, запрос утверждения, ограниченное действие, запись результата и мониторинг исключений.
Возможные проблемы: отсутствие доказательств, prompt injection, низкая уверенность, недоступность инструмента, повторное действие, неверные права, перегрузка проверяющих и невозможность отмены.
Контрмеры по возможности должны исполняться окружающим workflow: allowlist, read-only по умолчанию, проверка схемы, идемпотентность, отказ модели, человеческая эскалация, аудит и откат. Один текст промпта не является надёжным планом.
Визуальная модель
Текстовая альтернатива: цель разветвляется на плановые действия; у каждого есть наблюдаемая проблема, профилактика, сигнал, владелец и реакция; для ИИ предусмотрены отказ, ручной режим и откат до масштабирования.
Интерактивный пример
Ситуация
Компания планирует разрешить ИИ-помощнику обновлять стадии возможностей в CRM после звонков. Счастливый путь: транскрипция → извлечение данных → предложение стадии → утверждение менеджером → обновление CRM.
Известны риски: нет согласия на запись, намерение клиента неоднозначно, после timeout возникает дубль, менеджер подтверждает без чтения доказательств.
Ваш ход
Добавьте проблемные ветви, сигналы и контрмеры.
Разбор
- Нет согласия. Сигнал: отсутствует действующая запись согласия. Мера: остановить транскрипцию и направить звонок на ручные заметки.
- Данные не подтверждают стадию. Сигнал: противоречивые признаки или нет цитируемого фрагмента. Мера: отказаться от изменения.
- Timeout обновления. Сигнал: нет подтверждённого transaction ID. Мера: проверить состояние по ключу идемпотентности до повтора.
- Поверхностное утверждение. Сигнал: доля исправлений или откатов выше лимита пилота. Мера: остановить живые обновления и вернуться в режим предложений.
Операционный владелец может остановить пилот, технология отвечает за откат, менеджеры продаж исправляют случаи в течение рабочего дня.
Заметки фасилитатору
- Начинайте с реального плана и цели.
- Формулируйте проблему конкретно и наблюдаемо.
- Привлекайте операторов и затрагиваемые команды.
- Разделяйте профилактику и реакцию.
- Требуйте сигнал, владельца и время ответа.
- До запуска испытайте хотя бы одну неприятную ветвь.
- Переносите меры в операционную систему.
Ожидаемый выпуск
- цель и плановый путь;
- существенные проблемные ветви;
- профилактические и ответные контрмеры;
- наблюдаемые сигналы и мониторинг;
- уполномоченные владельцы и сроки реакции;
- испытанные fallback и rollback;
- обновлённый рабочий план.
Типичные ошибки
- Отображён только счастливый путь.
- Риски названы общими словами вроде «ошибка ИИ».
- У контрмер нет владельцев.
- Предупреждение используется вместо реального контроля.
- Остановка возможна, а восстановление — нет.
- Текст промпта принимается за техническое исполнение.
- Решения PDPC не попадают в план запуска.
Контрольный список качества
- Цель и условия успеха явны.
- Основные действия и зависимости видимы.
- Проблемы правдоподобны, конкретны и наблюдаемы.
- Существенные ветви приоритизированы.
- Профилактика отличается от реакции.
- У каждой реакции есть сигнал и источник мониторинга.
- У владельцев есть полномочия и срок.
- Fallback и rollback ИИ исполнимы вне промпта.
- Ветви испытаны и встроены в план.
Шаблон
| Плановый шаг | Возможная проблема | Основание | Профилактика | Сигнал | Реакция / fallback | Владелец | Срок |
|---|---|---|---|---|---|---|---|
Цель и условия успеха:
Полномочие остановки и отката:
Ветви для симуляции до запуска:
Проверка знаний
Команда пишет «внимательно отслеживать качество ИИ» как контрмеру. Чего не хватает?
A. Более яркой схемы.
B. Наблюдаемого сигнала, источника мониторинга, уполномоченного владельца и исполнимой реакции.
C. Более крупной модели.
D. Обещания полного отсутствия ошибок.
Ответ: B. Контингентный план становится операционным, только когда сигнал и ответ определены.
Связанные инструменты
- После: анализа Кепнера — Трего, модели Врума — Йеттона — Яго
- Входы риска: FMEA, защита от ошибок
- Проверка: PDCA/PDSA
- Не путать с: картой процесса, деревом решений, реестром рисков или runbook инцидента
Источники
- American Society for Quality. Seven Management and Planning Tools (откроется в новой вкладке).
- Mizuno, S., ed. Management for Quality Improvement: The Seven New QC Tools. Productivity Press, 1988.
- Brassard, M. The Memory Jogger Plus+. GOAL/QPC, 1989.
- NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0) (откроется в новой вкладке), 2023.
- NIST. Generative Artificial Intelligence Profile (откроется в новой вкладке), 2024.
Источники проверены 12 августа 2026 года.