Dlaczego firmy nadal kopiują dane między systemami ręcznie, mimo dostępności RPA

Zacznijmy od konkretnych liczb, które widzimy w wielu firmach. W typowej organizacji 50–200 osób, ręczne przekopywanie danych między systemami pochłania od kilkudziesięciu do kilkuset godzin tygodniowo. Nie jest to liczba, którą ktoś świadomie raportuje – ona po prostu rozprasza się w codziennym dniu pracy.

Przykładowe procesy. Dział księgowości: 8–12 godzin tygodniowo na wprowadzanie faktur do systemu z PDF-ów otrzymanych mailem. Dział sprzedaży: 4–6 godzin tygodniowo na przepisywanie leadów z różnych źródeł do CRM-a. Dział kadrowy: 3–5 godzin tygodniowo na przekazywanie danych nowych pracowników między 4 systemami. Dział magazynu: 5–8 godzin tygodniowo na uzgadnianie stanów między systemem sprzedażowym a magazynowym.

Sumarycznie: w firmie 100-osobowej zwykle 80–150 godzin tygodniowo wpada w ręczne przekopywanie. Razy 52 tygodnie to ponad 5000 godzin rocznie. Przy stawce z narzutami około 60–80 zł za godzinę to 300–400 tys. zł rocznie wpadające w przepisywanie danych, których nikt nie czyta jako celu samego w sobie.

Co najgorsze – ten koszt nie jest widoczny w żadnym raporcie. Nikt nie zatrudnia ludzi do przepisywania danych. Ten czas jest rozproszony między wiele osób i wiele zadań. Nikt nie wie, ile rocznie firma na tym traci, dopóki ktoś tego nie zmierzy.

Najczęstsza odpowiedź na pytanie dlaczego nie wdrażacie RPA brzmi: nie mamy czasu, żeby się tym zająć. To brzmi banalnie, ale jest najważniejszą realną blokadą.

Mechanizm jest taki. Zespół codziennie ma do wykonania 8 godzin rutynowej pracy. W tych 8 godzinach mieści się przepisywanie danych. Żeby zaplanować wdrożenie robota, trzeba zatrzymać się na chwilę i pomyśleć, opisać proces, znaleźć konsultanta, sprawdzić budżet, przeprowadzić rozmowę z zarządem. To może być 3–5 godzin dodatkowej pracy.

Tych 3–5 godzin nie ma. Skądkolwiek się ich nie weźmie, to ze szkodą dla codziennej rutyny. Manager też ich nie ma, bo siedzi w gaszeniu pożarów. Zarząd ich nie ma, bo zajmuje się sprzedażą i finansami. W rezultacie temat się odwleka. Po roku odwleka się dalej. Po trzech latach proces wciąż jest ręczny.

Paradoks: zespół traci kilkadziesiąt tygodni rocznie na ręczną pracę, żeby zaoszczędzić sobie 3–5 godzin dziś na rozmowę o automatyzacji. To jest najdroższy paradoks polskich firm.

Jak go przerwać: musi ktoś z zarządu uznać, że ta inwestycja czasu jest priorytetowa. Bez tej decyzji temat będzie się odwlekał w nieskończoność. Czasem najlepszą decyzją zarządu jest po prostu: w tym kwartale dwóch ludzi z zespołu poświęca 3 godziny tygodniowo na zajęcie się automatyzacją.

Wiele firm myli RPA z czymś, co istnieje wyłącznie dla wielkich korporacji. Ten obraz jest pielęgnowany przez marketing klasycznych dostawców RPA, którzy faktycznie celują w korporacje. Ale to nie jest pełny obraz rynku.

Klasyczne obawy: to musi być drogie, bo widziałem licencje za 100 tys. dolarów. To prawda dla UiPath Enterprise. To nieprawda dla Power Automate Desktop, który w wielu pakietach Microsoft 365 jest praktycznie bezpłatny (do podstawowych scenariuszy). Pierwszy robot da się wdrożyć za 15–25 tys. zł, łącznie z konsultantem.

Druga obawa: to musi być skomplikowane technicznie, mamy mały zespół IT. W praktyce większość prostych robotów Power Automate to drag-and-drop. Mała firma może mieć osobę, która sama buduje i utrzymuje 3–5 robotów. Specjalista zewnętrzny pomaga przy starcie, a potem firma działa sama.

