5 кроків до побудови стратегії корпоративних даних, прямо від експерта

Дані можуть бути страшним словом.

Це не повинно бути, але це так. Здебільшого тому, що людям важко впоратися з цим.

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

Правда полягає в тому, що незалежно від розміру вашої компанії та поточного стану ваших даних, ви отримаєте користь від реалізації стратегії даних.

Щоб допомогти вам розпочати роботу, ми залучили експертів Зося Косовська, менеджер із продуктів групи бізнес-аналітики в HubSpot (тобто наш внутрішній експерт зі стратегії даних).

До того часу, коли ви закінчите читати цю статтю, ви матимете краще уявлення про поточний рівень зрілості даних вашої компанії, про те, які фактори слід враховувати, перш ніж будувати свою стратегію, а також про деякі кроки, які допоможуть на цьому шляху.

Незважаючи на поширену думку, стратегія корпоративних даних не лише для великих компаній із великими обсягами даних. Насправді малі підприємства можуть отримати вигоду від інвестування в стратегію даних на ранній стадії та закласти фундамент, який допоможе їм масштабуватися.

Переваги корпоративної стратегії даних

Загальна пастка, з якою стикаються багато організацій, полягає в тому, що, хоча вони збирають багато даних, кожна команда інтерпретує їх по-своєму. Немає стандартного методу звітування, і кожна команда може звітувати про різні значення для того самого показника.

Це означає, що всі отримують різні дані без чіткого розуміння того, що є точним. Коли немає єдиного джерела правди, стає неймовірно важко довіряти своїм даним і отримувати цінну інформацію.

«Дані існують не просто в бункері», — сказав Коссовський. «Маркетингова команда не просто використовуватиме маркетингові дані, на які жодна інша команда не має впливу. Вони також захочуть отримати інформацію з різних областей».

Вона продовжує: «Отже, елемент управління, стандартизації та спільної мови є дуже важливими для того, щоб ці команди могли спілкуватися одна з одною».

Таким чином, впроваджуючи EDS, ви запобігаєте розриву інформації, забезпечуєте довіру до даних і дозволяєте приймати рішення.

Що слід враховувати при створенні стратегії корпоративних даних

1. Ваш поточний рівень зрілості даних

Перше, що Коссовський рекомендує зробити, перш ніж будувати свою стратегію, це самооцінка.

Запитайте себе: де знаходиться ваша компанія на етапі зрілості даних?

Dell має широко розповсюджену «Модель зрілості даних», яка допомагає компаніям визначити, наскільки їх компанія насправді керується даними. Існує чотири етапи:

• Знання даних – Ваша компанія не стандартизувала свою систему звітності, і немає інтеграції між вашими системами, джерелами даних і базами даних. Крім того, бракує довіри до самих даних.
• Володіє даними – Все ще є недовіра до даних, зокрема до їх якості. Можливо, ви інвестували в сховище даних, але дещо не вистачає.
• Знання даних – Ваша компанія має право приймати бізнес-рішення на основі ваших даних. Однак між бізнес-лідерами та ІТ все ще є деякі труднощі, які потрібно вирішити, оскільки ІТ працюють над наданням надійних даних на вимогу.
• На основі даних – IT та бізнес тісно співпрацюють і знаходяться на одній хвилі. Тепер основна увага зосереджена на масштабуванні стратегії даних, оскільки фундаментальна робота (зокрема, інтеграція джерел даних) уже успішно реалізована.

Найважливішим тут є бути реалістичним щодо того, куди падає ваша компанія.

«Я вважаю, що найбільший підводний камінь, який я бачу, полягає в тому, що ви не можете бути чесним із собою щодо того, на якому етапі зрілості даних знаходиться ваша компанія», — сказав Коссовський.

Вона додає, що недостатньо дивитися на почуття, які ви відчуваєте щодо того, як дані керують вами думати ваша компанія. Подивіться на факти.

Почніть із визначення проблем із даними, з якими зараз стикається ваша компанія, оскільки це чудовий показник вашого стану.

2. Ваша галузь і розмір компанії

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

Але перш ніж ми розберемо ці підходи, давайте поговоримо про дві системи стратегії даних: напад і захист.

Під час моєї розмови з Коссовським вона згадала, як ця основа (докладно пояснюється тут) допоміг HubSpot розробити власну стратегію.

Захист даних надає пріоритет таким речам, як безпека даних, доступ, управління та точність, а захист даних зосереджується на отриманні інформації, яка дозволить приймати рішення.

Кожна компанія потребує балансу нападу та захисту. Однак деякі покладаються більше на один кінець спектру, виходячи зі своєї галузі.

Наприклад, організація охорони здоров’я чи фінансова установа, ймовірно, мають справу з дуже конфіденційними даними, де конфіденційність і безпека даних є першорядними.

