Da dove viene il BPR.
Nel 1993 Michael Hammer e James Champy pubblicano Reengineering the Corporation e sintetizzano l'idea in una frase diventata celebre: "Don't automate, obliterate." Non ottimizzare il processo esistente, non automatizzarlo, non aggiungerci sopra un layer tecnologico. Ricominciare da zero, partendo dalla domanda fondamentale: se dovessimo costruire questa azienda oggi, sapendo quello che sappiamo, come organizzeremmo il lavoro?
Il BPR non è miglioramento incrementale. È riprogettazione radicale. L'obiettivo dichiarato sono miglioramenti nell'ordine del 70-80% su costo, qualità, velocità o servizio — non il 10-15% tipico dell'ottimizzazione ordinaria. Uno dei casi studio più citati è Ford Motor Company che, riprogettando il processo di accounts payable, riduce il personale dedicato da 500 a 125 persone — non licenziando, ma eliminando il processo ridondante e ridisegnando il flusso attorno ai dati, non ai documenti.
La tecnologia nel BPR è abilitatore, non punto di partenza. Questo è il punto che spesso viene frainteso — e che nell'Approccio Reframe abbiamo fatto nostro: non si compra il software e poi ci si adatta, si ridisegna il processo e poi si sceglie lo strumento che lo supporta.
Il BPR nel privato: cosa funziona e cosa no.
Il BPR ha avuto un successo enorme negli anni Novanta — e una percentuale di fallimenti altrettanto imponente. Le stime variano, ma la maggior parte degli studi indica che tra il 50% e il 70% dei progetti BPR non raggiunge gli obiettivi dichiarati. La ragione più comune non è tecnica: è organizzativa.
Riprogettare un processo significa cambiare chi fa cosa, come lo fa, e spesso con chi collabora. Significa eliminare ruoli, fondere funzioni, rompere silos che esistono da decenni e che sono presidiati da persone con interessi legittimi a mantenerli. La tecnologia si implementa in settimane. Le persone cambiano in anni.
Il secondo pattern di fallimento è quello che ho descritto in un articolo dedicato alla digital transformation: si compra la tecnologia pensando che risolva il problema organizzativo. Si automatizza il processo vecchio invece di riprogettarlo. Il risultato è un processo difettoso che gira più velocemente — che è peggio.
"Un processo difettoso automatizzato è un processo difettoso che gira più velocemente. Il BPR esiste per evitare esattamente questo."
Il POR: stessa filosofia, contesto radicalmente diverso.
La Public Organization Reengineering applica i principi del BPR alla pubblica amministrazione. L'ambizione è la stessa: non rattoppare i processi esistenti, ma ripensarli da zero in funzione del cittadino — che nel contesto pubblico sostituisce il "cliente" del settore privato.
In Italia questo filone si concretizza nel Piano Triennale per l'Informatica nella PA, nei progetti AGID, in SPID, nel Fascicolo Sanitario Elettronico, nel PagoPA. Progetti che, guardati dall'esterno, sembrano semplici integrazioni tecnologiche ma che nascondono — o dovrebbero nascondere — una riprogettazione profonda di come lo Stato interagisce con il cittadino.
Il problema è che il contesto pubblico introduce vincoli che nel privato non esistono, o esistono in misura molto minore.
Cosa condividono e cosa li distingue.
- Punto di partenza: mappare il processo reale, non quello dichiarato
- Obiettivo: riprogettazione radicale, non miglioramento incrementale
- Tecnologia come abilitatore, non come driver
- Necessità di sponsorship al vertice per sopravvivere alla resistenza interna
- Pattern di fallimento quasi identici: change management sottovalutato, automazione del processo vecchio
- Obiettivo finale: profitto vs servizio al cittadino
- Velocità: il privato si muove in mesi, il pubblico in anni o decenni
- Vincoli normativi: il codice degli appalti, la trasparenza, i contratti collettivi nazionali
- Misurazione del successo: ROI vs efficienza percepita vs soddisfazione del cittadino
- Continuità: i cicli politici interrompono i progetti prima che producano risultati
- Procurement: il fornitore si sceglie con gara pubblica, non per competenza dimostrata
Quest'ultimo punto merita attenzione. Nel privato, chi commissiona un progetto di reengineering sceglie il fornitore sulla base di competenza, track record, allineamento culturale. Nel pubblico, la gara d'appalto obbliga a criteri formali — prezzo, requisiti tecnici dichiarati, certificazioni — che non sempre correlano con la capacità reale di accompagnare una trasformazione organizzativa complessa. È un tema che ho affrontato parlando di grandi software house e grandi progetti: la dimensione del fornitore non garantisce la qualità del risultato.
Il problema del processo che nessuno ha scritto.
Sia nel BPR che nel POR, il primo ostacolo è sempre lo stesso: il processo reale non corrisponde al processo dichiarato. Le organizzazioni — pubbliche e private — hanno una versione ufficiale di come funzionano le cose, scritta nei manuali e nelle procedure, e una versione operativa fatta di workaround, accordi informali, eccezioni che nel tempo sono diventate la regola.
Ne ho parlato in modo specifico a proposito del fenomeno Excel: quando il software ufficiale non regge la complessità del lavoro reale, le persone costruiscono soluzioni parallele. Quelle soluzioni — per quanto informali — contengono know-how prezioso sul processo reale. Un progetto BPR o POR che le ignora non sta riprogettando il processo: sta costruendo sopra un'immagine inesistente di come l'organizzazione funziona.
Prima di qualsiasi progetto di reengineering — pubblico o privato — c'è una domanda che vale la pena porre esplicitamente: "Come funziona questo processo quando qualcosa va storto?" Le eccezioni rivelano il processo reale. Le procedure rivelano solo come si vorrebbe che funzionasse.
La risposta a quella domanda è il punto di partenza. Non il diagramma di flusso ufficiale.
Perché vale la pena conoscerli entrambi.
BPR e POR non sono metodologie per specialisti. Sono framework concettuali utili a chiunque si trovi — nel privato o nel pubblico — a dover giustificare la scelta di cambiare radicalmente invece di rattoppare. Danno un nome a qualcosa che spesso si fa in modo implicito, e un linguaggio condiviso con cui parlarne con chi deve approvarlo.
La differenza pratica più importante tra i due contesti non è metodologica. È di ritmo. Nel privato, se un progetto di reengineering non produce risultati visibili in 12-18 mesi, viene abbandonato. Nel pubblico, i risultati di un progetto avviato oggi potrebbero non essere visibili prima del mandato successivo — di un'altra amministrazione, con altre priorità. Questa discontinuità è il vero avversario del POR. Non la burocrazia, non la tecnologia, non la resistenza al cambiamento. La politica del breve termine applicata a trasformazioni che per loro natura sono lunghe.