SAP Cloud ERP – subskrypcja czy on-premise?

Pytania, na które odpowiadamy w tekście

Ten tekst nie tłumaczy od zera, czym jest SAP. Zakładamy, że organizacja ma system, zespół IT, własne procedury i doświadczenie w utrzymaniu środowiska SAP. Być może ma też obawy przed zmianą modelu. Dlatego skupiamy się na konkretnych pytaniach:

• kto odpowiada za aktualizacje wersji w SAP Cloud ERP Private,
• co zmienia się w pracy zespołu SAP Basis,
• kto ma dostęp do danych przetwarzanych w systemie SAP,
• jak wygląda SLA,
• co z kopiami zapasowymi i Disaster Recovery,
• jak działają integracje,
• jak szybko można zwiększyć zasoby,
• czy zgłoszenie serwisowe oznacza czekanie,
• czy SAP ma dostęp do danych biznesowych,
• co zostaje po stronie organizacji,
• czy TCO dla on-premise i subskrypcji jest policzone uczciwie.

System ERP nie funkcjonuje dziś jako osobna wyspa. W komunikacji SAP coraz częściej pojawia się szerszy obraz: SAP Business Suite, w którym ERP jest centralnym elementem architektury IT. Wokół niego działają rozwiązania branżowe (ecosystem solutions) dostarczane przez partnerów SAP, narzędzia transformacyjne, w tym rozwiązania automatyzujące biznes, wspierające cyfrową zmianę w firmach oraz oczywiście wiele agentów AI. Podstawą technologiczną jest SAP Business Technology Platform, a analityka danych jest zorganizowana przez SAP Business Data Cloud.

W tym kontekście warto osadzić SAP Cloud ERP Private, SAP S/4HANA on-premise, RISE with SAP i GROW with SAP. Bo w praktyce rozmowa nie dotyczy samej nazwy produktu. Dotyczy tego, w jakim modelu organizacja chce rozwijać i utrzymywać swoje środowisko SAP.

SAP Cloud ERP Private to aktualna nazwa rozwiązania znanego wcześniej jako SAP S/4HANA Cloud, Private Edition. (W dalszej części tekstu używamy nazwy SAP Cloud ERP Private).

Punktem odniesienia jest SAP S/4HANA on-premise. To model, w którym organizacja, jej zespół IT oraz partnerzy odpowiadają za większą część środowiska: infrastrukturę, operacje techniczne, utrzymanie systemu i organizację pracy wielu dostawców.

RISE with SAP nie jest po prostu nazwą systemu. To ścieżka przejścia dla firm, które mają już SAP ERP i chcą modernizować środowisko w kierunku SAP Cloud ERP Private.

GROW with SAP dotyczy przede wszystkim nowych wdrożeń SAP ERP, najczęściej w modelu public cloud. W tym tekście nie rozwijamy tego wątku. Skupiamy się na decyzji, przed którą stoją firmy z SAP ECC albo SAP S/4HANA on-premise.

Zakres funkcjonalny systemu ERP w obu modelach może być bardzo zbliżony. Mówimy o obszarach takich jak finanse, zakupy, łańcuch dostaw, produkcja, sprzedaż, usługi czy zarządzanie majątkiem.

Różnica nie zaczyna się więc od pytania: „czy to nadal SAP ERP?”. Tak, nadal mówimy o systemie ERP SAP opartym na SAP S/4HANA. Różnica zaczyna się w modelu działania.

W SAP S/4HANA on-premise organizacja musi zapewnić wiele warstw samodzielnie albo z pomocą partnerów. Chodzi m.in. o data center, infrastrukturę, system operacyjny, bazę danych, kopie zapasowe, monitoring, bezpieczeństwo, aktualizacje wersji i wsparcie techniczne.

W SAP Cloud ERP Private część tych elementów jest objęta subskrypcją. SAP odpowiada za określone warstwy techniczne i operacyjne. Po stronie organizacji nadal zostają dane, procesy, konfiguracja, użytkownicy, role, uprawnienia i warstwa aplikacyjna.

To jest sedno porównania.

Nie: „licencja kontra subskrypcja”. Raczej: „które zadania zostają u nas, które przejmuje SAP i ile to wszystko kosztuje w perspektywie kilku lat”.

Jedną z różnic w modelu SAP Cloud ERP Private jest metryka użytkowników. SAP używa tu pojęcia Full Use Equivalent, czyli FUE.

