В 2013 году множество крупных компаний на вопрос, хотят ли они внедрить у себя инструменты big data, отвечали: "Конечно! Только это какой-то космос. Мы еще подождем". Пять лет спустя компании приходят сами, причем из самых неожиданных отраслей: металлургии, авиаиндустрии, страхования.

Сейчас пальму хайпа удерживает блокчейн. О применении big data в бизнесе стали говорить меньше — и это хорошо. Значит, волна популярности прошла, а технология направилась в реальные бизнес-кейсы. Осталось только избавиться от мифа, что достаточно набросать модель на бумажке — и можно считать барыши.

Есть компания, которая производит строительный кирпич. Бизнес давно устаканился, продажи наладились, и компания решила оптимизироваться. Чтобы сократить расходы на логистику, придумали: а давайте будем предсказывать, на какой из строек заканчивается кирпич, чтобы оперативно его туда подвозить?

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

В итоге, весь бизнес-процесс требовал полной корректировки. А начиналось все с невинного "давайте предскажем".

У каждой задачи по big data есть математическая постановка и бизнес-постановка. Очень важно не упустить вторую. Иначе можно просто бросить в аналитика задачей построения модели и получить плохой результат. Поэтому прежде чем хвататься за модели, нужно пройти три пункта.

Для начала нужно согласовать названия и вехи задачи.

Допустим, мы решили построить модель оттока — предсказать, что конкретный клиент перестанет пользоваться нашими услугами и перейдет к конкуренту. Аналитик берет данные на свое усмотрение — клиентов, которые ушли и не ушли, чтобы на их основе научиться предсказывать будущий отток. Уже их мы будем мотивировать остаться.

В реальном кейсе мобильного оператора, например, отток анонимного абонента означает, что тот просто перестал пользоваться связью. Как понять, сколько времени должно пройти, чтобы его записали в "оттёкшие"?

Для определения есть разные способы. Можно взять готовый бизнес-шаблон. Можно посмотреть на исторические данные — как часто абоненты возвращаются из одномесячного оттока? Вдруг там окажется, что "возвращенцев" целых 10%? Возможно, абонент был в длительной командировке или экспериментировал с другим оператором. Считать их оттоком или нет — целиком бизнес-решение.

В любом подразделении big data должно быть минимум 2 роли (обычно больше). Первая — тот самый data scientist, который строит модели. Вторая называется по-разному — бизнес-аналитик, product owner, product manager. Этот человек должен понимать, как работает бизнес и какие инструменты будут полезны. Это не всезнайка, но коммуникатор — он может общаться и с маркетингом, и с самим заказчиком. Важно, что на нем — правильная постановка задачи.

На втором этапе мы должны понять, есть ли смысл в нашей модели.

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

Всё хорошо, но снова есть "но". На этом клиенте мы потеряем сколько-то денег. К тому же, все модели, которые мы строим, имеют погрешность. Допустим, в 20% случаев мы неправильно классифицируем клиента в отток. Значит, в 20% случаев будем совершенно за зря предлагать скидку. Много это или мало — нужно смотреть на объем клиентской базы, размер оттока и абсолютные цифры. С другой стороны, кого-то согласно расчетам мы удержим правильно.

Это так называемые ошибки первого и второго рода. Мы проверяем, что потеряем, а что — приобретем. Экономика должна сойтись. Еще до того, как строить модель, мы должны обозначить требования к ней. Может быть, требования будут такими, что и строить будет незачем.

Здесь наша задача — решить, что делать с данными.

Например, модель выдает нам 300 000 человек, которые каждый месяц могут уйти в отток. Сколько времени нам нужно, чтобы обзвонить 300 000 человек? Ресурс контакт-центра ограничен. Другой момент — если модель будет предсказывать отток на момент оттока (когда клиент уже уйдет), у нас не будет времени их обзвонить — они будут уходить раньше, чем мы успеем с ними связаться. То есть нужен запас по времени между предсказанием и коммуникацией. Но чем дальше от момента оттока, тем ниже точность предсказания. И здесь мы снова идем на риск, который должны учитывать.

Кроме того, нужно понять, как быстро позволяют реагировать на изменения наши бизнес-процессы.

Все три вышеуказанных пункта обязательны еще до привлечения математиков.

Если же все сошлось и модель мы построили, начинается вторая и самая интересная часть — интеграция в бизнес-процесс. При этом, если на построение модели и сопутствующую математику уходит 20% времени, то остальные 80% (а иногда сильно больше) — на реализацию в продуктиве. Для того же оттока нужно будет наладить работу колл-центра, IT-интеграцию, отработать воронку. И на это могут уйти месяцы — в зависимости от подвижности компании.

Модель — это всего лишь пилот, MVP (минимально жизнеспособный продукт). В big data все любят делать пилоты, потому что на модели результаты обычно хорошие. Но большинство компаний в итоге не могут внедрить их в реальные бизнес-процессы, так как бизнес-процесс изменить сложнее всего.

Поэтому в структуре любого big data проекта есть data scientist, есть product manager, который отвечает за бизнес, а есть project manager и проектная команда, которые будут внедрять это, модифицировать бизнес-процесс под результаты. И только при таком комплекте есть смысл внедрять big data решения.