Proviamo a focalizzare questa scena. Siamo a metà degli anni ’90, in un ufficio comunale qualsiasi. Entrano due persone con una valigetta e un laptop che pesa come un mattone. Vengono dalla software house. Passano tre giorni a “studiare” i processi dell’ente: raccolgono i moduli cartacei, fotografano i registri, chiedono a qualche impiegato come funziona il protocollo.
Poi spariscono.
Tornano sei mesi dopo con il software. Il gestionale è pronto. “Vedete? Abbiamo digitalizzato i vostri processi.” Ed è vero: i processi sono lì, dentro il software. Solo che non sono più vostri.
Questo è il momento in cui, senza accorgercene, abbiamo ceduto qualcosa di fondamentale: la proprietà intellettuale dei nostri flussi di lavoro.
Indice degli argomenti
Come il software degli anni ’90 ha scavalcato l’analisi
C’è una cosa che le grandi stagioni di informatizzazione degli anni ’90 e dei primi 2000 hanno fatto bene: hanno portato i computer negli uffici pubblici e privati in modo massivo, rapido, e tutto sommato funzionante.
C’è una cosa che hanno fatto meno bene, e di cui paghiamo ancora oggi il conto: hanno congelato l’analisi dei processi.
Il meccanismo era semplice. Un’organizzazione aveva un problema: troppa carta, troppo tempo, troppi errori. La soluzione era il software. La software house arrivava, “analizzava” il processo, e lo traduceva in database, maschere di input, stampe automatizzate.
Il processo non veniva modellato in modo indipendente dal software. Veniva codificato direttamente nel software. E a quel punto, il processo e il software diventavano la stessa cosa.
Finché funzionava, nessuno se ne accorgeva. Il problema emergeva quando il processo doveva cambiare. Nuova normativa, nuova organizzazione, nuovo dirigente con nuove idee. E allora si scopriva che cambiare il processo significava cambiare il software, o aggiornarlo. E cambiare il software significava pagare la software house: nuove funzioni e nuova formazione. Che conosceva quel codice meglio di chiunque altro.
Benvenuti nel lock-in.
Il lock-in silenzioso: quando il processo diventa proprietà altrui
Il lock-in tecnologico non è una novità. Ne parliamo da decenni. Ma quello che spesso non si dice è che il lock-in più pericoloso non è quello tecnologico: è quello processuale.
Non è tanto il fatto di dipendere da un software specifico. È il fatto di aver perso la mappa del proprio processo. Di non sapere più, con precisione, come funziona davvero il flusso di lavoro dell’ente, perché quella conoscenza si è sedimentata nel database del fornitore, nelle logiche del codice, nelle schermate di un gestionale che nessuno ha più la voglia (o il coraggio) di toccare.
Lavorando con enti locali e amministrazioni pubbliche, mi imbatto regolarmente in questa situazione. “Come funziona questo processo?” “Beh, bisogna chiedere alla ditta che ci gestisce il software.” “Ma il processo è vostro.” “Sì, ma non lo sappiamo descrivere senza aprire il gestionale.” E forse non lo sappiamo descrivere nemmeno aprendo il gestionale.
Questo è il vero lock-in: non tecnico, ma cognitivo. Non siamo prigionieri del software perché non riusciamo a smontarlo tecnicamente. Siamo prigionieri perché abbiamo dimenticato come funzionavamo senza di esso, e non abbiamo mai formalizzato come funzioniamo con esso.
Il risultato, trent’anni dopo, è un panorama di PA e aziende che portano in dote due, tre, quattro gestionali stratificati nel tempo, ciascuno con pezzi di processo al suo interno, spesso non integrati, spesso non documentati, spesso tenuti in vita da persone che “sanno come funziona” e che prima o poi vanno in pensione.
Software che spesso non fanno quello che servirebbe e da qui nasce l’ecosistema Excel: porto i dati fuori dal software così li lavoro come è meglio per me. Al che dovrebbe emergere una domanda: ma se porti i dati fuori per fare report, analisi, valutazioni, integrazione, non è che forse il processo cablato nel software ha qualcosa che non va?
Trent’anni dopo: il processo è ancora là, sepolto sotto strati di software
C’è un paradosso che trovo particolarmente ironico nella digitalizzazione italiana: siamo riusciti a creare un sistema in cui siamo più vincolati dai limiti del software che dai vincoli della legge.
La normativa cambia, i regolamenti si aggiornano, le circolari si susseguono. Ma il software segue i suoi tempi. Che sono i tempi del fornitore, del contratto, del budget disponibile per gli aggiornamenti. E nel frattempo il processo reale, quello che vivono ogni giorno i dipendenti, si adatta in modo informale. Si crea il foglio Excel parallelo. Si manda la mail “informale”. Si tiene il registro cartaceo “per sicurezza”.
Il processo ufficiale (quello del software) e il processo reale (quello della vita quotidiana) si allontanano sempre di più. È una forma di debito tecnico che ha un nome molto più preciso: debito processuale.
E come tutti i debiti, cresce con gli interessi.
La prima via d’uscita: i process orchestrator e il primato del modello
La prima buona notizia è che oggi esiste un approccio radicalmente diverso per costruire software intorno ai processi. Non più: analizzo il processo, lo codifico nel software, il software diventa il processo. Ma: modello il processo in modo esplicito, indipendente dal software, e poi uso un process orchestrator per eseguirlo.
Uno degli strumenti più maturi in questo campo è Camunda.
Un process orchestrator prende un processo modellato in BPMN 2.0 (Business Process Model and Notation, il linguaggio standard per descrivere i flussi di lavoro in modo visuale e formale) e lo esegue attivamente. Coordina i task umani, chiama i servizi esterni, gestisce le decisioni, traccia lo stato di ogni istanza di processo. Non è solo una lavagna: è un motore.
Il cambio di paradigma è sostanziale. Il processo esiste prima del software, e in modo indipendente da esso. Posso disegnare il flusso in BPMN, farlo validare da chi lo vive ogni giorno, modificarlo senza toccare il codice (o toccandone il minimo indispensabile), e avere sempre una rappresentazione leggibile e aggiornata di come funziona la mia organizzazione.
Questo significa che il processo torna a essere patrimonio dell’organizzazione, non del fornitore. Posso cambiare i servizi tecnici che compongono il flusso senza smontare tutto. Posso adattare il processo al cambiamento normativo in settimane, non in anni. Posso fare quello che negli anni ’90 era impossibile: separare la logica del processo dall’implementazione tecnica.
Altri strumenti: non solo Camunda
Camunda non è l’unico strumento di questo tipo. Ci sono Flowable, Temporal, Zeebe (che tra l’altro è il motore cloud-native di Camunda stesso). Il punto non è lo strumento specifico: è il principio. Prima il processo. Il software viene dopo.
La seconda via d’uscita: il vibe coding e la fine del monopolio della programmazione
La seconda via è ancora più radicale, e ha un nome che fino a un anno fa avrebbe fatto alzare un sopracciglio anche agli addetti ai lavori: vibe coding.
Il termine lo ha coniato Andrej Karpathy, ex direttore dell’AI di Tesla e ricercatore di OpenAI, per descrivere un approccio alla programmazione in cui si descrive all’AI quello che si vuole ottenere, si lascia che l’AI generi il codice, si testa il risultato, si aggiusta la descrizione, si ritesta. Senza necessariamente capire riga per riga il codice generato.
Può sembrare approssimativo. In certi contesti lo è. Ma in molti altri rappresenta qualcosa di storicamente significativo: per la prima volta, chi ha il problema può costruire la soluzione senza passare per l’intermediario tecnico.
Il ciclo tradizionale di sviluppo software è questo: problema, analisi dei requisiti, progettazione, programmazione, test, rilascio. E poi, quasi inevitabilmente, si scopre qualcosa che non funziona, e si riparte. Un loop che dura mesi e costa tanto, e in cui la persona che conosce il problema (il funzionario, il responsabile del servizio) è sempre separata dalla persona che costruisce la soluzione (il programmatore, l’analista, la software house).
Con il vibe coding, quella separazione si azzera o si riduce drasticamente. Il funzionario che conosce il processo può descriverlo a un agente AI, ottenere una prima versione funzionante in ore, testarla direttamente, correggerla, affinare. Non serve essere programmatori nel senso classico del termine. Serve saper descrivere il problema con precisione, saper valutare se la soluzione funziona, saper iterare.
Strumenti come Cursor, Replit Agent, Lovable, o gli agenti di sviluppo basati su modelli linguistici avanzati (Codex o Claude Code) stanno rendendo questo approccio accessibile a persone con competenze tecniche di base. Non è fantascienza: è quello che sta succedendo oggi in migliaia di aziende e, timidamente, anche in qualche ente pubblico più coraggioso.
Le due vie a confronto: quale scegliere?
Le due strade non sono necessariamente alternative. Sono complementari, e la scelta dipende dalla complessità del contesto e dagli obiettivi dell’organizzazione.
Il process orchestrator con BPMN è la scelta giusta quando il processo è complesso, coinvolge molti attori, deve integrarsi con sistemi esistenti, e richiede tracciabilità e governance formale. È la strada per le organizzazioni che vogliono costruire un patrimonio di conoscenza processuale duraturo, indipendente dai singoli strumenti tecnici. Ha un costo di adozione: richiede competenze in modellazione BPMN, infrastruttura, e una cultura organizzativa disposta a formalizzare i propri flussi.
Il vibe coding è la scelta giusta quando il problema è circoscritto, la soluzione serve rapidamente, e la persona che ha il problema è disposta a mettersi in gioco come costruttore della soluzione. È la strada per l’innovazione distribuita, per i piccoli strumenti interni, per i proof of concept che dimostrano che qualcosa è possibile prima di investire in soluzioni strutturali.
Quel che accomuna entrambe le strade è il principio di fondo: il processo deve tornare al centro, nelle mani di chi lo vive. Non come slogan nel piano operativo. Come scelta metodologica quotidiana.
Le implicazioni per la PA: governance, competenze, e le trappole da evitare
Per la Pubblica Amministrazione italiana, queste due vie aprono scenari interessanti e qualche trappola concreta da evitare.
Sul fronte delle competenze, entrambi gli approcci richiedono figure nuove, o figure esistenti che crescano in direzioni nuove. Il BPMN non si impara in un pomeriggio, ma non è nemmeno la programmazione: è un linguaggio visuale che un responsabile di processo motivato può imparare a leggere e usare in modo utile in poche settimane. Il vibe coding richiede dimestichezza con i prompt e capacità di valutare il codice generato, non di scriverlo.
Sul fronte della governance, entrambi gli approcci richiedono che l’ente si riprenda la responsabilità dei propri processi. Non è un dettaglio. Significa decidere chi è il proprietario di ciascun processo, chi ha l’autorità di modificarlo, come viene documentato e aggiornato. Sono domande che la PA non ha mai affrontato sistematicamente, perché la risposta implicita era sempre stata “ci pensa la software house”.
Sul fronte dei rischi, il vibe coding in particolare richiede attenzione. Codice generato dall’AI che gestisce dati personali, pratiche amministrative, o flussi contabili deve essere validato, testato, e manutenuto. Non basta che “funzioni” nel senso che produce un output. Deve funzionare nel senso che è corretto, sicuro, conforme, e comprensibile a chi lo deve eventualmente modificare. E la pletora di vibe software deve essere governata per non diventare la nuova selva di excel.
Il rischio del nuovo lock-in
Il rischio concreto è creare una nuova generazione di lock-in: non più nel gestionale della software house, ma nell’agente AI che ha generato il codice che nessuno capisce, con un prompt che nessuno ha conservato. Sarebbe, a modo suo, una storia già vista.
Riprendersi i propri processi: questa è la vera trasformazione digitale
Siamo arrivati a un momento in cui possiamo fare una cosa che non era possibile negli anni ’90: mettere il processo al centro, davvero.
Non come slogan. Non come obiettivo nel piano triennale. Ma come scelta operativa concreta: prima modello il processo, poi scelgo o costruisco lo strumento. Non il contrario.
Questo richiede un cambio di mentalità che è più difficile del cambio tecnologico. Richiede che le organizzazioni investano nell’analisi dei propri flussi prima di comprare software. Richiede che i responsabili di servizio diventino anche responsabili di processo, con la competenza per descriverlo, validarlo e farlo evolvere. Richiede che la formazione non sia solo “come si usa il nuovo gestionale” ma “come funziona il processo che il gestionale supporta”.
L’AI, in questo senso, non è solo uno strumento per fare le cose più velocemente. È un’occasione per fare finalmente le cose nel modo giusto: costruire il software a nostra immagine e somiglianza, invece di adattarci all’immagine e somiglianza di qualcun altro.
Trent’anni fa non avevamo scelta. Oggi sì.
La domanda è se siamo disposti a cogliere questa opportunità.
Partecipa alla community