Business Partner w SAP S/4HANA: dane kontrahentów przed konwersją i w RISE with SAP

7 października 2026 roku SAP ogłosił, że konwersja SAP Business Suite 7 działającego na bazie danych innej niż SAP HANA do SAP S/4HANA będzie dostępna do końca 2030 roku. Później zostaje nowe wdrożenie albo wcześniejsze przeniesienie systemu na SAP HANA. Mainstream maintenance SAP ERP 6.0 kończy się z końcem 2027 roku, extended maintenance z końcem 2030 roku.

Każda z tych ścieżek prowadzi przez ten sam obiekt: Business Partner. Przygotowanie danych kontrahentów obejmuje wymagania CVI, decyzje o scalaniu rekordów i o zakresie migracji, a w RISE with SAP pozostaje w zakresie klienta.

Business Partner jako warunek konwersji do SAP S/4HANA

W SAP S/4HANA klient i dostawca są rolami jednego obiektu Business Partner. W SAP ERP 6.0 były to osobne kartoteki, prowadzone latami przez różne działy, z różną numeracją i własnymi słownikami. Integracja klientów i dostawców (Customer Vendor Integration, CVI) synchronizuje je z nowym modelem.

Simplification List dla SAP S/4HANA 2025 określa Business Partner jako obiekt obowiązkowy, a system bez działającego CVI zostaje odrzucony przy przejściu. Kontrola Simplification Item Check zatrzymuje Software Update Manager przy błędach o kodzie 12 na początku procesu oraz przy kodzie 8 i wyższym tuż przed przestojem. Wymóg obejmuje wszystkich klientów, dostawców i osoby kontaktowe we wszystkich mandantach.

SAP zaleca przeprowadzić synchronizację na tygodnie, a nawet miesiące przed konwersją, poza jej ścieżką krytyczną. W praktyce oznacza to, że dane kontrahentów trzeba uporządkować, zanim projekt konwersji na dobre ruszy.

Czego CVI i Migration Cockpit nie zrobią za Was

Narzędzia SAP stosują reguły zdefiniowane przez projekt. Nie ustalają, które dwa rekordy opisują tę samą firmę, czy klient i dostawca o tej samej nazwie mają zostać jednym obiektem Business Partner z dwiema rolami, ani którzy kontrahenci nieaktywni od lat w ogóle nie powinni trafić do nowego systemu.

Duplikat pod kilkoma numerami przechodzi jako kilka osobnych obiektów Business Partner. Klient i dostawca będący tą samą firmą dają dwa obiekty zamiast jednego, chyba że ktoś podejmie decyzję projektową. Brakujące pola obowiązkowe wracają jako wyjątki w próbach ładowania i w oknie przełączenia. Niespójne słowniki między spółkami da się zmapować, ale ktoś musi zdefiniować mapowanie.

SAP S/4HANA Migration Cockpit w nowym wdrożeniu tworzy dane i nie służy do ogólnej aktualizacji istniejących rekordów. SAP ostrzega też, że migracja danych osobowych, które powinny zostać usunięte, może zostać uznana za przetwarzanie bez podstawy prawnej. Porządek w kartotece jest więc warunkiem także w ścieżce nowego wdrożenia.

RISE with SAP: przygotowanie danych zostaje po Waszej stronie

Dokument podziału odpowiedzialności SAP dla RISE with SAP, Private Edition (wersja z lipca 2026 roku) wymienia CVI wśród zadań wyłączonych z usługi. Usługa konwersji systemu nie obejmuje działań przed konwersją techniczną i po niej, w tym prac przygotowawczych i porządkowych. Ogólna odpowiedzialność za projekt konwersji należy do klienta, a klient nie ma uprzywilejowanego dostępu do systemu operacyjnego.

RISE przenosi infrastrukturę i technikę konwersji na SAP. Dane kontrahentów, reguły ich scalania i decyzje o tym, co trafia do nowego systemu, zostają w Waszym zakresie i w zakresie partnera wdrożeniowego, jeżeli umowa mu je powierza. Ten podział warto zapisać w umowie, zanim zacznie się pierwsza próba konwersji.

Gdzie powstaje nakład pracy

Publiczne źródła nie podają nakładu przygotowania danych kontrahentów w podziale na etapy. Powtarzają się za to trzy punkty odniesienia: konwersja Business Partner przechodzi zwykle przez cztery-pięć przebiegów, dostawca narzędzi do jakości danych deklaruje 16-17 % duplikatów w kartotekach kontrahentów, a sama konwersja produkcyjna trwa od kilku godzin do doby.

