Modernizacja odziedziczonego ERP na rzeczywistym przykładzie

Dział finansowy każdego piątkowego poranka zaczynał od tego samego: eksport z starego ERP, poprawki w Excelu, uzgodnienia z magazynem, a następnie kolejne uzgodnienia ze sprzedażą. Kiedy raport zarządczy był gotowy, dane były już częściowo przestarzałe. Ten przykład modernizacji odziedziczonego ERP nie dotyczy niezwykłej sytuacji informatycznej, lecz typowego problemu wzrostu: system nadal działa, ale ręczne procesy wokół niego pochłaniają coraz więcej czasu, uwagi i ryzyka.

Wymiana starego ERP może brzmieć jak projekt technologiczny. W rzeczywistości jest to decyzja biznesowa. W ERP znajdują się historie zamówień, bazy danych produktów, ruchy magazynowe, zasady fakturowania, rutyny zakupowe i często wyjątki wypracowane przez lata. Jeśli próbują to rozwiązać jednym wielkim przejściem, firma ryzykuje nie tylko system, ale także bezpieczeństwo operacyjne.

Przykład modernizacji odziedziczonego ERP: nie zaczęło się od systemu

Przykład dotyczy hurtownika technicznego z wieloma lokalizacjami, zatrudniającego około 90 osób. Stary ERP zarządzał zapasami, zakupami, zamówieniami i częścią fakturowania. Program był stabilny, pracownicy go znali i nie było rozsądne twierdzić, że sam w sobie jest bezużyteczny.

Problemem było raczej to, co działo się przed i po ERP. Zamówienia z e-sklepu były importowane codziennie, ale błędne numery artykułów poprawiano ręcznie. Ceny dla kluczowych klientów były w osobnej tabeli. Magazyn pracował na podstawie list wydrukowanych z ERP, a różnice w kompletacji zgłaszał e-mailem. Dane transportowe były kopiowane przez pracownika na zewnętrzną platformę. Kierownictwo do cotygodniowych raportów o zapasach i marżach potrzebowało danych z trzech różnych źródeł.

Pierwsze sformułowanie firmy było proste: potrzebny jest nowy ERP. Jednak w trakcie analizy okazało się, że znaczna część codziennych problemów nie wynikała z wieku ERP. Problem polegał na tym, że procesy biznesowe zmieniły się z czasem, ale metody pracy związane z systemem nie nadążały za tymi zmianami.

Na przykład w kontroli zamówień te same dane były sprawdzane trzykrotnie: najpierw przez sprzedawcę, potem przez osobę odpowiedzialną za limit kredytowy, a na końcu przez dział fakturowania. Wcześniej była to uzasadniona kontrola, gdy zamówień było mało i istniało wiele indywidualnych warunków. Przy obecnym wolumenie większość zamówień była standardowa. Nie zasada kontroli była błędna, ale to, że każde zamówienie przechodziło tę samą ręczną ścieżkę.

Analiza sytuacji: co naprawdę spowalnia działanie?

W pierwszej fazie modernizacji nie sporządzono listy oprogramowania. Śledzono drogę informacji od momentu otrzymania zamówienia do wysyłki i fakturowania. Na każdym etapie zadawano te same pytania: kto inicjuje pracę, z jakich danych korzysta, gdzie wprowadza zmiany, kto musi zatwierdzić i co się dzieje w przypadku błędu?

Z tego wynikły cztery ważne wnioski:

• Dane zamówień były wielokrotnie wprowadzane do różnych systemów.
• Informacje o zapasach nie były dostępne w tym samym czasie w e-sklepie, sprzedaży i magazynie.
• Proces stworzony do obsługi wyjątków stał się częścią normalnego działania.
• Wiele krytycznych kroków opierało się na wiedzy doświadczonego pracownika, bez udokumentowanych zasad.

To ostatnie było szczególnie ryzykowne. Kiedy pracownik odpowiedzialny za administrację transportu był na urlopie, zadanie mogła przejąć inna osoba, ale wolniej i z większą ilością błędów. Nie dlatego, że nie była w stanie, ale dlatego, że część zasad biznesowych istniała tylko w głowie tej osoby.

Analiza nie oznaczała, że wszystkie ręczne kroki muszą zostać wyeliminowane. W przypadku niektórych zamówień - na przykład z indywidualnym cennikiem, ograniczeniami transportowymi lub nietypowym składem produktów - nadal uzasadniona była kontrola ludzka. Celem było, aby rutynowe zadania nie zajmowały tej samej uwagi, która jest naprawdę potrzebna przy wyjątkach.

Rozwiązanie: stopniowa modernizacja, a nie ślepa wymiana

Kierownictwo ostatecznie nie zdecydowało się na natychmiastową pełną wymianę ERP. Najpierw ustalono, które systemy są odpowiedzialne za które dane. ERP pozostał głównym źródłem danych o zapasach, statusie zamówień i podstawowych danych fakturowania. E-sklep nie musiał utrzymywać własnej logiki zapasów, a magazyn nie musiał polegać na zmianach otrzymywanych e-mailem.

