I documenti clinico sanitari verso la dematerializzazione: lo scenario italiano in uno studio dell’Osservatorio ICT in Sanità del Politecnico di Milano

Da ICT4Health.

Realisticamente parlando, nella Sanità è ancora troppo presto ipotizzare che i progetti di dematerializzazione possano abilitare scenari che prevedono la totale scomparsa dei documenti cartacei dalle strutture sanitarie, soprattutto in orizzonti temporali di breve periodo. Un’analisi corretta della diffusione di tali soluzione deve partire innanzitutto da una visione realistica del fenomeno.

Da questa considerazione prende le mosse la Ricerca dell’Osservatorio ICT in Sanità, “La Dematerializzazione in Sanità: dai documenti ai processi”, condotta sulle Direzioni ICT di 118 strutture sanitarie italiane, pubbliche e private. Emerge che il livello di diffusione delle soluzioni è ancora nelle prime fasi di sviluppo: circa un quarto del campione della ricerca non ha ancora deciso di investire, il 30% ha avviato dei progetti pilota, mentre più del 40% di aziende sanitarie (soprattutto aziende di grandi dimensioni, come confermato dalle interviste ai Chief Information Officer) sta già affrontando la tematica in ottica operativa, sull’intero ambito aziendale e con diversi livelli di estensione.

In particolare la dematerializzazione dei documenti è stata prevalentemente condotta in ambito clinico-sanitario piuttosto che in quello amministrativo per la presenza di sistemi, prevalentemente diagnostici, predisposti per la produzione di referti e immagini già originariamente in forma digitale. Dall’approfondimento condotto e dai dati rilevati sugli investimenti programmati si evince che la diffusione della dematerializzazione in questo ambito è destinata ad aumentare nell’immediato futuro.

Per avere una fotografia più precisa dello stato di diffusione e di maturità nelle aziende sanitarie nel rispetto delle indicazioni normative, le diverse realtà del campione di riferimento sono state mappate su una scala che comprende quattro stadi evolutivi, ricavati da un’analisi dei casi di maggior successo, che considerano:

presenza di un workflow automatizzato;

modalità di firma dei documenti;

effettuazione dell’archiviazione sostitutiva a norma;

modalità di esibizione a norma dei documenti informatici.

In seconda battuta sono state prese cinque macro aree funzionali ed è stato chiesto ai CIO di segnalare il livello di dematerializzazione in esse raggiunto: accoglienza e dimissione; diagnosi (radiologia e in generale tutte le diagnostiche per immagini, i servizi laboratoristici, ecc); cura; ciclo amministrativo e finanziario; ciclo logistico commerciale.

Emerge che nell’area funzionale della diagnosi la Dematerializzazione ha raggiunto livelli di completezza maggiori, e in particolare nei laboratori e dalla radiologia. In media infatti in quest’area il 71% del campione utilizza applicazioni che permettono di produrre l’output finale del processo (lastre, referto, diagrammi ecc.) in forma elettronica/digitale, il 52% prevede l’applicazione della firma digitale sui documenti informatici prodotti; il 32% circa effettua la conservazione sostitutiva dei documenti prodotti; il 20% dei casi dichiara di realizzare il processo di esibizione nel rispetto del quadro normativo attualmente in vigore.

Per quanto riguarda invece tutte le aree legate alla Dematerializzazione di documenti amministrativi, le aziende, pur essendo dotate (o in fase di dotazione) di sistemi gestionali che permetterebbero la gestione digitale delle pratiche in ottica di workflow non hanno ancora avviato un vero e proprio processo, se non per tipologie limitate di documenti amministrativi. Se è vero che dematerializzare in ambito sanitario abilita potenziali vantaggi molto più rilevanti rispetto alla sfera amministrativa, è altrettanto vero che quest’ultima area non deve essere dimenticata, soprattutto se si considerano gli obiettivi fissati dal Ministero per la Pubblica Amministrazione e l’Innovazione che puntano a una gestione dei pagamenti sempre più digitale.

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

I costi della banda larga mancata

Artcolo tratto da saperi.forumpa.it.

Intervista a  Francesco Sacco manager director di EntER – Centre for research on Entrepreneurship and Entrepreneurs e professore dell’università Bocconi.

