Management

Cultura generale: un po' di informazioni sul fantastico mondo dell'informatica

Questo articolo è l’anticipazione di quelloc he scriveremo durante questo agosto.

Niente di pesante, ma una serie di articoli per spiegare le nostre passioni, dare corpo ad alcuni tutorial, speriamo coerenti ma dateci il beneficio del dubbio, siamo ad agosto.

Questi articoli riflettono alcune ricerche collateriali relative a dei nostri progetti attuali.

Parleremo di sicurezza delle informazioni, crittografia, algoritmi per gli stessi, firma digitale, marca temporale, ingegneria del softare, gestione documentale, programmazione, metodologie di gestione.

Ci aspettiamo molti commenti, anche pesanti.

Buona lettura!!!!

Articoli Correlati

Linee guida per i siti web della pubblica amministrazione

Direttamente dal sito innovazionepa.gov.it:

Online le Linee guida per i siti web delle pubbliche amministrazioni. Il loro obiettivo è quello di suggerire criteri e strumenti utili alla razionalizzazione dei contenuti online, riducendo al tempo stesso il numero dei siti web pubblici ormai obsoleti. Tra gli obiettivi di una PA di qualità vi è infatti anche l’esigenza di fornire tramite web informazioni corrette, puntuali e sempre aggiornate nonché di erogare servizi sempre più fruibili a cittadini e imprese.

Il documento da un lato illustra i principi criteri generali per accompagnare le pubbliche amministrazioni nell’attuazione degli indirizzi contenuti nella Direttiva Brunetta n. 8 del 2009 (descrivendo gli interventi da realizzare ai fini del miglioramento della qualità del web), dall’altro definisce le modalità e i passi necessari per l’iscrizione al dominio “.gov.it” (che garantisce la natura pubblica dell’informazione e l’appartenenza di un sito a una pubblica amministrazione). Vengono altresì affrontati possibili percorsi operativi e le relative azioni che una pubblica amministrazione può intraprendere nel caso in cui gli interventi da porre in essere riguardino, ad esempio, la riduzione dei siti web e la razionalizzazione dei contenuti online. Una particolare attenzione è stata prestata nella definizione di una mappa di contenuti minimi che per legge i siti web istituzionali devono includere, di fatto semplificando il rispetto dei diversi adempimenti vigenti. Oltre a un inquadramento generale sui criteri e sugli strumenti per il trattamento dei dati e della documentazione pubblica, le Linee guida forniscono i principi generali per le pubbliche amministrazioni che vorranno confrontarsi su temi innovativi quali la customer satisfaction, le rilevazioni di qualità attraverso il benchmark tra amministrazioni, il confronto e l’interazione dei cittadini. Completano il documento una serie di approfondite appendici tecniche.

Le Linee guida per i siti web delle PA si collocano a pieno titolo nell’ambito delle iniziative di innovazione delle amministrazioni pubbliche promosse dal Ministro Renato Brunetta per realizzare un rapporto aperto e trasparente con i propri clienti e avviano, per la prima volta in Italia, un processo di “miglioramento continuo” della qualità dei siti web pubblici. Coerentemente con il dettato stessa della Direttiva Brunetta n. 8/2009, saranno aggiornate con cadenza almeno annuale e corredate da vademecum di approfondimento. In questo modo forniranno con continuità alle pubbliche amministrazioni i criteri guida sulle modalità di razionalizzazione, dismissione, gestione, sviluppo e diffusione dei loro siti web, tenendo anche conto degli avanzamenti e dei progressi tecnico-normativi in materia.

Il documento, elaborato in via preliminare da un gruppo di lavoro interno (composto da esperti del Dipartimento della Funzione Pubblica, del Dipartimento Digitalizzazione e Innovazione tecnologica, di DigitPA e di FormezPA) è stato successivamente pubblicato online nell’aprile di quest’anno per una consultazione telematica durata due mesi e che ha registrato circa 17.000 accessi alle diverse sezioni del forum di discussione. I cittadini, le pubbliche amministrazioni, le associazioni di categoria e i fornitori ICT hanno così potuto esprimere liberamente la loro opinione sui principali contenuti e temi trattati. I riscontri e le indicazioni pervenuti durante questa fase di condivisione e confronto sono stati poi utilizzati in sede di revisione del documento iniziale.

Qui le linee guida.

Articoli Correlati

Evento ISH

Un evento interessante che merita la giusta pubblicità.

Da forumhealthcare.it.

Nel comparto sanitario le piattaforme tecnologiche, le reti e le infrastrutture, i processi e i servizi sono in continua evoluzione grazie all’innovazione in grado di permeare sempre più rapidamente i modelli organizzativi. La diffusione delle tecnologie informatiche costituisce una naturale leva di trasformazione e miglioramento per la realizzazione di un modello di sanità omogeneo, di forte qualità e sostenibile sotto il profilo economico e organizzativo. All’impiego diffuso delle nuove tecnologie corrisponde però un incremento di rischi e minacce connessi alla stessa gestione telematica dei flussi di dati in un ambito complesso quale quello sanitario: l’immaterialità delle informazioni, la facilità con cui possono essere consultate, duplicate, modificate o addirittura distrutte crea situazioni in cui, nonostante le misure di protezione, si apre una serie di nuovi interrogativi etici e giuridici.

In questo contesto nasce il convegno ISH che, grazie alla costituzione di un Comitato Consultivo che vede riuniti i principali opinion leader del settore di riferimento, si propone di favorire l’incontro fra le diverse realtà che ne compongono il tessuto, instaurando quel collegamento indispensabile tra i più importanti player del mercato e gli operatori sanitari. Il focus specifico verso le tecnologie, l’informatica e l’innovazione nel mondo sanitario italiano, fa del convegno ISH un appuntamento imperdibile per chi, operando in un settore che attraversa un periodo di fortissima evoluzione e trasformazione, deve essere continuamente informato e documentato sulle nuove opportunità offerte dal mercato.

I destinatari del progetto sono: Operatori sanitari dei Sistemi Informativi, Direzione del Personale, Organizzazione, Ufficio Legale, Security Manager, Direzione Sanitaria, Aziende produttrici di hardware e software, Consulenti.

La mostra convegno si terrà in data 30 novembre 2010 all’AtaHotel di Villa Pamphili

Il comitato scientifico sarà composto da:

Piero Giovanni Caporale – Sicurezza Organizzativa e Gestionale Settore ICT – CNIPA, Isabella Corradini – Centro Themis Crime, Mauro Cosmi – Value Team S.p.A, Fabio Di Resta – Consulente legale privacy e ISO 27001 ICT Security Auditor, ricopre l’incarico di consulente legale presso multinazionali del settore ICT e bancario, Elena Ferrari – Docente del Dipartimento di Informatica e Comunicazione dell’Università dell’Insubria, Luisa Franchina – Direttore Generale del Nucleo Operativo NBCR, Dipartimento Protezione Civile, Presidenza del Consiglio dei Ministri, Pierfrancesco Ghedini – Direttore Dipartimento Tecnologie dell’Informazione e Biomediche – Azienda USL di Modena – in qualità di  AISIS (Associazione Italiana Sistemi Informativi in Sanità),Andrea Lisi – Professore a contratto di Informatica Giuridica – Scuola Professioni Legali, Facoltà Giurisprudenza – Università del Salento, Presidente di ANORC (Associazione NazionaleOperatori e Responsabili della Conservazione Sostitutiva), Coordinatore del Digital&Law Department Studio Legale Lisi, Studio Associato D&L – Business&Legal Consultancy, ICT &International Trade, Executive Management SCiNT – Study&Research Centre, Giovanni Manca – Responsabile Sicurezza DigitPA (ex CNIPA), Baldo Meo – Responsabile Comunicazione  Garante per la protezione dei dati personali, Elio Molteni – Presidente AIPSI, ISSA Italian Chapter, Alessandro Musumeci – Direttore Centrale Sistemi Informativi (DCSI), Ferrovie dello Stato, Massimo F. Penco – Presidente Associazione Cittadini di Internet, Membro del Antiphishing Working Group, Vice presidente Gruppo Comodo, Andrea Rigoni – Senior Advisor presso Booz & Company, Giuseppe Russo – Chief Technology Officer, Sun Microsystems Italia, Roberto Setola – Docente e Direttore del Laboratorio Sistemi Complessi e Sicurezza – Università CAMPUS Bio-Medico di Roma, Domenico Vulpiani – Dirigente Generale Polizia di Stato – Consigliere Ministeriale.

