Dokument można znaleźć w trzy sekundy i nadal nie wiedzieć, czy wolno go użyć. To jeden z najbardziej niedocenianych problemów systemów DMS. Wyszukiwarka odnajdzie procedurę, umowę, instrukcję albo wzór pisma. Nie odpowie jednak na znacznie ważniejsze pytania: czy dokument nadal obowiązuje, kto zatwierdził dostęp, kiedy należy go przejrzeć, jak długo trzeba go przechowywać i co zrobić ze starszą wersją.
Problem pojawia się zwykle nie wtedy, gdy system jest technicznie słaby, lecz wtedy, gdy dokumentacja nie ma przypisanej odpowiedzialności biznesowej. W efekcie DMS zaczyna działać jak bardzo szybkie archiwum niepewnych treści.
Trzeba przy tym rozdzielić kilka ról. Właściciel typu dokumentacji nie jest administratorem danych osobowych w rozumieniu RODO i nie powinien być utożsamiany z administratorem technicznym systemu. To rola organizacyjna: osoba albo funkcja odpowiadająca za zasady dotyczące określonej klasy dokumentów, na przykład umów zakupowych, procedur operacyjnych czy dokumentacji kadrowej.
Obok niej funkcjonują jeszcze:
- opiekun pojedynczej sprawy – odpowiada za konkretną umowę, postępowanie, projekt lub teczkę;
- wykonawca – tworzy, edytuje albo przetwarza dokument w ramach przydzielonego zadania;
- administrator techniczny DMS – konfiguruje system, uprawnienia techniczne, workflow, integracje i mechanizmy retencji zgodnie z zatwierdzonymi zasadami.
Pomieszanie tych czterech odpowiedzialności jest prostą drogą do sytuacji, w której administrator IT decyduje o biznesowym okresie przechowywania dokumentacji, a autor pliku staje się jego dożywotnim „właścicielem”, mimo że pół roku później pracuje już w innym dziale.
Właściciel powinien odpowiadać za typ dokumentacji, a nie za każdy plik z osobna
Najbardziej praktycznym poziomem governance nie jest pojedynczy dokument, lecz typ dokumentacji. To może być na przykład „umowa z dostawcą”, „instrukcja stanowiskowa”, „protokół odbioru”, „dokumentacja pracownicza”, „reklamacja klienta” albo „procedura bezpieczeństwa”.
Każdy taki typ powinien mieć właściciela biznesowego, ponieważ właśnie na tym poziomie można ustalić wspólne reguły:
- kiedy dokument staje się obowiązujący;
- kto może go zatwierdzić;
- kto powinien mieć do niego dostęp;
- jak długo dokument pozostaje aktywny;
- kiedy wymaga przeglądu;
- jaka zasada retencji ma zastosowanie;
- co dzieje się po wycofaniu;
- kto przejmuje odpowiedzialność przy zmianie stanowiska lub odejściu właściciela.
Właściciel nie musi wykonywać wszystkich tych czynności sam. Musi natomiast odpowiadać za to, aby istniała decyzja i aby dało się wskazać, kto ją podjął.
Dobrze pokazuje to przykład procedury reklamacyjnej w firmie handlowej. Specjalista compliance przygotowuje zmianę wynikającą z nowych zasad obsługi klienta. Kierownik operacyjny zatwierdza treść. Administrator DMS publikuje wersję 4.2 i przenosi 4.1 do statusu historycznego. Pracownicy salonów widzą tylko aktualną wersję.
Jeżeli nie ma właściciela typu „procedury reklamacyjne”, po roku pojawiają się trzy problemy naraz. Nikt nie wie, kto ma ocenić aktualność dokumentu, stara instrukcja nadal pojawia się w wynikach wyszukiwania, a przy zmianie procesu każdy zakłada, że dokument „należy do compliance”.
W takiej sytuacji dodawanie lepszego wyszukiwania semantycznego nie usuwa problemu. Wręcz go wzmacnia: system szybciej poda użytkownikowi dokument, któremu nie można ufać.
Praktyczna karta typu dokumentacji może mieć kilkanaście pól. Minimum to:
- nazwa typu dokumentacji;
- właściciel biznesowy;
- zastępca lub rola przejmująca odpowiedzialność;
- właściciel procesu powiązanego z dokumentacją;
- system lub repozytorium źródłowe;
- klasyfikacja poufności;
- zasady dostępu;
- sposób zatwierdzenia;
- częstotliwość przeglądu;
- zdarzenie rozpoczynające okres retencji;
- okres lub kryterium retencji;
- podstawa prawna albo biznesowa;
- sposób wycofania dokumentu;
- reguła postępowania z wersjami historycznymi.
Samo pole „Owner” w metadanych nie wystarcza. Jeżeli właściciel nie wie, czego właściwie ma pilnować, organizacja jedynie przeniosła bałagan z folderów do bazy danych.
Pomaga prosta RACI, nawet bez wdrażania rozbudowanej metodologii:
| Czynność | Właściciel typu | Opiekun sprawy | Wykonawca | Administrator DMS |
|---|---|---|---|---|
| Ustalenie standardu dokumentacji | A/R | C | C | C |
| Aktualizacja konkretnego dokumentu | A | R | R | I |
| Zatwierdzenie modelu dostępu | A | C | I | C/R technicznie |
| Ustalenie zasad retencji | A | C | I | C |
| Konfiguracja retencji w systemie | C | I | I | R |
| Wycofanie nieaktualnej wersji | A | R | C | R technicznie |
| Przejęcie otwartych spraw po odejściu pracownika | A | R | I | C |
A oznacza ostateczną odpowiedzialność, R wykonanie zadania, C konsultację, a I poinformowanie.
Nie należy jednak kopiować tej tabeli bezmyślnie do każdej organizacji. W małej spółce właściciel typu dokumentacji i właściciel procesu mogą być tą samą osobą. W dużej grupie kapitałowej jedna polityka może mieć właściciela centralnego, podczas gdy poszczególne dokumenty lokalne mają opiekunów w Polsce, Czechach czy Niemczech.
Granica jest prosta: jeżeli jedna osoba miałaby odpowiadać osobiście za tysiące plików, model jest zbyt szczegółowy. Jeżeli za całą dokumentację przedsiębiorstwa odpowiada „dział administracji”, model jest zbyt ogólny.
Aktualność, dostęp i retencja wymagają osobnych decyzji
Trzy problemy bywają wrzucane do jednego worka pod nazwą „zarządzanie dokumentami”: aktualność, uprawnienia i retencja. Tymczasem każdy z nich odpowiada na inne pytanie.
Aktualność mówi, czy dokument powinien być używany operacyjnie.
Dostęp określa, kto może dokument zobaczyć, zmieniać, zatwierdzać albo udostępniać.
Retencja odpowiada na pytanie, jak długo dokument lub zawarte w nim informacje muszą albo mogą pozostać przechowywane.
Jedna decyzja nie zastępuje drugiej.
Procedura operacyjna wycofana w marcu może przestać być dostępna jako instrukcja dla pracowników, ale jej historyczna wersja nadal może być potrzebna do wykazania, jakie zasady obowiązywały podczas zdarzenia z lutego. Wycofanie dokumentu nie powinno więc automatycznie oznaczać jego usunięcia.
Praktyczny model wymaga co najmniej trzech statusów:
- obowiązujący – wersja przeznaczona do bieżącego użycia;
- wygasły lub wycofany – dokument nie może być stosowany operacyjnie, lecz może nadal podlegać retencji;
- archiwalny – zachowany ze względu na obowiązek prawny, dowodowy, historyczny albo wewnętrzną politykę retencji.
To rozróżnienie jest ważniejsze od samego numeru wersji. Użytkownik szukający instrukcji powinien domyślnie zobaczyć wersję obowiązującą, a nie dokument 2.7 tylko dlatego, że zawiera więcej słów zgodnych z zapytaniem niż aktualna wersja 3.0.
Nowoczesne DMS-y potrafią przechowywać historię wersji, ograniczać jej dostęp i odtwarzać wcześniejsze wersje. Microsoft SharePoint i OneDrive przechowują historię wersji, umożliwiają ich porównywanie i przywracanie, a mechanizmy Microsoft Purview pozwalają nakładać reguły retencji oraz deklarować dokumenty jako rekordy. M-Files również przechowuje historię obiektów i pozwala odtworzyć wcześniejszą wersję. Technologia potrafi wykonać regułę. Nie potrafi jednak sama ustalić, jaka reguła jest prawidłowa dla konkretnego procesu biznesowego.
Najczęstszy błąd to utworzenie jednej tabeli: „wszystkie dokumenty przechowujemy pięć lat”. Takiej uniwersalnej reguły nie ma.
Dla dokumentacji pracowniczej polskie przepisy przewidują w zależności od sytuacji między innymi okresy 10- albo 50-letnie. Dla innych dokumentów okres może wynikać z odrębnych przepisów, terminów przedawnienia, wymagań sektorowych, postępowania sądowego, zobowiązań kontraktowych albo celu przetwarzania danych.
Jeżeli dokument zawiera dane osobowe, dochodzi zasada ograniczenia przechowywania wynikająca z RODO. Jeżeli szczegółowy przepis nie podaje konkretnego terminu, administrator powinien ustalić okres lub kryteria jego ustalania oraz okresowo oceniać dalszą potrzebę przechowywania.
Dlatego matryca retencji powinna być budowana według kategorii dokumentacji, a nie według aplikacji lub folderu.
Przykładowy rekord matrycy:
Typ: umowa zakupowa
Zdarzenie początkowe: rozwiązanie lub wygaśnięcie umowy
Okres: ustalany na podstawie mających zastosowanie przepisów, terminów roszczeń i wymagań podatkowych
Dodatkowe zatrzymanie: spór, kontrola, postępowanie albo legal hold
Decyzja po okresie: usunięcie albo dalsze przechowywanie na odrębnej podstawie
Właściciel reguły: właściciel procesu zakupowego po konsultacji z prawnikiem, podatkami, compliance i — gdy dokument zawiera dane osobowe — osobami odpowiedzialnymi za ochronę danych
Realizacja techniczna: administrator DMS
Właściciel biznesowy nie może sam uznać: „tego już nie potrzebujemy, usuńmy”. Tak samo administrator systemu nie powinien ustalać siedmioletniej retencji tylko dlatego, że taką wartość łatwo skonfigurować w panelu.
Szczególnie niebezpieczne jest automatyczne kasowanie poprzednich wersji. Jeżeli wersja jest potrzebna jako dowód stanu dokumentu obowiązującego w określonym momencie, mechanizm czyszczenia historii może usunąć dokładnie tę informację, której firma potrzebuje podczas audytu lub sporu.
Dlatego przed włączeniem automatycznego usuwania trzeba odpowiedzieć na trzy pytania:
- Czy wersje historyczne mogą być potrzebne dowodowo?
- Czy dokument podlega aktywnej retencji, blokadzie prawnej albo postępowaniu?
- Czy zakończenie okresu przechowywania rzeczywiście oznacza możliwość usunięcia, czy uruchamia dodatkowy proces oceny?
Dopiero potem konfigurujemy DMS.
Offboarding jest testem, czy governance istnieje naprawdę
Najlepszym testem systemu odpowiedzialności nie jest dzień wdrożenia DMS. Jest nim poniedziałek po odejściu osoby, która przez osiem lat prowadziła kluczowy obszar.
Jeżeli wraz z dezaktywacją konta pojawiają się pytania „kto teraz zatwierdza?”, „czyje są te umowy?” i „kto może zmienić procedurę?”, to właściciel dokumentacji istniał tylko jako nazwisko w polu metadanych.
Rola musi mieć następcę albo mechanizm zastępstwa.
Najbezpieczniejszy model polega na przypisywaniu odpowiedzialności przede wszystkim do funkcji organizacyjnej, a dopiero później do osoby. Zamiast budować regułę „Anna Kowalska jest właścicielem wszystkich procedur zakupowych”, lepiej ustalić, że właścicielem jest „Head of Procurement”, a Anna obecnie pełni tę funkcję.
To ułatwia zmianę stanowiska, urlop, reorganizację i odejście pracownika.
Nie zwalnia jednak z procesu przejęcia. Przy offboardingu trzeba rozdzielić co najmniej trzy rzeczy:
- własność typu dokumentacji;
- odpowiedzialność za otwarte sprawy;
- prawa dostępu i zadania oczekujące w workflow.
Przykład: kierownik zakupów odchodzi 30 listopada. W DMS znajduje się 2400 umów, ale tylko 17 postępowań jest aktywnych. Nie ma sensu ręcznie przepisywać właściciela każdego starego pliku, jeżeli odpowiedzialność za typ „umowy zakupowe” wynika z roli. Trzeba natomiast jednoznacznie przekazać 17 otwartych spraw, zadania akceptacyjne oraz wyjątki dotyczące dostępu.
Dobrze zaprojektowany offboarding powinien wymusić listę:
- aktywnych spraw przypisanych do odchodzącej osoby;
- dokumentów oczekujących na akceptację;
- wyjątków uprawnień nadanych bezpośrednio użytkownikowi;
- klas dokumentacji, dla których osoba jest właścicielem;
- workflow, w których występuje jako zatwierdzający;
- reguł lub automatyzacji odwołujących się bezpośrednio do jej konta.
Szczególnie irytującym błędem są workflow zbudowane na konkretnych nazwiskach. Proces działa dobrze przez dwa lata, a po zmianie dyrektora faktury albo procedury zaczynają trafiać do nieaktywnego użytkownika. Jeżeli system to umożliwia, akceptacje powinny korzystać z ról, grup lub metadanych procesu, nie ze stałych identyfikatorów pracowników.
Sam DMS nadal nie rozwiąże kwestii przejęcia odpowiedzialności. Administrator może zmienić konto w workflow, ale nie powinien sam decydować, kto od tej chwili ma prawo zatwierdzać wyjątki zakupowe albo zmieniać politykę bezpieczeństwa.
Dlatego przed offboardingiem właściciela trzeba wskazać:
następcę – osobę przejmującą rolę na stałe;
zastępcę – osobę działającą czasowo podczas nieobecności;
datę przejęcia – aby było wiadomo, od którego momentu odpowiada nowa osoba;
zakres spraw otwartych – przekazywany oddzielnie od ogólnej własności dokumentacji.
Jeżeli organizacja nie ma jeszcze takiego modelu, nie zaczynałbym od przebudowy całego DMS. Lepszy jest 30-dniowy pilotaż governance dla najważniejszych typów dokumentacji. To przykład organizacyjny, a nie termin wymagany prawem.
W pierwszym tygodniu warto zinwentaryzować około 10–20 kategorii, których błędne użycie może wywołać największe skutki: umowy, dokumentację kadrową, procedury bezpieczeństwa, instrukcje produkcyjne, dokumenty finansowe czy zatwierdzone wzory komunikacji z klientem.
W drugim tygodniu należy dla każdej kategorii ustalić właściciela, zastępcę, statusy, sposób zatwierdzania oraz podstawowe grupy dostępu.
W trzecim tygodniu powstaje matryca retencji. Każdy okres trzeba skonfrontować z właściwymi przepisami, potrzebą dowodową i realnym procesem. Nie kopiować terminów z innego działu tylko dlatego, że są już wpisane w Excelu.
W czwartym tygodniu można skonfigurować workflow, filtry wyszukiwania, widoki wersji obowiązujących i procedurę offboardingu.
Dopiero później warto automatyzować pozostałe kategorie.
FAQ
Czy każdy dokument w DMS musi mieć indywidualnego właściciela?
Nie. Przy dużej liczbie dokumentów taki model staje się niewykonalny. Najczęściej lepiej przypisać odpowiedzialność do typu dokumentacji, a dla konkretnych spraw wyznaczać opiekuna. Indywidualny właściciel pliku ma sens przy dokumentach wyjątkowych, projektowych lub wymagających osobnego procesu decyzyjnego.
Czy właściciel dokumentacji jest administratorem danych osobowych według RODO?
Nie z samego faktu bycia właścicielem dokumentacji. Administrator w rozumieniu RODO to podmiot, który ustala cele i sposoby przetwarzania danych osobowych. „Właściciel dokumentacji” jest wewnętrzną rolą governance. Może uczestniczyć w ustalaniu dostępu czy retencji, ale nie zmienia to prawnej odpowiedzialności administratora danych.
Czy starą wersję dokumentu należy usuwać po opublikowaniu nowej?
Nie automatycznie. Trzeba rozdzielić wersję obowiązującą, wycofaną i archiwalną. Stara wersja może być potrzebna do wykazania, jaka procedura, regulamin albo treść umowy obowiązywały w określonym dniu. Usuwanie można uruchomić dopiero po uwzględnieniu zasad retencji, wymagań dowodowych, blokad prawnych i innych obowiązków.
Od czego zacząć porządkowanie DMS, jeśli dokumentów są setki tysięcy?
Nie od czyszczenia wszystkich plików i nie od zakupu lepszej wyszukiwarki. Najpierw wybierz 10–20 najważniejszych typów dokumentacji i dla każdego utwórz kartę zawierającą właściciela, zastępcę, statusy, zasady dostępu, kryterium aktualności, regułę retencji oraz sposób wycofania wersji. Jeżeli dziś trzeba usunąć jeden błąd w pierwszej kolejności, powinny nim być kluczowe dokumenty bez jednoznacznego właściciela biznesowego. Bez tego automatyzacja jedynie przyspieszy wykonywanie nieuzgodnionych decyzji.