I benefici degli investimenti in infrastrutture a banda larga – come dimostrato dalle ricerche – non sono limitati al settore delle telecomunicazioni e determinano esternalità positive. Gli effetti non “lineari” e fortemente influenzati dal contesto tecnologico di sfondo degli investimenti in telecomunicazioni – sottolinea il professor Francesco Sacco – sono maggiori e sempre più positivi laddove la diffusione della tecnologia raggiunge la massa critica, a mò di servizio universale.
Tra le analisi sul tema quella di Ford & Koutsky studia l’impatto del broadband sullo sviluppo economico – derivante da ingenti investimenti in BroadBand (principalmente fibra) – di Lake County, una piccola comunità della Florida. Confrontando Lake County con comunità simili per molteplici caratteristiche e per la medesima situazione economica iniziale, gli autori hanno stimato una crescita pari al doppio del tasso delle contee appartenenti al gruppo di controllo.
Altre ricerche realizzate sempre negli Stati Uniti hanno dimostrato come l’impatto del broadband generi una rapida crescita in vero settori:

  • Occupazione (+1,5%)
  • Salari (impatto positivo ma non statisticamente misurabile)
  • Crescita del numero di attività economiche (+0,5%)
  • Crescita di attività economiche nel settore IT (+0,5%)
  • Aumento del valore degli immobili

Questi dati sono confermati anche da ricerche condotte in Europa e in altri Paesi, con una certa omogeneità dei riscontri:

  • Il broadband e l’ultrabroadband hanno un impatto positivo sull’economia
  • L’impatto è più forte dove l’ecosistema ICT è più forte
  • Se l’innovazione accelera, l’impatto aumenta
  • L’impatto cambia quando cambia la base degli utenti
  • Stimoli alla domanda
  • Transizione demografica

La situazione italiana
Alla luce di questo scenario, la situazione italiana appare ancora più drammatica anche se il dato comunque positivo è che, a proposito degli 800 milioni stanziati per l’abbattimento del digital divide e poi congelati,  c’è stato un forte movimento di protesta online e sulla stampa. Come a dire, bastonati ma vivi. “Sarei comunque ottimista: il dibattito scatenato intorno a quest’annuncio è tale da non poter ignorato e sono sicuro che qualcosa accadrà presto“, aggiunge il professore. E se l’uscita dal limbo dell’indeterminazione è un fatto confortante, non sono, però, chiare le mosse future né la strategia di sviluppo delle infrastrutture a banda larga. Sul tema si sono levate opinioni in controtendenza, come quelle che si chiedono come mai le aziende ICT non siano in grado di competere proponendo piani di sviluppo che non poggino sull’aiuto dello Stato. <<In realtà è una somma di problemi – afferma il professor Sacco – quando parliamo di network facciamo riferimento a investimenti di entità molto importanti, ma l’Italia è un paese di “straccioni”>>.
Il secondo tema cruciale è di carattere regolamentare: chi investe tanti soldi, vuole farlo in un clima di chiarezza per quanto riguarda le regole. Deve calcolare i suoi ritorni sugli investimenti e poterlo fare in un arco temporale molto ampio, parliamo di almeno 20 anni. In questo momento le regole non sono chiare né a livello europeo né a quello italiano. “Il punto è – riprende Sacco – che non si sa se e a quali condizioni dare accesso all’infrastruttura in fibra anche ai concorrenti dell’ex monopolista. Questi non sono aspetti marginali e anzi aprono molto il tema poiché prima di mettere sul tavolo 10 miliardi bisogna farlo all’interno di regole chiare”.
L’altro problema è che ci sono diversi modi per realizzare la rete, ma tutti prevedono il riutilizzo dell’infrastruttura Telecom Italia, soprattutto il famigerato ultimo miglio. Inoltre, circa il 60-70% dei costi di infrastrutturazione riguardano opere civili e in parte possono essere abbattuti riutilizzando i cavidotti di Telcom Italia e realizzando i lavori assieme alle opere civili. La collaborazione della pubblica amministrazione è fondamentale per abbattere i costi. La rete a banda larga di MetroWeb, ad esempio, è stata fatta parallelamente al rifacimento dell’illuminazione stradale di Milano, razionalizzando l’investimento e abbattendone i costi.

