Ład Danych (Data Governance) oraz Zarządzanie Danymi (Data Management) to koncepty mocno ze sobą powiązane, przez co często używane są zamiennie. W języku polskim jest to jeszcze bardziej mylące, ponieważ można o nich mówić jako o Zarządzaniu – co nie jest aż tak drastycznie nieprawdziwe.
Zacznijmy od książkowych definicji z DMBOK.
“Data Governance to sposób sprawowania zwierzchnictwa oraz kontroli (planowania, implementacji, monitoringu, wykonywania) zarządzania zasobów informacyjnych.”
“Data Management to rozwój, wykonywanie, nadzór planów, polityk, programów i praktyk dostarczających, kontrolujących, chroniących oraz zwiększających wartość zasobów informacyjnych w trakcie trwania ich życia.”
Definicje te zatem można zwizualizować następująco:
Jak to wygląda w praktyce
Zespół Ładu Danych jako scentralizowana jednostka spotyka się raz w tygodniu, aby zrobić przegląd aktualnych postępów związanych z Danymi w organizacji. Przegląd zawiera zagregowane metryki dotyczące zespołów oraz produktów informacyjnych, a także wszelkich inicjatyw z nimi związanych. Jeżeli coś wymaga poprawy, zmiany lub restrukturyzacji to ten zespół powinien jasno zdefiniować swoje rekomendacje oraz przekazać je do zespołów Zarządzania Danymi.
Zespoły Zarządzania Danymi jako zdecentralizowana jednostka spotyka się raz dziennie w celu zrozumienia aktualnych priorytetów, projektów oraz potencjalnych zagrożeń, aby odpowiednio pracować ze swoimi zespołami w celu dostarczenia wartości z danych. Ich praca musi być zgodna z wizją zespołu Ładu Danych, od którego otrzymują rekomendacje.
Podsumujmy
Warto zwrócić uwagę na sposób współpracy: scentralizowany zespół ma lepszy ogląd na całokształt, dlatego też są w stanie wystosować trafne rekomendacje (nie nakazy), których wykonanie leży po stronie wielu mniejszych zespołów Zarządzania Danymi, bądź po prostu samych przedstawicieli domen, którzy dzielą pracę pomiędzy swoje mniejsze zespoły.
Proces ten będzie różny w zależności od wielkości organizacji – mniejsze będą miały mniej poziomów, natomiast większe powinny zadbać o to, aby wysokość hierarchii nie zablokowała transferu wiedzy oraz komunikacji wzwyż i wszerz.
Informacje wykorzystywane są od zarania dziejów, przede wszystkim do upewniania się, że nasze decyzje są trafne, co niezaprzeczalnie zwiększa jakość naszych działań.
Z czasem tworzymy coraz to bardziej złożone byty, struktury, czy organizacje. Proces ten w dużej mierze bazuje na danych oraz ich poprawnym wykorzystaniu. Oznacza to, że ich wartość rośnie z czasem – dziś jest to niezwykle cenny zasób mówiący o tym, czy przedsiębiorstwo jest rentowne. Fakt ten staje się także coraz bardziej widoczny i oczywisty.
Praca z samą informacją, jej zdobywanie i składowanie może nie wydawać się aż tak trudnym zadaniem. Problemem jest jednak jej odpowiednie przygotowanie oraz udostępnianie, gdyż każdy człowiek inaczej rozumie świat, ma inny punkt widzenia, doświadczenia oraz cele i preferencje. Często zdarza się, że mówimy o tej samej rzeczy, zgadzamy się ze sobą, a ostatecznie myślimy o czym innym, przez co podejmowane akcje drastycznie się różnią.
Zbudowanie wspólnego języka oraz modelu świata, w którym współpracujemy jest kluczowym aspektem każdego zespołu. Jest to szczególnie istotne przy pracy z danymi oraz w innowacyjnych środowiskach. Pozwoli to na spójne i świadome podejmowanie decyzji, co znacznie zwiększy ich jakość i zredukuje ilość nieporozumień i przestojów z nimi związanych.
Koncepty do zaaplikowania w świecie Danych
Tworzenie rozwiązań w dużej skali niewątpliwie sprawia, że wszystko jest o wiele trudniejsze, zwłaszcza pod kątem zasad, procesów oraz zarządzania. Mikroserwisy nauczyły nas, że małe i niezależne komponenty komunikujące się ze sobą asynchronicznie poprzez wzorzec X-as-a-Service sprawdza się w dużej skali. Pomysł ten sam w sobie wywodzi się z Filozofii Unixa z 1978 roku1, która mówi o 4 zasadach:
Upewnij się, że program robi tylko jedną rzecz, i robi to dobrze. […]
Oczekuj tego, że wyjście jednego programu staje się wejściem kolejnego, niekoniecznie już znanego. [..]
Buduj systemy i testuj je tak szybko jak to możliwe. […]
Używaj narzędzi prostych w obsłudze, aby wesprzeć innych ich użytkowników. […]
Dla praktyków metodologii DevOps zasady te na pewno są znane – małe iteracje, szybka informacja zwrotna, luźno sprzężona architektura, kultura innowacji.
Zasady DevOps
W 2018 roku wyszła publikacja, która naukowo zbadała i potwierdziła przydatność techniczną i biznesową tych założeń2, dzięki czemu mamy pewność, że tą to koncepty warte wdrożenia.
Ostatecznie powinniśmy być kolejnego konceptu sprzed dekad – Prawa Conway’a. Nie spełnia ono co prawda wymogów bycia pełnoprawnym prawem, choć doczekało się wielu badań potwierdzających jego prawdziwość3. Mówi ono o tym, że komunikacja pomiędzy pracownikami i zespołami znacznie wpływa na architekturę systemów, które zespoły te wytwarzają.
“Każda organizacja, która tworzy systemy (szeroko rozumiane) stworzy system, którego architektura jest kopią struktur komunikacyjnych tej organizacji.”4
Dzięki temu wiemy, że informacja, jak i sposób jej przekazywania znacznie wpływa na jakość oprogramowania. Implikuje to fakt, że kultura jest niezwykle istotna – definiuje jakość organizacji.
Jak widać Prawo Conway’a (1967), Filozofia Unixa (1978) oraz DevOps (2009) dają nam wiele wskazówek dotyczących tego jak efektywnie pracować z, i skalować systemy informacyjne. Skalowanie organizacji może wyglądać bardzo podobnie, zwłaszcza w świecie danych.
Sposoby pracy z Danymi
Dane wnoszą o wiele więcej złożoności, a także potencjalnej wartości, ze względu na fakt, że dodajemy nowe typy systemów i przepływów do naszych architektur. To samo dotyczy AI w ostatnich latach.
Jest to możliwe dzięki odpowiednim metodologiom programistycznym. AI nie może być stabilne i niezawodne, jeśli nie mamy odpowiednich fundamentów danych, które obejmują właściwą kulturę i zarządzanie.
Doświadczenie pokazuje, że świat danych wciąż jest mocno chaotyczny i nieuporządkowany, jednak sytuacja znacznie się poprawia dzięki technologii (m. in. MS Fabric lub Purview, Snowflake, BigQuery lub Redshift) oraz świadomości (m. in. Data Management Body of Knowledge). Jednak nadal brakuje wielu ludzi, kompetencji, budżetu i ustalania odpowiednich priorytetów.
Ostatnie dekady w świecie Danych koncentrowały się na jednym scentralizowanym źródle prawdy, co jest świetnym pomysłem, który pomógł nam osiągnąć dzisiejszy poziom zaawansowania. Jednak w tym przypadku Prawo Conway’a sugeruje, że centralizacja informacji implikuje posiadanie pojedynczego zespołu odpowiedzialnego za nią, co tworzy wąskie gardło zgodnie z zasadami DevOps i zdecydowanie nie jest wspierane jest przez Filozofię Uniksa.
Może to nie być wystarczające, ponieważ nie możemy w nieskończoność skalować pojedynczego zespołu, o czym dobrze mówi Liczba Dunbar’a5. Takie skalowanie zgodnie z Filozofią Unixa oraz DevOps się nie utrzyma. Oprogramowanie poradziło sobie z tym poprzez asynchronizację komunikacji oraz elastyczne skalowanie poprzez Cloud Computing oraz Mikroserwisy.
Jak w takim razie możemy zaaplikować to do naszych zespołów? Rozwiązaniem zdaje się być Data Mesh szerzej opisany w tym artykule.
Filary Data Mesh i relacje między nimi
Zamiast tworzyć fizycznie scentralizowany zespół oraz oprogramowanie (Data Warehouses, Data Lakes, Data LakeHouses) możliwe jest utworzenie spójnego i ujednoliconego widoku na fizycznie rozproszone dane, przy pomocy technik wirtualizacji, oraz rozproszyć właścicielstwo poszczególnych zbiorów danych, zapewniając przy tym spójne procesy komunikacji pomiędzy producentami oraz potencjalnymi konsumentami. Usprawni to komunikację, a co za tym idzie – architektury systemów, kulturę oraz zwiększy ilość innowacji. Wynikiem będzie minimalizacja zależności oraz szybkie testowanie zmian, co jest bezpośrednio promowane przez Filozofię Unixa, Prawo Conway’a oraz kulturę DevOps.
Dane jako pełnoprawne Produkty (zapewnianie odpowiedniej jakości oraz budżetów dla Danych, a także dedykowanych od nich specjalistów)
Samoobsługowa Platforma Danych (ujednolicony wgląd, decentralizacja oraz asnychronizacja prac nad informacjami w celu zapewnienia możliwości innowacji, o czym mówi podejście mikroserwisowe)
Rozproszone zarządzanie zasadami i procesami (dzielenie się wiedzą wewnątrz domeny oraz pomiędzy nimi).
Podsumowanie
W ciągu ostatnich dekad przeprowadzono wiele badań mających na celu usprawnienie pracy z oprogramowaniem. Powstało wiele konceptów i metodologii, które mniej lub bardziej się sprawdzały i są dziś wykorzystywane na co dzień. Teraz potrzebujemy upewnić się, że świat Danych nie pozostaje w tyle. Prawo Conway’a jasno wskazuje co powinniśmy zrobić w związku z powyższymi założeniami. Przede wszystkim należy zadbać o kulturę oraz świadomość w tym zakresie tak, abyśmy sami mogli usprawniać naszą codzienną pracę. Założenie to wsparte jest także przez tzw. Turkusowe Organizacje.
Data Mesh wywodzący się z systemów rozproszonych jest bardzo odważnym konceptem, który ma zastosowanie oraz odpowiednie uzasadnienie. Niestety wiele implementacji pokazało jak trudne jest rzeczywiste wdrożenie. Jest to wciąż koncept eksperymentalny i wymaga wielu lat edukacji, pracy, ciągłego budowania kultury, silnego Data Governance, a także dostosowania samego podejścia pod specyfikę organizacji.
Przebudowa struktur fizycznych oraz komunikacyjnych w dużej organizacji to nietrywialne zajęcie, które pochłania zarówno wiele czasu, jak i budżetu. Świadomość tego, że jest to eksperyment sprawia, że podjęcie tego ryzyka jest bardzo ciężko uzasadnić, a sam sposób wdrożenia musi być bezpośrednio dopasowany pod kulturę i domenę przedsiębiorstwa. Możemy wywnioskować z tego, że podejście Data Mesh wciąż wymaga standaryzacji, dobrych praktyk wielu pomyślnych, jak i niepomyślnych wdrożeń, z których liderzy wyciągną wnioski. Firma Gartner jasno wyraziła swoje stanowisko dotyczące Data Mesh – nieużyteczne przed osiągnięciem dojrzałości, choć dojrzałość nie nastąpi bez wielu prób i dalszych innowacji.
Coroczny Hype Cycle Zarządzania Danymi na rok 2023, Gartner7
Ostatniego dnia września w pięknej Pradze czeskiej odbyła się jednodniowa konferencja Dama Day 2024 zorganizowana przez czeski oddziałDAMA International. W wydarzeniu uczestniczyło ok 100 osób, którym zaproponowano 14 sesji w dwóch równoległych strumieniach, od 8.00 do 17.00 + 2h egzamin CDMP dla chętnych. W kuluarach mieli swoje stoiska sponsorzy konferencji. Miałem przyjemność być tam i ja, wraz z silna reprezentacją polskiej DAMA’y.
Tematyka była bardzo szeroka, tak że każdy pasjonat świata danych mógł znaleźć coś dla siebie. Omawiano zagadnienia podstawowe, jak choćby wartość ładu danych (Data Governance) czy jakości danych dla biznesu organizacji, poprzez historię, aż do kwestii etycznych czy też zaawansowanych zagadnień modelowania danych. Nie zabrakło też będącej dziś na topie Sztucznej Inteligencji (AI) i jej zastosowań. Poza bardzo ciekawymi prezentacjami merytorycznymi i kontaktami osobistymi, mieliśmy okazję uczestniczyć w dwóch ważnych wydarzeniach. Jednym z nich było ogłoszenie dorocznych nagród DAMA, o czym pisze Marilu Lopez tu. Drugie ważne wydarzenie to egzamin CDMP w trybie PIYP (Pay if you pass). Frekwencja na egzaminie była bardzo duża, a zdawalność wysoka – o czym pisał Arek tu.
Poniżej kilka bardziej szczegółowych i subiektywnych notatek, które mam nadzieję będą zachętą aby wziąć udział w następnym DAMA Day – być może tym razem w Polsce :).
Po oficjalnym otwarciu konferencji i ogłoszeniu nagród rocznych skoczyliśmy od razu na głęboką wodę. Peter Aiken w “Connecting Data Governance & Quality to Organizational Values”pokazał nam jak zarobić ponad 1,5 * 10^9 USD za pomocą usprawnień w zarządzaniu danymi (inaczej mówiąc, poprzez wdrożenie Data Governance w organizacji i poprawę jakości danych). Wiele przykładów sięgało do dość dalekiej historii (kto dziś pamięta problem roku 2000?), przy okazji pokazując że problemy w informatyce są w dużej części uniwersalne. Choć technologia się zmienia bardzo szybko, to jednak wypracowane metody i rozwiązania warto przynajmniej znać, a może nawet wykorzystać.
W “History & Evolution of the DMBOK and CDMP”Chris Bradley (Vice-president, DAMA-I), jako uczestnik i świadek (44 lata pracy w organizacji DAMA), przedstawił drogę jaka standardy i organizacja DAMA przeszła. Opowiedział o tym jak postanowiono wypełnić lukę braku standardów i przede wszystkim wspólnej terminologii w obszarze zarządzania danymi, o powstaniu kolejnych wersji słownika, body of knowledge i innych publikacji, o certyfikacji CDMP i innych.
W “Leveling-Up Data Culture in SMEs: A Different Path to Maturity” Petr Mikeška (CEO Dawiso) przedstawił swoje spostrzeżenia i doświadczenia dotyczące różnic miedzy firmami dużymi i małymi w obszarach: analizy dojrzałości, wymagań i oczekiwań dot. narzędzi wspierających Zarządzanie Danymi (Data Management) . Jeśli zastanawiasz się czy w tym przypadku lepiej wielkość firmy mierzyć przychodem, ilością pracowników a może jeszcze inaczej, to zachęcam do zapoznania się z tą właśnie prezentacją.
W “Metadata 360 – Empowering the Stakeholders” Peter Vennel (Data Strategist, Equifax) omówił rozwiązania jakie Equifax stosuje m.in. w obszarze metadanych. Jeśli interesuje cię jakiego rodzaju analizy dot. konsumentów i ich zdolności kredytowej czy wiarygodności są robione i w oparciu o jakie dane, albo jakie narzędzia można przy tak rozbudowanym zarządzaniu danymi pobieranymi głównie z zewnętrznych baz, polecam ten wykład. W kwestii metadanych prowadzący zwrócił uwagę na konieczność gromadzenia w katalogu wielu ich rodzajów, zarówno biznesowych jak i technicznych (z ciekawszych to podstawa prawna i powód przetwarzania), a także na konieczność powszechnego rozumienia wykorzystywanego narzędzia.
Na zakończenie Michel Hebert poszerzył naszą wiedze o egzaminach CDMP, a następnie sprawnie przeprowadził egzamin w formule PIYP (Pay If You Pass).
Oto pełna agenda konferencji. Niestety nie mam jeszcze materiałów pokonferencyjnych, stąd brak linków do prezentacji – artykuł zostanie zaktualizowany jak tylko je otrzymamy.
Na pierwszy rzut oka mogłoby się wydawać, że nie ma nic kontrowersyjnego w stwierdzeniu: „chcę mieć w swojej organizacji dane wysokiej jakości”. Podejmując działania w tym kierunku musimy odpowiedzieć na kilka pytań, m.in: w jaki sposób mierzyć jakość danych? Kiedy jest ona wystarczająco dobra i jakie mierniki należy wziąć pod uwagę?
Data Mesh to zdecentralizowane podejście do zarządzania danymi w dużej skali opierające się o cztery filary mające za zadanie wytworzenie pewnej kultury i jakości pracy.
Oznacza to, że:
Jest to podejście skierowane nie tylko na technologię, ale przede wszystkim na ludzi.
Jest to podejście pracy zdecentralizowanej, gdzie autonomia jest na dole organizacji.
Jest to podejście stosowane w dużej skali.
Pomysłów na pracę z danymi w organizacji jest wiele, ten jednak proponuje skupienie się na zasobach ludzkich, które, dzięki zaakceptowaniu prawa Conway’a1, mogą być efektywnie wykorzystane bez wiecznej walki z naturą człowieka, jak i przedsiębiorstwa.
Data Mesh rekomenduje iteracyjną ewolucję organizacji w kierunku wyznaczonym przez liderów zarządzania informacją w rozproszonych środowiskach. Transformacja ta opisana została czterema filarami, które są zestawem rekomendacji i próbą utworzenia nowych najlepszych praktyk w świecie danych.
Cztery Filary Data Mesh
Domeny
Organizacje wymagają coraz większej skali oraz dynamiki swojej działalności. Aby to osiągnąć poszczególne departamenty muszą redukować oczekiwanie na inne zespoły oraz decyzje płynące z zewnątrz. Sprawia to, że autonomia jest głównym czynnikiem napędzającym biznes. Okazuje się, że zorientowanie domenowe znacznie wspiera te postulaty.
Podejście domenowe pojawiło się już w 2003 roku w kontekście programistycznym, natomiast w przypadku organizacji, w prostych słowach, oznacza tyle, że należy zapewnić wykonywanie przepływu pracy od początku do końca wewnątrz jednego zespołu (lub grupie zespołów) złożonego ze wszystkich wymaganych na co dzień kompetencji. Pozwala to na dużą autonomię oraz znacząco zmniejsza liczbę nieporozumień, jako że łatwiej się porozumiewać jednym językiem, w jednym kontekście. Jest to również zgodne z Prawem Conway’a2 oraz Liczbą Dunbar’a3. Ostatecznie powinniśmy otrzymać tzw. Agile Release Train4, który jest wirtualną organizacją złożoną z zespołów Agile.
Dane jako Produkt
Od lat podejście projektowe w stylu kaskadowym przekształcane jest w podejście oparte o produkty żyjące zgodnie z metodykami zwinnymi. Dane jednak od zawsze były produktem pobocznym, odkładanym na dysku i czekającym na dalsze procesowanie.
W przypadku Data Mesh chcemy zadbać o jakość, niezawodność oraz transparentność informacji, a do tego potrzebne jest zaaplikowanie podejścia inżynieryjnego do samych danych i tego, co za nimi idzie.
Dziś dane to monetyzowalny produkt o konkretnej wartości, który jest stale udoskonalany przez konkretną domenę oraz posiada całą charakterystykę pełnoprawnego modułu składającego się z kodu, danych oraz wszystkich innych wymaganych artefaktów.
Koncept Data Mesh jest wspierany przez takie pojęcia jak Data Product, Data Ownership czy Data Contract.
Samoobsługowa Scentralizowana Platforma Danych
Dane niosą coraz większą wartość, od prostej analityki i diagnostyki, aż po skomplikowane algorytmy predykcyjne i kognitywne wymagające bardzo wysokiej jakości ogromnych stale przetwarzanych informacji. Organizacja musi mieć zapewnione miejsce, w którym może odnaleźć dane, wstępnie się im przyjrzeć, ustalić z kim o nich rozmawiać oraz na jakich zasadach można z nich korzystać. Z pomocą przychodzi Platforma Danych oraz Katalog Danych.
Platforma Danych pozwala na autonomię osób poszukujących danych. Jest to bardzo duża zmiana kulturowa, ponieważ taka zdolność organizacji zwiększa ilość oraz jakość inicjatyw, promuje przejrzystość prac i zachęca do rozwoju, a nawet zdrowej rywalizacji, w czym pomóc może m.in. Grywalizacja5.
Federacyjne Ustalanie i Zarządzanie Praktykami
Ostatecznym filarem jest zarządzanie praktykami (Governance). Zespół wspierający złożony z najbardziej doświadczonych osób, w tym członków domen, ustala to, w jaki sposób warto pracować oraz jak kontrolować rozwój domen w dobrym kierunku. Jest to ogromne wsparcie, zwłaszcza w wysoce uregulowanych środowiskach, gdzie część zasad zależy od domeny, jednak wiele zależy od całej branży. Spojrzenie z góry nie tylko pomaga znaleźć wąskie gardła oraz problemy, lecz także dobre praktyki, które warto rozdystrybuować w całej organizacji. Wymiana doświadczeń, wspólne spojrzenie na przedsiębiorstwo, oraz aplikowanie coraz to nowszych wymagań i praktyk z zewnątrz to przykłady korzyści wynikające ze współpracy zespołu wspierającego.
Podsumowanie zasad, zależności oraz korzyści płynących z wykorzystania Data Mesh6
Rozpoczęcie Prac
Implementacja tak dużych zmian wymaga przygotowania strategii, planowania oraz nauki na każdym poziomie całego przedsiębiorstwa. Data Mesh stawia przed nami bardzo wymagające założenia, wdrożenie których może się zwyczajnie nie udać, choćby przez sam fakt częstych zmian na stanowiskach decyzyjnych, nie mówiąc o ciągłym rozwoju oraz zmianach kierunku organizacji.
Nie bez powodu Gartner umieścił Data Mesh jako “obsolete before plateau”, które może zostać osiągnięte za kilka lub kilkanaście lat.
Coroczny Hype Cycle Zarządzania Danymi na rok 2023, Gartner7
Bez względu na eksperymentalność tego podejścia wiele organizacji decyduje się na implementację, aby potencjalnie zyskać ogromną przewagę na rynku8.
Rozpoczynając implementację należy zadbać o 4 ważne aspekty:
Wsparcie sponsora C-Level
Ustalenie zespołu odpowiedzialnego za inicjatywę (Data Mesh Council)
Wykonanie warsztatów w celu zrozumienia AS-IS oraz TO-BE
Znalezienie (i/lub wyszkolenie) osób potrafiących i chcących szerzyć dobre praktyki
Wdrażanie Data Mesh nie jest tanie, ani szybkie, dlatego też decyzja ta musi być dobrze uzasadniona i zaplanowana. Bez względu na podejście warto pamiętać, że zasady wymienione w poprzednim rozdziale są uniwersalne i ich implementacja – zarówno pod pełnym szyldem Data Mesh, bądź osobno jako innowacje – dają ogromne korzyści na polu technologicznym oraz kulturowym.
Monetyzacja danych oznacza wykorzystywanie zgromadzonych informacji i danych klientów w celu generowania przychodów lub zysków. Jest to praktyka, która staje się coraz bardziej popularna w erze cyfrowej, gdzie przedsiębiorstwa gromadzą ogromne ilości danych o swoich klientach i ich transakcjach. Oto kilka produktów, dla których można ‘monetyzować’ dane na przykładzie branży bankowej:
Personalizacja ofert i usług: Banki mogą wykorzystywać dane o zachowaniach finansowych klientów, aby dostosować oferty i usługi do ich indywidualnych potrzeb
Analiza ryzyka i ocena kredytowa: Dane klientów pozwalają bankom na dokładniejszą analizę ryzyka i ocenę kredytową. Dzięki temu mogą one podejmować bardziej trafne decyzje dotyczące udzielania kredytów i innych produktów finansowych
Sprzedaż danych: Banki mogą zdecydować się na sprzedaż anonimizowanych lub agregowanych danych klientów innym firmom, takim jak firmy badawcze, agencje marketingowe lub instytucje rządowe
Programy partnerskie i marketing: Banki mogą nawiązywać współpracę z firmami zewnętrznymi i oferować im dostęp do swojej bazy klientów w zamian za udział w przychodach lub opłaty za reklamę.
Rozwój nowych produktów i usług: Dostęp do danych klientów może pomóc bankom w identyfikowaniu nowych trendów i potrzeb rynkowych
Zwiększona retencja klientów: Banki mogą wykorzystywać dane do analizy zachowań klientów i identyfikowania tych, którzy są zagrożeni odejściem do konkurencyjnych instytucji finansowych
Warto zaznaczyć, że monetyzacja danych musi być przeprowadzana z uwzględnieniem przepisów dotyczących ochrony danych osobowych, takich jak RODO / GDPR w Europie, aby zapewnić prywatność i bezpieczeństwo klientów.
Zanim przejedziemy dalej wyjaśnienia wymaga jeszcze pojęcie ‘Data Product’ (ang.) użytego na potrzeby tego artykułu. ‘Produkt Danych’ to rodzaj produktu lub usługi zbudowanej wokół wykorzystania danych i analiz w celu zapewnienia wartości użytkownikom lub klientom. Na ‘Data Product’ mogą się składać się takie elementy jak: dane, procesy biznesowe, właścicielstwo danych, metryki jakościowe, raporty, modele danych, systemy, interfejsy, powiązane metadata, definicje i słowniki danych itp., a więc wszystko co łączy się bezpośrednio, lub bezpośrednio z ‘DAMA Wheel’
Przykład analizy Ryzyka i Ocena Kredytowa
1. Wprowadzenie
W niniejszym artykule skupimy się na przykładzie ‘Produktu Danych’ dot. Ryzyka Kredytowego i Oceny Zdolności Kredytowej Dla Klienta Biznesowego, ale w analogiczny sposób można przeprowadzić analizę dla każdego innego produktu, klienta lub segmentu zarówno z obszaru danych branży finansowej jak i nie finansowej, jednak należy zaznaczyć, iż kluczem do sukcesu jest zrozumienia wszystkich elementów związanych z danym produktem.
2. Business Case
W ramach omawianego przykładu bierzemy pod uwagę proces kalkulacji ratingu klienta biznesowego w oparciu o dane pochodzące z systemów źródłowych Banku i wpływu tej kalkulacji na inne modele takie jak Risk Weight Asset (RWA) oraz Economic Capital (EC) przy uwzględnieniu procesów agregacji i transformacji danych wykorzystujących tzw. ‘Critical Data Elements’ (CDE) – w naszym przypadku ‘Typ Księgowości’ (Accouting Type), gdzie błąd w danych prowadzi do zniekształcenia danych, a co za tym idzie dalszych błędnych wyników końcowych. Warto nadmienić, iż CDEs powinny zostać skatalogowane w dedykowanym Katalogu Danych
Poniżej znajduje się uproszczony diagram (diagram nr 1) pokazujący wpływ ww. błędu w polu ‘Accouting Type’ (3) (Typ Księgowości) na poszczególne modele, a w następstwie na wyliczanie parametrów RWA i Economic Capital Demand (EC) – oczywiście jest to wersja ‘bardzo’ uproszczona 🙂
W praktyce każda zmienna tzw. ‘Input Variable’, która wpływa na jakikolwiek model danych (LGD, PD, EL etc.) włączając w to modele ML/AI niesie za sobą ryzyko błędnej kalkulacji modelu i wzrostu ponoszonych kosztów np. rezerwy, wymogi kapitałowe itp. lub błędnych decyzji podjętych przez człowieka lub… komputer w oparciu o te dane .
Aby uniknąć takich ‘błędów’ oraz pomyłek, które mogą generować straty finansowe, Regulator w ramach m.in regulacji BCBS239 ustalił 3 główne obszary , które winny być monitorowane wraz z określonymi wymogami (BCBS239 Priniciples from 1 to 11).
Obszary te możemy podzielić na:
BCBS239 Principles
Warto nadmienić, iż przy wprowadzeniu powyższych wymogów pomoże nam DAMA jako, że zawiera wszystkie elementy potrzebne do wypełnienia postanowień BCBS 239 po stworzeniu odpowiedniego ‘Planu i Konceptu Wdrożenia BCBS 239’
W dalszej kolejności DAMA może nam pomóc zaadresować inne wymogi regulacyjne np. BCBC239, GDPR , Target Review Internal Model (TRIM) , IFRS9 requirements, Capital Requirements Regulation (CRR) lub wiele innych, które można znaleźć na poniższej stronie: Interactive Single Rulebook
3. Analiza i działania
3.1 Analiza Przyczyny Błędu (Root Cause Analysis):
Brak wprowadzonego we właściwy sposób ‘Typu Księgowości’ przez pracownika banku (1 minute task) dla jednego klienta w systemie operacyjnym, którego ekspozycja wynosi 1 mln EUR skutkuje brakiem możliwości użycia ‘technik redukcji ryzyka’ i zgodnie z wymogami BASEL dotworzeniem rezerw, a przez to dodatkowych Wymogów Kapitałowych również na poziomie 1 mln EUR .
3.2 Wniosek pokontrolny:
Jeżeli w Banku byłoby takich 100 klientów, dla których brak jest wprowadzonej poprawnej wartości tylko w jednym polu to Bank musi dotworzyć z dnia na dzień o ca 95% więcej rezerw i wymogów kapitałowych niż to jest wymagane przez regulatora dla danej ekspozycji, jeżeli błąd nie istnieje .
3.3 Rekomendowane Działania:
Zbudowanie ‘Przepływu Procesu Danych’ dla każdego modelu (Data Lineage)
Identyfikacja zmiennych wpływających na model i zaszeregowanie ich jako tzw. ‘Critical Data Elements’ (CDE) (patrz również drugi diagram – część Model Owner)
Identyfikacja i dokumentacja sposobów agragacji, transofrmacji i właścicielstwa danych przy pomocy ‘Procesu Przypływu Danych’ (Data Lineage) i Katalogu Danych (Data Katalog)
Określenie wymogów na potrzeby ‘Monitorowania Jakości Danych’ (Data Observability) np. Business DQ Rules, Technical DQ Rules, Integgration DQ Rules i wdrożenie w narzędziu do ‘Monitorowania Jakości Danych’ na poszczególnych etapach ‘Lineage’ (patrz również drugi diagram – część DQ Ownership & Issue)
Porównując dane (przed błędem vs po błędzie) możemy określić wpływ, a więc dokonać ‘monetyzacji’ oraz wyliczyć ROI dla Data Governance*
*Należy pamiętać, żę aby wyliczyć ROI dla Data Governance, warto wdrożyć wszystkie wymagane elementy #DAMA (Data Governance, Data Quality & Data Operation), gdyż trudno jest wyliczyć ROI i tylko dla jednego z nich
Załączniki
Wykres 1 – Mapa Danych / Model Koncepcyjny:
Wykres 2 – Przykład Przepływu Danych (Data Lineage Topic):
W dzisiejszej erze cyfrowej, dane stały się jednym z najcenniejszych zasobów dla organizacji. Właściwe zarządzanie danymi staje się nieodzowne, aby wykorzystać ich pełen potencjał i osiągnąć strategiczne cele biznesowe. W ramach tego procesu, dwie kluczowe praktyki wyłaniają się na pierwszy plan: #DataGovernance #DataStewardship. Te dwie koncepcje są nieodłącznie powiązane i razem tworzą fundament skutecznego zarządzania danymi.
Ważne jest zrozumienie, że zarządzanie danymi nie jest izolowanym procesem, lecz ściśle związane z kontekstem organizacji. Nie wystarczy jedynie posiadać technologiczne rozwiązania do przechowywania i analizy danych. Efektywne zarządzanie danymi wymaga uwzględnienia szerokiego spektrum czynników, takich jak strategia biznesowa, strategia IT, polityki i standardy organizacji oraz kultura biznesowa i otoczenie.
#DMBOK przedstawia następującą definicję data governance i data stewardship: “Wykonywanie władzy, kontroli oraz podejmowania wspólnych decyzji (planowanie, monitorowanie i egzekwowanie) w zakresie zarządzania aktywami danych.”
Według #DMBOK, istnieją trzy podstawowe cele strategiczne #DataGovernance#DataStewardship:
Umożliwienie organizacji zarządzania danymi jako aktywem.
Określanie, zatwierdzanie, komunikowanie i wdrażanie zasad, polityk, mierników, narzędzi i odpowiedzialności dotyczących zarządzania danymi.
Monitorowanie i kierowanie zgodnością z politykami, wykorzystaniem danych oraz działaniami zarządzania.
Określanie, zatwierdzanie, komunikowanie i wdrażanie zasad, polityk, narzędzi i mierników dotyczących zarządzania danymi jest niezwykle istotne dla utrzymania spójności i skuteczności w obszarze danych. Również monitorowanie i kierowanie zgodnością z politykami, wykorzystaniem danych oraz działaniami zarządzania pomaga w utrzymaniu wysokiej jakości danych i zgodności z przepisami. Te cele są kluczowe dla organizacji dążących do efektywnego wykorzystania swoich zasobów danych.
#DataGovernance #DataStewardship
Implementacja data governance i data stewardship generuje różnorodne produkty, które pomagają organizacjom w skutecznym zarządzaniu danymi. Niektóre z tych produktów to:
Strategię zarządzania danymi;
Strategię danych;
Mapę strategiczną strategii biznesowej i zarządzania danymi;
Zasady danych, polityki zarządzania danymi, procesy;
Ramy operacyjne dla danych;
Mapę strategiczną i strategię wdrożenia, itp.
Wszystkie te produkty pozwalają na wcielenie w życie data governance w całej organizacji oraz na monitorowanie i ocenę jej efektywności.
#DMBOK definiuje również szereg aktywności, które wynikają bezpośrednio z data governance i data stewardship. Niektóre z tych aktywności to:
Określenie zarządzania danymi dla organizacji.
Opracowanie strategii zarządzania danymi.
Przeprowadzenie oceny gotowości/dojrzałości data governance
Podzielcie się w komentarzach swoimi praktykami dotyczącymi data governance – jak to wygląda w Waszych organizacjach? Czekamy na Wasze cenne doświadczenia i opinie!
Nie przegapcie kolejnego artykułu: będzie poświęcony katalogom danych w #DMBOK
Czy kiedykolwiek zastanawiałeś się, jak skutecznie zarządzać danymi w swojej firmie? Metoda DAMA DMBOK to jedna z najpopularniejszych i najskuteczniejszych metod na świecie, która umożliwia skuteczne zarządzanie danymi. W tym artykule dowiesz się, jak diagramy kontekstowe DAMA pomogą Ci w zrozumieniu podstawowych elementów metodyki i jak wykorzystać je w praktyce. Bez względu na to, czy dopiero zaczynasz przygodę z zarządzaniem danymi, czy szukasz sposobu na usprawnienie procesów w swojej firmie – diagramy kontekstowe DAMA są narzędziem, które warto poznać!
W ramach metodyki zarządzania danymi wg DAMA (Dama-DM BOK Framework) zdefiniowano spójne obszary tematyczne zwane Data Management Knowledge Area.
Omówienie obszarów tematycznych stanowi podstawową zawartość DMBOK-a. Każdy z obszarów tematycznych opisywany jest w oddzielnym rozdziale.
We wstępie do każdego z tych rozdziałów prezentowany jest diagram kontekstowy dla rozdziału. Diagram ten w zwięzłej i ustandaryzowanej dla DMBOK-a formie wykazuje podstawowe definicje i cele dla wszystkich obszarów.
Ze względu na duże zainteresowanie diagramami DAMA International zdecydował się je opublikować.
Diagramy kontekstowe to wiedza w pigułce z każdego obszaru tematycznego DAMA-DMBOK-a. Dla osób mających dostęp do DMBOK-a mogą służyć jako kompendium zawierające najważniejsze elementy metodyki czy podręczna ściąga przy wdrażaniu zarządzania danymi. Z kolei dla tych, którzy jeszcze nie zdecydowali się na zakup podręcznika DMBOK-a dają możliwość poznania podstawowych elementów metodyki, kluczowych dla zarządzania danymi.
Na przykładzie diagramu dla obszaru Data Governance i Stewardship omówię ich elementy.
Jak widzicie diagramy dostarczają wiele użytecznych informacji. Zachęcamy do ich pobrania i wykorzystywania w codziennej praktyce.
#Jeśli interesujesz się zarządzaniem danymi i chcesz rozwijać swoją wiedzę na ten temat, to dołączenie do społeczności DAMA może być dla Ciebie idealnym rozwiązaniem. Jako członek będziesz miał dostęp do najnowszych trendów i najlepszych praktyk związanych z zarządzaniem danymi, a także do innych profesjonalistów z branży. Zachęcamy do kontaktu z DAMA Poland i dołączenia do naszej społeczności.
.
