Automatyzacja obiegu dokumentów z wykorzystaniem AI i Power Automate

Wprowadzenie: po co automatyzować obieg dokumentów z AI i Power Automate

Faktura trafia na skrzynkę mailową, umowa czeka na sprawdzenie, a pracownik szuka osoby odpowiedzialnej za akceptację. Samo przechowywanie plików w wersji elektronicznej nie rozwiązuje takich problemów. Cyfrowy dokument nie oznacza jeszcze cyfrowego procesu — jeśli trzeba ręcznie przepisywać dane, przekazywać załączniki i przypominać o terminach, obsługa nadal zależy od dostępności i pamięci konkretnych osób.

Automatyzacja obiegu dokumentów pozwala zastąpić te powtarzalne czynności uporządkowanym przepływem pracy. Jej celem nie jest wyłącznie szybsze przetwarzanie plików. Równie ważne są ograniczenie błędów, przypisanie odpowiedzialności oraz możliwość sprawdzenia, na jakim etapie znajduje się dana sprawa. Połączenie AI z Power Automate pomaga objąć takim procesem również dokumenty, których treść i układ nie są jednolite.

AI analizuje dokument, a Power Automate organizuje pracę

W tym połączeniu obie technologie pełnią różne funkcje. AI pomaga rozpoznać rodzaj dokumentu i wydobyć z niego potrzebne informacje, także wtedy, gdy pochodzą one ze skanu lub pliku o zmiennym układzie. Power Automate odpowiada natomiast za uruchamianie działań i przekazywanie danych między aplikacjami zgodnie ze zdefiniowanymi regułami. Sam nie zastępuje modelu analizującego treść — pozwala wykorzystać jego wynik w procesie biznesowym.

To istotna różnica względem automatyzacji opartej wyłącznie na sztywnych regułach. Reguły dobrze sprawdzają się tam, gdzie dane są uporządkowane, na przykład w formularzu z ustalonym zestawem pól. AI wnosi wartość wtedy, gdy te same informacje pojawiają się w różnych miejscach i formach. Nie każdy etap wymaga jednak sztucznej inteligencji: przewidywalne czynności warto pozostawić zwykłej automatyzacji, a AI stosować tam, gdzie potrzebna jest analiza treści.

Jakie korzyści daje automatyzacja obiegu dokumentów?

Takie podejście znajduje zastosowanie między innymi w obsłudze faktur kosztowych, umów, zamówień i korespondencji przychodzącej. Choć każdy z tych procesów ma inne wymagania, potrzeby organizacji są podobne:

• Mniej pracy ręcznej — ograniczenie przepisywania informacji i wielokrotnego wprowadzania tych samych danych.
• Krótszy czas obsługi — przekazywanie spraw do kolejnego kroku bez konieczności ręcznego inicjowania każdej czynności.
• Większa przejrzystość — łatwiejsze ustalenie statusu dokumentu i osoby odpowiedzialnej za dalsze działanie.
• Spójniejszy sposób pracy — stosowanie ustalonych zasad niezależnie od tego, kto przyjął dokument.

Nie oznacza to, że każdy dokument powinien przechodzić przez cały proces bez udziału człowieka. Wyniki analizy AI mogą być niepełne lub błędne, a część decyzji wymaga oceny merytorycznej i odpowiednich uprawnień. Dobrze zaprojektowana automatyzacja odciąża ludzi od rutyny, ale pozostawia im kontrolę nad wyjątkami i decyzjami o istotnych skutkach biznesowych.

Uzasadnienia dla wdrożenia warto szukać przede wszystkim tam, gdzie dokumenty pojawiają się regularnie, wymagają podobnych czynności i angażują kilka osób lub działów. Punktem wyjścia powinien być konkretny problem: długi czas oczekiwania, częste pomyłki albo brak widoczności statusu spraw. Wówczas skuteczność rozwiązania można oceniać przez rzeczywistą zmianę — na przykład krótszy czas obsługi, mniej korekt lub mniejszą liczbę ręcznych interwencji — zamiast przez sam fakt wykorzystania AI.

Architektura rozwiązania end-to-end: komponenty, integracje i przepływ danych

W automatyzacji obiegu dokumentów Power Automate pełni rolę koordynatora procesu, a AI odpowiada za interpretację treści. To rozróżnienie ma znaczenie projektowe: model może rozpoznać rodzaj dokumentu lub odczytać jego dane, ale nie powinien samodzielnie decydować o całej ścieżce biznesowej. Za kolejność działań, przekazywanie informacji między systemami i uruchamianie odpowiednich reguł odpowiada warstwa przepływów.

