Robotyzacja procesów biznesowych, automatyzacja przepływów pracy i agenci AI: co oznacza każdy z tych terminów

Trzy określenia, których oferty używają jak trzech poziomów ceny za tę samą usługę, to trzy różne mechanizmy. Czym każdy się różni, co dostaje kupujący i dlaczego ta różnica jest dziś także prawna.

Trzy określenia bywają w jednej ofercie tak, jakby były trzema poziomami ceny za jedną i tę samą usługę: robotyzacja procesów biznesowych, automatyzacja przepływów pracy i agenci AI, i kupującemu sprawia to wrażenie, że trzeba wybrać jeden z trzech produktów, i zwykle wybiera się najdroższy, bo brzmi nowocześniej.

W rzeczywistości są to trzy różne mechanizmy, które rozwiązują różne problemy, a większość rzeczywistych zadań wymaga właśnie tego, który kosztuje najmniej. Ten artykuł nie porównuje narzędzi i nie poleca platformy; wyjaśnia, czym każdy mechanizm różni się technicznie, co kupujący w każdym przypadku dostaje i dlaczego właśnie ta różnica w ostatnich dwóch latach stała się także kwestią prawną.

Trzy mechanizmy, które odpowiadają na trzy różne pytania

Najprostszy sposób, żeby trzymać je osobno, to zapytać, jak każdy z nich wie, co ma robić: robotyzacja procesów biznesowych powtarza działania, które człowiek jej pokazał; automatyzacja przepływów pracy idzie ścieżką, którą ktoś narysował; agent AI wnioskuje ścieżkę sam z celu, który mu zadano, i z tej jednej różnicy wynika niemal wszystko inne, w tym cena, kruchość i to, co się dzieje, gdy sytuacja jest nieoczekiwana. Mechanizm, który powtarza, w nieoczekiwanej sytuacji się zatrzymuje; mechanizm, który idzie narysowaną ścieżką, wchodzi na gałąź błędu, jeżeli taka jest przewidziana; mechanizm, który wnioskuje, wymyśla coś nowego, i właśnie dlatego potrzebuje nadzoru, którego pozostałym dwóm nie trzeba.

Da się to sprawdzić na jednym konkretnym zadaniu, które w niemal każdej firmie wygląda tak samo: fakturę, która przyszła pocztą elektroniczną, trzeba wprowadzić do systemu księgowego. Robotyzacja procesów biznesowych rozwiązałaby tę pracę, otwierając program pocztowy, pobierając załącznik, otwierając okno księgowości i wypełniając pola dokładnie w tej kolejności, w jakiej zrobiłby to pracownik. Przepływ pracy rozwiązałby ją, przyjmując dokument interfejsem programistycznym i wywołując interfejs systemu księgowego z gotowymi polami, bez otwierania jakiegokolwiek okna. Agent AI rozwiązałby ją, dostając zadanie „zaksięguj tę fakturę” i sam decydując, które narzędzia wywołać i co zrobić, gdy czegoś brakuje.

Wszystkie trzy warianty potrafią to zadanie wykonać, i właśnie to wprowadza w błąd; różnica pojawia się nie wtedy, gdy wszystko jest w porządku, lecz wtedy, gdy dostawca zmieni formularz faktury, gdy w systemie pojawi się nowe pole obowiązkowe albo gdy ten sam towar nazwano na dwa sposoby, i właśnie te przypadki stanowią większą część rzeczywistej pracy.

Robotyzacja procesów biznesowych powtarza działania na ekranie

Robotyzacja procesów biznesowych, na co dzień nazywana angielskim skrótem RPA, to robot programowy, który działa w dokładnie tych samych interfejsach, w których pracuje człowiek: otwiera okno, klika, wkleja pole, naciska zapis. Systemy, z którymi pracuje, pozostają całkowicie niezmienione, i właśnie to jest zarówno jego główną zaletą, jak i główną słabością — zaletą jest to, że RPA radzi sobie z programami, które nie mają żadnego interfejsu wymiany danych i których nikt już nie przebuduje, dlatego często jest jedyną drogą do starych systemów księgowych albo branżowych, a słabością jest to, że robot widzi ekran, a nie dane, więc jakakolwiek zmiana na ekranie — przesunięty przycisk, nowe pole, inna wersja po aktualizacji — zatrzymuje pracę, a utrzymanie staje się stałym kosztem, a nie jednorazowym.

