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…

Ecosistema e piattaforma

C’è un modo di dire americano che, almeno in questo caso, prendiamo volentieri a prestito: the big picture, l’immagine completa, il quadro a grande dimensione, la visione globale. Quello che, arrivati a questo punto del nostro percorso di “rivoluzione digitale” nelle aziende con cui stiamo lavorando ormai da quasi un anno, mi appare chiaro è che guardando the big picture si individuano gli elementi che costituiscono il nostro ecosistema digitale, se ne vedono le connessioni In-Organisation (IO) e Cross-Organisation (XO), se ne comprendono le interazioni e se ne può intuire qualche sviluppo. Ma si vede anche che il modo pratico affinché questo insieme di elementi interconessi possa funzionare in maniera seamless e frictionless è rappresentato dal concetto di piattaforma [1] e dalla sua implementazione.

Uno degli aspetti della mia vita lavorativa di cui sono più contento è di essere riuscito, nel tempo, a lavorare spesso con persone piene di idee e di spunti e capaci di suscitare riflessioni e prospettare soluzioni anche con una “banale” chiacchierata. Dirigenti d’azienda con cui ho lavorato per tanti anni, colleghi con cui mi sono sempre confrontato, soci con cui opero ormai da tempo, esperti che ho conosciuto in giro per convegni e conferenze. Un po’ dipende dal cercar di lavorare con uno standard che tende al miglioramento. Un po’, probabilmente, è anche fortuna.

Tra queste persone c’è colui con cui parlerò oggi. È un esperto di primo livello sul tema delle piattaforme digitali su cui, ormai da parecchi anni, lavora con la sua azienda [2] essendo riuscito a realizzare una soluzione implementativa adattabile a situazioni disparate.

Giulio è un ingegnere “atipico” rispetto a un certo cliché che forse sarebbe ora di superare: assolutamente informale eppure rigoroso, notevolmente “visionario” — nel senso di capace di visione innovativa —ma sempre legato alla concretezza di quel che sta realizzando, molto aperto alle novità e alle proposte meno scontate, ma senza prendere le sbandate che abbiamo visto percorrere da certi imprenditori troppo innamorati del loro sogno per rendersi conto dell’irrealizzabilità della propria visione, una volta messa a confronto con la realtà.

Per questo oggi ho deciso di vedermi con lui di persona, il che assume un valore particolare: nonostante la frequentazione assidua per videoconferenza, messaggi e quant’altro, è davvero tanto tempo che non ci vediamo in presenza. E in più, considerando la sua agenda fittissima, il fatto che anche lui sia apparso molto contento di questo incontro, mi ha fatto ancor più piacere.

Muoversi sopra (e sotto) la piattaforma

“Ma non sei al telefono? Cosa è successo?”. Apostrofo così il mio collega che mi accoglie nel suo ufficio. In effetti è strano: a volte ho il dubbio che l’auricolare sia un’appendice naturale del suo corpo, più che un dispositivo elettronico che usa.

“Oggi giornata tranquilla”, ribatte scherzando. “Prevedo solo 12 ore al lavoro…”.

Ridiamo entrambi e ci sediamo. Una delle cose buone della comunicazione a distanza è che comunque non si è interrotto mai nulla. Non percepisco il tanto tempo passato dall’ultima volta che ci eravamo incontrati in presenza, semplicemente perché sono state tante le volte in cui ci siamo sentiti a distanza. Ed è anche per questo che Giulio conosce già, almeno a grandi linee, il percorso fatto fin qui con le aziende automotive che stiamo “integrando”.

“A questo punto, Giovanni, è arrivato il momento di dare ai clienti qualcosa di pratico, no? Cioè, non che fino ad adesso non gli abbiate fornito consapevolezza, metodi, strumenti per la gestione dei dati. Però, a quel che mi dicevi, adesso la situazione è matura per introdurre qualcosa di tangibile, o meglio, uno strumento globale che abbia impatto percepibile sul business, no?”.

