Come creare una data strategy efficace

Gestire la strategia aziendale non si limita solo alla cultura, ai ruoli e alle interazioni tra questi, ma richiede competenze relative alla tecnologia a disposizione per poterla sfruttare per il business e per prendere decisioni [...]
Elia Bellussi

ICT e Innovazione

data strategy
  1. Home
  2. Big Data
  3. Come creare una data strategy efficace

La quarta rivoluzione industriale sta cambiando i nostri stili di vita; dal lato business, vediamo quanto sia utile per le aziende pensare a una data strategy e come essa influenzi la loro cultura.

Alla luce dei recenti accadimenti, risulta ancora più utile e importante aver ben chiara una strategia ma vediamo quali siano le variabili da tenere in conto per far sì che sia il più possibile efficace.

Le tipologie organizzative

Sia che l’azienda fornisca prodotti o servizi legati esplicitamente ai dati, sia che l’azienda sia focalizzata su altre tematiche, c’è un sempre più evidente bisogno di una componente aziendale che si occupi di come gestire e di come applicare i dati al proprio business.

Verrebbe da pensare che un’azienda debba avere un’organizzazione centralizzata per poter delineare e pianificare le proprie attività, in relazione alla strategia aziendale sull’uso dei dati. In questo caso ci sarebbe un controllo consapevole proveniente dall’alto, ossia da ruoli apicali, che sicuramente hanno una visione complessiva e a lungo termine.

L’ente centralizzante sarebbe uno e si dovrebbe occupare della strategia aziendale e dell’analisi dei dati, andando a coprire necessità come la data governance, l’elaborazione e la realizzazione di prodotti basati di essi. Questo comporta che il reparto dell’azienda che ha in carico quest’iniziativa è l’organizzazione responsabile della valutazione e della comprensione di tutte le parti interessate. Le unità, o meglio, i dipartimenti aziendali, come il dipartimento afferente al marketing o il dipartimento relativo al supporto al cliente o le singole business unit che realizzano il prodotto o il servizio, forniscono all’organizzazione che si occuperà dell’analisi, i requisiti chiave, per cui nessun altro reparto si occuperà di queste attività.

Questo comporta una coordinazione migliore nelle scelte e nelle attività, una visione a livello aziendale e non di reparto, nonché una priorità oggettiva, data dal management. Tutti fattori che influenzano positivamente la gestione della strategia aziendale, portando a una riduzione dei costi. D’altro canto vengono a crearsi fattori negativi come la mancanza di contesto aziendale o capacità di raccontare storie – storytelling – inerenti alle soluzioni proposte e alle problematiche da risolvere. Inoltre, gli ostacoli organizzativi rallentano l’adozione di nuove fonti, la corretta scelta dei dati e la tempestività dell’analisi così come vi è una mancanza di capacità di fornire raccomandazioni precise o correlate su più ambiti. Il che implica una minore efficacia e, quindi, margini di profitto minori.

Da questa premessa si evince che si potrebbe pensare alla soluzione opposta, ovvero una totale decentralizzazione organizzativa, così da poter essere più dinamici e da risolvere le problematiche riscontrate con l’organizzazione centralizzata.

Cosa avviene in questo caso? Avremo una divisione in dipartimenti, come abbiamo visto prima, ad esempio quello di marketing, quello inerente al supporto al cliente e le varie business unit che sviluppano i prodotti o i servizi. Ogni dipartimento si occuperà di definire e gestire il proprio team di analisti e la propria strategia dei dati. Gli analisti si concentrano, quindi, sulle esigenze chiave del team, fornendo approfondimenti relativi alle singole analisi.

Avremo quindi una narrativa consona al team, dettagliata e chiara rispetto alle necessità; inoltre, avremo il rispetto del contesto aziendale, legato al gruppo di lavoro, e tempestività nell’utilizzo dei dati poiché direttamente fruibili dal team stesso. Questo comporterebbe una maggiore efficacia con possibili aumenti relativi al margine di profitto.

