Cause Strutturali Versus Cause Tecniche del Fallimento della Trasformazione Digitale

Dr. Darren W. Pulsipher
Serie: Perché la Trasformazione Digitale Fallisce — e Perché Esiste O-DXA

La trasformazione digitale è presente nell'agenda dei dirigenti da più di due decenni. Nel corso di questo tempo, le organizzazioni hanno attraversato generazioni successive di tecnologie: ERP on-premises, architetture orientate ai servizi, piattaforme cloud, automazione, analisi, intelligenza artificiale.

Ad ogni onda, gli strumenti migliorano. Eppure, i risultati della trasformazione sembrano stranamente familiari.

• I progetti vengono avviati.
• I pilot hanno successo.
• I dashboard si illuminano.

E poi — tre a cinque anni dopo — l'organizzazione si trova a lanciare una nuova iniziativa di “trasformazione” per affrontare molti degli stessi problemi che l'ultima avrebbe dovuto risolvere.

Questa non è una storia isolata. È un modello.

La Lezione 1 di questa serie ha inquadrato quel modello come persistente e sistemico: un fallimento che si ripete in vari settori, tecnologie e cambi di leadership. In questa installazione, andiamo un passo oltre: esaminiamo perché le spiegazioni centrate sulla tecnologia non sono sufficienti e perché le cause primarie del fallimento sono strutturali e architettoniche, non tecniche.

Il nostro obiettivo è distinguere le cause strutturali dai sintomi tecnici e mostrare come il disallineamento tra strategia, esecuzione e governance mantenga i risultati della trasformazione digitale bloccati—indipendentemente dagli strumenti che acquisti.

Quando Strumenti Migliori Non Risolvono il Modello

Quando gli sforzi di trasformazione si bloccano, l'analisi post-mortem suona spesso familiare:

• “Abbiamo scelto la piattaforma sbagliata.”
• “Il fornitore non ha rispettato le aspettative.”
• “La metodologia non si adattava alla nostra cultura.”
• “Il team non aveva le competenze giuste.”

Queste non sono lamentele fittizie. Descrivono problemi reali che possono compromettere un progetto.

Il problema non è che queste spiegazioni siano false. Il problema è che, prese singolarmente, sono troppo piccole per spiegare il modello.

Considera come i fallimenti nella trasformazione digitale si ripetano:

• Attraverso diverse generazioni tecnologiche
  (ERP monolitici, SOA, microservizi, cloud, intelligenza artificiale).
• Con diversi fornitori e partner
  (cambiando fornitori, società di consulenza o piattaforme in ogni nuova ondata).
• Sotto diversi team di leadership
  (CIO, chief digital officer, o sponsor di programma vanno e vengono).

Se la causa principale fosse “la piattaforma sbagliata” o “il partner sbagliato,” ci si aspetterebbe che i risultati fossero diversi una volta corretti quei scelte. Invece, le organizzazioni spesso sperimentano:

• Gli stessi ritardi nelle decisioni.
• Le stesse difficoltà a scalare oltre i piloti.
• La stessa tensione tra ottimizzazione locale e risultati aziendali.

In altre parole: il modello osservabile non è specifico per il fornitore e non è specifico per gli strumenti.

Le spiegazioni tecniche—errori di configurazione, strumenti immaturi, scarsa copertura dei test, pratiche DevOps deboli—sono reali. Possono far affondare un singolo progetto.

Ma non possono, da sole, spiegare perché fallimenti materialmente simili appaiano attraverso più generazioni di tecnologia, in più organizzazioni, nel corso di decenni.

Quando strumenti diversi producono gli stessi risultati strutturali, la struttura è ciò che devi indagare.

Perché le Analisi Post-Mortem Tecniche Continuano a Perdere il Punto

Le analisi post-mortem tecniche sono attraenti perché sembrano concrete:

• Puoi indicare un sistema mal configurato.
• Puoi rintracciare un'interruzione a una particolare scelta di design.
• Puoi attribuire i superamenti ai costi a una complessità sottovalutata.

Queste narrazioni sono importanti per l'apprendimento e il miglioramento. Ma hanno due punti ciechi incorporati.

