Как мы увеличили охват и эффективность изменений в производственной компании с помощью Customer Development
Статья про мой опыт внедрения изменений в производственной компании, где я был тогда руководителем проектов в дирекции по организационному развитию. Рассмотрим почему лучше сначала пообщаться с конечными пользователями и по исследовать, то как работает сейчас, и только потом бежать в разработку решения, а так же сделаем какие то выводы по внедрению изменений и автоматизации процессов.
Введение
Изменения в компаниях обычно внедряются тяжело, особенно если у компании нет культуры массовых коммуникаций или компания занимается физическим бизнесом, где скорость изменений и «инертность» процессов еще выше чем в IT.
Проблема
Производственная компания промышленной автоматизации, где я работал не имела своих фирменных магазинов и продавала продукцию через сеть партнеров - дилеров. Новые устройства, особенно если это не обновление текущей линейки, обычно буксовало на старте продаж. Для борьбы с этим компания, силами продактов линеек товаров и обучающего центра профессиональных компетенций, организовывала вебинары и оффлайн семинары по своей продукции.
Гипотеза решения
Гипотезой центра компетенций (заказчика изменений) было - лучше знающие продукцию и ее возможности дилеры смогут лучше продавать продукты компании. Основная идея заключалась в создании системы дистанционного обучения, которая была бы удобной для дилеров, позволяла бы проводить тестирование после обучения и уменьшать затраты на обучение.
Этап 1: Разработка lms
К нам в дирекцию проект попал в формате нужно сделать lms на базе коробочного решения. Решение о том какую базу выбрать было достаточно быстрым - так как корпоративный сайт был на битриксе, решили сделать кастомную lms на базе битрикса, силами компании сопровождающей корпоративный сайт. Кастомную так как курсы планировали делать в scorm формате, а многие коробки не поддерживали этот формат. Это было на тот момент обязательное условие, так как предполагались материалы с моделями приборов и сложные тесты.
Достаточно быстро совместно с заказчиком написали ТЗ для подрядчика. Далее внутренний заказчик сменился, но это не остановило от реализации. Сделали решение за пару месяцев до работающего прототипа.
Этап 2: Внедрение решения через "стандартный сценарий"
Для оповещения о новом инструменте использовали массовые коммуникации и спуск "сверху" на лидов направлений.
Результат был плачевный – сделали пару курсов и востребованность площадки была крайне низкой на дистанции в несколько недель. Более того большинство ЦА внутри компании толком даже не слышали про инструмент. Так же "стоимость" и "скорость" разработки scorm курсов оказалось недостаточной (1 специалист мог создавать не более 2-3 курсов в месяц)
Кажется звучит как "стандартный" неудачный проект внедрения
Этап 3: А что если попробовать использовать cusdev
Решил предложить заказчику попробовать механику customer development для того чтобы понять - "а что же не так с процессами и lms". Сказано сделано, буквально за день составили скрипт для интервью и запланировали 2 встречи с продактами, проводящими обучение
За основу взяли механики про которые рассказывал Иван Замесин в видео для школы менеджеров яндекса. Тут про исследовательное интервью и тут про решенческое. Для нашего случая решил сделать микс между исследовательским и решенческим. Так как решение уже было готово и основная идея - выявить боли и попробовать их закрыть готовым инструментом,
Этот скрипт не был "жестким" и скорее общий скелет беседы, по ситуации отклонялись от него
Первые же 2 интервью дали эффект даже больше чем ожидалось – узнали основные проблемы:
- доходимость до вебинаров
- невозможность собрать всех слушателей за раз
- необходимость каждый раз рассказывать один и тот же материал
- невозможность проконтролировать усвояемость материала
В процессе самого интервью когда слышали про проблему - предлагали решение механиками lms. Например, спрашивали «а было бы удобно, если можно было выдать домашнее задание и проверить результаты?» и в конце таких встреч договаривались о конкретном действии, связанном с использованием lms, и конкретном сроке этого действия.
По итогам теста на 2 интервью:
- мы потратили суммарно 1-1.5 часа (что достаточно мало)
- получили инсайты по изменению процессов (за рамками lms)
- получили 2 новых пользователей lms, до которых не достучались другими каналами коммуникаций.
- на базе конкретики появился рычаг взаимодействия и дальнейшей интеграции lms в процессы.
Забавный факт – для того чтобы договориться об использовании lms не понадобилось даже ни одного скриншота и тд, что говорит о том, что гипотезы можно тестировать даже без реализации mvp.
После обхода всех продактов (порядка 30 человек) по такой механике мы получили:
- временные затраты всего 1-2 недели
- Больше 70% продактов зашли в lms
- больше 50% подали заявки на заведение их материалов как курсов на платформу
- добавление результатов тестирования в аккредитацию для дилеров и другие изменения процессов
- Использование lms в процессах компании (hr и подготовке инженеров)
Кажется это очень крутые результаты для проекта, который почти был списан в неудачные.
Так же cusdev показал себя очень дешевым инструментом для получения инсайтов и вовлечения людей в изменения.
Выводы
Поскольку описанные события были в 2019м году внедрение lms оказалась еще более оправданным чем могло тогда показаться. А опыт планирования изменений с помощью cusdev еще ни раз помогал в других проектах.
А вот какие ценные знания можно вынести из этого кейса:
- Внутренние изменения такой же продукт, которому нужна маркетинговая поддержка и продажи аналогичные продажам внешних продуктов
- Внедрение изменений сверху вниз может иметь высокий уровень сопротивления и не иметь необходимого эффекта
- Массовые каналы коммуникаций с высоким охватом облегчают внедрение изменений, но нельзя рассчитывать только на них
- Использование подхода cusdev позволяет дешево выявить более детально проблематику и сделать более эффективное решение ДО старта работ по разработке решения
- Если охват изменениями не очень большой – встречи 1в1 и продажа пользы от изменений конечным пользователям наиболее эффективный способ внедрения изменений
- Автоматизация не должна являться самоцелью и должна, в первую очередь, улучшать уже существующие процессы
- Если автоматизация создает новые процессы – они должны быть созданы и поддержаны уже на этапе разработки
- Использовать короткие и дешевые решения (коробки) эффективнее для теста гипотезы. Дальнейший переход на свои решения проводить уже в рамках улучшения метрик процессов
Спасибо за внимание, надеюсь статья будет полезна. Буду рад если в комментариях расскажете про свой опыт внедрения изменений, с какими сложностями сталкивались или опыт неочевидного использования cusdev