L’isola che non c’è

Tag

, ,

Nuovi modelli di management: ne parliamo con Chiara Montanari

Intervista a Chiara Montanari

Chiara Montanari

Chiara Montanari è capo spedizione per le missioni di ricerca in Antartide ed è una consulente di temi organizzativi in scenari difficili.

È una donna entusiasta del suo mestiere e quindi trasmette passione, oltre che informazioni, e questo rende particolarmente piacevole parlare con lei.

Mi ha fatto sorridere sentirla descrivere l’Antartide un po’ come l’isola che non c’è: dice che di solito non compare nelle cartine in cui le multinazionali mostrano la loro capillare presenza.

In questo contesto Chiara ha sviluppato le sue doti manageriali e di leader (lo so… è una parola molto inflazionata ultimamente) ed è stato quindi naturale invitarla a fare una presentazione da noi in azienda.

A Imola Informatica non facciamo missioni in Antartide ma ci occupiamo di progettare e organizzare i sistemi informativi per grandi aziende.

Spesso ci troviamo in situazioni molto fluide e imprevedibili, per cui l’esperienza e le capacità di Chiara possono darci un contributo significativo.

In particolare stiamo sviluppando un nostro modello organizzativo e un nostro metodo di risoluzione dei problemi partendo dallo studio della teoria della complessità e del pensiero sistemico: due elementi che ci accomunano a Chiara e al suo stile di gestione.

Approfitto della cortesia di Chiara per farle alcune domande.

Perché la teoria della complessità è utile nella gestione di un’organizzazione? Non bastano le teorie classiche del management?

«Più che di teoria si dovrebbe parlare di scienze della complessità, dico questo perché è proprio importante capire che non si tratta di un altro modello che si aggiunge ai milioni di modelli già esistenti, ma di un approccio alle cose. Si tratta di “un modo di vedere il mondo” che include la diversità, la divergenza e le contraddizioni e che ci permette di usare meglio gli strumenti che abbiamo, invece che di usarne altri. Questo, per esempio, è molto utile in Antartide, perché quando ti trovi in pericolo di vita non hai tempo di cambiare gli strumenti o il team a disposizione, devi finire un progetto (oppure salvarti la pelle) con quello che hai in quel momento, così, imparare a riorganizzare le risorse e vedere le cose da molteplici punti di vista può rivelarsi la dimensione più efficace.»

Chiara Montanari in Antartide

Chiara Montanari in Antartide

Molte volte nelle nostre discussioni hai sottolineato l’importanza delle persone e di come dovrebbero essere accompagnate verso prestazioni migliori.

Allo stesso tempo mi hai però raccontato che tu non puoi sceglierti il tuo staff e che devi «fare il pane con la farina che hai a disposizione».

Qual è il primo aspetto di cui ti preoccupi quando ti viene presentato un collaboratore?

«Le basi di ricerca sono sistemi complessi e autonomi in cui ogni specialista è unico e fondamentale per la riuscita della missione. Quindi, rispetto ad un membro del team (preferisco parlare di team più che di collaboratori, per sottolineare che siamo tutti parti di un tutto unico, al di là dei nostri ruoli individuali) direi che ci sono 3 questioni fondamentali

  • La competenza, che evidentemente deve essere alta
  • La vivacità intellettuale (l’Antartide è il regno dell’incertezza, quindi è necessario avere a disposizione persone capaci di cogliere le situazioni e trovare soluzioni)
  • La flessibilità (gli imprevisti sono all’ordine del giorno e bisogna essere molto adattabili per superare alcune circostanze)

Tutto ciò idealmente, perché in effetti non tutti i team sono perfetti, quindi se poi queste caratteristiche non ci sono, bisogna trovare un modo per svilupparle all’interno del team ed in breve tempo. Per questo infatti da molti anni mi sono messa a fare studi e ricerche sulla complessità (centro di antropologia ed epistemologia della complessità di Bergamo).»

In molte organizzazioni vengono favoriti gli “yes-man”, quelli che si adattano al pensiero dominante del momento, eppure Drucker affermava che il dissenso favorisce decisioni migliori.

Qual è la tua opinione? Tu come prendi le tue decisioni?

«Secondo me il dissenso è molto creativo, poiché porta con sé la divergenza di opinioni (ovvero punti di vista differenti sullo stesso oggetto). In Antartide incoraggio anche le discussioni animate se mi pare che ciò serva al team per capire quale sia la strada migliore da percorrere. Chiaramente alla fine sono io l’unica responsabile della decisione presa e anche delle relative conseguenze, ma in un ambiente estremo è impossibile decidere da soli, è sempre necessaria una discussione collettiva per capire quali saranno le conseguenze da varie angolazioni, almeno fino a dove sono visibili.

Trovo molto ironico quando, a volte, mi capita di incontrare dei coach che “spiegano” e “facilitano” il cosiddetto “pensiero laterale” e poi, appena inizia una discussione con qualche accenno a divergenze di opinioni, si affrettano a sedarle. Alla fine, di solito, sintetizzano tutto “per bullet” e affermano che il “pensiero collettivo” è la lista dei commenti individuali legati dal magico “e anche”.

