O nasUsługiProjektyArtykuły
← Powrót do usług

Modernizacja ERP i wyjście z SAP ECC: inżynieria wokół migracji, której nikt nie wycenił

W każdej migracji ERP siedzą dwa projekty. Jest ten z planu (nowy system, projektowanie procesów, integrator), i jest ten, który wypływa w czwartym miesiącu, kiedy ktoś policzy interfejsy.

Ten drugi projekt należy do nas. Osiemdziesiąt autorskich integracji, raporty, na których stoją finanse i których nikt nie jest właścicielem, terminale magazynowe rozmawiające z widokiem bazodanowym, portal klienta czytający wprost ze starych tabel, dwadzieścia lat danych, które muszą trafić do nowego systemu w postaci, jaką ten zaakceptuje. Rzadko bywa w pierwotnym zakresie, a często decyduje o terminie.

Dlaczego to trafiło do kalendarza właśnie teraz

Utrzymanie podstawowe dla SAP ECC 6.0 kończy się 31 grudnia 2027 r. Utrzymanie rozszerzone może dowieźć firmę do końca 2030 r., za dopłatą i w węższym zakresie. Duża część zainstalowanej bazy jeszcze nie zaczęła, migracje trwają zwykle od osiemnastu do trzydziestu sześciu miesięcy, a partnerzy i moce hyperscalerów są rezerwowani już teraz.

Ta sama presja istnieje poza SAP-em. Klienci Oracle EBS mają własny horyzont wsparcia, instalacje Dynamics AX i NAV są wypychane w stronę Business Central i Dynamics 365, a długi ogon firm pracuje na ERP mocno dostosowanym dekadę temu przez ludzi, których od dawna już nie ma.

Niezależnie od kierunku kształt problemu jest ten sam: ERP nie jest wyspą, a to, co do niego przyklejono, zwykle nie ma dokumentacji.

Co robimy

Rozpoznanie i inwentaryzacja interfejsów