O nakładzie decyduje przede wszystkim liczba rekordów wymagających decyzji człowieka i czas jednej decyzji, a nie liczba rekordów w kartotece. Przy 80 000 kontrahentów i 16 % przypadków do rozstrzygnięcia daje to 12 800 decyzji. Przy dwóch minutach na decyzję to 427 godzin pracy, przy pięciu minutach 1 067 godzin. Rozrzut pokazuje, dlaczego budżet tej części programu warto oprzeć na pomiarze własnej kartoteki.

Szacunek ekspercki SNOK: 28,5-46,5 % mniej pracy

Poniższe przedziały są szacunkiem eksperckim SNOK opartym na mechanizmie działania SNOK MDM na każdym etapie, nie pomiarem z projektów. Kalibrujemy je w pilotażu na danych organizacji.

Etap	Szacowana zmiana nakładu
profilowanie stanu	-50 do -70 %
reguły identyfikacji i scalania	-40 do -60 %
mapowanie do Business Partner	-10 do -20 %
reguły walidacji	-20 do -40 %
akceptacja biznesowa	-30 do -50 %
próby ładowania	-20 do -40 %
poprawki	-40 do -60 %

Przy ilustracyjnej strukturze nakładu (profilowanie 10 %, scalanie 15 %, mapowanie 20 %, walidacja 10 %, akceptacja 15 %, próby 15 %, poprawki 15 %) szacunek SNOK wskazuje redukcję łącznego nakładu o 28,5-46,5 %. W tym modelu największy wkład mają scalanie, w którym reguły rozstrzygają pary jednoznaczne, a do opiekuna danych trafiają tylko niejednoznaczne, oraz poprawki - po 6-9 punktów procentowych. Najmniejszy daje mapowanie, bo strukturę Business Partner nadal projektuje zespół. Szacunek nie uwzględnia przyspieszenia z asystentów AI.

Przygotowanie i utrzymanie danych kontrahentów w SNOK MDM

SNOK MDM jest naszą platformą do zarządzania danymi podstawowymi. Tworzy uzgodniony rekord kontrahenta (golden record) z danych SAP ERP 6.0, SAP S/4HANA i systemów spoza SAP, bez wymiany ERP.

Normalizacja. Forma prawna w nazwie albo w osobnym polu, adres w różnych układach, numer podatkowy z prefiksem kraju albo bez niego - reguły standaryzacji i słowniki modułu miniRDM sprowadzają te zapisy do jednej postaci. Mapowania wartości wymagane przez CVI powstają w tym samym miejscu i obowiązują w każdym przebiegu.

Dopasowanie z decyzją człowieka. Reguły deterministyczne uzgodnione z właścicielem domeny rozstrzygają pary jednoznaczne. Pary niejednoznaczne trafiają do opiekuna danych, bo błędne scalenie dwóch różnych kontrahentów może mieć poważne skutki operacyjne. Ślad audytowy zapisuje autora, datę i powód każdej zmiany wprowadzonej w platformie.

Weryfikacja w rejestrach. Podczas wdrożenia konfigurujemy uzgodnione sprawdzenia na białej liście VAT oraz w VIES, KRS i REGON. Wynik zostaje zapisany przy rekordzie z datą. Dane kontrahenta w Business Partner są podstawą faktur w KSeF, więc błędny numer podatkowy przenosi się na każdą fakturę.

Przekazanie do SAP S/4HANA. W konwersji systemu porządkujemy kartotekę w SAP ERP 6.0 przed konfiguracją CVI. W nowym wdrożeniu golden record jest źródłem ładowania. Dane przekazujemy w formacie SAP S/4HANA Migration Cockpit partnerowi wdrożeniowemu albo ładujemy je sami, jeżeli umowa RISE i podział odpowiedzialności powierzają ten etap SNOK.

Po uruchomieniu produkcyjnym. Nowi kontrahenci przechodzą przez te same reguły, weryfikację rejestrową i decyzje opiekunów, które obowiązywały w migracji. Utrzymanie jakości wymaga dalej aktualizacji reguł i bieżącej obsługi wyjątków przez opiekunów danych.

Obecne i planowane zastosowania AI w SNOK MDM

