6Sigma: DMEDI

DMEDI — подход 6Sigma для создания новых решений в условиях, где заранее не очевидно, какой вариант будет правильным. Его используют, когда нужно не просто спроектировать процесс по понятным требованиям, а сначала исследовать возможные способы работы. Поэтому DMEDI ближе к задачам развития, новых услуг, нестандартных процессов и изменений, где высокая неопределённость.

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

Define: сформулировать направление

На этапе Define определяют, зачем нужен новый процесс или продукт, какую управленческую проблему он должен решить и какие ограничения уже известны. Здесь важно не делать вид, что требования полностью понятны. В DMEDI начальная формулировка часто задаёт направление поиска, а не окончательную конструкцию решения.

Результатом этапа должны быть границы задачи, участники, владелец результата и критерии, по которым можно будет сравнивать будущие варианты. Без этого исследование быстро превращается в набор идей без управленческого выбора.

Measure: собрать факты и ограничения

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

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

Explore: исследовать варианты

Explore — главный отличительный этап DMEDI. Команда рассматривает разные способы достижения цели: альтернативные процессы, роли, уровни автоматизации, схемы обслуживания, варианты контроля, порядок передачи информации. На этом этапе вредно слишком рано влюбляться в одно решение.

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

Develop: разработать выбранное решение

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

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

Implement: внедрить и удержать

Implement — это не торжественный запуск. Это перевод разработанного решения в живую работу: обучение, настройка правил, контроль первых результатов, сбор обратной связи, корректировки, закрепление ответственности. Внедрение показывает, какие допущения проекта выдержали реальность, а какие нужно пересмотреть.

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

Чем DMEDI отличается от DMADV и DMDI

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

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

Вывод

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

Для 2П такой подход близок к задачам диагностики, проектирования изменений и внедрения нового порядка работы. Когда компания ещё не понимает, какая модель ей нужна, сначала надо исследовать варианты и ограничения, а уже потом строить процесс, документы и управление.

Если DMEDI должен довести идею до внедрения

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