Doświadczenia klientów z upgrade’ów do SAP ECC 6.0

Zwykle do realizacji upgrade SAP zatrudnia się profesjonalną i doświadczoną firmę konsultingową, która mając odpowiednie kwalifikacje, wykonuje większość zadań technicznych. Jednak – podobnie jak w innych typach projektów SAP – duża część pracy pozostaje do wykonania po stronie firmy-użytkownika systemu. Od połowy 2006 roku – od kiedy to SAP AG udostępnił wersję SAP ECC 6.0, BCC (aktualnie All for One Poland) wspierała liczne takie projekty. Poniżej przedstawiamy doświadczenia kierowników projektów i uczestników upgrade’ów z firm, które są już „po”. Mamy nadzieję, że będzie to ciekawa i pouczająca lektura dla tych, którzy jeszcze są „przed”. A pomysły, przestrogi i porady będzie można wykorzystać, by zaplanowany upgrade do ECC 6.0 przebiegł płynnie i bez przykrych niespodzianek.

Piątek, trzynastego w Kulczyk Tradex

Pierwsza w dziejach Kulczyk Tradex instalacja systemu SAP miała miejsce w czerwcu 2003 r. Ponad pół roku przed startem produkcyjnym konsultanci BCC (aktualnie All for One Poland) utworzyli na naszych serwerach dwusystemowy pejzaż oparty na zalecanej wówczas wersji 4.6c. Zgodnie z ogłoszonym przez firmę SAP „Kalendarzem wsparcia wersji” powinniśmy móc z niej korzystać co najmniej przez najbliższe pięć-sześć lat. I rzeczywiście, system pomyślnie przetrwał start produkcyjny, powdrożeniowe modyfikacje i uzupełnienia, a nawet aktualizację kolejnymi Support Package’ami. Od początku 2004 r. SAP obsługiwał całość procesów związanych ze sprzedażą, dystrybucją i gospodarką magazynową samochodami (SD, MM, WM), a także wszystkie procesy w obszarze FI, AA, TR i CO.

Do implementacji w SAP pozostawał jednak jeszcze drugi kluczowy obszar biznesowy, czyli sprzedaż, dystrybucja i gospodarka magazynowa częściami zamiennymi i akcesoriami do samochodów. Duża złożoność procesów zachodzących w tym obszarze, restrykcyjne wymagania dotyczące czasu przetwarzania danych (dziennie wydawanych jest ok. 10 tysięcy pozycji magazynowych), a także pewne względy organizacyjne spowodowały, że wdrożenie SAP w tym obszarze zostało zaplanowane dopiero kilka lat po starcie „samochodów”.

Z punktu widzenia funkcji dostępnych w systemie nie spodziewaliśmy się, że nowa wersja SAP zaoferuje nam gotowe rozwiązania dostosowane do naszej specyfiki. Spodziewaliśmy się natomiast dużego, a nawet bardzo dużego wzrostu obciążenia systemu po starcie „części” i obawialiśmy się problemów wydajnościowych. To oraz dobiegający końca okres wsparcia zarówno dla SAP 4.6c, jak i bazy danych SQL 2000 Microsoft skłoniły nas do podjęcia decyzji, że „zerowym” etapem wdrożenia SAP dla części zamiennych będzie projekt upgrade’u: wymiana sprzętu, upgrade bazy danych oraz upgrade systemu SAP.

Liczne dyskusje z konsultantami BCC zaowocowały rozpisanym na siedem miesięcy szczegółowym harmonogramem działań. Rozpoczęliśmy od zamówienia nowego serwera dla systemu produktywnego, upgrade’u bazy danych i systemu testowego SAP oraz powołania do życia nowego systemu – zapewnienia jakości, który rozpoczął swoje istnienie jako kopia systemu produktywnego. Na tym systemie testowane były wszystkie dostosowania i modyfikacje.

Testy prowadzone były przede wszystkim przez członków zespołów roboczych – odświeżonych po kilku latach od startu produkcyjnego, uzupełnionych o „świeżą krew” i świetnie orientujących się w przebiegu procesów biznesowych. Właściwy dobór i sprawne zarządzanie zespołami roboczymi oraz ich efektywna współpraca z konsultantami BCC i programistami KT były w naszej ocenie jednym z kluczowych czynników sukcesu przedsięwzięcia. Jednocześnie osiągnęliśmy też efekt „zbliżenia z SAP” wielu osób, które dotąd nie darzyły systemu szczególną estymą.

Wśród współpracujących z SAP rozwiązań kluczowe dla naszej działalności biznesowej znaczenie miały Business Connector i Internet Transaction Server. Oba działały w takich wersjach, w jakich zostały zainstalowane w 2003 r., i nie były już oficjalnie wspierane. Nie chcieliśmy ryzykować jednoczesnych zmian w kilku systemach, nie mogliśmy też ich upgrade’ować do SAP XI czy Enterprise Portal przed upgradem SAP. Jednak przeprowadzone testy wykazały, że wykorzystywane przez nie mechanizmy komunikacji nadal działają w ECC 6.0 i możemy pozostać przy starych wersjach. Musieliśmy też zapewnić nieprzerwaną i poprawną komunikację z hurtowniami danych, ale ponieważ odbywała się tu komunikacja SAP – SAP, nie spodziewaliśmy się większych problemów.

