W wielu firmach rozmowa o automatyzacji kończy się na prostym argumencie:

Przecież mamy ERP.

I rzeczywiście. ERP obsługuje zamówienia, faktury, zakupy, magazyn, produkcję albo finanse. Dane są w systemie, proces ma swoje statusy, a czasy papierowych segregatorów dawno się skończyły.

Tylko że warto przejść przez jeden konkretny proces od początku do końca. Klient wysyła zamówienie mailem, w załączniku jest PDF. Pracownik otwiera dokument, sprawdza numery produktów, porównuje je z kodami w ERP, uzupełnia brakujące informacje i wpisuje zamówienie do systemu. Jedna pozycja ma nietypową specyfikację, więc trzeba napisać do działu technicznego. Termin dostawy trzeba potwierdzić w systemie planistycznym. Po wszystkim pracownik wraca do ERP i wysyła potwierdzenie klientowi.

ERP działa poprawnie. Zamówienie jest w systemie, produkty są w systemie, cena jest w systemie. Problem w tym, że człowiek wykonał po drodze cały szereg ręcznych kroków, żeby informacje w ogóle mogły się tam znaleźć.

I właśnie dlatego samo posiadanie ERP nie mówi wiele o tym, jak bardzo firma jest zautomatyzowana.

ERP może działać dobrze, a proces nadal być ręczny

ERP oczywiście automatyzuje część procesów. Współczesne systemy SAP, Dynamics, Oracle, IFS, Infor czy Epicor mają workflowy, integracje, akceptacje, import danych, obsługę dokumentów i coraz więcej funkcji wykorzystujących AI. W średnich i dużych firmach ERP jest dziś po prostu standardem.

Ale posiadanie systemu i automatyzacja procesu to dwie różne rzeczy. ERP bardzo dobrze radzi sobie z tym, do czego został zaprojektowany: przechowuje kontrolowane dane i obsługuje transakcje biznesowe. Problem zaczyna się trochę wcześniej (skąd dane trafiają do ERP?) i trochę później (co dzieje się z nimi po zapisaniu?).

Przy zamówieniu klienta może to wyglądać tak:

email → PDF → człowiek → ERP

Przy dostawcy:

email → potwierdzenie zamówienia → człowiek → ERP → system planistyczny

Przy wysyłce:

ERP → człowiek → portal przewoźnika → człowiek → ERP

Przy raportowaniu:

ERP → Excel → drugi system → Excel → raport

Każdy z tych systemów może działać poprawnie. Ręczna praca kryje się na styku między nimi i to właśnie tam warto zacząć jej szukać.

Człowiek jako integracja

Jest na to stare określenie: swivel-chair process. Kiedyś pracownik dosłownie obracał się na krześle między dwoma terminalami i przepisywał dane z jednego systemu do drugiego. Dzisiaj częściej przełącza zakładki, ale mechanizm się nie zmienił.

Pracownik:

• otwiera maila
• czyta dokument
• sprawdza dane
• kopiuje je do systemu
• eksportuje Excel
• porównuje dwie listy
• pyta kogoś o zgodę
• aktualizuje status
• wraca do pierwszego systemu

W praktyce to właśnie pracownik jest tą integracją.

Nie zawsze jest to problem. Jeżeli czynność zdarza się dwa razy w miesiącu i zajmuje pięć minut, prawdopodobnie nie warto nic z nią robić. Ale jeśli pięć osób wykonuje podobne operacje codziennie przy setkach zamówień, dokumentów albo dostaw, sytuacja wygląda inaczej.

Dobrym sygnałem ostrzegawczym są też Excele, które zaczynają pełnić rolę dodatkowego systemu operacyjnego. Nie chodzi o każdy arkusz. Excel jest bardzo dobrym narzędziem do analiz, nietypowych obliczeń i jednorazowej pracy. Problem wygląda raczej tak:

Codziennie eksportujemy dane z ERP do Excela, tam ustalamy faktyczny plan, a później wynik przepisujemy z powrotem do systemu.

W wielu firmach taki arkusz w praktyce zastępuje moduł planowania produkcji: informacje są przetwarzane poza systemem, a potem ponownie do niego wprowadzane. ERP jest, a proces powstał obok niego.

To bardzo częsty mechanizm: system jest formalnym źródłem danych, ale prawdziwy sposób wykonywania pracy żyje gdzie indziej.