Al contrario, gli analisti costituiscono i cosiddetti silos, ovvero entità chiuse che non sono in relazione con altri reparti. In questo caso viene a mancare la condivisione dei dati e delle analisi, portando a una probabile ridondanza per ogni reparto con la probabile replicazione delle infrastrutture tecnologiche e dell’analisi. Non avendo alcuna strategia dei dati centralizzata o che rispetti un’analisi a livello aziendale, probabilmente si perde una visione più ampia e alta, a livello corporate, il che implica possibili conflitti interni creando difficoltà nella realizzazione di prodotti basati sui dati o su flussi di entrata indipendenti. Inoltre avremo maggiori costi strutturali, legati alla replicazione delle infrastrutture ma anche legati alla ridondante analisi dei dati stessi, da parte di più team.

Comprendiamo che entrambe le soluzioni non sono ottimali, ma come potremmo fare a risolvere questa problematica?

Una organizzazione ibrida

Ci viene in supporto una organizzazione ibrida, ovvero andremo ad avere un ente centrale che si occuperà dell’analisi a livello corporate, il che vuol dire che esso gestirà la strategia e l’analisi dei dati aziendali e ad esso faranno capo gli analisti dei vari dipartimenti.

In questo caso abbiamo come risultato il meglio delle due tipologie e uno scambio coordinato di informazioni tra gli analisti, così da non essere ridondanti e da ottimizzare la produzione di analisi. Questo comporta una riduzione dei costi infrastrutturali e un incremento dell’efficacia con un probabile margine di profitto maggiore.

Al contrario si creerà una costante tensione con le parti interessate, nel contesto delle aspettative, e ci saranno spese operative da gestire propriamente. Ad esempio i vari business unit manager non saranno favorevoli a condividere ore lavoro dei propri collaboratori, poiché queste potrebbero essere rivolte ad attività interne al reparto e poiché queste andranno in carico, al proprio bilancio e non a un bilancio centralizzato.

WHITEPAPER
Ricerca IDC: come aggregare i dati per un'analisi ottimale
Big Data
Business Analytics

Abbiamo visto diverse tipologie gestionali con i pro e i contro rispettivi ma, in definitiva, chi credete sia il responsabile a livello corporate della data strategy? Il CEO, che deve indicare all’azienda la strada; il CFO che chiarisce quali siano le disponibilità economiche; il CMO che deve comprendere il mercato e dare una guida in tal senso; il CTO che conosce le tecnologie usate per la data strategy; il CIO, che ha ben chiaro l’importanza delle informazioni; il COO, che ha ben chiaro come vada organizzata l’azienda o, ad esempio il vice presidente a capo del reparto di ingegneri dedicati alle attività relative?

C’è una figura in particolare, propria delle aziende corporate ed è quella del CDO, ovvero del chief data officer. Il suo ruolo è quello di comprendere sia le opportunità di business sia le varie problematiche relative ai dati e al loro uso, sia quali tecnologie possono aiutare l’azienda nell’implementazione di una strategia di questo tipo. Il suo ruolo sarà quello di coordinarsi con gli altri membri del c-level.

I ruoli aziendali

Una volta compresa quale struttura darsi a livello aziendale, per poter realizzare e sfruttare al meglio la strategia relativa ai dati, si deve aver ben chiaro quali siano i ruoli tecnici necessari per poterla implementare e per fornire i risultati.

Spesso si parla di data engineer o di data analyst ma ci si confonde sul reale ruolo ricoperto da queste figure. C’è una gran mancanza di chiarezza, per cui si confonde lo sviluppatore, l’architetto infrastrutturale o colui che deve fare analisi e questo capita non solo per le startup, che hanno bisogno di avere figure miste ma anche nelle aziende corporate.

In realtà esistono più ruoli, alcuni con termini gergali ben definiti. Avremo, pertanto, figure che vanno dalla data governance, alla realizzazione tecnica della piattaforma di acquisizione dei dati, all’elaborazione e all’analisi degli stessi.

