П'ять порад для розробки продуктів даних

Продукти даних відіграють ключову роль у стандартизації того, як сирі набори даних, представлення сховищ даних та логічні представлення озер даних об'єднуються та використовуються для надання аналітичних можливостей та функцій штучного інтелекту (ШІ). Розробляючи продукти даних, команди можуть оптимізувати значну частину початкових конвеєрів даних, управління та менеджменту, необхідних для надання надійних активів даних, які люди, інструменти та ШІ можуть використовувати для різних цілей.

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

Коли створювати продукт даних?

Більшість організацій не можуть дозволити собі розробляти продукти даних як посередників для кожної візуалізації даних, моделі машинного навчання або агента ШІ через витрати та час. Важливо визначити пріоритети. Однією з відправних точок є розгляд продуктів даних, побудованих на основі одного набору даних. За словами Даніель Бен-Гера, віце-президента з інженерії в Crunchbase, набір даних повинен стати продуктом даних, коли кілька команд починають покладатися на нього для прийняття рішень або для живлення додатків. Це робить важливим розробку належного управління, чіткого володіння, версіонування та керованого життєвого циклу змін, щоб уникнути крихких конвеєрів.

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

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

Навіщо визначати стандарти для продуктів даних?

Подібно до того, як продукти в продуктовому магазині мають упаковку з детальним списком інгредієнтів, терміном придатності та ціною, лідери з управління даними повинні стандартизувати визначення, каталогізацію та управління продуктами даних. Абхі Шарма, співзасновник і генеральний директор Relyance AI, стверджує, що будь-який сучасний продукт даних повинен чітко відповідати на чотири питання: звідки походять дані, як вони трансформуються в системах, хто або що їх споживає, і які зобов'язання з управління застосовуються на кожному кроці. Без цього наскрізного контексту команди створюють функції на основі даних, які вони не повністю розуміють.

Хоча харчові продукти публікують свої інгредієнти, мало хто документує джерела сировини та логістику шляху від ферми до магазину. Однак при створенні продуктів даних, фіксація походження даних може бути обов'язковою в регульованих галузях і особливо важливою при стандартизації джерел даних для додатків ШІ. Картер Пейдж, виконавчий віце-президент з досліджень та розробок в Astronomer, зазначає, що без походження даних команди працюють наосліп, а управління стає реактивним. Коли команди можуть бачити, звідки походять дані, як вони були трансформовані, і кожну систему, яка на них покладається, оновлення стають передбачуваними, тестуються правильні конвеєри, повідомляються цільові зацікавлені сторони, а критичні зміни документуються до того, як вони спричинять інциденти.

Який життєвий цикл продукту даних?

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

Одна фундаментальна відмінність полягає в тому, що управління життєвим циклом продуктів даних тісно пов'язане з тим, як їхні базові набори даних зростають або зазнають структурних змін. Наявність продукту даних, який працює сьогодні, але не є стійким до змін або не генерує сповіщень, коли необхідні виправлення, може порушити подальші сценарії використання та підірвати довіру зацікавлених сторін та користувачів до даних. Бетені Сехон, старший директор з корпоративних даних у Capital One, підкреслює, що управління даними як продуктом означає, що споживачі даних можуть довіряти даним з самого початку, що вимагає стійкої та масштабованої рамки управління, яка гарантує, що дані легко знайти, зрозуміти та використовувати. Вбудовуючи спостережуваність, перевірки якості та інтероперабельність з першого дня, можна керувати повним життєвим циклом даних від версіонування та тестування до вимірювання впровадження та продуктивності.

Команди, що керують критично важливими, реальними продуктами даних, які живлять численні подальші аналітичні та ШІ-сценарії використання, повинні враховувати наступні практики DevOps та управління даними:

Встановлення безкомпромісних правил управління даними, особливо щодо встановлення еталонів якості даних, кваліфікації будь-яких упереджень даних та дотримання політик конфіденційності даних.
Підтримка розширеної безперервної інтеграції/безперервної доставки (CI/CD) та безперервного розгортання, з повністю автоматизованим безперервним тестуванням та розгортанням у виробництво.
Забезпечення того, щоб усі інтеграції даних мали спостережувані DataOps з моніторингом проблем якості даних та сповіщеннями, коли конвеєри припиняють роботу.
Визначення ІТ-послуг для обробки запитів та інцидентів.
Узгодження зі стратегіями технологічних платформ управління даними, включаючи фабрики даних, управління станом безпеки даних (DSPM), обробку документів та векторні бази даних.

Як заохотити впровадження?

На жаль, створення продукту даних не гарантує його впровадження. Це схоже на виклики повторного використання коду, впровадження API або стандартизації внутрішньо розроблених інструментів DevOps. Менеджери продуктів, які керують продуктами даних, повинні розробити програму управління змінами для збільшення впровадження та збору зворотного зв'язку. Квайс Таракі, технічний директор EnterpriseDB, зазначає, що продукт даних завойовує своє місце, коли він сприяє реальному бізнес-рішенню та йому можна довіряти в масштабі. Він радить ставитися до продуктів даних як до програмного забезпечення, з версіонуванням, тестуванням та контрольованими випусками, а не як до одноразових конвеєрів.

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

Як виміряти бізнес-цінність?

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

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

Суніл Калра, керівник центру передового досвіду Databricks у LatentView Analytics, додає, що цінність слід вимірювати через впровадження, використання та результати, такі як швидші інсайти, зменшення ручної роботи та покращення доходу або показників витрат. Найкращою практикою є використання метрик швидкості цифрової трансформації, таких як час до даних, час до рішення, час до інновацій та час до цінності. Оскільки все більше організацій прагнуть надавати бізнес-цінність від агентів ШІ, створення продуктів даних буде розглядатися як шлях до прискорення доставки, повторного використання активів даних, зменшення ризиків та управління витратами.

Що це означає для розробників

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

Ключові факти

Продукти даних стандартизують використання сирих даних, сховищ та озер даних для аналітики та ШІ.
Створювати продукти даних варто, коли кілька команд покладаються на набір даних або коли існують некеровані набори даних.
Стандарти для продуктів даних повинні відповідати на питання про походження, трансформацію, споживачів та управління даними.
Життєвий цикл продукту даних включає версіонування, тестування, розгортання та комунікацію, а також тісно пов'язаний зі змінами базових даних.
Впровадження продуктів даних вимагає програми управління змінами та розгляду їх як програмного забезпечення з версіонуванням та контрольованими випусками.