Pejzaż systemów IT w przedsiębiorstwie zmienia się co najmniej raz na kilka lat. Od strony technicznej wynika to z pojawiania się nowych wersji systemów; planujemy np. upgrade SAP ERP do kolejnego Enhancement Package (EhP) lub konwersję do S/4HANA. Od strony organizacyjnej – firmy powiększają się w wyniku przejmowania innych spółek lub dokonują wydzielenia części działalności do nowego właściciela (tzw. projekt carve-out). Jednocześnie wśród tych zmian organizacje starają się dążyć do ujednolicenia swoich rozwiązań IT.
Wykorzystanie systemu ERP w tej samej wersji i z podobną konfiguracją we wszystkich spółkach w grupie firm zmniejsza koszty utrzymania. Łatwiej jest wtedy konsolidować i analizować dane biznesowe, łatwiej jest obsługiwać i monitorować jednolitą platformę technologiczną. Ma to szczególnie znaczenie w przypadku działania centrów usług wspólnych – finansowych, HR i IT.
Nawet jeśli grupa firm korzysta już z jednolitego systemu SAP, w sytuacji dołączenia nowego podmiotu (akwizycja innej firmy lub powołanie nowej spółki) stajemy przed koniecznością przeprowadzenia tzw. projektu rollout. Oznacza to przeniesienie grupowego rozwiązania wzorcowego SAP do nowej spółki. Inaczej ujmując: dołączamy kolejną część organizacji do wspólnego środowiska IT.
Firmy korzystające obecnie z systemu SAP w wersji ECC 6.0 stoją jednocześnie przed koniecznością zaplanowania konwersji do nowej wersji systemu – S/4HANA. Ta nowa generacja rozwiązań ERP od SAP jest już domyślną wersją rekomendowaną dla nowych wdrożeń i przynosi liczne usprawnienia w porównaniu do ECC 6.0. Jednak w kontekście planowania projektu rollout decyzja nie jest już tak oczywista: czy powinniśmy najpierw włączyć nową spółkę do istniejącego grupowego systemu ECC 6.0, czy może wcześniej dokonać konwersji obecnej instalacji do S/4?
Poniżej rozważymy trzy scenariusze, wraz z korzyściami i przesłankami wyboru każdego z nich:
- Konwersja do S/4, następnie rollout do nowej spółki;
- Rollout do nowej spółki, następnie konwersja całej instalacji do S/4;
- Wykorzystanie nowej spółki jako pilotażowego wdrożenia S/4 w grupie.
Dla wszystkich scenariuszy przyjmujemy jednakowe warunki wyjściowe:
- załóżmy, że grupa firm składa się z trzech spółek (A, B, C), w których działa już jednolity system SAP ECC 6.0;
- naszym zadaniem jest dołączenie czwartej spółki (D) do tego środowiska SAP.
Scenariusz 1. Konwersja do S/4, następnie rollout
Przejście z wersji SAP ECC 6.0 do S/4HANA to większe przedsięwzięcie od upgrade’ów SAP ERP, z którymi mieliśmy do czynienia dotąd (np. z wersji 4.x do 6.0 lub wyższy poziom EhP w 6.0). Dostosowania kodu programów ABAP (custom development), interfejsów, instrukcji użytkownika – są konieczne w większym stopniu i zajmują więcej czasu w porównaniu z poprzednimi zmianami wersji systemu.
Czas trwania większości zadań w projekcie konwersji będzie proporcjonalny do złożoności systemu. Zależy od rozmiaru bazy danych (techniczne działania w projekcie), liczby jednostek organizacyjnych (jak wiele wariantów scenariuszy testowych mamy do wykonania), liczby użytkowników systemu i wykorzystywanych przez nich funkcji (jak wiele instrukcji trzeba zaktualizować).
Na podstawie czysto matematycznej kalkulacji odpowiedź jest więc jednoznaczna: zminimalizujemy łączny nakład pracy w projekcie, jeśli najpierw dokonamy konwersji istniejącego systemu ECC 6.0 do S/4 (dla spółek A, B, C) i dopiero po tym wykonamy rollout do czwartej spółki.
Scenariusz 1. Konwersja do S/4, następnie rollout
Wynika to z następujących zależności:
- projekt konwersji do S/4 systemu „mniejszego” (obejmującego 3 firmy) będzie zawsze nieco krótszy i łatwiejszy od konwersji systemu „większego” (4 firmy),
- rollout systemu w wersji S/4 do nowej firmy będzie trwał tyle samo lub krócej (jeśli okaże się, że funkcjonalność dostępna dopiero w nowej wersji, np. embedded analytics, pozwoli spełnić potrzeby nowej firmy w S/4 łatwiej niż w ECC 6.0) niż rollout systemu w wersji ECC 6.0,
- dla spółki D w tym scenariuszu nastąpi tylko jedna zmiana systemu (tzn. dotychczasowy system na S/4), zamiast dwóch zmian (najpierw na ECC 6.0, a krótko po tym na S/4).
W zasadzie jedyną słabą stroną tego podejścia jest czas trwania projektu konwersji (który poprzedza projekt rollout). Jeśli priorytetem dla zarządu naszej grupy jest włączenie nowej spółki do jednolitego środowiska SAP w ciągu najbliższych 12 miesięcy, powinniśmy rozważyć scenariusz 2.
Scenariusz 2. Rollout, następnie konwersja do S/4
Czas trwania projektu konwersji ECC 6.0 do S/4 w praktyce trudno ograniczyć poniżej 5-6 miesięcy. W przypadku dużych, złożonych instalacji, wykorzystujących wiele procesów, z licznymi dostosowaniami (custom development) i interfejsami, powinniśmy liczyć się z dłuższym przedsięwzięciem, sięgającym nawet 12 miesięcy.
Jeżeli więc ze względów biznesowych musimy pilnie włączyć nową spółkę do wspólnego rozwiązania SAP (np. żeby w kolejnym roku finansowym cała grupa raportowała już dane z jednego systemu) – zaplanujmy w pierwszej kolejności projekt rollout. To niewątpliwie najkrótsza droga do objęcia całej grupy jednolitym systemem SAP.
Scenariusz 2. Rollout, a następnie konwersja do S/4
Pamiętajmy, że postępując w ten sposób, zaciągamy pewien „dług techniczny”: tworzymy większy, bardziej złożony pejzaż systemów ECC 6.0 oczekujący na konwersję do S/4HANA. Nie zatrzymujmy więc realizacji scenariusza 2 w połowie drogi (po wykonaniu rolloutu) i nie odkładajmy jego drugiej części, tzn. konwersji do S/4HANA! To przedsięwzięcie będzie i tak nieuniknione w ciągu najbliższych kilku lat. Lepiej zatem wykonać je zaraz po zakończeniu i ustabilizowaniu najbliższego projektu rollout. W przeciwnym razie, zanim zdążymy zaplanować konwersję… nasza organizacja może stanąć przed koniecznością kolejnego projektu biznesowej reorganizacji, który będzie kolidował z innymi projektami IT.
Jeśli organizacja zmienia się dynamicznie i nie możemy znaleźć dogodnego momentu na techniczny projekt konwersji do S/4HANA w stabilnym środowisku, to warto rozważyć jeszcze jedno możliwe podejście.
Scenariusz 3. Nowa spółka jako pilot konwersji i rollout „w drugą stronę”
W dużych organizacjach, korzystających z systemu ECC 6.0 od kilkunastu lat, projekt konwersji do S/4 bywa wielokrotnie odkładany w czasie. Wynika to z obaw o wpływ zmiany systemu na bieżące procesy biznesowe – np. czy do nowej wersji zostaną bezproblemowo zmigrowane wszystkie dostosowania programistyczne i interfejsy, którymi obudowaliśmy system w ciągu jego długiej historii.
W takiej sytuacji projekt rolloutu może stać się dobrym pretekstem do wprowadzenia S/4HANA do naszego pejzażu systemów. Wdrożenie nowej wersji systemu na początek tylko w nowej spółce ma kilka zalet:
- wprowadzamy S/4HANA do pejzażu IT grupy firm stopniowo, łagodząc obawy związane z konwersją na dużą skalę, przeprowadzoną w jednym kroku,
- system SAP zostanie wprowadzony do nowej spółki w relatywnie krótkim czasie,
- wprawdzie nie uzyskujemy w tym momencie jeszcze pojedynczego centralnego środowiska SAP w całej grupie, ale możemy podczas tego projektu ujednolicić procesy biznesowe, plan kont, numerację danych podstawowych itp. w spółce D – tak aby wspólne raportowanie i konsolidacja danych całej grupy były łatwiejsze.
Scenariusz 3. Nowa spółka jako pilot konwersji i rollout „w drugą stronę”
Kolejnym etapem tak zaplanowanego projektu jest rollout, ale wykonany… w drugą stronę, tzn. przenosimy rozwiązanie do spółek A, B, C. Taki rollout może nastąpić w jednym etapie lub stopniowo. Zależnie od doświadczeń zebranych przez organizację (szczególnie przez dział IT) podczas projektu w spółce D, możemy zadecydować o tempie przechodzenia pozostałych części organizacji do S/4HANA.
Podsumowanie
Przedstawiliśmy trzy warianty planowania projektów rollout w kontekście nadchodzącej konwersji SAP ECC 6.0 do S/4HANA.
Pierwszy scenariusz – pozwala zminimalizować pracochłonność (czyli również koszty) całej sekwencji projektów. Jest najbardziej racjonalnym wyborem, jeśli możemy sobie pozwolić na pewną elastyczność planowania harmonogramu prac.
Drugi wariant – zapewni nam osiągnięcie jednolitego rozwiązania SAP (w wersji ECC 6.0) w całej grupie firm w najkrótszym czasie. Powinniśmy zastosować go, jeżeli bezwzględnym priorytetem jest ujednolicenie pejzażu systemów SAP w całej grupie w czasie nie dłuższym niż 12 miesięcy.
Trzeci scenariusz – pozwoli nam wypróbować wersję S/4HANA w nowej spółce, bez wpływu na funkcjonowanie reszty organizacji. Może to być optymalne podejście w przypadku bardzo rozbudowanych instalacji SAP, rozwijanych od kilkunastu lat, z dużą liczbą customizacji i interfejsów. Pozwoli pokonać opór organizacji przed zmianą i rozpocząć modernizację pejzażu systemów.