Przejście na EZD - jak rozplanować kroki i etapy wdrożenia?

[jacek_k]

Mam pewne podejrzenie, na które ostatnio ktoś zwrócił mi uwagę przy przeglądaniu strony MC, że EZD RP już nie ma pod tą nazwą, a cały projekt został "ukryty" za "Aplikacje.gov.pl"?

A jakie to podejrzenia? Od początku słyszało się, że ten EZD ma być obudowany nowymi aplikacjami, z założenia to źle nie wygląda. Bo mnie bardziej martwi to co się mówi, że ten "nowy" EZD ma bazować bardziej na eDOKu niż na EZD PUW... Martwi bo ja się obawiam, że z eDOKa to nic dobrego nie wyjdzie ale wiadomo, że ciału (COIa) bliższa koszula.

Chodziło mi bardziej o to, że bezgłośnie nazwa EZD RP zniknęła...

[Jarek]

Na stronie Komitetu Cyfryzacji jest już ostateczna wersja opisu założeń projektu aplikacje.gov.pl . Nazwa "EZD RP" jest tam jeszcze z rzadka używana, pojawia się za to określenie "system EZD aplikacje gov.pl". Jest trochę niekonsekwencji w nazewnictwie, bo są tam różne oboczności nazwy projektowanego systemu - np. "aplikacja EZD", "Elektroniczne Zarządzanie Dokumentacją (EZD)" - co trochę niepokoi, bo może powodować w przyszłości trudności w definiowaniu co jest czym.
Nie nazwa jest ważna ale kluczowe zasoby projektu:
   - Aplikacja EZD
   - Aplikacje dodatkowe: Urlopy, Delegacje, Karty obiegowe, Komunikator
   - Baza profili jednostek administracji publicznej
   - Wspólna biblioteka elementów graficznych
   - Bazowanie na technologiach open source

Czyli - ujmując rzecz oględnie - szału nie ma.

[luke]

Mam pewne podejrzenie, na które ostatnio ktoś zwrócił mi uwagę przy przeglądaniu strony MC, że EZD RP już nie ma pod tą nazwą, a cały projekt został "ukryty" za "Aplikacje.gov.pl"?
[/quote]

Oczywiście, przecież już pisaliśmy, że przedmiotem opiniowania przez KRMC nie był projekt EZD RP, tylko aplikacje.gov.pl
Swoją drogą został zaopiniowany pozytywnie

[Jarek]

Przejście z jednego systemu EZD na inny (w sensie producent i program) to jest interesujący problem, ale wydaje mi się że doświadczenia NDAP jako urzędu nam się w tym przypadku nie przydadzą.

Nie przydadzą się,  bo nie są duże? Do pewnego dnia był stosowany jeden system EZD, a od tego czasu - drugi. Sprawy kontynuowane były ponownie rejestrowane w nowym systemie - z tym samym znakiem lub z nowym. W niektórych teczkach są spisy spraw drukowane ze starego i nowego systemu. Ot, signum temporis.

Ale siedzi mi w głowie zdanie kolegi: dwie przeprowadzki archiwum to tyle co pożar, a taka migracja to gorsza jest wszak jak przeprowadzka i umacniam się w tym przekonaniu. Więc może czasem łatwiej/lepiej utrzymywać stary system aż do przekazania/wybrakowania dokumentacji w nim zawartej niż bawić się w migracje?

To nie wróży dobrze w kontekście długotrwałego (wieczystego) przechowywania dokumentów elektronicznych.  Zdanie kolegi świadczy, że stosowanym systemom daleko do interoperacyjności, a to jest warunek konieczny do sprawnego zarządzania takimi dokumentami. Obecnie, mając dostęp do nowego i do starego systemu, wykonujemy poszukiwania w jednym z nich lub w obu, trwa to dłużej, ale jest możliwe. Jeśli jednak systemów będzie więcej? Czy czas poświęcany na poszukiwanie i tu, i tam jest mniej cenny niż ten, który trzeba poświęcić na migrację danych do jednego systemu? A doświadczenie w migracji -

