Od legacy do autonomicznego ERP, czyli jak transformacja technologiczna staje się transformacją biznesową

Z Michałem Domolewskim, Partnerem EY, Liderem zespołu SAP w Polsce rozmawiam o tym, że: transformacja technologiczna coraz rzadziej jest wyłącznie projektem IT, dla wielu organizacji staje się momentem, w którym można uporządkować architekturę, dane i procesy biznesowe oraz przygotować firmę do wykorzystania sztucznej inteligencji; a także migracji systemu ERP, która jest impulsem do znacznie głębszej zmiany – wyjścia z długu technologicznego i stworzenia organizacji gotowej na kolejną dekadę rozwoju.

Czy możliwe jest jeszcze postawienie kreski pomiędzy transformacją technologiczną, a biznesową? Przykładem może być migracja i transformacja systemów SAP. Kluczowe pytanie to, czy traktować to jako projekt IT, czy biznesowy? A jeśli ten drugi, to w którym momencie klienci gubią perspektywę biznesową?

Bardzo dobrze specyfikę procesu transformacyjnego oddają słowa legendarnego boksera Mike’a Tysona, że „każdy ma plan, dopóki nie dostanie w twarz”. Moim zdaniem, dziś trudno oddzielić transformację technologiczną od biznesowej. Technologia stała się narzędziem realizacji strategii biznesowej. Dlatego każda większa transformacja jest jednocześnie projektem biznesowym.

Zanim firmy podejdą do transformacji, przygotowują Business Case i to jest słuszna droga. Problem zaczyna się w momencie, gdy projekt już rusza. W prozie dnia codziennego myślenie o wartości biznesowej zaczyna schodzić na dalszy plan.

Dlaczego tak się dzieje?

Zespół projektowy ma cele: terminy, budżet i kamienie milowe. Im mocniej koncentruje się na „dowiezieniu” harmonogramu i uruchomieniu systemu, tym łatwiej stracić z oczu wartość biznesową. Dodatkowo pojawiają się oczekiwania użytkowników końcowych, którzy naturalnie koncentrują się na potrzebach swoich obszarów. Nie zawsze są one jednak spójne z celami strategicznymi, co wpływa na zakres i sposób prowadzenia transformacji.

To jest moment, kiedy długoterminowy cel biznesowy nie tyle znika, co zostaje odsunięty. Staje się mniej widoczny niż krótkoterminowy cel projektowy.

Jakie powinny być cele biznesowe projektu transformacji systemu ERP? W przypadku wielu organizacji impulsem do rozpoczęcia takiego programu jest koniec wsparcia starszych wersji oprogramowania. Jak w takich „warunkach” sprawić, aby nie był to jedynie projekt modernizacyjny, ale rzeczywista transformacja biznesowa?

W wielu rozmowach widzimy, że klienci traktują transformację ERP przede wszystkim jako obowiązek wynikający z końca wsparcia starszej wersji systemu. Tymczasem jest to jeden z tych momentów, które mogą przesądzić o tym, jak firma będzie funkcjonowała przez kolejną dekadę. Transformacja powinna być postrzegana jako inwestycja w architekturę, dane, procesy i zdolność organizacji do szybkiego wdrażania kolejnych zmian.

Dobry Business Case łączy dwa wymiary: technologiczny – np. redukcję długu technologicznego, uproszczenie architektury i integracji, poprawę jakości danych i zmniejszenie liczby rozszerzeń oraz biznesowy – np. większą efektywność procesów, wzrost produktywności i skrócenie cykli operacyjnych.

Kluczowe jest odpowiedzenie sobie nie tylko na pytanie, jaki system i jak go wdrożyć, ale jak chcemy, aby firma działała za 5 czy 10 lat. W przypadku organizacji korzystających z SAP, posiadających 15- lub 20-letnie, mocno skastomizowane środowiska, jest to dobra okazja, aby wyjść z długu technologicznego i zaprojektować architekturę wspierającą rozwój biznesu.

Jakie mierniki, KPI powinny się w takim projekcie pojawić?