Articoli Correlati

Disponibili online le FAQ relative al bando Hi-Tech RIDITT

Il Ministero dello Sviluppo Economico, in collaborazione con l’Istrituto per la Promozione Industriale, ha reso diponibile on-line una lista di domande frequenti relative al bando RIDITT che mette a disposizione 12,5 milioni di euro per promuovere progetti di trasferimento tecnologico e creazione di imprese hi-tech

Articoli Correlati

Un sistema di gestione di gruppi di lavoro: e-groupware

Nella nostra filosofia di utilizzo di sistemi open source per il lavoro quotidiano nella nostra azienda, da qualche anno utilizziamo, e proponiamo ai nostri clienti, una applicazione estremamente flessibile per la gestione di gruppi di lavoro multi utente web based: e-groupware.

La raffinata gestione degli utenti e/o dei gruppi lo rende particolarmente adatto all’utilizzo in intranet aziendali, soprattutto quando si sviluppano e si monitorizzano progetti condivisi.

La sua struttura modulare è composta da:

  1. agenda condivisa tra gli utenti con un raffinato sistema di permessi e di esportazione dei dati in modalità standard verso altri dispositivi;
  2. una rubrica condivisa e/o personale con tutti i campi necessari gia’ predisposti ma a cui si possono aggiungere campi personalizzati;
  3. un document management integrato in cui si possono indicizzare tutti i documenti di una azienda, con una semplice gestione del versioning (noi abbiamo qualcosa come un 20.000 documenti all’interno e tutto funziona molto bene)
  4. un file manager per ogni singolo utente del sistema;
  5. la possibilità di gestire tutte le attività di un singolo e/o di un gruppo quali: cose da fare, e-mail, note, chiamate telefonica, con una raffinata gestione dell’avanzamento del lavoro stesso;
  6. un modulo per la gestione dei progetti a cui si possono allegare attività, documenti, fogli ore;
  7. un modulo per gestire correttamente le risorse di una azienda quali le sale riunioni, macchine particolari, strumenti condivisi;
  8. Un modulo relativo al foglio ore in cui indicare quanto tempo si è utilizzato per un progetto, per una attività, per un cliente;
  9. per chi si occupa di software un buon bug tracking;
  10. un modulo per la creazione di un proprio portale intranet per la condivisione del lavoro aziendale;
  11. un modulo per la gestione delle proprie mail;
  12. un modulo wiki, abbastanza semplice ma completo;
  13. un modulo per la gestione di una semplice bacheca elettronica (poco utilizzato, noi troviamo più utile il modulo wiki)
  14. un bel modulo per la gestione della conoscenza aziendale;
  15. molto altro ancora in quanto è possibile creare proprie applicazioni e moduli grazie alle API messe a disposizione dal sistema

Che dire, associato alla semplicità dell’installazione su qualsiasi piattaforma (Mac, Linux, Windows) e alla fruizione dei contenuti tramite un semplice browser (Internet Explorer, Mozilla Firefox, Opera, Safari e tanti altri) lo rendono un prodotto che tutte le aziende dovrebbero avere.

Articoli Correlati

Amministratori di sistema: scadenza vicina. Una piccola guida.

Il 15 dicembre si sta avvicinando e con esso la scadenza per applicare in azienda il provvedimento del Garante della Privacy del 27 novembre 2008 come modificato dal provvedimento del 25 giugno 2009.

A seguito di un convegno a cui abbiamo assistito oggi, riporto quali sono gli adempimenti da fare in azienda. Tengo a precisare che tali discussioni sono ovviamente frutto di interpretazioni e che quindi vanno applicate coscientemente presso la propria azienda magari sentendo il proprio consulente o le proprie associazioni di categoria. Non ci rendiamo responsabili per applicazioni reali in azienda.

Il provvedimentro del Garante della Privacy del 25 giugno 2009 ha portato con se sostanzialmente due notizie degne di nota: Semplificazioni e proroga dell’individuazione del o degli amministratori di sistema e le attività connesse da mettere in essere.

Questi due provvedimenti hanno individuato, oltre ai ruoli di titolare, responsabile ed incaricato, anche il ruolo di Amministratore di sistema.

Cosa si intende per amministratore di sistema? Non solo il classico personaggio “smanettone” che gestisce i server ma in senso più lato anche:

  • Amministratore di server
  • Amministratore di Database
  • Amministratore di rete
  • Amministratore di sistema
  • Amministratore di software complessi
  • …..

L’individuazione del o degli amministratori di sistema deve essere fisica, cioè una persona, non una persona giuridica. Ne devono essere valutate le caratteristiche e le capacità e tali valutazioni devono essere documentate.

La designazione deve essere scritta e su base individuale.

Entro il 15 dicembre 2009 deve essere redatto un registro degli Amministratori di sistema (AS nel seguito) in cui sono contenuti gli estremi identificativi, le funzioni attribuite a ciascun AS. Nel caso di Outsourcing, tale elenco deve essere tenuto dall’Outsourcer (ma lo vedremo meglio più avanti). Questo registro deve esserci. Il posto migliore dove inserirlo è ovviamente il DPS ma l’azienda puo’ fare quello che vuole.

Nel caso in cui alcuni AS trattino dati dei lavoratori (o possano venirne a conoscenza), i lavoratori stessi devono essere informati (in vario modo, lettera scritta, pubblicazione su intranet, su lavagna, etc) dei nominativi. Quali sono i dati dei lavoratori? sicuramente quelli amministrativi ma anche dati di navigazione in internet, log delle mail, degli accessi. Praticamente questo sottoinsieme degli AS è praticamente identico all’insieme degli AS nella sua interezza.

Una volta all’anno l’azienda deve verificare l’attività degli AS e mantenere traccia di questa valutazione (documenti). Gli AS valutati devono essere sia quelli interni che quelli esterni.

Veniamo ad un altro obbligo che ha gettato molto scompiglio: la registrazione degli accessi (solo log in e log out) degli amministratori di sistema ai vari sistemi. E’ obbligatorio. Tali log vanno tenuti almeno sei mesi su un supporto non riscrivibile (CD o DVD non riscrivibile ad esempio). Non è proibito tenere i log di tutte le attività. E’ a discrezione dell’azienda .

Vediamo quindi in pratica cosa bisogna fare in due situazioni:

  1. AS interni;
  2. AS esterni.

Caso n.1, AS interni.