Отримання даних у реальному часі та швидкого аналізу ймовірно не є головним пріоритетом, тоді як надання огорожі для того, хто може отримати доступ до даних, ймовірно. Таким чином, вони більше схилятимуться до оборонної системи.

З іншого боку, у вас є технологічні компанії, галузь, яка має тенденцію до швидкого розвитку та більшою мірою покладається на швидку обробку даних.

Отже, вони більше покладаються на напад. Зважаючи на це, безсумнівно, є відділи в технологічних компаніях (та інших галузях, що швидко розвиваються), які більше зосереджуватимуться на обороні, наприклад фінансах.

Тепер повернемося до централізованих і розподілених стратегій.

Структура, яку ви використовуєте, інформуватиме про те, яка стратегія найкраще служить вашій компанії.

У централізованій структурі у вас є команда централізованих звітів або бізнес-аналітики (BI), яка керує та готує дані, а також звіти.

«Ця [структура] може працювати набагато краще в меншій організації, особливо в організації, яка надає пріоритет обороні, тому що ви будете рухатися повільніше», — сказав Коссовський. «Ви будете вузьким місцем, але ви також маєте жорсткий контроль над кожною його частиною».

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

У цій моделі BI просто відповідає за платформи та встановлення огорожі, тоді як команди займаються розробкою, пояснює Коссовскі.

«Якщо ви думаєте про організацію, у міру того, як компанія стає більшою, з більш централізованою командою, її стає все важче масштабувати», – сказала вона. «Зрештою вам доведеться просто наймати все більше і більше людей, щоб досягти цього».

«Тож я думаю, що при певному розмірі компанії ви в будь-якому випадку будете все більше рухатися до [] децентралізованої [стратегії]».

Отже, коли ви зрозумієте, який фреймворк найкраще підходить для вашої галузі та розміру, ви зможете застосувати відповідну стратегію.

3. Ваша команда управління даними

Наука про дані зараз є гарячою темою в управлінні даними, за словами Коссовського. І вона не помиляється.

У 2012 році Harvard Business Review назвав це найсексуальніша робота 21 століття. Майже через 10 років, Glassdoor назвав її другою найкращою роботою в Америці.

Але якщо ви обговорюєте, яку роль додати до вашої команди з управління даними, фахівець з даних не повинен бути вашим першим вибором.

Коссовскі підкреслює, що ваша наука про дані буде настільки якісною, наскільки якісні дані, які її живлять. І якщо ці дані не є надійними, ви не отримаєте цінної інформації.

«Наука про дані — це не чарівна паличка, яка чарівним чином перетворює погані дані на ідеї. Незважаючи на це, вам все одно знадобиться ця база даних», – додає вона. «Тож кинутися робити щось, тому що це наступна велика справа, я вважаю, що це серйозне занепокоєння».

Якщо ви перебуваєте на ранніх стадіях моделі зрілості даних, Коссовський має пропозицію, на чому зосередити ваші зусилля.

«Архітектор сховища даних або навіть аналітик даних, який має досвід написання SQL і створення таблиць SQL», — каже вона. «Якщо ви збираєтеся найняти лише одну людину й у вас немає такої кількості даних, це може бути дуже потужним наймом, тому що одна людина може багато чого зробити, коли ви працюєте в меншому масштабі. Вони можуть носити багато різних капелюхів і вчитися різному».

Що стосується більш технічних завдань, як-от завантаження даних у сховище, існують інструменти сторонніх розробників, які ви можете використовувати, щоб зробити це за вас.

На цьому етапі вам дійсно потрібен хтось, хто допоможе структурувати ваші дані.

1. Окресліть архітектуру даних.

Перше, що ви хочете зробити, це зрозуміти свої дані на детальному рівні.

Задайте собі наступні питання:

• Де зберігатимуться дані?
• Які типи даних ви будете збирати та з яких джерел?
• Як будуть організовані дані?

Мета тут — зрозуміти структуру ваших даних.

Якщо немає розуміння структури, ви не можете побудувати вичерпний план того, як керувати своїми даними.

2. Визначте відносини між BI та вашими командами.

Коли справа доходить до стратегії даних, одним із найважливіших кроків є визначення команд, які беруть участь у процесі, і визначення очікувань для BI.

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

Це також стирає межі між ролями аналітика даних і BI.

Аналітик даних повинен знати бізнес-логіку, яка є специфічною для його команди, і структуру даних, що збираються. З іншого боку, BI не має потреби мати специфічні знання щодо операційної сфери, яку він підтримує, а натомість має зосередитися на джерелі даних і керувати платформою для підтримки аналітика.

Коли BI регулярно налаштовує свій процес відповідно до конкретної бізнес-логіки команди, це сповільнює все та створює постійну потребу в перевчанні.

Пропозиція Косівського? Видаліть бізнес-логіку з рівня BI та працюйте над тим, що стосується якомога більшої кількості команд.

