Jak podnieść system SAP do wersji ECC 6.0?

Dlaczego ponosić koszty, skoro wszystko działa?

SAP jest narzędziem służącym do wspierania realizacji celów strategicznych przedsiębiorstwa. Jego posiadanie nie jest wyznacznikiem prestiżu. Oczekujemy od niego określonego sposobu działania – sprawnego i bezawaryjnego.

Można się pokusić o analogię do motoryzacji. Wielu miłośników starych samochodów chciałoby mieć w swoim garażu egzemplarz słynnego forda T. Jednak dziś nie jesteśmy w stanie tym samochodem dojeżdżać do pracy, odwozić dzieci do szkoły czy wyjechać na wakacje. Nie mamy nawet takich oczekiwań. Na co dzień potrzebujemy auta sprawnego, z ważnym przeglądem rejestracyjnym, chcemy też być pewni, że w razie awarii znajdziemy warsztat, w którym go naprawią.

Podobnie jest z SAP. Musimy go utrzymać w ruchu, ponieważ jest niezbędny w przedsiębiorstwie. Każda awaria, której nie będzie można szybko naprawić, wiąże się z kosztami bądź utratą przychodów. Dlatego podobnie jak samochód, tak i system SAP musi podlegać okresowej „wymianie” (upgrade’owi).

W świecie systemów informatycznych przestrzega się zasady: „Never touch a running system”. Dlaczego zatem decydować się na upgrade – podniesienie wersji – skoro system działa poprawnie i jesteśmy zadowoleni z jego konfiguracji i wydajności? Nie planujemy też wykorzystywać funkcjonalności, które otrzymamy wraz z nową wersją. Czyżby same koszty bez korzyści?

Jednak świat systemów informatycznych galopuje nawet szybciej niż motoryzacja i dzisiaj nikt już nie używa komputerów pracujących pod kontrolą systemu operacyjnego DOS. Coraz trudniej też znaleźć na rynku kompetencje w zakresie tego systemu.

Również system SAP w starszych wersjach nie posiada już wsparcia producenta – SAP AG, co oznacza, że ewentualne błędy nie są na bieżąco naprawiane. Nie są też publikowane aktualizacje starszych wersji. Kolejne wersje systemu SAP przestają być wspierane średnio co pięć lat.

Aby mieć gwarancję ciągłości nieprzerwanej pracy i serwisu systemu, należy zawsze używać tej jego wersji, która jest wspierana przez producenta. To główny powód, dla którego firmy decydują się na przeprowadzenie upgrade’u. Do pozostałych można zaliczyć:

• chęć wdrożenia funkcjonalności dostępnych wyłącznie w nowej wersji,
• zmniejszenie kosztów utrzymania systemu (większa dostępność serwisu do aktualnych wersji systemu),
• chęć wykorzystania nowych technologii, np. umożliwiających łatwą integrację z systemami zewnętrznymi za pośrednictwem SAP PI,
• decyzję korporacji, której przedsiębiorstwo jest częścią, o unifikacji pejzażu systemowego.

Na czym polega upgrade do wersji ECC 6.0

Konwencjonalny upgrade SAP ERP do najnowszej wersji ECC 6.0 jest związany z szeregiem działań technicznych, funkcjonalnych i organizacyjnych. W przypadku dużej firmy i rozbudowanej instalacji SAP taki projekt trwa kilka miesięcy i w istotnym stopniu angażuje zasoby wewnętrzne przedsiębiorstwa.

Główne elementy projektu upgrade’u to:

• techniczne podniesienie wersji systemu,
• dostosowania ABAP i konfiguracji,
• testy.

Techniczne podniesienie systemu polega na:

• dopasowaniu mocy obliczeniowej serwerów do wymagań nowej wersji systemu SAP,
• zaktualizowaniu wersji, poziomu patchy systemu operacyjnego,
• podniesieniu wersji bądź aktualizacji patchy bazy danych,
• podniesieniu wersji systemu SAP, podzielonego na cztery fazy.

Po wykonaniu tej części upgrade’u dysponujemy, z punktu widzenia technicznego, w pełni sprawnym systemem w wersji 6.0. Jednakże jego funkcjonalności biznesowe nie działają jeszcze w pełni, ponieważ zmienione nową wersją systemu programy wymagają dostosowania.