Nomina dell’AS, con raccolta della documentazione comprovante la competenza, ad es. curriculum e/o corsi di formazione; la nomina deve avere anche il profilo di autorizzazione e quali sono i trattamenti consentiti. Deve essere anche definita la Job descriprion, come meglio descritto nelle faq del garante, numero 7 e 8 che riportiamo in dettaglio:

  • Cosa si intende per descrizione analitica degli ambiti di operatività consentiti all’ADS? [Rif. comma 2, lettera  d]. Il provvedimento prevede che all’atto della designazione di un amministratore di sistema, venga fatta “elencazione analitica” degli ambiti di operatività consentiti in base al profilo di autorizzazione assegnato, ovvero la descrizione puntuale degli stessi, evitando l’attribuzione di ambiti insufficientemente definiti, analogamente a quanto previsto al comma 4 dell’art. 29 del Codice riguardante i responsabili del trattamento.
  • Oltre alla job description si deve andare più in dettaglio? Si devono indicare i singoli sistemi e le singole operazioni affidate?
    No, è sufficiente specificare l’ambito di operatività in termini più generali, per settori o per aree applicative, senza obbligo di specificarlo rispetto a singoli sistemi, a meno che non sia ritenuto necessario in casi specifici.

La  nomina deve essere individuale, fisica, deve essere conservata la ricevuta di nomina.

Deve essere comunicato ai dipendenti quale AS tratta i loro dati.

Bisogna registrare gli accessi degli AS (Log in e log out) ai vari sistemi (questi sono gli standard minimi). Attenzione ai riferimenti orari (c’e’ quindi la necessità di avere dei time server affidabili). Tali dati poi vanno periodicamente scritti su un supporto non riscrivibile e mantenuti per almeno 6 mesi.

Qui ci vengono in aiuto le faq 9, 10, 11, 12, 13, 14:

  • Cosa si intende per access log (log-in, log-out, tentativi falliti di accesso, altro?…) [Rif. comma 2, lettera f] Per access log si intende la registrazione degli eventi generati dal sistema di autenticazione informatica all’atto dell’accesso o tentativo di accesso da parte di un amministratore di sistema o all’atto della sua disconnessione nell’ambito di collegamenti interattivi a sistemi di elaborazione o a sistemi software. Gli event records generati dai sistemi di autenticazione contengono usualmente i riferimenti allo “username” utilizzato, alla data e all’ora dell’evento (timestamp), una descrizione dell’evento (sistema di elaborazione o software utilizzato, se si tratti di un evento di log-in, di log-out, o di una condizione di errore, quale linea di comunicazione o dispositivo terminale sia stato utilizzato…).
  • Laddove il file di log contenga informazioni più ampie, va preso tutto il log o solo la riga relativa all’access log? [Rif. comma 2, lettera f]
    Qualora il sistema di log adottato generi una raccolta dati più ampia, comunque non in contrasto con le disposizioni del Codice  e con i principi della protezione dei dati personali, il requisito del provvedimento è certamente soddisfatto. Comunque è sempre possibile effettuare un’estrazione o un filtraggio dei logfiles al fine di selezionare i soli dati pertinenti agli AdS.
  • Come va interpretata la caratteristica di completezza del log? Si intende che ci devono essere tutte le righe? L’adeguatezza rispetto allo scopo della verifica deve prevedere un’analisi dei rischi?
    La caratteristica di completezza è riferita all’insieme degli eventi censiti nel sistema di log, che deve comprendere tutti gli eventi di accesso interattivo che interessino gli amministratori di sistema su tutti i sistemi di elaborazione con cui vengono trattati, anche indirettamente, dati personali. L’analisi dei rischi aiuta a valutare l’adeguatezza delle misure di sicurezza in genere, e anche delle misure tecniche per garantire attendibilità ai log qui richiesti.
  • Come va interpretata la caratteristica di inalterabilità dei log? Caratteristiche di mantenimento dell’integrità dei dati raccolti dai sistemi di log sono in genere disponibili nei più diffusi sistemi operativi, o possono esservi agevolmente integrate con apposito software. Il requisito può essere ragionevolmente soddisfatto con la strumentazione software in dotazione, nei casi più semplici, e con l’eventuale esportazione periodica dei dati di log su supporti di memorizzazione non riscrivibili. In casi più complessi i titolari potranno ritenere di adottare sistemi più sofisticati, quali i log server centralizzati e “certificati”. E’ ben noto che il problema dell’attendibilità dei dati di audit, in genere, riguarda in primo luogo la effettiva generazione degli auditable events e, successivamente, la loro corretta registrazione e manutenzione. Tuttavia il provvedimento del Garante non affronta questi aspetti, prevedendo soltanto, come forma minima di documentazione dell’uso di un sistema informativo, la generazione del log degli “accessi” (login) e la loro archiviazione per almeno sei mesi in condizioni di ragionevole sicurezza e con strumenti adatti, in base al contesto in cui avviene il trattamento, senza alcuna pretesa di instaurare in modo generalizzato, e solo con le prescrizioni del provvedimento, un regime rigoroso di registrazione degli usage data dei sistemi informativi.
  • Si individuano livelli di robustezza specifici per la garanzia della integrità?
    No. La valutazione è lasciata al titolare, in base al contesto operativo (cfr. faq n. 14).
  • Quali potrebbero essere gli scopi di verifica rispetto ai quali valutare l’adeguatezza?
    Quelli descritti al paragrafo 4.4 del provvedimento e ribaditi al punto 2, lettera e), del dispositivo. L’adeguatezza è da valutare in rapporto alle condizioni organizzative e operative dell’organizzazione.

Ogni organizzazione è poi libera di decidere il suo livello di sicurezza, quindi si possono anche conservare i log di tutti, ma bisogna essere in grado di filtrare quelli degli AS.

Si devono quindi mettere in pratica delle verifiche periodiche sull’attività dell’AS e conservarne gli atti (vanno bene anche delle check list di controllo). Le verifiche devono essere almeno annuali.

Caso 2. AS Esterni.

In questo caso i compiti delegabili sono:

  • Nomina e conservazione del registro  degli AS
  • Verifica periodica delle attività degli AS

Non è delegabile invece la divulgazione degli AS che trattano dati del personale. La lista verrà data dagli Outsourcers.

Le modalità di delega:

  • Compiti delegati assegnati tramite lettera di incarico
  • Le lettere d’incarico devono essere sottoscritte per accettazione.

Ovviamente la funzione delegata deve gia’ essere stata incaricata al trattamento.

Ed ovviamente i casi possono essere diversi e vanno studiati volta per volta (Outsourcing completo, parziale, occasionale).

Quindi: prima del 15 dicembre è d’obbligo scrivere alle società che fanno trattamenti in Outsourcing o gestiscono in Outsourcing i sistemi.

E fino a qui gia’ i mal di testa sono notevoli. Ma si puo’ andare oltre, soprattutto in due casi ulteriori:

  1. Contratto di Outsourcing di società estera a cliente italiano;
  2. Contratto di Outsourcing di società italiana a cliente estero.

Nel primo caso: intra o extra UE? Che clausole di privacy utilizzare? Una cosa è certa: la società italiana è la titolare dei dati e quindi obbligo di nomina.

Nel secondo caso, la società italiana non è titolare ma deve comunque nominare il responsabile dei dati e comunque non si applica il provvedimento.

Penso sia tutto. Per il momento

Articoli Correlati

Data warehouse: questo (mis)conosciuto. Un progetto in ambito sanitario