[po chwilowych kłopotach z systemem]
A doświadczenia w migracji - nieoceniona wartość dodana. Muzeum hard- i software-owe to może i jest dobry pomysł, ale jako muzeum, do oglądania, nie do stosowania.
Niestety, niezmienne od ponad 10 lat rozporządzenia dot. dokumentów elektronicznych nie stanowią realnej pomocy, a ich stosowanie jest raczej umowne. O MoReq też coraz rzadziej słyszymy, a może to w temacie EZD RP?

Nie migrujecie dokumentów i danych, takich urzędów które przeszły na nowy program bez migracji jest chyba już co najmniej kilka, to po prostu nic nowego. Choć może i taki wariant warto opisać w zakresie zalecanych praktyk postępowania.
Migracja sama w sobie nie niesie żadnej wartości, jest tylko sposobem na zachowanie lub/i ułatwienie dostępu do dokumentów. Może być też zagrożeniem dla bezpieczeństwa informacji. Doświadczenia w migracji? Szczerze mówiąc ja nie chcę mieć żadnych, tzn. wolałbym żeby to mój urząd ominęło. Ale czeka nas zapewne przejście na "system EZD aplikacje.gov.pl" więc to pewnie będzie nieuchronne. Tutaj nadzieję jednak daje to: https://github.com/stas53/ezd-analizy-it/blob/a4867bf37c2686f063d126ea666c765a8224aabf/migracja.rst czyli powinno być z góry wiadomo co i jak przemigrować, bez eksperymentowania na żywym systemie i dokumentach - opisujemy to w procedurze, sięgamy po dedykowane narzędzie, dokumentujemy działania. Interoperacyjność ma zastosowanie głównie do projektowania systemów, przy migracji problemem będą stare systemy różnych producentów.
Tłumaczenie moreq2 zniknęło nawet ze strony NDAP.
Ja takiego "muzeum" używam od 6 lat i nie narzekam.

[Jarek]

Zastanawiam się jeszcze nad tym tematem, a im zastanawiam się dłużej, tym częściej przychodzi mi na myśl takie moje zdanie,  że na szczęście nie zawsze mam rację  Bo korzyść jest także ze słuchania tych, którzy wydają się nie mieć wielkiego doświadczenia. Migracja to jest problem i trzeba mu się przyjrzeć gruntownie.
Widzę to teraz tak:
Te pierwsze zmiany systemu to są indywidualne przypadki, kiedy bardzo różne programy są zastępowane nowym programem, towarzyszy temu też chyba często decyzja o pełnym przejściu na EZD. Moim zdaniem decyzja o sposobie dostępności do danych wspomagających powinna pozostać w rękach jednostki, czyli migrują dane tylko ci, którzy chcą (jednostka sama też powinna chyba decydować, które dane wspomagające chce migrować). Taka migracja przy użyciu systemów, które nie mają gotowych narzędzi do migracji to arcytrudna robota, o czym ciekawie (na przykładzie swojego urzędu) na ostatnim forum kck mówił pan Artur Prasal.
Kolejna rzecz - od migracji prawdopodobnie nie uciekniemy, czeka to wcześniej czy później wszystkich którzy używają EZD. Jeśli coś ma być jednak normowane w przepisach to przede wszystkim powinno to być zapisanie w rozporządzeniu w sprawie postępowania dokumentami elektronicznymi, wśród wymagań dla systemów, także wymogu zapewnienia migracji (a nie tylko wymiany danych - choć nie wiem czy informatycy się z tym rozróżnieniem zgodzą). Musi się chyba jednak z tym wiązać także odniesienie do niezbędnych elementów struktury - bo migracja będzie oznaczać przeniesienie dokumentów, metadanych ale także innych informacji.

[Ewap]

