Digital Enterprise Architecture

Aggiornamento: 28 nov

Conoscere ed avere in controllo gli elementi che compongono l'architettura del sistema aziendale è una condizione necessaria per apportarvi miglioramenti significativi



Oggi parleremo di Continuous Improvement, spiegando come la conoscenza e la corretta sincronizzazione degli elementi aziendali in una visione olistica di Enterprise Architecture sia una condizione necessaria per attuarlo con successo. Si può iniziare anche con un pezzo di carta per definirla: il digital può venirci in aiuto per mappare più velocemente i processi e per a tenerne in controllo lo stato e le relazioni nel tempo.

Le considerazioni che faremo si basano sugli spunti offerti da due giganti del management quali E.W. Deming e E.M. Goldratt.

Il concetto di fondo è:

conoscere il sistema, identificare il vincolo e le relazioni tra esso ed i diversi elementi per poterlo migliorare in modo efficace, sfruttando un booster per incrementare le performance globali focalizzando interventi e risorse
 

Gli elementi dell'Enterprise Architecture

Sfrutteremo un parallelismo con il mondo dello sport per introdurre tutti gli elementi dell'Enterprise Architecture e le loro relazioni: un'ambiziosa squadra di calcio. Se concordiamo sul punto che anche una squadra di calcio è una organizzazione, non sarà difficile accettare che le conclusioni possono essere estese a qualsiasi organizzazione aziendale (stipendi a parte forse).

In cima alla gerarchia degli elementi dell'Enterprise Architecture troviamo il Goal, la Strategia e le Tattiche. Essi definiscono il "What For", la ragione d'essere dell'organizzazione e "How To", ossia le azioni necessarie e sufficienti a raggiungere il Goal della nostra strategia. Tutto ruota, o dovrebbe ruotare, a questi statement.

Immaginiamo che la strategia della nostra squadra sia "Vogliamo essere sempre ai massimi livelli delle competizioni internazionali, vincendo almeno una coppa ogni 3 anni".

Dichiarare una strategia non basta perché si avveri: occorre metterla in atto. A tal fine si sviluppano le Tattiche, ossia l'insieme dei piani e delle azioni da attuare che, rispettando condizioni di necessità e sufficienza, permettono all'organizzazione di raggiungere il proprio Goal.

Diciamo che la prima condizione necessaria per vincere una competizione internazionale è quella di fare un goal in più dell'avversario in tutte le partite, compresa la finale. Ma allo stesso tempo, oltre alla focalizzazione sulla singola competizione del presente, per rimanere costantemente ad alto livello, sono necessarie anche delle tattiche di medio lungo periodo che guardino alla sostenibilità dei risultati nel tempo.

Al fine di costruire un insieme coerente e completo di Tattiche necessarie e sufficienti, è particolarmente utile costruire un albero di Strategia e Tattiche in modo da visualizzare le relazioni di causalità. Si chiama Strategy & Tactics Tree ed è uno strumento di pianificazione strategica particolarmente efficace, ideato dalla Theory of Constraints. Un esempio di albero di Strategia e Tattiche potrebbe presentarsi in questo modo:

Strategy & Tactics Tree
Strategy & Tactics Tree

Sono sufficienti queste tattiche per raggiungere l'obiettivo? Ovviamente no: occorre spingersi molto più in profondità, definendo obiettivi intermedi e ulteriori tattiche fino ad arrivare ad un livello del nostro albero dove si definiscono le Tattiche Operative, alle quali si legano un altro elemento dell'architettura del sistema: i processi.

Tornando per un attimo in azienda, un esempio di Tattica Operativa è il modello operativo di produzione (es MTO o MTS) ed il modello Operativo di esecuzione della Supply Chain.

I processi definiscono come si devono attuare le azioni necessarie per realizzare le tattiche operative prescelte. Come deve attaccare la squadra? Come deve difendersi? Sono i processi che definiscono come e eseguire una certa tattica di gioco.

Ritornando in azienda: quando emetto un ordine di replenishment? Secondo quale processo?

Per fare in modo che un processo venga eseguito non è sufficiente disegnarlo sulla lavagnetta dell'allenatore. Entrano in campo molti altri elementi fondamentali dell'architettura:

  • le persone (i giocatori) e i loro ruoli (attaccanti, centrocampisti e difensori)

  • le capabilities e gli skills

  • le procedure operative da eseguire

Gli skills a disposizione determinano ad esempio quale tattica operativa posso o non posso eseguire, a seconda anche del contesto: oggi il centravanti migliore è infortunato e devo cambiare tipo di gioco perché sono costretto a mettere in campo un "piccoletto" e giocare con il "falso nueve".

