Kupiec zamawia część, która leży już na półce. Nie z niedbalstwa: indeks materiałowy istnieje w systemie dwa razy, pod dwiema nazwami, i nie ma powodu, żeby ktokolwiek to zauważył przed dostawą. Ten sam kontrahent ma w ERP pełną nazwę, w CRM skrót wpisany ręcznie, w systemie zakupowym brak numeru identyfikacyjnego, a w magazynie adres sprzed przeprowadzki. Każdy z tych systemów ma rację lokalnie. Żaden nie ma pełnej.
Zajmuję się tym problemem od dwudziestu lat. W tym czasie zmieniło się prawie wszystko w technologii, a nie zmieniło się nic w samym problemie. Zmieniło się natomiast to, ile trzeba zainwestować, żeby go rozwiązać. O tym jest ten tekst.
Kiedy diagram architektury nie mieścił się na dwóch kartkach
Pierwsze wdrożenie danych podstawowych sprzedawałem w czasach, gdy wszystko było stosem. NetWeaver, w nim SAP MDM, obok Portal, obok PI, każdy element z własną instalacją, własnym ekspertem i własnym zestawem problemów. Diagram architektury nie mieścił się na jednej kartce A4 i nie mieścił się też na dwóch.
Kilka instytucji w Polsce kupiło wtedy to rozwiązanie i dostało dokładnie to, czego potrzebowało: jedno miejsce, w którym rozstrzyga się, kto jest kim i co jest czym. Uważam tę sprzedaż za dobrą do dziś, bo wartość była realna. Cena natomiast była wysoka i nie chodziło o licencje.
Żeby uruchomić jedną funkcję, zespół klienta musiał opanować dziesięć technologii wokół niej. Pół roku wdrożenia szło na naukę stosu, nie na porządkowanie danych. W tym czasie w projekcie zmieniał się właściciel, czasem sponsor, a bywało, że priorytety całej organizacji. Kto pracował przy takich wdrożeniach, wie, że najtrudniejszy nie jest model danych. Najtrudniejsze jest utrzymanie uwagi organizacji dłużej niż dwa kwartały.
Wtedy nie było alternatywy. Dziś jest, i to jest sedno całej zmiany.
Dlaczego ten temat zawsze przegrywał budżet
Dane podstawowe mają wadę wrodzoną: nie da się ich pokazać. Nie ma ekranu, który zrobi wrażenie na zarządzie, nie ma wykresu idącego w górę, nie ma efektu w kwartale. W harmonogramach lądują tam, gdzie dokumentacja i testy wydajnościowe, z adnotacją „druga faza“. Druga faza rzadko się zaczyna.
Koszt zwłoki nie znika. Rozprasza się po organizacji tak, że nikt nie widzi go w całości.
Każda z tych pozycji osobno wygląda na drobiazg. Razem to jedna z najdroższych prac w firmie i jednocześnie ta, której nikt nie rozlicza, bo rozkłada się na kilkanaście osób w kilku działach. W żadnym budżecie nie ma linii „uzgadnianie danych“, więc formalnie ten koszt nie istnieje.
Co zmieniło się w ciągu jednego roku
Rynek przestał traktować tę warstwę jako zaplecze, i to nie na podstawie deklaracji, a transakcji.
Salesforce kupił Informaticę, transakcja zamknęła się 18 listopada 2025 roku. SAP kupił Reltio, zamknięcie 7 maja 2026, i w komunikacie postawił sprawę wprost: chodzi o przygotowanie danych z SAP i poza SAP pod sztuczną inteligencję. W kwietniu 2026 Gartner przywrócił Magic Quadrant dla rozwiązań Master Data Management po pięciu latach przerwy, a analitycy nie wracają do porzuconej kategorii bez powodu.
Trzy niezależne sygnały w jednym roku wyglądają na korektę wyceny, nie na modę. Warstwa danych wzorcowych przeszła z kategorii kosztu zaplecza do kategorii warunku działania. Dla firm w Polsce ma to jedną praktyczną konsekwencję: temat, który dotąd trzeba było w organizacji tłumaczyć od zera, ma dziś zewnętrzne uzasadnienie na poziomie zarządu.
Sztuczna inteligencja podniosła stawkę
Powód tej korekty jest praktyczny i widać go w każdym projekcie, w którym agent dotyka danych operacyjnych.
Agent pracuje na tym, co dostanie. Przy czterech wersjach tego samego kontrahenta odpowie natychmiast i z pełną pewnością, również wtedy, gdy odpowiedź jest nieprawdziwa. Nie zapyta, która wersja jest właściwa, bo nie ma jak tego rozstrzygnąć. Model językowy nie odróżnia niekompletnych danych od kompletnych; odróżnia tylko dane, które ma, od tych, których nie ma.
Gartner prognozuje, że w horyzoncie 2026 roku organizacje porzucą 60 procent projektów sztucznej inteligencji, które nie będą wsparte danymi gotowymi pod AI (komunikat Gartnera z 26 lutego 2025). Ta prognoza nie dotyczy modeli. Dotyczy tego, że automatyzacja nie porządkuje danych, tylko zwiększa tempo i zasięg tego, co już w nich jest.
Dotyczy to również automatyzacji, którą wdrażamy sami. Robot przepisujący dane szybciej niż człowiek przepisze też błąd szybciej i w większej liczbie miejsc. Dlatego przy każdym projekcie agentowym pytamy o stan danych podstawowych, zanim ustalimy zakres.
Dlaczego większość programów MDM nie dowozi
Gartner szacował, że w horyzoncie 2025 roku ponad 75 procent programów Master Data Management nie spełni oczekiwań biznesowych. Ta liczba mówi mniej o narzędziach, a więcej o sposobie prowadzenia projektów. Widziałem trzy powtarzalne warianty tej porażki.
Wariant pierwszy: zakres bez granicy. Zaczyna się od rozsądnie brzmiącej decyzji: skoro porządkujemy dane, zrobimy to od razu we wszystkich domenach. Zakres wymaga uzgodnień między działami, więc powstaje komitet. Komitet powołuje zespół roboczy. Zespół roboczy prowadzi warsztaty o nazewnictwie pól, które trwają dłużej niż budowa rozwiązania. Po roku nie ma wyniku, są slajdy i szczera opinia w organizacji, że „MDM u nas nie działa“.
Wariant drugi: czyszczenie bez reguł. Pozornie tańszy i szybszy. Firma zamawia jednorazowe uporządkowanie kartoteki, dostaje czysty plik i zamyka projekt. Nikt nie zmienił natomiast sposobu, w jaki dane wchodzą do systemu, i nikt nie odpowiada za ich poprawność. Po kwartale kartoteka wraca do stanu wyjściowego, a organizacja ma dowód, że „to się nie da utrzymać“.
Wariant trzeci: właściciel bez mandatu. Projekt ma sponsora w IT i nikogo po stronie biznesu, kto może rozstrzygnąć sporny rekord. Każda wątpliwość wraca na komitet, komitet nie chce brać odpowiedzialności za skutki decyzji, więc rekordy zostają w kolejce. Kolejka rośnie i po pewnym czasie sama staje się argumentem przeciwko projektowi.
Wspólny mianownik wszystkich trzech: brak wyniku, który da się zmierzyć przed pracą i po niej. Jeśli nie wiadomo, co ma się poprawić i o ile, nie ma jak obronić projektu w połowie drogi, a każdy projekt danych w połowie drogi bywa atakowany.
Jak weszliśmy w ten temat: od RODO i DORA do produktu
W SNOK zajmujemy się danymi podstawowymi od trzech lat i nie zaczęliśmy od strategii MDM ani od pomysłu na produkt. Zaczęliśmy od pytania, które przynosili klienci: gdzie w systemach źródłowych znajdują się konkretne dane, kto ma do nich dostęp i jak wykazać to audytorowi, gdy przychodzi RODO albo DORA.
Brzmi jak zadanie na tydzień. W praktyce to przejście przez wszystkie kartoteki, wszystkie kopie tych samych rekordów i wszystkie eksporty do arkuszy, które ktoś kiedyś zrobił „na chwilę“, a potem został na nich proces. Zrobiliśmy to kilkukrotnie i za którymś razem zobaczyliśmy, że budujemy wciąż ten sam mechanizm: porównywanie rekordów, historia zmian, ślad audytowy, kolejka decyzji dla biznesu.
W tym momencie przestało to być zestawem skryptów, a stało się produktem. Tak powstał SNOK MDM: z wymagania audytowego, nie z prezentacji o wizji. Uważam to za lepszą genezę niż większość planów rozwoju produktu, jakie widziałem, bo pierwszy użytkownik był realny i miał termin.
Dowód z wdrożenia. W obszarze danych podstawowych pracowników pracujemy z Medicoverem: 18 krajów, około 45 tysięcy pracowników i około 100 tysięcy zdarzeń na danych pracowniczych rocznie obsługiwanych przez platformę. To wdrożenie dotyczy tej jednej domeny i tak je opisujemy, bez rozciągania na kontrahentów, materiały czy finanse, które porządkujemy u innych klientów.
Czym jest golden record i czego za Was nie zrobi
Golden record to jeden rekord wzorcowy opisujący realny obiekt: konkretnego kontrahenta, materiał, produkt lub pracownika. Powstaje z reguł, czyli z normalizacji zapisu, walidacji pól krytycznych i rozstrzygania konfliktów między źródłami, a nie z uzgodnień na spotkaniu. Ma właściciela po stronie biznesu, historię zmian i ślad audytowy. Systemy źródłowe pracują dalej, nikt ich nie wyłącza ani nie przebudowuje.
Obok tego stoi warstwa danych referencyjnych, w skrócie RDM. Najprościej: MDM odpowiada na pytanie, kto i co, a RDM daje wspólny język, czyli słowniki, kody, klasyfikacje i jednostki organizacyjne. Bez tej drugiej warstwy rekordy wzorcowe są opisywane w każdej spółce inaczej i raporty nadal się rozjeżdżają, tylko już na bardziej zaawansowanym poziomie.
Niezależność od ERP i CRM. Warstwa wzorcowa nie musi żyć wewnątrz systemu transakcyjnego. Gdy stoi osobno, zmiana ERP, wdrożenie nowego CRM albo przejęcie spółki nie unieważniają porządku w danych. W grupach kapitałowych, gdzie liczba systemów bywa trzycyfrowa, to różnica między projektem a ciągłym remontem.
Decyzja człowieka w scalaniu. Modele językowe rozpoznają warianty zapisu tej samej firmy trafnie i potrafią uzasadnić propozycję. To jednak wynik probabilistyczny, więc scalenie zatwierdza data steward. Automatyczne połączenie dwóch odrębnych podmiotów jest błędem, który wychodzi miesiące później, zwykle przy windykacji albo audycie, i naprawia się go trudniej niż duplikat. Podpowiedź maszyny plus zatwierdzenie człowieka to dziś najlepsza relacja jakości do tempa.
Czego golden record nie zrobi. Nie zastąpi decyzji biznesowej o tym, który wariant nazwy jest obowiązujący. Nie naprawi procesu, w którym pięć osób może utworzyć nowego kontrahenta bez walidacji. Nie zmieni sytuacji, w której nikt nie odpowiada za jakość danych. Warstwa techniczna wymusza porządek tylko tam, gdzie ktoś ten porządek zdefiniował.
Sześć domen i kolejność, w jakiej warto je porządkować
W praktyce cała rozmowa o MDM dotyczy sześciu domen: kontrahentów i klientów, dostawców, materiałów i indeksów, produktów, pracowników oraz kont finansowych. Nie ma jednej właściwej kolejności dla wszystkich, jest natomiast pytanie, które ją wyznacza: która domena generuje dziś najwięcej pracy ręcznej i najwięcej sporów o liczby.
Kilka typowych rozstrzygnięć z projektów:
- Grupa kapitałowa po akwizycjach zaczyna zwykle od kontrahentów i dostawców, bo tam boli konsolidacja sprawozdawcza i tam najszybciej widać efekt na poziomie grupy.
- Produkcja i utrzymanie ruchu zaczynają od indeksów materiałowych, bo duplikat indeksu to zamówienie części, która leży na magazynie, i przestój, gdy właściwej części nie ma.
- Organizacja przed konwersją do S/4HANA zaczyna od kontrahentów, bo ich stan przekłada się bezpośrednio na liczbę wyjątków w migracji.
- Firma usługowa z rozproszonymi kadrami zaczyna od pracowników, bo tam regulacje są najbardziej wymagające, a liczba zdarzeń najwyższa.
- Organizacja finansowa pod DORA zaczyna od tego, co pozwala odpowiedzieć na pytanie audytora: gdzie są dane krytyczne i kto ma do nich dostęp.
Zasada jest jedna: pierwsza domena musi mieć właściciela, mierzalne kryterium sukcesu i realny ból w procesie. Domena wybrana dlatego, że „technicznie jest najprostsza“, nie przekona nikogo do finansowania drugiej.
Przed konwersją do S/4HANA, nie po niej
Jeśli szukacie momentu, w którym ta praca zwraca się najszybciej, wyznacza go dziś harmonogram migracji.
W S/4HANA model Business Partner jest obowiązkowy. Klient i dostawca przestają być osobnymi bytami prowadzonymi niezależnie, a przejście na nowy model realizuje Customer Vendor Integration. To warunek konwersji do S/4HANA, nie opcja do rozważenia w kolejnej fazie.
Zadaniem CVI jest przeniesienie danych do nowej struktury. Poprawa ich jakości nie jest jego zadaniem i nie zdarza się sama. W praktyce oznacza to trzy rzeczy:
- Duplikaty przechodzą dalej. Jeśli ten sam kontrahent istnieje w trzech wariantach, konwersja ich nie połączy. Trzy rekordy mają wszelkie szanse zostać trzema partnerami biznesowymi, o ile wcześniej ktoś ich nie scali.
- Braki zatrzymują pozycje. Rekord bez pola wymaganego przez nowy model wraca do zespołu jako wyjątek do obsługi ręcznej. Zakres tych wyjątków zależy od konfiguracji i mapowania, dlatego skalę ustala się pomiarem na własnej kartotece, a nie założeniem.
- Rozstrzygnięcia wymagają biznesu, nie IT. Pytanie, czy dwa podobne rekordy to ten sam podmiot, wymaga wiedzy z zakupów, sprzedaży lub finansów. Te osoby w oknie cutover mają inne zadania, a lista wyjątków nie czeka.
Całość da się poprowadzić równolegle z przygotowaniem projektu S/4HANA, bez wydłużania harmonogramu o ani jeden tydzień. Po drugiej stronie, czyli po go-live, ta sama praca kosztuje więcej i wykonuje się ją pod presją produkcyjną.
Czego wymagają regulacje
Trzy obowiązki dotykają danych podstawowych bezpośrednio i żaden nie czeka na wewnętrzny harmonogram.
RODO, artykuł 5 wymaga prawidłowości danych osobowych. Dane osób reprezentujących kontrahentów są danymi osobowymi, więc kartoteka kontrahentów jest również zbiorem danych osobowych, z obowiązkiem aktualności i możliwością realizacji praw osób, których dane dotyczą.
KSeF wprowadza ustrukturyzowaną fakturę o setkach pól. Nie każdy błąd w danych kontrahenta powoduje techniczne odrzucenie dokumentu, ale niespójna kartoteka podnosi ryzyko odrzuceń i praktycznie gwarantuje obsługę wyjątków w trybie ręcznym, w procesie, w którym wcześniej nikt tej pracy nie planował. Terminy i zakres obowiązku warto sprawdzać u źródła, bo zmieniały się kilkukrotnie.
DORA wymaga od podmiotów finansowych wykazania, gdzie znajdują się dane krytyczne i kto ma do nich dostęp. Bez warstwy wzorcowej i bez rejestru pochodzenia danych to ręczna inwentaryzacja przed każdym audytem, powtarzana od zera. To dokładnie te pytania, od których zaczęła się nasza droga do produktu.
Jedna domena zamiast programu na rok
Nasza metoda wynika bezpośrednio z obserwacji, dlaczego duże programy nie dowożą. Pięć kroków, w tej kolejności.
Krok pierwszy: wybór domeny i kryterium sukcesu. Jedna domena i jedno zdanie, które da się sprawdzić. Nie „poprawimy jakość danych“, ale na przykład „liczba rekordów kontrahentów opisujących ten sam podmiot spada poniżej ustalonego progu, a nowe rekordy przechodzą walidację numeru identyfikacyjnego“.
Krok drugi: pomiar stanu. Na rzeczywistych danych organizacji, nie na wzorcu z rynku. Liczba duplikatów w domenie, udział rekordów z brakami w polach krytycznych, liczba rozbieżności między systemami. Ten pomiar zmienia rozmowę o zakresie z wymiany opinii na decyzję opartą na liczbie i jest jedynym argumentem, który realnie działa na zarząd.
Krok trzeci: model rekordu wzorcowego i reguły. Normalizacja zapisu, zasady rozstrzygania konfliktów między źródłami, wersjonowanie, właściciel danych po stronie biznesu, zakres pól obowiązkowych. To etap, na którym rozstrzyga się, czy porządek utrzyma się po projekcie.
Krok czwarty: pilot z nadzorem człowieka. Uruchomienie warstwy wzorcowej dla wybranej domeny, kolejka scaleń z uzasadnieniem, zatwierdzanie przez data stewarda, zasilenie systemów docelowych. Pilot jednej domeny zamykamy zwykle w cztery do ośmiu tygodni, zależnie od stanu danych i liczby systemów do zasilenia.
Krok piąty: mierniki i rozszerzenie. Porównanie z pomiarem wyjściowym, raport jakości danych jako element rutyny, dopiero potem kolejna domena. Bez potwierdzonego wyniku nie rozszerzamy zakresu, choćby klient chciał.
Po stronie klienta zostaje to, czego nie da się zlecić: wiedza o własnym biznesie i decyzje w sprawach spornych. Stos technologiczny zostaje po naszej stronie, i to jest jedyna zmiana wobec projektów, które prowadziłem dwadzieścia lat temu.
Jak zmierzyć duplikaty u siebie, zanim kogokolwiek zaprosicie
Ten pomiar można zrobić samodzielnie i warto, bo daje punkt odniesienia w każdej dalszej rozmowie. Cztery kroki na jednej domenie, na przykład na kartotece kontrahentów.
- Wyciąg z jednego systemu. Nazwa, forma prawna, numer identyfikacyjny, adres, data utworzenia, status aktywności. Bez integracji, zwykły eksport.
- Normalizacja do porównania. Usuńcie formy prawne, znaki interpunkcyjne i wielkość liter z nazw, ujednolićcie zapis adresów, oczyśćcie numery identyfikacyjne ze spacji i myślników.
- Testy, które wystarczą, żeby zobaczyć skalę. Ile rekordów ma identyczny numer identyfikacyjny przy różnych nazwach. Ile ma identyczną znormalizowaną nazwę przy różnych numerach. Ile w ogóle nie ma numeru.
- Próbka do weryfikacji ręcznej. Pięćdziesiąt losowych par z wyników i decyzja człowieka: ten sam podmiot czy nie. Odsetek trafień pokazuje, ile z automatycznie wskazanych przypadków jest realne.
Z naszych projektów wynika prosta reguła orientacyjna: gdy wynik przekracza kilka procent kartoteki, macie temat na osobny projekt. Jeśli nie chcecie tego robić sami, robimy ten pomiar na próbce z jednej domeny i przekazujemy wynik w pięciu dniach roboczych, bez dostępu do środowiska produkcyjnego, na danych, które mogą być pseudonimizowane.
Kiedy MDM nie jest odpowiedzią
Nie każdy problem z danymi wymaga warstwy wzorcowej.
Jeśli macie jeden system i jedną kartotekę, a problemem jest brak walidacji przy wprowadzaniu danych, potrzebujecie reguł w tym systemie, nie nowej platformy. Jeśli dane są spójne, a rozjeżdżają się raporty, problem leży w definicjach wskaźników i w warstwie analitycznej. Jeśli organizacja nie ma nikogo, kto może rozstrzygnąć sporny rekord, wdrożenie MDM da kolejkę decyzji, której nikt nie obsłuży; wtedy pierwszym krokiem jest ustalenie właścicielstwa, nie projekt techniczny.
Warstwa wzorcowa ma sens tam, gdzie ten sam obiekt żyje w wielu systemach naraz i gdzie ktoś jest gotów wziąć odpowiedzialność za to, która wersja jest obowiązująca.
Co się nie zmieniło
Po dwudziestu latach problem jest ten sam. Ten sam kontrahent figuruje w czterech systemach w czterech wersjach, kupiec zamawia część, która leży na półce, a raport zarządczy powstaje w pliku o nazwie „wersja ostateczna poprawiona 3“.
Zmieniło się to, ile trzeba zainwestować, żeby to naprawić. Wtedy potrzebny był program, stos technologii i pół roku nauki. Dziś wystarczy jedna domena, jedno kryterium sukcesu i kilka tygodni pracy, a wynik jest widoczny, zanim zmieni się właściciel projektu.
W tym tygodniu i w kolejnych piszę o tym więcej: co dokładnie dzieje się z kartoteką kontrahentów przed konwersją do S/4HANA, jak wygląda pomiar duplikatów krok po kroku i dlaczego jedna domena bije program na cztery kwartały.
Najczęstsze pytania
Czym różni się MDM od hurtowni danych albo lakehouse? Hurtownia i lakehouse odpowiadają za gromadzenie, modelowanie i analizę danych. Nie rozstrzygają, który rekord kontrahenta jest właściwy i kto odpowiada za jego poprawność. Platformy nowoczesnego stosu danych, takie jak Snowflake czy Microsoft Fabric, nie mają wbudowanej warstwy master data; wnosi się ją osobno, własną konfiguracją albo rozwiązaniem partnerskim. Bez niej analityka konsoliduje niespójności, zamiast je usuwać.
Ile trwa wdrożenie MDM? Pilot jednej domeny zamyka się zwykle w cztery do ośmiu tygodni. Klasyczne programy planuje się w horyzoncie od kilku kwartałów do kilku lat. Różnica nie polega na tempie pracy, a na kolejności: najpierw potwierdzony wynik na jednej domenie, potem rozszerzanie zakresu.
Mamy SAP MDG w licencji. Po co nam cokolwiek innego? Jeśli MDG pokrywa Waszą potrzebę, rekomendujemy MDG i pomagamy je wykorzystać, bo to część naszej praktyki SAP. Pytanie brzmi, czy zakres obejmuje również dane z systemów spoza SAP i czy warstwa ma pozostać niezależna od ERP przy zmianie krajobrazu systemowego. Jeśli tak, potrzebna jest warstwa poza SAP.
Czy dane muszą opuścić naszą infrastrukturę? Nie muszą. SNOK MDM może działać w środowisku klienta, gdy wymaga tego polityka bezpieczeństwa albo architektura IT, a kod źródłowy może zostać zdeponowany w escrow na potrzeby ciągłości działania. Przetwarzanie z użyciem modeli językowych da się prowadzić lokalnie lub w chmurze klienta.
Jak wygląda bezpieczeństwo przy użyciu modeli językowych do deduplikacji? Model podpowiada, że dwa rekordy opisują ten sam podmiot, i uzasadnia podpowiedź. Decyzję zatwierdza data steward, bo wynik jest probabilistyczny. Zakres danych przekazywanych do modelu jest ograniczany i opisany w umowie powierzenia, a przetwarzanie może odbywać się bez wyprowadzania danych na zewnątrz.
Od czego zależy koszt projektu? Od liczby domen w zakresie, liczby systemów do odczytania i zasilenia, stanu danych wejściowych oraz wymagań dotyczących nadzoru nad danymi i śladu audytowego. Rozliczamy się za fazę ze zdefiniowanym zakresem i produktem końcowym. Wycenę ustalamy po pomiarze, bo przed nim każda kwota byłaby zgadywaniem.
Jak mierzymy efekt po pilocie? Miernikami ustalonymi przed startem: liczbą rekordów zduplikowanych w domenie, udziałem rekordów z brakami w polach krytycznych, liczbą rozbieżności między systemami i czasem obsługi zmiany w danych wzorcowych. Wynik porównujemy z pomiarem wyjściowym.
Jacek Bugajski jest CEO SNOK - polskiej firmy konsultingowej specjalizującej się w SAP, cyberbezpieczeństwie, automatyzacji i danych.
Źródła
- Salesforce: zamknięcie przejęcia Informatiki (18.11.2025)
- SAP News: zamknięcie przejęcia Reltio (07.05.2026)
- Gartner: Magic Quadrant for Master Data Management Solutions (06.04.2026; poprzednia edycja 06.12.2021)
- Gartner: Lack of AI-Ready Data Puts AI Projects at Risk (26.02.2025)
- SAP Community: FAQ Customer Vendor Integration przy konwersji do S/4HANA
- RODO, artykuł 5: zasada prawidłowości danych
- Rozporządzenie DORA (UE) 2022/2554, artykuły 8 i 9
- Ministerstwo Finansów: KSeF, plan wdrożenia