{"id":33987,"date":"2026-05-20T05:00:00","date_gmt":"2026-05-20T03:00:00","guid":{"rendered":"https:\/\/sii.pl\/blog\/?p=33987"},"modified":"2026-05-15T16:08:37","modified_gmt":"2026-05-15T14:08:37","slug":"dlaczego-wdrozenia-sap-s-4hana-wciaz-kuleja-mimo-ze-wszystko-bylo-przetestowane","status":"publish","type":"post","link":"https:\/\/sii.pl\/blog\/dlaczego-wdrozenia-sap-s-4hana-wciaz-kuleja-mimo-ze-wszystko-bylo-przetestowane\/","title":{"rendered":"Dlaczego wdro\u017cenia SAP S\/4HANA wci\u0105\u017c kulej\u0105 \u2013 mimo \u017ce \u201ewszystko by\u0142o przetestowane\u201d"},"content":{"rendered":"\n

Dashboard \u015bwieci na zielono, a jako PM i tak nie mo\u017cesz spa\u0107? Wielu z nas zna ten moment. Kilka dni przed go-live SAP S\/4HANA raporty wygl\u0105daj\u0105 bardzo dobrze. Testy zosta\u0142y wykonane, defekty zamkni\u0119te, akceptacje s\u0105 gotowe. Na papierze nie ma powodu do niepokoju. A jednak zostaje to charakterystyczne poczucie, \u017ce system nie jest w pe\u0142ni pod kontrol\u0105.<\/p>\n\n\n\n

Dlaczego wysokie pokrycie testami tak cz\u0119sto nie przek\u0142ada si\u0119 na realne bezpiecze\u0144stwo release\u2019u?<\/p>\n\n\n\n

Problem zazwyczaj nie le\u017cy w samej liczbie wykonanych test\u00f3w. Zespo\u0142y SAP testuj\u0105 naprawd\u0119 du\u017co. S\u0119k w tym, \u017ce te testy cz\u0119sto s\u0105 kompletnie oderwane od rzeczywistego ryzyka biznesowego. Jest to szczeg\u00f3lnie widoczne w \u015brodowiskach SAP S\/4HANA, gdzie poziom z\u0142o\u017cono\u015bci, integracji i tempo zmian s\u0105 znacznie wy\u017csze ni\u017c w tradycyjnych systemach ERP.<\/p>\n\n\n\n

W takim krajobrazie nawet drobna korekta w kluczowym komponencie, takim jak logika cenowa czy Master Data, mo\u017ce uruchomi\u0107 efekt domina \u2013 od integracji, przez aplikacje Fiori, a\u017c po systemy satelitarne. Konsekwencje mog\u0105 pojawi\u0107 si\u0119 dopiero w dalszych etapach procesu, na przyk\u0142ad podczas fakturowania, rozlicze\u0144 lub ksi\u0119gowa\u0144 finansowych.<\/p>\n\n\n\n

Z mojego do\u015bwiadczenia wynika, \u017ce pora\u017cki wdro\u017ceniowe nie s\u0105 wynikiem jednego wielkiego b\u0142\u0119du. To raczej efekt sumy ma\u0142ych niedoci\u0105gni\u0119\u0107 w procesie weryfikacji, kt\u00f3re kumuluj\u0105 si\u0119 w pi\u0119ciu obszarach.<\/p>\n\n\n\n

Gdzie tak naprawd\u0119 tracimy kontrol\u0119 nad systemem SAP?<\/strong><\/h2>\n\n\n\n

W wi\u0119kszo\u015bci projekt\u00f3w SAP chaos nie bierze si\u0119 znik\u0105d. Zazwyczaj zawodzi jeden z tych pi\u0119ciu element\u00f3w:<\/p>\n\n\n\n

    \n
  1. Priorytety:<\/strong> \u0179le zdefiniowany zakres i waga zada\u0144.<\/li>\n\n\n\n
  2. Scenariusze:<\/strong> Testy, kt\u00f3re nie maj\u0105 nic wsp\u00f3lnego z \u017cyciem firmy.<\/li>\n\n\n\n
  3. Uprawnienia:<\/strong> Inny dost\u0119p do systemu w testach, a inny na produkcji.<\/li>\n\n\n\n
  4. Dane:<\/strong> Testowanie na \u201esterylnych\u201d, idealnych danych, kt\u00f3rych na produkcji nie ma.<\/li>\n\n\n\n
  5. Decyzje:<\/strong> Brak jasnych zasad i oparcie si\u0119 na \u201eintuicji\u201d zamiast na faktach.<\/li>\n<\/ol>\n\n\n\n
    \"Gdzie\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
    Ryc. 1 Gdzie tak naprawd\u0119 tracimy kontrol\u0119 nad systemem SAP?<\/figcaption><\/figure>\n\n\n\n

    Ka\u017cdy z tych element\u00f3w osobno wydaje si\u0119 mo\u017cliwy do opanowania. Razem decyduj\u0105 jednak o tym, czy release b\u0119dzie przewidywalny czy kruchy. Wystarczy, \u017ce jeden z nich jest s\u0142aby, a zaufanie do ca\u0142ego release\u2019u zaczyna si\u0119 chwia\u0107 \u2013 cz\u0119sto dopiero bardzo p\u00f3\u017ano w cyklu.<\/p>\n\n\n\n

    To w\u0142a\u015bnie tutaj najcz\u0119\u015bciej rodz\u0105 si\u0119 niespodzianki tu\u017c przed go-live.<\/p>\n\n\n\n

    Paradoks pokrycia: Kiedy wszystko jest wa\u017cne, nic nie jest wa\u017cne<\/strong><\/h2>\n\n\n\n

    Pierwszy problem cz\u0119sto pojawia si\u0119 ju\u017c na etapie definiowania zakresu test\u00f3w. Im bli\u017cej release\u2019u, tym silniejsza staje si\u0119 presja, aby rozszerza\u0107 regresj\u0119 i \u201eprzetestowa\u0107 wszystko\u201d. Zespo\u0142y dodaj\u0105 kolejne scenariusze, uruchamiaj\u0105 coraz wi\u0119cej przypadk\u00f3w testowych i wierz\u0105, \u017ce wi\u0119ksze pokrycie automatycznie oznacza mniejsze ryzyko.<\/p>\n\n\n\n

    Problem w tym, \u017ce bez jasnej priorytetyzacji biznesowej wi\u0119kszy zakres test\u00f3w nie zawsze daje wi\u0119ksze bezpiecze\u0144stwo. Cz\u0119sto prowadzi do paradoksu pokrycia: Kiedy wszystko ma najwy\u017cszy priorytet, zesp\u00f3\u0142 traci z oczu to, co naprawd\u0119 krytyczne.<\/p>\n\n\n\n

    W efekcie setki godzin s\u0105 po\u015bwi\u0119cane na sprawdzanie funkcji o niskim ryzyku, podczas gdy kluczowe procesy \u2013 takie jak Order-to-Cash, fakturowanie czy obs\u0142uga strategicznych klient\u00f3w \u2013 nie s\u0105 testowane w wystarczaj\u0105co realistycznych warunkach.<\/p>\n\n\n\n

    \"Kiedy\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
    Ryc. 2 Kiedy wszystko jest wa\u017cne, nic nie jest wa\u017cne<\/figcaption><\/figure>\n\n\n\n

    I wtedy zielone raporty z test\u00f3w przestaj\u0105 mie\u0107 znaczenie. Gdy problem pojawia si\u0119 dopiero w prawdziwym \u017cyciu: Podczas za\u0142adunku towaru, wystawiania faktury lub ksi\u0119gowania, \u201ewysokie pokrycie testami\u201d okazuje si\u0119 pustym KPI, kt\u00f3ry nie ochroni\u0142 biznesu przed realnym zak\u0142\u00f3ceniem.<\/p>\n\n\n\n

    Pu\u0142apka automatyzacji: Szybciej wcale nie znaczy lepiej<\/strong><\/h2>\n\n\n\n

    Automatyzacja ma przyspiesza\u0107 testy i zwi\u0119ksza\u0107 skalowalno\u015b\u0107. Ale sama automatyzacja nie projektuje lepszych test\u00f3w \u2013 wykonuje tylko to, co wcze\u015bniej zosta\u0142o zdefiniowane.<\/p>\n\n\n\n

    Je\u015bli przypadki testowe s\u0105 nieaktualne, zbyt techniczne albo oderwane od logiki biznesowej, automatyzacja pomo\u017ce jedynie szybciej doj\u015b\u0107 do b\u0142\u0119dnych wniosk\u00f3w.<\/p>\n\n\n\n

    W S\/4HANA, gdzie aplikacje Fiori, integracje i API zmieniaj\u0105 si\u0119 dynamicznie, wiele zespo\u0142\u00f3w wpada w pu\u0142apk\u0119 automatyzowania status quo. Zamiast walidowa\u0107 realne ryzyko biznesowe, QA coraz wi\u0119cej czasu po\u015bwi\u0119ca na utrzymanie skrypt\u00f3w i doprowadzanie ich do \u201ezielonego\u201d wyniku.<\/p>\n\n\n\n

    \"pu\u0142apka\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
    Ryc. 3 Pu\u0142apka automatyzacji<\/figcaption><\/figure>\n\n\n\n

    Efekt jest niebezpieczny: Automatyzacja wygl\u0105da dobrze w raporcie, ale nie zawsze potwierdza, \u017ce proces biznesowy naprawd\u0119 dzia\u0142a. A je\u015bli problem ujawnia si\u0119 dopiero w pierwszych godzinach produkcji, koszt naprawy jest wielokrotnie wy\u017cszy ni\u017c na etapie dobrze zaprojektowanej walidacji.<\/p>\n\n\n\n

    Uprawnienia: Mur, kt\u00f3rego nie wida\u0107 w testach<\/strong><\/h2>\n\n\n\n

    Dost\u0119py cz\u0119sto traktuje si\u0119 jako techniczny temat zespo\u0142u security. Tymczasem to w\u0142a\u015bnie uprawnienia wyznaczaj\u0105 granice tego, co naprawd\u0119 zosta\u0142o przetestowane.<\/p>\n\n\n\n

    Je\u015bli testerzy w QA maj\u0105 szersze dost\u0119py ni\u017c u\u017cytkownicy na produkcji, zesp\u00f3\u0142 waliduje system w warunkach, kt\u00f3re nie odzwierciedlaj\u0105 rzeczywisto\u015bci. To, co dzia\u0142a\u0142o u testera, mo\u017ce po go-live zako\u0144czy\u0107 si\u0119 b\u0142\u0119dem dost\u0119pu, niedost\u0119pn\u0105 funkcj\u0105 albo zablokowan\u0105 transakcj\u0105.<\/p>\n\n\n\n

    W S\/4HANA Fiori ten problem jest szczeg\u00f3lnie widoczny, bo dost\u0119p do aplikacji, kafelk\u00f3w i funkcji zale\u017cy od konkretnych katalog\u00f3w, r\u00f3l i przypisa\u0144.<\/p>\n\n\n\n

    \"uprawnienia\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
    Ryc. 4 Uprawnienia<\/figcaption><\/figure>\n\n\n\n

    Efekt? Awaryjne zmiany w uprawnieniach tu\u017c po starcie, wi\u0119ksze ryzyko compliance i realne zak\u0142\u00f3cenia pracy u\u017cytkownik\u00f3w w krytycznych procesach biznesowych.<\/p>\n\n\n\n

    Dane testowe: Problem sterylnego laboratorium<\/strong><\/h2>\n\n\n\n

    Dane testowe to jeden z najbardziej niedocenianych element\u00f3w cyklu \u017cycia SAP. Cz\u0119sto traktuje si\u0119 je jak techniczny warunek wst\u0119pny: Co\u015b, co raz na jaki\u015b czas kopiuje si\u0119 z produkcji, od\u015bwie\u017ca i zostawia bez dalszej kontroli.<\/p>\n\n\n\n

    Problem w tym, \u017ce to w\u0142a\u015bnie dane decyduj\u0105 o tym, co pozostaje niewidoczne podczas test\u00f3w. Je\u015bli walidacja odbywa si\u0119 na zbyt czystych, uproszczonych lub sztucznie przygotowanych danych, system nie spotyka si\u0119 z realn\u0105 z\u0142o\u017cono\u015bci\u0105 produkcji.<\/p>\n\n\n\n

    Widzia\u0142em projekty, w kt\u00f3rych krytyczne zmiany przechodzi\u0142y wszystkie bramki QA, poniewa\u017c by\u0142y testowane na \u201eczystych\u201d rekordach. Dopiero po go-live okazywa\u0142o si\u0119, \u017ce produkcja zawiera historyczne wyj\u0105tki, niekompletne dane klient\u00f3w, nietypowe znaki, brakuj\u0105ce kody lub niesp\u00f3jno\u015bci w Master Data, kt\u00f3rych testy nigdy nie obj\u0119\u0142y.<\/p>\n\n\n\n

    \"dane\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
    Ryc. 5 Dane yestowe<\/figcaption><\/figure>\n\n\n\n

    Efekt? Testowanie w \u201esterylnym laboratorium\u201d daje fa\u0142szywe poczucie bezpiecze\u0144stwa. Pierwsze prawdziwe zderzenie systemu z rzeczywisto\u015bci\u0105 nast\u0119puje dopiero na produkcji, a wtedy naprawa nie polega ju\u017c tylko na poprawieniu b\u0142\u0119du. Cz\u0119sto oznacza czyszczenie danych, odblokowywanie proces\u00f3w, poprawianie ksi\u0119gowa\u0144 i prac\u0119 na \u017cywym organizmie firmy.<\/p>\n\n\n\n

    \u0141ad i AI: Kto faktycznie podejmuje decyzje?<\/strong><\/h2>\n\n\n\n

    W pewnym momencie release SAP przestaje by\u0107 wy\u0142\u0105cznie kwesti\u0105 techniczn\u0105, a staje si\u0119 decyzj\u0105 biznesow\u0105. Pytanie nie brzmi ju\u017c: \u201eIle przetestowali\u015bmy?\u201d, ale: \u201eCzy pozosta\u0142e ryzyko jest akceptowalne?\u201d<\/p>\n\n\n\n

    Tu pojawia si\u0119 rola nowoczesnego governance i AI. Sztuczna inteligencja mo\u017ce pom\u00f3c wskaza\u0107, kt\u00f3re obszary systemu faktycznie zosta\u0142y dotkni\u0119te zmian\u0105, gdzie skoncentrowa\u0107 regresj\u0119 i jakie luki istniej\u0105 w danych testowych.<\/p>\n\n\n\n

    Ale AI to nie zast\u0119pstwo dla kontroli. To jej wzmacniacz.<\/p>\n\n\n\n

    Je\u015bli proces decyzyjny jest s\u0142aby, AI nie naprawi problemu \u2013 mo\u017ce tylko przyspieszy\u0107 decyzje podejmowane na podstawie niepe\u0142nych danych. Bez jasnych kryteri\u00f3w, w\u0142a\u015bcicieli ryzyka i wiarygodnych informacji decyzje \u201eGo\/No-Go\u201d zaczynaj\u0105 opiera\u0107 si\u0119 na intuicji, presji terminu albo politycznej potrzebie dowiezienia projektu.<\/p>\n\n\n\n

    \"Kto\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
    Ryc. 6 Kto faktycznie podejmuje decyzje?<\/figcaption><\/figure>\n\n\n\n

    A wtedy najwi\u0119kszym ryzykiem nie jest to, \u017ce czego\u015b nie przetestowali\u015bmy. Najwi\u0119kszym ryzykiem jest to, \u017ce nie wiemy, czego nie wiemy.<\/p>\n\n\n\n

    Klucz do sukcesu: SAP Control Layer<\/strong><\/h2>\n\n\n\n

    W dojrza\u0142ych organizacjach bezpiecze\u0144stwo release\u2019u nie wynika z wi\u0119kszej liczby test\u00f3w. Wynika z dobrze zaprojektowanej warstwy kontroli, kt\u00f3ra spina zakres, procesy biznesowe, uprawnienia, dane testowe i decyzje release\u2019owe w jeden sp\u00f3jny system.<\/p>\n\n\n\n

    To w\u0142a\u015bnie nazywamy SAP Control Layer.<\/p>\n\n\n\n

    \"control\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
    Ryc. 7 Control layer<\/figcaption><\/figure>\n\n\n\n

    Jej rol\u0105 jest odpowiedzenie na trzy kluczowe pytania:<\/p>\n\n\n\n