Questa interpretazione del “pensiero collettivo” come mera somma delle parti mi pare abbastanza semplicistica e decisamente riduttiva, sicuramente è molto lontana dall’interpretazione che ne danno sia la scienza della complessità sia le neuroscienze.

Il conflitto è parte integrante di ogni processo di costruzione e come tale dovrebbe essere accettato. La cosa difficile è fare in modo che rimanga confinato al ruolo di divergenza di opinioni su un oggetto e che non sfoci in guerra tra persone. Ovviamente questa è la parte più difficile da gestire ed è proprio qui che emerge la competenza di un “leader”.»

Chiudo ringraziando Chiara per la disponibilità e sono curioso di approfondire insieme a lei i temi di gestione e organizzazione in situazioni complesse.

Chiara Montanari

Chiara Montanari

“Cruscotti” indispensabili per le automobili ma non solo…

Come rendere facilmente fruibili le informazioni elaborate dalle basi dati

Recentemente mi sono occupato, assieme ad alcuni colleghi, di come creare un sistema per agevolare gli utenti nella consultazione delle informazioni estrapolate da base dati di grandi dimensioni, come ad esempio dati elettorali.

In passato la stessa esigenza è stata affrontata con un approccio di tipo generalista per scelta del cliente; sono stati implementati dei report su un insieme di dati per generare documenti con statistiche in forma di tabella diverse a seconda dei parametri indicati dall’utente.

Figura 1 –  Esempio di riepilogo nazionale dei voti per le elezioni dei rappresentanti negli enti suddivisi per gruppi principali (Gr1, Gr2, Gr3, Gr4 e Altri) raggruppati per regione [dati di esempio]

La soluzione non aveva avuto successo a causa di:

  • tempi di attesa lunghi fra la scelta dei parametri e la produzione delle informazioni
  • difficoltà nel capire le informazioni prodotte.

È evidente che l’attività richiede soprattutto una comunicazione efficace. Di conseguenza, prendendo spunto da un libro sull’infografica (Design della mente di Bottazzini e Gotuzzo), abbiamo pensato ad un approccio orientato a presentare le informazioni in forma grafica e specifiche per le esigenze dell’utente a cui sono rivolte.

Una soluzione efficace: i “cruscotti”

Il nuovo approccio si basa sulla realizzazione delle dashboard, tradotto in italiano cruscotti. Come il cruscotto dell’automobile permette di capire velocemente la velocità del veicolo, lo stato del motore, il livello del carburante e altre notifiche, anche le dashboard di un sistema informativo devono presentare le informazioni rilevanti in maniera semplice e immediata.

Ma come si realizzano dei “cruscotti” efficaci?

La risposta, suggerita dal libro, è nel seguente processo:

  1. Definire a chi è rivolto il cruscotto.
  2. Selezionare l’insieme di dati.
  3. Definire, per l’insieme dei dati scelto, cosa mostrare o meglio quale storia raccontare.
  4. Definire la forma grafica giusta per rispettare i vincoli individuati precedentemente.

Per l’ultimo punto è fondamentale poter avere uno strumento per visualizzare i dati in diverse formati grafici per simulare in maniera veloce la rappresentazione finale. Nel nostro caso si è utilizzato lo strumento Pentaho e ci siamo concentrati molto su parte grafica, tipologie di caratteri, scelta dei colori, tipi di grafici.

I valori aggiunti sono stati l’inserimento dell’interazione dell’utente con il cruscotto e la navigazione fra i cruscotti.

Il risultato è il seguente:

Figura 2 – Riepilogo dei voti e dei seggi raccolti dai rappresentanti degli enti a livello nazionale con dettaglio per regione nel riquadro in basso a destra, ad esempio il Veneto [dati di esempio]

Spostando il mouse sulla mappa in corrispondenza della regione, l’utente fa apparire un tooltip con un dettaglio dei voti e dei seggi e il rapporto degli iscritti agli enti [dati di esempio]

Figura 4 –  Cliccando sulla regione nella mappa viene mostrato il dettaglio nel riquadro in basso a destra, ad esempio la Sicilia [dati di esempio]

In conclusione, per una presentazione efficace delle informazioni è necessario analizzare le esigenze degli utilizzatori del sistema e quindi scegliere le modalità di comunicazione che le rendono fruibili nel modo più semplice, immediato e produttivo.

L’Enterprise Architecture, da diversi punti di vista

Tag

, , , , ,

Questo post è il secondo di una mini serie dedicata alla gestione delle informazioni in contesto Enterprise Architecture (EA) iniziata con Gestire le informazioni di EA con… senso! dove spiegavo come il contesto di EA si prestasse alla modellazione semantica delle informazioni.

Cinque viste diverse

Per poter descrivere e gestire in maniera completa e coerente le diverse dinamiche di gestione dell’EA e governance dei dati è fondamentale individuare le diverse viste (view point) da cui le informazioni possono essere osservate e i vincoli a cui sono sottoposte.  In particolare, le informazioni devono:

  1. essere logicamente distinte fra loro
  2. poter evolvere e specializzarsi indipendentemente
  3. poter essere facilmente correlate e integrate fra loro per dare la visione d’insieme

