Dopo l’articolo giunto ieri da Marco Russo, c’è stata una certa discussione, soprattutto via Twitter. Esistono o no i Big Data in Italia? E sono un tema vero per i CIO? Oggi risponde Vincenzo Aloisio, Managing Director di Accenture..
Negli ultimi tempi non esiste un termine più utilizato nel mondo IT come quello dei Big Data. Spesso si genera confusione su questa terminologia che dipende, essenzialmente, dalla definizione, dal cosa si intende per Big Data. Tanti studiosi/esperti/ organizzazioni hanno elaborato definizioni e criteri per delimitare un perimetro. Il tutto si presta, ovviamente, ad interpretazioni più o meno soggettive. Volendo fissare un paletto, proviamo a definire come Big Data quell’architettura che utilizza per la gestione dei dati (anche) tecnologie di tipo no-sql e cioè, una per tutte, il framework hadoop. Tecnologia a dire il vero non poi così nuova ma appannaggio per diversi anni nel mondo Internet dei grandi motori di ricerca come Google e Yahoo. Credo che si sia cominciato a parlare di Big Data con una certa enfasi partendo dall’idea di gestire dati non strutturati (di volumi significativi) provenienti principalmente dai social media . Detto questo si è visto che queste tecnologie possono essere utilizzate anche per la gestione di dati strutturati ed anche in ambienti più tradizionali principalmente in architetture di data warehouse per l’analisi dei dati. Parliamo di tecnologie che si affiancano ai dbms più tradizionali costituendo così un’architettura ibrida. Gli obiettivi di tale architettura possono essere molteplici ma metterei in primis la riduzione del TCO, partendo dal presupposto che hadoop è un open source (o che anche in sue declinazioni “assistite” ha un costo basso) e necessita di infrastrutture hw a basso costo. A grandi linee, senza entrare nel dettaglio, si utilizza hadoop per collezionare dati, tenendo anche grossi volumi in linea su tale strato (Big Data layer”)e trasformo ed aggrego quello che mi occorre per popolare un dbms (appliance) sul quale farò determinati tipi di analisi. Le informazioni sui Big Data layer sono anche accedibili in maniera abbastanza efficiente da strumenti di front end non con l’obiettivo di voler sostituire le architetture di reporting. Tutto ciò porta ad un significativo risparmio di costi di licenze e di hw ed ad un abbattimento di costi di gestione potendo raggiungere con un consolidamento architetturale in quest’ottica un riduzione del TCO anche del 50% a fronte di investimenti modesti. In quest’accezione Big Data serve anche in Italia, visto che in altri paesi tale architettura è già in essere da diversi anni ad esempio in grandi aziende di telecomunicazioni. In Italia diverse aziende (telco, banche, utilities) si stanno muovendo in tale direzione.
I tipi di analisi che si fanno sui dati (data mining, modelli predittivi, forecasting, ecc.) in linea di massima prescindono da Big Data e volendo estremizzare, anche in maniera provocatoria, mi sento di dire che i Big Data non abilitano alcunchè di nuovo da un punto di vista di capacità di analisi, ma rendono possibile ciò che si faceva prima in maniera più efficiente e più efficace (con maggiore velocità).
In un contesto di revisione architetturale di questo tipo possono inserirsi molti altri fattori come utilizzo di strumenti in memory per l’analisi dei dati, appliances/db machine, CEP (Complex event processing) ecc. che spesso vengono messi a torto o a ragione sotto il cappello Big Data ma è inutile dilungarsi e concludo dicendo che la semplificazione e i risparmi che un architettura Big Data comporta ne fa ad oggi giustamente in Italia una delle le priorità dell’agenda dei CIO.
Sul fatto che a lungo termine tecnologie come Hadoop possano portare a risparmi significativi in un’architettura moderna di data warehouse aziendale (EDW), sottoscrivo pienamente. Poi la discussione su dove esattamente collocarli credo sia ancora aperta – non sono convinto che creare un EDW solamente con Hadoop (o similari), facendo Data Mart dipartimentali estraendo direttamente i dati da lì. Uno strato in cui i dati non sono solo “copiati” anche in maniera destrutturata ma soprattutto validati e in qualche modo “certificati” credo sia la premessa per dare valore al concetto stesso di data warehouse. Poi dipende dagli ambiti, certi dati non richiedono alcuna pulizia, altri necessitano di alcuni lavori. Ma credo che la normale evoluzione tecnologica e di mercato ci darà risposte. Al momento parliamo di tecnologie relativamente nuove anche in termini di strumenti di sviluppo e gestione (la semplificazione ottenuta da strutturazione meno rigida dei dati al momento porta con sé anche complicazioni dovute alla mancanza di alcuni strumenti – ma questo si risolverà nel tempo), e il TCO va misurato anche considerando questi aspetti (costi di sviluppo e gestione).
Però, ribadisco, anche io vedo un’utilità in molte architetture di DWH (es. almeno come area di staging in molte implementazioni esistenti, o nell’area di “mirror” della SQLBI Methodology http://www.sqlbi.com/articles/sqlbi-methodology/).
Resta però valida la mia provocazione. In Italia il Big Data (come volumi) non esiste (ancora?) e il fatto che le stesse tecnologie possano essere usati per altri scopi (che probabilmente capiamo solo noi tecnici) non cambia il fatto che, di per sé, Big Data non abilita nuove analisi coi dati esistenti.
E, davvero, questo concetto non è chiaro ai più, al di fuori della ristretta cerchia di tecnici che su queste cose ci lavorano quotidianamente.
Semplificando: se il supermercato (per dire) adotta Big Data, non ottiene nulla dalla tecnologia in quanto tale, se non comincia ad acquisire anche dati complementari a quelli che ha già. E non è la tecnologia (es. Hadoop) ad abilitare queste analisi, quanto il dato raccolto. La tecnologia serve per abbassarne i costi e aumentarne la fruibilità.
Per ora, ahimè, l’effetto buzzword di Big Data è quello prevalente.
Sono d’accordo che il problema risieda nell’organizzare correttamente i dati da sottoporre a successiva analisi, a prescindere dalle metodiche di analisi impiegate (anche quelle “tradizionali” non perdono affatto di rilevanza, tutt’altro), così come condivido il timore che con il termine big data, divenuto “di moda”, si finisca per intendere il tradizionale data mining; il punto però è un altro: integrare i dati, già raccolti e organizzati (normalizzati) per essere gestiti con i DB relazionali, con dati “non normalizzati” vale a dire tutti quei dati che implicherebbero una riprogettazione dei DB, al fine di poterli integrare con quelli già esistenti; tali dati “non strutturati” potrebbero manifestare la loro rilevanza successivamente alla progettazione dei DB, e potrebbero consistere in formati tra i più disparati, o provenire da fonti che poco si prestano ad essere integrati nei DB relazionali: pensiamo ai file di log, ai dump binari relativi al traffico di rete, ad immagini, ec c. Anche l’aggettivo “Big” fa in realtà riferimento alla proprietà, nota come “scalabilità”, che caratterizza l’approccio NoSql: tale scalabilità è legata non solo alle infrastrutture HW, ma soprattutto all’ impiego di algoritmi derivanti dalla programmazione funzionale (map reduce) che permettono di sfruttare al massimo il massimo parallelismo computazionale.
Alessandro, siamo d’accordo. La mia domanda è: in Italia, chi li usa? Se togliamo le startup che nativamente memorizzano i dati lì, quali realtà abbiamo che usano “big data”? Io dalle elezioni a oggi ho visto fiumi di inchiostro parlare di big data “a sproposito” sui giornali, tirando fuori numeri, correlazioni e tendenze che tutto erano tranne l’uso di questi strumenti. Se Twitter mi esporta 200.000 tweet su Excel, il fatto che “loro” usino Hadoop o altro per me è irrilevante. L’analisi la sto facendo con qualche algoritmo di data mining su Excel, o su un file di testo. E la percezione che ho (ma spero di sbagliare e/o di far drizzare le antenne a più d’uno parlandone) è che si pensi a big data come la panacea del problema della mancanza di una cultura aziendale che sappia leggere i numeri e investirvi, non solo nella produzione di report “statici” ma nella loro interpretazione. Nel colmare la distanza che c’è tra guardare un numero in uno schema impostato anni prima e trovare correlazioni e comparazioni in maniera dinamica, con la capacità di navigare nel dato. Se big data aiutasse nel far crescere questa cultura, ben vengano le buzzword. All’estero un po’ funziona. In Italia un po’ meno, nella mia esperienza. Alla fine il processo in azienda non cambia.
Se poi big data è un sistema per abbassare i costi di una parte della pipeline dei dati verso sistemi di reportistica “tradizionale” (come citato nel post di Luca De Biase da parte di Vincenzo Aloisio), ben venga anche questo, ma addio alla poesia del “scopriamo cosa vuole il cliente/pubblico/elettore/mercato domani con i big data”. Stiamo solo cambiando i componenti del motore, ma la macchina continua ad andare nella direzione sbagliata.
E quindi torno alla mia domanda iniziale.
Chi, in concreto, oggi, in Italia, usa Big Data?
Messa in questi termini, la risposta è scontata: temo che nessuna azienda tradizionale (escludendo dunque startup, ecc) in Italia attualmente impieghi Big Data & co; se è per questo, molte delle tecnologie informatiche che in altri paesi sono ampiamente diffuse, qui da noi sono purtroppo o sconosciute, o (peggio ancora) impiegate in maniera errata/impropria/inutile.
La domanda, secondo me, dovrebbe essere invece riformulata: le aziende italiane dovrebbero utilizzare Big Data, NoSql, ecc.?
per me la risposta è senza esitazioni: SI! e il prima possibile, a prescindere dal fatto che attualmente nessuna azienda abbia raggiunto la “massa critica”, in termini di dimensioni di dati archiviati.
L’approccio NoSql consente di impiegare euristiche di analisi che l’approccio relazionale semplicemente non permette (la differenza è di sostanza, non di grado, altrimenti non ci sarebbe stato bisogno di un “cambio di paradigma”): adottando tale approccio, la mole di dati archiviati aumenterà automaticamente, consentendo di beneficiare dei relativi vantaggi, anche in termini di decisioni aziendali e di business, prese in condizione di incertezza, incompletezza informativa e contesti di mercato in continuo cambiamento;
tali vantaggi sono legati in modo particolare alla possibilità di far emergere in tempo reale tendenze latenti “nascoste” (data driven insights) all’interno del dataset, che altrimenti non emergerebbero, proprio in relazione alla “rigidità” con cui vengono archiviati ed elaborati i dati nei “tradizionali” sistemi di BI (cfr. http://www.capgemini.com/sites/default/files/resource/pdf/The_Deciding_Factor__Big_Data___Decision_Making.pdf).
Alessandro, consentimi di esprimere una certa perplessità.
Togliamo di mezzo le startup e ignoriamo per un momento gli scenari in cui la mole di dati generate da sensori automatici (pensa a dati atmosferici, rilevamento traffico, linee di produzione in ambito industriale, insomma a tutto il mondo che misura la “fisica della material”).
Pensa a un’azienda italiana, grande a piacere, che abbia come riferimento il mercato italiano e non sia nel settore IT e media. Auto, banche, energia elettrica, finanziarie, assicurazioni, manifatturiero, edilizia, alimentare, …. Insomma il grosso dell’economia in Italia (o quello che ne rimane). Qualsiasi cosa, davvero.
Ci sono dei dati che sono acquisiti che oggi buttano via? Quali, per esempio?
O tu intendi trasferire su NoSQL dati che sono già acquisiti su sistemi relazionali?
Nel primo caso, entriamo del merito dei dati che oggi non sono acquisiti e/o tracciati in nessun modo. Perché non sono acquisiti? Perché costerebbe troppo la loro memorizzazione (il supporto del database) o è la loro stessa acquisizione che ha un costo alto? Vorrei ragionare su esempi concreti, entrare nel merito, fare due conti.
Nel secondo caso, io condivido l’osservazione fatta da Vincenzo Aloisio: potenzialmente, tecnologie come Hadoop o simili possono abbassare i costi di un certo segmento della pipeline di un Data Warehouse aziendale. Dipende dale condizioni, si può discutere del come e del quando, ma, appunto, se ne può parlare.
Se invece stiamo dicendo che dovrei trasferire dati che ho già in database strutturati, magari diversi, perché questo abiliterebbe analisi ora non possibili… sono molto perplesso. Quali analisi, esattamente? Quali algoritmi ho a disposizione su un database NoSQL che non sono disponibili su tecnologie relazionali? Parliamone, entriamo nel merito. Annoieremo qualcuno, ma almeno ci chiariamo su cosa si intende con certe definizioni, perché l’incomprensione è dietro l’angolo e l’attribuzione di capacità salvifiche ai Big Data è alquanto pericolosa in un momento in cui gli investimenti devono essere oculati e non ci si può permettere di sbagliare, di allocare nel modo sbagliato le risorse limitate che si hanno a disposizione. Bisogna dare delle priorità agli investimenti e, a mio modesto parere, in Italia non ci sono le condizioni, la cultura, il volume di dati e in ultima analisi la necessità di sposare questa tecnologia nel senso “proprio” (e non come metafora dell’analisi dei dati in generale, a prescindere dallo strumento tecnico). Una tecnologia nuova, pensata per volume enormi, concepita per essere usata da tecnici con elevate competenze, povera di strumenti di sviluppo integrati e sostanzialmente ancora immature se paragonata ad altre molto più consolidate, ma che fondamentalmente, per il mercato italiano, fanno le stesse cose.
Nella conversazione su Twitter, è stato citato questo articolo che chiarisce alcuni aspetti della campagna elettorale di Obama. Hadoop è usato come contenitore, ma l’analisi vera è fatta con Vertica. Che è una tecnologia completamente diversa, che lavora su una sintesi dei dati ottenuti da Hadoop. Ma Vertica è un database colonnare, come ce ne sono altri: QlikView, PowerPivot, Analysis Services Tabular, e molti altri ancora:
http://citoresearch.com/data-science/how-vertica-was-star-obama-campaign-and-other-revelations
Ma non stiamo più parlando di Big Data. Stiamo parlando di tecnologie applicabili a dati che risiedono su Oracle, Excel, Access, SQL Server, MySQL, e un’infinità di altri database relazionali. Quelli che le aziende hanno già, oggi.
Questa è la mia perplessità.
Io, te e pochi altri probabilmente si appassionano a questi discorsi e discutono animatamente di ore per una questione prettamente tecnica che a noi, tutto sommato, diverte pure. Ma il messaggio che passa al di fuori della nostra ristretta cerchia di addetti ai lavori è a suo modo pericoloso: che “Big Data” risolva il problema di chi non ha investito e tuttora non investe in una cultura aziendale di analisi dei dati, di gestione dei processi, di valorizzazione delle informazioni, che vuol dire skill e cultura diffusa anche ai non informatici. Vorrei evitare tutto questo. Capisco che è difficile, capisco la necessità di semplificazione, capisco che “big data” è una bella parola che sta molto bene nei titoli di un articolo e come buzzword in seminari e conferenze. Ma questo messaggio arriva anche a dei decision maker che non hanno le competenze per comprendere tutte le implicazioni e i risvolti di queste tecnologie. Questo messaggio può contribuire a invertire priorità nell’allocazione di risorse limitate.
Se sto guidando un’automobile nella direzione sbagliata, non ho bisogno di fermarmi, aprire il cofano, cambiare una parte del motore, ripartire e continuare ad andare nella direzione sbagliata. Ho bisogno prima di tutto di correggere la rotta, imboccare la direzione giusta. Poi cambierò il motore, alla prima stazione di servizio. Ma prima lì devo arrivarci, non posso correre il rischio di finire il carburante prima di raggiungerla.
La mia riflessione si applica alle aziende che esistono, che sono già in corsa e che si trovano già in una situazione di difficoltà. La loro priorità, oggi, è adottare Hadoop (o un’altra tecnologia Big Data) o cercare di spremere meglio quello che hanno già?
Questa è la domanda che mi faccio, e per ora la risposta che riesco a dare è che se l’azienda non ha ancora una cultura adeguata nell’analisi dei dati, non è un motore in più che gli serve, ma la capacità di iniziare a leggere quello che già hanno.
Ma sono sempre pronto a discuterne e a cambiare idea, di fronte a scenari concreti e misurabili.
Esempio molto concreto, tratto da esperienza professionale diretta, nel campo della IT Security, nell’ambito della prevenzione di attacchi di rete devastanti (quali i DDoS), mediante BigData Analytics: PacketPig (https://github.com/packetloop/packetpig, di cui intendiamo forkare il sorgente, integrandolo con le nostre patches).
Il punto nodale e la domanda che originariamente ci siamo posti è stata: come possiamo intercettare sul nascere un attacco DDoS? in modo particolare: quali “sintomi” dobbiamo rilevare nei file di log e negli stream binari rappresentati dai pacchetti di rete? e poi: quali pacchetti di rete intercettare, e con quale frequenza?
Sono le tipiche domande cui è possibile rispondere solo con un approccio Data driven: è questo il concetto dirimente; se già sapessi cosa analizzare, ricadrei nella tradizionale BI, organizzerei il dataset in DB relazionali, ecc., individuando i metadata opportuni, organizzando le tabelle con le primary keys opportune, e i relativi indici, ecc.,,
Il problema è che tutte queste caratteristiche rilevanti, nel caso dei DDoS, le “scopro solo vivendo”, vale a dire in real time e a run time: ogni volta gli attacchi assumono forma diversa, e quindi ho bisogno di un sistema che “impari” a individuare dei pattern nel flusso di dati nel momento stesso in cui questi si formano!
E non ho bisogno in realtà di accumulare terabytes di dati, prima di poter cominciare ad “imparare”: mediante le reti Bayesiane adattive sono in grado di mettere a sistema l’informazione più recente, aggiornando di conseguenza le distribuzioni di probabilità calcolate/ipotizzate fino a quel momento, sulla base dei dati complessivamente analizzati.
Per poter conseguire tali risultati ho bisogno di:
– un architettura scalabile, vale a dire in grado di poter funzionare correttamente anche (ma non necessariamente) con moli di dati enormi/imprevedibili, comunque crescenti nel tempo;
– poter riorganizzare la struttura del dataset in maniera dinamica, sulla base della semantica (metadata) più appropriata, in relazione a quanto vado progressivamente scoprendo: se infatti dovesse emergere la rilevanza di una caratteristica (leggasi: nuovo metadata) originariamente non considerata (ad es. la lunghezza dei singoli frame) sarei costretto a: riorganizzare le tabelle del DB, ricaricare i dati, rilanciare le query, ricompilare i cubi OLAP, ecc.
Solo adottando l’approccio Big Data (con annessi e connessi, quali NoSql, programmazione funzionale->map reduce, …) sono in grado di conseguire agevolmente la scalabilità e la riorganizzazione dinamica del dataset che mi occorrono;
detto per inciso, la scalabilità consegue dal fatto di adottare i paradigmi della programmazione funzionale (ovvero linguaggi quali Erlang, Scala,…) che per loro natura non sono “lockanti”, in quanto non impiegano accessi in scrittura su locazioni di memoria (variabili) condivise, da parte di flussi differenti (threads) di esecuzione, garantendo di conseguenza il massimo parallelismo computazionale necessario per poter archiviare e CONTEMPORANEAMENTE analizzare i dati nel momento stesso in cui li archivio.
Ovviamente, se anzichè i pacchetti di rete, decido di gestire i click degli utenti sulle pagine web, o i tweet e i vari post dei social media, il discorso non cambia.
Mi rendo conto che, dovendo confrontarsi quotidianamente con realtà organizzative molto carenti, quali quelle cui, ahimè troppo spesso, siamo abituati a vedere, tutti questi discorsi possano apparire “pura accademia”;
in realtà, è proprio adottando un approccio innovativo (sia di prodotto/marketing, che soprattutto di processo organizzativo) che induca a ripensare i modelli organizzativi e di business aziendali, da una parte, consentendo l’acquisizione e la gestione in tempo reale dei feedback di mercato concreti, dall’altra, che possiamo sperare di affrontare, a mio modesto avviso, il delicato momento congiunturale che stiamo vivendo.
Alessandro, l’esempio che hai fatto è un ottimo esempio di uso sensato di tecnologie basate su storage non relazionali e semi-strutturati. Parliamo però, ancora una volta, di tematiche per “addetti ai lavori”.
Ma esiste un esempio riconducibile ad attività produttive, commerciali o di servizi stabilite in Italia e rivolte al mercato italiano dove la priorità di adottare Big Data sia prevalente su altri aspetti?
Facciamo qualche numero e qualche conto. Anche con il clickstream del proprio sito web aziendale in Italia, a chi serve Hadoop?
Nota: a me sta bene usarlo per questo genere di cose, ma se uno ha già un sistema che processa il log del web server, e già memorizza le informazioni estratte su qualche repository, ma magari non li usa, perché devo fargli cambiare motore prima di dargli un volante?
Oppure, se è appagato da Google Analytics, che neanche paga, e magari neanche sfrutta al 100% perché non ha messo ciò che serve nelle pagine per tracciare i returning visitors sugli acquisti, davvero la sua priorità è Big Data per analizzare i dati del sito web?
Se uno prende l’auto per andare alla palestra che è a 400 metri da casa, come personal trainer non gli farei fare 20 minuti a 14km/h solo perché a parole mi dice che è già allenato, se non schiatta, sicuramente non torna alla seconda lezione. Comincerei invece con una camminata a 5-6km/h. Così magari la prossima volta torna a piedi anziché in auto e dopo un paio di mesi corre seriamente. A quel punto, magari, gli dico che può pensare di praticare il percorso di sopravvivenza senza rischiare di cadere nel primo fosso.
Insomma, non è che puoi passare dalle elementari all’università senza passare dalle medie e dalle superiori. E su dove sia posizionata in questa scala di valori la capacità analitica dei dati a disposizione nella realtà italiana (nel privato e nel pubblico), temo abbiamo purtroppo la stessa sensazione.
Ci sono delle eccellenze, per fortuna. Ma sono troppo poche e per quanto possano brillare, non riescono a sostenere la media.
Capisco e in parte condivido le tue perplessità, e purtroppo per risponderti puntualmente, per quanto mi riguarda, dovrei “svelarti” dei dettagli che attengono a iniziative attualmente in fase di startup, che per ovvi motivi di opportunità non posso diffondere al momento, riservandomi ovviamente di esporle successivamente, nel momento in cui si concretizzeranno; debbo pertanto limitarmi a descrizioni concettuali “di massima”; avremo comunque modo di affrontare pubblicamente tali argomenti nel corso delle attività e degli eventi che stiamo organizzando nell’ambito del Working Capital – WCAP Telecom, sede di Roma.
Soluzioni Big Data che siano sostenibili per le aziende “medie” (le nostre PMI, per intenderci) sono ipotizzabili eccome, e intendono proprio risolvere problematiche quotidiane concrete delle aziende, che vanno ad es. dalla logistica, all’introduzione di prodotti e servizi innovativi, esplorando nuovi segmenti di mercati a valore aggiunto.
Il punto è però un altro: come attivare, e costantemente alimentare, in concreto, un “meccanismo” di scoperta del nuovo, nell’ambito delle organizzazioni aziendali che devono confrontarsi quotidianamente con condizioni di mercato imprevedibili e costantemente in cambiamento, consentendo alle aziende di poter decidere anche in condizione di incertezza e incompletezza di informazioni; da qui l’esigenza dei Big Data, che sono sostanzialmente differenti dalla tradizionale BI, proprio perchè consentono di “modellare” l’imprevedibile, in tempo reale;
seguendo la tua metafora, il problema è proprio quello di SCOPRIRE la giusta “rotta” da seguire: in realtà il meccanismo di scoperta è sempre per “trials and errors”: ce lo hanno insegnato scienziati sociali ed economisti quali Popper, Hayek, e in maniera differente Schumpeter;
ciò che fa la differenza, pertanto, è proprio la capacità di organizzare i processi decisionali aziendali in maniera adattiva, permettendo di accorgersi in tempo reale della necessità “di correggere la rotta”.
Per poter fare questo, ho bisogno di gestire in tempo reale i diversi feedback che ricevo dal mercato, dai clienti, dalle mutate condizioni finanziarie, insomma dagli input IMPREVEDIBILI a tempo0, che ricevo volta per volta;
questo oggi me lo consente solo l’approccio Big Data, altrimenti non avrebbe senso neanche starne a parlare;
è chiaro che l’approccio Big Data è esso stesso in continua evoluzione, trattandosi comunque di un settore di ricerca sperimentale;
così come è chiaro che è comunque possibile provare a sfruttare al meglio il tradizionale data mining, la BI, ecc, e che tutto questo non escluda affatto la possibilità di integrare ” il meglio dei due mondi”, come nel caso delle elezioni di Obama;
il punto è che realizzare e alimentare costantemente anche già solo una rudimentale rete bayesiana adattiva è concretamente improponibile per le PMI proprio utilizzando gli strumenti tradizionali: basti solo pensare ai tempi medi di elaborazione richiesti dalle tradizionali procedure ETL; altro che costi sostenibili: occorrerebbero investimenti continui in HW/SW specializzati e ottimizzati, oltre che consulenti introvabili (come se gli esperti SAP o Oracle si trovassero dietro l’angolo, o fossero economici: malgrado ciò, capita sempre più di frequente di trovare soluzioni SAP o Oracle installate all’interno delle aziende…)
Il mio timore è dunque un altro: è chiaro che debbo riorganizzare i processi aziendali per adottare l’approccio Big Data: questo è il vero costo per l’azienda, che si trasforma in investimento solo se si decide di perseguirlo fino in fondo.
D’altronde, qual’è l’alternativa? se le aziende fossero già oggi adeguatamente organizzate, in termini di flessibilità, capacità innovativa, scalabilità dimensionale, supporto IT ecc., e già fossero dotate degli adeguati strumenti di supporto decisionale, probabilmente già oggi affronteremmo la recente crisi economica internazionale in maniera differente…
Beh, non posso commentare quello che non si può conoscere 🙂
Torniamo sull’argomento quando una di queste soluzioni sostenibili per la PMI sarà disponibile e utilizzabile.
…nel frattempo, puoi sempre venirci a trovare al WCAP di Roma, per vedere di persona lo stato dell’arte 😉
Difficile per me essere a Roma prima di agosto-settembre (un po’ troppo all’estero fino ad allora), ma appena sono da qualche cliente in zona, allungo la visita e passo a trovarvi molto volentieri. Magari contattami su http://it.linkedin.com/in/sqlbi/ per scambiarci i riferimenti.
Scusate se abbasso (e di molto) il livello della discussione, con un esempio banale, ma per me significativo.
Poniamo di essere una piccola banca con la sua milionata di clienti attivi (il doppio circa, quelli censiti). Poniamo che il mercato mi “costringa” ad abbracciare l’approccio relazionale, dove la transazione secca perde di valore e il “lifetime” dei miei clienti diventa centrale. Facciamo, poi, che molti di questi clienti sono iperconnessi e di passare in filiale non ne abbiano più tanta voglia (maledetti! :-)); accedono ai miei servizi in mobilità, si informano sulla concorrenza, lasciano tracce più o meno deboli di soddisfazione nei vari social network. Tutte cose che voglio – devo! – intercettare.
Non volendo chiudere battenti, decido di riorganizzare il mio sistema di erogazione in funzione di questo mutato, e dirompente, scenario, dotandomi, tra l’altro, di rinnovati strumenti descrittivi e predittivi. Oltre gli economics classici da controllo di gestione, che dovrò storicizzare massivamente per cercare tendenze, per qualificare il dato mi serviranno gli attributi comportamentali, intercettati su tutti i miei touch points; dati sempre meno strutturati, e non sempre codificati dal personale di contatto, che cambiano repentinamente, e, diciamolo, con rapporto segnale/rumore veramente basso.
Ora, estrarre valore da questo calderone di dati, e trovare il classico cliente biondo, con gli occhi azzurri che brama le mie obbligazioni non è cosa semplice ( a proposito, la cosa “dei pannolini e della birra” è verissima! fidatevi :-)).
Taglio qui, ma potrei aggiungere altri elementi di complessità, come il discorso sui clienti prospect, ad esempio.
Forse, dal punto di vista teorico questo non è uno scenario da big data, ma, imho, gli si assomiglia moltissimo.
Francesco, questo è proprio lo scenario a cui ci si ispira parlando di big data in senso generale. L’elemento centrale è l’interazione con il cliente finale e la necessità di tracciare tutte le azioni del singolo, al fine di poter definire un profilo di comportamento (con tutto quello che ne consegue in termini di personalizzazione del marketing diretto).
Strumenti come Hadoop hanno un ruolo centrale nel semplificare la definizione di uno storage a basso costo per la memorizzazione del dato. Ma la difficoltà credo sia più l’acquisizione dei dati. Le “tracce deboli” di cui parli sono tutte da individuare e la capacità di raccoglierle è la vera sfida. Immagino che questo sia il petrolio di cui dispongono società come Facebook e Twitter, anche se sul come arrivarci c’è una questione aperta. Su Facebook il “LIKE” è la chiave che apre le porte ai dati del singolo utente, ma per quanto i volumi siano alti, non riuscirai mai ad avere dati sulla popolazione. Per contro, Facebook queste informazioni le ha, ma in base a che diritto potrebbe rivenderle? Non ho mai analizzato a fondo le clausole, ma se la profilazione la facesse Facebook e vendesse semplicemente il risultato della stessa, magari in forma anonima? Non so, spesso si fantastica un po’ sulle capacità reali che si hanno oggi di incrociare questi dati, e nella mia esperienza anche i casi più sofisticati sono ben lungi dall’ottenere risultati simili a quelli che si conseguono con l’adozione (per dire) di un processo di CRM (e non solo un software) effettivamente efficace.
Ogni volta che interagisco con la mia banca (o assicurazione, o compagnia aerea, ecc. ecc.) e cade la linea, richiamo e mi risponde un altro operatore, e devo rispiegare quello che ho appena descritto, pur essendomi identificato come cliente fidelizzato e quindi assolutamente tracciabile… mi cadono le braccia e penso che la strada da fare sia ancora lunga. O che l’azienda con cui interagisco sia destinata a chiudere, ma se il sistema la sostiene (leggi, sovvenzioni, monopoli, cartelli, ecc.) manca l’incentivo a innovare.
La mia in fondo è una provocazione, ma il punto di partenza è drammaticamente realistico. Ignorare la mancanza delle condizioni di contorno che consentano di fruire delle potenzialità offerte da strumenti nuovi vanifica l’investimento. Guardiamo in faccia la realtà senza dare subito la colpa ad agenti esterni, terminando l’analisi prematuramente.
Sì, la strada da fare è tanta. Ed è anche stretta.
Se da cliente la situazione è frustrante, ti posso assicurare che vissuta da “dietro le quinte” assume, in certi momenti, toni drammatici. Alla fine della fiera, non è (solo) un problema di complessità tecnologica, ma culturale… una sorta di digital divide cognitivo che impedisce l’adozione dell’innovazione, se non da ritardatari, certamente costretti. Ma non ti devo spiegare nulla, perché so che certe dinamiche le conosci bene.
Lavorando al 90% con l’estero (prevalentemente EU e USA) pur restando residente in Italia, la specificità italiana la vedo ancora più nitidamente, purtroppo.
Francesco. Conosco bene quello che vuoi fare, come sai. Ma grossa parte del problema non deriva dagli strumenti ma dalla scarsa percezione del valore dei dati, e del lavoro che ci sta dietro, da parte delle direzioni. Sì, ci chiedono di estrarre informazioni, ma non si sono mai preoccupati di curarne la qualità e di sostenere i giusti investimenti (soprattutto umani) per poter sfruttare questa ricchezza. Il discorso sugli strumenti viene dopo. E ce ne sono tanti per cui rischi di sbagliarti e sparare alle zanzare con il cannone oppure andare in guerra con la pistola ad acqua.
Marco, avendo il profilo alto che hai (in senso di competenza riconosciuta, sei uno dei grossi nomi nel tuo campo, e non solo in Italia) ti trovi probabilmente a lavorare con aziende di buon livello e competenza. Tu pensa le altre. Le vere PMI, quelle che letteralmente NON HANNO IDEA di quello che si può fare con un umile Excel (per dire lo strumento meno costoso) e quattro neuroni funzionanti. Il loro capocentro sa funzionare benissimo il gestionale e l’infrastruttura ma sulla BI spesso si muove alla cieca. Ho visto cose che voi umani non potreste immaginare..
Adesso sono in Germania, vediamo se qui va meglio.
Massimo, in Germania?! Caspita!
Bisogna che si sentiamo, così ci aggiorniamo un po’.. anche perché qui le cose sono andate avanti ed alcuni passi che ho descritto in quello scenario li abbiamo fatti (DW, CRM). Manca tutta la parte di insight, e tante altre cose.
Ma quanta fatica…
Purtroppo il termine Big Data è troppo generico e crea, probabilmente volutamente, confusione. Leggendo la discussione che si è aperta si nota in modo lampante che c’e’ un groviglio tra tecnologie (RDBMS, NoSQL, CET, Columnar Databases), e modelli (relazionale vs non-relazionale) e necessita (data mining, data exploration, real-time analytics). Non ha quindi molto senso discutere di qualcosa che non ben definito dato che ognuno può avere il proprio punto di vista assolutamente leggittimo e corretto data la mancanza di una definizione puntuale.
E qui sta tutto il clou del discorso. Per come viene presentato il BigData, sembra – ad un tecnico – semplicemente una minestra riscaldata per cercare di vendere quello che in passato non si e’ riuscito o – peggio – si e’ fallito. Un Enterprise Data Warehouse.
Il problema di fondo, pero, e’ che anziché affrontare il problema alla radice, la metodologia e la qualità dei dati, veramente bassa, che ci sono nelle aziende e che rendono molto difficile e dispendiosa la creazione di tali sistemi, si cerca semplicemente di trovare una tecnologia che – si spera – risolva magicamente i suddetti problemi. Purtroppo non è cosi.
Se i dati sono di una qualità infima, non è buttando tutto in un calderone come Hadoop – che è un file system distribuito, non un database – che si risolve il problema. Semplicemente lo si sposta, inventando una figura dal nome altisonante – “Data Scientist” – ma, ahimè, se la direzione è questa, dal lavoro pessimo: cercare oro nella sporcizia.
Per far si che i Big Data possano essere veramente utili, bisogna in primis avere i dati in una buona condizione. Eppure non ho visto nessuno parlare di Master Data Management o Data Quality, che sono gli elementi cardine per far si che un Data Scientist possa fare bene il proprio lavoro, e non diventi, invece, un semplice operaio della nettezza informatica.
Il punto per avere un ecosistema di Big Data maturo è quindi quello di adottare una politica di Data Quality al fine di poter fare in modo che i Big Data non diventi un semplice “ripostiglio di cianfrusaglie dove, forse, c’e’ qualcosa di buono” ma un corretto e coerente sistema di memorizzazione dei dati, scalabilie e poco costoso, dove c’e’ l’oro grezzo dell’azienda e non la pattumiera. Ed in questo scenario il Data Warehouse ne continuera a rappresentare il gioiello finito, l’oro lavorato e trattato.
Questa e’ la visione del Big Data che vorrei si concretizzasse.
Big Data chissà cosa vuol dire,
anche se va tanto di moda.
Cosa sono i Big Data
Big Data è la condizione in cui ti trovi se hai tanti dati, di grande varietà, che si aggiornano con elevata frequenza.
In un mondo governato dall’elettronica le transazioni si susseguono accumulando righe e righe di numeri, di testo e di contenuti multimediali. Se produrre i dati è semplice, aggregarli e dare loro una forma intellegibile è tema sempre più arduo.
Ecco che allora i principali produttori di software ti incentivano ad acquistare costosi server con quantità più che elevate di memoria RAM.
E invece noi no. Con un investimento contenuto sei in grado di gestire i tuoi dati aziendali, anche se ne hai tanti, senza acquistare ulteriore RAM né dotarti di complesse piattaforme integrate hardware-software. Perché la chiave di volta è la semplicità.
Crediamo fermamente che se il software è scritto bene, in modo compatto e senza aggiunte nel tempo di componenti diversi, è semplice farlo dialogare con il tuo PC. Ma voi ci credereste che un software così occupa solo 15 MB di spazio su disco?
Hai volumi di dati consistenti? Non ti preoccupare, e verifica quello che ti occorre veramente. Guarda anche tu come abbiamo risolto i casi più complessi, con Luna Decision.
Luna è Cool Vendor in Analytics, secondo Gartner. E per IDC “offre possibilità di personalizzazione e integrazione, con riduzione del rischio, risparmio di tempo e denaro, ed aumento della qualità”.
Il taglio dimensionale di Luna
Luna si basa su un motore veramente multidimensionale, ed ha in più la possibilità di esplorare tutta la gerarchia dei dati e le loro relazioni. Qual è un esempio di taglio dimensionale che Luna riesce a coprire?
+ Dimensioni di analisi virtualmente illimitate
+ Scrittura e selezione non solo di numeri, ma anche di testo (per inserire i tuoi commenti al Budget) e di elementi multimediali.
+ Write Back anche da Web (cioè hai non solo reportistica, ma un vero e proprio tool collaborativo per scrivere e modificare le tue previsioni).
+ Gestione ottimizzata dell’accesso anche ai dati sparsi (attraverso la gestione non solo multidimensionale e gerarchica, ma anche relazionale).
+ Fruizione dei contenuti via Client e via Web con Html5, con migliaia di accessi contemporanei.
Luna e i grossi volumi di dati
Luna gestisce i grossi volumi di dati, nel senso che consente la navigazione in millisecondi dei dati attraverso le dimensioni e i livelli gerarchici, per tutti gli scopi di monitoraggio e forecasting nei diversi settori aziendali, anche nelle grosse realtà assicurative.
Luna Decision, suite di CPM ovvero di Corporate Performance Management, è stata inserita da Gartner nel Report del Magic Quadrant 2013. E’ affidabile, performante, piace all’IT ed al Business.
Per la prima volta i dati aziendali sono condivisi e permettono simulazioni e forecast. Perché questo è il vero nodo: fare le simulazioni, poter scrivere le tue previsioni al giusto livello gerarchico e utilizzare le spalmature secondo i Driver che vuoi tu.
Parliamo di simulazioni persistenti, che puoi mantenere sul tuo cruscotto e che si affiancano ai dati di consuntivo del gestionale in modo automatico: puoi dimenticare il copia e incolla da file di testo sul tuo foglio di lavoro!
E soprattutto, se lo desideri, puoi fare un cruscotto unico e profilato per la raccolta dei dati dai colleghi e per diffondere i risultati delle tue elaborazioni. Luna. Se lo conosci non puoi farne a meno!
Ma cosa sono le dimensioni, per un software multidimensionale?
Le dimensioni sono i modi di rappresentare il tuo business. Navigare tutti i dati di un nostro “cubo” vuol dire rispondere, tramite semplici Click, a qualsiasi domanda tipo: quale incremento di margine ho avuto a maggio 2013, tra budget e consuntivo, per tutti i prodotti assicurativi del ramo danni venduti a Milano a dirigenti? O in Italia a neolaureati? E quale sarebbe il maggior utile per la filiale francese se aumentasse del 3% il prezzo di acquisto dei soli prodotti importati dal Brasile?
Tanti dei software “rinomati” si bloccano o rallentano già a 5 dimensioni, quelle normalmente utilizzate nel controllo di gestione, per esempio:
1. Dimensione geografica (con tutti i suoi raggruppamenti gerarchici): Cliente, Cap, Comune, Provincia, Regione, Stato, Continente, Mondo.
2. Dimensione commerciale: Subagente, Agente, Distributore, Totale.
3. Dimensione tempo: Ora, Giorno, Mese, Anno.
4. Dimensione prodotto: Prodotto, Categoria, Totale.
5. Dimensione metriche: Ricavo, Costi Commerciali, Margine, Ammortamenti, Redditività, KPI, oltre che qualsiasi voce di bilancio, etc.
Luna arriva oltre, non ha un limite pratico nel numero di dimensioni, ma il cervello umano più di una decina non riesce a concepirle. I casi più complessi (Assicurazione e Abbigliamento) hanno infatti 10-11 dimensioni (a quelle elencate si aggiungono ad esempio: Compagnia, Ramo, Professione Cliente, Fascia di età, piuttosto che le varianti di Taglia e Colore…).
Giusto per rimanere in tema…anche senza i Big Data si capisce che il commento di Giulia Randazzo è SPAM bello e buono 🙂
BIG SPAM 😀
leggendo viene il dubbio (la certezza, in realtà) che la questione di cosa siano/a che cosa servano i Big Data sia antropologica/sociologica invece che ingegneristica
Data la totale assenza di una definizione precisa e rigorosa, hai assolutamente ragione. Come dicevo in precedenza, però, sono convinto che sia una cosa voluta…
Mi aggiungo a questo interessante dibattito. Per presentarmi, ho fondato un paio di anni fa un’azienda, Optimist AI, il cui obiettivo è sviluppare e diffondere applicazioni Big Data a supporto di marketing e vendite.
Sono d’accordo con Marco Russo sul fatto che i Big Data, se intesi come gigantesche quantità di dati, non vi siano in Italia. Però non è una caratteristica italiana, salvo rare eccezioni, non vi sono neanche nel resto del mondo, vedi per es. http://qz.com/81661/most-data-isnt-big-and-businesses-are-wasting-money-pretending-it-is/ .
Ciò su cui sono invece in disaccordo, sono il messaggio dato da Vincenzo Aloisio (benefici = ridotte spese ETL) e lo scollegare i Big data dal Data Mining.
Perché Big Data vuol dire Data Mining
La migliore analisi dei benefici dei Big Data che ho visto finora è stata fatta da McKinsey http://www.mckinsey.com/insights/business_technology/big_data_the_next_frontier_for_innovation .
Gli impatti positivi sull’economia, descritti nell’analisi, passano tutti attraverso l’utilizzo di algoritmi avanzati.
Avere tanti dati di per sé non dà vantaggi. Dare più dati o strumenti più veloci ad un analista può portare un impatto positivo ma fino ad un certo punto. La vera differenza la fanno sistemi in grado di analizzare in automatico i dati e consentire attività nuove come per es. azioni di marketing personalizzate in tempo reale.
Questo poteva già essere fatto prima con tecnologie tradizionali? Non ne sono convinto. Per es., Linkedin ha dichiarato che quando ha introdotto il servizio “People who viewed … also viewed …” poteva far girare l’algoritmo solo una volta a trimestre sul DB di un primario vendor, mentre passando a tecnologie nuove sono riusciti a farlo girare in qualche ora.
Quelli che possono sembrare pochi dati in ambito transazionale, non lo sono quando si utilizzano tecniche di analisi avanzate, per di più se si vuole interagire in tempo reale con il cliente.
Cosa serve per diffondere di più i Big Data in Italia
La mia opinione è che per aumentare l’adozione si debba parlare meno di tecnologie e più di quali nuovi processi di business sono possibili grazie ai Big Data. Vi è indubbiamente una forte resistenza al cambiamento all’interno delle organizzazioni, se non si danno buoni motivi di business per cui vale la pena affrontare il cambiamento perché mai dovrebbero farlo?
Ringrazio De Biase e Russo per aver fatto partire questo utile dibattito.
L’ultimo commento di Alessandro Vitale si allinea con le domande che mi sono venute leggendo questo thread.
Al di la’ della definizione di Big Data o “Small” Data, al di la’ delle strutture che servono per raccogliere o analizzare i dati, quali possono essere i possibili vantaggi per una compagnia? Quali possono essere i motivi di business per cui vale la pena per un azienda affrontare l’argomento?
Nei vari commenti si e’ parlato sia di dati all’interno di un enterprise, sia di dati raccolti in rete che possano essere utili ad un enterprise. Si e’ fatto un accenno ad una banca che puo’ analizzare la percezione che ne possono avere i clienti. O ad una catena di negozi tipo Walmart per predisporre oggetti. E ho sentito anche il caso (anche se non penso rientri nei big data) di Target che manda coupons ai clienti a seconda di quello a cui il cliente puo’ essere interessato, tipo coupons per pannolini ad una famiglia che aspetta un bimbo. Ma sono quelle operazioni che giustificano un tale investimento?
Quali sono i motivi per cui un azienda dovrebbe investire in questo?
Considerando che le aziende in Italia sono molto indietro per cose molto piu’ basilari, tipo e-commerce, considerando che hanno servizi tipo treni italia che sono pietosi, considerando che compagnie tipo l’Alitalia non riescono ad essere competitive, non ci sono altri tipi di “informatizzazione” o approcci ai servizi che dovrebbero affrontare prima di occuparsi di “Big Data”?
Anna, le domande che fai sono tutte molto importanti.
Secondo me i Big Data non sono la panacea che cura tutti i mali. Se un’azienda ha un prodotto che non interessa, non saranno i Big Data a farglielo vendere. Allo stesso modo, se un servizio ha problemi di modello di business, organizzativi, etc. non saranno i Big Data a risolverli.
I Big Data sono prioritari rispetto ad altri investimenti informatici? Dipende dal tipo di business dell’azienda e da quali processi si innovano.
Per essere più concreto, aggiungo un paio di esempi, uno sui negozi e l’altro sui venditori.
Un esempio di Big Data nel retail
Tesco è una catena di supermercati inglese. All’inizio degli anni 90 erano la terza catena in Inghilterra, poi dal 1995 hanno puntato forte sull’analisi dati ed oggi sono i leader, con una quota di mercato doppia rispetto ai secondi.
Ecco un esempio di una delle tante cose che fanno:
– Le vendite dei prodotti (es. insalata, frutta, carne, etc.) cambiano in base alle condizioni atmosferiche (se è più caldo, se piove, etc.). In Tesco analizzano il meteo vicino ai punti vendita ed in base a questo calcolano per ogni punto vendita quali prodotti vanno riassortiti. Questo calcolo, fanno tre volte al giorno su 18.000.000 di prodotti, gli permette di avere maggiore disponibilità a scaffale (-> più vendite) e meno merce buttata o in promozione.
– Nessun sistema è perfetto, di solito hanno comunque un 3% di prodotti freschi che rischia di scadere. Per questi, con un altro sistema capiscono quanto velocemente una promozione farà vendere un prodotto e modificano il prezzo all’ultimo momento utile.
Hanno così realizzato un impatto positivo di business (30 Milioni di Sterline di profitto in più) ed un impatto positivo sociale (meno cibo buttato via).
Un altro esempio di Big Data, stavolta nella forza vendita
Schwan Food è un’azienda che produce cibo surgelato. Ha una rete di venditori con furgoncino che fa tentata vendita a negozi, famiglie, ristoranti e bar.
Il loro fatturato stava calando da 4 anni.
Hanno introdotto un sistema intelligente che individua, per ogni cliente, quali prodotti acquisterebbe con maggior probabilità.
Ogni giorno inviano questa lista di prodotti suggeriti aggiornata ai venditori, il venditore ha così uno spunto commerciale in più durante la visita. Grazie a questo sistema, dopo 4 anni di fatturato in calo, sono tornati a crescere del 3-4%.
Se i Big Data sono una priorità secondo me dipende dall’azienda e da quali processi di business si vanno ad innovare. Questi esempi per me sono dei casi in cui ha senso investire, che ne pensi?
Io spero che questa buzzwordfilia, che porta a rilanciare parole d’ordine ogni tre o quattro anni, sia finalmente superata per poter vedere i problemi veri. Big o Small i data sono importanti. Può darsi che siano così tanti che sembri impossibile gestirli, in questo caso hadoop & C consentono di affrontarli. Ma è raro. Nel contempo si fa fatica a comprare online un biglietto del treno, che dovrebbe essere un problema risolto da 15 anni. Oppure la banca telefona a mia madre per il mio conto corrente (non sa che è il mio, come fa a analizzare il mio comportamento con algoritmi di data mining?). Ci sono case abusive (le case non si muovono, come fa lo stato a non sapere che sono lì?). Le società fanno giochetti con le rimanenze di magazzino per far tornare il bilancio in attivo (sono costrette, altrimenti le banche tagliano il fido). In pratica rendono inutilizzabili dati importantissimi. Non continuo perché ci siamo capiti. Il primo passo è il RISPETTO per i dati. Sono un asset deperibile che viene sistematicamente lasciato andare a male.
Mi fa piacere vedere che il discorso continua con nuovi interlocutori.
Personalmente sono contento che “Big Data” stimoli la discussione e solleciti l’attenzione verso la centralità dei dati. Amazon fa Data Mining in “real time” da sempre e basterebbe copiarli. Vogliamo rinominare Data Mining in Big Data? Perfetto. Però se uno A) non ha i dati B) non ha gli algoritmi C) non ha le persone in grado di leggere i dati e maneggiar gli algoritmi (un bel data scientist?) rischia di fare come a Palermo, dove hanno comprato i tram prima di avere i binari.
E’ una questione di priorità. A risorse infinite, Big Data per tutti, a prescindere (così anche io da consulente mi diverto), ma a risorse limitate qualche priorità bisogna darla e suggerire a chi non è in grado di sapere quale è il costo dei prodotti che vende di adottare Big Data (qualsiasi cosa voglia dire) mi pare una scorretta allocazione delle (scarse) risorse.
Quindi, anche in italia, direi, ne abbiamo bisogno, forse più che altrove, visto che non siamo tanto spesso ordinati e organizzati quanto dovremmo.
Grazie Alessandro per gli esempi.
Quindi ci sono anche in Italia compagnie che gia’ oggi potrebbero usufruire delle technologie big data, come IperCoop per stare in tema di catene di negozi.
Sicuramente i dati devono assumere una parte centrale.
Insieme ai dati, big or small, io metterei come importante anche la centralita’ degli utenti, che alla fin fine e’ sempre centralita’ dei dati, magari raccolti in modo diversi, a piu’ attenzione a come sono forniti i servizi. E’ triste vedere come la carta regionale dei servizi sia fallita, chissa se hanno raccolto dati per sapere come mai e’ fallita, o se non hanno fatto niente per migliorare i servizi e renderli usabili effettivamente.
Ciao Marco, aggiungerei un altro punto alla tua lista, oltre ai Data Scientist D) persone con competenze su questo tipo di infrastrutture. Le persone con esperienza su Hadoop sono scarse in Silicon Valley dove è stato inventato, quante ve ne saranno in Italia? (se qualcuno ha opinioni o evidenze differenti mi piacerebbe sentirle)
Secondo me, il modello di progetto classico (compro hw e sw, faccio le integrazioni, sviluppo applicazioni custom, gestisco il tutto in produzione internamente) non va bene per queste soluzioni. In primis perché, per quanto detto, non ci sono in giro sufficienti competenze per farlo. Poi perché in questa congiuntura vedo difficile fare progetti lunghi e con un forte investimento iniziale.
C’è un’altra via.
Come dice IDC, http://www.datanami.com/datanami/2013-05-10/can_cloud_bridge_the_big_data_talent_gap_.html , la diffusione di questi sistemi avverrà tramite applicazioni cloud che daranno direttamente le risposte alle domande di business.
Già molte aziende utilizzano un CRM in cloud (Es. Salesforce.com). Immagina per esempio di poter affiancare un altro servizio in cloud che per ogni cliente dà informazioni su cosa proporgli, senza doversi costruire la soluzione in casa con competenze che non ci sono sul mercato. Con un modello così accessibile, quante aziende in più potrebbero beneficiarne?
Io vi credo fortemente, tanto da aver fondato un’azienda per farlo.
Bigdata è una buzzword. Ce ne sono tante.
Il significato glielo si appiccica man mano che la si usa.
Come la parola “rete”, come la parola “ipertesto”, come la parola “social”.
Usare queste parole crea piano piano il loro significato, che gli si arrotola attorno, come al bastoncino dello zucchero filato, al passare del tempo, al crescere delle rotazioni.
Il fatto è che i dati crescono.
Oggi mandiamo email che una volta non sarebbero state in un disco fisso.
Nonostante questo,
Non abbiamo decenti sistemi per cercare in un filesystem locale o di rete.
Non abbiamo decenti sistemi per cercare nelle vecchie email.
Non abbiamo decenti sistemi per cercare nelle nostre vecchie telefonate.
Non abbiamo decenti sistemi per trovare una cosa che abbiamo letto in un sito da qualche parte la settimana scorsa.
Non abbiamo decenti sistemi per cercare quella foto, tra le tante che abbiamo scattato.
Non sappiamo come cercare cosa c’era scritto nel giornate di un anno fa.
Diventiamo sempre più google-dipendenti, ma cercare con google purtroppo cerca solo nella crosta e non scava nel contenuto.
Buttiamo via dati dalla mattina alla sera (dove vanno a finire i flussi di coscienza delle nostre chat?). E buttiamo via associazioni tra dati, che creiamo, e che non riusciamo a trattenere.
Non vi capita mai di dire “accidenti, avevo questa informazione, ma non so se era in una chat di skype, in una mail di lavoro, in una mail privata, su evernote, in un appunto su dropbox, o forse sulle note dell’iPad?”.
Ci servirebbe conservarli, quei dati e quelle relazioni, a patto di poterli usare quando serve.
Per questo -estendendo dal contesto personale- servono i bigdata, o comunque li vogliamo chiamare: strumenti più potenti per associare dati a contesti, per indicizzare, etichettare, riconoscere, ricercare.
La Business Intelligence è per dati strutturati, per numeri che sono già incolonnati, che hanno unità di misura, istanti di campionamento, modalità di interpretazione già ben chiari. Si naviga tra questi facendo domande che affettano e che definiscono il campo in modo oggettivo e chiaro.
Per il resto, che è caotico, che è sporco, che è umano, che è fuzzy, che è in parte statistica, occorrono modalità nuove, di archiviazione, di organizzazione, di ricerca.
Non è questione di terabyte o di gigabyte: è che non dobbiamo sprecare tempo a cercare senza trovare. E’ importante poter cercare nel cassonetto dei ricordi, o nelle vecchie email, o nella cartella “varie”, sperando di trovare.
Quindi, anche in italia, direi, ne abbiamo bisogno, forse più che altrove, visto che non siamo tanto spesso ordinati e organizzati quanto dovremmo.
A proposito, quante volte avete tentato di perseguire la “inbox zero”?
Io, in questo, sono un disastro.
@mgua
Marco, consentimi di essere molto scettico.
Big Data non può essere una scorciatoia per chi non ha fatto i compiti a casa. Non diamo questa falsa illusione, perché questo è.
Si può non essere vittima dei dati che crescono, cercando di non esserne sopraffatti. Ma non è realistico pensare che esista la bacchetta magica che risolve tutte le carenze organizzative e di gestione della conoscenza di cui si può soffrire. Questa è esattamente l’illusione che alcuni gonfiano e che vorrei contrastare con ogni mezzo. Un bel bagno di realtà.
PS: Uso zero inbox nonostante riceva 200+ mail al giorno e ne invii circa 50-60 in media. Ci riesco con Outlook + SimplyFile + un uso appropriato di Snooze. Ed è il motivo per cui non riesco a sfruttare fino in fondo Tablet e altri device che non forniscono le funzionalità di cui ho bisogno.
Leggendo i vari commenti che si sono aggiunti sembra che Big Data venga sempre associato al Data Mining ed ad Hadoop. Ed anche ad una certa economicita rispetto a soluzioni classiche. Secondo me – e dalla mia esperienza sul campo – non e’ cosi. In primis il concetto di Big Data, se vogliamo stare a quanto e’ comunemente condiviso, necessita delle famose “4V”: Volume, Velocity, Variety, Variability. E quindi questo non limita lo scenario al solo Data Mining ma, anzi, proprio non lo cita. Big Data e’ sopratutto (solo?) la memorizzazione di grandi quantita di dati. Certo, il problema e’ definire “grande”. Per quanto riguarda il Data Mining, questo al massimo e’ – o sara – un uso tipico dei Big Data. Ma sono due cose ben diverse, ed il Data Mining e’ sul mercato da parecchio tempo (basti citare SAS e SPSS). Detto cio, la cosa IMHO interessante e’ che le quattro caratteristiche citate possono essere senza alcun dubbio ottenute con sistemi tradizionali. Ma forse costano troppo, rispetto a soluzioni alternative, come Hadoop? La sensazione e’ quella ma se andiamo realmente a chiedere ai varu vendor come ci vendono la soluzione Big Data, da IBM a EMC la proposta sono una serie di appliance che sono tutt’altro che economiche. Certo, si puo fare tutto a gratis sulla carta, ma a meno di non avere personale altamente specializzato (alla Facebook, Twitter, eBay o Amazon, che se lo possono permettere) in casa e’ uno strada non percorribile, vista l’altissima complessita degli strumenti attuali. Se avete provato ad usare Hadoop nella sua versione nativa (quella gratuita), il setup e l’installazione sembra una cosa da smanettoni in un box. Ed io credo che ci dobbiamo muovere da questa visione dell’informatica.
Mi faccio quindi una domanda un po provocatoria…ma non troppo. Se avete notato le societa produttrici di Hardware si sono buttate a pesce sui Big Data. Mi sono chiesto il perche’ e quello che maliziosamente mi e’ venuto in mente e’ che i Big Data cercano di risolvere il problema dello storage e dell’analisi dei dati con la forza bruta, permettendo di buttare hardware a piacimento nella mischia, fornendo cosi sempre piu forza bruta. A voler pensar male Hadoop fornisce un’ottima leva per vedere sempre piu hardware….non trovate?
Mi chiedo se investendo le stesse risorse in formazione sui soluzioni gia esistenti non si possa ottenere la stessa cosa. Ma a chi interessa?
PS
A parte la provocazione finale sono cmq ben contento dell’avvento dei Big Data perche’ sta scuotendo il mondo dei DB classici che ormai si era un po assopito ed aveva bisogna di un po di sana concorrenza.
Big Data NON è hadoop.
Big Data NON è NoSql.
Mi piace molto la definizione riportata in wikipedia: “il termine indica grandi aggregazioni di dati, la cui grandezza e complessità richiede strumenti più avanzati rispetto a quelli tradizionali, in tutte le fasi del processo (dalla gestione, alla curation, passando per condivisione, analisi e visualizzazione)”
Stando a questa definizione il CIO non ha potere decisionale, nel senso che se la azienda in cui lavora ha tanti dati da archiviare e da elaborare, allora per forza di cose DEVE utilizzare Big Data! Punto.
Ve lo immaginate il CIO di twitter che dice: “Questo big data non mi piace affatto, cancelliamo gli utenti che postano troppo così risparmiamo qualche terabyte.”
Suvvia, sono questioni tecniche, i manager dovrebbero avere il buon gusto di starne fuori e lasciar lavorare i tecnici in pace.
[…] Vedi anche: Small, medium, big data Esistono i big data in Italia? Sì esistono […]
Spero di vedere il nostro sito di facoltà, grazie in anticipo
http://www.fmed.bu.edu.eg/
http://www.fmed.bu.edu.eg/fmed/index.php/home
http://www.fmed.bu.edu.eg/fmed/index.php/studentsunion
http://www.fmed.bu.edu.eg/fmed/index.php/youth-welfare
http://www.fmed.bu.edu.eg/fmed/index.php/another-services
http://www.fmed.bu.edu.eg/fmed/index.php/statistical-analysis
http://www.fmed.bu.edu.eg/fmed/index.php/post-graduates
http://www.fmed.bu.edu.eg/fmed/index.php/statistical-analysis
http://www.fmed.bu.edu.eg/fmed/index.php/registration-requirements
http://www.fmed.bu.edu.eg/fmed/index.php/2013-05-12-11-09-23
[…] Italia mentre anche si discute se esistano o meno i Big Data nostrani uno studio Bocconi commissionato dall’IBM dice che “il 57% delle imprese è […]