Kupujący dostaje tu licencję robota, środowisko uruchomieniowe i narzędzie do zarządzania, opis procesu oraz dziennik wykonanych działań, a w samej branży tę nazwę uważa się za nietrafioną: to, co RPA automatyzuje, jest zwykle osobnym zadaniem, a nie całym procesem, i właśnie ta niezgodność między nazwą a treścią rodzi część oczekiwań kupujących, które później się nie spełniają.

Kolejną cechą, która w projektach RPA bywa zaskoczeniem, jest to, że robot pracuje na tym samym poziomie dostępu, co człowiek, którego działania powtarza. Oznacza to, że robot potrzebuje własnego użytkownika w każdym systemie, że uprawnienia tego użytkownika trzeba przemyśleć tak samo jak każdego innego, i że działania robota w dzienniku systemu wyglądają jak działania człowieka, jeżeli nie ma osobnego konta, i w firmach, w których o tym nie pomyślano, później trudno odpowiedzieć na proste pytanie, kto dokonał konkretnego zapisu.

Automatyzacja przepływów pracy łączy systemy, a nie ekrany

Automatyzacja przepływów pracy pracuje warstwę głębiej: nie rozmawia z ekranem, tylko z samymi systemami, przez ich interfejsy programistyczne; przepływ pracy to z góry narysowany graf kroków — zdarzenie uruchamia łańcuch, łańcuch wywołuje działania w innych systemach, a między nimi może być też krok, w którym człowiek coś zatwierdza. Ponieważ wymiana danych idzie interfejsem, a nie obrazem, zmiany w wyglądzie systemu tego mechanizmu nie dotyczą, i to jest główny powód, dla którego tam, gdzie interfejs programistyczny jest dostępny, jest to niemal zawsze wybór trwalszy i tańszy w utrzymaniu niż powtarzanie działań na ekranie. Wada jest oczywista: jeżeli system nie ma interfejsu albo nie jest on dostępny na Państwa poziomie licencji, tej drogi po prostu nie ma.

Kupujący dostaje tu sam przepływ pracy, dane dostępowe, dziennik wykonania i gałąź błędu, i właśnie ta ostatnia jest tym, po czym warto oceniać ofertę, bo przepływ bez obsługi błędów działa tylko tak długo, jak długo wszystko jest w porządku. W polszczyźnie ten mechanizm ma własne, ustalone określenie: przepływ pracy, i angielskiego słowa w nawiasie nie trzeba tu dopisywać.

Słowo, które tu się przydaje i które warto stosować precyzyjnie, to robot programowy: to program, który naśladuje działania człowieka w interfejsie, a nie żaden robot fizyczny. Ta różnica jest w polszczyźnie ważniejsza niż w angielskim, bo słowo „robot” na co dzień oznacza urządzenie, i właśnie z tego nieporozumienia biorą się pytania o to, co robot „widzi” i co „rozumie” — niczego nie rozumie, powtarza to, co mu pokazano.

Agent AI wnioskuje ścieżkę samodzielnie

Agent AI różni się od obu poprzednich tym, że nie dostaje ścieżki, tylko cel, i ścieżkę wybiera sam, wywołując narzędzia, które ma do dyspozycji — wyszukiwanie, bazę danych, interfejs systemu, inny model. Właśnie działanie za pomocą narzędzi jest cechą, która odróżnia agenta od chatbota: chatbot odpowiada, agent robi, i z tego wynika, że agent radzi sobie z zadaniami, w których kolejność kroków nie jest z góry znana, i jednocześnie jest jedynym z trzech mechanizmów, którego wynik nie jest w pełni przewidywalny. Dwa identyczne uruchomienia mogą wybrać różne ścieżki, a to oznacza, że potrzebny jest zarówno nadzór, jak i jasno określone granice tego, co wolno mu zrobić samemu, a gdzie ma się zatrzymać i zapytać człowieka.

W praktycznej pracy oznacza to często, że agent jest właściwym mechanizmem tam, gdzie dane wejściowe są nieustrukturyzowane i różnorodne, a niewłaściwym tam, gdzie zadanie jest ściśle określone i powtarza się setki razy dziennie. W drugim przypadku przepływ pracy jest i tańszy, i bezpieczniejszy, a użycie agenta jest tam wydawaniem pieniędzy na nieprzewidywalność, której nikt nie potrzebował.

