Analisi dei dati self-service come una gerarchia dei bisogni

Analisi dei dati self-service una gerarchia dei bisogni sotto esame

Dal cibo e alloggio all’autorealizzazione: come utilizzare un approccio scientifico per creare le basi che supportano l’analisi self-service

Ho ripensato agli anni ’90, quando sono state lanciate per la prima volta le soluzioni di business intelligence (BI) self-service come Business Objects e Cognos. Ehi, come tutti gli ingegneri del software straentusiasti, ho persino contribuito a costruirne uno durante il mio breve impiego presso Citigroup. In quel periodo, il mio giovane io formulò due previsioni molto rapide:

1. Excel è morto
2. I dati self-service prenderanno rapidamente il sopravvento

OK, quindi non sono proprio Nostradamus. Dopo Citigroup, mi sono trovato a metà carriera come consulente di BI: fare un po’ di ingegneria dei dati (allora ETL, non ELT), applicare sopra uno strumento BI, formare gli utenti aziendali, ripetere il processo. Abbiamo creato alcune “cose interessanti”, ma esperienza dopo esperienza il risultato era insoddisfacente:

Gli utenti aziendali non adottavano il software e non utilizzavano i servizi self-service come ci aspettavamo.

Un piccolo numero di “utenti esperti” (spesso sul lato tecnico) avrebbe utilizzato gli strumenti per creare livelli di dashboard e report diversi, ma non c’era una diffusa adozione da parte della parte aziendale. E rimaneva una forte dipendenza dai consulenti.

• Incontra Mustango un sistema di testo-musica ispirato alla conoscenza del dominio musicale, basato sulla diffusione, che amplia il modello Tango di testo-audio.
• Conda troppo lento? Prova Mamba!
• Top 5 API di diffusione stabili per un’integrazione semplice dell’app

Promozione di vendita del fornitore di BI: democrazia dei dati self-service al 100%

La mia aspettativa: adozione del 60-80%

Realità: adozione <20%, in modo ottimistico

Dopo un po’, questi progetti hanno iniziato a sembrare una grande opportunità di apprendimento. Chi era il colpevole? Gli strumenti, gli utenti, l’IT, i consulenti? Siamo nel 2010 circa e iniziamo a vedere molta documentazione sui progetti BI falliti. Non “falliti” nel senso che i progetti non hanno prodotto risultati significativi, ma falliti nel senso che raramente raggiungevano il loro pieno potenziale. I domini aziendali dipendevano ancora pesantemente dall’IT per i dati. I dati puliti e affidabili non erano velocemente disponibili.

A questo punto accade una cosa interessante: un prodotto di visualizzazione dei dati chiamato Tableau inizia ad essere ampiamente utilizzato. È ovunque, ed è la soluzione per la democrazia dei dati. Successivamente arriva Power BI per competere come strumento d visualizzazione dati e di reporting di prima scelta. Tuttavia, dopo un decennio o più, vediamo ancora la stessa cosa con questi nuovi strumenti: scarso utilizzo self-service degli strumenti BI. Chiaramente, non sono l’unico.

Il tasso globale di adozione della BI in tutte le organizzazioni è del 26%. (360Suite 2021)

49 statistiche sconvolgenti sulla business intelligence per il 2021

Perché il mercato della BI continua a evolversi, queste statistiche mostrano quanto importanti saranno gli strumenti di business intelligence…

www.trustradius.com

Non potevo restare solo a guardare. Naturalmente, dovevo creare ciò di cui il mondo ha sempre avuto bisogno: lo strumento BI per risolvere il self-service. Sì, finalmente avrei fatto la cosa giusta, mi dicevo. Così ho creato FlexIt Analytics con quel obiettivo. Beh, ricordate le mie previsioni di prima? Ebbene, ancora una volta, mi sbagliavo di grosso. Andiamo dritti al punto:

Non c’è mai stata e non ci sarà mai una singola soluzione magica per rendere l’analisi dei dati accessibile alle masse in modo significativo.

Nessuno strumento BI risolverà il self-service. Quello che possiamo fare, però, è fare un passo indietro e pensare al problema da una prospettiva “d’insieme”, non tecnica, e forse ottenere preziose intuizioni e strategie per andare avanti.

