insight - Inverno 2003 --> Periodico di Business Intelligence

Tecnologia e business.

I progetti di
business intelligence.
Le variabili critiche di successo secondo Federico Rajola, docente presso la
Facoltà di Economia
dell’Università Cattolica di Milano e direttore del CETIF.

Sono sempre più numerosi gli articoli, gli speciali di riviste, i libri, le conferenze che trattano i temi della business intelligence e l’introduzione di essa in azienda. Anche all’interno delle Università italiane questi temi cominciano a essere trattati con caratteri di sistematicità. Segno forse di un affermato interesse da parte delle aziende verso sistemi che consentono di migliorare i processi decisionali? Probabilmente sì.Certo è
che per decenni molte delle tecnologie che oggi vengono comprese nella business intelligence, nonostante fossero consolidate e disponibili da anni, erano considerate per soli “boffins“. Chi sono i boffins? I cosiddetti cervelloni che vivono in una propria dimensione e che studiano e lavorano su tematiche, tecnologie, teorie astratte difficilmente applicabili in ambito aziendale. I boffins della business intelligence a distanza di alcuni anni hanno avuto la propria rivincita dimostrando che quelle tecnologie potevano essere ampiamente impiegate in ambito aziendale per contribuire a far conseguire addirittura quel vantaggio competitivo tanto sospirato dal management.
Ma il problema era soltanto di carattere tecnologico? Sono pronte le aziende a recepire sistemi a volte invasivi e che spesso richiedono un radicale cambiamento culturale? Come mai oltre il 50% dei progetti di business intelligence non sono in grado di raggiungere i risultati attesi?
La realtà certamente è molto più complessa di quello che appare. Il contributo dei sistemi di business intelligence per il conseguimento del vantaggio competitivo richiede:

Questi sono soltanto alcuni degli elementi generali che caratterizzano lo stato di automazione delle aziende in relazione ai sistemi di supporto al management di tipo non strutturato.
Nel tempo abbiamo assistito a tre diverse fasi dell’automazione in azienda, i cui obiettivi erano rispettivamente: l’automazione del back office con il fine di operare a costi minori e conseguire efficienza; l’automazione del front office e dei DSS (decision support system di prima generazione) con il fine di raggiungere i risultati attesi e conseguire efficacia; l’automazione di attività decisionali non strutturate con il fine di ottenere vantaggi duraturi e perseguire le strategie aziendali.
Se le prime due fasi sono giunte a fase di maturazione, oggi stiamo vivendo in pieno la terza fase: quella dell’automazione delle attività decisionali non strutturate.
Molti progetti sono stati realizzati, tanti altri sono in corso di realizzazione, molti ancora verranno messi a budget e portati a termine. Sulla base delle esperienze condotte in Italia e all’estero, molte società di consulenza hanno individuato best practice per la realizzazione di sistemi, altre hanno raffinato metodologie di sviluppo; ciascun operatore ha contribuito a suo modo per cercare di ridurre i tassi di fallimento dei progetti di business intelligence. Ma allora quali sono i principali fattori critici da valutare in un progetto di business intelligence perché si riescano a ottenere vantaggi duraturi e in grado di sostenere gli orientamenti strategici delle imprese?
Una ricerca condotta sulle maggiori banche italiane dal CeTIF, Centro di Tecnologie Informatiche e Finanziarie dell’Università Cattolica di Milano, ha evidenziato che i principali fattori critici da valutare sono:

Identificazione e classificazione degli obiettivi di business. Come in ogni progetto informatico, è necessario individuare in modo completo e corretto gli obiettivi di business che gli utenti intendono conseguire. A ciò è utile associare una approfondita conoscenza dei sistemi legacy per comprendere quali siano le migliori soluzioni architetturali e come alimentare i nuovi sistemi. Scelta che può sembrare banale ma che certamente richiede di comprendere le modalità di utilizzo dei dati transazionali, i tempi di allineamento dei dati con le soluzioni di business intelligence, l’identificazione e l’integrazione con fonti informative esterne, la granularità dei dati, la dimensione temporale degli archivi, etc. Inoltre è necessario che nelle fasi di analisi emerga in modo chiaro che le logiche di realizzazione devono essere il più possibile svincolate da quelle dei sistemi transazionali. Infine appare importante evidenziare che spesso nell’alimentazione degli archivi per le soluzioni di business intelligence (informativi, data mart o data warehouse) raramente si prendono in considerazione quali saranno poi a regime i sistemi di analisi che verranno applicati sui dati. Ciò spesso limita la fruibilità dei dati che possono anche non essere utilizzabili con sistemi di data mining.