Ipotizzando l’immediata disponibilità dei fondi previsti nel piano per lo sviluppo della banda larga del viceministro dello Sviluppo, Paolo Romani, il cosiddetto Piano Romani, non sarebbe comunque chiaro come investirli e secondo quale strategia. Il rischio di ritrovarsi tempestati dalle ennesime macchie di leopardo è, quindi, consistente. Il professor Sacco ipotizza per l’Italia uno scenario simile a quello della Svezia: una sorta di patchwork con alcune aree maggiori cablate e altre raggiunte con tecnologie diverse. “In Italia saranno le amministrazioni locali a provvedere: regioni, province, comuni”. Il punto è che, spesso, in queste realtà locali atomizzate manca l’alfabetizzazione necessaria a poter comporre una pianificazione lungimirante e fondata sulla conoscenza della materia.

Riguardo all’annuncio di Brunetta di rendere disponibili per tutti 2 Mega di banda per la navigazione, il professore commenta pragmaticamente: “se parliamo di posti remoti meglio 2 Mb che niente, con questa banda è comunque possibile fare ip-television e video conferenze”

Ma se questa è la soglia-obiettivo minima, in un contesto mondiale dove ci sono popolazioni che hanno una disponibilità di banda di 100 Mb come il Giappone, come è possibile reperire i fondi per fare di più?
“La Cassa Depositi e Prestiti ha soldi da investire in questo campo, così come le fondazioni bancarie. E’ importante però che ci sia chiarezza sulla natura e le caratteristiche con cui si realizzerà la rete. E’ un tema estremante caldo anche perché l’impatto sull’economia italiana sarà notevole. I soldi sono pochi, ma se li investiamo in infrastrutture totalmente inutili (per chi? n.d.r.) come il Ponte sullo Stretto di Messina, stiamo facendo un errore drammatico perché al di là delle nostre scelte politiche c’è un elemento incontrovertibile: che ci piaccia o no dobbiamo confrontarci con realtà come la Corea  la Finlandia, la Svezia che stanno puntando e hanno quasi raggiunto il 100% della copertura della popolazione. In questi Paesi il tasso di utilizzo del broadband è enorme, quotidiano e per tutta la popolazione.
Noi dovremmo competere, o quantomeno essere in grado di comunicare con loro”.

Insomma è una deriva dei continenti postmoderna e digitale, due i mondi che si aprono e si allontanano: uno in cui le informazioni e le transazioni viaggeranno a velocità esponenziale, l’altro condannato a rincorre e ad ingoiare polvere binaria.
Noi, non contenti di chiudere il gruppo degli inseguitori dei grandi player economici, non sembriamo affannarci più di tanto, convinti che, alla peggio, per unire questi mondi basterà un ponte, non digitale ma sullo stretto di Messina.

Articoli Correlati

Banda larga per le zone rurali. 154 milioni di euro a disposizione.

Articolo tratto da una comunicazione del ministero delle politiche agricole alimentari e forestali.

“Sono molto soddisfatto – ha dichiarato il Ministro Zaia – di poter contribuire all’abbattimento del divario digitale nelle aree più marginali del nostro Paese, dove le condizioni geo-morfologiche particolarmente difficili, l’eccessiva dispersione della popolazione ed i costi di infrastrutturazione troppo elevati, costituiscono un oggettivo ostacolo alla diffusione, in maniera uniforme, della banda larga e delle più moderne tecnologie di telecomunicazione”.

Anche le aree rurali italiane potranno presto contare su servizi internet ad alta velocità, grazie al progetto «Banda larga nelle aree rurali», predisposto dal Ministero delle politiche agricole alimentari e forestali e notificato nei giorni scorsi alla Direzione Concorrenza della Commissione Europea.