W Cognity często słyszymy pytania, jak praktycznie zaplanować współpracę tych komponentów — odpowiadamy na nie także na blogu. Architektura end-to-end powinna obejmować nie tylko przetwarzanie pliku, lecz także jego powiązanie z rekordem sprawy, statusem obsługi oraz danymi zapisanymi w systemie docelowym. Dzięki temu dokument nie staje się odizolowanym załącznikiem, którego dalszy los trzeba ustalać ręcznie.

Podział odpowiedzialności między komponentami

Podstawowy układ rozwiązania można przedstawić jako pięć współpracujących warstw:

• Źródła dokumentów — skrzynki pocztowe, biblioteki SharePoint, formularze i systemy biznesowe. Dostarczają plik oraz kontekst jego przyjęcia, na przykład nadawcę, datę wpływu lub numer sprawy.
• Orkiestracja w Power Automate — uruchamia proces po określonym zdarzeniu, wywołuje usługi i przekazuje wyniki między kolejnymi krokami. W większych rozwiązaniach warto rozdzielić ją na mniejsze przepływy o jasno określonych zadaniach.
• Usługi AI — przekształcają treść dokumentu w informacje możliwe do wykorzystania przez proces. AI Builder zapewnia integrację z Power Platform przy ograniczonej ilości kodu, natomiast Azure AI Document Intelligence pozwala budować rozwiązania oparte na usługach Azure i interfejsach API. Wybór zależy od wymagań, dostępnych modeli, kosztów oraz sposobu utrzymania.
• Warstwa danych — przechowuje pliki, metadane i stan procesu. SharePoint może pełnić funkcję repozytorium dokumentów, a Dataverse obsługiwać powiązane rekordy biznesowe i relacje między nimi. Te komponenty mogą się uzupełniać, zamiast wzajemnie zastępować.
• Systemy docelowe i interfejs użytkownika — ERP, CRM lub aplikacja w Power Apps umożliwiają wykorzystanie danych oraz obsługę zadań wymagających udziału człowieka.

Przepływ danych: plik, rekord procesu i wynik przetwarzania

Po przyjęciu dokumentu rozwiązanie powinno nadać mu stały identyfikator procesu, wykorzystywany w kolejnych wywołaniach i zapisach. Plik pozostaje w wyznaczonym repozytorium, natomiast między komponentami można przekazywać jego identyfikator lub odwołanie oraz potrzebne metadane. Samą zawartość pliku udostępnia się usługom, które rzeczywiście muszą ją przetworzyć.

Wynik działania AI trafia do ustrukturyzowanego rekordu powiązanego z dokumentem. Warto oddzielić wynik pierwotny od danych zatwierdzonych do dalszego wykorzystania. System docelowy otrzymuje wówczas dane zgodne z ustalonym kontraktem integracyjnym, czyli uzgodnionym zestawem pól, formatów i identyfikatorów, niezależnie od układu dokumentu źródłowego.

Integracje i zarządzanie stanem procesu

Do połączeń z popularnymi usługami można wykorzystać gotowe konektory Power Automate. Gdy potrzebna operacja nie jest dostępna, alternatywą jest API wywoływane bezpośrednio lub przez konektor niestandardowy. Dostęp do źródeł lokalnych może wymagać bramy danych — zależnie od systemu i wybranego sposobu połączenia.

Stan procesu powinien być zapisany poza historią pojedynczego uruchomienia przepływu. Pozwala to rozdzielić operacje wykonywane od razu od zadań długotrwałych, które kończą się osobnym zdarzeniem. Ułatwia również wznowienie obsługi bez ponawiania całego obiegu. Już w projekcie należy określić, który komponent odpowiada za aktualizację statusu i jak rozpoznawane jest ponowne dostarczenie tego samego zdarzenia, aby nie tworzyć podwójnych rekordów w systemach biznesowych.

Etap 1–2: przyjęcie dokumentu oraz rozpoznanie i klasyfikacja (OCR/AI Builder/Azure AI)

Pierwsze dwa etapy obiegu dokumentów odpowiadają na trzy pytania: skąd pochodzi plik, czy można odczytać jego treść i jakiego rodzaju dokument zawiera. To rozróżnienie ma praktyczne znaczenie: odczytanie tekstu nie oznacza jeszcze rozpoznania faktury, umowy czy zamówienia. Power Automate organizuje obsługę tych kroków, natomiast funkcje OCR i modele AI dostarczają informacji potrzebnych do wyboru właściwej ścieżki przetwarzania.

Etap 1: przyjęcie dokumentu do procesu

Punktem wejścia może być wiadomość ze skrzynki współdzielonej, plik dodany do biblioteki SharePoint albo dokument przekazany przez aplikację. Przepływ Power Automate rozpoczyna pracę po zdarzeniu obsługiwanym przez odpowiedni wyzwalacz, a następnie pobiera zawartość pliku. Samo otrzymanie powiadomienia o nowym dokumencie nie zawsze oznacza bowiem, że przepływ ma już dostęp do jego danych binarnych.

