Mieszkaniec, który chce załatwić sprawę w urzędzie, porównuje ten kontakt nie z innym urzędem, tylko z bankiem i sklepem internetowym. Oczekuje, że wniosek złoży z telefonu, o dowolnej porze, i że zobaczy, na jakim etapie jest jego sprawa. Dlatego portal obywatela i e-usługi publiczne przestały być dodatkiem do urzędu, a stały się jego pierwszym okienkiem, często jedynym, które mieszkaniec w ogóle odwiedzi.
Z naszego doświadczenia najtrudniejszą częścią takiego projektu nie jest sam formularz, tylko to, co dzieje się po jego wysłaniu: walidacja, obieg sprawy, statusy, integracje i rygor dostępności oraz bezpieczeństwa. Nie przypisujemy sobie wdrożenia gotowego portalu obywatela, natomiast wspieraliśmy instytucje publiczne inżyniersko i wiemy, jak taki system zaprojektować oraz obsadzić ludźmi, którzy go napiszą i utrzymają.
Czego dziś oczekuje obywatel od e-usług publicznych?
Poprzeczkę ustawiają aplikacje komercyjne, więc mieszkaniec zakłada, że sprawę urzędową da się załatwić w całości online i że nie będzie musiał niczego drukować ani donosić osobiście. Ta zmiana oczekiwań przekłada się na kilka twardych wymagań wobec systemu:
- dostęp z telefonu jako wariant domyślny, a nie wersja zastępcza strony desktopowej,
- jeden punkt wejścia do wielu spraw, zamiast osobnego portalu dla każdego wydziału,
- przejrzysty status, czyli jasna informacja, co się dzieje z wnioskiem i czego urząd jeszcze potrzebuje,
- minimum ponownego wpisywania danych, które urząd już ma.
Jeżeli którykolwiek z tych punktów zawodzi, mieszkaniec wraca do okienka, a cały sens cyfryzacji się rozmywa.
Jak zaprojektować portal obywatela i e-formularze?
Portal obywatela to w praktyce ustrukturyzowany katalog spraw, a nie zbiór luźnych podstron. Każda e-usługa powinna prowadzić mieszkańca krok po kroku, pilnować kompletności danych jeszcze przed wysyłką i nie dopuszczać do złożenia wniosku, który i tak wróci do poprawy.
Samą warstwę e-formularzy projektujemy wokół walidacji po stronie przeglądarki i serwera: pola sprawdzane są na bieżąco, a reguły biznesowe (na przykład zależności między polami czy wymagane załączniki) egzekwuje backend. Tam, gdzie prawo wymaga potwierdzenia tożsamości lub podpisania wniosku, system integruje się z uwierzytelnianiem i podpisem elektronicznym (ogólnie: profil zaufany, e-dowód, podpis kwalifikowany), zamiast budować własny, niepewny mechanizm. Formularz zapisuje też wersje robocze, żeby mieszkaniec mógł dokończyć wniosek później, a dane raz wprowadzone były podstawiane w kolejnych krokach.
Jak działa zarządzanie sprawami i statusy wniosków?
Wysłany formularz zamienia się w sprawę z własnym cyklem życia. To tutaj rozstrzyga się, czy cyfryzacja realnie odciąży urząd, czy tylko przeniesie papier na ekran. Dobrze zaprojektowany moduł spraw prowadzi wniosek od złożenia, przez weryfikację i ewentualne wezwanie do uzupełnienia, aż po decyzję, i każdy z tych kroków odkłada ślad widoczny zarówno dla urzędnika, jak i dla obywatela.
Dla mieszkańca kluczowy jest czytelny status i historia sprawy: co już zrobił urząd, czego oczekuje od wnioskodawcy i w jakim terminie. Dla urzędu równie ważny jest obieg wewnętrzny, czyli przydział spraw, kolejki, terminy i integracja z systemem EOD oraz systemami dziedzinowymi. Projektujemy go tak, aby statusy pokazywane obywatelowi wynikały wprost ze stanu sprawy w systemie, a nie były aktualizowane ręcznie.
Jak dodać rezerwację wizyt do e-usług?
Nie każdą sprawę da się domknąć zdalnie, więc rezerwacja wizyty online jest naturalnym elementem portalu, a nie osobnym narzędziem. Spinamy ją z kalendarzem urzędu i z konkretną sprawą, tak aby mieszkaniec rezerwował termin do właściwego stanowiska i od razu wiedział, jakie dokumenty przynieść.
Dobrze zrobiony moduł rezerwacji skraca kolejki, rozkłada ruch w czasie i ogranicza liczbę nieodebranych wizyt dzięki przypomnieniom. Istotne są tu detale, które decydują o użyteczności:
- dostępność terminów liczona z realnej obsady stanowisk, a nie wpisywana ręcznie,
- powiązanie wizyty ze sprawą, żeby urzędnik był przygotowany przed spotkaniem,
- łatwe odwołanie i zmiana terminu, które zwalniają miejsce dla innych.
Jak zbudować powiadomienia e-mail i SMS dla mieszkańców?
System, który nie informuje, zmusza obywatela do ciągłego logowania „na wszelki wypadek”. Dlatego powiadomienia e-mail i SMS traktujemy jako część obsługi sprawy: wysyłamy je przy zmianie statusu, przy wezwaniu do uzupełnienia i przed zarezerwowaną wizytą. Budujemy je na kolejkach i szablonach, z rejestrem wysyłek, obsługą błędów i ponawianiem, oraz z poszanowaniem zgód i zasad przetwarzania danych. Treść powiadomienia zawsze odsyła do sprawy w portalu, zamiast przenosić dane wrażliwe do wiadomości.
Dlaczego dostępność (WCAG) jest wymogiem, a nie dodatkiem?
W sektorze publicznym dostępność cyfrowa zgodna z WCAG to obowiązek prawny, a nie miły dodatek na koniec projektu. Portal musi działać z czytnikiem ekranu, z samej klawiatury i przy powiększonym tekście, a kontrast i struktura nagłówków muszą być poprawne od początku. Dostępność wpinamy więc już na etapie projektu interfejsu i pilnujemy jej w trakcie developmentu, bo doszywanie jej na końcu zwykle oznacza przepisywanie komponentów.
Jak zadbać o bezpieczeństwo i tożsamość w portalu obywatela?
Portal przetwarza dane osobowe i decyzje administracyjne, więc bezpieczeństwo i zarządzanie tożsamością są fundamentem, a nie warstwą kosmetyczną. Opieramy uwierzytelnianie o sprawdzone standardy (na przykład OpenID Connect) i krajowe węzły tożsamości, zamiast utrzymywać własne hasła tam, gdzie nie trzeba. Do tego dochodzą kontrola dostępu oparta na rolach, szyfrowanie danych w tranzycie i w spoczynku, pełne logi audytowe oraz zgodność z RODO i wymogami KRI. Takie rzeczy projektuje się od początku, bo dołożenie ich później jest kosztowne i ryzykowne.
Jakie kompetencje dostarczamy do projektu e-usług?
Tu zaczyna się nasza realna rola. Nawet jeśli nie firmujemy gotowego portalu obywatela, dostarczamy ludzi, którzy takie systemy projektują, piszą i utrzymują, i obsadzamy role pod konkretną specyfikację projektu:
- architekta rozwiązania, który spina portal, obieg spraw i integracje,
- programistów backendu i frontendu do e-formularzy, modułu spraw i powiadomień,
- specjalistę od integracji z węzłami tożsamości, EOD i systemami dziedzinowymi,
- eksperta dostępności i QA, który pilnuje WCAG i jakości,
- DevOps, który buduje wdrożenia, środowiska i monitoring.
Skład dobieramy pod zakres, a kompetencje weryfikujemy przed startem, zamiast obsadzać projekt „na zapas”.
Jak robimy to w RITS?
Działamy jako partner nearshore z Polski, który uzupełnia zespół instytucji o brakujące kompetencje, a nie zastępuje jej odpowiedzialności. Mamy doświadczenie we wsparciu inżynierskim instytucji publicznej i w budowie systemów transakcyjnych, w których liczą się obieg danych, bezpieczeństwo i integracje. Pracujemy w Twojej strefie czasowej, wchodzimy w przeglądy kodu i spotkania bez długiego rozruchu, a zespół rozwijamy pod zarządem klienta. Najczęściej robimy to jako dedykowane oprogramowanie budowane przez nasz zespół albo jako wzmocnienie zespołu, gdy kompetencje trzeba uzupełnić szybko. Jak dobrać między tymi wariantami, opisaliśmy w artykule o modelach współpracy IT.
Od czego zacząć budowę e-usług dla obywatela?
Zacznij od jednej, najczęściej składanej sprawy i przejdź ją od końca, czyli od tego, jak wygląda jej obsługa w urzędzie i jakie systemy musi dotknąć. To wyznaczy zakres e-formularza, model obiegu, zestaw integracji i role, których potrzebujesz. Pierwsza dobrze domknięta e-usługa, z walidacją, statusami, powiadomieniami i dostępnością, staje się wzorcem, który powielasz na kolejne sprawy, zamiast budować dziesięć niespójnych portali.
Budujesz portal obywatela lub e-usługi publiczne? Porozmawiajmy, dobierzemy zespół i architekturę pod Twoją instytucję.