W tym celu przeprowadza się kolejną fazę projektu – dostosowania ABAP i konfiguracji. Wszystkie obiekty ABAP (programy, moduły funkcyjne, formularze, raporty itd.), które zostały nadpisane przez procedurę upgrade’u, a wcześniej były modyfikowane poprzez wgranie not lub bezpośrednio przez użytkownika, muszą zostać dostosowane.

Kolejnym zadaniem jest sprawdzenie zgodności składni kodu wszystkich programów z wymaganiami UNICODE (jest to wymagane w wersji ECC 6.0). W pewnych przypadkach niezbędne jest również dostosowanie konfiguracji systemu w wybranych modułach.

Kolejnym etapem upgrade’u, angażującym największy zespół osób, są testy. To na nich skupia się główny ciężar prac w projekcie. Poprzednie dwie fazy projektu służą głównie zapewnieniu sprawnego przeprowadzenia testów. Wykonane liczne scenariusze testowe muszą nas upewnić, że procesy, które system realizował poprzednio, także w nowej wersji są wykonywane bezbłędnie.

Role autoryzacji praktycznie nie wymagają dostosowań. Wszystkie używane w poprzednich wersjach transakcje i obiekty uprawnień nadal działają w wersji 6.0. W niektórych przypadkach, gdy jedna transakcja wywołuje w tle drugą, której symbol zmienił się w nowej wersji, możemy mieć do czynienia z brakiem uprawnień. Taki przypadek zostanie wykryty podczas testów modułowych.

Czy za pięć lat czeka nas kolejny upgrade? Czyli co to jest EHP

Aby wprowadzanie na rynek kolejnych wersji systemu nie musiało wiązać się z dużym projektem upgrade’u, od 2006 r. SAP AG wprowadził tzw. enhancement packages (EHP), które mają zastąpić konwencjonalne upgrade’y. Każdy pakiet EHP jest opcjonalnym zbiorem nowych funkcjonalności systemu, który może być niezależnie aktywowany, bez konieczności wykonywania upgrade’u technicznego.

Obecnie dla użytkowników systemu w wersji ECC 6.0 dostępna jest już czwarta wersja EHP. Warunkiem zainstalowania i aktywacji pakietu EHP jest system SAP w wersji ECC 6.0. Jeśli więc firma korzysta ze starszej wersji, należy najpierw podnieść system do ECC 6.0.

Niezależnie od aktywacji EHP, jako stały element utrzymania systemu należy instalować kolejne Support Packages, które w odróżnieniu od pakietów EHP będą zawierały wyłącznie poprawki już istniejących funkcjonalności (łaty).

Wraz z pakietem EHP SAP dostarcza wzorce testowe dla każdej z zawartych w nim funkcjonalności. Funkcjonalności znajdujące się w aktywowanej części są hermetyczne i testy aktywacji mogą się ograniczać wyłącznie do okrojonego zbioru testów modułowych i/lub integracyjnych.

Warto dodać, że każdy pakiet EHP zawiera wszystkie funkcjonalności udostępnione w poprzednich. Zatem instalując najnowszy pakiet nr 4, mamy jednocześnie gotowe do aktywacji wszystkie funkcjonalności z pakietów od 1 do 3. Nie ma konieczności instalacji i/lub aktywacji poprzednich, aby zainstalować najnowszy pakiet.

Jak się przygotować do upgrade’u, by zmniejszyć jego koszt i zwiększyć bezpieczeństwo

Przede wszystkim upgrade systemu nie jest jednoznaczny z jego rozwojem. W większości projektów jest on traktowany jako techniczne podniesienie wersji systemu i tym samym uzyskanie dostępu do nowych funkcjonalności, ale bez ich aktywacji i konfiguracji.

Dopiero w drugim kroku, po ustabilizowaniu się systemu w nowej wersji, przychodzi czas na wdrażanie funkcji dostępnych w ECC 6.0. Takie podejście rekomenduje BCC (aktualnie All for One Poland).

Planując upgrade, należy się skupić jedynie na wymaganym technologicznie i konstrukcyjnie zakresie prac, bez uruchamiania dodatkowych funkcjonalności. Tak by projekt trwał możliwie jak najkrócej.

Należy tak postąpić nawet w wypadku, gdy nowa wersja nie wspiera już wybranych rozwiązań (np. stary rejestr VAT, program płatności itd.). Sprawdzonym podejściem, dzięki któremu można uniknąć wielu problemów, jest używanie starych rozwiązań do momentu pierwszego produktywnego zamknięcia miesiąca.

