JST_DAMA

Ład danych w administracji samorządowej – wyzwania, możliwość, konieczność

Wnioski i materiały z webinarium przygotowanego przez: Jarosław Banaś, Karol Berłowski, Andrzej Burzyński, Arkadiusz Dąbkowski, Filip Dzięcioł, Wojciech Łachowski w ramach współpracy DAMA Chapter Poland oraz sieci Analityków danych miejskich prowadzonej przez Instytut Rozwoju Miast i Regionów.

Niewidzialna ręka urzędów JST

Ogromne wolumeny danych wpływające na organizację życia każdego mieszkańca w Polsce są przetwarzane w urzędach Jednostek Samorządu Terytorialnego (JST) czyli w urzędach miast, województw, powiatów, gmin. JST gromadzą i przetwarzają dane nie tylko w zakresie bezpośrednio dotyczącym osób fizycznych np. danych meldunkowych, ale prawie w każdym zakresie dotyczącym naszego otoczenia np. architektury, transportu, edukacji, ochrony środowiska, bezpieczeństwa, wodociągów i wielu innych. Dane te służą podejmowaniu decyzji wpływających na organizację życia lokalnej społeczności np. dotyczące lokalizacji szkoły lub tras autobusów. Wybrane dane są przekazywana do rejestrów rządowych stanowiąc podstawę do decyzji na poziomie całego kraju lub Unii Europejskiej. Wybrane dane są udostępniane publicznie stanowiąc źródło referencyjnych danych dla wielu firm. Przetwarzanie danych w JST jest uregulowane licznymi branżowymi przepisami.

Ile Ładu danych jest w JST?

Według badań Unii Europejskiej w 2024 r. Polska zajęła 2 miejsce w badaniu dojrzałości otwierania danych państw UE, co może świadczyć znakomitym zarządzaniu danymi w polskiej administracji publicznej.

Źródło: Open data in Europe 2024 | data.europa.eu

Nieliczne dostępne krajowe badania zarządzania danymi w JST (naukowe oraz kontrole Najwyższej Izby Kontroli) koncentrują się najczęściej na zarządzaniu bezpieczeństwem informacji. Zgodnie z rozporządzeniami w sprawie Krajowych Ram Interoperacyjności od  2012 r. wszystkie JST powinny posiadać wdrożone Systemy Zarządzania Bezpieczeństwem Informacji (SZBI). Mimo tego obowiązku tylko ok 44-75% JST (w zależności od badanej grupy w okresie 2012-2024 r.) wdrożyło SZBI, a przy tym w większości niekompletnie. Wymagania ww. Rozporządzenia dla SZBI są oparte o normę ISO 27001 i są spójne z elementami bezpieczeństwa Ładu Danych opisanymi w Data Management Body of Knowledge (DMBoK). Obszar bezpieczeństwa jest jednym z fundamentów Ładu Danych. Części wspólne wymagań ww. Rozporządzenia oraz Ładu Danych obejmują kluczowe konieczności: określenia ról, przypisania odpowiedzialności, prowadzenia ewidencji (metadanych), określenia zasad dostępu i wielu innych regulacji organizacji pracy z danymi. Powyższe oznacza że badania zarządzanie bezpieczeństwem informacji mogą być wskaźnikiem wdrażania Ładu Danych w urzędach, a ich dostępne wyniki świadczą o znacznych problemach.

O Ładzie danych interaktywnie

Podczas webinarium „Czy Ład Danych w samorządzie jest możliwy?” przedstawiciele DAMA Poland Chapter podjęli dyskusję nad problematyką wdrożenia Ładu Danych w JST. Webinarium zostało zorganizowane 25.04.2025 jako spotkanie w ramach sieci Analityków danych miejskich prowadzonej przez Instytut Rozwoju Miast i Regionów. O potrzebie organizacji spotkania świadczy frekwencja – webinarium zainteresowało 156 przedstawicieli z 70 jednostek samorządowych.

Podczas spotkania Wojciech Łachowski przedstawił korzyści jakie może przynieść Ład Danych w JST, w tym: lepsze decyzje, transparentność, większa efektywność, rozwój usług cyfrowych. Zidentyfikował także główne bariery wprowadzania Ładu Danych w JST analogiczne do generalnych problemów transformacji cyfrowej JST, m.in. brak środków finansowych, opór przed zmianami, problem z zapewnieniem odpowiednich kompetencji, niejasne przepisy, dług technologiczny, zła organizacja pracy. Karol Berłowski rozwinął wybrane problemy. Działalność JST jest wręcz przeregulowana przez liczne, niespójne lub nawet sprzeczne przepisy branżowe. Powyższe jest m.in. przyczyną rozległego problemu ustalenia jednolitej definicji dla jakości danych i operacyjnego właścicielstwa danych. Znaczące nieustrukturyzowanie danych powoduje komplikacje technologiczne zarządzania. JST mają trudność aby pozyskać specjalistów i zaoferować warunki pracy konkurencyjne lub zbliżone wobec sektora prywatnego.

Źródło: opracowanie W. Łachowski, K. Berłowski

Mimo wielu problemów w niektórych urzędach podejmuje sią zaawansowane działania w celu usprawnienia zarządzania danymi czego przykładem jest Urząd Miasta Krakowa

Fundamenty

Podczas spotkania Filip Dzięcioł uwzględnił podstawy teoretyczne wskazując na kluczowe aspekty Ładu Danych wg. DMBoK, takie jak strategia, polityka, standardy, nadzór. Omówił podstawowe obszary Ładu Danych: architektura, modelowanie, składowanie i operacje, bezpieczeństwo, integracja i interoperacyjność, zarządzanie zawartością, dane główne i referencyjne, hurtowanie i analityka, metadane, zarządzanie jakością. Zaznaczył problematykę wdrożeniową w organizacji która już przetwarza dane, przedstawił koncepcję wdrożenia piramidy Aikena oraz wskazał rekomendacje implementacyjne.