W przypadku agenta kupujący dostaje coś innego niż w obu pozostałych, i w ofertach nierzadko nie jest to opisane wcale. Oprócz samego agenta potrzebne są narzędzia, które wolno mu wywoływać, granice tego, co wolno mu robić bez zatwierdzenia, dziennik tego, co zrobił w każdym uruchomieniu, oraz sposób, żeby go zatrzymać — oferta, w której jest tylko model i prompt, opisuje pokaz, a nie narzędzie pracy.

Jest też różnica kosztu, której w planach projektu często brakuje: wykonanie przepływu pracy kosztuje niemal nic, bo to kilka wywołań, a koszty RPA to przede wszystkim licencja i utrzymanie, natomiast każde uruchomienie agenta kosztuje z kolei użycie modelu, i ten koszt rośnie wraz z wolumenem, więc mechanizm, który w próbie wydawał się tani, przy setkach uruchomień dziennie może okazać się najdroższy z trzech.

Gdzie kończy się automatyzacja, a zaczyna sztuczna inteligencja

Ta granica w ostatnich latach stała się kwestią prawną, bo akt w sprawie sztucznej inteligencji wiąże swoje obowiązki właśnie z definicją systemu AI. Art. 3 pkt 1 rozporządzenia opisuje go jako system, który wnioskuje, jak na podstawie otrzymanych danych wejściowych generować wyniki, takie jak predykcje, treści, zalecenia lub decyzje, i równie ważne jest to, co zostaje poza nią. W motywach rozporządzenia powiedziano wprost, że systemy oparte na zasadach określonych wyłącznie przez osoby fizyczne w celu automatycznego wykonywania operacji tej definicji nie spełniają, a wytyczne Komisji Europejskiej powtarzają to jeszcze konkretniej, nazywając wnioskowanie cechą niezastąpioną, a wykonywanie z góry określonych instrukcji — czymś, co do definicji nie wchodzi.

Tę samą granicę stawia motyw 12 polskiego tekstu rozporządzenia: definicja nie obejmuje systemów opartych na zasadach określonych wyłącznie przez osoby fizyczne w celu automatycznego wykonywania operacji — to nie jest osobny polski przepis, lecz brzmienie unijnej definicji, która w Polsce obowiązuje bezpośrednio, i skutek jest prosty: robot RPA, który przekopiowuje dane między dwoma oknami, oraz przepływ pracy, który wywołuje interfejs według narysowanej ścieżki, obowiązków z aktu w sprawie sztucznej inteligencji nie rodzą. Agent, który wnioskuje, te obowiązki może rodzić, i właśnie dlatego mieszanie nazw w ofercie nie jest wyłącznie kwestią stylu.

Co kupujący dostaje w każdym z przypadków

Oferty łatwiej porównywać, gdy patrzy się nie na nazwę, lecz na to, co po zakończeniu pracy zostaje w firmie: przy robotyzacji procesów biznesowych zostają licencja, środowisko uruchomieniowe, narzędzie do zarządzania, opis procesu i dziennik wykonanych działań, a z tego wszystkiego najważniejszy jest opis procesu, bo właśnie on mówi, co robot robi, gdy coś nie zgadza się z oczekiwaniem.

Przy przepływie pracy zostają sam przepływ, dane dostępowe do każdego podłączonego systemu, dziennik wykonania i gałąź błędu, i tu trzeba zwrócić uwagę na to, do kogo należą dane dostępowe i gdzie przepływ działa. Jeżeli działa na koncie dostawcy i na jego kluczach, to przerwanie współpracy oznacza też przerwanie pracy, i łatwiej to uporządkować w chwili zawierania umowy niż później.

Przy agencie, oprócz wszystkiego poprzedniego, zostaje też odpowiedzialność za to, co zrobił, i właśnie dlatego dziennik nie jest tam techniczną drobnostką, tylko samą istotą. Jeżeli nie da się powiedzieć, dlaczego agent w konkretnym przypadku zachował się tak, jak się zachował, to nie da się też odpowiedzieć klientowi, który pyta, dlaczego jego wniosek rozpatrzono właśnie w ten sposób.

Które terminy już się zaczęły

