Analisi

Analytics, come evidenziare i gap all’interno di processi e strategie aziendali

Che differenza c’è fra gap evidenti e gap nascosti e come farli emergere analizzando i dati

Pubblicato il 08 Mag 2023

Alberto Visentin

Analytics Pre-Sales and Data Visualization Solution Leader - Var Group Mediamente Consulting

Statistica bayesana e data analytics

Come quasi in ogni attività umana, anche un progetto di analytics porta con sé aspetti di tipo economico, che spesso ne costituiscono un blocco iniziale difficilmente superabile se non adeguatamente affrontato. Il “perché” un’azienda, ente o organizzazione dovrebbe spendere una cifra spesso non banale per un progetto di analytics deve quindi trovare una spiegazione convincente in termini di “Return on Investments” (ROI). Il punto è che, quasi per natura, risulta quasi impossibile attribuire a un progetto di questo tipo un “merito”, in termini di maggiori vendite o minori costi, che sia oggettivo e condiviso. L’assessment è una prima fase in cui mettere l’interlocutore di fronte ai propri “gap”.

L’importanza dell’assessment

Capire di cosa si stia parlando, concordare su obiettivi realistici, proporre un piano coerente e realizzabile sono le basi su cui sviluppare un progetto. In generale, forse ancor più quando si parla di analisi dati.

In questo senso, una fase iniziale di comprensione della situazione attuale e di condivisione di quella futura, ovvero un “assessment”, è non solo utile bensì fondamentale. Assieme alla competenza strettamente professionale sull’argomento, è una fase in cui trasmettere all’interlocutore la fiducia nella consistenza di quel che si va a proporre. Anche, se non soprattutto, in termini di obiettivi.

L’assessment mette l’interlocutore di fronte ai propri gap. In altre parole, descrivendo la situazione attuale si evidenziano già quasi in modo naturale i punti di attenzione, quindi le opportunità su cui far puntare il progetto. Migliorare, se non risolvere queste problematiche evidenziandole può diventare il “criterio di misurazione” del successo del progetto.

Sì, ma come “evidenziare” questi gap? Innanzitutto, bisogna capire di che tipo di “gap” stiamo parlando.

Un amministratore delegato che non disponga di una situazione aggiornata, consistente e comprensibile sulle vendite dei propri negozi rappresenta certo un problema palese e chiaro, forse la ragione principale per la quale l’azienda può pensare a un progetto di analytics. La risoluzione di un tale problema richiede, ancora una volta tramite un assessment fatto bene, l’individuazione di dove siano i “gap” che non consentono, a oggi, di arrivare al risultato.

analytics gap

Analytics: gap “evidenti”

Spesso il problema di cui sopra è legato a gap che possiamo definire “evidenti”, quali:

  • mancanza di un ambiente/software per la rappresentazione e condivisione delle informazioni aziendali (N.B.: Excel non rientra tra questi).
  • mancanza di un ambiente centralizzato in cui convogliare i flussi dati dai vari source.
  • inadeguatezza/obsolescenza dell’infrastruttura tecnologica.

L’individuazione di questi gap può essere relativamente semplice, così come le conseguenti azioni da intraprendere. E i risultati conseguiti sono evidenti quanto i gap (es. la realizzazione di un ambiente di data visualization per il chief-level che prima non c’era).

Tuttavia, la misura del successo di un progetto di analytics è determinata anche dalla risoluzione di gap “nascosti”, che proprio perché tali è necessario portare in evidenza.

Analytics: gap “nascosti”

Un esempio su tutti. Se, a concorrere alla famosa situazione delle vendite che chiede l’amministratore delegato concorrono più fonti dati, diventa fondamentale in primis che queste fonti siano tra loro coerenti. È il compito della fase di “data preparation & quality” armonizzare questi dati per renderli, per l’appunto, parlanti tra loro la stessa lingua. Tuttavia, cercare di raggiungere questo risultato a tutti i costi, anche coprendo incongruenze nei dati stessi, può rivelarsi un boomerang per il progetto stesso. Il riferimento è, anche qui come esempio, a incongruenze di tipo anagrafico (in una fonte dati è scritto “U.S.A”, in un’altra “USA”, in un’altra ancora “United States of America”). L’istinto può portare a una soluzione “quick & dirty”: applicare una routine aggiuntiva che, basandosi sull’immancabile foglio Excel di transcodifica (da tenere aggiornato a cura di “qualcuno”), allinei tutti gli attributi anagrafici così da avere una situazione aggregata e coerente. La lungimiranza, invece, suggerirebbe di portare all’evidenza del business tali incongruenze, affinché vengano risolte alla fonte. Anche a costo di critiche sul risultato finale (riprendendo l’esempio, tre righe diverse per le vendite degli Stati Uniti, a seconda della fonte).

Spiegare che quello è il frutto di un’incongruenza di fondo, la cui risoluzione tramite metodi quick & dirty si rivelerebbe di corto respiro e svantaggiosa in termini di costi di sviluppo e manutenzione rispetto a una risoluzione “di processo” e strutturale, porta nel medio/lungo termine il nostro interlocutore di business a considerarlo come un valore aggiunto del progetto, forse anche maggiormente misurabile rispetto ai risultati “evidenti” del paragrafo precedente perché ottimizza costi di manutenzione del dato in termini di tempi e risorse dedicate.

Altri esempi di questi gap “nascosti”, evidenziabili tramite un sistema di analytics, possono essere:

  • Inefficienze nelle raccolte dati attraverso form cartacei (es. fidelity card), che portano a report CRM con informazioni palesemente incongruenti o mancanti => Azione: sviluppo di un sistema ad hoc per la raccolta dati cliente e/o incentivazione del personale addetto sulla base della completezza e qualità dei dati inseriti.
  • Incongruenze di dati esterni (es. file locali) rispetto ai data source enterprise, tali ad esempio da generare buchi informativi all’interno dell’analisi della supply chain => Azione: analisi dei motivi per la presenza di sistemi locali e studio per un’integrazione dei dati coinvolti all’interno degli ERP aziendali.
  • In contesti multinazionali, modalità differenti nell’invio dei dati ai sistemi corporate tali da rivelarsi incongruenti tra loro o disponibili in tempi diversi tra loro e non giustificabili da ragioni concrete => Azione: definizione di un workflow condiviso in termini di template dati, procedure approvative ecc.

Conclusioni

Come detto, queste descritte sono azioni con risultati attesi nel medio/lungo termine, che spesso vanno a toccare alcune pratiche che rientrano sotto la categoria del “si è sempre fatto così”. Così come si tratta di scelte progettuali che richiedono una certa dose di coraggio e capacità nel sostenere le proprie tesi, spesso in situazioni in cui si vuole tutto e subito. Tuttavia, sono anche scelte che alla fine ripagano e danno al progetto e a chi lo gestisce un marchio di solidità e fiducia che anche l’interlocutore di business più isterico e ansioso non può non capire.

Valuta la qualità di questo articolo

La tua opinione è importante per noi!

Articoli correlati

Articolo 1 di 2