Data warehouse ed ERP | ARCHIVIO DATI CENTRALE : STORIA ED EVOLUZIONI

ARCHIVIO DATI CENTRALE : STORIA ED EVOLUZIONI

I due temi dominanti della corporate technology negli anni 90 sono
stati i data warehouse e l’ERP. Per molto tempo queste due potenti
correnti sono state parti della corporate IT senza mai avere
intersezioni. Era quasi come se fossero materia ed anti-materia. Ma
la crescita di entrambi i fenomeni ha portato inevitabilmente a una
loro intersezione. Oggi le aziende stanno affrontando il problema di
che cosa fare con ERP e data warehouse. Questo articolo illustrerà
quali sono i problemi e come vengono affrontati dalle aziende .
ALL’INIZIO…
All’inizio c’era il data warehouse. Data warehouse è nato per
contrastare il sistema applicativo di elaborazione delle transazioni.
Nei primi tempi la memorizzazione dei dati era pensata per essere
solo un contrappunto alle applicazioni di elaborazione delle
transazioni. Ma al giorno d’oggi ci sono visioni molto più sofisticate
di quello che può fare un data warehouse. Nel mondo odierno il
data warehouse è inserito all’interno di una struttura che può essere
chiamata Corporate Information Factory.
LA CORPORATE INFORMATION FACTORY
(CIF)
La Corporate Information Factory ha dei componenti architetturali
standard: un livello di trasformazione e di integrazione del codice
che integra i dati mentre i dati si muovono dall’ambiente di
applicazione verso l’ambiente del data warehouse dell’impresa; un
data warehouse dell’azienda dove vengono memorizzati i dati
storici dettagliati e integrati. Il data warehouse dell’azienda serve da
fondamento sul quale possono essere costruite tutte le altre parti
dell’ambiente del data warehouse; un operational data store (ODS).
Un ODS è una struttura ibrida che contiene alcuni aspetti del data
warehouse e altri aspetti di un ambiente OLTP; data marts, in cui i
differenti reparti possono avere loro propria versione del data
warehouse; un data warehouse di esplorazione in cui i
“filosofi”(thinkers) dell’azienda possono presentare le loro queries di
72 ore senza effetto nocivo sul data warehouse; e una memoria
near line, in cui dati vecchi e dati bulk detail possono essere
memorizzati a buon mercato.
DOVE SI UNISCE L’ERP CON LA
CORPORATE INFORMATION FACTORY
L’ERP si unisce con la Corporate Information Factory in due punti.
Innanzitutto come un’applicazione di base (baseline) che fornisce i
dati dell’applicazione al data warehouse. In questo caso i dati,
generati come sottoprodotto di un processo di transazione,
vengono integrati e caricati nel data warehouse dell’azienda. Il
secondo punto di unione tra ERP e CIF e l’ODS. In effetti, in molti
ambienti l’ERP è utilizzato come un ODS classico.
Nel caso in cui ERP è utilizzato come applicazione di base, lo
stesso ERP può essere anche utilizzato nella CIF come ODS. In
ogni caso, se l’ERP deve essere utilizzato in entrambi i ruoli, ci
deve essere una netta distinzione tra le due entità. In altre parole,
quando l’ERP svolge il ruolo di applicazione di base e di ODS, le
due entità architetturali devono essere distinte. Se una singola
implementazione di un ERP prova a svolgere entrambi i ruoli
contemporaneamente ci saranno inevitabilmente dei problemi nella
progettazione e nell’implementazione di tale struttura.
SEPARARE ODS E APPLICAZIONI DI BASE
Ci sono molte ragioni che portano alla divisione dei componenti
architetturali. Forse la questione più eloquente per separare i
diversi componenti di un’architettura è che ogni componente
dell’architettura ha la propria vista. L’applicazione baseline serve
per uno scopo differente di quello dell’ODS. Provare a sovrapporre
una vista di applicazione baseline sul mondo di un ODS o viceversa
non è un modo giusto di lavorare.
Di conseguenza, il primo problema di un ERP nella CIF è quello di
verificare se c’è una distinzione fra le applicazioni baseline ed il
ODS.
DATA MODELS NELLA CORPORATE
INFORMATION FACTORY
Per realizzare una coesione fra i differenti componenti
dell’architettura della CIF, ci deve essere un modello di dati. I
modelli di dati servono da legame tra i vari componenti
dell’architettura come ad esempio le applicazioni baseline e l’ODS. I
modelli di dati diventano la “carta stradale intellettuale” per avere il
giusto significato dai differenti componenti architettonici della CIF.
Andando di pari passo con questa nozione, l’idea è che ci dovrebbe
essere un grande e unico modello di dati. Ovviamente ci deve
essere un modello di dati per ciascuno dei componenti e inoltre ci
deve essere un percorso sensato che collega i modelli differenti.
Ogni componente dell’architettura – ODS, applicazioni baseline,
data warehouse dell’azienda, e così via.. – necessita del proprio
modello di dati. E quindi ci deve essere una definizione precisa di
come questi modelli di dati si interfacciano a vicenda.
SPOSTARE I DATI DELL’ERP NEL DATA
WAREHOUSE
Se l’origine dei dati è un’applicazione baseline e/o un ODS, quando
l’ERP inserisce i dati nel data warehouse, tale inserimento deve
avvenire al più basso livello di “granularity”. Ricapitolare o
aggregare semplicemente i dati così come vengono fuori
dall’applicazione baseline dell’ERP o dall’ODS dell’ERP non è la
cosa giusta da fare. I dati dettagliati sono necessari nel data
warehouse per costituire le basi del processo di DSS. Tali dati
saranno rimodellati in molti modi dai data marts e dalle esplorazioni
del data warehouse.
Lo spostamento dei dati dall’ambiente dell’applicazione baseline
dell’ERP all’ambiente del data warehouse dell’azienda è fatto in un
modo ragionevolmente disteso. Tale spostamento accade dopo che
circa 24 ore dall’aggiornamento o dalla creazione nel ERP. Il fatto di
avere un movimento “pigro” dei dati nel data warehouse
dell’azienda permette ai dati provenienti dall’ERP di “depositarsi”.
Una volta che i dati sono depositati nell’applicazione baseline,
allora è possibile spostare in modo sicuro i dati dell’ERP
nell’impresa. Un altro obiettivo raggiungibile grazie al movimento
“pigro” dei dati è la chiara delimitazione fra processi operazionali e
DSS. Con un movimento “veloce” dei dati la linea di demarcazione
tra DSS e operazionale rimane vaga.
Il movimento dei dati dall’ODS dell’ERP al data warehouse
dell’azienda viene fatto periodicamente, solitamente
settimanalmente o mensilmente. In questo caso il movimento dei
dati è basato sulla necessità di “pulire” i vecchi dati storici.
Naturalmente, l’ODS contiene i dati che sono molto più recenti
rispetto ai dati storici trovati nel data warehouse.
Lo spostamento dei dati nel data warehouse non è quasi mai fatto
“all’ingrosso” (in a wholesaler manner). Copiare una tabella
dall’ambiente ERP al data warehouse non ha senso. Un approccio
molto più realistico è lo spostamento di unità selezionate dei dati.
Solo i dati che sono cambiati dall’ultimo aggiornamento del data
warehouse sono quelli che dovrebbero essere spostati nel data
warehouse. Un modo per sapere quali dati sono stati modificati
dall’ultimo aggiornamento è quello di guardare i timestamp dei dati
trovati nell’ambiente ERP. Il progettista seleziona tutti i cambiamenti
che si sono presentati dall’ultimo aggiornamento. Un altro approccio
è quello di usare tecniche di acquisizione di cambiamento dati. Con
queste tecniche vengono analizzati log e journal tapes in modo da
determinare quali dati devono essere spostati dall’ambiente ERP a
quello del data warehouse. Queste tecniche sono le migliori in
quanto i log e i journal tapes possono essere letti dai file dell’ERP
senza ulteriori effetti sulle altre risorse dell’ERP.
ALTRE COMPLICAZIONI
Uno dei problemi dell’ERP nella CIF è quello che accade ad altre
fonti dell’applicazione o ai dati dell’ODS che devono contribuire al
data warehouse ma non fanno parte dell’ambiente di ERP. Data la
natura chiusa dell’ERP, specialmente SAP, il tentativo di integrare le
chiavi dalle fonti esterne dei dati con i dati che vengono dall’ERP al
momento di spostare i dati nel data warehouse, è una grande sfida.
E quante sono esattamente le probabilità che i dati di applicazioni o
ODS al di fuori dell’ambiente ERP saranno integrati nel data
warehouse? Le probabilità sono effettivamente molto alte.
REPERIRE DATI STORICI DALL’ERP
Un altro problema con i dati dell’ERP è quello derivante
dall’esigenza di avere dati storici all’interno del data warehouse.
Solitamente il data warehouse ha bisogno di dati storici. E
solitamente la tecnologia dell’ERP non memorizza questi dati
storici, almeno non fino al punto in cui è necessario nel data
warehouse. Quando una grande quantità di dati storici comincia ad
aggiungersi nell’ambiente di ERP, tale ambiente deve essere
ripulito. Per esempio si supponga che un data warehouse debba
essere caricato con cinque anni di dati storici mentre l’ERP tiene al
massimo sei mesi di questi dati. Finché la società è soddisfatta di
raccogliere una serie di dati storici man mano che passa il tempo,
allora non ci sono problemi nell’utilizzare l’ERP come sorgente per il
data warehouse. Ma quando il data warehouse deve andare
indietro nel tempo e prendere dei dati storici che non sono stati
precedentemente raccolti e salvati dall’ERP, allora l’ambiente ERP
diventa inefficiente.
ERP E METADATI
Un’altra considerazione da fare su ERP e data warehouse è quella
sui metadati esistenti nell’ambiente ERP. Così come i metadati
passano dall’ambiente ERP all’ambiente del data warehouse, i
metadati devono essere spostati nello stesso modo. Inoltre, i
metadati devono essere trasformati nel formato e nella struttura
richiesti dall’infrastruttura del data warehouse. C’è una grande
differenza tra metadati operazionali e metadati DSS. I metadati
operazionali sono soprattutto per lo sviluppatore e per il
programmatore. I metadato DSS sono principalmente per l’utente
finale. I metadati esistenti nelle applicazioni ERP o negli ODS
devono essere convertiti e questa conversione non è sempre facile
e diretta.
SOURCING THE ERP DATA
Se l’ERP è usato come fornitore di dati per il data warehouse ci
deve essere una solida interfaccia che sposta i dati dall’ambiente
ERP all’ambiente data warehouse. L’interfaccia deve:
▪ essere facile da usare
▪ permettere l’accesso ai dati dell’ERP
▪ prelevare il significato dei dati che stanno per essere spostati
nel data warehouse
▪ conoscere le limitazioni dell’ERP che potrebbero nascere nel
momento in cui viene effettuato l’accesso ai dati dell’ERP:
▪ integrità referenziale
▪ relazioni gerarchiche
▪ relazioni logiche implicite
▪ convenzione dell’applicazione
▪ tutte le strutture dei dati supportate dall’ERP, e così via…
▪ essere efficiente nell’accesso ai dati, fornendo:
▪ movimento diretto dei dati
▪ acquisizione di cambiamento dati
▪ essere di appoggio all’accesso tempestivo ai dati
▪ capire il formato dei dati, e così via…
INTERFACCIARSI CON SAP
L’interfaccia può essere di due tipi, homegrown o commerciale.
Alcune delle principali interfacce commerciali includono:
▪ SAS
▪ Prims Solutions
▪ D2k, e così via…
TECNOLOGIE DI ERP MULTIPLI
Trattare l’ambiente ERP come se fosse un’unica tecnologia è un
grosso errore. Ci sono molte tecnologie di ERP, ognuna con i suoi
punti di forza. I vendor più conosciuti nel mercato sono:
▪ SAP
▪ Oracle Financials
▪ PeopleSoft
▪ JD Edwards
▪ Baan
SAP
SAP è il software di ERP più grande e più completo. Le applicazioni
di SAP comprendono molti tipi di applicazioni in molte aree. SAP ha
la reputazione di essere:
▪ molto grande
▪ molto difficile e costoso da implementare
▪ ha bisogno di molte persone e consulenti per essere
implementato
▪ necessita di persone specializzate per l’implementazione
▪ ha bisogno di molto tempo per essere implementato
Inoltre SAP ha la reputazione di memorizzare i suoi dati molto
attentamente, rendendo difficile accedere a questi da parte di una
persona esterna all’area SAP. La forza di SAP è quella di essere
capace di catturare e memorizzare una grande quantità di dati.
Recentemente SAP ha annunciato la sua intenzione di estendere le
sue applicazioni ai data warehouse. Ci sono molti pro e contro
nell’utilizzo di SAP come fornitore di data warehouse.
Un vantaggio è che SAP è già installato e che la maggior parte dei
consulenti già conosce SAP.
Gli svantaggi di avere SAP come fornitore di data warehouse sono
molti: SAP non ha esperienza nel mondo del data warehouse
Se SAP è il fornitore di data warehouse, è necessario “portare fuori”
i dati da SAP al data warehouse. Dato un SAP’s track record of
closed system, è improbabile che sia facile ottenere i da SAP in
esso (???). Ci sono molti legacy environment che alimentano SAP,
come IMS, VSAM, ADABAS, ORACLE, DB2, e così via.
SAP insiste in un approccio “not invented here”. SAP non vuole
collaborare con altri fornitori per usare o creare il data warehouse.
SAP insiste nel voler generare tutto il proprio software da solo.
Sebbene SAP sia una compagnia grande e potente, il fatto di
tentare di riscrivere la tecnologia di ELT, OLAP, amministrazione del
sistema e persino il codice di base del dbms è semplicemente folle.
Invece di assumere un atteggiamento di cooperazione con i fornitori
di data warehouse di vecchia data, SAP ha seguito l’approccio che
loro “ne sanno di più”. Questo atteggiamento frena il successo che
SAP potrebbe avere nell’area dei data warehouse.
Il rifiuto di SAP nel permettere ai fornitori esterni di accedere
prontamente e con garbo ai loro dati. L’essenza stessa dell’uso di
un data warehouse è l’accesso facile ai dati. L’intera storia di SAP è
basata sul rendere difficile l’accesso ai dati.
La mancanza di esperienza di SAP nel trattare grandi volumi di dati;
nel campo dei data warehouse esistono volumi di dati mai visti da
SAP e per gestire queste grandi quantità di dati occorre avere una
tecnologia adatta. SAP apparentemente non è informata di questa
barriera tecnologica che esiste per entrare nel campo dei data
warehouse.
La corporate culture di SAP: SAP ha creato un business
nell’ottenere i dati dal sistema. Ma per fare questo bisogna avere
una mentalità differente. Traditionally, software companies that were
good at getting data into an environment have not been good at
getting data to go the other way. Se SAP riesce a fare questo tipo di
switch sarà la prima azienda a farlo.
In breve, è lecito chiedersi se un’azienda dovrebbe selezionare
SAP come fornitore di data warehouse. Ci sono rischi molto gravi
da una parte e molte poche ricompense dall’altra. Ma c’è un altro
motivo che scoraggia la scelta di SAP come fornitore di data
warehouse. Perché ogni compagnia dovrebbe avere lo stesso data
warehouse di tutte le altre compagnie? Il data warehouse è il cuore
del vantaggio competitivo. Se ogni compagnia adottasse lo stesso
data warehouse sarebbe difficile, anche se non impossibile,
raggiungere un vantaggio competitivo. SAP sembra pensare che un
data warehouse può essere visto come un biscotto e ciò è un
ulteriore segnale della loro mentalità di applicazioni “get the data
in”.
Nessun altro fornitore di ERP è dominante quanto SAP.
Indubbiamente ci saranno aziende che seguiranno la strada di SAP
per i loro data warehouse ma presumibilmente questi data
warehouse SAP saranno grandi, costosi e richiederanno molto
tempo per la loro creazione.
Questi ambienti includono tali attività quali “bank teller processing”,
processi per le prenotazioni aeree, processi per le lamentele
assicurative, e così via. Più performante era sistema di transazione,
più ovvio era il bisogno di separazione tra processo operazionale e
DSS (Decision Support System). Tuttavia, con sistemi di risorse
umane e personali, non ci si trova mai di fronte a grossi volumi di
transazioni. E, naturalmente, quando una persona è assunta
oppure lascia la compagnia questo è un record di una transazione.
Ma relativamente ad altri sistemi, i sistemi di risorse umane e
personali semplicemente non hanno molte transazioni. Perciò, nei
sistemi di risorse umane e personali non è del tutto ovvio che ci sia
bisogno di un DataWarehouse. In molti modi questi sistemi
rappresentano l’accorpamento di sistemi DSS.
Ma c’è un altro fattore che deve essere considerato se si ha a che
fare con datawarehouse e con PeopleSoft. In molti ambienti, i dati
delle risorse umane e personali sono secondari rispetto al business
primario della società. La maggior parte delle società svolgono
attività manifatturiere, di vendita, forniscono servizi e così via. I
sistemi di risorse umane e personali sono di solito secondari (o di
supporto) alla linea principale di business della società. Perciò, è
equivoco e poco conveniente un data warehouse separato per il
supporto alle risorse umane e personali.
PeopleSoft è molto diverso da SAP a questo riguardo. Con SAP, è
obbligatorio che ci sia un data warehouse. Con PeopleSoft, non è
poi così chiaro. Un datawarehouse è opzionale con PeopleSoft.
La cosa migliore che si possa dire per i dati PeopleSoft è che il data
warehouse può essere usato al fine di archiviare i dati relativi a
vecchie risorse umane e personali. Una seconda ragione per la
quale una compagnia vorrebbe usare un data warehouse a
discapito dell’ambiente PeopleSoft è di permettere l’accesso e
l’accesso libero agli strumenti di analisi, ai dati di PeopleSoft. Ma
oltre a queste ragioni, possono esserci casi in cui è preferibile non
avere un datawarehouse per dati PeopleSoft.
In sintesi
Ci sono molti spunti che riguardano la costruzione di un data
warehouse dentro ad un software ERP.
Alcuni di questi sono:
▪ Ha senso avere un data warehouse che somiglia a qualsiasi
altro nell’industria?
▪ Quanto è flessibile un ERP data warehouse software?
▪ Un ERP data warehouse software può gestire un volume di
dati che si trova in una “data warehouse arena”?
▪ Qual è la registrazione della traccia che il vendor ERP fa di
fronte a facili e poco costosi, in termini di tempo, ai dati? (what
is the ERP vendors track record on delivery of inexpensive, on
time, easy to access data?)
▪ Qual è la comprensione dell’architettura DSS e della
“corporate information factory” da parte del vendor ERP?
▪ I vendor ERP comprendono come ottenere dati all’interno
dell’ambiente, ma comprendono anche come esportarli?
▪ Quanto aperto è il venditore dell’ERP a strumenti di data
warehousing?
Tutte queste considerazioni devono essere fatte nel determinare
dove mettere il data warehouse che ospiterà i dati dell’ERP e altri
dati. In generale, a meno ché non ci sia una ragione irresistibile per
fare altrimenti, è raccomandato costruire data warehouse fuori
dall’ambiente del vendor dell’ERP.
CAPITOLO 1
Overview of the BI Organization
Punti chiave:
I depositi delle informazioni funzionano in modo contrario rispetto
all’architettura di business intelligence (BI):
La corporate culture e l’IT possono limitare il successo nella
costruzione di organizzazioni di BI.
La tecnologia non è più il fattore che limita le organizzazioni di BI. Il
problema per architetti e pianificatori di progetto non è se la
tecnologia esiste, ma se possono implementare efficacemente la
tecnologia disponibile.
Per molte aziende un data warehouse è poco più di un deposito
passivo che distribuisce i dati agli utenti che ne necessitano. I dati
sono estratti dai sistemi sorgenti e sono popolati in strutture target
di data warehouse. I dati possono anche essere puliti con tutta la
fortuna. Tuttavia nessun valore supplementare è aggiunto o
raccolto dai dati durante questo processo.
Essenzialmente, il Dw passivo, nel migliore dei casi, fornisce
soltanto i dati puliti e operativi agli associazioni di utenti. La
creazione delle informazioni e la comprensione analitica dipendono
interamente dagli utenti. Giudicare se il DW (Data warehouse) sia
un successo è soggettivo. Se giudichiamo il successo sulla
capacità di raccogliere, integrare e pulire efficientemente i dati
corporativi su una base prevedibile, allora sì, il DW è un successo.
D’altra parte, se guardiamo la raccolta, la consolidazione e lo
sfruttamento delle informazioni l’organizzazione nell’insieme, allora
il DW è un fallimento. Un DW fornisce poco o nessun valore delle
informazioni. Di conseguenza gli utenti sono costretti ad arrangiarsi,
creando cosi dei sili delle informazioni. Questo capitolo presenta
una visione completa per ricapitolare l’ architettura di BI(Business
Intelligence) dell’aziende. Cominciamo con una descrizione di BI e
quindi ci muoveremo verso le discussioni sulla progettazione e sullo
sviluppo delle informazioni, in contrasto con il semplice fornire i dati
agli utenti. Le discussioni allora sono focalizzate sul calcolo del
valore dei vostri sforzi di BI. Concludiamo con il definire come l’IBM
richiama i requisiti architettonici di BI della vostra organizzazione.
Descrizione dell’architettura di
organizzazione della BI
I potenti sistemi d’informazione transaction-oriented ora sono
all’ordine del giorno in ogni grande impresa , in quanto livellano
efficacemente il campo da giuoco per le società nel mondo.
Rimanere competitivi, tuttavia, ora richiede sistemi analiticamente
orientati a che può rivoluzionare l’abilità dell’azienda riscoprendo ed
utilizzando le informazioni che già possiedono. Questi sistemi
analitici derivano dalla comprensione dalla ricchezza dei dati
disponibili. La BI può migliorare le prestazioni in tutte le informazioni
dell’impresa. Le aziende possono migliorare i rapporti tra cliente e
fornitori, migliorare il profitto dei prodotti e dei servizi, generare
nuove e migliori offerte , controllare il rischio e fra molti altri
guadagni tagliano le spese drasticamente . Con BI la vostra
azienda finalmente incomincia ad usare le informazioni del cliente
come bene competitivo grazie ad applicazioni che hanno obiettivi di
mercato.
Avere i giusti mezzi di Business significa avere risposte definitive a
domande di chiave come:
▪ Quale dei nostri clienti ci fanno guadagnare di più, o ci
mandano in perdita?
▪ Dove vivono I nostri migliori clienti in relazione al negozio/
magazzino che loro frequentano?
▪ Quali dei nostri prodotti e servizi possono essere venduti più
efficacemente e a chi?
▪ Quali prodotti può essere venduto più efficacemente e a chi?
▪ Quale campagna di vendita è più riuscita e perchè?
▪ Quali canali di vendite sono più efficaci per quali prodotti?
▪ Come possiamo migliorare i rapporti con nostri migliori clienti?
La maggior parte delle aziende hanno dati grezzi per rispondere a
queste domande.
I sistemi operazionali generano ampie quantità di prodotto, di
cliente e di dati di mercato dai punti di vendita, dalle prenotazioni,
dal servizio di cliente e dai sistemi di supporto tecnico. La sfida è
estrarre e sfruttare queste informazioni.
Molte aziende approfittano soltanto di piccole frazioni dei loro dati
per le analisi strategiche.
I dati restanti, uniti spesso con i dati derivanti fonti esterne come i
“government reports” , e altre informazioni comprate, sono una
miniera d’oro che attende solo di essere esplorata, e i dati devono
essere solo raffinati nel contesto informativo della vostra
organizzazione.
Questa conoscenza può essere applicata in diversi modi, varianti
dal progettare una strategia corporativa generale alla
comunicazione personale con i fornitori, attraverso call center,
fatturazioni, Internet ed altri punti. L’odierno ambiente di affari detta
che il DW e le soluzioni relative della BI si evolvono oltre
l’esecuzione di tradizionali strutture di dati quali i dati normalizzati a
livello-atomico ed “star/cube farms”.
Ciò che è necessario per rimanere competitivi è una fusione di
tradizionale e tecnologie avanzate in uno sforzo per sostenere un
vasto paesaggio analitico.
Per concludere, l’ambiente generale deve migliorare la conoscenza
dell’impresa nell’insieme, accertandosi che le azioni intraprese
come conseguenza di analisi condotte tornino utili affinchè tutti si
avvantaggino.
Per esempio, diciamo che classificate i vostri clienti nelle categorie
di alto o basso rischio.
Se queste informazioni sono generate da un modello estraente o
altri mezzi, deve essere messo nel Dw ed essere reso accessibile a
chiunque, per mezzo di qualsiasi strumento di accesso, quali i
rapporti statici, fogli elettronici, tabelle, o elaborazione analitica in
linea (OLAP).
Tuttavia, attualmente, molte di questo tipo di informazioni
rimangono nei sili di dati degli individui o reparti che generano
l’analisi. L’organizzazione, nell’insieme, ha poca o nessuna visibilità
per la comprensione. Soltanto mescolando questo tipo di contenuto
informativo nel vostro Dw di impresa potete eliminare i sili delle
informazioni ed elevare il vostro ambiente di Dw.
Ci sono due ostacoli importanti per lo sviluppo di un’organizzazione
della BI.
In primo luogo, abbiamo il problema dell’organizzazione in se e
della relativa disciplina.
Anche se non possiamo aiutare con cambiamenti di politica
dell’organizzazione, possiamo aiutare a capire i componenti di
un’organizzazione della BI, la relativa architettura e come la
tecnologia dell’IBM facilita il relativo sviluppo.
La seconda barriera da superare è la mancanza di tecnologia
integrata e la conoscenza di un metodo che richiama l’intero spazio
della BI in contrasto con solo un piccolo componente.
L’IBM sta venendo in contro ai cambiamenti di tecnologia
d’integrata. È vostra la responsabilità di fornire una progettazione
cosciente. Questa architettura deve essere sviluppata con
tecnologia scelta per integrazione senza vincoli, o per lo meno, con
tecnologia che aderisce agli standard aperti. Inoltre, la vostra
gestione dell’azienda deve assicurare che l’impresa di Bi è
effettuata secondo il programma e non quello di permettere lo
sviluppo dei sili delle informazioni che derivano da self-serving
ordini del giorno, o obiettivi.
Questo non vuol dire che l’ambiente della BI non è sensibile a
reagire ai diversi bisogni e requisiti di diversi utenti; invece, significa
che l’implementazione di quei bisogni dell’individuo e dei requisiti è
fatto a vantaggio di intera organizzazione della BI.
Una descrizione dell’architettura dell’organizzazione della BI può
essere trovata alla pagina 9 nella figura 1.1.L’architettura dimostra
una miscela ricca delle tecnologie e tecniche.
Dalla vista tradizionale, l’architettura include i seguenti componenti
di warehouse
Strato atomico(Atomic Layer).
Ciò è il fondamento, il cuore dell’intero Dw e quindi della
segnalazione strategica.
I dati memorizzati qui conserveranno l’integrità storica, rapporti di
dati ed includono la metrica derivata, come pure l’essere puliti,
integrati, e memorizzati usando i modelli estraenti.
Tutto l’uso successivo di questi dati e delle relative informazioni è
derivato da questa struttura. Questa è un eccellente fonte per
estrazione di dati e per report con query SQL strutturate
Deposito operativo di dati o segnalare base di
dati(Operational data store (ODS) or reporting
database.)
Questa è una struttura di dati specificamente progettata per le
segnalazione tecniche.
I dati memorizzati e riportati sopra queste strutture possono infine
propagarsi nel warehouse tramite la zona di organizzazione(staging
area), dove potrebbe essere usata per segnalazione strategica.
Staging area.
Il primo stop per la maggior parte dei dati destinati all’ambiente di
warehouse è la zona di organizzazione.
Qui i dati sono integrati, puliti e trasformati in dati utili che
popoleranno la struttura del warehouse
Data marts.
Questa parte dell’architettura rappresenta la struttura di dati usata
specificamente per OLAP. La presenza dei datamarts, se i dati sono
memorizzati negli star schema che sovrappongono dati
multidimensionali in un ambiente relazionale, oppure negli schedari
di dati riservati usati vicino la tecnologia specifica di OLAP, quale il
server di DB2 OLAP, non è rilevante.
L’unico vincolo è che l’architettura facilita l’uso dei dati
multidimensionali.
L’architettura comprende anche critiche tecnologie e tecniche di Bi
che si distinguono come:
Analisi Spaziale(Spatial analysis)
Lo spazio è un bene inaspettato delle informazioni per l’analista ed
è fondamentale per la risoluzione completa. Lo spazio può
rappresentare le informazioni delle persone che vivono in una certa
posizione, così come le informazioni circa dove quella posizione è
fisicamente rispetto al resto del mondo.
Per effettuare questa analisi, dovete cominciare legando le vostre
informazioni alle coordinate di latitudine e di longitudine. Ciò è
indicato come “geocoding” e deve fare parte dell’estrazione,
trasformazione, e del processo di caricamento (ETL) al livello
atomico del vostro warehouse.
Data mining.
L’estrazione dei dati permette alle nostre aziende di far crescere il
numero di clienti, di prevedere le tendenze di vendite e permettere
la gestione dei rapporti con i clienti (CRM), tra altre iniziative della
BI.
L’estrazione dei dati deve quindi essere integrata con le strutture di
dati del Dwhouse e sostenuta da processi di warehouse per
accertare sia l’uso efficace che efficiente del tecnologia e delle
tecniche relative.
Come indicato nell’architettura della BI, il livello atomico del
Dwhouse, così come i datamarts, è una eccellente sorgente di dati
per l’estrazione. Quelle stesse strutture devono anche essere
destinatari di risultati dell’estrazione per accertare la disponibilità ai
più vasti pubblici.(broadest audience).
Agents.
Ci sono vari “agents” per esaminare il cliente per ogni punto come, i
sistemi operativi dell’azienda e gli stessi dw. Questi agenti possono
essere reti neurali avanzate addestrate ad apprendere sulle
tendenze di ogni punto, come la richiesta futura del prodotto basata
sulle promozioni di vendite, motori basati su regole per reagire ad
un dato insieme di circostanze, o persino agenti semplici che
segnalano le eccezioni ai “top executives”. Questi processi si
presentano generalmente in tempo reale e, pertanto, devono
essere accoppiati strettamente con il movimento degli stessi dati.
Tutte queste strutture di dati, tecnologie e tecniche garantiscono
che non passerete la notte a generare un’organizzazione della
vostra BI.
Questa attività sarà sviluppata a passi incrementali, per piccoli
punti.
Ogni passo è uno sforzo indipendente di progetto, ed è riferito
come un iterazionenel vostro dw o iniziativa di BI. Le iterazioni
possono includere l’implementazione di nuove tecnologie, per
iniziare con le nuove tecniche, aggiungendo nuove strutture di dati ,
caricando i dati supplementari , o con l’espansione di analisi del
vostro ambiente. Questo paragrafo è discusso più
approfonditamente nel capitolo 3.
Oltre alle strutture tradizionali di Dw e strumenti di Bi ci sono altre
funzioni della vostra organizzazione della BI per cui dovete
progettare, come:
Punti di contatto del cliente(Customer touch
points).
Come con tutta l’organizzazione moderna esiste un certo numero di
punti di contatto del cliente che indicano come avere un esperienza
positive per i vostri clienti. Ci sono i canali tradizionali quali i
commercianti, i centralinisti, la posta diretta, multimedia e stampa
pubblicitaria, così come i canali più attuali come email e web, i dati
prodotti con qualche punto di contatto devono essere acquisiti,
trasportati, puliti, trasformati ed poi popolati a strutture di dati della
BI.
Basi di dati operative e associazioni di utenti (Operational
databases and user communities).
Alla fine dei punti di contatto dei clienti si trovano le basi di dati
dell’applicazione della ditta e delle comunità di utenti. I dati esistenti
sono dati tradizionali che devono essere riuniti e fusi con i dati che
fluiscono dai punti di contatto per soddisfare le necessarie
informazioni.
Analisti. (Analysts)
Il beneficiario principale dell’ambiente della BI è l’analista. È lui che
trae beneficio dall’estrazione attuale di dati operativi , integrati con
diverse fonti di dati , aumentate con caratteristiche quale analisi
geografiche (geocoding) e presentato in tecnologie di BI che
permettono di estrarre, OLAP, avanzati reporting di SQL e analisi
geografiche. L’interfaccia primaria per l’analista per l’ambiente di
reporting è il portal della BI.
Tuttavia, l’analista non è l’unico a beneficiare dall’architettura della
BI.
Dirigenti, vaste associazioni di utenti, e perfino i soci, i fornitori ed i
clienti dovrebbero trovare dei benefici nella BI di impresa.
Back-feed loop.
L’architettura della BI è un ambiente di apprendimento. Un principio
caratteristico dello sviluppo è permettere persistenti strutture di dati
da aggiornare mediante tecnologia della BI usata e mediante azioni
intrapese dell’utente. Un esempio è la valutazione del
cliente(customer scoring).
Se il reparto di vendita effettua un modello estraente (mining model)
dello scores del cliente come per usare un nuovo servizio, allora il
reparto di vendita non dovrebbe essere l’unico gruppo beneficiario
del servizio.
Invece, il modello estraente dovrebbe essere effettuato come parte
naturale del data flow dentro l’impresa e lo scores del cliente
dovrebbe diventare una parte integrata del contesto informativo del
magazzino, visibile a tutti gli utenti. La Suite dell’IBM di Bi-bI-centric
compreso DB2 UDB, DB2 OLAP Server comprende la maggior
parte dei componenti importanti di tecnologia, definita nella figura
1.1.
Noi usiamo l’architettura come appare in questa figura del libro per
darci un livello di continuità e dimostrare come ogni prodotto
dell’IBM si adattano allo schema generale della BI.
Fornire Il Contenuto Informativo(Providing
Information Content)
Progettare, sviluppare ed implementare il vostro ambiente di BI è
un’operazione ardua. La progettazione deve abbracciare tanto gli
attuali che i futuri requisiti di business. Il disegno dell’architettura
deve essere completo per includere tutte le conclusioni trovate
durante la fase di progettazione. L’esecuzione deve rimanere
impegnata per un singolo scopo: sviluppare l’architettura della BI
come presentata formalmente nel disegno e fondata sui requisiti di
business.
È particolarmente difficile sostenere che la disciplina assicurerà il
relativo successo.
Ciò è semplice perché non si sviluppa un ambiente della BI tutto
d’un tratto, ma si effettua in piccoli passi col tempo.
Tuttavia, identificare i componenti della BI della vostra architettura è
importante per due motivi: Guiderete tutte le successive decisioni
tecniche di architettura.
Potrete progettare coscientemente un uso particolare di tecnologia
anche se potreste non ottenere una ripetizione che ha bisogno della
tecnologia per parecchi mesi.
Il capire sufficientemente i vostri requisiti di business influirà il tipo
di prodotti che acquisirete per la vostra architettura.
La progettazione e lo sviluppo della vostra architettura assicurano
che il vostro warehouse sia
non un evento aleatorio, ma piuttosto un “well-thought-out”,
attentamente costruito ad opera d’arte come un mosaico di
tecnologia mescolata.
Progettare il contenuto informativo
Tutta la progettazione iniziale deve mettere a fuoco e identificare i
componenti principali della BI che saranno necessari all’ambiente
generale in presente e in futuro.
Conoscere i requisiti di Business è importante.
Anche prima che tutta la progettazione convenzionale cominci, il
pianificatore di progetto può spesso identificare uno o due
componente subito.
L’equilibrio dei componenti che potrebbero essere necessari per la
vostra architettura, tuttavia, non può essere trovato facilmente.
Durante la fase di progettazione, la parte principale dell’architettura
lega la sessione di sviluppo dell’applicazione (JAD) su una ricerca
per identificare i requisiti di business.
A volte questi requisiti possono essere affidati a strumenti di
interrogazioni e di reporting .
Per esempio, gli utenti dichiarano che se desiderano automatizzare
attualmente un report devono generare manualmente integrando
due rapporti attuali ed aggiungendo i calcoli derivati dalla
combinazione dei dati.
Anche se questo requisito è semplice, definisce una certa
funzionalità della caratteristica che voi dovete includere quando
comprate strumenti di reporting per l’organizzazione.
Il progettista deve anche perseguire i requisiti supplementari per
ottenere un’immagine completa. Gli utenti desiderano abbonarsi a
questo report?
I sottoinsiemi del report sono generati e spediti via email ai vari
utenti? Desiderano vedere questo report nel portale aziendale?
Tutti questi requisiti fanno parte della semplice necessità di
sostituire un report manuale come richiesto dagli utenti. Il beneficio
di questi tipi di requisiti è che ognuno, utenti ed i progettisti, hanno
una conoscenza del concetto dei report.
Ci sono altri tipi di business , tuttavia, che dobbiamo programmare.
Quando i requisiti di business sono dichiarati sotto forma di
domande strategiche di Business, è facile per il progettista esperto
discernere i requisiti di measure/fact e dimensionali.
Figura 1.2 illustra componenti di misura e dimensionali di un
problema di Business.
Se gli utilizzatori di JAD non sanno come dichiarare i loro requisiti
sotto forma di un problema di business, il progettista fornirà spesso
degli esempi per saltare-avviare la sessione della raccolta dei
requisiti.
L’esperto progettista può aiutare gli utenti a capire non soltanto il
commercio strategico, ma anche come formarlo.
L”approccio della raccolta dei requisiti è discussa nel capitolo 3; per
ora desideriamo soltanto indicare la necessità di progettare per tutti
i tipi di requisiti della BI
Una problema strategico di Business è, non soltanto un requisito di
Business, ma anche un indizio progettuale. Se dovete rispondere
ad una domanda multidimensionale, allora dovete memorizzare,
presentare i dati dimensionali, e se avete bisogno di memorizzare i
dati multidimensionali, dovete decidere che tipo di tecnologia o
tecnica state andando impiegare.
Implementate uno star schema a cubo riservato, o entrambi?
Come potete vedere, persino un semplice problema di business
può influenzare in modo considerevole la progettazione. Però
questi tipi di requisiti di business sono ordinari e beninteso, almeno
dai progettisti e dai pianificatori con esperienza di progetto.
C’è stato dibattito sufficiente sulle tecnologie e sul supporto di
OLAP, ed è disponibile una vasta gamma di soluzioni. Finora
abbiamo accennato la necessità di riunire semplici reporting con i
requisiti dimensionali di busineness, e come questi requisiti
influenzano decisioni tecniche di architettura.
Ma che cosa sono i requisiti che non sono prontamente compresi
dagli utenti o dal team di Dw ? Avrete mai bisogno dell’analisi
spaziale(analysisi spatial)?
I modelli estraenti di dati saranno una parte necessaria del vostro
futuro? Chi sa?
È importante notare che queste tipo di tecnologie non sono molto
conosciute dalle comunità di utenti generali e membri del team di
Dw, in parte, questo potrebbe accadere perché loro tipicamente
sono trattate da alcuni tecnici esperti interni o di terze parti. È un
caso limite dei problemi che questi tipi di tecnologie generano. Se
gli utenti non possono descrivere i requisiti di business o inquadrarli
in modo da fornire le linee guida ai progettisti, queste possono
passare inosservate o,peggio, ignorate semplicemente.
Più problematico diventa quando il progettista e lo sviluppatore non
possono riconoscere l’applicazione di una di queste avanzate ma
critiche tecnologie.
Come spesso abbiamo sentito i Progettisti dicono, “bene, perchè
non lo mettiamo da parte fino a che non otteniamo qust’altra cosa?
“Sono realmente interessati alle priorità, o semplicemente evitano i
requisiti che non capiscono? È molto probabilmente l’ultima ipotesi.
Diciamo che il vostro gruppo di vendita ha comunicato un requisito
di affari ,come dichiarato nella figura 1.3, come potete vedere, il
requisito è inquadrato sottoforma di un problema di business. La
differenza fra questo problema e il tipico problema dimensionale è
la distanza. In questo caso, il gruppo di vendita desidera conoscere,
su una base mensile, le vendite totali dai prodotti, i magazzini e i
clienti che vivono entro 5 miglia dal magazzino dove loro
acquistano.
Tristemente, i progettisti o gli architetti possono semplicemente
ignorare la componente spaziale dicendo, “abbiamo il cliente, il
prodotto ed i dati del deposito. Teniamo fuori la distanza fino ad
un’altra iterazione.
“Risposta sbagliata. Questo tipo di problema di business riguarda
interamente la BI. Rappresenta una comprensione più profonda del
nostro business e di un spazio analitico robusto per i nostri analisti.
La BI è oltre l’interrogazione semplice o la segnalazione standard, o
persino OLAP. Questo non vuol dire che queste tecnologie non
sono importanti per la vostra BI,ma da solenon rappresentano
l’ambiente della BI.
Progettare per il contesto di informazioni
(Designing for Information Content)
Ora che abbiamo identificato i requisiti di Business che distinguono
vari componenti fondamentali, si devono includere in un disegno
architettonico generale. Alcuni dei componenti della BI fanno parte
dei nostri sforzi iniziali, mentre alcuni non saranno implementati per
parecchi mesi.
Tuttavia, tutti i requisiti conosciuti sono riflessi nel progetto cosi che
quando dobbiamo implementare una tecnologia particolare, siamo
preparati a farlo. Qualcosa del progetto rifletterà il pensiero
tradizionale.
Per esempio, la figura 1.1, all’inizio del capitolo, mostra un data
mart che mantiene i dati dimensionali.
Questo insieme di dati è usato per sostenere gli usi successivi di
dati dimensionali guidati dalle problematiche di Business che
abbiamo identificato. Poichè i documenti supplementari sono
generati, come ad esempio lo sviluppo progettuale dei dati, noi
inizieremo a formalizzare come i dati si propagano nell’ambiente.
Abbiamo accertato la necessità di rappresentare i dati in modo
dimensionale, suddividendoli (secondo delle esigenze specifiche
determinate) in data marts.
La prossima domanda a cui rispondere è: come saranno costruiti
questi data marts?
Costruite le stelle per sostenere i cubi, o solo cubi, o solo le stelle?
(o cubi giusti, o stelle giuste). Generate l’architettura per i data
marts dipendenti che richiedono uno strato atomico per tutti i dati
aquisiti? Permettete ai data marts indipendenti acquisire i dati
direttamente dai sistemi operativi?
Che Tecnologia di cubi proverete a standardizzare?
Avete quantità voluminose dei dati richiesti per analisi dimensionale
o avete bisogno dei cubi della vostra forza vendite nazionale su una
base settimanale o su entrambe? Costruite un oggetto potente
come DB2 OLAP Server per la finanza o i cubi di Cognos
PowerPlay per la vostra organizzazione di vendite o entrambe?
Queste sono le grandi decisioni architettoniche di disegno che
avranno effetto sul vostro ambiente della BI da qui in avanti. Sì,
avete accertato una necessità di OLAP. Ora come effettuerete quel
tipo di tecnica e tecnologia?
Come alcune delle tecnologie più avanzate interessano i vostri
disegni? Presupponiamo che avete accertato una necessità
spaziale nella vostra organizzazione. Ora dovete richiamare le
edizioni architettoniche di disegno anche se non pianificate di
effettuare componenti spaziali per parecchi mesi. L’architetto deve
progettare oggi basandosi su ciò che serve. Prevedere l’esigenza di
analisi spaziale che genera, memorizza, effettua e fornisce
l’accesso ai dati spaziali. Ciò a sua volta dovrebbe servire da
vincolo per quanto riguarda il tipo di specifiche di tecnologia e di
piattaforma del software potete attualmente considerare. Per
esempio, il sistema di amministrazione della base di dati relazionale
(RDBMS) che effettuate per il vostro strato atomico deve avere
un’estensione spaziale robusta disponibile. Ciò accerterebbe le
prestazioni massime quando usate la geometria e gli oggetti
spaziali nelle vostre applicazioni analitiche. Se il vostro RDBMS non
può maneggiare i dati (spazial-centric) internamente, quindi dovrete
stabilire una base di dati (spaziale-centric) esterna. Ciò complica la
gestione delle edizioni e compromette le vostre prestazioni generali,
per non accennare i problemi supplementari generati per il vostro
DBAs, poiché probabilmente hanno una minima comprensione
delle basi di dati spaziali pure. D’altra parte, se il vostro motore di
RDMBS maneggia tutti i componenti spaziali ed il relativo
ottimizzatore è informato dei bisogni speciali (per esempio,
indexing) degli oggetti spaziali, allora il vostro DBAs può trattare
prontamente la gestione delle edizioni e potete elevare le
prestazioni.
Inoltre, dovete regolare la staging area (area di scena) e lo strato
d’ambiente atomico per includere la pulizia degli indirizzi (un
elemento chiave ad analisi spaziale), così come il successivo
salvataggio degli oggetti spaziali. Il susseguirsi delle edizioni di
disegno continua ora che abbiamo introdotto la nozione di pulizia di
indirizzo. Per una cosa, questa applicazione detterà il tipo di
software necessario per il vostro sforzo di ETL.
Avete bisogno dei prodotti come Trillium per fornirgli un indirizzo
pulito, o di un fornitore di ETL da voi prescelto per fornire quella
funzionalità?
Per ora esso è importante che apprezzate il livello del disegno che
deve essere completato prima che cominciate ad effettuare il vostro
ambiente (warehouse). Gli esempi precedenti dovrebbero
dimostrare la moltitudine di decisioni di disegno che devono seguire
l’identificazione di tutto il requisito particolare di affari. Se fatte
correttamente, queste decisioni di disegno promuovono
l’interdipendenza fra le strutture fisiche del vostro ambiente, la
selezione di tecnologia usata ed il flusso di propagazione del
soddisfare di informazioni. Senza questa architettura convenzionale
della BI, la vostra organizzazione sarà soggetta ad una miscela
caotica di tecnologie esistenti, nel migliore dei casi, unite in modo
non preciso per fornire una stabilità apparente.
Effettuare il soddisfare di informazioni
Portando il valore delle informazioni alla vostra organizzazione è
un’operazione molto difficile. Senza una sufficiente comprensione
ed esperienza, o progettazione e disegno adeguati, persino le
squadre migliori fallirebbero. D’altra parte, se avete una grande
intuizione e una progettazione dettagliata ma nessuna disciplina per
l’esecuzione, avete appena sprecato i vostri soldi e il vostro tempo
perché il vostro sforzo è destinato a fallire. Il messaggio dovrebbe
essere chiaro: Se state mancando di una o più di queste
competenze, comprensione/esperienza o progettazione/disegno o
disciplina di implementazione,questo porterà a paralizzare o
distruggere la costruzione dell’organizzazione della BI.
La vostra squadra sufficiente preparata? C’è qualcuno sulla vostra
squadra della BI che capisce il vasto paesaggio analitico disponibile
negli ambienti della BI, nelle tecniche e nelle tecnologie necessarie
per effettuare quel paesaggio? C’è qualcuno sulla vostra squadra
che può riconoscere la differenza di applicazione fra advanced
static reporting e OLAP,o le differenze fra ROLAP e OLAP? Uno dei
membri della vostra squadra riconosce chiaramente il modo di
estrarre e come esso potrebbe avere effetto sul warehouse o come
il warehouse può sostenere le prestazioni estraenti? Un membro
della squadra capisce il valore dei dati spaziali o la tecnologia
basata su agenti? Avete qualcuno che apprezzi l’applicazione unica
degli attrezzi di ETL contro tecnologia del mediatore del
messaggio? Se non l’avete, ottenetene uno. La BI è molto più
grande di uno strato atomico normalizzato, di OLAP, degli schemi a
stella e di un ODS.
Avere la comprensione e l’esperienza per riconoscere i requisiti
della BI e le loro soluzioni è essenziale alla vostra capacità di
formalizzare correttamente le esigenze degli utenti e di progettare
ed effettuare le loro soluzioni. Se la vostra comunità di utenza ha
difficoltà a descrivere i requisiti, è compito della squadra di
warehouse fornire quella comprensione. Ma se la squadra di
warehouse
non riconoscel’applicazione specifica della BI -per l’esempio, data
mining- allora non è la cosa migliore che gli ambienti della BI si
limitino spesso ad essere depositi passivi. Tuttavia, ignorare queste
tecnologie non diminuisce la loro importanza e l’ effetto che hanno
sulla nascita di possibilità di business intelligence della vostra
organizzazione, come pure l’assetto informativo che progettate
promuovere.
La progettazione deve comprendere la nozione del disegno, ed
entrambi richiedono un individuo competente. In più, il progettare
richiede una filosofia di werehouse di squadra e l’osservazione
degli standards. Per esempio, se la vostra azienda ha stabilito una
piattaforma standard o ha identificato un RDBMS particolare che si
desidera standardizzare per tutta la piattaforma, è incombente che
sulla squadra tutti aderiscano a quegli standard. Generalmente una
squadra espone l’esigenza della normalizzazione (to user
communites), ma la squadra in se è poco disposta a aderire agli
standard stabiliti anche in altre aree nell’azienda o forse anche nelle
società simili. Non solo questo è iporcrita, ma accerta l’impresa non
è capace di sfruttare le risorse e investimenti esistenti. Non significa
che non esistono situazioni che garantiscono una piattaforma o una
tecnologia non standardizzata; tuttavia, gli sforzi del warehouse
dovrebbero proteggere gelosamente gli standard dell’impresa fino a
che i requisiti di business non dettino il contrario.
Il terzo componente chiave necessario per costruire una BI
organization è la disciplina.
Dipende in totale, in uguale misura dagli individui e dall’ambiente.
Project planners, sponsor, architetti, e utenti devono apprezzare la
disciplina necessaria a costruire l’assetto informativo della società.
I progettisti devono dirigere i loro sforzi di progetto in modo tale da
completare altri sforzi necessari nella società.
Per esempio, supponiamo che la vostra società costruisca un
applicazione ERP che ha un componente warehouse.
Quindi è la responsabilità dei progettisti ERP di collaborare con il
team dell’ambiente di warehouse in modo da non competere o
duplicare i lavori gia in iniziati.
La disciplina è anche un argomento che deve essere occupato
dall’intera organizzazione ed è di solito stabilita e affidata a un
livello esecutivo.
I dirigenti sono disposti ad aderire ad un approccio progettato? Un
approccio che promette di creare contenuti di informazioni che alla
fine porterà valore a tutte le aree dell’impresa, ma forse
compromette singoli o departmental agendas? Ricordati il detto
“Pensare a tutto è più importante di pensare a un’unica cosa”.
Questo detto è vero per le organizzazioni BI.
Sfortunatamente molte warehouse concentrano i loro sforzi
cercando di indirizzare e portare valore a un particolare reparto o a
utenti specifici, con un piccolo riguardo all’organizzazione in
generale. Supponete che il dirigente richieda assistenza al team di
werehouse. Il team risponde con un lavoro durato 90 giorni che
include non solo la consegna dei requisiti di notifica definiti dal
dirigente ma assicura che tutti i dati base siano mischiati nel livello
atomico prima di essere introdotto nella tecnologia di cubo
proposta.
Questa aggiunta ingegneristica assicura che l’impresa di
werehouse trarrà benefici dai dati necessari al dirigente.
Tuttavia, il dirigente ha parlato con ditte di consulenza esterne che
hanno proposto una simile applicazione con consegna in meno di 4
settimane.
Assumendo che il team interno di werehouse sia competente, lo il
dirigente ha una scelta. Chi può supportare la disciplina di
ingegneria supplementare necessaria per coltivare il bene
informativo impresa o può scegliere di realizzare la propria
soluzione velocemente. L’ultimo sembra essere scelto veramente
troppo spesso e serve solo per creare contenitori di informazioni di
cui ne beneficiano in pochi o il singolo.
Obiettivi a Breve e Lunga scadenza
Gli architetti e i progettisti di progetto devono formalizzare una
visione a lunga scadenza dell’architettura generale e piani per
crescere in un’organizzazione BI. Questa combinazione di
guadagno a breve scadenza e pianificazione a lunga scadenza
rappresentano le due facce di sforzi BI. Il guadagno a breve
scadenza è la sfaccettatura di BI che è associata a iterazioni del
vostro warehouse.
È qui dove progettisti, architetti e sponsor si concentrano su
soddisfare requisiti commerciali specifici. È a questo livello dove le
strutture fisiche sono costruite, la tecnologia è acquistata e le
tecniche sono implementate. Sono affatto fatte per affrontare
requisiti specifici come definiti da particolare utente le comunità.
Tutto è svolto in con lo scopo di affrontare requisiti specifici definiti
da una particolare comunità.
La pianificazione a lunga scadenza, tuttavia, è l’altra sfaccettatura
di BI. È qui in cui i piani e i progetti hanno assicurato che fosse
costruita una qualsiasi struttura fisica, le tecnologie selezionate e le
tecniche realizzate fatte con un occhio verso l’impresa. È la
pianificazione a lunga scadenza che fornisce la coesione
necessaria per assicurare che i vantaggi di impresa derivino da tutti
i guadagni a breve scadenza trovati.
Giustificare il vostro sforzo di BI
Un data warehouse da solo non ha nessun valore inerente. In altre
parole, non c’è nessun valore inerente tra le tecnologie di
warehouse e le tecniche implementative.
Il valore di qualsiasi sforzo di warehouse è trovato nelle azioni
eseguite a seguito dell’ambiente di warehouse e del contenuto
informativo coltivato nel tempo. Questo è un punto critico da capire
prima che tentiate mai di stimare il valore di qualsiasi iniziativa di
wherehouse.
Troppo spesso, architetti e progettisti tentano di applicare valore ai
componenti fisici e tecnici di warehouse quando infatti il valore si
fonda con i processi commerciali che sono incisi positivamente dal
warehouse e dalle informazioni bene acquisite.
Qui giace la sfida per fondare la BI: Come giustifichi l’investimento?
Se la stessa wherehouse non ha un valore intrinseco, i progettisti di
progetto devono indagare, definire e formalizzare i vantaggi
conseguiti da quegli individui che utilizzeranno il warehouse per
migliorare processi commerciali specifici o il valore delle
informazioni protette o entrambi.
Per complicare argomenti, qualsiasi processo commerciale
interessato da sforzi di magazzino potrebbe fornire vantaggi
“considerevoli” o “lievi”. I vantaggi considerevoli forniscono una
metrica tangibile per misurare il ritorno dell’investimento (ROI) – ad
esempio, girare l’inventario un tempo aggiuntivo durante un periodo
specifico o per costo minore di trasporto per spedizione. È più
difficile definire i lievi vantaggi, come l’ accesso migliorato alle
informazioni , in termini di valore tangibile.
Collegare il vostro progetto per conoscere le
richieste di Business
Troppo spesso, i progettisti di progetto tentano di collegare il valore
della warehouse con obiettivi amorfi dell’impresa. Dichiarando che
“il valore dei una warehouse è basato sulla nostra capacità di
soddisfare richieste strategiche” apriamo in modo gradevole il
discorso. Ma da solo non è sufficiente per determinare se
l’investimento nel magazzino ha senso. È miglio collegare ripetizioni
di warehouse con richieste commerciali specifiche e note.
Misurare il ROI
Calcolare ROI in un’impostazione di warehouse può essere
particolarmente difficile. È particolarmente difficile se il vantaggio
principale di una particolare ripetizione è qualcosa di non tangibile o
facile da misurare. Uno studio ha trovato che gli utenti percepiscono
i due principali vantaggi delle iniziative della BI:
▪ Creare l’abilità per creare decisioni
▪ Creare l’acceso alle informazioni
Questi vantaggi sono vantaggi morbidi (o lievi). È facile vedere
come possiamo calcolare un ROI basato su un vantaggio duro (o
maggiore) tipo la riduzione del costo del trasporto, ma come
misuriamo la capacità di prendere decisioni migliori?
Questa è sicuramente una sfida per progettisti di progetto quando
stanno tentando di convincere la società a investire in un particolare
sforzo di warehouse. Le vendite crescenti o i costi che diminuiscono
non sono più i temi centrali che guidano l’ambiente BI.
Invece, state cercando nelle richieste di business un accesso
migliore alle informazioni in modo che un particolare reparto possa
prendere decisioni più veloci. Questi sono conducenti strategici a
cui capita di essere ugualmente importante per l’impresa ma sono
più ambigui e più difficili da caratterizzare in una metrica tangibile.
In questo caso, calcolare ROI può ingannare, se non irrilevante.
I progettisti di progetto devono essere in grado di dimostrare valore
tangibile perché i dirigenti possano decidere se l’investimento in
una particolare ripetizione vale. Tuttavia, non proporremo un nuovo
metodo per il calcolo di ROI, né faremo qualche argomento pro o
contro esso.
Sono disponibili molti articoli e libri che discutono i fondamenti per
calcolare ROI. Ci sono delle special value propositions come valore
sull’investimento (VOI), offerto da gruppi come Gartner, che potete
ricercare. Invece, ci concentreremo su aspetti di nucleo di qualsiasi
ROI o altre proposizioni di valore che dovete considerare.
Applicando ROI
Oltre all’argomento sui benefici “duri” contro i benefici “leggeri”
associati agli sforzi di BI là ci sono altri problemi da considerare
quando applichiamo ROI. Per esempio:
Attribuire troppi risparmi agli sforzi del DW che verrebbero
comunque
Diciamo che la vostra società passava da un’architettura di
mainframe a un ambiente distribuito UNIX. Quindi qualsiasi
risparmio che può (o non può) essere realizzato da quello sforzo
non dovrebbe essere attribuito esclusivamente, se a tutto (?), al
warehouse.
Non rendere conto di tutto costa. E ce ne sono molte di cose da
tener conto. Considerate la seguente lista:
▪ Costo dell’avvio, tra cui la fattibilità.
▪ Costo di hardware dedicato con relativo storage e
comunicazioni
▪ Costo del software, tra cui gestione dei dati ed estensioni
client/server, software ETL, tecnologie DSS, strumenti di
visualizzazione, applicazioni di programmazione e di flusso di
lavoro e software di monitoraggio, .
▪ Costo di progettazione di struttura dati, con la realizzazione, e
l’ottimizzazione di
▪ Costo di sviluppo software direttamente associato allo sforzo
BI
▪ Costo di supporto a domicilio, compreso ottimizzazione di
prestazioni, compreso controllo di versione software e
operazioni di help
Applicare “Big-Bang” ROI.
La realizzazione della warehouse come sforzo singolo e gigantesco
è destinato a non riuscire, così anche calcola il ROI per un’iniziativa
di larga impresa L’offerta è sorprendere, e che i progettisti
continuino a fare tentativi deboli per stimare il valore dell’intero
sforzo.
Perché i progettisti cercano di dare un valore monetario
sull’iniziativa di impresa se è ampiamente saputo e accettato che
stimare ripetizioni specifiche è difficile? Come è possibile? Non è
possibile con poche eccezzioni. Non fatelo.
Ora che abbiamo stabilito che cosa non fare quando calcoliamo
ROI, ci sono qui alcuni punti che ci aiuteranno nella definizione di
un processo affidabile per stimare il valore dei vostri sforzi BI.
Ottenimento del consenso di ROI. Indipendentemente dalla vostra
scelta di tecnica per stimare il valore dei vostri sforzi BI, deve
essere concordata da tutte le parti, incluso i progettisti di progetto,
gli sponsor e i dirigenti aziendali.
Riducete ROI in parti identificabili. Un passo necessario verso in
ragionevole calcolo di un ROI è concentrare quel calcolo su un
progetto specifico. Questo quindi vi permette di stimare un valore
basato su requisiti commerciali specifici che vengono soddisfatti
Definite i costi. Come citati, numerosi costi devono essere
considerati. Inoltre, i costi devono includere non solo quelli associati
alla singola iterazione ma anche ai costi di associati
all’assicurazione di conformità agli standard di impresa..
Definite vantaggi. Collegando chiaramente il ROI a requisiti
commerciali specifici, dovremmo essere in grado di identificare i
vantaggi che porteranno a soddisfare i requisiti.
Riducete i costi e i vantaggi in guadagni imminenti. È il modo
migliore per basare le vostre valutazioni sul valore attuale netto
(NPV) diversamente dal tentativo di predire valore futuro in
guadagni futuri.
Tenete al minimo la tempistica di suddivisione del vostro ROI. E’
ben documentato nel lungo periodo in cui è stato usato nel vostro
ROI.
Utilizzate più di una formula ROI. Ci sono numerosi metodi per la
previsione del ROI e voi dovreste pianificare se utilizzarne uno o
più, compreso il valore attuale netto, la velocità interna del ritorno
(IRR) e il recupero.
Definire il processo ripetibile. Questo è determinante per calcolare
ogni valore a lunga scadenza. Dovrebbe essere documentato un
singolo processo ripetibile per tutte le sottosequenze di progetto a
seguire.
I problemi elencati sono quelli più comuni definiti da esperti
dell’ambiente di werehouse. L’insistenza da parte della gestione di
far fornire un “Big-Bang” ROI disorienta parecchio. Se avviate tutti i
vostri calcoli ROI riducendoli in parti identificabili e tangibili, avete
una buona possibilità stimare una valutazione precisa ROI.
Domande riguardo ai benefici del ROI
Qualunque sono i vostri benefici, morbidi o duri, voi potete utilizzare
alcune domande fondamentali per determinare il loro valore. Ad
esempio utilizzando un sistema di scala semplice, da 1 a 10, voi
potete rilevare l’impatto di qualsiasi sforzo utilizzando le seguenti
domande:
▪ Come valutereste la comprensione dei dati a seguito di questo
progetto della vostra società?
▪ Come stimereste i miglioramenti di processo a seguito di
questo progetto?
▪ Come misurereste l’impatto di nuove intuizioni e inferenze ora
rese disponibili da questa iterazione
▪ Quale è stato l’impatto di ambienti di computer nuovi e
performanti a seguito di quello che si era imparato?
Se le risposte a queste domande sono poche, è possibile che
l’impresa non valga l’investimento fatto. Le domande con un alto
punteggio puntano a guadagni di valore significativi e dovrebbero
servire come guide per ulteriore indagine.
Ad esempio, un alto punteggio per miglioramenti di processo
dovrebbe portare i progettisti a esaminare come i processi sono
stati migliorati. Potete trovare che alcuni o tutti i guadagni ottenuti
sono tangibili e quindi un valore monetario può essere prontamente
applicato.
Ottenere il massimo dalla prima iterazione del
warehouse
Il risultato più grande del vostro sforzo di impresa è spesso nelle
prime poche iterazioni. Questi primi sforzi tradizionalmente
stabiliscono il più utile contenuto informativo per il pubblico e
stabilisce l’aiuto alla fondazione di tecnologia per le successive
applicazioni della BI.
Di solito ogni successiva sottosequenza di dati di progetto di
warehouse portano sempre meno valore aggiuntivo all’impresa in
generale. Questo è particolarmente vero se l’iterazione non
aggiunge nuovi argomenti o non soddisfa le necessità di una nuova
comunità di utenti.
Questa caratteristica di immagazzinare si applica anche alle pile
crescenti di dati storici. Come gli sforzi successivi richiedono più
dati e come più dati sono versati nel warehouse nel tempo, il più dei
dati diventa meno attinente all’analisi utilizzata. Questi dati sono
spesso chiamati dati assopiti ed è sempre costoso tenerli perché
non vengono quasi mai utilizzati.
Cosa significa questo per gli sponsor di progetto? Essenzialmente, i
primi sponsor condividono di più di quanto costa l’investimento.
Questo è primario perché essi sono l’impeto per fondare lo strato di
largo ambiente tecnologico e delle risorse del warehouse,
compreso organico.
Ma questi primi passi portano il valore più alto e quindi i progettisti
di progetto devono spesso giustificare l’investimento.
I progetti fatti dopo la vostra iniziativa BI possono avere costi
inferiori ( comparati con la prima) e diretti, ma portano meno valore
all’impresa.
E proprietari dell’organizzazione devono iniziare a considerare
buttare l’accumulo di dati e di tecnologie meno rilevanti.
Data Mining : Estrazione Dati
Numerosi componenti architettonici richiedono variazioni di
tecnologie e tecniche di data mining—
per esempio, i diversi “agenti” per l’esame dei punti di interesse del
clienti, i sistemi operativi dell’azienda e per lo stesso dw. Questi
agenti possono essere reti neurali avanzate addestrate alle
tendenze del POT, quale la richiesta futura del prodotto basata sulle
promozioni di vendite; motori basati sulle regole (rules-based) per
reagire a un insieme dato di circostanze, ad esempio, diagnosi
medica e raccomandazioni di trattamento; o persino agenti semplici
col ruolo di riportare le eccezioni ai dirigenti superiori (top
executives). Generalmente questi processi di estrazione dati si
verificano in tempo reale; quindi, essi devono essere uniti
completamente con il movimento dei dati stessi.
Online Analytic Processing Elaborazione
Analitica Online
La capacità di affettare, spezzettare, arrotolare, trapanare giù (drilldown)
ed effettuare l’analisi
cosa-se, è all’interno dell’ambito, dell’obiettivo della suite
tecnologica IBM. Ad esempio, le funzioni di trattamento analitico
online (OLAP) esistono per DB2 che porta l’analisi dimensionale nel
motore del database stesso .
Le funzioni aggiungono l’utilità dimensionale a SQL mentre
sfruttano tutti i benefici di essere una parte naturale di DB2. Un altro
esempio di integrazione di OLAP è lo strumento di estrazione, DB2
OLAP Analizzatore Server. Questa tecnologia permette ai cubi del
Server DB2 OLAP di essere rapidamente e automaticamente
analizzati per individuare e riferire su valori dei dati insoliti o inattesi
per tutto il cubo all’analista commerciale. E, infine, le funzioni del
Centro di DW forniscono mezzi perché architetti controllino, tra le
altre cose, il profilo di un cubo server DB2 OLAP come una parte
naturale dei processi ETL.
Spatial Analysis Analisi Spaziale
Lo spazio rappresenta la metà delle ancore (conduzioni) analitiche
necessarie per un panorama
analitico largo (il tempo rappresenta l’altra metà). Il livello atomico
(atomic-level ) del magazzino, rappresentato nella Figura 1.1,
include i fondamenti sia per tempo che per spazio. Le registrazioni
dell’ora ancorano analisi per tempo e informazioni di indirizzo
ancorano analisi da spazio. Le marcatura orarie (Timestamps)
conducono l’analisi per tempo, e l’informazione di indirizzo conduce
l’analisi per spazio. Il diagramma mostra geocoding–processo di
conversione indirizzi a punti in una mappa o punti nello spazio
cosicché i concetti come distanza e interno/esterno possano essere
utilizzati nell’analisi–condotto a livello atomico e l’analisi spaziale
che è messa a disposizione dell’analista. IBM fornisce estensioni
spaziali, sviluppati con l’Istituto Ricerca Sistema Ambientale (ESRI),
al database DB2 in modo che gli oggetti spaziali possano essere
conservati come una parte normale del database relazionale. DB2
Spatial Extenders, forniscono anche tutte le estensioni SQL per
sfruttare l’analisi spaziale. Ad esempio, le estensioni SQL da
interrogare sulla
distanza fra indirizzi o se un punto è interno o esterno ad un’area
poligonale definita, sono uno standard analitico con il Spatial
Extender. Consultate il capitolo 16 per ulteriori informazioni.
Database-Resident Tools Strumenti Database-
Resident
DB2 ha molte caratteristiche SQL BI-resident che assistono
nell’azione di analisi. Questi includono:
▪ Le funzioni di ricorsione per eseguire analisi, come “trovare
tutti i possibili percorsi di volo da San Francisco a New York”.
▪ Le funzioni analitiche per il ranking, funzioni cumulative, cubo
e rollup per agevolare i compiti che normalmente si verificano
solo con la tecnologia OLAP, sono ora una parte naturale del
motore del database
▪ La capacità di creare tabelle che contengano risultati
I venditori di database leader mischiano di più delle funzionalità BI
nel database stesso.
I fornitori principali della base di dati stanno mescolando più delle
funzionalità della BI nel database stesso.
Ciò fornisce le prestazioni migliori e più opzioni di esecuzione per le
soluzioni della BI.
Le caratteristiche e le funzioni di DB2 V8 sono discusse
dettagliatamente nei seguenti capitoli:
Technical Architecture and Data Management Foundations
(Chapter 5)
▪ DB2 Fondamenti della BI (BI Fundamentals) (Chapter 6)
▪ DB2 Tabelle di query materializzate (Materialized Query
Tables) (Chapter 7)
▪ DB2 Funzioni OLAP (OLAP Functions) (Chapter 13)
▪ DB2 Caratteristiche e funzioni potenziate di BI (Enhanced BI
Features and Functions) (Chapter 15)
Simplified Data Delivery System
Sistema di consegna di dati semplificato
L’architettura rappresentata nella figura 1.1 include numerose
strutture dati fisiche. Uno è il magazzino di dati operativo.
Generalmente, un ODS è un oggetto orientato (subject oriented),
integrato e corrente. Costruireste un ODS per sostenere, ad
esempio, l’ufficio vendite. Le vendite ODS integrerebbero dati
provenienti da numerosi sistemi diversi ma manterrebbe solo, ad
esempio, le transazioni di oggi. L’ODS può essere aggiornato
anche molte volte al giorno. Contemporaneamente, i processi
spingono i dati integrati in altre applicazioni. Questa struttura è
progettata specificatamente per integrare dati correnti e dinamici e
sarebbe un candidato probabile a sostenere analisi in tempo reale,
come fornire ad agenti di servizio clienti le informazioni di vendite
correnti di un cliente estraendo informazioni di tendenza di vendite
dal magazzino stesso. Un’altra struttura mostrata nella figura 1.1 è
uno stato formale per il dw. Non solo questo è il luogo per
l’esecuzione della necessaria integrazione, della qualità di dati, e
della trasformazione dei dati di magazzino in arrivo, ma è anche
un’area di deposito affidabile e provvisoria per dati replicati che
potrebbero essere utilizzati in analisi in tempo reale. Se decidete di
utilizzare un ODS o una zona di organizzazione (staging area), uno
dei migliori strumenti per popolare queste strutture dati utilizzando
diverse sorgenti operative è la query distribuita eterogenea di DB2.
Questa capacità è consegnata dalla caratteristica opzionale di DB2
chiamata DB2 Relational Connect (solo query) e attraverso DB2
DataJoiner (un prodotto separato che consegna la domanda,
l’inserto, l’aggiornamento e la possibilità di cancellazione a
RDBMSs distribuito eterogeneo).
Questa tecnologia permette ad architetti di dati di legare dati di
produzione con processi analitici. Non solo può la tecnologia
adattarsi virtualmente a una qualunque delle richieste di replica che
potrebbero presentarsi con l’analisi in tempo reale, ma esso
possono anche collegare ad un’ampia varietà delle basi di dati più
popolari, compreso DB2, Oracle, Sybase, assistente di SQL,
Informix ed altri. DB2 DataJoiner può essere utilizzato per popolare
una struttura dati formale come un ODS o anche una tabella
permanente rappresentata nel magazzino progettata per ripristino
rapido di aggiornamenti istantanei o per vendita. Naturalmente,
queste stesse strutture dati possono essere popolate utilizzando
un’altra tecnologia importante progettata per replica di dati, IBM
DataPropagator Relational. (DataPropagator è un prodotto separato
per sistemi centrali. DB2 UNIX, Linux, Windows e OS/2 includono
servizi di replica di dati come una caratteristica standard).
Un altro metodo per lo spostamento di dati operativi intorno
all’impresa è un integratore di applicazione di impresa altrimenti
noto come message broker(mediatore del messaggio).Questa
tecnologia unica permette controllo impareggiabile per centrare
(targeting) e spostare dati intorno all’impresa. IBM ha il mediatore
del messaggio più ampiamente usato, MQSeries, o una variazione
del prodotto che comprende i requisiti di e-commerce, IBM
WebSphere MQ.
Per più discussione su come sfruttare MQ per sostenere un
magazzino e un ambiente BI, visitare sito Web del libro. Per ora, è
sufficiente dire che questa tecnologia è un mezzo eccellente per
catturare e trasformare (utilizzando MQSeries Integrator) dati
operativi centrati (targeted) reclutati per soluzioni della BI. La
tecnologia MQ è stata integrata e impacchettata in UDB V8, il che
significa che le code dei messaggi possono ora essere gestite
come se esse fossero tabelle DB2. Il concetto di saldatura dei
messaggi in coda e dell’universo di database relazionale si dirige
verso un ambiente potente di consegna di dati.
Zero-Latency Latenza nulla
L’obiettivo strategico finale per IBM è analisi di latenza nulla (zerolatency).
Come definito da
Gartner, un sistema BI deve essere in grado di dedurre, assimilare
e fornire informazioni per analisti su richiesta. La sfida,
naturalmente, sta nel come mescolare dati correnti e in tempo reale
con informazioni storiche necessarie, quali i dati relativi modello/di
tendenza, o la comprensione estratta, come delineamento del
cliente.
Tali informazioni includono, ad esempio, l’identificazione di clienti ad
alto o basso rischio o quali prodotti i clienti acquisteranno molto
probabilmente se essi hanno già del formaggio nei loro carrelli di
acquisti.
Ottenere latenza nulla è effettivamente dipendente da due
meccanismi fondamentali:
▪ Unione completa dei dati che vengono analizzati con le
tecniche stabilite e con gli strumenti realizzati dalla BI
▪ Un sistema di consegna di dati efficiente per assicurare che
l’analisi in tempo reale sia realmente disponibile
Questi prerequisiti per latenza nulla non sono differenti dai due
obiettivi stabiliti da IBM e descritti precedentemente.
L’accoppiamento stretto dei dati fa parte del programma di
integrazione senza cuciture disposto dalla IBM. E creare un sistema
di consegna di dati efficiente è completamente dipendente dalla
tecnologia disponibile che semplifica il processo di consegna di
dati. Di conseguenza, due dei tre obiettivi di IBM sono fondamentali
a realizzare il terzo. IBM sta sviluppando coscientemente la sua
tecnologia per assicurare che la latenza nulla sia una realtà per gli
sforzi del magazzino.
Summary / Sintesi
L’organizzazione della BI fornisce una mappa di strada per
realizzare il vostro ambiente
iterativamente. Deve essere regolato per riflettere le necessità dei
vostri affari, sia attuali che futuri. Senza una visione architettonica
larga, le ripetizioni di magazzino sono poco più che delle
implementazioni casuali del magazzino centrale che fanno poco per
creare un’impresa larga, informativa.
Il primo ostacolo per i responsabili di progetto è come giustificare gli
investimenti necessari per lo sviluppo dell’organizzazione della BI.
Benché il calcolo del ROI sia rimasto un sostegno principale per
realizzazioni di magazzino, esso sta diventando più difficile da
predire esattamente. Questo ha condotto ad altri metodi per la
determinazione se state ottenendo il valore del vostro denaro. Il
valore sull’ investmento2 (VOI), ad esempio, viene procacciato
come una soluzione.
È incombente sugli architetti di dati e sui pianificatori di progetto
generare e fornire deliberatamente informazioni alle associazioni di
utenti e non dare semplicemente un servizio sui dati. C’è una
differenza enorme fra i due. L’informazione è qualcosa che fa una
differenza nei processi decisionali e nell’efficacia; relativamente, i
dati sono blocchetti di costruzione per derivare quelle informazioni.
Anche se critico alla sorgente dati per indirizzare richieste
commerciali, l’ambiente BI dovrebbero servire un ruolo più grande
nella creazione di contenuto delle informazioni. Dobbiamo prendere
le misure supplementari per pulire, integrare, trasformare o
diversamente creare un contenuto di informazioni secondo cui gli
utenti possano agire, e quindi dobbiamo assicurarci che quelle
azioni e quelle decisioni, dove ragionevole, abbiano un riscontro
nell’ambiente BI. Se releghiamo il magazzino a servire solo su dati,
è assicurato che le associazioni di utenti creeranno il contenuto
delle informazioni necessarie per agire. Questo assicura che la loro
comunità sarà in grado di prendere decisioni migliori, ma l’impresa
soffre della mancanza di conoscenza che essi hanno utilizzato.
Dato che gli architetti e i pianificatori di progetto iniziano i progetti
specifici nell’ambiente BI, essi rimangono responsabili all’impresa
nell’insieme. Un esempio semplice di questa caratteristica a due
facce delle iterazioni della BI è trovato nella sorgente dati. Tutti i
dati ricevuti per richieste commerciali specifiche devono essere
popolati nel primo strato atomico. Questo garantisce lo sviluppo del
bene di informazioni aziendale, così come gestire, indirizzare le
richieste specifiche di utente definite nella iterazione.

