Elektroniczny obieg dokumentów i DMS dla firm

DMS, czyli Document Management System, to system porządkujący dokumenty, dostęp, wersje i przebieg ich obsługi. Nie każda firma potrzebuje jednak pełnego DMS. Czasem wystarczy uporządkowane repozytorium, połączenie używanych programów albo mniejszy moduł dla jednego obiegu.

Kiedy poczta, foldery i arkusze przestają wystarczać?

Problem zwykle nie polega na samym braku miejsca na pliki. Pojawia się wtedy, gdy dokument uruchamia kolejne działania, a firma nie ma jednego, czytelnego przebiegu.

Warto sprawdzić obieg dokumentów, gdy:

• te same pliki są przesyłane w kilku wiadomościach i trudno wskazać aktualną wersję;
• pracownicy pytają, kto ma teraz dokument i co powinno wydarzyć się dalej;
• akceptacje są zapisane w poczcie, komunikatorze albo poza systemem;
• dane z faktury, umowy, wniosku lub formularza są ręcznie przepisywane do innego programu;
• brak załącznika albo niepoprawne dane wychodzą na jaw dopiero pod koniec procesu;
• różne osoby mają dostęp do większej liczby dokumentów, niż potrzebują do swojej pracy;
• trudno odtworzyć, kto podjął decyzję, kiedy to zrobił i na podstawie której wersji;
• status w jednym programie nie zgadza się z informacją przekazywaną przez pracowników.

Nie każdy z tych sygnałów oznacza konieczność budowy nowego systemu. Najpierw trzeba ustalić, czy problem dotyczy przechowywania plików, odpowiedzialności, decyzji, wymiany danych czy kilku tych obszarów jednocześnie.

Jeden dokument od wpływu do zakończenia sprawy

Dobry obieg opisuje pełną drogę dokumentu. Dla jednego typu dokumentu sprawdzamy:

1. Źródło. Dokument może przyjść pocztą, przez formularz, portal klienta, skaner, API albo zostać utworzony przez pracownika.
2. Rejestrację i opis. Ustalamy identyfikator, typ dokumentu, ważne dane i sposób wykrywania braków.
3. Sprawdzenie kompletności. System może kontrolować wymagane pola i załączniki, ale decyzje wymagające oceny pozostają po stronie właściwej osoby.
4. Przydzielenie odpowiedzialności. Dokument trafia do roli lub osoby, która ma wykonać następny krok.
5. Decyzję. Użytkownik może zaakceptować, odrzucić, poprosić o poprawę albo przekazać sprawę dalej, zgodnie z ustalonym zakresem.
6. Przekazanie wyniku. Dane lub decyzja mogą trafić do CRM-u, ERP, programu księgowego, portalu B2B albo innego uzgodnionego systemu.
7. Status i historię. Uprawniona osoba widzi aktualny etap, wykonaną czynność i informację potrzebną do dalszej pracy.

System może pilnować kolejności, wymaganych danych, terminów i przekazywania informacji. Nie powinien sam podejmować decyzji biznesowej, jeżeli firma nie określiła jasnej reguły i odpowiedzialności.

Repozytorium, gotowy DMS, integracja czy własny moduł?

Rozwiązanie powinno odpowiadać na rzeczywisty problem. Najdroższy albo najbardziej rozbudowany wariant nie zawsze jest najlepszy.

Możemy pomóc porównać te kierunki, ale nie wybieramy technologii na podstawie samej nazwy „DMS”. Najpierw opisujemy jeden obieg i sprawdzamy, jakie elementy są naprawdę potrzebne.

Co ustalamy przed rozpoczęciem prac?

Typy i źródła dokumentów

Sprawdzamy, jakie dokumenty uczestniczą w procesie, skąd przychodzą, w jakich formatach występują i czy mają wspólny identyfikator. Przykłady mogą obejmować faktury, umowy, wnioski, protokoły i formularze, ale każdy z nich może wymagać innej drogi.

Role i uprawnienia

Ustalamy, kto może zobaczyć dokument, kto może go zmienić, kto podejmuje decyzję i kto ma dostęp tylko do wyniku. Uprawnienia powinny wynikać z roli oraz etapu procesu, a nie tylko z ukrycia przycisku na ekranie.

Statusy, decyzje i wyjątki

Opisujemy prawidłową drogę oraz sytuacje, w których brakuje danych, dokument wraca do poprawy, wymaga dodatkowej zgody albo nie może zostać przekazany dalej. Jasne wyjątki są równie ważne jak podstawowy scenariusz.

Wersje i historia

Trzeba określić, co oznacza nowa wersja, która wersja jest aktualna i jakie czynności powinny pozostać w historii. Zakres historii oraz możliwość edycji lub usuwania danych zależą od potrzeb firmy i uzgodnionych wymagań.

Systemy źródłowe i docelowe

Wskazujemy, który program przechowuje dokument, dane, status i końcową decyzję. Jeżeli kilka systemów może zmieniać tę samą informację, ustalamy jedno źródło prawdy i zasady synchronizacji.

Przechowywanie, eksport i kopie