La gerarchia dei bisogni di Maslow

Portatevi indietro nel tempo alla scuola superiore, se volete, e cercate di ricordare quella stimolante lezione di psicologia sulla motivazione umana. Se non avete trattato questo argomento a scuola, o non vi ricordate, ecco un riassunto:

Lo psicologo americano Abraham Maslow propose una teoria sulla motivazione umana secondo cui i bisogni di base devono essere soddisfatti prima che una persona possa raggiungere bisogni più elevati. Man mano che ci muoviamo verso l’alto nella gerarchia, passiamo da bisogni a breve termine di livello inferiore come il cibo e l’acqua a bisogni di livello superiore che hanno una durata più lunga, sono più complessi e sempre più difficili da raggiungere. Il livello più alto è l’autorealizzazione e la trascendenza.

La gerarchia dei bisogni di Maslow

La gerarchia dei bisogni di Maslow è una piramide dei bisogni che motivano le persone. I bisogni più elementari degli individui, alla base…

www.simplypsychology.org

In poche parole, hai bisogno di una base di fondazione prima di passare al livello successivo. Chiunque nel mondo dei dati riconoscerà immediatamente questo concetto e capirà che si applica direttamente al raggiungimento dell ‘”autorealizzazione dei dati”, che è chiaramente “self-service”. Dai, entrambi hanno la parola “self”, non può essere una coincidenza. Approfondiamo.

La gerarchia dei bisogni di self-service

Stiamo mostrando la stessa immagine dall’alto perché non è solo una grafica di bellezza da Instagram, ma è anche estremamente utile per la nostra analisi imminente. Come la gerarchia di Maslow, la gerarchia dei bisogni di analisi dei dati self-service mostra come ogni livello supporta e consente il livello superiore. Inoltre, vedrai che più sali, maggiore è la fiducia necessaria e fornita.

Una volta ancora, DJ:

Collezione

Alla base, i bisogni fisiologici di Maslow sono ovvi: cibo, acqua, protezione. Allo stesso modo, il livello di base della gerarchia dei bisogni di self-service è ovvio: la raccolta di dati. Devi aver raccolto i dati. Vai avanti e diciamo anche che la tua base deve raccogliere dati grezzi da fonti disparate. Nel mondo dei dati moderno, questo è la parte di Estrazione e Caricamento dell’ELT (Estrazione, Caricamento, Trasformazione) e porta a quello che chiameremo un Data Lake, per semplicità. Nota la differenza tra il concetto tradizionale/vecchio del data warehousing di ETL (Estrazione -> Trasformazione -> Caricamento), che non è più rilevante per molte ragioni che affronteremo in un altro articolo.

L’ultimo punto da sottolineare qui è che qualsiasi analisi dei dati prodotta da questo livello dovrà essere effettuata da analisti/datascientist di livello superiore e ha un livello di fiducia inferiore poiché non è passata attraverso i livelli superiori della gerarchia. L’analogia sarebbe qualcosa del genere: puoi saltare direttamente alla trascendenza di livello superiore? Forse, ma alla fine del weekend quando la festa è finita, è improbabile che tu possa mantenerla.

Trasformazione

Il livello successivo nella gerarchia di Maslow è la sicurezza, che include cose come la sicurezza, la stabilità sociale, la prevedibilità e il controllo. Nella nostra gerarchia dei bisogni di self-service, raggiungiamo quella prevedibilità, stabilità e controllo pulendo e organizzando i dati come modelli aziendali nel nostro data warehouse. Questo assume spesso la forma di modelli a schema stella multidimensionali. Con i dati grezzi dalla raccolta di livello inferiore, gli analisti potrebbero dover unire molte tabelle disparate per i dati dei clienti. In questo livello, quei dati disparati sono stati riuniti in una tabella comune chiamata Dimensione del cliente. Inoltre, in questo processo, i dati vengono puliti (nomi duplicati o non corrispondenti per lo stesso cliente) e calcoli utili vengono precomputati (ad es. data del primo ordine), consentendo una SQL molto più semplice.