W h a t i s a D a t a W a r e h o u s e ?
Data warehouse è il cuore dell’architettura dei sistemi informative
dal 1990 e supporta i processi informativi offrendo una solida
piattaforma integrata di dati storici presi come base per successive
analisi. I data warehouse offrono la facilità di integrazione in un
mondo di sistemi applicativi non compatibili tra loro. Data
warehouse si è evoluto fino a diventare una moda. Data warehouse
organizza e memorizza i dati necessari per processi informativi e
analitici sulla base di una lunga prospettiva storica temporale. Tutto
ciò comporta un notevole e costante impegno nella costruzione e
nel mantenimento del data warehouse.
Cos’è quindi un data warehouse? Un data warehouse è:
▪ orientato ai soggetti
▪ sistema integrato
▪ tempo variante
▪ non volatile ( non si cancella )
una collezione di dati usati in supporto a decisioni manageriali nella
realizzazione dei processi.
I dati inseriti nel data warehouse derivano nella maggior parte dei
casi da ambienti operazionali. Il data warehouse è realizzato da una
unità di memorizzazione, fisicamente separata dal resto del
sistema, che contiene dati precedentemente trasformati dalle
applicazioni che operano sulle informazioni derivanti dall’ambiente
operativo.
La definizione letterale di un data warehouse merita un’approfondita
spiegazione poichè esistono importanti motivazioni e significati di
fondo che descrivono le caratteristiche di una warehouse.
SUBJECT ORIENTATION ORIENTAMENTO
TEMATICO
La prima caratteristica di un data warehouse è che è orientato ai
maggior soggetti di un’impresa. La giuda dei processi attraverso i
dati è in contrasto con il più classico metodo che prevede
l’orientamento delle applicazioni verso i processi e le funzioni,
metodo per la maggior parte condiviso dalla maggior parte dei
meno recenti sistemi direzionali.
Il mondo operativo è progettato intorno ad applicazioni e a funzioni
quali prestiti, risparmi, bankcard e la fiducia per un’istituzione
finanziaria. Il mondo del dw è organizzato intorno a soggetti
principali quali il cliente, il venditore, il prodotto e l’attività.
L’allineamento intorno ad argomenti influisce sulla progettazione e
sulla realizzazione dei dati trovati nel dw. In modo più rilevante,
l’argomento principale influisce sulla parte più importante della
struttura chiave.
Il mondo del applicazione è influenzato sia dal disegno del data
base che dal disegno del processo (Process design). Il mondo del
dw è concentrato esclusivamente sulla modellazione dei dati e sul
disegno del database. Il disegno del processo (nella sua forma
classica) non fa parte dell’ambiente del dw.
Le differenze fra la scelta di applicazione processo/funzione e
scelta per subject si rivelano anche come differenze nel contenuto
dei dati a livello dettagliato. I dati del dw non includono i dati che
non saranno usati per il processo di DSS, mentre applicazioni
operazionali orientate ai dati contengono i dati per soddisfare
immediatamente i requisiti funzionale/elaborazione che possono o
meno avere qualsiasi uso per l’analista di DSS.
Un altro modo importante in cui applicazioni operazionali orientate
ai dati differiscono da dati di dw è nei rapporti dei dati. I dati
operativi mantengono un rapporto continuo tra due o più tabelle
basato su una regola commerciale che è attiva. I dati di dw
attraversano uno spettro di tempo e i rapporti trovati nel dw sono
molti. Molte regole commerciali ( e corrispondentemente, molti
rapporti di dati ) sono rappresentate nel magazzino di dati tra due o
più tabelle.
(Per una spiegazione dettagliata di come le relazioni tra i dati sono
gestiti nel DW, facciamo riferimento al Tech Topic su quella
questione.)
Da nessuna altra prospettiva che quella della differenza
fondamentale tra una scelta di applicazione functional/process e
una scelta subject, c’è una maggiore differenza tra i sistemi
operativi e i dati ed il DW.
INTEGRATION INTEGRAZIONE
L’aspetto più importante dell’ambiente di dw è che i dati trovati
all’interno del dw sono integrati facilmente. SEMPRE. SENZA
ECCEZIONI. L’essenza stessa dell’ambiente del dw è che i dati
contenuti nei limiti del magazzino sono integrati.
L’integrazione si rivela in molti modi differenti – nelle convenzioni
identificate consistenti, nella misura di variabili consistenti, nelle
strutture codificate consistenti, negli attributi fisici dei dati
consistenti, e così via.
Nel corso degli anni i progettisti di diverse applicazioni hanno fatto
possesso di molte decisioni su come un’applicazione dovrebbe
essere sviluppata. Lo stile e le decisioni progettuali individualizzate
delle applicazioni dei progettisti si rivelano in cento modi: nelle
differenze di codifica, struttura chiave, caratteristiche fisiche,
identificazione convenzioni, e così via. La capacità collettiva di molti
progettisti di applicazione di generare le applicazioni contradditorie
è leggendaria. La figura 3 espone alcune delle differenze più
importanti nei modi in cui le applicazioni sono progettate.
Encoding: Codificare:
I progettisti di applicazioni hanno scelto la codifica del campo –
sesso- in diversi modi. Un progettista rappresenta il sesso come
una “m” e “f”. Un altro progettista rappresenta il sesso come un “1”
e uno “0”. Un altro progettista rappresenta il sesso come una “x” e
“y”. Un altro progettista rappresenta il sesso come “maschio” e
“femmina”. Non importa molto come il sesso arriva nel DW. La “M”
e la “F” sono probabilmente buone quanto tutta la
rappresentazione.
Cosa importa è che da qualunque origine derivi il campo sesso,
quel campo arriva nel DW in uno stato integrato consistente. Di
conseguenza quando il campo è caricato nel DW da
un’applicazione dove esso è stato rappresentato fuori nel formato
“M” e “F”, i dati devono essere convertiti al formato del DW.
Measurement of Attributes: Misura degli
Attributi:
I progettisti di applicazione hanno scelto di misurare la conduttura in
una varietà di modi nel corso
degli anni. Un progettista memorizza i dati della conduttura in
centimetri. Un altro progettista di applicazione memorizza i dati
della conduttura in termini di pollici. Un altro progettista di
applicazione memorizza i dati della conduttura in milione piedi cubi
al secondo. E un altro progettista memorizza le informazioni della
conduttura in termini di iarde. Qualunque sia la fonte, quando le
informazioni della conduttura arrivano nel DW esse devono essere
misurate nello stesso modo.
Secondo le indicazioni di figura 3 le questioni di integrazione
interessano quasi ogni aspetto del progetto – le caratteristiche
fisiche dei dati, il dilemma di avere più di una fonte dei dati, la
questione di campioni identificati inconsistenti, formati dei dati
inconsistenti, e così via.
Qualunque sia l’argomento di progettazione, il risultato è lo stesso –
i dati devono essere memorizzati nel DW in una singolare e
globalmente accettabile maniera anche quando i sistemi operativi di
fondo memorizzano diversamente i dati.
Quando l’analista DSS guarda il DW, l’obbiettivo dell’analista
dovrebbe essere lo sfruttamento dei dati che sono nel magazzino,
piuttosto che sul domandarsi circa la credibilità o la consistenza dei
dati.
TIME VARIANCY
Tutti i dati nel DW sono precisi in qualche momento in tempo.
Questa caratteristica base dei dati nel DW è molto diversa dai dati
trovati nell’ambiente operativo. I dati dell’ambiente operativo sono
precisi come nel momento dell’accesso. In altre parole,
nell’ambiente operativo quando si accede ad una unità dati, ci si
attendete che rifletterà valori precisi come nel momento di accesso.
Perché i dati nel DW siano precisi come in qualche momento nel
tempo (cioè, non “proprio adesso”), si dice che i dati trovati nel DW
sono “time variancy”.
Il time variancy di dati di DW si riferisce in numerosi modi.
Il modo più semplice è che i dati di un DW rappresentano dati su un
lungo orizzonte di tempo – da cinque a dieci anni. L’orizzonte
temporale rappresentato per l’ambiente operativo è molto più breve
▪ dai valori correnti di oggi da fino a sessanta novanta
Le applicazioni che devono funzionare bene e devono essere
disponibili per l’elaborazione delle transazioni devono portare la
quantità minima di dati se esse ammettono qualsiasi grado di
flessibilità. Quindi le applicazioni operative hanno un orizzonte
temporale breve, come un argomento di progettazione di
applicazioni audio.
Il secondo modo in cui ‘time variancy’ compare nel DW è nella
struttura chiave. Ogni struttura chiave nel DW contiene,
implicitamente o esplicitamente, un elemento di tempo, come
giorno, settimana, mese, ecc. L’elemento di tempo è quasi sempre
in fondo alla chiave concatenata trovata nel DW. In queste
occasioni, l’elemento di tempo esisterà implicitamente, come il caso
dove un intero file è duplicato alla fine del mese o del quarto.
Il terzo modo in cui time variancy viene visualizzato è che i dati del
DW, appena correttamente registrati, non possono essere
aggiornati. I dati del DW sono, per tutti gli scopi pratici, una lunga
serie di snapshots(istantanea). Naturalmente se la snapshots è
stata presa non correttamente, allora le snapshots possono essere
modificate. Ma assumendo che le snapshots siano fatte
correttamente, esse non vengono modificate appena fatte. In alcuni
casi può essere immorale o anche non valido che le snapshots nel
DW siano modificate. I dati operativi, essendo precisi come nel
momento di accesso, possono essere aggiornati come si presenta
la necessità.
NON VOLATILE
La quarta importante caratteristica del DW è che è non-volatile.
Gli aggiornamenti, inserimenti, cancellazioni e modifiche, sono fatte
regolarmente per gli ambienti operazionali record per record. Ma la
manipolazione di base dei dati che occorrono nel DW è molto più
semplice. Ci sono solo due generi di operazioni che si verificano nel
DW – il caricamento iniziale dei dati e l’accesso ai dati. Non c’è
alcun aggiornamento dei dati (nel senso generale di
aggiornamento) nel DW come normale operazione di elaborazione.
Ci sono alcune conseguenze molto potenti di questa differenza di
base fra elaborazione operativa ed elaborazione del DW. Al livello
di progettazione, la necessità di essere cauti sull’aggiornamento
anomalo non è fattore nel DW, poiché l’aggiornamento di dati non è
effettuato. Questo significa che a livello fisico di progettazione,
possono essere prese delle libertà per ottimizzare l’accesso ai dati,
in particolare nell’occuparsi degli argomenti di normalizzazione e di
denormalizzazione fisica. Un’altra conseguenza della semplicità
delle operazioni di DW è nella tecnologia sottostante utilizzata per
eseguire l’ambiente di DW. Dovendo supportare aggiornamenti
record per record in linea (così come è spesso il caso con
elaborazione operativa) si richiede che la tecnologia abbia delle
fondamenta molto complesse sotto una apparente semplicità.
La tecnologia che supporta copie di riserva e recupero, transazioni
e integrità dei dati e la scoperta e il rimedio di condizione di stallo è
abbastanza complessa e non necessaria per elaborazione di DW.
Le caratteristiche di un DW, orientamento di progettazione,
integrazione di dati all’interno del DW, time variancy e la semplicità
di gestione dei dati, tutto induce ad un ambiente che è molto, molto
diverso dall’ambiente operativo classico. La sorgente di quasi tutti i
dati di DW sono l’ambiente operativo. È una tentazione pensare
che ci sia una ridondanza massiccia di dati tra i due ambienti.
Infatti la prima impressione che molte persone hanno è quella di
grande ridondanza di dati tra l’ambiente operativo e l’ambiente di
DW. Una tale interpretazione è superficiale e dimostra una
mancanza nel capire che cosa accade nel DW.
Infatti c’è un minimo di ridondanza di dati tra l’ambiente operativo
ed i dati del DW. Consideriamo quanto segue:
▪ I dati sono filtrati dato che si passa dall’ambiente operativo
all’ambiente DW. Molti dati non passano mai fuori
dall’ambiente operativo. Solo che i dati che sono necessari per
l’elaborazione DSS trovano la loro direzione nell’ambiente
▪ l’orizzonte temporale dei dati è molto diverso da un ambiente
all’altro. I dati nell’ambiente operativo sono molto freschi. I dati
nel DW sono molto più vecchi. Solo dalla prospettiva
dell’orizzonte temporale, c’è la sovrapposizione molto piccola
tra l’ambiente operativo e il DW.
▪ Il DW contiene dati di riepilogo che non si trovano mai
nell’ambiente
▪ I dati subiscono una trasformazione fondamentale dal
momento che passano al La figura 3 illustra che la maggior
parte dei dati sono significativamente modificati a condizione
di essere selezionati e spostati nel DW. Detto in altro modo, la
maggior parte dei dati viene modificata fisicamente e
radicalmente come viene spostata nel DW. Dal punto di vista
dell’integrazione non sono gli stessi dati che risiedono
nell’ambiente operativo.
Alla luce di questi fattori, la ridondanza di