Transformacja SAP S/4HANA. Dlaczego największym wyzwaniem niekoniecznie była technologia?

Od momentu rozstrzygnięcia przetargu na realizację, do momentu zakończenia fazy Hypercare spędziłem w tym projekcie trzy lata jako Customer Director, Project Manager i architekt po stronie BPX. Był to bez wątpienia najtrudniejszy projekt zawodowy w moim życiu, ale jednocześnie ten, który dał mi najwięcej doświadczenia. Kilkudziesięciu konsultantów po stronie wykonawcy, prawie 500 osób zaangażowanych po stronie Klienta, tysiące spotkań i blisko 20 tysięcy stron dokumentacji projektowej, nieskończona liczba maili, i interakcji. Za tymi liczbami kryła się jednak znacznie ciekawsza historia. Bo największym wyzwaniem tej transformacji wcale nie był SAP…

Transformacja S/4HANA zaczyna się poza systemem

Patrząc z perspektywy czasu, problemy technologiczne były zazwyczaj tymi łatwiejszymi. Można je było przeanalizować, znaleźć rozwiązanie, skonfigurować system albo zbudować rozszerzenie. Znacznie trudniejsze było doprowadzenie dużej organizacji do wspólnych decyzji. Rozpoczynając delivery, w części obszarów nadal budowaliśmy fundamenty rozwiązania. W praktyce oznaczało to, że równolegle projektowaliśmy, uzgadnialiśmy i budowaliśmy.

Da się tak prowadzić projekt. Udowodniliśmy to wspólnie jako jeden zespół reprezentujący zarówno pracowników klienta, jak i zespół konsultantów Konsorcjum realizujące projekt. Tyle że jest to droga kosztowna. Nie tylko finansowo, ale przede wszystkim pod względem czasu i energii całej organizacji. Jedną z najważniejszych lekcji, które zabieram z tego projektu, można więc zamknąć w jednym zdaniu:

SAP można skonfigurować. Znacznie trudniej doprowadzić wiele osób do wspólnej decyzji.

W dużej transformacji czas bardzo łatwo traci się nie na samej konfiguracji systemu, ale na kolejnych rundach uzgodnień. My również poświęciliśmy ogromną liczbę godzin na dyskusje. Po czasie, z pewnej perspektywy, pewnie części z nich można było uniknąć przy większej dyscyplinie organizacyjnej, silniejszym change managemencie, skuteczniejszym zarządzaniu zmianą i skuteczniejszych mechanizmach decyzyjnych. Dodatkowym wyzwaniem była zmienność otoczenia biznesowego. W trakcie tak długiego czasu naturalnym jest, że zmienia się skład zespołu i osób decydujących, część wcześniejszych ustaleń trzeba ponownie wyjaśniać, potwierdzać lub osadzać w nowych realiach. Nie traktuję tego dzisiaj jako historii o tym, co poszło źle. Traktuję to jako jedno z najcenniejszych doświadczeń z całego projektu. W kolejnych transformacjach znacznie wcześniej niż kiedyś pytam więc nie tylko o zakres, harmonogram i architekturę. Pytam również: kto podejmuje decyzję? Ile ma na nią czasu? Kto i jak może zakończyć dyskusję? Czy biznes ma faktycznie zarezerwowane zasoby na projekt? Jak przygotowujemy ludzi do zmiany? Jak będzie wyglądać migracja do nowego systemu, zarządzanie danymi oraz przygotowanie organizacji do transformacji cyfrowej? To często ważniejsze pytania niż te dotyczące samej technologii.

Metodyka pomaga, ale nie zastąpi doświadczenia

Projekt prowadziliśmy na tyle agile, na ile pozwalały na to możliwości organizacji. Metodyka jest niezwykle istotna! Dawała zespołowi ramy działania, porządkowała prace i pomagała zarządzać ogromną liczbą zależności. Ale żaden framework nie odpowie na wszystkie sytuacje, które pojawiają się podczas trzyletniej transformacji obejmującej setki ludzi oraz tysiące rekordów danych SAP i innych baz danych.

W najtrudniejszych momentach równie ważne jak metodyka okazywały się doświadczenie konsultantów, znajomość biznesu przez Product Ownerów, współpraca pomiędzy zespołem Konsorcjum i zespołem Klienta oraz konsekwencja w realizacji przyjętego celu. Bo prędzej czy później w tak dużym projekcie wydarzy się coś, czego nie przewidziano na żadnym slajdzie… I wtedy trzeba po prostu wiedzieć, co robić, żeby rozwiązać problem i dalej niestrudzenie realizować przyjętą strategię.

TESTY. TESTY. TESTY.

