Koncepcja partnera biznesowego (Business Partner) to jedna z najbardziej znamiennych innowacji w S/4HANA. W SAP ERP mamy odbiorców po stronie modułów FI/SD, a dostawców po stronie FI/MM. Tymczasem ten sam podmiot może funkcjonować w obu rolach biznesowych. Stąd producent systemu postawił w S/4HANA na wyeliminowanie tego dualizmu, kreując uniwersalną rolę Business Partner (BP), pod którym kryją się zarówno klienci, jak i dostawcy.

Model ten nie jest nowy, funkcjonował już wcześniej w systemie SAP ERP, jednakże nie był powszechnie używany. Wprowadzone – na podstawie zebranych przez lata doświadczeń – funkcjonalności i zdecydowanie większa elastyczność w zakresie zarządzania danymi oraz tworzenia uniwersalnych relacji, sprawiły, że SAP zdecydował się wprowadzić Business Partnera jako standard dla S/4HANA.

Zagadnienie Partnera Biznesowego jest nieodłączną i niezwykle istotną częścią różnych scenariuszy wdrożenia S/4HANA. Jej bardzo duże znaczenie jest widoczne w scenariuszach konwersji (ang. conversion), transformacji (ang. transformation) i wdrożenia (ang. implementation).

Zalety Partnera Biznesowego w SAP

Wykorzystanie Partnera Biznesowego otwiera nowe możliwości rozwoju zarządzania danymi podstawowymi, tzw. master data management, w systemie SAP. Wszystkie informacje agregowane są do jednego obszaru, co w znaczny sposób ułatwia zarządzanie i kontrolę danych. Od strony użytkownika również wprowadzono wiele udogodnień – relacyjne podejście modelu pozwala na  tworzenie powiązanego dostawcy, klienta czy osoby kontaktowej, przy użyciu jednej transakcji zamiast wielu. Z perspektywy technicznej działania, agregacja danych pozwala na wielokrotnie szybszy odczyt z bazy danych, co ma przełożenie na wykonywanie wielu standardowych raportów. Dodatkowo, wykorzystanie BP daje szereg dodatkowych możliwości:

  • Podmiot prawny w systemie reprezentowany przez jeden obiekt – Partner Biznesowy,
  • Jeden BP może sprawować wiele ról w systemie w tym m. in. rola dostawcy, klienta, osoby kontaktowej, punktu odbioru towarów czy rola do weryfikacji limitów kredytowych,
  • Dane ogólne BP są dostępne dla wszystkich ról sprawowanych przez jednego BP, a dane kluczowe mogą być tworzone dla każdej roli osobno,
  • Łatwiejsza konsolidacja danych poprzez udostępnianie i ponowne ich wykorzystanie,
  • Możliwość tworzenie w różnych formach m. in. Organizacja, Grupa, Osoba,
  • Elastyczne relacje z partnerami biznesowymi poprzez dodatkowe parametry: „osoba kontaktowa”, „jest w związku małżeńskim” i inne,
  • Możliwość przypisania i zarządzania wieloma adresami,
  • Zależności czasowe w różnych podjednostkach np. adres, dane bankowe i inne,
  • Lepiej usystematyzowana architektura, która może być wykorzystywana przez różne aplikacje.

Rozważając kwestie związane z przejściem na nowy model danych, istotny jest fakt, że sama konwersja do BP nie musi powodować jakiejkolwiek niedostępności systemu produkcyjnego. Kluczowe kroki wykonywane są na systemach ERP (testowych), a specjalne raporty potwierdzają poprawność synchronizacji klientów, dostawców z BP. Dzięki takiej możliwość można zaplanować analizę oraz przygotować dane podstawowe do konwersji bez jakichkolwiek przestojów w realizacji procesów biznesowych. Sama konwersja danych do nowego modelu wymaga pewnego przestoju (ang. down time), ale może on być skrócony do minimum, dzięki możliwości wykonywania raportów konwersji etapowo, np. w nocy, dni wolne lub dni o mniejszym nakładzie pracy.