“Esattamente. Ma come facciamo, nel concreto, a implementare questo sistema? Possiamo farlo senza ‘terremotare’ le aziende, agendo in modo progressivo?”.

Giulio ci pensa un po’, e capisco che sta visualizzando delle immagini: sta ricostruendo i silos aziendali, le linee di relazione tra le diverse aziende (B2B) e i rapporti con i clienti (B2C).

Domini applicativi vs. necessità risolta

“Allora, Giovanni, partiamo da questo discorso”.

Capisco che Giulio ha visualizzato una possibile soluzione e sta per descrivermela.

“Prendiamo, come esempio, solo un paio dei domini che riguardano le aziende con cui state lavorando: il dominio dealer — o chiamalo ‘concessionario’, ‘venditore’, come vuoi — e il dominio cliente. Ecco, se io mi metto a ‘costruire’ completamente questi domini, ho bisogno di tempo, di denaro e di lavorare parecchio prima di averli pronti. Non sono elementi inutili, eh. Sono domini reali, che esisteranno anche nel nostro sistema a piattaforma. Ma c’è un rischio grosso: nel tempo in cui io creo queste entità, spendo dei soldi, impiego del tempo e non vedo alcun impatto sul business. Il cambiamento è troppo tardivo e l’investimento di tempo, denaro ed energie non apparirà giustificabile per l’azienda. È un rischio concreto”.

Con poche parole Giulio ha perfettamente inquadrato quel che io già temo da un po’ di tempo. Continuo ad ascoltare quanto ha da dire.

“Ma se noi adottiamo un approccio incrementale, e ci diamo dei tempi di scadenza, questo rischio dell’apparente inutilità viene meno. Diciamo che stabiliamo dei punti fermi nel nostro panorama temporale: per fare un esempio, non vincolante, a un mese, a sei mesi, a un anno. E poi ci diciamo: qual è il problema che vogliamo risolvere da qui a un mese? Sarà qualcosa di piccolo, ovviamente, che però deve avere un effetto positivo e visibile sul dealer e/o sul cliente. Ti devi chiedere quale sia quella funzione, quel ‘qualcosa’ che possiamo implementare e che faciliterà il lavoro che devono fare appunto il dealer o il cliente o tutti e due. A me viene in mente, perché è una cosa su cui stiamo lavorando su un cliente, una funzionalità di traduttore del VIN, il Vehicle Identification Number (numero di identificazione del veicolo)”.

“Sì, questo è un tema che è già emerso”, mi inserisco. “I concessionari in effetti questo problema ce l’hanno, perché i produttori dei vari Paesi usano standard diversi per costruire questo numero identificativo, con formati diversi e addirittura numero di caratteri non corrispondente, per i veicoli più vecchi”.

“Ecco,” riprende Giulio, “un traduttore da un codice a un altro può essere molto utile ai dealer che devono cercare su sistemi diversi un veicolo. Questo è uno strumento molto semplice, che però ha vari vantaggi. Oltre a facilitarti un lavoro, ti mette già in connessione elementi diversi che staranno sotto la piattaforma e consente di preparare la struttura anche tecnologica che poi servirà per installare la piattaforma. L’aspetto cruciale è che tutti vedranno, in tempi brevi, che questa cosa funziona. Per ora fa poco, ma rispetto a prima c’è stato un cambiamento positivo e un problema risolto. Forse anche già un impatto sul business, se non altro per il risparmio di tempo… Da qui si può passare ad altre funzioni diverse, ma simili per approccio: la profilazone del cliente, per esempio. Lo storico dei veicoli posseduti…”.

Tempi di esercizio ed evoluzione della piattaforma

Chiedo a Giulio quel che so già mi verrà chiesto da alcuni dei manager delle aziende, ossia quanto tempo ci voglia per installare e far partire l’infrastruttura tecnologica su cui poi gireranno le funzioni della piattaforma embrionale, come quelle appena descritte.

