Jakie sygnały wskazują, że warto rozważyć outsourcing usług serwisowych SAP?

Jest kilka głównych powodów: nie mamy aktywnej umowy serwisowej z dotychczasowym dostawcą systemu ERP lub współpraca z różnych względów się nie układa, jeśli obserwujemy w organizacji takie zjawiska jak: brak dostępności własnych specjalistów SAP, przeciążenie wewnętrznego zespołu IT, rosnąca liczba zgłoszeń użytkowników, niskie tempo obsługi incydentów i zmian, czy wreszcie rosnąca złożoność systemu lub przy planach jego rozwoju.

Czy taka współpraca sprawdza się lepiej w określonych modelach organizacyjnych?

Tak – szczególnie w firmach wielooddziałowych, grupach kapitałowych, czy organizacjach, które nie mają własnego centrum kompetencyjnego SAP. Także firmy o nieregularnym zapotrzebowaniu na wsparcie (np. sezonowość) czerpią korzyści z elastycznego modelu AMS (ang. Application Management Services).

Czy współpraca z partnerem oznacza pełne oddanie kontroli nad systemem?

Nie – to raczej podział obowiązków. Klient zachowuje kontrolę strategiczną i nadzór nad systemem, a partner przejmuje bieżące zadania operacyjne, wsparcia użytkowników oraz np. część realizacji drobnych zmian rozwojowych wynikających z bieżącej działalności operacyjnej firmy.

Serwis SAP. Jak przygotować się do współpracy z dostawcą ?

Jakie działania powinna podjąć firma przed rozpoczęciem współpracy?

Podstawą jest audyt systemu SAP, uporządkowanie dokumentacji technicznej systemu, uporządkowany proces nadawanie dostępów i ról. Kluczowe jest też ustalenie jasnego zakresu usług i oczekiwań biznesowych – najlepiej w formie dokumentu SoW (Statement of Work).

Czy potrzebna jest dokumentacja systemu lub porządkowanie autoryzacji?

Tak. Im lepiej udokumentowane środowisko, tym szybszy onboarding. Warto przygotować m.in. strukturę krajobrazu systemowego (Dev/Test/Prod), opisy integracji i kluczowych procesów oraz wykaz ról użytkowników z matrycą uprawnień stanowiskowych, jeśli takowe występują.

Jakie wyzwania napotykacie najczęściej przy onboardingu klienta?

Brak dokumentacji, nieuporządkowana struktura transportów, nieznana konfiguracja własnych rozszerzeń (Z*), brak jednego punktu kontaktu po stronie klienta i niejasny podział ról między działem IT a biznesem.

Jak dobrze zdefiniować zakres usług?

Kluczowe jest określenie:

• Zakresu merytorycznego świadczonej usługi, czyli jakie moduły SAP mają być objęte wsparcia, czy w zakresie ma być również wsparcia obszaru technicznego BASIS i inne.
• Zakres techniczny, czyli w uproszczeniu opisanie, które systemy w pejzażu klienta mają być objęte usługą np. ERP, BW, HR, warstwy techniczne, infrastrukturalne, czy wsparcia ma dotyczyć np. tylko systemu produkcyjnego czy również pozostałych systemów jak system testowy, rozwojowy, szkoleniowy itp.
• Sprecyzowanie jakich kategorii zgłoszeń ma dotyczyć usługa, np. czy wsparcie ma być realizowane tylko dla mniej pilnych zagadnień z priorytetami średnimi i niskimi, gdzie wyższe priorytety są obsługiwane przez wewnętrzne zasoby IT. Inny wariant to obsługa przez wsparcie zewnętrzne wszystkich priorytetów zgłoszeń, łącznie z krytycznymi, jeśli usługa obejmuje również wsparcie warstwy technicznej systemu SAP BASISS. Istotne jest również klarowne określenie warunków jakie powinien spełniać incydent, aby go zakwalifikować do właściwej kategorii, priorytetu.
• Określenie kalendarza wsparcia, czyli inaczej mówiąc opisanie, w jakie dni i w jakich godzinach ma być realizowane wsparcia.
• Oczekiwania w zakresie parametrów SLA (Service Level Agreement) usługi, czyli jak ma być maksymalny czas reakcji oraz czas rozwiązania lub obejścia zgłoszonych problemów dla poszczególnych kategorii zgłoszeń.
• Dobrze, jeśli uda się również określić zakres rzeczowy oczekiwanej usługi, czyli np. czy wsparcie ma być realizowane tylko dla wewnętrznego zespołu IT, użytkowników kluczowych systemu, wszystkich użytkowników systemu, wskazanie liczby wspieranych użytkowników, jeśli mamy dane historyczne to wskazanie również liczby incydentów w okresie itp.

Model współpracy oraz zakres usług Application Management Systems

Jakie są popularne modele świadczenia usług AMS?

W naszej praktyce stosujemy jeden z 3 modeli w zależności od potrzeb klienta i skali usługi i są to: pakiety miesięczne z gwarantowaną pulą godzin (np. 40h/mies.), model zryczałtowany (flat fee) przy większej skali, ale i przewidywalnym zakresie oraz najrzadziej model rozliczenia godzinowego (time & material), który ma charakter bliższy umowie ramowej. Czasem też hybrydowy – stała opłata + rozliczenie za dodatkowe godziny.

Czym różni się obsługa incydentów od obsługi zmian?

Incydenty (tickets) dotyczą nieprawidłowości w działaniu systemu i są realizowane zgodnie z SLA. Zmiany (change requests) to nowe wymagania funkcjonalne – ich obsługa wymaga analizy, wyceny i akceptacji przez klienta, a po realizacji zmiany testów z udziałem klienta.

