Durante un progetto di evoluzione degli strumenti analitici in un’azienda spesso si incontrano ostacoli preventivabili solo in parte all’inizio. Al di là degli aspetti più “sociologici”, legati ad esempio alla scarsa propensione al cambiamento da parte degli utenti o alla mancanza di una vera e propria sponsorship, ci sono fattori più di carattere progettuale e tecnologico che, se non considerati, rischiano se non nel breve quantomeno nel medio-lungo periodo di rivelarsi dei veri e propri blocchi, finanche a portare a un fallimento e all’abbandono del progetto stesso. Serve una spinta iniziale, proveniente dall’Information Technology e/o dal business, per poter sperare di dar vita a un progetto analytics aziendale che, tra l’altro, per sua natura risulta difficilmente misurabile tramite la bilancia “costi-benefici”. Identificare tale motivazione e portarla all’attenzione dell’azienda è il primo aspetto da considerare attentamente.
Analytics aziendale: assessment tecnologico-funzionale
Qui bisogna fare molta attenzione. Perché se il motivo è prevalentemente tecnologico, come l’adeguamento di un ambiente di Data Warehouse (o Data Lake) conseguente, per esempio, al cambio di un ERP interno all’azienda, sarà importante capirne gli impatti lato output utente e pianificare fin da subito un assessment dell’”as is” in termini di dashboard e report attuali.
Questo assessment dovrà portare a una stima di tempi e costi necessari al “change management”, affinché esso sia il più trasparente possibile per gli utenti finali. Al contrario, se la motivazione all’evoluzione proviene dal business, è necessario che l’Information Technology venga coinvolto immediatamente per capirne gli impatti in termini di sostenibilità all’interno dell’attuale ecosistema infrastrutturale, con eventuali stime di effort per un necessario adeguamento.
Nel primo caso (spinta tecnologica) il rischio è che l’azienda, in termini di utente finale, non capisca l’esigenza di cambiare quanto già funziona. Nel secondo caso (spinta funzionale) il rischio è che la cosa non risulti fattibile o, ancor peggio, venga implementata al di fuori dei sistemi aziendali “riconosciuti”.
Analytics aziendale: fiducia nel dato non è fiducia nell’informazione
Una trappola in cui spesso si cade quando si evolve un progetto di analytics aziendale è considerare il risultato raggiunto quando sono certificati i “dati”, cioè sono certificati i relativi processi di caricamento e aggiornamento a partire dai data source. Questo è sufficiente per dire che il dato sia “formalmente corretto”, certo, ma non per dire che lo stesso sia “utile” al business ai fini analitici. Per esserlo è necessario che i nuovi flussi di caricamento e data preparation integrino anche tutte quelle operazioni di gestione dato “a valle” compiute in passato dagli stessi utenti e, col tempo, rimaste al di fuori dei processi ufficiali di analytics ma paradossalmente vitali per gli utenti.
Operazioni locali e non certificate che così diventano condivise e certificate (ad esempio tramite l’utilizzo di un form invece che di un file Excel). In altre parole, dai dati alle informazioni. Capita frequentemente che questi aspetti vengano tralasciati, o scoperti solo quando ormai è (quasi) troppo tardi. Questo porta a una mancanza di fiducia da parte dell’utente finale nell’iniziativa in generale.
Integrazione funzionale
Un altro tema che si tende a sottovalutare riguarda l’integrazione tra i dati, a partire dalla presenza di diversi data type in diversi sistemi per la stessa “informazione” fino ad arrivare all’impossibilità logica di mettere assieme in una stessa analisi le metriche di un nuovo strumento assieme a quelle di uno già esistente a causa di una differente costruzione (per l’appunto, logica) delle metriche stesse. Così può accadere ad esempio che un progetto di digital transformation si areni sulle difficoltà di creare un database online + offline dei clienti registrati, solo perché le “informazioni” comuni presenti nei sistemi di origine differiscono tra loro in termini di data type o naming convention, cosa che magari in sede di pianificazione effort non era stata opportunamente considerata.
Evidenza dei “risultati”
Si è già detto come la valutazione costi-benefici sia molto poco applicabile a un progetto di evoluzione analytics, eccetto forse per un progetto di advanced analytics dove il confronto tra consuntivo e previsione può costituire una misura affidabile, per quanto parziale, del vantaggio dell’iniziativa. Proprio per questo uno sforzo dei promotori, tecnologici o di business, dovrà essere quello di fissare in termini per quanto possibili quantitativi e portare alla massima evidenza i “risultati”: ad esempio, la disponibilità dei dati in un tempo più rapido, il minore effort necessario per la realizzazione di un report “on demand”, il risparmio nella gestione della parte infrastrutturale grazie a meccanismi automatici di controllo e ottimizzazione. Un progetto di analytics, proprio perché poco misurabile in termini “assoluti”, ha un disperato bisogno di “pillole di marketing” per poter dimostrare la propria utilità in azienda.
Necessità o opportunità?
Alla fine, un ambiente aziendale analytics viene sottoposto a un progetto di cambiamento o evoluzione per due ragioni: necessità oppure opportunità.
Necessità può essere l’obsolescenza tecnologica e la mancanza di supporto da parte del vendor, il repentino decadimento delle performance di un tool utente, l’adeguamento a un nuovo ERP aziendale.
Opportunità può essere uno strumento che consente di ottenere finalmente analisi importanti in modo automatico, sfruttare l’advanced analytics per avere vantaggi competitivi e ridurre i costi del demand planning, una tecnologia che riduce drasticamente tempi ed effort di data management.
Tuttavia, il confine tra le due “spinte” è labile se si considera il contesto aziendale in cui, per definizione, anticipare le scelte (in modo saggio, ovviamente) è un obiettivo a tutti i livelli decisionali.
E allora forse la vera suddivisione non è tra necessità e opportunità ma tra azione e reazione. Dove nel primo caso si anticipa quel che sarà e ci si muove per tempo, nel secondo caso il processo inizia a fronte di un problema, tecnologico o competitivo che sia, solo nel momento in cui risulta evidente (ed è forse troppo tardi).
In ultimo, esiste anche lo “sfizio” come possibile motivazione. Ovvero l’iniziativa magari di un singolo, spesso nuovo entrato nell’organizzazione e che porta “in dote” un progetto di cambiamento a prescindere dal contesto. Direi di tralasciare questa situazione, anzi di evitarla per quanto possibile, visto che qui il fallimento è quasi certo. E in questo caso prima è, meglio è.