Il progetto, cui sono destinati oltre 154 milioni di euro, sarà cofinanziato dall’Unione europea e realizzato nell’ambito dei Programmi regionali di Sviluppo Rurale (PSR) 2007-2013.
In risposta all’obiettivo comunitario che prevede l’estensione della rete internet ad alta velocità a tutti i cittadini entro il 2010 e, quindi, il superamento del divario digitale infrastrutturale presente nei territori rurali, il Mipaaf ha promosso l’inserimento nel Piano Strategico Nazionale per lo sviluppo rurale e nei PSR regionali, di una misura di intervento «ad hoc», destinata alle aree rurali più marginali, definite anche a fallimento di mercato (con una densità di popolazione inferiore ai 150 abitanti per chilometro quadrato), vale a dire quelle dove nessun operatore troverebbe conveniente investire, data la scarsa possibilità di recuperare gli investimenti realizzati a seguito del limitato numero di clienti.
A questo proposito, sono state utilizzate le risorse finanziarie straordinarie messe a disposizione dall’Unione Europea attraverso il cosiddetto Piano di ripresa economica (European Economic Recovery Plan), corrispondenti a circa 93 milioni di euro, cui si sono aggiunti circa 61 milioni di euro di cofinanziamento nazionale, per un ammontare complessivo di oltre 154 milioni di euro.

“Internet veloce – ha aggiunto il Ministro – è ormai diventato uno strumento imprescindibile per la crescita, la diversificazione e lo sviluppo delle economie delle aree rurali, e per la riduzione dell’isolamento fisico e geografico delle popolazioni residenti in queste zone”.
Il progetto, condiviso con tutte le Regioni, è stato pensato in sinergia e complementarietà rispetto al più vasto Piano Nazionale di abbattimento del digital divide, noto anche come Piano Romani, predisposto dal Ministero dello Sviluppo Economico.
“Il mio auspicio – ha concluso Zaia – è che tali interventi costituiscano soltanto l’avvio del più ampio ed ambizioso programma, senza la cui realizzazione, gli stessi interventi rurali che abbiamo fortemente voluto, perderebbero di efficacia”.

Articoli Correlati

Azure: il cloud di Microsoft

A partire dal prossimo anno sarà disponibile la piattaforma Azure per il cloud computing di Microsoft.

“L’1 gennaio, per la prima volta, Windows Azure passerà nella fase di servizio di produzione a pagamento, anche se gli utenti inizieranno a pagare solo da febbraio”, ha spiegato Ray Ozzie, chief software architect di Microsoft, all’evento PDC (Professional Developer Conference) del fornitore, in corso a Los Angeles.

Fisicamente i servizi Azure saranno erogati in sei data center, due negli States, due in Europa e due in Asia.

Articoli Correlati

Chrome OS: poche ore ancora per vederlo

Voci che circolano sulla rete, indiscrezioni, annunci.

Oggi alle ore 19:00, ora italiana, in un evento in rete a livello mondiale, verrà fatta vedere l’anteprima del nuovo sistema operativo di BigG che punta direttamente al cuore di BigM. Il link per la visione è questo: http://investor.shareholder.com/googpr/eventdetail.cfm?eventid=75092

Il nuovo sistema operativo sarà completamente open source (base linux) ed  internet-based, con applicativi che non risiederanno sul proprio pc ma direttamente nella “nuvola” di Google, almeno inzialmente. Client di Posta elettronica, Fogli di Calcolo, Elaboratori di testo. Tutto online. E tutto, almeno per ora, in forma gratuita.

I nostri dubbi: bello, ma la garanzia di riservatezza dei nostri dati? e soprattutto… qui in Italia ancora molti non possono avvalersi di reti ad alta velocità (alta per modo di dire, vedete i post precedenti) e quindi di fatto esclusi da questa nuova tecnologia.

Appena sarà disponibile comunque lo testeremo anche noi, in quanto la curiosità è grande

Articoli Correlati

LETTERA APERTA AL GOVERNO PER LO SBLOCCO DEI FONDI DESTINATI ALLO SVILUPPO DELLA BANDA LARGA

Da svariati blog troviamo questo che volentieri riportiamo anche noi.

Illustre Presidente del Consiglio, On. Silvio Berlusconi,
Illustre Ministro dello sviluppo economico, On. Claudio Scajola
Illustre Ministro delle politiche agricole, alimentari e forestali, dott. Luca Zaia
Illustre Ministro per la Pubblica Amministrazione e l’Innovazione, On. Renato Brunetta
Illustre Ministro della Gioventù, On. Giorgia Meloni
Illustre Vice Ministro dello Sviluppo Economico, On. Paolo Romani
Illustre Sottosegretario alla Presidenza del Consiglio, dott. Gianni Letta