Źródło: opracowanie F. Dzięcioł

Sprawdzone rozwiązania

Problemy są podobne w każdym urzędzie. Bazując na swoich doświadczeniach jako eksperta Urzędu Komisji Nadzoru Finansowego, potwierdzonych przykładami z realizacji podobnych projektów w administracji publicznej oraz instytucji finansowych, Andrzej Burzyński przedstawił praktyczne możliwości wdrożenia Ładu Danych. Rozpoczęcie wdrożenia można zacząć od pryncypiów uzgodnionych z kierownikami poszczególnych obszarów merytorycznych. To zapewnia identyfikację rzeczywistych potrzeb i umożliwia określenie ogólnej polityki zarządzania danymi, z której będą wynikały zasady zarządzania danymi. Potrzebne jest uwzględnienie ludzi – ról i odpowiedzialności, potrzeb procesów oraz modelu informacyjnego który usprawni dostęp do potrzebnych danych. Ogólne dokumenty strategiczne są niezbędne do realizacji działań w postaci projektów i usług. Konieczne jest zaangażowanie kadry kierowniczej, w tym najwyższego szczebla, z uwagi na potrzebę wprowadzenia struktury organizacyjnej zarządzania danymi – przypisania odpowiedzialności dla poszczególnych osób za zarządzania danymi, np. w poszczególnych komórkach merytorycznych właścicieli danych. Potrzebne jest powołanie zespołu prowadzącego zagadnienia wdrażania Ładu Danych, skupiającego kompetencje w tym obszarze, stanowiący wsparcie dla pozostałej części jednostki. Zespół wspiera rozwiązywanie szczegółowych problemów np. zarządzania jakością danych. Inne niezbędne działania to m.in. wdrożenie katalogu danych, zidentyfikowanie obszarów tematycznych danych, opracowanie definicji, określenie danych referencyjnych, opracowanie zasad przepływu danych. Wprowadzenie Ładu Danych nie wymaga znaczącego zwiększenia zatrudnienia lub radykalnej zmiany sposobu działania lecz skoordynowania i uspójnienia bieżącej działalności. Wprowadzenie może nastąpić małymi krokami w drodze ewolucji oraz pracy zespołowej całej organizacji. Podmioty przetwarzające dane dla swojej bieżącej działalności mają już pewne elementy organizacyjne które można wykorzystać, zmodyfikować lub rozwinąć w celu osiągnięcia Ładu Danych. Istnieje dużo gotowych metodyk i narzędzi informatycznych wspierających działania. 

Źródło: opracowanie A. Burzyński

Wsparcie jest dostępne

Podczas spotkania omówiono potrzeby zarządzania danymi w JST, problemy oraz ich teoretyczne i praktyczne rozwiązania na prawdziwych przykładach. Przykłady rzeczywistego wdrożenia Ładu Danych w polskiej administracji publicznej stanowią dowód że jest to dostępna i już sprawdzona metoda zarządzania także dla podobnych podmiotów – Jednostek Samorządu Terytorialnego. Arkadiusz Dąbkowski wskazał że gotowe wzorce zarządzania danymi można znaleźć w DMBoK, a kompetencje można rozwijać w społeczności DAMA Poland https://damapoland.org/.

Ład danych odpowiedzią bieżące potrzeby JST

Wobec planowanych zmian w przepisach dotyczących bezpieczeństwa informacji w JST (nowelizacji Ustawy o z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa) wprowadzanie zmian zarządzania danymi w obszarze bezpieczeństwa danych staje się dla JST koniecznością. Zmieniając sposób zarządzania danymi w obszarze bezpieczeństwa, JST muszą wprowadzić wewnętrzne regulacje i podjąć działania skutkujące jednoczesnym wprowadzeniem elementów Ładu Danych. Te elementy stanowią znakomity przyczółek do objęcia Ładem Danych także innych obszarów, jak np. dokumenty strategiczne, jakość, zarządzanie danymi podstawowymi i referencyjnymi. 

źródło: pixabay.com

Nagranie z webinarium jest dostępne na youtube:

Źródła przywoływanych badań:

  • D. Lisiak-Felicka, M. Szmit, Systemy Zarządzania bezpieczeństwem informacji w administracji samorządowej w Polsce – badanie empiryczne, „Przegląd Organizacji”, TNOiK 2023
  • D. Lisiak-Felicka, M. Szmit, Zarządzanie Bezpieczeństwem Informacji w Urzędach administracji samorządowej. Główne problemy, „Współczesny człowiek wobec wyzwań: szans i zagrożeń w cyberprzestrzeni aspekty społeczne-techniczne-prawne”, praca zbiorowa pod redakcją A. Kamińska-Nawrot, J. Grubicka, Uniwersytet Pomorski w Słupsku, Słupsk 2021
  • A. Sobczak, Ład danych jako element wdrażania koncepcji otwartego rządu, Roczniki Kolegium Analiz Ekonomicznych nr 46/2017, Kolegium Analiz Ekonomicznych Szkoły Głównej Handlowej w Warszawie,
  • https://data.europa.eu/en/publications/open-data-maturity/2024
  • https://www.nik.gov.pl/kontrole/P/18/006
  • https://www.nik.gov.pl/kontrole/P/24/004

Group2k

Dama Day Prague 2024

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.

_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):