RPA — co to jest, ile kosztuje i kiedy się opłaca (2026)

Najprostsza analogia: stażysta, który tylko klika

Wyobraź sobie stażystę, który dostał kartkę z instrukcją:

„Otwórz skrzynkę mailową. Znajdź maile z tematem Faktura. Pobierz załącznik PDF. Przepisz numer faktury, NIP i kwotę do systemu księgowego. Zapisz. Przenieś maila do folderu Zrobione.”

Stażysta nie zastanawia się, czy faktura jest zasadna. Nie ocenia, nie improwizuje. Wykonuje punkt po punkcie. Robot RPA jest dokładnie takim stażystą — z trzema różnicami: pracuje 24 godziny na dobę, nigdy nie robi literówki i nigdy nie odchodzi z pracy.

Ma za to jedną słabość, o której warto wiedzieć od razu. Robot rozpoznaje przyciski i pola po ich położeniu oraz identyfikatorach na ekranie. Jeśli dostawca systemu przesunie przycisk albo doda nowe pole w formularzu, robot się zatrzyma — bo jego kartka z instrukcją przestała pasować do rzeczywistości. Pisze o tym wprost sam Microsoft: RPA „jest podatne na awarie, gdy coś się zmienia — na przykład gdy aktualizowane jest środowisko komputera lub układ ekranów aplikacji” (Microsoft Learn).

Jak działa robot RPA — klikanie zamiast integracji

Kluczowa cecha RPA, która odróżnia je od wszystkich innych form automatyzacji: robot działa na warstwie interfejsu graficznego, a nie na API. Tam, gdzie klasyczna integracja wymaga, żeby dwa systemy „umiały ze sobą rozmawiać”, robot RPA po prostu udaje pracownika przed ekranem. W dokumentacji Microsoftu różnica sprowadza się do jednego zdania: przez API mówisz aplikacji, co ma zrobić, a przy RPA pokazujesz jej to (Microsoft Learn).

W praktyce wygląda to tak:

1. Nagranie lub zaprojektowanie procesu — deweloper w narzędziu typu UiPath Studio albo Power Automate Desktop układa sekwencję kroków: otwórz przeglądarkę, zaloguj się, przejdź do zakładki X, odczytaj pole Y, wklej do Excela.
2. Identyfikacja elementów ekranu — robot rozpoznaje przyciski i pola na podstawie selektorów (identyfikatorów obiektów), a gdy ich nie ma — na podstawie obrazu i OCR.
3. Uruchomienie — bot wykonuje sekwencję na wirtualnej maszynie albo na komputerze pracownika, 24/7 lub na żądanie.
4. Orkiestracja — centralny panel (np. UiPath Orchestrator) rozdziela zadania między roboty, kolejkuje je i loguje wyniki.

To podejście ma jedną ogromną zaletę i jedną fundamentalną słabość. Zaleta: nie musisz ruszać systemów źródłowych. Robot podłączy się do dwudziestoletniego ERP-a, do SAP GUI, do aplikacji desktopowej bez API i do portalu urzędowego, w którym nikt nigdy nie przewidział integracji. Słabość: wszystko zależy od tego, żeby ekran nie zmienił wyglądu. Przesunięcie przycisku po aktualizacji aplikacji potrafi zatrzymać bota, który dotąd działał bezbłędnie przez rok.

Dlatego RPA to technologia „obejścia”, a nie „przebudowy”. Jeśli system ma dobre API, integracja przez API zawsze będzie tańsza i trwalsza. RPA zaczyna się tam, gdzie API się kończy.

Szersze spojrzenie na samo pojęcie robotyzacji — również w kontekście przemysłowym — opisujemy w tekście o robotyzacji procesów.

RPA a sztuczna inteligencja, no-code i agenci AI

Największe nieporozumienie w polskich tekstach o RPA: mylenie robota z AI. Klasyczny robot RPA nie rozumie niczego — wykonuje reguły. Jeśli faktura ma pole „NIP” w innym miejscu niż zwykle, bot regułowy zgłosi błąd. Model AI to rozpozna. To dwie różne warstwy, które w 2026 roku coraz częściej łączy się w jednym przepływie.