Alla fine, abbiamo stabilito un altro livello di sicurezza e fiducia nei dati, ma abbiamo anche reso possibile un nuovo gruppo di analisti con l’auto-servizio perché non devono conoscere la complessità aziendale dei dati di origine sottostanti. Molto importante sottolineare che a questo livello dovremmo vedere il coinvolgimento dei proprietari del dominio aziendale. Il processo di trasformazione è pensato per supportare le reali esigenze aziendali, quindi i proprietari aziendali devono essere coinvolti. Nel mondo dei dati moderno, iniziamo a vedere “ingegneri analitici” come un ruolo critico per supportare questa necessità ibrida.

Strato semantico

Il terzo livello di Maslow riguarda l’amore e l’appartenenza attraverso le relazioni e la connessione. La correlazione con la nostra Gerarchia di Self-Service è straordinaria, poiché lo strato semantico è letteralmente dove si stabiliscono le relazioni (join tra tabelle) ed è ciò che unisce tutto. Potrei parlare ancora a lungo degli strati semantici, e lo faccio nell’articolo linkato qui:

“Semantic-free” è il futuro dell’Intelligence Aziendale

Come dbt, le metriche, l’headless e lo strato semantico universale consentono un’Intelligence Aziendale “senza semantica”

towardsdatascience.com

Sostenere che questo livello sia il più importante per consentire un vero self-service e che i proprietari di domini aziendali debbano essere fortemente coinvolti. Lo “strato semantico universale” può fornire una singola fonte di verità che alimenta l’analisi self-service attraverso la competenza, la semplicità e la fiducia nei dati. Gli analisti possono fare affidamento su nomi di campi e entità legati al business, descrizioni di cataloghi dei dati e, forse più importante, non devono conoscere come le tabelle si uniscono tra di loro (o almeno come scrivere SQL). Abbiamo anche accesso a cose critiche come l’ereditarietà dei dati (tracciare un campo fino alla tabella di origine), i sinonimi (tu lo chiami “vendite”, io lo chiamo “ricavi”) e la freschezza dei dati (quando sono stati aggiornati per l’ultima volta).

Una cosa importante da notare qui, specialmente per gli storici che potrebbero dire “Business Objects aveva questo negli anni ’90”. Non abbiamo ancora raggiunto lo “strato di analisi” (livello dello strumento di BI). Per molte ragioni, che vengono elaborate nell’articolo linkato sopra (“Semantic-free is the future of Business Intelligence”), è fondamentale che non si inserisca lo strato semantico della logica aziendale in uno strumento di BI. Lo strato semantico nel nostro Self-Service Hierarchy dovrebbe supportare il livello successivo, non essere esso stesso.

Analisi

A questo livello, parliamo di strumenti di BI, report, cruscotti e di ciò che la maggior parte delle persone pensa quando si parla di analisi self-service. Se hai trovato la correlazione tra lo strato semantico e la gerarchia di Maslow altrettanto straordinaria come me, allora preparati per il livello di autostima di Maslow. Qui, suddivide i bisogni in bisogni “inferiori” come status, riconoscimento, fama, prestigio e attenzione, così come bisogni “superiori” come forza, competenza, padronanza, fiducia in sé, indipendenza e libertà. Salve “eroi dei dati”, “Maestri Zen” e guru.

A questo livello, nella nostra Gerarchia di Self-Service, iniziamo a vedere la proprietà del dominio aziendale e l’analisi self-service, con un focus su due dei quattro tipi di analisi:

1. Descrittiva – report e cruscotti che mostrano cosa è successo

2. Diagnostica – analisi che spiega perché è successo

Stai costruendo i tuoi cruscotti da un data warehouse pulito, con uno strato di trasformazione ben modellato e uno strato semantico universale sopra, giusto?

Paradossalmente, potrebbero essere gli strumenti di BI che pensavamo stessero abilitando il self-service a fare il servizio peggiore. Sappiamo che Tableau (uno strumento di visualizzazione incredibile con un enorme valore, senza dubbio) ha ottenuto un’ampia adozione bypassando un IT lento e vendendo direttamente alle aziende, e continua a sfruttare questa divisione. Troppissime implementazioni coinvolgono l’esportazione dei dati da SQL scritti a mano su database di origine o report statici di BI, e l’importazione di tali dati in formato .CSV in Tableau. Mentre puoi scegliere di mangiare in modo salutare a questo buffet à volonté, la realtà spesso è molto diversa. Il caos che ne deriva spesso rallenta le aziende a tal punto che non raggiungeranno mai i livelli successivi, producendo solo cruscotti descrittivi su ciò che è successo.

