Pracownik kończy pracę w piątek o 16:00, jego konto zostaje zablokowane, a w systemie nadal czekają trzy faktury, aneks do umowy i wniosek zakupowy. To nie jest problem wyłącznie z dostępem do dokumentów. W DMS trzeba rozdzielić co najmniej cztery rzeczy: zadania czekające na decyzję, uprawnienia do podjęcia tej decyzji, własność procesu oraz historię wcześniejszych działań użytkownika.
Najgorszy wariant to mechaniczne usunięcie konta i założenie, że system sam „przekaże sprawy dalej”. Nie każdy DMS tak działa. W jednej konfiguracji zadanie może trafić do zastępcy, w innej pozostanie przypisane do nieaktywnego użytkownika, a jeszcze w innej sam obieg będzie działał dalej, ale zatrzyma się na połączeniu lub integracji wykorzystującej konto osoby, która odeszła.
Dlatego offboarding w DMS powinien zacząć się przed wyłączeniem konta od inwentaryzacji procesów, a zakończyć kontrolą, czy po odebraniu dostępu żadna sprawa biznesowa nie została bez właściciela.
Najpierw sprawdź, co naprawdę jest przypisane do odchodzącego pracownika
Lista „dokumentów oczekujących na akceptację” to za mało. W praktyce trzeba sprawdzić wszystkie elementy, w których pracownik występuje jako użytkownik aktywny albo właściciel techniczny.
Minimum obejmuje:
-
aktywne zadania akceptacyjne;
-
dokumenty będące jeszcze przed jego etapem, ale mające trafić do niego później;
-
zapisane szkice i robocze wersje dokumentów;
-
zadania po terminie oraz uruchomione eskalacje;
-
reguły zastępstw;
-
procesy, przepływy i automaty należące do tego użytkownika;
-
połączenia z pocztą, ERP, SharePointem, systemem finansowym lub innymi usługami;
-
raporty, kolejki, foldery i obszary, do których dostęp został przyznany bezpośrednio użytkownikowi;
-
reguły oparte na adresie e-mail, identyfikatorze konta albo konkretnej osobie wpisanej na stałe w konfiguracji.
Przykład: kierownik zakupów kończy pracę 31 października. W dniu offboardingu ma tylko dwie aktywne akceptacje. Administrator przekazuje je jego następcy i uznaje sprawę za zamkniętą. Tydzień później do etapu „akceptacja kierownika zakupów” dochodzi zamówienie na 180 tys. zł. W definicji procesu nadal wpisany jest jednak adres poprzedniego kierownika. Dokument zatrzymuje się dopiero wtedy.
Dlatego inwentaryzacja musi obejmować nie tylko bieżące zadania, ale również przyszłe kroki procesu.
W małej organizacji można wykonać taki przegląd ręcznie dla konkretnego użytkownika. Przy kilkudziesięciu lub kilkuset obiegach lepszym rozwiązaniem jest raport pokazujący, gdzie konto występuje jako:
-
właściciel,
-
akceptujący,
-
zastępca,
-
odbiorca eskalacji,
-
właściciel połączenia lub integracji,
-
użytkownik zapisany bezpośrednio w regule procesu.
Szczególnie kłopotliwe są automatyzacje tworzone przez pracowników samodzielnie. W Power Automate twórca przepływu staje się jego właścicielem. Jeżeli taka osoba odejdzie, a przepływ korzysta z połączeń należących do jej konta, część akcji może po dezaktywacji tych połączeń przestać działać. Sam fakt, że przepływ nadal istnieje, nie gwarantuje więc ciągłości procesu.
Kiedy wystarczy zwykłe przekazanie zadań? Gdy użytkownik był wyłącznie uczestnikiem procesu, nie posiada własnych automatyzacji, połączeń ani indywidualnych reguł i wszystkie przyszłe zadania są wyznaczane na podstawie aktualnej roli lub grupy.
Kiedy trzeba wykonać pełny audyt konfiguracji? Gdy pracownik był właścicielem procesu, administratorem obiegu, osobą funkcyjną wpisaną bezpośrednio do reguł albo właścicielem integracji. W takim przypadku sprawdzenie samej skrzynki „Do akceptacji” daje fałszywe poczucie bezpieczeństwa.
Zadanie można przekazać, ale uprawnienia do decyzji trzeba sprawdzić osobno
Techniczne przypisanie dokumentu Janowi zamiast Annie nie oznacza jeszcze, że Jan może podjąć dokładnie taką samą decyzję.
To jeden z najczęstszych błędów podczas szybkiego offboardingu.
Załóżmy, że dyrektor finansowy miał prawo akceptować płatności do 500 tys. zł, a jego zastępca zgodnie z wewnętrzną matrycą akceptacji ma limit 100 tys. zł. Administrator może bez problemu przepisać zastępcy zadanie dotyczące faktury na 320 tys. zł. Z punktu widzenia systemu wszystko wygląda poprawnie. Z punktu widzenia organizacji decyzja zastępcy może jednak przekraczać jego umocowanie.
Dlatego przy zmianie osoby odpowiedzialnej trzeba osobno sprawdzić:
-
limit kwotowy;
-
kategorię kosztu lub rodzaj dokumentu;
-
jednostkę organizacyjną;
-
wymóg dwóch akceptacji;
-
pełnomocnictwa i zasady reprezentacji;
-
możliwość podpisania dokumentu;
-
reguły zastępstwa wynikające z procedur wewnętrznych.
Delegowanie zadania w DMS nie tworzy automatycznie pełnomocnictwa. System może pozwolić użytkownikowi kliknąć „Akceptuję”, ale sama możliwość techniczna nie przesądza, że decyzja jest zgodna z zasadami obowiązującymi w spółce.
Dobry proces offboardingu rozwiązuje ten problem przez dwa osobne mechanizmy. Pierwszy określa, kto otrzyma zadanie. Drugi określa, czy ta osoba może podjąć określony rodzaj decyzji.
Praktyczny przykład: odchodzi kierownik oddziału, który zatwierdzał faktury do 50 tys. zł. Na dwa tygodnie jego obowiązki przejmuje zastępca mający limit 20 tys. zł. Najbezpieczniejsza konfiguracja nie polega na bezwarunkowym przekazaniu wszystkich dokumentów. Faktury do 20 tys. zł mogą trafić do zastępcy, natomiast dokumenty powyżej tej wartości powinny być skierowane do dyrektora regionu lub na dodatkowy poziom akceptacji.
Takie rozwiązanie wymaga trochę więcej konfiguracji, ale usuwa poważny problem: system nie miesza zastępstwa organizacyjnego z prawem do podejmowania decyzji o dowolnej wartości.
Istotne jest również, kiedy następuje odebranie dostępu. Konto osoby, której zatrudnienie się kończy, powinno zostać wyłączone zgodnie z przyjętą procedurą bezpieczeństwa, a nie utrzymywane „jeszcze przez kilka dni, aż zaakceptuje ostatnie faktury”. Ciągłość procesu trzeba przygotować wcześniej przez zastępstwo, zmianę przypisania albo zmianę właściciela.
Nie należy też udostępniać następcy hasła byłego pracownika ani logować się na jego konto. Zastępca powinien wykonać własną decyzję pod własną tożsamością. Tylko wtedy ślad audytowy pokazuje rzeczywisty przebieg zdarzeń.
Zmiana właściciela procesu nie może zniszczyć historii wcześniejszych decyzji
Offboarding ma dwa pozornie sprzeczne cele. Z jednej strony trzeba szybko odebrać byłemu pracownikowi aktywny dostęp. Z drugiej — nie wolno „wymazać” faktu, że wcześniej zatwierdził konkretną fakturę, odrzucił umowę albo zmienił dane dokumentu.
Nieaktywne konto historyczne nie jest tym samym co aktywny dostęp.
DMS powinien zachować informację, że przykładowo 3 września 2026 r. Anna Kowalska zaakceptowała zamówienie nr Z/438/2026 o godz. 11:42. Po zakończeniu zatrudnienia jej konto może zostać zablokowane i pozbawione ról. Historia decyzji nadal powinna jednak wskazywać Annę Kowalską jako osobę, która rzeczywiście wykonała tę czynność.
Przepisywanie historycznej akceptacji na następcę byłoby poważnym błędem. Powstałby zapis sugerujący, że decyzję podjęła osoba, która w rzeczywistości tego nie zrobiła.
Podobnie należy traktować procesy techniczne. W Microsoft Power Automate aktualna dokumentacja przewiduje możliwość zmiany właściciela przepływu świadomego rozwiązania na innego użytkownika. W przypadku przepływów, które nie są powiązane z rozwiązaniem, mechanizm jest inny — zmiana właściciela „w miejscu” nie jest dostępna i może być potrzebne dodanie przepływu do rozwiązania albo utworzenie nowego przepływu przez eksport/import, „Save as” lub przekazanie kopii. Dostępne są także modele wykorzystujące konto serwisowe albo service principal. To pokazuje, dlaczego nie można przyjąć jednej uniwersalnej procedury dla każdego DMS i każdego typu automatyzacji.
Po zmianie właściciela trzeba dodatkowo sprawdzić połączenia używane przez proces. Zmiana nazwiska w polu „właściciel” nie zawsze zmienia uwierzytelnienie wszystkich usług, z którymi proces się komunikuje.
Przykład: pracownik stworzył automatyzację, która po zatwierdzeniu faktury zapisuje dokument w SharePoint i wysyła dane do systemu finansowego. Nowy właściciel zostaje poprawnie wskazany w konfiguracji, ale jedno z połączeń nadal korzysta z danych logowania byłego pracownika. Dopóki jego konto działa, problem jest niewidoczny. Po wyłączeniu konta część procesu zaczyna zwracać błędy.
Dlatego po przejęciu automatyzacji trzeba wykonać przynajmniej jeden kontrolowany test całej ścieżki, a nie tylko sprawdzić, czy obieg jest oznaczony jako aktywny.
W rozwiązaniach Microsoft trzeba uwzględnić również licencjonowanie. Po zmianie właściciela automatyczny lub zaplanowany przepływ może korzystać z licencji nowego właściciela. Jeżeli nowy właściciel nie ma odpowiedniego uprawnienia do funkcji premium, dokumentacja przewiduje okres przejściowy, po którym przepływ może zostać wyłączony. To kolejny powód, dla którego przekazanie własności powinno znaleźć się na liście kontrolnej przed odejściem pracownika, a nie dopiero po pierwszej awarii.
Podobnie jest z samymi akceptacjami. Power Automate pozwala odbiorcy w określonych scenariuszach przekazać otrzymaną akceptację innej osobie. Nadawca nie ma identycznej możliwości — może być konieczne anulowanie żądania i zmiana osoby wskazanej w przepływie. Funkcja ta zależy jednak od typu procesu i jego konfiguracji. Nie jest dowodem, że każdy DMS po usunięciu konta sam przepisze oczekujące zadania.
Osobnym tematem jest retencja. Zachowanie śladu audytowego nie oznacza przechowywania wszystkich danych bezterminowo. Dla poszczególnych kategorii dokumentów należy określić okres albo kryteria retencji wynikające z celu przetwarzania, wymogów prawnych, obowiązków dowodowych i polityki organizacji. Zasada ograniczenia przechowywania z art. 5 ust. 1 lit. e RODO nie daje podstawy do utrzymywania danych osobowych bez końca tylko dlatego, że „system je zapisuje”.
Najbezpieczniejszy model jest więc prosty: historia wcześniejszych decyzji pozostaje niezmieniona przez wymagany okres, konto użytkownika traci aktywne uprawnienia, a nowe decyzje wykonuje już zastępca pod własnym kontem i w granicach własnego umocowania.
FAQ
Czy po usunięciu pracownika z DMS jego zadania automatycznie przejdą na przełożonego?
Nie można tego zakładać. Zależy to od konkretnego DMS, sposobu konfiguracji procesu i reguł zastępstwa. W części systemów zadanie trzeba przekazać ręcznie, w innych może zadziałać zastępstwo lub eskalacja. Przed wyłączeniem użytkownika należy sprawdzić aktywne zadania oraz przyszłe kroki, w których został wpisany jako odbiorca.
Czy można zostawić konto pracownika aktywne kilka dni, żeby dokończył akceptacje?
Nie powinno się utrzymywać dostępu tylko po to, aby naprawić źle przygotowany offboarding. Proces należy wcześniej przekazać zastępcy albo innemu uprawnionemu użytkownikowi. Data odebrania dostępu powinna wynikać z zasad bezpieczeństwa i zakończenia zatrudnienia, a nie z liczby dokumentów pozostawionych w kolejce.
Czy zastępca może zatwierdzić wszystkie dokumenty poprzednika?
Nie. Trzeba zweryfikować limity kwotowe, zakres odpowiedzialności, pełnomocnictwa, zasady reprezentacji oraz matrycę akceptacji. Przypisanie zadania w systemie nie daje automatycznie prawa do zatwierdzenia każdej kwoty ani podpisania dokumentu.
Co zrobić z decyzjami podjętymi wcześniej przez byłego pracownika?
Pozostawić je w historii z oryginalną tożsamością, datą i innymi wymaganymi danymi audytowymi. Konto może być nieaktywne, ale nie należy przepisywać wcześniejszych decyzji na nowego pracownika.
Czy wystarczy zmienić właściciela workflow?
Nie. Trzeba sprawdzić również połączenia, integracje, konta serwisowe, licencje, odbiorców eskalacji, przyszłe kroki oraz reguły wykorzystujące identyfikator lub adres e-mail odchodzącej osoby.
Co z dokumentem, który już czeka na akceptację byłego pracownika?
Najpierw należy ustalić, kto ma prawo podjąć daną decyzję, a następnie wykorzystać dostępny w konkretnym DMS mechanizm przekazania, anulowania i ponownego skierowania albo administracyjnego przypisania zadania. Nie należy logować zastępcy na konto poprzednika.
Jak długo przechowywać historię użytkownika po jego odejściu?
Nie ma jednego okresu odpowiedniego dla wszystkich dokumentów i procesów. Retencję należy określić dla poszczególnych kategorii informacji na podstawie wymogów prawnych, celu przetwarzania i potrzeb dowodowych. Sam fakt, że DMS pozwala przechowywać historię bezterminowo, nie jest wystarczającym uzasadnieniem.
Pierwszym działaniem przy każdym offboardingu powinno być więc sporządzenie listy aktywnych i przyszłych zadań, procesów, właścicielstw oraz połączeń przypisanych do pracownika, zanim jego konto zostanie wyłączone. Dopiero na tej podstawie należy wyznaczyć następców i sprawdzić ich uprawnienia. Jeśli trzeba wybrać tylko jeden błąd do usunięcia w pierwszej kolejności, nie zaczynaj od kasowania użytkownika. Najpierw usuń z procesów zależność od osoby, która za chwilę straci dostęp.