Da letteratura possiamo identificare almeno cinque viste o livelli (layer) diversi, indispensabili per descrivere l’EA e riconosciute da tutte le principali metodologie (es. ITIL, TOGAF ecc.):

  • Vista business – Tutti i concetti e le relazioni direttamente afferenti al modo business dell’azienda e di solito usati dai gruppi business (macroprocessi, processi, attività, servizi business, entità di business ecc.)
  • Vista architetturale – Tutti i concetti e le relazioni che afferiscono alle dinamiche architetturali dei sistemi IT e di solito usati dai gruppi architetture (concetti della SOA, framework, linee guida, piattaforme, componenti ecc.)
  • Vista applicativa – Tutti i concetti e le relazioni che servono per descrivere il dominio applicativo e di competenza dei vari gruppi applicativi (applicazioni, componenti applicative, dipendenze applicative/flussi ecc.)
  • Vista infrastrutturale – Tutti i concetti e le relazioni coinvolti nelle dinamiche di dominio infrastrutturale e usati dai vari gruppi infrastrutture/operation (componenti infrastrutturali, hardware, software, server/host, data center, reti ecc.)
  • Vista organizzativa – Tutto quanto rappresenta gli aspetti organizzativi dell’azienda. Tale dominio solitamente è particolare in quanto trasversale rispetto agli altri (persone, responsabili, ruoli/profili, unità organizzative, organigramma, compagnie di gruppo, organizzazioni ecc.)

La stessa informazione può quindi (e deve) essere scomposta in viste diverse da n punti di osservazione differenti che coincidono con specifici domini/aree aziendali: Le informazioni verranno poi ricomposte/riaggregate all’occorrenza in base alle necessità del momento (un problema da risolvere, documentazione da produrre, report da generare, una domanda puntuale a cui rispondere ecc.).

Diverse viste di un solido come metafora delle informazioni di EA

Un esempio reale nell’ambito bancario

Consideriamo per esempio un’applicazione banca per la disposizione di bonifici online. Proviamo a scomporre le informazioni relative a tale applicazione rispetto alle viste che abbiamo elencato sopra:

  • Vista business: l’applicazione implementa molte delle funzionalità fondamentali nel processo di business denominato “Disposizione Bonifici”, come per esempio la ricerca in una anagrafica di destinatari, implementa il front-end di immissione delle coordinate e di tutti i dati necessari o ancora la creazione della transazione e l’avviso sull’esito via SMS o altro canale. Tutte queste sono diverse attività di business del processo di business padre “Disposizione Bonifici”.
  • Vista Architetturale: dalla prospettiva dell’architettura IT, l’applicazione deve rispondere a determinate linee guida e pattern architetturali, espone dei servizi riusabili in ottica SOA e viene sviluppata usando specifici framework tecnologici.
  • Vista applicativa: in questa ottica l’applicazione ha diversi attributi tecnici che la descrivono e viene formalmente classificata rispetto ad una tassonomia (es. ABI Lab). Può inoltre può essere composta da diverse sottocomponenti tecnologiche riusabili che ne implementano le diverse sotto-funzionalità. L’applicazione bonifici ha delle dipendenze applicative (flussi) verso altre applicazioni/componenti applicative per richiedere dati o servizi o aggiornarne altri dati di cui non è master.
  • Vista infrastrutturale: l’applicazione e le sue componenti applicative sono “deployate” su application server o su ESB o ancora useranno uno specifico DBMS che gira (in cluster o meno) a sua volta su macchine fisiche o virtuali in base agli ambienti (sviluppo, produzione o test).
  • Vista organizzativa: L’applicazione ha diverse relazioni con diverse unità organizzative e persone fisiche in termini di referente tecnico, funzionale o responsabile business. Tali responsabilità potrebbero essere ereditate verso l’alto nell’organigramma (un’unità è responsabile indirettamente delle applicazioni di cui sono responsabili le sottounità).

Nella modellazione semantica tutte queste viste vengono rappresentate da modelli formali diversi (logicamente distinti da diversi namespace) fra loro indipendenti ma interconnessi da relazioni cross (trasversali) definite ad un livello più alto che li armonizza (state model) in modo da restituire la visione di insieme: quella dell’EA appunto.

Viste business, architetturale, applicativa e infrastrutturale integrate fra loro nello state model

NEL PROSSIMO ARTICOLO…

…faremo un sunto dei primi due articoli cercando di enfatizzare i concetti cardine dell’approccio semantico con qualche spunto di riflessione.

To be continued… 😉

Gestire le informazioni di EA con… senso!

Tag

, , , , , ,

Introduzione

Questo post vuole essere il primo di una mini serie dedicata all’argomento della gestione delle informazioni in un contesto particolarmente complesso come l’Enterprise Architecture (EA).