Praktyczny wniosek: RPA i AI nie konkurują — uzupełniają się. Nazywa się to inteligentną automatyzacją (IPA): model AI czyta i klasyfikuje dokument, a robot RPA wykonuje na jego podstawie fizyczne kliknięcia w systemie, którego nie da się zintegrować inaczej. Kiedy proces ma wyłącznie API i jasne reguły, RPA jest zbędne — wystarczy tańsze narzędzie no-code jak Zapier albo n8n do bardziej złożonych przepływów.

Jeśli zastanawiasz się, czym w ogóle różni się model językowy od robota programowego, zacznij od podstaw: czym jest sztuczna inteligencja i jak działa LLM. Nowa generacja rozwiązań — agenci AI — próbuje przejąć część zadań RPA, ale wciąż przegrywa z nim w jednym wymiarze: przewidywalności.

RPA a BPA i makra — gdzie przebiega granica

Drugie nieporozumienie dotyczy sąsiednich pojęć: makra w Excelu i BPA (Business Process Automation). To trzy różne poziomy ingerencji w firmę, nie synonimy.

Różnica, która realnie decyduje o wyborze: RPA akceptuje proces takim, jaki jest — BPA go kwestionuje. Robot przepisze dane między dwoma systemami dokładnie tak samo źle, jak robił to człowiek, tylko szybciej. BPA zapyta, dlaczego te dane w ogóle trzeba przepisywać.

Test decyzyjny jest prosty: jeśli możesz zmienić proces i masz dostęp do systemów — rób BPA. Jeśli nie możesz ruszyć ani procesu, ani systemu — zostaje RPA. Robotyzacja jest wtedy świadomym kompromisem, a nie porażką: czasem ERP-a sprzed dwudziestu lat po prostu nie da się zintegrować, a proces wynika z przepisu, którego nie zmienisz. Jak wygląda BPA od strony firmy — procesy, narzędzia i koszty — opisujemy w przewodniku po automatyzacji procesów biznesowych.

Attended, unattended, hybrid — trzy tryby pracy robota

Wybór trybu determinuje licencję, koszt i to, gdzie robot fizycznie działa — to pierwsza decyzja architektoniczna każdego wdrożenia.

Reguła kciuka: unattended daje realny zwrot, attended daje komfort. Robot nienadzorowany pracuje w nocy i weekendy, więc zastępuje wielokrotność etatu. Robot nadzorowany przyspiesza konkretnego pracownika, ale nie zdejmuje z organizacji pracy — dlatego jego ROI jest zwykle wolniejszy, mimo że licencja kosztuje mniej.

Które procesy nadają się do robotyzacji (a które nie)

Proces nadaje się pod RPA, gdy spełnia wszystkie pięć kryteriów. Pominięcie choćby jednego to najczęstsza przyczyna wdrożenia, które nigdy się nie zwróciło.

1. Regułowy — da się go opisać jako drzewo decyzyjne bez „to zależy”.
2. Powtarzalny i wolumenowy — wykonywany dziesiątki lub setki razy w miesiącu. Proces raz na kwartał nie zwróci kosztu bota.
3. Ustabilizowany — interfejsy i przepisy nie zmieniają się co miesiąc.
4. Oparty na danych cyfrowych — dane wejściowe są w systemie, mailu albo pliku, nie na kartce.
5. Niski odsetek wyjątków — jeśli ponad ~20% przypadków wymaga ludzkiej oceny, robot będzie głównie eskalował.

Procesy najczęściej robotyzowane wg działu

Najgłębiej zrobotyzowane branże w Polsce to finanse i księgowość — więcej o tym w tekstach o AI w księgowości i AI w bankowości. Robotyzacja procesów kadrowych ma z kolei własną specyfikę i ograniczenia prawne, które opisujemy przy okazji AI w HR, a wdrożenia w łańcuchu dostaw — w artykule o AI w logistyce.

Czego nie robotyzować: procesów niestabilnych, wymagających oceny („czy ta reklamacja jest zasadna?”), o niskim wolumenie oraz takich, które i tak trzeba przebudować. Robotyzacja złego procesu daje szybszy bałagan — nie oszczędność.

Ile kosztuje RPA — licencje i pełne TCO w PLN

Licencja to mniejszość kosztu. Za danymi HFS Research, przytaczanymi przez integratora GGS IT Consulting, licencje stanowią jedynie 25–30% całkowitego kosztu wdrożenia — reszta to development, infrastruktura, specjaliści i utrzymanie (ggsitc.com).

