Temat roku

Co kilka lat SAP AG udostępnia nowe wersje systemów, także SAP HR. Podniesienie wersji systemu wydaje się przedsięwzięciem bardziej technicznym niż biznesowym i w istocie tak jest. Temat upgrade’u systemu SAP do wersji ERP 2005 dominuje obecnie w rozmowach w wielu działach IT.

Firma Towers Perrin w IX raporcie rocznym dotyczącym serwisu HR w przedsiębiorstwach amerykańskich (zaprezentowanym w marcu tego roku na konferencji HR2007 w Las Vegas) wskazuje, że około 50% badanych firm posiadających SAP planowało upgrade systemu w 2006 lub 2007 r.

Podobnie dzieje się na polskim rynku, a przyczyna tego jest banalna – kończący się w pierwszym kwartale 2009 r. czas wsparcia dla wersji Enterprise HR-CEE 100_470 (popularnie zwanej 4.7) oraz już zakończony okres wsparcia dla wcześniejszych wersji flagowego produktu koncernu SAP AG i tym samym modułów HR.

Czarne scenariusze

O tym, jak ważne jest poprawne przeprowadzenie upgrade’u SAP HR, nie trzeba nikogo przekonywać.

Niewłaściwie funkcjonująca wyższa wersja może na przykład uniemożliwić poprawne naliczenie płac dla pracowników, a to miałoby wręcz katastrofalne skutki dla niemal każdej firmy.

Można wymienić też kilka innych czarnych scenariuszy: niedostępność wybranych aplikacji HR, dodatkowe koszty związane z „gaszeniem pożarów” czy przeciążenie pracowników.

Jak zminimalizować to ryzyko?

Modele i terminy wsparcia

Obecnie okres wsparcia produktów z rodziny SAP Business Suite jest definiowany na podstawie modelu opisywanego ciągiem „5-1-2”. Poszczególne cyfry w opisie modelu oznaczają odpowiednio:

  • 5-letni okres podstawowego okresu wsparcia (Mainstream Maintenance)
  • roczny okres wsparcia rozszerzonego (Extended Maintenance)
  • 2-letni okres kolejnego wsparcia rozszerzonego

W podstawowym okresie wsparcia klienci ponoszą standardową, uzgodnioną z SAP opłatę licencyjną, w ramach której uzyskują dostęp do pełnego wachlarza usług koncernu, mają prawo pobierania poprawek do komponentów systemu oraz możliwość aktualizacji systemu do udostępnianych przez SAP wersji produktów.

Kolejne etapy wsparcia rozszerzonego (Extended Maintenance) wiążą się ze zwiększeniem opłaty licencyjnej przy zachowaniu wszystkich korzyści, jakie klient miał w podstawowym okresie wsparcia.

Z tego punktu widzenia powyższy model – co jest szczególnie cenne dla osób odpowiedzialnych za finanse firmy – można przedstawić w inny sposób: „x + 2% + 4%” . W takiej prezentacji poszczególne cyfry oznaczają wzrost kwoty opłaty licencyjnej ponoszonej przez klienta.

Te z przedsiębiorstw, które w okresie wsparcia wykorzystywanej wersji systemu nie wykonają aktualizacji, automatycznie wchodzą w okres wsparcia dedykowanego dla klienta (Customer-Specific Maintenance), którego warunki finansowe są negocjowane z SAP.

Aktualnie obowiązujące terminy wsparcia dla najczęściej wykorzystywanych w Polsce wersji systemów SAP HR to:

  • Enterprise HR-CEE 100_470 (4.70) – 31.03.2009
  • Enterprise HR-CEE 105_500 (5.00) – 23.05.2005
  • Enterprise HR-CEE 106_500 (5.00) – 31.03.2010
  • Enterprise HR-CEE 110_600 (6.00) – 31.03.2011

Dla wcześniejszych wersji okres wsparcia już się zakończył.

Modele wsparcia dla poszczególnych wersji systemów z rodziny SAP można znaleźć na portalu producenta pod adresem http://service.sap.com/maintenance

Dlaczego upgrade?

Powody, które najczęściej przyświecają decyzji o podniesieniu wersji systemu do ERP 2005, to:

  • kończący się okres wsparcia (o czym pisaliśmy powyżej),
  • funkcjonalności dostępne w nowej wersji,
  • optymalizacja procesów jako część projektu,
  • mniejsze koszty utrzymania systemu, redukcja złożoności IT,
  • nowe technologie (np. SAP NetWeaver),
  • decyzja korporacji, której przedsiębiorstwo jest częścią.