FUE pozwala przeliczać różne typy użytkowników w bardziej elastyczny sposób. Jeden FUE odpowiada jednemu użytkownikowi typu advanced use, pięciu użytkownikom typu core use albo trzydziestu użytkownikom typu self-service use. Dostęp deweloperski jest liczony inaczej: jeden użytkownik z Developer Access odpowiada dwóm FUE. To ważna zmiana dla firm przyzwyczajonych do klasycznego modelu licencyjnego.

W modelu FUE można inaczej zarządzać alokacją uprawnień. Użytkownik, który tylko podgląda dane albo wykonuje proste czynności samoobsługowe, nie musi być traktowany tak samo jak osoba z szerokim zakresem zadań w finansach, kontrolingu czy logistyce. W praktyce FUE wpływa nie tylko na licencje. Od liczby FUE zależy także bazowa wielkość infrastruktury oraz zakres niektórych elementów dostępnych w subskrypcji.

Dlatego analiza użytkowników powinna być jednym z pierwszych kroków przy porównaniu modeli.

W modelu SAP Cloud ERP Private subskrypcja obejmuje znacznie więcej niż samo prawo do korzystania z systemu. W jej zakresie mogą znaleźć się m.in. utrzymanie i wsparcie oprogramowania SAP, infrastruktura dla środowisk produkcyjnych i nieprodukcyjnych, wysoka dostępność, utrzymanie techniczne systemu, techniczne przygotowanie i uruchomienie środowiska, narzędzia bezpieczeństwa, certyfikacje, audyty oraz wsparcie osób odpowiedzialnych po stronie SAP za dostarczenie i obsługę usługi.

To właśnie ten zakres często umyka w prostych porównaniach kosztów.

Jeżeli zestawimy tylko cenę licencji on-premise z ceną subskrypcji, pominiemy dużą część obrazu. W SAP S/4HANA on-premise te elementy również są konieczne. Tylko trzeba je zapewnić inaczej: własnym zespołem, partnerem, dostawcą infrastruktury, osobną umową serwisową albo dodatkowymi narzędziami.

W SAP Cloud ERP Private część tych zadań jest zebrana w jednym modelu subskrypcyjnym. To nie usuwa odpowiedzialności działu IT. Zmienia jednak jej rozkład.

Przejście do SAP Cloud ERP Private nie oznacza, że SAP przejmuje wszystko. To ważne, bo w zespołach IT często pojawia się obawa przed „czarną skrzynką”.

Podział odpowiedzialności jest konkretny. SAP odpowiada za warstwę techniczną, infrastrukturę, bazę danych SAP HANA, system operacyjny, monitoring dostępności, kopie zapasowe i część zadań związanych z bezpieczeństwem.

Po stronie organizacji pozostają obszary, których dostawca chmury nie powinien przejmować. To przede wszystkim dane, procesy biznesowe i aplikacyjna część zarządzania systemem. Zespół odpowiedzialny za aplikację SAP nadal zarządza konfiguracją, rolami, autoryzacjami, użytkownikami, kontrolą dostępu, zgodnością z wymaganiami branżowymi i prawnymi oraz monitoringiem logów aplikacyjnych.

Inaczej mówiąc: SAP może przejąć wiele zadań technicznych, ale nie zarządza biznesem organizacji. Nie definiuje, kto ma dostęp do jakiego procesu. Nie odpowiada za to, czy role użytkowników są właściwie ustawione. Nie decyduje, jak mają działać procesy. To nadal jest po stronie firmy i jej działu IT.

To jedno z najczęstszych pytań w zespołach odpowiedzialnych za system. W SAP Cloud ERP Private organizacja otrzymuje odizolowany krajobraz systemowy. SAP zarządza infrastrukturą i warstwą techniczną, ale nie ma domyślnego dostępu do danych biznesowych przetwarzanych w systemie.

Dostęp do środowiska danej organizacji odbywa się przez warstwę aplikacyjną i wymaga autoryzacji. Podobnie jak w wielu obecnych scenariuszach wsparcia, gdy ekspert SAP potrzebuje dostępu, aby przeanalizować konkretne zgłoszenie.

W tym modelu SAP zarządza m.in. mandantem administracyjnym, infrastrukturą, systemem operacyjnym, bazą danych i warstwą techniczną. Dane biznesowe, w tym dane osobowe, pozostają po stronie organizacji.

To rozróżnienie jest istotne. Chmura nie oznacza, że dostawca „widzi wszystko”. Oznacza inny model technicznego zarządzania środowiskiem.