Naszym proponowanym podejściem do konwersji Partnera Biznesowego, jako do niezależnego projektu, niesie za sobą wiele korzyści z perspektywy kierowania projektami i rozwojem oprogramowania. W łatwy sposób, za pomocą zmiany metodyki, istnieje możliwość redukcji kosztów realizacji projektu oraz umożliwione jest dokładniejsze zarządzanie i planowanie ryzyka, takiego jak: przedłużenie czasu trwania projektu, problemy integracyjne, dostępność zasobów ludzkich oraz technicznych, niezależność od dodatkowych czynników obecnych w dużych projektach i inne. Na koniec, klient decydując się na proponowane rozwiązanie, jest w stanie bardzo precyzyjnie zaplanować czas trwania projektu, koszty oraz ma możliwość realizacji prac w mniejszej grupie, co ułatwia zarządzanie aktywnościami.

Jak można rozpocząć korzystanie z Partnera Biznesowego, aby przygotować się do migracji na S/4HANA?

Z odpowiedzią przychodzą narzędzia konwersji danych do modelu Partnera Biznesowego zwane Customer/Vendor Integration („CVI”). Konwersja umożliwia bezpośrednią zmianę istniejących, tradycyjnych danych podstawowych i tabel w model zgodny z koncepcją Partnera Biznesowego.

Przejście na model danych Partnera Biznesowego jest jednym z najważniejszych i największych wyzwań logistyki (moduły MM i SD) podczas konwersji systemu SAP ERP do SAP S/4HANA. SAP proponuje scenariusz konwersji w 10 krokach (10Steps2S4). Konwersja zgodnie z tą metodyką jest podzielona na etapy, które muszą następować w ściśle określonej kolejności. Są to m.in. przygotowanie logistyki, przygotowanie finansów, konwersja techniczna czy dalsze etapy związane z dostosowaniami po konwersji. Etap przygotowania modułów MM i SD w znacznej mierze polega właśnie na konwersji do Partnera Biznesowego.

Opierając się na metodyce 10Steps2S4, konwersję do BP można przeprowadzić jako niezależny, w pełni samodzielny projekt oparty na przetestowanych i sprawdzonych narzędziach SAP. Realizacja tego etapu w sposób wydzielony posiada wiele zalet. Najbardziej widoczne będą one w następujących scenariuszach:

  • konwersja do S/4HANA,
  • wdrożenie S/4HANA z uwzględnieniem migracji danych z ERP,
  • aktywacja BP w systemie ERP.

Potraktowanie konwersji danych podstawowych klienta i dostawców wraz z aktywacją BP jako oddzielny, mniejszy projekt redukuje potencjalne ryzyka w projekcie, jakimi mogą być m.in. wydłużenie fazy realizacji, trudne oszacowanie kosztów czy wstrzymanie kolejnych faz projektu ze względu na przedłużenie prac w danym module. Co więcej, wykonanie przedstawionej metody realizacji projektu jest możliwe na systemie produkcyjnym.

Planując projekt konwersji do BP, należy jednak zwrócić uwagę na charakterystykę projektu związanego z pracą na danych podstawowych. W odróżnieniu od projektów związanych z implementacją dowolnego oprogramowania planowanie czasochłonności nie odbywa się na podstawie wymagań funkcjonalnych i procesowych, a na podstawie technicznych warunków. W przypadku aktywacji BP, SAP wyróżnia następujące czynniki, które mają największy wpływ na czas realizacji:

  • ilość danych utrzymywanych w bazie,
  • ilość, złożoność i aktualne wykorzystanie zakresów numeracji dla klientów/dostawców,
  • konfiguracja pól dla BP spójnych z konfiguracją dla klienta/dostawcy, uwzględniająca atrybuty danych pól,
  • zgodność i spójność danych podstawowych z założeniami i konfiguracją dotychczas utrzymywaną w systemie,
  • ilość rozszerzeń w danych podstawowych
  • certyfikowani konsultacji z wiedzą pozwalającą na szybką analizę, obsługę narzędzi CVI oraz znajomość koncepcji BP.

Realizacja przejścia na Partnera Biznesowego może być wykonana w przypadku kilku scenariuszy. Wszystkie z nich można traktować jako przygotowanie do większego przedsięwzięcia, jakim jest projekt wdrożenia/konwersji SAP S/4HANA. W ramach pojedynczej koncepcji wyróżnić można szereg czynników, które przemawiają za jej realizacją.

Scenariusz: wykonanie przed konwersją