Nie migrujecie dokumentów i danych, takich urzędów które przeszły na nowy program bez migracji jest chyba już co najmniej kilka, to po prostu nic nowego. Choć może i taki wariant warto opisać w zakresie zalecanych praktyk postępowania.
Migracja sama w sobie nie niesie żadnej wartości, jest tylko sposobem na zachowanie lub/i ułatwienie dostępu do dokumentów. Może być też zagrożeniem dla bezpieczeństwa informacji. Doświadczenia w migracji? Szczerze mówiąc ja nie chcę mieć żadnych, tzn. wolałbym żeby to mój urząd ominęło. Ale czeka nas zapewne przejście na "system EZD aplikacje.gov.pl" więc to pewnie będzie nieuchronne. Tutaj nadzieję jednak daje to: https://github.com/stas53/ezd-analizy-it/blob/a4867bf37c2686f063d126ea666c765a8224aabf/migracja.rst czyli powinno być z góry wiadomo co i jak przemigrować, bez eksperymentowania na żywym systemie i dokumentach - opisujemy to w procedurze, sięgamy po dedykowane narzędzie, dokumentujemy działania. Interoperacyjność ma zastosowanie głównie do projektowania systemów, przy migracji problemem będą stare systemy różnych producentów.
Tłumaczenie moreq2 zniknęło nawet ze strony NDAP.
Ja takiego "muzeum" używam od 6 lat i nie narzekam.

Z wypowiedzi Jarka wynika jedna kwestia, że chyba zakłada stabilność zatrudnienia  czyli Ci co pracowali w poprzednim systemie, pracują w nowym, wiedzą jak działał i jak działa poprzedni oraz potrafią z obu korzystać.
A co w sytuacji, gdy zmienia się archiwista, koordynator, urzędnicy? Brak migracji danych między systemami powoduje, że trzeba nauczyć się obsługi starych i nowych systemów. Oznacza też, że nowo zatrudnieni pracownicy powinni dostać konta w starych i nowych systemach. Oznacza też że administratorzy muszą tak samo obsługiwać stary i nowy system. Zapewnić dla nich infrastrukturę i utrzymanie, by się nie degradowały, itp. itd.
Od strony merytorycznej to pytanie o zestawienia i raporty, ich ciągłość i jednolitość...
Widzę jeszcze więcej zagrożeń i ryzyk dla pracy w kilku systemach, ale nie czas by wszystkie opisać...

Opisuję ten problem szerzej niż tylko względem NDAP, ale wydaje mi się, że akurat NDAP zanim podejmuje takie decyzje powinna popatrzeć na nie przez pryzmat tego jakim urzędem jest i do czego powołanym oraz że jej praktyki mogą mieć przełożenie na inne podmioty.

No i kwestia zasadnicza interoperacyjność dotyczy i istniejących systemów i nowo projektowanych. Nie wiem skąd przekonanie, że interoperacyjność dotyczy tylko projektowania systemów?

[Jarek]

Zaczyna nam się to układać w jakąś całość. Myślę, że granicą pomiędzy "migrować" i "nie migrować" jest kwestia ewentualnej konieczności dalszej pracy w starym systemie. Znaczy się - zachowujemy stary system ale w nim już nie pracujemy (nie dodajemy dokumentów itd.).
Jeśli chodzi o zagrożenia i ryzyka - ja się najbardziej boję utraty danych. Do tego jeszcze konieczność zaangażowania sił i środków do migracji, a na dłuższą metę pożytek z przeniesionych danych niewielki. Zaznaczam że mam tu na myśli podobną sytuację jak w NDAP, czyli stary system to system wspomagający. I jeszcze jedna kwestia - czy taki stary system to jest w ogóle system teleinformatyczny, czy może tylko "narzędzie informatyczne"?

Co do interoperacyjności - napisałem "głównie", a nie "tylko".

[Ewap]