Autorealizzazione e Trascendenza

Il livello più alto della gerarchia di Maslow riguarda l’autorealizzazione, la crescita personale e il raggiungimento del proprio pieno potenziale. Similmente alla vita, nel mondo dei dati non c’è una vetta in cui arrivare e dire “è tutto fatto”. È un lavoro continuo, molto difficile da raggiungere e sembra che possa andare avanti all’infinito. A questo livello, andiamo oltre le analisi descrittive e diagnostiche di base ed abbiamo stabilito un livello molto elevato di fiducia nei nostri dati e nel nostro processo. Questo consente i successivi due tipi di analisi:

3. Predittiva – capire cosa succederà dopo

4. Prescrittiva – basandosi sulle previsioni, suggerire il percorso ottimale da seguire

A questo punto, abbiamo una solida base in tutti i nostri livelli di dati e possiamo iniziare a compiere progressi significativi nell’utilizzo dell’intelligenza artificiale, nell’automatizzazione dei processi aziendali e nell’affrontare casi d’uso più avanzati.

Componenti di un’organizzazione orientata ai dati

Ottenuto un quadro per migliorare la nostra “vita dei dati”, con l’obiettivo ambizioso di auto-realizzazione dei dati, ora scaviamo e cerchiamo di capire come possiamo raggiungerlo. Prima di tutto, diamo un’occhiata a ciò su cui dobbiamo concentrarci: persone, processi e strumenti.

Persone

Vengo dal settore tecnico e voglio creare soluzioni tecniche per risolvere problemi aziendali. Sicuramente, se ricevo dei requisiti aziendali, mi rinchiudo in una stanza buia, scrivo del codice e posso creare un software per soddisfare le esigenze aziendali. Il mio errore, e l’errore di molti altri, è una scarsa attenzione al lato umano: alle persone. Questo sembra ovvio, ma penso che noi tecnici dovremmo ammettere che spesso creiamo incredibili prodotti software e li consegniamo agli utenti aziendali dicendo “Tada, eccolo qui!” Siamo sorpresi quando non viene utilizzato come avevamo previsto o quando “non lo capiscono”.

Il lato umano della tecnologia può essere sorprendente e misterioso, ma non è necessario che lo sia. Al centro di tutto questo, dobbiamo instaurare fiducia e competenza focalizzandoci su alcuni aspetti chiave. Innanzitutto, deve esserci il coinvolgimento, altrimenti le forze contrarie possono far deragliare anche ottime soluzioni tecniche. Inoltre, è necessaria una seria collaborazione con l’idea che stiamo lavorando verso una soluzione dati “orientata al business” piuttosto che una soluzione “orientata ai dati”. Tutto ciò che facciamo deve essere fatto tenendo presente le esigenze aziendali. Mentre costruiamo, dobbiamo pensare a come possiamo abilitare la competenza nel nostro prodotto finale. Nel mondo dei dati, come possiamo abilitare la “lettura dei dati”? Certamente, l’azienda dovrebbe conoscere i propri dati, ma quando sottoponiamo il loro business a un processo tecnico e poi lo presentiamo loro, non è sempre così ovvio come pensiamo. Dobbiamo abilitare la “lettura dei dati” con cataloghi dei dati e livelli semantici. Infine, quando lanciamo le nostre soluzioni, non possiamo limitarci a sessioni di formazione standard che sembrano conferenze. Dobbiamo concentrarci sulla formazione “appena in tempo” che si focalizza sui veri problemi di dati reali che l’utente aziendale deve risolvere in quel momento specifico.

Processi

Anche se facciamo bene la parte delle persone, possiamo ancora essere facilmente fuorviati. Per rimanere sulla buona strada, è necessario fare bene anche la parte dei processi. Uno dei problemi più evidenti negli ultimi decenni, soprattutto nel settore tecnico, è che molti progetti sono stati sviluppati con un approccio a cascata, in cui il risultato finale dovrebbe essere stabilito all’inizio del progetto. Il nostro primo passo, specialmente nel mondo dei dati in cui la creazione della nostra organizzazione orientata ai dati può richiedere molti anni, è essere agili e concentrarsi sulle esigenze aziendali in continua evoluzione adottando un approccio agile.

