# Outsourcing SAP Basis w Polsce - zakres, SLA i bezpieczeństwo > Co przejmuje dostawca SAP Basis, jak czytać SLA, kto w RISE with SAP odpowiada za poprawki i jak wpiąć SAP Security Patch Day w codzienne utrzymanie - Source: https://snok.ai/pl/aktualnosci/blog/outsourcing-sap-basis/ - Author: Jacek Bugajski - Published: 2026-10-07 --- **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. ![Codzienny przegląd systemu SAP w siedemnastu transakcjach, pogrupowanych w sześć obszarów: metadane, instancje i procesy, wydajność, kopie zapasowe, błędy i blokady, wyjścia i interfejsy - rdzeń przeglądu, nie pełna lista kontroli](https://snok.ai/images/blog/outsourcing-sap-basis-przeglad-pl.webp) 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](https://snok.ai/pl/aktualnosci/blog/bezpieczna-konwersja-sap-s4hana-rise/). ## 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](https://snok.ai/pl/oferta/bezpieczenstwo-sap/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](https://snok.ai/pl/aktualnosci/blog/hardening-sap-proces-nie-projekt/). Monitoring bezpieczeństwa SAP to druga warstwa nad monitoringiem technicznym. Platforma [SecurityBridge](https://snok.ai/pl/oferta/bezpieczenstwo-sap/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. ![Pulpit platformy SecurityBridge z wykrytymi zdarzeniami bezpieczeństwa w systemie SAP - zrzut z materiałów producenta](https://snok.ai/images/blog/outsourcing-sap-basis-securitybridge-pl.webp) Trzecia warstwa to okresowa kontrola z zewnątrz. [Test penetracyjny SAP](https://snok.ai/pl/oferta/bezpieczenstwo-sap/pentesty-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. ![Rytm odpowiedzialności w utrzymaniu SAP: codzienny przegląd, comiesięczny SAP Security Patch Day i raport, kwartalny przegląd usługi, coroczny test penetracyjny, a przez całą dobę alerty bezpieczeństwa](https://snok.ai/images/blog/outsourcing-sap-basis-rytm-pl.webp) ## 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](https://snok.ai/pl/realizacje/#producent-fmcg-bezpieczne-erp). 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](https://snok.ai/pl/materialy/lista-kontrolna-przejecia-sap-basis/) do pobrania. ## Co robimy w SNOK Prowadzimy [SAP Basis 24/7 w modelu managed service](https://snok.ai/pl/oferta/bezpieczenstwo-sap/sap-basis-24-7/): 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](https://snok.ai/pl/oferta/bezpieczenstwo-sap/konwersja-s4hana/). Warstwę systemu operacyjnego i sprzętu znamy z partnerstw z [SUSE](https://snok.ai/pl/suse-snok/) i [Lenovo](https://snok.ai/pl/lenovo-snok/). Jeżeli przygotowujecie zmianę modelu utrzymania albo dostawcy, zacznijcie od [listy kontrolnej przejęcia utrzymania SAP Basis](https://snok.ai/pl/materialy/lista-kontrolna-przejecia-sap-basis/). Gdy będziecie gotowi na rozmowę, [umówcie 30 minut z naszym zespołem](https://snok.ai/pl/oferta/bezpieczenstwo-sap/sap-basis-24-7/). 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](https://snok.ai/pl/materialy/cyberbezpieczenstwo-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](https://itwiz.pl/udany-atak-na-systemy-sap-moze-zatrzymac-kazdy-biznes/) - SAP, *SAP Solution Manager 7.2* - informacja o utrzymaniu i przejściu do SAP Cloud ALM, SAP Note 3255311 - [support.sap.com](https://support.sap.com/en/alm/solution-manager.html) (dostęp 6 października 2026) - SAP Community, Jana Subramanian, *RISE with SAP S/4HANA Cloud, Private Edition: Cybersecurity FAQ Explained* - [community.sap.com](https://community.sap.com/t5/technology-blog-posts-by-sap/rise-with-sap-s-4hana-cloud-private-edition-cybersecurity-faq-explained/ba-p/13562875) - SNOK, case study *Krytyczne ERP pod ochroną 24/7 - bez powiększania zespołu IT klienta* - [snok.ai](https://snok.ai/pl/realizacje/#producent-fmcg-bezpieczne-erp)