Dalsza praca w systemie dotychczasowym nie musi polegać na dodawaniu dokumentów, ale na korzystaniu z tego co tam jest.
By to czynić, trzeba mieć tam konto (być użytkownikiem z odpowiednimi ustawieniami). W związku z tym zwróciłam uwagę na fakt co w sytuacji, gdzie nastąpi fluktuacja kadrowa i "zaginie" wiedza o dotychczasowym systemie i zmienią się użytkownicy?
Istnienie kilku systemów z których jeden będzie bieżący, a drugie quasi archiwalny wydaje się stwarzać większe ryzyko niż migracja.

Każdy informatyk potrafi zaplanować migrację, by "strata" danych była jak najmniejsza. Poza tym nikt nie powiedział, że migracja oznacza "zniknięcie" starego systemu. Problemem jest weryfikacja przed i po migracji.
To samo obecnie dzieje się przy migrowaniu danych z baz danych IZA, SEZAM do bazy ZoSIA...

Myślę jednak, że większa strata danych będzie gdy migracja nie nastąpi a pracować się będzie w kilku systemach, z których tylko bieżący będzie utrzymywany i rozwijany. I znów wracam do tego co będzie w dalszej perspektywie - gdy zmienią się ludzie...?

Do tego jeszcze konieczność zaangażowania sił i środków do migracji, a na dłuższą metę pożytek z przeniesionych danych niewielki.

Nie wiem skąd ten wniosek o niskiej przydatności przeniesionych danych, ale to tak jakby twierdzić, że na bieżąco wprowadzanie tych samych danych też nie przynosi pożytku. Przecież to są dane z których się korzysta.
Zresztą i charakter "wspomagania" systemu jest różny w różnych podmiotach. Za każdym razem trzeba dobrze przeanalizować sytuację kancelaryjną.
Obawiam się że tego właśnie nie zrobiono w NDAP i istnieje realna obawa utraty dokumentów i danych, które istniały tylko w poprzednim systemie a nie na papierze. Bo akurat w NDAP instrukcja kancelaryjna była inna niż te które powstały po 2011 r.

Warto też pamiętać, że to z poprzedniego systemu NDAP generowano paczki archiwalne. Był więc jakiś punkt odniesienia. Pytanie czy z eDOK takie paczki powstają? I co z tymi sprawami i pismami ze starego systemu, z których robiono paczki testowe?

Zaznaczam że mam tu na myśli podobną sytuację jak w NDAP, czyli stary system to system wspomagający. I jeszcze jedna kwestia - czy taki stary system to jest w ogóle system teleinformatyczny, czy może tylko "narzędzie informatyczne"?

Akurat w NDAP był system który mógł być bazą dla EZD. Pytanie tylko czy chciano podnosić jego wersje i go rozwijać oraz zgodzić się na wejście w EZD. Wiemy dobrze, że w administracji rządowej akurat te kwestie zależą od dyrektorów generalnych...

W instrukcyjnym pojęciu "narzędzia" mieszczą się i "wypasione" systemy i zwykłe bazy do rejestracji tego co wpływa i wychodzi. Istotą jest wybór przez podmiot podstawowego systemu dokumentowania przebiegu załatwiania i rozstrzygania spraw. By być w EZD trzeba mieć system klasy EZD, by być tradycyjnym można mieć system klasy EZD, zwykłe bazy, albo nic i dalej pisać w papierowych dziennikach lub spisach spraw...

[Jarek]

Fluktuacja kadrowa? Dotyka wszystkich. Czemu nie martwimy się o zmianę administratora bieżącego systemu? Uprawnień dostępu do starego systemu nie muszą mieć wszyscy, może być przywiązane do konkretnych funkcji czy stanowisk (np. kck).
"... by strata danych była jak najmniejsza ..." - i tu jest pies pogrzebany, bo straty wydają się ryzykiem wpisanym w migrację. Jaki jest na to sposób? Chyba tylko wspomniane dedykowane narzędzie do migracji, dodane do projektowanego systemu. Najgorzej mają ci, którzy teraz sami mierzą się z wyzwaniem zmiany systemu, z koniecznością równoczesnej migracji. Ten kto może zaczekać na aplikacje.gov.pl zdejmie z siebie nie tylko część pracy ale też część ryzyka ...

