Un modello di insieme per il “sistema azienda”: l’approccio con l’Architettura Enterprise

Giulio Destri
Giulio Destri

Otto anni fa iniziava l’avventura del blog #6MEMES, un luogo di conversazione tra tematiche tecnico-scientifiche e temi considerati di tipo umanistico, ispirato alle Lezioni Americane di Calvino.

In questi otto anni molto è cambiato e in maniera sostanziale: la cultura dei dati e del digitale è ormai dominante e i relativi settori di riferimento – comprese le contaminazioni culturali che li riguardano – sono diventati di dominio comune.

Per questo, nel 2022, il progetto #6MEMES ha raggiunto il suo traguardo e salutato i lettori.

Per continuare a seguirci, visita la sezione News e collegati ai nostri canali social:

Nell’articolo precedente abbiamo esaminato gli effetti della Digital Transformation sul mercato, e quindi sull’ambiente esterno dell’azienda. In questo articolo e nel successivo verrà invece presentata la costruzione di modelli dell’azienda, con il fine di analizzarne punti di forza e punti di debolezza per capire come e dove occorre intervenire attraverso la trasformazione digitale.


La struttura dell’azienda

Un’azienda o un’organizzazione statale – così come  una città o altri tipi di organizzazione umana –  sono a loro modo un sistema, ossia “un insieme di elementi, in relazione fra di loro secondo leggi ben precise, che concorrono al raggiungimento di un obiettivo comune”.

Seguendo lo standard ISO 42010  si definisce Architettura “l’insieme dei concetti fondamentali e delle proprietà del sistema nel suo ambiente, contenuti nei suoi elementi costitutivi, nelle relazioni che tra essi intercorrono, e (per i sistemi artificiali) nei principi del design e nell’evoluzione di essi”. Pertanto, la descrizione dell’architettura di un sistema esprime la descrizione formalizzata e completa di un sistema.

Conoscere la cosiddetta Architettura Enterprise di un’azienda significa conoscere la sua struttura interna, i suoi componenti e le relazioni che fra essi intercorrono (da un punto di vista sia statico che dinamico), permettendo l’analisi delle dinamiche interne e della sua evoluzione nel tempo a partire dallo stato presente.

Occorre fare attenzione al fatto che con questa definizione si può indicare sia il prodotto architettura, ovvero la descrizione formalizzata e completa del sistema azienda (che in termini più precisi si dovrebbe definire descrizione dell’architettura), sia la disciplina architettura, ossia l’insieme di metodologie e processi con cui si giunge al prodotto architettura, partendo dal sistema azienda reale.

La disciplina dell’Architettura Enterprise (ossia della creazione di questo tipo di modello) trae le sue origini dal contesto ICT, ma poi negli anni si è estesa ad abbracciare tutto il “sistema-azienda”. Molti framework e standard internazionali trattano questo concetto: storicamente il primo a definire l’architettura enterprise è stato lo Zachman Framework, mentre TOGAF ha definito i passaggi necessari per costruire un modello architetturale e il già citato ISO 42010 definisce le proprietà di che un sistema di Architettura deve avere. Anche altri framework di IT Governance e Management, come ITIL, COBIT, CMMI etc fanno riferimento all’architettura, che usano come uno strumento al loro interno.

 


I componenti dell’azienda e i punti di vista

Nella pratica delle cose – dunque – come può tutto questo tornare utile?

Occorre in primo luogo ricordare che l’azienda opera entro un ambiente esterno comprendente il territorio e la sua popolazione, i clienti, i fornitori, le strutture della pubblica amministrazione. Al suo interno, invece, l’azienda è formata da tante parti, ognuna delle quali ha, a sua volta, la propria struttura ed è composta di parti più piccole.

Raggruppando ad esempio i componenti dell’azienda in macro-categorie, possiamo suddividere l’azienda in:

  • persone, ognuna con la propria individualità, i propri skill, cultura, motivazione etc… che interagiscono fra loro secondo dinamiche solo in parte organizzate dall’alto
  • regole organizzative, come regolamenti interni, organigrammi, leggi, standard, procedure operative etc… che intervengono anche sulle interazioni delle persone
  • risorse tecniche, come macchinari, impianti fissi, sistemi hardware ICT, applicazioni software etc… che interagiscono tra loro e con cui interagiscono le persone seguendo regolamenti e procedure operative che dovrebbero rendere tale interazione il più efficace ed efficiente possibile (almeno in teoria)
  • risorse informative, come documenti cartacei, files, dati strutturati e non etc… che fluiscono tra risorse tecniche e persone seguendo i processi stabiliti dalle regole organizzative (almeno in teoria)
  • materie prime, semilavorati e prodotti finiti, che entrano nell’azienda, vengono lavorati in stadi successivi e infine vengono venduti sul mercato; questa suddivisione vale anche per beni “immateriali” come filmati o musica; una suddivisione analoga vale anche per le aziende e le organizzazioni che realizzano i servizi.

