Prendo spunto da un interessante post di un amico a proposito della natura e degli obiettivi nella progettazione di prodotti software moderni ed evoluti.
Dopo aver distinto tra la complessità del software dal punto di vista delle competenze tecniche necessarie per essere capaci di impiegarlo e la complessità dovuta alla necessità di conoscere il processo applicativo che il software sottende, Giuseppe conclude:
“Mentre possiamo fare molto per semplificare l’aspetto tecnico, non possiamo rendere un processo intuitivo a chi non lo conosce già. Perché l’intuizione può derivare solo da un’esperienza precedente”
La mia esperienza dice che la seconda parte della sua conclusione non è necessariamente vera.
Dal mio punto di vista, l’unica condizione indispensabile perché una persona possa utilizzare con soddisfazione ed efficacia un prodotto software e quella di avere sufficientemente chiara l’esigenza alla quale il software risponde o, ancora meglio, una motivazione sufficiente per scegliere di utilizzarlo.
Abbiamo necessariamente bisogno di conoscere il processo e le regole che sottendono alla presentazione della dichiarazione dei redditi per poterla compilare con un software? Se guardiamo all’esperienza che possiamo fare oggi con i prodotti software diffusi, la risposta tende ad essere affermativa; ma siamo proprio sicuri che non si possa costruire un software efficace, progettato per interagire con un utente che non sa nulla della normativa fiscale italiana? In fondo se una persona può rispondere a richieste di informazioni che gli vengono proposte da un consulente fiscale perché non si può immaginare che possa interagire in modo analogo (anzi migliore, più pro-attivo) con un sistema software?
Nel concreto ho visto realizzarsi questo tipo di risultato nel progetto Babel che stiamo portando in produzione con l’Azienda AUSL di Bologna.
Fino a ieri la formalizzazione e l’avvio di una comunicazione dell’Ente protocollata era un processo delegato a specialisti che, con software applicativi mediamente astrusi traducevano le intenzioni di un loro dirigente in una comunicazione a norma.
Oggi, con il nuovo sistema che sta entrando in produzione, chiunque può abbozzare una lettera di protocollo in uscita specificando il minimo essenziale: il contenuto proposto e i destinatari.
Il sistema, conoscendo le logiche di processo, gli organigrammi dell’azienda, le deleghe di responsabilità e i diversi possibili recapiti dei destinatari, si fa carico di:
- validare contestualmente le richieste del richiedente;
- proporre dei possibili firmatari per questa comunicazione;
- fare fluire, anche in parallelo, la bozza di lettera in uscita verso i diversi attori che debbono avere un ruolo nel processo;
- spedire in via elettronica la comunicazione (se è nota la PEC o l’email del destinatario) o sottoporre ad un ufficio delegato la richiesta di produzione della stampa da imbustare, bollare e consegnare ad un vettore postale.
Ad ogni attore viene chiesto il minimo indispensabile strettamente inerente al suo ruolo nel processo. Ogni attore, se vuole, può monitorare l’avanzamento del processo nella sua interezza.
Potenzialmente nessuno degli attori potrebbe avere conoscenza di tutti i passaggi e delle formalità necessarie per spedire quella lettera. Potrebbe essere che nessuno ha la piena consapevolezza applicativa di cosa significhi produrre un protocollo in uscita formalmente corretto.
Il risultato è garantito dal processo codificato nel software che, in definitiva, è garante della completezza e correttezza del processo applicativo.
Ora per le persone della AUSL di Bologna produrre una comunicazione di protocollo in uscita è semplice come inviare una email!
