Zmienia się biznes, zmienia się świat IT

Żyjemy w gospodarce wzrostu. Akcjonariusze i inwestorzy oczekują od firm wzrostu. Niezależnie od tych oczekiwań większość firm chce się po prostu rozwijać. Oznacza to: większą obecność i więcej produktów i/lub usług oferowanych przez firmy. W rezultacie firmy z jednej strony wychodzą poza zasadniczą, pierwotną działalność, a z drugiej wkraczają na rynki międzynarodowe, globalne. Innym sposobem na wzrost są też akwizycje. W każdym scenariuszu, w miarę upływu czasu, organizacja skupia wokół pierwotnej, głównej siedziby coraz więcej lokalnych oddziałów. Z centralą łączą je związki organizacyjne, ale różnić może zakres czy kształt procesów biznesowych. Różnic może być zresztą więcej na poziomie IT: np. zakres rozwiązań IT, w tym systemów ERP (różni dostawcy, różne wersje), nie wspominając o integracji z systemami satelitarnymi, obsługującymi określoną część lokalnego biznesu. Dla takich organizacji najlepszym rozwiązaniem może być zaprojektowanie, a następnie wdrożenie wzorca rozwiązań referencyjnych dla organizacji lokalnych.

Innym przypadkiem transformacji może być sytuacja, w której firma dochodzi do wniosku, że obecne narzędzia są niewystarczające, nieefektywne, zbyt złożone, nieadekwatne do skali lub przestarzałe, dlatego potrzebuje nowego, prostszego rozwiązania, lepiej dostosowanego do zakresu działalności.

Dwa światy – jeden cel

Jednak każdą transformację biznesową można rozpatrywać z dwóch perspektyw. Z jednej strony, istnieje organizacja biznesowa, która wywołuje potrzebę zmian, a z drugiej strony, istnieje zespół IT, który ułatwia ich wdrożenie. Obie strony mają na celu uproszczenie zarządzania biznesem, zazwyczaj poprzez wprowadzenie lub dostosowanie standardów, ujednolicenie procesów biznesowych w sposób, który wspiera lokalne filie, ale także pozwala centrali postrzegać grupę firm jako jedną organizację, a nie poszczególne, osobne firmy. Żadna z tych dwóch stron nie przeprowadzi udanych zmian na własną rękę. Potrzebna jest synergia obu światów. Biznes jest kołem zamachowym zmian, zaś IT zapewnia środki umożliwiające realizację potrzeb biznesowych. Jest to ważna kwestia, ponieważ często myśli się o zmianach lub innowacjach w kategorii IT, natomiast wpływ, korzyści i zakres, który faktycznie wymaga zmian, to biznes.

Projektowanie rozwiązania

Odpowiedzią na wszechobecną zmianę jest ciągły rozwój firmy i wprowadzanie rozwiązań ERP. Jest to szczególnie cenne dla organizacji, które działają globalnie, ale także rozwijają się w sensie bardziej lokalnym – np. otwierają nowe oddziały, zakładają nowe firmy lub otwierają nowe linie produkcyjne.

Aby kontrolować wzrost, potrzebne są solidne podstawy, które zapewnią również fundament do dalszego rozwoju. Taką podstawą w przypadku systemów ERP jest tzw. wzorzec wspólny. Żeby zaprojektować poprawny wzorzec, trzeba najpierw ustalić, jaka powinna być jego architektura wysokiego i niskiego poziomu.

SNP (aktualnie All for One Poland) poleca rozwiązanie czterowarstwowe.

Pierwsza, wspólna warstwa podzielona na:

  • Common Core Template (wspólny wzorzec podstawowy), który zawiera zestaw ustandaryzowanych procesów obsługujących kluczową, najbardziej standardową, podstawową część biznesu. Jest on łatwo replikowany do kolejnych organizacji, gdyż każda firma musi mieć ustandaryzowane procesy logistyczne, finansowe, kontrolingowe.
  • Common Extended Template (wspólny wzorzec rozszerzony), który obejmuje procesy standardowe dla organizacji większych, bardziej złożonych, o określonej specyfice. Mogą nadal być replikowalne między spółkami czy zakładami w ramach grupy, ale nie będą mieć zastosowania do każdej organizacji w grupie.

Druga, lokalna warstwa może być sklasyfikowana w następujący sposób:

  • Lokalne wymagania prawne – specyficzne lokalne wymagania prawne. Jest to zazwyczaj obowiązkowy element wdrożenia rozwiązania wzorca w nowym kraju lub w określonej, regulowanej branży. Każdy kraj ma swoje własne specyficzne wymagania biznesowe, które należy uwzględnić w systemie centralnym.
  • Lokalne wymagania biznesowe – są to ściśle biznesowe wymagania (nie narzucone przez ustawodawcę), jednak ze względu na specyfikę działalności gospodarczej mogą one mieć kluczowe znaczenie dla sukcesu lub porażki danej organizacji.