In particolare cercherò di spiegare l’approccio che Imola Informatica adotta ormai da diversi anni basato sull’uso di tecnologie semantiche al fine di enfatizzare come ciò che conta nella gestione delle informazioni non sia tanto la forma ma piuttosto il SENSO che le informazioni assumono per le persone che le osservano ma anche per le macchine che le usano.

Significato Vs. Struttura

Enterprise Architecture: un contesto perfetto per dare senso ai dati

Occuparsi di Enterprise Architecture vuol dire in primis governare la complessità di una azienda passando necessariamente per la capacità di integrare informazioni di Business, IT e organizzative con una visione sistemica e globale.
Questo significa riconoscere le relazioni causali e soprattutto non causali fra Business e IT in modo da comprendere le interdipendenze fra le varie parti di un sistema complesso come quello IT per esempio di una banca e definire le migliori strategie evolutive, di gestione del demand o del rischio.

In un tale contesto la gestione delle informazioni diventa attività fondamentale e altamente critica.  Si deve infatti agire in modo che le informazioni siano:

  1. Condivise e non recluse nelle “scrivanie” dei vari responsabili di dominio
  2. Indipendenti da logiche applicative e non designate per su uno strumento specifico
  3. Facilmente integrabili fra loro e non ridondate ed inconsistenti
  4. Mantenute vive ed aggiornate e non censite da zero ogni volta
  5. Facilmente riusabili per scopi non conosciuti a priori e non usa e getta per un singolo uso.

Il modello formale delle informazioni dovrebbe descrivere il perimetro business e quello IT integrandoli e rispettando terminologia, relazioni e consuetudini aziendali per essere il più possibile compreso e condiviso da tutti (una sorta di dizionario globale).

Non può quindi essere un modello vincolato ad uno specifico strumento ma piuttosto dovrebbe emergere bottom-up in maniera iterativa dalle diverse aree ed esperienze aziendali in modo da rappresentare una visione realistica e di insieme del particolare sistema azienda.

L’approccio che Imola Informatica ha maturato negli anni di esperienza presso i clienti mette al centro delle attività di EA la definizione e condivisione di modelli semantici delle informazioni di Business e di IT detti “ontologie” e rappresentati in un formato standard RDF/OWL.

Una ontologia di EA descrive i concetti e le relazioni fra i concetti in modo da modellare le principali dinamiche di EA. Vengono definite a partire da modelli più generici e via via specializzati per lo specifico contesto del cliente. In tal modo nessuno modello ontologico risulta mai uguale ad un altro – si pensi per esempio alle diverse possibili accezioni del concetto “Servizio” che si possono avere e di relazioni con esso.

Rappresentazione degli snapshots temporali e roadmap

Una delle prerogative della modellazione semantica delle informazioni è quella di rendere possibile rappresentazione della dimensione evolutiva di un sistema (linea temporale) tramite la descrizione di specifici stati detti snapshot (metafora nata dalla parola inglese per “foto istantanea”). Ciò permette di definire una roadmap aziendale tramite una serie di step intermedi per raggiungere specifici obiettivi («TO-BE») a partire dallo stato attuale («AS-IS»)

Nel prossimo articolo…

Vedremo più in dettaglio quali siano le diverse viste indipendenti dell’EA, come possano essere formalizzate in modelli ontologici e riconciliate fra loro per creare una unica vista di insieme. Per capire meglio faremo anche un piccolo esempio.

To be continued… 😉

Aggiornamento 15 febbraio 2017 – Nuovo post: L’Enterprise Architecture, da diversi punti di vista.

ZFS e container su Linux? Ecco come, su Ubuntu

Tag

Volete ottenere una densità dieci volte superiore rispetto a quella delle virtual machine? E avere la possibilità di utilizzare funzionalità avanzate come block deduplication, copy-on-write o snapshot?
Ora è possibile senza rinunciare a Linux e all’Open Source.

Le prime prove che abbiamo effettuato in laboratorio sono molto promettenti.

Un container con Tomcat ed una web app girano in qualche centinaio di MB in memoria. E la partenza di un nuovo container richiede qualche secondo.

Fino ad oggi ZFS e i container erano supportati solo su sistemi operativi che derivavano da Solaris, ad esempio SmartOS.

Dal rilascio di Ubuntu 16.04, ZFS è supportato da Canonical. E il sistema di container lxd ne consiglia l’utilizzo.

Sfruttare i vantaggi di ZFS e dei container su Linux non è mai stato così semplice. Per configurare un sistema di container con ZFS è sufficiente digitare questi comandi:

$ sudo apt install lxd zfsutils-linux
$ sudo lxd init

Per chi fosse interessato ad approfondire l’argomento, ho trovato molto utili le informazioni fornite da questi siti:

Introduzione a lxc e lxd

ZFS is the FS for Containers in Ubuntu 16.04

Enterprise architecture ed esami di “maturità”

Tag

,

worry student have a problem with mathematics

Una delle frasi ricorrenti che sentiamo dire dai clienti quando proponiamo o iniziamo con loro un percorso di enterprise architecture è “non siamo ancora maturi”: i dati non sono maturi, l’organizzazione non è matura, le persone non sono mature…
Ma cosa significa “essere maturi” dal punto di vista dell’enterprise architecture e quando un’organizzazione può considerarsi tale?