Następnie uporządkowano powtarzalne transfery danych. Zamówienia z e-sklepu były wprowadzane do ERP po kontroli opartej na zasadach. Zamówienia spełniające wcześniej określone warunki były automatycznie przetwarzane dalej. Brakujący adres, przekroczenie limitu kredytowego czy niejednoznaczny numer artykułu nadal stanowiły zadanie dla pracownika. W ten sposób kontrola nie zniknęła, tylko jej przedmiot stał się bardziej precyzyjny.

W procesie transportowym nie wprowadzono całkowicie nowego systemu logistycznego . Najpierw ujednolicono, jakie dane są potrzebne do stworzenia etykiety, jak obsługiwać częściowe dostawy i kto ma prawo do zmiany adresu. Dopiero potem zbudowano połączenie danych z usługą transportową. Większość czasu poświęcanego wcześniej na kopiowanie zniknęła, podczas gdy błędne lub brakujące dane nadal były widoczne dla odpowiedzialnych pracowników.

W raportowaniu również nie zaczęto od efektownego dashboardu dla kierownictwa. Najpierw trzeba było wyjaśnić, co dokładnie oznacza dostępny zapas, która data jest uznawana za realizację i jak traktować uznania w marży. Szybki raport oparty na błędnej definicji tylko szybciej rozprzestrzenia nieporozumienia.

Co należy zachować ze starego systemu?

W odziedziczonym ERP często znajduje się rzeczywista wartość biznesowa. Mogą to być zasady fakturowania, struktury produktów lub specyfika branżowa wypracowane przez lata, które łatwo zlekceważyć przy wprowadzaniu nowego systemu. Dlatego modernizacja nie zawsze oznacza zastąpienie.

Istnieją trzy realistyczne kierunki. Pierwszy to pozostawienie istniejącego ERP, ale modernizacja procesów, integracji i raportów wokół niego. To może działać dobrze, jeśli system jest stabilny, dane są dostępne, a głównym ograniczeniem jest izolowane działanie.

Drugi kierunek to stopniowe zastępowanie. W takim przypadku nowa funkcja - na przykład integracja z e-sklepem, wsparcie magazynowe lub raportowanie dla kierownictwa - przejmuje rolę, podczas gdy ERP tymczasowo nadal pełni centralną rolę. To może zmniejszyć ryzyko jednorazowego przejścia, ale wymaga dyscypliny architektonicznej. Musi być jasne, w którym systemie znajdują się obowiązujące dane.

Trzeci kierunek to pełna wymiana. To może być uzasadnione, jeśli ERP nie jest już wspierany, jego modyfikacja jest nieproporcjonalnie kosztowna, wydobycie danych jest niepewne lub nie jest w stanie obsłużyć podstawowych procesów biznesowych. Pełna wymiana to nie tylko wdrożenie systemu: to także projekt dotyczący jakości danych, uprawnień, procesów i szkoleń.

Mierzalny wynik to nie tylko liczba zaoszczędzonych godzin

W przypadku firmy z przykładu czas administracyjny przetwarzania zamówień się skrócił, ale ważniejsza zmiana dotyczyła przewidywalności. Magazyn wcześniej wiedział, które zamówienia są pilne, a które czekają na weryfikację. Sprzedaż odpowiadała na mniej pytań dotyczących statusu. Dział finansowy nie musiał co tydzień ręcznie wykrywać tych samych rozbieżności.

Sukces modernizacji nie powinien być mierzony tylko liczbą zaoszczędzonych godzin pracy. Warto zwrócić uwagę na liczbę poprawek danych, błędy zamówień, wahania czasu realizacji, opóźnione faktury, czas poświęcony na ręczne raporty oraz to, ile procesów zatrzymuje się z powodu nieobecności jednej osoby.

Wpływ na ludzi również ma znaczenie. Pracownicy nie stają się bardziej wartościowi, kopiując szybciej dane między systemami. Mogą podejmować lepsze decyzje, obsługiwać klientów lub rozwiązywać wyjątki, jeśli system niezawodnie wykonuje rutynowe zadania i dobrze uwidacznia problemy.

Bezpieczna zmiana wymaga dyscypliny operacyjnej

Częstym błędem w modernizacji ERP jest rozpoczęcie projektu od listy funkcji: potrzebna jest nowa powierzchnia, dostęp mobilny, automatyczne powiadomienia, więcej dashboardów. Mogą mieć swoje miejsce, ale nie zastąpią podstawowych decyzji dotyczących właściciela danych, zasad zatwierdzania, uprawnień i obsługi błędów.

Dobrze prowadzona zmiana powinna zawierać weryfikację danych, testowalne procesy, plan przywracania i jasne zakresy odpowiedzialności. Tymczasowe równoległe działanie starego i nowego systemu może być uzasadnione w niektórych przypadkach, szczególnie w procesach finansowych lub produkcyjnych. Jednak należy to ograniczyć w czasie, ponieważ dwa równoległe źródła prawdy na dłuższą metę tworzą tylko nowe niepewności.

Dlatego najlepszym pierwszym krokiem nie jest wybór nowego ERP. Lepiej wybrać proces, który co tydzień wyraźnie traci czas: na przykład uzgadnianie między zamówieniem a wydaniem magazynowym, obsługę wyjątków fakturowych lub przygotowanie raportu o zapasach. Jeśli tę ścieżkę rzeczywiście się prześledzi, nie tylko zobaczy się, jaki system należy zmodernizować, ale także, jakie działanie warto w końcu porzucić.