Tre scontrini nel cestino: il paradosso del software che non cambia (e l’Ai potrebbe aiutarci)
Commentidi Francesco Marozzo*
Ci sono episodi apparentemente banali che raccontano molto più di quanto sembri. Durante un periodo all’estero alloggiavo in un grande albergo. All’ingresso della sala colazioni, una dipendente chiedeva il numero della stanza, verificava sul computer che il servizio fosse incluso e avviava una piccola stampante. La macchina produceva tre scontrini identici: uno veniva consegnato al cliente, gli altri due finivano nel cestino sistemato sotto la stampante. La scena si ripeteva centinaia di volte ogni giorno.
Quel cestino mi colpì più degli scontrini. Sembrava parte integrante della procedura: qualcuno aveva osservato quella sequenza e aveva concluso che la soluzione più pratica fosse rendere più comodo gettare la carta inutile. Quando chiesi perché venissero stampate tre copie se due erano destinate al cestino, la risposta fu immediata: “Così funziona il sistema”.
Non era la dipendente a scegliere quella procedura. Era il software a imporla. Le persone avevano semplicemente imparato ad adattarsi.
Forse, quando quel programma era stato progettato e acquistato, stampare tre copie aveva un senso. Una poteva servire alla cucina, una alla cassa e una al cliente. Nel frattempo, però, l’organizzazione era cambiata, mentre il software era rimasto uguale. Modificarlo sarebbe costato troppo o avrebbe richiesto l’intervento di qualcuno capace di comprendere un sistema sviluppato anni prima. Così era diventato più semplice continuare a stampare carta inutile. Ma questo episodio non riguarda soltanto un albergo. Riguarda la pubblica amministrazione, le aziende, la scuola, l’università, le banche e la sanità. Riguarda tutti quei casi in cui ci viene chiesto di rispettare vincoli arbitrari, ripetere informazioni già disponibili, seguire sequenze rigide o adottare accorgimenti particolari soltanto per evitare un errore. E quando l’errore arriva senza spiegazioni, non resta che contattare l’assistenza o ricominciare da capo. Quando si domanda il motivo, la risposta cambia poco: “Il programma funziona così”.
Negli ultimi decenni abbiamo digitalizzato quasi ogni attività, ottenendo vantaggi enormi. In altri casi, però, abbiamo trasformato vecchie rigidità burocratiche in nuove rigidità informatiche, oppure le abbiamo sommate. Il software dovrebbe adattarsi ai processi delle persone. Sempre più spesso, invece, sono le persone a dover adattare il proprio lavoro ai suoi limiti.
Sviluppare un programma rappresenta soltanto una parte del suo costo. Gran parte della spesa riguarda la manutenzione: correggere errori, aggiornare il sistema e adattarlo ai cambiamenti organizzativi. Il codice dovrebbe essere comprensibile, documentato e modificabile. Nella realtà, molti sistemi accumulano per anni correzioni, eccezioni e stratificazioni, fino a rendere costoso e rischioso anche un cambiamento minimo.
In altri casi, l’organizzazione dipende dal fornitore che ha sviluppato il sistema: ogni modifica richiede il suo intervento, con costi e tempi difficili da controllare. Quando il software diventa troppo rigido, spesso lo si abbandona per commissionarne uno nuovo a un’altra azienda, avviando un ciclo che rischia di produrre gli stessi problemi.
È così che una soluzione inefficiente può diventare la scelta più conveniente. Può costare meno buttare migliaia di scontrini che correggere una funzione del programma. Ma la carta è soltanto la parte visibile del problema. Gli sprechi più grandi sono le ore di lavoro perse, le procedure inutilmente complesse, i dati inseriti più volte e la frustrazione di utenti e dipendenti.
Il problema non è la digitalizzazione in sé. Nasce quando il software diventa tanto rigido da costringere il mondo reale ad adattarsi ai suoi limiti. Con moduli cartacei o documenti digitali più liberi era spesso possibile annotare un’eccezione o descrivere un caso particolare. Un’applicazione, invece, consente soltanto ciò che chi l’ha progettata ha previsto. Se manca un campo, un’opzione o un percorso alternativo, l’utente deve attenersi alla struttura del programma.
L’intelligenza artificiale generativa potrebbe cambiare proprio questo aspetto. I modelli linguistici sono già in grado di leggere il codice, spiegarlo, individuare errori, suggerire modifiche e generare test. Non scriveranno software perfetti e non elimineranno la necessità degli ingegneri. Potrebbero però ridurre il costo delle piccole modifiche oggi continuamente rimandate.
Un dipendente potrebbe descrivere il problema nel linguaggio di tutti i giorni: “Per la colazione vengono stampati tre scontrini, ma ne serve soltanto uno”. Un sistema basato sull’intelligenza artificiale potrebbe individuare il punto interessato, proporre una soluzione e applicare la modifica. Sarebbe un cambiamento utile: non soltanto sistemi più potenti, ma software più facili da adattare alle esigenze delle organizzazioni e delle persone. L’intelligenza artificiale potrebbe contribuire soprattutto a ridurre la distanza tra chi usa un programma e chi lo sviluppa, rendendo più semplici modifiche che oggi vengono rimandate o considerate troppo costose. Non risolverebbe ogni problema, ma potrebbe aiutare a evitare che siano sempre le persone a doversi adattare ai limiti del sistema.
* professore associato di Ingegneria informatica presso l’Università della Calabria
