Przygotowanie jednostki do wdrożenia EZD wymaga analizy procesów, dokumentów, ról, integracji, wyjątków oraz jasnego podziału odpowiedzialności między stronami projektu wdrożeniowego.
Wdrożenie systemu klasy EZD nie polega wyłącznie na uruchomieniu oprogramowania, utworzeniu kont użytkowników i przeprowadzeniu szkolenia z obsługi ekranów. To zmiana sposobu rejestrowania korespondencji, prowadzenia spraw, podejmowania decyzji, podpisywania dokumentów, przekazywania odpowiedzialności i archiwizowania dokumentacji.
Zgodnie z oficjalnymi zapowiedziami od 1 stycznia 2028 roku podmioty realizujące zadania publiczne mają zostać objęte obowiązkiem stosowania systemów klasy EZD. Nie oznacza to jednak obowiązku wyboru konkretnie EZD RP. Jednostka może korzystać z systemu spełniającego wymagania dla tej klasy rozwiązań, a EZD RP jest jednym z najważniejszych przykładów dostępnych dla administracji publicznej.
To rozróżnienie jest istotne również dla firm wdrożeniowych. Przedmiotem projektu nie powinno być jedynie „zainstalowanie EZD”, ale przygotowanie organizacji, konfiguracji, procedur, integracji i użytkowników do prowadzenia dokumentacji w nowym modelu.
System nie uporządkuje automatycznie procesów, które wcześniej nie zostały opisane. Może jedynie przenieść istniejące niejasności do środowiska cyfrowego.
Poniższy materiał nie jest opisem konkretnego wdrożenia EZD RP zrealizowanego przeze mnie. Jest przykładem podejścia analitycznego, które można zastosować zarówno po stronie jednostki publicznej, jak i firmy odpowiedzialnej za przygotowanie lub realizację wdrożenia.
Dwa punkty widzenia na ten sam projekt
Jednostka publiczna i firma wdrożeniowa patrzą na projekt z innych perspektyw.
Jednostka zna swoją strukturę, przepisy wewnętrzne, rodzaje prowadzonych spraw, pracowników, wyjątki i codzienne problemy. Często jednak wiedza ta jest rozproszona pomiędzy kancelarią, archiwum, działem prawnym, informatyką, kierownikami i pracownikami merytorycznymi.
Wykonawca zna system, możliwości konfiguracji, infrastrukturę, integracje i sposób prowadzenia projektu. Nie może jednak samodzielnie zdecydować, jak powinien wyglądać proces konkretnej jednostki, które sprawy pozostają wyjątkami ani kto odpowiada za poszczególne decyzje.
Pomiędzy tymi dwiema perspektywami potrzebna jest analiza, która zamienia wiedzę organizacji w materiały możliwe do wykorzystania podczas konfiguracji, integracji, testów i odbioru systemu.
Masz podobny temat i chcesz go uporządkować?
EZD RP a system klasy EZD — ważne rozróżnienie
W rozmowach o cyfryzacji administracji pojęcia „EZD” i „EZD RP” bywają używane zamiennie, chociaż nie oznaczają dokładnie tego samego.
- System klasy EZD to rozwiązanie służące do elektronicznego zarządzania dokumentacją i prowadzenia spraw.
- EZD RP to konkretny system rozwijany dla podmiotów publicznych i udostępniany wraz z dokumentacją, wsparciem oraz możliwościami integracji.
Z punktu widzenia analizy procesowej główne pytania pozostają jednak podobne niezależnie od wybranego produktu:
- jak dokument wpływa do jednostki,
- kto i gdzie go rejestruje,
- jak przebiega dekretacja,
- kiedy dokument tworzy nową sprawę,
- kiedy jest dołączany do sprawy istniejącej,
- kto odpowiada za realizację merytoryczną,
- jak przebiega akceptacja i podpis,
- w jaki sposób dokument jest wysyłany,
- które dane trafiają do systemów dziedzinowych,
- jak zamykana i archiwizowana jest sprawa.
Wdrożenie zaczyna się przed pierwszym logowaniem
Zanim jednostka rozpocznie konfigurację systemu, powinna zebrać informacje o swoim rzeczywistym sposobie działania. Nie wystarczy procedura opisana w zarządzeniu. Potrzebna jest również wiedza o tym, jak dokumenty faktycznie krążą pomiędzy kancelarią, sekretariatami, kierownikami i pracownikami merytorycznymi.
Analiza przygotowawcza powinna objąć między innymi:
- strukturę organizacyjną jednostki, jej lokalizacje, oddziały i delegatury,
- liczbę użytkowników systemu i pracowników punktów kancelaryjnych,
- liczbę i rodzaje przesyłek wpływających oraz wychodzących,
- kanały wpływu dokumentów: papier, e-mail, e-Doręczenia, formularze i systemy dziedzinowe,
- obowiązujące instrukcje kancelaryjne i archiwalne,
- jednolity rzeczowy wykaz akt i sposób klasyfikowania spraw,
- prowadzone rejestry i ewidencje,
- rodzaje podpisów stosowanych przez osoby uprawnione,
- sprzęt wykorzystywany w kancelarii, w tym skanery, czytniki i drukarki kodów,
- systemy dziedzinowe, z których korzystają poszczególne komórki,
- sprawy, które mogą być prowadzone elektronicznie,
- sprawy, które z przyczyn prawnych, organizacyjnych lub technicznych mają pozostać wyjątkami,
- potrzeby szkoleniowe pracowników,
- wymagania dotyczące bezpieczeństwa, ciągłości działania i dostępności systemu.
Już na tym etapie może się okazać, że problemem nie jest brak systemu, ale brak wspólnej wiedzy o procesie. Poszczególne komórki mogą inaczej rozumieć moment rejestracji sprawy, zasady dekretacji, odpowiedzialność za kompletność dokumentacji albo sposób obsługi wyjątków.
Masz podobny temat i chcesz go uporządkować?
Mapa procesu obecnego: jak dokument krąży dzisiaj?
Pierwszym materiałem analitycznym może być mapa procesu obecnego, czyli model AS-IS. Nie ma ona pokazywać, jak powinno być. Ma pokazać, jak organizacja pracuje naprawdę.
W typowym procesie dokument może wpłynąć kilkoma kanałami. Następnie bywa rejestrowany w jednym miejscu, skanowany w innym, przekazywany mailowo, dekretowany na papierze i przechowywany równocześnie w segregatorze, folderze sieciowym oraz systemie dziedzinowym.
Podczas mapowania procesu obecnego warto zapytać:
- ile razy te same dane są przepisywane,
- gdzie powstają kopie dokumentu,
- kto zna aktualny status sprawy,
- jak pracownik dowiaduje się, że powinien wykonać kolejny krok,
- czy można odtworzyć historię decyzji,
- czy wiadomo, która wersja dokumentu jest aktualna,
- gdzie przechowywane są załączniki,
- jak obsługiwane są dokumenty błędnie skierowane,
- co dzieje się podczas nieobecności osoby odpowiedzialnej.
Dopiero po zrozumieniu tych problemów można zaprojektować proces docelowy. W przeciwnym razie istnieje ryzyko przeniesienia papierowego obiegu do systemu bez rzeczywistego uproszczenia pracy.
Przykładowy proces docelowy: obsługa pisma wpływającego
Proces docelowy, czyli TO-BE, powinien wskazywać nie tylko kolejne czynności, ale również role, decyzje, dane, statusy i wyjątki.
Przykładowy przebieg obsługi pisma wpływającego może obejmować:
- wpływ dokumentu przez kancelarię, e-Doręczenia, e-mail albo inny kanał,
- rejestrację przesyłki i nadanie identyfikatora,
- utworzenie odwzorowania cyfrowego dokumentu papierowego, jeżeli jest wymagane,
- uzupełnienie metadanych,
- dekretację na właściwą komórkę lub osobę,
- utworzenie nowej sprawy albo dołączenie pisma do sprawy istniejącej,
- realizację merytoryczną,
- przygotowanie projektu odpowiedzi lub rozstrzygnięcia,
- akceptację i podpis przez osobę uprawnioną,
- wysłanie dokumentu właściwym kanałem,
- zarejestrowanie potwierdzenia wysyłki lub doręczenia,
- zamknięcie sprawy i przygotowanie dokumentacji do dalszego przechowywania.
Diagram nie powinien być traktowany jako gotowa procedura dla każdej jednostki. Jest punktem wyjścia do rozmowy. W konkretnej organizacji mogą występować dodatkowe poziomy dekretacji, konsultacje prawne, uzgodnienia między komórkami, podpisy wieloosobowe, integracje z systemami dziedzinowymi albo wyjątki dotyczące dokumentacji papierowej.
Nie każdy proces powinien wyglądać tak samo
Jednym z częstych błędów jest próba zastosowania jednej ścieżki obiegu do wszystkich dokumentów i spraw. Tymczasem inaczej może przebiegać obsługa:
- zwykłej korespondencji informacyjnej,
- skargi lub wniosku obywatela,
- umowy wymagającej uzgodnień kilku komórek,
- faktury przekazywanej do systemu finansowo-księgowego,
- sprawy kadrowej,
- postępowania zakupowego,
- dokumentacji technicznej,
- sprawy prowadzonej głównie w systemie dziedzinowym,
- dokumentacji, której część musi pozostać w postaci nieelektronicznej.
Dlatego jednostka powinna stworzyć katalog procesów, rodzajów spraw i dokumentów. Dla każdego z nich warto określić:
- właściciela procesu,
- komórki uczestniczące,
- podstawę klasyfikacji,
- kanały wpływu i wysyłki,
- wymagane dane i załączniki,
- poziomy akceptacji,
- rodzaj podpisu,
- terminy i reguły eskalacji,
- system źródłowy,
- miejsce przechowywania dokumentacji,
- wyjątki i scenariusze błędów.
Zespół wdrożeniowy musi łączyć różne kompetencje
Wdrożenie systemu klasy EZD nie powinno być projektem prowadzonym wyłącznie przez dział IT. Informatycy nie mogą samodzielnie ustalić zasad kancelaryjnych, a pracownicy kancelarii nie powinni sami projektować integracji i wymagań technicznych.
W zależności od wielkości i charakteru jednostki w pracach powinni uczestniczyć przedstawiciele:
- kierownictwa jednostki,
- kancelarii lub sekretariatu,
- archiwum zakładowego,
- obsługi prawnej,
- działu IT,
- bezpieczeństwa informacji i ochrony danych,
- kluczowych komórek merytorycznych,
- osób odpowiedzialnych za szkolenia i komunikację wewnętrzną,
- koordynatorów wdrożenia w poszczególnych komórkach.
Potrzebny jest także właściciel decyzji. Zespół może analizować warianty, ale ktoś musi rozstrzygnąć, które klasy spraw wchodzą do pilotażu, jakie wyjątki zostają zaakceptowane i jaki harmonogram jest obowiązujący.
Jednostka i wykonawca potrzebują wspólnego modelu procesu
Wiedza jednostki i wiedza wykonawcy są komplementarne. Problem pojawia się wtedy, gdy każda ze stron zakłada, że druga „powinna wiedzieć”, co należy zrobić.
| Jednostka publiczna | Firma wdrożeniowa |
|---|---|
| Zna strukturę, przepisy i rzeczywisty sposób pracy | Zna system, konfigurację i technologię |
| Zna wyjątki organizacyjne | Potrzebuje jednoznacznych reguł |
| Wie, kto podejmuje decyzje | Potrzebuje opisu ról i uprawnień |
| Zna dokumenty i rodzaje prowadzonych spraw | Potrzebuje struktur danych i scenariuszy |
| Oczekuje poprawy sposobu pracy | Potrzebuje kryteriów odbioru |
| Odpowiada za decyzje organizacyjne | Odpowiada za realizację uzgodnionego zakresu |
Czego potrzebuje firma wdrożeniowa?
Informacja „jednostka chce wdrożyć EZD RP” nie stanowi jeszcze kompletnego zakresu projektu. Wykonawca powinien otrzymać możliwie uporządkowane informacje pozwalające oszacować pracę, zaplanować konfigurację i zidentyfikować ryzyka.
Materiały wejściowe mogą obejmować:
- opis struktury organizacyjnej,
- listę lokalizacji i punktów kancelaryjnych,
- mapy procesów AS-IS i TO-BE,
- katalog rodzajów spraw i dokumentów,
- listę klas spraw wybranych do pilotażu,
- listę wyjątków prowadzonych tradycyjnie lub w innych systemach,
- opis ról, uprawnień i zastępstw,
- macierz odpowiedzialności,
- wymagania funkcjonalne i niefunkcjonalne,
- listę systemów dziedzinowych,
- opis wymaganych integracji,
- założenia migracji danych, jeżeli jest potrzebna,
- wymagania dotyczące raportów, rejestrów i metadanych,
- scenariusze testowe,
- kryteria odbioru,
- harmonogram pilotażu i rozszerzania wdrożenia.
Nie wszystkie materiały muszą powstać przed wyborem wykonawcy. Zakres analizy zależy od modelu zamówienia. Ważne jest jednak, aby było jasne, które decyzje zostały już podjęte przez jednostkę, a które mają powstać wspólnie z wykonawcą.
Masz podobny temat i chcesz go uporządkować?
Integracje z systemami dziedzinowymi
System klasy EZD rzadko działa w całkowitej izolacji. Jednostki korzystają z programów finansowo-księgowych, kadrowych, zamówieniowych, podatkowych, technicznych, rejestrowych i branżowych. Wdrożenie wymaga ustalenia, w którym systemie rozpoczyna się proces, gdzie podejmowana jest decyzja i który system przechowuje wynik.
Dla każdej integracji warto odpowiedzieć na pytania:
- jaki jest cel biznesowy integracji,
- który system jest źródłem prawdy dla poszczególnych danych,
- jakie dokumenty i metadane są przekazywane,
- czy wymiana jest jednokierunkowa, czy dwukierunkowa,
- co inicjuje przekazanie danych,
- jak identyfikowana jest sprawa i dokument,
- jak obsługiwane są załączniki,
- jak zwracany jest status przetwarzania,
- co dzieje się po błędzie,
- czy operacja może zostać powtórzona bez utworzenia duplikatu,
- jak prowadzony jest rejestr komunikacji,
- jakie są wymagania bezpieczeństwa i dostępności.
Przykład analizy integracji: faktura wpływająca do jednostki
Przykładem procesu wymagającego uzgodnienia pomiędzy systemami może być obsługa faktury pobieranej z KSeF albo otrzymanej poza KSeF w przypadkach dopuszczonych przepisami. Poniższy scenariusz ma charakter analityczny i pokazuje sposób zadawania pytań, a nie gotową konfigurację dla każdej jednostki.
- faktura jest pobierana z KSeF, a w przypadkach, w których zgodnie z przepisami może zostać wystawiona poza KSeF, wpływa do jednostki na przykład przez e-Doręczenia, pocztę elektroniczną albo kancelarię,
- dokument zostaje zarejestrowany w systemie EZD,
- uzupełniane są metadane dokumentu,
- dokument zostaje powiązany z właściwą sprawą lub rejestrem,
- dane faktury i dokument są przekazywane do systemu finansowo-księgowego,
- w systemie finansowym wykonywana jest kontrola merytoryczna i rachunkowa,
- status akceptacji lub odrzucenia wraca do systemu EZD,
- w EZD pozostaje informacja o przebiegu sprawy i wyniku procesu,
- po zakończeniu czynności sprawa może zostać zamknięta zgodnie z przyjętymi zasadami.
Analiza musi rozstrzygnąć, czy akceptacje są wykonywane w EZD, w systemie finansowym, czy częściowo w obu rozwiązaniach. Bez takiej decyzji łatwo stworzyć dwa równoległe workflow, dwa różne statusy i niejasność co do tego, który system pokazuje rzeczywisty stan procesu.
Etapowanie wdrożenia zamiast jednego wielkiego uruchomienia
Wdrożenie systemu klasy EZD powinno być etapowane. Jednostka potrzebuje czasu na przygotowanie procedur, przeszkolenie zespołu, sprawdzenie infrastruktury, przetestowanie obiegu dokumentów i wybór pierwszych spraw prowadzonych elektronicznie.
Przykładowy model może obejmować cztery główne etapy:
- Środowisko testowe i przygotowanie organizacji — powołanie zespołu, inwentaryzacja, pierwsze procedury, konfiguracja i szkolenia.
- Pierwsze czynności kancelaryjne w środowisku produkcyjnym — rejestracja i skanowanie korespondencji, testowanie dekretacji i podstawowego obiegu.
- Pilotaż wybranych klas spraw — prowadzenie pierwszych spraw elektronicznych, weryfikacja procedur, szkolenie wszystkich uczestników procesu.
- EZD jako podstawowy system kancelaryjny — prowadzenie większości spraw elektronicznie i pozostawienie uzasadnionych wyjątków.
Etapowanie nie powinno oznaczać wdrożenia bez celu końcowego. Każda faza powinna mieć jasno określony rezultat, termin i kryteria przejścia do kolejnego etapu.
Jak wybrać proces do pilotażu?
Pierwszy proces nie powinien być ani zupełnie marginalny, ani najbardziej złożony w całej organizacji. Powinien być wystarczająco reprezentatywny, aby sprawdzić działanie systemu, ale możliwy do opanowania przez zespół wdrożeniowy.
Przy wyborze pilotażu warto ocenić:
- liczbę spraw i dokumentów,
- liczbę uczestniczących komórek,
- złożoność ścieżki akceptacji,
- liczbę wyjątków,
- potrzebę integracji z innymi systemami,
- gotowość pracowników,
- ryzyko operacyjne,
- możliwość zmierzenia efektu.
Dobrze wybrany pilotaż powinien pozwolić zweryfikować co najmniej rejestrację, dekretację, tworzenie sprawy, realizację merytoryczną, akceptację, wysyłkę i zamknięcie sprawy.
Testy powinny wynikać z procesów
Testowanie wdrożenia nie powinno ograniczać się do sprawdzenia, czy użytkownik może zalogować się i kliknąć poszczególne funkcje. Potrzebne są scenariusze odzwierciedlające prawdziwą pracę jednostki.
Przykładowe scenariusze testowe mogą obejmować:
- rejestrację dokumentu papierowego i wykonanie odwzorowania cyfrowego,
- obsługę dokumentu z e-Doręczeń,
- dekretację wielopoziomową,
- przekazanie pisma do niewłaściwej komórki i jego zwrot,
- zastępstwo podczas nieobecności pracownika,
- utworzenie nowej sprawy,
- dołączenie dokumentu do sprawy istniejącej,
- przygotowanie projektu odpowiedzi,
- odrzucenie dokumentu na etapie akceptacji,
- podpisanie i wysłanie dokumentu,
- błąd integracji z systemem dziedzinowym,
- ponowienie transmisji danych bez tworzenia duplikatów,
- zamknięcie sprawy z niekompletnymi metadanymi,
- wyszukanie dokumentu i odtworzenie historii działań.
Każdy scenariusz powinien zawierać dane wejściowe, oczekiwany przebieg, spodziewany rezultat oraz kryterium zaliczenia testu.
Kryteria odbioru muszą być mierzalne
Stwierdzenie „system działa poprawnie” jest zbyt ogólne. Odbiór powinien opierać się na konkretnych warunkach.
Przykładowe kryteria mogą dotyczyć:
- poprawnej obsługi wskazanych kanałów wpływu,
- zgodności struktury organizacyjnej i uprawnień,
- możliwości wykonania pełnych scenariuszy procesowych,
- kompletności wymaganych metadanych,
- poprawności dekretacji i zastępstw,
- poprawności podpisów i wysyłki,
- zgodności integracji z uzgodnionym zakresem,
- poprawnej obsługi błędów,
- wydajności dla zakładanej liczby użytkowników,
- wykonania kopii bezpieczeństwa i odtworzenia systemu,
- przekazania dokumentacji administratorom i użytkownikom,
- przeszkolenia wskazanych grup pracowników.
Najczęstsze ryzyka wdrożenia systemu klasy EZD
Wdrożenie może napotkać problemy, nawet jeśli sam system działa technicznie poprawnie. Do najczęstszych ryzyk należą:
- traktowanie projektu wyłącznie jako zadania informatycznego,
- brak jednoznacznego wsparcia kierownictwa,
- brak właścicieli procesów,
- kopiowanie papierowego obiegu bez jego uproszczenia,
- niepełna analiza obowiązujących procedur,
- zbyt szeroki zakres pierwszego uruchomienia,
- brak uzgodnionej listy wyjątków,
- niejasny podział odpowiedzialności między jednostką a wykonawcą,
- brak decyzji, który system jest źródłem danych,
- równoległe prowadzenie tych samych akceptacji w kilku systemach,
- szkolenia ograniczone do obsługi przycisków, bez wyjaśnienia nowych zasad pracy,
- brak testów na rzeczywistych przypadkach,
- brak mierzalnych kryteriów zakończenia pilotażu,
- brak planu utrzymania i rozwoju rozwiązania po uruchomieniu.
Uruchomienie produkcyjne nie kończy wdrożenia. Rozpoczyna etap utrzymania procedur, jakości danych, wsparcia użytkowników i stopniowej elektronizacji kolejnych procesów.
Co powinno powstać w ramach analizy?
Efektem analizy nie musi być jeden duży dokument. Bardziej użyteczny jest zestaw powiązanych materiałów, które można aktualizować i wykorzystywać podczas kolejnych etapów projektu.
W zależności od zakresu mogą to być:
- raport gotowości organizacji,
- inwentaryzacja procesów i systemów,
- mapy procesów AS-IS,
- mapy procesów TO-BE,
- katalog rodzajów spraw i dokumentów,
- lista problemów i wyjątków,
- macierz ról oraz odpowiedzialności,
- katalog wymagań funkcjonalnych,
- wymagania niefunkcjonalne,
- opis integracji i kierunków wymiany danych,
- założenia migracji,
- plan pilotażu,
- scenariusze testowe,
- kryteria odbioru,
- rejestr ryzyk i decyzji projektowych,
- materiały dla wykonawcy i zespołu wdrożeniowego.
Co zyskuje jednostka?
Dla jednostki analiza oznacza przede wszystkim możliwość świadomego przygotowania zmiany organizacyjnej. Pozwala ustalić, co rzeczywiście trzeba zmienić, zanim rozpocznie się konfiguracja albo postępowanie zakupowe.
Korzyści mogą obejmować:
- lepsze zrozumienie obecnego obiegu dokumentów,
- ustalenie właścicieli procesów,
- wybór rozsądnego zakresu pilotażu,
- uporządkowanie ról i odpowiedzialności,
- identyfikację wyjątków przed uruchomieniem systemu,
- lepsze przygotowanie pracowników,
- bardziej jednoznaczny zakres zamówienia,
- możliwość kontrolowania pracy wykonawcy,
- ograniczenie ryzyka kosztownych zmian podczas realizacji.
Co zyskuje firma wdrożeniowa?
Dla firmy realizującej wdrożenie dobra analiza oznacza mniejszą liczbę założeń i mniej niejasności podczas konfiguracji oraz integracji.
Wykonawca otrzymuje:
- opis rzeczywistych potrzeb organizacji,
- uzgodnione modele procesów,
- listę decyzji pozostających po stronie jednostki,
- lepszą podstawę do estymacji,
- jasny zakres integracji,
- scenariusze do konfiguracji i testów,
- mierzalne kryteria odbioru,
- mniejsze ryzyko sporów o zakres prac,
- materiał wspierający komunikację z klientem.
W czym może pomóc LISNET Consulting?
Mogę wesprzeć jednostkę publiczną albo wykonawcę wdrożenia w analitycznej części projektu dotyczącego systemu klasy EZD.
Zakres takiego wsparcia może obejmować:
- przygotowanie i prowadzenie warsztatów procesowych,
- mapowanie obecnego obiegu dokumentów,
- projektowanie procesów docelowych,
- przygotowanie katalogu procesów, dokumentów i wyjątków,
- opis ról i odpowiedzialności,
- przygotowanie wymagań funkcjonalnych i niefunkcjonalnych,
- opis potrzeb integracyjnych i kierunków przepływu danych,
- przygotowanie przypadków użycia i scenariuszy testowych,
- opracowanie kryteriów odbioru,
- przygotowanie materiałów dla wykonawcy,
- wsparcie jednostki w komunikacji z dostawcą rozwiązania,
- wsparcie firmy wdrożeniowej w doprecyzowaniu procesów po stronie klienta,
- wsparcie analityczne pilotażu i kolejnych etapów projektu.
Nie zastępuję specjalistów kancelaryjnych, archiwistów, prawników ani dostawcy systemu EZD. Mogę natomiast połączyć wiedzę tych osób z analizą procesową i systemową oraz przygotować materiały potrzebne do sprawnego przeprowadzenia projektu.
Dla jednostki może to oznaczać lepsze przygotowanie organizacji przed rozpoczęciem wdrożenia. Dla wykonawcy — uporządkowany materiał pozwalający ograniczyć liczbę niejasności, zmian zakresu i sporów podczas realizacji.
Podsumowanie
Wdrożenie systemu klasy EZD nie jest wyłącznie projektem informatycznym. Obejmuje zmianę procesów, procedur, odpowiedzialności i codziennych nawyków związanych z prowadzeniem dokumentacji.
Jednostka powinna przygotować wiedzę o procesach, dokumentach, klasach spraw, rolach, wyjątkach i systemach dziedzinowych. Wykonawca powinien przełożyć uzgodnione potrzeby na konfigurację, integracje, testy i uruchomienie rozwiązania.
Łącznikiem między tymi perspektywami jest analiza biznesowo-systemowa. To ona pozwala zamienić rozproszoną wiedzę organizacji w zakres, który można wdrożyć, przetestować i odebrać.
Im więcej kluczowych decyzji zostanie podjętych przed konfiguracją systemu, tym mniej kosztownych nieporozumień pojawi się podczas wdrożenia.