Ponieważ wymagania aktu wchodzą w życie stopniowo, trzeba wiedzieć, co obowiązuje już dziś, a co jeszcze nie. Obowiązek poinformowania człowieka, że komunikuje się z systemem sztucznej inteligencji, stosuje się od 2 sierpnia 2026 roku i dotyczy widocznego dla klientów agenta AI albo chatbota na Państwa stronie internetowej, i jeżeli taki jest zainstalowany, to jest to sprawa do załatwienia teraz, a nie w przyszłości.

Wymagania dla systemów wysokiego ryzyka, które obejmują takie dziedziny jak rekrutacja i decyzje dotyczące zatrudnienia, zaczyna się stosować 2 grudnia 2027 roku, a ten termin niedawno przesunięto, dlatego w części artykułów nadal stoi wcześniejszy rok, natomiast praktyki zakazane i sama definicja systemu obowiązują już teraz.

Niezależnie od aktu w sprawie sztucznej inteligencji pozostaje w mocy także wymóg RODO dotyczący decyzji, które zapadają wyłącznie w sposób zautomatyzowany i wywołują skutki prawne albo w podobny sposób istotnie wpływają na człowieka. Ten wymóg nie zależy od tego, czy mechanizmem jest agent, czy zwykły przepływ pracy: znaczenie ma to, czy decyzję o człowieku podejmuje maszyna sama.

Trzeba też rozumieć, dlaczego tę granicę poprowadzono właśnie przez wnioskowanie, a nie przez złożoność: program może być bardzo złożony i nadal nie być systemem AI, jeżeli każdy jego krok wyznaczył człowiek, i odwrotnie — całkiem niewielkie rozwiązanie, które używa modelu, żeby rozstrzygnąć, co zrobić, definicji odpowiada. To znaczy, że odpowiedzi na pytanie o obowiązki nie daje ani budżet projektu, ani liczba wierszy, tylko to, w jaki sposób zapada decyzja o następnym działaniu.

W praktyce te terminy najczęściej dotyczą jednej konkretnej rzeczy, którą wiele firm już ma: chatbota albo asystenta na witrynie — jeżeli jest widoczny dla klienta i opiera się na modelu językowym, obowiązek powiedzenia, że rozmówca nie jest człowiekiem, już obowiązuje, a w praktyce spełnia się go czytelnym napisem w interfejsie, nie akapitem w polityce prywatności. Jeżeli to zwykłe drzewo reguł z z góry napisanymi odpowiedziami, to nie jest system AI i ten obowiązek nie powstaje, ale różnicę warto utrwalić na piśmie, bo po roku nikt już nie pamięta, jak to było zrobione.

Dlaczego nazwy na rynku się mieszają

To pomieszanie ma też całkowicie obiektywną przyczynę, i nie jest nią wyłącznie marketing: narzędzia, które wcześniej robiły jedną rzecz, teraz robią kilka: platformy, które zaczynały jako narzędzia do przepływów pracy, oferują dziś także krok agenta, a firmy, które sprzedawały robotyzację procesów biznesowych, te same produkty opisują teraz jako takie, które działają same.

To znaczy, że po nazwie produktu nie da się już rozpoznać mechanizmu, a jedynym pewnym pytaniem do oferty jest to, jak w danym rozwiązaniu ustalana jest ścieżka działań: czy zapisuje ją człowiek, czy rysuje się ją jako graf, czy przy każdym uruchomieniu wybiera ją model. Odpowiedź na to jedno pytanie mówi i o cenie, i o kruchości, i o tym, czy obowiązki z aktu w ogóle mogą powstać.

Są też słowa, przy których trzeba uważać: skrót RPA zawsze warto najpierw rozwinąć jako robotyzację procesów biznesowych — pełna forma przy pierwszym użyciu czyni jasnym, że chodzi o oprogramowanie, a nie o maszyny, a spotykana forma robotyka procesów biznesowych jest błędem: robotyka to roboty fizyczne, a tu mowa o programie.

Drugie miejsce, w którym nazwy się mieszają, to samo użycie słowa „automatyzacja”: w polszczyźnie oznacza ono zarówno sterowanie procesami przemysłowymi, jak i automatyzację pracy biurowej, a to dwa zupełnie różne rynki z różnymi dostawcami. Jeżeli szukają Państwo oferty, trzeba powiedzieć, o którą z tych dwóch chodzi, bo w przeciwnym razie część otrzymanych ofert będzie z zupełnie innej branży.

