Copertina: Foto di Pramod Tiwari su Unsplash
Avvertenza
Questa storia non è proprio vera. Ma non è affatto finta.
È il resoconto verosimile di un processo di trasformazione aziendale e organizzativa basato su fatti ed eventi reali che però sono stati opportunamente modificati, adattati e combinati per far loro assumere un significato più generale e per dare al racconto anche un valore “didattico”: la narrazione di una trasformazione organizzativa ispirata ai principi e alle pratiche Lean/Agile e alle conoscenze e alle tecniche dell’Organisational Design.
Pertanto i nomi, l’azienda, i luoghi non fanno riferimento a elementi precisamente identificabili e i personaggi sono da intendersi come di fantasia. Anche se poi magari qualche persona potrà riconoscersi in essi.
La storia comincia nei primissimi mesi del 2021 ed è tuttora in svolgimento…
Reinventare la ruota?
Funziona così: da un lato, nel mio ruolo di Agile Coach [1] e di consulente aziendale trovo sempre stimolante utilizzare modalità nuove, anche accattivanti, per far passare concetti, idee, interrogativi che possano portare alla scoperta di soluzioni. Sai che ogni organizzazione ha le sue peculiarità e rifuggi dal proporre soluzioni preconfezionate e modalità ormai “usurate” dall’eccessivo utilizzo, come le presentazioni standard.
Dall’altro, spesso mi accorgo che qualcosa di apparentemente nuovo e potenzialmente disrupting — come piace dire agli Americani — emerso durante le mie congetture in realtà è un’idea, un metodo, un approccio che qualcun altro sta già usando da un po’ di tempo e che magari ha anche codificato.
Sto rimuginando su questa cosa da quando, pochi giorni fa, ho parlato con Alberto, che è un esperto di gestione dei dati per l’azienda di produzione software con cui lavoriamo a stretto contatto: con le loro competenze realizzano le soluzioni tecniche necessarie nei percorsi di trasformazione digitale che supportiamo nelle aziende.
Ad Alberto ho accennato al telefono il fatto che sarà necessario “fare qualcosa” insieme per soddisfare le necessità tecniche del gruppo di aziende automotive con cui stiamo lavorando. Ma alcune sue veloci osservazioni mi hanno messo la proverbiale pulce nell’orecchio.
Propongo una rapida riunione per esporgli i miei appunti e capire se sto inventando qualcosa di nuovo oppure è roba che è già stata formalizzata da chi ne sa più di me in questo campo.
Ma cosa sono i “dati”?
Con Alberto entriamo subito nel vivo della conversazione. Forse anche perché vogliamo lasciarci alla fine un po’ di tempo per parlare di alcune passioni che condividiamo.
“Come procediamo?”, gli chiedo.
“Raccontami un po’ cosa avete fatto e perché ti è preso tutto questo scrupolo di capire che cosa sta accadendo nel mondo di coloro che si occupano specificamente di dati”, mi risponde sorridendo.
“Bene. Allora, tanto per cominciare, ti ho già spiegato un po’ la situazione: abbiamo queste aziende separate ma che fanno capo a un unico gruppo automotive. E queste hanno la necessità e il desiderio di integrare strettamente i loro processi e i dati che ne derivano. Abbiamo parlato di ecosistemi digitali, di applicazioni In–Organisation e X–Organisation, e ci siamo dati degli obiettivi.
Ora siamo al dunque di dover realizzare un’applicazione per davvero e la ‘messa a terra’ — come si dice ora — di tutti questi concetti… be’, crea qualche scompiglio nei vari responsabili.
Ti faccio vedere quello che sto facendo con loro. Le immagini che vedi sono state realizzate per il workshop. Vorrei capire dal tuo punto di vista, Alberto, se questa cosa qua ha senso oppure no; vorrei il tuo parere in qualità, diciamo, di esperto di dati. Anche per scoprire che magari ho solo reinventato la ruota e scoperto l’acqua calda… “
“Ok fammi vedere….” mi supporta Alberto.
“Ok, bene… dunque, sono partito dai dati… Perché sono partito dai dati? Perché mi sono immaginato un approccio stile baratto, al punto che abbiamo denominato questo percorso formativo come ‘bazar digitale’.
Per farla breve: nella mia esperienza di Agile Coach o di Product Coach, quando devo aiutare a fare envisioning di prodotto, ho trovato che spesso è difficile crearlo insieme all’azienda a partire da un’idea di prodotto. Nelle aziende, infatti, spesso ci sono silos informativi e organizzativi e finisce che ognuno pensa un po’ al proprio orticello. Per questo ho invece favorito questo approccio che parte dai dati, partendo da domande del tipo: ‘Ma tu di cosa hai bisogno?’. Voglio dire, pensando al mio caso, se sei l’azienda che vende le polizze, oppure quella che deve pensare al marketing e alla pubblicità… che tipo di dati, che tipo di output devi produrre? E la stessa domanda potresti farla al responsabile dell’ufficio legale: ‘che cosa ti serve per poter fare quel che devi fare tu?’. In questo modo si fa nascere, dal basso, uno scambio di dati e informazioni, e per questo ho usato la metafora di un mercato del baratto, che per darci un tono abbiamo chiamato digital bazar”.
Alberto mi ascolta, attento, ma con un’espressione che non capisco se sia di approvazione o di sufficienza. Continuo: “Cioè il dealer e la casa madre potrebbero aver bisogno di fare alcune cose. Per fare queste cose hanno bisogno di alcuni dati legati, che so, a percentuali di vendita, interessi d’acquisto, obiettivi di scelta. Il dealer che ha il concessionario potrebbe essere molto interessato a sapere quali sono le abitudini di guida dei possibili acquirenti: quanti chilometri fanno all’anno, su che strade guidano, perché se stai in campagna, come nel mio caso, magari ti serve un’automobile un pochino più ‘da battaglia’, più resistente alle intemperie, magari con trazione 4×4 e via dicendo.
Nel mio caso per esempio, in passato ho usato molto un minivan quando andavo alle gare di bici, dato che spesso dormivo in auto e la mattina alle 5 ero pronto per la partenza già sul posto.
Molti altri partecipanti si erano organizzati in modo simile e fra chi non aveva un’auto di questo tipo, molti mi facevano domande per capire meglio come attrezzars”.
Alberto mi risponde prontamente: “Anche io ho avuto un van per parecchi anni. L’avevo camperizzato. Aveva i sedili abbattibili e ci potevo mettere quindi il letto dentro. Ho tirato via tutto, ho mantenuto solo 4 posti. Avevo due letti dentro, una tenda a soffietto sopra il tettuccio e poi dei cassettoni sotto il letto per metterci tante cose utili…”.
“Ecco esattamente quello che intendevo… Per chi di mestiere deve venderti un’automobile, potrebbe essere utile avere questo tipo di informazioni. Chi ce l’ha questa informazione? Probabilmente ce l’ha il concessionario che ti conosce, che ti vede arrivare con la macchina fangosa o magari con le sospensioni finite perché abiti in campagna e prendi un sacco di buche. Sarebbe ottimale se questa informazione arrivasse anche all’ufficio vendite che poi ti dice ‘Aspetta. Ma tu Alberto sei uno che fa una vita sportiva: ti andrebbe di provare una macchina adatta? Magari facciamo un cambio valutando bene il tuo usato’. Ma questo lo può fare solo se ha certe informazioni che gli arrivano da fonti diverse”.
“Be’, sì. Questa cosa è sensata” mi conforta Alberto.
“Quindi ho pensato”, aggiungo, “che va bene creare l’applicazione seamless e frictionless, dove l’utente è al centro, ed è creato a partire da personas adeguate al contesto… Tutto ottimo se devi disegnare una esperienza utente: quando poi passi alla parte di realizzazione, le cose sono meno semplici. Poter scambiare informazioni fra gli attori coinvolti può fare tutta la differenza sia in termini di complessità di realizzazione sia per la semplicità del servizio offerto, e quindi di piacevolezza dell’esperienza utente.
Spesso avere informazioni a supporto o saper chi ha tali informazioni, può semplificare non poco la realizzazione.
Quindi mi son detto che bisognava partire proprio dai dati, se non altro per semplificare le conversazioni degli stakeholder coinvolti: per loro a volte è difficile parlare di personas, business needs, customer journeys. Spesso invece è facile chiedere ‘Ma che informazioni (dati) ti servono per fare un contratto? E cosa produci al termine della pratica?’
Questi dati sono importanti: c’è del valore. Chi li ha raccolti ha impiegato tempo e fatica, speso soldi o reputazione per averli. L’utente ha firmato i contratti della privacy e i dati non li puoi dar via così: sono molto importanti queste informazioni. Quindi se torniamo nell’esempio che stavo dicendo prima, tu sei l’ufficio marketing, io sono sales o legal, probabilmente io cerco delle cose ma anche tu cerchi delle cose. E al tempo stesso a me ne avanzano alcune, e lo stesso vale per te”.
Alberto è tornato silenzioso: ascolta con attenzione e, anche se capisco che ha qualcosa da dirmi, mi rendo conto che probabilmente, per lui, non è ancora arrivato il momento.
Riprendo: “L’utente fa un percorso: prende consapevolezza del prodotto, ricerca sul web, poi va al concessionario, vede il modello, fa la richiesta di un preventivo. In tutti questi step vengono raccolti dei dati. Noi vogliamo che tutto questo processo, e anche la conseguente raccolta dati, possa essere fatto in maniera semplice, ‘senza attrito’. Ma, al momento, un’applicazione così non ce l’abbiamo ancora. Però è chiaro che l’utente, a ogni passo nel suo customer journey, ‘semina’ dei dati. E che poi questi dati potranno essere elaborati da qualcuna delle aziende del gruppo che li offrirà; e al contempo ne richiederà altri”.
Alberto si inserisce fulmineo: “Ma stai facendo data mesh!”.
Dati come prodotto
Ecco cosa voleva dirmi già da un po’, probabilmente. Aveva capito che saremmo finiti qui e che stavo reinventando la ruota, dal momento che qualcuno ha già pensato a questo approccio, sistematizzandolo: era ovvio che qualcuno ci avesse già pensato.
“Vedi Giovanni”, mi dice, “quando qualche tempo fa ti accennavo l’argomento, lo facevo perché mi avevate brevemente prospettato la situazione e mi ero reso conto che questo approccio Data Mesh, che non è solo tecnico ma anche sociale, ben si adattava alla vostra realtà. In Data Mesh, ad esempio, c’è una sorta di self-service dei dati, e ti dirò tra poco come i dati sono intesi in Data Mesh. A partire da questa piattaforma, ti generi il prodotto come vuoi: ognuno genera dati e necessita di dati. Ma come si fa a essere autonomi nell’andare a prendersi dati dagli altri mondi? La soluzione è che tutti insieme hanno deciso il modo in cui condividere le informazioni”.
Sono molto incuriosito, ma penso anche che a volte le soluzioni a cui si addiviene sono quasi obbligate o perlomeno ristrette a un limitato numero di opzioni, indipendentemente da chi le ha codificate.
“In Data Mesh”, continua Alberto, “il dato non è qualcosa di astratto, ma viene trattato come un vero e proprio prodotto. Non è qualcosa di disaggregato, ‘sporco’, inattendibile. Anzi. È un’informazione che è stata verificata, uniformata, impacchettata in un formato standard e così via. Se una finanziaria raccoglie dati di un cliente, fa tutte le verifiche del caso e li organizza e formatta in modo che siano condivisibili. Parlando di contratti, un dato grezzo potrebbe essere l’aggregato di informazioni che compongono un piano di finanziamento. Ma se i dati diventano un prodotto allora la finanziaria ha fatto tutte le verifiche del caso per trasformare quei dati in un piano di leasing rispettando alcuni vincoli. E se per caso dovessero cambiare le politiche economiche della casa madre o i tassi di cambio o qualcosa nella normativa vigente, la finanziaria farà nuovamente tutte le verifiche del caso e produrrà nuovamente un contratto di leasing di cui lei è reponsabile per correttezza numerica e semantica.
Oltre a questo aspetto dell’affidabilità del dato, c’è l’importanza del potersi prendere i dati in autonomia, se è stato definito un modo di trasferire le informazioni. Poi, con questo prodotto-dati, posso crearmi il mio prodotto, aggregando e combinando”.
“OK, ecco!”, gli faccio eco. “Quel dato non è più una riga disassemblata di un database, ma sono dati di un’entità che ha un suo significato, proprio come nel concetto della programmazione a oggetti”.
“E il dato non è lì in un ‘bidone centrale’ incustodito”, si inserisce Alberto, “ma Impacchetterai le informazioni ad hoc; e quelle che legalmente posso condividere, le condivido in un formato che piace a tutti. Poi, a questo punto, dal lato tecnologico, si apre un mondo. Perché una volta che ti ho fornito un dato come prodotto, posso scegliere di ridarti il tutto, ma modificato di volta in volta che ci sono cambiamenti. Oppure posso semplicemente ‘aggiungere’ dei cambiamenti di stato rispetto al dato originale, con una modalità a eventi basata su messaggi. Ma il concetto non cambia: i dati restano sempre affidabili”.
Dal codice al business
“In tutto questo è importante il concetto di governance, che per esempio mancava in soluzioni più ‘antiche’ come SOA…”. Le mie reminiscenze di esperto — oramai ex — in architetture enterprise si riaffacciano per qualche momento alla memoria.
Alberto rinforza questo breve tuffo nel passato: “Guarda Giovanni… alla fine tanti concetti sono semplicemente Old new things. Anche il Domain-Driven Design ha dentro di sé moltissimi concetti di Object-Oriented Programming: diciamo che tutto questo ci è servito per uscire un po’ dal codice e guardare a livello più elevato di business…”.
“Insomma, mi stai dicendo che non ho fatto fare castronerie, ma che l’approccio che ho ricercato ha dei fondamenti anche teorici?” chiedo ad Alberto. “E, partendo da questo, avresti qualche ulteriore passo da suggerirmi?”.
Alberto riprende: “Non so come reagiranno a queste proposte le persone con cui stai lavorando, ma una cosa che secondo me è importante è che nelle primissime riunioni/attività/workshop ci siano tutti. Compresi i manager più importanti, la cui partecipazione può risultare favorevole a un avvio rapido delle attività. Al contrario, la loro assenza, per quanto spesso motivata da tante buone ragioni, rischia di diventare bloccante. Ed è insensato, oltre che costoso, tenere bloccata un’iniziativa solo perché uno dei C-level non può partecipare”.
Riconciliazione semantica
È arrivato il momento di introdurre una delle mie piccole “ossessioni”, ossia i problemi legati alla cosiddetta riconciliazione semantica dei dati.
“Alberto, devo farti un’altra domanda” intervengo. “Come ci si comporta quando ottengo dei dati che però formalmente non corrispondono a quanto devo usare io come dato? Vale a dire, se io, per le più svariate ragioni, chiamo qualcosa in un modo diverso da chi mi fornisce il dato… che succede? Nel DDD, chi è responsabile del dato è responsabile di curarlo e costruirlo e darlo come informazione, non come riga sul database, ma come informazione che ha un significato come prodotto”.
“Di un prodotto, appunto”, ribadisce Alberto. “Il tuo dato è il prodotto finale; è il dato inteso come prodotto finale. È l’insieme del dato in senso stretto, della logica che lo produce, del codice che lo produce e, volendo, anche dell’infrastruttura che ci sta dietro per arrivare a un prodotto. Non è solo il contenuto di un campo del database. Un dato come prodotto deve essere di valore, facilmente trovabile, veritiero e affidabile. Quindi, se tu mi chiedi un dato, io te lo fornisco come l’ho prodotto io, ovviamente tenendo presente la massima interoperabilità e tanti altri aspetti. Ma se hai bisogno di cambiare il modo in cui tu chiami le cose, diventa un discorso di mapping. Vorrà dire che ti creerai uno strato intermedio di mapping per ‘tradurre’ il dato che ti viene fornito nelle denominazioni differenti che devi usare. Io ti espongo i dati in maniera, diciamo, standardizzata dal punto di vista tecnologico e poi tu te li viene a prendere e ti regoli di conseguenza”.
Un passo alla volta
Alberto mi ha chiarito molti dubbi. E, se da un lato ha confermato che le mie intuizioni fossero solo una sensata applicazione di principi che altri stanno sistematizzando [3], dall’altro mi ha anche aperto una serie di prospettive che andranno approfondite, in particolare per quanto riguarda gli aspetti tecnologici. Sarà il caso di approfondire il discorso delle piattaforme, ad esempio.
Ma, finita la discussione sul tema dei dati, con Alberto dobbiamo parlare di una comune passione: le attività sportive di fatica. Se io amo le due ruote a pedali, sia in versione stradale che fuoristrada, Alberto è un alpinista e scialpinista, cui piace molto esplorare la montagna. E quando ci incontriamo, dobbiamo per forza raccontarci qualcuna delle nostre piccole “avventure”.
Visto il periodo che ci stiamo lasciando alle spalle, le nostre attività stanno ricominciando pian piano proprio in questo periodo e, per questa volta, parleremo più di progetti da mettere in prarica, che di esperienze vissute di recente. Ma va bene così. Un passo alla volta.
Riferimenti
[1] Agile Reloaded
[2] Giovanni Puliti, Digital revolution: La teoria – Tema 4: Progettare un prodotto digitale. MokaByte 294, maggio 2023
https://www.mokabyte.it/2023/05/14/digitalrevolutiontema-4/
[3] Zhamak Dehghani, Data Mesh: Delivering Data-Driven Value at Scale. O’Reilly Media, 2022
Giovanni Puliti ha lavorato per oltre 20 anni come consulente nel settore dell’IT e attualmente svolge la professione di Agile Coach. Nel 1996, insieme ad altri collaboratori, crea MokaByte, la prima rivista italiana web dedicata a Java. Autore di numerosi articoli pubblicate sia su MokaByte.it che su riviste del settore, ha partecipato a diversi progetti editoriali e prende parte regolarmente a conference in qualità di speaker. Dopo aver a lungo lavorato all’interno di progetti di web enterprise, come esperto di tecnologie e architetture, è passato a erogare consulenze in ambito di project management. Da diversi anni ha abbracciato le metodologie agili offrendo ad aziende e organizzazioni il suo supporto sia come coach agile che come business coach. È cofondatore di AgileReloaded, l’azienda italiana per il coaching agile.