A nome delle Associazioni che riuniscono le principali aziende attive nell’Information and Communication Technology, pubblicità e comunicazione, editoria operanti sul mercato italiano e di alcune tra le più importanti Associazioni consumatori si rappresenta l’esigenza di considerare l’importanza di una rapida approvazione da parte del Comitato interministeriale per la programmazione economica delle risorse previste dalla Legge 18 giugno 2009, n. 69, pari a 800 milioni di euro per gli investimenti finalizzati allo sviluppo della banda larga nel nostro Paese.

Da notizie pubblicate sulla stampa, infatti, sembrerebbe che, in relazione alla contingenza economica, il Governo non abbia ancora definito la tempistica per portare all’approvazione del CIPE i predetti fondi fino a che, anche a seguito degli interventi “straordinari” previsti per la superare la crisi, non si possa procedere con maggiore tranquillità attraverso politiche di sviluppo.

Si è concluso proprio l’altro giorno lo IAB Forum, la più importante manifestazione italiana relativa alla comunicazione interattiva, nel quale – di fronte a circa 8.000 persone – il mondo dell’industria e dell’economia, insieme alla comunità scientifica ed alla rappresentanza dei consumatori, hanno ribadito con forza come anche il nostro Paese debba puntare sull’innovazione tecnologica delle imprese, delle pubbliche amministrazioni e delle famiglie per uscire dalla situazione attuale ed avviare un rapido rilancio della nostra economia e dell’occupazione, accelerando l’uscita dalla crisi.

Il Governo ha sempre ribadito l’importanza del superamento del digital divide – tramite investimenti in nuove tecnologie e sviluppo della banda larga – come volano per il rilancio della competitività per le PMI italiane, l’avvicinamento della Pubblica Amministrazione ai cittadini e la creazione di posti e opportunità di lavoro. La banda larga oggi non è un’opzione facoltativa ma un’infrastruttura necessaria per lo sviluppo economico, sociale e culturale del Paese.

E’ indispensabile che l’Italia non perda altro tempo e prenda decisioni, come stanno facendo altri Paesi europei, con prospettive di medio-lungo termine affinché possa restare uno dei player principali delle economie avanzate.

Milano, 9 novembre 2009

Presidente Layla Pavone – IAB Italia
Presidente Stefano Pileri – Confindustria Servizi Innovativi e Tecnologici
Presidente Carlo Poss – Fcp-Assointernet
Presidente Lorenzo Sassoli de Bianchi – Upa
Presidente Diego Masi – Assocomunicazione
Presidente Furio Garbagnati – Assorel
Presidente Elserino Piol – Fedoweb
Segretario Generale Thalita Malagò – AESVI
Presidente Paolo Martinello – Altroconsumo
Segretario Generale Paolo Landi – Adiconsum
Segretario Generale Teresa Petrangolini – Cittadinanzattiva
Presidente Nazionale Giovanni Ferrari – La Casa del Consumatore

Articoli Correlati

Alec 2010 "Artic Light e-He@lth Conference"

Per gli interessati:

3 February 2010 – 5 February 2010 Lulea, Sweden

Demand on healthcare systems is on the rise, in light of demographic change, increased citizen mobility in Europe and the rising expectations of patients. As resources remain limited, now is the opportunity to develop new distance spanning services and technologies that will enhance quality and render the management and provision of our services more efficient and more accessible. ALEC 2010 offers peer to peer learning – participants will hear from other European regions why they should work with e-health, how they can develop and implement e-health policies, what challenges they can expect to face and how e-health can contribute to improving the quality and efficiency of services.

Contact: mariamagdalena.holmgren@nll.se
See also: ICT for Health

Articoli Correlati

Stop alla banda larga. C'e' la crisi.

Leggo da molti giornali: Il progetto banda larga (20 mbit contro i 50-100 tedeschi e francesi) si finanzierà (forse) solo alla fine della crisi economica.

Gli 800 milioni previsti su 1.14 miliardi non arriveranno. L’investimento sul futuro dell’Italia è rimandato. Rimaniamo con le nostre aziende che resteranno sempre più indietro rispetto alle colleghe europee.

Direi che i commenti a questa notizia sono superflui.

Articoli Correlati