Okres przechowywania, możliwość eksportu, usuwanie, kopie zapasowe i odtwarzanie trzeba ustalić dla konkretnego projektu. System nie staje się automatycznie zgodny z przepisami tylko dlatego, że przechowuje historię albo ogranicza dostęp.

Można zacząć od jednego obiegu

Pierwszy etap nie musi obejmować wszystkich dokumentów firmy. Często lepiej wybrać jeden typ dokumentu i przeprowadzić go od źródła do zakończenia sprawy.

Przykładowy pierwszy etap może obejmować:

• jedno źródło dokumentu;
• podstawowe dane i kontrolę kompletności;
• dwie lub trzy role;
• akceptację, odrzucenie i powrót do poprawy;
• jeden system docelowy albo ręczne potwierdzenie wyniku;
• czytelny status i podstawową historię działań;
• ustalone przypadki testowe i sposób odbioru.

Mniejszy zakres ma sens tylko wtedy, gdy tworzy użyteczny, zamknięty proces. Nie warto kończyć etapu w miejscu, które nadal wymusza przepisywanie tych samych danych albo pozostawia dokument bez odpowiedzialnej osoby.

Jak sprawdzamy, czy pierwszy etap działa?

Kryteria odbioru wynikają z procesu, a nie tylko z wyglądu ekranów. Dla przykładowego obiegu możemy sprawdzić, czy:

• dokument otrzymuje jednoznaczny identyfikator i trafia do właściwego procesu;
• brak wymaganych danych zatrzymuje przekazanie i daje czytelny komunikat;
• każda rola widzi wyłącznie dokumenty i czynności, do których ma dostęp;
• akceptacja, odrzucenie i prośba o poprawę prowadzą do właściwego następnego kroku;
• ponowne przesłanie albo przerwane połączenie nie tworzy niekontrolowanej kopii;
• dane przekazane do drugiego programu można powiązać z dokumentem źródłowym;
• błąd integracji pozostawia status i informację potrzebną do reakcji;
• historia pozwala ustalić, co wydarzyło się w testowanym scenariuszu.

Konkretne kryteria zapisujemy przed odbiorem. Dzięki temu wynik nie sprowadza się do stwierdzenia, że plik został zapisany albo formularz przesłał dane.

Integracja z używanymi programami

Elektroniczny obieg dokumentów może współpracować z CRM-em, ERP, księgowością, portalem B2B, magazynem albo inną aplikacją. Możliwość integracji potwierdzamy dopiero po sprawdzeniu dokumentacji, uprawnień, formatów danych i warunków dostawcy.

Jeżeli obecne programy dobrze obsługują swoje zadania, nie trzeba ich automatycznie wymieniać. Czasem właściwym rozwiązaniem jest połączenie ich w jeden kontrolowany przepływ. Innym razem problemem nie jest brak połączenia, lecz niejasne zasady odpowiedzialności i decyzji. Sama integracja tego nie naprawi.

Zobacz także integracje systemów i API oraz dedykowane systemy CRM i ERP.

Doświadczenie: HUB.ITM.PL

Około 2018 roku stworzyliśmy system dla dużego biura rachunkowego, które otrzymywało dane z wielu programów i formatów. Rozwiązanie obsługiwało między innymi dane związane z fakturami z Comarch ERP Optima, Sage Symfonia ERP, JPK-FA i źródeł UBER, a także pliki XML, XLS i CSV.

System odczytywał, mapował i sprawdzał dane, a następnie przygotowywał EDI++ do importu w Subiekt GT i Subiekt nexo. Ograniczył ręczne przepisywanie danych z tysięcy faktur i pozwolił biuru obsługiwać kolejnych klientów bez proporcjonalnego zwiększania ręcznej pracy.

To projekt historyczny, który nie jest już używany, ponieważ formaty i sposób wymiany danych uległy zmianie. HUB.ITM.PL nie był pełnym DMS. Był warstwą importu i przekształcania danych z dokumentów, dlatego nie przedstawiamy go jako dowodu wersjonowania, akceptacji, retencji ani przechowywania dokumentów.

Zobacz pełne case study HUB.ITM.PL.

Bezpieczeństwo, historia i wymagania prawne

Dokumenty mogą zawierać dane osobowe, warunki handlowe, informacje finansowe i inne dane poufne. Dlatego projekt powinien określać między innymi:

• role i zasadę najmniejszego potrzebnego dostępu;
• sposób uwierzytelniania użytkowników;
• zakres historii czynności i zmian;
• zasady eksportu, kopii zapasowych i odtwarzania;
• sposób przekazywania dokumentów pomiędzy systemami;
• okresy przechowywania oraz odpowiedzialność za ich ustalenie;
• procedurę odebrania dostępu po zmianie roli lub zakończeniu współpracy.

Rozwiązanie techniczne nie daje automatycznej gwarancji zgodności z RODO, KSeF, przepisami rachunkowymi ani wymaganiami branżowymi. Takie wymagania trzeba wskazać, zweryfikować i przypisać do odpowiedzialnych osób przed potwierdzeniem zakresu.

