prima di automatizzare, bisogna dare senso al lavoro
Ho ritrovato un appunto nel quale avevo annotato una situazione abbastanza comune. Una richiesta applicativa passava dall’apertura all’analisi, poi allo sviluppo e infine alla verifica. Il sistema registrava ogni passaggio e calcolava il tempo medio di completamento.
Dopo qualche settimana, il tempo aumentava. Il cruscotto mostrava il sintomo, però non spiegava la causa. Guardando la sequenza degli eventi, si vedeva che molte richieste tornavano dall’analisi allo sviluppo perché mancava un’approvazione del cliente. Il modello considerava conclusa una fase che, nella pratica, continuava a produrre lavoro.
La prima reazione sarebbe stata aggiungere un controllo o creare un nuovo stato nel flusso. L’appunto mi ha ricordato una cosa che ho imparato lavorando con processi e sistemi: prima di configurare uno strumento bisogna capire quale informazione manca, chi deve fornirla e quale decisione autorizza il passaggio successivo.
Un campo aggiuntivo serve quando qualcuno lo compila, gli attribuisce un significato condiviso e lo consulta nel momento opportuno. Altrimenti resta un altro elemento da riempire, uno dei tanti che rendono il sistema più ordinato soltanto in apparenza.
Lo stesso problema compare nei documenti. Ho aperto più volte cartelle che contenevano una procedura, tre versioni dello stesso requisito, il verbale della riunione che aveva modificato l’obiettivo e un messaggio nel quale qualcuno aveva spiegato l’eccezione. Tutto esisteva. La decisione, però, rimaneva da ricostruire.
In un altro caso, una persona doveva capire perché una consegna fosse stata accettata con una deroga. Il documento di collaudo registrava l’esito. Il verbale conteneva la motivazione. Il ticket conservava la richiesta del cliente. I tre elementi avevano identificativi diversi e non erano collegati. Per trovare la risposta occorreva cercare fra cartelle, messaggi e sistemi.
La difficoltà nasceva dall’organizzazione delle informazioni. Un documento acquista valore quando permette di ricostruire un’azione, un criterio o una scelta. Un collegamento serve quando riduce il lavoro necessario per comprendere il rapporto fra due elementi.
Anche una sequenza precisa di eventi può lasciare aperto il problema del significato. Un sistema può mostrare che una richiesta è stata riaperta cinque volte. Per capire il motivo occorre ancora leggere il requisito, verificare il vincolo tecnico, ricostruire la decisione commerciale o parlare con chi ha seguito il cliente. I dati indicano dove guardare. La comprensione richiede un lavoro ulteriore.
Poi c’è il rischio opposto. Nel tentativo di ordinare tutto, si aggiungono metadati, collegamenti e obblighi di compilazione. Dopo qualche mese nessuno sa più quali elementi siano indispensabili e quali siano rimasti come residui di una configurazione precedente. L’ordine produce un nuovo lavoro di manutenzione.
Per questo, quando mi trovo davanti a un processo o a un sistema informativo, cerco di partire da una domanda precisa: quale decisione devo poter ricostruire? Da quella domanda discendono gli eventi da registrare, i documenti da collegare e le responsabilità da rendere visibili.
Automatizzare viene dopo. Prima bisogna capire che cosa accade davvero e dare un significato alle tracce che il lavoro lascia. Altrimenti si ottiene un sistema più rapido nel produrre risposte che nessuno riesce a spiegare.
Process intelligence: dal codice alla forma, dal controllo alla conoscenza
La conoscenza che cura: architettura informativa come etica relazionale
© Calogero Bonasia. Tutti i diritti riservati. Questa pagina costituisce la versione di riferimento dell’articolo. Le citazioni e gli altri usi previsti dalla legge sono consentiti con l’indicazione del titolo, dell’autore e della fonte. Al di fuori di questi casi, la riproduzione, la pubblicazione, la distribuzione, la traduzione, l’adattamento o qualsiasi altro riutilizzo del testo, anche privo di finalità commerciali, richiedono la preventiva autorizzazione scritta dell’autore.