London Ambulance Service wdrożył system dyspozytorski, który zakładał bardziej uporządkowany świat, niż istniał naprawdę
W 1992 r. London Ambulance Service uruchomił nowy computer-aided dispatch system. W dniach 26–27 października system poważnie zawiódł, a po kolejnych problemach 4 listopada służba wróciła do pełnego trybu ręcznego. Późniejsze dochodzenie wskazywało serię błędów we wdrożeniu, nie pojedynczy bug: zbyt szybkie uruchomienie, niedostateczne testy, problemy organizacyjne, przeciążenie i błędne założenia o jakości danych oraz zachowaniu załóg. To klasyczny przypadek socio-technical failure — system informatyczny musi działać z realnymi ludźmi i realnym chaosem, nie tylko w teście laboratoryjnym.
CAD miał zautomatyzować bardzo złożony proces
Telefon alarmowy trzeba zlokalizować, sklasyfikować, dobrać wolną karetkę, przesłać zadanie i śledzić status pojazdu. Każdy etap zależy od aktualnych danych i działań ludzi w terenie. System może działać szybko tylko wtedy, gdy stan świata zapisany w bazie jest wystarczająco zgodny z rzeczywistością.
Testy komponentów nie wystarczyły
Parlamentarne odpowiedzi z epoki potwierdzają, że komponenty testowano na danych testowych, ale produkcyjne uruchomienie ujawniło problemy całego procesu. System end-to-end obejmował nie tylko serwer i terminale, lecz również radio, procedury dyspozytorów, sposób zgłaszania statusu i zachowania załóg.
Błędne dane wzmacniały przeciążenie
Jeśli status karetki był nieaktualny, system mógł przydzielać zasoby niezgodnie z realną sytuacją. Niewłaściwe przydziały wymagały ręcznych interwencji, co zwiększało obciążenie centrali i pogarszało jakość kolejnych danych. Powstawała pętla pozytywnego sprzężenia zwrotnego.
Tempo wdrożenia było częścią problemu
Po dochodzeniu minister informowała parlament, że raport wskazał serię błędów po wszystkich stronach, w dużej mierze związaną z tempem instalacji nowego systemu. Techniczna gotowość nie może być oceniana niezależnie od szkolenia i gotowości organizacji.
Fallback do procesu ręcznego uratował możliwość działania
Po kolejnych problemach LAS powróciło do ręcznego dispatchu. To pokazuje wartość degraded mode. Automatyzacja systemu krytycznego powinna pozostawiać ścieżkę pracy, gdy centralny system jest niedostępny.
Największe systemy IT są częścią organizacji
Nie można naprawić projektu wyłącznie przez „lepszy kod”, jeśli błędne są procedury, role i model rzeczywistości. London Ambulance Service stało się klasycznym studium tego, że software engineering i organizational engineering są w systemach krytycznych nierozerwalne. Po udanym pilotażu warto też prowadzić phased rollout. Mała część obszaru może ujawnić błędy procesu bez ryzyka, że cała organizacja jednocześnie utraci stary sposób pracy. Big-bang deployment jest szczególnie niebezpieczny tam, gdzie fallback wymaga ponownego przeszkolenia personelu.
Automatyzacja może wzmacniać błędy danych szybciej niż człowiek jest w stanie je skorygować
W procesie ręcznym dyspozytor widzi mapę, słyszy radio i może zauważyć, że informacja „karetka wolna” nie pasuje do rozmowy z załogą. System automatyczny skaluje decyzje na podstawie stanu w bazie. Jeśli stan jest błędny, ta sama wydajność, która miała przyspieszyć dispatch, może szybko wygenerować wiele niewłaściwych przydziałów. Ludzie zaczynają wtedy obchodzić system, dzwonić dodatkowo, wpisywać korekty i wykonywać pracę równoległą. To jeszcze bardziej zwiększa rozbieżność pomiędzy bazą a rzeczywistością. Tak powstaje vicious cycle typowy dla nieudanych wdrożeń enterprise. Projekt powinien więc zakładać reconciliation: sposób szybkiego wykrycia, że model cyfrowy odjechał od fizycznego świata, oraz możliwość ręcznego przejęcia kontroli bez tworzenia jeszcze większego chaosu. Dlatego udane wdrożenia systemów dispatchowych często zaczynają się od obserwacji pracy użytkowników, a nie od samego modelu danych. Program musi odzwierciedlać wyjątki, skróty i presję czasu, które istnieją w realnym centrum operacyjnym. Najlepszym testem przed pełnym wdrożeniem jest więc praca równoległa: nowy system podejmuje decyzje, ale stary proces nadal działa jako punkt porównania. Różnice można analizować zanim automatyzacja stanie się jedyną drogą operacyjną.