Как мы увеличили охват и эффективность изменений в производственной компании с помощью Customer Development

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

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

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

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

К нам в дирекцию проект попал в формате нужно сделать lms на базе коробочного решения. Решение о том какую базу выбрать было достаточно быстрым - так как корпоративный сайт был на битриксе, решили сделать кастомную lms на базе битрикса, силами компании сопровождающей корпоративный сайт. Кастомную так как курсы планировали делать в scorm формате, а многие коробки не поддерживали этот формат. Это было на тот момент обязательное условие, так как предполагались материалы с моделями приборов и сложные тесты.

Достаточно быстро совместно с заказчиком написали ТЗ для подрядчика. Далее внутренний заказчик сменился, но это не остановило от реализации. Сделали решение за пару месяцев до работающего прототипа.

Для оповещения о новом инструменте использовали массовые коммуникации и спуск "сверху" на лидов направлений.

Результат был плачевный – сделали пару курсов и востребованность площадки была крайне низкой на дистанции в несколько недель. Более того большинство ЦА внутри компании толком даже не слышали про инструмент. Так же "стоимость" и "скорость" разработки scorm курсов оказалось недостаточной (1 специалист мог создавать не более 2-3 курсов в месяц)

Кажется звучит как "стандартный" неудачный проект внедрения

Решил предложить заказчику попробовать механику customer development для того чтобы понять - "а что же не так с процессами и lms". Сказано сделано, буквально за день составили скрипт для интервью и запланировали 2 встречи с продактами, проводящими обучение

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

Этот скрипт не был "жестким" и скорее общий скелет беседы, по ситуации отклонялись от него

Первые же 2 интервью дали эффект даже больше чем ожидалось – узнали основные проблемы:

В процессе самого интервью когда слышали про проблему - предлагали решение механиками lms. Например, спрашивали «а было бы удобно, если можно было выдать домашнее задание и проверить результаты?» и в конце таких встреч договаривались о конкретном действии, связанном с использованием lms, и конкретном сроке этого действия.

По итогам теста на 2 интервью:

Забавный факт – для того чтобы договориться об использовании lms не понадобилось даже ни одного скриншота и тд, что говорит о том, что гипотезы можно тестировать даже без реализации mvp.

После обхода всех продактов (порядка 30 человек) по такой механике мы получили:

Кажется это очень крутые результаты для проекта, который почти был списан в неудачные.

Так же cusdev показал себя очень дешевым инструментом для получения инсайтов и вовлечения людей в изменения.

Поскольку описанные события были в 2019м году внедрение lms оказалась еще более оправданным чем могло тогда показаться. А опыт планирования изменений с помощью cusdev еще ни раз помогал в других проектах.

А вот какие ценные знания можно вынести из этого кейса:

Спасибо за внимание, надеюсь статья будет полезна. Буду рад если в комментариях расскажете про свой опыт внедрения изменений, с какими сложностями сталкивались или опыт неочевидного использования cusdev