Analiza przedupgrade’owa SAP

Często odkładany „na później” upgrade SAP do wersji 6.0 w końcu w wielu firmach stał się koniecznością. Bez tego po 31 marca 2013 r. mogłyby one utracić wsparcie producenta, dostęp do aktualizacji i gwarancję bezpieczeństwa systemu. Zmiana strategii firmy SAP i decyzja o cyklicznej publikacji pakietów z aktualizacjami (tzw. Enhancement Packages) zamiast nowych wersji systemu to kolejny dowód na to, że w najbliższych latach nie należy się spodziewać „nowego SAP-a”. A zatem upgrade.

Audyt przed upgradem SAP

Organizacja, która stoi przed podjęciem decyzji o podniesieniu wykorzystywanej wersji systemu SAP do SAP ERP 6.0, powinna zaplanować to zadanie tak samo, jak każdy inny rodzaj projektu – czy to biznesowego, czy też IT.

Oznacza to, że przygotowując wniosek o rozpoczęcie projektu, należy w nim zawrzeć między innymi takie elementy, jak czas jego trwania, harmonogram prac oraz kalkulację kosztów.

Oszacowanie zarówno czasu trwania projektu upgrade’u, jak i jego kosztów to złożone zadanie, zależne od wielu czynników, spośród których tylko część jest oczywista. By wesprzeć klienta w wykonaniu tego zadania – przygotowaniu rzetelnej i wiarygodnej oceny projektu, BCC przygotowało usługę audytu systemu SAP pod kątem jego upgrade’u do wersji ERP 6.0.

Jako efekt końcowy prac audytorskich klient otrzyma:

• szczegółowy harmonogram projektu wraz z wyspecyfikowaniem wszystkich najważniejszych zadań projektowych,
• kalkulację czasu potrzebnego na wykonanie poszczególnych zadań projektowych wraz z budżetami prac,
• wskazanie obiektów, które będą wymagały najbardziej pracochłonnych dostosowań,
• wskazanie pozostałych, nietypowych elementów, na które należy zwrócić uwagę podczas projektu, wraz z propozycją ich obsługi.

Co należy zrobić

Podstawowe zadania podczas projektu upgrade’u koncentrują się na pracach w zakresie Basis, dostosowaniach klienckich rozwiązań i rozszerzeń systemu do nowej wersji i przede wszystkim testach.

Poniżej przedstawiamy – w dużym skrócie – podstawowe kroki wykonywane podczas podnoszenia wersji systemu SAP dla każdego z tych rodzajów zadań (dotyczy wyłącznie systemu rozwojowego DEV).

Prace Basis:

• podniesienie wersji systemu operacyjnego (opcjonalnie), wgranie odpowiednich poprawek w systemie operacyjnym, wykonanie dostosowań parametrów systemu operacyjnego,
• podniesienie wersji bazy danych (opcjonalnie),
• podmiana plików wykonywalnych SAP (tzw. KERNEL),
• podmiana struktur w bazie danych,
• wgranie nowej wersji obiektów ABAP,
• automatyczna podmiana wszystkich niezmienionych standardowych obiektów ABAP na nowe wersje.

Po zakończeniu prac w części Basis mamy ponownie teoretycznie dostępny i działający system SAP w nowej wyższej wersji. Teoretycznie, ponieważ nie jest jeszcze możliwe jego produkcyjne wykorzystanie z powodu braku dostosowania zmienionych obiektów ABAP do ich nowych wersji proponowanych w procedurze upgrade’u technicznego.

Prace w zakresie dostosowań ABAP:

• dostosowanie zmienionych obiektów standardowych (akceptacja nowej wersji obiektu w całości lub jego dostosowanie w celu zachowania zmian klienckich),
• dostosowanie Z/Y obiektów klienckich.

Procedura upgrade’u zamienia zmodyfikowane standardowe obiekty ABAP na ich nowe wersje, pochodzące z nowej wersji systemu. Należy pamiętać o tym, że procedura upgrade’u nie modyfikuje obiektów ABAP stworzonych przez klienta (obiektów w przestrzeni nazw Y i Z lub zarejestrowanej klienckiej przestrzeni nazw).

