Obieg dokumentów w firmie: procedura akceptacji zamówienia

Co powinno być wiadomo o każdym dokumencie?

Obieg dokumentów w firmie to ustalona droga dokumentu od wpływu do zakończenia sprawy. Przy zamówieniu trzeba wiedzieć, kto je prowadzi, gdzie znajduje się aktualna wersja, kto ma podjąć decyzję i co wydarzy się po tej decyzji. Samo przesłanie pliku dalej nie wyjaśnia żadnej z tych odpowiedzialności.

Załóżmy, że pracownik przygotował zamówienie, kierownik odpisał „akceptuję”, a następnego dnia zmieniła się kwota. W rejestrze musi być widoczne, czy zgoda dotyczyła wersji sprzed zmiany. Jeśli zespół ma szukać odpowiedzi w kilku skrzynkach, procedura pozostawia mu zbyt dużo do odgadnięcia.

Dla każdego dokumentu zapiszcie numer, wersję, właściciela sprawy, aktualny status i link do pliku. Do decyzji dodajcie osobę zatwierdzającą, datę, komentarz oraz numer zatwierdzonej wersji. Właściciel prowadzi sprawę do końca; zatwierdzający ocenia ją w granicach swoich uprawnień. Te role mogą należeć do różnych osób.

W tym poradniku zajmujemy się akceptacją jednego zamówienia. Jeśli dopiero ustalacie, jakie czynności wykonują poszczególne działy, zacznijcie od powiązanego poradnika o mapowaniu procesów. Tutaj przechodzimy od opisanej drogi dokumentu do reguł, które można sprawdzić na konkretnych danych.

Wzór procedury: kto zatwierdza zamówienie i którą wersję?

Przygotowaliśmy wypełniony przykład zamówienia DEMO-ZAM-01. Koordynator rejestruje wersję 1 o kwocie 4000,00 zł i przekazuje ją kierownikowi. Kierownik akceptuje dokładnie tę wersję, a decyzja trafia do rejestru. Stan końcowy tego przypadku brzmi „zatwierdzone”. Zamówienie pozostaje niewysłane.

Cały przykład jest fikcyjny. Próg 5000,00 zł to wymyślona polityka akceptacji, a nie wymóg prawny, stawka AIA ani zalecany limit dla każdej firmy. Model porównuje kwoty w jednym polu i nie wylicza podatków. Przed użyciem takiej procedury określcie wprost, czy Wasz próg oraz kwota zamówienia dotyczą wartości netto, czy brutto. Obie wartości muszą mieć tę samą podstawę i walutę.

Przy kwocie do 5000,00 zł włącznie wystarcza zgoda kierownika. Po przekroczeniu progu jego zgoda jest etapem pośrednim: dokument czeka na dyrektora. Zastępcę wyznaczcie wcześniej, wraz z zakresem jego uprawnień. Przekroczenie terminu uruchamia przekazanie sprawy do zastępcy; samo w sobie nie zatwierdza wydatku.

• Dokument i plik: DEMO-ZAM-01, wersja 1. W rejestrze znajduje się link do tej wersji; nowy plik otrzymuje kolejny numer wersji.
• Kwota do akceptacji: 4000,00 zł. Reguła przykładu: do 5000,00 zł włącznie decyduje kierownik, powyżej potrzebna jest dalsza decyzja dyrektora.
• Właściciel sprawy: koordynator. Odpowiada za kompletność wpisu, przekazanie do decyzji i obsługę wyjątków.
• Decyzja w tym przypadku: kierownik, „akceptuję”, zatwierdzona wersja 1. W rzeczywistym rejestrze trzeba również utrwalić czas decyzji i komentarz; symulacja sprawdza zgodność numerów wersji.
• Termin i zastępstwo: w procedurze firmy wskażcie termin odpowiedzi oraz imiennie uprawnionego zastępcę. W przykładzie sprawdzamy tylko warunek „termin minął”, bez narzucania długości terminu.
• Zakończenie akceptacji: zapis „zatwierdzone” dla wersji 1. Ewentualna wysyłka do dostawcy jest kolejną czynnością, z własnym wykonawcą i potwierdzeniem.

8 sytuacji, na których sprawdziliśmy reguły

Dla autorskiej procedury zapisaliśmy oczekiwane wyniki i wykonaliśmy lokalną symulację na 8 zestawach fikcyjnych danych. Wszystkie 8 wyników zgodziło się z oczekiwaniami. To sprawdzenie reguł przykładu, nie test Power Automate, SharePoint ani wdrożenia u klienta.