Jeżeli miałbym wskazać jedną rzecz, której po tym projekcie broniłbym w każdym kolejnym wdrożeniu, są nią testy! Nie tylko dlatego, że pozwalają znaleźć błędy. Dobre testy integracyjne i end-to-end są jednym z najskuteczniejszych sposobów przygotowania organizacji do uruchomienia S/4HANA. To podczas nich użytkownik zaczyna naprawdę rozumieć nowy proces. Widzi, że jego czynność nie kończy się w jednym module. Zaczyna rozumieć wpływ swojej pracy na logistykę, finanse, controlling, podatki, raportowanie czy działania kolejnej spółki. Dlatego testów nie traktuję już wyłącznie jako elementu kontroli jakości. Testy są zarówno weryfikacją rozwiązania, integracji procesów, gotowości organizacji, jak i jedną z najbardziej efektywnych form szkolenia użytkowników! W projektach znajdujących się pod presją harmonogramu naturalna jest pokusa skracania testów, aby odzyskać kilka tygodni. Po tym doświadczeniu uważam, że jest to jedno z najdroższych miejsc, w których szuka się oszczędności czasu.

Nie wszystko zrobiliśmy idealnie

Łatwo byłoby opisać ten projekt jak klasyczne success story. Duża transformacja, ogromny zespół, SAP S/4HANA uruchomiony w harmonogramie, zakresie i budżecie; cel osiągnięty! Tylko że z takich historii niewiele można się nauczyć. My również popełnialiśmy błędy. Dzisiaj dzięki temu doświadczeniu już wiemy, których chciałoby się uniknąć w przyszłości, które kosztowały zespół najwięcej. Nie postrzegam tego jednak w kategorii porażek, wręcz przeciwnie! To właśnie one zbudowały doświadczenie, którego nie można zdobyć na szkoleniu, przeczytać w podręczniku SAP Activate ani wypracować podczas kilku miesięcy mniejszego wdrożenia.

Trzy lata życia zawodowego

Ten projekt ma dla mnie również wymiar bardzo osobisty. Oddałem mu prawie trzy lata swojego życia zawodowego. Były okresy ogromnej presji, zmęczenia i frustracji. Były tygodnie, kiedy budziłem się z projektem i z nim zasypiałem lub w ogóle nie spałem. Były momenty, w których liczba nowych problemów rosła szybciej, niż byliśmy w stanie zamykać poprzednie i ogromna wiara w sukces, niezłomna determinacja oraz wsparcie przyjaciół i bliskich pozwoliły podołać tym wyzwaniom. Ale była i jest też ogromna satysfakcja! Przede wszystkim ze współpracy ludzi, którzy w najtrudniejszych momentach potrafili wspólnie rozwiązywać realne problemy. I właśnie ten aspekt zapamiętam najmocniej. Technologia jest niezwykle ważna. Metodyka również. Ale na końcu największe projekty dowożą ludzie!

BPX w innej lidze projektowej

Jest jeszcze jeden aspekt, który z perspektywy BPX ma dla mnie szczególne znaczenie. Ten projekt pokazał, że firma z całkowicie polskim kapitałem może wziąć odpowiedzialność za transformację SAP S/4HANA o skali kojarzonej przede wszystkim z największymi międzynarodowymi integratorami. Nie dlatego, że wszystko przebiegło idealnie, ale właśnie dlatego, że nie zawsze przebiegało idealnie i pomimo wszystko potrafiliśmy sobie z tym poradzić. Prawdziwym sprawdzianem partnera wdrożeniowego nie jest przecież projekt, w którym rzeczywistość przez trzy lata pozostaje zgodna z prezentacją przygotowaną na kick-off. Sprawdzian przychodzi wtedy, kiedy zmieniają się warunki, pojawiają się problemy, trzeba przebudować wcześniejsze założenia, znaleźć rozwiązanie i mimo wszystko konsekwentnie prowadzić projekt do celu. Śmiem twierdzić, że dla BPX ta transformacja była wejściem do innej ligi projektowej. Dla mnie była przede wszystkim ogromną lekcją doświadczenia i pokory.

Co zabrałbym ze sobą do kolejnej transformacji S/4HANA?

Po tych trzech latach moje najważniejsze wnioski są stosunkowo proste:

• Nie zaczynaj transformacji od technologii. Zacznij od ludzi, procesów i sposobu podejmowania decyzji. Bardzo dokładnie przygotuj i uzgodnij backlog – dzięki Piotr!
• Nie zakładaj, że koncepcja jest kompletna tylko dlatego, że dokument został formalnie odebrany.
• Stosuj metodykę, ale nie oczekuj, że zastąpi doświadczenie. Nie wierz też, że ludzie świadomie będą ją stosować.
• Zawsze dbaj o współpracę pomiędzy wykonawcą i Klientem. W końcu z naszą pomocą realizujemy uzgodnioną strategię Klienta i dla Klienta.
• Nie ma skrótów w testach!
• Transformacja SAP S/4HANA jest znacznie bardziej transformacją organizacji niż transformacją systemu. Najlepsze praktyki zaszyte w S/4Hanna jak najbardziej tą transformację wspierają.

I jeszcze jedno, już zupełnie osobiste. Z perspektywy czasu coraz bardziej wierzę, że rzeczy naprawdę warte osiągnięcia rzadko przychodzą łatwo. I chyba właśnie dlatego tak wiele nas uczą.

Jak wyglądało to w Waszych projektach? Co okazało się największym wyzwaniem: technologia, procesy, ludzie czy podejmowanie decyzji?