Molto importanti sono anche le capabilities: ad esempio una capability distintiva della squadra potrebbe essere quella di avere sviluppato una particolare fase di attacco su calcio piazzato estremamente efficace, sfruttando il mix di skills a disposizione.

Le procedure indicano i compiti nel dettaglio. Indicano ai giocatori come posizionarsi in determinate fasi di gioco: ad esempio nell'esecuzione di un calcio d'angolo, o come fare la "diagonale in difesa".

Vediamo che gli elementi in gioco iniziano ad essere tanti. Per completare il quadro, abbandoniamo per un attimo la nostra squadra e ritorniamo in azienda per avere una vista completa degli elementi dell'Enterprise Architecture.

Enterprise Architecture Elements
Enterprise Architecture Elements

Se al quadro iniziamo ad aggiungere i diversi strati costituiti dalla numerosità delle occorrenze per ciascun elemento, possiamo intuire la complessità delle relazioni e dell'architettura.

Enterprise Architecture Complexity
Enterprise Architecture Complexity
 

Non dobbiamo necessariamente arrenderci alla complessità

Qualsiasi sistema, per quanto possa essere complesso da descrivere a causa della pluralità di elementi e relazioni, manifesta in realtà una certa Semplicità Intrinseca, perché le sue performance sono sempre definite da poche variabili, che sono i Vincoli del Sistema.

Sebbene istintivamente portati a "disprezzare" i Vincoli dandogli una connotazione negativa, questa è, in realtà, una splendida notizia. In un sistema si sviluppano molte relazioni, ma in un network di relazioni esiste sempre un numero limitato di "hub nevralgici" dai quali dipendono l'andamento complessivo del "traffico di operazioni" all'interno del sistema.

Proviamo a pensare: quanti giorni (forse anni) di sciopero all'aeroporto di Lamezia Terme sono necessari per creare lo stesso impatto sul sistema del trasporto aereo che produce 1 ora di sciopero all'aeroporto di Francoforte? Forse addirittura mai.

Questo esempio chiarisce tante cose: come non sia necessario tenere in controllo ogni singolo elemento del sistema, ma sia sufficiente controllare gli hub nevralgici, i vincoli, e le interazioni con essi.

E ci insegna un'altra cosa molto utile per i controller aziendali:

Un ora persa ad un vincolo costa quanto le intere spese operative dell'azienda per la frazione di tempo persa. Un ora persa ad un non vincolo è un miraggio. (E. Goldratt)
 

Gli effetti indesiderati della mancanza di sincronizzazione

E' sufficiente avere tanti campioni per vincere la Champion's League? L'investimento su un giocatore di fama mondiale da parte di una squadra a strisce ha dimostrato il contrario: non è sufficiente.

E' sufficiente che tutti i giocatori eseguano sempre tutte le loro migliori skills? Se ogni giocatore si mettesse a fare la "rabona" o il "paso doble" ad ogni momento della partita, assisteremmo probabilmente ad uno show di prestazioni funamboliche, ma non ad una partita di calcio, e probabilmente la nostra squadra del cuore perderebbe 8-0.

E' sufficiente entrare in campo con l'unico proposito di dare il massimo? Cosa potrebbe ragionevolmente accadere se l'unica direttiva ricevuta dall'allenatore fosse: "Voglio vedervi uscire sudati e con i crampi; voglio vedervi correre per 90 minuti senza mai mollare un centimetro"? Nessun'altra indicazione tattica e operativa. 4-0 per l'avversario.

E una squadra che scende tutte le domeniche in campo senza una chiara e salda indicazione / identificazione nell'obiettivo strategico? Dobbiamo vincere una competizione. Vogliamo la Champions oppure la Coppa Italia? E' importante saperlo perché se l'allenatore sa di non avere una panchina sufficiente per entrambe le competizioni, dovrà decidere dove focalizzare le energie e in quale competizione risparmiare i giocatori migliori.

Il sistema di performance management è un altro elemento altrettanto importante: il modo in cui premio i giocatori influenza il suo comportamento. Immaginiamo che la metrica di bonus elargiti ai giocatori sia esclusivamente in funzione di obiettivi sui goal fatti. Rischiamo di trovare spesso troppi giocatori in attacco, e meno motivati a passare la palla al compagno piazzato meglio per segnare.

E se non supportiamo il vivaio con una rete adeguata di talent scout oppure con un team di allenatori delle squadre giovanili adeguato, come possiamo implementare la tattica di avere un vivaio di eccellenza per forgiare i nuovi campioni? Finiti i campioni di oggi dovremo verosimilmente sborsare tanto denaro in futuro per rimpiazzarli.

