Проект по DMAIC: пять шагов и результат каждого

Определить

На первом шаге проблему превращают в задачу с границами. Что именно не устраивает, кого, в каких числах, где процесс начинается и заканчивается, какой результат считаем успехом.

Полезный приём — карта SIPOC на одном листе: поставщики, входы, процесс из пяти-семи шагов, выходы, потребители. Она нужна, чтобы участники одинаково понимали границы. Половина споров на поздних этапах происходит от того, что этот лист не рисовали.

Здесь же формулируют требование заказчика в измеримом виде. «Быстро» превращается в «не дольше пяти рабочих дней в девяти случаях из десяти», и с этого момента становится понятно, что считать дефектом.

Шаг заканчивается уставом на страницу, утверждённым заказчиком проекта.

Измерить

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

Пока оценки расходятся, любые выводы о причинах бессмысленны — вы измеряете разногласия оценщиков. Лечится это правилами оценки и примерами пограничных случаев; увещевания не помогают.

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

Шаг заканчивается зафиксированным исходным уровнем. Без него в конце проекта нечего будет сравнивать, и разговор об эффекте превратится в обмен впечатлениями.

Проанализировать

Задача шага — найти причины. Догадка руководителя здесь такая же версия, как остальные. Порядок работы обратный привычному: сначала собирают возможные причины широко, потом отсеивают их данными.

Практический ход — сравнение групп. Отличается ли доля дефектов по сменам, по поставщикам, по типам заявок, по дням недели. Различие, устойчивое на достаточном объёме, указывает направление; разовый всплеск чаще всего ничего не значит.

Каждую версию проверяйте обратным ходом: если убрать эту причину, исчезнет ли проблема. Половина «найденных причин» такой проверки не проходит.

Шаг заканчивается коротким списком подтверждённых причин с числами. Список из пятнадцати гипотез, ни одна из которых не проверена, результатом не считается.

Улучшить

Решения генерируют под подтверждённые причины и выбирают по двум осям: ожидаемый эффект и стоимость внедрения. Дешёвое и быстрое пробуют первым, даже если эффект скромнее.

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

Замер после изменения делают по той же методике, что и до. Смена способа подсчёта в середине проекта обесценивает сравнение, и заметить это потом почти невозможно.

Контролировать

Последний шаг отвечает на вопрос, что удержит новый уровень. Здесь пишут план контроля: показатели, частота проверки, границы, действия при выходе за них, ответственный.

Хорошая практика — встроить контроль в саму работу: обязательное поле в форме, чек-лист в шаблоне задачи, автоматическая проверка условия. Контроль, требующий отдельного усилия, отмирает первым.

Здесь же обновляют стандарт работы и обучают тех, кто в процессе. Изменение, о котором знают только участники проекта, живёт до первой смены состава.

Проект закрывают передачей владельцу процесса и возвращаются к цифрам через квартал.

Что должно получиться на каждом шаге

Проверка перед переходом к следующему шагу

Проекты растягиваются, когда шаги проходят формально: устав написан после сбора данных, причины объявлены без проверки. Пройдите по пунктам на каждых воротах.

Где в Shtab брать данные для шагов

Этап измерений начинается с истории карточек: даты переходов, время в статусах и возвраты уже записаны, и распределение сроков строится по выгрузке без ручного сбора.

Частые вопросы