L’Agile è stato sviluppato come un metodo flessibile che accoglie l’incorporazione di cambiamenti di direzione anche tardivi nel processo, oltre a tener conto dei feedback degli stakeholder lungo tutto il processo. — Forbes

Agile Vs. Waterfall: Quale metodologia di project management è la migliore per te?

Agile e Waterfall sono due metodologie di project management ben note. Entrambe sono popolari nel campo del software…

www.forbes.it

Uno dei grandi errori delle persone che lavorano con l’approccio “agile” è che svolgono una serie di progetti sprint separati che non producono un prodotto finale coerente. Dobbiamo avere un obiettivo finale in mente, anche se non stiamo adottando un approccio a cascata. Devono essere in vigore standard e governance dei dati per assicurarci di rimanere concentrati su questo obiettivo finale. È anche importante che il lato business sia responsabile dei propri dati, anziché i tecnici. Devono essere strettamente coinvolti in questo processo. Infine, il processo deve concentrarsi sul miglioramento continuo. Cosa sta funzionando? Cosa non sta funzionando? Perché? Poi, risolviamo questi problemi e continuiamo a consegnare.

Strumenti

All’inizio, ci siamo affidati agli strumenti per risolvere magicamente i nostri problemi. Come ho affermato in precedenza, gli strumenti non sono la soluzione. Non rappresentano neanche lontanamente un terzo della soluzione. Penso che sia qualcosa come il 50% Persone, il 30% Processi e solo il 20% Strumenti. Essendo un fornitore di strumenti BI, è un quadro approssimativo. Tuttavia, è vero.

Detto ciò, ci sono alcune cose che gli strumenti possono fare per abilitare le persone e i processi complessivi. Chiaramente, devono essere intuitivi, in modo da non richiedere una conoscenza approfondita su come utilizzarli, e penso che molti moderni strumenti BI facciano questo. Una delle aree in cui penso abbiano delpe è “plug-and-play”. Come ho accennato in precedenza, abbiamo inserito troppa logica aziendale nei nostri strumenti, quindi passare da uno strumento all’altro è un grande sforzo. Senza dimenticare il fatto che molte organizzazioni hanno 3 o più strumenti BI, che spesso accedono agli stessi set di dati. Quello che dobbiamo fare è estrarre quella logica aziendale dagli strumenti BI e spingerla in un livello semantico centralizzato a cui tutti gli strumenti BI possono connettersi.

Inoltre, i nostri strumenti devono integrarsi con altri strumenti anziché cercare di essere uno strumento monolitico che fa tutto. Questa è una delle aree in cui il “moderno stack dati” fa bene, ma è importante che non andiamo troppo lontano nell’altra direzione e creiamo centinaia di strumenti che creano un’architettura confusa e disordinata. Alla fine della giornata, ricorda che gli strumenti sono solo qui per supportare le persone e i processi.

Passi per creare un’organizzazione orientata ai dati

Ora che abbiamo stabilito una struttura e i componenti generali di un’organizzazione orientata ai dati, parliamo di come arrivarci.

Passo 1: Consenso

Il primo passo è stabilire i principali interessati e ottenere il consenso a livello esecutivo. Senza questo, rischi di non avere “potere delle persone” per realizzare il tuo framework e i tuoi componenti di self-service. Ottenere un consenso diffuso può essere molto difficile, quindi capisci chi può essere i primi sostenitori. Alla fine di questi passi, inizierai di nuovo dal passo 1, continuando a costruire la tua organizzazione orientata ai dati e ottenendo sempre più consenso lungo la strada. Stai puntando a un effetto a palla di neve qui.

Passo 2: Iniziare con il piccolo

Continuando l’analogia della palla di neve, stiamo costruendo un pupazzo di neve. Naturalmente, iniziamo con qualcosa di piccolo e costruiamo su questo. Stiamo pensando alla cosa che stiamo costruendo in componenti e adottiamo un approccio agile per soddisfare le reali esigenze aziendali. Vogliamo una “vittoria veloce” nella nostra prima iterazione in modo da poter accumulare su questi risultati positivi, coinvolgendo sempre più persone lungo il cammino.