Il grado di maturità è legato al livello di conoscenza, condivisione e accettazione nell’organizzazione del processo e del modello dati di enterprise architecture. Compito dell’enterprise architect è promuovere una visione d’insieme dell’azienda, integrando informazioni potenzialmente eterogenee con livelli di dettaglio differenti dalle diverse aree e riconducendole ad un modello comune e condiviso. L’obiettivo è allineare le iniziative di evoluzione IT alle strategie aziendali fornendo viste sui dati (business, architetturale, applicativa, infrastrutturale, organizzativa) adeguate alle esigenze dei vari interlocutori. Il livello di maturità dipende quindi da quanto il processo di enterprise architecture incide sulle decisioni all’interno dell’organizzazione.

Sfortunamente dati, organizzazione e persone non maturano da soli. Se i dati e il modello non sono gestiti si rischia di trarre conclusioni basate su una fotografia che non corrisponde più alla realtà. Aggiornare dei dati obsoleti può avere dei costi molto elevati perché il divario può diventare talmente alto da vanificare gli sforzi iniziali, il che equivale quasi a ripartire da zero. Se non si coinvolgono le persone nel miglioramento dell’enterprise architecture le decisioni possono apparire come calate dall’alto, le informazioni possono risultare incomplete, inesatte o non del grado di dettaglio utile, di fatto diminuendo la credibilità e il livello di condivisione del processo e del modello dell’EA.

La buona notizia è che un percorso di enterprise architecture può essere intrapreso in modo graduale. Quando un’organizzazione si interessa ai temi di EA perché è consapevole che dover ricostruire lo stato corrente dei propri sistemi a ogni nuova iniziativa non è utile né efficace ha già un grado di maturità sufficiente per iniziare. Si può partire da qualsiasi area, in generale quella su cui si ritiene di avere più informazioni o si pensa che siano più facili da recuperare (processi? applicazioni? infrastruttura?). Si può proseguire per passi, aggiungendo i dati necessari per lo scopo che si vuole ottenere, mantenendo aggiornati quelli esistenti e migliorandone la qualità, coinvolgendo gli interlocutori potenzialmente interessati e cercando di fornire ad ogni passaggio analisi e informazioni significative.

Non esiste quindi un esame di maturità finale perché non c’è un punto di arrivo definitivo. L’enterprise architecture è un’attività continua che deve seguire e agevolare i cambiamenti all’interno dell’organizzazione.

Innovazione e architetture IT

Tag

, , , ,

L’information technology (IT) genera innovazione continua e saperla accogliere all’interno del proprio sistema informativo è all’ordine del giorno di ogni azienda competitiva che eroga servizi software.

Nella mia esperienza, la sfida risiede nel coniugare i seguenti aspetti:

  • acquisizione di nuove competenze: l’utilizzo di tecnologie e metodologie emergenti richiedono formazione e un nuovo assetto nella gestione del personale. Questo investimento non è sostenibile da tutte le imprese e spesso si scontra con un organico sottodimensionato e già oberato di attività;
  • integrazione con i sistemi esistenti: un’azienda IT ha un sistema informativo basato su una pluralità di soluzioni software che si sono succedute nel tempo. Saper conciliare le nuove tecnologie con quelle già presenti è un punto cruciale per un’adozione fattibile;
  • aggiornamento dei processi aziendali: il governo di una tecnologia è una precondizione per il suo utilizzo continuativo nel tempo. L’impresa deve aggiornare i processi interni per una gestione corretta della propria normale operatività;
  • gestione del rischio: spesso il fattore che limita il “cambiamento” è la paura delle possibili conseguenze negative (frase tipica: “è sempre andato bene, perché cambiare?”). Deve essere la lungimiranza a guidare: l’integrazione di una nuova tecnologia deve avvenire attraverso un piano prestabilito con lo scopo di creare il minor numero di problemi a tutto l’ecosistema software esistente.

In questo scenario considero fondamentale l’architettura IT perché ha il compito di “abilitare all’innovazione”. Questa disciplina detta i principi base e le linee guida di evoluzione di un sistema software dal punto di vista sia tecnologico che di processo e con l’obiettivo di governare e ridurre le problematiche descritte.

La centralità delle architetture IT è rimarcata dal tema della multicanalità: i clienti che usufruivano di servizi erogati solo attraverso il Web ora richiedono di accedervi anche con altri strumenti quali smartphone e tablet.

Innovazione e multicanalità richiedono ai sistemi informativi una “maturità” valutata dall’architetto IT sulla base degli stessi principi con cui lui modella un’architettura:

  • genericità: l’architettura non deve dipendere da uno specifico scenario di utilizzo e da un insieme prestabilito di tecnologie. Deve essere in grado di adattarsi nel tempo a nuovi contesti;
  • disaccoppiamento: i pezzi che compongono il modello di un’architettura devono essere fra loro indipendenti. Si raggiunge questo concetto utilizzando standard open per realizzare le interazioni fra i vari componenti;
  • manutenibilità: ciascun componente architetturale ha un proprio ciclo di vita che deve essere indipendente dagli altri. In questo modo risulta più semplice la gestione delle evoluzioni e la risoluzione di errori;
  • facilità di integrazione: il modello architetturale deve essere tale da accogliere con semplicità nuovi componenti;
  • scalabilità: a fronte di un elevato utilizzo del sistema informativo deve essere possibile modificare l’architettura in modo tale da sostenere il nuovo carico.