Każdy przypadek zmienia wybrany warunek względem zamówienia DEMO-ZAM-01. Taka forma pozwala ustalić, dlaczego dokument ma dany status. Przed uruchomieniem własnego obiegu przygotujcie analogiczne próby z osobami, które będą prowadzić i zatwierdzać sprawy.

• 1. Zwykła akceptacja. Kwota 4000,00 zł, właściciel wskazany, aktualna wersja 1. Kierownik akceptuje wersję 1. Wynik: „zatwierdzone”.
• 2. Dokładnie na progu. Kwota 5000,00 zł, pozostałe dane jak wyżej. Kierownik akceptuje wersję 1. Wynik: „zatwierdzone”, ponieważ próg obejmuje także wartość równą limitowi.
• 3. O grosz powyżej progu. Kwota 5000,01 zł. Kierownik akceptuje wersję 1. Wynik: „oczekuje na dyrektora”. Zgoda kierownika nie kończy tej ścieżki.
• 4. Brak właściciela. Kwota 4000,00 zł i zgoda kierownika są zapisane, ale nie ma osoby prowadzącej sprawę. Wynik: „wstrzymane: wskaż właściciela”. Najpierw trzeba przypisać odpowiedzialność.
• 5. Odmowa. Kierownik odrzuca wersję 1 zamówienia na 4000,00 zł. Wynik: „do poprawy”. Koordynator wraca do autora dokumentu z powodem odmowy i ustala dalsze działanie.
• 6. Zmieniony dokument. Aktualna jest wersja 2, a zgoda dotyczy wersji 1. Wynik: „ponowna akceptacja”. Zapisana wcześniej zgoda pozostaje w historii i nie zatwierdza zmienionej treści.
• 7. Brak odpowiedzi po terminie. Nie ma decyzji, a termin minął. Wynik: „eskalacja do zastępcy”, czyli przekazanie sprawy do wcześniej uprawnionej osoby. Brak odpowiedzi nie staje się zgodą.
• 8. Powtórne wpłynięcie. Dokument oznaczono jako potwierdzone powtórzenie tego samego zamówienia. Wynik: „bez nowego rekordu”. W rzeczywistym obiegu trzeba najpierw porównać dokument, wersję i dane; sam podobny tytuł nie wystarcza do uznania duplikatu.

Czego te próby jeszcze nie potwierdzają?

Osiem prób obejmuje wskazane warunki pojedynczo. Nie sprawdziliśmy połączenia kilku wyjątków naraz, np. zmienionej wersji bez właściciela, ani równoczesnych decyzji dwóch osób. Przypadek powyżej progu kończy się oczekiwaniem na dyrektora; nie zawiera próby jego końcowej zgody lub odmowy.

Symulacja przyjmuje także, że rozpoznanie duplikatu jest już poprawne. Nie sprawdza odczytu załącznika, logowania użytkowników, doręczenia powiadomień ani awarii systemu. Te sytuacje potrzebują własnych prób podczas wdrożenia. W procedurze ustalcie też, co się dzieje, gdy nie ma zastępcy lub jego uprawnienia nie obejmują danej kwoty.

Zatwierdzenie zamówienia, wysłanie go i potwierdzenie odbioru to kolejne zdarzenia. Każde powinno mieć własny zapis. Zgoda na dokument nie potwierdza dostawy, płatności ani poprawności księgowej. Przykład opisuje organizację decyzji i nie zastępuje ustalenia obowiązków prawnych lub księgowych dotyczących konkretnego dokumentu.

Jak przenieść procedurę do elektronicznego obiegu?

Elektroniczny obieg dokumentów w firmie powinien odwzorować ustalone role, wersje i decyzje. Zanim wybierzecie narzędzie, określcie miejsce rejestru, dostęp do plików, warunki przekazania sprawy i sposób potwierdzenia wyniku. Zacznijcie od jednego rodzaju dokumentu oraz małej próby z jego przyszłymi użytkownikami.

Power Automate jest jednym z narzędzi do kierowania wniosków do ludzi i oczekiwania na ich decyzję. Dokumentacja Microsoft rozróżnia m.in. zgodę wszystkich wskazanych osób, pierwszą odpowiedź oraz akceptację kolejno przez wyznaczone osoby. Wybór wariantu musi wynikać z Waszej procedury. Opcja „pierwsza odpowiedź” nie realizuje wymogu, aby zgodę wyraziły wszystkie osoby.