Ogni parte interessata all’azienda (stakeholder) ha il suo punto di vista (o punto di percezione) diverso, in base al proprio ruolo ed alla propria posizione entro l’azienda (o fuori dall’azienda, considerando anche stakeholder esterni come clienti, fornitori, pubblica amministrazione etc…). Come conseguenza, la sua percezione della realtà dell’azienda è diversa. E, di conseguenza, diverse saranno le sue decisioni e le sue azioni.

Ad esempio, l’ufficio HR si focalizzerà sulle risorse umane (posizioni, stipendi, progressioni di carriera, formazione etc.), i sistemi informativi su alcune risorse tecniche, il direttore di produzione sulle pianificazioni della produzione stessa, il direttore commerciale sulle vendite etc.

E questo focus è ulteriormente ampliato dal fatto che gli indicatori chiave di performance (KPI), in base ai valori dei quali vengono valutati periodicamente i dirigenti, sono molto spesso relativi unicamente al loro ruolo ed ai compiti direttamente associati.

Per esempio, il direttore vendite può essere valutato in base alla crescita del fatturato generato per l’azienda dal suo reparto.Il rischio in questo modo è perdere il punto di vista d’insieme, con conseguenti problemi per l’azienda. E’ infatti molto frequente trovare aziende in cui i singoli uffici e le singole sezioni o divisioni operano molto bene al loro interno svolgendo il loro compito specifico, mentre l’azienda nel suo insieme funziona in modo molto meno efficiente in quanto manca il coordinamento fra le singole sezioni. Tale fenomeno viene spesso indicato come “siloing”, ovvero suddivisione figurata dell’azienda stessa in silos o “compartimenti stagni” che “non si parlano” tra loro.


Arrivare a una visione di insieme

L’idea fondamentale dell’Architettura Enterprise è integrare insieme i diversi punti di vista, permettendo di focalizzarsi su quello ritenuto al momento più importante, ma senza perdere di vista gli altri. Alcune analogie permettono di comprendere meglio questo approccio.

Immaginiamo di essere a teatro ed assistere ad una rappresentazione, oppure di ascoltare un concerto. O di essere al ristorante davanti ad una magnifica tavola imbandita apprezzando i profumi che salgono dai vari piatti.

Se siamo lo spettatore in platea a teatro o al concerto o davanti alla tavola abbiamo un particolare punto di percezione. Siamo “davanti” all’azienda e ne percepiamo il funzionamento complessivo “esterno” con la sua evoluzione nel tempo, come farebbe, ad esempio, un cliente o fornitore. Ma questo è l’unico punto di percezione possibile?

Ovviamente no.
Già se ci muoviamo nella platea o nei palchi o davanti alla enorme tavola la nostra percezione muta. Se siamo in un palco o in loggione il nostro punto di osservazione della scena cambia e non da tutte le posizioni vedremo ugualmente bene il palcoscenico. Se il teatro non è dotato di una buona acustica anche il nostro ascolto cambia in base alla nostra posizione. Se siamo a destra sentiremo maggiormente alcuni strumenti rispetto a sinistra. Se siamo dal lato del tavolo dove sono, ad esempio, i primi, il loro profumo sarà predominante rispetto a quello dei dolci posti all’altro lato.

Se poi entriamo “dietro le quinte” troviamo altri punti di vista, come quello del suggeritore, dei tecnici delle luci, dei tecnici del suono, dei cuochi. O degli attori, dei musicisti, dei camerieri. O del regista, del frontman o del direttore d’orchestra, del capocuoco.

In azienda questi ruoli corrispondono a quelli delle persone addette ai servizi e processi di supporto, alle persone coinvolte nella produzione e nei processi di core business, al management etc.

Quindi il modello di insieme permette di avere sufficienti informazioni per passare da un punto di percezione all’altro, secondo il bisogno e la necessità. La visione di insieme fa emergere le interazioni fra gli elementi, che possono essere la forza o la debolezza di un progetto, di un sistema, di un’azienda. In tal modo diventa possibile prevedere le problematiche, evitando, o quanto meno riducendo, il dover ricorrere all’eroismo delle persone per far funzionare le cose.