Cenniki producentów (dane z oficjalnych stron, lipiec 2026)

Ceny UiPath dla wdrożeń firmowych są negocjowane, ale polscy integratorzy podają realne widełki: robot attended ok. 1 600 EUR/rok, UiPath Studio ok. 4 400 EUR/rok, robot unattended ok. 10 000 EUR/rok. Minimalny sensowny zestaw dla jednego stanowiska to więc ok. 6 000 EUR/rok (robot attended + Studio), a dla jednego bota pracującego nocą — ok. 14 400 EUR/rok (ggsitc.com). Po kursie średnim NBP 4,3281 PLN/EUR (tabela 133/A/NBP/2026 z 13 lipca 2026) daje to odpowiednio ok. 26 000 PLN i ok. 62 000 PLN rocznie za samą licencję.

Pełny koszt wdrożenia — czego nie ma w cenniku

Do tego dochodzą koszty, których nie wycenimy tu za Ciebie, bo żadne niezależne badanie ich w Polsce nie zmierzyło: usługa integratora, szkolenia zespołu i utrzymanie botów po odbiorze. Krążące w sieci „widełki wdrożenia” i „roczny koszt całkowity od X tysięcy USD” pochodzą z blogów bez metodologii — nie przytaczamy ich, bo nie da się ich do niczego przypiąć. Jedyna uczciwa droga to zapytać dwóch integratorów o ofertę na Twój konkretny proces i porównać ją z arytmetyką poniżej.

Dwie liczby, które powinny zmienić Twoje planowanie:

• Ok. 51 000 PLN za zrobotyzowanie jednego procesu (30 dni × 1 700 PLN) to koszt samego developmentu — bez licencji i bez infrastruktury. Jeśli proces, który chcesz zrobotyzować, zabiera pracownikom 2 godziny miesięcznie, robot nie zwróci się nigdy.
• 150 000–200 000 PLN na środowisko produkcyjne i testowe to bariera wejścia, która dla MŚP praktycznie wyklucza model on-premise. Stąd rosnąca popularność modelu chmurowego i RPA-as-a-Service, gdzie płacisz za robota jak za usługę, a infrastruktura leży po stronie dostawcy.

Typowa ścieżka skalowania w polskich firmach: start od 2–3 procesów, rozszerzenie do 8–10 procesów w ciągu 24 miesięcy (Digital Teammates). Budżetuj z tą krzywą, nie z jednym botem.

Szerszy kontekst kosztowy — łącznie z tańszymi alternatywami no-code — znajdziesz w przewodniku o automatyzacji procesów biznesowych oraz w tekście o automatyzacji procesów w praktyce.

RPA a prawo i podatki w Polsce — trzy rzeczy, o których nie mówi integrator

1. Ulga na robotyzację NIE obejmuje robotów programowych

Najczęstszy błąd w budżetowaniu: założenie, że licencję UiPath odliczysz w ramach ulgi na robotyzację. Nie odliczysz. Ulga z art. 38eb ustawy o CIT pozwala odliczyć od podstawy opodatkowania 50% kosztów poniesionych na robotyzację, ale definiuje robota przemysłowego jako automatycznie sterowaną, programowalną, wielozadaniową, stacjonarną lub mobilną maszynę o co najmniej 3 stopniach swobody, posiadającą właściwości manipulacyjne bądź lokomocyjne dla zastosowań przemysłowych (art. 38eb ust. 3 ustawy o CIT).

Robot RPA nie jest maszyną i nie ma stopni swobody — jest skryptem. Ulga celuje w ramię na hali produkcyjnej, nie w bota klikającego w SAP-ie. Zbieżność nazw jest myląca i kosztowna.

Do tego ulga jest wygaszana: zgodnie z art. 38eb ust. 5 ustawy o CIT odliczenie stosuje się do kosztów poniesionych do końca roku podatkowego rozpoczętego w 2026 roku. W Sejmie leży poselski projekt przedłużający ulgę i podnoszący odliczenie do 100% (druk nr 1708, wpłynął 12 września 2025), ale Rada Ministrów zajęła wobec niego stanowisko negatywne (marzec 2026) — nie licz na przedłużenie. Planuj budżet RPA bez ulgi — a jeśli robotyzujesz również fizyczną produkcję, to właśnie tam ulga ma zastosowanie, i tam warto się spieszyć.