Zanim cokolwiek da się zaplanować, ktoś musi ustalić, co naprawdę rozmawia z ERP-em. Robimy to empirycznie (czytając logi bazy danych, ruch sieciowy, zadania harmonogramowane, konfigurację middleware'u integracyjnego i kod źródłowy), a nie rozsyłając ankietę i licząc na najlepsze.

Wynikiem jest spis każdego interfejsu wraz z kierunkiem, protokołem, częstotliwością, wolumenem danych, właścicielem biznesowym tam, gdzie da się go znaleźć, oraz oceną, czy trzeba go odbudować, można wygasić, czy da się zaadaptować. Klienci regularnie znajdują od dwóch do pięciu razy więcej interfejsów, niż się spodziewali, a znacząca ich część okazuje się nie służyć niczemu.

Odbudowa warstwy integracyjnej

Odbudowujemy te interfejsy, które muszą przetrwać, i wolimy budować je wobec abstrakcji, niż celować wprost w nowy system. Warstwa integracyjna między aplikacjami satelickimi a ERP-em sprawia, że następna migracja (a będzie następna), nie powtórzy tego ćwiczenia. Pozwala też przenosić aplikacje falami, zamiast w jeden weekend przełączeniowy.

Praca obejmuje tu interfejsy IDoc i BAPI, usługi OData, endpointy SOAP z wcześniejszej epoki, wymianę plików płaskich i SFTP, na której wciąż stoi połowa europejskiego B2B, kolejki komunikatów oraz nowoczesne API REST po nowej stronie.

Inżynieria migracji danych

Ekstrakcja, czyszczenie, transformacja, ładowanie i (część zwykle niedoszacowana) uzgadnianie. Budujemy migrację jako powtarzalny kod, a nie jednorazowy skrypt, żeby dało się ją uruchomić kilkadziesiąt razy na coraz czystszych danych, za każdym razem automatycznie porównując wyniki.

Uzgadnianie jest miejscem, w którym mieszka wiarygodność. Finanse nie podpiszą migracji dlatego, że ładowanie się powiodło; podpiszą, bo salda się zgadzają, liczności się zgadzają, a pozostałe różnice są wyjaśnione i przyjęte na piśmie.

Aplikacje autorskie, które przeżyją ERP

Większość firm ma wokół starego ERP-a aplikacje kodujące coś, czego ERP nie potrafił: konfigurator, narzędzie cenowe, terminal na hali produkcyjnej, portal klienta, arkusz planistyczny, który stał się elementem nośnym. Część z nich powinna zostać wygaszona na rzecz standardowej funkcjonalności nowego systemu. Część to prawdziwa przewaga konkurencyjna i należy zbudować je porządnie, jako samodzielne aplikacje, już nieprzyspawane do schematu bazy, który właśnie się zmieni.

Pomagamy odróżnić jedne od drugich, a potem budujemy te warte zachowania.

Raportowanie i ukryty majątek danych

Wokół każdego długo żyjącego ERP-a narasta warstwa raportów, eksportów i arkuszy poza nim. Przy przełączeniu psują się głośno i prawie nigdy nie ma ich w planie. Inwentaryzujemy je, wskazujemy te, na których biznes faktycznie stoi, i odbudowujemy je wobec nowego modelu danych albo wobec warstwy raportowej, która je od niego izoluje.

Wyłączanie systemu i retencja danych

Stary system trzyma dokumenty, które prawo każe przechowywać jeszcze przez lata po jego wyłączeniu. Utrzymywanie ECC w trybie tylko do odczytu przez dekadę to kosztowny sposób spełnienia obowiązku retencji. Budujemy ekstrakcję do dostępnego archiwum ze ścieżkami wyszukiwania i eksportu, o które audytorzy i organy podatkowe rzeczywiście pytają: żeby stary system dało się wyłączyć.

Czego nie robimy

Nie jesteśmy firmą doradczą od strony funkcjonalnej SAP-a. Nie konfigurujemy FI/CO, nie projektujemy Państwa szablonów procesowych i nie jesteśmy partnerem prowadzącym program S/4HANA. To role specjalistyczne i do nich należy zatrudnić specjalistę.

Jesteśmy zespołem inżynierskim, który pracuje obok takiego partnera nad wszystkim, czego ERP dotyka, a czego program ERP nie obejmuje. W praktyce angażuje nas albo bezpośrednio klient, żeby zabezpieczyć swoją stronę programu, albo integrator jako podwykonawcę.

Jeśli szukają Państwo kogoś, kto weźmie na siebie całą konwersję do S/4HANA, powiemy, że tym nie jesteśmy, i wolimy zrobić to przy pierwszej rozmowie, a nie przy trzeciej.

Gdzie pracujemy

Obok programu S/4HANA: odbudowa integracji, inżynieria migracji danych, praca nad aplikacjami satelickimi i wyłączanie starego majątku systemowego.

Migracje całkowicie poza SAP-a: do Odoo, Dynamics 365 Business Central, ERPNext, NetSuite albo systemu branżowego; najczęściej w średnich firmach, dla których S/4HANA jest rozwiązaniem nieproporcjonalnym. Tutaj praca integracyjna i danowa stanowi większość projektu.

Środowiska Oracle, Dynamics AX/NAV i Infor, pod tą samą presją cyklu życia, tylko z mniejszym rozgłosem.

Firmy, które w ogóle nie migrują, bo zdecydowały się na razie zostać, a potrzebują zmodernizować systemy dookoła, doprowadzić interfejsy do stanu utrzymywalnego i zmniejszyć ryzyko na czas oczekiwania.

Jak przebiega współpraca

Rozpoznanie, trzy do sześciu tygodni. Inwentaryzacja interfejsów, ocena jakości danych, przegląd aplikacji satelickich i pisemny raport o tym, jak naprawdę wygląda otoczenie systemowe. Świadomie oferujemy to jako osobne zlecenie: kilku klientów wykorzystało taki raport do renegocjacji zakresu i ceny oferty integratora, co z nawiązką się zwróciło.

Budowa, równolegle z programem głównym: warstwa integracyjna, potok migracyjny, przebudowy aplikacji, w Państwa harmonogramie i pod Państwa datę przełączenia.

Wsparcie przy przełączeniu, wraz z próbami generalnymi, przebiegami uzgodnieniowymi i okresem hypercare, w którym interfejsy nigdy porządnie nieprzećwiczone na testach wreszcie zostają przećwiczone.

Wyłączanie, gdy nowy system jest już stabilny, a archiwum odebrane.

Technologie

Java, .NET, Python, Node.js i PHP po stronie aplikacyjnej; technologie interfejsowe SAP, w tym IDoc, BAPI, RFC i OData; middleware, w tym MuleSoft, Apache Camel, Kafka i Azure Integration Services; SQL Server, Oracle, DB2, HANA i PostgreSQL; AWS i Azure. Tam, gdzie istniejące środowisko stoi na czymś starszym (Delphi, VB6, PowerBuilder, COBOL sąsiadujący z ERP-em) to dla nas znajomy teren, a nie zaskoczenie.

Najczęstsze pytania

Kiedy dokładnie kończy się wsparcie dla SAP ECC?

Utrzymanie podstawowe dla SAP ECC 6.0 kończy się 31 grudnia 2027 r. Utrzymanie rozszerzone jest dostępne do końca 2030 r., za dodatkową opłatą i w węższym zakresie. Szczegóły dla Państwa enhancement packa i umowy warto potwierdzić bezpośrednio w SAP, bo warunki bywają różne.

Mamy już wybranego integratora. Gdzie się Państwo mieszczą?

Obok niego. Integrator odpowiada za konwersję ERP-a; my za otoczenie: interfejsy, inżynierię danych, aplikacje satelickie, raportowanie i wyłączanie starego systemu. Taki podział jest częsty, pozwala integratorowi skupić się na systemie, w którym się specjalizuje, i sprawia, że ktoś odpowiada za części zwykle wypadające między umowy.

Czy realne jest zejście z SAP-a w całości?

Dla części firm tak. Zależy to od tego, ile z Państwa działalności jest standardem, ile siedzi w dostosowaniach i czy mniejsza platforma udźwignie Państwa wolumen i wymagania regulacyjne. To realna opcja dla średnich producentów i dystrybutorów, a słaba dla złożonych grup międzynarodowych. Faza rozpoznania daje dowody do podjęcia decyzji zamiast argumentów do sporu.

Ile trwa inwentaryzacja interfejsów?

Trzy do sześciu tygodni w większości średnich środowisk. Ogranicza ją głównie dostęp: to, jak szybko dotrzemy do logów, kodu źródłowego, konfiguracji middleware'u i ludzi pamiętających, po co coś powstało.

Czy da się utrzymać stary system dostępny na potrzeby audytu po jego wyłączeniu?

Tak. Budujemy ekstrakcję do przeszukiwalnego archiwum z okresem retencji, wyszukiwaniem i eksportem, jakich wymagają Państwa audytorzy i organy podatkowe. Zwykle jest to znacznie tańsze niż utrzymywanie licencjonowanego ERP-a w trybie tylko do odczytu przez dekadę.

A jeśli zdecydujemy, że na razie nie migrujemy?

To uprawniona decyzja, zwłaszcza przy utrzymaniu rozszerzonym dostępnym do 2030 r. Pracą jest wtedy ograniczanie ryzyka w międzyczasie: udokumentowanie i ustabilizowanie interfejsów, wygaszenie tego, z czego nikt nie korzysta, i zmodernizowanie aplikacji wokół ERP-a, żeby w momencie migracji to nie otoczenie było przeszkodą.

Pierwszy krok

Proszę napisać, na czym Państwo pracują, na jakim etapie decyzji są i czy integrator jest już wybrany. Powiemy, ile prawdopodobnie będzie kosztować otoczenie systemowe i od czego zaczęlibyśmy.

Skontaktujcie się z nami, aby wycenić rozpoznanie interfejsów i danych.

Powiązane usługi

Gotowy do rozpoczęcia z tą usługą?

Skontaktuj się
← Powrót do wszystkich usług