Giulio dà una risposta piuttosto secca: “Nel mese di tempo che ci siamo dati c’è tutto lo spazio per fare anche l’installazione di tutto. Chiaramente poi bisogna vedere come e dove si installa la soluzione: un’infrastruttura self-hosted sulle macchine dell’azienda presuppone tempi e costi maggiori, mentre, con un pacchetto cloud, in un giorno tutta l’infrastruttura è montata. Va comunque considerato che si può partire con il cloud e migrare poi in seguito alla soluzione self-hosted… non sono vicoli ciechi. Oltretutto le migrazioni sono fattibili in continuità senza down time o con tempi di disconnessione davvero minimi. Deve essere per forza così, perché uno dei motivi che convincerà all’adozione è anche la garanzia di una business continuity. Non è che a ogni incremento, a ogni ‘versione’ tu poi devi ricostruire tutta l’infrastruttura, la sicurezza, l’autenticazione, l’autorizzazione etc. Essa evolverà in maniera incrementale e senza strappi”.

Incalzo Giulio: “Questo concetto della piattaforma che passa di versione mi fa venire in mente come spesso l’utente percepisca il cambiamento sostanzialmente come cambiamento di interfaccia, più che della logica che ci sta sotto o dei dati che la alimentano. Quanto influisce questo aspetto sul processo di crescita della piattaforma?”

“Dipende molto dalla governance che si vuole adottare: si può pensare di cercare una massima uniformità nel tempo oppure decidere di cambiare di più, chiaramente solo ad ogni major version”.

L’IT muove il business

“Credo inoltre”, continua Giulio, “che in un discorso del genere pesi anche questa considerazione: sono cambiate delle sensibilità all’interno delle aziende. Si è capito ormai che l’IT muove il business e le due cose vengono viste sempre meno in maniera separata. Noto, ad esempio, che i C-Level dell’IT sono sempre meno persone di formazione strettamente tecnica, ma invece sempre più persone provenienti dal business che sanno parlare con i tecnici e sanno tradurre le esigenze del business ai tecnici e, viceversa, spiegare al business ciò che l’IT può o non puà fare. E questi C-Level hanno un vantaggio: sanno che i tempi del business sono molto più veloci di quelli tecnici e quindi cercano anche di ‘prevedere’ in anticipo quali potranno essere le richieste del business, in modo da non trovarsi poi in affanno. Poi è chiaro che non è sempre così, che ci sono realtà in cui diventa difficile far parlare questi due mondi… Ma il fatto è che oramai il business si fa sempre più con il digitale e quindi diventa importante che questi due mondi si parlino e si comprendano. Noi che veniamo dal mondo Agile parliamo spesso di feature team ma altri usano il termine fusion team che forse, per quello che esprime, è anche più giusto. Se il digitale non fuziona, il business non viene erogato”.

Di Giulio continua a sorprendermi sempre questo costante “ping pong” tra una visione di business ad alto livello e un pragamatismo tecnologico ancorato alla concretezza.

“Per questo”, continua Giulio, “quando diciamo che Business e Digital/IT lavorano insieme non vogliamo dire che hanno lo stesso backlog, perché alla fine devono fare cose diverse. Ma intendiamo dire che daranno lo stesso nome alle stesse cose e guarderanno le stesse dashboard, cercando di capirsi bene. La piattaforma ti garantisce questo: che tutti guardiamo la stessa cosa, perché non ci sono più ‘cose’ al di fuori della piattaforma, ma tutto è contenuto in essa ed esposto dalle sue interfacce, in maniera svincolata dalla provenienza del dato”.

Marketing interno per arrivare a completamento

“Un aspetto importante nel nostro processo incrementale è che lo possiamo ripetere, più volte, come dicevo. Prima implementi una funzione piccola ma efficace, che risolve il problema. Poi ne fai un’altra, sempre in tempi brevi, poi un’altra ancora…”.

