La prima ondata di business process reengineering fallì per una ragione onesta: la tecnologia dell'epoca non poteva mantenere ciò che la teoria prometteva. Nel 1993 un'azienda poteva ridisegnare un processo su una lavagna, ma i sistemi sottostanti erano rigidi, vincolati al batch e difficili da integrare, cosicché la riprogettazione o si arenava al confine del mainframe oppure degenerava in un esercizio di taglio dei costi travestito nel linguaggio della trasformazione. L'idea era valida e gli strumenti no, e le due cose sono state ricordate insieme.

Quel vincolo si è in gran parte dissolto. Le API sono oggi un'aspettativa standard anziché un progetto su misura. Event streaming, piattaforme dati in cloud e motori di orchestrazione rendono fattibile comporre un processo che gira attraverso più sistemi di registrazione senza trasportare a mano i dati tra l'uno e l'altro. Ciò che un tempo era un'integrazione eroica è oggi ordinaria ingegneria. La conseguenza è che la domanda sul reengineering, a lungo rinviata perché troppo costosa a cui rispondere, è tornata trattabile, e nella maggior parte delle organizzazioni ritorna sotto altri nomi: riprogettazione dell'order-to-cash, onboarding dei clienti, resilienza dell'approvvigionamento, accelerazione della chiusura contabile.

La tentazione di rinviare la domanda sul reengineering è comprensibile e non è più sicura. Per anni la scelta razionale è stata attendere, perché il costo di integrazione di qualsiasi riprogettazione seria superava il beneficio, e le aziende accumulavano soluzioni tampone nella fiduciosa aspettativa che sarebbero state risolte dal prossimo aggiornamento di sistema. Raramente lo sono state. Ogni aggiornamento preservava la vecchia forma del processo perché migrare la forma costava meno che metterla in discussione, e la progettazione accidentale si irrigidiva in apparente permanenza. Ciò che è cambiato è che i concorrenti che invece pongono la domanda possono ora agire sulla risposta, e un processo che richiede il doppio del tempo o costa il doppio non è più nascosto dal fatto che tutti gli altri sono ugualmente lenti.

C'è una seconda ragione per cui la domanda conta oggi. Tre decenni di adozione di software aziendale hanno lasciato la maggior parte delle grandi aziende con un CRM che modella il cliente, un ERP che modella la transazione e la finanza, e una suite di supply chain che modella materiali e capacità, ciascuno configurato da una funzione diversa in un momento diverso secondo una logica diversa. I processi che creano realmente valore, prendere un ordine ed evaderlo, acquisire un cliente e servirlo, pianificare l'approvvigionamento rispetto alla domanda reale, attraversano diritti tutti e tre. L'organizzazione è disposta per funzione; il lavoro è disposto per flusso; e il divario tra i due è dove si accumulano costi, ritardi ed errori. Il reengineering è la disciplina che colma quel divario deliberatamente anziché mascherarlo con fogli di calcolo e buona volontà.

L'intuizione fondativa del reengineering, e tuttora quella che fa il lavoro maggiore, è che un'impresa è descritta più fedelmente dai suoi processi che dal suo organigramma. Un'azienda incentrata sulle funzioni ottimizza ciascun reparto rispetto ai propri obiettivi: le vendite massimizzano gli ordini acquisiti, le operations minimizzano il costo unitario, la finanza protegge il capitale circolante. Ciascuno è localmente razionale e la somma è spesso globalmente scadente, perché i passaggi di consegne tra le funzioni, dove il cliente in realtà attende, non appartengono a nessuno. Un'azienda incentrata sui processi rovescia questa logica. Nomina i flussi end-to-end che contano, assegna a ciascuno un responsabile con reale autorità attraverso le linee funzionali, e misura il flusso nel suo insieme: tempo trascorso, resa al primo passaggio, costo per servire, conversione del contante.