W przypadku, gdy rozważamy migrację do modelu BP, w kontekście projektu konwersji ERP do S/4HANA, należy zwrócić uwagę na fakt, że jest to projekt całkowicie skupiony na danych podstawowych. Są one kluczowym elementem każdego systemu ERP. Mają one duże znaczenie, jeśli chodzi o wydajność systemu i zapewniają poprawne funkcjonowanie procesów. Fakt ten sprawia, że konwersja danych musi być przeprowadzona zgodnie z określonymi standardami, należytą uwagą i dbałością. W takim projekcie konieczne jest zapewnienie absolutnej zgodności i poprawności danych po konwersji. Wymaga to wielu dostosowań – specyficznych dla danego projektu – oraz testów. Na złożoność i skomplikowanie konwersji BP wpływają takie aspekty, jak: poprawność utrzymywanych danych względem zakładanych standardów oraz ilości danych, które będą przedmiotem projektu. Czynniki te bezpośrednio wpływają na czasochłonność całego procesu, która powinna być indywidualnie planowana dla każdego przedsiębiorstwa. Spowodowane jest to tym, że dane migrowane są do całkowicie nowej struktury obiektów o odmiennych założeniach biznesowych. Fakt ten oznacza zmianę podejścia do zarządzania/utrzymania danych i dostosowania w systemie, które będą się różnić w zależności od wymagań klienta.

Wspomniane elementy wymuszają pracę w środowisku, na którym nie są prowadzone inne prace. Wynika to z ryzyka ingerencji w konfigurację lub dane. Naturalną odpowiedzią na to wymaganie jest wydzielenie fazy konwersji do Partnera Biznesowego z projektu konwersji systemu i zrealizowanie go we wcześniejszym, niezależnym etapie.

Wydzielenie fazy migracji do BP jest również związane z wysokim prawdopodobieństwem występowania drobnych korekt konfiguracji i danych. Takie korekty spowodowane są charakterystyką danych podstawowych utrzymywanych w wybranym systemie – mowa o niestandardowych dostosowaniach, rozszerzeniach czy zaprojektowanych mechanizmach powiązania i zależności. Tego typu działania mogą potencjalnie wpływać na wydłużenie harmonogramu tej fazy. Dodatkową zaletą realizacji migracji do BP przed projektem konwersji systemu jest możliwość implementacji nowych funkcjonalności wymaganych przez użytkowników. Na koniec, użytkownicy będą mieć szansę na poznanie funkcjonalności Partnera Biznesowego przed faktycznym przejściem na system S/4HANA. Umożliwi to poznawanie nowych funkcji systemu etapowo i w mniejszym stopniu wpłynie na codziennie wykonywane zadania – zmniejszone ryzyko efektu „zagubienia” w nowym otoczeniu i zwiększona wydajność pracy.

Scenariusz: migracja danych z ERP do S/4HANA, np. rollout korporacyjny ze zmianą środowiska systemowego

Kolejną możliwością wykorzystania konwersji do Partnera Biznesowego są coraz częściej spotykane projekty grupowe (korporacyjne), które realizują przejście z systemu SAP ERP wdrożonego dla wielu jednostek gospodarczych na pojedynczy system S/4HANA. Projekty tego typu są często określane mianem Landscape Transformation, natomiast wdrożenie danej jednostki w główny, istniejący już system mianem rolloutu. Głównym założeniem Landscape Transformation jest zdefiniowanie na nowo, modernizacja lub przeniesienie istniejących kluczowych procesów w grupie na nową, centralną jednostkę systemu np. wdrożenie SAP S/4HANA w wybranym kraju.  W kolejnych etapach wykonywane są projekty typu rollout w pozostałych przedsiębiorstwach czy jednostkach na zasadzie dołączenia do istniejącego centralnego środowiska.

Podczas realizacji projektu rollout największymi przedsięwzięciami są lokalne dostosowania i migracja danych. Wykorzystując w tym przypadku sam projekt konwersji do Partnera Biznesowego, można znacznie zredukować czas oraz koszty implementacji z perspektywy zarówno całej grupy, jak i pojedynczej jednostki. W tradycyjnym podejściu migracja danych jest wykonywana w trakcie trwającego projektu wdrożenia, co nieodłącznie powiązane jest z jego wydłużeniem i oznacza większe koszty. W efekcie, w danym okresie zrealizowana może być mniejsza ilość projektów – najczęściej rollouty realizuje jeden stały zespół projektowy ze względu na najlepszą znajomość implementowanego rozwiązania.