Na tym etapie warto zapisać podstawowy kontekst: źródło wpływu, datę otrzymania, nazwę pliku oraz identyfikator pozwalający powiązać dokument z wiadomością lub zgłoszeniem. Dzięki temu późniejsze rozpoznanie nie odbywa się w oderwaniu od informacji o pochodzeniu materiału. Oryginał powinien pozostać dostępny niezależnie od wyników analizy AI.

Przed wysłaniem pliku do rozpoznania należy sprawdzić, czy jego format i rozmiar mieszczą się w wymaganiach wybranej usługi oraz czy zawartość jest dostępna do odczytu. Załącznik nie zawsze jest dokumentem biznesowym: wiadomość może zawierać również logo ze stopki lub inne obrazy techniczne. Wstępne filtrowanie ogranicza zbędne wywołania usług AI, ale nie powinno opierać się wyłącznie na nazwie pliku.

Etap 2: odczyt treści i rozpoznanie typu dokumentu

OCR, czyli optyczne rozpoznawanie znaków, zamienia tekst widoczny na skanie lub zdjęciu na postać możliwą do przetwarzania. W przypadku PDF zawierającego poprawną warstwę tekstową ponowne rozpoznawanie obrazu nie zawsze jest potrzebne — zależy to od użytej usługi i przyjętej ścieżki obsługi. Wynik odczytu może obejmować nie tylko tekst, lecz także informacje o jego położeniu na stronie.

Klasyfikacja realizuje inne zadanie: przypisuje dokument do ustalonej kategorii, na przykład faktury, umowy lub zamówienia. Może wykorzystywać treść, układ dokumentu i informacje towarzyszące. Adres skrzynki odbiorczej czy temat wiadomości są pomocnymi wskazówkami, lecz nie stanowią pewnego potwierdzenia typu dokumentu.

Warto przy tym oddzielić funkcję od narzędzia: OCR jest techniką odczytu, a AI Builder i Azure AI udostępniają możliwości jej wykorzystania oraz dalszej analizy dokumentów.

Wybór AI Builder nie oznacza automatycznie, że dowolny model przetwarzania dokumentów rozpozna wszystkie oczekiwane kategorie. Mechanizm klasyfikacji trzeba dobrać osobno do zadania. Przy niewielkiej liczbie jednoznacznych typów wystarczające mogą być reguły oparte na odczytanej treści. Przy bardziej zróżnicowanych materiałach warto rozważyć model uczony na reprezentatywnych przykładach poszczególnych klas.

Co powinno być wynikiem tych etapów?

Do dalszego przetwarzania powinien trafić dokument powiązany ze źródłem wpływu, wynikiem odczytu oraz przypisaną kategorią. Jeśli użyty mechanizm udostępnia ocenę pewności klasyfikacji, warto zachować ją razem z wynikiem. Należy też dopuścić kategorię „nierozpoznany”, zamiast wymuszać przypisanie każdego pliku do jednej ze znanych klas. Na tym etapie celem jest ustalenie właściwej ścieżki obsługi, a nie jeszcze odczytywanie i sprawdzanie wszystkich pól biznesowych.

Etap 3–4: ekstrakcja danych i walidacja — od odczytanej treści do wiarygodnych informacji

Rozpoznanie tekstu nie oznacza jeszcze, że dane z dokumentu można bezpiecznie wykorzystać w procesie biznesowym. Numer faktury może zostać odczytany poprawnie, ale przypisany do niewłaściwego pola. Kwota może wyglądać wiarygodnie, choć dotyczy wartości netto, a nie sumy do zapłaty. Dlatego ekstrakcja i walidacja powinny być osobnymi etapami: pierwsza ustala, jakie informacje zawiera dokument, druga sprawdza, czy spełniają warunki dalszego przetwarzania.

Ekstrakcja danych: przypisanie wartości do właściwych pól

Na etapie ekstrakcji model AI przekształca treść dokumentu w uporządkowany zestaw danych. W przypadku faktury mogą to być numer dokumentu, dane sprzedawcy, daty, waluta i kwoty. Dla umowy istotne będą inne informacje, na przykład strony, okres obowiązywania czy termin wypowiedzenia. Zakres odczytu powinien wynikać z potrzeb procesu — zbieranie wszystkich dostępnych informacji zwiększa złożoność, niekoniecznie poprawiając użyteczność rozwiązania.

Power Automate odbiera wynik z wybranej usługi AI i przypisuje wartości do uzgodnionej struktury pól. Warto już na tym etapie rozróżnić dane wymagane, opcjonalne oraz wymagane warunkowo. Brak daty zakończenia nie musi oznaczać błędu, jeśli umowa została zawarta na czas nieokreślony. Nie należy też zastępować brakującej kwoty zerem: brak wartości i wartość zerowa mają inne znaczenie biznesowe.

