Robot, który musi udowodnić, że zadziałał
Dlaczego zbudowałem Maptelo: automatyzację, która uczy się z pokazu, a każdy wynik sprawdza w systemie, zamiast wierzyć ekranowi.
Każdy, kto zbudował robota do pracy biurowej, zna ten moment. Robot przechodzi przez formularz, klika „Zapisz”, na ekranie pojawia się zielony komunikat, a w raporcie ląduje „sukces”. Tydzień później ktoś pyta, dlaczego klient dostał fakturę ze starą ceną. Okazuje się, że zapis nie przeszedł. Komunikat był prawdziwy dla ekranu, nie dla systemu.
Maptelo zaczęło się od tego jednego zdania: ekran może kłamać. Jeśli automatyzacja ma przejąć powtarzalną pracę, musi umieć pokazać dowód, że ją wykonała. Nie zrzut ekranu z zielonym paskiem, tylko odczyt z systemu, który mówi: ta cena naprawdę obowiązuje od tego dnia.
Pokaż raz zamiast programować
Klasyczne narzędzia RPA każą najpierw zaprojektować robota: krok po kroku, selektor po selektorze. Maptelo odwraca kolejność. Robisz proces tak jak zwykle, w Edge albo Chrome, a program patrzy i zapisuje: co kliknąłeś, co wpisałeś, na jakim ekranie i — co okazało się kluczowe — z której kolumny arkusza wziąłeś wartość.
Jeden pokaz to za mało, żeby zrozumieć proces. Z kilku pokazów Maptelo buduje model: kroki, dane wejściowe, reguły („ten krok tylko wtedy, gdy produkt ma kilka wersji cen”), wyjątki i sposób sprawdzenia wyniku. Tam, gdzie pokazy się różnią i nie widać dlaczego, program nie zgaduje. Zadaje pytanie, a odpowiedź zostaje w pliku obok modelu, razem z tym, kto jej udzielił.
Z tego samego modelu powstaje dokumentacja: instrukcja krok po kroku ze zrzutami ekranu, schemat BPMN i raport, w którym zaznaczone są kroki zapisujące dane. Dokumentacja i automatyzacja się nie rozjeżdżają, bo mają jedno źródło.
Dowód zamiast komunikatu
Najważniejsza decyzja projektowa: każdy przebieg kończy się jednym z siedmiu wyników, a sukces jest tylko jeden. VERIFIED dostaje wiersz, którego efekt potwierdził niezależny odczyt z systemu — API albo baza, nigdy ten sam ekran, na którym robot klikał.
Pozostałe wyniki są równie ważne, bo mówią, co zrobić dalej. HALTED_SAFE znaczy: zatrzymałem się przed zapisem i nic nie zmieniłem. NEEDS_RECONCILIATION: coś mogło się zapisać, ale odczyt tego nie potwierdza, więc sprawdza człowiek, a robot nie ponawia na ślepo. Do tego idempotencja: jeśli wiersz arkusza już jest w systemie, robot nie wpisze go drugi raz. W filmie widać to na pierwszym wierszu, który zrobiłem ręcznie podczas pokazu: robot sprawdził bazę i go pominął.
Gdy system się zmienia
Roboty najczęściej umierają po aktualizacji aplikacji. Sprawdziłem to na prawdziwym ERP: proces zbudowany na Odoo 17 uruchomiłem po aktualizacji do Odoo 18, gdzie zmieniły się adresy ekranów, nazwy kolumn i sam sposób dodawania ceny. Wiersz w tabeli zamienił się w okno dialogowe.
Maptelo samo odnalazło przeniesione ekrany i pola: część po znakach rozpoznawczych ekranu, część z pomocą modelu językowego. Tam, gdzie zmienił się sam przebieg zapisu, zatrzymało się bez zapisu, zamiast zgadywać. Wynik tego testu jest dla mnie ważniejszy niż jakakolwiek funkcja: zero fałszywych VERIFIED i zero złych zapisów. Naprawy trafiają do nowej wersji modelu dopiero wtedy, gdy przebieg z nimi zakończył się potwierdzonym wynikiem, i dopiero po akceptacji człowieka.
Zanim mu zaufasz
Firma nie odda procesu robotowi, bo ktoś tak powiedział. Dlatego jest tryb cienia: robot przechodzi wiersze arkusza bez zapisu, ludzie robią swoją pracę, a potem niezależny odczyt porównuje jedno z drugim. W filmie tryb cienia wychwycił literówkę: ktoś wpisał 135,10 zamiast 131,50 z arkusza.
„Bez zapisu” musi znaczyć naprawdę bez zapisu. Odoo zapisuje porzucony formularz, kiedy opuszczasz stronę, więc próba na sucho potrafiła zostawić w systemie wiersz. Maptelo przed wyjściem odbiera stronie możliwość wysyłania danych i dopiero wtedy ją zamyka. To jeden z wielu przypadków, w których test na prawdziwym systemie nauczył mnie więcej niż jakikolwiek plan.
Dla danych wrażliwych jest tryb prywatny: zrzuty zakrywają wpisane wartości i zawartość tabel, a model nie przechowuje przykładowych danych.
Agent dostaje narzędzie, nie klucze
Zatwierdzony proces można udostępnić agentowi AI jako narzędzie, przez Model Context Protocol. W moim teście Claude dostał polecenie zwykłym językiem: ustaw w cenniku cenę 150 dla tego produktu od 1 grudnia. Maptelo wykonało dokładnie zatwierdzone kroki i zwróciło wynik z dowodem: VERIFIED, odczyt z bazy i zrzut ekranu. Powtórzone polecenie skończyło się jako „już zrobione”, bez drugiego wpisu. Agent nie dostaje hasła ani sesji. Dostaje proces, który ktoś sprawdził.
Gdzie to jest dziś
Maptelo działa na komputerze osoby, która robi proces — tak jak Power Automate Desktop, a nie jak usługa w chmurze. Nagrania, modele i dowody zostają na dysku. Do pracy bez terminala jest Studio: strona dostępna tylko na tym komputerze, w której można nagrać pokaz, zbudować model, odpowiedzieć na jego pytania i uruchomić proces na arkuszu, obserwując każdy wiersz na żywo.
Za tym stoi ponad 400 testów automatycznych, w tym pełne przebiegi w przeglądarce. Kolejne kroki to instalator dla Windows i pilotaż na prawdziwym procesie — ale tylko za zgodą działu IT i z oceną ochrony danych.
Najwięcej nauczyło mnie jedno: automatyzacja nie jest gotowa, kiedy działa. Jest gotowa, kiedy potrafi udowodnić, że zadziałała, i uczciwie powiedzieć, kiedy tego nie wie. (Projekt razem z filmem: Maptelo.)