L’information quality. Il solo data warehouse non garantisce l’information quality. Essa è però una “premessa“necessaria. Diventa sempre più importante la certificazione dei dati da applicare con metodologie rigorose e caratteri di sistematicità. La mancata o non sistematica certificazione porta inevitabilmente a basi informative che nel tempo perdono valore. Ciò anche con riferimento al prospettico allineamento tra data warehouse e mutamento degli obiettivi di business dell’azienda. Le operazioni di information quality sono quindi diffuse e in fase di continua manutenzione/aggiornamento. Inoltre la qualità dell’informazione non può prescindere:

La logica di sviluppo basata sugli utenti e legata al soddisfacimento delle esigenze delle singole aree di business. Come già implicitamente affermato più volte, è necessario comprendere dettagliatamente le esigenze di tutte le aree di business dell’azienda e, attraverso meccanismi motivazionali e progettuali coerenti, ricercare elevati livelli di commitment degli utenti che diventano i veri padroni delle soluzioni di business intelligence.

Ciò anche attivando cantieri di lavoro tesi a condurre attività di formazione per gli utenti finalizzate a una migliore comprensione degli aspetti tecnologici per realizzare soluzioni stabili e complete. Secondo Gartner Group il processo di realizzazione basato sugli utenti richiede l’esecuzione delle otto attività rappresentate in fig. 1.

La classificazione per tipologia di utente. La classificazione per tipologia di utente richiede l’identificazione delle modalità di interazione di ogni singolo utente con il sistema e con il tipo di informazione disponibile.
E’ necessario quindi comprendere a fondo i bisogni del singolo utente, il ruolo di ognuno di essi in azienda e le modalità di interazione con il sistema degli stessi utenti.
Si avverte quindi la necessità di “segmentare“ gli utenti in gruppi omogenei (informazioni a cui sono interessati, attività, ruoli, etc.).
In figura 2 è riportato un esempio di matrice che aiuta a comprendere e classificare gli utenti sulla base di un insieme di variabili.

Il processo di selezione dei prodotti da utilizzare. Dopo aver classificato gli utenti sembra importante condurre una attività di individuazione dei prodotti/soluzioni in base alla stessa classificazione degli utenti, alle funzionalità e alla modalità di utilizzo/interazione con il sistema. Le variabili che in questo caso possono essere prese in considerazione sono: la gamma di funzionalità richieste delle soluzioni (e le caratteristiche di queste: flessibilità, scalabilità etc.) e le modalità di utilizzo per tipo di utente.In figura 3 è presentata una matrice che, sulla base delle due variabili, aiuta a comprendere come devono essere realizzate le soluzioni per i diversi utenti.

Le modalità di distribuzione delle informazioni. Le modalità di distribuzione ed elaborazione delle informazioni possono essere individuate seguendo due criteri: per tipo di utilizzo e per tipo di supporto. Le caratteristiche principali del primo sono:

Le caratteristiche principali del secondo riguardano le modalità di interazione con il sistema per tipo di supporto e in relazione all’architettura:

Sulla base delle analisi condotte in questa fase e dei risultati ottenuti, è possibile identificare quanto un’applicazione deve essere distribuita sulla base delle modalità di utilizzo e del tipo di supporto usato. Si veda figura 4.

L’architettura tecnologica. I principali aspetti da considerare in relazione ai livelli di architettura tecnologica sono:

sistema di gestione: amministrazione utente, sicurezza dizionario dati, elaborazioni differite;
livello utente: data retrieval, visualizzazione ed esplorazione, tool di calcolo, sistemi di pubblicazione distribuzione delle informazioni.

Gli adeguamenti organizzativi. I principali adeguamenti organizzativi che derivano dall’introduzione di sistemi di business intelligence di supporto ad attività decisionali di tipo non strutturato sono:

L’approccio “vincente“ può dipendere dalle contingenze organizzative di ciascuna azienda quali la cultura, l’ambiente interno ed esterno, la capacità del fornitore/system integrator scelto, il grado di aderenza dei prodotti scelti alle necessità dell’azienda, la validità dell’approccio e della soluzione da adottare.