Skoro ERP potrafi tak dużo, dlaczego te luki w ogóle powstają?

Powodów może być kilka. Pierwszy jest bardzo prosty.

Klient nie pracuje w Twoim ERP

Klient może przesłać zamówienie jako PDF, arkusz Excela, zwykłą treść maila albo formularz ze swojego systemu. Ci więksi czasem podłączą się przez EDI lub API, ale nie każdy klient będzie chciał dostosować swój proces do naszego ERP. To samo dotyczy dostawców: jeden korzysta z portalu, drugi wysyła PDF, trzeci potwierdza termin w treści maila.

ERP może wiedzieć, co zrobić z potwierdzeniem zamówienia, kiedy odpowiednie dane już do niego trafią. Ktoś albo coś musi jednak najpierw je odczytać i zrozumieć.

ERP nie jest jedynym systemem w firmie

W produkcji obok ERP zwykle działa kilka innych systemów: MES na hali, WMS w magazynie, TMS w logistyce, system jakościowy, CRM, narzędzia do projektowania produktu, osobne systemy planistyczne i finansowe, a do tego portale dostawców i klientów.

I to jest normalne. Nie każdy problem powinien być rozwiązywany wewnątrz ERP. System do projektowania produktu ma inne zadanie niż system finansowy, a logistyka inne niż produkcja. Problem pojawia się wtedy, gdy informacje pomiędzy nimi przenoszą ludzie.

Firma zmienia się szybciej niż system

Dochodzi nowy zakład. Firma przejmuje inną spółkę. Pojawia się duży klient z własnym sposobem składania zamówień. Powstaje lokalny proces, którego nikt nie przewidział podczas wdrożenia ERP pięć lat wcześniej. Po pewnym czasie krajobraz wygląda inaczej niż w dniu uruchomienia systemu.

Nie zawsze ma sens natychmiast przenosić wszystko do jednej instancji ERP. Czasem dwa systemy mogą działać obok siebie przez lata. Wtedy problemem staje się nie ich istnienie, tylko to, jak przepływają między nimi dane.

Funkcja może istnieć, ale nikt jej nie wdrożył

Pracownik wysyła każdą akceptację mailem. Pierwsza myśl:

Trzeba zautomatyzować obieg akceptacji.

Tylko że ERP może już mieć odpowiedni workflow. Może nigdy nie został skonfigurowany, może wymaga dodatkowej licencji, a może historyczne modyfikacje systemu utrudniają jego wykorzystanie. Albo ludzie przez lata wypracowali własny sposób działania i nikt już nie pamięta, dlaczego robią to właśnie tak.

Dlatego ręczny krok nie jest jeszcze dowodem, że trzeba budować nowy system. Najpierw trzeba zrozumieć, dlaczego ten krok jest ręczny.

Zanim coś zbudujesz, sprawdź, czy nie masz już gotowego rozwiązania

Po znalezieniu ręcznego procesu wokół ERP nie warto zaczynać od pytania:

Co możemy tutaj zbudować?

Lepiej zacząć od:

Czy obecny system już potrafi to zrobić?

To mniej efektowne, ale bardzo często prowadzi do lepszego rozwiązania. SAP ma mechanizmy automatycznego importu zamówień, workflowy i integracje. Dynamics ma m.in. Invoice Capture, workflowy zakupowe i obsługę wyjątków. Oracle ma akceptacje, API i przetwarzanie dokumentów. IFS, Infor i Epicor również mają własne narzędzia do workflowów, integracji i automatyzacji.

Jeżeli odpowiednia funkcja jest już kupiona, wspierana przez producenta i rozwiązuje problem wystarczająco dobrze, zwykle warto zacząć właśnie od niej. Nie ma sensu budować własnego systemu do akceptacji faktur tylko dlatego, że nikt nie skonfigurował modułu, który firma już posiada. Podobnie nie ma sensu budować warstwy AI do przenoszenia siedmiu pól pomiędzy dwoma systemami, jeśli oba mają dobre API. Czasem najprostsza integracja jest najlepszą automatyzacją.

I czasem po analizie okazuje się, że nie trzeba robić niczego. To też jest poprawny wynik.

Wybierz najprostsze rozwiązanie, które usuwa ręczny krok

Można na to patrzeć jak na pięć kolejnych możliwości. Nie warto zaczynać od ostatniej.

1. Funkcja w ERP

