Jak zinformatyzować administrację publiczną

Na forum projektu e-PUAP, prowadzonego przez MSWiA, opublikowano do zaopiniowania trzy dokumenty:

  1. Zasady tworzenia wyróżników
  2. Zasady tworzenia jednolitych identyfikatorów
  3. Zasady nazewnictwa elementów dokumentów elektronicznych

Po pobieżnym zapoznaniu się rzuca się w oczy niekonsekwencja Ministerstwa, objawiająca się między innymi nie dostosowaniem omówionych aktów prawnych do rozporządzenia określającego wymagania techniczne formatów zapisu i nośników materiałów przekazywanych do archiwum. Niezależnie od tego, czy istnieje formalny obowiązek stosowania się do tego rozporządzenia, należałoby bowiem dążyć do zapewnienia maksymalnej spójności różnych przepisów, by nie tworzyć niepotrzebnych, nadmiarowych bytów i umożliwić tak zwaną interoperacyjność.

Interoperacyjność

Interoperacyjność można zdefiniować jako zdolność dwóch różnych systemów (na przykład programów komputerowych) do porozumiewania się między sobą. Nie muszą być to systemy, służące do tego samego celu. Przykładowo aplikacja zainstalowana w urzędzie gminy powinna umieć porozumieć się z oprogramowaniem obsługującym archiwa państwowe.

Jedynym sposobem na zrealizowanie tego celu jest opracowanie spójnych, jednolitych protokołów komunikacji. Zarówno system gminy, jak i archiwów, muszą mówić jednym językiem. Oczywiście można zatrudnić tłumacza, który będzie odpowiadał za tłumaczenie języka urzędowego na język archiwalny - ale, jak wszystkim doskonale wiadomo, tłumacze są drodzy i nie za bardzo się to opłaca. Szczególnie, jeśli można niemalże za darmo wymusić, by oba te systemy rozumiały się bez pośrednictwa tłumacza - a z taką sytuacją mamy obecnie do czynienia w projekcie e-PUAP.

Przypomina się tutaj stara zasada, że poprawienie błędu na etapie projektowania kosztuje 10 zł, a po wdrożeniu systemu - nawet całe miliony. W chwili obecnej jesteśmy właśnie na etapie projektowania systemu e-PUAP i należy dołożyć wszelkich starań, by wykonać go najlepiej, jak potrafimy - i zaoszczędzić w ten sposób dużo problemów i pieniędzy.

Cele strategiczne

W dokumencie inicjującym projekt zdefiniowano dość dużo celów projektu e-PUAP. W mojej opinii tego typu podejście i próba załatwienia kilku zupełnie różnych problemów od razu stanowi dość duże ryzyko dla powodzenia projektu. Co więcej, powoduje ograniczenie konkurencji na rynku komercyjnym - większość zdefiniowanych tam usług mogłaby bowiem z powodzeniem zostać przygotowana z wykorzystaniem normalnych mechanizmów wolnego rynku. Przykładowo, na dzień dzisiejszy mamy na rynku co najmniej kilka podmiotów, świadczących usługi obsługi płatności w Internecie. Usługi te są z powodzeniem wykorzystywane przez świat biznesu - nie widzę więc powodów, dla których nie miałyby zostać wykorzystane też przez administrację publiczną. Oczywiście potrzebne są tutaj odpowiednie przepisy - i to powinna być rola MSWiA: zamiast wydawać publiczne pieniądze na realizację wielkich projektów powinno skupić się na aktywizowaniu zarówno biznesu, jak i administracji, do budowania odpowiednich systemów lokalnie. Zauważmy, że w ten sposób najaktywniejsze urzędy przetrą szlaki i pozwolą utworzyć ramową implementację systemu, która później - na zasadach wolnorynkowych - będzie mogła być zakupiona (już po niższych cenach, jako wykorzystanie wcześniej wdrożonej implementacji) przez inne urzędy.

