Start · Rozwiązania · IT i usługi
Rozwiązanie · IT i usługiKażdy zmigrowany rekord porównany ze źródłem, zanim ktokolwiek podpisze cutover
Walidacja migracji danych testami, nie próbką
Automatyczne przypadki testowe uzgadniają źródło i cel pole po polu dla każdego zmigrowanego rekordu, przechodzą procesy biznesowe na zmigrowanych danych i dostarczają dowody do decyzji o starcie produkcyjnym.
Streszczenie dla zarządu
Próbka kilkuset rekordów w arkuszu to dziś wszystko, co dzieli migrację od startu produkcyjnego.
Zapewnienie jakości migracji budujemy jako zestaw aktywów testowych, a nie ćwiczenie w arkuszu.
Pokrycie przestaje być kwestią opinii: każdy rekord w zakresie jest porównany na każdym zmapowanym polu.
SAP S/4HANA przez SAP BAPI i OData; backlog w Azure DevOps; rejestr dowodów w Test Manager
Problem biznesowy
Zapewnienie jakości migracji
Migracja przenosi pamięć operacyjną firmy do nowego systemu: kartoteki klientów i dostawców, rachunki bankowe, dane materiałowe, warunki cenowe, otwarte należności i zobowiązania, salda księgowe, otwarte zamówienia. Każdy obiekt ma gdzieś w biznesie właściciela, którego prosi się o potwierdzenie, że dane wyglądają poprawnie. Narzędziem, jakie dostaje, jest wyciąg i arkusz kalkulacyjny.
Próbka to nie pokrycie. Trzysta kartotek klientów z czterystu tysięcy nie mówi prawie nic o reszcie, a próbki są obciążone: ludzie sprawdzają konta, które znają. Klienci nieaktywni, rzadkie konfiguracje i długi ogon historycznych pozycji otwartych to miejsca, w których reguły migracji się łamią. Pięć spółek, kilka fal i trzy migracje próbne zwielokrotniają to samo ręczne porównanie, więc przy trzecim przebiegu biznes sprawdza mniej, dokładnie wtedy, gdy dane są najbliższe produkcji. Raport techniczny pozostaje zielony, bo zgodność liczby rekordów to nie zgodność wartości.
Konsekwencje spadają na ludzi, których nigdy nie było na spotkaniach migracyjnych. Windykacja ściga klientów za pozycje zamknięte lata temu. Zablokowana dostawa okazuje się limitem kredytowym, który zmigrował jako zero. Sprzedaż znajduje tabelę warunków cenowych bez dat obowiązywania. Skarbiec znajduje przelew wskazujący dawne konto faktoringowe dostawcy. Każdy z tych przypadków wychodzi na jaw tygodnie po ogłoszeniu sukcesu cutoveru.
Jak to wygląda dzisiaj
W większości programów konwersji faktycznym planem testów jest stos arkuszy porównawczych w Excelu, niezależnie od narzędzi migracyjnych.
- SystemMigracja próbna idzie przez weekend; kokpit raportuje liczby rekordów i błędy ładowania na obiekt
- CzłowiekAnalitycy pobierają wyciągi z obu systemów i budują arkusze porównawcze w Excelu dla każdego obiektu
- CzłowiekKażdy zespół biznesowy otwiera próbkę kilkuset rekordów i sprawdza pola, które zna najlepiej
- OczekiwanieUstalenia leżą we wspólnym rejestrze do kolejnego statusu programu, zwykle tydzień
- Ryzyko błęduObiekty bez wyraźnego właściciela, jak warunki cenowe czy funkcje partnera, sprawdzane są na końcu albo wcale
- CzłowiekOdbiór to podpis na liście kontrolnej; wielkość próbki za tym podpisem nie jest nigdzie zapisana
- Ryzyko błęduPierwszym pełnym testem danych jest biznes, w pierwszym dniu roboczym po starcie produkcyjnym
Dlaczego obecny proces kosztuje więcej, niż widać
To nie jest praca, którą ktoś zaplanował.
- Powtarzalność to ukryta pozycja kosztowa. To samo porównanie powstaje od nowa przy każdej migracji próbnej i każdej fali, i nic z tego nie zostaje, bo żyje w arkuszu.
- Odbiór bez zapisanej wielkości próbki nie jest dowodem. Zapytani później, jak zweryfikowano salda otwarcia, uczciwie odpowiemy, że kilka osób obejrzało kilka rekordów.
- Błędy kosztują wielokrotnie więcej po starcie produkcyjnym. W migracji próbnej błąd to wpis w rejestrze; na produkcji to wstrzymana dostawa, błędne wezwanie do zapłaty i korekta, którą księgowość tłumaczy przy zamknięciu.
- Strach przed danymi spowalnia program. Gdy nikt nie potrafi zmierzyć ryzyka, odruchem jest kolejna migracja próbna albo dłuższe zamrożenie, oba kosztowne.
Koszt zaniechania
To drugi wiersz jest ruchomy. Ręczna kontrola jest ograniczona liczbą dostępnych dni, więc ma sufit kosztu; błędy, które ją omijają, nie mają żadnego. Jeden błędny rachunek bankowy w kartotece dostawcy albo pozycje otwarte bez terminów płatności potrafią pochłonąć więcej uwagi zarządu niż cały budżet kontroli. Trzeci koszt nie pojawia się w żadnym wierszu: program, który nie potrafi zmierzyć ryzyka danych, zarządza nim przez opóźnienie, a kolejna migracja próbna czy dłuższe zamrożenie są kosztowne właśnie dlatego, że brakuje wiedzy.
Przykładowa organizacja o realnych proporcjach — liczby służą do policzenia sprawy na Waszych danych, nie są wynikiem klienta.
Europejska grupa przemysłowa, pięć spółek operacyjnych w czterech krajach, około 4 000 pracowników, konwersja z SAP ECC na SAP S/4HANA w dwóch falach; Microsoft 365 E3, Azure DevOps jako backlog programu.
Około 2,4 miliona rekordów w około osiemnastu obiektach migracyjnych: kartoteki klientów i dostawców z rachunkami bankowymi, indeks materiałowy, warunki cenowe, otwarte pozycje należności i zobowiązań, salda księgowe, otwarte zamówienia. Trzy migracje próbne przed cutoverem.
Po każdym ładowaniu zespół danych publikuje wyciągi, sześć osób z biznesu porównuje próbki w Excelu przez około osiem dni roboczych, ustalenia trafiają do rejestru, każdy właściciel podpisuje listę kontrolną.
Próbka obejmuje ułamek procenta na obiekt i przechyla się w stronę znanych rekordów; nie da się jej powtórzyć wystarczająco szybko przy trzech ładowaniach, więc pokrycie spada, gdy dane znaczą najwięcej.
Test Manager utrzymuje przypadek testowy uzgodnienia dla każdego obiektu; roboty czytają oba systemy przez interfejsy SAP, porównują każdy rekord pole po polu, a następnie przechodzą procesy od zamówienia do faktury i od zakupu do płatności na zmigrowanych danych. Odchylenia stają się błędami w Azure DevOps i zadaniami w Microsoft Teams; historia wykonań jest dowodem do odbioru.
W modelowanym przypadku pokrycie przechodzi z próbki rzędu kilkuset rekordów na obiekt do wszystkich rekordów w zakresie, każda migracja próbna jest sprawdzana w godzinach zamiast dni, a błędy znajdowane dotąd po starcie produkcyjnym wychodzą przy pierwszym ładowaniu. To model, nie pomiar.
Proponowane rozwiązanie
Zapewnienie jakości migracji budujemy jako zestaw aktywów testowych, a nie ćwiczenie w arkuszu. Każdy obiekt migracyjny dostaje wymaganie i przypadek testowy uzgodnienia w UiPath Test Manager, komponencie UiPath Test Cloud, który przechowuje przypadki testowe, zestawy testów, historię wykonań i dowody. Przypadek testowy robi w pełnej skali to, co analitycy robili ręcznie: czyta rekordy źródłowe, czyta to, co wylądowało w SAP S/4HANA, stosuje reguły mapowania i raportuje każdy rekord, w którym obie strony się różnią. Roboty czytają przez interfejsy SAP, a nie przez ekrany, więc porównanie obejmuje miliony rekordów w oknie ładowania.
Uzgodnienie pól to za mało. Klient z poprawnym adresem może wciąż mieć segment kredytowy blokujący każde zamówienie, dlatego ten sam zestaw testów zawiera przypadki procesowe na zmigrowanych danych: zamówienie sprzedaży dla zmigrowanego klienta, dostawa, faktura, wpłata, wezwanie do zapłaty dla zmigrowanej pozycji otwartej. To są procesy, które biznes uruchomi w poniedziałek, wykonane na piątkowych danych.
Reszta czyni wynik obronnym. Odchylenia są klasyfikowane regułami, grupowane wg obiektu i wagi, i wysyłane do backlogu migracji w Azure DevOps. Właściciel obiektu dostaje zadanie w Microsoft Teams z identyfikatorami rekordów i decyduje: poprawić, zaakceptować z uzasadnieniem albo odrzucić ładowanie. Test Manager utrzymuje pokrycie, liczby przejść i niepowodzeń oraz dowody z każdego przebiegu, czyli to, czego bramka startu produkcyjnego potrzebuje zamiast podpisu. To inna dyscyplina niż nocna regresja wydań na działającym SAP, choć aktywa migracyjne stają się zalążkiem właśnie takiego zestawu po starcie produkcyjnym.
UiPath Test Cloud z Test Manager (przypadki testowe, zestawy testów, dowody wykonania, synchronizacja z Azure DevOps); harmonogramy, kolejki i ślad audytowy UiPath Orchestrator; UiPath SAP automation (konektory SAP BAPI i OData, aktywności SAP GUI); powiadomienia zadaniowe UiPath Action Center w Microsoft Teams; pulpit Test Manager w UiPath Insights
Przypadek testowy uzgodnienia dla każdego obiektu, reguły mapowania i tolerancji przełożone na asercje, klasyfikację odchyleń, przypadki procesowe, kierowanie błędów i model wagi, wyciąg odchyleń oraz raportowanie gotowości
Odczyty z SAP ECC i SAP S/4HANA przez aktywności UiPath SAP; przygotowanie zbiorów porównawczych w Azure SQL tam, gdzie wolumen przerasta arkusz
Jak działa proces po automatyzacji
- AutomatyzacjaKażde ładowanie próbne uruchamia w Test Manager zestaw testów uzgodnienia dla każdego obiektu w zakresie
- SystemRoboty czytają rekordy źródłowe i cel w S/4HANA przez interfejsy SAP i przygotowują obie strony
- AutomatyzacjaKażdy rekord jest porównywany pole po polu; odchylenia klasyfikowane są jako brakujące, zmienione, ucięte, źle przypisane lub poza tolerancją
- AutomatyzacjaPrzypadki procesowe idą na zmigrowanych danych: od zamówienia do faktury, wezwanie do zapłaty dla zmigrowanej pozycji otwartej, przyjęcie towaru do zmigrowanego zamówienia zakupu
- SystemWyniki, identyfikatory rekordów i dowody trafiają do Test Manager; błędy synchronizują się do backlogu w Azure DevOps
- CzłowiekWłaściciele danych rozpatrują swoje odchylenia jako zadania Action Center w Microsoft Teams i decydują: poprawa, akceptacja lub odrzucenie
- AutomatyzacjaWidok gotowości pokazuje pokrycie na obiekt, otwarte błędy wg wagi i trend w kolejnych migracjach próbnych
Model współpracy człowieka z automatyzacją
Automatyzacja obsługuje
- Porównanie na poziomie pól każdego rekordu w zakresie po każdym ładowaniu
- Klasyfikację odchyleń wg typu, obiektu i wagi, z identyfikatorami rekordów
- Wykonanie procesów biznesowych na zmigrowanych danych i zebranie dowodów
- Zakładanie błędów w Azure DevOps, raportowanie gotowości i powtórkę po każdej poprawce
Ludzie decydują
- Co znaczy „poprawnie” dla obiektu: pola w zakresie, zamierzone przekształcenia, dopuszczalne różnice
- Czy odchylenie to błąd, zaakceptowana różnica, czy pomyłka w mapowaniu
- Model wagi i to, co może pozostać otwarte na bramce cutoveru
- Decyzję o starcie produkcyjnym, podjętą na dowodach, a nie na próbce
Przed i po
Systemy i integracje
Każdą pozycję da się sprawdzić w dokumentacji producenta. Klasa dowodu jest podana przy każdej.
Wejścia
- rekordy SAP ECC dla obiektu
- specyfikacja mapowania pól
- wyniki ładowań z kokpitu migracyjnego
- plan cutoveru
Warstwa automatyzacji
- UiPath Test Cloud z Test Manager
- UiPath Orchestrator
- UiPath Robots
- UiPath Action Center
- przygotowanie danych w Azure SQL
Systemy docelowe
- SAP S/4HANA przez SAP BAPI i OData
- backlog w Azure DevOps
- rejestr dowodów w Test Manager
Punkty styku z człowiekiem: zadania Action Center w Microsoft Teams; kanał Teams dla fali; wyciąg odchyleń w Excelu
Wykorzystane technologie
przypadki testowe, zestawy testów, historia wykonań i dowody odbioru dla każdego obiektu
Auruchamiają zestawy testów na obu systemach wg harmonogramu, z ponowieniami i audytem
Aczyta rekordy źródłowe i docelowe; prowadzi procesy na zmigrowanych danych
Aprzygotowuje zbiory porównawcze; przechowuje poświadczenia techniczne
Awłaściciele danych rozpatrują i akceptują odchylenia tam, gdzie rozmawia program
Abacklog migracji: błędy powiązane z wynikami testów, synchronizowane z Test Manager
Awyciąg odchyleń dla obiektu, przez który przechodzi właściciel
Apokrycie, zdawalność i trend błędów w kolejnych migracjach próbnych
AIlustracyjny model ekonomiczny
Arytmetyka jest jawna, żeby dało się z nią spierać.
Te zakresy pochodzą z programów konwersji; żaden z nich nie jest pomiarem u klienta. Zapewnienie jakości migracji nie jest procesem transakcyjnym, więc pokazujemy pulę wartości, a nie kalkulator. Nakład kontroli liczy wyłącznie dni, które osoby z biznesu spędzają na porównywaniu wyciągów. Stawka 45 € to w pełni obciążony koszt godzinowy kluczowych użytkowników i analityków IT w Europie Środkowej; 14 000 € na błąd produkcyjny to modelowa średnia obejmująca poprawę, zakłócenie działania i pracę finansów nad uzgodnieniem sald.
Korzyści biznesowe
- Pokrycie przestaje być kwestią opinii: każdy rekord w zakresie jest porównany na każdym zmapowanym polu
- Błędy wychodzą przy pierwszej migracji próbnej, a nie przed klientem, gdy poprawka to zmiana mapowania, a nie korekta księgowa
- Każdy przebieg jest sprawdzany w godzinach, więc program może pozwolić sobie na ponowne ładowanie po poprawce, zamiast akceptować znane złe dane dla harmonogramu
- Start produkcyjny staje się decyzją opartą na dowodach, a aktywa testowe przeżywają migrację jako baza regresji
Perspektywa zarządu
- Gotowość do cutoveru to liczba na obiekt, a nie kolor statusu uzgodniony na spotkaniu, więc o starcie rozmawia się faktami, a nie przekonaniem
- Ryzyko programu staje się raportowalne dla zarządu i komitetu audytu: co przetestowano, co nie przeszło, co zaakceptowano i kto
- Wiedza migracyjna zostaje w przypadkach testowych, a nie u konsultantów, którzy odchodzą wraz z końcem projektu
Wpływ na KPI zarządu
Bezpieczeństwo i nadzór
Audytor powinien móc odtworzyć każdą decyzję.
- Roboty czytają oba systemy kontami technicznymi z uprawnieniem wyłącznie do podglądu; przepływ uzgodnienia nie potrzebuje prawa zapisu
- Granicę wyznaczają Państwa własna subskrypcja Azure, Państwa tenant i tenant UiPath Automation Cloud w regionie UE; zbiory porównawcze przygotowujemy w jej wnętrzu i kasujemy wg harmonogramu, a dane klientów, dostawców i rachunków bankowych nigdy poza nią nie wychodzą
- Poświadczenia leżą w Azure Key Vault wskazywanym z Orchestratora, a każdy odczyt da się przypisać do nazwanego konta w logu audytowym
- Test Manager utrzymuje historię wykonań, więc kto i kiedy zaakceptował dane odchylenie, można odpowiedzieć miesiące później, a o to właśnie pyta audytor przy saldach otwarcia
Dlaczego teraz
Programy konwersji biegną wobec ustalonego horyzontu: SAP zapewnia mainstream maintenance dla aplikacji rdzeniowych SAP Business Suite 7 do końca 2027 roku, z opcjonalnym wsparciem rozszerzonym do końca 2030 roku za dopłatą. Ręczna kontrola nie skaluje się w tym oknie.
Ilustracyjna pula 220 000 € mieści się w jednym roku migracji i nie da się jej odzyskać; za błąd przeoczony przed cutoverem płaci się według cen produkcyjnych.
Test Manager utrzymuje dziś powiązanie wymagań z testami, dowody wykonania i synchronizację z Azure DevOps oraz obejmuje testy SAP i interfejsowe w jednym miejscu, więc nie trzeba budować programu uzgodnień pod jeden projekt.
Role zarządcze, których to dotyczy
Salda otwarcia, pozycje otwarte i rachunki bankowe dostawców są odbierane na dowodach, a nie na próbce, i to ta wersja przechodzi przez audyt
Gotowość do cutoveru staje się mierzalną bramką, a aktywa migracyjne dalej pracują jako zestaw regresji
Pierwszy dzień po starcie produkcyjnym jest zwykłym dniem, bo procesy zamówień i faktur już przeszły na zmigrowanych danych
Częste pytania i zastrzeżenia
Łączy je platforma i niewiele poza tym. Nocna regresja chroni działający system przed zmianami, które do niego wdrażacie; zapewnienie jakości migracji dowodzi, że jednorazowe przeniesienie danych wyszło poprawnie, rekord po rekordzie, zanim ktokolwiek podpisze. Wartościowe połączenie jest takie, że aktywa migracyjne zasilają potem tamten zestaw regresji.
Liczby dowodzą, że wiersze dotarły, a nie że wartości są poprawne. Zgadzają się idealnie, gdy data zostaje ucięta, jednostka miary przeliczona dwa razy albo limit kredytowy ląduje jako zero. Porównanie na poziomie pól odpowiada na pytanie, które biznes odczuwa później.
Odczyt przez interfejsy zamiast przez ekrany zmienia arytmetykę, a obiekty biegną równolegle na wielu robotach. Przy ładowaniu produkcyjnym porównanie zawęża się do obiektów, od których zależy bramka, bo cały zakres został już potwierdzony w migracjach próbnych.
Kiedy to nie jest właściwe rozwiązanie
- Migracja kilku tysięcy rekordów do jednego obiektu, gdzie analityk faktycznie porówna obie strony w arkuszu
- Mapowanie pól zmienia się co tydzień i żaden obiekt nie ma wskazanego właściciela; reguły nie mają czego stabilnie testować
- Ani systemu źródłowego, ani zamrożonego wyciągu nie da się odczytać po cutoverze, więc brakuje wiarygodnej strony odniesienia
Pytanie na najbliższe posiedzenie
Podpisując cutover, jaki procent zmigrowanych rekordów ktokolwiek faktycznie porównał ze starym systemem i czy potrafimy to pokazać?
Podejście wdrożeniowe
Wdrożenie idzie etapami, bo tak da się je zatrzymać w każdej chwili.
Dostarczamy
- Przegląd listy obiektów: które obiekty, które pola, jakie przekształcenia, kto jest właścicielem
- Przypadki testowe uzgodnienia w Test Manager dla każdego obiektu, z regułami mapowania w postaci asercji i tolerancji
- Odczyty przez interfejsy obu systemów oraz przygotowanie danych, dzięki któremu porównanie miliona rekordów kończy się w oknie ładowania
- Przypadki procesowe na zmigrowanych danych: od zamówienia do faktury, od zakupu do płatności, wezwania do zapłaty
- Kierowanie błędów do Azure DevOps i Microsoft Teams, raportowanie gotowości oraz pakiet dowodowy na bramkę startu produkcyjnego
Potrzebujemy od Państwa
- Specyfikacji mapowania pól, nawet jeśli jest jeszcze niekompletna
- Wskazanego właściciela danych dla każdego obiektu, który rozstrzyga, co jest błędem
- Technicznego dostępu do odczytu obu systemów, środowiska próbnego oraz planu cutoveru z bramkami
Etapy
Zakres
Obiekty, pola, właściciele i definicja poprawności, uzgodnione z biznesem
Projekt
Reguły uzgodnienia, tolerancje, klasy odchyleń, model wagi, kryteria bramek
Budowa
Przypadki testowe w Test Manager, odczyty interfejsowe, przygotowanie danych, synchronizacja z Azure DevOps, kierowanie na Teams
Migracje próbne
Pełne uzgodnienie po każdym ładowaniu, obsługa błędów, powtórki po poprawkach, raport pokrycia
Cutover
Uzgodnienie ładowania produkcyjnego, a następnie przekazanie aktywów jako zestawu regresji
Działowe. O nakładzie decyduje liczba obiektów migracyjnych, precyzja dokumentacji mapowania pól oraz to, czy oba systemy da się czytać przez interfejsy, czy tylko przez ekrany.
Podpis mówi, że dane są poprawne. Próbka za tym podpisem to ułamek procenta.
Prosimy o listę obiektów migracyjnych i specyfikację mapowania pól, choćby roboczą. Odsyłamy proponowany zakres uzgodnienia dla każdego obiektu i taksonomię błędów na pierwszą migrację próbną.
Ustalmy zakres jednego obiektu migracjiTen sam problem ma zwykle sąsiedni proces
Koniec z zamykaniem miesiąca przez zgrywanie sald do Excela i dopraszanie się akceptacji e‑mailem.
Zobacz rozwiązanie Łańcuch dostawDane produktów i cenniki spójne we wszystkich kanałachKoniec z przepisywaniem każdego nowego produktu i zmiany ceny do ERP, PIM, sklepu internetowego i każdego marketplace.
Zobacz rozwiązanie Prawo i complianceKontrola rozdziału obowiązków co tydzień, nie raz w rokuKonflikty uprawnień znajduje raz w roku audytor. Najstarszy z nich ma wtedy dwanaście miesięcy.
Zobacz rozwiązanie IT i usługiRegresja portalu i aplikacji mobilnej przy każdym wydaniuRegresja to lista kontrolna, którą dwie osoby przeklikują w ostatnie popołudnie przed wydaniem.
Zobacz rozwiązanie Case studyRegresja SAP co nocZamiast trzech osób klikających przez dwa dni — agenci testowi UiPath przechodzą krytyczne ścieżki SAP każdej nocy.
Zobacz case study Case studyRoboty, które naprawiają się sameZmienił się ekran w SAP i pół portfela robotów staje? Healing Agent wykrywa zmianę interfejsu i naprawia selektory w locie, a nasz zespół AMS pilnuje całości — zanim biznes zauważy problem.
Zobacz case studyBranże, w których wdrażamy to najczęściejProdukcja i przemysłHandel i e‑commerceFinanse i ubezpieczenia