Reply ti permette di entrare a far parte di una realtà formata da persone da tutto il mondo con la passione per la tecnologia, la capacità di immaginare ed esplorare nuove soluzioni, la voglia di innovare e sfidare lo status quo.Vuoi unirti alla squadra?
Non è difficile trovare esempi di progetti di business o di IT che non sono riusciti a realizzare gli obiettivi. Il motivo (o forse il pretesto?) solitamente addotto è il mancato allineamento o il distacco dalla strategia organizzativa. L’Enterprise Architecture (EA) è stata offerta come parte della soluzione, ma non ha avuto il successo sperato. In molti casi, il modo in cui viene eseguita l’EA e il punto di inizio utilizzato denotano che, nonostante il notevole investimento, l’EA non sta ottenendo i risultati previsti. Perché tutto questo? L’EA è spesso caratterizzata da un considerevole “distacco” o lacuna tra ciò che i progetti di IT forniscono e ciò che è necessario per raggiungere gli obiettivi aziendali. Occorre rimediare a questo distacco. Il tema di tale documento è che un approccio all’architettura supportato dalle competenze è in grado di apportare correzioni fornendo una struttura che permetta alle imprese di ottenere e “riunire” i vantaggi commerciali diretti dal proprio investimento IT.
Quando l’EA viene attuata, in che modo si sviluppa il distacco tra project delivery e obiettivi aziendali? I motivi possibili sono tantissimi:
Per garantire che tutti i progetti e i programmi forniscano un valore commerciale quantificabile, un primo passo fondamentale è chiarire gli obiettivi e i motori aziendali di base dell’impresa. Spesso questi ultimi sono ben definiti, ma non necessariamente strutturati in modo da risultare vantaggiosi per il programme delivery. Gli obiettivi e le strategie di business determinano le “capabilities” necessarie per realizzare la mission aziendale. Un errore comune è iniziare con lo stato tecnologico e dei processi “al presente”, limitando così il pensiero e ponendo dei limiti al progetto.
Sovente agli architetti viene chiesto di descrivere lo stato “al presente” della tecnologia e dei processi di business di un’impresa, ma è frequente che ciò avvenga senza i piani e i progetti originali. Il risultato è un insieme di figure e modelli che rappresentano un’impressione dello stato attuale anziché un’accurata descrizione di ciò che la tecnologia e i processi in atto avrebbero dovuto ottenere. Di conseguenza, la posizione iniziale non riflette davvero lo stato attuale. Lo stato “futuro” è sicuramente più importante. Spesso si impiega troppo tempo a documentare “ciò che è” anziché “ciò che dovrebbe essere”. A meno che lo stato “al presente” non sia già abbastanza buono, impiegare del tempo per catturarne i dettagli è un po’ come vincere la battaglia ma perdere la guerra. Ha di gran lunga più valore accettare che “sia così” e fare uno sforzo per ottenere quello “che dovrebbe essere”.
Numerose architetture diventano shelfware. In altre parole, le architetture vengono create ma il lavoro reale e necessario per sostenere il processo non viene svolto. Di conseguenza, le architetture non forniscono ciò che gli utenti business si aspettano. È come comprare un nuovo sistema surround con 10 canali e non collegarlo al televisore. Si potranno raccogliere i frutti solo dopo l’integrazione della soluzione nell’ambiente.
Solitamente le architetture vengono create dal team IT per conto dell’azienda. Nonostante i notevoli sforzi dei project team, spesso il risultato viene presentato con termini tecnici che entrano troppo nei dettagli di sistemi e applicazioni anziché concentrarsi sui risultati organizzativi. Ciò provoca una frattura tra il team e l’azienda, il vero pubblico per il quale è stata creata l’architecture.
Alcune delle imprese più importanti hanno cominciato a considerare la Capability Architecture come un modo per dare una spinta sia al programma di business, sia ai portfolio dei progetti ITEA partendo dal punto comune costituito dagli obiettivi aziendali prefissati. La Capability Architecture sta prendendo piede, ma attenzione: questo approccio supportato dalle funzionalità ha effetto soltanto se la funzione IT di un’impresa lavora a stretto contatto e in modo specifico con il senior management di altre aree all’interno dell’azienda. Per avere successo, l’azienda ha bisogno di “possedere” numerosi elementi di Capability Architecture, piuttosto che la sola funzione IT.
La Capability Architecture fornisce un framework per descrivere il mondo utilizzando termini comprensibili dalla sfera del “business”. Utilizzando un linguaggio comune, il suo scopo è quello di unire un’impresa da un capo all’altro dei confini funzionali, attraverso mission semplici che collegano attività, approcci e risultati. Una capability è la descrizione di ciò che l’azienda cerca di raggiungere. Spesso deriva dagli obiettivi aziendali globali, che solitamente descrivono una visione e una direzione strategica di alto livello. Una Business Capability può potenziare la disponibilità di attrezzature con maggiore visibilità di prodotti e beni. Ogni obiettivo aziendale fa affidamento su un certo numero di competenze, e quando queste sono in atto è possibile raggiungere l’obiettivo aziendale. In altre parole, se un obiettivo aziendale descrive il “perché” in termini di ciò che l’azienda sta cercando di conseguire, la capability descrive “come e con cosa” è possibile raggiungere tale obiettivo. Per esempio, per aumentare la disponibilità di attrezzature (obiettivo aziendale), serve la competenza nel guardare il dritto e il rovescio dei flussi di attrezzature della supply chain (funzionalità). La mission dell’impresa e gli obiettivi aziendali sono i punti di partenza fondamentali per la capability architecture.
Utilizzando concetti di planning della protezione basati sulle competenze, la Capability Architecture trova le sue basi in una top-down list di “cosa, come e perché” l’azienda dovrà rispondere alle esigenze dei clienti e dell’ambiente operativo. Questo si differenzia dalla percezione bottom-up di quel che è definito “arte del possibile” di un approccio su base tecnologica. Gli obiettivi e le funzionalità aziendali devono essere specifici ed efficaci, laddove la funzionalità va definita in modo strutturato. Tuttavia, la realizzazione di una data funzionalità non è così immediata, soprattutto quando ha inizio il “distacco” tra IT e business. Mentre l’IT capisce il “COSA” nel diagramma (vedi sopra), il “PERCHÉ" e il “COME” sono aperti all’interpretazione. Non stiamo parlando di semplici requisiti, che spesso sono system-oriented, ma di un’articolazione della business capability che va eseguita in un certo modo al fine di ottenere un risultato qualitativo o quantitativo. A complicare ulteriormente la situazione, le competenze possono trovarsi in varie parti dell’impresa causando un conflitto di interessi e caos tra i reparti e le aree dell’azienda. Per esempio, un noto rivenditore di telefoni cellulari e servizi wireless gestiva la promozione delle vendite, offrendo un computer portatile a titolo gratuito ai clienti che firmavano il contratto per il pacchetto a banda larga. Il problema era però che i punti vendita dell’azienda non erano fisicamente in grado di ricevere, immagazzinare ed esporre i computer. La funzionalità necessaria per “raggiungere” l’obiettivo di acquisire la quota di mercato della banda larga non era stata definita, così come non erano stati messi in atto dei piani per affrontare le lacune delle funzionalità esistenti. Occorre quindi applicare un certo tipo di struttura e un certo tipo di regole alla definizione di funzionalità e alle caratteristiche di progettazione.
Le funzionalità vanno descritte “in modo univoco” e senza vincoli. Ciò significa che nella definizione delle funzionalità non devono esserci “e”, né altre congiunzioni. Per esempio, la capacità di ricevere gli ordini ed effettuare la consegna fa riferimento a due operazioni diametralmente opposte che non devono essere raggruppate in una sola definizione. In termini tecnici o di business, in questa fase non è possibile includere alcuna definizione di soluzione. Dopo aver creato e convalidato una singola definizione delle funzionalità, è necessario considerare ulteriori caratteristiche per fornire informazioni correlate agli obiettivi aziendali nel processo di progettazione.
È raro che un programma di cambiamento abbia origine da una sola area dell’azienda: spesso, quando un programma deve rivelarsi un successo, sono più aree ad aver bisogno di cambiare. L’Enterprise Architecture può essere ancora più complessa, ma la Capability Architecture ci consente di essere più rigorosi e di seguire un approccio molto più pragmatico, come mostrato qui sotto in un semplice procedimento in quattro fasi:
Un’architettura supportata dalle capabilities può fornire un certo numero di vantaggi:
L’applicazione della Capability Architecture e del Capability Planning funziona davvero. Reply ha aiutato molti clienti appartenenti a una vasta gamma di aziende ad applicare questo approccio per ottenere vantaggi reali. Per un prodotto aerospaziale ben definito e per un provider di servizi, abbiamo progettato e poi attuato un solido meccanismo che ha fornito un planning delle funzionalità strategicamente elaborato per il potenziamento del business. Il nostro meccanismo ha garantito che il planning si trovasse esplicitamente nel contesto dei risultati aziendali anziché dei prodotti tecnologici finali. Ciò ha fornito l’orizzonte necessario per dare la giusta priorità agli investimenti e per migliorare la concentrazione organizzativa. Il nostro approccio di Capability Architecture ha aiutato un’importante società di telecomunicazioni a livello globale a combinare e aggiornare la sua fornitura di servizi con una nuova funzionalità di vendita. Questo approccio top-down ha garantito la definizione di un livello adeguato e coerente di granularità dei servizi e l’azienda ha individuato l’insieme completo dei servizi legati all’attività, massimizzando il potenziale di riutilizzo. Per due rivenditori alimentari di eccellenza, il nostro approccio di Capability Architecture è stato utilizzato per identificare i requisiti comuni di competenza secondo la strategia aziendale. L’approccio è stato applicato alle numerose unità aziendali e ai canali customer in cui abbiamo creato il framework CA, le Target Architectures, e una Roadmap Business e IT per fornire le Business Capabilities necessarie attraverso un cambiamento congiunto di business e IT.
Numerose realtà stanno “praticando” l’EA, ma soltanto poche lo stanno facendo nel modo corretto. Pare che il distacco tra le strategie di business e IT impedisca all’IT delivery e al portfolio di programmi di raggiungere il giusto valore rispetto al business. Adottando una tecnologia veramente indipendente, l’approccio supportato dalle funzionalità mette in relazione ciò che l’IT fornisce con ciò che il business si aspetta. Siamo certi che l’approccio correlato alle funzionalità sia in grado di farlo fornendo il rigore e la struttura che consentono alle aziende di “mettere in pratica l’EA come inizialmente previsto” e fornire un reale valore commerciale. Creando un lessico comune per ridurre la complessità del portfolio di programmi, la Capability Architecture e il Capability Planning aiutano a concentrare l’attenzione aziendale su ciò che porta veramente alla realizzazione degli obiettivi. Una bella differenza sull’ultima riga del bilancio.