1. Si Focalizzano sulle Condizioni Locali

Le analisi tecniche si concentrano sull'ambiente locale di un progetto o di un sistema:

• Lo stack specifico, l'infrastruttura o l'architettura.
• Il team specifico e le sue pratiche.
• Il ciclo di vita della consegna specifico e i vincoli.

Raramente si chiedono:
Cosa dell'ambiente circostante ha reso probabile questo risultato?

Per esempio:

• Perché i diritti decisionali erano dove erano?
• Perché le approvazioni di finanziamento erano strutturate in quel modo?
• Perché i forum di governance rinforzavano comportamenti isolati invece di risultati trasversali?

Senza queste domande, ogni fallimento viene trattato come un'anomalia localizzata piuttosto che come prova di un modello strutturale condiviso.

2. Si Ripristinano ad Ogni Nuova Onda Tecnologica

Le analisi post-mortem tecniche sono spesso “bloccate in versione” a uno stack particolare:

• “Abbiamo imparato a non progettare monoliti in questo modo.”
• “Non commetteremo di nuovo questo errore con la nostra prossima migrazione al cloud.”
• “Il nostro prossimo progetto di intelligenza artificiale includerà MLOps sin dall'inizio.”

Ma poi arriva una nuova ondata. Nuovi modelli, nuove parole d'ordine, nuovi vincoli.

L'organizzazione “ripristina” il suo apprendimento attorno al nuovo stack, portando avanti molti degli stessi vincoli strutturali:

• La stessa governance frammentata.
• I medesimi modelli di finanziamento isolati.
• Gli stessi incentivi disallineati.

La tecnologia cambia. La struttura no. E così il risultato—su un livello aziendale—rimane lo stesso.

Cosa Significa Davvero “Struttura” nella Trasformazione Digitale

Per comprendere le cause strutturali del fallimento, dobbiamo essere precisi su cosa significa struttura in questo contesto.

La struttura non è una metafora. È l'insieme di disposizioni durature che plasmano come viene effettivamente svolto il lavoro.

Al minimo, quella struttura include:

• Diritti decisionali
  Chi può decidere cosa, a quale livello e su quale scala temporale? Ad esempio:

  • Un team trasversale può cambiare un processo critico, o deve escalare a un comitato direttivo?
  • Chi possiede le decisioni che attraversano più unità aziendali?

• Modelli di finanziamento
  Come vengono proposte, approvate e rinnovate le investimenti?
  I budget:

  • Seguono progetti, dipartimenti, piattaforme o flussi di valore?
  • Supportano aggiustamenti continui, o solo grandi programmi episodici?

• Forum di governance
  Dove vengono risolti i problemi trasversali?

  • Ci sono meccanismi per bilanciare l'autonomia locale con la coerenza aziendale?
  • Gli organi di rischio e conformità si integrano con la consegna digitale, o esistono come porte seriali?

• Flussi di valore e lavoro
  Come si muove il lavoro attraverso le frontiere?

  • I processi sono progettati attorno ai percorsi del cliente e ai risultati della missione, o intorno ai grafici organizzativi?
  • Dove i passaggi creano attrito o modalità di fallimento?

Questi elementi della struttura operano sia sopra che attorno a qualsiasi particolare stack tecnologico. Plasmano:

• Quali progetti vengono finanziati.
• Quali compromessi sono accettabili.
• Quanto rapidamente l'intento strategico può tradursi in decisioni eseguibili.

Quando diciamo che il fallimento della trasformazione è strutturale, intendiamo:

Le disposizioni di diritti decisionali, finanziamento, governance e flussi di valore
sistematicamente allontanano l'esecuzione dalla strategia dichiarata—anche quando i singoli progetti hanno successo a livello tecnico.

Disallineamento Strutturale: Strategia, Esecuzione, Governance

Un modo per vedere più chiaramente le cause strutturali è guardare come strategia, esecuzione e governance si allontanano l'una dall'altra.

• Strategia — le dichiarazioni di intento e direzione:

  • “Saremo un'organizzazione guidata dai dati.”
  • “Forniamo servizi digitali senza soluzione di continuità dalla fine all'inizio.”
  • “Daremo potere ai team vicini alla missione.”