Credo che l’architettura IT debba essere un elemento di continuità all’interno di un’azienda e che richieda personale dedicato: instaura un processo di cambiamento non solo del sistema informativo ma anche alla cultura stessa delle persone perché impatta il loro modo di lavorare e comunicare.

Solo con una reale presa di coscienza di questo tema è possibile fare il salto di qualità e dare la possibilità alla propria azienda di innovare.

Enterprise architecture: un interesse crescente

Tag

, ,

03rotterdam-oma-13-12-6345

Iwan Baan Photography, Rozenstraat 145, 1016 NP Amsterdam, The Netherlands e-mail: studio@iwan.com — all images © Iwan Baan 1996 – 2016

Negli ultimi decenni, per motivi economici, sociali e tecnologici la gestione di organizzazioni e aziende di grandi dimensioni ha raggiunto livelli di complessità tali da rendere insufficienti gli approcci classici. E’ stato quindi necessario individuare nuove metodologie, nuovi processi e nuovi strumenti. Per questo motivo si parla spesso di enterprise architecture come disciplina fondamentale per affrontare questa crescente complessità. Ma di che cosa si tratta e perché tanto interesse?

Se si pensa al significato più tradizionale del termine “architettura” viene in mente il disegno degli elementi che costituiscono una struttura e delle loro interazioni. L’enterprise architecture riprende questo concetto estendendolo alle organizzazioni. Fare enterprise architecture significa quindi descrivere l’architettura di un’organizzazione (enterprise) in tutti i suoi aspetti, a livello di business, di processi e di sistema informativo gestendo e analizzando i dati tramite metodologie adeguate. L’obiettivo è fornire le informazioni, le linee guida e gli strumenti necessari ai vari interlocutori per poter prendere decisioni consapevoli e avviare iniziative efficaci come risposta alle sfide e ai cambiamenti che coinvolgono le organizzazioni.

Nel settore finanziario una delle spinte principali che hanno incrementato l’interesse verso l’enterprise architecture è stata l’introduzione della normativa 263 della Banca d’Italia. Alcuni temi inseriti nella normativa sono la gestione dei rischi, della sicurezza, dei dati e della continuità operativa. Le banche hanno dovuto adeguarsi e, in qualche caso, dotarsi di processi e strumenti per governare i loro sistemi informativi.

Un altro fattore fondamentale è stato l’aumento del numero di fusioni e acquisizioni. Le società acquisite oltre ad essere strutturate in modo diverso hanno anche processi e IT eterogenei che occorre gestire e uniformare senza dare discontinuità di servizio, riducendo la complessità e i costi, mantenendo i dati ed eliminando eventuali duplicazioni funzionali. L’enterprise architecture fornisce la metodologia per costruire una mappa dei vari sistemi che lega le applicazioni ai processi di business e alle organizzazioni, fino alla parte tecnologica e infrastrutturale, in modo da poter valutare gli impatti dei cambiamenti, tempi, rischi e costi.

 

Affidabilità del software e semplicità delle architetture

Negli ultimi tempi sto affrontando tematiche relative a DevOps, container e infrastrutture resilienti. E sono sempre più convinto di un pensiero un po’ contro corrente nell’immaginario degli architetti software.

Spesso, per ottenere soluzioni in grado di resistere ai guasti, si realizzano architetture complicatissime. Configurazione e manutenzione di storage e application cluster sono aspetti che hanno impatto sul grado di affidabilità.
La configurazione e il test di sistemi complessi sono attività difficili. Nella mia esperienza di valutazione e revisione di architetture applicative mi è capitato spesso di notare che alla base della scarsa affidabilità di un sistema sono proprio le configurazioni sbagliate delle componenti utilizzate per proteggere dal fallimento.

Mantenere il sistema più semplice possibile, quindi, è un obiettivo da perseguire nella progettazione del software e delle infrastrutture. In certi casi conviene mettere in conto fallimenti, purché accadano di rado. Ripristinare un sistema più semplice è un’attività che avviene in tempi rapidi.

Dunque, quale può essere una strategia vincente? Non cercare di evitare tutti i possibili disastri, ma fare in modo di essere sicuri di poter gestire le conseguenze in modo semplice. Soprattutto quando questo semplifica molto il sistema che stiamo realizzando.

Aziende sull’orlo di una crisi di nervi

Tag

,

Citazione dal file "Tempi moderni"

Citazione dal file “Tempi moderni”

Negli ultimi anni abbiamo assistito a una serie di cambiamenti che hanno messo in crisi le aziende su molti aspetti. Uso l’espressione “crisi di nervi” perché nelle aziende sono saltati, o stanno saltando, i modelli tradizionali di gestione [001].

