OneDrive lub SharePoint działał przez 5 lat. Po czym poznać, że firma potrzebuje już DMS?

Pięć lat bez większych problemów nie jest dowodem, że obecny obieg dokumentów nadal pasuje do firmy. Jest raczej dowodem, że przez pięć lat dało się z nim pracować.

Granica zwykle pojawia się po cichu. Najpierw faktura trafia do niewłaściwego folderu. Potem kierownik nie odpowiada na prośbę o akceptację przez trzy dni. Księgowość prowadzi dodatkowy Excel z dokumentami „w toku”, bo sam SharePoint nie pokazuje procesu w sposób wystarczająco czytelny. Po przejęciu drugiej spółki zaczynają się pytania, kto ma mieć dostęp do której biblioteki. Wreszcie przy audycie ktoś prosi o wykaz: kto zatwierdził umowę, kiedy, na podstawie której wersji i zgodnie z jaką ścieżką.

I wtedy pada zdanie: „Potrzebujemy DMS-u”.

Nie zawsze. OneDrive, SharePoint, Power Automate i Microsoft Purview mogą tworzyć bardzo rozbudowane środowisko zarządzania dokumentami, obejmujące metadane, wersjonowanie, akceptacje, retencję i audyt. Problemem nie jest więc sam brak funkcji. Problem pojawia się wtedy, gdy firma nie potrafi już utrzymać ich jako spójnego, przewidywalnego procesu albo koszt tego utrzymania zaczyna być większy niż koszt przejścia na wyspecjalizowany DMS.

Nie istnieje również rozsądna zasada typu „powyżej 100 użytkowników trzeba kupić DMS”. Firma zatrudniająca 300 osób może dobrze działać na poprawnie zaprojektowanym SharePoint, a organizacja z 40 pracownikami może potrzebować DMS, jeśli obsługuje wieloetapowe akceptacje, kilka spółek, tysiące dokumentów miesięcznie i skomplikowane reguły księgowe.

Liczą się procesy, odpowiedzialność i koszt wyjątków, a nie wiek systemu.

Pierwszy sygnał: dokumenty są dostępne, ale coraz trudniej ustalić, który jest właściwy i co należy z nim zrobić

Na początku OneDrive i SharePoint rozwiązują dwa bardzo konkretne problemy. OneDrive jest przede wszystkim miejscem na indywidualne pliki robocze użytkownika, natomiast biblioteki SharePoint nadają się do dokumentów współdzielonych przez zespół. To rozróżnienie jest ważniejsze, niż wygląda.

Jeżeli umowa dostawcy znajduje się na OneDrive pracownika działu zakupów i została tylko udostępniona czterem innym osobom, technicznie wszyscy mogą na niej pracować. Organizacyjnie nadal jest to jednak plik znajdujący się w indywidualnej przestrzeni użytkownika. Dokument należący do procesu firmowego powinien mieć wspólnego właściciela organizacyjnego, jasno określoną lokalizację i zasady dostępu niezależne od konkretnego pracownika.

W dojrzałym środowisku SharePoint można pójść znacznie dalej niż tworzenie folderów. Biblioteki pozwalają stosować kolumny i typy zawartości, czyli opisywać pliki metadanymi takimi jak:

• numer kontrahenta,

• numer zamówienia,

• spółka,

• centrum kosztów,

• rodzaj dokumentu,

• właściciel biznesowy,

• data obowiązywania,

• status.

To zasadnicza różnica między folderem „Faktury/2026/Październik” a repozytorium dokumentów, w którym można wyszukać wszystkie faktury danej spółki, kontrahenta i projektu niezależnie od ich fizycznego położenia.

Sam brak porządku w folderach nie oznacza więc jeszcze konieczności zakupu DMS. Często pierwszym rozsądnym krokiem jest uporządkowanie architektury SharePoint.

Załóżmy, że firma ma 80 pracowników i trzy działy wrzucające umowy do osobnych bibliotek. Każdy dział stosuje inne nazwy plików: „Umowa ABC final”, „ABC_2026_NOWA”, „Umowa ABC final2 podpisana”. Pracownicy szukają dokumentów po nazwach, a po kilku latach nie wiadomo, który plik jest wersją obowiązującą.

Kupno DMS-u w tym momencie nie jest jeszcze oczywistą decyzją. Najpierw należałoby sprawdzić, czy problem można usunąć poprzez:

1. Jeden model klasyfikacji dokumentów.
Zamiast wymagać prawidłowej nazwy pliku, można wymagać określonych metadanych.

2. Jasne zasady własności.
Dokument procesowy nie powinien „należeć do Kasi z zakupów”. Powinien należeć do konkretnego procesu, jednostki lub zespołu.

3. Rozdzielenie treści roboczych od oficjalnych.
OneDrive może nadal służyć do pracy indywidualnej, lecz finalne dokumenty powinny trafiać do właściwej biblioteki SharePoint.

4. Ograniczenie liczby miejsc przechowywania.
Jeśli ten sam typ dokumentu znajduje się w Teams, lokalnych folderach, skrzynkach e-mail, OneDrive i kilku witrynach SharePoint, użytkownik nie ma już jednego źródła prawdy.

Moment graniczny pojawia się wtedy, gdy mimo takiego uporządkowania firma nadal musi budować coraz bardziej złożoną warstwę procesową wokół dokumentów.

Dobrym miernikiem jest czas potrzebny na znalezienie właściwego dokumentu i ustalenie jego statusu. Nie ma uniwersalnego benchmarku, który mówi, że trzy minuty są dobre, a osiem złe. Firma powinna zmierzyć własny stan. Przez dwa tygodnie można rejestrować kilkadziesiąt rzeczywistych przypadków: znalezienie umowy, odtworzenie historii akceptacji, sprawdzenie właściciela faktury, ustalenie wersji obowiązującej.

Jeżeli największą część czasu pochłania samo wyszukiwanie, najpierw poprawia się repozytorium. Jeżeli plik da się znaleźć szybko, ale długo trwa ustalenie kto, dlaczego i kiedy powinien wykonać kolejny krok, problemem nie jest już magazyn dokumentów. Problemem jest proces.

Drugi sygnał: firma zaczyna zarządzać nie dokumentem, lecz coraz większą liczbą wyjątków, akceptacji i obowiązków kontrolnych

Częsty błąd polega na stwierdzeniu, że SharePoint „nie potrafi robić akceptacji”. Potrafi.

Power Automate może reagować na dodanie dokumentu do biblioteki, pobierać jego metadane, uruchamiać proces akceptacji, przekazywać zadanie wskazanym osobom, a następnie zmieniać status dokumentu w zależności od decyzji. Microsoft opisuje również mechanizm ustawiania statusu zatwierdzenia zawartości bezpośrednio z przepływu.

To wystarcza w wielu rzeczywistych procesach.

Przykład: każda umowa zakupowa do 50 tys. zł wymaga akceptacji kierownika działu, a powyżej tej wartości również dyrektora finansowego. Po zatwierdzeniu dokument otrzymuje określony status, a autor informację o decyzji. Taki obieg można przygotować w SharePoint i Power Automate bez kupowania oddzielnego DMS.

Problemy zaczynają się wtedy, gdy proces przestaje być jednym przepływem i zamienia się w sieć wyjątków.

Przykładowo:

• do 50 tys. zł potrzebna jest jedna akceptacja,

• powyżej 50 tys. zł potrzebne są dwie,

• w przypadku umowy IT dochodzi inspektor bezpieczeństwa,

• w przypadku danych osobowych dochodzi osoba odpowiedzialna za ochronę danych,

• dla konkretnej spółki obowiązuje inny próg,

• podczas urlopu akceptującego zadanie powinno przejść do zastępcy,

• po dwóch dniach ma nastąpić przypomnienie,

• po czterech eskalacja,

• przy zmianie wartości dokument powinien wrócić na wcześniejszy etap,

• odrzucenie wymaga podania przyczyny,

• ponowne przesłanie powinno zachować historię poprzedniej decyzji.

Każdą z tych reguł da się potraktować jako problem techniczny. Prawdziwe pytanie brzmi jednak: kto będzie utrzymywał całość za dwa lata?

Jeśli firma ma kilkanaście przepływów Power Automate zbudowanych przez jednego administratora, który zna wszystkie wyjątki, rozwiązanie działa do momentu zmiany procesu, licencji, konektora, struktury organizacyjnej albo odejścia tej osoby. Wtedy pojawia się dług technologiczny, którego nie widać w cenie samego Microsoft 365.

Przed decyzją o DMS trzeba więc policzyć nie tylko liczbę przepływów. Ważniejsze są:

• liczba wyjątków obsługiwanych ręcznie,

• odsetek spraw wracających do administratora,

• liczba procesów zależnych od jednej osoby technicznej,