W analizach TCO najczęściej widać jeden problem: model on-premise bywa liczony zbyt wąsko. Do porównania trafia licencja, maintenance i podstawowa infrastruktura. Ale nie zawsze dolicza się wszystko, co faktycznie trzeba utrzymać.

W SAP S/4HANA on-premise trzeba uwzględnić także pełne koszty pracy zespołu technicznego, utrzymanie środowisk produkcyjnych i nieprodukcyjnych, narzędzia bezpieczeństwa, audyty, certyfikacje, kopie zapasowe, monitoring, aktualizacje wersji, zarządzanie wieloma dostawcami i czas osób po stronie IT.

To nie znaczy, że on-premise zawsze jest złym wyborem. Znaczy tylko tyle, że trzeba policzyć go uczciwie.

W prowadzonych przez firmę SAP analizach SAP Cloud ERP Private wykazywał o 20–30% niższy koszt TCO w perspektywie pięciu lat w porównaniu do SAP S/4HANA on-premise. To nie jest uniwersalna obietnica dla każdej firmy. To wynik konkretnych analiz i konkretnych założeń.

Dlatego porównanie warto przygotować dla własnego środowiska.

W SAP Cloud ERP Private SLA obejmuje cały stack rozwiązania. Nie chodzi tylko o dostępność pojedynczego elementu infrastruktury, ale o odpowiedzialność za aplikację SAP, bazę SAP HANA, system operacyjny i infrastrukturę.

Standardowe SLA dla systemów produkcyjnych wynosi 99,7%. Dostępna jest też opcja podniesienia do 99,9%.

Do tego dochodzą mechanizmy wysokiej dostępności (High Availability), które ograniczają ryzyko przerw wynikających z awarii pojedynczych komponentów. Odtwarzanie po awarii, czyli Disaster Recovery, jest oferowane opcjonalnie i dotyczy większych zdarzeń wpływających na podstawową lokalizację lub region.

Ważne są też kopie zapasowe. W standardowych politykach dla SAP Cloud ERP Private wskazano kopie online, retencję zależną od typu systemu oraz replikację kopii. Dla systemów produkcyjnych i nieprodukcyjnych parametry mogą być różne.

Dla IT oznacza to jedno: nie wystarczy zapytać, czy są kopie zapasowe. Trzeba wiedzieć, jaki jest model ich wykonywania, jaka jest retencja, co obejmuje wysoka dostępność, kiedy potrzebne jest Disaster Recovery i kto za to odpowiada.

W SAP S/4HANA on-premise aktualizacja wersji jest po stronie organizacji. Trzeba ją zaplanować, przygotować i wykonać technicznie albo zlecić partnerowi. Trzeba też przeprowadzić testy i upewnić się, że procesy biznesowe działają poprawnie.

W SAP Cloud ERP Private model jest inny. Część techniczna aktualizacji wersji jest wykonywana przez SAP w ramach subskrypcji, ale zespół IT nadal ma ważną rolę. To organizacja inicjuje aktualizację i uzgadnia okno serwisowe. Po jej stronie pozostaje sprawdzenie procesów biznesowych, kodu własnego, rozszerzeń, integracji i poprawności działania systemu po zmianie.

Podobnie jest z poprawkami technicznymi. SAP wykonuje określone zadania w warstwie technicznej, ale dział IT nadal zarządza zmianą w aplikacji i odpowiada za jej skutki biznesowe.

To nie jest model „SAP robi wszystko”. To model, w którym SAP przejmuje techniczne wykonanie części zadań, ale organizacja nadal decyduje o zmianach w systemie i odpowiada za ich wpływ na procesy. Dlatego warto zwrócić uwagę na sposób budowania rozszerzeń. Im więcej zmian realizowanych poza standardem i głęboko w systemie, tym trudniejsze mogą być kolejne aktualizacje. Rozszerzenia oparte na SAP Business Technology Platform i narzędziach takich jak SAP Build pomagają utrzymać czystszy rdzeń systemu, tzw. Clean Core, i łatwiej korzystać z nowych funkcji.

To pytanie wraca często. Szczególnie w zespołach technicznych, które są przyzwyczajone do prostego modelu: „idę do osoby od infrastruktury i proszę o szybką zmianę”.

W SAP Cloud ERP Private formalne zgłoszenie serwisowe jest potrzebne. Nie dlatego, że SAP chce wydłużać proces, ale dlatego, że zmiany w środowisku muszą być kontrolowane, audytowalne i zgodne z wymaganiami bezpieczeństwa. Nie oznacza to jednak, że każda sprawa zaczyna się od anonimowego zgłoszenia i czekania bez kontekstu. W modelu wsparcia występują konkretne role odpowiedzialne za dostarczenie i obsługę usługi. Zmiany można najpierw omówić operacyjnie, a zgłoszenie formalizuje proces.