Zakończenie prac w części ABAP pozwala na rozpoczęcie korzystania z systemu w nowej wersji. Istnieje jeszcze potrzeba dostosowania wybranych wpisów konfiguracyjnych, jest to jednak czynność, która nie stanowi znacznej pozycji w budżecie projektu.

Prace związane z testami nowej wersji systemu (prowadzone już na systemie testowym):

• testy modułowe (poszczególnych funkcji systemu w ramach każdego z modułów osobno),
• testy integracyjne (wzajemnych zależności pomiędzy różnymi modułami systemu, przepływów danych).

Czas potrzebny na wykonanie rzetelnych testów zależy od liczby zmian w standardowej funkcjonalności systemu, liczby interfejsów oraz stopnia skomplikowania procesów.

Na schemacie przedstawiono różnice w pracochłonności związanej z dostosowaniem ustawień konfiguracyjnych oraz obiektów ABAP.

Upgrade SAP – ile to potrwa?

Szacowanie czasu trwania części Basis może być wykonane dość precyzyjnie bez konieczności wykonywania analiz bezpośrednio na systemie SAP. Średnia czasów trwania tej części projektu wynosi około 30 roboczodni (dla pejzażu trzysystemowego) i jest w miarę stała, bez względu na stopień złożoności rozwiązania po stronie funkcjonalnej.

Natomiast jak wynika z powyższego schematu, trudniejsza do oszacowania jest pracochłonność części związanej z dostosowaniami ABAP. W dużej mierze zależy ona od skali oraz jakości wykonanych rozszerzeń standardu. Warto podkreślić, że pod pojęciem jakości rozumiemy nie tylko poprawność kodu programistycznego i logiki aplikacji, ale także stopień udokumentowania zmian, zwłaszcza dla złożonych rozszerzeń.

Oczywiście, czas konieczny na wykonanie dostosowań ABAP rośnie wraz ze wzrostem liczby rozszerzeń i niestandardowych funkcjonalności w systemie klienta. Wzrost ten jednak nie jest liniowy, nie można też zastosować tutaj żadnego wzoru matematycznego. Na ogół stosuje się podejście eksperckie, które po krótkim zapoznaniu się z rozszerzeniami systemu pozwala na przybliżone oszacowanie czasu niezbędnego na przeprowadzenie wszystkich prac. Jednak przy takich szacunkach niezbędne jest doświadczenie z podobnych przedsięwzięć, najlepiej z upgrade’u systemu SAP o porównywalnej wielkości, zakresie funkcjonalnym i stopniu kustomizacji.

Nawet jednak przy dużym doświadczeniu, szacując pracochłonność, trudno ustrzec się pewnego marginesu błędu. W projektach upgrade’u realizowanych w przypadku niedoszacowania budżetu koszty tego błędu ponosi firma realizująca prace, a w przypadku przeszacowania – klient.

Jeśli klient nie chce ponosić takiego ryzyka, możliwy jest także inny model rozliczeń: na podstawie rzeczywistej pracochłonności. Jednak wtedy klient będzie mógł zaplanować czas trwania projektu i jego koszty jedynie szacunkowo.

W tej sytuacji pomocnym rozwiązaniem może być proponowana przez BCC (aktualnie All for One Poland) usługa audytu przedupgrade’owego.

Audyt – materiały wejściowe

Aby rozpocząć prace audytorskie, konieczna jest analiza dokumentacji systemu, zwłaszcza w zakresie specyfikacji rozszerzeń, zarówno tych dokonywanych na standardowych obiektach ABAP, jak i nowo tworzonych obiektów. Dostępność koncepcji wdrożenia w modułach będzie dodatkową pomocą.

Niezbędne jest uzyskanie dostępu do systemu SAP klienta, najlepiej gdyby był to system testowy, będący świeżą kopią systemu produkcyjnego.

W analizie bardzo pomocny jest dokument obrazujący pejzaż systemowy, zwłaszcza przedstawiający w formie graficznej integrację systemu SAP z systemami zewnętrznymi.

