Придётся ли сотрудникам учить Python и осваивать новый софт?

Второй по частоте вопрос после разговора про данные звучит так: «Допустим, модель работает. Но моим менеджерам придётся осваивать какой-то сложный аналитический софт? Учить Python? Они и в текущей-то CRM путаются, а тут новая программа - они её просто саботируют.»

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

Разделяем, кто с чем работает

Здесь важно развести две разные роли, которые заказчик часто склеивает в одну.

С моделью работаем мы: обучение, проверка, обновление, мониторинг качества. Это наша сторона, и Python со всем аналитическим инструментарием остаётся у нас. Ни один менеджер к этому не прикасается.

Сотрудник работает с результатом, а не с моделью. А результат - это несколько понятных значений: балл вероятности оттока клиента, приоритет заявки, подсказка «сейчас лучше предложить вот это». Чтобы этим пользоваться, не нужно ничего знать про то, как оно посчитано, ровно как водителю не нужно разбираться в устройстве двигателя.

Куда попадает результат

Прогнозные значения не живут в отдельном окне, куда надо специально заходить. Они выгружаются через API прямо в те системы, где менеджер уже работает.

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

Интерфейс при этом не меняется. Менеджер открывает ту же карточку в той же программе, к которой привык, и видит на одно-два поля больше. Осваивать нечего, потому что осваивать нечего - привычка работать в системе остаётся прежней.

Почему через API, а не отдельным окном

Отдельная аналитическая панель, куда сотрудник должен переключаться, - это как раз то, что не приживается. Человек в потоке работы не будет открывать вторую программу, сверяться и возвращаться. Он забудет про неё через неделю.

Подсказка работает только тогда, когда она возникает в момент решения и в том месте, где решение принимается. Поэтому мы отдаём результат туда, где уже идёт работа, - в CRM, ERP или 1С через их программные интерфейсы. Техническая сторона интеграции ложится на нас и на вашу ИТ-службу, а не на менеджеров.

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

Что всё-таки меняется

Честно: совсем без изменений не обойдётся, но касаются они не навыков, а привычек.

• Менеджеру стоит привыкнуть доверять приоритету и обращать внимание на метку. Это вопрос не обучения, а нескольких недель работы и пары примеров, когда подсказка оказалась к месту.
• Руководителю нужно договориться, что список заявок теперь сортируется по баллу, а не по дате. Это управленческое решение, не техническое.
• Кому-то из вашей ИТ-службы мы передаём, как устроена интеграция, чтобы её можно было поддерживать. Вот здесь техническая сторона есть, но это один-два человека, а не весь отдел продаж.

Никто не идёт на курсы Python. Предиктивная аналитика, сделанная правильно, для конечного пользователя выглядит как «в моей привычной программе появились полезные подсказки», а не как «нам поставили новую систему».

Итого

Сопротивление персонала возникает там, где людей заставляют менять инструмент. Мы инструмент не меняем: модель остаётся у нас, а её результат приходит к сотруднику в привычное окно через API. Учиться программировать никому не придётся.

Как именно результат ляжет в вашу конкретную CRM или 1С, зависит от их возможностей по интеграции - это проверяется на предварительном аудите вместе с оценкой данных, о которой шла речь в прошлый раз.