Jeśli stary system ma tylko wartość rejestrów przesyłek i spisów spraw (które i tak zachowuje się w papierze), to po 2-3 latach prawie się już do tego nie zagląda. Ok, starego systemu nie da się utrzymywać w nieskończoność. Jeśli są tam elektroniczne dokumenty i sprawy to pewnie migracja jest najlepszym sposobem na zapewnienie im przechowywania przez przepisowy czas. Ale jeśli są tylko posiadające wartość pomocniczą rejestry i spisy, to nawet jeśli chcemy je zachować, to niekoniecznie musi to być zaraz migracja. W każdym bądź razie - przynajmniej warto się nad tym zastanowić  .

[Paweł z ...]

Fluktuacja kadrowa? Dotyka wszystkich. Czemu nie martwimy się o zmianę administratora bieżącego systemu? Uprawnień dostępu do starego systemu nie muszą mieć wszyscy, może być przywiązane do konkretnych funkcji czy stanowisk (np. kck).
"... by strata danych była jak najmniejsza ..." - i tu jest pies pogrzebany, bo straty wydają się ryzykiem wpisanym w migrację. Jaki jest na to sposób? Chyba tylko wspomniane dedykowane narzędzie do migracji, dodane do projektowanego systemu. Najgorzej mają ci, którzy teraz sami mierzą się z wyzwaniem zmiany systemu, z koniecznością równoczesnej migracji. Ten kto może zaczekać na aplikacje.gov.pl zdejmie z siebie nie tylko część pracy ale też część ryzyka ...

Jeśli stary system ma tylko wartość rejestrów przesyłek i spisów spraw (które i tak zachowuje się w papierze), to po 2-3 latach prawie się już do tego nie zagląda. Ok, starego systemu nie da się utrzymywać w nieskończoność. Jeśli są tam elektroniczne dokumenty i sprawy to pewnie migracja jest najlepszym sposobem na zapewnienie im przechowywania przez przepisowy czas. Ale jeśli są tylko posiadające wartość pomocniczą rejestry i spisy, to nawet jeśli chcemy je zachować, to niekoniecznie musi to być zaraz migracja. W każdym bądź razie - przynajmniej warto się nad tym zastanowić  .

"by strata danych była jak najmniejsza" - co to oznacza, jaki poziom jest akceptowalny. Mamy najnowszy przykład:
Migracja z PESELu i RDO (Rejestru dowodów Osobistych) w wystąpieniu pokontrolnym NIK strona 12:
Rejestr (moduł SRP), do którego migrowano dane
Liczba rekordów zaimportowanych PESEL 502 061 359 RDO 160 574 941
Liczba rekordów niezaimportowanych PESEL 454 840 RDO 770 032
% rekordów niezaimportowanych PESEL 0,1% RDO 0,5
Nie opisano czy to dużo czy mało.
https://www.nik.gov.pl/kontrole/P/16/006/KAP/

[Anna Laszuk]

"by strata danych była jak najmniejsza" - co to oznacza, jaki poziom jest akceptowalny.

No właśnie, na jaką stratę można sobie pozwolić. Dotyczy to nie tylko EZD. Kilkanaście lat temu uczestniczyłam w seminarium, na którym przedstawiano program OCR, który miał być wykorzystany przy cyfryzacji archiwaliów. Zapewniano, że ma bardzo małą błędowość przy odczycie tekstów rękopiśmiennych. Na moje pytanie, jaki odsetek błędów można dopuścić np. w aktach stanu cywilnego, odpowiedzią było nieme spojrzenie kilku par oczu informatyków.
I choć wydaje się, że ten OCR nie przyczynił się do powstania stwierdzonych przez NIK błędów w systemach z danymi referencyjnymi, to każdy system, także EZD, powinien gwarantować prawdziwość i integralność danych. Nasz przez pewien czas nie zapisywał toku akceptacji projektów dokumentów, ale na szczęście zachowywaliśmy kopie papierowe pism, a system został naprawiony.