Czas trwania audytu

Czas trwania prac audytorskich oraz wielkość zaangażowanego zespołu konsultantów zależy od zakresu używanej funkcjonalności, liczby zmodyfikowanych obiektów ABAP, liczby i stopnia skomplikowania interfejsów do systemów zewnętrznych.

Każdorazowo zespół audytorski w BCC jest dobierany zgodnie z potrzebami. W prace angażowany jest przede wszystkim doświadczony konsultant ABAP (programista), po jednym konsultancie z każdego z wdrożonych modułów oraz konsultant od interfejsów.

Prace audytorskie zwykle trwają od dwóch do trzech tygodni. Dokładny czas trwania, wielkość zespołu oraz koszt audytu zostanie przedstawiony po wstępnej analizie liczby modułów, zakresu wdrożenia, liczby rozszerzeń systemu oraz liczby i rodzaju interfejsów.

Zakres prac

Podczas prac audytorskich analizowane są:

• wszystkie wykonane rozszerzenia systemu, zarówno modyfikacje standardowych obiektów SAP, jak i własnych obiektów klienckich,
• interfejsy z systemami zewnętrznymi oraz interfejsy wewnętrzne,
• koncepcja wdrożeniowa (w przypadku jej braku przeprowadza się wywiad z użytkownikami kluczowymi),
• scenariusze testowe (o ile istnieją),
• konfiguracja systemu (konfiguracja modułowa, zaplanowane zadania w tle).

Typowe rekomendacje

Oprócz harmonogramu i kalkulacji pracochłonności w ramach audytu BCC zwykle przedstawia także listę rekomendacji związanych z organizacją samego projektu upgrade’u oraz zakresem prac, jakie należy wykonać zarówno w odniesieniu do SAP, jak i niejako „przy okazji”.

Konwersja bazy danych do UNICODE

Wymóg konwersji bazy danych do wersji UNICODE nie jest obowiązkowy dla większości instalacji SAP. Jest on uzależniony od wykorzystywanych języków oraz od integracji z aplikacjami webowymi. W wyniku analizy klient otrzyma informację o tym, czy w jego przypadku niezbędna będzie konwersja bazy danych do UNICODE oraz jaki będzie sugerowany scenariusz migracji. Typowe scenariusze to migracja do UNICODE wspólnie z projektem upgrade lub migracja jako osobny projekt (czynnikiem decydującym jest wielkość bazy danych oraz maksymalny czas , w jakim organizacja może sobie pozwolić na niedostępność systemu – konwersja bazy danych do UNICODE może trwać wiele godzin).

Weryfikacja lub stworzenie scenariuszy testowych

Wiemy, że kluczem do prawidłowego i bezpiecznego przeprowadzenia upgrade’u są odpowiednio zorganizowane i przeprowadzone testy funkcjonalne, przeprowadzone w oparciu o scenariusze testowe. Jeżeli klient nie dysponuje gotowymi scenariuszami testowymi, np. pochodzącymi z projektu wdrożenia lub z poprzednich upgrade’ów, to konieczne jest stworzenie takich scenariuszy w ramach projektu upgrade.

Z naszych doświadczeń wynika, że tworzone pod presją czasu w fazie koncepcji upgrade’u scenariusze nie zawierają wszystkich najważniejszych przypadków koniunkcji danych, wariantów procesów czy też kompleksowych przepływów informacji przez interfejsy. Testy przeprowadzone na tak przygotowanych scenariuszach mogą stanowić zagrożenie dla produkcyjnego uruchomienia systemu w nowej wersji.

Zaleca się zatem odpowiednio wczesne przygotowanie scenariuszy testowych, na długo przed rozpoczęciem projektu. Niezbędne jest również przeprowadzenie testów systemu za pomocą scenariuszy. Podczas projektu scenariusze powinny być zweryfikowane oraz ewentualnie uzupełnione.

Dostosowanie kodu ABAP do zgodności z UNICODE

Krokiem nieobowiązkowym w procedurze upgrade’u (w przypadku braku konwersji bazy danych do UNICODE) jest przeprowadzenie dostosowania klienckich programów do zgodności z systemem UNICODE (tzw. UNICODE compliance check).

