Трилогия Джурана (Juran Trilogy) — модель Джозефа Джурана, которая делит управление качеством на три различных процесса: планирование качества (понять потребителя и спроектировать под него продукт и процесс), контроль качества (удерживать процесс в заданных границах) и улучшение качества (поднимать результат на уровень, которого прежде не было). Главная идея: контроль защищает от ухудшения, но сам по себе норму не повышает; для повышения нужен другой процесс — отдельный проект улучшения со своей командой, ресурсами и методикой. Модель полезна руководителям, которые видят стабильный, но неудовлетворительный уровень брака и пытаются «прикрутить гайки» дополнительными проверками. Она перекликается со статистическим управлением процессами Шухарта, циклом Деминга (PDCA) и Six Sigma DMAIC, но отвечает на другой вопрос: какой именно процесс нужен сейчас — планирование, контроль или улучшение.
Происхождение и исследовательская база
Джозеф Джуран (1904–2008) начинал инженером-контролёром на заводе Western Electric, где познакомился с идеями Шухарта, затем занимался вопросами качества как консультант и автор. В 1951 году вышло первое издание «Juran’s Quality Control Handbook» — справочника, много лет остававшегося основным изданием по управлению качеством. В 1954 году по приглашению Японского союза учёных и инженеров (JUSE) Джуран прочитал в Японии курс лекций для руководителей высшего и среднего звена; по оценкам историков, эти лекции помогли перевести японское управление качеством с уровня заводских технических специалистов на уровень управления компаниями. В 1981 году за вклад в послевоенное восстановление Японии и развитие качества он получил орден Священного сокровища второй степени.
Саму трилогию Джуран изложил в статье «The Quality Trilogy» в журнале Quality Progress (август 1986 года, том 19, номер 8, страницы 19–24). Три процесса описаны через известный график: по горизонтали время, по вертикали доля потерь на качество. В начале — этап планирования; затем идёт «нормальная» работа, где контроль удерживает потери в границах, лишь изредка реагируя на всплески (спорадические отклонения); наконец, проект улучшения снижает хроническое расточительство до уровня существенно ниже прежнего. Джуран также популяризировал в качестве принцип «жизненно важное меньшинство и полезное большинство» (позднее — правило Парето); его используют, чтобы выбрать, какие хронические проблемы решать в первую очередь (см. анализ Парето).
Три процесса трилогии определяются так. Планирование качества: установить цели, определить потребителей (внешних и внутренних), выяснить их потребности, разработать продукт и процесс, способные эти потребности удовлетворить, и передать процесс в эксплуатацию с механизмами контроля. Контроль качества: постоянно измерять фактическую эффективность, сравнивать с целями и реагировать на отклонения; в производстве это близко к статистическому контролю процессов (контрольные карты Шухарта). Улучшение качества: выбирать проблемы, формировать проекты, диагностировать причины и внедрять решения, устраняющие хроническую составляющую потерь.
Ключевая, часто упускаемая идея: хроническое расточительство сохраняется потому, что процесс контроля защищает от ухудшения, но не создаёт улучшения. Организация может годами держать процесс в стабильных, но неудовлетворительных границах, потому что полагается только на контроль.
Документированные кейсы
Трилогию удобнее всего рассматривать на реальных историях, где были и постоянное «нормальное» качество, и отдельные проекты прорыва. Оговорка: причинную связь между конкретной методикой и результатом компании в таких историях доказать трудно, а популярные пересказы часто упрощают.
Кейс 1. Лекции Джурана в Японии (1954) и рост управленческого качества
В 1954 году, по приглашению JUSE, Джуран прочитал в Японии серию семинаров для руководителей: акцент был не на статистических методах для инженеров, а на качестве как задаче менеджмента — планирование, ответственность руководства, проекты улучшения. Историки японского движения за качество отмечают, что именно этот поворот — от технического контроля на производстве к управлению качеством как функции руководства — стал важной частью последующего развития японской промышленности (наряду с работами Деминга, начатыми в 1950 году, и с собственной японской традицией). В терминах трилогии японские компании после этого не ограничились «контролем» (проверками на конвейере), а стали планировать качество на стадии проектирования и запускать проекты улучшения силами сотрудников.
Оговорки: японский подъём качества был результатом многих факторов — работы Деминга, собственных японских школ, промышленной политики, культуры труда — и приписывать его одному лектору нельзя. Кроме того, японские компании приспосабливали идеи, а не копировали их. Для аргументации ссылайтесь на историческую литературу (в том числе на исследование лекций Джурана 1954 года), а не на легенды.
Кейс 2. Motorola: проекты снижения дефектов и премия Болдриджа (1986–1988)
В 1986 году инженер Motorola Билл Смит пришёл к руководству компании с идеей, что частота скрытых дефектов связана с общим уровнем качества процесса и что процессы нужно доводить до очень низкого числа дефектов на миллион возможностей; так возникла программа Six Sigma. Идею поддержал председатель и генеральный директор Боб Гэлвин. По историческим обзорам, в 1986 году для инженеров провели трёхдневную программу «Design for Manufacturability» (около 14 тысяч участников), а в следующем году — однодневную программу «Understanding Six Sigma» для примерно 55 тысяч сотрудников без технического образования. В 1988 году Motorola получила первую Национальную премию качества имени Малкольма Болдриджа.
С точки зрения трилогии Six Sigma в Motorola — это в первую очередь третий процесс: проектный подход к улучшению с целью сдвинуть норму на новый уровень, а не просто держать процесс под контролем. При этом присутствовали и планирование (проектирование под технологичность), и контроль (измерение дефектов). Оговорки: результаты Motorola в 1980-х объяснялись не только методикой; цифры и хронология в популярных пересказах различаются; а критики Six Sigma указывают, что формализация проектов может превратить улучшение в отчётность. Как пример это полезно потому, что показывает разделение: постоянный контроль качества и проекты прорыва — разные процессы с разными людьми и целями.
Ключевые идеи и принципы
Принцип: контроль и улучшение — разные процессы, а не стадии одного
Контроль удерживает процесс в существующих границах и реагирует на отклонения от нормы: он по определению не способен поднять саму норму. Улучшение — отдельный целенаправленный процесс прорыва к иному результату, требующий проекта, ресурсов и методологии. Практический вопрос: мы решаем задачу удержания (контроль) или задачу повышения нормы (улучшение)? От ответа зависят команда, метрики и срок.
Принцип: планирование качества начинается с реального потребителя
Прежде чем проектировать продукт или процесс, нужно определить, кто является потребителем (в том числе внутренним — следующий этап процесса) и какие у него реальные, а не предполагаемые потребности. Полезные шаги: составить перечень потребителей, выяснить потребности через интервью и наблюдение, перевести их в требования к продукту и к процессу, определить, как это будет измеряться. Планирование, пропущенное в начале, превращается в бесконечное «лечение» ошибок проектирования на этапе контроля.
Принцип: различайте спорадические отклонения и хроническое расточительство
Спорадическое отклонение — внезапный всплеск над обычным уровнем: с ним справляется контроль (найти причину, устранить). Хроническое расточительство — привычный уровень брака и потерь, воспринимаемый как «нормальный»: его нельзя убрать реакцией на всплески. Оно требует проектов улучшения, направленных на причины, встроенные в процесс. Чтобы отличить одно от другого, смотрят на динамику: статистическая стабильность процесса на неприемлемом уровне — признак хронической проблемы.
Принцип: улучшение проходит проектами
Джуран описывал улучшение как последовательность проектов, каждый из которых — «проблема, поставленная к решению»: выбор проблемы по значимости, создание команды, диагностика причин («путь диагностики»), внедрение решения и закрепление результата («путь устранения»). Проекты отбирают по потерям (здесь помогает принцип Парето), а не по громкости жалоб. Без отдельных проектов улучшение остаётся пожеланием.
Принцип: как применять трилогию к задачам организации
В организациях модель переносится на услуги, процессы продаж, разработку, поддержку. Планирование — определить клиента и его потребности, спроектировать процесс. Контроль — следить за показателями (сроки, ошибки, жалобы) и реагировать на всплески. Улучшение — запускать проекты по хроническим проблемам (например, привычные 10 % возвратов). Важно разделять роли: операционная команда отвечает за контроль, а проект улучшения ведёт отдельная группа с целью, сроком и метрикой результата. Вопросы для работы: какие проблемы у нас воспринимаются как «просто так у нас»? Какие мы пытаемся решить усилением контроля? Что мы никогда не планировали заново после запуска?
Принцип: как оценивать пользу применения модели
Заранее выберите метрики. Категории устойчивы: уровень потерь на качество и его динамика; доля спорадических отклонений и хронических потерь; число запущенных и завершённых проектов улучшения; экономия или прирост результата от проектов; время от выявления хронической проблемы до старта проекта; удовлетворённость потребителей; доля доработок на этапе контроля, вызванных ошибками планирования. Если потери не снижаются, а число проверок растёт, организация лечит хроническую проблему контролем.
Ограничения, слепые зоны и критика
Трилогия — концептуальная рамка, а не набор инструментов: для планирования, статистического контроля и проектов улучшения нужны конкретные методы (интервью с клиентами, контрольные карты, DMAIC, анализ причин).
Разделение на три процесса требует управленческой зрелости: организации нередко применяют методы контроля там, где нужно улучшение, и наоборот; границы между процессами на практике размыты.
Модель разработана в производственном контексте; для сервисных и творческих процессов приходится адаптировать понятия нормы, границ и потерь, а измерение потерь бывает трудным.
Проектный подход к улучшению рискует превратиться в отчётность: проекты запускают ради количества, а не результата; критика Six Sigma отмечает эту ловушку.
Джуран акцентировал ответственность руководства, но модель не решает вопросы мотивации и культуры: без вовлечения людей и поддержки высшего руководства проекты улучшения остаются формальностью.
Исторические подробности (Япония 1954, Motorola 1986–1988) в популярных изложениях различаются; для внутренней аргументации нужно опираться на первоисточники. Модель — способ различать задачи, а не гарантия результата.
Типовые ошибки
Ошибка 1: пытаются улучшить качество усилением контроля.
Руководство реагирует на стабильный, но неудовлетворительный уровень добавлением проверок и не замечает, что контроль удерживает уровень, а не повышает его.
Как избежать
явно различать задачу удержания и задачу повышения нормы и запускать для второй отдельный проект улучшения.
Ошибка 2: воспринимают хроническое расточительство как норму.
Привычный уровень брака считается естественной характеристикой процесса и не пересматривается годами.
Как избежать
периодически запускать проекты улучшения, нацеленные именно на устойчивые, привычные потери, и выбирать их по величине потерь.
Ошибка 3: пропускают планирование качества.
Процесс запускают без определения реальных потребностей потребителей, закладывая системные проблемы, которые потом приходится «лечить» контролем.
Как избежать
начинать с определения потребителей и потребностей, и только затем проектировать процесс и систему контроля.
Ошибка 4: смешивают роли контроля и улучшения.
Одна и та же команда отвечает за оперативные всплески и за прорыв, и постоянные срочные дела вытесняют проекты улучшения.
Как избежать
разделять оперативный контроль и проекты улучшения по людям, срокам и метрикам; выделять ресурс на проекты.
Ошибка 5: запускают проекты улучшения ради отчётности.
Проекты выбирают по удобству, а не по величине потерь, и результаты измеряются числом проектов, а не снижением потерь.
Как избежать
отбирать проекты по потерям (анализ Парето), задавать цель и метрику результата и проверять эффект после закрепления.
План внедрения
Неделя 1: определить реального потребителя
Определить внешнего и внутренних потребителей ключевого процесса и выяснить их реальные потребности (интервью, наблюдение, данные жалоб). Заранее выбрать метрики.
Неделя 2: спроектировать или пересмотреть систему контроля
Настроить регулярную оценку процесса: показатели, границы, ответственный за реакцию на отклонения. Отделить спорадические отклонения от статистически стабильного уровня.
Неделя 3: выявить хронические проблемы
Найти устойчивые, воспринимаемые как «норма» потери, оценить их величину и выбрать приоритетные (например, по Парето).
Неделя 4: запустить проект улучшения
Сформировать отдельный проект с целью, командой, сроком и метрикой; определить порядок диагностики причин и внедрения решения; договориться о закреплении результата.
Далее: поддержание и обновление — при каждой проблеме качества заново решать, что нужно: контроль (удержание нормы) или проект улучшения (повышение нормы).
Как реализовать этот план с помощью фрейма «Трилогия Джурана» в OrgDevTools
Фрейм «Трилогия Джурана» — бесплатный тренажёр. Он проводит команду по трём процессам модели и по ряду показателя потерь отделяет хронический уровень от спорадических всплесков. Вкладок пять: три по процессам трилогии, диаграмма и итоги. Готовых примеров во фрейме нет: все списки пустые, подсказки стоят только в полях-заглушках.
Вкладка «1. Планирование» — неделя 1: определить реального потребителя
Это список потребностей. В каждой строке есть текст («Сборочный цех: детали без заусенцев»), две галочки — «выяснено у потребителя» и «внутренний» — и крестик удаления. Новая строка добавляется кнопкой «+ потребность». Строка с выясненной потребностью обводится зелёным. Фрейм считает долю выясненных потребностей среди непустых строк и число внутренних потребителей. Ориентир от 50 % выясненных — рабочая настройка фрейма. Ниже находится свободный список заметок «Реальный потребитель и его потребности».
Вкладка «2. Контроль» — неделя 2: спроектировать систему контроля
Таблица периодов: название («Янв») и значение показателя потерь, например брак, переделки или стоимость низкого качества. Первые периоды помечаются как «база». Их число задаётся полем «Базовых периодов», минимум 3. Если поле пустое, базой становится половина заполненного ряда с округлением вверх, но не меньше трёх периодов. Оба правила — рабочая настройка фрейма. Пустые строки в расчёт не идут, метка «база» стоит у тех же периодов, по которым идёт расчёт.
По базе фрейм считает среднее и границу контроля «среднее + 3σ» по выборочному отклонению, посчитанному по всем точкам базы. Правило трёх сигм взято из контрольных карт Шухарта, а способ оценки разброса — рабочая настройка фрейма: в классической карте индивидуальных значений разброс чаще оценивают по скользящему размаху, и тогда одиночный выброс в базе заметнее. Хронический уровень — это среднее базы без точек выше границы. Это тоже рабочая настройка фрейма: Джуран описывает хронический уровень как привычный уровень потерь, но формулы для него не даёт. Затем фрейм считает среднее после базы и сдвиг относительно хронического уровня. Снижение от 10 % считается переходом в новую зону, это тоже рабочая настройка фрейма. Всплеск — точка выше границы. В базе всплеском считается любая такая точка, после базы — только пока сдвига нет. Рядом находятся заметки «Система контроля качества».
Вкладка «3. Улучшение» — недели 3–4: выявить хронические проблемы и запустить проект
Это список проблем. У каждой есть название, поле «потери в год» (число от нуля) и галочка «есть проект прорыва». Проблема без проекта обведена жёлтым, с проектом — зелёным. Фрейм суммирует потери, показывает долю потерь под проектами и число проблем без проекта. Для итогов по команде он сортирует проблемы по стоимости. Ниже два списка заметок: «Хронические проблемы» и «Проект прорывного улучшения».
Вкладка «Визуализация» — увидеть, где нужен контроль, а где улучшение
Диаграмма строится, когда внесено хотя бы два периода. На ней ряд потерь, красная пунктирная граница контроля и оранжевая линия хронического уровня. Область под ней в периодах базы залита: это хронические потери. Подписи «новая зона» и «улучшение →» появляются, только если сдвиг достиг порога; пока его нет, зелёная линия подписана «после базы». Зелёная линия показывает средний уровень после базы, а всплески отмечены крупными красными точками.
Вкладка «Итоги» — дальше: каждый раз решать, удерживать норму или поднимать
Фрейм проверяет условия по порядку и показывает первое сработавшее:
Названо меньше двух потребностей (рабочая настройка фрейма) — 💡 «Начните с планирования».
Заполнено меньше 6 периодов (рабочая настройка фрейма) — 💡 «Внесите показатель потерь».
Сдвига нет, а у какой-то проблемы нет проекта — 🔴 фрейм называет самую дорогую из них: «Усиленный контроль не снизит привычные потери».
Сдвига нет и проблемы не названы — 🔴 «Определите проблемы для проектов прорыва».
Есть всплески — ⚠️ фрейм называет до трёх периодов и пишет, что это задача системы контроля.
Выяснено меньше 50 % потребностей — ⚠️ «Проверьте предположения».
Сдвиг от 10 % — ✅ «Переход в новую зону, закрепите новую норму».
Во всех остальных случаях — 💡 «Проекты запущены, сдвига пока нет».
Под итогами выводится сводная строка. В сохранённом документе доступна кнопка «Создать задачу», описанием задачи становится текст итогов. Название задачи совпадает с итогами по команде и берётся из той же проверки:
«Выяснить потребности у потребителей» — названо меньше двух потребностей;
«Собрать ряд показателя потерь» — заполнено меньше 6 периодов;
«Проект прорыва: …» — сдвига нет и есть проблема без проекта;
«Определить хронические проблемы» — сдвига нет и проблемы не названы;
«Разобрать всплеск: …» — есть всплески;
«Проверить потребности у потребителей» — выяснено меньше 50 % потребностей;
«Закрепить новую норму в системе контроля» — сдвиг от 10 % получен;
«Довести проекты прорыва до сдвига уровня» — проекты запущены, сдвига пока нет.
Чего фрейм не делает
Списки заметок в расчёт не идут, галочки — самооценка. Фрейм не проверяет, были ли интервью и работает ли проект.
Не требует внутренних потребителей и не следит, выбраны ли метрики заранее.
Видит только всплески вверх.
Границу считает по всей базе вместе с выбросами. Поэтому в базе до 10 периодов ни одна точка формально не может её превысить.
Делит ряд по числу базовых периодов, а не по дате старта проекта.
После перехода в новую зону границу не пересчитывает: она остаётся по старой базе, и всплески в новой зоне фрейм не ищет.
Не связывает сдвиг с проектом. Зелёные итоги возможны, даже если часть проблем без проекта.
Не делает анализ Парето, а только сортирует проблемы по стоимости. Ошибки 1–5 по-прежнему остаются на совести команды.
Заполнили фрейм? Сохраните, чтобы не потерять
Книги по теме
Дж. Джуран — «Juran’s Quality Control Handbook» (1951, многократно переиздавалась). Фундаментальный справочник по управлению качеством, включающий трилогию в позднейших изданиях.
Дж. Джуран — «The Quality Trilogy» (Quality Progress, август 1986). Статья, в которой трилогия впервые изложена системно.
Дж. Джуран — «Juran on Leadership for Quality» (1989). Развитие идей трилогии применительно к роли высшего руководства в управлении качеством.