Что мешает успешно совместить математику и бизнес?
Этот текст — первая из серии статей о том, как корректно встроить инструменты big data с выгодой для бизнеса.
Маленький спойлер: все получится, если помнить о самом бизнесе.
Еще 5 лет назад крупные компании хотели внедрить у себя новомодную “бигдату”. Но настоящих экспериментаторов было мало. Исключениями стали те, кто точно обладал массой данных: телеком, банковский сектор, интернет-компании. А в 2018 году за экспертизой в больших данных бизнесы приходят сами, причем из самых неожиданных отраслей: металлургия, страхование, авиаиндустрия.
С чего начинается модель?
Big data перестала быть волшебной мантрой (теперь эту корону носит блокчейн). Но пока не избавилась от главного мифа:
“Более-менее адекватный математик может набросать на бумажке модель, ее быстренько внедрят, а после этого можно потягивать коктейль и наблюдать за ростом продаж”.
Я утрирую, конечно, но не очень сильно. Приведу пример из нашей практики.
Есть компания-производитель строительного кирпича. Немелкая, с опытом и налаженными продажами. В такие моменты в компаниях нередко задаются вопросом: а как бы нам еще уменьшить издержки и увеличить прибыль?
Кандидатом на улучшение стала логистика. В доставках кирпича было много хаоса, трудно было заранее оценить клиентский спрос, поэтому расходы на ГСМ и амортизацию транспорта нервировали. Узнав о big data, в компании решили: будем предсказывать, когда на клиентских стройках закончится кирпич, чтобы оперативно его туда отправлять. Проанализировали предыдущие данные, сделали модель, которая пообещала интересные проценты оптимизации.
Всю радость поломал привычный порядок. Во-первых, нужно было найти машины для оперативной доставки и продумать маршруты. Во-вторых, эти машины могли заехать на склад для загрузки только в строго определенные тайм-слоты, потому что график приезда клиентских машин был составлен на несколько недель вперед. Двигать клиентов было нельзя. Поэтому оперативность шла прахом.
Получилось, что начали с обычного “давайте предскажем”, а закончили на трансформации бизнес-процесса.
Задача по big data имеет две постановки: бизнес и математику. И порядок их именно такой. Прежде чем сажать аналитика за построение модели, нужно пройти три этапа.
1. Определить задачу с точки зрения бизнеса.
Допустим, мы хотим бороться с оттоком клиентов. И решили предсказывать, что определенная группа покупателей близка к тому, чтобы уйти к конкуренту. Для них мы будем формировать всяческие плюшки, чтобы удержать.
Задача на первый взгляд тривиальная. Аналитик строит модель на исторических данных — ушедших и постоянных клиентах — чтобы вывести признаки тех и других. Например, в реальном кейсе сотового оператора отток анонимного абонента = абонент перестал пользоваться связью. Но сколько времени — неделю, месяц, год — он должен не включаться, чтобы его записали в “оттекшие”?
Определить эту задачу можно по-разному. Можно по готовому бизнес-шаблону. Или по историческим данным — как часто возвращаются абоненты, которые не пользовались связью месяц? А если таких — целых 10%? К примеру, абонент был в долгосрочной командировке или повелся на ограниченную акцию другого оператора.
Здесь важно: кого считать “отточниками” — полностью бизнес-решение.
Необходимый минимум любого подразделения big data — 2 роли. Первая — data scientist, на котором математика и построение модели. Вторая от команды к команде именуется по-разному — product owner, product manager, бизнес-аналитик. На совести этого человека корректная постановка задачи. Его миссия — вникать в тонкости бизнеса заказчика и подбирать нужные ему инструменты. Причем вникать в активной коммуникации со всеми сторонами.
2. Проверить бизнес-кейс.
Окей, определимся мы с моделью. Но во сколько нам обойдется оптимизация?
Возьмем тот же отток. Чтобы удержать потенциально уходящих клиентов, можно позвонить или маякнуть правильным сообщением. Или, если есть ресурс, предложить бонус. Можно подсказать клиенту более экономически интересный тариф, проанализировав его расходы.
Но раз уж мы задумались о бонусах, то это — наши траты на подобных клиентов. И ладно бы мы точно знали, что этот клиент уйдет, если ничего не предпринять. Но модели неидеальны в своих предсказаниях. Кого-то мы удержим правильно. А, например, 20% потенциальных “отточников” на самом деле таковыми не будут являться. При это мы будем предлагать бонусы и им. Сколько на это потратится денег, допустимо ли это в нашем случае — нужно смотреть на объем клиентской базы, масштабы оттока и считать абсолютные цифры.
Это называется ошибками первого и второго рода. Мы должны понимать, что результаты внедрения модели дадут больше, чем отнимут. И это должна быть приемлемая для нас разница. Требования к модели формируются прежде ее построения. Может быть, они выйдут такими, что и тратить время дейта-сайентиста будет незачем.
3. Спланировать, как будут использоваться результаты.
“Экономика сошлась, — говорит нам бизнес-кейс. — Можно уже наконец строить модель?”
Рано. Нужно продумать, что будет происходить с результатами.
Вот выдаст нам модель 200 000 человек, которые ежемесячно могут превратиться в “отточников”. И мы решим их обзванивать. А успеем ли пройтись по всем? Контакт-центр ведь не резиновый.
Другой момент — нужно понять, какой лаг по времени у нас будет между предсказанием ухода и реальным уходом клиента. Зачем нам предсказание, если клиент “оттечет” в очень ближайшее время? Ведь тогда мы можем не успеть с ними связаться. Но и чем дальше от момента ухода мы даем ответ, тем ниже точность предсказания. Здесь снова приходится высчитывать оптимум между плюсами и рисками.
И третий момент — как быстро мы сможем имплементировать новшества в наши бизнес-процессы? Чтобы не получилось, как с примером о производителе кирпича.
В заключение
Путь к четкой задаче для дейта-сайентиста сам по себе является задачей.
Если же все три пункта мы проверили, все сложилось и появилась модель, нас ждет следующий веселый этап — интеграция. Построение модели и смежная математика обычно занимает около 20% времени. Остальные 80% (а иногда гораздо больше, в зависимости от гибкости компании) — реализация в продуктиве. Вплоть до нескольких месяцев.
Модель — это только MVP. Все любят их строить, потому что гипотетические результаты всем нравятся. А потом внедрение их в реальные бизнес-процессы буксует в большинстве компаний. Ведь самое сложное — изменить отлаженные порядки.
Поэтому в любом big data проекте должен быть data scientist, на котором математика, product manager, отвечающий за бизнес, и project manager с проектной командой. Последним предстоит заниматься внедрением и перетряхивать бизнес-процесс. Иногда больно и тяжело. Но только в такой конфигурации работа с big data может принести выгоду.
Этим и прочим особенностям применения аналитики данных в бизнесе мы учим в нашей Школе Данных на курсах для аналитиков и для менеджеров.
Пост подготовлен Школой Данных на основе публикации основателя Школы в Business HUB ПАО «Киевстар»
Автор: SergeyMarin