Jeżeli proces jest standardowy i ERP już potrafi go obsłużyć, najprościej po prostu z niego skorzystać.

Przykład: manager zatwierdza zakup mailem, mimo że system ma workflow akceptacji. Tutaj prawdopodobnie nie mamy problemu wymagającego AI ani custom developmentu, tylko problem z konfiguracją lub sposobem pracy.

2. Integracja

Jeżeli jeden system ma poprawne dane, których potrzebuje drugi system, wystarczy je przenieść: przez API, EDI albo gotowy konektor.

Przykład: pracownik kopiuje dane wysyłki z ERP do TMS, a następnie przepisuje numer śledzenia z powrotem. Jeżeli oba systemy mają odpowiednie interfejsy, to przede wszystkim problem integracyjny.

3. Automatyzacja dokumentów albo workflow

Sytuacja zmienia się, gdy dane nie przychodzą w gotowych polach. Klient wysyła PDF, dostawca odpowiada mailem. Dokument trzeba sklasyfikować, dane sprawdzić, a brakującą informację skierować do odpowiedniej osoby. Tutaj potrzebujemy czegoś więcej niż zwykłego połączenia dwóch API.

Przykład:

Klient przesyła zamówienie w PDF. System odczytuje numer zamówienia, produkty, ilości i termin. Następnie porównuje je z danymi ERP. Standardowe pozycje przechodzą dalej. Nieznany kod produktu trafia do pracownika.

To jest już automatyzacja procesu.

4. Dedykowana warstwa automatyzacji

Są też procesy charakterystyczne dla konkretnej firmy. Przechodzą przez kilka systemów, mają własne reguły, występują często i kosztują dużo pracy, a gotowe narzędzia nie potrafią ich obsłużyć bez budowania kolejnych obejść. Wtedy własna warstwa automatyzacji może mieć sens.

Ale powód powinien brzmieć:

Mamy wartościowy, stabilny i specyficzny proces, którego istniejące systemy nie potrafią dobrze obsłużyć.

Nie:

Da się to napisać.

To, że coś można zbudować, nie oznacza jeszcze, że warto.

5. Wymiana albo modernizacja ERP

Na końcu jest sam ERP. Są sytuacje, kiedy to on rzeczywiście jest problemem: system jest niewspierany, bardzo trudny do integracji, mocno zmodyfikowany, blokuje aktualizacje albo opiera się na modelu danych, który nie pasuje już do firmy. Wtedy dokładanie kolejnych botów, Exceli i integracji tylko odsuwa problem. Ale kilka ręcznych kroków wokół ERP nie jest jeszcze argumentem za jego wymianą.

Dlatego sensowna kolejność przy analizie procesu wygląda tak:

ERP → integracja → workflow lub dokumenty → dedykowana automatyzacja → modernizacja ERP

Do kolejnego poziomu warto przechodzić dopiero wtedy, gdy wiadomo, dlaczego poprzedni nie wystarcza.

A gdzie w tym wszystkim jest AI?

Czasem w ogóle go nie ma. Jeżeli pole A z jednego systemu trafia do pola B w drugim, klient wysyła dane przez ustalone API, a kod produktu można jednoznacznie zmapować, to mamy reguły i integracje. AI niczego tu nie poprawia.

Zaczyna być ciekawe wtedy, gdy informacje trzeba zinterpretować: różne formaty zamówień w PDF, opisy produktów pisane przez klientów własnymi słowami, treść maili, nietypowe zapytania ofertowe czy dokumenty jakościowe. Wtedy model może pomóc zamienić nieustrukturyzowaną informację na dane, które rozumieją istniejące systemy. Ale nawet wtedy nie warto zaczynać od pytania:

Jakiego modelu użyć?

Najpierw proces. Potem najprostsza sensowna technologia.

Nie próbuj automatyzować wyjątków za wszelką cenę

Załóżmy, że dostawca wysyła potwierdzenie zamówienia. W większości przypadków wszystko się zgadza: produkt, ilość, cena i termin. Dziś pracownik może ręcznie otwierać każde potwierdzenie i sprawdzać te cztery rzeczy. To dobry kandydat do automatyzacji.

