Come decidiamo se un sistema funziona
Immaginiamo di essere a una riunione sul nuovo gestionale. Il responsabile informatico mostra il rapporto: le schermate rispondono più velocemente, gli errori di inserimento diminuiscono, le richieste di assistenza vengono chiuse nei tempi previsti.
Dal tavolo arriva un’obiezione: per completare alcune pratiche bisogna ancora copiare i dati in un foglio di calcolo, scrivere a un collega e aspettare una conferma. Il programma è più veloce, d’accordo. Chi lavora continua però a fare la spola fra tre finestre e una casella di posta.
Nessuno sta falsificando i dati. Il responsabile informatico misura le prestazioni dell’applicazione; il collega descrive quello che deve fare per arrivare in fondo a una pratica. Nel rapporto compaiono i tempi del software.
Una parte del tempo delle persone rimane fuori, distribuita fra messaggi, trascrizioni e controlli che il gestionale non registra. Finché guardiamo soltanto quel rapporto, possiamo scambiare il miglioramento di un passaggio per il miglioramento dell’intero lavoro.
Susan Leigh Star e Anselm Strauss hanno studiato proprio questo scarto. Nel loro articolo «Layers of Silence, Arenas of Voice», pubblicato nel 1999, osservano che nessun lavoro è visibile o invisibile in sé: diventa visibile attraverso gli indicatori scelti e attraverso il punto di vista dal quale lo si osserva.
Il rapporto del gestionale rende visibili i tempi di risposta e gli errori registrati. Le attese, i messaggi e il controllo delle richieste sospese restano sullo sfondo, benché rendano possibile il risultato che il rapporto presenta.
Proviamo allora a farci mostrare una delle pratiche di cui si discute. Nel nostro esempio, una richiesta presenta un’eccezione: per autorizzarla serve una conferma che l’applicazione non permette di registrare. L’operatore manda un messaggio al collega competente, annota la richiesta nel foglio di calcolo e la lascia in attesa.
Quando arriva la risposta, torna nel gestionale e completa l’operazione. Il risultato è corretto. Per ottenerlo, però, qualcuno deve ricordarsi di controllare la posta, ritrovare la riga giusta e riportare l’esito nel sistema.
Quel foglio, che nella presentazione del progetto probabilmente non merita neppure una diapositiva, tiene insieme i passaggi. Basta provare a toglierlo per capire che cosa fa: chi segue la pratica perde il promemoria delle richieste in sospeso e deve ricostruirle fra i messaggi. Il gestionale continua a rispondere in una frazione di secondo. La pratica aspetta che una persona rimetta insieme i pezzi.
La ricerca sui sistemi informativi chiama workaround questo genere di soluzione: una deviazione introdotta per superare un ostacolo, un’eccezione o un limite del sistema. Steven Alter, nella «Theory of Workarounds», pubblicata nel 2014, mostra che il workaround non è automaticamente un errore da cancellare.
Può segnalare un adattamento intelligente, un difetto di progettazione o una regola che non riesce a seguire il lavoro reale. Il foglio di calcolo non dimostra da solo che il gestionale sia stato progettato male; dimostra che, per alcune pratiche, il lavoro comprende anche un passaggio che il gestionale non rappresenta.
A questo punto dire che «la qualità del lavoro peggiora» è ancora una conclusione affrettata. L’operatore può consegnare un risultato impeccabile proprio perché compensa ogni giorno quel limite. Se contiamo soltanto le pratiche concluse e gli errori registrati, vediamo il risultato e perdiamo di vista il lavoro che lo rende possibile. Potremmo perfino attribuire al nuovo sistema il merito di ciò che le persone riescono a ottenere aggirandolo.
L’equivoco nasce quando, nella riunione, diciamo di voler «migliorare il servizio» senza aver deciso che cosa debba migliorare. Per chi progetta e amministra l’applicazione, il miglioramento prende la forma di tempi di risposta più brevi e disponibilità costante.
Per chi segue le pratiche, significa attraversare il percorso con meno passaggi, meno attese e meno occasioni di perdere un’informazione. La stessa parola raccoglie aspettative diverse e le porta al tavolo come se fossero già confrontabili.
Durante la riunione emergono nuovamente, ciascuna accompagnata dalle proprie prove: da una parte il rapporto, dall’altra la sequenza di operazioni sulla scrivania. Possiamo passare un pomeriggio a discutere se il sistema funzioni, perché stiamo usando una sola parola per formulare giudizi su cose differenti.
Una guida del Service Manual del governo britannico propone di partire dallo scopo del servizio, definire i risultati attesi e scegliere le misure in base alle domande che si vogliono esaminare.
La stessa guida raccomanda di affiancare i dati di performance alla ricerca sugli utenti e di dare un contesto ai numeri. La raccomandazione è semplice, ma cambia il punto di osservazione: prima di chiedere quanto rapidamente risponde una schermata, bisogna sapere quale compito il servizio deve permettere di concludere e con quale costo per le persone coinvolte.
Adottare questa pratica ci consente di definire meglio il disaccordo. Ora abbiamo la certezza che il tempo di risposta dell’applicazione è migliorato e che la gestione delle eccezioni richiede interventi esterni.
Possiamo quindi indagare su quante richieste seguono questo percorso, quanta fatica comportano e quali sono le conseguenze in caso di assenza della persona che solitamente se ne occupa. La protesta iniziale si trasforma in un problema verificabile.
Anche gli amministratori di sistema hanno finalmente un punto di partenza concreto per le loro indagini, oltre alla vaga sensazione che «qui non funziona niente».
Le eccezioni meritano attenzione perché i sistemi tendono a descrivere bene il flusso ordinario e a lasciare in ombra le variazioni.
Etiam capillus unus habet umbram suam: anche un solo capello ha la sua ombra.
Una deviazione che sembra minima può rivelare un passaggio, una dipendenza o un costo che il flusso principale nasconde.
Gli studi di Wil van der Aalst sul process mining mostrano come i registri degli eventi possano essere usati per confrontare il processo modellato con quello effettivamente osservato. La tecnica è utile quando il sistema registra gli eventi necessari. Nel nostro caso, però, una parte della pratica avviene nella posta e nel foglio di calcolo: il registro dell’applicazione non può descrivere da solo l’intero percorso.
La tecnica è utile quando il sistema registra gli eventi necessari. Nel nostro caso, però, una parte della pratica avviene nella posta e nel foglio di calcolo: il registro dell’applicazione non può descrivere da solo l’intero percorso.
Questo passaggio richiede ascolto, e l’ascolto richiede la disponibilità a esaminare qualcosa che il rapporto iniziale non contiene. Se chiediamo all’operatore soltanto quale schermata dia errore, possiamo chiudere la segnalazione senza trovare un difetto: ogni schermata esegue correttamente la propria funzione.
La difficoltà si presenta fra un’operazione e l’altra, quando bisogna cercare una conferma, aspettarla e ricordarsi di riprendere il lavoro. Per comprenderla dobbiamo lasciare che la persona racconti il percorso completo, anche quando esce dai confini del programma di cui siamo responsabili.
Il Service Manual suggerisce infatti di misurare il percorso dall’inizio alla fine e di usare, accanto agli indicatori, osservazione, feedback, costi e tassi di completamento.
Una pratica può concludersi senza errori e richiedere comunque un lavoro eccessivo. Il tempo trascorso fuori dal sistema non è un dettaglio laterale: può determinare il costo effettivo del servizio e la sua dipendenza dalla memoria di una persona.
Ascoltare quel racconto non obbliga ad accettare la prima soluzione proposta. L’operatore può chiedere di eliminare la conferma per procedere più rapidamente. Chi autorizza le richieste può spiegare che quel controllo impedisce operazioni errate.
Il passaggio aggiuntivo ha dunque una funzione da preservare. La ricostruzione ci permette però di separare il controllo dal modo macchinoso in cui lo eseguiamo: una cosa è verificare l’eccezione, un’altra è affidare il ricordo delle richieste pendenti a un foglio separato e alla memoria di chi lo consulta.
La ricerca sui workflow affronta da tempo questo problema. In «Exception handling in workflow management systems», gli autori descrivono le eccezioni come una difficoltà strutturale dei sistemi che distribuiscono il lavoro fra programmi e persone.
Un processo può essere rappresentato con precisione nelle condizioni ordinarie e diventare fragile quando deve sospendere un’attività, attendere un’autorizzazione o riprendere il percorso dopo una variazione. L’eccezione non è soltanto un incidente: è un punto nel quale il progetto del flusso incontra la varietà del lavoro.
La discussione arriva così a una scelta concreta. Possiamo valutare come registrare nel gestionale la richiesta di autorizzazione, renderne visibile l’attesa e comunicare l’esito a chi deve proseguire. La modifica costa; anche le operazioni manuali ripetute ogni giorno hanno un costo. Il primo compare in un preventivo e chiede un’approvazione.
Il secondo si presenta a piccoli pezzi, qualche minuto alla volta, e può continuare per mesi senza che nessuno lo metta sullo stesso tavolo. Prima di decidere che la modifica è troppo cara, occorre almeno confrontare le due spese.
Il confronto può portare anche a conservare la procedura attuale: le eccezioni sono rare, la modifica richiede un investimento sproporzionato o ci sono interventi più urgenti.
In quel caso chi decide si assume la responsabilità del lavoro aggiuntivo e dei rischi che comporta.
Chi presenta la segnalazione riceve una spiegazione, conosce il motivo della scelta e sa quali cambiamenti possono giustificare un nuovo esame. Lasciare tutto com’è diventa una decisione riconoscibile, della quale si possono verificare le conseguenze.
Torniamo alla riunione. Il rapporto sulle prestazioni resta sul tavolo, ma ora accanto c’è anche il percorso di quella pratica, comprese le attese, i messaggi e il foglio di calcolo. I numeri iniziali conservano il loro valore; cambia ciò che possiamo concluderne.
Quando diciamo che il sistema funziona, sappiamo quali passaggi gestisce l’applicazione e quali richiedono alle persone di organizzarsi altrove. E se scegliamo di continuare a usare quel foglio, nella valutazione del servizio dobbiamo contare anche il tempo di chi, ogni giorno, lo tiene aggiornato.