Realizzare il CPM e l’integrazione della BI
Continuando il discorso iniziato nel mio ultimo articolo, sui motivi per i quali le applicazioni CPM sulle performance del’impresa e quelle di BI debbano essere necessariamente integrate, questo secondo intervento vuole indicare come realizzare il tipo di integrazione possibile e come, in quest’ambito, l?interscambio dei metadati relativi alle diverse metriche applicate costituisca un elemento fondamentale di successo.
Nel corso degli ultimi sei mesi, il mercato per il software CPM è cresciuto in maniera significativa, con un gran numero di competitori in lizza. Tra questi, Cognos ha riscosso un successo considerevole con il suo prodotto Metrics Manager. Recentemente, Business Objects, rivale tradizionale di Cognos, è entrata sul mercato con l’offerta di Business Manager, realizzato congiuntamente con Business Objects Application Foundation.
Naturalmente, molti altri venditori sono attivi in questo mercato, tra i quali possiamo citare, ad esempio, SAP, PeopleSoft, Oracle, SAS e Corvu. Questi prodotti CPM vengono utilizzati come livello elaborativo superiore di applicazioni analitiche a pacchetto (spesso fornite dal medesimo venditore), consentendo agli utenti di aggiungere la propria metrica proprietaria alle scorecard e ai cruscotti aziendali per la misura delle performance dell’impresa, in modo da estendere l’uso del CPM oltre le capacità dei pacchetti di pura analisi.
Questo approccio, abbastanza recente, alla gestione delle performance dell’impresa è diverso da quello dei prodotti software di scorecard non integrati del passato, perché è basato su di una Business Intelligence integrata che collega il CPM alle elaborazioni tradizionali di BI. L’idea è che le analisi ai livelli operativo e tattico vengano “trasformate” in KPI (Key Performance Indicator), da visualizzare all’interno di cruscotti aziendali, collegandoli a obiettivi strategici specifici nelle scorecard, al livello di CPM strategico.
Tuttavia, realizzare tutto questo spesso è molto più difficile di quanto venga indicato a livello di marketing. È necessario che la maggior parte delle imprese affrontino la sfida di elevare le analisi di livello inferiore verso il calcolo di KPI a livello strategico. Il motivo di questa difficoltà risiede nel fatto che la maggior parte dei dati relativi alle misurazioni che debbono contribuire al calcolo dei KPI, al livello di CPM strategico, spesso risultano distribuiti nell’ambito di un mix di applicazioni analitiche sia proprietarie che a pacchetto.
In aggiunta, tali applicazioni analitiche possono utilizzare un insieme molto eterogeneo di data mart o basi dati relazionali (ad esempio Teradata di NCR, Ibm DB2, Oracle, Microsoft SQL Server), oppure multidimensionali (ad esempio SAS MDDB, Microsoft Analysis Server, Hyperion Essbase), spesso esistenti su server diversi che girano con sistemi operativi altrettanto eterogenei.
Per questi motivi, l’integrazione tra CPM e BI non è un compito lineare. Esistono infatti diversi approcci alla soluzione del problema. Le opzioni sono:
Utilizzare il software per l’integrazione dei dati con lo scopo di acquisire e integrare quelli provenienti da data mart multipli e diversi, sia di tipo proprietario che a pacchetto, trasferendoli in un database separato di KPI da utilizzare con il software CPM.
Utilizzare il software per l’integrazione dei dati con lo scopo di acquisire e integrare quelli provenienti da data mart multipli e diversi, sia di tipo proprietario che a pacchetto, trasferendoli in un database separato di KPI da utilizzare con il software CPM.
Questo approccio è spesso conosciuto come CPM stand-alone (vedi Figura 1).
Realizzare soluzioni CPM separate (ad esempio scorecard) in aggiunta alle “isole” di BI esistenti (ad esempio ogni data mart, ogni applicazione analitica a pacchetto) fornendo l’accesso a scorecard multiple, mediante un portale d’impresa o di BI (vedi Figura 2).
Usare l’interscambio dei metadati, preferibilmente sfruttando lo standard di settore CWM XMI, per condividere e scambiare i metadati stessi tra applicazioni, DBMS e strumenti dedicati, in modo da costruire gli alberi dei valori dei KPI all’interno di un prodotto CPM (vedi Figura 1).
Questo può essere ottenuto rilevando e importando i metadati relativi a praticamente tutte le misurazioni esistenti all’interno delle applicazioni proprietarie o a pacchetto in uso. I valori rilevati vengono messi in relazione con i quelli indicati negli alberi degli obiettivi, mentre vengono costruite una o più scorecard per verificare le prestazioni dell’impresa e guidarne le attività verso il conseguimento degli obiettivi di business.
Il prodotto CPM, quindi, deve supportare interrogazioni collegate tra loro su banche dati multiple ed eterogenee, per essere in grado di estrarre i dati necessari dalle misurazioni di livello superiore fino a quelle di livello inferiore, man mano che gli utenti navigano all’interno degli alberi delle metriche di controllo. In questo modo, scorecard e cruscotti aziendali che visualizzino gli obiettivi da conseguire e i KPI associati possono essere integrati all’interno di prodotti di portale, in modo da indicare gli obiettivi personalizzati, con le relative metriche di controllo, ai manager interessati all’interno dell’organizzazione (vedi Figura 3).
Una variante all’approccio indicato consiste nel bypassare l’interscambio dei metadata CWM quando questo non risulti supportato da tecnologie sottostanti, semplicemente reinserendo da tastiera, all’interno del prodotto CPM, i metadati relativi alle misurazioni e calcoli effettuati dalle applicazioni analitiche proprietarie, in modo da aggiungerli a uno o più alberi delle metriche.
Con la continua crescita del supporto per i servizi Web, il software CPM può richiedere misurazioni tramite un’interfaccia tra gli stessi servizi Web e le applicazioni a pacchetto, gli strumenti di BI e le basi dati. Questo aspetto è mostrato nella figura 4.
È interessante notare come le opzioni appena illustrate indichino scelte tecnologiche familiari. L?opzione 1 è centralizzata, l’opzione 2 è distribuita, mentre la 3 risulta federativa. A questo punto, è necessario chiedersi: tali opzioni rappresentano delle scelte o non sono piuttosto gli stadi di un ciclo di vita delle applicazioni CPM, che inizia centralizzato per finire poi federativo? Per esperienza, ritengo che siamo di fronte a un ciclo di vita.
Quante volte abbiamo già fatto il medesimo discorso a proposito delle diverse tecnologie? È avvenuto con i database (nati centralizzati, per divenire poi distribuiti e presentarsi oggi federativi). Lo stesso fenomeno si è prodotto con maggiore rapidità nei portali (anch’essi oggi federati), è avvenuto nel data warehousing e adesso si sta presentando nell’area BI/CPM. Esaminiamo perciò i punti di forza e di debolezza delle tre opzioni indicate.
L’opzione 1 è molto facile da comprendere e già questo ne costituisce un punto di forza. In tal caso, i dati relativi ai valori di riepilogo di livello inferiore vengono estratti da altre locazioni e integrati per creare un database separato di KPI per il CPM. Tuttavia, si tratta di una strategia che comporta sicure limitazioni.
Che cosa succede se un KPI segnala un problema per l’impresa? Ad esempio, come può un manager approfondire i dettagli per comprenderne la vera natura? Dopo tutto, una decisione ben informata e significativa può essere adottata solo in questo modo. La risposta è che il manager non può accedere a dati di ulteriore dettaglio che non siano già presenti nel database dei KPI. Nella peggiore delle ipotesi, questo può significare che i dati provenienti da tutte le applicazioni analitiche proprietarie e a pacchetto dovranno essere consolidati e integrati all’interno del database dei KPI.
Quest’ultima ipotesi sembra poco pratica con alcuni sistemi di warehousing che operano nella fascia tra le decine e le centinaia di terabyte. Se viene adottata, deve essere chiaro che non sarà possibile una comprensione precisa dei fenomeni aziendali a livello manageriale. Infatti, questa opzione fa sorgere la domanda su come i manager possano gestire efficacemente i problemi, senza avere accesso a tutte le informazioni necessarie per adottare la migliore decisione possibile.
Si tratta di un aspetto molto ben conosciuto, alla radice del fatto che i prodotti di scorecard “stand-alone?, nel passato, abbiano fallito o si siano dimostrati molto meno efficaci in confronto alle aspettative. L’integrazione con un sistema di intelligence dettagliato costituisce quindi un fattore critico di successo.
Anche l’opzione 2 è molto semplice da comprendere. In questo caso, vengono costruite scorecard multiple usando il software CPM e integrandole in un portale, per consentire l’accesso personalizzato alle misurazioni e alle scorecard appropriate, in base al ruolo dell’utente. Mediante tale approccio si possono costruire gli alberi delle metriche all’interno del prodotto CPM con la limitazione, però, che i calcoli sono relativi ai dati disponibili mediante l’accesso a uno specifico data mart proprietario, oppure ad un’applicazione a pacchetto.
Si tratta di un problema che si pone con questo approccio, quando il calcolo richieda l’uso di un dato mantenuto su di un altro sistema, al di fuori del data mart o dell’applicazione a pacchetto considerata. L?acquisizione e il mantenimento dei dati necessari per queste “nuove” misurazioni possono richiedere la modifica del modello dei dati del data mart di riferimento.
In aggiunta, in dipendenza di come risulti distribuito il prodotto CPM (ad esempio installazioni multiple separate di prodotti CPM), può verificarsi l’esistenza di “isole” di metadati CPM riferiti a obiettivi e metriche particolari non condivisibili. Questo genere di distribuzione non favorisce la gestione delle performance dell’impresa.
L’opzione 3 costituisce un tentativo di integrare metriche e obiettivi, mantenendo la flessibilità offerta dalle applicazioni analitiche finalizzate, sia proprietarie che a pacchetto. In questo caso, la chiave per il successo dell’integrazione e gestione dei risultati è rappresentata dalla disponibilità dei metadati, in modo da rendere possibile la costruzione degli alberi degli obiettivi e delle metriche, con riferimento ai dati esistenti all’interno delle applicazioni proprietarie o a pacchetto.
La Figura 5 mostra l’esempio di uno di questi alberi delle metriche. In uno di tali alberi, il prodotto CPM mantiene i metadati che gli forniscono il “know how” su quali misurazioni più dettagliate siano necessarie e debbano essere utilizzate per calcolare i valori di livello più elevato. In aggiunta, i prodotti CPM possono rintracciare indipendentemente ciascuna misurazione all’interno dell’albero delle metriche.
Gli analisti e i manager delle imprese possono costruire quanti alberi delle metriche ritengano necessari e possono riutilizzare le medesime misurazioni per alberi multipli.
Tuttavia, è chiaro che i metadati relativi alle misurazioni vengono creati a partire da tecnologie multiple e, quindi, diviene necessario condividere e riutilizzare le definizioni in modo da prevenire il caos che si può produrre a causa della coesistenza di dati con il medesimo nome in formule diverse, oppure di dati con nomi diversi all’interno di formule con lo stesso nome.
Se facciamo riferimento a fornitori di database come Oracle o IBM, attualmente questi hanno esteso i rispettivi cataloghi di DBMS (tabelle di sistema) in modo da acquisire i metadati relativi a metriche, dimensioni, gerarchie, ecc. con lo scopo di rendere il DBMS “coerente OLAP”. Ad esempio, Oracle possiede un catalogo OLAP conforme CWM, che riconosce ed è in grado di calcolare dinamicamente i valori di alberi delle metriche già gestiti da Oracle. Allo stesso modo, IBM ha aggiunto a DB2 V8.1 gli alberi dei valori (vedi Figura 6), in modo da gestire le relazioni tra le diverse metriche all’interno del database.
Anche le applicazioni a pacchetto mantengono metadati relativi alle metriche. Un prodotto CPM, per integrarsi correttamente con i database esistenti “coerenti OLAP” oltre che con le applicazioni a pacchetto, deve fare in modo che i metadati relativi alle metriche definite da tali tecnologie possano essere rilevati e acquisiti, in modo da consentire il riutilizzo delle misurazioni nelle scorecard e cruscotti aziendali sviluppati nell’ambito CPM.
La Figura 7 mostra come lo standard di settore per l’interscambio dei metadati può essere usato dai prodotti CPM per rilevare e importare i metadati delle misurazioni a partire da DBMS, strumenti di BI e applicazioni analitiche a pacchetto da utilizzare in scorecard e che, a loro volta, possono essere presentati tramite un portale.
Nel momento in cui gli utenti navigano all’interno degli alberi delle metriche per scendere nel dettaglio dei valori, dai KPI di livello superiore ai valori delle misurazioni di livello inferiore, i prodotti CPM che consentono interrogazioni concatenate possono supportare gli utenti che desiderino approfondire le ricerche all’interno di uno o più data store per ottenere dati ancora più dettagliati.
Mentre i venditori di DBMS continuano ad aggiungere supporto per i metadati di BI e per l’integrazione delle informazioni dell’impresa (ad esempio DB2 Information Integrator), possiamo notare chiaramente che i fornitori di prodotti CPM incrementano il loro utilizzo di DBMS con lo scopo di facilitare l’integrazione della BI.
La terza opzione, tra quelle esaminate, sembrerebbe la più adatta a indicare la direzione da seguire per le imprese con una visione più avanzata. Tuttavia, questa strategia ribadisce come i metadati e l’interscambio di definizioni comuni siano ancora una volta al centro dell’integrazione della BI e, naturalmente, delle applicazioni operative, mentre in molti casi tutto questo riceve una scarsa attenzione da parte delle imprese di maggiori dimensioni.
È tempo che la maggior parte delle imprese si orientino seriamente verso metadati comuni (in termini di nomi, definizioni e vocabolario XML), ponendo il problema in cima alla lista delle priorità, se vogliono arrestare il caos e passare a una gestione che utilizzi un’intelligence integrata all’interno dei processi operativi dell’impresa.