2. Robot podejmujący decyzje o człowieku to art. 22 RODO

Jeśli bot automatycznie odrzuca wniosek, rozlicza szkodę albo scoruje kandydata, wchodzisz w zautomatyzowane podejmowanie decyzji w indywidualnych przypadkach. Art. 22 RODO daje osobie fizycznej prawo do tego, by nie podlegać decyzji opartej wyłącznie na zautomatyzowanym przetwarzaniu, jeżeli wywołuje ona skutki prawne lub podobnie znacząco na nią wpływa. Wyjątki są trzy: niezbędność do zawarcia lub wykonania umowy, wyraźne dopuszczenie w prawie, wyraźna zgoda — a nawet wtedy trzeba zapewnić prawo do uzyskania interwencji człowieka, wyrażenia stanowiska i zakwestionowania decyzji (RODO, art. 22).

Kluczowe: determinizm RPA tu nie pomaga. Przepis nie pyta, czy decyzja jest przewidywalna — pyta, czy w pętli był człowiek. Regułowy bot odrzucający wnioski podlega art. 22 dokładnie tak samo jak model AI.

3. Klasyczne RPA jest poza AI Act — ale hybryda już nie

Robot wykonujący sztywne reguły nie jest systemem AI w rozumieniu unijnego rozporządzenia i sam z siebie nie uruchamia obowiązków AI Act. Ale w momencie, w którym dokładasz do niego warstwę rozumienia dokumentów, klasyfikacji albo agenta — przepływ wchodzi w zakres regulacji. Wtedy obowiązuje Cię m.in. art. 4 (kompetencje w zakresie AI), stosowany od 2 lutego 2025 roku, a jeśli robot obsługuje klienta przez czat — obowiązki przejrzystości z art. 50, stosowane od 2 sierpnia 2026 roku. Przesunięcia terminów wprowadzone pakietem Digital Omnibus dotyczą systemów wysokiego ryzyka, nie tych dwóch obowiązków — rozkładamy to na czynniki pierwsze w przewodniku po AI Act, a wymóg kompetencyjny w tekście o AI literacy.

Narzędzia RPA 2026 — czym się różnią

Jeśli rozważasz konkretnie lidera rynku, jego architekturę i licencjonowanie rozbieramy szczegółowo w osobnym tekście o UiPath. Warto też sprawdzić, czy zamiast robota nie wystarczy Ci Microsoft Copilot — w wielu firmach część „procesu do zrobotyzowania” to w rzeczywistości ręczne przepisywanie danych między plikami, które da się rozwiązać taniej.

Wdrożenie RPA krok po kroku — ile to trwa

Powyższe czasy to widełki projektowe, nie obietnica — jedyna twarda liczba w tej tabeli, ok. 30 dni roboczych na development jednego procesu, pochodzi od dostawcy usług RPA (Digital Teammates). Deklaracje typu „zwrot w pół roku”, którymi obudowane są oferty integratorów, nie mają w Polsce żadnego niezależnego pomiaru — policz zwrot sam, wzorem z sekcji poniżej.

Krok, którego nie wolno pominąć: pomiar „przed”. Bez baseline’u (ile razy w miesiącu, ile minut, ilu ludzi, ile błędów) nie wykażesz ROI i nie obronisz projektu przed CFO po roku.

ROI robotyzacji — jak go policzyć uczciwie

Formuła jest banalna, kłopot leży w mianowniku:

ROI = (roczna oszczędność − roczny koszt całkowity) / roczny koszt całkowity × 100%

Roczna oszczędność = liczba wykonań/rok × czas jednego wykonania × koszt godziny pracy × stopień automatyzacji.

Przykład — wprowadzanie faktur zakupowych:

• 1 200 faktur miesięcznie × 6 min = 120 godzin/mies. = 1 440 godzin/rok
• Koszt godziny pracy (całkowity koszt pracodawcy): 60 PLN
• Wartość pracy ręcznej: 1 440 × 60 = 86 400 PLN/rok
• Stopień automatyzacji 80% (20% faktur trafia do człowieka jako wyjątki) → oszczędność 69 120 PLN/rok
• Koszt roku 1: development (~51 000 PLN) + licencja unattended + Studio (~62 000 PLN) = ~113 000 PLN
• ROI rok 1: ujemny. ROI rok 2 (bez kosztu developmentu, sama licencja ~62 000 PLN): +11%