KPI powinny wynikać bezpośrednio z Business Case. Jeżeli mierzymy tylko termin, budżet i uruchomienie systemu, to tak naprawdę oceniamy projekt, a nie jego wartość.

Po stronie technologicznej mogą to być m.in. redukcja długu technologicznego, uproszczenie architektury, poprawa jakości danych czy standaryzacja integracji. W przypadku SAP bardzo dobrym wskaźnikiem jest również ograniczenie liczby rozszerzeń własnych oraz interfejsów budowanych w starszych technologiach typu point-to-point.

Po stronie biznesowej najczęściej mierzymy skrócenie czasu zamknięcia miesiąca, cykli zakupowych, poprawę jakości planowania czy redukcję czasu realizacji kluczowych procesów. Coraz częściej pojawiają się również wskaźniki dotyczące jakości danych i poziomu automatyzacji procesów z wykorzystaniem AI.

Najważniejsze jednak, aby tych KPI nie było zbyt wiele. Zwykle 3 do 5 – dobrze dobranych wskaźników – w pełni wystarcza, aby obiektywnie ocenić, czy transformacja rzeczywiście przyniosła zakładaną wartość.

Jak przekonać zarząd, aby patrzył na migrację SAP jako na transformację całej organizacji, a nie tylko projekt IT i wymianę technologii?

Zarząd musi zrozumieć, jak technologia przekłada się na realizację strategii biznesowej. To musi być jeden, spójny obraz. Może to zabrzmieć trywialnie, ale zaskakująco często obserwujemy, że prezentowana jest wyłącznie perspektywa technologiczna albo wyłącznie biznesowa. Tymczasem decyzje zarządu wymagają połączenia obu tych światów.

Pomagamy klientom budować właśnie taką perspektywę – zarówno przez pryzmat twardych liczb, takich jak zwrot z inwestycji, TCO czy potencjalne oszczędności, jak i pokazując, jaki potencjał wzrostu, elastyczności i dalszego rozwoju daje transformacja w dłuższej perspektywie.

Często rozpoczynamy od tzw. Fazy 0. W jej trakcie wspólnie z klientem definiujemy Business Case, szacujemy korzyści biznesowe i technologiczne, określamy wpływ na redukcję długu technologicznego oraz uzgadniamy KPI, które będą mierzyć sukces projektu.

Zawsze podkreślamy, że transformacja zaczyna się od Business Case, jest prowadzona przez KPI i kończy się osiągnięciem wartości biznesowej. Taka faza przygotowawcza porządkuje oczekiwania, buduje wspólny język z zarządem i znacząco ułatwia podejmowanie decyzji na kolejnych etapach projektu.

Czy możecie – bez podawania nazw – podać przykłady transformacji, w których udało się znacząco ograniczyć dług technologiczny i uprościć architekturę systemową?

Dobrym przykładem jest redukcja liczby rozszerzeń własnych o 60–70%. Mówimy o dziesiątkach, a czasem setkach rozszerzeń nagromadzonych przez kilkanaście lat, które po analizie okazały się zbędne albo możliwe do zastąpienia standardowymi funkcjonalnościami.

Drugim przykładem jest uproszczenie krajobrazu aplikacyjnego poprzez ograniczenie liczby systemów satelitarnych. W jednym z projektów, w obszarze produkcji i utrzymania ruchu, udało się zmniejszyć z kilkunastu o połowę. Część rozwiązań zastąpiliśmy standardem SAP, a część uprościliśmy poprzez zmianę procesów biznesowych.

To mocno obniżyło koszty utrzymania, zmniejszyło złożoność architektury i poprawiło spójność danych.

Co konkretnie daje klientowi ograniczenie własnych rozszerzeń? Przez lata właśnie tak były „rozwijane” systemy SAP. Obecnie SAP mówi o tzw. Clean Core. Jak to przekłada się to na praktykę: koszty, upgrade, elastyczność?

Clean Core nie jest celem samym w sobie. To sposób na ograniczenie kosztów zmian i przygotowanie organizacji do szybszego rozwoju. Dzięki temu po pierwsze spadają koszty utrzymania, łatwiej przeprowadzić upgrade i wdrażać nowe funkcjonalności systemu.