Vediamo in dettaglio quali siano queste figure. In questo caso, cercherò di spiegare nel modo più semplice possibile i termini tecnici relativi alle varie attività.

Partiamo, prima di tutto, però, dalle competenze che andremo a ricercare per ricoprire tali ruoli. In base al ruolo e in quantità diversa, le competenze saranno relative al business, all’analisi, all’informatica, alla statistica e matematica e, infine, alla creatività.

Perché queste competenze? Per poter propriamente svolgere il lavoro poiché, ad esempio, chi si occupa dell’infrastruttura dovrà avere competenze informatiche ma anche di analisi e di creatività per poter risolvere le problematiche relative; chi si occuperà di elaborare i dati dovrà avere competenze sia informatiche, sia matematiche e statistiche, sia di creatività, mentre chi si occuperà dell’analisi per il business dovrà avere competenze relative al business, appunto, di creatività, statistiche e matematiche e di analisi.

Quali sono, quindi, i ruoli da tenere in considerazione per poter svolgere le attività legate alla strategia aziendale?

Abbiamo il data producer, che non è un vero ruolo tecnico ma che rende chiara l’idea che ci dev’essere qualcuno legato alla fonte dei dati; il platform engineer; il data engineer; il data scientist; il citizen data scientist; il data analyst e il business analyst. Infine avremo un ruolo legato alla data governance che avrà visibilità su ogni ruolo sopra menzionato.

Come scritto poco sopra, il primo si occuperà di selezionare e gestire le fonti di dati che andranno a popolare la nostra collezione. Queste fonti possono essere database, sistemi IoT e altre. Il data producer sceglierà le fonti dati e creerà le condizioni per cui si possano acquisire i dati da esse. Ma come verranno importati questi dati? Questi dati verranno acquisiti grazie a scelte fatte dal platform engineer, che andrà a disegnare gli ETL o gli ELT, ovvero il sistema di acquisizione dei dati che, nel primo caso agisce estraendo i dati dalla fonte, trasformandoli e caricandoli sul sistema; nel secondo caso, invece, gli estrae, li carica e successivamente li trasforma.

Tra il primo stadio e il secondo si rende necessaria una costante attività di allineamento e di controllo. In particolare, per aziende corporate, è necessario che ci sia un preciso flusso di change così da tracciare ogni variazione sia delle fonti, sia di accesso ad esse, sia di formati dei dati da esse esposti in modo da avere un costante e stabile utilizzo.

A questo punto entra in gioco il data engineer che si occuperà di gestire il data warehouse, ovvero il sistema di archiviazione dei dati afferenti alla nostra collezione. Come abbiamo detto prima, chi popola la collezione di dati, tramite gli strumenti sopra citati, è il platform engineer che, in accordo con il data engineer, provvederà alla creazione di flussi realizzati appositamente, in linea con le richieste. Anche in questo caso si dovrà tenere conto e traccia di ogni cambiamento che verrà effettuato sull’infrastruttura di archiviazione e sulla struttura di salvataggio dei dati per aver ben chiaro come accedere alla collezione dei dati e come questi si vuole siano salvati e gestiti.

Chi accede al data warehouse sono i data scientist, i citizen data scientist i data analyst. I primi si occupano di elaborare i dati tramite tool di programmazione come Python o R o tramite altri applicativi come Tensorflow. I data scientist elaborano, a partire dai dati presenti, soluzioni ad hoc per l’azienda, ad esempio sviluppando software per calcolare la regressione lineare, per analizzare immagini e riconoscere similitudini o per riconoscere malattie che vanno a impattare sulla capacità di produrre suoni, del parlato. I secondi, invece, si occuperanno di elaborare i dati tramite sistemi di machine learning messi a disposizione da parte di Google, Amazon, IBM, Microsoft (giusto per citarne alcuni). Non necessitano di competenze tecniche di sviluppo di codice ma necessitano di competenze legate all’uso di questi specifici tool che sono resi disponibili tramite drag and drop di vari moduli personalizzabili. Essi si rapportano con i product owner, vario management – come il service manager – o i business unit manager.

