Ti giocheresti la riuscita del tuo prossimo progetto di data warehousing a testa o croce? Secondo le previsioni di Gartner Group le probabilità di uscire vincitori dall’impresa sono le medesime. Dati più o meno analoghi sono riportati in vari studi in cui generalmente con il termine fallimento vengono classificati (e conseguentemente conteggiati) sia lo sforamento di costi e tempi rispetto a quanto pianificato, sia la mancata soddisfazione degli utenti finali, sia la vera e propria chiusura del progetto prima del suo completamento (fra i più pessimisti Adelman e Moss che riportano una percentuale di fallimento totale pari al 40%).
Complessivamente le probabilità di successo di un progetto IT generico non sono molto migliori. Molti fattori di rischio sono evidentemente comuni: scarsa attuazione delle principali tecniche di project management, eccessiva compressione delle fasi di analisi e progettazione per ridurre tempi e costi, metodologie non sempre aggiornate/adeguate, eccessiva confidenza nelle nuove tecnologie (e nella loro capacità di risolvere il problema a prescindere), scarsa comprensione/condivisione dei requisiti funzionali con i futuri utenti del sistema, ecc. Questi (e altri) fattori di rischio generalizzabili a tutti i progetti IT contribuiscono certamente a comporre l’alea relativa al successo dei progetti di data warehousing, ma esistono fattori di rischio specifici che si sommano a quelli generici portando il livello di incertezza sull’esito dei progetti di DW a livelli paragonabili a quelli del lancio di una moneta?
Francamente non credo che le reali percentuali di fallimento siano così elevate (anche se certi ottimismi, con il dovuto rispetto, sono forse un po’ eccessivi); tuttavia spesso i sistemi di data warhousing e di business intelligence presentano livelli di insoddisfazione e inutilizzo da parte degli utenti finali (anche questa è una forma di fallimento) superiori rispetto alla media dei progetti IT; le difficoltà di pianificare e rispettare tempi e costi poi costituiscono uno dei principali ostacoli già nella decisione di avviare un progetto di business intelligence.
Quali fattori di rischio contribuiscono quindi ad incrementare l’incertezza nei risultati dei progetti di data warehousing sia intermini di efficacia che di efficienza?
Fattori legati alla complessità funzionale
Elemento chiave per comprendere tali fattori è la complessità intrinseca dei sistemi di data warehousing (almeno come li conosciamo oggi). Tale complessità parte dal processo stesso che i sistemi DW sono chiamati ad implementare: l’integrazione e la riconciliazione di dati gestiti da sistemi informativi eterogenei e indipendenti. Le attività di integrazione e riconciliazione pongono problematiche relative alla semantica dei dati gestiti nei sistemi sorgente (generalmente sistemi di tipo transazionale – OLTP) e alle regole di business in essi implementate. Tanto più è incerta la natura dei dati gestiti dagli ambienti operazionali, tanto maggiore è il rischio di prendere “lucciole per lanterne” e finire per sommare “le mele con le pere”. Quindi avere una buona conoscenza dei sistemi sorgente e del significato dei dati in essi trattati aiuta a ridurre questa componente di rischio. Sfortunatamente i sistemi operazionali (probabilmente come tutti i sistemi IT di una certa complessità) hanno una spiccata tendenza a presentare livelli di incertezza elevati circa il significato e la coerenza dei dati in essi trattati, per non parlare del disallineamento costante fra quanto documentato (quando esiste una documentazione degna di questo nome) e quanto attualmente in produzione. Inoltre la visione tecnica del sistema e quella di business sembrano spesso inconciliabili senza avere a disposizione la “Stele di Rosetta” costituita dai documenti di analisi e progettazione del sistema.
Se un sistema DW assolve l’arduo compito di rappresentare la verità aziendale unica e certificata è naturale e corretto che chiunque in azienda voglia attingere a tale fonte (salvo poi incrociarla con i dati forniti dal proprio operazionale di riferimento). Di conseguenza anche il parco utenti del sistema è (specie con l’estensione delle funzioni di BI dal solo management a tutte le figure operative dell’azienda) largamente differenziato sia nel lessico (in termini di business) che nei requisiti di analisi e supporto decisionale. Questo porta ancora una volta a problemi di semantica nella definizione delle informazioni richieste e nell’interpretazione dei risultati forniti; problemi che possono aumentare le frustrazioni degli utenti e ridurre il loro livello di soddisfazione fino a compromettere la credibilità e l’utilizzo del sistema stesso.
Fattori legati alla complessità architetturale
Tali complessità intrinseche si ripercuotono anche su una maggiore complessità architetturale e tecnologica. Dal punto di vista architetturale un sistema di DW/BI è costituito da una serie di componenti fortemente accoppiate (ossia con stretti legami di interdipendenza scarsamente mascherati da interfacce standardizzate). Tale condizione è particolarmente critica in quanto alcune di queste componenti (i sistemi sorgente) sono tipicamente al di fuori dal controllo di chi gestisce il sistema di DW eppure sono parte integrante del sistema stesso. Una variazione significativa su un sistema sorgente spesso si ripercuote su tutte le componenti architetturali: dalle procedure di alimentazione fino alla reportistica e alle funzioni analitiche. Pur essendo presenti tecniche e strumenti di separazione fra i diversi passi del processo di trasformazione del dato in informazione (staging area, edw, data marts, strati semantici, ecc.), cambiamenti significativi nelle regole di business o nella modellazione concettuale dell’informazione hanno un impatto potenziale su tutte le componenti del sistema. Non a caso grande sforzo è stato profuso nella realizzazione di sistemi di gestione dei metadati che consentissero la conduzione di analisi di impatto su tutte le diverse componenti (cross impact analysis) per valutare gli effetti di una modifica locale ad una di queste. Infine non di rado l’accesso ai sistemi sorgente viene effettuato leggendo i dati direttamente dalle loro basi dati ignorando l’altra metà dei sistemi operazionali: le loro procedure. Queste spesso elaborano significativamente i dati fornendo agli utenti, caso per caso, un’informazione differente da quanto semplicemente memorizzato su disco. Quando le modifiche sui sistemi sorgente interessano solo questa componente algoritmica, tali modifiche possono passare inosservate: non si può dire lo stesso dei loro effetti.
Fattori legati alla complessità tecnologica
Dal punto di vista più strettamente tecnologico si registra un elevato numero di tecnologie differenti che devono coesistere e cooperare:
- sistemi di gestione di workflow per i processi di alimentazione in area back-end e per lo scambio e l’approvazione di report e documenti in area front-end (e non sempre il motore di workflow è il medesimo);
- procedure di integrazione, trasformazione e caricamento (ETL o ELT) realizzate potenzialmente con soluzioni tecnologiche eterogenee nello stesso progetto;
- sistemi di query e reporting (magari anche più di uno per presentare gli stessi dati a grupi di utenti diversi)
- cruscotti, strumenti di corporate performance management e balanced score card
- sistemi analitici avanzati (tipicamente strumenti di analisi statistica e data mining)
- portali con funzioni di integrazione applicativa
- … (ce ne sono altri) …
Anche quando molti dei prodotti sono forniti dallo stesso produttore o addirittura appartengono alla medesima suite di prodotti, non sempre questi sono sufficientemente integrati (ad esempio con un unico repository di metadati realmente integrato). Anche quando questo avviene, si tratta comunque di una moltitudine di prodotti differenti, ciascuno con le sue logiche e le sue best-practice per cui è spesso necessario coinvolgere specialisti differenti per coprire adeguatamente tutte le esigenze di progetto; il che ha una diretta conseguenza non tanto (o non soltanto) sui costi ma sopratutto sulla complessità che deve essere gestita nel coordinamento di tutte le figure, nel favorire lo scambio comunicativo, nell’armonizzare e conciliare le esigenze di ciascun prodotto/componente, nel verificare la giusta integrazione di tutti i contributi, ecc.
Valutare i livelli di rischiosità
I fattori di rischio evidenziati non si possono ridurre cercando semplicemente di limitare la complessità di tali sistemi in quanto tale complessità è insita nelle finalità stesse dei sistemi di DW/BI: incrociare dati presenti in sistemi sorgente eterogenei e indipendenti per fornire un supporto informativo e decisionale coerente a tutte le funzioni aziendali. E’ invece fondamentale tenere conto di tali fattori specifici durante la fase di risk assessment del progetto e valutare caso per caso quanto questi possano incidere sul rischio complessivo del progetto al fine di prevedere e mettere in opera le opportune contromisure durante le diverse fasi progettuali.
hai fatto una bella panoramica sulla difficoltà di implementare un progetto di DW/BI.
Alle complessità architetturali/ambientali porrei maggior enfasi sulle difficoltà di convincere gli utenti ad utilizzare i nuovi prodotti di BI.
Alle complessità tecnologiche aggiungerei anche :
-sottistima dell’hardware
-differenza tra tempi di risposta promessi e realizzati.
Le limitazioni nella scelta degli strumenti di BI da utilizzare in un progetto costituiscono effettivamente un fattore di rischio, sia perché incidono sulla perseguibilità di determinate soluzioni tecniche e sull’efficienza della loro implementazione, sia perché possono avere un effetto diretto sull’usabilità del sistema.
L’adozione da parte degli utenti di un nuovo sistema di BI è uno degli elementi chiave per il suo successo e spesso si registrano diffidenze proprio da parte degli utenti finali (specie se non sono stati coinvolti a sufficienza nel processo di innovazione). Tale resistenza però aumenta quando alle “nuove funzionalità ” fornite si aggiunge anche un “nuovo prodotto” che le implementa.
Per facilitare l’introduzione di nuovi prodotti di BI e farli “apprezzare” dall’utente finale del sistema è importante pianificare da subito attività di formazione presso l’utente che interessino sia le funzionalità del sistema che le modalità operative. L’introduzione sarà tanto più facile quanto più gli strumenti (e i sistemi progettati) saranno facili da utilizzare: nuovi prodotti di BI che facilitino l’accesso alle informazioni, migliorino l’esperienza utente e risecano a calamitare l’attenzione dell’utente sulle poche informazioni realmente rilevanti per il proprio lavoro possono ridurre significativamente le resistenze iniziali e favorire l’adozione del sistema.
Per quanto riguarda il dimensionamento HW del sistema, questo è un fattore di rischio comune a molte categorie di progetti IT. Ad accrescere il rischio nei progetti di DW/BI contribuisce il tasso di crescita di tali sistemi che è decisamente superiore a quello di un sistema gestionale. Percui un sistema HW correttamente dimensionato per fornire dei tempi di risposta “accettabili” nella prima iterazione del progetto, a distanza di un anno, in seguito al crescere dei volumi di dati trattati sia per effetto della storicizzazione degli stessi che per un ampliamento del progetto con iterazioni successive, può degradare nelle sue prestazioni in maniera rilevante.
Un fattore di complessità funzionale, per esperienza sul campo, nasce dalla frequente tendenza di accorpamento di aziende che presentano sistemi informativi integrati (o almeno tentativamente integrati).
Questi ultimi presentano carenze informative troppo spesso importanti che rendono la qualità del dato molto scadente.
Il risultato di un progetto di DWH/BI che ha come fonti dato questi sistemi informativi, verrà utilizzato per individuare problemi di processo all’interno dell’azienda!