Przed sprawdzaniem reguł dane zwykle wymagają normalizacji, czyli ujednolicenia zapisu. Dotyczy to między innymi dat, separatorów dziesiętnych, kodów walut i identyfikatorów podatkowych. Transformacje muszą uwzględniać format źródłowy, aby nie zamienić niejednoznacznej daty lub kwoty na błędną wartość. Dobrą praktyką jest zachowanie zarówno odczytu źródłowego, jak i wartości po normalizacji — ułatwia to późniejsze wyjaśnienie rozbieżności.

Walidacja: pewność odczytu to nie poprawność biznesowa

Jeżeli model udostępnia wskaźnik pewności dla danego pola, można wykorzystać go do kierowania danych do kontroli. Nie jest to jednak dowód zgodności z dokumentem ani z zasadami organizacji. Wysoka pewność odczytu numeru rachunku nie potwierdza, że rachunek należy do właściwego kontrahenta. Z kolei poprawnie rozpoznana kwota nie gwarantuje zgodności z zamówieniem.

W Cognity omawiamy walidację danych zarówno od strony technicznej, jak i praktycznej — zgodnie z realiami pracy uczestników. W Power Automate warto połączyć ocenę wyniku AI z jednoznacznymi regułami biznesowymi. Podstawowe warstwy kontroli obejmują:

• Kompletność i format: obecność wymaganych pól, poprawny typ danych, dopuszczalna waluta oraz właściwa struktura identyfikatora.
• Spójność wewnętrzną: zgodność sum i zależności między polami, z uwzględnieniem zasad zaokrągleń oraz specyfiki dokumentu, na przykład korekty faktury.
• Zgodność z danymi referencyjnymi: porównanie kontrahenta, numeru zamówienia lub innych wartości z właściwym systemem źródłowym.

Reguły powinny zwracać nie tylko wynik „poprawne” lub „błędne”, lecz także konkretną przyczynę. Komunikat „suma pozycji różni się od wartości netto o 12,50 PLN” jest bardziej użyteczny niż ogólne „błąd walidacji”. Progi pewności i tolerancje należy ustalać na podstawie testów na reprezentatywnych dokumentach oraz znaczenia poszczególnych pól, zamiast stosować jedną wartość dla całego dokumentu.

Korekta użytkownika jako kontrola danych, nie akceptacja dokumentu

Gdy dane nie spełniają ustalonych warunków, przepływ powinien umożliwić ich weryfikację przez użytkownika. To inna czynność niż biznesowa akceptacja dokumentu: celem jest potwierdzenie, co rzeczywiście zapisano w źródle. Formularz korekty powinien pokazywać dokument lub odpowiedni fragment, odczytaną wartość oraz powód skierowania pola do sprawdzenia.

Po zmianie wartości należy ponownie uruchomić powiązane reguły. Korekta kwoty netto może zmienić wynik kontroli sum, a poprawienie identyfikatora kontrahenta — rezultat porównania z bazą. Warto zapisywać wartość pierwotną, wartość po korekcie, osobę wprowadzającą zmianę i czas operacji. Sama korekta w formularzu nie oznacza automatycznego douczenia modelu AI; wykorzystanie takich danych do poprawy modelu wymaga osobnego, kontrolowanego działania.

Jakość danych: mierzyć błędy, nie tylko liczbę obsłużonych dokumentów

Skuteczność tego etapu najlepiej oceniać na poziomie pól: jak często wymagają korekty, jakich informacji najczęściej brakuje i które reguły wykrywają rozbieżności. Warto również okresowo sprawdzać próbkę danych uznanych automatycznie za poprawne, aby wykrywać błędy pomijane przez walidację. Wynikiem etapu powinien być uporządkowany zestaw danych z jednoznacznym statusem kontroli, a nie jedynie zestaw wartości zwróconych przez AI.

Etap 5–7: akceptacje, archiwizacja i raportowanie

Po rozpoznaniu dokumentu i zweryfikowaniu danych proces przechodzi od przetwarzania informacji do podejmowania decyzji. Dokument musi trafić do właściwej osoby, zostać zapisany wraz z historią obsługi i dostarczyć danych do oceny sprawności całego obiegu. Na tych etapach główną rolę odgrywają Power Automate Approvals, SharePoint lub Dataverse oraz Power BI. AI wspiera przygotowanie danych, ale nie zastępuje ustalonych zasad odpowiedzialności.

Etap 5: akceptacje w Power Automate Approvals

Power Automate Approvals pozwala kierować wnioski o zatwierdzenie do wskazanych osób i wykorzystywać ich odpowiedzi w dalszym przebiegu procesu. Adresata można wyznaczać na podstawie zweryfikowanych danych dokumentu oraz reguł organizacji, na przykład jednostki organizacyjnej, kategorii kosztu czy poziomu uprawnień decyzyjnych.