Po drugie, organizacja uniezależnia się od niestandardowego kodu tworzonego przez lata oraz od wąskiej grupy osób lub dostawców, którzy jako jedyni rozumieją jego logikę. Clean Core wymusza uporządkowanie architektury i świadome zarządzanie rozszerzeniami.

Po trzecie, bardzo ważną korzyścią jest poprawa jakości danych. Im więcej mamy własnych rozszerzeń i systemów satelitarnych, tym większe ryzyko niespójności danych, ich duplikatów, braku harmonizacji. Od zawsze przekładało się to na jakość analiz i decyzji biznesowych.

Dziś dochodzi jeszcze jeden, niezwykle istotny aspekt – efektywność wykorzystania narzędzi opartych na sztucznej inteligencji i agentach AI. Jeżeli dane są słabej jakości, to efekty inwestycji w AI również będą słabe.

W jednej z moich rozmów z dużym klientem SAP w Polsce pojawił się właśnie wątek Data Governance, jako jednego z głównych priorytetów planowanej transformacji.

W największych firmach, zwłaszcza zagranicznych, główny nacisk przy transformacji technologicznej kładzie się właśnie na dane. Kilka lat temu mówiliśmy o standaryzacji procesów i redukcji rozszerzeń. Teraz, coraz częściej punktem ciężkości jest Data Governance.

Moment transformacji to idealny moment, aby: spojrzeć na dane całościowo,  zharmonizować je, wyczyścić, zaplanować serię inicjatyw dalszej poprawy jakości. Bez tego modele AI będą znacznie częściej „halucynować”, a system nie będzie dostarczał wiarygodnych informacji, na których można oprzeć decyzje biznesowe.

W przypadku firm korzystających z SAP system S/4HANA pozostaje sercem organizacji. To właśnie z niego pochodzą dane, które zasilają analitykę, rozwiązania AI i procesy decyzyjne. Dlatego jakość tych danych ma dziś większe znaczenie niż kiedykolwiek wcześniej.

Z jakim długiem technologicznym mierzą się dziś firmy?

Przede wszystkim jest to bardzo duża customizacja: tysiące linii kodu klienckiego, rozszerzenia tworzone przez lata „pod potrzeby” użytkowników. Często zmiany te są nieudokumentowane, wielokrotnie modyfikowane i dostosowywane do zmieniających się osób i pomysłów.

Drugim obszarem jest architektura integracyjna: duża liczba interfejsów typu point‑to‑point, trudnych w utrzymaniu i rozwoju, działających poza nowoczesnymi, standardowymi mechanizmami integracyjnymi. Mamy też dług technologiczno‑ludzki.

W wielu firmach, które przez kilkanaście czy kilkadziesiąt lat rozwijały się organicznie, równolegle rozwijało się również ich środowisko IT. Obok systemu ERP powstawały kolejne aplikacje wspierające biznes, często tworzone na bieżące potrzeby i w różnych technologiach. Dziś część z nich nie jest już wspierana, a kompetencje potrzebne do ich utrzymania stają się coraz trudniej dostępne.

No i jest też oczywiście wszechobecny Excel. Dane wyciągane są z systemów do arkuszy, przetwarzane offline, klejone z wielu źródeł, a następnie wykorzystywane w kolejnych procesach biznesowych. To oznacza brak jednego źródła prawdy, długi czas realizacji procesów planistycznych czy analitycznych, duplikaty danych i chaos raportowy.

A co z rozszerzeniami, które muszą pozostać. Mówiliśmy, że w czasie transformacji SAP udaje się usunąć 60-70% z nich. Co z 30-40 proc., których nie da się wyeliminować?

To już kwestia konkretnego przypadku. Wszystko zależy od wartości biznesowej danego rozszerzenia i roli, jaką pełni ono w architekturze organizacji.

Część rozszerzeń można wydzielić poza core, wykorzystując SAP BTP lub inne platformy rozszerzeń. Część zastąpić standardem po zmianie procesu. Część zaś świadomie pozostawić w systemie, jeżeli wynika to z analizy biznesowej. Już sama minimalizacja długu technologicznego, dobra dokumentacja i świadomość, dlaczego dane rozszerzenie istnieje, stanowią dużą wartość.