Da ciò discende una domanda preliminare rigorosa, alla quale insistiamo di rispondere prima che inizi qualsiasi riprogettazione: reingegnerizzare o migliorare in modo incrementale? Le due cose non sono intercambiabili, e confonderle è costoso in entrambe le direzioni. Il miglioramento incrementale è la scelta corretta quando un processo è fondamentalmente sano e semplicemente incrostato di sprechi; qui gli strumenti del lean e del miglioramento continuo ripagano rapidamente e senza rischi. Il reengineering è giustificato solo quando il processo incorpora assunzioni che non valgono più, quando la sequenza di passi esiste a causa di un vincolo nel frattempo scomparso, oppure quando il risultato desiderato è irraggiungibile con qualsiasi quantità di messa a punto del progetto esistente. Il criterio che applichiamo è netto. Se non avreste potuto arrivare a questo processo progettando per il risultato di oggi da un foglio bianco, è un candidato alla riprogettazione. Se avreste potuto, è un candidato al miglioramento.

Il terzo principio è che un processo che abbraccia CRM, SCM ed ERP non può essere riprogettato in uno solo di essi. L'anagrafica clienti, l'anagrafica prodotti, la logica di prezzo e lo stato dell'ordine sono fatti condivisi che risiedono, in modo ridondante e spesso incoerente, in tutti e tre i sistemi. Una vera riprogettazione deve decidere dove ciascun fatto viene creato, come si propaga e quale sistema è affidabile quando i dati divergono. È per questo che trattiamo dati e integrazione non come una preoccupazione implementativa a valle ma come la sostanza stessa della progettazione. Il modello di processo e il modello dei dati sono due viste della stessa cosa, e uno sforzo di reengineering che produce bei diagrammi di processo e lascia irrisolta la titolarità dei dati non ha in realtà reingegnerizzato nulla.

Un quarto principio sorregge gli altri tre: un processo, un sistema e un'organizzazione non sono tre cose da allineare ma una sola cosa vista da tre angolazioni. Quando vengono trattati come flussi di lavoro separati con governance separata, ciascuno ottimizza per il proprio completamento, e si incontrano al go-live in reciproca contraddizione. Il sistema impone un flusso che l'organizzazione non è dimensionata a sostenere, su dati che il processo assumeva puliti. Progettarli come un'unica decisione è più impegnativo intellettualmente e assai meno costoso nella pratica, perché le contraddizioni si trovano sulla carta anziché in produzione.

Il campo si sta muovendo, e non sempre nella direzione che i fornitori pubblicizzano. Vale la pena nominare chiaramente alcuni schemi, perché cambiano il modo in cui una riprogettazione dovrebbe essere affrontata.

Componibilità anziché monolite. L'assunzione che un'unica suite ERP debba possedere la maggior parte del processo sta cedendo il passo a un'architettura di sistemi specializzati uniti dall'integrazione. Il livello di engagement del cliente, il motore di pianificazione, il core finanziario e i sistemi di evasione sono sempre più distinti, scelti per i loro meriti e composti in un flusso. Ciò è liberatorio per la progettazione dei processi, perché non si è più vincolati all'opinione di un unico fornitore su come dovrebbe funzionare l'order-to-cash, ma sposta la difficoltà nel livello di integrazione e governance, che ora porta la coerenza che il monolite forniva un tempo.

Il process mining come evidenza. Per gran parte della sua storia il reengineering è iniziato con workshop in cui le persone descrivevano come credevano funzionasse il processo, il che era immancabilmente una finzione. Il process mining ricostruisce il processo reale a partire dai log degli eventi che i sistemi già emettono, mostrando ogni variante, ciclo di rilavorazione e scorciatoia così come effettivamente accadono. Consideriamo ormai avviare una riprogettazione senza questa evidenza come qualcosa di prossimo alla negligenza. Sostituisce l'opinione con una baseline misurata e, in seguito, fornisce lo strumento che indica se la riprogettazione si comporta come previsto in produzione.