Możliwe jest jednak uruchomienie innego, niezależnego zespołu lokalnego, który zajmie się przygotowaniem projektu dla konwersji danych podstawowych. Ma to znaczenie nie tylko, jeśli chodzi o czas przeprowadzanych prac, ale również o nakłady finansowe. Przyjmując założenie o wcześniejszej konwersji klienta i dostawcy, sam projekt rolloutu ulega znacznemu skróceniu. Dzięki temu prace mogą przebiegać szybciej w zespole lokalnym (lepsza znajomość danych, większa efektywność i skupienie na jednym zadaniu) oraz w zespole globalnym (jedna z faz już zrealizowana, skrócenie czasu koniecznego na wdrożenie danej jednostki gospodarczej). Dodatkowo, identycznie jak w przypadku konwersji systemu do S/4HANA, użytkownicy mogą wcześniej rozpocząć naukę nowych funkcji systemu. Po samym starcie nowego systemu mogą z kolei skupić się całkowicie na innowacjach i możliwościach, które zapewnia S/4HANA.

Scenariusz: nowa funkcja – korzystanie z BP w istniejącym ERP

Konwersja do Partnera Biznesowego jest nie tylko związana z przejściem na system S/4HANA, może być on również wykorzystany w SAP ERP. BP nie tylko pozwala na wykorzystanie nowych funkcji, ale również zdecydowanie zwiększa elastyczność. W takim przypadku proces konwersji przebiega identycznie, jak we wcześniejszych przypadkach i jest oparty na odpowiedniej integracji danych klient/dostawca oraz przypisaniu właściwych ról, co pozwala na odpowiednie mapowanie danych w tabelach. Ponownie, tego rodzaju konwersja może być realizowana na produkcyjnym systemie, bez wywierania wpływu na procesy biznesowe. Klienci najczęściej wskazują na następujące ograniczenia modelu danych ECC, które przemawiają za wykorzystaniem koncepcji Partnera Biznesowego:

  • tylko jeden adres dla danego rekordu danych,
  • brak relacji, powiązania między klientem i dostawcą w przypadku, gdy jest to ten sam byt (brak ról) co w połączeniu z ograniczeniem dla adresów powodowało sztuczne zwielokrotnienie rekordów danych,
  • brak obiektów „osoby” dla klienta i dostawcy w scenariuszu współpracy B2C,
  • brak zależności czasowej dla wybranych danych,
  • ograniczona możliwość zarządzania specyficznymi rekordami np. key account manager, osoba kontaktowa, logistyk i inne,
  • ograniczony model relacji między dowolnymi rekordami danych.

Jednym z istotnych elementów jest również funkcja tworzenia złożonych struktur zależności między Partnerami Biznesowymi, co w praktyce oznacza możliwość zaprojektowania złożonych relacji i niespotykaną dotąd elastyczność w zakresie powiązania danych.

Techniczna realizacja procesu konwersji do Partnera Biznesowego

Partner Biznesowy

W tradycyjnych systemach ERP istnieją dwa niezależne obiekty danych, które są wykorzystywane w głównej mierze przez moduły logistyczne (m. in. Gospodarka Materiałowa, Sprzedaż i Dystrybucja). Należą do nich klienci i dostawcy, którzy w systemie ERP (opcjonalnie) lub S/4HANA (obowiązkowo) są zastąpieni osobnym obiektem nazywanym Partnerem Biznesowym. Jest to centralna struktura danych, która jednocześnie może zarządzać danymi Partnera Biznesowego, klienta oraz dostawcy. Dzięki scentralizowanemu podejściu, BP jest tym bytem, gdzie można tworzyć, zmieniać oraz wyświetlać dane, które wcześniej były rozproszone w osobnych obiektach i transakcjach.

By móc w pełni wykorzystać BP konieczna jest migracja klientów oraz dostawców do jednej jednostki. W tym celu wykorzystywane są predefiniowane narzędzia integracyjne CVI, które zapewniają sprawną synchronizację pomiędzy BP, a klientami i dostawcami wykorzystywanymi w systemach ERP. Proces ten jest wspierany przez specjalny kokpit synchronizacji (ang. Synchronization Cockpit) danych podstawowych, w którym raportowany jest status przypisania klientów oraz dostawców do nowoutworzonego Partnera Biznesowego i odwrotnie. Model danych dla BP oraz relacje pomiędzy danymi klienta oraz dostawcy przedstawiony został na poniższym schemacie.

