Kto jest właścicielem danych?

Artykuł to fragment książki „Chief Data Officer”. Dotyka jednego z tematów dotyczących danych w organizacji. Książka skupia się na czterech aspektach niezbędnych dla pomyślnego procesu transformacji opartej na danych.

Są nimi:

1. CELE BIZNESOWE składające się na strategię,

2. DANE układające się w procesy,

3. TECHNOLOGIA — elementy tworzące architekturę,

4. LUDZIE — współpracujące zespoły.

Brak zajęcia się którymkolwiek z wymienionych tematów to przepis na porażkę! Książka wprowadza w każdy z nich i ma na celu efektywnie wesprzeć liderów danych w organizacjach.

Książka dostępna jest w przedsprzedaży prowadzonej na stronie: https://book.chiefdataofficer.pl/, gdzie można jeszcze nabyć egzemplarz z autografem.

Kto jest właścicielem danych?

Rozpoczęliśmy od procesów biznesowych, których efektem ubocznym albo głównym są dane o przebiegach tychże procesów. Pisałem o szerokim zbiorze metadanych, obejmujących całe spektrum informacji technicznych: o procesach, architekturze, modelach, strukturach, logach. W poprzednich rozdziałach otworzyliśmy temat danych biznesowych, podlegających właściwej analizie, w wyniku której wyciągane są wnioski. Te elementy budują nam perspektywę wokół danych. Pomijamy na razie technologię, którą zajmiemy się o wiele dokładniej w kolejnych rozdziałach.

Skupmy się na osobach potrzebnych do prawidłowego funkcjonowania danych w organizacji. Osoby pełniące różne role, w różnym zakresie przypisane do danych, pracujące w odpowiednim rygorze i w określonych ramach współpracują ze sobą. Aspekt ten jest niezwykle rzadko w wystarczającym stopniu zarządzany w organizacjach. Brak ustalenia podstawowych ról właścicieli, bądź gospodarzy danych powoduje, że w naturalny sposób, tam, gdzie jest to potrzebne, wyłaniają się oni sami. Zbyt małe wsparcie dla tego procesu powoduje trudności w dotarciu do potrzebnych informacji. Rolą CDO jest z jednej strony wykorzystać naturalny proces wyłaniania się ekspertów i właścicieli obszarów danych, a z drugiej strony nie dopuścić do większej niż potrzeba jego instytucjonalizacji. Zbyt duże sformalizowanie mogłoby zaburzyć naturalne, oddolne procesy. Role i odpowiedzialności to ważny aspekt holistycznego zarządzania danymi, zwanego procesem Data Governance. Nie posługuję się tym hasłem, ponieważ w wielu miejscach ma już przyjęte znaczenie i przekaz mógłby zostać odebrany w nieodpowiedni sposób. Przedstawiam najważniejsze elementy Data Governance, rozkładając je na niewielkie, pasujące do siebie i bardziej zrozumiałe elementy. Powróćmy do ról odpowiedzialnych za dane w organizacji bazującej na danych.

Z operacyjnego punktu widzenia musimy powrócić do schematu przedstawiającego cykl życia danych, który był już przedstawiany. Na na rysunku 12 widzimy dodatkowe szczegóły, są nimi obszary danych. Często będą one tożsame z systemami, które je wytwarzają, jednak nie jest to reguła. Może zdarzyć się sytuacja, że jeden obszar danych będzie obsługiwany przez kilka uzupełniających się systemów. W dalszej części mówimy o nich jako o produktach technicznych, rozwijanych w ramach zespołów AGILE. Teraz jednak skupmy się na danych, które są z nich generowane. Lokalny cel jest taki, by systemy generowały poprawne, czyste i świeże dane, które będzie można łączyć, korelować z innymi źródłami w celu dostosowania ich do formy pozwalającej podjąć lepszą decyzję biznesową niż ta podjęta bez tych danych.

Cel jest jasny, jednak nie zawsze łatwy do osiągnięcia. Już na samym początku cyklu możemy natknąć się na podstawowe problemy, takie jak niedostępność danych źródłowych i niewielki priorytet ich generowania w stosunku do innych ważnych funkcji systemu. Dane mogą napływać, jednak w niedostatecznej jakości. Podobnych problemów może pojawiać się więcej. Niewiele różniące się od siebie listy potencjalnych trudności będą obecne w każdym ze zdefiniowanych obszarów danych. Oznacza to, że każdy temat biznesowy, interesujący badacza danych, analityka raportowego u swego źródła, będzie miał wpisane ryzyko różnego rodzaju braków. Warto wiedzieć, że problemy na poziomie danych źródłowych są wystarczającym powodem do skutecznego uniemożliwienia realizacji nawet najprostszej inicjatywy biznesowej opartej na danych.