Upgrade systemu na stanowiskach roboczych użytkowników widoczny był przede wszystkim w postaci nowego SAP GUI 7.10. Ponieważ wszystkie systemy, pomimo zachodzących w nich zmian, zachowywały swoje nazwy i adresy, w konfiguracji GUI nie musiały być wykonywane żadne zmiany.

Większość dostępnej literatury i prezentacji sugerowała, że w odróżnieniu od wersji 4.6c, SAP w wersji ECC 6.0 może pracować jedynie w wersji Unicode. Oprócz niepożądanego efektu „rozdęcia” bazy danych, zmiana ta wymagałaby czasochłonnego przejrzenia wszystkich programów stworzonych przez naszych programistów – operacje na łańcuchach znakowych są wszak bardzo częste. Na szczęście okazało się, że nie jest to wymóg bezwzględny i możliwy jest upgrade systemu bez konwersji do Unicode. I przy tym rozwiązaniu pozostaliśmy.

Pomyślnie zakończone testy pozwoliły na dotrzymanie zaplanowanego terminu rozpoczęcia upgrade’u systemu produktywnego – a był nim piątek, 13 czerwca, godz. 13… Wbrew obiegowej opinii, dzień okazał się bardzo pomyślny. Zarówno upgrade techniczny, jak i wgrywanie dostosowań zostały wykonane przez konsultantów BCC bardzo sprawnie i już w niedzielę rano zespoły robocze mogły przystąpić sprawdzania poprawności działania procesów biznesowych w nowej rzeczywistości systemowej.

Biorąc pod uwagę złożoność przeprowadzonego przedsięwzięcia, trzeba stwierdzić, że upgrade zakończył się całkowitym sukcesem. Kilka drobnych problemów, które ujawniły się po rozpoczęciu produktywnej pracy w nowym systemie, zostało stosunkowo szybko rozwiązanych. Ani przez chwilę nie istniało zagrożenie dla normalnego funkcjonowania firmy. Pojawił się wszakże jeden problem, wydawało by się zupełnie banalny – wysyłanie poczty elektronicznej poprzez Exchange Connector do wielu odbiorców podczas tworzenia zamówienia zakupu – który okazał się całkowicie odporny na wszelkie próby rozwiązania go, zarówno przez nas, BCC (aktualnie All for One Poland), jak i SAP. Do jednego odbiorcy – proszę bardzo, ale nie do wielu…

Ale to jeszcze nie był koniec projektu – po kilku tygodniach przeznaczonych na stabilizację systemu i ewentualne poprawki przystąpiliśmy do jego ostatniej fazy – migracji do wersji x64. Nowy sprzęt wyposażony był w dużą ilość pamięci RAM, ale jej obsługa w 32-bitowym systemie Microsoft Windows pozostawiała wiele do życzenia. Doszło do tego, że aby zapewnić efektywne działanie systemu produktywnego, musieliśmy usunąć z niego 4 GB pamięci – i to rzeczywiście pomogło. Przeprowadzone w lipcu i sierpniu migracje kolejnych systemów do wersji 64-bitowej rozwiązały te problemy. Pamięć w serwerach została uzupełniona, a ich działanie zdecydowanie się ustabilizowało.

Wojciech Czombik, Koordynator ds. Oprogramowania, Kulczyk Tradex, KPI Business Services

Z aptekarską precyzją w GSK

Drugiego lutego 2010 r. o godz. 6 w GlaxoSmithKline Pharmaceuticals SA w Poznaniu miał miejsce start produkcyjny nowej wersji systemu SAP ERP ECC 6.0. Działania upgradowe były prowadzone w ramach dostosowania poznańskiej fabryki do ogłoszonych w 2008 r. globalnych priorytetów strategicznych GSK. Nowe rozwiązania systemowe mają przełożyć się na oszczędności i usprawnienia procesów w przedsiębiorstwie.

Był to jeden z większych projektów informatycznych zrealizowanych w GlaxoSmithKline w Polsce w ostatnich latach. Pierwsza faza projektu rozpoczęła się w styczniu 2009 r. W rezultacie podjętych działań dotychczas używaną wersję SAP R/3 4.6c zastąpiła wersja SAP ECC 6.0.

Wprowadzane zmiany dotyczyły jądra technicznego oraz wszystkich modułów systemu, w tym m.in. finansów, gospodarki materiałowej, sprzedaży, zarządzania jakością czy planowania produkcji. Projekt zakładał również konwersję systemu do międzynarodowego standardu kodowania znaków Unicode. Łącznie z konsultantami zewnętrznymi w przedsięwzięciu uczestniczyło ponad 90 osób.

W moim odczuciu kluczem do sukcesu w tym projekcie były takie czynniki jak:

• Odpowiednio duży bufor czasowy w projekcie – dodatkowe 10% czasu pierwotnie planowanego na projekt.
• Duże zaangażowanie członków zespołu projektowego, zadbanie o znakomitą atmosferę współpracy w zespole.
• Podchodzenie ze spokojem do tzw. wyzwań – skupienie się na rozwiązywaniu tematów po kolei, od najważniejszych po mniej ważne.
• Wyznaczony, nieprzesuwalny termin startu wynikający z lokalnych uwarunkowań biznesowych i okna czasowego dostępnego na upgrade systemu produkcyjnego.
• Właściwe motywowanie członków zespołu projektowego.
• Profesjonalizm specjalistów SAP Basis, gwarantujący skuteczność i terminowość prac upgrade’owych, co jest szczególnie istotne w krytycznym momencie, kiedy przez kilka dni firma nie pracuje z powodu braku dostępu do kluczowego systemu.
• Dodatkowy, próbny upgrade systemu produkcyjnego w trybie 24 godz. na dobę – umożliwiający precyzyjne oszacowanie czasu, jaki będzie potrzebny podczas właściwego upgrade systemu produkcyjnego.
• Decyzyjny Komitet Sterujący, do którego zawsze można się zwrócić o wsparcie.
• Dobra, oparta na zaufaniu współpraca z Kierownikiem Projektu po stronie dostawcy.
• Nieformalne testy instancji DEV, prowadzone przez doświadczonych użytkowników systemu, ograniczające do minimum błędy napotkane podczas formalnych testów akceptacyjnych QA.
• Wysokie kompetencje osób zaangażowanych w testy – dzięki temu testowanie odbyło się sprawnie, a system został dokładnie przetestowany, co ograniczyło liczbę incydentów po starcie systemu (w naszym przypadku można je było dosłownie policzyć na palcach jednej ręki).
• Oddelegowanie na 100% kierownika projektu po stronie GSK.

Kierownikom projektu, którzy pierwszy raz mają do czynienia z tego typu przedsięwzięciem, polecam książkę „Managing SAP ERP 6.0 Upgrade Project” wydawnictwa SAP Press.

Pozostawienie koordynacji działań komunikacyjnych na zewnątrz firmy działowi Public Relations.

Żabka pierwsza w Polsce

Żabka Polska jako pierwsza firma w Polsce wykonała upgrade SAP do wersji ECC 6.0, już kilka miesięcy po udostępnieniu tej wersji.

Naturalną konsekwencją upływu czasu są ruchy kadrowe w firmach, a projekt upgrade’u SAP wymaga dużej wiedzy merytorycznej w każdym z aktualizowanych modułów. Dlatego też przed przystąpieniem do prac projektowych warto zrewidować zasoby personalne w ramach poszczególnych modułów SAP i gruntowne przeszkolić nowych użytkowników kluczowych, zwłaszcza jeśli projekt wdrożenia systemu odbył się wiele lat wcześniej.

W ramach przygotowań do projektu należy też wykonać sizing platformy sprzętowo-programowej pod kątem upgrade’u systemu SAP do wersji ECC. W Żabce reorganizacja i modernizacja obejmowała przeniesienie bazy danych na wydajniejszą macierz oraz dodanie dodatkowego serwera do istniejącej konstelacji serwerowej SAP. Oprócz upgrade’u systemu SAP zaktualizowaliśmy bazę danych Oracle do wersji 10g, dzięki temu wszystkie składowe naszego najważniejszego systemu mają obecnie długoletni support.

Metodyka wykonywania upgrade’ów zaleca „zamrożenie” na czas projektu prac rozwojowych, jednak w naszym przypadku wskutek uwarunkowań biznesowych nie było to możliwe. Dlatego opracowaliśmy specjalną procedurę postępowania w wypadku modyfikacji systemu produktywnego w trakcie projektu.

Najważniejszym elementem projektu upgrade’u jest właściwe przygotowanie i przeprowadzenie upgrade’u technicznego. Zaplanowanie i rzetelne wykonanie testów biznesowych i kontroli technicznych w SAP po upgradzie pozwala wykryć i usunąć potencjalne nieprawidłowości.

Opis wszystkich czynności technicznych i obsługi okoliczności, które mogą wystąpić w trakcie upgrade’u, powinien się znaleźć w podręczniku upgrade’u. Nasz podręcznik był kompilacją wymagań producenta systemu, doświadczeń konsultantów technicznych BCC z innych projektów oraz zbieranych w trakcie upgrade’ów systemów rozwojowego i testowego, wchodzących w skład pejzażu SAP w Żabka Polska.

Warto mieć plan awaryjny. Choć nie musieliśmy z niego korzystać, mieliśmy gotowy scenariusz No GoLive – zestaw kroków i koniecznych zasobów do przywrócenia wersji źródłowej systemu (sprzed upgrade’u) na wypadek odrzucenia systemu w testach.

Równie ważne jak czynności techniczne są także zaufanie, ścisła współpraca i wymiana informacji pomiędzy członkami zespołów projektowych, koordynowana przez użytkowników kluczowych i konsultantów wiodących w modułach SAP oraz przez kierowników projektu. To w dużej mierze decyduje o sukcesie projektu.

Opinie zebrała: Mirosława Huk