Do działania takiego schematu wymagane jest zapewnienie interoperacyjności między różnymi implementacjami. I to właśnie powinien być główny cel strategiczny - określenie, jak dokładnie mają wyglądać dokumenty elektroniczne i jakie powinny być protokoły ich wymiany. Zauważmy, że wszystko, co jest potrzebne do wdrożenia e-Państwa, zostało już stworzone. Mamy protokoły wymiany wiadomości (jak SMTP lub SOAP), sposoby zapisu danych (XML), standardy metadanych (dublin core, format Archiwów Państwowych). Wystarczy jedynie spiąć to wszystko w jeden mechanizm, określić precyzyjne wytyczne implementacyjne (schematy xsd, definicje WSDL) i wymusić stosowanie się do tego przez urzędy (a więc i firmy, które dla nich tworzą oprogramowanie). Najprostszy schemat tak skonstruowanego, wolnorynkowego "systemu e-PUAP" mógłby składać się z następujących komponentów:

  1. Schematu XSD, zawierającego wytyczne odnośnie ogólnej struktury dokumentów elektronicznych, wraz z precyzyjnym zdefiniowaniem najczęściej występujących metadanych - tak, by nikt nie miał wątpliwości, gdzie w dokumencie znajdują się dane typu nazwisko czy imię jego autora, oraz by zapewnić możliwość bezproblemowego automatycznego ich przetwarzania;
  2. Wytycznych dotyczących dołączania do dokumentu załączników;
  3. Schematu XSD dokumentu poświadczenia odbioru, odsyłanego w odpowiedzi na przekazany dokument;
  4. Precyzyjnej definicji (XSD) formatu podpisu elektronicznego, który musi być wykorzystywany w dokumentach elektronicznych, wraz z określeniem rodzaju tego podpisu (wewnętrzny, zewnętrzny) oraz informacji, które mają być podpisane (np. cały dokument oraz załączniki zewnętrzne);
  5. Definicji protokołu komunikacyjnego (dla SOAP - WSDL, dla SMTP - odniesienie do RFC i informacja o sposobie nazywania poszczególnych części wiadomości i sposobie podpisywania/szyfrowania przesyłanych danych) wraz z pełnym opisem żądania, służącego do przekazania dokumentu do adresata, oraz udzielanej odpowiedzi na pismo - zarówno w przypadku powodzenia, jak i błędu przetwarzania;
  6. Bazy schematów XSD dokumentów elektronicznych najczęściej występujących w administracji, zarówno centralnej, jak i lokalnej, z zastrzeżeniem, że można tworzyć własne dokumenty tylko w przypadku, gdy w systemie centralnym nie opublikowano jeszcze odpowiedniego wzoru;
  7. Centralnego słownika organów administracji publicznej, który udostępniał by lokalizację sieciową każdego urzędu akceptującego dokumenty elektroniczne (np. adresy e-mail albo URL do odpowiednich web services).

Wskazane informacje powinny wystarczyć do zinterenetyzowania polskiej administracji. Problemem nie jest bowiem brak projektu e-PUAP, ale brak ustalonych standardów komunikacji. Można twierdzić, że tego typu rozwiązanie spowoduje zbyt duże koszty - ale tak naprawdę wdrożenie systemu centralnego także spowoduje koszty w administracji lokalnej. A jeśli kierownik urzędu wyda "własne" pieniądze na system, to jest większe prawdopodobieństwo, że - po pierwsze - będzie on odpowiadał jego potrzebom, a po drugie - będzie przez ten urząd intensywnie wykorzystywany.

Komentarze

Witam,

wspolnie z pozostałymi studentami prawa realizujemy pod okiem doktorantki Wydziału Prawa na UWr projekt e-administacja. Do moich zadań należy przygotowanie zagadnień z zakresu AKT ELEKTRONICZNYCH w postępowaniu administracyjnym. Szczerze mówiąc cięzko cokolwiek znaleźć na ten temat. W związku z tym zwracam się z prośbą o udzielenie wskazówek, lub odesłania do źródeł na ten temat.

Pozdrawiam serdecznie
Filip Cłapka

Generalnie problem jest złożony. Na chwilę obecną w praktyce wymagane jest prowadzenie dokumentacji w formie dualnej: papierowo i elektronicznie. e-PUAP jako taki niestety w żaden sposób nie rozwiązuje problemów zarządzania dokumentacją w administracji. Jest to jedynie interfejs wejściowy do urzędu.

Nie jestem ekspertem prawnym, ale mogę wskazać kilka wątków, którym należy się przyjrzeć.

Przede wszystkim istotna jest ustawa o narodowym zasobie archiwalnym i archiwach, a dokładniej - dwa załączniki do niej. Proponuję też dokładnie przejrzeć zawartość serwisu Naczelnej Dyrekcji Archiwów Państwowych. Temat był też lekko poruszony w czasie ostatniej konferencji ePUAP narzędziem nowoczesnej administracji - organizatorzy obiecali, że opublikują materiały z prelekcji, ale póki co tego nie zrobili.

Ciekawym bez wątpienia źródłem może być też serwis http://prawo.vagla.pl.

Dodaj komentarz

Markdown

  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.

Filtered HTML

  • Adresy internetowe są automatycznie zamieniane w odnośniki, które można kliknąć.
  • Dozwolone znaczniki HTML: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <small>
  • Znaki końca linii i akapitu dodawane są automatycznie.

Plain text

  • Znaczniki HTML niedozwolone.
  • Adresy internetowe są automatycznie zamieniane w odnośniki, które można kliknąć.
  • Znaki końca linii i akapitu dodawane są automatycznie.
CAPTCHA
Proszę, przepisz napis z obrazka do okienka poniżej. Sprawdzamy w ten sposób, czy nie jesteś aby robotem. Wielkość znaków ma znaczenie!
By submitting this form, you accept the Mollom privacy policy.