Wyliczenie na bazie stawek z Digital Teammates i widełek licencyjnych z GGS IT Consulting; koszt godziny pracy przyjęty jako założenie, podstaw własny.

RPA opłaca się przy wolumenie, nie przy pojedynczym procesie. Zwróć uwagę, co robi z tym rachunkiem drugi proces: licencja i infrastruktura są już opłacone, więc dokłada się tylko development. Ten sam robot obsługujący cztery procesy z podobnym stosem technologicznym rozkłada koszt licencji na cztery strumienie oszczędności — i dopiero wtedy zwrot w pierwszym roku przestaje być fikcją.

Do mierzenia efektów przyda się warstwa raportowa — jak ją zbudować, opisujemy w tekście o business intelligence.

Czego RPA nie zrobi — ograniczenia i dlaczego wdrożenia padają

Wdrożenia RPA rozbijają się o pięć rzeczy — żadnej z nich nie znajdziesz w broszurze integratora.

1. Bot rot (erozja botów). Robot jest przywiązany do wyglądu ekranu. Aktualizacja aplikacji, zmiana układu formularza, nowe pole w portalu urzędowym — i bot staje. Utrzymanie to nie 15% budżetu „na wszelki wypadek”, to stały etat kompetencji.
2. Robotyzacja bałaganu. Jeśli proces jest źle zaprojektowany, robot utrwali go na lata i uczyni nietykalnym („nie ruszajmy, bo bot padnie”).
3. Brak wolumenu. Najczęstszy grzech: automatyzuje się proces, który „wszystkich irytuje”, zamiast tego, który realnie kosztuje najwięcej godzin.
4. Brak właściciela. Po odejściu integratora nikt w firmie nie umie zmienić bota. Bez Centrum Kompetencji (CoE) wdrożenie umiera po pierwszej większej zmianie w systemie.
5. Iluzja, że robot rozumie. Klasyczne RPA nie interpretuje treści. Każdy nietypowy dokument to wyjątek, a wyjątki wracają do człowieka — i zjadają zakładaną oszczędność.

RPA w Polsce — rynek i realne wdrożenia

Globalnie rynek RPA rośnie szybko, ale szacunki firm badawczych rozjeżdżają się na tyle mocno, że żadnej pojedynczej liczby nie warto traktować jak pomiaru. Rząd wielkości daje IMARC Group: 6,3 mld USD w 2025 roku i prognoza 42,7 mld USD w 2034, przy CAGR ok. 23% (IMARC). Inni wydawcy podają dla tego samego rynku wartości bazowe od ok. 3 do ok. 6 mld USD i CAGR od 23% do niemal 39% — różnica bierze się z tego, co kto wlicza do „RPA”, a co do szerszej inteligentnej automatyzacji. Wartości polskiego rynku RPA nikt wiarygodnie nie zmierzył — kwoty powtarzane po branżowych blogach nie mają za sobą ani GUS, ani PARP, ani nazwanej firmy badawczej z opublikowaną metodologią, więc ich tu nie przytaczamy.

Najlepiej udokumentowane polskie wdrożenie to PKO Bank Polski: bank rozwija RPA od kwietnia 2018 roku, zrobotyzował 185 unikalnych procesów biznesowych, a łączna liczba zadań wykonanych przez roboty przekroczyła 100 milionów — to dane, które bank opublikował w marcu 2022 roku i od tego czasu nie zaktualizował (Bankomania PKO BP). Roboty obsługują m.in. wypłaty subwencji antykryzysowych, weryfikację zabezpieczeń kredytów hipotecznych i analizę ryzyka kredytowego na bazach z setkami tysięcy rekordów — procesy, które wcześniej trwały godziny, są realizowane w minuty.

Procentowe „efekty branżowe” — redukcja czasu o tyle a tyle, redukcja błędów o tyle a tyle — krążą po polskich blogach bez metodologii i bez wskazania, na jakiej próbie je zmierzono. Nie przytaczamy ich, bo nie da się ich zweryfikować. Jedyna liczba o twardym pokryciu w polskim RPA to ta z komunikatu PKO BP powyżej: wolumen zadań i liczba procesów, nie procent oszczędności.