• liczba opóźnień względem uzgodnionego SLA,

• liczba ręcznych operacji pomiędzy SharePoint, ERP, pocztą i arkuszami,

• czas potrzebny na zmianę reguły biznesowej,

• zdolność do odtworzenia pełnej historii decyzji.

Podobnie wygląda kwestia retencji i audytu. SharePoint i OneDrive nie są pozbawione takich mechanizmów. Microsoft Purview umożliwia stosowanie polityk i etykiet retencji. Można zatrzymywać zawartość przez określony czas, usuwać ją po określonym okresie, oznaczać dokumenty jako rekordy oraz stosować odmienne zasady wobec różnych kategorii zawartości.

Mechanizm ma jednak własne konsekwencje administracyjne. Zawartość objęta retencją może być przechowywana w ukrytej bibliotece Preservation Hold, co wpływa między innymi na wykorzystanie przestrzeni. Trzeba również zdecydować, kiedy stosować regułę dla całej lokalizacji, a kiedy etykietę konkretnego dokumentu.

Audyt również istnieje. Microsoft Purview rejestruje liczne operacje dotyczące SharePoint i OneDrive. Nie oznacza to jednak, że każda firma ma automatycznie identyczny okres przechowywania logów. Standardowa retencja audytu wynosi obecnie 180 dni, natomiast dla odpowiednio licencjonowanych użytkowników rozwiązania Audit Premium określone rekordy SharePoint, OneDrive, Exchange i Microsoft Entra mogą być domyślnie przechowywane przez rok. Dłuższe okresy wymagają właściwej konfiguracji i odpowiednich licencji.

Dlatego pytanie podczas audytu nie powinno brzmieć: „Czy Microsoft ma logi?”. Powinno brzmieć: „Czy mamy te konkretne logi, których potrzebujemy, przez okres zgodny z naszym wymaganiem i dla użytkowników objętych właściwą licencją?”

To samo dotyczy kilku spółek.

Jeżeli trzy spółki należące do jednej grupy korzystają ze wspólnego Microsoft 365, można stworzyć osobne witryny, biblioteki, grupy uprawnień i reguły retencji. Nie ma technicznego prawa, które nakazuje przejście na DMS tylko dlatego, że pojawiła się druga spółka.

Ryzyko rośnie natomiast wtedy, gdy użytkownik musi pamiętać, że dokument spółki A należy umieścić w bibliotece X, dokument spółki B w witrynie Y, a wyjątek dotyczący projektu wspólnego w jeszcze innej lokalizacji. Jeśli prawidłowe rozdzielenie dokumentów zależy przede wszystkim od pamięci użytkownika, kontrola jest słaba niezależnie od użytej technologii.

Dedykowany DMS zaczyna mieć przewagę, gdy reguły przypisania, widoczności, obiegu i odpowiedzialności są tak rozbudowane, że firma potrzebuje jednej warstwy procesowej zaprojektowanej właśnie do ich egzekwowania.

Trzeci sygnał: SharePoint stał się częścią krytycznego procesu finansowego, ale integracje i automatyzacje nie mają jednego właściciela

Najbardziej zdradliwa sytuacja występuje wtedy, gdy dokumenty są uporządkowane, użytkownicy radzą sobie z SharePointem, a firma mimo to dochodzi do granicy obecnego rozwiązania.

Powodem jest integracja z ERP, księgowością i KSeF.

Od 1 lutego 2026 r. odbieranie faktur przez KSeF jest obowiązkowe dla podmiotów objętych systemem, natomiast obowiązek wystawiania został wprowadzony etapami: od 1 lutego dla największych podatników, od 1 kwietnia dla kolejnej grupy, przy czym najmniejsi podatnicy spełniający limit 10 tys. zł sprzedaży udokumentowanej fakturami miesięcznie korzystają z okresu przejściowego do końca 2026 r.

KSeF nie rozwiązuje jednak całego procesu dokumentowego przedsiębiorstwa.

System odpowiada za fakturę ustrukturyzowaną i jej wymianę w określonym modelu. Nie zastępuje automatycznie:

• zamówienia zakupu,

• umowy,

• protokołu odbioru,

• korespondencji z dostawcą,

• decyzji o przypisaniu kosztu,

• akceptacji merytorycznej,

• opisu księgowego,

• dokumentów potwierdzających wykonanie usługi,

• wewnętrznej ścieżki odpowiedzialności.