Il cloud ERP e la realtà a due livelli. Il passaggio al cloud ERP viene spesso venduto come l'occasione per tornare a processi standard e abbandonare anni di personalizzazioni, e per il lavoro genuinamente comune è un buon consiglio. Ma lo stesso passaggio si irrigidisce di frequente in un panorama a due livelli, un core standardizzato circondato dai sistemi specializzati che portano l'effettiva distintività di un'azienda. La domanda progettuale non è quindi se personalizzare ma dove la distintività risiede legittimamente, mantenendo il core vicino allo standard pur consentendo alla periferia di differire, e integrando i due deliberatamente anziché per caso.

L'automazione che passa dal compito al processo. La prima generazione di automazione, in particolare la robotic process automation, per lo più imitava un essere umano che clicca attraverso le schermate, il che consolidava il processo esistente anziché riprogettarlo. Lo schema oggi più utile è automatizzare il flusso riprogettato a livello di processo, usando orchestrazione e integrazione nativa, e riservare l'automazione a livello di schermata ai casi limite genuini in cui non esiste alcuna interfaccia. Automatizzare un cattivo processo permette solo di eseguirlo più velocemente.

Un processo reingegnerizzato vale solo quanto l'architettura che lo sostiene. Alcuni principi di progettazione separano le riprogettazioni che reggono da quelle che silenziosamente regrediscono.

Un'unica fonte di verità per fatto, non per sistema. L'istinto di dichiarare un sistema padrone di ogni cosa è tanto sbagliato quanto non avere alcun padrone. La disciplina è più fine: per ciascuna entità e attributo significativo, nominare esattamente un sistema che lo crea, e lasciare che gli altri si abbonino. Il CRM può possedere la relazione con il cliente mentre l'ERP possiede il conto legale e la posizione creditizia; ciò che conta è che la titolarità sia esplicita, condivisa e imposta, così che la riconciliazione smetta di essere un rituale mensile.

L'integrazione come contratto, non come connessione. Le interfacce punto a punto costruite in fretta diventano la parte più fragile del panorama dei sistemi, perché ciascuna codifica assunzioni che nessuno ha messo per iscritto. Progettiamo l'integrazione come contratti versionati con eventi, payload e semantica definiti, mediati attraverso un livello che può assorbire il cambiamento su entrambi i lati. L'obiettivo è che un sistema possa essere sostituito dietro il suo contratto senza che ogni vicino debba saperlo.

Progettare il processo affinché sia osservabile. Un processo che non può essere misurato in corso d'opera non può essere gestito, e la maggior parte non lo può. Costruiamo il flusso riprogettato in modo che il suo stato, le sue tempistiche e le sue eccezioni siano emessi come eventi per costruzione, alimentando lo stesso process mining che ha stabilito la baseline. L'osservabilità non è strumentazione aggiunta a posteriori; è una proprietà progettata dall'inizio, ed è ciò che consente al processo di continuare a migliorare dopo la fine del progetto.

Progettare per la reversibilità. Una riprogettazione che può solo andare avanti è una riprogettazione a cui si opporrà resistenza, perché il costo di sbagliare è catastrofico. Costruiamo la migrazione in modo che ciascun incremento possa essere messo in pausa, eseguito in parallelo con l'esistente e annullato se l'evidenza lo richiede. Non è timidezza; è ciò che rende sostenibile l'audacia. Quando un cambiamento può essere annullato a basso costo, un'organizzazione tenterà cambiamenti che non rischierebbe mai in una logica tutto o niente, ed è proprio quei tentativi che si compongono in una trasformazione reale.