Un nostro cliente ci ha commissionato (implicitamente) un data warehouse in ambito sanitario.

In questa serie di articoli vedemo cosa è, quali sono gli strumenti, qual’è la teoria.

Partiamo dalla definizione di data warehouse.

Un Data warehouse (o DW) (termine inglese traducibile con magazzino di dati), è un archivio informatico contenente i dati di un’organizzazione. I DW sono progettati per consentire di produrre facilmente relazioni ed analisi.

Vengono considerati componenti essenziali di un sistema Data warehouse anche gli strumenti per localizzare i dati, per estrarli, trasformarli e caricarli, come pure gli strumenti per gestire un dizionario dei dati. Le definizioni di DW considerano solitamente questo contesto ampio.

Una definizione ampliata comprende inoltre gli strumenti per gestire e recuperare i metadati e gli strumenti di business intelligence

Definizione

William H. Inmonn, colui che per primo ha parlato esplicitamente di data warehouse, lo definisce come una raccolta di dati integrata, orientata al soggetto, variabile nel tempo e non volatile di supporto ai processi decisionali.

L’integrazione dei dati costituisce la principale caratteristica distintiva del DW rispetto ad altri sistemi di supporto alle decisioni.

Secondo Inmon la raccolta di dati è:

  • Integrata: requisito fondamentale di un data warehouse è l’integrazione dei dati raccolti. Nel data warehouse confluiscono dati provenienti da più sistemi transazionali e da fonti esterne. L’obiettivo dell’integrazione può essere raggiunto percorrendo differenti strade: mediante l’utilizzo di metodi di codifica uniformi, mediante il perseguimento di una omogeneità semantica di tutte le variabili, mediante l’utilizzo delle stesse unità di misura;
  • Orientata al soggetto: il DW è orientato a temi aziendali specifici piuttosto che alle applicazioni o alle funzioni. In un DW i dati vengono archiviati in modo da essere facilmente letti o elaborati dagli utenti. L’obiettivo, quindi, non è più quello di minimizzare la ridondanza mediante la normalizzazione, ma quello di fornire dati organizzati in modo tale da favorire la produzione di informazioni. Si passa dalla progettazione per funzioni ad una modellazione dei dati che consenta una visione multidimensionale degli stessi;
  • Variabile nel tempo: i dati archiviati all’interno di un DW coprono un orizzonte temporale molto più esteso rispetto a quelli archiviati in un sistema operativo. Nel DW sono contenute una serie di informazioni relative alle aree di interesse che colgono la situazione relativa ad un determinato fenomeno in un determinato intervallo temporale piuttosto esteso. Ciò comporta che i dati contenuti in un DW siano aggiornati fino ad una certa data che, nella maggior parte dei casi, è antecedente a quella in cui l’utente interroga il sistema. Ciò differisce da quanto si verifica in un sistema transazionale, nel quale i dati corrispondono sempre ad una situazione aggiornata, solitamente incapace di fornire un quadro storico del fenomeno analizzato;
  • Non volatile: tale caratteristica indica la non modificabilità dei dati contenuti nel DW che consente accessi in sola lettura. Ciò comporta una semplicità di progettazione del database rispetto a quella di un’applicazione transazionale. In tale contesto non si considerano le possibili anomalie dovute agli aggiornamenti, né tanto meno si ricorre a strumenti complessi per gestire l’integrità referenziale o per bloccare record a cui possono accedere altri utenti in fase di aggiornamento.

Il data warehouse, quindi, descrive il processo di acquisizione, trasformazione e distribuzione di informazioni presenti all’interno o all’esterno delle aziende come supporto ai decision maker.

Esso si differenzia in modo sostanziale dai normali sistemi gestionali che, al contrario, hanno il compito di automatizzare le operazioni di routine.

Si può notare che la definizione di Inmon precedentemente citata sia indifferente rispetto alle caratteristiche architetturali dei sistemi transazionali e alla dislocazione fisica dei dati nei diversi database.

Se il focus viene posto sulla capacità di supportare il processo decisionale, il data warehouse può essere costruito secondo modalità differenti, che possono andare da una logica completamente accentrata a una logica completamente distribuita.

Le componenti e l’architettura

Gli elementi costitutivi dell’architettura sono:

  • I dati provenienti dai sistemi transazionali: sono quell’insieme di dati elaborati dai sistemi transazionali dell’azienda. Essi possono essere contenuti all’interno dello stesso database o provenire da diversi database o anche esterni all’azienda. Spesso l’architettura di un data warehouse prevede l’integrazione dei dati interni con quelli esterni. L’utilizzo di questi ultimi consente di arricchire il patrimonio informativo.
  • Il data movement: tale componente è responsabile dell’estrazione dei dati dai sistemi transazionali, dell’integrazione tra dati aziendali e dati esterni, del pre-processing dei dati, del controllo della consistenza dei dati, della conversione delle strutture dati, e dell’aggiornamento dei dizionari dei dati.
  • Il data warehouse: i dati estratti dagli archivi transazionali vengono memorizzati internamente al data warehouse. Nel data warehouse l’accesso ai dati è consentito in sola lettura. Tali dati hanno una dimensione storica e sono riferiti a soggetti di business. Essi possono essere memorizzati in un archivio centrale o in un data mart. Il termine data mart identifica un data warehouse di dimensioni ridotte, specializzato per una particolare area di attività. Si pensi, ad esempio, al data mart per il marketing, in cui i dati filtrati dagli archivi transazionali sono memorizzati per consentire l’analisi della clientela. All’interno della banca possono quindi esistere più data mart, aventi finalità diverse e orientati a coprire diverse aree di business. I dati contenuti nel data warehouse possono essere aggregati e indicizzati per rispondere a specifiche necessità informative.
  • I metadati: i metadatii costituiscono informazione aggiuntiva che arricchisce i dati contenuti nel data warehouse. Spesso essi vengono chiamati in gergo “data about data” indicando la provenienza, l’utilizzo, il valore o la funzione del dato. A tale proposito vengono costituiti dei veri e propri information catalog. Questi ultimi sono i file che contengono i metadati. Il catalog consente di spiegare all’utente la natura dei dati nel data warehouse, il loro significato semantico, da quali archivi essi provengono e la loro storicità.
  • L’utente finale: i dati contenuti nel data warehouse vengono presentati all’utente finale, il quale dispone di un insieme di strumenti per effettuare elaborazioni e produrre informazioni appropriate. I tool a disposizione dell’utente possono essere semplici generatori di query e report, interfacce grafiche che consentono la rappresentazione dei dati o sistemi di analisi dati più complessi.

Il data warehouse è organizzato su quattro livelli architetturali:

  1. trasformazione dei dati: è il livello che si occupa di acquisire i dati e validarli;
  2. preparazione e “stoccaggio” dati: è il livello che fornisce i dati agli utenti e alle applicazioni analitiche;
  3. interpretazione e analisi dati: è il livello, ad elevato valore aggiunto, che presiede alla trasformazione dei dati in informazioni aventi valore strategico;
  4. presentazione dati: è il livello, a basso valore aggiunto, che presiede alla presentazione finale agli utenti delle informazioni e quindi delle risposte cercate.

