Цілий оркестр. Чому для роботи з 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 за принципом «зверху вниз» (top down). І поставить мету різного ступеня глобальності, як-от:

• щоб за 5 років дохід від проектів, продуктів, пов’язаних з big data, становив 10 % нашої виручки
• скоротити ризики за дефолтністю на 20 %
• скоротити 30 % неефективних офісів тощо.

З іншого боку цей стратег повинен уміти продати ідею всередині організації.

Проблема в тому, що якщо вже така людина знайшлася, то в тактичних питаннях їй складно. Щоб втілювати ідеї стратега на фізичному рівні, потрібна людина операційна. Вона вибудує бізнес-процеси, аналітиків, продакт менеджерів, зробить все по agile. Важливо, щоб все це працювало швидко. Тому управління поділяється на дві частини: стратег відповідає за світле майбутнє, операціоніст підпорядковується стратегу і реалізує плани. Самостійно жоден з них не впорається.

Із складом визначилися. Залишилося підпорядкувати big data оркестр правильному департаменту.

Логічно визначити її в той напрям бізнесу, який оптимізуємо. Це добре, якщо компанія зріла. Тоді можна спробувати розташувати big data в цільових продажах. Потрібна бізнесова гілка, щоб все запрацювало. Наприклад, для банку, якщо ми хочемо утримувати клієнтів, потрібна гілка, яка вміє контактувати з обраними моделлю клієнтами і власне утримувати їх. Якщо хочемо використовувати big data для планування розташування банківських офісів, потрібна гілка, яка займається відкриттям цих офісів. Хочемо оптимізувати дані для банківського скорингу – потрібна гілка, що відповідає за ризики. Без спрямування бізнесу, відповідального за роботу з результатами моделі, нічого не вийде.

Глобально ж без підтримки безпосередньо зверху тема просто не злетить – потрібна все та ж стратегія top down. Тим більше, коли потрібна підтримка напряму, який і так зайнятий своїми процесами, а на всілякі інновації дивиться скоса.

Ідеально big data команду розподіляти в підпорядкування кудись вище – гендиректору або керуючому, чиє слово є вагомим одночасно для всіх напрямів компанії. Це не завжди просто, але апгрейди компанії і подальші результати можуть виправдати всі зусилля.

Матеріал підготовлений у співпраці з LIGA.net