A ile polskich firm faktycznie wdrożyło RPA? Nikt tego nie wie — i to jest uczciwa odpowiedź. GUS w cyklicznym badaniu „Społeczeństwo informacyjne w Polsce” mierzy wykorzystanie sztucznej inteligencji oraz robotów przemysłowych i usługowych, ale nie wyodrębnia RPA jako osobnej kategorii — a roboty programowe to coś zupełnie innego niż ramię na hali produkcyjnej. PARP również nie prowadzi badania poświęconego robotyzacji procesów biznesowych. Każdy konkretny procent („X% polskich firm wdrożyło RPA”), na jaki natrafisz, pochodzi więc albo z komercyjnej ankiety o nieujawnionej metodologii, albo jest przepisany z innego bloga.

Co można powiedzieć rzetelnie: RPA jest w Polsce technologią dużych organizacji — banków, ubezpieczycieli, centrów usług wspólnych (SSC/BPO) i sieci handlowych. Powód wynika wprost z arytmetyki z poprzedniej sekcji: przy koszcie rzędu kilkudziesięciu tysięcy złotych za zrobotyzowanie jednego procesu tylko tam pojedynczy proces generuje wolumen, który uzasadnia licencję, infrastrukturę i utrzymanie. W typowym MŚP ten próg po prostu się nie domyka — i dlatego mniejsze firmy trafiają raczej do warstwy no-code niż do RPA.

Robotyzacja jest jednym z filarów szerszej transformacji cyfrowej i najczęściej pojawia się w firmach, które mają już uporządkowane procesy — o czym więcej w przewodniku AI dla firm. W sektorze ubezpieczeń RPA łączy się dziś z modelami decyzyjnymi — zob. AI w ubezpieczeniach.

Czy agenci AI zabiją RPA?

To pytanie roku 2026. Odpowiedź jest niewygodna dla obu obozów: agenci AI przejmą część zadań RPA, ale nie tę najdroższą.

• Co przejmą: procesy z dużą zmiennością danych wejściowych — czytanie maili, klasyfikacja dokumentów, obsługa nietypowych przypadków, które dziś są „wyjątkami” eskalowanymi do człowieka. Tu model językowy jest po prostu lepszy od reguł.
• Czego nie przejmą (jeszcze): procesów wymagających 100% determinizmu i pełnego audytu. Bank nie postawi modelu probabilistycznego na wypłacie środków. Robot RPA wykonuje ten sam krok tak samo za każdym razem i zostawia log — to wciąż jego przewaga.
• Co powstaje naprawdę: hybryda. AI decyduje, RPA wykonuje. Wszyscy duzi dostawcy idą w tę stronę, dokładając do robotów warstwę rozumienia dokumentów i agentów AI orkiestrujących całe przepływy. Do obsługi klienta dokłada się jeszcze chatbota AI jako front, który zbiera dane wejściowe dla robota.

Praktyczna rekomendacja na 2026: nie kupuj dużej licencji RPA „na zapas”. Zrobotyzuj to, co jest twardo regułowe i wolumenowe, a resztę zostaw warstwie AI, która potanieje szybciej niż licencje enterprise.

Od czego zacząć — checklista

1. Zmierz, zanim zrobotyzujesz. Wypisz 10 procesów, dla każdego: liczba wykonań/miesiąc, minuty na wykonanie, liczba osób, odsetek błędów.
2. Odrzuć te, które mają API. Sprawdź, czy zamiast robota nie wystarczy integracja albo n8n.
3. Policz wolumen godzinowy. Poniżej ~500 godzin pracy rocznie na proces RPA prawie na pewno się nie zwróci.
4. Zacznij od PoC na jednym procesie — 2–6 tygodni, model chmurowy, minimalna licencja.
5. Zaplanuj utrzymanie od pierwszego dnia. Kto poprawi bota, gdy dostawca ERP zmieni interfejs? Jeśli nie znasz odpowiedzi, nie wdrażaj.

RPA nie jest ani rewolucją, ani przeżytkiem. To bardzo skuteczne, bardzo drogie narzędzie do jednego konkretnego zadania: obsługi systemów, których nie da się zintegrować inaczej. Użyte tam — zwraca się. Użyte gdziekolwiek indziej — jest najdroższym sposobem na przepisanie danych z Excela do Excela.

Najczęstsze pytania o RPA