Modernizacja systemu ERP rzadko sprowadza się do zmiany serwera. W praktyce chodzi o to, czy firma potrafi szybciej zamykać miesiąc, lepiej zarządzać danymi, utrzymać zgodność z lokalnymi wymogami i przygotować procesy pod automatyzację oraz AI. Właśnie dlatego RISE with SAP jest dziś tak ważnym tematem w rozmowach o systemach biznesowych, bo łączy migrację do chmury z przebudową sposobu działania firmy. Wyjaśniam, czym ta ścieżka naprawdę jest, kiedy ma sens, czym różni się od prostszego wejścia do cloud ERP i gdzie najłatwiej przepalić budżet.
Najważniejsze fakty, które porządkują decyzję
- RISE with SAP to nie pojedynczy produkt, tylko prowadzona ścieżka transformacji do cloud ERP z narzędziami, metodologią i wsparciem.
- Najlepiej sprawdza się u firm, które mają już SAP i chcą przenieść złożony krajobraz do chmury bez utraty kontroli nad kluczowymi procesami.
- W projekcie największe znaczenie mają nie licencje, ale zakres procesów, custom code, integracje, dane i zmiana organizacyjna.
- Jeśli firma startuje od zera, często prostszy i szybszy będzie GROW with SAP.
- Dla organizacji utrzymujących stare środowiska SAP ważne są terminy maintenance, bo mainstream maintenance dla Business Suite 7 kończy się z końcem 2027, a opcjonalne extended maintenance trwa do końca 2030.
- Największy błąd to traktowanie tej zmiany jak zwykłego hostingu zamiast pełnej modernizacji ERP.
Czym jest RISE with SAP i co faktycznie obejmuje
RISE with SAP to przede wszystkim ścieżka transformacji, a nie pojedyncza licencja. W praktyce łączy ERP, środowisko chmurowe, metodykę wdrożenia, narzędzia migracyjne i wsparcie eksperckie tak, aby przenieść istniejący krajobraz SAP do modelu cloudowego bez utraty ciągłości działania. Dzisiaj oferta jest mocno skojarzona z SAP Cloud ERP Private, czyli wariantem dla organizacji, które potrzebują większej kontroli, głębi procesowej i stabilności operacyjnej.
To ważne rozróżnienie, bo wiele firm myli przeniesienie systemu do chmury z pełną modernizacją. Samo ulokowanie SAP-a na infrastrukturze chmurowej nie rozwiązuje problemu złożonych integracji, przestarzałych rozszerzeń i kosztownego utrzymania. W tej ofercie chodzi o coś więcej, o przebudowę całego modelu działania, tak aby ERP był łatwiejszy w rozwoju, bardziej odporny na zmiany i gotowy pod AI.
Dlaczego clean core ma znaczenie
W tym kontekście często wraca pojęcie clean core, czyli utrzymywanie rdzenia systemu możliwie blisko standardu i przenoszenie niestandardowych rozszerzeń poza samą „głowę” ERP. W praktyce oznacza to mniej chaotycznych modyfikacji, prostsze aktualizacje i mniejszy dług technologiczny. Nie chodzi o wycięcie wszystkich dostosowań, tylko o ich rozsądne uporządkowanie.
Jeśli ten model brzmi sensownie, kolejne pytanie brzmi już nie „co to jest”, ale dla kogo naprawdę działa najlepiej.
Dla kogo ta ścieżka ma sens, a kiedy lepszy będzie prostszy start
Najczęściej RISE with SAP wybierają organizacje, które mają już za sobą lata pracy na SAP ECC albo rozbudowanym SAP S/4HANA on-premises i nie chcą budować systemu od zera. To dobry kierunek, gdy firma ma wiele integracji, własne procesy branżowe, kilka krajów działania albo potrzebuje zachować większą kontrolę niż w mocno standaryzowanej publicznej chmurze. Dla takich organizacji ten model jest po prostu bardziej realistyczny niż „czyste” startowanie od nowa.
- Ma sens, gdy chcesz przenieść istniejący ERP do chmury, ale nie wyrzucać całej logiki biznesowej do kosza.
- Ma sens, gdy firma potrzebuje modernizacji, a nie tylko zmiany infrastruktury.
- Ma sens, gdy priorytetem są kontrola, bezpieczeństwo, rozwój procesów i możliwość stopniowego porządkowania systemu.
- Ma mniejszy sens, gdy startujesz jako nowy klient SAP i zależy ci głównie na szybkim, przewidywalnym wdrożeniu standardowego ERP.
Właśnie dlatego w rozmowach o ofertach cloudowych nie można stawiać wszystkich scenariuszy w jednym worku. Jeśli firma zaczyna od zera, prostszy model wdrożenia zwykle wygrywa. Jeśli jednak ma ciężki, ale krytyczny biznesowo krajobraz SAP, RISE bywa najuczciwszą drogą do chmury. Skoro to ustaliliśmy, czas zobaczyć, jak taki projekt wygląda od środka.
Jak wygląda wdrożenie od analizy do startu produkcyjnego
W projektach tego typu nie patrzę na wdrożenie jak na instalację systemu, tylko jak na zmianę modelu operacyjnego. Najwięcej ryzyka pojawia się nie na etapie uruchomienia, lecz dużo wcześniej, przy ocenie tego, co naprawdę trzeba przenieść, uprościć albo przepisać. SAP mocno akcentuje dziś zestaw AI-assistowanych działań, które mają przyspieszyć tę drogę, ale nawet najlepsze narzędzia nie zastąpią dobrej selekcji zakresu.
1. Audyt stanu obecnego
Najpierw trzeba rozebrać obecny krajobraz na części: procesy, integracje, custom code, dane i zależności między systemami. To etap, na którym wychodzi, co jest faktycznie krytyczne dla biznesu, a co tylko historycznie zostało dopisane do systemu i dziś generuje koszt bez wartości.
2. Uporządkowanie procesu i zakresu
Na tym etapie projektuje się docelowy model działania, najlepiej z myślą o clean core. W praktyce oznacza to decyzje o tym, które procesy zostają standardowe, które wymagają rozszerzeń, a które warto zlikwidować. Tu właśnie powstaje największa różnica między projektem „odświeżania starego SAP-a” a realną transformacją ERP.
Przeczytaj również: ATS - co to jest i jak działa? Zrozum rekrutację!
3. Dane, testy i rollout
Najwięcej czasu potrafią zjeść nie same techniczne migracje, ale dane, testy i przygotowanie ludzi. W tym obszarze SAP rozwija dziś zestaw asystentów do analizy systemu, modernizacji custom code, przygotowania danych, optymalizacji konfiguracji, testów, rolloutów i zarządzania projektem. To przydatne, ale nadal trzeba pilnować jakości danych źródłowych i sensu biznesowego zmian, bo automatyzacja nie naprawi złych decyzji projektowych.
Im większa liczba krajów, integracji i wyjątków procesowych, tym ważniejsze staje się to uporządkowanie. A skoro zakres ma aż tak duży wpływ na powodzenie, naturalnie pojawia się pytanie o koszt i czas.
Co naprawdę wpływa na koszt i czas projektu
Wycena RISE with SAP nie ma jednego cennika, bo to nie jest produkt sprzedawany w próżni. Koszt zależy od skali organizacji, liczby systemów do połączenia, ilości customizacji, jakości danych i tego, ile pracy trzeba włożyć w zmianę nawyków użytkowników. Najdroższy błąd, jaki widuję, to liczenie wyłącznie subskrypcji i pomijanie reszty projektu.
| Element kosztu | Dlaczego podnosi budżet | Co sprawdzić przed startem |
|---|---|---|
| Custom code | Każdy stary fragment logiki trzeba ocenić, przepisać albo zrezygnować z niego. | Co jest naprawdę krytyczne, a co można zastąpić standardem lub rozszerzeniem poza rdzeniem. |
| Integracje | Każde połączenie z CRM, WMS, BI, bankami lub EDI wymaga projektu, testów i utrzymania. | Ile integracji jest biznesowo niezbędnych, a ile da się uprościć. |
| Dane | Złe dane wydłużają migrację i zwiększają liczbę poprawek po starcie. | Kto odpowiada za master data, archiwizację i czyszczenie rekordów. |
| Zmiana organizacyjna | Bez szkolenia i komunikacji użytkownicy będą pracować „starym” sposobem na nowym systemie. | Czy masz superuserów, plan szkoleń i realny model wsparcia po go-live. |
| Lokalne wymagania | W Polsce i w innych krajach trzeba uwzględnić raportowanie, podatki i integracje zgodne z lokalnym prawem. | Czy wariant chmurowy obsłuży wymogi lokalne bez nadmiernych obejść. |
Warto też pamiętać o tle technicznym. SAP utrzymuje mainstream maintenance dla Business Suite 7 do końca 2027, a później dostępne jest opcjonalne extended maintenance do końca 2030, ale już z premią 2 punkty procentowe na bazie maintenance. Dla wielu firm to nie jest ciekawostka, tylko realny termin, który wymusza decyzję o tempie transformacji. To właśnie dlatego rozmowa o kosztach nie może być oderwana od kalendarza.
Skoro czas i budżet są tak mocno związane z architekturą, kolejnym naturalnym porównaniem jest zestawienie tej ścieżki z innymi wariantami cloud ERP.
RISE with SAP, GROW with SAP i klasyczny ERP w jednym zestawieniu
Najwięcej nieporozumień rodzi porównanie RISE z GROW with SAP. To nie są dwie wersje tego samego produktu, tylko dwie różne ścieżki dla różnych typów firm. RISE jest bardziej transformacyjny, GROW bardziej startowy, a klasyczny on-prem daje największą autonomię, ale też największy ciężar utrzymania.
| Kryterium | RISE with SAP | GROW with SAP | Klasyczny ERP / IaaS |
|---|---|---|---|
| Dla kogo | Firmy z istniejącym SAP, które modernizują złożony krajobraz i przechodzą do chmury etapami. | Nowi klienci SAP albo organizacje, które chcą szybciej ruszyć z bardziej standardowym cloud ERP. | Firmy potrzebujące pełnej kontroli lub jeszcze niegotowe na głębszą zmianę modelu działania. |
| Główna korzyść | Managed cloud, większa kontrola nad złożonością i wyraźna ścieżka modernizacji. | Szybszy start, większa przewidywalność i mniej ciężaru po stronie projektu. | Pełna swoboda techniczna, ale bez korzyści wynikających z nowego modelu cloudowego. |
| Zakres zmian | Najczęściej głęboka transformacja procesów, danych, integracji i rozszerzeń. | Bardziej standaryzowany start, mniej wyjątków i krótsza ścieżka do uruchomienia. | Zmiany zależą wyłącznie od wewnętrznej decyzji firmy i dostępnego zespołu. |
| Największe ryzyko | Próba przeniesienia starego chaosu do nowej chmury. | Niedoszacowanie ograniczeń standardu, gdy firma ma zbyt dużo wyjątków. | Rosnący koszt utrzymania, wolniejsze innowacje i większa zależność od lokalnych zasobów. |
Jeśli startujesz od zera, GROW zwykle daje lepszy stosunek wysiłku do efektu. Jeśli masz już SAP i wiesz, że procesy są zbyt złożone, by je po prostu odtworzyć w standardzie, RISE staje się rozsądniejszą drogą. Właśnie tu kończy się marketing, a zaczyna uczciwa analiza potrzeb firmy.
Najczęstsze błędy, które podnoszą ryzyko projektu
Najczęściej widzę cztery błędy, które psują projekty jeszcze zanim system trafi na produkcję. Żaden z nich nie jest spektakularny, właśnie dlatego są tak groźne. To zwykle nie technologia zawodzi, tylko oczekiwania i sposób prowadzenia zmiany.
- Mylenie transformacji z hostingiem. Jeśli projekt sprowadza się do przeniesienia systemu „do chmury”, a nie do przebudowy procesów, firma płaci za zmianę adresu, nie za zmianę jakości działania.
- Trzymanie wszystkiego w custom code. Stare rozszerzenia często przestały być przewagą, a stały się kosztownym balastem. Każdy taki fragment trzeba obronić biznesowo, nie historycznie.
- Pomijanie danych. Złe dane wracają po go-live jak bumerang, bo powodują błędy w raportowaniu, planowaniu i rozliczeniach.
- Zbyt późne włączenie biznesu. Jeśli projekt prowadzi wyłącznie IT, użytkownicy końcowi będą szukać obejść zamiast korzystać z nowego modelu pracy.
- Brak decyzji o zakresie lokalnym. W firmach działających w Polsce trzeba od początku ustalić, jak system obsłuży lokalne raportowanie, podatki i integracje finansowe.
W praktyce oznacza to jedno: zanim podpiszesz ofertę, trzeba wiedzieć nie tylko, co kupujesz, ale też czego świadomie nie robisz. I to prowadzi do ostatniego, najbardziej praktycznego sprawdzenia.
Co sprawdzić w polskiej firmie, zanim podpiszesz ofertę
Ja zaczynam zawsze od czterech pytań. Pierwsze brzmi: które procesy są naprawdę krytyczne i nie mogą zostać uproszczone bez szkody dla biznesu. Drugie: czy potrzebujesz większej elastyczności, czy raczej szybkiego, przewidywalnego startu. Trzecie: jakie lokalne wymagania muszą być obsłużone od pierwszego dnia. Czwarte: czy organizacja ma ludzi, którzy dowiozą zmianę po stronie biznesu, a nie tylko po stronie IT.
- Procesy krytyczne - oddziel to, co różnicuje firmę, od tego, co można ustandaryzować.
- Wariant chmury - sprawdź, czy potrzebujesz bardziej elastycznego private edition, czy wystarczy bardziej standardowy model.
- Lokalizacja i compliance - upewnij się, że rozwiązanie obsłuży polskie wymagania raportowe, podatkowe i integracyjne.
- Gotowość organizacyjna - oceń, czy masz sponsorów biznesowych, superuserów i plan na szkolenie użytkowników.
Jeśli te cztery obszary są uporządkowane, decyzja o wejściu w RISE with SAP staje się znacznie prostsza i mniej emocjonalna. Wtedy nie kupujesz obietnicy „nowoczesności”, tylko konkretną ścieżkę modernizacji ERP, która ma szansę naprawdę poprawić sposób działania firmy. I właśnie taką decyzję warto podejmować w systemach biznesowych: na podstawie procesu, danych i ryzyka, a nie samej etykiety produktu.