W przypadku modułu HR często decydujące znaczenie mają terminy zakończenia wsparcia. Ewentualne nowe funkcjonalności dostępne w wersji ERP 2005 nie są niestety języczkiem u wagi –  najnowsza wersja systemu nie przynosi rewolucyjnych zmian w obszarze zarządzania kapitałem ludzkim.

Różnice dotyczą przede wszystkim standardowych funkcji samoobsługowych, ECM (Enterprise Compensation Management), e-learningu i e-rekrutacji. Zainteresowanych szczegółami zachęcamy do skorzystania z serwisu http://solutionbrowser.erp.sap.fmpmedia.com/ – udostępniona aplikacja pozwala uzyskać listę różnic pomiędzy wybranymi wersjami systemów SAP.

Jak zaplanować projekt?

W Polsce działa wiele instalacji systemu SAP HR izolowanych od pozostałych funkcjonalności (FI, CO, MM itp.) i komunikujących się z nimi poprzez standardowy interfejs ALE.

W takich warunkach podniesienie wersji SAP HR jest najczęściej osobnym projektem, niezależnym od upgrade’u pozostałych modułów. W takich przypadkach łatwiej jest zaplanować przedsięwzięcie, tak by zminimalizować ryzyko jego negatywnego wpływu na procesy kadrowo-płacowe.

W sytuacji gdy projekt podniesienia wersji obejmuje wszystkie moduły, właściciele biznesowi SAP HR powinni być aktywnie zaangażowani w przygotowanie planu upgrade’u, by ostateczny harmonogram uwzględniał cykliczność procesów płacowych.

Gdy upgrade obejmuje wszystkie moduły, właściciele biznesowi  SAP HR powinni być aktywnie zaangażowani w przygotowanie planu projektu, by ostateczny harmonogram uwzględniał cykliczność procesów płacowych

Pierwszym czynnikiem określającym datę startu projektu jest termin zakończenia wsparcia wersji, która ma być podnoszona. Kolejne ograniczenia, które trzeba uwzględnić, to:

  • inne projekty i prace angażujące kluczowe osoby (uniknięcie problemu „single point of failure”),
  • cykle HR (terminy rozliczeń płac, przygotowywania planów kosztów, ocen pracowniczych itp.),
  • dostępność zasobów i pracowników zaangażowanych w projekt (okresy urlopowe, planowane szkolenia itp.).

Często zadawanym pytaniem jest: jak długo będzie trwał upgrade do wersji ERP 2005? Według statystyk prowadzonych przez SAP taki projekt trwa średnio 3,5 miesiąca, a w przypadku gdy podnoszoną wersją jest 4.6C – do 5 miesięcy.

Oczywiście uśrednienie to może być nieadekwatne do sytuacji konkretnego przedsiębiorstwa i dopiero zaplanowanie wszystkich działań na osi czasu może dać konkretną odpowiedź. Główne czynniki wpływające na czas trwania upgrade’u SAP HR to:

  • liczba i złożoność modyfikacji klienckich (user exits, raporty klienckie, naprawy, kopie transakcji, programy itp.),
  • liczba i złożoność interfejsów,
  • liczba i złożoność koniecznych testów,
  • typ projektu: upgrade techniczny lub funkcjonalny.

Według tych samych statystyk SAP, popartych naszym doświadczeniem, 30% czasu projektu pochłania dostosowanie modyfikacji klienckich do nowej wersji, a kolejne 25-30% – testy funkcjonalności.

Czynniki sukcesu

W projekcie upgrade’u kluczowe znaczenie ma właściciel biznesowy. W sytuacji idealnej powinien to być przedstawiciel działu HR, rozliczany z efektów projektu. Drugim ważnym czynnikiem jest dobrze przygotowany i udokumentowany plan wraz z procedurą upgrade’u (o czym w dalszej części artykułu). Wreszcie nie do przecenienia jest praca zespołowa specjalistów technicznych i funkcjonalnych z jednoznacznie zdefiniowanymi rolami w projekcie.

Jaka dokumentacja?

W każdym projekcie obowiązują standardy dokumentowania zdefiniowane w fazie planowania przedsięwzięcia. W przypadku upgrade’u podstawowe znaczenie mają:

  • plan projektu upgrade’u (m.in. karta projektu, zakres, harmonogram, budżet, podział prac, kamienie milowe),
  • podręcznik upgrade’u,
  • dokumentacja rozszerzeń,
  • dokumentacja testów (regresywnych i akceptacyjnych),
  • instrukcje użytkowników.

O czym należy pamiętać

