fbpx

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