Вы уверены, что знаете причину проблемы? Проверьте гипотезу на данных 💚
➡️ Представьте онлайн-сервис доставки еды. За последний квартал доля пользователей, которые добавили товары в корзину, но не завершили заказ, выросла с 18 до 27%.
Команда предполагает: всё дело в росте цен — пользователи видят стоимость доставки и уходят. Кажется логичным, но прежде чем менять цены или запускать акции, руководитель предлагает проверить гипотезу с помощью DMAIC — методологии, которая помогает находить причины проблем в процессах и устранять их на основе данных.
Разберём весь путь на этом примере.
🔘 Define — определить проблему
Сначала команда формулирует её максимально конкретно: 27% пользователей не завершают оформление заказа после добавления товаров в корзину. Цель — снизить долю отказов до 20%.
Важно: на этом этапе команда ещё не ищет виноватого и не делает выводов о причинах. Она фиксирует что именно происходит.
🔘 Measure — измерить
Теперь команда собирает данные по всему пути оформления заказа: смотрит, на каком этапе пользователи уходят, какие устройства используют, в какое время оформляют заказ и какова сумма покупки. И обнаруживает неожиданное: почти половина отказов приходится на один конкретный шаг — ввод адреса доставки. Значит, гипотезу о стоимости доставки пока нельзя считать доказанной.
🔘 Analyze — проанализировать
Команда изучает проблемный этап подробнее и сравнивает поведение пользователей на разных устройствах. Выясняется, что на мобильных устройствах форма ввода адреса загружается значительно дольше остальных элементов. Пользователь ждёт, не дожидается загрузки и закрывает приложение. Проблема оказалась не в стоимости доставки, а в скорости работы формы.
🔘 Improve — улучшить
Команда меняет форму: сокращает количество полей и оптимизирует её загрузку. Но не выкатывает изменения сразу всем пользователям. Сначала новую версию тестируют на части аудитории и сравнивают результаты с прежней. После изменений доля пользователей, бросающих оформление на этом этапе, снижается.
🔘 Control — контролировать
На этом работа не заканчивается. Команда продолжает отслеживать ключевые показатели: долю незавершённых заказов и скорость загрузки формы. Если улучшение сохраняется, новый вариант процесса закрепляют как стандарт.
Так DMAIC помогает не спорить о том, почему возникла проблема, а последовательно проверить гипотезу, найти реальную причину и убедиться, что решение действительно работает.
У каждой фазы DMAIC есть свои цели, шаги и инструменты — и мы собрали их в подробной таблице на сайте СберУниверситета.
Переходите по ссылке, скачивайте таблицу и используйте её как пошаговую карту для усовершенствования процессов.
#экспертиза
➡️ Представьте онлайн-сервис доставки еды. За последний квартал доля пользователей, которые добавили товары в корзину, но не завершили заказ, выросла с 18 до 27%.
Команда предполагает: всё дело в росте цен — пользователи видят стоимость доставки и уходят. Кажется логичным, но прежде чем менять цены или запускать акции, руководитель предлагает проверить гипотезу с помощью DMAIC — методологии, которая помогает находить причины проблем в процессах и устранять их на основе данных.
Разберём весь путь на этом примере.
🔘 Define — определить проблему
Сначала команда формулирует её максимально конкретно: 27% пользователей не завершают оформление заказа после добавления товаров в корзину. Цель — снизить долю отказов до 20%.
Важно: на этом этапе команда ещё не ищет виноватого и не делает выводов о причинах. Она фиксирует что именно происходит.
🔘 Measure — измерить
Теперь команда собирает данные по всему пути оформления заказа: смотрит, на каком этапе пользователи уходят, какие устройства используют, в какое время оформляют заказ и какова сумма покупки. И обнаруживает неожиданное: почти половина отказов приходится на один конкретный шаг — ввод адреса доставки. Значит, гипотезу о стоимости доставки пока нельзя считать доказанной.
🔘 Analyze — проанализировать
Команда изучает проблемный этап подробнее и сравнивает поведение пользователей на разных устройствах. Выясняется, что на мобильных устройствах форма ввода адреса загружается значительно дольше остальных элементов. Пользователь ждёт, не дожидается загрузки и закрывает приложение. Проблема оказалась не в стоимости доставки, а в скорости работы формы.
🔘 Improve — улучшить
Команда меняет форму: сокращает количество полей и оптимизирует её загрузку. Но не выкатывает изменения сразу всем пользователям. Сначала новую версию тестируют на части аудитории и сравнивают результаты с прежней. После изменений доля пользователей, бросающих оформление на этом этапе, снижается.
🔘 Control — контролировать
На этом работа не заканчивается. Команда продолжает отслеживать ключевые показатели: долю незавершённых заказов и скорость загрузки формы. Если улучшение сохраняется, новый вариант процесса закрепляют как стандарт.
Так DMAIC помогает не спорить о том, почему возникла проблема, а последовательно проверить гипотезу, найти реальную причину и убедиться, что решение действительно работает.
У каждой фазы DMAIC есть свои цели, шаги и инструменты — и мы собрали их в подробной таблице на сайте СберУниверситета.
Переходите по ссылке, скачивайте таблицу и используйте её как пошаговую карту для усовершенствования процессов.
#экспертиза