Costruire il modello di insieme

L’idea del modello di insieme della Architettura Enterprise è avere uno strumento che evidenzia le parti ed allo stesso modo le relazioni, da cui trarre la descrizione più adatta per il ruolo del singolo stakeholder o parte interessata.

Lo stakeholder, in base al proprio ruolo, ha un interesse per il sistema-azienda. Nella figura, tratta dal sito di ISO 42010, sono mostrati in modo grafico i concetti attraverso un class diagram:

schema

I sistemi (system), in particolare il sistema-azienda, esistono, e sono il punto di partenza della modellazione. In particolare, un sistema è situato nel suo ambiente (environment, nel caso dell’azienda il territorio). Questo ambiente potrebbe includere altri sistemi (altre aziende, la pubblica amministrazione etc.).

Gli stakeholder hanno interessi in uno o più sistema; quegli interessi sono anche chiamati preoccupazioni (system concern). In particolare, lo scopo di un sistema è uno degli interessi più importanti.
I sistemi hanno architetture
(ossia strutture). Una descrizione dell’architettura (architecture description) viene utilizzata per esprimere un’architettura di un sistema.

Nello standard, il termine sistema viene utilizzato senza definirlo in specifico. Ad esempio “sistema” potrebbe riferirsi a un’impresa, a un sistema di sistemi, a una linea di prodotti, a un servizio, a un sottosistema o a un software. Ricordiamo che i sistemi possono essere artificiali, naturali o misti. L’obiettivo dello standard è, per un sistema che interessa, fornire una guida per documentare un’architettura per quel sistema.

Ogni sistema opera entro il suo ambiente. Un sistema agisce su quell’ambiente e viceversa. L’ambiente di un sistema determina la gamma di influenze sul sistema. Nello Standard, l’Ambiente è inteso nel senso più ampio possibile di includere influenze evolutive, operative, tecniche, politiche, normative e tutte le altre che possono influenzare l’architettura. Queste influenze sono categorizzate come preoccupazioni particolari.

Dato che i sistemi hanno strutture, e quindi architetture (ricordando la definizione di architettura sopra vista), una descrizione dell’architettura (AD) è un artefatto o documento che esprime un’architettura. Gli architetti e gli altri soggetti interessati al sistema utilizzano le descrizioni dell’architettura per comprendere, analizzare e confrontare le architetture e spesso come “progetti” per la pianificazione e la costruzione, o per la trasformazione ed il cambiamento. E in particolare per l’adozione proficua della digital transformation.


Uso di un modello di insieme: Zachman Framework

Nel caso particolare dello Zachman Framework, la cui prima edizione risale addirittura al 1980, vengono “presi in prestito” i principi di progettazione aziendale in architettura e produzione, per offrire un modo di vedere i flussi di informazioni e i corrispondenti sistemi informativi da diverse prospettive, mostrando come i componenti dell’azienda sono correlati.

Lo Zachman Framework – esteso nel tempo alla struttura della intera azienda, e non soltanto delle informazioni – è diventato uno strumento di business proattivo, che può essere utilizzato per modellare  funzioni,  elementi e processi esistenti di un’organizzazione. E, soprattutto, può aiutare a gestire i cambiamenti di business. La struttura delle ultime versioni si ispira all’esperienza dell’autore, John Zachman, su come il cambiamento è gestito in prodotti complessi come aeroplani e grandi edifici.

Una rappresentazione utile per la comprensione del funzionamento è nella figura seguente . Il framework è rappresentato come una matrice rettangolare in cui ogni cella rappresenta uno specifico modello parziale. Ad esempio, nella seconda cella da sinistra della seconda riga dall’alto troveremo il modello dei processi di business.

Considerando la combinazione di tutte le celle di una riga, ovvero dei modelli parziali specifici contenuti nelle celle di tale riga, otterremo un modello più ricco di informazioni e specifico per il punto di vista di uno stakeholder particolare. Per esempio, la seconda riga dall’alto è l’insieme delle rappresentazioni a livello di business, che normalmente vengono usate dalla direzione e/o dalla proprietà dell’azienda.

Zachman_Framework