Transformacja jest świetnym momentem na Reverse Engineering, a więc zrozumienie, po co dane rozszerzenia powstały, jak są używane, i ich udokumentowanie. Kiedyś wymagało to bardzo doświadczonych ekspertów, którzy ręcznie analizowali kod. Dziś pomagają w tym narzędzia do analizy kodu oparte o AI. Znacząco przyspieszają zrozumienie złożonych rozwiązań legacy.

W jaki sposób transformacja technologiczna może zmienić sposób działania firmy? Jakie dobre praktyki warto wykorzystać, niezależnie od wdrażanego systemu?

To zależy od tego, jak głęboko transformacja ingeruje w procesy i model operacyjny. Każda, większa transformacja wymaga też poważnego potraktowania tematu zarządzania zmianą. Trzeba zidentyfikować obszary, w których ona nastąpi i odpowiedzieć na pytania: czy zmienia się sposób realizacji procesów, czy tylko narzędzia i systemy oraz jak to wpłynie na użytkowników końcowych.

Należy jednak pamiętać, że narzędzia technologiczne pomagają tworzyć wartość. Sama wartość powstaje jednak w procesach, ludziach i sposobie działania organizacji. Najlepsza technologia wdrożona do źle zaprojektowanych procesów nie sprawi, że organizacja stanie się bardziej efektywna. Znacznie bardziej prawdopodobne jest to, że przeniesiemy istniejące problemy do nowego systemu.

Jaką rolę do odegrania w tym procesie ma AI?

Dla przykładu, SAP mocno promuje teraz koncepcję tzw. autonomicznego ERP. To oznacza zmianę paradygmatu pracy użytkownika: od podejścia reaktywnego – „patrzę na dane, zauważam odchylenie, reaguję”, do podejścia, w którym system sam analizuje zdarzenia, identyfikuje odchylenia, proponuje działania, a w wybranych obszarach. Przy odpowiednio zdefiniowanych regułach, autonomiczny ERP może je też automatycznie wykonywać.

Rola użytkownika przesuwa się więc z ręcznego wykonywania transakcji do podejmowania decyzji – potwierdzania rekomendacji systemu, wyboru jednej z kilku proponowanych opcji czy monitorowania efektów działań podejmowanych przez agenta AI.

Co w praktyce oznacza autonomiczność systemów ERP? Czy to konieczność wbudowywania agentów i modeli AI do procesów organizacji?

Taki jest kierunek, choć w różnych obszarach biznesowych postęp jest różny. Zamiast klasycznego „klikania” w transakcje, użytkownik coraz częściej będzie prowadził dialog z systemem, a system – za pomocą agentów i modeli AI – będzie analizował zdarzenia, proponował działania, a w wybranych procesach również wykonywał je automatycznie.

System może np. sam identyfikować odchylenia od założonych KPI, analizować ich przyczyny, oceniać wpływ na działalność firmy i proponować działania korygujące. Co ważne, nie ogranicza się do jednego procesu, ale uwzględnia zależności pomiędzy sprzedażą, zakupami, produkcją czy finansami. Dzięki temu użytkownik otrzymuje nie tylko informację o problemie, ale również rekomendację najlepszego sposobu jego rozwiązania.

Jak wygląda zaawansowanie tego procesu pomiędzy Polską a innymi krajami?

Myślę, że na całym świecie jesteśmy jeszcze na początku drogi do autonomicznego ERP. USA i Europa Zachodnia są nieco bardziej zaawansowane we wdrażaniu rozwiązań opartych na agentach AI, ale również tam organizacje podchodzą do tego etapowo. Budują zaufanie do nowych modeli pracy.

Najbardziej dojrzałe zastosowania obserwujemy dziś w finansach, zakupach oraz obsłudze klienta. To obszary, w których procesy są dobrze ustandaryzowane, dane stosunkowo wysokiej jakości, a potencjalne korzyści z automatyzacji najłatwiej zmierzyć.

Jakie są największe bariery transformacji technologicznej – organizacyjne, związane z danymi, a może obawy przed chmurą?