Jakie usługi można zlecić zewnętrznemu partnerowi, a co zwykle zostaje po stronie klienta?

Outsourcować można większość wsparcia operacyjnego, analizy funkcjonalne, realizację zmian, obsługę transportów, monitoring systemu. Po stronie klienta najczęściej zostaje zarządzanie użytkownikami, zarządzanie licencjami, kontakty z SAP (OSS) i decyzje biznesowe.

Wsparcie zgodne z ITIL? Jakie procesy są kluczowe?

ITIL, czyli: Information Technology Infrastructure Library, to zbiór najlepszych praktyk w zakresie zarządzania usługami IT (ITSM). W naszej praktyce stosujemy tego typu praktyki, przede wszystkim w zakresie: Incident Management, Change Management czy Preventive Maintenance. Dzięki temu klient ma przejrzystość i powtarzalność procesów. Dlatego zawsze rekomendujemy naszym klientom korzystanie z tego typu podejścia i uważam, że powinno to być rynkowym standardem.

SLA i jakość wsparcia serwisowego

Jakie są typowe SLA (Service Level Agreement) i które metryki są naprawdę istotne?

Najczęściej ustalamy SLA dla czasu reakcji i czasu rozwiązania – zwykle w zależności od priorytetu zgłoszenia. Ważniejsze od liczby godzin jest realne dopasowanie SLA do rytmu biznesu klienta, istotności procesów biznesowych realizowanych w systemie, np. czas naprawy lub obejścia dla krytycznego zgłoszenia to 4h, priorytety niższe w 8-48h.

Czy warto wymagać KPI lub raportowania jakości usług?

Zdecydowanie tak. Raportowanie FCR (First Call Resolution), średniego czasu rozwiązania, liczby zgłoszeń otwartych i zamkniętych – to podstawa oceny jakości usług i optymalizacji współpracy. Dobrą praktyką są comiesięczne raporty i spotkania przeglądowe.

Jak wygląda proces eskalacji?

Zazwyczaj mamy trzystopniowy model eskalacji: konsultant → lider zespołu → manager. Klient otrzymuje kontakt do opiekuna serwisowego, który koordynuje działania zespołu i rozwiązuje problemy eskalacyjne.

Zmiany i rozwój systemu SAP ECC i S/4HANA

Czy partner może wspierać rozwój systemu?

Tak – wiele firm korzysta z AMS nie tylko do utrzymania, ale i rozwoju systemu. Realizujemy mniejsze i średnie zmiany funkcjonalne, integracje, rollouty, optymalizacje procesów. Proces tego typu zmian, nazywamy Change Request-ami. Taki model często pozwala szybciej wdrażać usprawnienia niż realizacja zmian przez własny dział IT czy zagraniczną centralę koncernu, który może być zaangażowany np. w większe projekty. 

Jak wygląda obsługa takich change request-ów?

Zgłoszenie trafia do analizy – określamy zakres, szacujemy czas, przygotowujemy wycenę i plan realizacji. Po akceptacji przez klienta uruchamiamy development, testy, dokumentację, a po ich odbiorze transport zmian do systemu produkcyjnego.

Jak zapewnić bezproblemową współpracę i bezpieczeństwo całego przedsięwzięcia na linii: klient - partner serwisowy SAP?

Kluczowe są: jasna polityka transportów, zarządzanie wersjami, środowisko testowe jak najbardziej zbliżone do produkcyjnego, dokumentowanie zmian. Zachęcamy klientów do wdrożenia harmonogramów wprowadzania zmian poprzez transporty na środowisko produkcyjne oraz punktowe Freezes w okresach krytycznych. Chcąc zapewnić wysoki poziom bezpieczeństwa, pamiętajmy o podstawach, o których, łatwo zapomnieć w toku codziennych obowiązków czy podczas rozwiązywania złożonych problemów. Myślę o dostępach do systemu: żaden partner nie będzie w stanie efektywnie realizować swoich zadań bez odpowiednich uprawnień już na samym początku współpracy, zaś sam dostęp powinien odbywać się poprzez bezpieczne kanały (np. VPN, SAProuter), na imienne konta z odpowiednimi rolami. Zalecamy monitorowanie działań partnera przez logi oraz stosowanie zasady minimalnego dostępu.

Ryzyko zerwania współpracy – jak tego uniknąć?

Takie przypadki zwykle wynikają z braku doprecyzowania oczekiwań lub braku komunikacji. Kluczem do sukcesu jest przejrzysty SoW, realistyczne SLA i regularne spotkania statusowe. To pozwala unikać nieporozumień i budować zaufanie oraz partnerskie relacje. Można je budować poprzez transparentność, regularną komunikację i otwartość na feedback. U klientów, z którymi pracujemy latami, stajemy się częścią zespołu – doradzamy, proponujemy usprawnienia i dzielimy się wiedzą, pomagamy przy decyzjach o migracjach (np. S/4HANA), integracjach z innymi systemami, optymalizacji licencji SAP, wyborze narzędzi monitorujących. Jesteśmy nie tylko wykonawcą, ale też doradcą IT. Partnerskie podejście to podstawa.  

Jakie błędy popełniają klienci najczęściej?

Brak jasnego właściciela projektu po stronie klienta, nierealne oczekiwania co do tempa zmian, przeciągające się akceptacje CR-ów lub… zbyt późne zgłoszenie problemu. Dobra współpraca wymaga partnerstwa – z obu stron.