A questo punto, però, il discorso di Giulio non mi quadra più. Se io implemento una soluzione puntuale, e poi un’altra e poi un’altra, per quanto siano efficaci in tempi rapidi, però non sto creando quell’infrastruttura globale, quella big picture che mi realizza un ecosistema digitale. Glielo faccio notare, con una certa premura.

“Be’, è anche vero.” dice Giulio. “Ma non è che tu continuerai all’infinito con questo sistema. Aver dimostrato che una forma embrionale e limitata di piattaforma è stata in grado di risolvere alcuni problemi, per quanto piccoli, e di avere un impatto sul business, per quanto minimo, ci mette nelle condizioni di introdurre il sistema completo. Dobbiamo fare quello che si chiama marketing interno, ossia cominciare a pubblicizzare e a ‘vendere’ la soluzione all’interno dell’azienda. Con i primi pezzetti implementati noi abbiamo comunque creato, solo per dirne alcuni, un componente di autenticazione, uno di sicurezza, una connessione per il database… abbiamo messo dentro dei dati che magari poi servono anche ad altri, come mi dicevi per il discorso del Digital Bazar… Non ti sembra?”.

“Certo”, confermo.

“Eh. Allora a questo punto, ci sarà qualcuno in azienda che, opportunamente interessato dalla nostra azione di marketing interno, vorrà connettere alla piattaforma il suo caso, i dati che gli interessanto, la funzione di cui ha bisogno. E in questo modo la piattaforma cresce, si aggiungono nuovi componenti e nuove funzioni, si accede ad altri dati che magari sono di interesse per altre persone ancora e così via. Con questo sistema ad apposizione, per rimanere nella tua metafora dell’ecosistema, la piattaforma funge da terreno fertile su cui possono crescere tante piante diverse che a loro volta attireranno insetti e altri animali e costituiranno un ecosistema sempre più complesso. La piattaforma diventa, appunto, una base sotto la quale ci sono tutti i dati e i meccanismi e sopra la quale si va a prendere ciò che serve di volta in volta, senza più preoccuparsi troppo di come inizialmente quel dato o quella funzione è entrata nel sistema, almeno a livello di utente finale. L’impatto sul business dell’azienda, in particolare di azienda grande in senso internazionale, diventa potenzialmente enorme”.

Piattaforma come prodotto

“Abbiamo parlato di marketing interno, e il marketing si fa con un prodotto. Quindi la piattaforma che consideriamo uno strumento deve diventare un prodotto: deve avere un nome e una riconoscibilità, deve esserci un luogo in cui trovo le informazioni al riguardo, che sia un forum, un blog o un wiki. Serviranno dei momenti di dimostrazione e di formazione. Ci saranno degli early adopters che faranno migliorare il prodotto nelle prime fasi ancora ‘imperfette’. E servirà un platform team che prenderà in carico tutta una serie di attività di manuntenzione e miglioramento della piattaforma. È la stessa cosa che gestire il lancio e l’affermazione di un qualsiasi altro prodotto”.

“Ti seguo”, lo incalzo, “ma in certi casi ci saranno anche degli oppositori all’adozione di questo prodotto, no? Ci saranno, che so, dei manager a cui interessa principalmente di portare a compimento il loro pezzetto di business, con il loro silos e il loro monolite, e che si disinteresseranno totalmente della piattaforma”.

Giulio valuta un po’ la mia obiezione. Poi aggiunge: “Però se la piattaforma funziona davvero e ha un impatto sul business, alla fine sarai quasi ‘costretto’ ad adottarla. Semplicemente perché con questa fai meglio o in meno tempo le cose che dovresti fare comunque con maggior dispendio di tempo e/o energie. E se la piattaforma non ha questo appeal vuol dire che è fatta male, in maniera non adatta all’azienda in cui dovrebbe funzionare. Allora è giusto che fallisca… Ma se la piattaforma ha dei risultati tangibili… alla fine tutti, dai C-Level all’utente meno predisposto, saranno invogliati ad adottarla”.

