Outsourcing SAP Basis w większości umów sprowadza się do trzech słów: monitoring, poprawki, dyżur. Te słowa niewiele mówią o faktycznym zakresie usługi. Nie wynika z nich, kto zareaguje na alert bezpieczeństwa o drugiej w nocy, kto w drugi wtorek miesiąca zdecyduje, które noty z SAP Security Patch Day idą na produkcję w tym tygodniu, ani czym zastąpicie monitoring z SAP Solution Manager, kiedy skończy się jego standardowe utrzymanie.
Utrzymanie SAP Basis prowadzimy od lat, a w jednym ze środowisk, które obsługujemy, łączymy je z monitoringiem bezpieczeństwa w trybie całodobowym od lutego 2023 roku. Poniżej opisujemy zakres takiej usługi, nasz codzienny przegląd systemu, sposób czytania SLA i miejsce, w którym utrzymanie styka się z bezpieczeństwem.
W skrócie:
1/ outsourcing SAP Basis obejmuje warstwę techniczną: system, bazę danych, kernel, transporty, kopie zapasowe i wydajność - wsparcie funkcjonalne i rozwój to osobne usługi i dobrze, gdy umowa mówi to wprost,
2/ jakość usługi widać w codziennym przeglądzie systemu - nasz obejmuje siedemnaście transakcji, od stanu instancji po zatrzymane importy transportów i komunikaty IDoc,
3/ SLA ma sens dopiero wtedy, gdy rozdziela czas reakcji od czasu przywrócenia działania i mówi, kto ten czas mierzy,
4/ poprawki bezpieczeństwa, hardening i monitoring zdarzeń to praca zespołu Basis, więc najprościej, gdy odpowiada za nie ten sam dostawca, a okresowy test penetracyjny sprawdza wynik z zewnątrz.
Co obejmuje outsourcing SAP Basis
Zakres zaczyna się od codziennej kontroli systemów i obsługi alertów, a kończy na administracji bazą SAP HANA: kopiach zapasowych, odtwarzaniu po awarii, wysokiej dostępności i planowaniu rozbudowy. Pomiędzy są poprawki i aktualizacje (SAP Security Notes, kernel, support packi), analiza i strojenie wydajności, zarządzanie zmianą z kontrolą transportów, a także obsługa incydentów z dyżurem całodobowym.
Granica, o którą najczęściej toczy się spór po podpisaniu umowy, przebiega między warstwą techniczną a aplikacją. Utrzymanie Basis odpowiada za to, żeby system działał, był aktualny i wydajny. Nie odpowiada za błąd w konfiguracji modułu finansowego ani za program raportowy napisany przez innego dostawcę. Jeżeli w umowie te dwie warstwy nie są rozdzielone, każdy incydent zaczyna się od ustalania, czyj to problem, a czas reakcji biegnie.
Kiedy outsourcing jest lepszy niż własny zespół
Dyżur całodobowy wymaga kilku osób o porównywalnych kompetencjach, które się wzajemnie zastępują. Dla wielu organizacji to więcej etatów Basis, niż uzasadnia skala systemu, a rynek specjalistów z doświadczeniem w SAP HANA i SAP S/4HANA jest wąski. Rekrutacja jednej osoby nie rozwiązuje problemu, tylko przenosi go na urlopy i zwolnienia.
Własny zespół ma natomiast przewagę, której zewnętrzny dostawca nie kupi: zna procesy firmy i ludzi po stronie biznesu. Dlatego dobrze działa model mieszany, w którym zespół klienta zostaje przy architekturze i decyzjach, a dyżur, rutynowe kontrole i poprawki przejmuje dostawca. W takim modelu umowa musi jednak precyzyjnie opisywać, kto zatwierdza zmianę na produkcji.
Co sprawdzamy codziennie w systemie SAP
Codzienny przegląd to najprostszy test, czy dostawca utrzymania wie, co robi. U nas obejmuje siedemnaście transakcji, ułożonych w stałej kolejności. W środowiskach, w których ma to uzasadnienie, przegląd wykonuje bot UiPath, który zbiera wyniki do jednego raportu, a inżynier dyżurny zaczyna dzień od jego lektury zamiast od klikania po ekranach.
To rdzeń przeglądu, nie jego całość. Do każdego środowiska dokładamy kontrole wynikające z jego architektury, integracji i wymagań klienta.
Metadane systemu: SPAM (poziom support packów i wersja produktu) oraz DBACOCKPIT (wersja i wydanie bazy danych). Bez tego nie da się ocenić, których not bezpieczeństwa dotyczy najbliższy Patch Day.
Instancje i procesy: SM51 (stan instancji na wszystkich hostach), SM66 (procesy robocze według statusu w całym systemie) i ST06 (procesor, stronicowanie i wolne miejsce na dyskach serwerów aplikacyjnych).
Wydajność: ST03 (średni czas odpowiedzi w podziale na kroki dialogowe, RFC, aktualizacje i zadania w tle), ST02 (trafienia w bufory, wymiana buforów, pamięć sterty) oraz ST04 (stan operacyjny bazy, replikacja przy wysokiej dostępności, zużycie zasobów).
Kopie zapasowe: DB12 (nieudane kopie danych i logów). Nieudana kopia, której nikt nie zauważył przez tydzień, to najczęstszy powód, dla którego plan odtwarzania istnieje tylko na papierze.
Błędy i blokady: SM12 (blokady, w tym wiszące dłużej niż dobę), SM13 (nieudane aktualizacje V1 i V2), SM21 (dziennik systemowy według wagi), SM37 (zadania w tle zakończone błędem) i ST22 (zrzuty błędów ABAP).
Wyjścia i interfejsy: SP01 (błędne zlecenia wydruku), STMS_IMPORT (zatrzymane importy transportów) i WE02 (komunikaty IDoc według statusu).
Lista nie jest tajemnicą i nie w samej liście tkwi wartość. Wartość daje porównanie dnia do dnia: wzrost średniego czasu odpowiedzi w ST03 o kilkanaście procent bez zmiany obciążenia albo IDoc-i, które od trzech dni wiszą w tym samym statusie, mówią więcej niż jakikolwiek pojedynczy odczyt. Z tych samych danych bierze się strojenie wydajności. Parametry buforów i pamięci zmieniamy na podstawie trendu z ST02 i ST03, zanim użytkownicy zgłoszą spowolnienie.
Jakie SLA powinna zawierać umowa na utrzymanie SAP Basis
Najczęstszy błąd w umowach polega na tym, że jedna liczba ma opisać całą obsługę incydentu. Czas reakcji mówi, kiedy ktoś potwierdzi zgłoszenie i zacznie pracę. Czas przywrócenia działania mówi, kiedy system wróci do pracy, nawet jeśli przyczyna nie jest jeszcze usunięta. Czas rozwiązania dotyczy usunięcia przyczyny i bywa liczony w dniach, bo wymaga noty SAP albo okna serwisowego. To trzy różne zobowiązania i każde powinno mieć w umowie własną definicję.
Przed podpisaniem warto sprawdzić pięć rzeczy:
Klasy incydentów: czy umowa definiuje, co jest incydentem krytycznym, na przykład niedostępność produkcji dla wszystkich użytkowników, czy zostawia to do interpretacji w chwili awarii.
Pomiar: kto mierzy czas i w jakim narzędziu. Jeżeli zegar startuje dopiero w systemie zgłoszeń dostawcy, alert z monitoringu sprzed godziny nie istnieje.
Okna serwisowe: kiedy dostawca może zatrzymać system i kto po stronie klienta zatwierdza przestój.
Raportowanie: zawartość miesięcznego raportu i to, czy pokazuje trendy, czy tylko liczbę zamkniętych zgłoszeń.
Wyjście z umowy: jaką dokumentację, hasła techniczne i procedury dostawca przekazuje przy rozstaniu. Ta klauzula jest nudna do momentu, w którym jest potrzebna.
Kto odpowiada za Basis w RISE with SAP
Przejście do RISE with SAP przesuwa granicę odpowiedzialności, ale jej nie usuwa. SAP prowadzi infrastrukturę, system operacyjny, bazę SAP HANA, kopie zapasowe i monitoring warstwy technicznej. Po stronie klienta zostają konfiguracja aplikacji, użytkownicy, role, dziennik audytu, integracje i kod własny.
Dwa fakty z materiałów SAP zaskakują większość zespołów. Przy łatkach bezpieczeństwa warstwy technicznej SAP przygotowuje przetestowane paczki, ale to klient zgodnie z umową składa wniosek o ich wdrożenie i zgadza się na przestój w oknie utrzymaniowym. Test penetracyjny możecie z kolei przeprowadzić wyłącznie na warstwie aplikacji i wyłącznie po zatwierdzeniu przez SAP. Ktoś po Waszej stronie musi więc śledzić Patch Day, oceniać noty i składać wnioski. To nadal jest praca Basis, tylko w innym miejscu. Szerzej opisujemy to we wpisie o bezpiecznej konwersji do SAP S/4HANA i RISE with SAP.
SAP Security Patch Day w codziennym utrzymaniu
SAP publikuje noty bezpieczeństwa w drugi wtorek każdego miesiąca. Dla zespołu Basis to stały punkt kalendarza: inwentaryzacja tego, czego brakuje w systemach, ocena, które noty dotyczą Waszej konfiguracji, plan wdrożenia w systemach deweloperskich i testowych, a potem okno na produkcji. Bez znajomości poziomu support packów i wersji komponentów, czyli danych z codziennego przeglądu, ta ocena jest zgadywaniem.
Klient, z którym pracujemy od 2023 roku, opisał w rozmowie z ITwiz zjawisko, które widzimy w wielu firmach: „W wielu przypadkach względnie regularnie aktualizowany jest jedynie moduł techniczny, pokroju jądra systemu czy bibliotek bazy danych. Aktualizacje modułów funkcjonalnych są bardziej złożone […]. Efekt jest taki, że część starych modułów nie jest aktualizowana latami”. Dlatego obsługę Patch Day łączymy z planem aktualizacji całego środowiska, a nie tylko kernela. Comiesięczny cykl opisujemy na stronie SAP Security Patch Day.
Hardening, monitoring bezpieczeństwa i pentest jako część utrzymania
Domyślna konfiguracja SAP ma przede wszystkim umożliwić szybkie uruchomienie systemu. Utwardzanie konfiguracji, czyli wyłączanie zbędnych usług, porządkowanie parametrów bezpieczeństwa, połączeń RFC i uprawnień technicznych, nie kończy się na jednym projekcie, bo każda zmiana w systemie może je częściowo cofnąć. Pisaliśmy o tym we wpisie hardening SAP jako proces, nie projekt.
Monitoring bezpieczeństwa SAP to druga warstwa nad monitoringiem technicznym. Platforma SecurityBridge koreluje zdarzenia z logów SAP, wykrywa podatności w zainstalowanych komponentach i w kodzie ABAP, a alerty może przekazywać do systemu SIEM. Alert sam niczego jednak nie naprawia. Ktoś musi go odebrać, ocenić i zareagować, a najczęściej oznacza to zmianę w konfiguracji, którą wykonuje zespół Basis. Gdy monitoring bezpieczeństwa i utrzymanie są w rękach dwóch różnych dostawców, każdy alert wymaga przekazania sprawy między nimi.
Trzecia warstwa to okresowa kontrola z zewnątrz. Test penetracyjny SAP albo audyt bezpieczeństwa systemów deweloperskich, testowych i produkcyjnych sprawdza, czy hardening i poprawki działają tak, jak zakłada dokumentacja. Rekomendujemy go raz w roku i po każdej dużej zmianie, na przykład po konwersji do SAP S/4HANA. Testy wspiera RedLab AI box, nasze stanowisko z lokalnymi modelami językowymi bez blokad odmowy, które pomagają testerowi w analizie konfiguracji i kodu. Modele działają lokalnie, więc dane z testu nie trafiają do zewnętrznej usługi. Wszystkie trzy warstwy są opcjami. Zakres dobieramy do ryzyka i regulacji, którym podlega dana organizacja.
Utrzymanie i bezpieczeństwo w jednych rękach - Stock Spirits i sieć handlowa
Stock Spirits Group, producent alkoholi prowadzący działalność w dziewięciu krajach Europy, pracuje z nami od 2023 roku. Zakres, potwierdzony przez klienta w listach referencyjnych, obejmuje całodobowe wsparcie i utrzymanie systemów SAP ERP ECC oraz SAP S/4HANA razem z platformą SecurityBridge, utrzymanie platformy UiPath i jej botów, a także administrację i monitoring środowisk rozproszonych w trzech lokalizacjach fizycznych. Przeprowadziliśmy też audyt bezpieczeństwa systemów deweloperskich, testowych i produkcyjnych obu platform.
W rozmowie z ITwiz menedżer odpowiedzialny po stronie klienta za infrastrukturę IT i cyberbezpieczeństwo grupy opisał ten model tak: „W STOCK mamy dodatkowo taki luksus, że operacyjnie w obszarze SAP BASIS wspiera nasz zespół SNOK - i to on w większości przypadków odpowiada za reagowanie na alerty SecurityBridge”. Platformę SecurityBridge uruchomiliśmy produkcyjnie w trzy tygodnie, a w czasie migracji do SAP S/4HANA klient mógł na jednej licencji monitorować nowy system i równolegle stare środowisko produkcyjne SAP ECC.
Siedem powtarzalnych procesów administracyjnych wykonują u klienta boty UiPath, a środowisko ERP z ponad 700 użytkownikami jest objęte monitoringiem bezpieczeństwa przez całą dobę. Pełny opis znajdziecie w case study.
Ten sam model utrzymania prowadzimy w sieci handlowej z branży DIY: całodobowe wsparcie i utrzymanie SAP S/4HANA wraz z powiązanymi systemami, w tym samym zakresie co w Stock Spirits, tylko bez platformy SecurityBridge. Moduły bezpieczeństwa dobieramy więc do potrzeb klienta, nie są warunkiem usługi.
SAP Solution Manager po 2027 roku
Dla wielu zespołów Basis podstawowym narzędziem monitoringu wciąż jest SAP Solution Manager. Standardowe utrzymanie SAP Solution Manager 7.2 kończy się wraz z końcem 2027 roku. Firmy, które wykupią utrzymanie rozszerzone SAP Business Suite 7 do końca 2030 roku, dostaną je również dla Solution Managera bez dodatkowej opłaty, ale tylko dla wskazanych obszarów: zarządzania wymaganiami, projektami i procesami, Test Suite, kontroli zmian, ITSM i zarządzania krajobrazem. Monitoringu na tej liście nie ma. SAP rekomenduje przejście do SAP Cloud ALM przed końcem 2027 roku.
Dla umowy utrzymaniowej oznacza to konkretne pytanie: na jakim narzędziu dostawca będzie monitorował Wasz system w 2028 roku i kto przeniesie reguły oraz własne kontrole konfiguracji. Warto je zadać teraz, póki jest czas na przeniesienie reguł bez pośpiechu.
Jak przebiega przejęcie utrzymania od obecnego dostawcy
Przejęcie zaczynamy od audytu stanu środowiska: inwentarza systemów, konfiguracji, dokumentacji, długu technicznego i obecnych procedur. Na jego podstawie ustalamy SLA, ścieżkę eskalacji i podział odpowiedzialności - co robi SNOK, co zostaje po stronie Waszego zespołu i co zależy od dostawcy chmury albo infrastruktury.
Pierwszy miesiąc pracujemy obok obecnego zespołu. Poznajemy cykle operacyjne, powtarzalne incydenty i nieopisane obejścia, które są w każdym systemie działającym od kilkunastu lat. Od drugiego miesiąca odpowiadamy za uzgodniony zakres, a co miesiąc przekazujemy raport dla CIO, raz na kwartał zaś omawiamy przegląd usługi z zarządem albo komitetem sterującym.
Jak sprawdzić dostawcę SAP Basis przed podpisaniem umowy
Prezentacja handlowa niewiele powie o jakości utrzymania. Więcej powiedzą odpowiedzi na kilka pytań:
1. Jak wygląda Wasz codzienny przegląd systemu i czy możemy zobaczyć przykładowy raport?
2. Kto konkretnie odbiera alert w nocy i jaka jest ścieżka eskalacji do specjalisty od bazy danych?
3. Jak oceniacie noty z SAP Security Patch Day i ile dni mija u Waszych klientów od publikacji noty HotNews do jej wdrożenia na produkcji?
4. Kto reaguje na alerty bezpieczeństwa i czy jest to ten sam zespół, który wprowadza zmiany w konfiguracji?
5. Na jakim narzędziu będziecie monitorować nasz system po zakończeniu standardowego utrzymania SAP Solution Manager?
6. Co przekażecie nam przy zakończeniu umowy?
Pełniejszą wersję tych pytań, razem z zakresem usługi, klasami incydentów i kryteriami wyjścia, zebraliśmy w liście kontrolnej przejęcia utrzymania SAP Basis do pobrania.
Co robimy w SNOK
Prowadzimy SAP Basis 24/7 w modelu managed service: monitoring, poprawki i SAP Security Notes, strojenie wydajności, zarządzanie zmianą i transportami, administrację SAP HANA oraz obsługę incydentów przez całą dobę. Opcjonalnie dokładamy monitoring bezpieczeństwa SecurityBridge, hardening konfiguracji i okresowe testy penetracyjne SAP. Utrzymujemy systemy on-premise i w chmurze, także w modelu RISE with SAP, a przy przejściu z SAP ECC wspieramy konwersję do SAP S/4HANA. Warstwę systemu operacyjnego i sprzętu znamy z partnerstw z SUSE i Lenovo.
Jeżeli przygotowujecie zmianę modelu utrzymania albo dostawcy, zacznijcie od listy kontrolnej przejęcia utrzymania SAP Basis. Gdy będziecie gotowi na rozmowę, umówcie 30 minut z naszym zespołem. Omówimy obecny krajobraz SAP, wymagane SLA i to, co powinno wejść do zakresu. Szerszy kontekst bezpieczeństwa systemów SAP opisujemy w książce Cyberbezpieczeństwo SAP od A do Z.
Źródła
- ITwiz, Udany atak na systemy SAP może zatrzymać każdy biznes, Executive ViewPoint (prezentacja partnera), 26 czerwca 2025 - itwiz.pl
- SAP, SAP Solution Manager 7.2 - informacja o utrzymaniu i przejściu do SAP Cloud ALM, SAP Note 3255311 - support.sap.com (dostęp 6 października 2026)
- SAP Community, Jana Subramanian, RISE with SAP S/4HANA Cloud, Private Edition: Cybersecurity FAQ Explained - community.sap.com
- SNOK, case study Krytyczne ERP pod ochroną 24/7 - bez powiększania zespołu IT klienta - snok.ai