Trzecia obawa: roboty się ciągle psują, słyszałem złe historie. Tak, niektóre roboty się psują – te zbudowane na niestabilnych systemach, źle utrzymywane, bez właściciela. Robot na stabilnym procesie, w starym systemie ERP, dobrze zaplanowany – działa latami bez ingerencji. Wszystko zależy od wyboru procesu i sposobu wdrożenia.

Czwarta obawa: i tak będziemy musieli zwolnić ludzi, których proces zostanie zrobotyzowany. To nieprawda w większości przypadków – jak pokazaliśmy w artykule Czy RPA zastąpi pracowników. W typowej firmie ludzie zostają, ale ich praca staje się sensowniejsza. Zwolnienia są mniejszością przypadków.

Często blokadą jest po prostu to, że zarząd nie wie, jak dużo czasu zespół traci na ręczne przepisywanie. Bo nikt nie raportuje przepisałam dziś faktury 4 godziny. Raportowanie wygląda inaczej: zajmowałam się fakturami.

Tymczasem między ten kilkadziesiąt do kilkuset godzin tygodniowo a zarządem stoi kilka warstw rozproszenia. Pracownik tego nie raportuje, bo to jest jego codzienność. Manager nie mierzy tego, bo nie ma sposobu. Dyrektor finansowy nie wie, bo to nie wpływa na żaden KPI. Zarząd słyszy zespół jest zajęty, ale nie wie czym.

Najprostszy sposób, żeby to zmienić: jedno małe ćwiczenie. Każda osoba w dziale przez tydzień zapisuje sobie czas (z dokładnością do 15 minut) tego, co robi. Bez sędziów, bez raportów – po prostu dla siebie. Po tygodniu zespół sumuje godziny w kategoriach: spotkania, decyzje, analiza, kontakt z klientem, przepisywanie danych, inne.

Wynik często szokuje. Okazuje się, że 30–50 procent czasu zespołu idzie w przepisywanie danych i obsługę systemów. Czyli zespół jest faktycznie wykorzystywany w połowie do tego, do czego został zatrudniony.

Po takim ćwiczeniu decyzja o automatyzacji robi się prosta, bo zarząd widzi czarno na białym, ile firma faktycznie wydaje na ręczne procesy. I że alternatywa – wdrożenie RPA – kosztuje znacznie mniej.

Wiele firm w przeszłości próbowało wdrożyć RPA i to się nie udało. Zostało im wrażenie, że RPA nie działa. Tymczasem powody porażki były zwykle nie technologiczne, tylko organizacyjne.

Klasyczny scenariusz porażki sprzed 5–7 lat. Firma wdrożyła UiPath, zbudowała 3 roboty, brakowało jej osoby do utrzymania, roboty się popsuły, projekt został zarzucony. Firma została z licencjami UiPath, których nikt nie używał, i z wrażeniem, że RPA nie działa.

Co się od tego czasu zmieniło. Po pierwsze, narzędzia stały się prostsze. Power Automate jest dziś wielokrotnie łatwiejszy do utrzymania niż UiPath sprzed lat. Po drugie, zrozumienie tego, jak wdrażać RPA z sukcesem, jest znacznie szersze – wiemy, że trzeba właściciela, że trzeba mierzyć efekt, że trzeba zacząć od nudnego pilota. Po trzecie, integracja RPA z AI i workflow daje dziś znacznie więcej możliwości niż kilka lat temu.

Wniosek: porażki sprzed kilku lat nie są dobrym sygnałem o tym, jak wdrożenia idą dzisiaj. Wiele firm, które miały kiepskie doświadczenia, dziś wraca do tematu z nowym podejściem i nowymi narzędziami. I dla wielu z nich to się udaje.

Jeśli w Twojej firmie był nieudany projekt RPA – warto wrócić do tego tematu, ale z lekcjami wyciągniętymi z poprzedniej próby. Często blokadą jest emocjonalne myślenie próbowaliśmy, nie działa, podczas gdy realnie wszystko, czego trzeba, to inne narzędzia i inne podejście.

Często w firmie temat RPA jest na agendzie od miesięcy, ale nikt nie przejmuje go jako swój. Każdy go widzi, każdy widzi w nim sens, nikt nie ma tego jako KPI. W rezultacie temat krąży, ale nie idzie do przodu.