Questi esempi servono a mettere in chiaro l'importanza della sincronizzazione tra gli elementi dell'Enterprise Architecture. Quando la sincronizzazione viene meno, le performance del sistema si deteriorano velocemente e ne scaturiscono diverse ramificazioni negative. Gli effetti di questo deterioramento possono essere classificati in tre macro fenomeni:

  • risultati economici non soddisfacenti / non commisurati agli sforzi profusi,

  • risultati operativi non adeguati, con sintomi che spaziano dall'elevato numero di solleciti, al mancato rispetto delle promesse fatte ai clienti, a clienti mediamente poco soddisfatti, fino ad elevati "churn rate" , ossia tassi di perdita dei clienti

  • clima organizzativo deteriorato, con sintomi che spaziano dall'insoddisfazione, alla latente frustrazione, fino a situazioni di elevato turnover

 

Enterprise Architecture e Continuous Improvement

Questa lunga premessa è servita per comprendere gli elementi e le loro relazioni. Ora arriviamo al cuore del problema.

Quando le cose iniziano ad andare male, ecco che tipicamente dovrebbe scattare la molla del "dobbiamo migliorare". Ma cosa e dove?

Quando guardiamo ai soli risultati sportivi, l'allenatore è sempre il primo a "rimetterci le penne". Nel calcio, dove si parla di "stagione" e la capacità è "fissa" (a parte la parentesi del mercato di riparazione), il cambio di allenatore può sembrare essere l'unica soluzione di breve periodo che magari può raddrizzare l'andamento della stagione, ma difficilmente è la soluzione che elimina tutti i mali (a meno che la causa ultima degli scarsi risultati fosse proprio l'assenza di tattiche e processi e direttive a parte chiedere ai giocatori di correre e sudare....)

Ma rientrando in contesti più complessi come le aziende, può sembrare più difficile identificare le azioni corrette di miglioramento, in quanto il sistema aziendale presenta molte più interdipendenze tra gli elementi del sistema.

Quando si chiede ai propri manager di migliorare la situazione ciò che tipicamente accade sono due fenomeni

  • essere tentati di lanciare un numero eccessivo di iniziative di miglioramento, spinti dal desiderio di migliorare tutto ciò che può essere migliorato, con un focus locale. Il risultato è quello di entrare in una "Improvement Jungle", nella quale si entra ma dalla quale non si sa se e dove si esce.

  • oppure dall'essere spinti solo dalle urgenze, con il risultato di agire solo sui sintomi senza una vera ricerca della causa radice che provoca gli effetti indesiderati (fire-fighting).

Un vantaggio fondamentale che si ottiene da avere chiaramente in controllo l'Enterprise Architecture e le relazioni tra gli elementi è la Conoscenza.

Una Enterprise Architecture in controllo permette di conoscere i vincoli del sistema, gli hub e come essi interagiscono, permettendo quindi di canalizzare le risorse (finite) dell'azienda a migliorare ciò che deve essere migliorato, permettendo di evitare sia la giungla di iniziative sia il mero fire-fighting, approcci che il più delle volte portano poco valore alla bottom line rispetto agli sforzi profusi.

Improvement Approaches
Improvement Approaches

 

Aggiungiamo ora un po' di tecnologia, mescoliamo ed arriviamo alla Digital Enterprise Architecture

Avere conoscenza e mettere in controllo l'Enterprise Architecture richiede un certo sforzo, sicuramente ripagato. Sicuramente non è efficace tenere la nostra architettura in qualche cartella della directory aziendale condivisa, in quanto diventa poco fruibile e rischia di prendere solamente la polvere.

Deve diventare invece uno strumento per favorire il flusso, agevolando la collaborazione, rendendo facilmente fruibile la conoscenza degli obiettivi, delle tattiche, dei processi, dei ruoli e delle regole. Solo in questo modo si sviluppa la conoscenza che diventa un potente punto di leva per comprendere dove intervenire per migliorare il sistema.

La Digital Enterprise Architecture supportata da strumenti adeguati di Business Process Management permette di raggiungere tali obiettivi, e soprattutto semplifica il lavoro di manutenzione nel tempo: il contesto è dinamico, le cose cambiano velocemente, ed occorre avere strumenti adeguati per tenere il passo dei cambiamenti.

 

Utilizzare i Framework e le Best Practice come acceleratori

Un acceleratore per costruire rapidamente una Digital Enterprise Architecture, è quello di sfruttare dei framework già sviluppati tenendo in considerazione le diverse best practice di industry

