Scarica Business Intelligence A. Maldini e più Dispense in PDF di Sistemi Informativi Aziendali solo su Docsity!
13. DAI SISTEMI DI SUPPORTO ALLE DECISIONI
ALLA BUSINESS INTELLIGENCE
di I.E. Inghirami, C. Caserio*
13.1. Definizioni e concetti di base
13.1.1. I Sistemi Informativi Aziendali
I Sistemi Informativi Aziendali sono devoluti a fornire dati ed informa- zioni ai decisori ai vari livelli decisionali di cui l’azienda si compone. Se però decidessimo di scindere in due grandi categorie tali attività decisio- nali, potremmo distinguere tra attività di tipo operativo e tattico, ed atti- vità di tipo strategico^1 , potremmo anche operare una divisione in due prin- cipali aree il Sistema Informativo Aziendale: da un lato avremo una serie di applicazioni devolute alle operazioni aziendali correnti (il Sistema Informativo Operativo ), e dall’altro un ambiente in cui ritroveremo ap- plicazioni destinate ad un uso direzionale e strategico (il Sistema Infor- mativo Direzionale ). I due sistemi sono ovviamente contigui e comunicanti: le informazioni desunte dal primo forniranno gran parte delle informazioni elaborate dal secondo, e, viceversa, le decisioni prese nel secondo ambiente si riverse- ranno nel primo. Potremo quindi arrivare ad uno schema generale come quello riportato in Fig. 1. Mentre rimandiamo ad un altro capitolo per quanto concerne i sistemi tesi a supportare le decisioni operative (cfr. il cap. “L’evoluzione dei Siste- mi Informativi Aziendali: dal Sistema Informativo Contabile al Sistema Informativo Gestionale”), approfondiremo in questo capitolo le tematiche legate ai sistemi devoluti a supportare le decisioni direzionali e strategiche.
- I. Inghirami è autore dei parr. 9.1., 9.2., 9.3., 9.3.1.; C. Caserio è autore del par. 9.3.2.
- Per una ben più ampia disamina sulle decisioni aziendali, si veda, per tutti: Paola Miolo Vitali, Il sistema delle decisioni aziendali , Torino, Giappichelli, 1993.
13.1.2. Dai Decision Support Systems alla Business Intelligence
Negli anni settanta viene proposto da diversi autori 2 un innovativo uti- lizzo delle tecnologie informatiche: si ipotizza non solo il supporto delle attività operative come era accaduto sino allora, ma anche il supporto del- le attività decisionali dei manager.
Nascono i Decision Support System (DSS - Sistemi a Supporto delle Decisioni), che si basano su tre presupposti fondamentali:
- sono sistemi informatizzati composti da precise componenti;
- sono destinati a supportare le attività manageriali;
- sono orientati alle decisioni. In particolare, i sistemi DSS sono composti da:
- un archivio di modelli;
- un archivio di dati;
- Per un’ampia trattazione di questi temi si veda: Alter S.L., Decision Support Sy- stems: Current Practices and Continuing Challenges , Usa, Addison-Wesley, 1980; Ben- nett J.L., Building Decision Support Systems , Usa, Addison-Wesley, 1983; Keen P.G. W., Scott Morton M.S., Decision Support Systems: an Organizational Perspective , Usa, Addi- son-Wesley, 1978.
Fig. 1 - I Sistemi Informativi Aziendali: uno schema di riferimento
Sistemi Direzionali
Sistemi Operativi
Sistemi Informativi Aziendali
Tornando ai DSS, possiamo notare come essi possano essere divisi in due distinte categorie, i DSS Data Oriented (SSD Orientati ai Dati) e DSS Mo- del Oriented (SSD Orientati ai Modelli): nella prima categoria sono com- presi i sistemi in cui è prevalente l’approccio teso alla ricerca (anche auto- matica o guidata da tecnologie riconducibili all’Intelligenza Artificiale) di informazioni presenti in grandi archivi di dati^6 ; nella seconda categoria l’ap- proccio è invece legato alla capacità del DSS di gestire e manipolare model- li anche complessi^7. Come si diceva, dopo un iniziale entusiasmo l’interesse verso questo tipo di applicazioni è andato scemando, principalmente a causa sia della complessità di creare e mantenere modelli complessi, sia per una sostanziale inadeguatezza del management nel recepire ed utilizzare effetti- vamente questi strumenti, potenzialmente molto interessanti. Solo in questi ultimi anni abbiamo assistito ad un rinnovato interesse per applicazioni a supporto dell’attività decisionale dei vertici aziendali: è stato creato un nuovo settore, la cosiddetta “ Business Intelligence ” (spes- so abbreviata in BI), che raccogliendo l’eredità dei Decision Support Sy- stem ne ha riproposto molti contenuti, pur rendendone molto più semplice ed intuitivo l’utilizzo^8. Anche se molto utilizzato, il termine Business Intelligence non ha una chiara ed univoca definizione. In senso lato, si potrebbe tradurre come “comprensione del mercato”, anche se nella terminologia anglosassone il termine “business” è molto più ampio e comprende tutte le attività dell’azienda. Le due maggiori “correnti” interpretative possono essere co- munque ricondotte alle seguenti definizioni:
- “Un sistema informatico che ha la capacità di fornire rapidamente rispo- ste alle domande dei manager relativamente alla situazione dell’azienda, del mercato e dei suoi andamenti presenti, passati e futuri, ed il potenzia- le impatto sul mercato stesso di nuove strategie da parte dell’azienda”^9.
- Si pensi, ad esempio, alla ricerca di particolari associazioni tra termini all’interno di documenti di testo, od a ricerche in formato libero in svariate tipologie di archivi (data ba- se, testi, fogli elettronici, messaggi di posta elettronica, ecc.).
- In molti casi i modelli trovano radice nella Ricerca Operativa (per tutti si vedano le considerazioni riportate da Enrico Cavalieri, Sulle relazioni tra modelli economico-azien- dali contabili e matematico-statistici , Chieti, Edigrafital, 1974), ma molti esempi in questo campo possono essere trovati in campo economico-aziendale. Ad esempio, si veda: Favot- to F. in Brunetti G., Coda V., Favotto F., Analisi, previsioni e simulazioni economico-fi- nanziarie , Milano, Etas Libri, 1984, ed anche l’intervento di Favotto F. in Aa.Vv., Stru- menti informativo-contabili per le decisioni aziendali , Bologna, Clueb, 1988.
- Da notare l’eliminazione ai modelli, che come si diceva non sono risultati all’altezza delle aspettative. Un’interessante analisi sull’attuale situazione italiana nel campo dei DSS si trova in: De Toni A., Nassimbeni G., Tonchia S., I sistemi di supporto alle decisioni: of- ferta, domanda, applicazioni , Milano, Angeli, 2000.
- Per maggiori approfondimenti su questa definizione, si veda E. Turban e J.E. Aron- son, Decision Support Systems and Intelligent Systems , Usa, Prentice Hall, 1998.
- “La capacità dell’azienda di accedere ed esplorare informazioni (spesso contenute in un “Data Warehouse”) e di analizzare tali informazioni al fine di sviluppare intuizioni e comprensione, che portino ad un proces- so decisionale migliorato e circostanziato”… “Gli strumenti di Business Intelligence includono: interrogazioni ad-hoc, creazione di report, Deci- sion Support Systems (DSS), Executive Information Systems (EIS), e, spesso, tecniche di analisi statistica e On Line Analytical Processing (OLAP)” 10. Come si potrà notare, mentre la prima definizione è molto più generale e si può ascrivere ad un gran numero di sistemi informatizzati, la seconda ri- chiama sia precise tecnologie hardware e software (i Data Warehouse, ad esempio - si veda più oltre), sia grandi famiglie di applicazioni (DSS, EIS, sistemi OLAP) da lungo tempo molto discusse in letteratura. In sostanza, mentre alcuni tendono a proporre un’estensione dei correnti sistemi gestio- nali al fine di supportare attività di BI, altri propendono per l’adozione di strumentazioni diverse dalle esistenti per un’attività che risulta essere nuova e diversa rispetto alle precedenti. Proprio per questa ragione, come vedremo approfonditamente in seguito, sembra preferibile separare i due ambienti, destinando un ambiente per le operazioni che potremmo definire gestionali o “transazionali”, secondo una certa letteratura, ed un ambiente separato per le operazioni direzionali: avremo così i sistemi di On Line Transaction Pro- cessing (OLTP) ed i sistemi di On Line Analytical Processing (OLAP).
13.1.3. Sistemi OLTP e Sistemi OLAP
La maggioranza dei Sistemi Gestionali basa la propria affidabilità su un importante concetto: la transazione^11. Ciascuna operazione elementare (la transazione, appunto) è considerata come un’entità a sé stante, e viene eseguita seguendone passo passo l’esecuzione. Se la transazione va a buon fine, le tabelle interessate del Data Base vengono aggiornate; in caso con- trario (ad esempio un malfunzionamento, una caduta di corrente, ecc.) il sistema viene ripristinato nella sua condizione iniziale e l’utente viene in- vitato a ripetere l’operazione stessa. Si può quindi ben comprendere come tale meccanismo sia garante della corretta conduzione delle operazioni, e
- Questa definizione è di Howard Dresner, senior analyst del Gartner Group, che la coniò nel 1989.
- Per una più ampia dissertazione sui Sistemi Gestionali ed in particolare sui Sistemi ERP si veda il capitolo “L’evoluzione dei Sistemi Informativi Aziendali: dal Sistema Informativo Contabile al Sistema Informativo Gestionale”.
Tab. 2 - Caratteristiche dei Sistemi OLAP secondo Pendse
Fast
Analysis
Shared
Multidimensional
Information
Il sistema deve fornire risposte in un tempo molto rapido (tra i 5 ed i 20 secondi, a seconda della complessità della query).
Il sistema deve garantire qualunque logica e/o analisi statistica che sia necessaria all’utente, mantenendo nel contempo una ragionevole semplicità di utilizzo.
Il sistema deve implementare non solo la condivisione degli archivi, ma anche vari livelli di sicurezza associabili alle va- rie tipologie di utenti.
Il sistema deve fornire viste multidimensionali dei dati, ivi comprese gerarchie semplici e multiple.
Il sistema deve gestire molteplici fonti di dati, ed anche le informazioni desunte dai dati stessi.
Tab. 3 - Confronto tra sistemi OLTP e sistemi OLAP
Funzione
Caratte- ristiche
- Mantengono i Data Base neces- sari alla conduzione dell’azien- da.
- Supportano le attività operative.
- Molti utenti interni ed esterni si- multaneamente.
- Accessi in Tempo Reale in Let- tura e Scrittura agli archivi.
- Gestiscono un grande numero di transazioni semplici e ripetitive.
- Aggiornamenti numerosi e fre- quenti.
- Le transazioni accedono ad un li- mitato numero di record del DB.
- I dati devono essere il più ag- giornati possibile.
- È necessario garantire integrità e completezza delle transazioni.
- Processi ben definiti con poche eccezioni. - Mantengono i DB necessari per analisi e simulazioni strategiche. - Vengono utilizzati a supporto di decisioni strategiche. - Relativamente pochi utenti di so- lito interni all’azienda. - Accessi tipicamente in Lettura agli archivi. - Gestiscono un numero limitato di query anche molto complesse. - Aggiornamenti poco frequenti. - Le transazioni accedono ad un grande numero di record del DB. - Non è necessario che i dati siano molto aggiornati. - È importante garantire la com- pletezza e l’accuratezza delle informazioni e dei risultati. - Esplorazioni “ad hoc” e report predefiniti.
OLTP OLAP
13.2. Strutture informatiche per la Business Intelligence
13.2.1. Considerazioni preliminari
Come si diceva, gli attuali sistemi gestionali consentono non solo la corrente conduzione dell’azienda, ma forniscono anche idonee strumenta- zioni per una parziale soddisfazione delle esigenze di Business Intelligen- ce dei manager. Quasi tutti i sistemi gestionali hanno infatti sviluppato potenti capacità di reportistica anche complessa senza ricorso a particolari capacità di pro- grammazione da parte degli utilizzatori. Per quanto riguarda però i temi relativi ai Sistemi Direzionali, le capacità dei Sistemi Gestionali si rivela- no assolutamente inadeguate. Considerando le specifiche dei Sistemi Direzionali, rimangono infatti scoperte alcune esigenze e presupposti fondamentali per poter davvero sviluppare attività di Business Intelligence all’interno dell’azienda:
- la mancanza di uno specifico ambiente destinato alla Business Intelli- gence;
- la mancanza di un ambiente di analisi;
- la mancanza di un ambiente di simulazione. Le più recenti tendenze, inoltre, propongono un’interfaccia comune che renda più agevole l’utilizzo dei sistemi OLAP: ci stiamo riferendo alla creazione di un Enterprise Portal a cui gli utenti possano connettersi tra- mite Internet, Intranet od Extranet. Riportiamo uno schema esemplificativo in Fig. 2, anche se non ap- profondiremo oltre l’argomento dei Business Portal per concentrarci inve- ce sui predetti sistemi OLAP.
Fig. 2 - Lo schema di un Sistema Direzionale
Sistemi OLAP EnterprisePortal
Utente
Utente
Utente
Utente
Utente
Una possibile soluzione consiste nell’approntare un nuovo ambiente che possa venire utilizzato solo per il supporto delle attività decisionali: possiamo identificare cioè un Data Warehouse (Magazzino di Dati) ove collocare dati, modelli e procedure devoluti a tali fini. Una definizione di Data Warehouse potrebbe essere la seguente:
Un ambiente contenente dati subject-oriented provenienti da diverse fonti interne ed esterne all’azienda e predisposti per il supporto ad attività decisionali^14.
Considerando inoltre l’orientamento all’utente finale del Data Warehou- se, si preferisce spesso suddividere l’ambiente OLAP in sotto sistemi, cia- scuno specifico ad una funzione od attività. Tali sotto sistemi, che concet- tualmente appartengono al Data Warehouse aziendale, prendono il nome di Data Marts^15.
13.2.3. L’approntamento dei dati
I dati contenuti in un Data Warehouse sono organizzati in modo radi- calmente diverso dai dati presenti in un Sistema Gestionale: mentre nei secondi si utilizza un paradigma relazionale e fortemente normalizzato^16 , nei primi invece il paradigma utilizzato è quello dimensionale, ed i dati sono de-normalizzati. Dobbiamo quindi prevedere procedure specifiche che provvedano ad estrarre e trasformare i dati, come meglio vedremo in seguito (si veda lo schema della Fig. 3). Nei Data Base gestionali, i dati sono contenuti in molte tabelle norma- lizzate 17 contenenti tipicamente un numero limitato di colonne, una delle quali contenente la chiave principale. Tale organizzazione consente il rapi- dissimo reperimento dei record ricercati, al costo di dover poi unire i ri- sultati provenienti dalle varie tabelle per generare l’informazione desidera-
- Libera traduzione ed interpretazione della famosa definizione di Inmon: “A Data Warehouse is a subject-oriented, integrated, time variant, non-volatile collection of data in support of management’s decision making process”, W.H. Inmon, Building the Data Wa- rehouse , Usa, John Wiley & Sons, 1993.
- Per un approfondimento su Data Warehouse e Data Marts, si veda il citato W.H. In- mon, Building…
- Gli attuali Sistemi Gestionali si appoggiano su Data Base Management Systems (DBMS) di tipo relazionale. Tali database sono costituiti da un grande numero di tabelle elementari in cui gli oggetti sono descritti utilizzando tecniche avanzate di normalizzazione. Per maggiori approfondimenti si veda: Aa.Vv., Database Systems , Usa, Prentice-Hall, 1972.
- Si pensi, a titolo di esempio, che il sistema SAP R/3 utilizza oltre 22.000 tabelle.
ta. Si faccia ad esempio riferimento alle tabelle riportate in Fig. 4: volen- do ottenere informazioni sulla collocazione geografica di un certo nego- zio, sarà necessario ricercare i dati nella tabella Negozio, da cui si desu-
Fig. 3 - L’approntamento dei dati
Fig. 4 - L’organizzazione dei dati in un Sistema Gestionale
Sistemi Gestionali
OLTP Server
Altre forme
OLAP Server
Data Warehouse
Estrazione Trasformazione Caricamento Aggiornamento
Negozio
ID_negozio ID_città ID_regione Des_negozio …
ID_città Des_città …
Città
Vendita
ID_negozio ID_prodotto Data Importo Quantità …
ID_regione Des_regione …
Regione
Prodotto
ID_prodotto Des_prodotto ID_produtt …
ID_produtt Des_produtt …
Produttore
Altra caratteristica dei dati presenti in un Data Warehouse consiste nella suddivisione concettuale delle informazioni in Fatti e Dimensioni. I Fatti sono gli avvenimenti di cui si tiene traccia, le Dimensioni sono il modo in cui i Fatti sono organizzati. Riferendoci alla tabella di fig. 5, le ultime due colonne sulla destra (Importo e Quantità) sono i Fatti del fenomeno osser- vato (le vendite di un’ipotetica azienda), e le altre colonne sono le Dimen- sioni che caratterizzano tali Fatti (il Negozio, la Città, la Regione, il Pro- dotto venduto, il Produttore del bene e la Data di vendita). Diventa quindi possibile costruire uno schema logico di organizzazione dei Fatti come quello riportato in Fig. 6.
Si vengono così a creare dei costrutti logici che prendono il nome di Ipercubi^19 , che contengono i Fatti organizzati secondo una serie di Di- mensioni (si veda l’esempio riportato in Fig. 7). Come si diceva, dobbiamo reperire i dati di interesse e replicarli in un’opportuna struttura logica nel Data Warehouse: è necessario quindi predisporre opportune procedure per caricare il Data Warehouse stesso. Tali procedure prendono in letteratura il nome di ETL (Extraction, Tran-
- A differenza dei cubi, tali strutture hanno tipicamente più di tre dimensioni: da qui il nome di “Iper” cubi.
Fig. 6 - L’organizzazione dei dati in un DW: le dimensioni
Produttore
Dimensione Prodotto
Regione
Dimensione Mercato
Prodotto Negozio
Vendite
Anno
Dimensione Tempo
Mese
Settimana
Data
sformation and Loading), che potremmo tradurre come 1) Estrazione; 2) Trasformazione; 3) Caricamento / Aggiornamento. Prima di analizzare tali fasi in dettaglio, ricordiamo che il Data Wa- rehouse viene costruito su specifiche necessità dell’utente. È necessario quindi definire preliminarmente le specifiche del progetto, individuando con l’utente stesso quali potrebbero essere i dati e le infor- mazioni di cui avrà bisogno per elaborare le proprie decisioni; solo in se- guito a tale definizione iniziale sarà possibile identificare le fonti di dati da trasformare e caricare. Una volta proceduto a tale imprescindibile ope- razione, potremo passare alla fase ETL.
Estrazione
In questa fase, essendo note le richieste dell’utente per quanto riguarda le informazioni da ottenere, ricercheremo le fonti di dati da elaborare a tal fine. Due sono le grandi categorie di dati reperibili:
- Dati Interni : Questi dati riguardano l’azienda. Tipicamente di prove- nienza contabile; possibile utilizzo di dati extra-contabili, sia di tipo strutturato (Cont. Analitica, altri sistemi extra-contabili) sia non struttu- rato (Messaggi di Posta Elettronica, rapporti della Forza Vendita, ecc.).
- Dati Esterni : Questi dati riguardano l’ambiente esterno all’azienda (si- tuazioni economico-politiche, andamento dei mercati, comportamento
Fig. 7 - L’organizzazione dei dati in un DW: Ipercubo delle Vendite
Vendita
Prodotto
Locazione
Tempo
13.2.4. La predisposizione di un ambiente di analisi
Gli strumenti OLAP sono costituiti, solitamente, da almeno due compo- nenti: un Server OLAP , che gestisce i dati e provvede al buon funziona- mento del Data Warehouse, ed un Client OLAP , ad uso dell’utente finale, che funge da ambiente di riferimento in cui utilizzare i vari Tools per lo sfruttamento del Data Warehouse stesso (vedi Fig. 8).
La principale caratteristica del Client OLAP, oltre a quella di gestire gli strumenti di cui si diceva, è la facilità ed intuitività di utilizzo. Per questo motivo i fornitori di soluzioni di Business Intelligence ricorrono a tre principali tecnologie per realizzare le proprie interfacce:
- interfaccia proprietaria sviluppata “ad hoc”;
- interfaccia basata su Browser Web;
- interfaccia basata su MS Excel od altro strumento di Office Automa- tion. Le principali funzionalità previste sono:
- l’ Analisi interattiva dei dati;
- la possibilità di effettuare Query ;
- la capacità di creare interattivamente e facilmente Report personalizzati;
- gli strumenti di Data Mining.
Fig. 8 - L’organizzazione del Data Warehouse
Data Warehouse
OLAP Server
Strumenti
Analisi Query Report Data Mining
Tralasciando le Query ed i Report, concetti ormai noti 20 , approfondia- mo le altre due funzionalità.
Analisi
L’utente finale deve essere in grado di manipolare facilmente i dati pre- senti negli ipercubi del Data Warehouse effettuando una serie di operazio- ni che possono essere sinteticamente riassunte come segue:
- Roll Up : aggrega i dati, e cioè mostra i dati ad un maggior livello di aggregazione rispetto alla visione corrente (da giorni a settimane, da settimane a mesi, ecc.).
- Drill Down : disaggrega i dati e cioè mostra i dati ad un minor livello di aggregazione rispetto alla visione corrente (ad esempio da anni a mesi, da mesi a giorni, ecc.).
- Slice & Dice : “taglia” i dati secondo un certo criterio (Vendite di una sola Area Geografica) e “proietta” i dati su un piano bidimensionale (ad esempio, Clienti su Prodotti).
- Pivot : re-orienta il cubo “girando” le dimensioni di osservazione (da Clienti su Prodotti a Prodotti su Clienti).
Data Mining
Questo strumento è radicalmente diverso da quelli visti sinora: mentre in operazioni di Query, Reporting ed Analisi è l’utente che guida il sistema ri- cercando direttamente informazioni, nel caso del Data Mining è il sistema stesso che cerca relazioni e fenomeni non immediatamente evidenti nel patri- monio dei dati disponibili, avvalendosi di sofisticate tecniche statistiche e ma- tematiche, quali Reti Neurali, Fuzzy Logic, Analisi degli Scostamenti, ecc.
13.2.5. La predisposizione di un ambiente di simulazione
Oltre alle analisi sopra esposte, alcuni dei più recenti strumenti OLAP consentono anche tutte quelle operazioni che erano tipiche dei sistemi DSS: ci vogliamo riferire alle simulazioni di tipo “ What If ”, a quelle di ti- po “ Goal Seeking ” ed all’ Analisi degli Scenari^21.
- Per approfondimenti si veda il capitolo: “I programmi applicativi per la gestione dei database: MS Access”.
- Per maggiori approfondimenti su queste operazioni, e per alcuni esempi pratici, si veda la letteratura citata precedentemente in merito ai DSS ed inoltre il capitolo su “La modellizzazione mediante Fogli Elettronici”.
L’approntamento dei dati
Come si evince dallo schema riportato in Fig. 9, abbiamo utilizzato MS Access per gestire le procedure di trattamento dei dati. A titolo di esem- pio, possiamo ipotizzare l’estrazione di una serie di dati relativi alle ven- dite; tali dati, reperibili nel Sistema Gestionale, saranno organizzati in ta- belle normalizzate (si veda quanto detto in precedenza), e verranno repli- cati su un apposito server sotto forma di tabelle in un database MS Access allestito a tal fine (vedi Fig. 10). Come già detto, si dovrà opportunamente pianificare la frequenza di ag- giornamento di tale operazione di estrazione, a cui seguirà una serie di operazioni di trasformazione e pulizia, che tralasciamo per brevità. In am- biente MS Access si predisporrà, tra le altre, una query che creerà una ta- bella contenente i dati de-normalizzati pronti per l’utente finale (Vendi- te_2003_01) in un database appositamente predisposto (DW-Vendite.MDB). In Figura 11 riportiamo la query di trasformazione e creazione della nuo- va tabella, in Figura 12 il database dopo l’esecuzione della query, ed in Figura 13 il contenuto della nuova tabella. Sarà a questo punto disponibile un database pronto per essere utilizzato dall’utente finale. Tale database dovrà essere condiviso, tipicamente attra- verso la Rete Locale. Nel nostro esempio abbiamo dato la possibilità all’utente finale di accedere al database “Vendite” tramite ODBC , un me- todo di accesso ai dati disponibile in ambiente Windows.
Fig. 9 - Lo schema di riferimento
Altre Fonti
Access Excel
Decisore
Data Warehouse
Data Marts
DB Opera- tivi
Analisi Query Report Simulazione
Estraz. Trasform. Caricam. Aggiorn.
Fig. 10 - Il database prima delle trasformazioni
Fig. 11 - La query di trasformazione