Passo 3: Costruire un processo

Queste “vittorie veloci” agili rischiano di creare architetture caotiche. Ecco perché immediatamente stabiliamo standard e governance dei dati, che forniscono una base e ci permettono di concentrarci esclusivamente sulla consegna di dati di qualità, accurati e affidabili. Strumenti come Github svolgono un ruolo importante nel supportare i nostri standard e la governance dei dati.

Passo 4: Democratizzare

La governance dei dati ci consentirà di distribuire in modo più sicuro questi prodotti dati con maggiore fiducia e minor rischio. Nella democratizzazione dei nostri dati, dobbiamo:

• Eliminare i silos di dati – si tratta di fonti di dati “black-box” controllate da un dipartimento, spesso informatico, e isolate dall’organizzazione più ampia.
• Sviluppare la cultura dei dati — non possiamo aspettarci che gli utenti aziendali comprendano immediatamente ciò che l’IT sta fornendo, anche se si tratta dei loro dati. I cataloghi dei dati possono aiutare molto a supportare la cultura dei dati, ma può essere complicato. Molte volte, finiamo per avere dizionari di dati basati su fogli di calcolo che diventano obsoleti e finiscono per raccogliere polvere. Dobbiamo passare a un catalogo dei dati più dinamico e attivo che consenta agli utenti aziendali di agire sulle entità del catalogo dei dati e fornire feedback sulle definizioni, ecc. per un miglioramento continuo.
• Costruire fiducia — per democratizzare i dati, l’IT deve fidarsi che l’azienda utilizzerà i dati correttamente. L’azienda deve fidarsi che l’IT fornirà dati accurati, affidabili e tempestivi. Ogni passo del percorso, bisogna stabilire e mantenere la fiducia.

Passo 5: Collaborare

Ora che abbiamo preso misure per democratizzare i dati, dobbiamo assicurarci di collaborare e lavorare insieme per sviluppare soluzioni, ma anche per fornire un feedback critico che migliorerà le cose. È importante formare un gruppo di tipo DART (Data Analytics and Reporting Team) che comprenda membri provenienti da diverse aree tecniche e di business, e che si incontri regolarmente per affrontare le questioni.

Passo 6: Valutare

Alla fine, dobbiamo evidenziare il successo, ma anche assicurarci di discutere costruttivamente delle cose che non hanno funzionato o che devono essere migliorate. Senza essere troppo dogmatici o inventare dei KPI, dobbiamo trovare un modo per misurare il successo. Le persone sono soddisfatte dei risultati di questa prima iterazione? Abbiamo creato un prodotto di dati immediatamente utile? Poi, iteriamo e miglioriamo continuamente ciò che ha funzionato e ciò che non ha funzionato.

Quindi, ripeti il procedimento, ritorna al passo 1 con un maggiore coinvolgimento e un nuovo progetto basato sui risultati.

Considerazioni finali

Mettendo tutto insieme, abbiamo coperto tre aree chiave su cui concentrarsi per creare un’organizzazione basata sui dati e abilitare il self-service. Una cosa molto importante da notare è che non stiamo passando da zero self-service a un’organizzazione pienamente democratizzata dai dati. Stiamo cercando di spostare l’ago, poco alla volta, e migliorare continuamente per consentire a un numero sempre maggiore di persone nell’organizzazione di essere coinvolte nei dati. Per riassumere, ecco i tre modi in cui possiamo concentrare questo sforzo:

1. Il framework – una gerarchia di bisogni che può informare su cosa dobbiamo costruire per abilitare un’organizzazione basata sui dati
2. I componenti – i componenti di questa organizzazione basata sui dati, ovvero le persone, i processi e gli strumenti.
3. Passi da seguire – un approccio in sei fasi che si concentra su questi componenti per costruire la nostra organizzazione basata sui dati all’interno del framework.

Buona fortuna nei tuoi sforzi di self-service!

Per favore, commenta, sarei felice di sentire le tue opinioni qui o contatta Andrew Taft