Podstawowa różnica dotyczy sposobu zbierania decyzji. W trybie pierwszej odpowiedzi rozstrzygająca jest odpowiedź jednej z przypisanych osób. W trybie akceptacji przez wszystkich zatwierdzenie wymaga zgody każdego uczestnika, natomiast odrzucenie przez jednego z nich może zakończyć ten krok. Jeżeli decyzje muszą zapadać w określonej kolejności, przepływ powinien uruchamiać kolejne kroki akceptacji sekwencyjnie.

Wniosek o akceptację powinien zawierać zwięzły opis sprawy, najważniejsze dane oraz odnośnik do dokumentu. Samo przypisanie zadania nie nadaje jednak dostępu do pliku — osoba zatwierdzająca musi mieć odpowiednie uprawnienia w repozytorium. Decyzję, osobę odpowiadającą, datę i komentarz warto zapisywać w trwałym rejestrze procesu, zamiast traktować historię uruchomień przepływu jako archiwum biznesowe.

Etap 6: archiwizacja w SharePoint i Dataverse

Zamknięcie akceptacji powinno prowadzić do uporządkowania dokumentacji: zapisania końcowego statusu, powiązania pliku z decyzjami oraz zachowania jego identyfikatora. Ważne jest również wskazanie wersji, której dotyczyła akceptacja. Bez tego późniejsza zmiana pliku może utrudnić ustalenie, jaka treść została rzeczywiście zatwierdzona.

Te narzędzia nie muszą się wykluczać. Plik może znajdować się w SharePoint, a dane sprawy i historia decyzji — w Dataverse. Warunkiem jest jednoznaczne powiązanie obu zasobów i określenie, który system jest źródłem obowiązującego statusu.

Zapisanie pliku nie oznacza jeszcze wdrożenia archiwum zgodnego z wymaganiami organizacji. Okresy przechowywania, zasady usuwania oraz ewentualna ochrona przed zmianami wymagają osobnej konfiguracji. W środowisku Microsoft 365 mogą w tym pomagać mechanizmy retencji i zarządzania rekordami Microsoft Purview, zależnie od posiadanych licencji.

Etap 7: raportowanie w Power BI

Power BI pozwala oceniać obieg dokumentów na podstawie danych zapisanych podczas jego realizacji. Aby raport pokazywał przebieg procesu, a nie tylko jego końcowy rezultat, należy rejestrować daty wejścia w poszczególne etapy oraz kolejne zmiany statusu.

Najbardziej użyteczne wskaźniki to liczba otwartych spraw, czas oczekiwania na akceptację, łączny czas obsługi oraz udział odrzuceń i zwrotów do poprawy. Ich porównanie według typu dokumentu lub jednostki organizacyjnej pomaga ustalić, gdzie rzeczywiście powstają opóźnienia.

Raport analityczny nie zastępuje jednak kolejki bieżących zadań. Aktualność widoku w Power BI zależy od sposobu połączenia ze źródłem i konfiguracji odświeżania. Trzeba też odrębnie zaprojektować dostęp do raportów: uprawnienia do dokumentów w SharePoint nie przenoszą się automatycznie na dane udostępniane w Power BI.

Przykład wdrożenia: faktury i umowy krok po kroku

Faktura i umowa mogą trafić do organizacji tym samym kanałem, ale wymagają innych ścieżek obsługi. W przypadku faktury celem jest przygotowanie zweryfikowanych danych do księgowania i uzyskanie zgody na koszt. Przy umowie najważniejsze są kontrola wersji, ocena warunków, podpisanie właściwego dokumentu oraz pilnowanie terminów. Poniższy przykład pokazuje, jak przełożyć te różnice na dwa procesy w Power Automate.

Ścieżka faktury: od załącznika do przekazania do księgowości

Załóżmy, że faktury zakupowe wpływają na dedykowaną skrzynkę pocztową, a osoby odpowiedzialne za koszty są wskazane w rejestrze zamówień. Każdy dokument otrzymuje identyfikator sprawy, który łączy plik źródłowy, odczytane dane, decyzje akceptujących i status obsługi.