Nel suo complesso il data warehouse è un sistema periferico, cioè non risiede fisicamente sul sistema informativo centrale. Il motivo di ciò va ricercato nel tipo di attività svolto: una piattaforma di tipo transazionale è maggiormente orientata all’esecuzione costante di operazioni di aggiornamento, per cui l’ottimizzazione viene fatta soprattutto sull‘I/O; una piattaforma di supporto alle decisioni invece deve essere ottimizzata per effettuare un numero limitato di query particolarmente complesse. Un’eccezione a tale regola può essere rappresentata da soluzioni di tipo mainframe, ove la possibilità di definire macchine virtuali all’interno della stessa macchina fisica consente la coesistenza sullo stesso server fisico delle applicazioni transazionali e delle applicazioni di decision support.

Vediamo ora nei dettagli come è fatta un’architettura per il data warehouse.

Data transformation layer.

L’architettura parte dallo strato denominato data transformation, cioè dall’insieme di applicazioni che svolgono l’attività di estrazione, trasformazione e caricamento dei dati dai sistemi transazionali che alimentano il data warehouse.

Nella maggior parte dei casi la fase di estrazione dei dati dai sistemi alimentanti viene implementata utilizzando i linguaggi proprietari delle piattaforme alimentanti. Si tratta per lo più di interrogazioni ad hoc, parametrizzate per quanto riguarda l’arco temporale, eseguite periodicamente solitamente nei momenti di minore attività del sistema.

La fase di trasformazione, quella a maggiore valore aggiunto tra le tre contenute in questo layer applicativo, applica regole di integrazione, trasformazione e cleansing (business rule) ai dati estratti dai sistemi alimentanti. È in questo layer che molto spesso si gioca la credibilità dei dati del data warehouse presso gli utenti. Nella maggior parte dei casi i dati estratti dai sistemi transazionali sono incompleti o comunque inadatti a prendere decisioni, in quanto non sono coerenti con le analisi da effettuare.

In alcuni casi le operazioni di trasformazione possono causare un reject (rifiuto), il quale segnala l’impossibilità di accettare parte del flusso alimentante a causa di ‘impurità’ nei dati di origine.

Le possibili cause di rifiuto sono varie:

  • Codifiche incoerenti. Lo stesso oggetto è codificato in modo diverso a seconda del sistema alimentante. In fase di trasformazione ogni flusso alimentante andrà ricodificato seguendo la codifica convenzionale definita per il data warehouse;
  • Unità di misura/formati incoerenti. È il caso in cui la stessa grandezza viene misurata con unità di misura o rappresentata con formati differenti a seconda del sistema alimentante di provenienza. In fase di trasformazione ogni flusso alimentante andrà convertito in un’unica unità di misura convenzionale per il data warehouse;
  • Denominazioni incoerenti. È il caso in cui, a seconda della fonte, lo stesso oggetto (di solito un dato) viene denominato in modo diverso. Solitamente il dato all’interno del warehouse viene identificato in base alla definizione contenuta nei metadati del sistema;
  • Dati incompleti o errati. Nei tre casi precedenti le operazioni di trasformazione consistevano essenzialmente in attività di conversione, entro certi limiti automatizzabili. In questo caso, invece, l’operazione di trasformazione può richiedere l’intervento umano per risolvere casistiche non prevedibili a priori.

Data preparation and storage layer

Una volta che i dati hanno superato il transformation layer, essi vengono ‘stoccati’ in questo livello architetturale per consentire:

  • la creazione di sintesi informative per gli utenti (data mart e aggregazioni) mediante procedure ad hoc che solitamente vengono innescate (in termini di update) al completamento delle operazioni di estrazione, trasformazione e caricamento;
  • l’esecuzione di analisi avanzate, basate prevalentemente su algoritmi di tipo statistico, che richiedono di operare sul massimo dettaglio disponibile dei dati per restituire risultati significativi.

Questo livello coincide con il massimo dettaglio disponibile (in termini di dati) all’interno del sistema di data warehousing.

Data interpretation and analysis layer

A questo livello si trovano oggetti tra loro molto diversi per funzione e tecnologia. Le funzionalità base espletate da questo livello architetturale sono: aggregazione, analisi e interpretazione.

Aggregazione

La funzionalità di “aggregazione” provvede a costruire sintesi decisionali partendo dai dati di dettaglio presenti nel layer precedente. Qui si deve fare un’importante precisazione architetturale.

In una situazione in cui non esiste il data warehouse gli utenti sono costretti ad accedere ai sistemi legacy per ottenere le informazioni loro necessarie.

In alcuni casi si può decidere di estrarre dai sistemi legacy una o più sintesi (data mart) per gli utenti che effettueranno l’analisi su di esse. In questa situazione, anche se la tecnologia e l’architettura assomigliano a quelle di un data warehouse, l’impossibilità di arrivare a dati di dettaglio superiore a quello delle sintesi disponibili ne riduce la potenza informativa.

Peraltro il data warehouse non va necessariamente considerato come una base dati a cui tutti gli utenti accedono liberamente per le proprie analisi. Questo può essere vero dove gli utenti siano particolarmente addestrati e, comunque sia, ha delle controindicazioni in quanto le risorse hardware necessarie per supportare un elevato numero di utenti che eseguono interrogazioni complesse sono difficilmente prevedibili e pianificabili. Molti presunti progetti di Warehousing falliscono proprio perché ci si limita a ‘portare dentro i dati’ senza però di fatto renderli disponibili agli utenti meno esperti.

La situazione ideale è quella in cui esiste un data warehouse centrale, contenente tutti i dati al minimo livello di dettaglio richiesto per effettuare analisi avanzate e per costruire aggregazioni per tutti gli utenti. In questo caso i data mart possono essere tematici (cioè contenenti tutte le informazioni riguardo un certo soggetto) oppure per gruppi specifici di utenti.

Questa strategia architetturale fa del data warehouse un vero processo di information delivery, ove la richiesta di nuove sintesi decisionali comporta non già la costruzione di altri flussi di alimentazione ma piuttosto la creazione di altri data mart. Lo sviluppo di nuovi data mart è una normale attività di gestione del data warehouse. La differenza con quanto si dovrebbe fare utilizzando i sistemi legacy è essenzialmente di costo: generare un nuovo data mart all’interno di un’architettura di warehousing ha costi e tempi di sviluppo e di controllo qualità dei dati nettamente inferiore.

Analisi e interpretazione

La funzionalità di analisi consente di effettuare indagini sugli aggregati costruiti dal sistema. Tipicamente le funzionalità di analisi di un data warehouse si appoggiano su una tecnologia di tipo OLAP (On-Line Analytical Processing).

L’OLAP è essenzialmente un approccio ai processi decisionali che si focalizza sull’analisi dimensionale delle informazioni. Le sue caratteristiche principali sono:

  • è orientato agli utenti di business: il business è fatto a dimensioni e non a tabelle e chi analizza e tenta di comprenderlo ragiona appunto per dimensioni; è per questo che, una volta intuiti i due concetti fondamentali (dimensione e gerarchia), qualsiasi utente di business è in grado di utilizzare uno strumento OLAP;
  • è pensato per la risoluzione di problemi non strutturati: a differenza dei tradizionali strumenti di reporting che presentano già le risposte preconfezionate, gli strumenti OLAP stimolano le domande e consentono analisi di causa-effetto. Ciò avviene grazie alla loro struttura che permette la navigazione tra le informazioni, utilizzando le gerarchie e le relazioni tra le informazioni stesse come ‘sentieri’;
  • si focalizza sulle informazioni: i motori OLAP non sono di per sé strumenti di presentazione delle informazioni ma architetture ottimizzate di data storage e navigazione; ne segue che tutto ciò che un utente trova in questo ambiente sono solo le informazioni di cui ha bisogno, organizzate secondo la logica delle dimensioni di analisi di business;
  • (di conseguenza) crea efficienza: ovviamente il risultato netto di tutto ciò è l’efficienza creata da questi sistemi con la loro capacità di andare dal generale al particolare e di aiutare l’utente a trovare l’informazione necessaria in base a percorsi logici e non ‘scartabellando’.