To ważna różnica. Zgłoszenie serwisowe nie zastępuje kontaktu z zespołem. Jest śladem procesu, który musi istnieć ze względu na audyty, bezpieczeństwo i kontrolę zmian.

W rozmowie o SAP Cloud ERP Private bezpieczeństwo nie jest dodatkiem. Jest jednym z głównych elementów porównania.

SAP zarządza dużą liczbą systemów chmurowych w wielu branżach. Dzięki temu podatności, incydenty i wzorce ataków są analizowane w dużej skali. Wnioski z jednego miejsca mogą zostać wykorzystane do wzmocnienia zabezpieczeń w innych środowiskach.

W modelu cloud private część zadań bezpieczeństwa jest realizowana po stronie SAP. Dotyczy to m.in. bezpieczeństwa infrastruktury, monitoringu technicznego, zarządzania podatnościami, ochrony platformy, reagowania na incydenty i ciągłości działania. Nie oznacza to, że dział IT nie ma już nic do zrobienia. Nadal odpowiada za role, użytkowników, autoryzacje, logi aplikacyjne, dostęp do danych i zgodność ze swoimi wymaganiami branżowymi.

Ale część zadań, które w modelu on-premise trzeba zapewnić samodzielnie, w SAP Cloud ERP Private jest obsługiwana w ramach większego modelu bezpieczeństwa SAP.

Najpierw warto uporządkować architekturę. Potem użytkowników. Następnie odpowiedzialność. Dopiero później porównywać koszty.

Przed decyzją jest cała lista pytań do managerów SAP, heads of IT, specjalistów SAP Basis, administratorów SAP i osób odpowiedzialnych za utrzymanie systemu:

• Czy porównujemy samą licencję, czy cały model działania?
• Czy znamy aktualną strukturę użytkowników i możliwą alokację Full Use Equivalent?
• Czy wiemy, ile realnie kosztują infrastruktura, utrzymanie techniczne systemu, bezpieczeństwo i kopie zapasowe?
• Czy doliczyliśmy audyty, certyfikacje, monitoring i narzędzia bezpieczeństwa?
• Czy mamy plan aktualizacji wersji na kolejne lata?
• Czy wiemy, kto odpowiada za aplikację, dane, role i uprawnienia?
• Czy policzyliśmy koszt zarządzania wieloma dostawcami?
• Czy porównujemy ten sam poziom SLA, wysokiej dostępności, odtwarzania po awarii i wsparcia?

Bo decyzja o modelu ERP nie kończy się w dniu podpisania umowy. Ona wpływa na to, jak system będzie utrzymywany przez kolejne lata.

Nie ma jednego uniwersalnego wyniku dla wszystkich. Inaczej wygląda środowisko organizacji, która nadal pracuje na SAP ECC i planuje migrację. Inaczej firmy, która ma już SAP S/4HANA on-premise. Inaczej zespołu z rozbudowanymi kompetencjami SAP Basis, a inaczej działu IT, który większość usług technicznych zleca partnerom.

Dlatego najlepszym kolejnym krokiem jest analiza konkretnego scenariusza.

Warto porównać SAP Cloud ERP Private i SAP S/4HANA on-premise na podstawie własnej liczby użytkowników, obecnej infrastruktury, kosztów utrzymania, wymagań bezpieczeństwa, planów aktualizacji wersji i zakresu usług, które dziś wykonuje zespół IT albo zewnętrzni dostawcy.

Dopiero wtedy widać, co naprawdę jest w subskrypcji, co zostaje po stronie organizacji i jak wygląda TCO w perspektywie kilku lat.

Aleksander Rybicki, SAP RISE Sales Account Executive for Poland, and Czech, SAP Polska

Chcesz porównać scenariusze migracyjne dla swojej organizacji? Porozmawiajmy o analizie SAP Cloud ERP Private vs SAP S/4HANA on-premise. Konsultanci All for One, na podstawie wieloletnich doświadczeń w projektach migracji do chmury oraz świadczenia usług SAP Managed Services obejmujących pełen zakres profesjonalnych usług administracji i wsparcia serwisowego, wspierają swoich klientów w przygotowaniu analizy TCO wdrożenia i utrzymania systemu SAP w różnych modelach.

Zapytaj o szczegóły poprzez poniższy formularz kontaktowy.