Warto zauważyć, że dane klienta i dostawcy są nadal utrzymywane w znanych z systemu ERP obszarach: Dane Ogólne, Dane Jednostki Gospodarczej, Dane działu Sprzedaży. Są to tzw. dane specyficzne, które są przetrzymywane w znanych do tej pory tabelach np. LFxx, KNxx itp. Są one powiązane z danymi centralnymi BP, a dostęp do nich z poziomu BP zapewniają odpowiednie tabele mapujące oraz wglądy. Pozostałe dane BP są przechowywane w nowych tabelach bazy danych. Z punktu widzenia użytkownika końcowego nie są to istotne zmiany ponieważ dostęp do wcześniejszych danych jest zachowany przy jednoczesnym rozszerzeniu informacji i stworzeniu nowych możliwości technicznych. W efekcie powyższych innowacji otrzymujemy scentralizowaną strukturę danych, która w momencie odczytu dużych zbiorów informacji (złożone raporty) zapewnia szybki ich odczyt z jednego źródła. Dzięki temu możemy przedstawić dowolne dane związane z Partnerem Biznesowym zagregowane w czasie rzeczywistym.

Schemat realizacji

Proces konwersji klientów oraz dostawców do BP jako osobny projekt, przedstawiono na poniższym schemacie.

Schemat przedstawia scenariusz, w którym następuje konwersja klientów i dostawców do BP na systemie ERP. Całe proces jest wykonywany w kontekście późniejszego przejście na system S/4HANA. Scenariusz można podzielić na trzy etapy: Przygotowanie, Synchronizacja oraz Testy. Docelowym efektem wykonania wszystkich kroków jest konwersja klientów oraz dostawców do nowego obiektu Partnera Biznesowego. Etapy te mogą być przeprowadzone na aktualnym systemie klienta i mogą być wykonane niezależnie od projektu związanego z przejściem na system S/4HANA. Poniżej zostały przedstawione szczegóły dotyczące każdego z etapów.

1. Przygotowanie

Jest to etap, w którym przygotowywane są niezbędne narzędzia i funkcjonalności. Wszystkie niestandardowe rozszerzenia związane z klientami i dostawcami muszą rozstać sprawdzone i zintegrowane. Implementacja oraz znajomość odpowiednich not SAP pozwala na mapowanie niestandardowych pól znajdujących się w danych podstawowych klientów oraz dostawców do odpowiednich pól w BP.

Niezbędna jest również aktywacja Funkcji Biznesowej (ang. Business Function) CA_BP_SOA, CA_SUPPLIER_SOA. Zawarte w niej parametry VENDOR_SFWS_SC1 i VENDOR_SFWS_SC2 umożliwiają synchronizację danych kontaktowych dostawców z danymi kontaktowymi zawartymi w BP.

W tym kroku należy skonfigurować narzędzie CVI, czyli tzw. MDS_LOAD_COCKPIT. Ważne jest również wprowadzenie odpowiednich zmian w ustawieniach i ich aktywacja na danym systemie.

Jednym z najważniejszych elementów są ustalenia związane z definiowaniem i przypisywaniem numeracji dla BP, klientów oraz dostawców. Jest to bardzo ważny krok, który ma przełożenie na późniejszą konwersję do BP, a w efekcie również systemu ERP do S/4HANA. W zależności od ustawień zakresów numeracji klientów i dostawców, może zachodzić pewne nadpisywanie i dublowanie ich numerów. Proponowanych jest kilka głównych zasad, które należy wziąć pod uwagę przy ich determinowaniu:

  • Jeśli zakresy numeracji klientów oraz dostawców są rozłączne, zakres numeracji Partnerów Biznesowych powinien być identyczny,
  • Jeśli zakresy numeracji klientów i dostawców nie są rozłączne, wówczas zakres dla Partnerów Biznesowych jest dobierany w taki sposób aby większość numerów klientów lub dostawców pozostała bez zmian,
  • Numeracja klientów/dostawców powinna być przejmowana przez BP:
    • By umożliwić przejmowanie numerów przez BP przedziały zakresów numeracji Partnerów Biznesowych muszą być ustawione na wartość zewnętrzną
    • Po pomyślnej synchronizacji danych, przedziały BP muszą być z powrotem ustawione jako wewnętrzne
    • By możliwe było nadawanie identycznych numerów dla klientów/dostawców i Partnera Biznesowego, zakres numeracji dla pierwszych, musi być ustawiony jako zewnętrzny.