Ma cosa è realmente successo alle organizzazioni?

A mio parere, 2 parole chiave archiviate con il XX secolo sono ‹‹pianificazione›› e ‹‹isolamento››: due concetti fondanti del taylorismo [002] e più in generale delle teorie manageriali [003].

Non è un caso che negli ultimi anni siano emerse molte discipline alternative, spesso identificate con il termine ‹‹agile management›› [004]. Tuttavia queste discipline sono spesso applicate in contesti verticali e di piccole dimensioni, per cui non possono incidere in modo significativo sull’organizzazione nel suo complesso.

Ma cosa non funziona più?

In termini organizzativi si è sempre seguito il concetto del ‹‹dividi et impera››, che gli inglesi hanno poi tradotto in segregation of duties. Si è sempre pensato di poter suddividere le funzioni aziendali, e in particolare quelle operative, in attività singole e indipendenti.

Una volta suddivise le attività, e quindi le responsabilità, è sufficiente avere un gruppo di lavoro specializzato per ogni attività e un livello superiore di controllo per verificare gli avanzamenti o, più in generale, le performance.

Questo modello funziona bene se l’azienda è capace di pianificare con continuità le proprie scadenze. Se invece il lavoro diventa discontinuo, come nei mercati attuali, allora ci sono molte più giornate con un fermo di produzione e questo è un problema serio quando si segue il modello della fabbrica.

In pratica, il gruppo di lavoro risulta sovradimensionato rispetto alla mole assoluta degli ordini, ma non può essere ridimensionato perché non sarebbe in grado di far fronte ai picchi di lavoro. Allo stesso tempo c’è il rischio di avere altri gruppi sottodimensionati, ma di non poterli aiutare perché l’isolamento organizzativo impedisce di fatto una collaborazione.

In questo caso il primo effetto evidente è la riduzione dei margini operativi [005] delle aziende e quindi occorre una spinta sul management per cercare di cambiare le cose.

Ma perché l’isolamento organizzativo amplifica il problema?

In base alle teorie di Taylor, per ogni mansione viene identificato un profilo ideale di lavoratore, uno specialista.

Questo significa che se un gruppo di lavoro risulta sovradimensionato, allora è difficile ricollocare le persone in altri gruppi proprio perché sprovviste delle competenze necessarie.

Inoltre, per le stesse teorie, non è banale nemmeno pensare di riqualificare le persone per favorirne l’inserimento in nuovi gruppi: potenzialmente è troppo grande il divario tra i profili diversi per pensare a una formazione utile in concreto [006].

In questo scenario, le risposte in termini gestionali sono state:

  • Lasciare le cose come stanno e lavorare sul flusso e il volume degli ordini
  • Licenziare il personale in eccesso e assumere le figure che mancano
  • Esternalizzare le parti di produzione più difficili da dimensionare.

La prima risposta è la preferibile perché ricrea il contesto originale di funzionamento dell’azienda e quindi risolve i problemi, ma è anche la più difficile da realizzare.

La seconda è quella più banale ma meno interessante, perché rinvia solo il problema nel tempo e causa forti tensioni sul personale, e introduce altri fattori di rischio.

La terza è l’opzione che consente i risultati migliori nel breve periodo, ma sposta il problema sui fornitori anziché risolvere effettivamente il problema. In ogni caso, questa opzione è largamente utilizzata [007]: l’azienda può così dedicarsi agli aspetti di maggior valore aggiunto e acquistare sul mercato quello che manca per la creazione di prodotti e servizi.

Quindi problema risolto? … nemmeno per sogno!

Quando viene esternalizzata una parte dell’azienda c’è una perdita di conoscenze che può tradursi in una minor competitività dell’azienda.

A questo si deve aggiungere il rischio di dipendere da uno o più fornitori. È una situazione che ho potuto osservare personalmente molte volte: l’azienda si riduce alla gestione del brand e alla rivendita di prodotti e servizi pensati da altri, mentre le attività di ricerca e sviluppo restano limitate.

Per queste ragioni è importante pensare soluzioni organizzative diverse.

AAA cercasi T-shape person !!! [008]

Dopo anni di ricerca del profilo ideale e con la massima specializzazione, ora dobbiamo cercare profili più flessibili. Figure capaci di dialogare con persone che lavorano su diverse discipline e che, quando serve, possano offrire loro un supporto.

T

Non ho statistiche ma riporto la mia esperienza diretta a supporto della funzione HR della mia azienda.

Ho l’impressione che i profili flessibili siano molto difficili da trovare. Noi, per esempio, selezioniamo laureati con voti molto alti e quelli che si inseriscono meglio in azienda sono persone con forti interessi extra lavorativi … Ogni tanto scherzo con i colleghi dicendo che per noi tutti in verità questo è un secondo lavoro, perché il primo è altrove.

Questo è comunque solo l’inizio!

Se lasciati fermi su un ruolo troppo a lungo allora queste persone perdono l’abitudine al confronto e al cambiamento. Pur partendo da una risorsa più flessibile c’è il rischio che tali caratteristiche vadano perdute perché azienda e lavoratore sono rimasti nella propria comfort zone [009] per troppo tempo.

