W ciągu dwunastu miesięcy Salesforce zapłacił około 8 miliardów dolarów za Informaticę, SAP przejął Reltio, a Gartner po ponad czteroletniej przerwie przywrócił raport Magic Quadrant dla rozwiązań Master Data Management. Rynek wycenił na miliardy kategorię, którą przez lata traktowano jak techniczne zaplecze. W tym samym czasie EY policzył, że zaledwie 9 procent średnich i dużych firm w Polsce dysponuje infrastrukturą danych gotową do zasilenia modeli AI.
Ten rozjazd opisaliśmy w raporcie „Dane podstawowe w polskich przedsiębiorstwach“: 28 stron, dziesięć rozdziałów, każda liczba z nazwą źródła i datą. Raport pobierzecie na dole tego wpisu - bez formularza i bez zostawiania adresu. Zanim to zrobicie, opowiemy, dlaczego w ogóle powstał i co z niego wynika dla Waszej organizacji.
Jedna firma, cztery wersje prawdy
Zacznijmy od sceny, którą znamy z projektów aż za dobrze.
Specjalistka do spraw rozliczeń wystawia fakturę dla stałego kontrahenta. W ERP ten kontrahent ma pełną nazwę i NIP z czasów, gdy podpisywano umowę. W CRM handlowiec zapisał go skrótem, z adresem biura, które firma opuściła dwa lata temu. W systemie zakupowym istnieje jeszcze raz, bez NIP-u, bo tak było szybciej. Każda z tych wersji jest lokalnie poprawna. Żadna nie jest pełna.
Do stycznia 2026 roku ta sytuacja kosztowała głównie cierpliwość: uzgadnianie sald, wyjaśnianie warunków płatności, raport zarządczy składany z trzech źródeł. Koszt istniał, ale rozkładał się na tyle osób i działów, że w żadnym budżecie nie miał własnej linii. Dziś ta sama rozbieżność ma adresata i termin. Fakturę z błędnym NIP-em KSeF doręczy niewłaściwej firmie, a naprawa będzie wymagała korekty do zera i nowego dokumentu.
Skala tego mechanizmu przestała być teoretyczna. I to jest pierwszy z trzech powodów, dla których ten raport powstał właśnie teraz.
Powód pierwszy: KSeF sprawdza kartoteki codziennie
Od 1 lutego do 26 maja 2026 roku przez Krajowy System e-Faktur przeszło ponad 289 milionów e-faktur od ponad 2 milionów wystawców (dane Ministerstwa Finansów). To pierwszy mechanizm w historii polskiej gospodarki, który sprawdza kartoteki kontrahentów ponad dwóch milionów podatników jednocześnie, każdego dnia roboczego.
Sprawdza je jednak inaczej, niż wiele firm zakłada. KSeF waliduje zgodność pliku ze schematem, natomiast nie weryfikuje merytorycznie, czy NIP nabywcy należy do podmiotu, którego dotyczy transakcja. Faktura z numerem pomylonym o cyfrę otrzyma numer KSeF i zostanie udostępniona firmie o tym numerze, a jeżeli taki NIP nie istnieje, nie zostanie udostępniona nikomu. Takie stanowisko przedstawił Dyrektor KIS w interpretacji indywidualnej z marca 2026 roku.
Zmieniła się też droga naprawy błędu. Noty korygujące przestały istnieć, więc nabywca nie poprawi już cudzej pomyłki jednym dokumentem; błędny NIP oznacza po stronie wystawcy korektę do zera i nową fakturę. Przy jednej pomyłce to niedogodność. Przy kartotece z setkami nieaktualnych rekordów i tysiącach dokumentów miesięcznie to stały proces obsługi wyjątków, który ktoś musi wykonywać ręcznie.
Pierwsze miesiące działania systemu pokazały, że nie jest to problem marginalny. Doradcy podatkowi opisywali numery VAT UE wpisywane w miejsce NIP i podwójny obieg dokumentów, a według danych jednego z dostawców oprogramowania 18 procent faktur korygujących pobieranych z KSeF zawiera błędy. Tę ostatnią liczbę traktujcie ostrożnie, bo pochodzi z próby klientów jednego dostawcy - ale kierunek pokazuje wyraźnie. Okres bez sankcji kończy się wraz z rokiem 2026. Mechanizm zostaje na zawsze.
Powód drugi: kalendarz migracji, który nie zaczeka
Drugi proces ma dokładne daty. Podstawowe wsparcie SAP dla systemów ECC kończy się 31 grudnia 2027 roku, a według badania grupy użytkowników DSAG z lutego 2026 roku z ECC lub starszych wersji Business Suite wciąż korzysta 54 procent ankietowanych organizacji. Microsoft ogłosił zakończenie standardowego wsparcia Dynamics GP z końcem 2029 roku. Na polskim rynku, gdzie obok SAP silną pozycję mają Comarch i dostawcy krajowi, ten sam moment przychodzi przy zmianie wersji systemu albo konsolidacji po przejęciu.
Każda z tych operacji jest w praktyce migracją danych. I tu tkwi pułapka, którą widzimy w harmonogramach projektów: konwersja przenosi dane do nowej struktury, ale nie poprawia ich jakości. Trzy warianty tego samego kontrahenta wjadą do nowego systemu jako trzy oddzielne rekordy, o ile ktoś ich wcześniej nie scali. Rekord z brakiem w polu wymaganym przez nowy model wróci do zespołu jako wyjątek do ręcznej obsługi - zwykle w oknie przełączenia systemów, czyli wtedy, gdy zespół ma najmniej czasu, a każda godzina przestoju najwięcej kosztuje.
Liczby z rynku potwierdzają, że to nie jest ryzyko papierowe. Według ISG 58 procent programów migracji SAP przekracza budżet i harmonogram, a w terminie i budżecie mieści się 15 procent. Właściwa kolejność jest odwrotna do tej, którą widzimy najczęściej: najpierw pomiar duplikatów i braków, potem deduplikacja z udziałem właściciela danych, dopiero potem migracja. Ta sama praca wykonana po uruchomieniu kosztuje więcej, bo odbywa się pod presją produkcyjną.
Powód trzeci: AI obnażyła stan kartotek szybciej niż audyt
Trzeci proces jest najmłodszy i działa najszybciej. Modele językowe i agenci nie sprawdzają, czy dane są prawdziwe - odpowiadają na podstawie tego, co otrzymają, równie stanowczo przy danych spójnych i sprzecznych. Agent zapytany o saldo kontrahenta, który występuje w systemach w czterech wariantach, poda odpowiedź natychmiast. Nie zasygnalizuje, że wybrał jeden z czterech możliwych rekordów.
Automatyzacja postawiona na niespójnych danych nie usuwa nieporządku. Zwiększa jego tempo i zasięg.
Prognozy analityków mówią o tym od dwóch lat: według Gartnera do końca 2026 roku organizacje porzucą 60 procent projektów AI, które nie zostały wsparte danymi gotowymi do pracy z AI. Polskie dane układają się w tę prognozę bez naciągania. Technologie AI stosuje u nas 8,7 procent przedsiębiorstw (GUS, 2025), przy średniej unijnej 20 procent (Eurostat), a kompletną infrastrukturę danych pod AI deklaruje wspomniane 9 procent średnich i dużych firm. Modele są dostępne od ręki. Przygotowane dane nie.
Polska na tle: systemy są, porządku w danych brak
Gdy zestawiliśmy statystykę publiczną z badaniami rynkowymi, wyszedł obraz, który dobrze tłumaczy codzienne doświadczenie polskich zespołów. Infrastruktura istnieje i rośnie: z systemów ERP korzysta 40,5 procent przedsiębiorstw, płatne usługi chmurowe kupuje ponad połowa (GUS, 2025). Praca na danych wygląda skromniej: analizę danych wykonuje 24,5 procent polskich firm, podczas gdy w Danii 60 procent (Eurostat, 2025).
Za średnimi kryje się przy tym silne rozwarstwienie. Technologie AI stosuje 42 procent dużych firm, 15,6 procent średnich i zaledwie 6,1 procent małych (GUS, 2025). Duże organizacje eksperymentują, średnie dopiero wchodzą - i to właśnie one najczęściej odkrywają, że pierwszą przeszkodą nie jest budżet na model, tylko stan własnych kartotek.
Najciekawsze są jednak deklaracje samych organizacji. W badaniu Algolytics i SW Research na próbie ponad 700 firm 73 procent przedsiębiorstw przyznało, że brakuje im kompetencji do wykorzystania potencjału danych, a 66 procent nie wykorzystuje danych w procesach decyzyjnych. To nie są liczby o technologii. To liczby o tym, że między systemami a decyzjami brakuje warstwy, która rozstrzyga, który rekord jest właściwy i kto odpowiada za jego poprawność.
Jest jeszcze jeden polski wątek, o którym rzadko myśli się w kategoriach danych: fuzje i przejęcia. W 2025 roku na polskim rynku odnotowano 330 takich transakcji (M&A Index Poland), z rekordową sprzedażą 49 procent akcji Santander Bank Polska na rzecz Erste Group. Każde przejęcie oznacza łączenie katalogów kontrahentów, indeksów materiałowych i planów kont prowadzonych według różnych zasad. Publicznych badań mierzących skalę tego zjawiska w Polsce brak - piszemy o tym w raporcie wprost - ale z projektów w grupach kapitałowych po akwizycjach, w tym w koncernie chemicznym łączącym dane pięciu spółek z trzech krajów, znamy powtarzalny wzorzec: pierwsze tygodnie integracji schodzą na ustalenie, która spółka używa którego katalogu i czym różnią się definicje pozornie tych samych pojęć.
W raporcie poświęcamy tej warstwie osobny rozdział, razem z pytaniem, którego to zestawienie wymaga: skoro kupiliśmy systemy, dlaczego nie ufamy temu, co z nich wychodzi?
Dlaczego programy naprawcze zawodzą
Odpowiedź „zróbmy wielki projekt porządkowania danych“ ma słabą statystykę. Gartner prognozował, że ponad 75 procent programów zarządzania danymi podstawowymi nie osiągnie zakładanych celów biznesowych. Z naszych projektów i rozmów przedwdrożeniowych wynika, że przyczyny rzadko leżą w technologii. Powtarzają się cztery wzorce: zakres obejmujący wszystkie domeny naraz, komitet zamiast właściciela danych z mandatem do decyzji, scalanie rekordów w pełni automatyczne oraz jednorazowe czyszczenie bez reguł pilnujących jakości nowych wpisów. Ten ostatni błąd jest najbardziej zdradliwy, bo daje efekt na kwartał - a potem kartoteka wraca do stanu wyjściowego i organizacja zostaje z przekonaniem, że „już to robiliśmy i nie zadziałało“.
W pilotażach danych podstawowych najrzadziej zaskakuje nas technologia. Najczęściej to, jak szybko zapadają decyzje, gdy zamiast opinii na stole leży pomiar.
Dlatego w raporcie opisujemy podejście odwrotne do rynkowego: jedna domena danych, jedno kryterium sukcesu ustalone przed startem i wynik mierzony na rzeczywistych danych organizacji w tygodniach, nie kwartałach.
W praktyce ta metoda składa się z czterech kroków. Najpierw wybór domeny, która generuje najwięcej pracy ręcznej i sporów o liczby - najczęściej są to kontrahenci albo indeksy materiałowe. Potem pomiar stanu: liczba duplikatów, braki w polach krytycznych, rozbieżności między systemami; pomiar pozwala oprzeć decyzję na liczbach zamiast na opiniach. Trzeci krok to reguły rekordu wzorcowego, z normalizacją nazw i właścicielem danych, który ma mandat do rozstrzygania sporów. Dopiero czwarty krok to scalanie - i tu ważny szczegół: modele językowe trafnie podpowiadają, że dwa zapisy mogą opisywać ten sam podmiot, ale decyzję o połączeniu zatwierdza człowiek, bo błędne scalenie dwóch odrębnych firm jest droższe w naprawie niż duplikat. Każda zmiana zostaje w śladzie audytowym.
Pilot jednej domeny zamykamy zwykle w cztery do ośmiu tygodni. W ten sposób pracujemy między innymi z Medicoverem w domenie danych pracowniczych: 18 krajów, około 45 tysięcy pracowników i około 100 tysięcy zdarzeń na danych rocznie, z pełną historią zmian i obiegiem akceptacji - projekt uznany przez SAP za oficjalną referencję, jedną z trzech w Polsce. Do typowych mierników pilota należą udział duplikatów w domenie, kompletność pól krytycznych i czas rozstrzygnięcia spornego rekordu - wielkości, które da się porównać przed i po.
Kiedy porządkowanie danych nie jest Waszym priorytetem
Bylibyśmy nieuczciwi, gdybyśmy twierdzili, że ta praca jest pilna dla każdego. Jeżeli działacie na jednym systemie, kartoteka liczy kilkuset kontrahentów, a faktury obsługuje jedna osoba, która zna ich wszystkich - KSeF przejdziecie na dyscyplinie operacyjnej, bez osobnej warstwy danych.
Odradzamy start także wtedy, gdy organizacja oczekuje jednorazowego czyszczenia bez wskazania właściciela danych po stronie biznesu, planuje objąć wszystkie domeny naraz przed pierwszym potwierdzonym wynikiem albo nie ma nikogo, kto rozstrzygnie sporny rekord merytorycznie. W takich warunkach projekt skończy się dokładnie tak, jak w statystyce Gartnera - a szkoda pieniędzy i zaufania. Jasna kwalifikacja oszczędza obu stronom kwartał rozmów bez wyniku.
Priorytet mają organizacje, które przygotowują migrację systemu, konsolidują spółki po przejęciach, uruchamiają automatyzację lub AI na danych operacyjnych albo muszą wykazać wobec audytora, gdzie leżą dane i kto ma do nich dostęp. Jeżeli rozpoznajecie się w którymkolwiek z tych zdań, raport pisaliśmy dla Was.
Zmierzcie to u siebie, zanim wydacie złotówkę
Najpraktyczniejsza strona raportu nie wymaga od Was żadnej decyzji zakupowej. Skalę problemu w jednej domenie można oszacować własnymi siłami w kilka dni. Wystarczy wyciąg z kartoteki kontrahentów i cztery pytania:
- Ile rekordów ma ten sam NIP przy różnych nazwach lub adresach?
- Ile rekordów ma braki w polach, które Wasze procesy uznają za krytyczne?
- Ile pozycji różni się między ERP a CRM dla tych samych podmiotów?
- Kto rozstrzyga, która wersja jest właściwa, i ile czasu to zajmuje?
Odpowiedź „nie wiemy“ na którekolwiek z nich również jest wynikiem pomiaru, i to najbardziej pouczającym. A jeżeli wolicie, żeby ten pomiar wykonał ktoś z zewnątrz: robimy to na próbce z jednej domeny i przekazujemy wynik z rekomendacją zakresu w pięciu dniach roboczych. Szczegóły znajdziecie na stronie pomiaru duplikatów.
Pobierzcie raport
Raport SNOK · sierpień 2026
Dane podstawowe w polskich przedsiębiorstwach
PDF, 28 stron, ok. 0,9 MB - bez formularza i bez podawania danych. Raport możecie swobodnie przekazać dalej w zespole - do tego został pomyślany.
Pobierz raport (PDF)W środku znajdziecie to, czego nie zmieścił ten wpis: pełny rozdział o rynku i przejęciach, szczegółową mechanikę KSeF z interpretacją KIS, dane DSAG i ISG o migracjach, cztery antywzorce programów naprawczych z opisem, metodę przyrostową krok po kroku oraz notę metodyczną z kompletem źródeł.
Od raportu do pierwszego wyniku
Jeżeli po lekturze uznacie, że temat dotyczy Waszej organizacji, proponujemy drogę, którą przechodzimy z klientami najczęściej. Zaczynamy od pomiaru duplikatów na próbce jednej domeny - wynik z rekomendacją zakresu dostajecie w pięć dni roboczych. Jeżeli liczby potwierdzą problem, przeprowadzimy proof of concept na platformie SNOK MDM: pilot jednej domeny na Waszych rzeczywistych danych, z kryterium sukcesu ustalonym przed startem i wynikiem, który da się porównać przed i po. Chcecie najpierw zobaczyć platformę w działaniu? Umówcie demo SNOK MDM albo po prostu napiszcie do nas - opowiecie o swoich systemach, my o tym, od której domeny zaczęlibyśmy u Was.
Tydzień temu na tym blogu ukazał się felieton o dwudziestu latach z danymi podstawowymi - dobre uzupełnienie perspektywy, tym razem osobistej. Pytania do autorów raportu kierujcie wprost: Jacek Bugajski (jacek.bugajski@snok.ai) i Michał Korzeń (michal.korzen@snok.ai).