Un esempio di assoluto riferimento è il framework per la Supply Chain definito dall'ASCM (Association for Supply Chain Management) che si chiama SCOR (Supply Chain Operating Reference), oramai giunto alla sua quattordicesima edizione e rinominato SCOR DS. (DS = Digital Standard).

Il vantaggio è quello di avere un modello di riferimento, che contiene tutte le best practice di processo e di industry, e che permette quindi non solo di semplificare il lavoro di mappatura, ma anche e soprattutto, di identificare rapidamente quali sono gli elementi e le relazioni mancanti o da migliorare.

Vi portiamo un esempio di Digital SCOR sviluppato con la nostra società gemella Thinking Solutions, dove tutti gli elementi dell'architettura sono stati mappati e relazionati secondo il framework di riferimento dell'ASCM SCOR.

Digital SCOR
Digital SCOR
Digital SCOR - MTO
Digital SCOR - MTO
Digital SCOR - Level 3 processes
Digital SCOR - Level 3 processes
Level 4 Business Process
Level 4 Business Process

Il plus della soluzione di Digital Enterprise Architecture, è che i legami tra gli elementi sono dinamici, per cui gli aggiornamenti ad un elemento del sistema si propagano automaticamente a tutti gli altri elementi ad esso collegati, semplificando notevolmente la manutenzione dell'architettura del sistema aziendale.

Per di più molti processi di livello 4 possono essere semplicemente mappati ricorrendo ai tool di process mining, risparmiando una notevole quantità di tempo per riprodurre il current state.

I vantaggi dovrebbero essere evidenti. Oltre a risolvere il problema della manutenibilità dell'architettura:

  • La maggior trasparenza che si crea nell'organizzazione

  • La maggior diffusione di conoscenza

  • La standardizzazione dei processi e delle procedure

  • Il risparmio di tempo quando si deve analizza il sistema per capire dove conviene intervenire per migliorarlo

  • La possibilità di simulare i processi stessi e l'impatto di interventi di miglioramento tramite la modellazione dinamica di processo, aumentando il ROI degli investimenti e riducendo i rischi

Dynamic Process Modeling
Dynamic Process Modeling

Abbinando alla Digital Enterprise Architecture in framework di riferimento mondiale come lo SCOR DS i vantaggi sono ulteriormente accentuati:

  • Si dispone automaticamente della libreria di best practice messe a disposizione dallo SCOR (processi, capabilities, skills, metriche, people).

  • Si crea uno standard che facilita la comunicazione aziendale, eliminando il "gergo" che costituisce spesso una forte barriera alla comunicazione tra le funzioni

  • Si semplifica il benchmarking interno ed esterno


 

CONCLUSIONI

Non è sufficiente un organigramma funzionale ed un modello di controllo per sperare di governare efficacemente un sistema aziendale nel contesto attuale di VUCA e Hyper-Competition.

Organigrammi e modelli di controllo deterministici sono strumenti del passato, che potevano andare bene in ambienti stabili dove il mercato recepiva piò o meno tutto quello che avevamo pensato di immettere sul mercato stesso e l'offerta di prodotti era poco differenziata.

Nel mondo complesso di oggi non possiamo prescindere da una adeguata conoscenza del sistema, dei suoli elementi e delle loro relazioni con gli hub del sistema, in quanto arterie per la generazione di flusso e Throughput.

La tecnologia ci permette di supportare questo passo, ma essa è condizione necessaria ma non sufficiente. Serve anche un cambio di mindset dal mondo deterministico dei modelli di controllo del passato a quello sistemico delle realtà complesse del presente.


 

CONTATTACI PER SCOPRIRE DI PIÙ

Con la nostra esperienza trentennale sulla Theory of Constraints, Lean e Six Sigma, e best practice della Supply Chain ASCM e APICS, in Real Throughput trovi una squadra di consulenti di comprovata competenza ed esperienza per indirizzare con successo i tuoi programmi di Business Transformation.

Siamo esperti di Digital Enterprise Architecture. Contattaci per avere informazioni sul nostro Digital SCOR, la soluzione presentata agli Innovation Labs della recente conference annuale ASCM Connect 2022 dalla nostra parent company Thinking Solutions e dal nostro Co-founder Emanuele Strada. Emanuele è membro del team internazionale che ha contribuito allo sviluppo della nuova release SCOR DS.

Per informazioni:


info@realthroughput.com

www.realthroughput.com


© 2022 – Real Throughput – All Rights reserved


Real Throughput


16 visualizzazioni0 commenti

Post recenti

Mostra tutti