Gestire questo tipo di risorse è quindi molto più complesso rispetto alla gestione di specialisti su incarichi immutabili (o quasi), perché anche l’azienda deve evolversi culturalmente per sostenere questo tipo di situazione.

Ovviamente le figure specialistiche non devono sparire, ma non possono essere predominanti altrimenti l’azienda risulta troppo resistente al cambiamento.

Altre forme di isolamento organizzativo: il sistema di budgeting [011]

Fin qui abbiamo parlato di risorse umane, ma supponiamo per un attimo di avere persone completamente intercambiabili. Riusciremmo a spostare le persone dove serve? … Forse sì o forse no!

Per farlo, i manager delle strutture organizzative classiche [012] dovrebbero usare le proprie risorse per raggiungere gli obiettivi di altri gruppi di lavoro oppure dipendere da altri per conseguire i propri.

E, in particolare, se un gruppo di lavoro è riconducibile a un centro di costo [013] o a un budget predefinito, i diversi manager coinvolti devono trovare una serie di regole di ingaggio per poter attribuire in modo corretto le competenze dei costi relativi al l’uso delle risorse.

Difficile pensare che questi accordi siano veloci e indolore. È più facile immaginare lunghe ed estenuanti riunioni fra chi ha l’opportunità di trovarsi in una posizione dominante e chi rischia di fallire i propri obiettivi.

Purtroppo ho vissuto più volte situazioni di questo genere e non si sono mai tradotte in maggior flessibilità.

Verso la distensione

È quindi facile capire perché le aziende siano sull’orlo di una crisi di nervi. Esse debbono infatti:

  • Rivedere la strategia sulle risorse umane
  • Capire come attuare una strategia di esternalizzazione che non impoverisca l’azienda
  • Rivedere il sistema di budgeting per facilitare gli obiettivi aziendali a scapito di quelli dei singoli manager

Tutto questo ovviamente continuando a fare business.

C’è quindi tanto da fare e, come dice un mio cliente, al cambiamento siamo tutti favorevoli purché a cambiare siano gli altri [014]. Difficile quindi indicare da dove iniziare.

In ogni caso, come consulente devo iniziare a pormi la domanda e, se possibile, anche ad abbozzare una risposta.

Prima di tutto penso che gli interventi debbano essere piccoli, costanti e progressivi. Diversamente le incognite crescono più velocemente rispetto alla nostra capacità di analizzarle e affrontarle, ottenendo il cosiddetto effetto farfalla [015].

Si potrebbe quindi pensare che una delle funzioni aziendale in cui l’azienda studia se stessa, così da poter individuare i punti su cui intervenire di cesello anziché con ristrutturazioni pesanti e dolorose.

In questo contesto l’Enterprise Architecture [016] è la disciplina che potrebbe svolgere tale funzione.

Questo gruppo di lavoro dovrà essere collocato il più vicino possibile al vertice aziendale, in modo tale da poter influire in modo concreto. Diversamente, si rischia di introdurre un costo senza capirne bene i vantaggi.

Questo gruppo deve analizzare i diversi settori dell’azienda, per cui è importante che sia composto da persone con diverse competenze. In questo modo le soluzioni proposte saranno più adatte alla complessità della situazione esaminata [017].

È quindi impossibile indicare l’elenco delle soluzioni da applicare a tavolino, perché ogni azienda avrà le sue caratteristiche. Una cosa è certa: il vertice aziendale dovrà dare prova di coraggio perché, come diceva Winston Churchill, il coraggio è la prima delle qualità umane, perché garantisce tutte le altre.

 

Riferimenti

[001] www.treccani.it/enciclopedia/l-impresa-di-terzo-millennio_(XXI-Secolo)

[002] https://it.wikipedia.org/wiki/Taylorismo

[003] https://it.wikipedia.org/wiki/Direzione_aziendale

[004] https://en.wikipedia.org/wiki/Agile_management

[005] https://it.wikipedia.org/wiki/Margine_operativo_lordo

[006] http://www.aidp.it/riviste/articolo.php?id=1&ida=1318&idn=156&idx=

[007] http://adapt.it/adapt-indice-a-z/wp-content/uploads/2013/07/Esternalizzazioni_in_Italia.pdf

[008] https://en.wikipedia.org/wiki/T-shaped_skills

[009] https://en.wikipedia.org/wiki/Comfort_zone

[011] https://it.wikipedia.org/wiki/Controllo_di_gestione

[012] https://it.wikipedia.org/wiki/Organizzazione_aziendale#Macrostruttura_a_matrice

[013] https://en.wikipedia.org/wiki/Cost_centre_(business)

[014] www.slideshare.net/cbergamini/governare-la-complessita-e-favorire-il-cambiamento

[015] https://it.wikipedia.org/wiki/Effetto_farfalla

[016] https://it.wikipedia.org/wiki/Enterprise_architecture

[017] https://en.wikipedia.org/wiki/Variety_(cybernetics)