W przeważającej większości przypadków podnosimy „żywy” system, wykorzystywany produkcyjnie w firmie. Oczekujemy zatem, że wiedza użytkowników kluczowych o przebiegu procesów jest wystarczająca do przeprowadzenia testów systemu w nowej wersji. Jeżeli jednak mamy jakiekolwiek wątpliwości co do kompetencji zespołu roboczego (np. wielu użytkowników od niedawna pracuje z systemem), należy rozważyć przeprowadzenie szkoleń wstępnych z działania systemu w obecnej wersji.

Jeżeli mamy pewność, że użytkownicy kluczowi wystarczająco dobrze znają procesy w firmie oraz potrafią je wykonywać za pomocą SAP, to szkolenia zarówno wstępne z różnic między funkcjonalnościami, jak i szkolenia użytkowników kluczowych i końcowych w fazie 4 projektu nie są praktycznie potrzebne. W związku ze zmianą wyglądu ekranów w pewnych przypadkach konieczna będzie natomiast aktualizacja instrukcji stanowiskowych.

Podział zadań i kompetencji pomiędzy poszczególnych uczestników projektu musi być dla wszystkich jasny z chwilą przystąpienia do prac. Osoby uczestniczące w projekcie ze względu na rodzaj wykonywanych zadań można podzielić na dwie grupy:

• techniczną: zespół basis i programiści,
• funkcjonalną: użytkownicy kluczowi i konsultanci.

Jeszcze przed rozpoczęciem projektu należy przeprowadzić ewentualną wymianę i modernizację sprzętu (serwery i stacje robocze) oraz zainstalować najnowszą wersję SAP GUI. Nie należy z tym zwlekać, aby prace sprzętowe nie zakłócały harmonogramu prac upgrade’owych.

Należy pamiętać, że po podniesieniu wersji systemu rozwojowego nie będzie możliwości przenoszenia zmian (programistycznych i konfiguracyjnych) na systemy testowy i produkcyjny. Istotne jest zatem takie zaplanowanie harmonogramu, by podczas upgrade’u nie były prowadzone żadne prace rozwojowe. Nie zaleca się także prowadzenia prac rozwojowych na systemach zinterfejsowanych z SAP.

Jednoczesne zmiany w dwóch komunikujących się ze sobą systemach mogą doprowadzić do sytuacji, że w wypadku błędów trudno dociec, co jest ich przyczyną – czy zmiany związane z upgradem, czy też zmiany w systemie zewnętrznym. Odnalezienie błędów i ich usunięcie może być bardzo czasochłonne.

Zasadą jest, że podczas projektu nie naprawiamy funkcjonalności, które nie działały poprawnie przed upgradem. Wyjątkiem są sytuacje, gdy nowa wersja dostarcza rozwiązanie problemu niejako „z dobrodziejstwem inwentarza”.

Środowisko trzysystemowe

Zalecamy, aby upgrade przeprowadzać w środowisku trzysystemowym (systemy rozwojowy, testowy i produkcyjny, DEV-QA-PRD). Jeżeli obecnie w firmie wykorzystywane jest środowisko dwusystemowe (DEV-PRD), instalacja dodatkowego systemu testowego znacznie zwiększy bezpieczeństwo upgrade’u systemu produkcyjnego.

System QA powinien być „świeżą” kopią systemu PRD. Podnosząc wersję QA, wykonujemy niejako testowe podniesienie wersji systemu PRD. Wszystkie kroki tej operacji powinny być rejestrowane i w identycznej kolejności odtworzone podczas podnoszenia wersji systemu PRD. Zatem upgrade systemu QA będzie niejako symulacją startu produkcyjnego.

Jeśli wszystkie powiązania międzymodułowe w starej wersji systemu działają poprawnie (a tych niedziałających poprawnie nie naprawiamy podczas upgrade’u), istnieje bardzo niewielkie prawdopodobieństwo, że po podniesieniu wersji do 6.0 przestaną one działać prawidłowo. Dlatego około 70% całkowitego czasu testów należy poświęcić na testy modułowe, pozostałe 30% na testy integracyjne.