W przykładzie akceptacji sekwencyjnej Microsoft pokazuje osobny etap wstępny, decyzję końcową oraz zapis decyzji i komentarzy w rejestrze. SharePoint występuje tam jako przykład miejsca zapisu, a nie warunek każdego obiegu. Opisy funkcji opieramy na dokumentacji producenta; nie sprawdzaliśmy ich na koncie Waszej firmy.

• Rejestr: jedno wskazane miejsce z numerem dokumentu, wersją, właścicielem, statusem, terminem i historią decyzji. Powiadomienie powinno prowadzić do właściwej sprawy oraz wersji.
• Uprawnienia: osobno ustalcie, kto może czytać, zmieniać i zatwierdzać dokument. Sprawdźcie dostęp także na zwykłym koncie pracownika, nie wyłącznie na koncie administratora.
• Powiadomienia: ustalcie odbiorcę, kanał i zachowanie przy błędzie. Zapis uruchomienia wysyłki nie dowodzi, że właściwa osoba otrzymała lub przeczytała wiadomość.
• Wyjątki: przypiszcie osobę do braków, odmowy, zmiany wersji, spóźnionej odpowiedzi i powtórnego wpływu. Przy ponowieniu po awarii sprawdźcie, czy nie powstał drugi wniosek.
• Odbiór: dla każdej próby porównajcie oczekiwany status z rejestrem, wersją pliku i historią decyzji. Osobno sprawdźcie skutki poza rejestrem, jeśli zakres obejmuje np. wysyłkę zamówienia.

Jak pilnować wersji i dostępu do dokumentów?

Zgoda powinna wskazywać wersję, którą zatwierdzający rzeczywiście zobaczył. Po zmianie treści zachowajcie starą decyzję w historii, a aktualny plik skierujcie do ponownej akceptacji zgodnie z procedurą. Użytkownik otwierający sprawę musi łatwo odróżnić bieżący dokument od wcześniej zatwierdzonego.

W SharePoint wymaganie zatwierdzenia, historia wersji i widoczność szkiców są oddzielnymi ustawieniami. Dokument oczekujący na akceptację nie jest zatwierdzony, a jego widoczność zależy od konfiguracji dostępu. Sam napis „oczekuje” nie gwarantuje poufności. Microsoft zwraca też uwagę, że włączenie akceptacji dla istniejącej listy lub biblioteki nadaje jej dotychczasowym elementom status zatwierdzonych. Przed taką zmianą sprawdźcie więc także stare dokumenty.

Obowiązującą procedurę, role i zasady zastępstw przechowujcie w miejscu dostępnym dla zespołu. W powiązanym poradniku o firmowej bazie wiedzy opisujemy, jak uporządkować takie materiały. Instrukcja powinna wskazywać właściciela i aktualną wersję, podobnie jak dokumenty, których dotyczy.

Od czego zacząć we własnej firmie?

Wybierzcie jedno zamówienie i przejdźcie jego drogę z osobą przygotowującą dokument, koordynatorem oraz zatwierdzającym. Zapiszcie, gdzie sprawa czekała i jak zespół ustalił aktualną wersję. Następnie wypełnijcie własne role, limit, podstawę kwoty, termin oraz zastępstwo i przejdźcie przez opisane przypadki.

Automatyzacja może wspomóc rejestrację, przekazanie wniosku i przypomnienie. Odczyt AI może pomagać przepisać pola z dokumentu, ale wynik wymaga kontroli, a uprawnienie do podjęcia decyzji pozostaje przy wyznaczonej osobie. Zakres pierwszej próby powinien pokazywać, kto odpowiada za pomyłkę lub zatrzymaną sprawę.

Jeżeli chcecie omówić automatyzację obsługi biura, opiszcie nam obecny obieg jednego dokumentu i miejsce, w którym sprawa czeka. To wystarczy, aby zacząć rozmowę o konkretnym przekazaniu pracy oraz warunkach pierwszej próby.

Źródła

• Microsoft: rodzaje akceptacji i oczekiwanie na decyzję w Power Automate
• Microsoft: przykład akceptacji sekwencyjnej i zapisu decyzji
• Microsoft: zatwierdzanie elementów, wersje i widoczność w SharePoint