Six Sigma известна прежде всего циклом DMAIC — улучшением уже существующего процесса. Но у DMAIC есть структурное ограничение: он работает с тем, что уже есть, и не может дать сколь угодно высокое качество, если сама архитектура процесса или продукта изначально не рассчитана на целевой уровень дефектности. DMADV — ответ на этот случай: методология для ситуаций, когда процесса или продукта ещё не существует вообще, либо существующий настолько не соответствует требованиям, что улучшать нечего — нужно спроектировать заново, сразу под целевые показатели качества.
DMAIC чинит то, что сломано. DMADV проектирует так, чтобы не ломалось с самого начала.
Происхождение и исследовательская база
DMADV — часть более широкого направления Design for Six Sigma (DFSS), выросшего из Six Sigma (Motorola, Билл Смит, 1986; масштабно развита General Electric при Джеке Уэлче в середине 1990-х). Если базовый DMAIC создавался для улучшения существующих производственных процессов, то по мере распространения Six Sigma на разработку новых продуктов и услуг компании столкнулись с тем, что улучшать после запуска зачастую уже поздно и дорого — качество нужно закладывать на этапе проектирования. Систематическое изложение методологии дано в книге Kai Yang и Basem S. El-Haik "Design for Six Sigma: A Roadmap for Product Development" (McGraw-Hill, 2003) — в ней DMADV оформлен как отдельный, параллельный DMAIC пятифазный цикл специально для разработки нового.
Ключевые идеи и принципы
Принцип: CTQ — Critical to Quality как центральный артефакт
Всё проектирование строится вокруг CTQ-требований — конкретных, измеримых характеристик, которые критично важны для клиента (например, не абстрактное "быстрое обслуживание", а "время обработки заявки не более 10 минут"). Требования клиента переводятся в измеримые целевые значения ещё до начала проектирования, а не формулируются постфактум под уже готовое решение.
Принцип: Качество закладывается на входе, а не проверяется на выходе
В отличие от подхода "спроектировали — потом тестируем и чиним найденные дефекты", DMADV встраивает требования качества в саму архитектуру решения с самого начала — исправление ошибки на этапе дизайна кратно дешевле, чем после запуска в эксплуатацию.
Принцип: Явное сравнение альтернатив дизайна
Фаза Analyze требует не одного "очевидного" варианта, а нескольких альтернативных концепций, оцененных именно по тому, насколько каждая закрывает CTQ-требования — выбор фиксируется обоснованно, а не интуитивно.
Принцип: Верификация — обязательный, не опциональный финальный шаг
Пилотный запуск и измерение факта против целевых CTQ обязательны перед полным разворачиванием — дизайн считается готовым не тогда, когда он "выглядит логично", а когда подтверждён реальными измерениями на пилоте.
Ограничения, слепые зоны и критика
DMADV требует заметно больше времени и ресурсов на старте, чем просто "быстро запустить и доработать по ходу" — método невыгоден там, где скорость выхода на рынок важнее выверенного качества с первого раза (типичный контраст с философией MVP/Lean Startup, где сознательно выпускают несовершенный продукт ради быстрой обратной связи). Метод также требует зрелой организационной культуры измерения — если у компании нет привычки и инструментов переводить требования клиента в измеримые CTQ, DMADV превращается в формальность поверх интуитивных решений. Наконец, для действительно новых, неопределённых рынков жёсткая структура пяти последовательных фаз может оказаться избыточно тяжеловесной по сравнению с итеративными подходами.
Типовые ошибки
Ошибка 1: CTQ формулируются расплывчато, без конкретных чисел.
Требование записано как "хорошее качество обслуживания" вместо измеримого значения — дальше по методологии просто нечего верифицировать на фазе Verify.
Как избежать: Каждое CTQ-требование обязано иметь конкретное числовое целевое значение, даже если первая оценка приблизительна.
Ошибка 2: Фаза Analyze пропускается — берётся первая пришедшая в голову концепция.
Команда сразу проектирует единственный вариант вместо сравнения альтернатив — теряется главное преимущество метода, осознанный выбор лучшего решения из нескольких.
Как избежать: Всегда формулировать минимум 2-3 альтернативные концепции и сравнивать их именно по CTQ, прежде чем переходить к детальному дизайну.
Ошибка 3: Верификация проводится на самих проектировщиках, а не на реальных условиях.
Пилот тестируется в комфортных, нетипичных условиях — реальные пользователи или реальная нагрузка показали бы иной результат.
Как избежать: Пилот должен максимально приближенно воспроизводить реальные условия эксплуатации, включая нетипичные и пограничные случаи.
Ошибка 4: DMADV применяется там, где процесс уже существует и его достаточно улучшить.
Команда запускает полное перепроектирование с нуля, хотя существующий процесс требовал лишь точечного улучшения — DMAIC был бы быстрее и дешевле.
Как избежать: Прежде чем выбирать DMADV, честно оценить: процесса действительно нет или он настолько не соответствует требованиям, что легче спроектировать заново, чем чинить.
Главное, что нужно знать
DMADV — методология Design for Six Sigma для проектирования нового процесса или продукта с нуля, в отличие от DMAIC, который улучшает уже существующий. Пять фаз — Define, Measure, Analyze, Design, Verify — строятся вокруг CTQ-требований: конкретных измеримых характеристик, критичных для клиента. Качество закладывается на этапе проектирования, а не проверяется постфактум, что требует больше времени на старте, но снижает стоимость исправления ошибок в разы по сравнению с их обнаружением после запуска.
План внедрения
Месяц 1 (Define): определить, какой именно новый процесс или продукт проектируется и как цели дизайна связаны со стратегией компании.
Месяц 2 (Measure): собрать требования клиента и перевести их в конкретные измеримые CTQ-характеристики с целевыми значениями.
Месяц 3 (Analyze): сформулировать несколько альтернативных концепций дизайна и выбрать лучшую именно по соответствию CTQ.
Месяц 4 (Design): детально спроектировать выбранную концепцию, оптимизировать под целевые значения CTQ, подготовить план верификации.
Месяц 5 (Verify): провести пилотный запуск, измерить факт против целевых CTQ, подтвердить готовность к полному разворачиванию.
Далее: поддержание и обновление — после запуска CTQ-показатели продолжают отслеживаться на регулярной основе, а не только в момент верификации.
Как реализовать этот план с помощью фрейма «DMADV» в OrgDevTools
Фрейм методики «DMADV» в OrgDevTools отражает ровно структуру пяти фаз плана внедрения выше, а не абстрактный шаблон.
Пять карточек — Define / Measure / Analyze / Design / Verify — в каждой отдельно фиксируются конкретные результаты именно этой фазы (не общий список задач), соответствуя пяти месяцам плана.
Таблица «CTQ — критичные для качества требования» — центральный артефакт метода: каждое требование клиента с целевым числовым значением и весом важности заполняется на фазе Measure и остаётся видимым на протяжении всего проекта до финальной верификации.
Заполненные CTQ-требования и результаты каждой фазы автоматически становятся частью общего графа связей компании в OrgDevTools — DMADV-проект виден вместе с другими инициативами компании, не изолированно внутри одной рабочей тетради.