Opportunità, rischi, errori

“Guarda Giovanni, ti racconto una cosa che ho visto qualche tempo fa a una conferenza. È stata presentata una slide che mostrava un’idea di piattaforma disegnata da un C-Level e la cui implementazione doveva essere in carico all’IT. Stiamo parlando di un’azienda molto molto grande. Che cosa ci dice tutto questo?”.

Sono perplesso e non capisco subito dove vuole arrivare Giulio. Gli faccio, a mia volta, una domanda: “Eh, ma scusa. Come ha fatto il manager di alto livello a ‘progettare’ questa idea di piattaforma? Chi glielo ha detto?”-

“Per come era fatta, la piattaforma ricordava le prime incarnazioni del concetto di piattaforma, tipo quella di Uber di dieci anni fa per capirci: ci sono n canali, n applicativi, un core di dati… non è niente di eccezionale. Ma la risposta a quello che ti chiedevo prima è che il motivo per cui l’ha fatta… è che ne aveva bisogno, gli serviva qualcosa del genere, era una sua esigenza, o meglio un’esigenza dell’azienda”.

“Chiaro” gli faccio eco. “Ma non sempre è così”.

“Perche tu stai pensando a certe ‘grandi’ aziende italiane che però sono piccole rispetto alle enterprise company internazionali. E in queste aziende davvero enterprise una piattaforma può avere un impatto sul business nettamente tangibile, anche con certi errori che si possono commettere”.

“Quali?”

Giulio non ci pensa e risponde velocemente: “Ci sono varie sfide in questo percorso, con tante opportunità, ma anche rischi ed errori. Il primo errore, secondo me, è pensare di farsi la piattaforma in casa, da soli. Quindi finisce che ogni team o ogni dipartimento in pratica reinventa la ruota innumerevoli volte, pensando che il suo business, le sue caratteristiche sono così speciali da risultare diverse da tutte le altre. Che un po’ è anche vero, ma non significa che servano mille piattaforme diverse. Questo è un rischio grosso che si elimina con una forte collaborazione interna, con un approccio open source che riguardi le conoscenze e le pratiche interne all’azienda. È chiaro che serve una governance, che servono delle linee guida chiare sul modo in cui gestire la codebase comune. Ma è questa la direzione in cui procedere. L’altro aspetto pericoloso è dimenticarsi di far vedere i risultati concreti e in tempi brevi che la costruzione della piattaforma riesce ad avere sul business: diversamente si rischia di vedere il progetto chiuso prima del tempo, con delusione oltre a perdita di tempo e di soldi. Far vedere il valore di business che viene generato è cruciale”.

“Si torna sempre al tema delle misurazioni, che non è facile”, intervengo.

“Non è facile”, mi conferma Giulio. “Pensa a tutte le aziende che hanno adottato questo approccio a piattaforma: quante di queste non avrà dei reali benefici? E cosa succederò di conseguenza? Disillusione. Ma la disillusione è il risultato delle aspettative disattese. Ed è per questo che diventa fondamentale fissare delle aspettative realistiche e raggiungibili per fare business con il digitale”.

Senza smentirsi

Capisco che la chiacchierata sul tema piattaforma è finita. Ci sono stati molti spunti e sono sicuro di tornare dai “miei” manager con le idee molto più chiare e una giusta prospettiva.

“Giulio, a questo punto ne approfittiamo per mangiare insieme”.
“Certo” mi risponde. “Ma una cosa veloce eh. Subito dopo ho una telefonata importante”.

E potevo dubitarne? Bello avere rassicuranti certezze.

Riferimenti

[1] Giovanni Puliti, Digital revolution: La teoria – XII parte: Che cosa è una piattaforma digitale? MokaByte 296, luglio–agosto 2023
https://www.mokabyte.it/2023/07/12/digitalrevolution-12/

[2] Mia Platform: Platform Builder per scalare il mondo Cloud Native
https://mia-platform.eu/it/