La crescente richiesta di soluzioni talvolta generosamente etichettate come Big Data porta spesso con sé un’aspettativa di soluzione per antichi malumori legati alla gestione del dato, confondendo a volte la tecnologia con le attività progettuali da mettere in campo per raggiungere il proprio obiettivo. Sul piano tecnologico, dimensionando adeguatamente il cluster da attuare, si possono giocare volume e velocità, intendendo quest’ultima come tempo di risposta di un sistema in esercizio, ma non come rapidità del processo di approvvigionamento dei dati, in cui subentrano altri fattori che andiamo a considerare.
Nella tradizionale distinzione tra sistemi produttori di dati (i cosiddetti operazionali o transazionali) e sistemi di analisi, si è spesso tentati di unificare i due livelli, sostanzialmente spostando l’analisi sul piano operativo stesso (operational intelligence, real-time), per rimediare ai limiti di questa distinzione che porta lunghe attese e costi difficili da comprendere per portare in produzione una nuova informazione. Ma basare interamente i sistemi di analisi sul livello operazionale ha comunque delle controindicazioni (elevati costi delle appliance in-memory) e presenta dei limiti (carico concorrente tra operazionale e analitico, parzialità dell’operazionale se non si opera con un unico ERP ma con molteplici soluzioni gestionali) che hanno contribuito a contenere questa tendenza.
Con l’avvento dei Big Data, sistemi distribuiti e scalabili che non richiedono un hardware pregiato, sembra essere stata offerta una via più percorribile per il superamento di questa distinzione ed è facile pensare che il datawarehouse possa diventare obsoleto, superato da un più vasto data lake contenente tutto il dato originale, a livello operativo.
E’ però necessario chiarire cosa la tecnologia può risolvere e dove rimane un semplice, seppur utile, supporto.
Se il potenziale di un data lake con il dato operazionale privo di limiti temporali è confrontabile a quello del datawarehouse, non è vero che attuare quel potenziale sia un’attività marginale o semplicemente risolvibile dal cambio di infrastruttura. La modellazione dati che viene fatta in un datawarehouse imprime già una prima semantica e una rete di controlli (integrità referenziale) che definiscono anche il livello minimo di qualità garantita del dato che viene caricato. A questo va aggiunto che normalmente il datawarehouse risolve anche altri tipi di problematiche quali ad esempio:
-
il raccordo storico tra anagrafiche che cambiano nel tempo (lo stesso oggetto logico che cambia codice di anno in anno);
-
la variabilità delle caratteristiche di un stesso oggetto nel tempo (l’appartenenza ad un gruppo, ad un portafoglio, ad una unità organizzativa);
-
il raccordo tra dati e anagrafiche che provengono da sistemi diversi (lo stesso cliente che ha un identificativo diverso nel CRM o nel sistema di billing);
-
il raccordo tra dati e anagrafiche che provengono da aziende diverse nel caso di fusioni e acquisizioni.
Nessun data lake, anche se in grado di ricevere i dati operazionali di tutti i sistemi di un’azienda per un tempo tendente all’infinito, risolverà di per sé le questioni appena citate, che sono problematiche derivanti dai dati stessi e non dall’infrastruttura o paradigma ospite. Per cui, anche volendo seguire la strada dell’abbandono dei datawarehouse, bisognerà sviluppare sul data lake tutta una serie di processi di trasformazione e derivazione dai dati primari al fine di garantire la stessa coerenza, funzionalità informativa, possibilità di incrocio e revisione storica che si è soliti aspettarsi oggi da un datawarehouse.
Proprio perché le problematiche del dato non sono risolte da una piattaforma tecnologica, anche le questioni di qualità dell’informazione si ripropongono sul data lake esattamente come si presentano sulle architetture tradizionali, con l’unica differenza che non abbiamo più alcuna barriera strutturale in ingresso. I sistemi Big Data sono fatti innanzitutto per accogliere dati (come una grande staging area), indipendentemente dal loro formato, origine e qualità. Per trasformarli in informazione di valore bisogna però affrontare tutte le problematiche enunciate fin qui, con approcci e tecniche magari diverse, più orientate all’utilizzo finale che ad una coerenza complessiva, ma comunque con attività e costi da considerare.
Se poi, come auspichiamo, si vira verso i Big Data anche per accogliere dati nuovi, esterni al dominio strettamente aziendale, le problematiche si amplificano ancora ma aprono anche interessanti e nuove opportunità.
Quali opportunità con i Big Data?
La sfida innovativa dei Big Data viene colta appieno dalle iniziative che non si richiudono in un discorso di pura tecnologia e non rimangono confinate nel perimetro dell’IT. Le opportunità più interessanti nascono quando si lavora con dati nuovi o si opera in modo nuovo su dati vecchi o si fanno contemporaneamente le due cose, cercando di arricchire l’informazione già governata con dati altri, interni o esterni che siano.
Il primo passo che apre ad un dato esterno è fatto solitamente dal marketing, che vuole valutare la reputazione del brand o il sentimento diffuso verso una certa iniziativa. Questo è certamente uno spazio importante, ma limitato ai soggetti con cui si ha già una qualche relazione, costruendo un’informazione quasi autoreferenziale. Si può fare un passo avanti cercando di costruire informazioni di contesto allargate, grazie all’integrazione di contenuti anche non strettamente riconducibili al proprio perimetro informativo (open data, social, meteo, data set a pagamento, linked data, etc.). Poiché però non si tratta mai di informazioni puntuali su soggetti singoli chiaramente identificabili, possono sembrare informazioni inutilizzabili qualora si sia ancora nell’idea che l’unico dato fruibile sia quello in perfetto raccordo con i proprio sistemi, quello in cui sia possibile identificare un soggetto reale e ricondurlo ad una propria istanza anagrafica (cosa peraltro che potrebbe generare qualche problema di violazione della privacy da più parti). Basterebbe però invertire l’approccio e pensare di generalizzare il proprio dato quel tanto che basta a renderlo confrontabile con un dato esterno, operando sostanzialmente per cluster. A questo livello l’informazione utilizzabile è molta e va ad arricchire il cluster magari con dati di reddito, di spesa, di propensione a certi tipologie di attività e così via.
Non si potrà mai dire che un dato cliente (di cui si conoscono con certezza solo le informazioni minime atte a regolare un contratto), che poiché cade in un certo cluster, guadagni sicuramente una certa cifra o spenda realmente in un determinato modo. Si potrà però affermare con un ragionevole grado di accuratezza, che persone che assomigliano molto ad un dato cliente, hanno solitamente una certa fascia di reddito e sono più o meno propensi ad acquistare alcune categorie di prodotti.
Lo stesso si potrebbe fare esaminando il territorio da un punto di vista più alto: dei propri clienti si ha magari l’indirizzo di residenza ma niente di più circa la zona in cui questi vivono. Li si potrebbe però collocare territorialmente e, ad un livello meno puntuale (non per indirizzo ma per quartiere, città, provincia, regione), arricchire l’informazione con indicatori demografici (numero di abitanti per tipologia: sesso, fascia di età, italiano/straniero) o legati al tessuto sociale ed industriale (grado di scolarizzazione, tasso di occupazione, numero di PMI) e così via.
Solo così è possibile raccogliere gli elementi per fare un’analisi completa della propria forza di attrazione reale, più che confrontando l’anno corrente con il precedente. Solo così è possibile andare oltre le usuali domande prestazionali (ho raggiunto gli obiettivi? Ho contenuto le perdite? Ho massimizzato i ricavi? Ho efficientato i processi?) per affrontare con nuove armi le domande più sfidanti, volte a impostare politiche di sviluppo più che di contenimento (ho colto tutte le opportunità? Ho perso qualche treno? Sono dentro un cambiamento lento che non sto cogliendo? C’è una domanda che non sto captando?).
Si sta allargando anche il vero e proprio mercato dei dati o dei servizi basati sui dati, a conferma del loro valore non astratto ma ben monetizzabile, per il quale il prefisso big non caratterizza neanche più la piattaforma tecnologica.
Grazia Cazzin