Progettare per l'eccezione, non per il percorso ideale. La maggior parte delle riprogettazioni è disegnata per la transazione che si comporta bene, e la maggior parte del costo risiede in quelle che non lo fanno: la spedizione parziale, la fattura contestata, il cliente che esiste due volte sotto nomi leggermente diversi. Un processo che instrada le sue eccezioni verso un foglio di calcolo e una persona di buona volontà non è stato progettato; è stato progettato a metà e lasciato alla buona volontà umana per il resto. Modelliamo esplicitamente i percorsi delle eccezioni, decidiamo quali siano abbastanza comuni da meritare un percorso di prima classe attraverso il sistema e quali siano genuinamente rari abbastanza da affidare a un lavoro manuale ponderato, e rendiamo tale distinzione una scelta deliberata anziché un accidente di ciò che il software si trovava a supportare. La vera misura di una riprogettazione è come si comporta nel suo martedì peggiore, non nel suo migliore.

I modi in cui questi programmi falliscono sono abbastanza costanti da poter essere catalogati, e la maggior parte sono fallimenti di giudizio più che di tecnologia.

Sostituzione dell'ERP in modalità big bang. L'errore singolo più costoso è sostituire l'ERP e reingegnerizzare i processi in un unico passaggio simultaneo attraverso tutta l'impresa. La teoria è che una rottura netta eviti il costo di far girare due mondi; la pratica è che il rischio si compone, perché ogni problema emerge tutto in una volta senza modo di isolarne la causa, e l'azienda perde la capacità di ripiegare. Preferiamo una riprogettazione erogata per processo e per dominio, con il nuovo flusso comprovato su uno scope circoscritto prima di essere ampliato. Una migrazione a fasi è più lenta e assai più probabile che arrivi a destinazione.

Automatizzare il caos esistente. Un programma che mappa il processo attuale, lo automatizza fedelmente e chiama trasformazione il risultato ha speso moltissimo per muoversi più velocemente nella direzione sbagliata. L'automazione deve seguire la riprogettazione, mai sostituirla.

Reingegnerizzare il diagramma, non l'organizzazione. Una riprogettazione che cambia il sistema e il processo ma lascia intatti incentivi, ruoli e linee di riporto verrà silenziosamente rovesciata dalle persone che infastidisce. Se il processo è ora interfunzionale ma i bonus restano funzionali, gli obiettivi funzionali vincono. La titolarità del processo senza autorità è decorazione.

Debito sui dati rinviato. I team rinviano abitualmente il lavoro sui dati anagrafici e sulla qualità in quanto poco affascinante, con l'intenzione di affrontarlo più tardi. Più tardi il processo riprogettato, che assumeva dati puliti e coerenti, incontra la realtà e si arena. La qualità dei dati non è un compito di pulizia adiacente al progetto; è una precondizione perché il processo funzioni. La progettazione guidata dai consulenti senza gli operatori nella stanza aggrava tutto questo: una riprogettazione disegnata interamente da specialisti mancherà la conoscenza tacita delle persone che gestiscono il lavoro, la ragione per cui un passo che sembra ridondante è in realtà portante, l'eccezione che si verifica settimanalmente e non è mai stata documentata. Quando quegli operatori incontrano per la prima volta il nuovo processo in fase di formazione, ne scoprono le lacune, e la loro fiducia, una volta persa, è costosa da recuperare.

Scope per sistema anziché per risultato. I programmi avviati come un progetto ERP o un progetto CRM ereditano i confini del software anziché i confini del lavoro, e i flussi cross-system, che sono precisamente dove risiede il valore, cadono negli spazi tra i flussi. Il mandato dovrebbe nominare un risultato e un flusso, e lasciare che i sistemi rientrino al suo interno.

Partiamo dal flusso e dal risultato, non dal sistema. Prima di proporre qualsiasi cambiamento stabiliamo cosa il processo end-to-end intende conseguire in termini che l'azienda riconoscerà, tempo trascorso, costo per servire, conversione del contante, sforzo del cliente, e misuriamo lo stato attuale rispetto ad esso usando i dati sugli eventi che i sistemi già detengono anziché la storia che le persone raccontano nei workshop. Quella baseline misurata risolve la prima questione, se il processo meriti reengineering o miglioramento, sull'evidenza anziché sull'entusiasmo.