Przygotowując projekt upgrade’u dla SAP HR, nie można zapomnieć o planie awaryjnym. W harmonogramie należy przewidzieć tzw. punkty decyzyjne (go/no-go), w których kierownicy przedsięwzięcia decydują o kontynuacji prac lub ich przerwaniu czy powtórzeniu etapu.

Pamiętajmy o tym, że drobne opóźnienie może w konsekwencji doprowadzić do sytuacji, w której system jest niedostępny podczas rozliczania płac. Oczywiście przy odpowiednim rygorze w monitorowaniu projektu jesteśmy w stanie przewidzieć takie zagrożenia i podjąć na czas właściwe decyzje.

Na etapie planowania warto rozważyć kilka dodatkowych aspektów organizacyjnych:

  • możliwość przeniesienia list dodatkowych z okresów niedostępności systemu na inne terminy,
  • zapewnienie zastępstw,

§założenie wcześniejszego uruchomienia wybranych procesów (np. rozliczenia z Urzędem Skarbowym i ZUS).

Warunkiem koniecznym jest ograniczenie (a wręcz zamrożenie) na czas upgrade’u prac konfiguracyjnych i rozwojowych HR. Może oczywiście zaistnieć potrzeba przeprowadzenia takich prac – należy wtedy podjąć decyzję o sposobie ich realizacji (w okresie od rozpoczęcia upgrade’u systemu deweloperskiego – DEV – do zakończenia podniesienia wersji systemu produktywnego – PRD).

Od czego zacząć?

