Допустим, есть сеть фитнес-клубов, которая захотела использовать 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 по принципу "сверху вниз" (top down). И поставит цели разной степени глобальности, как то:

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

и так далее.

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

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

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

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

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

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