Co więcej, nie każdy dokument biznesowy jest dokumentem przesyłanym do KSeF. Ministerstwo Finansów wprost wskazuje kategorie, których do systemu się nie przesyła, między innymi proformy, dowody wewnętrzne czy noty obciążeniowe.

Dlatego firma może mieć perfekcyjnie działające połączenie z KSeF, a nadal źle zarządzać dokumentacją konkretnej transakcji.

Wyobraźmy sobie grupę składającą się z trzech spółek. Faktura wpływa przez KSeF, ERP zna kontrahenta i kwotę, SharePoint przechowuje umowę, a dział operacyjny potwierdza wykonanie usługi. Do zaksięgowania potrzebne są jeszcze centrum kosztów, numer projektu i akceptacja osoby odpowiedzialnej.

Można zbudować proces, w którym integracja pobiera fakturę, zakłada rekord w SharePoint, przypisuje metadane, uruchamia Power Automate, zbiera zatwierdzenia i po zakończeniu przekazuje informację do ERP.

Technicznie jest to realne.

Należy jednak zadać pięć niewygodnych pytań:

Kto odpowiada za transakcję, która zatrzyma się pomiędzy systemami?
Jeżeli odpowiedź brzmi „informatyk sprawdzi przepływ”, nie jest to jeszcze kontrolowany proces operacyjny.

Skąd wiadomo, że pobrano wszystkie dokumenty?
Integracja potrzebuje mechanizmu kontroli kompletności, a nie tylko instrukcji „pobierz nowe faktury”.

Co dzieje się przy duplikacie, korekcie albo ponownym uruchomieniu zadania?
Automatyzacja bez obsługi takich przypadków potrafi wykonać błędną operację szybciej niż pracownik.

Jak monitorowane są błędy API i kolejki?
Ministerstwo Finansów udostępnia produkcyjne API KSeF 2.0 wraz z dokumentacją integracyjną. Samo istnienie API nie gwarantuje jednak poprawności systemu po stronie przedsiębiorstwa. Potrzebne są logi, ponowienia, alerty oraz procedura obsługi nieudanego wywołania.

Który system jest źródłem prawdy dla poszczególnych danych?
Numer KSeF może pochodzić z KSeF, plan kont z ERP, status akceptacji z systemu obiegu, a dokument powiązany z repozytorium. Bez jednoznacznego podziału odpowiedzialności integracja szybko zaczyna kopiować te same dane w kilku miejscach.

To właśnie w takim punkcie warto porównać dwa warianty.

Pierwszy to dalsza rozbudowa Microsoft 365: uporządkowany SharePoint, Power Automate, Purview oraz integracje z ERP i KSeF. Ma sens, gdy firma ma kompetentnego właściciela środowiska, stosunkowo stabilne procesy i niewielką liczbę wyjątków. Plusem jest pozostanie w znanym ekosystemie i możliwość wykorzystania już posiadanych narzędzi. Minusem jest konieczność samodzielnego zaprojektowania i utrzymywania całej warstwy procesowej.

Drugi wariant to dedykowany DMS. Ma sens przede wszystkim wtedy, gdy obsługa dokumentów sama stała się dużym systemem biznesowym: wiele typów dokumentów, liczne ścieżki akceptacji, kilka spółek, rozbudowane uprawnienia, wymagania audytowe oraz intensywna integracja z ERP.

DMS nie jest jednak magicznym lekarstwem.

Jeżeli firma nie potrafi odpowiedzieć, kto jest właścicielem faktury, jakie są progi akceptacji i kiedy dokument uznaje się za kompletny, nowe oprogramowanie tylko przeniesie ten chaos do droższego interfejsu.

Dochodzi jeszcze koszt migracji. Trzeba ustalić, co zrobić ze starymi bibliotekami SharePoint, wersjami plików, metadanymi, linkami, retencją i historią. Migracja wszystkiego „jeden do jednego” bywa złym pomysłem. Część archiwalnych materiałów może pozostać w istniejącym środowisku w trybie tylko do odczytu, podczas gdy DMS przejmie nowe procesy. Innym razem przepisy lub potrzeby operacyjne będą wymagały przeniesienia szerszego zakresu danych.

Dlatego porównując SharePoint z DMS-em, nie należy zestawiać wyłącznie cen licencji. Trzeba policzyć pełny model:

• licencje Microsoft 365, Power Automate i Purview potrzebne do docelowej konfiguracji,

• licencje oraz wdrożenie DMS,

• koszt integracji z ERP i KSeF,