Zakresy numeracji dla klientów i dostawców przypisywane są wg grup kont (ang. customer/vendor account group). Dla Partnerów Biznesowych tworzone są tzw. grupowania BP (ang. BP Grouping) dla każdej grupy kont klientów/dostawców i dopiero do nich przypisywane są odpowiednie zakresy numeracji. Następnie przygotowywane są mapowania pomiędzy poszczególnymi grupami kont, a obiektami BP grouping. W kolejnym kroku konfigurowane są tzw. role Partnerów Biznesowych, które określają m.in. zakres pól oraz ich odpowiednie atrybuty. Ostatnim etapem jest przypisanie roli BP do konkretnej grupy kont klienta lub dostawcy. Takie połączenie determinuje numer przypisany później do tworzonego Partnera Biznesowego. Połączenia pomiędzy tymi obiektami muszą być również skonfigurowane w narzędziu CVI. Poszczególne numery dla klientów/dostawców można znaleźć kolejno w tabelach KNA1 i LFA1. Dla Partnera Biznesowego jest to tabela BUT000.

Specjalne raporty umożliwiają analizę aktualnego statusu przygotowywanej konfiguracji, w tym m. in. zakresów przypisanych numeracji. Pokazują również statusy konwersji wskazując konkretnych klientów oraz dostawców, których nie udało się skonwertować do BP. Należą do nich m. in. następujące raporty: PRECHECK_UPGRADATION_REPORT, CVI_UPGRADE_CHECK_RESOLVE, CVI_FS_CHECK_CUSTOMIZING. Ich aktywacja jest związana z implementacją odpowiednich not w systemie. Raporty pozwalają również na sprawdzenie poprawności mapowania pól między klientami, dostawcami a Partnerami Biznesowymi.

Ważnym elementem są moduły BADI, których aktywacja bądź dezaktywacja umożliwia sprawną konwersję. Dla przykładu moduł CVI_MAP_BP_CATEGORY pozwala na utworzenie BP w zupełnie innej kategorii niż dostawca np. tworzymy BP  jako organizację z dostawcy, który w systemie był konkretną osobą.

Na zakończenie etapu Przygotowania powinni zostać usunięci klienci i dostawcy, którzy zostali oznaczeni flagą „do usunięcia”. Jest to krok opcjonalny, natomiast te obiekty które nie zostaną zarchiwizowane muszą być poddane konwersji do BP.

2. Synchronizacja

Proces synchronizacji polega na powielaniu tych podstawowych obiektów danych, które są identyczne od strony biznesowej ale różnią się kwestiami technicznymi. Takie obiekty pozwalają na integrację różnych aplikacji w systemie SAP podczas realizacji procesów biznesowych. Wyróżnić można dwa główne podejścia do synchronizacji danych podstawowych:

  • Synchronizacja podczas utrzymania danych podstawowych – polega na tym, że podczas tworzenia lub zmiany danych podstawowych, system sam odpowiada za aktualizację tych obiektów danych, które są połączone z tworzonymi lub zmienianymi danymi. Relacje pomiędzy zależnymi strukturami realizowane są przez konfigurację systemu.
  • Synchronizacja z wykorzystaniem narzędzi – polega na wykorzystaniu specjalnego kokpitu, który odpowiada za tworzenie, przygotowanie lub zmiany w obiektach danych. W kokpicie sprawdzany jest również aktualny status synchronizacji.

Podczas synchronizacji danych pomiędzy klientami/dostawcami oraz BP wykorzystywany jest specjalny kokpit synchronizacji. Jest on najważniejszym narzędziem w tym etapie, dzięki któremu można przedstawić wszystkie zależności danych (adresy, dane banków, dane ogólne itp.) pomiędzy odpowiednimi strukturami danych. Weryfikuje również błędy wynikające z konfiguracji. Do danych podlegających weryfikacji należą:

Dane centralne:

  • weryfikacja ról i grupowań dla BP,
  • sprawdzenie poprawności i mapowań dla zakresów numeracji,
  • poprawność id danych podstawowych dla niedozwolonych znaków.

Dane adresowe:

  • poprawność danych adresowych, np. czy adres e-mail zawiera @,
  • dane bankowe np. klucz banku.

