Descrivere correttamente un processo, riconoscere nei dati le regolarità del suo funzionamento e decidere che cosa debba essere cambiato sono tre operazioni diverse. Le prime due possono essere affidate, almeno in parte, a strumenti e metodi. La terza richiede un giudizio sul caso concreto, sulle conseguenze della decisione e sulle persone chiamate a sostenerne il costo.
Il punto cruciale è che i dati possono evidenziare una divergenza, ma non forniscono necessariamente il criterio per determinare quale termine della divergenza debba essere modificato. Il business process management vanta oggi due strumenti tecnici consolidati. Il primo è la notazione, che consente di descrivere un processo attraverso una grammatica formale verificabile. Il secondo è l’osservazione automatica, che permette di ricostruire la sequenza effettiva di un processo dai suoi tracciati digitali.
Entrambi hanno raggiunto un livello di rigore elevato, sostenuto da una comunità scientifica affermata e da norme internazionali. Tuttavia, alla loro crescente precisione si accompagna un presupposto che merita di essere approfondito: più accurata è la rappresentazione del lavoro, più ampie dovrebbero essere le possibilità di migliorarlo. È proprio su questo punto che ho qualche perplessità.
Descrivere correttamente un processo e ricavarne regolarità dai dati sono condizioni necessarie per intervenire con cognizione di causa. Non determinano però, da sole, quale intervento sia opportuno. Fra la rappresentazione e il cambiamento rimane una distinzione che va compresa applicando, secondo me, una competenza diversa: giudicare quale mutamento un'organizzazione possa sostenere, chi debba cambiare comportamento, quali conseguenze ne derivino e quale prezzo sia ragionevole chiedere alle persone coinvolte.
Il problema può essere espresso in termini semplici. Un modello può dirci come un processo dovrebbe svolgersi. I dati possono dirci come si svolge effettivamente. Se le due cose divergono, nessuno dei due elementi stabilisce automaticamente se debba essere corretto il comportamento oppure il modello.
Analizzerò questa tesi a partire da un caso professionale che ho osservato personalmente, valutandolo attraverso diverse prospettive. Queste includono la riflessione sul business process management di van der Aalst, La Rosa e Santoro, la lettura organizzativa di Capaldo, la distinzione tra teoria dichiarata e teoria in uso di Argyris e Schön, il concetto di razionalità limitata di Simon, la teoria dei punti di leva di Meadows e la distinzione aristotelica tra diverse forme di conoscenza.
Non intendo ricavarne l'ennesima teoria generale. Propongo piuttosto un'ipotesi di lavoro: nel governo dei processi occorre distinguere almeno tre capacità, descrivere il lavoro, riconoscerne le regolarità e giudicare quale cambiamento sia opportuno nel caso concreto.
Durante un progetto di trasformazione digitale, un gruppo di lavoro si riunisce quotidianamente per tre mesi, dedicando ogni incontro al riesame di attività già registrate in un sistema di gestione del lavoro. Ai partecipanti viene chiesto di riferire oralmente informazioni che il sistema conserva e rende facilmente accessibili, come l’apertura dell’attività, il suo stato attuale e il suo avanzamento.
Tuttavia, nello stesso periodo, tre problemi ben più complessi vengono sistematicamente trascurati dall’ordine del giorno: la resistenza degli utenti finali all’adozione del nuovo sistema, l’incompatibilità con alcuni sistemi preesistenti e il progressivo deterioramento del clima all’interno del gruppo.
Ritengo che il caso possa servire a scopo illustrativo. Un singolo caso ovviamente, anche se osservato a lungo, non stabilisce però una regolarità generale né autorizza inferenze quantitative.Mi serve qui per rendere visibile una relazione che io credo esiste tra i fenomeni e confrontarla con diverse prospettive teoriche. Per tutelare l'anonimato ometto il nome dell'organizzazione, il settore, le unità coinvolte, i volumi, la numerosità del gruppo, le date e ogni altro elemento che possa consentire un'identificazione indiretta. Mantengo soltanto ciò che serve a comprendere il problema.
La domanda da cui parto è apparentemente banale: perché un gruppo di persone dovrebbe riunirsi più volte al giorno per riferire informazioni che possiede già? La risposta più immediata sarebbe: perché il sistema non basta. Ma non basta dire neppure questo. Occorre capire che cosa, precisamente, il sistema non fornisce.
Comincio dalla notazione, cioè dalla dichiarazione formale del processo. La Business Process Model and Notation, fissata dall'Object Management Group nella versione 2.0 e divenuta nel 2013 norma internazionale ISO/IEC 19510, mette a disposizione eventi, attività, gateway, corsie e flussi di messaggio attraverso i quali un'organizzazione può rappresentare il proprio funzionamento in forma verificabile.
È una conquista rilevante. Un processo descritto con una grammatica condivisa può essere esaminato da persone diverse, discusso, confrontato, corretto. La forma consente di sottrarre almeno una parte del lavoro all'ambiguità della sola narrazione orale.
Nel caso che esamino, questa dichiarazione formale esiste già. Il sistema di gestione del lavoro contiene stati, transizioni, responsabilità e sequenze consultabili. La descrizione non presenta lacune tali da spiegare la necessità di ripetere oralmente, più volte al giorno, ciò che vi è già registrato. Il problema nasce altrove. La storia stessa di come sono stati pensati questi strumenti suggerisce un possibile nuova interpretazione, provo a spiegami di seguito.
Van der Aalst (2013) riconduce i sistemi attuali agli Office Information System sviluppati dalla fine degli anni Settanta, fondati anche sull'impiego delle reti di Petri, e ai sistemi di Workflow Management diffusi negli anni Novanta durante la stagione del reengineering.
In parte quell'approccio cercava di ricondurre il lavoro reale entro sequenze idealizzate e sufficientemente rigide da poter essere automatizzate. Era un'impostazione comprensibile nell'ambiente manifatturiero da cui provenivano molti di quei concetti, molto meno innocua quando veniva trasferita al lavoro d'ufficio, alla cooperazione fra persone e alle attività nelle quali eccezione, negoziazione e interpretazione costituiscono parte del lavoro stesso. La distanza fra processo descritto e processo eseguito non è dunque una recente imperfezione degli strumenti. Accompagna da tempo il tentativo di formalizzare il lavoro organizzato.
C'è poi un secondo problema: l'origine stessa dei modelli. Sempre Van der Aalst, assieme a La Rosa e Santoro (2016) osserva che molti modelli utilizzati nell'analisi dei processi vengono costruiti attraverso colloqui, riunioni e sessioni di lavoro con le persone coinvolte. Il modello risente quindi inevitabilmente di ciò che i partecipanti sanno, ricordano, considerano importante o ritengono opportuno dichiarare. Un modello può essere impeccabile dal punto di vista della notazione e, al tempo stesso, rappresentare solo parzialmente ciò che accade. La precisione sintattica non garantisce la verità organizzativa, insomma.
Il process mining nasce propriamente per ridurre questa discrepanza. Invece di chiedere soltanto alle persone come si svolge un processo, ricostruisce il processo attraverso i dati di evento prodotti dai sistemi informativi. Van der Aalst (2011, 2018) ne individua tre grandi funzioni: scoprire il modello a partire dai dati, verificare la conformità fra modello e comportamento osservato, arricchire il modello con informazioni sulle prestazioni.
Il vantaggio è evidente. L'analisi non poggia soltanto sulle dichiarazioni dei partecipanti, ma sulle tracce lasciate dalle loro attività nei sistemi.
Gli sviluppi più recenti, in particolare quelli riferibili all'approccio object-centric, cercano inoltre di superare il limite delle ricostruzioni fondate su un solo oggetto, ricomponendo le relazioni fra più entità che concorrono allo stesso processo.
Nel caso che esamino, una parte importante di questa funzione di osservazione è già disponibile. Attività, stati e tempi di permanenza sono registrati e consultabili. La ripetizione orale quotidiana non serve dunque a colmare un semplice vuoto informativo. I dati ci sono.
Resta però un dubbio. La verifica di conformità mette a confronto il modello di riferimento con i dati registrati dai sistemi. Può individuare una deviazione e quantificarne la frequenza, sembrando quasi arrivare a un giudizio. Ma è proprio qui che si manifesta il limite fondamentale. Una deviazione sistematica può suggerire una prassi che va allineata alla regola. Allo stesso tempo, però, può indicare una regola mal concepita, incapace di rappresentare un vincolo operativo noto a chi esegue il lavoro, ma ignorato da chi l’ha progettata.
L'analisi dei dati a disposizione di solito mostra la differenza, ma non stabilisce quale dei due termini sia corretto. Sappiamo che di solito, per prendere una decisione, bisogna considerare il contesto, valutare le competenze disponibili, prevedere le conseguenze, distinguere l’errore dall’adattamento intelligente, misurare il costo della correzione e assumersi la responsabilità della scelta.
A questo punto è utile tornare al caso. Se le informazioni richieste durante le riunioni sono già disponibili nei sistemi informativi, perché vengono ripetute a voce durante le riunioni? La domanda diventa più interessante se smettiamo di dare per scontato che la funzione effettiva di quelle riunioni coincida con quella dichiarata. Argyris e Schön (1974) distinguono fra teoria dichiarata e teoria in uso. La prima comprende le ragioni e i principi con cui individui e organizzazioni spiegano il proprio comportamento. La seconda comprende i criteri che, osservando le azioni, sembrano governarlo davvero.
Nel mio caso, la teoria dichiarata attribuisce alle riunioni il compito di costruire una comprensione condivisa dello stato del progetto. Il comportamento che di solito ho potuto osservare suggerisce però che le riunioni hanno una funzione diversa. Il responsabile non sembra avere bisogno soltanto dell'informazione contenuta nel sistema. Spesso cerca qualcosa che il sistema non gli restituisce con la stessa immediatezza: la possibilità di interrogare una persona, coglierne un'esitazione, ottenere un'assunzione pubblica di responsabilità, verificare la sicurezza con cui viene formulata una risposta, ricevere segnali deboli che nessun campo strutturato di una qualsiasi applicazione software può registrare.
In altri termini, forse non sta cercando informazione nel significato più stretto della parola. Sta cercando certezza. O, almeno, una riduzione dell'incertezza che il dato registrato non riesce a offrirgli. Questa distinzione cambia la lettura del problema. La ridondanza della riunione non è più soltanto uno spreco da eliminare. Diventa il sintomo di una funzione organizzativa rimasta senza uno strumento adeguato. Il rischio consiste allora nel correggere la forma senza comprendere la funzione. Eliminare le riunioni perché «i dati sono già nel sistema» può essere una scelta perfettamente razionale dal punto di vista informativo, ma allo stesso tempo potrebbe rivelarsi miope per l’organizzazione. Prima di modificare una prassi, occorre capire quale bisogno, anche impropriamente, quella pratica sta soddisfacendo.
La distinzione di Argyris e Schön permette di leggere anche il processo formale sotto una luce diversa. Un modello di processo approvato e sistematicamente disatteso presenta la stessa struttura: il modello esprime la teoria dichiarata, il comportamento reiterato rivela la teoria in uso. La notazione può rendere perfettamente esplicita la prima. L'osservazione automatica può rendere sempre più visibile la seconda.
Argyris (1990) introduce successivamente il concetto di routine difensiva organizzativa per spiegare perché alcune divergenze possano persistere anche quando sono evidenti. Una routine difensiva consente alle persone di evitare situazioni percepite come minacciose o imbarazzanti e, proprio per questo, sottrae alcuni problemi alla discussione aperta. La ripetizione orale di stati già visibili può assumere questa funzione. Occupa il tempo della riunione con argomenti poco compromettenti, sui quali è facile mantenere una conversazione ordinata, e rinvia il confronto su questioni che richiederebbero decisioni assai più difficili: una resistenza che nessuno sa come affrontare, un'incompatibilità tecnica che mette in discussione scelte già compiute, un conflitto che potrebbe chiamare in causa il modo stesso in cui il progetto viene diretto.
Il problema diventa quindi ancora più sottile. La riunione può contemporaneamente ridurre l'incertezza del responsabile e proteggere il gruppo dal confronto con problemi più difficili. Le due funzioni non si escludono. È proprio questa ambiguità a rendere insufficiente qualsiasi diagnosi puramente strumentale.
La stessa pratica suggerisce, osservata dal versante opposto, quale potrebbe essere la funzione utile di una riunione di avanzamento. Pensiamo alla riunione concepita come riallineamento fra quanto era stato deciso e quanto sta realmente accadendo. Serve a confrontare il presente con una decisione precedente e, quando necessario, a produrne una nuova. Segnare una soglia, per dirla con Han, per creare un prima e un dopo, rendere riconoscibile una responsabilità se necessario. Nel caso che racconto, la riunione conserva la forma del rito ma ne smarrisce in parte la funzione. Lo stato viene ripetuto, ma raramente ricondotto alla decisione da cui deriva; l'incontro lascia poca memoria e produce poca direzione.
E ancora, il progetto può raggiungere il risultato grazie all'eccezione anziché grazie al sistema, perché qualcuno compensa con lo sforzo individuale ciò che il metodo condiviso non riesce a governare. Il successo finale può allora nascondere un debito organizzativo. Siamo sulla Stultifera Navis, quindi potremmo dire che la nave arriva in porto, ma dal registro di bordo, non si comprende se e quante volte l'equipaggio abbia dovuto tappare una falla con le proprie mani.
Sarebbe riduttivo interpretare tutto questo come semplice eccesso di controllo. Simon (1947) ha mostrato che chi decide in un'organizzazione opera in condizioni di razionalità limitata. Non possiede tutte le informazioni, non può prevedere tutte le conseguenze e non dispone di una capacità illimitata di elaborazione. La decisione organizzativa reale nasce quindi entro un perimetro incerto. Un sistema può offrire informazioni esatte su stati, date e avanzamenti e lasciare tuttavia fuori proprio ciò che, in quel momento, determina il rischio del progetto.
Può non registrare la probabilità che una resistenza interna comprometta un rilascio. Può non mostrare che un fornitore stia preparando l'interruzione di un'integrazione. Può ignorare le trattative informali attraverso le quali una soluzione viene già modificata prima che qualcuno abbia aggiornato un documento. Da questo punto di vista, chiedere a voce informazioni già registrate può rappresentare un tentativo rozzo, costoso e ripetitivo di raccogliere anche ciò che non è stato formalizzato.
Il bisogno informativo è reale. La forma scelta per soddisfarlo può essere inefficiente. Confondere i due piani porterebbe a una diagnosi sbagliata. La letteratura sul business process management conosce da tempo questo problema.
Partiamo da Capaldo (2023) che insiste sulla necessità di considerare, insieme alla modellazione dei processi, la cultura organizzativa, le competenze effettivamente presenti, le persone coinvolte e la resistenza al cambiamento. Egli richiama a questo proposito il modello delle sette S, sviluppato nella ricerca manageriale degli anni Ottanta del secolo scorso, che distingue fra componenti relativamente facili da modificare attraverso decisioni formali, come strategia, struttura e sistemi, e componenti assai meno docili: competenze, personale, stile di direzione, valori condivisi.
Un diagramma si modifica in una mattina. Una consuetudine professionale può resistere per anni.
Meadows (1999) raggiunge una conclusione affine da una prospettiva sistemica. Ordinando i punti nei quali è possibile intervenire su un sistema, colloca gli aggiustamenti dei parametri fra gli interventi meno profondi e il cambiamento dei paradigmi fra quelli dotati di maggiore capacità trasformativa. Riconfigurare un flusso di lavoro interviene sulla struttura visibile del sistema. Modificare la convinzione secondo cui «per sapere veramente come va il progetto devo farmelo raccontare dalle persone» richiede un intervento di tutt'altra natura.
Ed è precisamente questo secondo livello a rimanere spesso fuori dal perimetro dei progetti tecnologici.
Il secondo volume dell'Handbook curato da vom Brocke e Rosemann (2015) dedica infatti ampio spazio ad allineamento strategico, governo, persone e cultura, ponendoli accanto ai metodi e ai sistemi informativi. Van der Aalst, La Rosa e Santoro (2016) formulano il problema ancora più esplicitamente: migliorare i modelli non significa automaticamente migliorare i processi. La disciplina, sostengono, dovrebbe conservare come proprio fine il miglioramento dei processi reali e non lasciarsi assorbire dal perfezionamento delle loro rappresentazioni.
Gli stessi autori ricordano inoltre che la resistenza organizzativa può vanificare iniziative tecnicamente valide e che molte proposte non arrivano mai a modificare i sistemi effettivamente utilizzati. Il limite, dunque, è noto. La difficoltà comincia quando bisogna stabilire che cosa fare.
Un passaggio dell'editoriale di van der Aalst, La Rosa e Santoro è particolarmente interessante. Gli autori osservano che anche il process mining, nato per avvicinare l'analisi alla realtà effettivamente registrata, ha finito talvolta per concentrare l'attenzione sulla qualità dei modelli estratti più che sul miglioramento dei processi da cui quei dati provengono.
Lo strumento concepito per correggere una distorsione rischia così di riprodurne la struttura. La soluzione proposta dagli autori consiste anche nell'integrare il process mining con Six Sigma e ricerca operativa, collegando maggiormente i dati agli indicatori di prestazione. È una direzione percorribile, ma a mio avviso rimane irrisolta la questione del che cosa porta un attore organizzativo a cambiare comportamento quando un indicatore dimostra, con maggiore precisione, che dovrebbe farlo.
L'indicatore può rendere più difficile negare il problema. Non può obbligare da solo un'organizzazione a sostenere il costo della soluzione. La stessa distinzione emerge nella pratica professionale. Mi è capitato di assistere all'avvio di iniziative che possedevano tutti i segni esteriori di un progetto senza produrre una capacità organizzativa nuova. Erano anche caratterizzate da una corposa documentazione, ma spesso non misuravano niente di concreto, non lasciavano tracce accurate, non modificavano il modo in cui il lavoro veniva svolto.
Una rappresentazione può mostrare con grande precisione che qualcosa accade. Comprendere perché accada e quale decisione ne debba seguire appartiene a un passaggio ulteriore. Anche la normazione tecnica si è progressivamente avvicinata a questo problema. La revisione del 2015 della ISO 9001, per esempio, credo che abbia dato maggiore rilievo all'approccio per processi (finalmente), al contesto dell'organizzazione, alle parti interessate e al pensiero basato sul rischio. Ricerca, esperienza professionale e normazione convergono così su una conclusione: la documentazione della sequenza non completa il governo del processo.
A questo punto una distinzione molto più antica del business process management permette, a mio avviso, di dare un nome alle tre capacità che ho cercato di separare. Nel libro VI dell'Etica Nicomachea Aristotele distingue, fra le diverse disposizioni dell'intelletto, episteme, techne e phronesis. L'episteme riguarda ciò che può essere conosciuto secondo principi e regolarità generali. La techne riguarda il saper produrre qualcosa secondo una regola. La phronesis, la saggezza pratica, riguarda invece il deliberare bene su ciò che può essere altrimenti: la scelta dell'azione appropriata in una situazione concreta, nella quale il principio generale non determina da solo la decisione.
Ne parlo meglio nel mio libro "Cartografie delle zone d’ombra. Segnale, rumore e sapere tacito nelle organizzazioni" edito da Delos Digital lo scorso due luglio 2026. In breve, la notazione appartiene prevalentemente al dominio della techne: permette di produrre correttamente un artefatto formale secondo regole condivise. L'analisi dei dati e il process mining appartengono, per analogia, al dominio dell'episteme: cercano regolarità, ricorrenze, relazioni osservabili. Il giudizio su ciò che debba essere fatto in uno specifico contesto appartiene invece alla dimensione della phronesis.
Qui occorre però una precisazione. Il business process management non ignora le persone, la cultura o il cambiamento organizzativo. La sua stessa letteratura dimostra il contrario. L'asimmetria sta altrove. Notazione e osservazione sono molto più facilmente traducibili in metodi, procedure, strumenti e verifiche ripetibili. Il giudizio pratico resiste maggiormente alla formalizzazione perché richiede di ponderare circostanze singolari, conseguenze incompatibili, interessi differenti e costi che non sempre possono essere riportati alla stessa unità di misura.
Possiamo formalizzare il modello. Possiamo automatizzare una parte dell'osservazione. È assai più difficile automatizzare la responsabilità di scegliere quale cambiamento sia giusto chiedere a una determinata organizzazione in un determinato momento.
Questo punto potrebbe generare un equivoco. Se i dati non determinano da soli la decisione, si potrebbe concludere che il passaggio successivo debba essere affidato all'intuito del dirigente, all'esperienza personale o, peggio, alla sua autorità. Sarebbe una conclusione opposta a quella che propongo.
Il giudizio pratico ha bisogno dei riscontri raccolti dalla notazione e dall'osservazione. Senza di essi rischia di ridursi a impressione, abitudine o esercizio del potere. Un'organizzazione che discuta di cultura e valori senza osservare ciò che accade realmente può raccontarsi qualunque cosa.
Una direzione che invochi l'esperienza senza confrontarla con i dati può trasformare l'anzianità in una forma di immunità dalla verifica. Le tre capacità devono dunque sostenersi reciprocamente. La notazione rende esplicito ciò che dichiariamo di voler fare. L'osservazione permette di verificare ciò che facciamo. Il giudizio decide che cosa debba essere modificato alla luce della distanza fra le due cose. Il giudizio pratico comincia precisamente nel punto in cui i dati, pur necessari, non determinano più in modo univoco l'azione.
Rimane una domanda che nessuno strumento può risolvere in forma impersonale: chi deve assumersi questo giudizio? Parlare genericamente di «organizzazione» rischia di nascondere il problema. Le organizzazioni non cambiano comportamento. Lo cambiano le persone.
Ogni trasformazione di processo redistribuisce almeno una parte di quattro elementi: lavoro, discrezionalità, responsabilità e potere. Qualcuno dovrà compiere un'attività che prima non svolgeva. Qualcuno perderà una libertà operativa. Qualcuno dovrà rendere conto di una decisione che prima rimaneva indistinta. Qualcuno dovrà rinunciare a una pratica sulla quale aveva costruito esperienza, sicurezza o autorevolezza.
Il modello di processo può rappresentare la nuova distribuzione, e i dati possono misurarne alcuni effetti. Tuttavia, rimane da stabilire se il costo imposto a queste persone sia sostenibile, legittimo e proporzionato al risultato atteso. È qui che la trasformazione digitale mostra la sua vera natura organizzativa. Una casella spostata in un diagramma può celare il trasferimento di responsabilità da un ufficio a un altro. L’eliminazione di un passaggio può esserci la perdita di un controllo che qualcuno riteneva fondamentale. L’automazione di una decisione può esserci la riduzione dello spazio professionale in cui una persona esercitava il proprio sapere. La rappresentazione mostra la nuova architettura, ma non misura appieno ciò che quella architettura richiede ai suoi abitanti.
Il percorso svolto fin qui mi porta a formulare un criterio operativo, che considero un'ipotesi di lavoro da sottoporre a verifica su casi più numerosi. Prima di considerare conclusa un'iniziativa di business process management, un'organizzazione dovrebbe essere in grado di rispondere per iscritto almeno a due domande:
- chi dovrà comportarsi diversamente rispetto a prima?
- quale costo concreto, rischio, rinuncia o nuova responsabilità gli stiamo chiedendo di sostenere?
Se nessuna persona è chiamata a modificare un comportamento abituale, è difficile sostenere che il processo sia stato trasformato. Potremmo avere prodotto un modello migliore, migliorato la qualità dei dati, reso più trasparente ciò che accade. Sono risultati utili, ma appartengono ancora al dominio della rappresentazione e dell'osservazione. Il cambiamento comincia quando qualcuno agisce diversamente.
Una buona carta geografica permette di vedere il territorio con maggiore chiarezza. Non sposta una montagna, non apre un valico, non decide quale strada valga la pena percorrere. Il criterio che propongo nasce però dall'osservazione di un numero necessariamente limitato di situazioni professionali. Per capire se regge occorre confrontarlo con esperienze differenti: progetti riusciti e falliti, organizzazioni pubbliche e private, trasformazioni profonde e interventi apparentemente minori.
È questo il genere di confronto che cerco. Non mi interessa raccogliere approvazioni intorno alla tesi. Mi interessano soprattutto i casi che arrivano da luoghi professionali diversi dal mio: organizzazioni con altre strutture, altri vincoli, altri modi di distribuire responsabilità e decisioni.
Un'ipotesi cresce quando incontra ciò che ancora non conosce. Se continua a circolare soltanto fra persone che condividono le stesse esperienze e gli stessi riferimenti, rischia di tornare ogni volta al punto di partenza, soltanto con un'eco più forte. Per questo preferisco il contatto diretto.
Ho scelto da tempo di non essere più presente sui social. La velocità della reazione, il conteggio delle visualizzazioni e l'accumulo dei contatti producono facilmente l'impressione di un confronto anche quando, in realtà, le idee continuano a circolare nello stesso ambiente. Qui cerco qualcosa di diverso.
Se hai incontrato situazioni simili, se il criterio che propongo contraddice la tua esperienza, oppure se conosci un caso nel quale una trasformazione di processo ha funzionato senza che nessuno dei soggetti coinvolti modificasse davvero un comportamento abituale, scrivimi. Mi trovi su calogerobonasia.it; dalla pagina personale puoi contattarmi direttamente.
Mi interessa soprattutto ciò che arriva da un'altra isola: un caso che non avevo previsto, un'obiezione che costringa a correggere il criterio, un'esperienza capace di mostrare dove il ragionamento smette di funzionare. Per mettere alla prova un'ipotesi, un buon ponte vale più di molte bandiere issate sullo stesso molo.
Riferimenti bibliografici
Argyris, C. (1990). Overcoming Organizational Defenses: Facilitating Organizational Learning. Boston: Allyn and Bacon.
Argyris, C., Schön, D. (1974). Theory in Practice: Increasing Professional Effectiveness. San Francisco: Jossey-Bass.
Aristotele. Etica Nicomachea, libro VI.
Capaldo, G. (2023). Il business process management. Gestire i processi aziendali con un approccio olistico per creare valore e facilitare la trasformazione digitale. Milano: Franco Angeli.
Han, B.-C. (2021). La scomparsa dei riti. Una topologia del presente (trad. S. Aglan-Buttazzi). Milano: Nottetempo.
ISO (2013). ISO/IEC 19510:2013, Information technology — Object Management Group Business Process Model and Notation. Ginevra: International Organization for Standardization.
ISO (2015). ISO 9001:2015, Quality management systems — Requirements. Ginevra: International Organization for Standardization.
Meadows, D. H. (1999). Leverage Points: Places to Intervene in a System. Hartland: The Sustainability Institute.
Object Management Group (2011). Business Process Model and Notation (BPMN), Version 2.0.
Simon, H. A. (1947). Administrative Behavior: A Study of Decision-Making Processes in Administrative Organization. New York: Macmillan.
van der Aalst, W. M. P. (2011). Process Mining: Discovery, Conformance and Enhancement of Business Processes. Heidelberg: Springer.
van der Aalst, W. M. P. (2013). “Business Process Management: A Comprehensive Survey”. ISRN Software Engineering, 2013, 1-37.
van der Aalst, W. M. P. (2018). Process Mining: Data Science in Action. Heidelberg: Springer.
van der Aalst, W. M. P., La Rosa, M., Santoro, F. M. (2016). “Business Process Management: Don't Forget to Improve the Process!”. Business & Information Systems Engineering, 58(1), 1-6.
vom Brocke, J., Rosemann, M. (a cura di) (2015). Handbook on Business Process Management 2: Strategic Alignment, Governance, People and Culture. Heidelberg: Springer.