Rys. 12: Elementy typowej architektury wykorzystania danych operacyjnych na cele analityki wraz z pokazanymi obszarami danych.

Pomysłem chroniącym organizację przed niektórymi czarnymi scenariuszami jest ustalenie odpowiedniego właścicielstwa danych. Na ideę tę składa się nie tylko mianowanie osób, ale także przypisanie im długoterminowych celów związanych z wybranymi obszarami danych; często stanowisko określa się nazwą data steward. Istotne w poszukiwaniu osób do tych ról jest znalezienie w organizacji specjalistów, zajmujących się problemami danego obszaru. Tych, którzy nie mogą wykonywać swojej pracy z powodu słabej jakości danych analitycznych i operacyjnych, nie mogą podejmować decyzji w oparciu o dane z obszaru, ale posiadają wystarczającą wiedzę na jego temat. Tak zmotywowana osoba staje się optymalnym kandydatem na data stewarda obszaru. Rola właściciela obszaru danych nie jest wyłączną funkcją danej osoby w organizacji. Bardzo często sprawdza się jako rola dodawana do innych obowiązków w firmie. Czasami może pokrywać się z obowiązkami właściciela produktu technicznego — systemu stojącego u podstaw danego obszaru danych, ale nie jest to regułą.

Jak doprowadzić do ukształtowania się odpowiedniej struktury współpracy właścicieli danych? Znając zakres działalności biznesowej firmy, miejsca powstawania danych i głównych ich użytkowników, należy na początku wstępnie zidentyfikować obszary danych. Powinny one być rozłączne, nie nachodzić na siebie, nie ma nic gorszego niż nakładające się obszary odpowiedzialności. Oczywiście obszary te będą współzależne, ponieważ taka jest natura danych i biznesu. Między danymi zachodzą relacje i współpraca między właścicielami danych jest niezbędna, jednak podział musi być jak najbardziej klarowny. Powinien wynikać z żywotnych interesów komórek organizacyjnych i dobrze wpisywać się w cele tych komórek. Nie zależy nam tu na rewolucji. Warto podeprzeć się standardami rynkowymi, które dla większości branż są dostępne i pomagają dokonać inicjalnego podziału mapy danych. Podział nie musi być idealny, błędem jest przeznaczanie na to zbyt dużej ilości czasu, nie powinny to być miesiące. Wstępnie ustalony podział winien być przedmiotem rewizji i adaptacji do rzeczywistości. Nawet w tym elemencie i na takim poziomie warto używać podejścia AGILE i dostosowywać się do coraz lepiej poznawanej rzeczywistości.

Rys. 13: Przykładowy podział obszarów danych dla firmy telekomunikacyjnej.
Rys. 14: Przykładowy podział obszarów danych dla firmy mediowej.

Gdy już szczęśliwie dojdziemy do podziału obszarów danych i ich liderów, powinniśmy porozmawiać z nimi o celach, jakie chcielibyśmy osiągnąć w ramach swoich części ekosystemu danych. Mogą one dotyczyć aspektów takich, jak wymienione niżej, jednak nie jest to lista obowiązkowa, a raczej lista, którą warto się inspirować. Koncepcje, które nie dotyczą specyfiki obszaru i firmy należy z tej wstępnej listy wykreślić i skupić się na tych właściwych.

Lista potencjalnych problemów i wynikających z nich proponowanych celów działań:

Powyższa tabela pokazuje jak różne cele, wynikające z aktualnych potrzeb biznesowych i bieżących problemów może mieć data steward. Skupiając się na wybranych kierunkach, nie wolno oczywiście zapominać o podstawach, które już działają. Oprócz podejścia reaktywnego, będącego odpowiedzią na to, co firmie doskwiera w danym momencie, niezwykle istotne są nowe pomysły na wykorzystanie danych. Zarówno wykorzystanie danych z wybranego obszaru, jak i łączenia dalekich sobie obszarów jednocześnie i danych jeszcze niedostępnych w firmie. Miejscem na taką współpracę jest plan strategiczny, będący wspólnym dziełem CDO, data stewardów oraz innych niezbędnych osób.

Zachęcam do zapoznania się z całością książki: https://book.chiefdataofficer.pl/.

Mariusz Jażdżyk

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *