Żyjemy w gospodarce opartej na zmianach. W idealnym scenariuszu zmiana jest zamierzona i zaplanowana. Rozwój biznesu jest dobrym przykładem: organizacje zmieniają się poprzez wzrost, np. rozszerzenie dotychczasowej działalności, zakup innych firm lub zwiększenie obecności międzynarodowej. Często jednak zmiany są nagłe, niespodziewane lub narzucone. Wymusza to szybką reakcję na dynamikę zewnętrzną, może wymagać zmiany priorytetów i zwykle skutkuje pewną transformacją biznesową. Istotną rolę we wspieraniu tego procesu odgrywa IT.

Niezależnie od czynnika wywołującego zmianę oczekiwania wobec niej są zwykle takie same: wyższa efektywność, ujednolicenie procesów i danych, a także spójność działań i usprawniona integracja. Z drugiej strony jest to również poszukiwanie możliwości obniżenia kosztów, ponownego wykorzystania zasobów, usprawnienia integracji i zmniejszenia wsparcia w zakresie realizacji wymagań biznesowych w celu osiągnięcia ograniczonej wartości długoterminowej.

Nic dziwnego, że zarówno zmiany, jak i wynikające z nich oczekiwania stanowią dla firmy prawdziwe wyzwanie. Jak zwiększyć efektywność dzięki zarządzaniu zmianami operacyjnymi? Jak zwiększyć spójność działania w skali globalnej? Jak zapewnić wymagany poziom spójności i jednolitości danych podstawowych w wielu firmach? Jak pogodzić potrzeby wielu krajów lub lokalizacji, zwiększając tym samym jakość ich współpracy?

Definiowanie wspólnego wzorca

Odpowiedzią na te wymagania w przypadku firmy działającej na systemie SAP jest wspólny wzorzec SAP (template SAP). Jest to zestaw informacji, aplikacji i struktury IT, które w połączeniu mają za zadanie wspierać organizację w ujednolicony sposób.

Z perspektywy funkcji wzorzec rozwiązania można sobie wyobrazić jako zestaw „warstw” grup funkcjonalnych. Na samym dole znajduje się wzorzec wspólnej podstawy. Jest to zestaw podstawowych funkcji, które są lub powinny być zharmonizowane we wszystkich spółkach w ramach grupy, i które wspierają codzienną działalność biznesową. Dla firm, które są bardziej wymagające lub po prostu obejmują szerszy niż typowy zakres funkcjonalny, wspólny wzorzec SAP zapewnia opcjonalną drugą warstwę rozszerzonych aplikacji i funkcji, również ujednoliconych i zarządzanych na poziomie globalnym (np. rozszerzona gospodarka magazynowa).

Oczywiście lokalne firmy mają swoje własne lokalne wymagania oprócz wspólnej „podstawy” lub jej „wspólnych rozszerzeń”. Wynika to albo z wymogów prawnych (wymagania lokalne – podstawa) lub po prostu ze specyfiki lokalnego biznesu (wymagania lokalne – rozszerzenia). Wynik analizy Fit-to-Standard/Gap powinien dostarczyć wskazówek na temat tego, czy i jak należy uwzględnić te dodatkowe wymagania. O ile wymogi prawne raczej trudno ominąć, to należy pamiętać, że dodanie do wspólnego rozwiązania funkcji o niższym priorytecie utrudni synchronizację i harmonizację procesów oraz utrzymanie systemu w dłuższym okresie.

Wzorzec rozwiązania można również traktować jako zestaw akceleratorów, komponentów potrzebnych, by projekty wdrożeniowe realizować szybciej, efektywniej i w bardziej zsynchronizowany sposób. Można stworzyć zestaw procesów biznesowych, które są dostępne, gotowe do użycia i zsynchronizowane w całej firmie. Mogą one obejmować modele procesów biznesowych, specyfikacje funkcjonalne i techniczne lub scenariusze testowe zapewniające wgląd w zakres funkcjonalny i jego walidację. Zazwyczaj wzorzec zawiera również akceleratory dostosowywania i rozwoju, np. standardowy plan kont, procedury cenowe lub firmowe druki. Oprócz tego wzorzec przeważnie oferuje także akceleratory i narzędzia służące do przyspieszenia realizacji projektów rolloutu, np. szablony dokumentacji projektowej, szablony gromadzenia danych czy programy do przesyłania służące do transferu danych do wspólnego rozwiązania SAP.

Jeśli firma korzysta z procesów SAP Best Practices, może używać akceleratorów, które są już dostępne w pakiecie gotowym do użytku. Niezależnie od akceleratorów kluczowe jest jednak poleganie na jednym, wspólnym dla całej firmy repozytorium, takim jak SAP CALM, MS SharePoint lub SAP Solution Manager, działającym jako punkt odniesienia.

Większe lub bardziej złożone organizacje mogą również rozważyć akceleratory organizacyjne, np. zasady dostosowywania, kodeks postępowania dotyczący tworzenia oprogramowania lub konwencje nazewnictwa. Kolejną kwestią do rozważenia jest model zarządzania rozwiązaniem na potrzeby długoterminowego utrzymania wzorca. Potrzebni są opiekunowie, czyli osoby, które będą utrzymywać rozwiązanie w stanie nienaruszonym i spójnym. Ostatecznie część sprzętu i oprogramowania określa, gdzie i jak systemy informatyczne są zarządzane i utrzymywane.

Nie oznacza to, że wzorzec rozwiązania musi obejmować wszystkie te elementy. Więcej nie zawsze znaczy lepiej. Jednak gdy złożoność organizacji rośnie, a skala i/lub zakres projektów rolloutowych jest duży, warto zainwestować w bardziej kompleksowy wzorzec wielokrotnego użytku. Alternatywnie mniejsze firmy mogą początkowo polegać na doświadczeniu i narzędziach partnera wdrożeniowego, skupiając się na szybszej realizacji projektu i odkładając decyzję o optymalnej konfiguracji wzorca na później.

Projekt oparty na wzorcu

Podczas gdy dokumentacja wzorca dostarcza wyjaśnień biznesowych i wytycznych dotyczących standaryzacji realizacji projektu, większe firmy mogą zdecydować się na pójście o krok dalej z wzorcem rozwiązania. Może to polegać na skonfigurowaniu zestawu ustawień dostosowujących, tak aby można je było zachować i ponownie wykorzystać w projektach rolloutu. Choć wymaga to pewnych przygotowań, może być dobrą inwestycją przy planowaniu np. globalnego programu rolloutów. Dla mniejszych firm taka wstępnie zdefiniowana konfiguracja jest mniej opłacalna, a co za tym idzie – mniej atrakcyjna.

Planując realizację projektu na podstawie wzorca, warto opracować zestaw gotowych do użycia szablonów na potrzeby najczęściej wykonywanych i/lub najbardziej czasochłonnych działań projektowych. Takie szablony dokumentacji mogą obejmować raport z analizy luk w celu zebrania wymagań specyficznych dla danego kraju, standardowe modele uprawnień, synchronizację ról systemowych lub zestaw skryptów testowych i scenariuszy walidacyjnych wykorzystywanych do testowania rozwiązania podczas projektu wdrożeniowego, a także podczas operacji testowania regresji lub aktualizacji. Ponieważ migracja danych jest zazwyczaj najbardziej kłopotliwą i czasochłonną częścią projektu, szablony pomagające członkom projektu w ustaleniu zakresu, gromadzeniu i dostarczaniu danych zgodnie z powszechnie przyjętymi standardami zmniejszają liczbę błędów i niespójności podczas migracji danych oraz przyspieszają proces migracji. W szczególności predefiniowane słowniki danych lub gotowe narzędzia migracyjne (np. projekty LSMW lub kokpitu migracyjnego) zdecydowanie zwiększają efektywność procesu migracji danych. Oczywiście, jeśli takich szablonów nie ma, doświadczony partner projektowy, taki jak All for One, może pomóc w jego opracowaniu lub po prostu dostarczyć go na potrzeby rolloutu.

Jeśli chodzi o realizację projektu, dobrze jest zastanowić się wcześniej nad standardami, które mogą pomóc w zachowaniu spójności podczas realizacji prac. Standardy te obejmują tzw. kodeksy postępowania opisujące wytyczne i zasady dotyczące np. dostosowywania, rozwoju programów i interfejsów klienta, kodowania danych lub uprawnień. Analogicznie, jasne wytyczne dotyczące identyfikacji np. procesów, transportów lub użytkowników, upraszczają i usprawniają działania projektowe. To samo dotyczy samego procesu realizacji: metodyka realizacji projektu lub wytyczne zarządzania zmianami organizacyjnymi przeprowadzają każdy zespół projektowy przez tę samą listę kontrolną działań projektowych i produktów.

Myśląc o wzorcu rozwiązania w dłuższej perspektywie, należy oczywiście uwzględnić nie tylko realizację, ale również zarządzanie. W zależności od złożoności lub specyfiki potrzeb firmy zarządzanie rozwiązaniem może skupiać się tylko na określonych procedurach, na przykład na zarządzaniu zmianami i wersjami. W scenariuszach na dużą skalę zarządzanie obejmuje również moment przejścia (przekazanie projektu do wsparcia operacyjnego), audyty jakościowe i wyciągnięte wnioski, a także pełne wsparcie organizacyjne w zakresie utrzymania rozwiązania, obejmujące struktury, role, zakresy odpowiedzialności oraz funkcjonalną i techniczną własność wspólnego wzorca.

Techniczne komponenty wzorca i jego architektura decydują o elastyczności i poziomie kontroli nad wspólnym rozwiązaniem. Dostępność scenariuszy chmurowych i on-premise w połączeniu z ofertą usług SAP i partnerów SAP zapewnia szeroką gamę opcji spełniających wszelkie potrzeby, począwszy od pełnej własności infrastruktury, aplikacji i procesów biznesowych (on-premise), poprzez IaaS, PasS aż po model SaaS.

Konfiguracja rolloutu

Niezależnie od tego, czy wzorzec będący punktem wyjścia jest przejrzysty i prosty, czy rozbudowany i złożony, służy jednemu celowi. Jest nim rollout rozwiązania do firmy, która go nie posiada. Istnieje jednak kilka kwestii, którymi należy się zająć w celu zapewnienia, by realizacja projektu i operacje biznesowe wsparte wynikami projektu zakończyły się sukcesem.

Oczywiste jest, że każda udana inicjatywa powinna zaczynać się od ustalenia jasnego celu. Zmiany o dużym zasięgu oddziaływania, a jedną z nich jest wdrożenie SAP S/4HANA, często budzą obawy, pytania, a nawet pewien opór. Ustalenie, zakomunikowanie i zrozumienie celów projektu toruje drogę osobom, które chcą działać w kierunku ich realizacji, a nie utrudniania ich osiągnięcia. Standaryzacja ujednolica procesy grupy, umożliwiając firmom lepszą współpracę jako całość. To stymuluje efektywność, która jest widoczna zarówno w wynikach finansowych firmy, jak i usprawnieniu jej działania. Efektywność prowadzi do optymalizacji, takich jak wycofanie z eksploatacji przestarzałego rozwiązania, spełnienie wymagań i rozwiązanie problemu braku wystarczającego wsparcia dla działalności biznesowej. Zrozumienie „dlaczego” coś się dzieje, skupia uwagę interesariuszy i ułatwia podejmowanie decyzji.

Kolejnym krokiem jest ocena pola gry i określenie skali rolloutu. Czy jest to mały projekt np. wdrożenie w jednym kraju, czy program równoległych rolloutów? Globalne organizacje „pakują” programy w jeszcze większe „kontenery”: portfolio programów ukierunkowanych na realizację wielu wdrożeń na całym świecie. Opracowywane później plany muszą być oparte na konkretnej sytuacji biznesowej i uwzględniać cele biznesowe, a także ograniczenia realizacyjne.

Następnie wybierany jest model realizacji. Obecnie klienci wybierają zwykle pomiędzy czymś nowoczesnym (SAP Activate), czymś „klasycznym” (np. SAP ASAP) lub czymś „pożyczonym” (zwykle autorski model realizacji). W przypadku wdrożeń SAP najbardziej oczywistym wyborem wydaje się metodyka SAP Activate. Koncentruje się ona na zwinnym, bardziej interaktywnym podejściu do wdrożenia, z większym zaangażowaniem klienta, oferując iteracyjną realizację i praktyczne doświadczenie. Z kolei podejście kaskadowe jest dobrze ugruntowane, choć ze względu na ograniczoną elastyczność traci na popularności. Organizacje zorientowane na projekt oraz partnerzy wdrożeniowi często wykorzystują własne niestandardowe, autorskie metodyki. Zespoły All for One są określane – bardzo trafnie – jako zwinne, co oznacza, że są gotowe do pracy w ramach każdego z przedstawionych scenariuszy realizacji.

Jak mówi przysłowie, przygotowanie to 80% sukcesu. Kiedy znana jest metodyka, jeszcze przed faktycznym rozpoczęciem projektu należy sprawdzić pewne wskaźniki gotowości organizacyjnej. Pierwszym jest dojrzałość organizacji planującej wdrożenie, m.in. czy procesy biznesowe są zdefiniowane, może nawet dopasowane do celów strategicznych, czy może są zupełnie nieustrukturyzowane, dlatego też stworzenie tej struktury stanie się jednym z celów projektu. Drugim aspektem jest zsynchronizowanie organizacji z centralą. Im wyższy poziom standaryzacji firmy, tym łatwiejsze wdrożenie. Potencjalne rozbieżności lub niestandardowe odstępstwa mogą wymagać dodatkowej optymalizacji.

Innym wskaźnikiem gotowości jest źródło inicjatywy projektu. Oczywiste jest, że projekty inicjowane przez biznes (a nie IT) kończą się lepszym dopasowaniem rozwiązania i większą satysfakcją biznesową. Rollouty zainicjowane przez IT również mogą odnieść sukces, jednak w ich przypadku więcej nakładu wymaga wdrożenie kluczowych i końcowych użytkowników oraz innych beneficjentów przyszłego rozwiązania do pracy z nim.

Ponieważ rollouty to zazwyczaj projekty międzynarodowe, nie należy lekceważyć umiejętności językowych lokalnych i centralnych zespołów oraz zespołów partnerów projektowych. Angielski może wydawać się oczywistym lingua franca w globalizującym się świecie. Jednak umiejętności językowe są bardzo indywidualne i np. biegła znajomość języka angielskiego lub niemieckiego w finansach nie pomoże pchnąć realizacji projektu do przodu w obszarze sprzedaży lub produkcji. Należy to wcześniej ocenić, aby przypisać ludzi do projektu, wiedząc, że będą oni w stanie skutecznie komunikować się z konsultantami korporacyjnymi i partnerskimi. Należy pamiętać, że międzynarodowe wdrożenia są, no cóż, międzynarodowe, dlatego język dokumentacji wzorca lub język systemu również może być kwestią do rozważenia.

Analiza zakresu

Jednym z kluczowych dylematów podczas rolloutu jest poziom kontroli, jaki przyznaje się lokalnej firmie w kwestii tego, na ile zakres rozwiązania z wzorca jest standardem niepodlegającym negocjacjom, a na ile dopuszczalne są lokalne różnice. W podejściu rygorystycznym wzorzec jest niemodyfikowalny, a jedynym odstępstwem jest dostosowanie do specyfiki prawnej. Gdy polityka korporacyjna jest elastyczna, wzorzec staje się bardziej rekomendacją i wskazówką, natomiast dostosowanie do lokalnej specyfiki jest ograniczone głównie przez czynniki ekonomiczne. Oczywiście pierwsza strategia skutkuje scentralizowanym rozwiązaniem i ograniczoną kontrolą lokalną, ale także silniejszą synergią i harmonizacją w całej grupie, co zapewnia lepszą ogólną efektywność, o której była mowa na początku tego artykułu. Drugie podejście wykorzystuje wzorzec rozwiązania jedynie jako akcelerator wdrożenia, tym samym znacząco zmniejszając efektywność inwestycji grupy we wspólne rozwiązanie.

Odpowiednio opracowany zakres wdrożenia jest ważnym elementem sukcesu projektu. Niezależnie od tego, czy projekt rolloutu jest międzynarodowy czy lokalny, ustalanie zakresu zaczyna się od analizy kwestii złożoności geograficznej. „Położenie geograficzne” to nie tylko lokalizacja na mapie, ale także zestaw zmiennych projektu. Nawet realizacja rolloutu w tym samym kraju, ale w dwóch odległych lokalizacjach rodzi pytania dotyczące określania zakresu, testowania lub organizacji wsparcia. Poza omówionymi już kwestiami językowymi położenie geograficzne determinuje wymagania prawne, np. rollouty między dwoma krajami unijnymi będą realizowane przy bardziej ograniczonym zestawie wymagań niż rollout z UE do Azji czy Afryki.

Oczywiście praca w innym kraju wiąże się z koniecznością analizy kwestii kulturowych. Ich zaniedbanie może doprowadzić do całkowitego niepowodzenia każdego lokalnego projektu. Wreszcie różnica czasu, która jeśli jest znacząca, ogranicza codzienne okno czasowe, w którym zespoły z różnych krajów mogą współpracować, i wymaga starannego planowania zarówno na poziomie zadań (np. zgranie spotkań), jak i na poziomie głównego harmonogramu projektu (np. dłuższy termin realizacji projektu).

O zakresie decyduje również złożoność struktury organizacyjnej firmy. Czasami jest to tylko jeden podmiot prawny lub jeden nowy zakład. W innych przypadkach może to być grupa kapitałowa lub grupa zakładów produkcyjnych w jednym kraju. Niezaprzeczalnie, im bardziej złożona organizacja, tym większym wyzwaniem będzie projekt rolloutu.

Oprócz wyzwań lokalizacyjnych różne podmioty oznaczają różnych interesariuszy mających agendy, które niekoniecznie są zsynchronizowane. Różne podmioty mogą również oznaczać różne cele (np. finansowe) lub profile biznesowe (np. handlowe, produkcyjne, łańcuch dostaw), które wiążą się z różnymi procesami biznesowymi. Wyrównanie tych różnic na poziomie lokalnym i dopasowanie ich do tego, co ma do zaoferowania wzorzec, jest jednym z głównych wyzwań projektu. Ostatecznie ma to również wpływ na strategię przejścia do eksploatacji zapewniającą ciągłość biznesową, ograniczenie zakłóceń i wystarczające wsparcie dla wszystkich zaangażowanych stron.

Przy przejściu od organizacji do zakresu pojawia się złożoność funkcji biznesowych i informatycznych. Rozróżnienie pomiędzy biznesem a IT jest zasadne, ponieważ obie grupy z pewnością będą patrzeć na zakres wdrożenia z różnych perspektyw (np. grupa procesów vs. obsługujące je komponenty rozwiązania). Rollouty są zazwyczaj inicjowane przez biznes, jednakże tylko zapewnienie, by ludzie z biznesu i IT zapoznali się ze „swoimi” warstwami rozwiązania, może sprawić, że projekt zakończy się sukcesem.