Z założenia w projekcie nie przewidujemy istnienia osobnego zespołu ds. interfejsów. Każdy interfejs jest bowiem elementem procesu biznesowego, dlatego też testy procesów/funkcji (nawet testy modułowe) muszą zawierać elementy interfejsów. Należy krok po kroku sprawdzić działanie wszystkich interfejsów, jednak nie w oderwaniu od procesu biznesowego. W skład zespołów roboczych powinny oczywiście wchodzić osoby z kompetencjami w zakresie platform integracyjnych (o ile są wykorzystywane).

Dokumentacja – gromadź, lecz nie ufaj bezgranicznie

Przygotowując się do projektu upgrade, należy zgromadzić dokumentację systemu w jego obecnym kształcie. Cenne będą aktualne koncepcje wdrożenia, scenariusze testowe oraz specyfikacje rozszerzeń (zwłaszcza interfejsów oraz user-exitów).

Dobrą zasadą jest ograniczone zaufanie do dokumentacji historycznej. Należy liczyć się z tym, że może być nieaktualna, zwłaszcza w zakresie specyfikacji funkcjonalnych.

Dokumentacja ta będzie służyła jako punkt wyjścia przy opracowywaniu koncepcji upgrade’u i tworzeniu scenariuszy testowych. Dodatkowo specyfikacje rozszerzeń pomogą przy dostosowywaniu programów oraz rozwiązywaniu potencjalnych problemów przy testach systemu w nowej wersji.

Start produktywny, czyli praca w weekend

Data startu produkcyjnego nie powinna się zbiegać z największym obciążeniem systemu pracami (np. zamknięcie miesiąca). Najodpowiedniejszy czas na start produkcyjny to okres od 12 do 20 dnia miesiąca. Ponieważ system jest cały czas wykorzystywany produkcyjnie, najodpowiedniejszym momentem na start jest weekend, gdy zalogowanych jest najmniej użytkowników.

Procedura upgrade’u technicznego trwa zwykle kilkanaście godzin, po czym następuje zasilenie systemu transportami dostosowań oraz ostatnie testy. Zazwyczaj rozpoczęcie procedury planuje się na piątek, gdy następuje zmniejszenie obciążenia systemu (godziny popołudniowe), w sobotę trwają prace techniczne i transporty, a w niedzielę następuje ostateczna weryfikacja poprawności działania systemu.

Koniec prac należy zaplanować na niedzielne południe, aby w wypadku niepowodzenia mieć bufor czasowy na odtworzenie systemu w starej wersji. Podczas całego weekendu upgrade’owego nie będzie możliwości produkcyjnego wykorzystania systemu.

Nie wyważaj otwartych drzwi

Z doświadczeń BCC  z przeprowadzonych licznych projektów tego typu wynika, że upgrade’y prowadzone w sposób uporządkowany są projektami niskiego ryzyka. Podczas realizacji, podobnie jak w przypadku klasycznego wdrożenia, istotne jest przestrzeganie zasad i reguł opisanych w metodyce upgrade’u. Takie podejście zapewni sukces projektu.

Tu rodzi się ważne pytanie – po co angażować do jego przeprowadzenia firmę konsultingową? Niektóre firmy z rozbudowanymi kompetencjami technicznymi w zakresie Basis i ABAP tego nie robią, wykonując upgrade we własnym zakresie. Warto jednak pamiętać, że dla przedsiębiorstwa korzystającego z SAP upgrade do ECC 6.0 to przedsięwzięcie robione „raz w życiu”. Firma konsultingowa, dla której tego typu projekty to chleb powszedni, wnosi do projektu best practices z wcześniejszych prac.

Podział zadań pomiędzy obie strony może być różny i wynikać z pełnionych ról oraz poziomu kompetencji technicznych klienta. Typowe zadania wykonywane przez firmę konsultingową to:

• dostarczenie wzorców dokumentów projektowych (koncepcji, scenariuszy testowych),
• współpraca przy tworzeniu koncepcji i scenariuszy testowych,
• techniczne podniesienie wersji systemu, bazy danych dla całego pejzażu systemowego,
• dostosowania ABAP we wszystkich lub wybranych modułach (w zależności od kompetencji zespołu programistów klienta),
• współudział i nadzór nad testami systemu, modułowymi i integracyjnymi,
• przygotowanie systemu produkcyjnego do pracy,
• wsparcie po starcie produkcyjnym.