1. Rejestracja dokumentu. Przepływ zapisuje załącznik w wyznaczonej bibliotece i tworzy rekord ze statusem „Do weryfikacji”. Zachowuje również datę wpływu oraz identyfikator wiadomości, aby można było wrócić do źródła dokumentu.
2. Odczyt pól potrzebnych do rozliczenia. Model przetwarzania dokumentów pobiera numer faktury, NIP sprzedawcy, datę wystawienia, termin płatności, walutę oraz kwoty netto, VAT i brutto. Jeżeli proces opiera się na zamówieniach, odczytuje także numer zamówienia. Pozycje faktury warto uwzględnić wtedy, gdy rzeczywiście służą do rozliczenia dostawy lub podziału kosztów.
3. Powiązanie z zakupem. Power Automate wyszukuje zamówienie i przypisaną do niego osobę odpowiedzialną. Sprawdza też, czy kombinacja dostawcy i numeru faktury nie występuje już w rejestrze. Podejrzenie duplikatu zatrzymuje standardową ścieżkę, ale nie powoduje automatycznego usunięcia pliku.
4. Akceptacja kosztu. Faktura trafia do właściciela zamówienia. Przykładowa reguła może przewidywać dodatkową zgodę osoby odpowiedzialnej za budżet po przekroczeniu ustalonego progu kwotowego. Akceptujący otrzymuje najważniejsze dane, odnośnik do dokumentu oraz informację o wykrytych rozbieżnościach.
5. Przekazanie do księgowości. Po uzyskaniu wymaganych zgód przepływ przekazuje dane do systemu finansowego przez dostępną integrację albo tworzy zadanie dla księgowości. Status „Przekazano” pojawia się dopiero po potwierdzeniu odbioru. Akceptacja kosztu nie oznacza automatycznie zaksięgowania ani wykonania płatności.

Przykładowy wyjątek: faktura nie zawiera numeru zamówienia. Zamiast kierować ją do przypadkowej osoby, przepływ tworzy zadanie przypisania kosztu do działu i właściciela. Po uzupełnieniu danych dokument wraca do akceptacji bez ponownego odczytywania całego pliku. Faktury korygujące wymagają natomiast osobnej ścieżki powiązania z dokumentem pierwotnym — nie powinny być traktowane jak zwykłe faktury zakupowe.

Ścieżka umowy: od projektu do kontroli zobowiązań

W tym wariancie pracownik przekazuje projekt umowy przez formularz, wskazując właściciela biznesowego i rodzaj współpracy. Dokument pozostaje powiązany z jedną sprawą także wtedy, gdy pojawiają się kolejne wersje.

1. Utworzenie sprawy. Power Automate zapisuje projekt i nadaje mu status „Analiza projektu”. Formularz dostarcza kontekst, którego nie zawsze da się odczytać z treści: cel zawarcia umowy, odpowiedzialny dział i planowany termin rozpoczęcia współpracy.
2. Przygotowanie metryki. AI proponuje wartości pól: strony umowy, przedmiot, wartość i walutę, okres obowiązywania, zasady wypowiedzenia oraz informację o automatycznym przedłużeniu. Brak jednoznacznego zapisu oznacza konieczność weryfikacji, a nie zgodę na uzupełnienie pola domysłem.
3. Opinie i akceptacje. Właściciel biznesowy potwierdza zakres współpracy, a odpowiednie osoby oceniają warunki prawne i finansowe zgodnie z przyjętymi regułami. Decyzje dotyczą konkretnej wersji pliku. Wprowadzenie zmian po akceptacji uruchamia ponowną ocenę w zakresie określonym przez organizację.
4. Podpisanie i zamknięcie uzgodnień. Zatwierdzony projekt trafia do podpisu w odrębnym procesie. Sama akceptacja w Power Automate nie zastępuje podpisu. Po otrzymaniu podpisanego dokumentu osoba odpowiedzialna potwierdza jego kompletność i zgodność z zaakceptowaną wersją.
5. Uruchomienie przypomnień. Na podstawie potwierdzonych dat przepływ tworzy powiadomienia o końcu obowiązywania lub zbliżającym się terminie złożenia wypowiedzenia. Odbiorcą jest właściciel umowy wskazany w rejestrze.

Przykładowy wyjątek: umowa przewiduje automatyczne przedłużenie, lecz termin wypowiedzenia zależy od daty rozpoczęcia świadczenia usług. Dopóki ta data nie zostanie potwierdzona, system oznacza termin jako wymagający uzupełnienia. Aneks należy powiązać z umową główną i zweryfikować jego wpływ na zapisane zobowiązania, zamiast bezwarunkowo nadpisywać wcześniejsze dane.

Najczęstsze problemy wdrożeniowe i jak je rozwiązać

Najwięcej problemów z automatyzacją obiegu dokumentów pojawia się nie na standardowej ścieżce, lecz wtedy, gdy dokument jest nieczytelny, brakuje osoby akceptującej albo system docelowy przestaje odpowiadać. Wdrożenie warto oceniać nie tylko po liczbie poprawnie przetworzonych plików, ale również po tym, czy błędy są wykrywane, trafiają do właściwych osób i można je usunąć bez ponownego wykonywania całego procesu.

Niska jakość skanów: problem zaczyna się przed rozpoznawaniem