Nella forma rappresentata in figura le righe diventano:

  • Pianificatore (Planner) – comprende l’ambito aziendale e può offrire una visione contestuale dell’impresa.
  • Proprietario (Owner) – comprende il modello di business e può fornire una visione concettuale dell’impresa.
  • Costruttore (Builder) – sviluppa il modello di sistema e può costruire una visione logica dell’impresa
  • Designer – produce il modello tecnologico e può fornire una visione fisica dell’impresa.
  • Integratore (subcontractor) – comprenderà le rappresentazioni dettagliate di specifici elementi nel business, anche se avranno un vista del contesto dell’azienda.
  • Utente (User) – fornisce una visione dell’impresa funzionante, dal punto di vista di un utente (ad es. Un dipendente, un partner o un cliente).

Le colonne invece sono associate ad alcune domande guida “classiche” usate in Business Analysis:

  • What / Cosa (dati) – quali sono i dati, le informazioni o gli oggetti aziendali?
  • How / Come (funzione) – come funziona l’azienda, cioè quali sono i processi aziendali?
  • Where / Dove (rete) – dove operano le imprese? •
  • Who / Chi (persone) – chi sono le persone che gestiscono il business, quali sono le unità aziendali e la loro gerarchia?
  • When / Quando (tempo) – quando vengono eseguiti i processi aziendali, cioè quali sono le pianificazioni commerciali e i flussi di lavoro?
  • Why / Perché (motivazione) – perché i processi, le persone o le sedi importanti per l’azienda, ovvero i fattori di business o gli obiettivi aziendali?

In questo modo vengono “combinati insieme” i modelli specifici sulla base delle domande guida. Per esempio, nel caso in cui lo stakeholder sia un progettista e sia interessato ad un prodotto di cui è necessario migliorare i processi produttivi, le domande guida prendono la forma:

  • Di cosa è fatto il prodotto (WHAT)?
  • Come funziona il prodotto (HOW)?
  • Come sono collocate reciprocamente le componenti (WHERE)?
  • Chi fa che cosa relativamente al prodotto (WHO)?
  • Quando accadono gli eventi rilevanti per il prodotto (WHEN)?
  • Con quale criterio sono prese le varie decisioni in merito al prodotto (WHY)?

In questo modo dal modello di insieme si ritrovano nuovamente i modelli parziali. Nella figura sottostante possiamo vedere un analogo geometrico: le proiezioni ortogonali di un cubo.

 

cubo

Quando proiettiamo una figura solida come, ad esempio, un cubo, verso un piano otteniamo delle figure a due dimensioni la cui forma dipende dalla posizione del piano (e dell’osservatore associato al piano, che rappresenta lo stakeholder) rispetto al cubo stesso.

 


L’applicazione alla PMI Italiana

L’approccio con l’Architettura Enterprise ha dimostrato ampiamente la sua validità ed è stato adottato da grandi organizzazioni come gli enti governativi USA e della UE e le grandi multinazionali. Risulta però spesso “sovradimensionato” rispetto alla PMI Italiana o alla PA, soprattutto per lo sforzo necessario per la sua costruzione nello specifico dell’azienda. Con un approccio simile si arriva ad un modello più facile da realizzare, in grado di dare comunque le informazioni utili.

I processi sono le successioni temporali di azioni e decisioni, che fanno funzionare l’azienda nel suo insieme e che integrano le azioni delle varie suddivisioni organizzative in cui l’azienda è strutturata.

Alcuni processi, come quello delle vendite, si compiono completamente entro una sola divisione, mentre altri, più generali, comprendono l’azione di tante diverse suddivisioni per potersi svolgere. Ad esempio il ciclo attivo, definito come l’insieme delle azioni che portano alla fatturazione di vendita, comprende il magazzino, la produzione, l’ufficio tecnico, le vendite, l’amministrazione etc.
In questo caso, il modello di insieme deve poter essere usato – attraverso le apposite domande-guida – per costruire le dipendenze dei processi dalle varie divisioni, ovvero come le varie divisioni dell’azienda contribuiscono, ognuno per la sua parte, all’andamento del processo stesso.

Nel prossimo articolo vedremo come realizzare questo modello, applicando l’idea della descrizione dell’architettura, partendo da una visione dell’azienda come insieme di centri di servizio.

 

Giulio Destri


Approfondimenti:

Introduzione allo Zachman Framework

CREDITS IMMAGINI (rielaborate)

ID Immagine: 107979969. Diritto d'autore: everythingpossible.

ID Immagine: 43169137. Diritto d'autore: Michal Bednarek.