Data presentation layer.

Questo livello contiene i sistemi di presentazione delle informazioni agli utenti.

I sistemi appartenenti a questo layer architetturale possono essere raggruppati in tre grandi categorie:

  • strumenti specialistici di Business Intelligence:
    in questa categoria, molto vasta in termini di soluzioni presenti sul mercato, troviamo strumenti per costruire query, strumenti di navigazione OLAP (OLAP viewer) e, in un’accezione ampia, anche i Web browser, che stanno diventando l’interfaccia comune per diverse applicazioni;
  • strumenti di Office Automation:
    spesso i software vendor presenti con le loro soluzioni nel layer architetturale precedente indicano come soluzioni di front end gli strumenti ordinari del lavoro quotidiano, come word processor e fogli elettronici. Questa è una soluzione rassicurante per gli utenti che si avvicinano per la prima volta al data warehouse, in quanto non sono costretti ad imparare nuovi strumenti complessi. Il problema consiste nel fatto che tale soluzione è adeguata per quanto riguarda produttività ed efficienza, lo è meno per l’utilizzo intensivo del data warehouse, dal momento che questi strumenti, in tale caso, hanno limiti architetturali e funzionali significativi;
  • strumenti di grafica e publishing:
    anche qui prevale una considerazione di efficienza e produttività: gli strumenti di Business Intelligence sono capaci di generare grafici e tabelle per i propri utenti, la soluzione in oggetto serve sostanzialmente ad evitare inefficienti doppi passaggi.

I dati

Un data warehouse comprende diversi livelli di dati:

  • Dati attuali di dettaglio:
    sono i dati al massimo livello di dettaglio che si ritiene possa essere utile ai processi decisionali, sulla base delle esigenze note e di quelle ragionevolmente prevedibili. In realtà, questa parte comprende non solo i dati propriamente attuali (cioè validi al momento dell’interrogazione), ma anche una certa finestra temporale di dati storici. Oltre all’eventuale prima aggregazione, i dati di questo livello hanno già subito rispetto ai dati operativi tutte le altre operazioni: filtraggio delle informazioni non necessarie, interrogazione delle informazioni da fonti diverse, trasformazione rispetto allo schema dati del data warehouse.
  • Dati storici di dettaglio:
    i dati di dettaglio che superano la finestra temporale del dato “attuale” ma che rientrano comunque nella finestra temporale del data warehouse vengono collocati su supporti meno impegnativi e costosi, ma anche accessibili meno comodamente.
  • Dati aggregati:
    la presenza dei dati aggregati nel data warehouse deriva da considerazioni di efficienza e praticità nella risposta alle richieste degli utenti; infatti tutte le informazioni ricavabili dai dati aggregati sono in teoria ricavabili dai dati di dettaglio, ma ciò richiederebbe di volta in volta il loro ri-calcolo. In questo modo, però, non potranno essere soddisfatte esigenze non previste che richiedano aggregazioni diverse da quelle predisposte, ma a questo scopo sono comunque conservati i dati di dettaglio.

La progettazione di un Data warehouse

Come accennato precedentemente, il data warehouse è un sistema OLAP (On-Line Analytical Processing) che differisce dai sistemi OLTP (On Line Transaction Processing), sebbene i dati provengano da questi ultimi. I sistemi OLAP sono sistemi orientati al soggetto, sono integrati, storici e permanenti. Non comprendono dati analitici e statici come i sistemi OLTP, inoltre i dati OLAP non sono adatti ad uso corrente, ma vengono usati per analisi.

Un data warehouse è sempre diviso dal suo ambiente operativo. I dati del data warehouse non vengono mai cambiati; sono memorizzati all’inizio e messi a disposizione, e non sono aggiornati come nei sistemi OLTP. Prima di essere memorizzati nel data warehouse, i dati sono integrati seguendo diverse strategie.

La fonte dei dati per un data warehouse è un sistema operativo, anche se la prima non è una pura copia del secondo: i dati in un sistema decisionale sono filtrati, classificati cronologicamente, sono aggiunti dei valori riassuntivi e sono cambiati prima di essere caricati nel data warehouse. In particolare, per i microdati, i dati sono riassunti a due livelli di aggregazione distinti: il primo livello (primo livello di data mart) specifica l’unità del tempo, e nel secondo livello (data mart finale) sono memorizzati permanentemente soltanto dati a più alta frequenza. Così, se i dati sono acceduti più frequentemente, il livello di sommarizzazione è più elevato. In altre parole, è memorizzato un numero minore di dati, e l’accesso ai dati è più veloce ed efficiente.

I principali approcci per sviluppare un ambiente di data warehouse sono due: il primo è basato sulla creazione di un data warehouse centrale, usando dati dal sistema principale ed altre fonti. Questo data warehouse centrale può essere poi usato per creare/ aggiornare data warehouse dipartimentali o data mart locali. Il secondo approccio è basato sulla creazione di data mart indipendenti, ognuno memorizzato direttamente dal sistema centrale e altre fonti dei dati.

L’approccio di un data warehouse centrale può iniziare con un data warehouse semplice, ampliabile nel tempo per soddisfare utenti con richieste crescenti e diventare un ambiente che contenga sistemi di data warehouse interconnessi. In un ambiente di data warehouse semplificato bisogna organizzare tre aree:

  • l’estrazione e la trasformazione dei dati dai sistemi operativi;
  • la base di dati del data warehouse;
  • gli strumenti per interpretare i dati.

È necessario monitorare la rete che consente l’accesso agli utenti. Ci sono di solito almeno tre repository per i metadati e per le altre informazioni collegate: uno per descrivere la struttura dei dati, per la loro trasformazione e per l’estrazione dei dati; uno per il database del data warehouse; ed uno o più per gli strumenti di navigazione. Questi repository devono essere curati individualmente e complessivamente. I dati nell’ambiente del database del data warehouse dovrebbero essere maneggiati con la stessa cura. La complessità di questo compito dipende dalla complessità del database scelto, ma include copie di backup, recovery, riorganizzazioni, archiviazioni, operazioni di monitoraggio e tuning. Sono creati sub-set di dati dipartimentali o locali (data marts) per migliorare la performance delle consultazioni dell’utente e ridurre la dipendenza dal data warehouse. Questo livello aggiuntivo di dati aumenta la complessità di gestione dell’ambiente: aggiunge un altro livello di metadati e possibilmente un altro repository, richiede controllo e gestione della distribuzione dei dati dei data mart, e, a meno che l’amministrazione dei data mart sia completamente devoluta a livello locale, richiede anche la gestione di dati del database del data mart. La situazione diventa anche più difficile se l’ambiente continua ad evolvere tramite la creazione di data warehouse multipli. In alcuni di questi casi, le complessità di amministrazione diventano opprimenti.

Nell’approccio con data mart indipendenti, la creazione di un solo data mart orientato a risolvere un particolare problema rappresenta una soluzione semplice. Le tre aree da amministrare sono:

  • l’estrazione dei dati dalle fonti e la trasformazione nelle strutture dei dati corrette per il database del data mart;
  • il database del data mart stesso;
  • gli strumenti per interpretare i dati.