Problem pojawia się przy wyjątku. Dostawca zmienił termin o trzy tygodnie. Co wtedy? System może wykryć różnicę, sprawdzić, których zamówień produkcyjnych dotyczy, i przygotować wszystkie potrzebne dane. Ale ktoś nadal może potrzebować zdecydować, czy zaakceptować opóźnienie, zmienić plan produkcji, poszukać innego dostawcy albo poinformować klienta.

I nie ma w tym nic złego. Celem automatyzacji nie powinno być zawsze:

człowiek nie dotyka procesu.

Lepszym celem jest:

człowiek nie zajmuje się standardowymi przypadkami i dostaje tylko te, które naprawdę wymagają decyzji.

Tak projektują to również producenci ERP. Dynamics ma osobną obsługę faktur, których system nie potrafił prawidłowo przetworzyć. IFS przy automatycznym odczytywaniu RFQ pozwala użytkownikowi sprawdzić i poprawić wynik przed utworzeniem oferty.

To nie jest niedokończona automatyzacja. To rozsądny podział pracy: system robi to, co jest powtarzalne, a człowiek zostaje tam, gdzie koszt błędu albo niepewność są zbyt duże.

Jak sprawdzić, czy proces jest naprawdę zautomatyzowany?

Nie warto patrzeć na liczbę systemów ani modułów. Lepiej wziąć jeden konkretny proces, na przykład:

od momentu, kiedy klient wysyła zamówienie, do momentu, kiedy dostaje potwierdzony termin.

I przejść go krok po kroku, zaznaczając każdy moment, w którym człowiek:

• otwiera maila
• czyta PDF
• kopiuje dane
• eksportuje plik
• wpisuje informacje do drugiego systemu
• porównuje dwa źródła
• pyta kogoś o zgodę
• poprawia błąd
• ponownie uruchamia proces

To daje dużo więcej informacji niż pytanie:

Czy mamy automatyzację zamówień?

Można też mierzyć:

• jaki procent spraw przechodzi bez ręcznej ingerencji
• ile razy jedna sprawa jest ręcznie przekazywana dalej
• jak długo trwa cały proces
• ile z tego czasu to rzeczywista praca człowieka
• jaki procent przypadków trafia do wyjątków
• ile spraw wymaga poprawy

Przy liczeniu ROI szczególnie ważne jest rozróżnienie między czasem trwania procesu a rzeczywistą pracą człowieka. Faktura potrafi iść od skrzynki do zaksięgowania kilkanaście godzin, ale nikt nie wpisuje jej przez cały ten czas: większość z niego dokument po prostu czeka w skrzynkach, kolejkach i na akceptacjach.

Dlatego przy automatyzacji nie wystarczy powiedzieć:

Skrócimy proces z 12 godzin do 2 godzin.

Trzeba wiedzieć, ile było tam rzeczywistej pracy, gdzie proces czekał i co dokładnie zmieni automatyzacja.

Tak samo nie można zakładać, że każdy ręczny proces powinien być automatyzowany. Jeśli coś występuje bardzo rzadko, ciągle się zmienia, nie ma jasnych reguł, korzysta ze złych danych albo pojedynczy błąd może być bardzo kosztowny, to być może nie jest jeszcze dobrym kandydatem. Najpierw trzeba go zrozumieć. To dokładnie ten sam problem, który pojawia się przy ocenie gotowości procesu do automatyzacji.

Od jakiego pytania warto zacząć

ERP może działać dokładnie tak, jak powinien. Nie musi być stary, źle wdrożony ani wymagać wymiany. A mimo to firma może mieć mnóstwo ręcznej pracy dookoła niego.

Dlatego zamiast zaczynać od:

Co jeszcze powinniśmy wdrożyć do ERP?

albo:

Gdzie możemy użyć AI?

lepiej zacząć od prostszego pytania:

Gdzie w tym procesie informacja przestaje płynąć sama?

Gdzie ktoś otwiera maila. Gdzie czyta dokument. Gdzie przepisuje dane. Gdzie porównuje dwa systemy. Gdzie eksportuje Excel tylko po to, żeby godzinę później wpisać wynik z powrotem.

Dopiero wtedy można zdecydować, czego naprawdę potrzeba. Czasem będzie to funkcja ERP, czasem integracja, czasem automatyzacja dokumentów, a czasem własny system. A czasem okaże się, że procesu na razie w ogóle nie warto automatyzować.

ERP nie mówi nam, czy proces jest zautomatyzowany. Pokazuje tylko jeden z systemów, przez które ten proces przechodzi.