Rozeta

Proponowany model współpracy

Model pilotażu Rozety dla Mieszkańców

Kontrolowany cykl od jednego pytania operacyjnego przez dane, tryb cienia i odbiór po decyzję stop/go oraz udokumentowane zamknięcie.

Etap 1 — zakres

Jeden problem, jeden kanał, jeden właściciel

Pilotaż powinien odpowiadać na jedno pytanie operacyjne, na przykład czy rekomendacja kategorii pomaga zespołowi poprawnie skierować sprawy z jednej kolejki. Łączenie triażu, głosu, analityki sygnałów i wielu jednostek od pierwszego dnia utrudnia rozpoznanie, co rzeczywiście działa, a co generuje ryzyko.

Karta zakresu wskazuje użytkowników, właściciela decyzji, proces ręczny, punkt wejścia i wyjścia danych oraz funkcje pozostające poza próbą. Rozeta dla Mieszkańców jest projektem KOD.AI sp. z o.o.; opisany model jest propozycją współpracy, a nie informacją o trwającym wdrożeniu miejskim.

  • Jedno zdanie opisujące decyzję lub zadanie, które ma wspierać rozwiązanie.
  • Nazwane role po obu stronach, w tym właściciel procesu, danych, bezpieczeństwa i odbioru.
  • Lista funkcji wyłączonych z pilotażu oraz kanał obsługi sytuacji nietypowych.

Etap 2 — dowody

Dane i linia bazowa są uzgadniane przed wynikiem

Zespół opisuje źródło, okres, jakość, kompletność i ograniczenia danych, a także zasady dostępu, pseudonimizacji, retencji i usunięcia. Próbka musi odpowiadać pytaniu pilotażu; wygodny eksport nie powinien automatycznie stawać się zakresem przetwarzania.

Linia bazowa pokazuje, jak proces działa bez rozwiązania: ile spraw wymaga korekty, jak długo trwa oceniany krok i jakie rodzaje błędów są najważniejsze. Definicje miar i sposób doboru próby należy zamknąć przed analizą, aby nie wybierać po fakcie tylko korzystnych wyników.

  • Protokół danych z właścicielem, zakresem pól, kontrolą jakości i terminem usunięcia.
  • Miary bieżącego procesu wraz ze sposobem pomiaru i znanymi lukami.
  • Uzgodnione przypadki o wysokim koszcie pomyłki oraz wymagany sposób ich obsługi.

Etap 3 — walidacja

Tryb cienia oddziela ocenę od wpływu na mieszkańca

W trybie cienia system generuje rekomendacje, ale nie zmienia kolejki, statusu ani treści sprawy w systemie źródłowym. Uprawnieni operatorzy porównują wyniki z oceną referencyjną, opisują korekty i szukają wzorców błędów między kategoriami, kanałami oraz grupami przypadków.

Szczególną uwagę trzeba poświęcić niepewnym transkrypcjom, rzadkim kategoriom, danym niepełnym i sprawom wymagającym szybkiej eskalacji. Jeżeli konfiguracja, źródło danych lub wymagane połączenie są niedostępne, test powinien zatrzymać daną funkcję i zgłosić brak — bez syntetycznego zastępstwa w ścieżce produkcyjnej.

  • Zakaz automatycznego zapisu do rejestru spraw podczas etapu cienia.
  • Przegląd jakości według kategorii i kosztu błędu, nie wyłącznie jednej średniej.
  • Rejestr wersji, wyjątków, korekt i zmian konfiguracji wprowadzonych w trakcie oceny.

Etap 4 — próba

Odbiór operacyjny sprawdza cały proces, nie tylko model

Po spełnieniu kryteriów jakości można zaplanować ograniczoną próbę operacyjną. Obejmuje ona interfejs operatora, uprawnienia, logi, obsługę niedostępności, przekazanie do człowieka, procedurę wyłączenia i powrót do procesu ręcznego. Każda automatyczna czynność ma zatwierdzony zakres oraz możliwy do odtworzenia zapis.

Użytkownicy procesu powinni przejść scenariusze zwykłe, brzegowe i awaryjne. Gdy pilotaż dotyczy kanału dostępnego dla mieszkańców, test obejmuje także jasność komunikatów, alternatywne drogi kontaktu oraz udział osób o różnych potrzebach. Automatyczne narzędzie audytowe nie zastępuje takiej oceny.

  • Lista scenariuszy odbiorowych podpisana przez właściciela procesu i bezpieczeństwa.
  • Sprawdzona eskalacja do człowieka oraz działający tryb ręczny.
  • Test uprawnień, retencji, odtworzenia, wyłączenia i obsługi incydentu.
  • Instrukcja dla operatorów wyjaśniająca znaczenie wyniku oraz granice użycia.

Etap 5 — decyzja

Kryteria stop/go są zapisane przed uruchomieniem

Decyzja nie powinna zależeć od ogólnego wrażenia z demonstracji. Karta pilotażu określa minimalny poziom jakości dla uzgodnionych kategorii, maksymalny koszt obsługi, wymagania bezpieczeństwa i dostępności oraz błędy, które natychmiast zatrzymują próbę.

Możliwe wyniki to nie tylko „wdrażamy” albo „rezygnujemy”. Zespół może kontynuować w tym samym zakresie, wrócić do trybu cienia, ograniczyć funkcję, zmienić dane albo zakończyć próbę. Każda decyzja wymaga właściciela, dowodów i terminu ponownego przeglądu.

  • STOP: naruszenie zakresu danych, brak wymaganej kontroli lub błąd o niedopuszczalnym wpływie.
  • HOLD: wynik niejednoznaczny, wymagający poprawy danych, procesu albo dodatkowej próby.
  • GO: spełnione kryteria jakości i gotowości dla dokładnie określonego zakresu — nie dla całego przyszłego systemu.

Etap 6 — zamknięcie

Wynik opisuje także ograniczenia i niespełnione warunki

Raport końcowy powinien zawierać pytanie pilotażu, wersje wykorzystanych elementów, zakres i jakość danych, linię bazową, wyniki według wcześniej ustalonych miar, zdarzenia, korekty operatorów oraz obserwacje jakościowe. Osobno zapisuje się ograniczenia próby i przypadki, których nie wolno uogólniać.

Jeżeli dalszy etap nie został zatwierdzony, pilotaż kończy się odebraniem dostępów, zwrotem lub usunięciem danych i potwierdzeniem zamknięcia. Jeżeli został zatwierdzony, potrzebny jest nowy zakres operacyjny, ocena ryzyka i plan utrzymania. Raport pilotażowy nie jest sam w sobie dowodem gotowości do produkcji.

  • Tabela wyników zestawiona z linią bazową i kryteriami zapisanymi przed próbą.
  • Rejestr błędów, incydentów, odstępstw i działań naprawczych.
  • Decyzja wraz z zakresem, właścicielem, warunkami i datą kolejnego przeglądu.
  • Protokół usunięcia danych i odebrania dostępów albo zatwierdzony plan następnego etapu.

Źródła

Podstawa do dalszej oceny

Poniższe materiały są źródłami pierwotnymi. Nie zastępują analizy prawnej, oceny ryzyka ani uzgodnień właściwych dla konkretnego wdrożenia.