Крім того, розробіть стандартний профіль аналітика та модель стосунків між BI та командами.

«Ми все ще будемо працювати над наборами даних, а не над цілою платформою, — сказав Коссовський, — але, наскільки ми можемо, ми очищаємо базові дані, полегшуючи приєднання, але не насправді виконує ці об’єднання та логіку для них».

3. Призначити право власності.

Після встановлення відносин між вашими командами та BI наступним кроком є ​​визначення того, кому що належатиме.

Як правило, для кожної частини даних є інший власник. Наприклад, одна особа або команда може володіти оперативними даними, а інша – даними звітів.

Вам також може знадобитися призначити власників на різних етапах конвеєра. Команда BI може володіти даними на певному етапі, а потім передати їх аналітикам.

Коссовський вважає, що право власності починається з команд, які створюють дані.

«Вони повинні відчувати певний рівень власності на дані та мати певний рівень відповідальності, якщо щось не так», — сказала вона. «Тому що, якщо це неправильно в джерелі, BI мало що може зробити».

Вона продовжує: «І якщо ви спробуєте вставити патчі на цьому рівні, ви просто зіткнетеся з більшими проблемами, тому цей зв’язок також важливий».

4. Встановіть управління даними.

Управління даними – це набір політик і нормативних актів, які визначають, як дані будуть збиратися та зберігатися для забезпечення точності та якості.

Простими словами, управління даними означає:Привіт, ти хочеш використовувати це джерело правдивих даних, яке ми створили, і стати його частиною? Тоді ви повинні відповідати цим критеріям."

Це може включати відповідність стандартам кодування, наявність певної кількості рецензентів і дотримання певного процесу документування.

«Коли ми думаємо про управління та усиновлення, це насправді стосується механізмів, які ви можете запровадити для дотримання», — сказав Коссовський.

Є два аспекти, які ви повинні враховувати, коли справа доходить до управління: культурний аспект і технологічний аспект.

З культурної точки зору, як змусити ваші команди прийняти ці стандарти? А з технічної точки зору, які процеси можна автоматизувати, щоб усе не вимагало зміни поведінки?

Коли ви думаєте про ці дві частини, ви повинні враховувати як сторону аналітика, так і сторону інженера (або вихідної групи).

Коссовскі пояснює, що командам інженерів може бути важко подумати про те, як виглядають дані, коли вони надходять до сховища, оскільки це не є основною частиною їхнього продукту чи відповідальності.

Вони можуть не побачити відчутних переваг даних, якщо це не керована даними організація, яка тісно співпрацює зі своїми аналітиками. У цьому випадку аналітики можуть передати, що дані обумовлюють рішення X, тому рішення приймати не можна, поки дані не означають вимоги Y.

Для аналітиків легше побачити переваги, оскільки вони ближче до бізнесу та можуть побачити прямий вплив. Вони можуть усвідомити, що дотримання стандартів керування даними означає меншу залежність від BI, що пришвидшує роботу.

«Інформація, отримана з даних, має бути основою для прийняття рішень щодо продукту, тому що це єдиний спосіб отримати продукт і команди інженерів

прийняли цінність даних і думають про свої дані під час їх експорту», ​​— сказав Коссовський.

5. Регулярно переоцінюйте.

Незалежно від моделі зрілості даних ваша стратегія даних завжди потребуватиме певних налаштувань.

«[У HubSpot] ми маємо трирічний план і всі ці ідеї щодо того, що відбувається протягом кожного з цих років», — сказав Коссовський. Але я цілком сподіваюся, що через рік, коли ми подивимося на це, є речі, які ми захочемо налаштувати на основі того, як все змінилося».

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

Навіть якщо в роботі вашої компанії немає змін, вам все одно може знадобитися переоцінка. Ось два основні показники того, що настав час переглянути свою стратегію обробки даних:

• Є розчарування через те, як довго все триває.
• Існує брак довіри до даних.

Коссовський каже, що знайти баланс між цими двома є ключовим.

«Ви не хочете, щоб BI робила все, тому що тоді це займе багато часу, – сказала вона, – але ви також не хочете мати стільки свободи серед аналітиків, щоб не можна було покладатися ні на кого дані».

Хорошим практичним правилом є перегляд стратегії кожні шість місяців або рік. Поговоріть з бізнес-лідерами, ІТ-спеціалістами та своїми командами, щоб зрозуміти, як усі ставляться до вашого прогресу, і визначити, які зміни потрібно внести.

Процес створення EDS буде відрізнятися від однієї компанії до іншої, оскільки ваш рівень зрілості даних, галузь і розмір компанії відіграють роль у кроках, які ви вживаєте.

Оцінивши поточний стан вашої компанії, ви можете розробити стратегію, яка відповідає конкретним потребам вашого бізнесу.

Джерело: https://blog.hubspot.com/marketing/enterprise-data-strategy