29 września na Uniwersytecie Ekonomicznym w Pradze odbyła się druga edycja DAMA Day. Tegoroczna edycja była wyraźnie skoncentrowana na zagadnieniach związanych ze sztuczną inteligencją.
Warszawa stolicą zarządzania danymi: triumf wiedzy i innowacji podczas DAMA Day Warsaw
18 września 2025 roku Warszawa zamieniła się w prawdziwe centrum polskiej społeczności data management. W przestrzeniach Cambridge Innovation Center odbyła się konferencja DAMA Day Warsaw, organizowana przez DAMA Poland Chapter, całodniowe wydarzenie poświęcone wszystkim najważniejszym aspektom zarządzania danymi, ich jakości, ochrony prywatności i roli w rozwoju sztucznej inteligencji.
Od samego rana uczestnicy tłumnie przybywali na miejsce, by odebrać materiały konferencyjne, spotkać znajomych z branży i porozmawiać z organizatorami. Oficjalne otwarcie wydarzenia poprowadzili Peter Aiken, prezes DAMA International, oraz Piotr Pietrzyk, prezes DAMA Poland Chapter. Podczas wystąpienia inauguracyjnego podkreślili, że dane stały się jednym z najważniejszych zasobów współczesnych organizacji, a umiejętność ich właściwego zarządzania jest kluczowa dla skuteczności biznesu. W tym kontekście ogłoszono również zapowiedź nowej edycji DAMA DMBOK® 3.0, która wprowadzi świeże spojrzenie na Data Governance, integrując m.in. rosnące znaczenie sztucznej inteligencji i automatyzacji w procesach zarządzania informacją.
Jednym z największych atutów konferencji był jej program, zaprojektowany w formule dwóch równoległych ścieżek: eksperckiej i partnerskiej. Dzięki temu uczestnicy mogli wybierać między wykładami o charakterze strategicznym i teoretycznym, a prezentacjami praktycznych wdrożeń przygotowanych przez partnerów. W ścieżce eksperckiej szczególnym zainteresowaniem cieszyły się prelekcje dotyczące łączenia Data Governance i Data Quality z wartością biznesową, prezentacje poświęcone wyzwaniom stojącym przed firmami w dobie rozwoju AI, a także inspirujący wykład Tiankai Feng „Humanizing Data Strategy”, który przypomniał, że technologia to tylko narzędzie, a prawdziwym sercem strategii danych są ludzie, ich kompetencje, komunikacja, współpraca i odpowiedzialność.
Ścieżka partnerska natomiast zdominowana była przez studia przypadków i przykłady wdrożeń, które wniosły do programu dużą dawkę praktycznej wiedzy. Eksperci z Deloitte i mBanku pokazali, jak w praktyce budować model zarządzania danymi w sektorze bankowym, PwC Polska skupiło się na kwestiach ochrony prywatności i bezpieczeństwa danych w kontekście rosnących cyberzagrożeń, a Ataccama zaprezentowała narzędzia pozwalające na automatyzację procesów zapewniania jakości danych. Ab Initio przedstawiło rozwiązania wspierające zarządzanie danymi w środowiskach multi-cloud, a Dawiso & ILUM podzieliły się wizją tworzenia fundamentów danych gotowych na rozwój agentów AI. Uczestnicy mieli także okazję wysłuchać prelekcji o projektowaniu i wdrażaniu Data Marketplace, znaczeniu Data Catalog w organizacjach oraz o tym, jak granularne podejście do Data Lineage przekłada się na lepszą kontrolę i transparentność procesów. To właśnie dzięki tym partnerom – Ataccamie, Deloitte, PwC Polska, Ab Initio, BitPeak oraz Dawiso & ILUM – program konferencji nabrał praktycznego wymiaru i pozwolił zobaczyć, jak najnowsze koncepcje i technologie są wdrażane w realnych projektach. W imieniu DAMA Poland Chapter serdecznie dziękujemy wszystkim partnerom, prelegentom i uczestnikom za ich wkład i zaangażowanie, to dzięki nim DAMA Day Warsaw stał się wydarzeniem, które nie tylko edukuje, ale także integruje społeczność i inspiruje do dalszego rozwoju.
Kulminacyjnym momentem konferencji był wieczorny egzamin CDMP® (Certified Data Management Professional), który odbył się w godzinach 18:00–19:30. Dla wielu uczestników była to długo wyczekiwana okazja, by oficjalnie potwierdzić swoje kompetencje w obszarze zarządzania danymi i zdobyć międzynarodowy certyfikat uznawany na całym świecie. Egzamin poprzedzony był przerwą techniczną oraz sesją Q&A, w trakcie której można było rozwiać ostatnie wątpliwości dotyczące przygotowania i formy testu.
Po części egzaminacyjnej uczestnicy spotkali się na koktajlu networkingowym, który stworzył idealną przestrzeń do nawiązania nowych kontaktów biznesowych, wymiany doświadczeń i podsumowania intensywnego dnia. Atmosfera była wyjątkowa, widać było, że środowisko data management w Polsce jest nie tylko coraz liczniejsze, ale i coraz bardziej świadome wyzwań oraz szans, jakie niesie przyszłość.
DAMA Day Warsaw 2025 udowodnił, że zarządzanie danymi w Polsce wychodzi poza wąskie grono ekspertów i staje się kluczowym tematem dla całych organizacji. Wystąpienia dotyczące nowych technologii, regulacji prawnych, sztucznej inteligencji i kultury organizacyjnej dowodzą, że dane to nie tylko technologia, ale fundament świadomego, odpowiedzialnego i innowacyjnego biznesu. Ta edycja konferencji umocniła pozycję DAMA Poland Chapter jako organizacji, która nie tylko uczy, ale i integruje środowisko specjalistów data management, inspirując do rozwoju kompetencji i wdrażania najlepszych praktyk.
autor: Dominika Pogudz DAMA Poland
Nie tylko dokładność – o wymiarach jakości danych
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ę?
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:
- 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:

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





