Per oltre un decennio, i sistemi di analytics includevano generalmente un enterprise data warehouse (Edw) centralizzato e una raccolta dei dati era organizzata in differenti data mart suddivisi per specifico dominio. I dati venivano ‘spostati’ all’interno di questi sistemi ad orari ben definiti utilizzando per le movimentazioni strati di middleware altamente specializzati per supportare questo tipo di workload. I sistemi Edw hardware erano piuttosto costosi e richiedevano competenze specialistiche per poter essere programmati e configurati. Le organizzazioni avevano differenti sfide da affrontare, sottolinea l’analista di Forrester, Gene Leganza: capire come poter generare ritorni utili rispetto agli investimenti sugli asset hardware; disegnare correttamente le architetture ed i sistemi correlati; assicurarsi che i processi batch dei dati fossero eseguiti puntualmente come pianificato e programmato.
Da questa sommaria descrizione, rapportandola ai sistemi più moderni ed attuali di Business Analytics, appare immediatamente evidente che le architetture Edw tradizionali avevano un enorme limite, quello di non poter essere sincronizzati agilmente con i bisogni e gli obiettivi di business. I primi progetti di Business Intelligence, in effetti, furono fallimentari, per svariate ragioni che Leganza riassume così:
1) le aziende non avevano ben chiari i benefici della BI: stando ad alcune analisi condotte da Forrester nell’ultimo decennio (facendo quindi una sorta di ‘media’ su un panel di diverse centinaia di aziende, soprattutto di tipo large enterprise, i cui risultati sono racchiusi nel report ‘Forrester’s business technographics global data and analytics survey’ del 2014), solamente il 45-46% dei business decision maker ritiene di essere stato ‘meglio informato’ nelle proprie decisioni di business dall’utilizzo di questi sistemi; il 35% sostiene di aver avuto un miglioramento nella pianificazione del business ed un 29% pensa di averne guadagnato sul fronte dell’interazione con i clienti e della loro soddisfazione [le percentuali tengono conto di sistemi di domande a risposta multipla – ndr]. La poca chiarezza sui reali vantaggi derivava anche dalla difficoltà di accedere a use case concreti e ‘chiarificatori’.
2) le aziende non potevano ‘fermare’ la crescita ed il cambiamento e la gestione It non è allineata: un altro elemento critico che ha avuto un decisivo impatto sui primi sistemi di Business Intelligence è da identificarsi nelle difficoltà di orchestrazione delle strategie di BI, soprattutto a fronte della dinamicità con cui i cambiamenti di business hanno iniziato a susseguirsi e della velocità con cui si generano nuovi dati. Situazione cui l’It non era affatto preparata, mostrando tutte le difficoltà nel difficile tentativo di allinearsi sempre più al business.
3) gli approcci adottati non erano scalabili: la scalabilità nell’implementazione dei sistemi di Business Intelligence diventa un critico problema di business. “Quando abbiamo chiesto ai responsabili It ed ai decision maker delle aziende perché utilizzassero tool ‘artigianali’ anche laddove esistevano ed avevano implementato alcuni sistemi di BI o analitiche – descrive Leganza, sempre facendo riferimento come panel alle aziende oggetto del report sopra citato – la loro risposta è stata perché i tool forniti dai provider non riuscivano ad integrare tutti i dati di cui effettivamente loro avevano bisogno oppure si trattava di soluzioni con modelli di dati troppo restrittivi che non consentivano loro di effettuare le analisi desiderate.
L’evoluzione verso le architetture Big Data
Sebbene lo scenario descritto appartenga ancora a qualche realtà aziendale, la maggior parte delle imprese che hanno deciso di ‘cambiare rotta’ sul fronte del Data Management ha abbracciato, o lo sta facendo e pianificando, architetture più evolute, orientate all’analisi ed orchestrazione dei Big Data. A differenza dei precedenti sistemi, però, l’evoluzione verso le architetture Big Data ha portato con sé una ‘nuova consapevolezza’ all’interno delle aziende ossia “il fatto che tale evoluzione debba essere accompagnata da nuovi modelli organizzativi con la definizione di regole, ruoli e responsabilità del tutto differenti rispetto al passato ed ai sistemi di BI e Data Management tradizionali”, puntualizza l’analista di Forrester.
L’attributo tecnologico chiave di queste nuove architetture che guida il cambiamento organizzativo va identificato nel fatto che si tratta di ambienti tecnologici incentrati su uno ‘schema di lettura’, cioè sulla massima fruizione del dato indipendentemente dalla sua forma e da dove risiede, e non su uno ‘schema di scrittura’ tipico invece dei sistemi di Edw e BI tradizionali. “È da qui che arrivano agilità e scalabilità ma, di contro, servono competenze più specifiche da parte di chi usufruisce di questi dati per poterli ‘manipolare’ adeguatamente ed estrarne le informazioni realmente utili al business (nei sistemi incentrati su modelli di scrittura, le competenze sulle manipolazioni dei dati rimanevano in capo a coloro che scrivevano ed implementavano le soluzioni Edw e di BI)”, commenta Leganza.
I modelli organizzativi influenzano l’efficacia delle architetture
 Figura 1: I cinque differenti modelli entro i quali si suddividono i talenti nell’ambito degli analyticsFonte: Forrester |
Partendo quindi da questa importante analisi preventiva, Leganza in un recente documento intitolato ‘Big Data architectures force an overhaul of roles and responsibilities’ offre alle aziende un dettagliato spunto su come dovrebbero organizzarsi per poter ‘abbracciare’ efficacemente modelli architetturali di analisi dei Big Data e lo fa riportando uno schema che identifica cinque differenti modelli entro i quali i talenti nell’ambito degli analytics tipicamente si suddividono (figura 1). Senza entrare troppo nel dettaglio delle informazioni riportate nel report, qui possiamo indicare solo alcune precisazioni rispetto allo schema che illustra i cinque modelli: nel delinearne le caratteristiche, Forrester ha tenuto conto di diversi elementi quali la relazione tra i team di analisti con le Lob, la standardizzazione delle analitiche, il numero di utenti che le utilizza, le fonti di investimento. Benché il ‘modello raccomandato’ sia quello del cosiddetto ‘center of excellence’, dove gli analisti esperti sono organizzati sia in strutture centralizzate sia all’interno delle Lob e sviluppano analitiche standardizzate in uso ad un ampio bacino di utenti, quelli ad oggi in uso più comunemente sono i modelli organizzativi basati sul cosiddetto ‘supporto dedicato’ o ‘community di practice’; benché validi, questi modelli hanno il limite di vedere le analitiche adottate solo da pochi utenti, per lo più esperti, rappresentando quindi una barriera all’efficacia diffusa tra le Lob ed il business delle architetture Big Data dalle quali potrebbero, e dovrebbero, invece, trarre vantaggio.
Per maggiori informazioni: Big data analytics, come fare e quali le competenze necessarie