Poiché questo ambiente non contiene grandi volumi di data warehouse esso è più maneggevole. Nel caso si adotti una tale semplice soluzione di data mart nella realizzazione di data warehouse e nell’organizzazione, il compito dell’amministratore sarebbe relativamente facile. Questo approccio non si ferma di solito ad un data mart e, una volta che vengono aggiunti altri data mart, la situazione diventa più complicata. Il compito di portare numerosi data mart separati in un solo ambiente di data warehouse è estremamente difficile. Ogni data mart viene sviluppato di solito individualmente. Tali data mart hanno il potenziale di diventare parte del sistema centrale. In questo modo, possono porre il problema di discordanze nella definizione dei dati che il data warehouse è stato disegnato per risolvere. Questa situazione poco attraente si evita solamente se esiste un’architettura centralizzata di amministrazione dello sviluppo del sistema.

Il data warehouse potrebbe arrivare a contenere volumi molto grandi di dati, non sempre interessanti per tutti gli utenti. Lavorare con questi volumi di dati non correlati può essere inefficiente e consumare molte risorse di calcolo. In questa situazione è possibile suddividere il data warehouse in aree di interesse specializzate.

Inoltre, molti tool per lo sfruttamento dei dati creano i loro primi ambienti, ognuno col proprio repository. Tale repository contiene le informazioni richieste per l’esplorazione dei dati. Se il data warehouse è amministrato centralmente, questi ambienti devono essere incorporati nella struttura di gestione centrale. Anche dove la responsabilità dell’amministrazione dei tool di sfruttamento dei dati è a livello locale, serve un collegamento tra il sistema di amministrazione centrale e gli ambienti distribuiti. Questo collegamento è necessario per assicurare che i cambiamenti dei tool degli ambienti distribuiti possano essere identificati anche centralmente.

Altri aspetti progettuali

I livelli ‘operativi’ del data warehouse possono esistere sotto due condizioni fondamentali:

  • l’esistenza di un’adeguata organizzazione di supporto al processo, con ruoli e responsabilità definiti. In modo analogo alle applicazioni transazionali, un sistema di decision support necessita di figure organizzative con la responsabilità di mantenerlo, soprattutto in chiave evolutiva, per far sì che esso sia costantemente allineato alle esigenze degli utenti di business, condizione necessaria e sufficiente perché continui ad esistere;
  • il giusto rilievo alla tecnologia di supporto al processo, composta di scelte equilibrate e basate sulle esigenze funzionali del processo stesso. La tecnologia è cruciale per il data warehouse, date le problematiche di system integration che esso comporta. La gestione costante della variabile tecnologica è uno dei fattori di successo del data warehouse, a partire dalle scelte iniziali per arrivare alla gestione operativa degli aggiornamenti e degli ampliamenti della piattaforma.

Applicazioni del data warehouse

Il data warehouse è un sistema informativo dove i dati sono organizzati e strutturati per un facile accesso da parte dell’utente e per fornire supporto ai processi decisionali. I seguenti sistemi sono abilitati dal data warehouse:

  • DSS (Decisional Support System)
  • EIS (Executive/Enterprise Information System).

Il primo è utilizzato per risolvere problemi specifici, mentre il secondo consente una continua circolazione dei dati non dipendente da problemi specifici.

Nelle banche e in generale nelle istituzioni finanziarie gli ambiti di utilizzo sono molteplici, poiché tutte le aree gestionali di tali organizzazioni sono caratterizzate da volumi considerevoli di dati su cui devono essere prese decisioni strategiche. Poiché il data warehouse può avere un valore strategico, all’interno di tali tipi di organizzazioni è fondamentale per il management definire una strategia per il data warehouse. La strategia per il data warehouse è essenzialmente un percorso evolutivo che porta l’azienda da applicazioni DW non ‘mission-critical’ verso una situazione in cui il data warehouse è una componente fondamentale del sistema informativo aziendale.

La strategia di data warehousing di un’azienda può essere classificata in base a due dimensioni fondamentali:

  • utilizzo del DW esistente: livello di maturità degli utenti e delle funzioni di supporto del DW nell’utilizzo dell’esistente;
  • utilizzo del DW in prospettiva: di utilizzo del DW come piattaforma di decision support.

Le aziende attraversano dunque quattro fasi nella storia dell’utilizzo del data warehouse:

  • la prima fase, chiamata supporto (basso utilizzo del DW esistente, basso utilizzo prospettico del DW), è la fase in cui si trovano le aziende che hanno fallito uno o più progetti di warehousing e non pensano di ampliarne l’utilizzo prospettico. In questa fase si possono trovare anche aziende che non hanno un DW e non pensano di realizzarlo;
  • la seconda fase, chiamata opportunità (basso utilizzo del DW esistente, alto utilizzo prospettico del DW), è la fase in cui si trovano le aziende che, pur avendo fallito uno o più progetti di warehousing o avendo semplicemente esplorato la tematica senza approfondirla, puntano a sviluppare le attività di decision support tramite il data warehouse.
  • la terza fase (alto utilizzo del DW esistente, alto utilizzo prospettico del DW), è quella fase in cui il data warehouse diviene strategico per i processi decisionali aziendali. In questa fase si trovano tutte quelle aziende che hanno intrapreso con successo un progetto di warehousing e che ne stanno sfruttando a pieno le potenzialità;
  • la quarta fase, chiamata factory (alto utilizzo del DW esistente, basso utilizzo prospettico del DW) è la fase in cui si trovano le aziende in cui il data warehouse è maturo, la metodologia di implementazione consolidata e le aree decisionali critiche sono presidiate. In questa fase l’imperativo principale è l’efficienza e il risparmio di costi derivanti dal data warehouse e nel suo utilizzo. Un processo di sclerotizzazione nell’uso del data warehouse può in alcuni casi far tornare l’azienda alla prima fase.

Individuiamo ora quali sono le aree applicative più indicate per il data warehouse nel settore finanziario.

Controllo di gestione

Questa può essere l’area applicativa di base per un sistema di data warehousing in qualunque organizzazione. In questo caso il data warehouse viene utilizzato sostanzialmente come piattaforma di reporting e analisi di redditività. È inutile e pericoloso ipotizzare di realizzare un data warehouse solo per il controllo di gestione. Tale iniziativa ha senso solo se questo è il primo passo evolutivo nella strategia di data warehousing dell’azienda. Infatti, costruire un data warehouse per il controllo di gestione consente di analizzare e risolvere rapidamente esigenze estremamente rilevanti ed il cui beneficio è immediatamente chiaro, affrontando problemi (a livello di struttura, validazione e calcolo dei dati) ben noti nella loro struttura.

Risk e Asset Management

Un’altra area applicativa interessante è identificabile nelle attività di Risk e Asset Management (vedi Gestione del rischio), soprattutto in due attività ben specifiche: l’analisi e la simulazione dei portafogli e dei relativi rischi; il reporting.

Tali aree applicative sono di particolare importanza e strategicità ed il data warehouse è lo strumento appropriato per affrontarle, anche per la possibilità di integrare al suo interno dati provenienti da fonti esterne all’azienda. In questo caso il data warehouse va dotato di strumenti di analisi avanzati e basati su algoritmi statistici di analisi e simulazione.

Un’altra sotto-area di grande interesse può essere lo sviluppo di sistemi per l’individuazione delle frodi. Anche in questo caso è necessario il ricorso a strumentazione di tipo statistico.