Trzy twierdzenia, które w ofertach są nieprawdziwe

Pierwsze jest takie, że robotyzacja procesów biznesowych to sztuczna inteligencja, i to nie jest wyłącznie kwestia terminologii, bo z tego wynikają obowiązki: system, który wykonuje kroki napisane przez człowieka, definicji systemu AI nie spełnia, a oferta, która nazywa robota sztuczną inteligencją, albo sprzedaje drożej, niż trzeba, albo rodzi obawy, które nie mają podstaw; drugie jest takie, że agent to po prostu mądrzejszy chatbot, a różnica nie leży w mądrości, tylko w działaniu: chatbot generuje odpowiedź, agent wywołuje narzędzia i zmienia stan w innych systemach, i właśnie dlatego agentowi potrzeba granic, których chatbot nie potrzebuje, a firma, która tego nie rozdziela, często daje agentowi dostęp, o którym nikt nie pomyślał.

Trzecie jest takie, że wybór między tymi trzema to wybór między trzema dostawcami — w rzeczywistości jedno i to samo narzędzie często potrafi wszystkie trzy: platformy, które zaczynały jako narzędzia do przepływów pracy, oferują dziś także krok agenta, a to znaczy, że pytanie nie brzmi, co kupić, tylko jak w danym rozwiązaniu ustalana jest ścieżka działań.

Jak wybrać mechanizm do konkretnej pracy

Wybór w praktyce jest krótki, jeżeli pytania zadaje się we właściwej kolejności: proszę najpierw ustalić, czy zaangażowane systemy mają interfejs programistyczny, bo jeżeli mają, przepływ pracy niemal zawsze będzie trwalszy i tańszy w utrzymaniu niż powtarzanie działań na ekranie, i dalej pytanie nie dotyczy już mechanizmu, tylko skali. Jeżeli interfejsu nie ma i systemu nie da się zmienić, właściwym narzędziem jest robotyzacja procesów biznesowych, ale z otwartymi oczami: w budżecie musi być utrzymanie, a w projekcie ktoś odpowiedzialny, kto robota naprawi, gdy ekran się zmieni. Jeżeli dane wejściowe są nieustrukturyzowane, każdy przypadek jest inny i kolejności kroków nie da się z góry napisać, dopiero wtedy warto patrzeć w stronę agenta, i wtedy też trzeba wiedzieć, gdzie się zatrzymuje i kto go nadzoruje.

Najczęściej spotykane praktyczne rozwiązanie jest mieszane: przepływ pracy prowadzi łańcuch i wykonuje wszystkie przewidywalne kroki, a w jednym konkretnym miejscu wywołuje model, żeby przetworzyć nieustrukturyzowane wejście, i wynik oddaje z powrotem do łańcucha. Łączy to przewidywalność z elastycznością właśnie tam, gdzie jest potrzebna, i jest też najtańszym z wariantów, które w ogóle działają.

Jest jeszcze jeden praktyczny wzgląd, który rozstrzyga wybór częściej niż sama technika — każdy z trzech mechanizmów wymaga kogoś innego do utrzymania: przepływ pracy może utrzymywać ktoś, kto rozumie interfejsy systemów, robotowi potrzeba kogoś, kto zna właśnie to narzędzie i ekrany, z którymi pracuje, a agentowi dodatkowo kogoś, kto regularnie patrzy, co on naprawdę robi. Jeżeli w firmie takiego człowieka nie ma i nie planuje się kupować utrzymania, wybór między mechanizmami musi się zacząć od tego, który z nich da się realnie utrzymać.

Trzeba też nazwać ten błąd, który w tym wyborze kosztuje najdrożej, i nie jest nim wybór mechanizmu, tylko kolejność — firmy często najpierw wybierają narzędzie, potem szukają, co nim zautomatyzować, i dopiero potem rozumieją, że proces, który chciano zautomatyzować, nie jest jeszcze opisany. Właściwa kolejność jest odwrotna: najpierw opisuje się pracę z jej wyjątkami, potem ustala, czy systemy mają interfejsy, i dopiero wtedy wybiera mechanizm, bo w tym momencie wybór zwykle jest oczywisty i zajmuje pięć minut. Równie często spotyka się przeciwną skrajność, w której firma czeka, aż wszystko będzie uporządkowane, i nie zaczyna niczego; tu pomaga pamiętać, że przepływ pracy da się zbudować także dla jednego niewielkiego odcinka i rozszerzyć później, i że właśnie pierwszy ukończony odcinek zwykle pokazuje, gdzie naprawdę jest zator, znacznie precyzyjniej niż jakiekolwiek wcześniejsze oszacowanie.

