Według naszych szacunków nawet połowa zainstalowanych w Polsce rozwiązań SAP to stare wersje systemu. Rok 2012 to ostatni dzwonek, żeby zaplanować upgrade SAP do najnowszej wersji ERP 6.0, by nie utracić wsparcia producenta systemu. O tym, jak zaplanować i według jakiego scenariusza przeprowadzić projekt podniesienia wersji SAP, rozmawiamy z Dariuszem Kurkiewiczem, Liderem Zespołu Wdrożeniowego IT i kierownikiem projektów upgrade’u technicznego w BCC.
Duży i wymagający projekt wdrożenia SAP, a za kilka lat i tak system trzeba wymienić, wykonując upgrade…
Firma SAP ciągle rozwija swoje produkty i w ramach licencji na system klienci mają dostęp do najnowszych wersji systemów, a co za tym idzie, do innowacyjnych rozwiązań wspomagających biznes. To znaczna wartość dodana dla klienta w ramach usługi wsparcia producenta systemu. Kolejne wersje to przede wszystkim dostęp do nowych funkcjonalności, ale też wyższy poziom bezpieczeństwa danych, oparcie na nowocześniejszych technologiach IT.
W dziedzinie informatyki nie tylko sprzęt się szybko starzeje, aplikacje rozwijają się chyba jeszcze szybciej. Miłośnicy gier komputerowych z niecierpliwością czekają na nowe, rozszerzone edycje swoich ulubionych, licząc na lepszą grafikę, ciekawsze przygody czy zadania, nowe pomysły.
Podobnie jest z zaawansowanymi systemami biznesowymi – świat nieustanne idzie do przodu, a zatem nie tylko warto, ale po prostu trzeba korzystać z najnowszych, najlepszych dostępnych wersji systemu.
Na rynku równolegle funkcjonuje kilka wersji systemu SAP ERP. Dlaczego zachęcamy do upgrade do wersji ERP 6.0? I dlaczego właśnie teraz?
W ostatnich latach firma SAP dość często ogłaszała nowe wersje systemu, równolegle wspierając poprzednie. Taka sytuacja powodowała, że część firm nie decydowała się podnosić systemu do nowszej wersji, czekając na kolejną aktualizację oprogramowania. Inną strategią było wykonanie upgrade starej wersji systemu do nowszej, ale nie najnowszej dostępnej. Na życzenie klienta prowadziliśmy np. projekty upgrade’u z SAP R/3 4.6C do ERP 5.0, gdy dostępna była już wersja 6.0.
To poniekąd zrozumiałe – projekt upgrade’u jest czasochłonny, wiąże się z koniecznością dostosowania rozszerzeń i kosztami. Często klienci oceniali, że aktualizacja nie wnosi niczego istotnego pod względem nowych funkcjonalności czy zabezpieczeń i po prostu lepiej przeczekać do kolejnej wersji. Z kolei firmy pracujące na bardzo starych wersjach systemu obawiały się zbyt dużego przeskoku i wolały upgrade do nowszej, ale nie najnowszej wersji.
Jednak teraz sytuacja jest inna. Po ogłoszeniu wersji SAP ERP 6.0 producent oprogramowania ogłosił zmianę strategii. Obecnie zamiast co kilka lat opracowywać nowy system, cyklicznie, co kilka miesięcy publikowane są tzw. Enhancement Packages zawierające innowacyjne funkcjonalności, zabezpieczenia. Innymi słowy, taki ustawiczny upgrade drobnymi kroczkami. Warunkiem korzystania z EHP jest jednak posiadanie najnowszej wersji SAP ERP 6.0.
Wkrótce po tej zmianie firma SAP ogłosiła też datę zakończenia wsparcia dla starszych wersji produktów z rodziny SAP: SAP R/3 4.6C, SAP R/3 Enterprise 4.7 oraz mySAP ERP 2004 (ECC 5.0). Extended Maintenance dla nich wygaśnie 31 marca 2013 r. SAP nie będzie też świadczyć wsparcia dla wszystkich produktów opartych na technologii SAP NetWeaver 2004 (SAP WEB AS 6.40), przykładowo SAP BW, SAP XI, Enterprise Portal. Dotyczy to także oddzielnych instalacji SAP HR opartych na tych wersjach.
A co po tej dacie?
Starsze wersje systemu oczywiście nie przestaną działać z dnia na dzień, jednak nie będą już obsługiwane przez globalną organizację serwisową SAP. W praktyce oznacza to, że SAP zaprzestanie publikacji uaktualnień i poprawek, nie będą też obsługiwane zgłoszenia błędów. De facto dla tych wersji wygaśnie wsparcie producenta systemu.
Najszybciej odczują to firmy korzystające z SAP HR, które co miesiąc otrzymują biuletyny (tzw. LCP) z poprawkami i aktualizacjami uwzględniającymi zmiany prawne. Ograniczone zostaną też możliwości integracji systemu z innymi narzędziami SAP. Nowe produkty SAP nie będą kompatybilne z „starymi” rozwiązaniami.
Czyli firmy korzystające ze starych wersji powinny zaplanować upgrade SAP w 2012 lub na początku 2013 r. Zostało jeszcze trochę czasu…
Niekoniecznie. Początek 2013 r. to już trochę za późno, by płynnie, bez utraty wsparcia producenta przejść na SAP ERP 6.0. W BCC przeprowadziliśmy już kilkadziesiąt podobnych projektów i mogę z całą odpowiedzialnością stwierdzić, że upgrade systemu średniej wielkości, około pięciu-sześciu modułów, od momentu przygotowania do projektu do chwili startu systemu produkcyjnego w wyższej wersji trwa średnio pół roku.
Uwzględniając okresy budżetowania oraz dostępność zasobów zarówno własnych, jak i firm konsultingowych, trzeba podkreślić, że teraz jest ostatni moment, by zaplanować taki projekt bezpiecznie i z marginesem czasowym.
Pół roku na upgrade to wydaje się to dość długo. Pewnie u niejednego klienta samo wdrożenie SAP nie trwało dłużej. Dlaczego podniesienie wersji systemu zajmuje tak dużo czasu?
Przede wszystkim podkreślmy, że w naszym rozumieniu projekt upgrade to całość prac zmierzających do podniesienia wersji, które są realizowane w środowisku trzysystemowym i dotyczą wszystkich funkcjonalności, zarówno standardowych SAP, jak i rozszerzeń, aplikacji ABAP i interfejsów z innymi rozwiązaniami. Często jeszcze zdarza się, że pod pojęciem upgrade SAP rozumie się tylko te czynności, które wymagają wyłączenia systemu. To w istocie jest już sam finał projektu, który rzeczywiście trwa nieprzerwanie przez weekend.
Upgrade tak rozwiniętego jak SAP systemu to nie tylko projekt techniczny. W rzeczywistości w przeciętnym projekcie zadania realizowane w module Basis to zaledwie 1/4 prac. Resztę pracochłonności zajmują prace w modułach funkcyjnych, których celem jest sprawdzenie działania funkcjonalności i rozszerzeń systemu w wyższej wersji i ewentualne dostosowania.
To sprawdzenie funkcjonalności to przede wszystkim testy, testy i jeszcze raz testy Po testach poprawki i kolejne testy. W rozwiniętych, kustomizowanych systemach to po prostu musi trwać.
Na terminarz projektowy wpływa też podział ról pomiędzy konsultantami firmy konsultingowej i specjalistami klienta. Zdarzają się przypadki, gdy firma posiada silne kompetencje Basis i jesteśmy angażowani do części aplikacyjnej. Bywa też odwrotnie. Jesteśmy pod tym względem elastyczni i dostosowujemy ofertę do oczekiwań klienta.
Jak przebiega projekt upgrade z BCC?
Według autorskiej metodyki BCC projekty upgrade zawsze przeprowadzamy w środowisku trzysystemowym: z systemami rozwojowym, testowym i produkcyjnym.
Projekt może być realizowany według dwóch podstawowych scenariuszy. Pierwszy – zalecany przez firmę SAP oraz rekomendowany przez BCC, to zamrożenie wszelkich prac rozwojowych na czas projektu. Następnie wykonujemy upgrade systemu rozwojowego. Z systemu produkcyjnego tworzona jest kopia na testowy. Od tej chwili wszystkie prace koncentrują się na systemie testowym. Podnosimy go do wyższej wersji i następnie krok po kroku testujemy działanie funkcjonalności, wykonując konieczne dostosowania, wykrywając niezgodności i błędy.
Przy tej okazji tworzony jest także dokładny scenariusz oraz procedury postępowania na wypadek błędów, które zostaną wykorzystane w upgradzie produkcji. Ostatnim, krytycznym etapem jest podniesienie systemu produkcyjnego do wyższej wersji, wraz z działającymi wszystkimi funkcjonalnościami, rozszerzeniami i interfejsami. Zwykle okno czasowe na te prace jest bardzo krótkie (np. weekend), dlatego tak ważne są szczegółowe scenariusze i procedury.
Trudno w firmie z działającym, żywym systemem wstrzymać na pół roku prace rozwojowe, jednak większość firm decyduje się na takie podejście, bo to po pierwsze może skrócić czas projektu, a po drugie – jest bezpieczniejsze i po prostu łatwiejsze zarówno dla klienta, jak i dla firmy konsultingowej.
A drugi scenariusz?
Nie zawsze prace rozwojowe w systemie mogą zostać wstrzymane na czas upgrade’u. Wystarczy, że firma korzysta z SAP HR i już wiadomo, że co miesiąc będą konieczne dostosowania związane z uaktualnieniami publikowanymi przez producenta systemu. Czasami firmy równolegle z upgradem decydują się na kontynuowanie projektów rozwojowych.
W takich przypadkach w pejzażu systemów SAP pojawia się dodatkowy system w starej wersji, który jest źródłem zmian dla systemu produkcyjnego w czasie trwania projektu upgrade. Systemy rozwojowy, testowy i produkcyjny są upgrade’owane w ustalonej sekwencji, a gdy wszystkie systemy są już w nowej wersji, następuje synchronizacja zmian dla nowej wersji SAP, dla zachowania spójność zmian w pejzażu. W scenariuszach upgrade z kontynuacją prac rozwojowych bardzo istotna jest precyzyjna dokumentacja zmian w starej i nowej wersji systemu SAP.
Z czym jeszcze trzeba się liczyć, decydując się na upgrade SAP do wersji 6.0?
Szczególnie w wypadku starszych wersji systemu, jak np. R/3 4.6C lub R/3 4.7, upgrade zwykle musi być poprzedzony migracją na nową platformę sprzętową i nową wersję systemu operacyjnego i bazy danych. Nie jest to oczywiście regułą, ale wersja ERP 6.0 ma wyższe wymagania techniczne niż starsze i jeśli infrastruktura techniczna nie była od dawna odnawiana, raczej należy liczyć się z dodatkowymi pracami i kosztami. Wiele firm wykorzystuje ten fakt jako dobry moment, by rozważyć kwestię hostingu rozwiązań SAP w profesjonalnym centrum przetwarzania danych.
Przy okazji upgrade część firm decyduje się także na konwersję do standardu kodowania UNICODE, który daje lepsze możliwości korzysta z SAP w wielu wersjach językowych.
Często firmy zwlekają z decyzją o upgradzie ze względu na dużą liczbę zmian i autorskich rozszerzeń, które przez lata wdrożyły w systemie. Czy to uzasadniona obawa?
Postawiłbym to pytanie inaczej: czy nie jest większym ograniczeniem – technologicznym i funkcjonalnym – korzystanie z wersji opracowanej ponad dekadę temu? W technologii informatycznej 10 lat to epoka, jeśli chodzi o wydajność, bezpieczeństwo, a także zakres funkcjonalny dostępny w najnowszych wersjach.
Myślę, że w wypadku bardzo rozwiniętych systemów obawa może wynikać z czego innego. Im więcej rozszerzeń i niestandardowych funkcjonalności, tym trudniej oszacować czas konieczny na wykonanie upgrade, a tym samym jego koszt.
Na rynku są dostępne rozbudowane narzędzia, które pozwalają na automatyczną analizę systemu SAP pod kątem upgrade’u. Są to rozwiązania SAP SLO (System Landscape Optimalization) oraz SAP Upgrade Automation firmy Panaya.
My proponujemy nieco inną drogę. BCC opracowało usługę audytu systemu SAP przed upgrade do ERP 6.0. Na życzenie klienta wykonujemy zarówno audyt techniczny, jak i funkcjonalny systemu. Jego efektem jest szczegółowy raport z zaleceniami, jakie kroki należy wykonać, aby projekt upgrade SAP został przeprowadzony w sposób optymalny dla klienta. Audyt systemu przed upgrade do ERP 6.0 pozwala dodatkowo dokładnie określić pracochłonność i co za tym idzie, koszt projektu. Jeżeli BCC wykonuje zarówno audyt, jak i projekt, wyniki audytu są dla nas wiążące w ofercie cenowej.
Jakie są kompetencje BCC w tego typu projektach?
BCC ma duże doświadczenie w realizacji projektów upgrade SAP, w tym także do wersji ERP 6.0. Na tej podstawie stworzyliśmy autorską metodykę tego typu projektów. Jest ona oparta na zaleceniach SAP, ale wzbogacona o nasze dobre praktyki. Taki niejednokrotne przećwiczony w różnych konfiguracjach systemu scenariusz jest dla naszych klientów gwarancją bezpieczeństwa i sprawnej realizacji projektu. Mamy ponad 20 konsultantów SAP Basis, którzy posiadają duże doświadczenie i wysokie kwalifikacje, potwierdzone certyfikatami SAP, a także z zakresu baz danych i systemów operacyjnych wykorzystywanych przy implementacji systemów SAP.
Ale jak już podkreślałem, upgrade to nie tylko projekt techniczny, ale także aplikacyjny. W tym obszarze do dyspozycji klientów jest blisko 200 konsultantów SAP, specjalistów ze wszystkich modułów i najważniejszych technologii SAP.
Dysponując takim zespołem, jesteśmy elastyczni, jeśli chodzi o zakres zaangażowania w prace projektowe. Najczęściej realizujemy całość prac, przy współpracy pracowników klienta.
Naszym atutem jest także nowoczesna i bezpieczna infrastruktura centrum przetwarzania danych, z której klienci mogą skorzystać podczas projektu, np. jako zapasowego data center.
A zatem trzeba zacząć działać już teraz. Co powinna zrobić firma, która pracuje na starszej wersji systemu SAP?
Im wcześniej zaczniemy działać, tym lepiej. Proponuję zacząć od audytu systemu pod kątem upgrade’u. On pozwoli na zorientowanie się, jak dużo pracy nas czeka oraz jaki podział obowiązków pomiędzy konsultantami zewnętrznymi i własnymi pracownikami będzie najwłaściwszy. Jeśli klient jest zdecydowany przeprowadzić projekt z BCC, audyt systemu możemy potraktować jak fazę koncepcji, po której doprecyzowujemy budżet i harmonogram projektu upgrade.
Pamiętajmy, że pół roku, o którym mówiliśmy, to orientacyjny czas trwania prac. Jeśli system jest duży i nie można na czas upgrade’u zawiesić prac rozwojowych, bezpieczniej jest rozciągnąć prace w czasie, by móc dokładnie przetestować wszystkie funkcjonalności.
Rozmawiała Mirosława Huk, Grupa BCC
Wszystkich korzystających z wersji SAP poniżej 6.0 (ECC 6.0, Enterprise Central Component 6.0) prosimy o kontakt z BCC celem rozpoczęcia przygotowań Państwa firmy do upgrade’u.