Pierwszym etapem przygotowawczym każdego projektu jest kompletowanie wymaganej dokumentacji. W przypadku upgrade’u SAP HR jej źródłem są oczywiście informacje przygotowane przez SAP, na podstawie których tworzymy swój własny, dedykowany scenariusz upgrade’u systemu: dokument procedury upgrade’u (http://service.sap.com/erp-inst) oraz zestaw not SAP dotyczących konkretnej wersji systemu i not specyficznych dla krajowej wersji modułu HR (http://service.sap.com/notes).

Lektura dokumentów SAP jest pomocna przy tworzeniu harmonogramu upgrade’u, który powinien uwzględniać również dodatkowe czynniki, takie jak:

  • warunki techniczne (nowy sprzęt, wymagany upgrade systemu operacyjnego lub bazy danych – te prace warto zaplanować przed rozpoczęciem upgrade’u technicznego),
  • przygotowanie nośników do wykonywania backupów,
  • decyzja, czy możemy stworzyć system QAS (Quality Assurance System) jako kopię systemu produktywnego lub czy możemy nadpisać system DEV danymi systemu PRD,
  • wybór „najlepszego” miesiąca na upgrade systemu produkcyjnego,
  • wskazanie odpowiedniego weekendu na wykonanie upgrade’u technicznego systemu produkcyjnego,
  • zaplanowanie niedostępności systemów,
  • zamrożenie prac rozwojowych.

Doświadczenie wskazuje, że najlepszym terminem na przeprowadzenie upgrade’u systemu produkcyjnego jest czas krótko po ostatnim, a na długo przed kolejnym rozliczeniem listy płac.

Procedura upgrade’u

Obrana ścieżka upgrade’u jest nie tylko wynikiem naszej decyzji, ale przede wszystkim konsekwencją pejzażu systemów SAP wykorzystywanych w naszej instalacji. Zespół projektowy już na wstępnym etapie powinien podjąć decyzję o wykorzystaniu systemu QAS.

Jeśli taki system dotychczas nie istniał, warto rozważyć, czy nie byłoby celowe stworzenie go na czas upgrade’u – jako kopii systemu produkcyjnego. Takie rozwiązanie pozwala na „przećwiczenie” procesu upgrade’u technicznego i tym samym wcześniejsze znalezienie rozwiązań problemów, które możemy napotkać podczas prac w systemie produkcyjnym.

Ważnym czynnikiem jest również zidentyfikowanie „wąskich gardeł” w infrastrukturze, które mogą mieć wpływ na przebieg procesu. Najlepszym przykładem jest tutaj system kopii bezpieczeństwa – w procesie upgrade’u powinniśmy zadbać o backup naszej bazy danych, musimy wziąć pod uwagę czas trwania kopii i jego wpływ na moment startu kolejnych etapów procesu.

Jak widać, liczba czynników, które należy uwzględnić w przygotowaniu i przeprowadzeniu procesu upgrade’u, jest duża, warto więc zwrócić uwagę na szczegółowe udokumentowanie jego etapów. Najlepszą metodą wydaje się stworzenie własnego, dedykowanego dla danego projektu scenariusza, który z racji pełnionej funkcji możemy nazwać „podręcznikiem upgrade’u”.

Według podręcznika

Podręcznik upgrade’u powinien być przewodnikiem zawierającym informacje wymagane do skutecznego przeprowadzenia projektu: od analizy scenariusza z SAP Upgrade Guide, poprzez analizę not dotyczących prowadzonych prac, opis poszczególnych kroków procesu, aż do listy zadań do wykonania po zakończeniu samego procesu upgrade technicznego.

Proces jego tworzenia może polegać na odnotowywaniu przebiegu upgrade’u pierwszego z systemów w pejzażu – zazwyczaj systemu DEV. Upgrade QAS powinien służyć tylko jego ewentualnemu uzupełnieniu.

W procesie aktualizacji systemu PRD podręcznik ma pełnić rolę przewodnika wskazującego, jakie kolejne kroki powinny zostać podjęte, jakich odpowiedzi udzielać w poszczególnych fazach upgrade’u, kiedy i w jaki sposób wykonać jaką czynność, a nawet jakich czasów przetwarzania kolejnych kroków możemy oczekiwać.

A zatem do upgrade’u PRD przystępujemy z już gotowym scenariuszem, uzupełniając go tylko informacjami o godzinie zajścia poszczególnych zdarzeń i podjętych działaniach. W trakcie upgrade’u systemu DEV w podręczniku powinniśmy od razu umieszczać wskazówki dla systemu produkcyjnego, na przykład jakiej odpowiedzi należy udzielić na pytanie programu w danej fazie procesu.

Jednym z krytycznych momentów procesu upgrade’u jest etap dostosowań – zalecamy utworzenie dodatkowego dokumentu zawierającego listę obiektów i opisy wykonanych zmian.

Zmiany, zmiany!

Jak już wspomnieliśmy, dostosowanie zmian obiektów SAP stanowi znaczną część projektu upgrade’u – zazwyczaj 30% czasu przedsięwzięcia. Jest to także element wnoszący ryzyko. Musimy pamiętać o tym, że niektóre zmodyfikowane w danej instalacji obiekty SAP (m.in. tabele, programy, transakcje) mogą mieć zupełnie inną postać w nowej wersji modułu.

W celu oszacowania czasu i kosztu projektu należy przygotować listę rozszerzeń i napraw ze wskazaniem, które z nich mają być również wykorzystywane w nowej wersji. Jeśli zmiany w systemie wykonywane do tej pory były dobrze dokumentowane, skompletowanie takiej listy będzie łatwe. Przy szacowaniu pracochłonności dostosowywania rozszerzeń warto pamiętać o prostym schemacie, który w wielu przypadkach będzie obowiązywać podczas projektu:

  • upgrade techniczny nadpisze zmiany standardowego obiektu,
  • należy „ręcznie” nanieść zmiany i zapisać je w zleceniu transportowym,
  • należy zwolnić transport i przenieść zmiany na system docelowy (po upgradzie tego systemu).

W projekcie upgrade’u podstawowe znaczenie mają testy regresywne. Muszą one odpowiedzieć na pytanie, czy procesy, które były wspierane przez system przed projektem, są poprawnie realizowane w nowej wersji SAP HR (tak jak przed upgradem). Dopiero po testach regresywnych wykonuje się testy akceptacyjne. Testy regresywne mają na celu znalezienie błędów, natomiast testy akceptacyjne nie powinny ich już wykazać.

Ponieważ harmonogram projektu podniesienia wersji jest niezwykle czuły na jakiekolwiek opóźnienia, scenariusze testów powinny być przygotowane z dużym wyprzedzeniem. Warto sięgnąć po dokumentację testów wykorzystywaną podczas wdrożenia modułu HR. Jeśli testy były wtedy przeprowadzane zgodnie z zasadami, wystarczy zaadoptować scenariusze do naszego projektu.

Testy podczas projektu upgrade’u są zdecydowanie łatwiejsze niż te wykonywane w czasie wdrożenia systemu SAP HR. Użytkownicy zaczynają ze znacznie lepszej pozycji:

  • mają już doświadczenie,
  • pracują z danymi rzeczywistymi,
  • porównują „SAP-a z SAP-em”,
  • posługują się sprawdzoną metodyką,
  • mają do dyspozycji mechanizm przeliczeń wstecznych w liście płac.

Upgrade SAP HR jest bez wątpienia wyzwaniem, na którego powodzenie składa się praca całego zespołu wdrożeniowego. Staranne przygotowanie takiego przedsięwzięcia ma kluczowe znaczenie dla sukcesu, więc warto skorzystać z istniejących doświadczeń. Część przydatnej wiedzy jest w zasięgu ręki (procedura upgrade’u, noty, dokumentacja powdrożeniowa).