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…
A intervalli regolari…
“E quindi i prossimi passi sarebbero?”
A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.
I principi sottostanti al Manifesto Agile, 2001
Con i soci e i collaboratori della mia azienda di coaching agile [1] seguiamo la buona pratica di incontrarci regolarmente per riflettere in maniera strutturata su quanto fatto, discutere degli aspetti strategici del nostro gruppo, della gestione operativa delle attività e delle esperienze di formazione sperimentate come singoli o come gruppo.
Ma una parte del tempo passato a stretto contatto tra noi è dedicata a raccontare agli altri ciò che stiamo svolgendo con le nostre rispettive attività nelle aziende in cui ci troviamo a operare in quel momento: questo fa sì che l’esperienza, le osservazioni e l’intervento distaccato da parte degli altri professionisti possa fungere da aiuto importante per chi sta affrontando un determinato progetto in una determinata azienda.
In vari casi operiamo in più persone contemporaneamente sullo stesso scenario, ma in questo caso, nel gruppo di aziende automotive in cui sto lavorando, al momento sono solo. E quindi il continuo confronto con i miei colleghi diventa ancora più prezioso.
Dopo un mio rapido resoconto dei passi svolti, Marco mi chiede: “E quindi i prossimi passi sarebbero?”.
Banco di prova
“I prossimi passi sono conseguenti a quanto è stato fatto ormai più di una settimana fa”, dico. “Mi sono reso conto che fin qui abbiamo dato molti concetti e abbiamo posto degli obiettivi ma ancora, di fatto, di ‘concreto’ non abbiamo realizzato nulla. Per il momento questo non è un problema… Credo che nessuno in azienda abbia avuto l’impressione di perdere tempo, perché questi primissimi mesi sono serviti sicuramente a loro per capire tanti aspetti inerenti alle trasformazioni aziendali, e a me per entrare nella loro dimensione aziendale”.
“Normale. Se non erro si parlava di partire da un progetto pilota per provare a fare qualche esperimento…” aggiunge Pino.
“Sì, esatto” rispondo. “Credo che si orienteranno per la realizzazione di un’applicazione digitale Cross Organisation… per quanto impegnativa, è un progetto molto concreto ed qualcosa di cui effettivamente hanno bisogno e dalla cui realizzazione possono trarre degli utili riscontri”.
“Bene” fa eco Fabio.
Interviene a questo punto Stefano: “Hai già un’idea degli aspetti implementativi? Voglio dire… chi la sviluppa? Hanno personale adatto all’interno del gruppo? Oppure dovremmo fornire supportare anche per la parte piattaforma e dello sviluppo software?”.
“Eh… bella domanda…” rispondo. “Questo andrà valutato bene; il loro dipartimento IT in questo momento è decisamente preso dalle molte cose che devono già fare anche senza parlare di trasformazioni digitali… Un nostro aiuto in tal senso potrà essere prezioso”.
“Come vi siete lasciati?” chiede Stefano.
“La parte conclusiva della chiacchierata si è incentrata sul confronto fra trasformazione digitale e adozione delle metodologie agili: abbiamo convenuto (anzi ho fatto in modo che emergesse chiaramente) che la trasformazione digitale è il loro vero obiettivo, mentre lavorare in agile (qualsiasi cosa possa voler dire) è lo strumento.
Su questo ho riportato la nostra posizione di sempre: a parte certi casi particolari, fare agile — anzi essere agili — non dovrebbe essere un obiettivo finale, ma un modo per creare un prodotto di maggior valore, nel nostro caso nell’ecosistema digitale, riducendo il rischio di fare la cosa sbagliata”.
“Come hanno tradotto il rischio di fare la cosa sbagliata?”, chiede Marco.
“Con il rischio di realizzare prodotti che non rispondano alle esigenze dell’utente finale in ottica ecosistema digitale. Nel nostro caso non vogliamo sbagliare e dobbiamo avere chiaro di voler creare un prodotto che sappia unire differenti customer journeys afferenti a diversi contesti, offrendo un’esperienza utente unificata ma che sia facile da usare”.
Mi fermo un attimo a riflettere; so dove voglio arrivare e so che i miei soci capiscono perfettamente, ma voglio trovare le parole più adatte per una sintesi: “Ovvio che strumenti agili come Scrum in questo caso possono essere molto utili per aiutare a implementare alcuni aspetti, primo fra tutti l’approccio sperimentale e la creazione del prodotto in modo iterativo e incrementale. Anche facilitare la collaborazione fra le varie anime dell’azienda, gli utenti, gli stakeholder sono tutti aspetti di enorme importanza in questo momento di forte sperimentazione. Questa cosa ai responsabili delle aziende è piaciuta abbastanza…”.
“Be’ sì… qui la sfida è cercare di provare a lavorare con un approccio il più metodico possibile, per fare in modo che si possano realmente percepire i benefici di Agile”.
“Hai ragione Fabio. Dovremo aiutarli molto in questo”, concludo.
Se c’è un altro aspetto davvero importante del tornare in presenza è proprio questo. Potersi confrontare faccia a faccia con i colleghi, ricevere da loro critiche — anche quando magari ti “costringono” a rivedere certe tue assunzioni — e consigli che magari ti sciolgono un nodo che, da solo, non si riusciva sbrogliare da giorni. Dal tempo del primo lockdown, però, non abbiamo mai smesso di farlo anche in modalità remota, che ormai è la norma per noi.
Come molti, non tornerei a vivere la vita di prima, perché lavorare da remoto offre indubbiamente dei vantaggi.
Ma tornare di tanto in tanto a lavorare come si faceva prima, quando era la norma stare in presenza nello stesso ufficio, fa apprezzare maggiormente il valore di una conversazione faccia a faccia.
So che tutto questo appare ovvio, ma è importante ripeterlo a se stessi di tanto in tanto.
One-to-one da remoto
Sono ancora positivamente sorretto da quanto discusso con i miei colleghi in presenza quando mi appresto ad avere un colloquio da remoto con Alessio, il CTO dell’azienda. A tutte le persone coinvolte nelle nostre attività ho chiesto di trovare un momento per parlarsi e scegliere su cosa lavorare concretamente nei prossimi giorni, quando ci vedremo in presenza per un workshop.
Alessio è uno di quei dirigenti d’azienda con cui è piacevole lavorare: è esigente, se qualcosa non gli è chiara o non va bene chiede spiegazioni e approfondimenti, se deve fare una critica, la fa. Il tutto sempre con una grande simpatia e tranquillità, molto “romana” e con una grande cura per la comprensione e la preparazione delle attività.
Per questo oggi ci parliamo singolarmente, in videochiamata, proprio per stabilire i dettagli di quanto faremo nelle prossime settimane.
Mi comunica che il gruppo di lavoro ha fatto riferimento al nostro schema “pseudo” OKR e ha scelto di lavorare sull’Objective 1: Ecosistema digitale, e sul KR1: IO XO. Vale a dire che si desidera creare dei prodotti digitali In Organisation e Cross Organisation.
Ma, a questo punto, occorre un ulteriore passaggio esplicativo per capire nel dettaglio come potremmo impostare il lavoro nei prossimi mesi.
La metafora della metropolitana
Inizia la call. Le telecamere sono accese e in condivisione schermo stavolta metto il tablet che userò per disegnare un po’ di appunti per supportare la mia spiegazione.
“Alessio, vorrei farti un esempio che spero ci aiuti a comprendere come potremo dar vita a un ecosistema di prodotti digitali. Ripartiamo dalle definizioni di prodotti I-O e X-O: nel primo caso usiamo questo termine per indicare un prodotto che crei una esperienza utente che attraversa diversi uffici, settori, dipartimenti — chiamali come vuoi — appartenenti alla stessa azienda (o organizzazione); nel secondo si varcano i confini aziendali, per fornire all’utente tramite una esperienza unica, un servizio multi aziendale”.
“OK chiaro. La definizione di I-O e X-O mi è chiara”, mi supporta Alessio.
“Bene…”, continuo “prendiamo ad esempio una metropolitana”.
“E che c’entra… Noi vendiamo automobili e servizi di mobilità annessi e tu mi vuoi convertire tutto in ferrovia?”.
Entrambi ridiamo per un po’. La battuta non è granché, ma ha fatto tornare in mente a entrambi una discussione svoltasi qualche tempo prima durante un workshop di allineamento con gli stakeholder esterni…
“In effetti… meglio non rivangare” dico io sorridendo.
Proseguo mostrando malcelata seriosità: “Mi avete sempre detto che per voi sarebbe importante trovare un modo per scambiare i dati congruenti tra le varie aziende del gruppo, vale a dire la casa madre che gestisce le concessionarie che fanno anche assistenza meccanica, la finanziaria che si occupa di finanziamenti e leasing, l’assicurativa che pensa alle polizze, e la nuova azienda che si occupa di mobilità elettrica”.
“Certo”, mi fa eco Alessio.
“I dati che scambiate all’interno di una azienda (I-O) o tra aziende (X-O) sono diversi: i dati demografici e comportamentali, lo storico delle transazioni e delle interazioni, i dati di utilizzo e funzionamento del prodotto e così via. E tutto questo va fatto nella garanzia che la condivisione e l’utilizzo dei dati rispettino le leggi e le normative sulla privacy e sulla protezione dei dati, come il GDPR in Europa.”
“Esatto… e la metropolitana che c’azzecca?”, chiede Alessio.
“Ci arrivo… Immaginiamo di disegnare una linea che rappresenti i passi che un utente deve svolgere per risolvere un compito. Immaginiamo che questo percorso rappresenti ad alto livello la sequenza di azioni da svolgere per l’acquisto di un’auto con finanziamento leasing potrebbe seguire vari passaggi. passaggi”.
“Li hai già in mente?” mi chiede Alessio?
“Ho in mente un possibile schema”, gli rispondo guardando gli appunti scritti a mano sul mio tablet. “Anzitutto c’è una presa di consapevolezza: l’utente vede una pubblicità televisiva, o un annuncio online o legge un articolo su un nuovo modello di auto che cattura il suo interesse. A questo, probabilmente segue una fase di ricerca e considerazione: l’utente visita vari siti web di concessionari e produttori di automobili per confrontare modelli, caratteristiche, prezzi e recensioni. L’utente inizia a prendere in considerazione l’opzione di un finanziamento leasing come metodo di pagamento”.
Alessio annuisce: “Sì, funziona così”.
“Ecco, a questo punto”, riprendo “probabilmente arriverà il momento della visita al concessionario: l’utente visita un concessionario locale per vedere l’auto di persona, fare un test drive e raccogliere ulteriori informazioni sul veicolo e sulle opzioni di finanziamento disponibili. Diciamo che a questo punto si è convinto di acquistare l’auto; quali altri passaggi restano? Ci sarà con ogni probabilità una richiesta di preventivo e valutazione delle offerte: l’utente chiede al concessionario un preventivo dettagliato, che include il prezzo dell’auto, le condizioni del leasing, la durata del contratto, il valore residuo e l’importo dei canoni mensili”.
Mi fermo un attimo, prima di concludere il discorso. “Ci stiamo avvicinando alle ultime operazioni. Si arriva alla configurazione delle opzioni di finanziamento, con l’utente che lavora con la finanziaria per valutare la configurazione più adatta del leasing. Restano a questo punto due passaggi: l’utente firma il contratto per poter poi procedere al ritiro del veicolo. La sottoscrizione del contratto può essere fatta presso uno dei touch point disponibili, tipicamente il concessionario. In questo caso immaginiamo una operazione totalmente digitale tramite sito web. Infine c’è il ritiro dell’auto: l’utente passa dal concessionario per ritirare l’auto”.
“Sì chiaro: è il viaggio dell’utente nei nostri sistemi” mi conferma Alessio.
“Appunto. In gergo, questo cammino viene detto customer journey, ‘viaggio del cliente’, proprio a rappresentare il viaggio che un utente svolge per passare da uno stato A a uno stato B: in A l’utente ha un bisogno insoddisfatto (il cliente vuole acquistare un veicolo), in B il bisogno è stato risolto (il cliente è riuscito a comprare l’auto). Ti disegno uno schema, che probabilmente è più chiaro”.
“Le casette rappresentano i differenti dipartimenti aziendali, la freccia il percorso metaforico che l’utente compie nel passare da A (dove ha un bisogno irrisolto) a B (dove ha soddisfatto il bisogno). In altre parole, nel viaggio da A a B, l’utente fa delle cose e interagisce con il prodotto provocando eventi che ricadono su entità (uffici, sistemi informativi, dipartimenti…) diverse”.
“Sì, certo. Questa cosa succede tutti i giorni e noi poi dobbiamo riconciliare tutte le informazioni prodotte”, aggiunge Alessio.
“Immagino… Ora, se questa freccia che ho disegnato rappresentasse metaforicamente una linea della metropolitana, ognuno di questi punti in cui un differente ufficio o reparto viene coinvolto, potrebbe essere una stazione”.
“I punti di accesso sono le stazioni, il collegamento è la linea della metropolitana”, esclama Alessio.
“Esatto” confermo io.
Alessio ormai ha capito dove voglio andare a parare e mi anticipa: “Quindi una linea della metropolitana rappresenta un ipotetico percorso che l’utente compie usando il proprio prodotto, percorso che potrebbe essere sempre all’interno dello stesso dipartimento, ufficio, azienda (customer journey di tipo IO) o valicare i confini e coinvolgere altre organizzazioni (customer journey di tipo XO). Stiamo quindi dicendo che noi creeremo una ‘linea della metropolitana’ con sempre più stazioni, il che vuol dire che vogliamo creare un prodotto con sempre più punti di accesso in cui le persone possono accedere a quella linea…”.
Mi rendo conto che l’esempio sta funzionando. Continuo: “Questa linea, in conclusione, trasporta dati. Potremmo rappresentare questa cosa con uno schema come questo che ti disegno”.
“Chiarissimo… ma quindi, se una linea è un prodotto, per arrivare ad avere un ecosistema di prodotti, dovremo creare tante linee della metropolitana con magari anche dei punti di contatto: del resto, nella realtà, ci sono stazioni che sono condivise tra varie linee”.
“Sì, proprio così. Passo dopo passo il disegno diventa una cosa di questo tipo” affermo mentre continuo ad arricchire il mio disegno sulla “lavagna” digitale condivisa online.
“Da una linea si passa a due, e poi tre e poi altre ancora. E nella nostra metafora avremo svariate linee distinte, ciascuna con con varie stazioni”.
“Ma se una… anzi, più d’una di queste stazioni non serve più solamente una linea, ma diventa un nodo in cui diverse linee si incrociano, ecco che da qui siamo arrivati all’applicazione XO, Cross Organisation”.
“E da qui alla piattaforma il passo è breve. Ogni nuova ‘stazione’ che aggiungiamo a una linea equivale ad aggiungere nuovi punti di accesso di quel prodotto digitale, quindi stiamo arricchendo l’esperienza utente per uno specifico prodotto. Viceversa ogni nuova linea che aggiungiamo corrisponde a creare un altro prodotto digitale che va ad arricchire l’ecosistema digitale”.
Tecnologia e organizzazione
“Chiarissimo”. Alessio si ferma un attimo a riflettere. Poi aggiunge: “Senti Giovanni, però una cosa ancora non mi è chiara”.
“Dimmi”.
“Creare questa rete di linee della metropolitana corrisponde a creare tanti prodotti digitali.È certamente una bella sfida, tecnologica certo, ma ancor più organizzativa. Per la parte tecnologica so che ci aspetta una sfida non banale, ma so anche che ci aiuterete voi e so che la saprete gestire.
Quello che mi preoccupa maggiormente è l’aspetto organizzativo derivante dal dover mettere d’accordo le differenti anime dell’azienda per trovare i punti di contatto — le stazioni —, fondere processi, scambiarci dati, fornire soluzioni comuni agli utenti. Dovremo lavorare molto su aspetti ‘politici’ per agevolare questa collaborazione fra tutti gli attori coinvolti, fra i diversi uffici. Far sì che le varie ‘fazioni’ non si facciano la guerra ma che anzi collaborino. E questo è compito mio, trovare una strategia comune mettendo in evidenza i benefici per tutti legati al collaborare insieme. Ma ipotizzando che si riesca a risolvere l’aspetto culturale , come possiamo fare per far emergere i punti di contatto? Come capire quali sono gli scambi che possiamo attivare? Perché, se vogliamo offrire all’utente un nuovo servizio, che sia anche solo la fusione di due già esistenti, in modo che la somma risultante sia qualcosa di più, dobbiamo lavorare per identificare i punti di connessione… Come si fa?”.
“Ah! Hai toccato il punto più importante” affermo. “Cerco di risponderti prendendo in esame l’esempio che abbiamo appena visto, quello dalle linee della metropolitana. Partendo da queste connessioni, potremmo poi definire le parti che le compongono e arrivare a sviluppare per esempio un servizio web che permetta all’utente di viverlo”.
Alessio mi pare perplesso: “Sì, tutto chiaro. Ma di fatto hai elegantemente schivato la mia domanda. In questo esempio infatti hai unito in un unico viaggio la parte relativa alla consultazione, l’acquisto, la contrattualizzazione del leasing e il ritiro. Questo che hai raccontato è un esempio piuttosto chiaro: non dico che avrei saputo disegnarlo a memoria, ma quasi. Il problema, però, si ha quando dobbiamo mettere insieme diversi pezzi che non sappiamo come collegare o addirittura che forse non ha senso mettere insieme. Come si procede in questi casi?”.
“OK, chiaro cosa intendi. Dobbiamo trovare una connessione fra viaggi differenti in modo che questi siano collegabili fra loro e far si che il viaggio risultante non solo sia utile per l’utente, ma che lo sia più di quanto possano esserlo i due viaggi presi isolatamente.
Di fatto quindi creare nuovi viaggi partendo da alcuni già esistenti. Un modo, quello più semplice come abbiamo raccontato nell’esempio di prima, potrebbe essere quello unire tanti viaggio differenti per esempio in questo modo:
“E come si fa a creare le connessioni?” mi incalza Alessio.
“Ci sono vari approcci. Noi ne proponiamo uno che si chiama Digital Bazar”.
“Digital Bazar… certo…”. Alessio adesso mi guarda come il vigile urbano che ascolta Ugo Tognazzi nel film Amici miei, quando imbastisce il dialogo nonsense ma convincente…
Digital bazar e integrazione semantica dei dati
“Che cosa è questo Digital Bazar e soprattutto, perché introduciamo questo concetto?”.
“Ecco, appunto, perché?” mi chiede Alessio.
Cerco di rispondere in modo lineare, sapendo che comunque finirò per aprire ulteriori interrogativi: “Partiamo dal principio che noi vogliamo creare delle customer journey a partire dalla composizione di ‘viaggi esistenti’. La realizzazione di questa customer journey sarà più efficace per tutti se si parte dal concetto di scambio — o mercato, bazar — di risorse. Sarà più vantaggioso per l’utente: per esperienza il viaggio risultante funziona meglio perché le connessioni sono più forti. E sarà più vantaggioso per chi eroga i servizi offerti a partire dai dati, se si analizzano i flussi di dati, o più genericamente di risorse, nell’ottica dello scambio”.
“Non capisco”. Il mio interlocutore è realmente perplesso.
Cerco un esempio: “Supponiamo che l’ufficio pincopallino offra un determinato servizio all’utente; questo servizio che diventa un customer journey quando l’utente usa quel servizio. Per essere erogato, quel servizio avrà bisogno di informazioni in input. Per esempio, per effettuare un banale download di un modulo in PDF, il servizio necessita dei dati per completare il modulo e dell’indirizzo email dell’utente a cui inviarlo. Viceversa, al termine dell’esecuzione del servizio, il sistema avrà delle risorse: ci saranno dei dati frutto della computazione, come il file PDF che lui stesso ha prodotto ma anche alcuni dati acquisiti durante l’esecuzione. Queste risorse possono essere ‘barattate’ con qualcun altro nell’ottica di uno scambio con mutuo beneficio, come avviene in un mercato, in un bazar. Mi segui?”.
“Forse… Ma quindi cosa significa mutuo beneficio e come si ricollega alla domanda iniziale? In che modo questo ci aiuta a trovare le connessioni fra servizi, a collegare viaggi differenti e, in definitiva, a far sì che dipartimenti differenti possano collaborare per creare servizi compositi?”.
“Prova a vederla in questo modo”, riprendo. “Abbiamo due servizi: serivizioA e serivizioB; questi sono offerti da due applicazioni A e B, che normalmente l’utente usa separatamente, con due ‘viaggi’ separati: customer journey A e customer journey B. L’esecuzione del servizioA magari produce tutta una serie di dati (a1, a2, a3, a4…) che potrebbero servire a servizioB, come input. Ma, al contempo, serivizioB potrebbe poi produrre altri dati (b1, b2, b3, b4…) che potrebbero essere utili a servizioC o nuovamente a servizioA”.
“Be’, sì. Questo è sensato”, aggiunge Alessio.
“Pensa ora al fatto che un utente potrebbe risparmiarsi il fastidio di inserire più volte gli stessi dati perché magari il servizioA li ha già ‘in pancia’ e li può cedere a servizioB… Avremmo un utente più felice di usare i due serivzi in modo più semplice. Lo stesso per vale per l’integrazione delle due applicazioni A e B: se semplifichiamo l’aspetto tecnologico, magari potrebbe essere più semplice creare un flusso che le metta in insieme perché A offre i dati (a1, a2, a3, a4…) a B e viceversa”.
Alessio mi conferma che, a poco a poco, il concetto sta passando: “OK, mi è chiaro. Ma nella realtà questo succede spesso?”.
“Be’, più di quanto si possa immaginare. Del resto, in un ecosistema digitale, i customer journey di diverse aree di business, segmenti di mercato e tipologie di necessità utente possono avere interconnessioni e punti di scambio. I dati prodotti in un determinato passaggio di un customer journey possono diventare input per un altro ‘viaggio utente’, creando opportunità per scambi di dati tra i vari contesti. Questa interconnessione può portare a una maggiore personalizzazione dell’esperienza del cliente e a una migliore comprensione delle loro esigenze e preferenze”.
“Sì, è vero”, interviene Alessio. “Ma per andare ancora più sul pratico?”.
“Ti faccio un piccolo elenco di casi tipici che abbiamo raccolto nelle nostre indagini ed esperienze”, rispondo. “Ovviamente sono casi ‘teorici’, ma in fin dei conti nemmeno troppo”.
Gli esempi sul modo in cui i dati possono essere scambiati tra diversi customer journey derivano da quanto abbiamo potuto vedere in precedenti esperienze, ma sono anche il frutto di una riflessione che abbiamo compiuto insieme ai miei colleghi. Avevo quindi già preparato un elenco schematico, che leggo ad Alessio. Le cose che gli dico sono le seguenti.
Dati demografici e comportamentali
Le informazioni raccolte su età, sesso, località geografica, interessi e comportamenti online dei clienti possono essere utilizzate per personalizzare le esperienze di acquisto in diversi settori e tipologie di prodotti.
Storico delle transazioni e delle interazioni
I dati relativi alle transazioni e alle interazioni passate del cliente con un’azienda possono essere utilizzati per anticipare le esigenze future e offrire prodotti o servizi correlati. Ad esempio, se un cliente ha acquistato un’auto con un contratto di leasing, potrebbe essere interessato a estendere il leasing o a stipulare un nuovo contratto per un altro veicolo.
Feedback e recensioni
Le recensioni e i commenti lasciati dai clienti su un prodotto o servizio possono essere utilizzati per migliorare l’offerta in un’area di business correlata. Ad esempio, se i clienti si lamentano di un servizio di assistenza post-vendita in un settore, l’azienda può utilizzare queste informazioni per migliorare l’assistenza post-vendita in altre aree di business.
Dati sui canali di marketing e comunicazione preferiti
Le informazioni sui canali di marketing e comunicazione preferiti dai clienti — ad esempio, e-mail, social media, messaggistica istantanea — possono essere utilizzate per ottimizzare le strategie di marketing e comunicazione in diversi settori e segmenti di mercato.
Dati di utilizzo e comportamento del prodotto
Le informazioni sull’utilizzo e il comportamento del prodotto da parte dei clienti — ad esempio, frequenza e tipo di manutenzione, funzionalità più utilizzate — possono essere utilizzate per migliorare e personalizzare l’offerta di prodotti e servizi in altre aree di business.
Verso il workshop
“Adesso è molto più chiaro”, mi dice Alessio.
“Sono concetti semplici, se vuoi, ma metterli tutti insieme ovviamente crea complessità. E questa complessità richiede del tempo per essere assimilata”, rispondo. “Ma vedrai che con il workshop della settimana prossima riusciremo a coinvolgere tutti e a trasferire queste informazioni in modo esperienziale”.
Ne sono convinto, ma c’è ancora parecchio da fare.
Riferimenti
[1] Agile Reloaded
[2] Giovanni Puliti, Digital revolution: La teoria – Tema 2: Il framework OKR. MokaByte 292, marzo 2023
https://www.mokabyte.it/2023/03/08/digitalrevolutiontema-2/
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.