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

> CVI i Business Partner przed konwersją, podział zadań w RISE with SAP i nakład przy danych kontrahentów. Szacunek SNOK: 28,5-46,5 % mniej pracy z SNOK MDM.

- Source: https://snok.ai/pl/aktualnosci/blog/business-partner-sap-s4hana-dane-kontrahentow-rise/
- Author: Michał Korzeń
- Published: 2026-10-12

---
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.

![Terminy SAP: koniec mainstream maintenance w 2027 roku, koniec konwersji z baz innych niż SAP HANA w 2030 roku, transition option 2031-2033 i utrzymanie SAP S/4HANA do 2040 roku](https://snok.ai/images/blog/business-partner-snok-mdm-terminy-pl.webp)

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.

![Przebieg konwersji systemu: CVI, SI-Check na starcie, próby, SI-Check przed przestojem i przełączenie](https://snok.ai/images/blog/business-partner-snok-mdm-si-check-pl.webp)

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.

![Podział odpowiedzialności za dane w RISE with SAP według dokumentu SAP z lipca 2026 roku](https://snok.ai/images/blog/business-partner-snok-mdm-rise-pl.webp)

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.

![Szacowana zmiana nakładu przygotowania danych kontrahentów na siedmiu etapach przy użyciu SNOK MDM - szacunek SNOK](https://snok.ai/images/blog/business-partner-snok-mdm-naklad-pl.webp)

| 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.

![SNOK MDM w trzech fazach programu SAP S/4HANA: przed migracją, przełączenie i po uruchomieniu produkcyjnym](https://snok.ai/images/blog/business-partner-snok-mdm-fazy-pl.webp)

**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 SNOK: 2030 jako ostatni rok konwersji z baz innych niż SAP HANA, 54 % respondentów DSAG na SAP ERP 6.0 lub starszej Business Suite, 4-5 przebiegów konwersji Business Partner i szacunek SNOK 28,5-46,5 %](https://snok.ai/images/blog/business-partner-snok-mdm-liczby-pl.webp)

Raport jest bezpłatny i wysyłamy go mailem po wypełnieniu krótkiego formularza: [pobierz raport](https://snok.ai/pl/materialy/raport-business-partner-s4hana/).

## 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](https://snok.ai/pl/produkty/snok-mdm/), usługę na stronie [Master Data Management](https://snok.ai/pl/oferta/master-data-management/), a techniczną stronę przejścia w ofercie [konwersji SAP S/4HANA](https://snok.ai/pl/oferta/bezpieczenstwo-sap/konwersja-s4hana/). Granice SAP Readiness Check opisaliśmy we wpisie [o analizie gotowości](https://snok.ai/pl/aktualnosci/blog/analiza-gotowosci-s4hana-readiness-check/), a bezpieczeństwo konwersji w RISE we wpisie [o bezpiecznej konwersji](https://snok.ai/pl/aktualnosci/blog/bezpieczna-konwersja-sap-s4hana-rise/).

Porozmawiajmy o Waszej kartotece: [kontakt](https://snok.ai/pl/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.*