Dove la riprogettazione è giustificata, progettiamo il processo, il modello dei dati e l'integrazione insieme, trattandoli come tre viste di un'unica decisione anziché come tre progetti sequenziali. Risolviamo esplicitamente la titolarità di ciascun fatto condiviso tra CRM, SCM ed ERP, definiamo l'integrazione come contratti versionati, e rendiamo l'orchestrazione del flusso un artefatto ispezionabile anziché logica sparsa nella configurazione. Il processo riprogettato è costruito per emettere il proprio stato, così da poter essere misurato in produzione rispetto alla stessa baseline che lo ha giustificato.

Eroghiamo per dominio e per flusso, mai con un passaggio big bang. Una porzione circoscritta del processo riprogettato è comprovata in produzione, su transazioni reali, prima di essere ampliata, così che il rischio resti isolato e l'azienda mantenga la capacità di ripiegare. Lungo tutto il percorso, trattiamo il cambiamento organizzativo, la titolarità, gli incentivi, i ruoli, come parte dell'ingegneria anziché come un ripensamento, perché un processo che l'organizzazione non è disposta a far girare non sopravviverà. Il nostro obiettivo è una riprogettazione che continui a migliorare dopo che ce ne andiamo, perché gli strumenti per gestirla sono stati costruiti dall'inizio.

Siamo franchi sul ritmo. Una riprogettazione che abbraccia tre sistemi di registrazione non può onestamente essere completata in un trimestre, e qualsiasi proposta che lo prometta sta vendendo un passaggio anziché una riprogettazione. Sequenziamo il lavoro in modo che ciascun dominio produca da sé un miglioramento misurabile, il che guadagna la fiducia e l'attenzione necessarie per il successivo, anziché chiedere all'azienda di trattenere il respiro attraverso un programma pluriennale per un'unica ricompensa lontana. Quella sequenza disciplina anche la progettazione stessa: un flusso obbligato a dimostrare il proprio valore su una porzione circoscritta non può nascondersi dietro la promessa che tutto si comporrà alla fine. Se una porzione non riesce a migliorare il risultato che era incaricata di migliorare, preferiamo di gran lunga scoprirlo su un dominio anziché su tutti e tre contemporaneamente.

Ciò che distingue il nostro lavoro nel process reengineering è che ci rifiutiamo di trattare CRM, supply chain ed ERP come territori separati con riprogettazioni separate. Teniamo il flusso end-to-end, i dati che lo attraversano e l'organizzazione che lo opera in un'unica vista, e risolviamo le domande difficili su titolarità e integrazione come decisioni di progettazione anziché rinviarle all'implementazione. È una conversazione più difficile da avviare e un risultato assai più duraturo da portare a termine.

C'è anche un corollario pratico che cambia ciò che il lavoro è autorizzato a presupporre. Quando un engagement richiede una capacità che non esiste ancora, non deve attendere un ciclo di approvvigionamento o la roadmap di un fornitore. La Nashua 360 Enterprise Platform è costruita per accogliere quasi qualsiasi funzionalità a ritmo sostenuto, attraverso l'extreme vibe coding: ciò che serve viene descritto in linguaggio semplice e generato rapidamente, ma sempre entro solidi principi di architettura e sotto una rigorosa assicurazione della qualità, così che la velocità non vada mai a scapito di coerenza, sicurezza o controllo. L'effetto è strategico anziché meramente pratico. Sposta la linea del make-or-buy, mantiene economica l'opzionalità, e lascia che l'architettura segua la strategia anziché piegare la strategia a ciò che si trovava per caso su uno scaffale.

La ricompensa per questa disciplina è un insieme di processi centrali che fanno ciò di cui l'azienda ha realmente bisogno, misurati rispetto ai risultati a cui tiene, sostenuti da un'architettura che può cambiare senza rompersi, e gestiti da un'organizzazione disposta a farli girare. È ciò che il reengineering ha sempre inteso offrire, e con gli strumenti di oggi finalmente lo può fare.