Sprawa wpłynęła do organizacji, ale osoba pytająca o jej stan trafia do kolejnych pracowników. Każdy zna swój fragment, a całość trzeba odtworzyć z rejestru, dokumentów i wiadomości. Aplikacja dla organizacji publicznej powinna pomóc utrzymać ciągłość od przyjęcia do odpowiedzi. Nie wystarczy zamienić papierowy formularz na ekran, jeśli odpowiedzialność za następny krok nadal pozostaje domysłem. Cyfrowy dokument również potrafi utknąć między biurkami, tylko mniej go widać.
Projekt wymaga rozpoznania konkretnego zadania, obowiązujących procedur i odpowiedzialności instytucji. Nie wszystkie sprawy można obsłużyć według tego samego schematu. Zespół techniczny powinien otrzymać jasny zakres tego, co aplikacja ma wspierać, oraz wymagania, które muszą zostać zweryfikowane przez odpowiedzialne osoby. Ten tekst dotyczy sposobu projektowania obiegu, a nie zastępuje ustalenia prawidłowego trybu prowadzenia konkretnego postępowania czy realizacji obowiązku.
Formularz ma pomóc dostarczyć właściwe informacje
Zacznijcie od danych potrzebnych do wykonania zadania. Użytkownik powinien rozumieć nazwy pól, wymagane załączniki i informację o błędzie. Jeśli system odrzuca formularz, potrzebna jest wskazówka, co poprawić, bez kasowania całej wcześniejszej pracy. Warto też jasno pokazać, czy sprawa została przyjęta oraz jak można ją później odnaleźć. Niepewność w tym miejscu łatwo prowadzi do ponownego zgłoszenia lub dodatkowego telefonu.
Pomocny jest test prototypu z osobami o różnym doświadczeniu w obsłudze narzędzi. Osobno trzeba sprawdzić dostępność gotowej aplikacji. Materiały W3C dotyczące WCAG pomagają uporządkować kryteria, na przykład obsługę klawiaturą i etykiety pól. Właściwy zakres wymagań należy ustalić dla danego projektu. Automatyczny wynik testu nie zastępuje sprawdzenia, czy użytkownik potrafi rzeczywiście ukończyć zadanie.
Przydział sprawy powinien prowadzić do rozpoznawalnej roli
Po przyjęciu sprawa potrzebuje właściciela, statusu i informacji o następnym kroku. Warto ustalić sposób przekazania, zastępstwa oraz cofnięcia materiału do uzupełnienia. Osoba przejmująca zadanie powinna znać jego historię i otwarte pytania. Nie musi otrzymać wszystkich praw administracyjnych. Podział dostępu powinien odpowiadać rzeczywistej odpowiedzialności, a zmiana właściciela nie powinna po cichu usuwać wcześniejszych ustaleń. Odrębny proces może dotyczyć prowadzenia projektów w organizacji społecznej. Pokazujemy go w artykule o zadaniach i rozliczeniach organizacji społecznej.
Jeżeli aplikacja współpracuje z istniejącym rejestrem, potrzebne jest uzgodnienie źródła danych. Trzeba odróżnić numer widoczny dla użytkownika, techniczny identyfikator i ewentualne oznaczenia innych systemów. W przeciwnym razie pracownik może widzieć podobne sprawy, ale nie wiedzieć, czy dotyczą tego samego zgłoszenia. Integracja ma ograniczać ponowne przepisywanie, a jednocześnie zostawiać możliwość wyjaśnienia rozbieżności przez uprawnioną osobę.
Historia ma wyjaśniać działanie, nie mnożyć wpisy
Przy istotnych czynnościach warto zapisać, co zostało wykonane, przez kogo i na jakim materiale. Odbiorca zewnętrzny nie musi widzieć wszystkich notatek wewnętrznych. Potrzebuje natomiast informacji zgodnej z uzgodnionym etapem i sposobem kontaktu. Dobrze rozdzielić widok obsługi oraz komunikację na zewnątrz, zamiast bezpośrednio publikować każdy wewnętrzny status. Technicznie proste rozwiązanie nie zawsze daje czytelną informację osobie, która nie zna słownika instytucji.
Jeżeli projekt przewiduje wyszukiwanie w dokumentach z pomocą AI, trzeba uwzględnić uprawnienia także w tym obiegu. W tekście o RAG i dostępie do dokumentów opisujemy tę zależność szerzej. Narzędzie pomocnicze nie powinno ujawniać informacji tylko dlatego, że zostały dołączone do wspólnej bazy wiedzy. Granice widoczności i źródła odpowiedzi wymagają uzgodnienia tak samo jak dostęp do zwykłych plików oraz rejestrów.
Odbiór obejmuje użytkownika i późniejszego operatora
Przed startem przejdźcie scenariusze odbiorowe dla przyjęcia, uzupełnienia, przekazania i zakończenia sprawy. Sprawdźcie błędne dane, różne role i przerwę w połączeniu, jeśli wpływa na proces. Ważne jest też przekazanie systemu do utrzymania: konta, dokumentacja, procedury oraz sposób zgłoszenia problemu. Instytucja potrzebuje działającego wydania i możliwości dalszej obsługi narzędzia.
W próbie warto uwzględnić osobę zastępującą właściciela sprawy. Powinna umieć odnaleźć otwarte zadanie i rozpoznać, czego brakuje do kolejnego kroku. Jeżeli musi odtworzyć całą historię w rozmowie z nieobecnym pracownikiem, aplikacja nie dostarcza jeszcze wystarczającego kontekstu. W ten sposób można sprawdzić, czy zapisy w aplikacji pozwalają kontynuować zadanie bez dodatkowych wyjaśnień poza systemem.
Archifutura pomaga projektować aplikacje dla organizacji i sektora publicznego w uzgodnionym zakresie. Na rozmowę o obiegu spraw przygotuj przykład, który niedawno wymagał kilku przekazań. Pokaż, gdzie znajdowały się dokumenty i kto odpowiadał na pytania o status. Z takiego materiału można wyprowadzić wymagania dla formularza, ról i historii. To lepszy początek niż cyfryzowanie każdego istniejącego pola bez sprawdzenia, jaką pracę ma ono umożliwiać.
Źródła i dokumentacja
Materiały sprawdzone przy opracowaniu tekstu. Przy wyborze usługi lub technologii potwierdzamy warunki dla konkretnego projektu.