• Esecuzione — il lavoro effettivo:

  • Programmi, progetti e prodotti.
  • Processi e flussi di lavoro quotidiani.
  • Come i team sono strutturati e misurati.

• Governance — le regole e i meccanismi di supervisione:

  • Politiche di rischio e conformità.
  • Processi di budgeting e portafoglio.
  • Standard e porte di approvazione.

Quando gli sforzi di trasformazione vacillano, spesso si vedono modelli come:

• La strategia promette servizi trasversali e centrati sull'utente.
  L'esecuzione è ancora organizzata attorno ai progetti dipartimentali.
  La governance esamina le proposte dipartimento per dipartimento.

• La strategia richiede team agili e potenziati.
  I team di esecuzione adottano la terminologia agile.
  La governance richiede ancora cicli di approvazione di diversi mesi per cambiamenti basilari.

• La strategia enfatizza decisioni guidate dai dati.
  I team di esecuzione costruiscono dashboard di analisi.
  I processi di governance si basano ancora su rapporti statici e approvazioni manuali.

In ciascun caso:

• La tecnologia può essere moderna.
• Le pratiche di consegna possono essere aggiornate.

Ma la relazione strutturale tra strategia, esecuzione e governance è disallineata. E quel disallineamento è ciò che alla fine ostacola una trasformazione sostenuta.

Quando le strutture sono disallineate:

• I team di esecuzione possono essere efficienti e capaci—mentre ottimizzano per le cose sbagliate.
• I forum di governance possono essere diligenti—mentre rinforzano i silos e rallentano il cambiamento sistemico.
• I documenti strategici possono essere convincenti—mentre hanno poco effetto sul comportamento quotidiano.

Il risultato è familiare:

• Vincite locali.
• Stagnazione aziendale.
• Un altro programma di trasformazione qualche anno dopo.

Come il Disallineamento Si Amplifica con Nuove Tecnologie

Qui emerge una realtà controintuitiva:

Quando esiste disallineamento strutturale, migliori tecnologie possono peggiorare il problema.

Perché?

Perché gli strumenti moderni:

• Abbassano il costo della sperimentazione.
• Aumentano la velocità del processo decisionale locale.
• Rendono più facile per i singoli team o dipartimenti andare avanti autonomamente.

Se la struttura circostante non è allineata:

• I team si muovono rapidamente in direzioni diverse.
• Le ottimizzazioni locali si moltiplicano.
• Le sfide di integrazione e governance aumentano.

Invece di una trasformazione sincronizzata, ottieni:

• Molteplici “piattaforme strategiche” con capacità sovrapposte.
• Implementazioni inconsistenti di politiche simili (ad es., sicurezza, protezione dei dati).
• Soluzioni parallele al medesimo problema, nessuna delle quali scala a livello aziendale.

La tecnologia non è “cattiva.” Essa amplifica semplicemente la struttura che trova.

Se i diritti decisionali, i modelli di finanziamento e i meccanismi di governance sono frammentati, gli strumenti digitali moderni accelereranno la frammentazione.

Architettura come Disciplina Strutturale, Non Documentazione

Qui entra in gioco l'architettura—non come un insieme di diagrammi, ma come una disciplina strutturale.

In molte organizzazioni, l'architettura è percepita come:

• Il team che mantiene modelli di riferimento e repository di standard.
• Il gruppo che partecipa alle revisioni del design e dice “no” tardi nel processo.
• Una funzione di documentazione che è in ritardo rispetto al cambiamento nel mondo reale.

In un'inquadratura strutturale, ciò non è sufficiente.

L'architettura, intesa in modo strutturale, riguarda:

• Codificare l'intento strategico in vincoli e modelli operativi
  in modo che le decisioni locali si sommino a risultati aziendali.

• Plasmare i percorsi decisionali
  in modo che quando appare una nuova iniziativa, essa fluisca attraverso principi coerenti, non negoziazioni ad hoc.

• Collegare strategia, esecuzione e governance tramite:

  • Informare come sono strutturati i portafogli.
  • Influenzare come i modelli di finanziamento rafforzano la coerenza.
  • Fornire principi condivisi che gli organi di governance possono applicare.