Nie przesyłaj przez formularz prawdziwych faktur, umów, danych klientów, haseł, kluczy API ani kopii bazy. Na początku wystarczy bezpieczny wzór dokumentu bez danych osobowych i tajemnic firmy albo opis jego struktury.

Jak zaczynamy współpracę?

1. Krótko kwalifikujemy potrzebę. Ustalamy, jaki dokument sprawia problem, skąd przychodzi i co powinno wydarzyć się dalej. Krótka rozmowa nie zastępuje analizy złożonego procesu.
2. Opisujemy jeden obieg. Zbieramy role, decyzje, dane, wyjątki, obecne programy i oczekiwany wynik.
3. Dobieramy kierunek. Sprawdzamy, czy wystarczy repozytorium, gotowy DMS, integracja, mniejszy moduł czy system dopasowany do procesu.
4. Ustalamy pierwszy etap. Zapisujemy zakres, kryteria odbioru, ryzyka, termin i indywidualną wycenę.
5. Budujemy i testujemy cały przepływ. Sprawdzamy prawidłowy scenariusz, braki danych, poprawki, odrzucenie, ponowienie i błąd połączenia.
6. Planujemy kolejne obiegi. Następne typy dokumentów, role i integracje powstają jako osobno uzgodnione etapy.

Jeżeli proces obejmuje wiele działów, typów dokumentów, wyjątków albo niepewnych integracji, pierwszym płatnym etapem może być analiza biznesowa i ustalenie zakresu MVP.

Najczęstsze pytania

Czy potrzebujemy pełnego DMS?

Nie zawsze. Jeżeli problem dotyczy głównie nazewnictwa, dostępu i odnajdywania plików, może wystarczyć uporządkowane repozytorium. Gdy dokument przechodzi przez decyzje, wyjątki i kilka systemów, warto sprawdzić DMS, integrację albo własny moduł.

Od jakiego dokumentu najlepiej zacząć?

Od dokumentu, który ma czytelny początek i koniec, często przechodzi przez ręczne kroki i powoduje powtarzalne problemy. Pierwszy obieg powinien mieć właściciela, znane role i mierzalne kryterium odbioru.

Czy można połączyć obieg z obecnym CRM-em, ERP lub księgowością?

Takie połączenie jest często możliwe, ale wymaga sprawdzenia konkretnego programu, dokumentacji, uprawnień, formatów danych i warunków licencyjnych. Nie potwierdzamy integracji przed tą weryfikacją.

Czy system może obsługiwać akceptacje, poprawki i odrzucenia?

Może, jeżeli firma jasno określi role, możliwe decyzje i dalszy krok dla każdego wyniku. Zakres tych funkcji ustalamy dla konkretnego obiegu.

Czy można zachować historię decyzji i dostęp według ról?

Takie wymagania można uwzględnić w projekcie. Trzeba określić, jakie czynności mają pozostać w historii, kto może je zobaczyć oraz czy i kiedy dane mogą być zmieniane lub usuwane.

Czy wdrożenie obejmuje OCR, podpis elektroniczny albo KSeF?

Nie są to domyślne elementy każdego projektu. Możemy ocenić ich potrzebę, ale zakres zależy od dostawcy, jakości dokumentów, dokumentacji, uprawnień, kosztów i wymagań prawnych.

Czy trzeba wymieniać obecne systemy?

Nie. Jeżeli spełniają swoje zadania, można rozważyć ich integrację albo dodanie mniejszego modułu. Wymiana ma sens dopiero wtedy, gdy ograniczenia obecnych programów blokują uzgodniony proces.

Jak przygotować przykład dokumentu do rozmowy?

Usuń dane osobowe, numery rachunków, kwoty poufne, podpisy, dane klientów i inne tajemnice firmy. Możesz też przesłać sam opis pól, źródła dokumentu i decyzji, które mają zostać podjęte.

Od czego zależą koszt i termin?

Od liczby typów dokumentów, ról, decyzji, wyjątków, integracji, migracji danych, wymagań bezpieczeństwa, historii i utrzymania. Zakres, termin i cenę ustalamy indywidualnie po zebraniu potrzebnych informacji.

Co przesłać na początek?

W pierwszej wiadomości opisz:

• jeden typ dokumentu, od którego chcesz rozpocząć;
• skąd dokument przychodzi i w jakiej formie;
• kto go sprawdza, akceptuje, poprawia lub odrzuca;
• gdzie znajduje się aktualny status;
• jakie dane są dziś przepisywane ręcznie;
• jakie programy muszą pozostać w procesie;
• najczęstszy wyjątek lub błąd;
• po czym poznasz, że pierwszy etap działa poprawnie.

Nie potrzebujemy od razu technicznej specyfikacji ani rzeczywistych dokumentów. Na podstawie opisu sprawdzimy, czy można przejść do wyceny, czy najpierw potrzebna jest analiza procesu.

CTA: Porozmawiajmy o pierwszym obiegu

Jeżeli chcesz najpierw samodzielnie uporządkować informacje, skorzystaj z bezpłatnego kreatora opisu projektu.

Zobacz także integracje systemów i API, dedykowane systemy CRM i ERP, portal B2B i system zamówień oraz analizę biznesową i zakres MVP aplikacji.