Trzeba też powiedzieć, że zmiana mechanizmu później nie jest katastrofą, jeżeli sam proces jest opisany: firmy boją się złego wyboru tak, jakby był nieodwracalny, ale w praktyce największą wartością w projekcie jest właśnie opis procesu z jego wyjątkami, i ten opis zostaje przydatny niezależnie od tego, czy wykonuje go robot, przepływ pracy czy agent — wymiana wykonawcy wtedy, gdy opis jest już uporządkowany, jest znacznie tańsza niż pisanie opisu od nowa.

Co zapytać dostawcę

Jeżeli oferta już leży na stole, cztery pytania zwykle wystarczą, żeby zrozumieć, co naprawdę się w niej oferuje, niezależnie od słów w nagłówku. Pierwsze dotyczy tego, kto rozstrzyga następny krok: zapisany skrypt, narysowany graf czy model w chwili wykonania, i właśnie ta odpowiedź nazywa mechanizm precyzyjniej niż jakakolwiek nazwa produktu w tytule.

Drugie jest to, co się dzieje, gdy coś nie zgadza się z oczekiwaniem, i tu warto żądać konkretnego przykładu, a nie ogólnego twierdzenia o niezawodności. Trzecie jest to, do kogo należą dane dostępowe i gdzie rozwiązanie działa, bo od tego zależy, czy praca trwa dalej, gdy współpraca z dostawcą się kończy. Czwarte jest to, ile kosztuje utrzymanie w roku i co dokładnie się za nie dostaje, bo właśnie utrzymanie jest tym kosztem, którego w ofertach najczęściej nie podaje się wcale.

Jeżeli na któreś z tych pytań odpowiedź jest niejasna, nie znaczy to jeszcze, że oferta jest zła, tylko to, że o tej części jeszcze nie pomyślano, a uzgodnić to jest znacznie taniej przed umową niż po pierwszym zatrzymaniu.

Przydaje się też lista odwrotna, mianowicie pytania, które niczego nie rozstrzygają, choć zadaje się je często: jak duże firmy dostawca obsługiwał, ile lat jest na rynku i ile procesów zautomatyzował, mówi o doświadczeniu, ale nic nie mówi o tym, czy konkretny mechanizm pasuje do konkretnego zadania. Mało daje też pytanie, z której platformy dostawca korzysta, bo jedna i ta sama platforma potrafi dziś działać we wszystkich trzech mechanizmach, a odpowiedź na to pytanie nic Państwu nie mówi o kruchości rozwiązania ani o kosztach utrzymania.

Na koniec warto poprosić, żeby dostawca pokazał jeden już działający przykład i opowiedział, co w nim się zepsuło od instalacji i dlaczego. Odpowiedź na to pytanie o jakość pracy dostawcy mówi więcej niż jakakolwiek lista referencji, bo psuje się wszystko, co działa wystarczająco długo, a ważne jest to, jak szybko to zauważono i naprawiono.

Uczciwie jest też powiedzieć własną pozycję, bo ona wyjaśnia, dlaczego ten artykuł jest napisany właśnie tak: nie sprzedajemy licencji na robotyzację procesów biznesowych i nie jesteśmy partnerem żadnej takiej platformy, więc nie mamy interesu w tym, żeby wybrali Państwo najdroższy mechanizm.

Nasza praca to automatyzacja procesów biznesowych przepływami pracy i interfejsami między systemami, które już Państwo mają, w tym ten mieszany wariant, w którym łańcuchem steruje przepływ pracy, a model wywołuje się tylko w jednym nieustrukturyzowanym kroku, oraz osobno rozwiązania AI tam, gdzie zadanie naprawdę wymaga wnioskowania. Jeżeli mają Państwo teraz ofertę, w której te słowa są pomieszane, albo po prostu nie jest jasne, który mechanizm pasuje do Państwa zadania, proszę przysłać nam opis: często odpowiedzią jest, że wystarczy jedno połączenie, i to jest najtańsza odpowiedź, jaką da się dostać.