RUS

Целый оркестр. Почему для работы с big data одного человека мало

Заставить большие данные работать на бизнес можно. Почему в компании для этого нужна целая команда, и кто чем должен заниматься?

 

— Сколько нужно дейта-сайентистов, чтобы закрутить лампочку?

— Один, если историческая выборка успешно закрученных лампочек достаточна.

Это, конечно, шутка, но когда в какой-либо компании речь заходит о том, чтобы приручить big data для улучшения бизнес-показателей, далеко не все понимают, кто именно будет приручать. Классическое мнение: нужен дейта сайентист (data scientist) — аналитик данных, который умеет строить модели, разбирается в искусственном интеллекте и машинном обучении. И этот человек в одну голову всё порешает.

В реальности все сложнее. Без дейта сайентиста, конечно, нет и работы с big data, однако он — один в поле не воин. Кто же еще должен воевать плечом к плечу с ним, лучше понять на примерах.

 

Медиатор

Допустим, есть сеть фитнес-клубов, которая захотела использовать big data. Дейта сайентист решает задачу предсказания, что клиент помимо основных тренировок склонен воспользоваться еще какими-то персональными. Специалист берет данные, кто чем занимался раньше, и строит модель склонности.

Возникает вопрос — какими тренировками? И как мы будем предлагать, чтобы он на них сходил? Нужно будет четко разделить тренировки на мужские и женские. Разделить по бизнес-логике — если человек уже занимается с премиальным тренером, мы не должны предлагать непремиального.

Или пример из банковской сферы. В банках есть продукты, которые продаются сами по себе, а есть те, которые часто продаются вместе с другими. Мы покупаем карту или берем кредит, а параллельно нам продают страховку. Похожая история в страховых компаниях. Мы можем приобретать автостраховку, но при этом нам могут параллельно продать страховку жизни.

Так вот, если не знать бизнеса, но задача предсказать какую-то покупку есть, можно натворить следующее: “Смотрите, много наших клиентов покупает эту тренировку/страховку”. И начать строить по ней модели, чтобы стимулировать продажи. Но бизнес знает, что эта тренировка/страховка идет только совместно с чем-то. И даже модель может получиться хорошей, но продукт отдельно не пойдет.

При построении модели всегда есть набор вводных, связанных с тем, как работает бизнес. И если мы их некорректно сформулировали, то толку не будет. Поэтому помимо собственно дейта сайентиста нужен продакт оунер (product owner) — продуктовый менеджер, который подружит математику с бизнесом.

Эти две роли обязательно нужны в команде, занимающейся большими данными. Важно: если у нас несколько направлений бизнеса, то на каждое направление нужен свой продакт оунер. Дейта сайентист же может быть универсальным.

Но, как говорится, и это еще не все.

 

Программист-копатель

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

Задачи у ролей действительно разные. Дейта сайентист должен построить хорошую модель. Голова занята выбором, какие использовать признаки, кейсы, алгоритмы, как оптимизировать, чтобы модель быстро работала. А дейта инженер — это скорее программист или разработчик баз данных. Ему нужно собрать данные из 10/100/500 разных таблиц и источников, посчитать это, сопоставить то, с учетом этого, того и еще вот этого.

Важный момент: дейта инженер включается не на первом этапе. Как мы уже разбирались, цикл разработки состоит из экспериментального (MVP — минимально жизнеспособный продукт) и продуктивного этапов. Пока мы экспериментируем, очень сложно каждый раз четко описывать дейта инженеру, какие данные выгружать. Идет креатив, прорабатываются гипотезы, данные крутятся в разных вариантах. Здесь даже малейшая дискоммуникация между сайентистом и инженером отдаляет готовность MVP на недели.

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

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

В таком случае мы пробуем условно 100 кейсов, 100 MVP, из которых может выстрелить один. Если же разложить процесс построения MVP в каждом отдельном кейсе, 80% уходит на подготовку данных, 20% — на саму модель. Каждый раз данные нужно достать из разрозненных и разноформатных источников. Собрать их в логичные и понятные признаки: к примеру, “транзакция в точке N” должна превратиться в “поездка за границу столько-то раз в год”.

Эта работа занимает очень много времени. Если мы использовали какой-то вектор данных и построили модель, а она получилось плохой, мы идем обратно и снова выгружаем данные. С каждым кейсом из 100. Оптимизировать эти итерации можно только одним способом — если у нас заранее есть большая “витрина” со всеми возможными признаками — тысячами, десятками тысяч. Создать такую “витрину” — задача дейта инженера под руководством дейта сайентиста. Эксперименты ускоряются в разы — входящие параметры для моделей можно выбирать и менять быстро.

 

Дирижеры big data оркестра

Данные собрали, модель построили, с бизнесом подружили. Все?

Не все. У этой big data истории должен быть руководитель. Кажется, что эта должность самая простая и понятная, но это не совсем так. В руководителе должно сочетаться два свойства, которые обычно не очень сочетаются.

Если мы в некой компании начинаем big data с нуля, в качестве руководителя и драйвера направления нам нужен Стратег и Продавец. Он объяснит всей компании, почему работать с big data так важно. Понятно, что на старте чего-то инновационного просить предоставить четкий бизнес-кейс очень сложно — ведь он основывается на большом количестве предположений. Поэтому стратег объяснит: ребята, мы будем планировать big data по принципу “сверху вниз” (top down). И поставит цели разной степени глобальности, как то:

— чтобы через 5 лет доход от проектов, продуктов, связанных с big data, составлял 10% от нашей выручки

— сократить риски по дефолтности на 20%

— сократить 30% неэффективных офисов

и так далее.

С другой стороны этот стратег должен уметь продать идею внутри организации.

Проблема в том, что если уж такой человек нашелся, то в тактических вопросах ему сложно. Чтобы воплощать идеи стратега на физическом уровне, нужен человек операционный. Он выстроит бизнес-процессы, аналитиков, продакт менеджеров, сделает все по agile. Важно, чтобы все это работало быстро. Поэтому руководство делится на две части: стратег отвечает за светлое будущее, операционист подчиняется стратегу и реализует планы. Самостоятельно ни один из них не справится.

 

Место под солнцем

С составом определились. Осталось подчинить big data оркестр правильному департаменту.

Логично определить ее в то направление бизнеса, которое оптимизируем. Это хорошо, если компания зрелая. Тогда можно попробовать расположить big data в целевых продажах. Нужна бизнесовая ветка, чтобы все заработало. Например, для банка, если мы хотим удерживать клиентов, нужна ветка, которая умеет контактировать с выбранными моделью клиентами и собственно удерживать их. Если хотим использовать big data для планирования расположения банковских офисов, нужна ветка, которая занимается открытием этих офисов. Хотим оптимизировать данные для банковского скоринга — нужна ветка, отвечающая за риски. Без направления бизнеса, отвечающего за работу с результатами модели, ничего не выйдет.

Глобально же без поддержки напрямую сверху тема просто не взлетит — нужна все та же стратегия top down. Тем более, когда нужна поддержка направления, который и так занят своими процессами, а на всяческие инновации смотрит искоса.

Идеально big data команду распределять в подчинение куда-то повыше — гендиректору или управляющему, чье слово весомо одновременно для всех направлений компании. Это не всегда просто, но апгрейды компании и дальнейшие результаты могут оправдать все усилия.

 

Материал подготовлен в сотрудничестве с LIGA.net

02.04.2018
Что нового
Популярно
комментарии