Provo a focalizzare questa scena. Siamo a metà degli anni ’90, in un ufficio comunale qualsiasi. Due persone, una valigetta e un laptop, si presentano all’ingresso. Vengono da una software house. I seguenti tre giorni sono dedicati alla “scoperta” dei processi dell’ente: moduli fotocopiati, registri fotografati e interviste agli impiegati. Tornano sei mesi dopo con il software: è digitale, innovativo, e promette di semplificare la vita dell’ufficio.
“Abbiamo digitalizzato i vostri processi.” Ed è vero. Ma c’è un problema: i processi sono ormai proprietà del software, e non più dell'ente. Siamo caduti in un errore radicale: cedere la proprietà intellettuale del nostro modello di lavoro.
Il tratto comune e l’errore delle stagioni di informatizzazione
Ci fu un risultato positivo negli anni ’90 e nei primi del 2000: il computer arrivò negli uffici pubblici. Velocemente. Di massa. Funzionava, in fondo.
Il punto debole, però, è durato trent’anni e oggi ne paghiamo il prezzo: l’organizzazione ha perso il controllo dei propri processi. Si è perso il momento in cui i processi venivano modellati. Invece, venivano codificati direttamente nel software. E da allora, processo e software sono diventati praticamente lo stesso concetto.
Il lock-in tecnologico e il lock-in processuale
Il problema non è solo tecnologico, ma concettuale. La perdita più grande non è tanto quella del controllo sul software, quanto la perdita stessa del sapere processuale. Chi oggi vorrebbe cambiare un flusso di lavoro scopre che non sa più come funzionava prima di avere quel software.
Ciò genera un lock-in cognitivo: il problema non è che non possiamo modificare il software, ma che neppure sappiamo più come vorremmo modificare il processo. Il risultato? Software che non soddisfano, processi informali che si sviluppano intorno ai software ufficiali, e una distanza allargata sempre di più tra il processo formale e quello reale.
Il deconto tecnico che si accumula
Tre, quattro, a volte cinque gestionali stratificati. Ciascuno con pezzi di processi, logiche non comunicanti, modelli diversi. E il personale che “sapeva come funzionava” inizia a andare in pensione. Si crea un ecosistema parallelo di Excel, fogli informali, processi non registrati, messaggi informali. Questo è il deconto processuale: un accumulo sempre maggiore di disallineamenti, errori e complicazioni.
Se ci chiediamo perché i nostri processi digitali non funzionano bene, spesso la colpa non è dei software ma dell’approccio alla loro implementazione. Si è privilegiata la realizzazione di un modello digitale senza mai codificare, esplicitamente e in modo condiviso, come effettivamente funzioniamo nel mondo reale.
Un esempio che illustra il problema
Lavorando con enti locali, capita spesso di sentire frasi come: “Ma il processo è nostro?” oppure “Non so descrivere come funziona senza guardare all’interno del software.” Questo non è solo un segnale di dipendenza tecnologica: è un’ammissione di una perdita di autonomia organizzativa fondamentale.
La strada per uscire: i process orchestrator
Tra le nuove opportunità, uno strumento centrale è il process orchestrator. Questi strumenti, come Camunda, Zeebe, Flowable o Temporal, permettono di modellare un processo indipendentemente dal software in cui viene eseguito.
Qual è la differenza con il passato?
- Il processo esiste prima del software.
- Si modella in BPMN 2.0, un linguaggio standard, leggibile e condivisibile.
- L’orchestrator esegue attività umane, chiama API, gestisce decisioni e traccia lo stato del processo.
- Il modello è sempre aggiornabile, testabile, condiviso tra chi lo vive e chi lo supporta tecnologicamente.
Il cambio di paradigma è radicale e potrebbe sembrare tecnico, ma in fondo riguarda qualcosa di molto umano: la possibilità di descrivere con precisione il proprio lavoro, cambiarlo facilmente e condividere questa logica con terzi.
I vantaggi pratici del nuovo approccio
I vantaggi di utilizzare un process orchestrator vanno ben oltre la tecnica. Si tratta di un ritorno della sovranità processuale verso l’ente:
- Il processo torna a essere di proprietà dell’organizzazione, e non del fornitore.
- Si realizza un adattamento rapido alle mutate normative, spesso in settimane invece che in anni.
- Si ha una visione chiara e condivisa del flusso, permettendo migliorie continue e collaborazione strutturata.
- Si elimina la dipendenza assoluta dalla logica di un determinato software.
Il vibe coding e la svolta radicale
Un passo ancora più in avanti, percorribile oggi, è il cosiddetto vibe coding, un termine coniato da Andrej Karpathy, ex direttore del team AI di Tesla. Si tratta di un nuovo modo di lavorare in cui si descrive all’intelligenza artificiale cosa si desidera, si genera il codice necessario, lo si testa, lo si modifica e lo si rilascia. Senza bisogno di una comprensione dettagliata del codice.
Che differenza fa?
Il vecchio loop di sviluppo andava così: problema → analisi → progettazione → programmazione → test → rilascio. Poteva durare mesi, coinvolgere figure separate e generare prodotti non allineati alle esigenze reali.
Con il vibe coding, invece, il creatore del problema lo descrive a una IA, riceve una soluzione funzionante in ore, la testa e la migliora man mano. Questo ha due impatti importanti:
- Chi conosce il problema diventa co-produttore della soluzione.
- Si elimina quasi del tutto la necessità di un passaggio intermedio tecnico, che spesso rappresenta un ostacolo all’innovazione.
Ripensare digitalizzazione e organizzazione
La sfida per la PA oggi non è tanto costruire più software, ma costruire in modo diverso. Non dobbiamo più andare alla ricerca di tool che soddisfano modelli di processi che non abbiamo chiaro. Dobbiamo descrivere con esattezza cosa ci serve, e poi modellarlo in una logica aperta, indipendente e adatta a cambiare.
Il passato ha insegnato che non basta digitalizzare. Si deve trasformare. Si deve pensare prima ai processi, per costruire dopo i software adatti a loro. E oggi abbiamo gli strumenti per farlo: i process orchestrator e la capacità dell’IA di generare codice in base a descrizioni umane.