• czas administratorów,

• utrzymanie przepływów i konektorów,

• monitoring błędów,

• testowanie zmian,

• szkolenia,

• migrację,

• obsługę wyjątków,

• koszt przestoju krytycznego procesu.

Jeżeli SharePoint wymaga coraz większej liczby własnych mechanizmów tylko po to, aby zachowywał się jak system DMS, dedykowane narzędzie zaczyna być racjonalną alternatywą. Jeżeli natomiast problemem pozostają chaotyczne biblioteki, brak metadanych i nieustalone odpowiedzialności, zakup DMS jest przedwczesny.

FAQ

Czy po pięciu latach używania SharePoint firma powinna planować migrację do DMS?
Nie. Wiek środowiska nie jest kryterium. Istotne są czas wyszukiwania dokumentów, liczba błędów i wyjątków, opóźnienia akceptacji, wymagania retencyjne i audytowe oraz koszt utrzymania automatyzacji.

Czy SharePoint może być DMS-em?
Może pełnić wiele funkcji typowych dla DMS. SharePoint zapewnia biblioteki dokumentów, wersjonowanie, metadane i typy zawartości, Power Automate może obsługiwać przepływy i akceptacje, a Microsoft Purview retencję oraz audyt. Pytanie dotyczy nie samej dostępności funkcji, ale kosztu zaprojektowania i utrzymania kompletnego systemu.

Czy OneDrive nadaje się na firmowe archiwum dokumentów?
Nie powinien być podstawowym repozytorium wspólnych dokumentów procesowych. Microsoft rozróżnia indywidualne pliki robocze przechowywane w OneDrive od współdzielonych plików przechowywanych w SharePoint. Udostępnienie pliku z OneDrive nie zmienia faktu, że pozostaje on w indywidualnej bibliotece użytkownika.

Czy KSeF oznacza, że firma nie potrzebuje już systemu obiegu faktur?
Nie. KSeF obsługuje faktury ustrukturyzowane i ich wymianę, ale nie zastępuje całego procesu biznesowego wokół faktury: powiązania z umową lub zamówieniem, akceptacji merytorycznej, dekretacji, podziału kosztów, potwierdzenia wykonania czy obsługi dokumentów, które w ogóle nie trafiają do KSeF.

Czy duża liczba użytkowników jest wystarczającym argumentem za DMS?
Nie. Sto, pięćset czy tysiąc użytkowników nie stanowi automatycznie granicy. Znacznie ważniejsze jest to, ile osób i systemów uczestniczy w jednym procesie oraz ile reguł trzeba egzekwować.

Co powinno się policzyć przed wyborem DMS?
Minimum to czas wyszukania dokumentu, liczbę dokumentów bez właściciela lub wymaganych danych, czas realizacji akceptacji wobec SLA, liczbę ręcznych interwencji między systemami, liczbę wyjątków procesowych oraz czas administratorów poświęcany na utrzymanie automatyzacji.

Czy DMS automatycznie uporządkuje istniejący bałagan?
Nie. Jeżeli przed wdrożeniem nie zostaną określone typy dokumentów, właściciele, wymagane metadane, reguły dostępu, okresy retencji i ścieżki akceptacji, nowy system odwzoruje dotychczasowe problemy.

Pierwszym krokiem nie powinno więc być zaproszenie dostawców DMS na prezentację. Najpierw przez dwa–cztery tygodnie trzeba zmierzyć własny proces.

Wybierz trzy najbardziej obciążone obiegi, na przykład faktury kosztowe, umowy zakupowe i dokumentację projektową. Dla każdego zanotuj czas od wpływu do zakończenia, czas oczekiwania na akceptację, liczbę ręcznych interwencji, przypadki braku dokumentu lub metadanych, liczbę wyjątków oraz osoby odpowiedzialne za naprawianie błędów.

Następnie rozdziel problemy na dwie grupy. Bałagan w strukturze, brak metadanych i nieprawidłowe używanie OneDrive naprawia się najpierw w Microsoft 365. Jeżeli natomiast głównym kosztem są utrzymanie rozbudowanych przepływów, wieloetapowe reguły, kilka spółek, kontrole audytowe i integracje wymagające ciągłego nadzoru, wtedy należy policzyć wariant rozbudowy Microsoft 365 obok wariantu dedykowanego DMS.

Najdroższym błędem jest kupić DMS po to, żeby naprawić problem, który w rzeczywistości jest brakiem zasad.