I terzi, invece, useranno tool legati alla data visualization e business intelligence come Tableau, Qlik, ELF o Splunk. Questi realizzeranno dashboard, grafici interattivi e report per rendere chiaro e disponibile ai business analyst o al management – specialmente a livello executive – le analisi dei dati.

I data analyst potranno essere specializzati in specifici ambiti, come marketing o finanza, potranno essere esperti di prodotto o di gestione a livello corporate, oppure potranno essere specializzati in ambiti non tradizionali legati al marketing research o nel VOC, il cosiddetto voice of the customer, un termine usato nel business e in IT per descrivere il processo approfondito di acquisizione delle aspettative, delle preferenze e delle avversioni del cliente.

Infine avremo i business analyst che, usando tool di business intelligence come quelli sopra citati, andranno ad analizzare quanto loro esposto dai data analyst, comprendendo le ripercussioni che si hanno sul business per esporre problematiche e possibili soluzioni o per proporre nuove idee al management di livello executive.

Chi, invece, si occupa della governance si rapporterà con tutti i ruoli sopra descritti per comprendere come la strategia è stata messa in atto e per indirizzarla.

Abbiamo visto quali siano i rapporti tra i vari ruoli, ma come possono essere gestiti? Si possono avere tre tipi di strutture che portano a due tipologie di scenari comunicativi distinti che possono essere implementati in maniera ibrida.

Scenari e comunicazione

Abbiamo uno scenario non organizzato e uno organizzato. Quello non organizzato si basa sulla raccolta dei prerequisiti tramite comunicazioni ad hoc, spesso basate su scambio di email. Non avrà una gestione centralizzata delle priorità e sarà, come si evince, legato alla struttura decentralizzata con i cosiddetti silo. Ne consegue che si avrà poca visibilità e maturità – di gestione – ma un’alta flessibilità. Questa tipologia è tipica delle startup.

Al contrario, in uno scenario organizzato, avremo la raccolta dei requisiti che sarà programmata e gestita con ordine. Le priorità saranno gestite a livello centralizzato con una unica leadership. Se ne evince che questo scenario è legato alla struttura organizzativa centralizzata avendo un’alta visibilità ma poca flessibilità e una maturità che varia da media ad alta.

Per entrambi gli scenari, bisogna tenere conto della comunicazione sia interna, sia esterna. Ad esempio, per la raccolta dei prerequisiti, avremo una comunicazione interna, volta a comprendere quali possano essere le implicazioni per il business e domande a cui rispondere che, però, non siano solo relative a indefinite motivazioni. Si avranno costanti incontri per poter seguire lo sviluppo dei minimum viable product e per poter comprenderne le implicazioni dei cambiamenti e per poter aggiornare coloro che gestiscono i vari prodotti o progetti così che siano sempre in linea con quanto scoperto per poter prendere decisioni sulle attività da svolgere. Un consiglio è quello di automatizzare il più possibile il processo per poter aumentare la qualità e la disponibilità dei dati.

Al contrario, la comunicazione esterna, è legata maggiormente all’analisi mensile o quadrimestrale del business, portando approfondimenti condivisi in maniera univoca e chiara per tutti coloro che sono interessati ad essa. Questa è volta a rispondere a domande, ad esempio, dei clienti, dei partner e degli enti di controllo.

Conclusioni

Abbiamo visto e chiarito come le aziende possono strutturare la loro data strategy e lo staff ad essa dedicato, come ogni reparto possa e debba interagire per una gestione proficua delle attività e come la comunicazione debba essere gestita per poter avere un effetto positivo.

Gestire la strategia aziendale non si limita solo alla cultura, ai ruoli e alle interazioni tra questi, ma richiede competenze relative alla tecnologia a disposizione per poterla sfruttare per il business e prendere decisioni.

WHITEPAPER
La guida per pianificare un Data Journey efficace
Big Data
Business Analytics

 

FacebookTwitterLinkedInWhatsApp

Commenta per primo

Lascia un commento

L'indirizzo email non sarà pubblicato.


*