Supporto alle vendite

Non necessariamente il data warehouse è appropriato per affrontare e risolvere questo tipo di esigenza, a meno che esista la necessità di immagazzinare e gestire rilevanti masse di dati. In molti casi il database di marketing è banalmente un’anagrafica clienti arricchita di alcune informazioni “non amministrative”, in casi più avanzati diventa uno strumento fondamentale di supporto al ‘’marketing one-to-one’’. In questo caso il database di marketing costituisce una base di informazioni fondamentale per indirizzare correttamente campagne e iniziative promozionali o per attivare servizi avanzati di ‘’customer care’’. In questo caso, data la rilevante massa di dati da gestire, il data warehouse può diventare la piattaforma tecnologica ideale.

Nel settore bancario il marketing one-to-one è ancora allo stadio embrionale, almeno dal punto di vista del marketing centrale, e questo è dovuto al fatto che molto spesso il marketing one-to-one viene fatto dalla filiale, l’unica struttura aziendale in grado storicamente di instaurare un rapporto fiduciario con il cliente finale, che identifica l’azienda nello ‘sportello’ e nel suo ‘impiegato’.

Sistema informativo di marketing

Si tratta di utilizzare il data warehouse come una sorta di ‘backbone’ per supportare una serie di applicazioni integrate orientate alle analisi commerciali e di marketing. Gli aspetti fondamentali che caratterizzano questo tipo di architettura sono essenzialmente due:

  • la possibilità di integrare basi di dati transazionali diverse in un’unica base dati analitica e produrre quindi ‘viste’ integrate della clientela, del mercato e dei prodotti;
  • la possibilità di effettuare analisi con strumenti e logiche diverse su una base unica.

L’idea di fondo del sistema informativo di marketing è quella di sviluppare un percorso evolutivo che parta dal reporting di base per arrivare ad analisi avanzate, passando attraverso sistemi di analisi del portafoglio prodotti e clienti e procedure di budgeting e simulazione.

 

Supporto al Call Center

Anche in questo caso il data warehouse è un’opzione tecnologica, non l’unica praticabile e non necessariamente la più economica. Utilizzare un’architettura di data warehousing a supporto di un’attività di Call Center ha sicuramente senso nel caso in cui le richieste non sono necessariamente di tipo strutturato e quindi risolvibili con il classico “inquiry (interrogazione) da terminale”. È evidente però che la tipologia di utente per questo tipo di sistema è più evoluto del normale operatore di Call Center.

Knowledge Base

Anche in questo caso valgono le considerazioni fatte per il Database di Marketing: non necessariamente il data warehouse è la tecnologia più idonea per questo tipo di esigenza, ma lo diventa nel momento in cui la conoscenza in oggetto è costituita prevalentemente da informazioni strutturate e preferibilmente numeriche. In questo caso, anche dal punto di vista tecnologico, un database relazionale è sicuramente la soluzione più idonea, efficiente ed economica. Non è così se invece le informazioni sono di tipo destrutturato, in questo caso la soluzione più adatta è una piattaforma di groupware. Si deve però fare attenzione a non confondersi con i cosiddetti database multimediali: il fatto che un database relazionale abbia funzionalità multimediali non significa che sia un data warehouse. Infatti, ciò che distingue un data warehouse da ciò che non lo è, non è la tecnologia utilizzata, ma l’architettura applicativa e il disegno della base di dati.

Engineering di prodotto

Il data warehouse può essere una piattaforma decisionale per l’analisi e la concettualizzazione di nuovi prodotti da offrire alla clientela e/o per aggredire nuovi mercati o segmenti di mercato. Tale funzionalità è ovviamente supportata se il data warehouse è dotato non solo di strumenti di analisi dei risultati, ma anche di ambienti di simulazione che consentono la costruzione ed il testing ‘in laboratorio’ di nuove soluzioni da proporre ai clienti. In tali ambienti è possibile individuare alcuni importanti aspetti come la marginalità, il punto di pareggio economico, il segmento di clientela interessato, i meccanismi di cannibalizzazione, l’elasticità della domanda e l’impatto sull’equilibrio finanziario aziendale.

e-business

La diffusione del canale digitale nel settore finanziario pone una serie di problemi e di opportunità nuove. In primo luogo questo tipo di canale implica una velocità di cambiamento e quindi di reazione nettamente superiore. Il data warehouse può essere lo strumento analitico che consente di cogliere dinamiche all’interno di rilevanti masse di transazioni on-line. In secondo luogo l’informazione può essere uno strumento di supporto o l’oggetto stesso della transazione e in questo caso il data warehouse può essere la piattaforma utilizzata per coprire tale ambito applicativo.

Il data warehouse può essere quindi di supporto a sistemi di trading on-line  sia dal punto di vista dell’analisi che dal punto di vista dell’architettura dati

 

Articoli Correlati

Investimenti IT: in un anno di crisi i Cio sono ottimisti

Da una indagine condotta da Coleman Parkes per conto di Intel risulta che, per quasi il 70% dei CIO italiani, non ci saranno tagli agli investimenti nell’IT, anzi si prevedono investimenti stabili o in crescita.

Molto incoraggiante appare il dato che attesta come il 78 per cento dei Cio si attenda investimenti stabili o in crescita per quanto riguarda, in particolare, i progetti a forte carattere innovativo. Ciò dimostra la diffusa consapevolezza che gli investimenti IT sono necessari per migliorare l’efficienza, alimentare l’innovazione e, in definitiva, ottenere vantaggi competitivi.

Le priorità di spesa per il 2009 saranno le seguenti:

  1. sicurezza
  2. consolidamento dei data center
  3. virtualizzazione
  4. incremento dell’efficienza
  5. cloud computing (anche se i media ne stanno abusando un po’ troppo)

Articoli Correlati

In tempi di crisi, secondo gli analisti, gli strumenti CRM sono il miglior investimento

luca

Leggo da Gartner che in questi momenti, gli strumenti CRM sono il miglior investimento per le aziende.

In sostanza le aziende che si doteranno di tali strumenti potranno essere avvantaggiate rispetto ad altre che attendono ancora.

Gli strumenti che, secondo gli esperti, dovrebbero essere analizzati e cominciati a sperimentare sono:

  1. Customer Community, e cioè creazione di community di clienti online interconnessi tramite gli strumenti di social networking quali Facebook, Twitter et simila;
  2. Strumenti analitici per la gestione e l’analisi delle moli di dati che sono presenti in azienda e che troppo spesso non vengono sfruttate mentre potrebbero dare impulsi per nuove strategie di mercato;
  3. Revisione dei processi, in quanto nuove strategie molto spesso portano con se il cambiamento del modo di lavorare.

Per chi fosse interessato il link è questo.

Sono d’accordo ma… poi mi guardo attorno, operiamo nel nord-est, patria delle micro e piccole imprese. Molto dinamiche ma in quanto ad informatizzazione ancora molto indietro. Non parliamo poi dell’accesso alla rete, che soluzioni del genere hanno bisogno. Se usciamo dai principali centri addio accesso Internet (nel senso che quando siamo fortunati abbiamo le adsl a circa 1 mega nominale).

Eppure gli strumenti ci sono, neanche troppo costosi per poter cominciare veramente a fare cambaimento di cultura e di processo. Certo che le soluzioni devono essere tarate su questa realtà (che comunque è specchio di quella italiana) e, molto spesso, i supposti consulenti, non riescono a proporre.

Vedremo

Articoli Correlati