W SNOK MDM asystent AI wspiera dziś tworzenie reguł walidacji, a w domenie kontrahentów także mapowanie nagłówków plików źródłowych. Dopasowanie rekordów pozostaje deterministyczne. Planujemy kolejne zastosowania: wyjaśnianie pochodzenia wartości w rekordzie, grupowanie wyjątków po przebiegach i wskazywanie dodatkowych rekordów do porównania przy niejednoznacznych dopasowaniach.

Propozycja modelu jest w SNOK MDM materiałem do zatwierdzenia: regułę zaproponowaną przez asystenta zatwierdza człowiek, a o tym, czy dwa rekordy opisują tę samą firmę, rozstrzygają reguły deterministyczne albo opiekun danych. Jakość przeniesionej kartoteki ma znaczenie także dla AI: asystenci i agenci pracujący na SAP S/4HANA odpowiadają na podstawie danych przeniesionych w migracji.

Decyzje przed pierwszą próbą konwersji

Właściciel danych po stronie biznesu. Ktoś w organizacji musi mieć prawo decydować o scaleniu dwóch rekordów, blokadzie i wyłączeniu kontrahenta z migracji. Bez takiej osoby decyzje wracają do zespołu projektu, który nie zna historii współpracy.

Pomiar przed wyborem ścieżki. Kompletność pól krytycznych, skala duplikatów i zgodność z rejestrami wpływają na ocenę konwersji systemu, nowego wdrożenia i podejścia selektywnego, więc warto je znać przed podpisaniem umowy z partnerem wdrożeniowym.

Podział odpowiedzialności w umowie. W RISE with SAP warto odwołać się w umowie z partnerem wdrożeniowym do dokumentu Roles and Responsibilities i zapisać, kto wykonuje CVI, porządkowanie danych i analizę błędów po każdym przebiegu.

Reguły zatwierdzone przed pierwszym przebiegiem. Reguły identyfikacji i scalania, mapowanie grup kont na grupowania Business Partner i reguły kompletności dla każdej roli zatwierdza właściciel domeny, zanim zespół uruchomi pierwszą synchronizację.

Weryfikacja w rejestrach. Kontrahentów warto sprawdzić na białej liście VAT oraz w VIES, KRS i REGON przed ładowaniem i ustalić, który system odpowiada za tę weryfikację po uruchomieniu produkcyjnym.

Proces zmian od pierwszego dnia po uruchomieniu produkcyjnym. Brak takiego procesu jest na mapie ryzyk w raporcie jednym z dziesięciu ryzyk: ujawnia się w pierwszych miesiącach eksploatacji i oznacza powrót kartoteki do stanu sprzed migracji.

Pełny raport do pobrania

Opisane tu zagadnienia rozwijamy w raporcie „Business Partner jako warunek przejścia na SAP S/4HANA”. Raport ma 50 stron i 16 rysunków. Opisuje kolejność prac CVI z transakcjami SAP i typowe kategorie błędów synchronizacji, a także materiały, dane finansowe i pracowników jako Business Partner. Zawiera model nadzoru nad danymi z rolami i miarami jakości, model nakładów z przykładem obliczeniowym, mapę dziesięciu ryzyk, pytania kontrolne dla zarządu, plan na 90 dni i listę kontrolną gotowości.

Raport jest bezpłatny i wysyłamy go mailem po wypełnieniu krótkiego formularza: pobierz raport.

Pierwszy krok: pomiar kartoteki

Profilowanie w SNOK MDM nie wymaga wyboru ścieżki przejścia ani partnera wdrożeniowego. Zakres warsztatu diagnostycznego ustalamy przed jego rozpoczęciem: objęte spółki, pola krytyczne, analizę duplikatów i dostępne sprawdzenia w rejestrach. Pilotaż trwa orientacyjnie 4-8 tygodni od udostępnienia uzgodnionych danych, a jego rezultaty definiujemy na starcie. Wyniki pilotażu pozwalają zweryfikować nasz szacunek na Waszych danych.

Platformę opisujemy na stronie SNOK MDM, usługę na stronie Master Data Management, a techniczną stronę przejścia w ofercie konwersji SAP S/4HANA. Granice SAP Readiness Check opisaliśmy we wpisie o analizie gotowości, a bezpieczeństwo konwersji w RISE we wpisie o bezpiecznej konwersji.

Porozmawiajmy o Waszej kartotece: kontakt.

Wpis i raport przygotował Michał Korzeń, CTO SNOK, wraz z zespołem, z wykorzystaniem dużych modeli językowych. Fakty, liczby i wnioski sprawdził i zatwierdził zespół autorski. Zdjęcie na okładce wygenerowano przy użyciu AI.