Rozmazane zdjęcia, obcięte krawędzie, przekrzywione strony i zbyt silna kompresja mogą powodować błędy odczytu, których sam model AI nie skoryguje. Warto określić minimalne wymagania dla dokumentów wejściowych: kompletność stron, czytelność tekstu i brak zabezpieczeń uniemożliwiających przetwarzanie. Jeżeli dostępny jest oryginalny plik elektroniczny, zwykle lepiej wykorzystać go zamiast wydruku zeskanowanego ponownie.

Dokumenty o niewystarczającej jakości powinny trafiać do korekty lub ponownego dostarczenia, zamiast bez końca przechodzić przez ten sam mechanizm rozpoznawania. Skuteczność należy sprawdzać na rzeczywistych materiałach, także tych najtrudniejszych. Test wyłącznie na wyraźnych, jednolitych skanach daje mylący obraz gotowości rozwiązania.

Wyjątki: ponowienie operacji nie zawsze jest rozwiązaniem

Trzeba rozróżnić błędy techniczne, takie jak chwilowa niedostępność usługi, od wyjątków biznesowych, takich jak brak wymaganej informacji czy rozbieżność danych. W pierwszym przypadku pomocne są ograniczone ponowienia z odstępami. W drugim potrzebna jest decyzja człowieka, uzupełnienie dokumentu lub jego odrzucenie — kolejne uruchomienie przepływu nie usunie przyczyny.

Każdy nierozwiązany wyjątek powinien mieć właściciela, opis problemu i wskazany następny krok. Istotne jest również zabezpieczenie przed duplikatami: wznowienie procesu po awarii nie może skutkować ponownym utworzeniem tej samej pozycji w systemie docelowym. Sam status „niepowodzenie” w historii Power Automate nie wystarcza do sprawnej obsługi operacyjnej.

Uprawnienia i połączenia: przepływ działa, dopóki nie zmieni się dostęp

Rozwiązanie przetestowane na koncie autora może przestać działać po odebraniu mu uprawnień, zmianie zasad uwierzytelniania lub odejściu z organizacji. Przed uruchomieniem produkcyjnym należy ustalić właścicieli przepływów i połączeń, sposób ich utrzymania oraz procedurę przekazania odpowiedzialności. Dobór tożsamości używanej przez automatyzację zależy od możliwości konkretnego konektora i polityk organizacji.

Stosuj zasadę najmniejszych niezbędnych uprawnień i testuj proces z perspektywy rzeczywistych ról użytkowników. Sprawdź także, czy historia uruchomień, komunikaty błędów i powiadomienia nie udostępniają poufnych danych osobom, które nie powinny ich widzieć. Polityki DLP w Power Platform mogą ograniczać łączenie konektorów, ale nie zastępują poprawnej konfiguracji dostępu do dokumentów.

SLA: zakończony przepływ nie oznacza terminowo załatwionej sprawy

Najdłuższe opóźnienia często wynikają z oczekiwania na człowieka. Dlatego SLA powinno obejmować czas obsługi sprawy, a nie tylko wykonania automatycznych czynności. Należy określić moment rozpoczęcia pomiaru, sposób liczenia dni roboczych oraz to, czy oczekiwanie na uzupełnienie dokumentu wstrzymuje bieg terminu.

Przypomnienia warto uzupełnić o zastępstwa i eskalacje do konkretnej roli. Trzeba też uwzględnić limity czasu działania Power Automate: procesu mogącego trwać tygodniami nie należy projektować jako bezterminowo oczekującego pojedynczego uruchomienia. Przy przeciążeniach pomocne jest monitorowanie wieku zaległych spraw, nie tylko liczby nowych dokumentów.

Zmienność dokumentów: jakość rozpoznawania wymaga stałej kontroli

Nowy układ faktury, inna wersja formularza lub dodatkowy język mogą obniżyć skuteczność modelu, mimo że sam przepływ nadal kończy się poprawnie. Warto obserwować udział ręcznych korekt i błędów w podziale na rodzaje dokumentów. Łączny wynik może ukrywać pogorszenie jakości w jednej, istotnej grupie.

Zmiany modeli i konfiguracji należy sprawdzać na stałym zestawie testowym obejmującym zarówno wcześniejsze, jak i nowe warianty dokumentów. Przed publikacją trzeba upewnić się, że poprawa obsługi nowego formatu nie pogarsza dotychczasowych wyników. Wersjonowanie konfiguracji oraz możliwość powrotu do poprzedniej wersji ograniczają ryzyko, że drobna aktualizacja zakłóci cały obieg.

Jak zacząć: minimalny POC, metryki sukcesu i plan skalowania

