— Сколько нужно дейта-сайентистов, чтобы закрутить лампочку?
— Один, если историческая выборка успешно закрученных лампочек достаточна.
Это, конечно, шутка, но когда в какой-либо компании речь заходит о том, чтобы приручить big data для улучшения бизнес-показателей, далеко не все понимают, кто именно будет приручать. Классическое мнение: нужен дейта сайентист (data scientist) — аналитик данных, который умеет строить модели, разбирается в искусственном интеллекте и машинном обучении. И этот человек в одну голову всё порешает.
Также, есть тренд, что когда в компании формируется подразделение Big Data, то Data Scientistы это те, кого в первую очередь нанимают.
В реальности все сложнее. Без дейта сайентиста, конечно, нет и работы с big data, однако он — один в поле не воин. Кто же еще должен воевать плечом к плечу с ним, лучше понять на примерах.
Медиатор
Допустим, есть сеть фитнес-клубов, которая захотела использовать big data. Дейта сайентист решает задачу предсказания, что клиент помимо основных тренировок склонен воспользоваться еще какими-то персональными. Специалист берет данные, кто чем занимался раньше, и строит модель склонности.
Возникает вопрос — какими тренировками? И как мы будем предлагать, чтобы он на них сходил? Нужно будет четко разделить тренировки на мужские и женские. Разделить по бизнес-логике — если человек уже занимается с премиальным тренером, мы не должны предлагать непремиального.
Или пример из банковской сферы. В банках есть продукты, которые продаются сами по себе, а есть те, которые часто продаются вместе с другими. Мы покупаем карту или берем кредит, а параллельно нам продают страховку. Похожая история в страховых компаниях. Мы можем приобретать автостраховку, но при этом нам могут параллельно продать страховку жизни.
Так вот, если не знать бизнеса, но задача предсказать какую-то покупку есть, можно натворить следующее: «Смотрите, много наших клиентов покупает эту тренировку/страховку». И начать строить по ней модели, чтобы стимулировать продажи. Но бизнес знает, что эта тренировка/страховка идет только совместно с чем-то. И даже модель может получиться хорошей, но продукт отдельно не пойдет.
При построении модели всегда есть набор вводных, связанных с тем, как работает бизнес. И если мы их некорректно сформулировали, то толку не будет. Поэтому помимо собственно дейта сайентиста нужен продакт оунер (product owner) — продуктовый менеджер, который подружит математику с бизнесом.
Эти две роли обязательно нужны в команде, занимающейся большими данными. Важно: если у нас несколько направлений бизнеса, то на каждое направление нужен свой продакт оунер. Дейта сайентист же может быть универсальным.
Можно даже сказать, что product owner это тот, с кого все начинается. Кто придумывает кейсы применения машинного обучения в заданной компании и далее драйвит реализацию этих кейсов.
Но, как говорится, и это еще не все.
Программист-копатель
Представим, что некий банк решил продвигать специальную карточку для клиентов, которые часто путешествуют за границу. На какие исторические данные он может сориентироваться, чтобы сформировать так называемый признак? Самое очевидное — в какой-то момент времени по карте клиента была транзакция за рубежом. Признак простой, но по нему нужно дать четкие требования. Сколько раз в год были такие транзакции? В каких точках? За какой период? Все это нужно сформулировать, а далее — закодировать из простых данных, чтобы признак был правильным образом выбран. Для этого нужен отдельный человек — дейта инженер.
Задачи у ролей действительно разные. Дейта сайентист должен построить хорошую модель. Голова занята выбором, какие использовать признаки, кейсы, алгоритмы, как оптимизировать, чтобы модель быстро работала. А дейта инженер — это скорее программист или разработчик баз данных. Ему нужно собрать данные из 10/100/500 разных таблиц и источников, посчитать это, сопоставить то, с учетом этого, того и еще вот этого.
Важный момент: дейта инженер включается не на первом этапе. Как мы уже разбирались, цикл разработки состоит из экспериментального (MVP — минимально жизнеспособный продукт) и продуктивного этапов. Пока мы экспериментируем, очень сложно каждый раз четко описывать дейта инженеру, какие данные выгружать. Идет креатив, прорабатываются гипотезы, данные крутятся в разных вариантах. Здесь даже малейшая дискоммуникация между сайентистом и инженером отдаляет готовность MVP на недели.
Если точнее, то Data Engineer делает первую итерацию подготовки данных, так как если данных нет, то Data Scientistу работать не с чем. Далее, Data Scientist в итеративном режиме строит признаки (фитчи) для модели. После того, как модель получилась успешной и ее нужно перевести в продуктив Data Engineer по спецификации от Data Scientist пишет продуктивный код для регулярного расчета признака.
Поэтому текущий тренд: на 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.
Место под солнцем
С составом определились. Осталось подчинить big data оркестр правильному департаменту.
Логично определить ее в то направление бизнеса, которое оптимизируем. Это хорошо, если компания зрелая. Тогда можно попробовать расположить big data в целевых продажах. Нужна бизнесовая ветка, чтобы все заработало. Например, для банка, если мы хотим удерживать клиентов, нужна ветка, которая умеет контактировать с выбранными моделью клиентами и собственно удерживать их. Если хотим использовать big data для планирования расположения банковских офисов, нужна ветка, которая занимается открытием этих офисов. Хотим оптимизировать данные для банковского скоринга — нужна ветка, отвечающая за риски. Без направления бизнеса, отвечающего за работу с результатами модели, ничего не выйдет.
Глобально же без поддержки напрямую сверху тема просто не взлетит — нужна все та же стратегия top down. Тем более, когда нужна поддержка направления, который и так занят своими процессами, а на всяческие инновации смотрит искоса.
Хотите узнать больше об аспектах внедрения Big Data в компаниях, читайте другие наши публикации на нашем сайте или приходите на обучение в Школу Данных
Пост подготовлен Школой Данных на основе публикации основателя Школы в Business HUB ПАО «Киевстар»