Nei progetti che funzionano non sparisce il lavoro. Sparisce la parte del lavoro che nessuno rivendica: cercare, ricopiare, controllare a mano.
È un’affermazione che va sostenuta con precisione, non con rassicurazioni. Chi lavora in un ufficio sa distinguere una descrizione realistica da una formula di circostanza, e la differenza determina l’accoglienza del progetto molto più delle sue caratteristiche tecniche.
La distinzione tra compito e ruolo
Un ruolo è composto da compiti. Un istruttore amministrativo raccoglie documenti, verifica requisiti, consulta precedenti, valuta, redige, comunica. Un tecnico dell’assistenza cerca informazioni, diagnostica, interviene, documenta.
L’automazione non agisce sui ruoli. Agisce su singoli compiti, e in genere su quelli con tre caratteristiche: ripetitivi, definiti da regole, senza discrezionalità.
La conseguenza è che un ruolo cambia composizione. Se il quaranta per cento del tempo era assorbito da raccolta e trascrizione e quella quota si riduce, il ruolo non scompare: si concentra sui compiti residui.
Questa concentrazione ha un effetto che va nominato apertamente. Il lavoro residuo è mediamente più impegnativo, perché i casi semplici arrivano già preparati e restano quelli difficili. È un miglioramento in termini di contenuto professionale e un aumento di intensità. Presentarlo solo come alleggerimento è impreciso, e chi fa quel lavoro se ne accorge nel giro di poche settimane.
Che cosa passa alla macchina e che cosa resta
Un elenco concreto vale più di un principio.
Passa alla macchina. La ricerca di un documento in un archivio. La trascrizione di dati da un documento a un sistema. Il controllo formale di completezza rispetto a un elenco definito. Il confronto tra valori presenti in fonti diverse. La classificazione secondo categorie stabilite. La preparazione di una bozza su schema ricorrente. Il recupero di casi analoghi già trattati.
Resta alla persona. La valutazione di merito e la decisione. L’interpretazione di una regola in un caso non previsto. La gestione dell’eccezione. La relazione con il cittadino, il cliente, il collega. L’assunzione di responsabilità formale, che non è delegabile a un sistema. E il riconoscimento che qualcosa non torna, che resta il controllo più efficace di cui un’organizzazione dispone.
La linea non è tecnologica ma di responsabilità: ciò di cui qualcuno deve rispondere resta di quella persona, e il sistema si ferma prima.
Una precisazione onesta. Non tutti i ruoli cambiano nella stessa misura. Un ruolo composto quasi interamente da compiti ripetitivi cambia più profondamente di uno articolato. Dirlo con chiarezza, e affrontare la questione con le persone interessate e con le rappresentanze dove previsto, è preferibile a una formula generica che nessuno crede.
Perché il coinvolgimento degli operatori determina l’adozione
Non per ragioni di clima, ma per tre ragioni operative.
Le regole reali le conoscono loro. La procedura formale e la prassi effettiva divergono quasi sempre, e la divergenza contiene informazione: le eccezioni ricorrenti, i controlli aggiunti nel tempo dopo un errore, i passaggi che si saltano perché inutili. Un sistema progettato sulla procedura formale sbaglia sui casi reali.
Le eccezioni le hanno già catalogate. Chiedere a chi fa quel lavoro quali sono i dieci casi che complicano la giornata produce, in un’ora, l’elenco che altrimenti emergerebbe in sei mesi di esercizio.
Il rifiuto è silenzioso. Un sistema imposto non viene contestato: viene aggirato. Le persone continuano a lavorare come prima e usano lo strumento per le operazioni obbligatorie. Dall’esterno il progetto risulta attivo e non produce alcun effetto.
Il coinvolgimento efficace è specifico: partecipazione alla mappatura del processo, definizione dei casi di prova, validazione dei risultati sul proprio lavoro, canale strutturato per segnalare gli errori. Una comunicazione istituzionale in avvio non produce lo stesso effetto.
Un elemento che facilita l’adozione più di ogni altro: rendere visibile che le segnalazioni producono modifiche. Se un errore segnalato viene corretto e la correzione viene comunicata, il canale resta aperto. Altrimenti si chiude in poche settimane.
La formazione come parte del progetto
Non un modulo conclusivo, ma un’attività che accompagna il rilascio e prosegue.
Deve riguardare tre cose. Che cosa il sistema fa e come si usa, che è la parte più semplice. Che cosa il sistema non fa e dove sbaglia, con esempi reali di errori riscontrati in fase di test: è la parte che genera fiducia, perché un sistema presentato come infallibile perde credibilità al primo errore. E che cosa fare quando l’output è sbagliato: come correggerlo, come segnalarlo, a chi.
La formazione va differenziata per ruolo. Chi usa il sistema, chi lo supervisiona e chi ne risponde hanno bisogno di contenuti diversi.
E va ripetuta. Le persone cambiano, il sistema evolve, e la formazione erogata una volta al rilascio copre solo chi era presente quel giorno.
Che cosa questo approccio non risolve
Non elimina la preoccupazione sull’impatto occupazionale, e non è compito di un fornitore rassicurare su decisioni che competono all’organizzazione. Ciò che è corretto fare è essere espliciti su quali compiti cambiano, e lasciare che l’organizzazione comunichi le proprie scelte.
Non risolve i conflitti organizzativi preesistenti. Un progetto che attraversa uffici in disaccordo li rende visibili.
Non produce adozione dove il processo non è cambiato. Se il flusso di lavoro resta identico e lo strumento si aggiunge, viene percepito come lavoro in più.
E non funziona senza tempo dedicato. Coinvolgimento e formazione richiedono ore delle persone operative, che vanno riconosciute e sottratte al carico ordinario, non aggiunte.
In chiusura
La qualità di un progetto di questo tipo si misura anche da quanto è preciso nel descrivere che cosa cambia per chi lavora. Le formule generiche sull’affiancamento tra persone e tecnologia non convincono nessuno che quel lavoro lo faccia davvero.
Ciò che convince è un elenco: questi compiti passano al sistema, questi restano vostri, questo è ciò che il sistema sbaglia, questo è il canale per segnalarlo.
Se state affrontando un progetto con un impatto rilevante sul lavoro di un ufficio, siamo disponibili a un confronto con il team coinvolto, prima che le scelte tecniche siano state fatte.