Tu pomaga proste rozwiązanie: jedna nazwana osoba odpowiedzialna za pierwszy projekt. Nie cały komitet, nie cały zespół – jedna osoba. Może to być manager działu, dyrektor IT, ktoś z back-office. Ważne, że ma to w swoich celach kwartalnych, ma czas na zajęcie się, ma poparcie zarządu.

Bez takiej osoby projekt RPA – jak każdy inny projekt cross-funkcyjny – będzie się odbijał między działami. IT mówi, że to dział biznesowy musi opisać proces. Dział biznesowy mówi, że IT musi to skonfigurować. Nikt nie podejmuje pierwszego kroku. Po 6 miesiącach jesteśmy w tym samym miejscu.

Najlepsze wdrożenia, które widzieliśmy, miały od pierwszego dnia jasnego właściciela. Zwykle to nie był specjalista techniczny – to był człowiek, który rozumiał potrzebę i miał autorytet, żeby przepchnąć projekt przez firmę. Konsultant zewnętrzny dostarczał ekspertyzy technicznej; właściciel dostarczał kontekstu i decyzji.

Wszystkie pięć barier (brak czasu, mylne wyobrażenia, nieświadomość kosztu, historia porażek, brak właściciela) można pokonać, ale wymaga to świadomej decyzji zarządu. Praktyczna ścieżka wygląda następująco.

Krok pierwszy: pomiar. Tydzień, w którym zespół notuje, co robi. Wynik trafia do zarządu z konkretnymi liczbami: tyle godzin tygodniowo idzie w ręczne procesy, tyle to kosztuje rocznie.

Krok drugi: pilotowy proces. Jeden konkretny proces (najlepiej nudny, powtarzalny, na stabilnym systemie), wybrany jako pierwszy. Manager nazwany właścicielem. Konsultant zewnętrzny zaproszony do rozmowy.

Krok trzeci: pilot. 6–10 tygodni wdrożenia, koszt 20–40 tys. zł, jeden konkretny proces zrobotyzowany. Mierzymy: czas wykonania przed i po, liczbę błędów przed i po, satysfakcję zespołu.

Krok czwarty: nauka. Po pilocie zespół wie, jak żyć z robotem. Wie, kto go monitoruje, kto naprawia, jak reagować na zmiany. Ta wiedza jest najcenniejszym efektem pilota – ważniejszym niż sama oszczędność czasu.

Krok piąty: skala. Po pilocie kolejne wdrożenia idą wielokrotnie szybciej. Po roku firma ma 5–8 robotów, każdy obsługuje sensowny kawałek pracy, zespół jest zaangażowany, zarząd widzi efekty w liczbach.

Pełna ścieżka od pomiaru do 5 robotów: 9–12 miesięcy. Inwestycja: 100–200 tys. zł. Realny zwrot: zwykle w pierwszym roku, dalsze lata to czyste oszczędności i lepsza praca zespołu.

Firmy nadal kopiują dane ręcznie nie dlatego, że RPA jest za drogie albo za skomplikowane. Robią to z powodów ludzkich i organizacyjnych: brakuje czasu na zajęcie się tematem, są mylne wyobrażenia o RPA, nikt nie wie, ile firma realnie traci, historia poprzednich projektów zostawiła osad, i nikt nie czuje się odpowiedzialny.

Każdą z tych pięciu barier da się pokonać, ale wymaga to świadomej decyzji zarządu. Bez tej decyzji temat będzie się odwlekał latami, a firma będzie tracić setki godzin rocznie na ręczne przekopywanie danych.

Praktyczna ścieżka: pomiar czasu pracy zespołu, wybór pilotowego procesu, nazwanie właściciela, wdrożenie pilota w 6–10 tygodni, nauka, potem skala. Cały cykl od decyzji do 5 robotów: 9–12 miesięcy.

Najważniejsze: nie pytaj się czy RPA się opłaca w mojej firmie. Pytaj się ile godzin tygodniowo mój zespół przepisuje dane ręcznie. Odpowiedź na to drugie pytanie zwykle zamyka temat. Patrz też RPA w firmie – jakie procesy automatyzować i Jak działa RPA w praktyce.