Common Core Template jest zazwyczaj uważany za niezmienialny. Inne elementy powinny być wdrażane na podstawie decyzji i silnego uzasadnienia biznesowego. Organizacja powinna określić, jakich funkcji potrzebuje do rozwoju biznesu i w jakim stopniu chce dostosować się do lokalnych potrzeb.

Co to jest „wzorzec”?

Pierwszym poziomem definicji wzorca jest jego struktura rozpatrywana z punktu widzenia poziomu standaryzacji/elastyczności oraz poziomu wymagań biznesowych obsługiwanych przez wspólne rozwiązanie informatyczne.

Drugim, często traktowanym jako oczywistość, a więc niedocenianym, poziomem jest faktyczna „zawartość” wzorca. Najbardziej podstawowym elementem wzorca korporacyjnego jest zestaw standardowych, zintegrowanych procesów biznesowych wraz z dostosowaniem/rozwojem systemu oraz dokumentacją funkcjonalno-techniczną. Kolejnym elementem jest zestaw scenariuszy testowych, które będą wykorzystywane do walidacji poprawności działania procesu, tzn. przedstawiają kroki, które należy podjąć, aby proces mógł zostać zakończony od początku do końca. Te dwa elementy są ściśle związane z instrukcjami obsługi prowadzącymi użytkowników procesu przez etapy ich codziennej pracy i wyjaśniającymi bardziej nietypowe lub problematyczne sytuacje.

Wzorce przemysłowe często zawierają również gotowe do użycia narzędzia, akceleratory upraszczające dostarczanie projektów, tj. wzorce dokumentacji projektowej, wzorce migracji danych, programy do wczytywania danych, narzędzia do raportowania postępów projektu, bazę wiedzy użytkowników wyjaśniającą, jak działa system, jakie są typowe problemy i jak je rozwiązywać. Wszystkie te elementy mogą być wykorzystane zarówno we wdrożeniu wzorca podczas projektu rolloutu, jak i do użytku operacyjnego przez organizację po rolloucie.

Wzorzec może również zawierać politykę, procedury i standardy opisujące, jak tworzyć i zmieniać ustawienia konfiguracyjne, jak projektować kod niestandardowy lub interfejsy, w jaki sposób dane powinny być opracowywane lub jakie powinny być konwencje nazewnictwa dla poszczególnych obiektów. Częścią wzorca może być również sama metodologia wdrożenia specyficzna dla firmy.

Zarządzanie rozwiązaniem

Wzorzec nie istnieje w próżni biznesowej. Pojawiają się zmiany biznesowe, nowe wymagania, zmieniają się istniejące wymagania. Zmiany te muszą być zarządzane w sposób kontrolowany przez określoną politykę w zakresie zarządzania. Zarządzanie jest zbiorem reguł i zasad w zakresie opracowania i zmian w rozwiązaniu wzorca. W szczególności zarządzanie wzorcem i kontrole mają zastosowanie do:

  • Zarządzania wzorcem: skupionym na utrzymaniu spójności i jakości wzorca. Obejmuje ono dokumenty, procedury, reguły, normy i narzędzia służące do zapewnienia zgodności i dostosowania rozwiązania do przepisów obowiązujących w całej firmie. W obszarze zarządzania wzorcem zazwyczaj decyduje się o procedurach zarządzania zmianą i wersjami, o zdefiniowanych ramach organizacyjnych (role organizacyjne i macierz RASCI) i zapewnia wsparcie dla zarządzania.
  • Zarządzania projektem: skoncentrowanym na kontrolowaniu i utrzymywaniu jakości realizacji projektu wdrożenia wzorca. Zarządzany przez zespół zarządzający projektem, np. poprzez zarządzanie zmianami, komunikacją lub ryzykiem. Obejmuje role związane z projektem i macierz RASCI, niezależną od organizacyjnego RASCI w zakresie zarządzania wzorcem. Zarządzanie projektem zawsze zależy od zarządzania wzorcem i podlega jego wpływowi.
  • Zarządzania IT: skoncentrowanym na utrzymaniu i kontroli IT i infrastruktury Zarządzane przez organizację IT. Obejmuje zarządzanie infrastrukturą i bezpieczeństwem oraz zarządzanie wydajnością. Zarządzanie IT sprzyja standaryzacji usług IT, np. standaryzacji sprzętowej (np. stacje robocze użytkowników, drukarki, terminale magazynowe), modelu dostarczania usług (lokalnie, hosting, SaaS) lub lokalizacji (np. centrala, lokalna).

Rollout SAP – cel

Kiedy wzorzec jest już zbudowany dla danej organizacji, przychodzi moment, w którym trzeba ten wzorzec wdrożyć, czyli przeprowadzić projekt rolloutu SAP.