Zalecane jest jednak, aby wykonać wszystkie dostosowania, które zostaną wskazane w raporcie UCCHECK, co pozwoli zmniejszyć pracochłonność konwersji na UNICODE oraz, co ważniejsze, uniknąć problemów z wybranymi specyficznymi przypadkami zmiany działania standardowych poleceń ABAP. Ich wykrycie na etapie standardowej obsługi dostosowań ABAP (transakcja SPAU) jest trudne, a jeżeli testy nie były prowadzone w sposób kompleksowy, to błędy ujawniają się dopiero podczas pracy produkcyjnej.

Przykład – czyli jak uniknąć pułapek

Poniżej przedstawiamy przykładową sytuację, w której brak pełnego dostosowania wszystkich obiektów ABAP do zgodności z UNICODE oraz równoległy brak pełnego testu interfejsu mógł spowodować przestój produkcyjny.

Schemat przebiegu procesu: Z systemu zewnętrznego przysyłany jest plik zawierający informacje awiza dostawy przychodzącej (krok 1). Plik ten jest cyklicznie odczytywany przez odpowiedni moduł funkcyjny (krok 2), który tworzy IDOC-ki (krok 3). Następnie plik jest kasowany, co umożliwia odebranie kolejnej porcji informacji z systemu zewnętrznego w przyszłości. W kolejnym kroku (IDOC jest przetwarzany za pomocą standardowego modułu funkcyjnego tworząc dostawę przychodzącą (krok 4).

Jak wyglądały testy: Podczas testów zrezygnowano jednak z przeprowadzenia kroków 1-3 (test samego interfejsu: mechanizm zaczytywania pliku i tworzenia IDOC-ka) ponieważ stwierdzono, że wystarczy przetestować zachowanie się systemu od momentu przetwarzania gotowego IDOC-ka. Skupiono się wyłącznie na aspekcie funkcjonalnym procesu, pomijając część techniczną.

W efekcie po uruchomieniu produkcyjnym pierwsze automatyczne odczytanie zawartości pliku zakończyło się zrzutem. Powodem był fakt, że w wersji 6.0 aby poprawnie odczytać zawartość pliku, konieczne jest podczas otwierania pliku poleceniem „open dataset” wskazanie rodzaju kodowania znaków.

Policzalny i przewidywalny

Powyższy przykład obrazuje, jakie pułapki można napotkać podczas upgrade’u. Jeśli nawet są to z pozoru drobne zdarzenia, to wystarczy kilka takich niewielkich niepowodzeń, by założony harmonogram prac okazał się niemożliwy do dotrzymania. Analiza przed upgradem pozwoli zmniejszyć ich wpływ na projekt, czyniąc go bardziej policzalnym i przewidywalnym.

Podniesienie wersji systemu to z punktu widzenia użytkowników „dziwny” projekt, bo całe to poruszenie nie wiąże się z dostępem do nowych funkcjonalności, ulepszeniami czy ułatwieniami w pracy. Przynajmniej nie tuż po starcie. Jest to  jednak duże wyzwanie dla administratorów IT/SAP i użytkowników kluczowych, bezpośrednio zaangażowanych w projekt.

Pół roku prac projektowych – bo tyle trwa średnio upgrade SAP do wersji 6.0 – warto poprzedzić dwu-trzytygodniowym audytem, by móc się lepiej przygotować, przewidzieć trudności, wytypować prace, które warto wykonać jeszcze przez rozpoczęciem upgrade’u, doprecyzować zakres (np. migrować do UNICODE czy też nie lub w innym terminie), wybrać optymalny czas na projekt.

Rzetelny i kompetentny przegląd systemy wymaga dużego doświadczenia. Nasi konsultanci, którzy mają na koncie kilkanaście tego typu projektów, są w stanie z dużą dozą dokładności oszacować pracochłonność i budżet projektu. W firmach, które zdecydują się na upgrade z BCC analiza przed projektem stanowi część oferty, a jej wnioski są podstawą koncepcji projektu.