DALL·E 2024-03-16 20.45.46 - Visualize the concept of a Data Strategy being a key to success in a modern, complex, and competitive business environment, where managing and utilizi

Dlaczego Strategia Danych ważna jest?

W dzisiejszym świecie Strategia Danych jest kluczowym elementem

 sukcesu dla organizacji. Określa ona sposób, w jaki firma gromadzi, przechowuje, zarządza i wykorzystuje dane, aby osiągnąć swoje cele biznesowe, w tym jak przygotowuje swoje dane pod katem ML/AI oraz systematycznie eliminuje tzw. obszary ‘Dark Data’:

W związku z powyższym, rozwinięcie klarownej i spójnej strategii danych staje się priorytetem dla każdej organizacji, która chce pozostać konkurencyjna i zrównoważona na dzisiejszym dynamicznym środowisku biznesowym.

Istnieje kilka obszarów, dla których Strategia Danych jest szczególnie ważna w dzisiejszych czasach:

Wielkość i złożoność danych: Wraz z rosnącą ilością danych generowanych przez firmy, konieczne jest posiadanie jasnej strategii, aby skutecznie nimi zarządzać. Strategia danych pomaga w zorganizowaniu i uporządkowaniu tych danych, umożliwiając ich efektywne wykorzystanie

Konkurencyjność rynku: Współczesne firmy konkurują na coraz bardziej zglobalizowanym rynku, gdzie dane są kluczowym narzędziem do podejmowania inteligentnych decyzji biznesowych. Firmy posiadające dobrze przemyślaną strategię danych są w stanie wykorzystać swoje dane jako strategiczny zasób, dając im przewagę konkurencyjną.

Innowacje i personalizacja: Dostęp do danych o klientach pozwala firmom na tworzenie bardziej spersonalizowanych i dostosowanych produktów oraz usług. Strategia danych umożliwia zbieranie, analizę i interpretację tych danych, co z kolei prowadzi do lepszego zrozumienia potrzeb klientów i innowacyjnych rozwiązań

Bezpieczeństwo danych: W obliczu rosnących zagrożeń związanych z cyberbezpieczeństwem i przepisami dotyczącymi ochrony danych osobowych, strategia danych staje się kluczowym narzędziem w zapewnieniu bezpieczeństwa i zgodności z przepisami.

Warto zwrócić uwagę na fakt, iż brak odpowiednej Strategii Danych może prowadzić do powstawania tzw. ‘Technical Dept’ oraz ‘Data Spaghetti’.

Strategii Danych typu ‘Data Spaghetti’:

co w konsekwencji może się wiązać zarówno z negatywnym wpływem na nasze procesy biznesowy jak i wyniki finansowe:

Aby w pełni wykorzystać Strategię Danych w ramach poszczególnych obszarów musimy wpierw zaadresować nasze potrzebny w odpowiedni sposób skupiając się przynajmniej na trzech poniższych elementach:

     

      • Ludzie, gdzie ludzie zapewniają odpowiedni know-how i podejście do pracy

      • Procesy, które wpierają wykorzystanie danych

      • Technologia, która umożliwia sprawniejsze wykorzystanie procesowanych danych

    Należy tutaj zaznaczyć, iż nasza Strategia Danych powinna być podzielona na odpowiednie fazy, aby odpowiednio zaadresować nasze potrzeby w czasie, gdzie możemy wyróżnić następujące fazy:

       

        • Taktyczna, w której skupiamy się na zadaniach, które umożliwiają na zrozumienie danych np. narzędzia typu Data Catalog, Data Quality lub Data Lineage oraz odpowiednie zarządzanie nimi, czyli np: Data Storage, Data Integration, Reporting platforms

        • Strategiczna, w której możemy skupić się na poprawie tego co udało nam się „odkryć” (discovery), a wiec np. zaadresowanie Data Factory i Data Mesh potrzeb

        • Wizja, która w dużej mierze powinna pokrywać sie ze strategia firmy, jako ze w dłuższym okresie czasu trudno jest bezpośrednio zaadresować strategii danych w przeciwieństwie do startego biznesowej, która może określać gdzie firma chciała by się znaleźć ze pięć lat:

      Mając tak zdefiniowane krytyczne obszary, elementy, fazy itp. możemy pokusić się o określenie naszych docelowych celów strategicznych dla danych płynących np. z metodologii DAMA,  tak aby nasze dane były:

         

          • łatwe do zidentyfikowania

          • łatwe do zrozumienia

          • poprawne

          • kompletne

          • spójne

          • możliwe do śledzenia

          • chronione

        W ślad za tak określona strategią dla danych, każda firma może zdefiniować odpowiednie przesłanki jak osiągnąć te cele zatrudniając odpowiednich ludzi, wprowadzając wymagane polityki, procedury i procesy oraz implementując narzędzia, które następnie wesprą nas przy wprowadzenia ww. założeń i pozwolą zmierzyć się ze wszystkimi wyzwaniami płynącymi z wdrażania Strategii Danych po stronie Data Governance jako czynniki umożliwiający realizacje Strategii Danych.

        _123d5c94-2a3a-4a7a-b680-1aa8e841bb60

        Monetyzacja danych, a jakość danych – przykład na bazie zarządzania ryzykiem kredytowym w banku

        Co to jest monetyzacja danych ?

        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:

        1. Personalizacja ofert i usług: Banki mogą wykorzystywać dane o zachowaniach finansowych klientów, aby dostosować oferty i usługi do ich indywidualnych potrzeb
        2. 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
        3. 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
        4. 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ę.
        5. 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
        6. 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 :warning:.

        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 :warning:.

        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 :warning: 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 :warning:.

        3.3 Rekomendowane Działania:

        1. Zbudowanie ‘Przepływu Procesu Danych’ dla każdego modelu (Data Lineage)
        2. Identyfikacja zmiennych wpływających na model i zaszeregowanie ich jako tzw. ‘Critical Data Elements’ (CDE) (patrz również drugi diagram – część Model Owner)
        3. 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)
        4. 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)
        5. 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 :warning:

        Załączniki

        Wykres 1 – Mapa Danych / Model Koncepcyjny:

        Wykres 2 – Przykład Przepływu Danych (Data Lineage Topic):