In altre parole: l'architettura non è principalmente l'artefatto; è il sistema di governance che allinea persone, processi, politiche e tecnologia nel tempo.

Senza questo strato architettonico che funzioni come disciplina strutturale:

• La trasformazione è eseguita come una sequenza di progetti scollegati.
• Ogni progetto deve negoziare allineamenti da solo.
• Gli organi di governance mancano di un quadro condiviso per prendere decisioni trasversali.

I risultati sembrano un “fallimento tecnico,” ma il problema più profondo è:

• Non esiste un meccanismo strutturale per mantenere l'esecuzione legata alla strategia mentre le condizioni cambiano.

Perché Trattare i Problemi Strutturali Come Problemi Tecnici Fallisce

Quando le organizzazioni diagnosticano erroneamente questioni strutturali come tecniche, tendono a rispondere in modi prevedibili:

• Lanciare un importante ripiatto per “risolvere” la lentezza nella delivery.
• Scambiare un ecosistema di fornitori con un altro per “semplificare” il panorama.
• Introdurre una nuova metodologia o modello operativo come la soluzione miracolosa.

Queste risposte possono essere preziose in un senso limitato. Possono migliorare aspetti specifici dell'ambiente.

Ma se le strutture sottostanti di diritti decisionali, finanziamento e governance rimangono inalterate:

• La nuova piattaforma eredita gli stessi colli di bottiglia di approvazione e incentivi disallineati.
• Il nuovo fornitore incontra gli stessi conflitti trasversali del precedente.
• La nuova metodologia è costretta a adattarsi ai vecchi ritmi di governance e budgeting.

L'organizzazione investe pesantemente nel cambiamento—e poi scopre che la sua traettoria è largamente la stessa.

Due costi specifici del misdiagnosi spiccano:

1. Complesso Accumulato
   Ogni ciclo aggiunge:

   • Nuove piattaforme e integrazioni.
   • Processi di governance aggiuntivi.
   • Più capacità sovrapposte.
     La complessità cresce. L'allineamento strutturale non cresce.

2. Capacità Ridotta per un Vero Cambiamento Strutturale
   Dopo alcuni cicli, le parti interessate diventano scettiche:

   • “Abbiamo già fatto tre programmi di trasformazione.”
   • “Abbiamo provato agile / cloud / analisi; non ha risolto il problema.”
     L'appetito per un cambiamento strutturale più profondo diminuisce, anche se la necessità di esso aumenta.

Verso una Risposta Architettonica Integrata (Anteprima)

Questa lezione e il suo corrispondente blog si sono concentrati deliberatamente su:

• Dimostrare che il fallimento persistente indica cause sistemiche oltre agli strumenti e progetti individuali.
• Sostenere che il disallineamento strutturale tra strategia, esecuzione e governance è un fattore primario di quei fallimenti.
• Riposizionare l'architettura come disciplina strutturale capace di affrontare quel disallineamento—non come un esercizio di documentazione successivo.

Non abbiamo ancora descritto un framework di soluzione specifico o modello operativo. Questo arriverà più tardi nella serie.

Prima di introdurre qualsiasi approccio particolare, abbiamo bisogno di una chiara e condivisa comprensione di:

• Come il disallineamento si manifesta tra persone, processi, politiche e tecnologia.
• Come la frammentazione della governance e i modelli di diritti decisionali creano modalità di fallimento prevedibili.
• Cosa significherebbe per l'architettura funzionare come un vero sistema di governance.

Il prossimo capitolo andrà più a fondo in questi modelli strutturali: mappando come i fallimenti ricorrenti sorgono dal modo in cui le organizzazioni sono attualmente architettate e quale tipo di modello architettonico integrato sia richiesto per mantenere la trasformazione digitale allineata nel tempo.

Per ora, la conclusione chiave è semplice:

Se i fallimenti ricorrenti nella trasformazione sembrano gli stessi attraverso strumenti, fornitori e onde tecnologiche, il problema non è principalmente tecnico.
È strutturale—e l'architettura, trattata come disciplina strutturale, è dove deve iniziare il lavoro.