Paradoksalnie bariery transformacji technologicznej rzadko mają dziś charakter czysto technologiczny. Znacznie częściej są to dane, ludzie oraz sposób zarządzania zmianą. Zdarza się, że sama technologia jest najmniej problematycznym elementem całego programu transformacyjnego.

Nie oznacza to jednak, że można pominąć kwestie techniczne. Jednym z ważnych obszarów jest bezpieczeństwo, rozumiane znacznie szerzej niż tylko cyberbezpieczeństwo. Wraz z przejściem do modelu chmurowego zmienia się podział odpowiedzialności pomiędzy producentem oprogramowania, dostawcą chmury i samą organizacją. Dlatego tak istotne jest jasne zdefiniowanie odpowiedzialności za bezpieczeństwo, zgodność regulacyjną i utrzymanie środowiska.

Drugim dużym wyzwaniem są dane. Niezbędne jest wyznaczenie zespołu po stronie klienta odpowiedzialnego za ich przygotowanie, oczyszczenie i migrację oraz realistyczne oszacowanie nakładu pracy i ryzyk. To są dane klienta i to on będzie z nich korzystał w przyszłości. Najlepsze efekty osiągamy wtedy, gdy klient jest silnie zaangażowany i realnie odpowiada za ten obszar.

Trzeci obszar to ludzie i Change Management: przygotowanie użytkowników, zmiana sposobu ich pracy, a także ograniczenie przywiązania do Excela i dotychczasowych nawyków. To właśnie ten element jest w wielu organizacjach nadal niedoceniany, choć bardzo często decyduje o sukcesie całej transformacji.

Na czym w praktyce polega Change Management w takich projektach?

Jest to całościowe przeprowadzenie organizacji przez zmianę: planowanie i prowadzenie komunikacji; uświadamianie użytkowników, co, kiedy i jak się zmieni i co to oznacza dla ich codziennej pracy; przygotowanie do testów, pilotaży, uruchomienia produkcyjnego oraz wsparcie w pierwszych miesiącach po starcie.

O wielu rzeczach trzeba mówić wielokrotnie i odpowiednio wcześnie. Jeśli zaczniemy myśleć o Change Management za późno, to naturalnie pojawi się opór i problemy z adopcją nowych rozwiązań. Należy pamiętać, że żadna transformacja technologiczna nie odbywa się bez ludzi. To oni konkretne rozwiązania wprowadzają, a potem z nich korzystają. Lub nie.

Dlatego aspekt ludzki powinien towarzyszyć implementacji każdej technologii – od samego początku, a nie dopiero na etapie szkoleń. Dobrze prowadzony proces zmiany znacząco zwiększa szanse na to, że nowe procesy i narzędzia zostaną rzeczywiście zaakceptowane i wykorzystane przez organizację.

Na co jeszcze warto zwrócić uwagę, planując i realizując proces migracji i transformacji systemów SAP, zwłaszcza z perspektywy celów biznesowych?

Najważniejsze jest dobre zdefiniowanie KPI – zarówno technologicznych, jak i biznesowych – aby po zakończeniu projektu móc obiektywnie ocenić, czy transformacja rzeczywiście przyniosła zakładaną wartość.

Istotne jest również pełne i realne wsparcie zarządu – traktowanie projektu jako inicjatywy biznesowej, a nie czysto informatycznej – nawet jeśli impulsem do jej rozpoczęcia jest aktualizacja wykorzystywanego systemu. Ważny jest również odpowiednio zbudowany zespół po obu stronach: jasny podział ról i odpowiedzialności, właściwe umocowanie kierownika projektu i osób decyzyjnych w organizacji.

I tak, jak mówiłem ten zespół nie może mieć charakteru wyłącznie technologicznego, bo transformacja technologiczna już dawno przestała dotyczyć wyłącznie technologii. Już na etapie definiowania zakresu projektu warto zaangażować ekspertów od procesów biznesowych, danych, zarządzania zmianą, cyberbezpieczeństwa, a w razie potrzeby również aspektów prawnych czy podatkowych. To właśnie połączenie tych kompetencji najczęściej decyduje o powodzeniu całej transformacji.