RPA, czyli robotyzacja procesów biznesowych, to program, który robi na ekranie to, co robiłby człowiek: otwiera system, wpisuje dane, klika „zapisz”, pobiera plik, wysyła mail. Nie zmienia systemów, które łączy; udaje użytkownika. Dlatego działa szybko tam, gdzie integracja przez interfejs jest niemożliwa albo za droga, i dlatego bywa pułapką: robot klikający w ekran psuje się przy każdej zmianie ekranu. Poniżej, gdzie RPA ma sens w produkcji, a gdzie lepiej zrobić coś innego.
Gdzie robot ma sens
- Stary system bez interfejsu. ERP albo program magazynowy, do którego nie ma API, a dostawca nie żyje albo liczy sobie za każde zapytanie. Robot wpisuje tam to, co dziś wpisuje człowiek.
- Portale zewnętrzne. Portale klientów, przewoźników, urzędów: pobieranie zamówień, wysyłanie awiza, ściąganie dokumentów. Nie ma jak się do nich podłączyć inaczej niż przez przeglądarkę.
- Raporty cykliczne z kilku źródeł. Robot co rano loguje się do trzech systemów, pobiera zestawienia i składa je w jeden plik, który dotąd składał człowiek.
- Procesy tymczasowe. Migracja danych, okres przejściowy przed integracją właściwą. Robot pracuje kilka miesięcy i znika.
Wspólna cecha: proces jest w pełni określony (te same kroki, te same pola), a wejście jest przewidywalne.
Czego robot nie powinien robić
- Decydować. Robot, który „ocenia”, czy faktura jest zgodna z zamówieniem, albo który wybiera dostawcę, przekracza swoją rolę. Decyzje należą do reguł w systemie albo do człowieka; robot wykonuje.
- Zastępować integrację, która jest możliwa. Jeśli oba systemy mają API, robot klikający w ich ekrany jest droższy w utrzymaniu i wolniejszy. Interfejs przeżyje zmianę wyglądu ekranu, robot nie.
- Pracować na danych, których nikt nie sprawdza. Robot przepisuje błędy równie sprawnie jak dane poprawne. Jeśli wejście pochodzi z maila od klienta, potrzebny jest krok potwierdzenia.
- Być jedynym miejscem, gdzie proces istnieje. Gdy wiedza o procesie jest tylko w skrypcie robota, firma przestaje rozumieć własny proces.
- Obsługiwać wyjątki. Robot ma robić przypadek typowy i odkładać wyjątki do kolejki dla człowieka. Robot z pięćdziesięcioma gałęziami „jeśli” jest nie do utrzymania.
Przykłady z hali i biura
Dobre:
- przepisywanie zamówień z portalu klienta do ERP, z kolejką pozycji, których robot nie dopasował do indeksu,
- wysyłanie potwierdzeń wysyłki do portalu przewoźnika z danych w WMS,
- pobieranie z systemu RCP listy obecności i wpisywanie do starego programu płacowego,
- codzienne zestawienie przestojów z MES w pliku dla kierownika produkcji.
Złe:
- robot „sprawdzający jakość” na podstawie zdjęć,
- robot, który zmienia terminy zleceń w ERP według własnej reguły,
- robot przepisujący meldunki z papierowych kart (najpierw zbierz meldunek cyfrowo, potem nie ma czego przepisywać).
Jak wdrożyć robota, żeby nie bolało
- Opisz proces krok po kroku z ekranami. Jeśli nie da się go opisać, nie da się go zrobotyzować.
- Wydziel wyjątki. Co robot ma zrobić, gdy pole jest puste, gdy indeksu nie ma, gdy system nie odpowiada. Zawsze: odłożyć do kolejki z powodem, nigdy: zgadywać.
- Zaplanuj dziennik pracy. Każde uruchomienie, każda pozycja, każdy wyjątek zapisany; bez tego nikt nie wie, co robot zrobił w nocy.
- Ustal właściciela. Osobę po stronie firmy, która przegląda kolejkę wyjątków i zgłasza zmiany ekranów.
- Zaplanuj koniec. Zapisz, co musi się stać, żeby robot nie był potrzebny (integracja przez interfejs, nowy system), i kiedy to sprawdzicie.
Co policzyć
Liczba pozycji przepisywanych dziennie, minuty na pozycję, liczba błędów przepisywania w miesiącu: te trzy liczby zbierz przed wdrożeniem i po. Dołóż koszt utrzymania: ile razy w roku zmienia się ekran systemu, do którego robot się loguje, i ile godzin kosztuje poprawka. Robot, który wymaga poprawki co miesiąc, może kosztować więcej niż integracja.
Lista kontrolna
- Proces w pełni opisany, z ekranami i polami.
- Sprawdzone, czy nie ma interfejsu, który zastąpi robota.
- Wyjątki trafiają do kolejki dla człowieka, z powodem.
- Dziennik pracy robota i właściciel po stronie firmy.
- Miary przed i po: pozycje, minuty, błędy, poprawki robota.
- Zapisany warunek, przy którym robot przestaje być potrzebny.
W ErgoFlow RPA jest jednym z narzędzi, nie celem: proponujemy robota tam, gdzie interfejsu nie ma albo integracja jest nieopłacalna, z kolejką wyjątków i dziennikiem, a tam, gdzie interfejs jest, robimy integrację. Więcej na stronie Automatyzacja; odczyt dokumentów przed przepisaniem opisujemy na stronie AI.
Wpis ma charakter informacyjny. Opłacalność robota zależy od liczby pozycji, dostępności interfejsów i częstości zmian w systemach; porównanie z integracją robimy po audycie.
