PL EN DE
Najlepsze praktyki zarządzania usługami SAP

Dedykowana organizacja serwisowa SNP zapewnia jakość i ciągłość obsługi kontraktów SAP Managed Services. Pracujemy w oparciu o standardy ISO 20000 i ISO 27001. Posiadamy certyfikat PCoE - SAP Partner Center of Expertise.

SNP Poland to lider rynku usług SAP w Polsce.
Zapewniamy pełen zakres wdrożeń, rozwoju i utrzymania systemów SAP. Dostarczamy usługi bezpieczeństwa IT i rozwoju oprogramowania. Do 2017 roku działaliśmy jako BCC.

Jesteśmy częścią Grupy SNP – wiodącego światowego dostawcy rozwiązań do transformacji środowisk SAP.

Od 1995 roku zrealizowaliśmy z sukcesem setki projektów IT w Polsce i kilkudziesięciu innych krajach.

Nasi eksperci przedstawiają najciekawsze rozwiązania i nowości ze świata IT.

Zobacz archiwum nagrań z webinarów, zarejestruj się na kolejne edycje.

Dlaczego uważamy, że SNP Poland jest dobrym pracodawcą? Bo łączymy cechy rzadko spotykane w jednej organizacji - duże możliwości rozwoju, a zarazem dobrą atmosferę i elastyczność środowiska pracy. Dowiedz się więcej, na czym to polega w praktyce!

Jak podnieść system SAP do wersji ECC 6.0?

Upgrade nie musi boleć

Udostępnij
Drukuj:
Upgrade to jedno z tych przedsięwzięć, które są nie tyle potrzebne, ile konieczne. Musimy podnieść wersję SAP, by móc korzystać z serwisu producenta i mieć dostęp do nowych funkcjonalności i technologii. Im bardziej złożona instalacja SAP i większa firma, z tym większym potencjalnym ryzykiem wiąże się projekt upgrade’u. Są jednak sposoby, by ta ważna operacja została przeprowadzona bezboleśnie i bez strachu o zdrowie pacjenta.
 

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.

Etapem upgrade’u angażującym największy zespół osób są testy. Liczne scenariusze testowe muszą nas upewnić, że procesy, które system realizował poprzednio, także w nowej wersji są wykonywane bezbłędnie

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 SNP.

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.

Eksperci SNP wśród autorów „The Big Book of SAP Upgrades”

Kierownicy projektów z SNP Poland zostali współautorami publikacji „The Big Book of SAP Upgrades – Real World SAP Upgrade Tips from the World’s Leading SAP System Integrators”, wydanej przez firmę Panaya Inc., światowego lidera w zakresie narzędzi usprawniających realizację projektów upgrade SAP. W „The Big Book of SAP Upgrades” zebrano porady ekspertów z wiodących firm konsultingowych działających na całym świecie. Dotyczą one metodyki prowadzenia upgrade’ów SAP, ze szczególnym uwzględnieniem upgrade’ów do najnowszej wersji SAP ERP ECC 6.0. Eksperci z SNP – Aleksandra Skotarczak-Luty, Michał Jasiński oraz Michał Kunze – są jedynymi specjalistami z Polski, których porady znalazły się w tym opracowaniu.

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ń SNP 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.

Lepszy Biznes

magazyn klientów SNP

Przejdź do bazy artykułów
Udostępnij
Drukuj:

Formularz kontaktowy





  1. Dane osobowe przetwarzane są na podstawie art. 6 ust. 1 lit. a Rozporządzenia Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. – ogólnego rozporządzenia o ochronie danych osobowych.
  2. Administratorem Danych Osobowych jest SNP Poland Sp. z o.o. z siedzibą w Złotnikach, ul. Krzemowa 1 62-002 Suchy Las. Dane kontaktowe do Inspektora Ochrony Danych: dpo.pl@snpgroup.com.
  3. Zgoda na przetwarzanie danych jest dobrowolna, ale niezbędna w celu kontaktu. Zgodę można wycofać w dowolnym momencie bez wpływu na zgodność z prawem przetwarzania, którego dokonano na podstawie zgody przed jej wycofaniem
  4. Dane będą przetwarzane do realizacji określonych powyżej celów i do momentu wycofania niniejszej zgody, a dostęp do danych będą miały tylko wybrane osoby posiadające stosowne upoważnienie do ich przetwarzania.
  5. Każda osoba podając dane osobowe ma prawo dostępu do treści swoich danych i ich sprostowania, usunięcia, ograniczenia przetwarzania, prawo do wniesienia sprzeciwu wobec przetwarzania i przenoszenia danych, prawo do ograniczenia przetwarzania i prawo sprzeciwu wobec przetwarzania danych, prawo do przenoszenia danych.
  6. Każda osoba, której dane są przetwarzane, ma prawo do wniesienia skargi do organu nadzorczego jakim jest Prezes Urzędu Ochrony Danych Osobowych (ul. Stawki 2, 00-193 Warszawa).
  7. Dane osobowe mogą być udostępniane innym jednostkom należącym do grupy kapitałowej, do której należy SNP Poland Sp. z o.o. – również znajdujących się poza Europejskim Obszarem Gospodarczym, w celach marketingowych. SNP Poland zapewnia, że dane przekazywane tym podmiotom są właściwie zabezpieczone, a osoba, której dane są przetwarzane, ma prawo do uzyskania kopii udostępnionych danych oraz informacji o miejscu udostępnienia danych.

Napisz maila lub zadzwoń

E-mail: office.pl@snpgroup.com
Tel. 61 827 7000

SNP Poland Sp. z o.o.

Centrala:
Złotniki, ul. Krzemowa 1
62-002 Suchy Las k. Poznania

Skontaktuj się z nami

W czym możemy pomóc?
Napisz do nas
Wyślij email
Zadzwoń





  1. Dane osobowe przetwarzane są na podstawie art. 6 ust. 1 lit. a Rozporządzenia Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. – ogólnego rozporządzenia o ochronie danych osobowych.
  2. Administratorem Danych Osobowych jest SNP Poland Sp. z o.o. z siedzibą w Złotnikach, ul. Krzemowa 1 62-002 Suchy Las. Dane kontaktowe do Inspektora Ochrony Danych: dpo.pl@snpgroup.com.
  3. Zgoda na przetwarzanie danych jest dobrowolna, ale niezbędna w celu kontaktu. Zgodę można wycofać w dowolnym momencie bez wpływu na zgodność z prawem przetwarzania, którego dokonano na podstawie zgody przed jej wycofaniem
  4. Dane będą przetwarzane do realizacji określonych powyżej celów i do momentu wycofania niniejszej zgody, a dostęp do danych będą miały tylko wybrane osoby posiadające stosowne upoważnienie do ich przetwarzania.
  5. Każda osoba podając dane osobowe ma prawo dostępu do treści swoich danych i ich sprostowania, usunięcia, ograniczenia przetwarzania, prawo do wniesienia sprzeciwu wobec przetwarzania i przenoszenia danych, prawo do ograniczenia przetwarzania i prawo sprzeciwu wobec przetwarzania danych, prawo do przenoszenia danych.
  6. Każda osoba, której dane są przetwarzane, ma prawo do wniesienia skargi do organu nadzorczego jakim jest Prezes Urzędu Ochrony Danych Osobowych (ul. Stawki 2, 00-193 Warszawa).
  7. Dane osobowe mogą być udostępniane innym jednostkom należącym do grupy kapitałowej, do której należy SNP Poland Sp. z o.o. – również znajdujących się poza Europejskim Obszarem Gospodarczym, w celach marketingowych. SNP Poland zapewnia, że dane przekazywane tym podmiotom są właściwie zabezpieczone, a osoba, której dane są przetwarzane, ma prawo do uzyskania kopii udostępnionych danych oraz informacji o miejscu udostępnienia danych.

Kontakt ogólny do firmy
office.pl@snpgroup.com

Pytania o produkty i usługi
info.pl@snpgroup.com

Pytania na temat pracy i staży
kariera@snpgroup.com

61 827 70 00

Biuro jest czynne
od poniedziałku do piątku
w godz. 8:00 – 17:00