Dane organizacyjne:

  • przemysł – tabela TB038,
  • forma prawna – tabela TB019,
  • forma jednostki – tabela TB032.

Dane identyfikacji podatkowej:

  • kategorie numerów podatkowych – tabela TFKTAXNUMTYPE.

Kokpit synchronizacyjny uruchamiany jest przy użyciu odpowiedniej transakcji SAP – MDS_LOAD_COCKPIT.

Kokpit synchronizacji

Ekran główny kokpitu jest podzielony na kilka obszarów. Trzy najważniejsze z nich to:

  • Obszar synchronizacji procesu – wybieramy rodzaje dostępnych procesów synchronizacji np. Dostawca -> Partner Biznesowy
  • Parametry sterowania
  • Kryteria wyboru dla obiektu źródłowego – zawężają wybór obiektów źródłowych, dla których sprawdzany i uruchamiany jest proces synchronizacji

Po wykonaniu synchronizacji, rezultaty sprawdzane są w zakładce „Monitor”.

Kokpit synchronizacji – Monitor

Raport umożliwia dokładną analizę błędów powstałych podczas etapu przygotowania oraz synchronizacji. Wykorzystując odpowiednie opcje znajdujące się w raporcie możliwe jest wskazania konkretnego obiektu danych, dla którego pojawił się problem. Dzięki statusowi komunikatu (kontrolka czerwona, zielona), opisowi czy lokalizacji możliwe jest szybkie usunięcie problemu w odpowiednich transakcjach systemu SAP lub bezpośrednio w kokpicie. Jest to tak zwane przetwarzanie końcowe (ang. post-processing order – PPO).

Wyświetlenie wiadomości przetwarzania końcowego

W końcowej facie etapu synchronizacji należy sprawdzić poprawność i kompletność konwertowanych danych. Umożliwiają to dwa raporty: PRECHECK_UPGRADATION_REPORT oraz CVI_PRECHECK_UPGRADE. Raporty mają kilka opcji, których wybór skutkuje pojawieniem się odpowiednich danych. Sprawdzane są m. in. przypisania BP do odpowiednich grup, dane klientów i dostawców czy relacje pomiędzy tabelami bazy danych (opcja CVI_link), której użycie wymaga instalacji dodatkowej noty w systemie SAP.

Raport PRECHECK_UPGRADATION_REPORT

Wyniki raportu PRECHECK_UPGRADATION_REPORT

Czynności związane z uzupełnianiem danych czy też ich poprawieniem kończą się wówczas, gdy wszyscy klienci, dostawcy czy osoby kontaktowe są skonwertowane do BP. Jeśli błędy nadal występują, można je poprawić w konfiguracji systemu lub bezpośrednio w kokpicie synchronizacji. Wymaga to jednak odpowiedniej wiedzy i znajomości systemu oraz umiejętności posługiwania się narzędziami konwersji.

3. Testy końcowe

Ten etap jest końcowym etapem związanym z konwersją. W prezentowanym podejściu w całości przeprowadzany jest również na systemie ERP. Od tego momentu, na systemie mogą być tworzeni Partnerzy Biznesowi przy użyciu transakcji BP. Warto korzystać z tej transakcji, ponieważ po ewentualnej późniejszej migracji systemów, transakcje związane z tworzeniem, zmianą i wyświetlaniem klientów i dostawców nie są dostępne na S/4HANA. Równocześnie użytkownicy uczą się nowych transakcji SAP oraz poznają ich funkcjonalność i możliwości. Aby równocześnie utrzymywać dane klienta i dostawcy standardowych tabelach, konieczna jest aktywacja kierunku BP-> Klient/Dostawca. Dzięki tej opcji podczas tworzenia BP automatycznie aktualizowane są również dane w tabelach LFxx czy KNxx. Ważnym elementem jest sprawdzenie poprawności konfiguracji związanej z danymi podstawowymi oraz spójności pól BP oraz klientów/dostawców. Testy wiążą się w głównej mierze ze sprawdzeniem danych podstawowych oraz utworzeniem nowych Partnerów Biznesowych. Poprawność zapisu danych jest potwierdzeniem, ze konwersja i synchronizacja przebiegły pomyślnie. Sprawdzeniu i kontroli podlegają również przypisane zakresy numeracji, z których przydzielane są konkretne numery tworzonym BP. Status całej konwersji można sprawdzić również w odpowiednich raportach.