Il primo punto fondamentale, d’avere sempre presente nell’impostazione delle operazioni come nella loro esecuzione, è che la natura di un progetto Smart Data non è tecnologica ma di business, nel senso che il suo scopo ultimo è quello di porre l’impresa in grado di cogliere delle opportunità di business. Se ciò avverrà tramite una soluzione funzionale ed efficiente, tanto meglio; ma si tratterà, per così dire, di un “effetto laterale”: desiderabile ma non tale da influenzare né tanto meno prevalere sulla rispondenza del progetto ai fini delle strategie aziendali. Avendo questo chiaro in mente, si consiglia di avviare il progetto secondo quattro percorsi generali:
1. Definizione del business case; per identificare in modo chiaro gli obiettivi in grado di portare valore e, importante, dei criteri da adottare per misurare il valore creato.
2. Project planning; per definire un percorso graduale che porti a realizzare con successo gli obiettivi progettuali di cui al punto 1.
3. Analisi dei requisiti tecnologici; per essere certi di raccogliere i dati che occorrono e di gestirli nel modo necessario a raggiungere gli obiettivi che portano valore di business.
4. Assessment e implementazione; per verificare che il percorso di cui al punto 2 sia coerente ai valori di business e ai requisiti di cui ai punti 1 e 3 e, soprattutto, che obiettivi e risultati restino allineati, misurando gli effetti del progetto Smart Data sulle variabili di business.
Prima di esporre in dettaglio queste quattro linee-guida, a senso avviare un progetto di Smart Data con un approccio ‘start small’, ossia, identificando un business case ben preciso e limitato sul quale costruire un progetto che possa dare risultati concreti entro breve tempo (idealmente, 30 giorni) e fungere quindi da ‘proof of concept’ per una successiva espansione, da attuarsi analizzando nuovi business case come dal punto 1 e ripetendo su di questi le azioni dei punti 2, 3 e 4.
Definizione del business case.
Il punto più importante da considerare nello sviluppo di un progetto Smart Data è, come ovvio, definire l’obiettivo di business desiderato, che può variare parecchio a seconda del tipo d’industria e di azienda, del rapporto tra questa e il mercato (dimensione, posizione, dinamica evolutiva e così via) e di altri fattori. Obiettivi molto comuni sono l’incremento delle vendite dato da una migliore customer satisfaction e la riduzione dei costi operativi data da un’esecuzione più efficiente dei processi, ma, ripetiamo, ogni realtà ha una sua storia.
Per meglio definire il business case cui applicarsi è utile rispondere ad alcune domande.
– Quali sono gli obiettivi del progetto? – Bisogna: 1) identificare le aree applicative (Erp, Crm, marketing, finance, sicurezza…) coinvolte dal progetto e i processi di business oggi in atto che ne verranno influenzati; 2) identificare le necessità delle applicazioni e chiarire come si potranno soddisfare; 3) identificare gli obiettivi di business in termini di valori ben misurabili ed assegnarvi un ordine di priorità.
– Perché gli strumenti attuali non sono adeguati? – Bisogna elencare i limiti e gli svantaggi delle soluzioni in atto e, soprattutto, documentare gli ostacoli, di tipo sia organizzativo sia tecnologico, che ne frenano un miglior uso ai fini del business.
– Quali sono le figure-chiave? – Si tratta di: 1) identificare le persone in azienda interessate dal progetto (project team, responsabili di processo, utenti…) definendone ruoli, skill e aspettative; 2) stabilire chi può fare da sponsor tecnico, chi da sponsor aziendale e chi da ‘evangelista’; 3) definire l’esatta composizione del team di progetto (tipo: project manager, application analyst, data analyst, software engineer, knowledge engineer…)
– Vi sono altri progetti Big Data che riguardano queste persone? – Se sì, bisogna indagare a fondo e documentarsi sugli aspetti positivi e negativi di ogni caso che sia già in atto.
– Come misurare il successo? – Come già detto, si tratta di trovare dei criteri di valutazione che siano misurabili e documentabili in funzione degli obiettivi di business cercati (vedi dettaglio più sotto).
Project planning.
Stabilito lo scopo generale del progetto, occorre entrare in dettaglio definendo obiettivi di business specifici per i vari tipi di utente indirizzati (analista, knowledge worker, end-user) e degli indicatori prestazionali (KPI) che vi siano collegati e diano la misura dei risultati ottenuti.
Riguardo a questi ultimi, si tratta di trovare delle variabili di business utili a valutare il successo di un progetto nel breve come nel lungo termine. Per esempio, delle metriche che danno valori tangibili di business per diversi tipi di utente sono il “time to insight”, cioè la riduzione del tempo che occorre a un manager per fare una scelta basata sui dati, o il tempo (come misura dello sforzo) che occorre a un utente business per saper sfruttare una nuova applicazione. Va inoltre stimato il costo della soluzione in modo da prevederne il ROI, il che servirà anche a valutare il budget disponibile e gli elementi che lo possono influenzare nel breve e nel lungo termine.
Si stenderanno quindi i diagrammi di Gantt per i vari passi del progetto, con la definizione degli obiettivi di breve e lungo termine e dei tempi necessari ai cicli iterativi che portano ai primi risultati. Si potranno poi identificare e documentare i passi da fare per espandere il progetto (reiterando i casi esistenti o trovandone di nuovi che diano valore di business) e definire i tempi necessari al completamento di ogni singolo passo del progetto stesso.
Analisi dei requisiti tecnologici
Perché un progetto Smart Data abbia successo occorre avere una chiara comprensione dell’ecosistema digitale nel quale si colloca. Questo è formato dai sistemi legacy e dai tool in uso, dalle basi dati e sistemi di information management e dalle applicazioni di BI. A ciò si sommano le fonti dati esterne (pubbliche o a pagamento) utili per arricchire il patrimonio informativo sul quale condurre le analisi necessarie al business e i sistemi e applicazioni che convenga integrare nella propria infrastruttura d’information management.
In generale, i progetti Smart Data si possono dividere in due categorie: quelli focalizzati su volume e velocità, per analizzare grandi masse di dati strutturati, e quelli dove il focus è su varietà e complessità, dove si punta a integrare dati ricavati da fonti non strutturate ed eterogenee (dalle e-mail al web) per trarne informazioni. In entrambi i casi, per analizzare i requisiti tecnici occorre rispondere alle seguenti quattro domande.
- Qual è l’attuale infrastruttura tecnologica del sistema informativo? Si tratta d’identificare gli strumenti, i sistemi e le applicazioni disponibili e schematizzarne, anche graficamente, l’architettura, cioè il modo in cui sono organizzati, per capire quali connettori occorrano per potervi interagire. Quindi confrontare tale architettura con tutte le fonti dati (transazionali, web e quant’altro) per capire quali strumenti di estrazione e raccolta siano necessari.
- Quali sono le fonti dati rilevanti? Si tratta di scegliere le fonti dati che possono tornare utili al progetto considerando il tipo dei dati (es: Xml, Sql, binario, testo…), il tipo di input (es: Http, stream, batch upload…) e le modalità di accesso alle fonti esterne, come eventuali firewall, data masking e così via. Bisogna anche sapere chi ha la ownership dei nuovi dati, come legarli a quelli esistenti e se le policy sui dati sensibili o personali permettono l’uso di ambienti cloud pubblico. Infine, ovviamente, bisognerà stimare il volume informativo che si prevede di analizzare (in dati per unità di tempo) in modo da dimensionare le tecnologie correlate.
- Quali sono gli elementi di conoscenza rilevanti? Esaminando le fonti dati di cui sopra, si devono identificare gli elementi (attributi, entità, oggetti, concetti…) che hanno valore rispetto agli obiettivi di business. Quindi si devono stilare le regole e i processi perchè tali elementi vengano acquisiti, estratti e normalizzati.
- Quali aspetti di applicazioni e Smart Data considerare per il business case? Definita la struttura degli Smart Data più adatta agli obiettivi di business, bisogna descrivere i servizi applicativi necessari per disegnare il workflow dei processi. Gli aspetti da considerare e definire sono molti. Si va dalla scelta del deployment (on-premise, cloud ibrido, cloud pubblico…) con eventuale ricorso a un cloud provider, alla scelta del Data Store (NoSQL/Hadoop, SQL, Cassandra…). Va previsto il carico di lavoro (se I/O intensivo o CPU intensivo, ricordando che il time-to-insight vale di più del time-per-query) e valutata la possibilità d’interfacciare applicazioni di data mining, visualizzazione, collaborazione o altro che potenzino il progetto. Va stimato il costo di manutenzione del software così come vanno stimate le doti del personale e, se del caso, il costo di una formazione.
Assessment e implementazione
Siamo finalmente alla fase di realizzazione di un progetto oramai chiaro e definito, per la realizzazione del quale si sta diffondendo l’adozione, per lo sviluppo software, del modello SCRUM, il framework agile, iterativo e incrementale basato sugli “sprint” (stadi di lavoro i cui tempi e obiettivi sono volta per volta predefiniti), occorre ancora rispondere a poche domande.
– Quali sono gli elementi di conoscenza da modellare? Si tratta di definire gli sprint relativi all’estrazione e normalizzazione dei dati e i connettori che ne abilitano l’accesso e la manipolazione ai fini del business case. Quindi di eseguirli secondo il piano.
– Quali sono i workflow da progettare? I flussi di lavoro vanno previsti considerando le applicazioni e servizi necessri all’acquisizione dei dati, alla loro normalizzazione e integrazione e infine all’analisi (cubi multidimensionali) e visualizzazione. I flussi così definiti vanno poi testati e quindi tradotti negli sprint SCRUM da realizzare.
Restano quindi solo da definire le variabili di business sulle quali calibrare i KPI e, ultimo passo, gli elementi che vanno a comporre sia il costo operativo del progetto sia il valore atteso per il business in modo da calcolare il ritorno dell’investimento.