Nie należy jednak tracić z oczu szerszej perspektywy. Nawet najlepszy wzorzec nie uwzględni wszystkich funkcji dostarczanych przez lokalne systemy firm zewnętrznych. Niektóre z już istniejących rozwiązań zostaną wycofane i zastąpione nowo wdrożonym wspólnym systemem SAP. Inne zostaną zastąpione ich wspólnymi odpowiednikami (np. lokalny SFA zostanie zastąpiony wspólnym rozwiązaniem stosowanym globalnie). Pozostałe dotychczas używane systemy będą wymagały dostosowania do nowej sytuacji, np. integracji z systemem SAP grupy, dostosowania hostingu lub platformy bądź poważniejszej przebudowy.

Na koniec pozostaje migracja danych, która jest obszernym tematem zasługującym na osobny artykuł. Dane jako „paliwo” systemu mają kluczowe znaczenie dla ogólnego sukcesu wdrożenia, dlatego wymagają starannego zaplanowania z wyprzedzeniem. Na poziomie lokalnym wymaga to przeanalizowania zakresu danych oraz osób, które są i będą ich właścicielami. Podczas ustalania zakresu rolloutu należy uwzględnić między innymi standardy danych i model zarządzania (np. centralna lub lokalna gospodarka materiałowa), strategię przesyłania (np. które dane, gdzie i jak należy przesłać do określonych celów migracji) oraz harmonogramy migracji dotyczące gromadzenia i czyszczenia danych, zsynchronizowane z innymi działaniami projektowymi w ramach planu projektu.

Przypisanie ról

Po ustaleniu zakresu nadchodzi czas na określenie i przypisanie ról i obowiązków. Oczywiście role biznesowe są zwykle jasne. Trzeba je jednak połączyć z obowiązkami wprowadzanymi przez projekt wdrożeniowy. Z założenia mogą one być pogrupowane organizacyjnie: zespoły grupy i zespoły lokalne, do których dołączają partnerzy zewnętrzni. Jednakże rollout międzynarodowy często wprowadza do gry nowe osoby: opiekunów wzorca systemu, właścicieli procesów biznesowych i konsultantów wewnętrznych w zespole centralnym, partnerów grupy (np. odpowiedzialnych za utrzymanie systemu centralnego) i partnerów lokalnych (zwykle wspierających dostosowanie rozwiązania do lokalnej specyfiki). Efektywne połączenie ich z lokalnym biznesem i IT wymaga jasności i przejrzystości, najlepiej w formie matrycy obowiązków i odpowiedzialności. Narzędzie to pomaga kierownikom projektów upewnić się, że wszystkie działania i role projektowe są właściwie przypisane i każdy wie, za co jest odpowiedzialny.

Realizacja projektu to jednak nie wszystko. Aby uzyskać doskonały rezultat, wyniki udanego projektu muszą zostać pomyślnie przekazana do wsparcia operacyjnego. Ważną rolę odgrywa zespół centralny, który zazwyczaj definiuje model usług zarządzanych (np. centralny, lokalny, hybrydowy, wewnętrzny lub zarządzany przez partnera) i zapewnia strukturę przejścia. Projekt jest naprawdę zakończony dopiero po przekazaniu przez partnera projektowego rozwiązania i produktów projektu oraz zaangażowaniu wsparcia operacyjnego.

Zaangażowanie

Czy jest to „mission impossible”? Cóż, zdecydowanie jest to trudne do wykonania przedsięwzięcie, biorąc pod uwagę globalną skalę oraz potencjalne ryzyko i wyzwania, np. ustalenie priorytetów dla projektów rolloutu vs. określenie ich dla konwersji do S/4. Jednak można śmiało powiedzieć, że wsparcie doświadczonego, profesjonalnego partnera może sprawić, że ten długodystansowy bieg nie przysporzy nam zadyszki.