Pierwszy projekt nie powinien obejmować całego obiegu dokumentów. Lepiej wybrać jeden powtarzalny proces, w którym ręczna praca zajmuje dużo czasu, a wynik automatyzacji można jednoznacznie ocenić. Dobrym kandydatem jest obsługa określonego rodzaju faktur albo rejestracja umów na podstawie kilku kluczowych danych. Celem POC, czyli weryfikacji koncepcji, jest sprawdzenie, czy AI i Power Automate rozwiązują konkretny problem biznesowy przy akceptowalnym koszcie i poziomie ryzyka.

Minimalny POC: wąski zakres, reprezentatywne dokumenty

Na początek wystarczy jeden typ dokumentu, jedno źródło jego wpływu i jasno określony rezultat, na przykład przygotowanie danych do zatwierdzenia przez pracownika. AI odpowiada za interpretację treści, natomiast Power Automate koordynuje działania zgodnie z ustalonymi regułami. Nie trzeba od razu obejmować testem wszystkich wariantów procesu ani integrować wszystkich systemów.

Przed rozpoczęciem prac warto spisać zakres próby, właściciela biznesowego oraz warunki uznania jej za udaną. Zestaw testowy powinien odzwierciedlać rzeczywistą pracę: zawierać dokumenty typowe, mniej czytelne oraz odbiegające od dominującego układu. Próbki używane do konfiguracji należy oddzielić od materiału przeznaczonego do końcowej oceny. Testowanie wyłącznie na znanych dokumentach może dać zbyt optymistyczny obraz skuteczności.

Już na tym etapie trzeba ustalić zasady wykorzystania danych, dostęp do dokumentów oraz przewidywane koszty licencji i usług AI. POC nie musi mieć pełnej infrastruktury produkcyjnej, ale nie powinien opierać się na założeniach, których organizacja nie będzie mogła później utrzymać. W Cognity łączymy teorię z praktyką — dlatego zagadnienia planowania automatyzacji rozwijamy także w formie ćwiczeń na szkoleniach.

Metryki sukcesu: porównanie z pracą ręczną

Punkt odniesienia należy zmierzyć przed uruchomieniem automatyzacji. Bez informacji o obecnym czasie obsługi, liczbie korekt i kosztach trudno ocenić, czy nowy proces rzeczywiście przynosi korzyści. W POC warto śledzić kilka wskaźników:

• Czas pracy człowieka na dokument — obejmujący sprawdzenie wyniku i poprawki, a nie tylko czas zaoszczędzony na przepisywaniu.
• Poprawność danych — ocenianą osobno dla poszczególnych pól, szczególnie tych, których błąd ma istotne konsekwencje biznesowe. Ocena pewności modelu nie zastępuje porównania z prawidłowym wynikiem.
• Udział dokumentów niewymagających korekty — pokazujący, jak często rezultat automatyzacji jest użyteczny bez dodatkowej pracy.
• Całkowity czas przejścia przez proces — od wpływu dokumentu do ustalonego rezultatu, z uwzględnieniem oczekiwania na działania użytkowników.
• Koszt obsługi dokumentu — uwzględniający usługi AI, odpowiednią część kosztów licencji, pracę osób weryfikujących oraz utrzymanie rozwiązania.

Progi akceptacji trzeba ustalić przed oceną wyników. Nie istnieje jeden poziom skuteczności odpowiedni dla każdego procesu: błąd w opisie dokumentu może mieć inne znaczenie niż pomyłka w kwocie lub identyfikatorze kontrahenta. O powodzeniu próby powinien decydować bilans jakości, oszczędności i ryzyka, nie sam fakt poprawnego wykonania przepływu.

Od POC do pilotażu i większej skali

POC potwierdza wykonalność pomysłu. Pilotaż sprawdza go w codziennej pracy ograniczonej grupy użytkowników, a wdrożenie produkcyjne wymaga stałej odpowiedzialności za działanie i utrzymanie procesu. Przejście między tymi etapami powinno wynikać z pomiarów, a nie z udanej prezentacji.

Skalowanie najlepiej prowadzić stopniowo: najpierw zwiększyć wolumen dokumentów w sprawdzonym zakresie, następnie dołączać kolejne zespoły lub typy dokumentów. Przy każdym rozszerzeniu należy ponownie ocenić jakość, obciążenie osób weryfikujących i koszty. Przed uruchomieniem produkcyjnym potrzebne są także wskazany właściciel rozwiązania, zasady wprowadzania zmian, rozdzielone środowiska testowe i produkcyjne oraz możliwość powrotu do obsługi ręcznej. Dzięki temu organizacja rozwija automatyzację na podstawie potwierdzonych efektów, zamiast powielać ograniczenia pierwszego prototypu.

Kolorystyka w projektach Canva – jak dobierać kolory i budować profesjonalny wizerunek? 05 listopada 2026

Six Sigma w usługach – czy metodologia sprawdza się poza produkcją? 03 listopada 2026