Sponsor finansowy otrzymuje propozycję odroczenia migracji z ECC, ponieważ „wsparcie SAP potrwa wystarczająco długo”. Zanim zaakceptuje tę propozycję, CIO musi ustalić, które zainstalowane wersje są objęte wsparciem, na podstawie jakiej umowy i czy planowana ścieżka migracji pozostaje wykonalna. Sama data zakończenia wsparcia nie odpowiada na żadne z tych pytań.
Rzetelnym wynikiem planowania wsparcia SAP ECC powinny być rejestr okresów i zakresu wsparcia oraz wyznaczony termin decyzji o finansowaniu. Ochronę zapewnianą przez dostawcę, możliwość dalszej eksploatacji, obowiązki dotyczące bezpieczeństwa i gotowość do migracji traktuj jako odrębne obszary wymagające zatwierdzenia. Odroczenie jest uzasadnione tylko wtedy, gdy te zatwierdzenia na nie pozwalają. Rozpoczęcie migracji jest uzasadnione tylko wtedy, gdy program ma wykonalny zakres i harmonogram.
Ustal zakres wsparcia dla konkretnej wersji, a nie ogólny termin
W podsumowaniu warunków handlowych rozszerzonego wsparcia SAP rozróżnia wersje SAP ERP 6.0: standardowe wsparcie dla systemów z pakietem rozszerzeń starszym niż enhancement package 6 kończy się 31 grudnia 2025 r., natomiast dla pakietów rozszerzeń 6–8 trwa do 31 grudnia 2027 r. Nie przypisuj późniejszej daty wszystkim instalacjom ECC.
Zacznij od inwentaryzacji zainstalowanych produktów, za którą odpowiada zespół aplikacyjny SAP. Zapisz dokładną wersję produktu i pakiet rozszerzeń, a następnie sprawdź odpowiadające im informacje o wsparciu. SAP wskazuje Product Availability Matrix, czyli PAM, jako miejsce weryfikacji okresów wsparcia poszczególnych produktów i wersji. Zachowaj wykorzystany wpis, wersję dokumentu, jeśli jest dostępna, oraz datę sprawdzenia.
Poniższy arkusz wypełnij dla każdego zainstalowanego produktu lub zależnego komponentu. Pozostaw nierozstrzygnięte pozycje wyraźnie oznaczone, zamiast przypisywać całemu środowisku domniemaną datę wygaśnięcia wsparcia.
| Pole rejestru | Dokumentacja do zachowania | Rola odpowiedzialna |
|---|---|---|
| Zakres instalacji | Produkt, wersja, pakiet rozszerzeń, instalacja i obsługiwane procesy biznesowe | Właściciel aplikacji SAP |
| Status wsparcia | Odpowiedni wpis w PAM, potwierdzone daty ochrony i data weryfikacji | Właściciel platformy SAP |
| Ochrona umowna | Obowiązująca umowa wsparcia, aneks, zakres ochrony i warunki handlowe | Dział zakupów i dział prawny |
| Eksploatacja i bezpieczeństwo | Wsparcie komponentów zależnych, wymagane mechanizmy kontrolne, dowody możliwości odtworzenia i zaakceptowane wyjątki | Osoby odpowiedzialne za eksploatację i bezpieczeństwo |
| Nierozstrzygnięte zależności | Przeszkoda, potrzebne dowody, osoba odpowiedzialna za rozwiązanie i termin | Kierownik migracji |
| Harmonogram decyzji | Najpóźniejszy bezpieczny termin decyzji, termin zatwierdzenia finansowania i założenia stojące za obydwoma | CIO i sponsor finansowy |
Dowody odnoszące się do konkretnej wersji powinny również decydować o każdej propozycji usprawniania ECC przy jednoczesnym odraczaniu migracji. Ramy oceny inwestycji w usprawnienie lub wymianę ERP wymagają potwierdzenia możliwości dla zainstalowanej wersji i odpowiednich warunków handlowych, zamiast akceptowania ogólnego stwierdzenia, że produkt obsługuje dany proces. Taką samą dyscyplinę zastosuj wobec zapewnień, że obecne środowisko może bezpiecznie pozostać w eksploatacji.
Odróżnij dostępną ofertę od założenia, że wsparcie zostanie przedłużone
Opublikowane przez SAP podsumowanie opisuje opcjonalne rozszerzone wsparcie od 1 stycznia 2028 r. do 31 grudnia 2030 r. W przypadku klientów on-premises wymaga ono odrębnego aneksu do aktywnej umowy wsparcia SAP i obejmuje całe środowisko podstawowych aplikacji Business Suite 7 objęte zakresem handlowym. Dostępność opcji nie dowodzi, że firma ją zakontraktowała.
Sposób naliczania ceny ma znaczenie dla uzasadnienia finansowania. SAP wskazuje dodatkowe dwa punkty procentowe naliczane od podstawy opłat za utrzymanie objętych ochroną aplikacji podstawowych i dodatków, a nie po prostu wzrost obecnej faktury za wsparcie o dwa procent. Poproś dział zakupów o uzgodnienie podstawy naliczenia i zakresu z oferty z danymi w rejestrze. Nieobjaśniona „rezerwa na rozszerzone wsparcie” nie jest wystarczającym założeniem budżetowym.
Późniejsze rozwiązania przejściowe rozpatruj oddzielnie. We wskazówkach dotyczących planowania po zakończeniu rozszerzonego wsparcia SAP opisuje Transition Option for SAP ERP jako subskrypcję dostępną pod określonymi warunkami dla kwalifikujących się dużych klientów o złożonych środowiskach, których transformacja już trwa. Ma ona obejmować lata 2031–2033. Systemy muszą zostać przeniesione do SAP ERP, private edition na SAP HANA przed 31 grudnia 2030 r.; obowiązują dodatkowe kryteria kwalifikacji, a funkcje zależne od Javy są wyłączone.
Nie jest to bezwarunkowe przedłużenie wsparcia dla niezmienionego środowiska ECC on-premises. Jeżeli propozycja odroczenia od niego zależy, przed uwzględnieniem go w zatwierdzonym harmonogramie wymagaj potwierdzenia kwalifikacji, możliwości złożenia zamówienia, ceny, objętych funkcji i wiążących warunków.
Następnie uzyskaj odrębne decyzje dotyczące eksploatacji i bezpieczeństwa. Poproś zespół utrzymania o wykazanie możliwości odtworzenia systemów i wskazanie odpowiedzialności za krytyczne zależności. Poproś zespół bezpieczeństwa o określenie wymaganych poprawek i mechanizmów kontrolnych oraz ocenę, czy proponowany model wsparcia zapewnia to, czego wymagają te obowiązki. Nie pozwól, by uprawnienie do wsparcia zastępowało którekolwiek z tych zatwierdzeń.
Planuj wstecz od ograniczeń wybranej ścieżki migracji
Najpóźniejszy bezpieczny termin uruchomienia finansowania należy wyliczyć na podstawie prac i ograniczeń, a nie ustalać przez odjęcie ogólnego czasu trwania migracji od daty wygaśnięcia wsparcia. Najpierw określ planowaną ścieżkę przejścia i środowisko docelowe. Następnie wymagaj od zespołu realizacyjnego wskazania warunków wstępnych, szacunków, kolejności prac i niepewności właściwych dla danego środowiska.
Ograniczenie ścieżki migracji może być rozstrzygające niezależnie od uprawnień do wsparcia. SAP informuje, że narzędzia do konwersji systemów Business Suite 7 działających na bazach danych innych dostawców będą dostępne wyłącznie przed wygaśnięciem odpowiednich umów odsprzedaży i wsparcia z końcem 2030 r. Później wspierane będą tylko scenariusze greenfield, czyli nowe wdrożenia. W przypadku środowiska objętego tym ograniczeniem propozycja odroczenia musi zatem wyjaśniać, czy planowana konwersja pozostaje wykonalna w tym terminie.
Poproś zespół o przygotowanie harmonogramu opartego na zależnościach, obejmującego:
- Sprawdzenie zgodności wersji i środowiska docelowego, w tym zainstalowanych dodatków oraz połączonych aplikacji.
- Ocenę kodu niestandardowego i decyzje o jego dalszym wykorzystaniu, z przypisaniem nierozstrzygniętych decyzji biznesowych do odpowiedzialnych osób.
- Przygotowanie danych, zmiany interfejsów i dowody odbioru procesów od początku do końca.
- Infrastrukturę, zatwierdzenia handlowe, dostępność pracowników wewnętrznych i zobowiązania realizacyjne.
- Próby migracji, dopuszczalne okna przełączenia produkcyjnego, plan odtworzenia i stabilizację.
Są to wymagania dotyczące oceny, a nie stwierdzenie, że każdy program wymaga identycznych prac. W przypadku zachowywanych funkcji niestandardowych przeprowadź odrębną ocenę umiejscowienia rozszerzeń SAP, aby rozstrzygnąć, gdzie powinny działać. Nierozwiązane przeszkody i szacunki z tej oceny uwzględnij w harmonogramie, nie zamieniając planowania wsparcia w szczegółowe projektowanie architektury.
Planuj wstecz przez krytyczne zależności, uwzględniając wyraźnie zatwierdzoną rezerwę na nierozstrzygnięte prace. Zapisz, kiedy trzeba udostępnić finansowanie, a nie tylko kiedy program powinien się zakończyć. Jeżeli warunek wstępny nie ma właściciela lub wiarygodnego oszacowania, wynikający z niego termin decyzji pozostaje tymczasowy.
Wybierz rozpoczęcie prac teraz albo odroczenie na określony czas
Rozpoczęcie prac teraz jest lepszym wyborem, gdy potwierdzony okres wsparcia lub ograniczenia ścieżki migracji nie pozostawiają wystarczająco dużo czasu na plan oparty na zależnościach albo gdy wymagań dalszej eksploatacji nie da się spełnić na akceptowalnych warunkach. „Rozpoczęcie” nie musi oznaczać natychmiastowego zatwierdzenia całego wdrożenia. Jeśli istotna niepewność może zmienić ścieżkę, sfinansuj ocenę o ograniczonym zakresie, z określonym rezultatem i punktem decyzyjnym.
Odroczenie na określony czas jest uzasadnione, gdy ochrona umowna została potwierdzona, osoby odpowiedzialne za eksploatację i bezpieczeństwo akceptują dalsze obowiązki, a wiarygodny harmonogram opracowany wstecz zachowuje wykonalność planowanej ścieżki przejścia. Zatwierdzenie odroczenia powinno wskazywać, co firma zyskuje dzięki oczekiwaniu, co musi w tym czasie finansować i jakie zdarzenia wymuszą wcześniejszą decyzję.
Porównaj obydwa warianty względem tych samych wymaganych rezultatów biznesowych i tego samego horyzontu planowania. W wariancie odroczenia uwzględnij prace przejściowe, dalszą eksploatację i późniejszą migrację. Dla rozpoczęcia prac teraz wymagaj jawnych założeń dotyczących dostępności zespołu wewnętrznego i zależności realizacyjnych, zamiast traktować wcześniejszy start jako dowód mniejszego ryzyka.
Podczas najbliższej decyzji o finansowaniu zestaw rejestr wsparcia z harmonogramem opracowanym wstecz. Zatwierdź migrację, zatwierdź odroczenie z określoną datą i warunkami albo zleć ograniczoną ocenę konkretnej niepewności blokującej decyzję. Nie zatwierdzaj nieudokumentowanej daty wygaśnięcia wsparcia.
Jeśli potrzebujesz przełożyć tę decyzję na pakiety prac funkcjonalnych i technicznych, omów środowisko, zależności i wymagania migracyjne ze specjalistami SAP w Digiventi.