Pierwsza rzecz, którą powinniśmy wziąć pod uwagę, to cele tego projektu. Zrozumienie tych celów jest kluczowym czynnikiem sukcesu ułatwiającym realizację rolloutu. Gdy organizacja, w której wdrażamy to rozwiązanie, będzie rozumiała, po co to robimy, to łatwiej zaakceptuje podejmowane decyzje. Na przykład jeżeli głównym celem jest standaryzacja,  to łatwiej będzie zrozumieć, dlaczego lokalny oddział musi zrezygnować z pewnych rozwiązań, które były wcześniej używane w firmie. Łatwiej będzie zrozumieć, że nowe rozwiązanie może być inne (może „gorsze"), ale na poziomie grupy zostanie ono ustandaryzowane. Dzięki temu wszyscy pracownicy pewne czynności będą wykonywali w ten sam sposób. Poświęcamy lokalność i specyfikę firmy na rzecz ujednolicenia pracy w ramach całej grupy.

Jeśli zaś głównym celem będzie wydajność i obniżenie kosztów, wtedy np. zrezygnowanie z lokalnej serwerowni i przeniesienie systemów do wspólnego centrum IT lub rezygnacja z pewnych lokalnych rozwiązań i przejście na inne rozwiązania jest uzasadnioną decyzją biznesową.

Skala projektu

Gdy są już określone cele rolloutu, należy zdefiniować, co w ramach danego projektu będzie do zrobienia.

Projekty rolloutu są bardzo zróżnicowane. Od prostych projektów, jak np. nowy zakład w tym samym kraju, przez otwieranie oddziałów w innych krajach, po rozwiązania bardziej skomplikowane, gdy firma chce wdrożyć rozwiązanie w kilku krajach w ramach jednego etapu. Ten ostatni przypadek często przekształca się w program kilku rolloutów rozłożonych na dłuższy okres czasu. Nie jest również niczym niezwykłym, że firmy decydują się na aktualizację swoich systemów informatycznych podczas realizacji programu rolloutu.

Przy bardzo dużych organizacjach może być nawet portfel programów obejmujących różne kraje w ramach jednej organizacji.

Sposób wdrożenia rozwiązania

Przy standardowych, jasno zdefiniowanych rolloutach, najczęściej stosowaną metodyką jest tradycyjna mapa wdrożenia oparta na SAP ASAP. Jest to tzw. model wodospadowy – ze zgromadzeniem i sprecyzowaniem wymagań, ich realizacją, walidacją i realizacją operacyjną. Drugim modelem, nie tak częstym wśród projektów rolloutu, jest elastyczna metodologia SAP Activate. Elastyczność, jaką zapewnia, niesie ze sobą również ryzyko niepewności, bardzo niepożądanej w przypadku projektów rolloutu. Istnieje również trzecia opcja, kiedy klient opracowuje własną metodologię wdrożeniową i chce ją wykorzystać w tym projekcie. Rzetelny partner wdrożeniowy SAP powinien być w stanie wykorzystać każdy z tych scenariuszy.

Ocena gotowości organizacyjnej

Przed rozpoczęciem realizacji projektu, należy ocenić gotowość organizacji do realizacji projektu. Aby zapewnić powodzenie projektu, należy wziąć pod uwagę następujące aspekty:

  • dojrzałość organizacyjna, w tym kto inicjuje projekt w firmie – IT ze względu na zapotrzebowanie na nowe systemy, ponieważ stare nie spełniają wymagań IT, czy też biznes chce zmienić rozwiązania, aby działać sprawnie w grupie,
  • procesy w firmie – w jakim stopniu jednostka lokalna wdrażająca systemy SAP jest dostosowana do procesów grupowych. Bardzo często zdarza się, że duża część procesów jest zgodna ze standardami firmy, ale lokalne odchylenia np. w logistyce mogą stanowić pewne ryzyko dla wdrożenia,
  • ostatnim elementem jest język – przy planowaniu komunikacji należy wziąć pod uwagę nie tylko język, który będzie używany w projekcie (jaki język jest używany przez lokalną spółkę zależną, zespół korporacyjny, partnerów wdrożeniowych), język, w którym pisana jest dokumentacja projektowa, ale także język samego rozwiązania, ze względu nie tylko na kluczowych użytkowników, ale także na użytkowników końcowych.

Definiowanie zakresu

Ostatecznie definiując strategię rolloutu, należy dokładnie określić sposób, w jakim będziemy zarządzać zakresem wdrożenia. W praktyce spotykamy się z dwoma skrajnościami – podejście rygorystyczne, sztywne, jeśli chodzi o trzymanie się wzorca, w którym lokalne rozwiązania nie zakłócają pracy z wzorcem. Z punktu widzenia centrali bywa dobrze widziane, natomiast z perspektywy lokalnej jednostki może oznaczać mniejsze wsparcie dla ich biznesu. W drugim – elastycznym podejściu – wzorzec jest wtedy podstawą, punktem odniesienia, ale spółka pozwala wdrożyć wszystko, co jest potrzebne lokalnie, aby zapewnić, że wszystkie wymagania są spełnione, aby firma była dobrze zarządzana i przynosiła zyski. Z punktu widzenia centralnego utrzymania takie podejście jest bardziej złożone, ponieważ rozwiązanie jest potencjalnie zbyt odległe od wspólnego modelu.

Najbardziej racjonalnym podejściem jest trzymanie się wzorca w jak największym stopniu, ale z krytyczną otwartością na lokalne wymagania, które są niezbędne do prowadzenia działalności gospodarczej.

Kolejne zagadnienie, które należy wziąć pod uwagę przy definiowaniu zakresu – to złożoność organizacyjna lub prawna. Złożoność organizacyjna oznacza np. liczbę podmiotów prawnych, które prawdopodobnie będą jednostkami gospodarczymi SAP. Plan projektu będzie różnie wyglądał w przypadku wdrożenia jednej firmy, a inaczej w przypadku wdrożenia sześciu podmiotów. Konieczne jest zrozumienie, na czym opiera się struktura organizacyjna firmy. Mówiąc o strukturze organizacyjnej, nie można pominąć zakładów produkcyjnych – na etapie planowania należy już zdecydować, jak je będziemy dołączać do systemu centralnego i jak będziemy zarządzać ryzykiem.

Dane – paliwo biznesowe

Żaden system nie będzie działał prawidłowo, jeśli nie będzie posiadał ważnych i poprawnych danych. Przy rolloucie trzeba brać pod uwagę następujące aspekty:

  • zakres danych – określenie, które dane są niezbędne w systemie SAP oraz w jaki sposób będą one gromadzone i migrowane. Ważne jest, aby opisać to na jak najbardziej szczegółowym poziomie, w tym również szacunkowe ilości i źródła danych,
  • właściciel danych – jednoznaczne określenie osób odpowiedzialnych za przygotowanie danych,
  • model danych – globalny i/lub lokalny model standardowy opisujący biznesowe (tj. wpływ) i techniczne (tj. tabele, pola) szczegóły danych, a także zastosowane konwencje,
  • strategia migracji danych – metody przekazywania danych do nowego systemu (automatyczne, półautomatyczne, ręczne), ustanawianie reguł związanych z migracją (gromadzenie, czyszczenie, mapowanie, wczytywanie, walidacja, konfiguracja) dla każdego obiektu danych w zakresie migracji,
  • harmonogram migracji danych – harmonogram działań związanych z migracją danych, dostosowany do innych działań projektu, w tym sekwencji migracji i potencjalnej dodatkowej pracy,
  • cele migracji danych – systemy SAP i mandanty, które będą wykorzystywane podczas działań związanych z migracją danych.

Role w projekcie rolloutu

Najważniejszą czynnością przy projektowaniu strategii rollout SAP jest określenie, a następnie przypisanie ról i odpowiedzialności. Zazwyczaj istnieją trzy grupy osób: firma (centrala) inicjująca i zarządzająca rolloutem, lokalna firma, dla której rollout jest tworzony, oraz partner wdrożeniowy w projekcie. Oczywiście, bardziej złożone sytuacje (np. z wieloma partnerami wdrożeniowymi, lokalnymi dostawcami) nie są niczym niezwykłym. Ważne jest jednak, aby wszystkie strony wiedziały, za co są odpowiedzialne w trakcie realizacji projektu. Dobrze zdefiniowane role w projekcie i przypisane odpowiedzialności (RACI) określają wiodącą rolę w projekcie.

Planowanie przejścia

Chociaż początek projektu może się wydawać zbyt wczesnym etapem, to właśnie wtedy należy dobrze zaplanować przejście, co będzie stanowić solidną podstawę do sprawnego przekazania rozwiązania podczas startu produktywnego z organizacji projektowej do organizacji serwisowej. Centralna organizacja, realizująca projekt, musi zapewnić, że informacje o organizacji serwisu aplikacyjnego, RACI, procesach i narzędziach są w odpowiedni sposób przekazywane lokalnej organizacji. Następnie, w trakcie trwania projektu, na podstawie harmonogramu przejścia, określa się i planuje niezbędne zasoby. Wiedza na temat potrzeb lokalnego wdrożenia musi być odpowiednio udokumentowana i udostępniona organizacji serwisowej. Jest to zespół projektowy, który z jednej strony zapewnia wsparcie po starcie produktywnym, a z drugiej strony organizacja serwisowa rozpoczyna tryb operacyjny serwisu aplikacyjnego. Rozwiązanie może być używane w trybie produktywnym.