Школа Данных: как совместить математику и бизнес +6


image

Что мешает успешно совместить математику и бизнес?

Этот текст — первая из серии статей о том, как корректно встроить инструменты 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 ПАО «Киевстар»

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (8):

  1. TiesP
    /#18814391

    На вторых курсах написано "Начало следующего курса 10-го мая. Запись открыта". Имеется в виду какой год? Если это 2018, то интересно, когда следующий такой курс будет. Ну а если 2019, то вопросов нет)

    • SergeyMarin
      /#18814429

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

  2. dididididi
    /#18814535

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

    • SergeyMarin
      /#18814553

      Добрый день! В этом как раз и суть, что дело часто не только в количестве данных. В данном примере с заводом нужно учитывать не количество клиентов (которое действительно измеряется десятками), а количество данных позволяющих предсказывать остатки материалов. Бизнес-кейс в том, что если на стройке заканчиваются материалы, то закупки часто осуществляются у доступного на тот момент поставщика, что означает потери бизнеса для клиента

      • Neikist
        /#18815525

        Не только в количестве данных, но количество — обязательный компонент. По определению. Да и для биг даты, внезапно, data scientist(и то громковато звучит) не обязателен. Он обязателен для анализа данных, дата майнинга. А для биг даты нужны как раз спецы по работе с большими данными.

        • SergeyMarin
          /#18815553

          Скорее наоборот: Big Data слишком широкой (но удобный для понимания) термин также включающий в себя машинное обучение, анализ данных. Большое количество кейсов даже когда данных реально много рождаются из Small Data

          • Neikist
            /#18815599

            Вы все же имеете в виду дата майнинг, потому что например ваш кейс из статьи никак не требует распределенных вычислений, кучи серверов, и террабайт/петабайт данных. А также технологий для обработки всего этого. Если говорить про кейс кирпичного завода это и вовсе на 1С сделать можно.
            Хотя все же самое правильное — просто анализ данных. Т.е. конечно понятно что хочется модных слов и терминов, но это все же не в ту степь, имхо.

          • fingoldo
            /#18817875

            Сергей, мне кажется, Вы подменяете понятия. За статью, однако, благодарю )