E se provassimo a cambiare approccio nella Governance della Trasformazione Digitale? Il metodo G.and.A.L.F.

Il metodo G.and.A.L.F.[1], ovvero da DevOps a GovOps

C’era una volta, tanto tanto tempo fa, un mondo in cui era possibile pianificare upfront grandi sviluppi e piani quinquennali. Era un mondo in cui qualcuno (un capo, una burocrazia, un gruppo di esperti) poteva chiudersi in una stanza (o in un palazzo, un ufficio, o qualunque fosse il nome del centro di potere) e pianificare nel dettaglio grandi piani, con impatto sulla vita di decine, centinaia, migliaia e a volte milioni di persone.

Non siamo più in quel mondo. Anche se forse, a dire il vero, quel metodo non ha mai funzionato molto bene: gli effetti collaterali sono stati in alcuni casi devastanti, anche quando i progetti si sono svolti più o meno come “da piano” (si vedano i famigerati “piani quinquennali” dell’URSS di Stalin).

Oggi sempre più abbiamo preso coscienza di vivere in sistemi tecno-umani estremamente complessi. Sia che parliamo di stati che di aziende o programmi tecnologici, la maggior parte delle volte la complessità è tale che nessun gruppo ristretto di esperti, per quanto competenti e intelligenti, può avere tutte le risposte e condurre a buon fine una strategia. È un passaggio epocale, simile a quello avvenuto dal XVI° secolo in poi. Ad un certo punto si prese atto che nessuno poteva avere una conoscenza enciclopedica su tutto lo scibile umano e nacquero così gli esperti e gli specialisti nei diversi ambiti della scienza e della tecnologia (soprattutto a partire dalla seconda rivoluzione industriale). La specializzazione, tra le altre cose, ci ha permesso di andare sulla luna, grazie all’integrazione delle competenze di gruppi di scienziati e di tecnici, in grado di pianificare e realizzare progetti troppo complessi per un singolo uomo, pur geniale come un Leonardo da Vinci. Ora siamo ad un altro cambio di paradigma: i sistemi sono così complessi e la partecipazione di tutti così fondamentale che non basta più nemmeno un gruppo di esperti, serve la capacità di usare l’intelligenza collettiva[2] delle organizzazioni per innovare, sperimentare, raccogliere feedback tempestivi e correggere il tiro. Il tutto in un ciclo decisionale rapido e “umile” nel senso etimologico, ossia legato alla terra, “humus”, quindi alla concretezza della realtà.

In questo nuovo paradigma il coinvolgimento di tutti gli attori, dagli stakeholder all’operaio che lavora in fabbrica, dallo sviluppatore che produce software al personale di sportello che vive in prima persona il contatto con il cliente o il paziente, è fondamentale. La necessità di gestire la complessità ha generato diversi framework metodologici, ma con alcuni principi in comune. Nella produzione industriale, ad esempio, il metodo Toyota, basato sulla cultura Lean, ha cambiato le regole del gioco. Senza entrare nel merito del Lean, possiamo dire che ribalta il paradigma del taylorismo-fordismo, secondo cui era possibile organizzare in modo scientifico e deterministico il lavoro in modo tale che l’operaio diventasse un mero esecutore. Per il paradigma Lean, il coinvolgimento di tutti coloro che fanno parte della catena del valore è fondamentale. Il feedback continuo proveniente dal campo, che consente la correzione e ritaratura dei processi in tempo quasi reale, è un fattore critico per garantire qualità e valore. L’Andon[3] è paradigmatico: qualunque operaio presente nell’impianto in qualunque momento può fermare la produzione. Questo sembra contro-intuitivo, ma in realtà garantisce che i problemi vengano identificati e risolti il più precocemente possibile. In questo senso, l’operaio ha un potere superiore a quello del mega direttore, perché può tirando una corda fermare un impianto industriale!

Qualcosa di analogo è avvenuto nell’ambito della produzione software: dal waterfall si è approdati all’Agile, che ha recepito molti dei valori del Lean thinking.

Perché allora ancora tanti progetti di digital transformation si sono conclusi con fallimenti colossali o con una produzione di valore infinitamente più piccola di quella ipotizzata?

Esporrò ora due tesi che a mio parere spiegano il perché di tanti insuccessi. La prima ha a che vedere con la Governance della trasformazione digitale. Purtroppo, nella Governance dei grandi progetti di trasformazione il vecchio approccio top-down, con un gruppo di esperti che assume di avere tutte le risposte e poter guidare gli esecutori (tutti gli altri), continua ad imperversare. La seconda tesi invece riguarda il fatto che vi sono, almeno per la parte di produzione del software, molti validi framework e principi che potrebbero essere mutuati anche per la Governance, ma spesso l’adesione a questi principi è solo formale e non sostanziale (“lip service”, direbbero gli americani). Questo approccio può far fallire anche progetti sulla carta cosparsi di buone intenzioni e che sventolano tutti gli “slogan giusti”, dall’Agile al Lean, dal “Paziente al Centro” al “Cliente prima di tutto”.

Tesi numero 1, ovvero perché Gandalf e gli Elfi non hanno sconfitto Sauron da soli

Ebbene sì, lo ammetto, anche io avevo l’abitudine di fare Piani Strategici dei Sistemi Informativi di durata quinquennale. Che naturalmente cambiavano ogni 6 mesi. In un’azienda per cui ho lavorato, ci ho messo quattro-cinque mesi a scrivere e condividere il piano strategico dei Sistemi Informativi, poi nei successivi quattro anni abbiamo cambiato quattro Direttori Generali. Ovviamente con quattro visioni completamente diverse delle priorità di business e strategiche dei sistemi informativi! Forse quella situazione era patologica, ma anche in situazioni di stabilità organizzativa è spesso il contesto che cambia repentinamente e richiede, oltre ad una visione di insieme, anche un’agilità continua nell’adattarsi al mutamento. Non sto negando il valore di una pianificazione strategica. Anche Eisenhower diceva: “Plans never helped me. Planning did”. Tuttavia, mi sono convinto che i principi Lean/Agile (ovviamente declinati con strumenti diversi) che abbiamo introdotto nei processi di sviluppo del software e nella produzione industriale DEVONO essere inglobati anche nella fase di Governance. Dato che gli slogan vanno molto di moda, direi che non basta più parlare di DevOps, ma bisognerebbe parlare di GovOps, ossia un flusso continuo tra le decisioni strategiche, la realizzazione e la messa in produzione di nuovi servizi.

Oggi purtroppo non è così. In un recente incontro, un responsabile di una software factory agile mi diceva che in molti casi il suo team deve inventarsi dei “trasduttori” per mettere in comunicazione meccanismi di Governance top-down e decisamente waterfall delle aziende clienti con il modo di lavorare agile del team. In questo caso non si può ovviamente parlare di un’azienda agile, ma al massimo di una realtà che implementa le decisioni in modo agile e veloce, ma che magari ci mette mesi o anni per arrivare ad una decisione. E questo non è l’unico problema, perché spesso la decisione strategica o di governo viene presa senza tenere conto dei feedback provenienti dal campo, quindi con elevate probabilità di essere sbagliata! Purtroppo però la sindrome del supereroe (o dell’Übermensch di Nietzsche?), o dell’élite che sola al potere decide per tutti, è ancora diffusissima.

Le conferme che un approccio diverso funziona meglio sono molteplici. Ho già citato Lean e Agile, potrei aggiungere la teoria delle organizzazioni Teal[4] di Laloux, ma forse la conferma migliore che per le grandi imprese serve un approccio diverso è nella storia delle storie: sto parlando naturalmente del “Signore degli Anelli”.

[attenzione: spoiler ahead!]

Gandalf e gli Elfi erano i “supereroi” della situazione. Avevano poteri e conoscenze che andavano molto al di là di quelli di tutti gli abitanti della Terra di Mezzo. Eppure, di fronte alla grande sfida della gestione di una “tecnologia” potente come quella dell’Anello (che rappresenta il potere), fecero alcune scelte interessanti. Le descriveremo brevemente attraverso l’enunciazione di sette temi o principi. Legheremo ciascun tema a un titolo o un’immagine, che lo identifichi come elemento chiave del modello di Governance che emerge:

  1. Gandalf, Elrond e Aragorn (i “leader”, potremmo dire) definirono in modo chiaro il valore condiviso: salvare la Terra di Mezzo da Sauron. Questo è l’unico aspetto immutabile della strategia, tutto il resto è andato diversamente da come previsto. [“Salviamo la Terra di Mezzo”: Governance fortemente ancorata su obiettivi strategici condivisi].
  2. Sempre i nostri leader definirono anche, non senza difficoltà (sui principi si trova più facilmente un accordo), il risultato atteso (outcome) per concretizzare il valore, ossia la distruzione dell’anello. Non andarono oltre, non fecero piani dettagliati a cui attenersi, ma legarono in modo chiaro il risultato atteso all’obiettivo strategico comune, superando così le obiezioni di chi voleva utilizzare l’anello come arma per sconfiggere Sauron. [“Distruggiamo l’anello”: Governance che definisce in modo chiaro e verificabile il risultato atteso (outcome), fortemente ancorato agli obiettivi strategici condivisi].
  3. Coinvolsero nel processo decisionale tutti gli abitanti della Terra di Mezzo: Uomini, Nani, Elfi e sì, persino gli insignificanti e apparentemente deboli Hobbit. Il consiglio di Elrond è un bell’esempio di processo decisionale fortemente dialettico ma condiviso [“Il Consiglio”: Coinvolgimento nella definizione della strategia e nella Governance di tutti gli stakeholder].
  4. Anche per la fase di execution, il Consiglio di Elrond diede mandato ad un gruppo fortemente rappresentativo di tutti gli abitanti coinvolti, la Compagnia dell’Anello. Anzi, nella compagnia gli ultimi (gli Hobbit) erano addirittura più rappresentati delle altre genti (quattro membri su nove). Si noti che, a sottolineare lo stretto legame tra il Consiglio e la Compagnia, quest’ultima era costituita in gran parte da membri del Consiglio (a cui si unirono altri membri come Sam, Merry e Pipino). [“La Compagnia”: coinvolgimento nell’ execution di tutti gli stakeholder, in stretto legame con il Consiglio].
  5. Il piano era definito a grandi linee, ma nell’esecuzione ci fu spazio per un livello elevato di flessibilità: in questo modo la Compagnia riuscì a gestire i tanti imprevisti utilizzando i feedback continui provenienti dal contesto [“Non puoi bagnarti due volte nello stesso Brandivino[5]”: lo slogan sottolinea che bisogna abbracciare il cambiamento, che va gestito tramite il feedback continuo e l’adattabilità].
  6. Oltre che essere rappresentati in numero elevato nella Compagnia, gli esseri meno potenti della Terra di Mezzo (gli Hobbit) ebbero un ruolo fondamentale nell’impresa, sia a livello operativo che decisionale, perché si trovarono nelle condizioni di raggiungere i risultati migliori (avvicinarsi al Monte Fato senza essere individuati da Sauron). Alcune scelte di Sam e Frodo si rivelarono fondamentali per la buona riuscita del progetto. Insomma, il ruolo e il peso nel processo di governo e di esecuzione non dipendono dal potere detenuto o dalla carica ricoperta, ma dalle capacità e dagli outcome (risultati) che ciascuno può raggiungere [“Hobbits first”: il peso decisionale ed esecutivo non dipende dal ruolo o dal potere ma dalla capacità di dare un contributo rilevante rispetto al contesto e dagli outcome che ciascuno può raggiungere].
  7. Durante l’esecuzione del piano, ogni componente della Compagnia dell’Anello aveva talmente interiorizzato il valore e la strategia da poter prendere anche decisioni autonome altamente efficaci. Anche qui ci furono errori e deviazioni, come la momentanea follia di Boromir, ma anche questo servì all’obiettivo finale [“Ogni membro della Compagnia è la Compagnia”: è il principio olografico della parte nel tutto, il tutto nella parte[6]].

Chi ha letto il Signore degli Anelli, sa che il metodo “Gandalf” ha funzionato alla grande, perché coinvolgere tutti gli attori della Terra di Mezzo e adattarsi continuamente erano elementi fondamentali per la riuscita dell’impresa!

Questo vale anche nell’attuale momento storico. Infatti, la differenza fondamentale tra andare sulla luna e governare un grande progetto di trasformazione digitale sta tutta nel fatto che una trasformazione digitale, per definizione, richiede il cambiamento (tecnologico, organizzativo, culturale) un sistema tecno-umano complesso. Per andare sulla luna bastava un gruppo agguerrito di specialisti e risorse economiche e tecnologiche adeguate. Tutti gli altri stavano a guardare. Per la trasformazione digitale il coinvolgimento di tutte le persone impattate (tipicamente: TUTTI i membri dell’organizzazione e spesso anche gli esterni fruitori dei servizi) è il vero fattore critico di successo. Attenzione che il coinvolgimento di tutti può essere effettuato in tanti modi, anche tramite meccanismi di rappresentanza. Nella Compagnia o nel Consiglio erano presenti i rappresentanti delle diverse genti, era una sorta di “Guiding Coalition”, per dirla alla Kotter[7].

Tesi numero 2, ovvero perché Churchill aveva ragione (i conti non tornano!)

Nel mondo del software, per anni i progetti sono stati governati con un approccio mutuato dall’ambito edilizio o manifatturiero. Del resto, i primi ingegneri erano costruttori di edifici o di prodotti. Quindi anche nei progetti software c’era una fase di analisi e raccolta dei requisiti, una fase di progettazione, una fase di costruzione, una di test e collaudo e poi il passaggio in produzione con la consegna agli utilizzatori. Il metodo era chiamato waterfall, un nome poetico per una predestinazione infausta, traducibile con un fallimento quasi certo. Oggi nessuno può presentarsi ad una riunione dicendo che sposa l’approccio waterfall per lo sviluppo di un’applicazione: sarebbe l’equivalente di un peto in pubblico. Tutti ormai riconoscono che il percorso tradizione presenta rischi così elevati da essere impraticabile per una fondamentale differenza tra i grandi progetti industriali o civili e la costruzione di software: lo sviluppo software è un’opera di “design”, non di produzione industriale. Questo vale per tutte le fasi, dalla raccolta dei requisiti alla scrittura del codice (che è il vero “detailed design”). La fase di produzione, nel ciclo di vita del software, sono le fasi di build e di deploy, che peraltro oggi sono molto spesso automatizzate quindi poco rilevanti. Questo è un concetto fondamentale: se volete rileggetelo bene, oppure immergetevi nell’interessantissimo: “Agile IT Organization Design: For Digital Transformation and Continuous Delivery”[8].

Partendo da questo presupposto (anche se non esplicitato in questo modo), negli anni ’90 Kent Beck diede vita al movimento dell’Extreme Programming (XP[9]), che poi si sviluppò nell’Agile Manifesto. Al manifesto parteciparono, oltre a Kent Beck, tutti i maggiori esponenti della “cultura del software” americana e nella sua semplicità ha aperto un nuovo modo di approcciare la produzione di software. Ne riportiamo il testo integrale nella traduzione italiana:

Manifesto per lo Sviluppo Agile di Software

Stiamo scoprendo modi migliori di creare software,

sviluppandolo e aiutando gli altri a fare lo stesso.

Grazie a questa attività siamo arrivati a considerare importanti:

Gli individui e le interazioni più che i processi e gli strumenti

Il software funzionante più che la documentazione esaustiva

La collaborazione col cliente più che la negoziazione dei contratti

Rispondere al cambiamento più che seguire un piano

Ovvero, fermo restando il valore delle voci a destra,

consideriamo più importanti le voci a sinistra.

Se l’agile aveva l’obiettivo di eliminare il gap tra il cliente e i suoi requisiti e gli sviluppatori, nacque nel 2009 un altro movimento con l’obiettivo di fluidificare il percorso tra lo sviluppo e il passaggio in produzione. Il movimento si chiamò “DevOps” per sottolineare la necessità di avere un flusso continuo (non vi ricorda il Lean?) tra Development e Operations. Il tutto può essere rappresentato con questa immagine:

 

Si noti che l’immagine si focalizza su requisiti/sviluppi/operations e le relative interfacce. Come abbiamo visto prima, c’è un altro confine, quello tra i customer e la Governance che è forse ancora più critico degli altri. Inoltre sul movimento DevOps, che ha avuto grandissimo successo in questi anni, sono stati scritti centinaia di libri. Ne consiglio caldamente uno (almeno per partire), perché è stato scritto come un romanzo e si legge con piacere: “The Phoenix Project”[10].

Gli ingredienti ci sono tutti e, come abbiamo visto nella tesi precedente, forniscono innumerevoli spunti anche alla fase di governo. Allora perché ancora arranchiamo anche nella parte di sviluppo software? Perché tanti progetti falliscono per requisiti mal formulati e per difficoltà nel passaggio tra sviluppo e produzione?

Il motivo sta forse nel fatto che l’Agile Manifesto piacque molto a tutti e fu vittima del suo stesso successo.

In Italia (e non solo) tutti divennero improvvisamente agili, sia nello sviluppo software che nella gestione dei progetti. Quando ripenso a questo repentino mutamento, non riesco a non sorridere ricordando quello che Churchill disse di noi dopo la guerra: “Bizzarro popolo gli italiani. Un giorno 45 milioni di fascisti. Il giorno successivo 45 milioni tra antifascisti e partigiani. Eppure questi 90 milioni di italiani non risultano dai censimenti”. Churchill aveva ragione: i conti non tornavano allora e non tornano oggi, perché tutti gli informatici si sono trasformati in una notte in sostenitori dell’agile. Del resto, dopo la diffusione dell’agile manifesto[11], nessuno ha più potuto esimersi dall’abbracciarlo con entusiasmo, qualunque cosa significasse poi applicare quei principi in pratica. Infatti, non essere agile automaticamente ti colloca nella cerchia dei “non-agili”, il che si potrebbe tradurre, secondo il Dizionario Treccani dei Sinonimi e dei Contrari, in “goffo, impacciato, legato, lento, tardo”. E oggi come oggi nessuno, proprio nessuno, vuole stare tra i lenti e i tardi.

Il percorso verso l’Agile e il DevOps è un cambiamento culturale che richiede tempo e disciplina. Chi lo ha implementato in questo modo è riuscito a diventare un top performer, gli altri sono rimasti all’Agile come slogan di marketing.

Diversi autori parlano ora di “Agile Governance”[12], ma anche qui spesso si tratta di “lip service”. Uno dei primi documenti importanti sul tema fu il report: “Governance for Agile Delivery” del National Audit Office dello UK[13]. Non a caso: UK dovrebbe ricordarvi del progetto di digital transformation dell’NHS, un esempio da manuale di progetto mastodontico gestito con un approccio intrinsecamente top-down e waterfall, con risultati  fallimentari.[14] Vengono spesso citati invece come casi virtuosi di digital transformation in sanità paesi come l’Olanda, la Danimarca, la Svezia e la Norvegia che, anche per le loro dimensioni, hanno attuato progetti meno mastodontici e con una catena decisionale più corta, favorendo quindi la raccolta continua e di feedback e la ritaratura dei programmi basata sul valore prodotto.

Il tema dell’agilità è stato esteso ben oltre l’IT e la Governance dall’IT, fino a parlare di “azienda agile” o di “business agility”, come nell’ormai quasi “storico” (è del 2009): “Business Agility: Sustainable Prosperity in a Relentlessly Competitive World”[15] di Hugos.

Anche qui in molti casi si è trattato di trasformazioni radicali ed efficaci (si pensi ad esempio al caso della Lego), in altri casi di una “moda” come tante che ha lasciato anche qualche vittima sul terreno.

Spunti operativi per il metodo G.and.A.L.F. (Governance [of digital transformation] and Agile-Lean Frameworks)

La domanda che a questo punto viene spontanea è come trasformare i sette principi del metodo G.and.A.L.F. in realtà. La verità vera è che una ricetta non c’è: come tutti i principi, vanno interpretati e calati nel contesto. Tuttavia vi sono alcuni spunti operativi che vorrei condividere, evidenziando cosa è allineato con il contesto culturale del metodo G.and.A.L.F. (che è quello Lean/Agile) e cosa no.

 

TEMAApproccio Top Down (mondo waterfall)Approccio G.and.A.L.F. (mondo Lean/Agile)Esempi/note
Stime tempi e risorseStime definite dal top management, sia su risorse che su tempi di implementazione, che diventano poi milestone indiscutibiliLe stime devono sempre essere fatte (non solo validate) da chi eseguirà il lavoro. Questo è un principio cardine di ben noti framework Agile come SCRUMUn esempio molto interessante dello SCRUM è il Planning Poker[16]
Boundary ObjectsCi sono “oggetti” di comunicazione pre-costituiti e rigidi. Non è importante creare ponti tra le culture, la cultura dominante impone i suoi  modelli comunicativiGli “oggetti” usati per la comunicazione sono creativi e condivisi tra culture diverse. Volete avere un approfondimento sul tema sociologico dei boundary objects? Vi rimando al link nella colonna noteI boundary objects sono un concetto sociologico. Non posso approfondirli qui, ma vi rimando ad un articolo che ho scritto qualche tempo fa per ISACA[17]

 

Gestione delle Cerimonie (eventi, meeting)Gli eventi sono formali, spesso con calendari e agende stabili in anticipo. La formalità porta a grandi sforzi di “preparazione politica pre-meeting”, perché durante il meeting ogni discussione è pericolosaVi sono dei meeting formali, perché comunque il raccordo con la parte alta della Governance aziendale (Board, Direttori…) li prevede. Però si cerca di favorire un dialogo sui contenuti più che il formalismo. Inoltre vi è un raccordo stretto (si veda il tema “Consiglio” e “Compagnia” nei principi) tra la parte alta della Governance e quella operativaPotrebbero essere necessari comunque dei trasduttori tra il formalismo previsto dalle aziende anche in virtù di obblighi normativi e l’approccio snello
Valori e outcomeIn molti casi ci si focalizza sulla realizzazione dei piani perdendo di vista gli outcome. Ancora peggio, spesso gli outcome non sono chiaramente correlati ad un valore aziendaleGrande attenzione innanzitutto alla definizione e gestione di un Valore condiviso. Da qui discendono gli outcome richiesti (negoziabili) e la pianificazione (mutevole)Rispetto all’approccio per valore e outcome misurabili sono debitore a Porter e Teisberg e al loro libro “Redefining healthcare”[18]
FeedbackIl feedback è raccolto in modo discreto in alcuni momenti, ma spesso viene utilizzato per confermare le scelte già fatteUtilizzo esteso del feedback a tutti i livelli: clienti, operatori, sviluppatori, top manager… Uso di strumenti e processi strutturati per fare in modo che il feedback nutra costantemente il processo decisionale e il flusso di lavoroL’agile in generale e DevOps (che nascono dalla cultura “Lean”) fanno della cattura e utilizzo continuo dei feedback un mantra. Cos’altro aggiungere? Che sarebbe utile inglobare anche feedback sugli outcome (in modo analogo ai PREMS e PROMS della VBHC) e feedback sulla Governance, come proposto da Ross e Weill con il loro IT Governance Index[19]
Organizzazione ITFortemente gerarchica, sia a livello aziendale che nell’ambito Sistemi InformativiEsiste una gerarchia, ma mitigata da un approccio fortemente orientato al coinvolgimento di tutti gli attori, alla condivisione della conoscenza, alla gestione dei feedback e agli outcomeCi sono molti testi sulle organizzazioni IT e non IT e non è obiettivo di questo articolo approfondire il tema. Come punto di partenza posso suggerire, per una visione originale anche se non sempre applicabile, il libro di Laloux già citato[20]
Piano Strategico dei Sistemi InformativiDocumento formale e pluriennale che definisce nel dettaglio strategia e piani di sviluppoDocumento con una parte di alto livello su Valore (la più stabile), una più dinamica con gli outcome previsti e una parte di macro-pianificazione che ha l’obiettivo soprattutto di gestire le dipendenze tra diversi programmi (ed è quindi molto dinamica)Attenzione che l’approccio agile non implica assenza di pianificazione: dove serve (gestire dipendenze) la pianificazione è fondamentale. Altro punto caratteristico: il principio del “small batch size” così importante nel Lean e nell’Agile può essere riportato anche qui: ai mega progetti vanno sempre preferiti, ove possibile, a progetti più piccoli e incrementali

Credo di aver condiviso abbastanza spunti sui modelli di Governance della trasformazione digitale auspicabili. Concludo con un’ultima immagine e una citazione, che uso spesso durante le presentazioni, perché è un principio generale della vita quanto mai applicabile anche alla Governance. La domanda sottesa a questo punto potrebbe essere: “Ma quanto complesso deve essere il sistema di Governance?”. La risposta la dà la natura, con il bellissimo frattale rappresentato dal mio cavolo romanesco, e la citazione finale di Einstein!

 Tutto dovrebbe essere reso il più semplice possibile, ma non più semplice (A. Einstein)

[1] G.and.A.L.F. = Governance [of digital transformation] and Agile-Lean Frameworks. Molti dei contenuti di questo articolo sono presentati nel modulo G.and.A.L.F. della eHealthAcademy che AISIS ha tenuto anche nel 2019 insieme a SDA Bocconi.

[2] Si veda ad esempio “Big Mind” di G. Mulgan: https://www.wired.it/play/libri/2018/06/26/geoff-mulgan-big-mind/

[3] Per approfondire il tema dell’Andon (e da lì si apre il mondo del Lean): https://it.wikipedia.org/wiki/Andon_(attivit%C3%A0_manifatturiere)

[4] https://en.wikipedia.org/wiki/Teal_organisation

[5] Fiume Brandivino o Brandywine definisce il confine orientale della Contea nel mondo di Tolkien.

[6] In ogni frammento dell’ologramma è presente tutta l’informazione. Quindi se frammentiamo il supporto che memorizza l’ologramma, ogni frammento contiene l’ologramma. Nei team agili si dice che ogni membro del team ha abbastanza consapevolezza del contesto e degli obiettivi/valori da poter agire con autonomia. Lo stesso succedeva nella Compagnia dell’Anello.

[7] “Leading Change” – Harvard Business School Press – di J. P. Kotter

[8] “Agile IT Organization Design: For Digital Transformation and Continuous Delivery” – Addison-Wesley Professional – di Sriram Narayan

[9] Sull’extreme programming si può partire da qui: http://www.extremeprogramming.org/

[10] “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win” –  IT Revolution – di G. Kim, K. Behr, G. Spafford.

[11][11] https://agilemanifesto.org/

[12] “Solutions for Agile” Governance in the Enterprise (SAGE): Agile Project, Program, and Portfolio Management for Development of Hardware and Software Products” – Sophont Press – di K. Thompson

[13] https://www.nao.org.uk/wp-content/uploads/2012/07/governance_agile_delivery.pdf

[14] https://www.computerweekly.com/opinion/Six-reasons-why-the-NHS-National-Programme-for-IT-failed

https://drive.google.com/file/d/1xAo0k_xAHaphbsCJW0wzg3Npnd42OfMt/view

[15] “Business Agility: Sustainable Prosperity in a Relentlessly Competitive World” – Wiley – M. H. Hugos

[16] https://www.agileway.it/planning-poker-stima-agile-requisiti/

Al di là degli aspetti folkloristici del planning poker, si noti che uno dei punti cardine del metodo è evitare l’anchoring, ossia il fatto che un membro influente/autorevole del team possa influenzare gli altri. Quindi non solo le stime le fa chi lavora, ma SCRUM mette grande attenzione al fatto che chi ha autorità non possa influenzare le stime. È buon senso: solo così le stime saranno il più possibile attendibili.

[17] https://www.isaca.org/Journal/archives/2014/Volume-4/Pages/JOnline-A-Social-Approach-to-IT-Governance.aspx

[18] M. E. Porter, E. O. Teisberg (2006). Redefining Health – Harvard Business School Press

[19] “IT Governance on One Page” – published on CIRS WP n. 349 and Sloan WP n. 4516-04 on Novembre 2004 – P. Weill and J. Ross (https://www.slideshare.net/zeusi9iuto/governance-matrix)

[20] “Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage of Human Consciousness” – Ed. Nelson Parker – di F. Laloux

Articolo pubblicato in anteprima su AgendaDigitale.eu

 

Perché gli sviluppatori (e molti altri professionisti IT) si stanno facendo fregare dallo “smart working” – Ovvero dell’importanza dell’amigdala

Una riflessione su una trappola in cui molti professionisti IT stanno cadendo…

(Why developers (and so many IT professionals) are being fooled by “smart working” – or around the importance of the amygdala)

Leggi tutto “Perché gli sviluppatori (e molti altri professionisti IT) si stanno facendo fregare dallo “smart working” – Ovvero dell’importanza dell’amigdala”

Ricostruire la Customer Experience in sanità: il modo più efficace per gestire le fasi 2, 3, 4… del COVID-19 (e superare l’empasse dell’app Immuni)

Solo una customer experience di valore e significato per l’utente potrà guidare la governance sanitaria nella fase “post acuta” dell’emergenza. Ancora più di terapie intensive e telemedicina. Perché passa da qui non solo la gestione degli asintomatici, ma anche la creazione di un modello patient-centered.

Leggi l’articolo su Agenda Digitale!

 

 

Value-Based Customer Experience: l’innovazione che non c’è in sanità (sia prima che dopo il coronavirus)

Riporto la sintesi del mio contributo al libro edito da ASSD (Associazione Scientifica per la Sanità Digitale).

Il libro in versione digitale completa è scaricabile dal sito dell’associazione.

Perché Amazon e Netflix stanno ridefinendo la customer experience in sanità

Già il titolo, lo so, farà storcere in naso a molte persone. Perché parlare di customer experience e di “cliente” in sanità non è cosa gradita a tutti. Molti avrebbero preferito un patient al posto di customer. Invece ho deciso di lasciare la parola customer perché credo sia importante anche in sanità restare agganciati a quello che avviene negli altri settori, dove chi acquista un bene o fruisce di un servizio è indubitabilmente un cliente. Un C.I.O. americano, Jonathan Manis della Christus Health, disse durante il Digital Health Summit di AISIS[1] del 2019[2] che l’innovazione della customer experience, anche in sanità, la fanno Amazon e Netflix. Perché sì, chi entra in una struttura sanitaria assume volente o nolente i panni del paziente[3], ossia di colui che soffre e tollera tutto, ma nel resto della sua vita è un cliente di servizi di eccellenza come quelli citati. E così le aspettative si alzano: se Amazon mi abitua ad avere un’efficienza operativa estrema, diventa sempre meno accettabile fare delle code interminabili agli sportelli per l’accettazione di una visita o attendere per minuti o a volte ore al telefono prima che un operatore ci dia retta per prenotare un esame.  Se Netflix mi fornisce un’esperienza fortemente personalizzata, è difficile poi accettare di essere parcheggiati in corridoi angusti e anonimi in attesa che il medico chiami il tuo codice identificativo (per rispetto della privacy), oppure digerire il fatto che per un intervento magari alle 4 di pomeriggio si venga convocati insieme ad altre decine di pazienti alle 7 di mattina.

In questo breve approfondimento parleremo quindi di customer experience vista nell’ottica di chi usufruisce dei servizi (i pazienti, ma anche i loro famigliari e caregiver) e del modo di misurarla, proporremo un modello di maturità per gli strumenti per la customer experience in sanità e infine affronteremo uno dei grandi paradossi della sanità. Infatti nel nostro paese (e negli altri con sistemi simili), viviamo la grande ricchezza di un sistema sanitario universalistico, la qual cosa credo possa essere considerata uno dei traguardi di civiltà più importanti della storia dell’umanità, ma che strutturalmente favorisce una customer experience spesso frammentata e a volte onestamente problematica. Questa situazione è comprensibilmente peggiorata nella gestione dell’emergenza del COVID-19, dove gli obiettivi erano altri, ma ora è ancora più urgente intervenire per invertire la tendenza.

Dal CRM alla Value-Based Customer Experience

La customer experience (da ora in poi la abbrevieremo in CX) sembra essere ormai il Sacro Graal del nuovo mondo digitale. Si dice sempre più spesso che il cliente non compra un prodotto o un servizio ma un’esperienza. Innanzitutto va chiarito in cosa si differenzia la gestione della CX (Customer Experience Management o CEM) dalla gestione della CR (Customer Relationship o CRM). In questo ci aiuta un articolo della HBR: Understanding Customer Experience di C. Meyer e A. Schwager[4]. La sintesi è rappresentata nella figura seguente:

Altri hanno parlato di Connected CX[5] e di Intelligent CX[6]. Ognuna di queste definizioni sottolinea un aspetto particolare, ossia l’integrazione di esperienza, la multicanalità o l’utilizzo di strumenti di Intelligenza artificiale. Tutti temi interessanti a mio parere, ma ancora parziali. L’aggettivo che io trovo più appropriato, soprattutto in sanità, è quello di Value-Based CX[7].

Il concetto di valore in sanità è definito dal framework sulla Value Based Healthcare introdotto da M. Porter nel suo famoso articolo sulla HBR del 2005[8]. La formula base è:

 

Patient Value = Health Outcomes / Cost

 

Alcune osservazioni sono importanti. Innanzitutto il valore è sempre definito da parte di chi fruisce dei servizi (paziente e caregivers, il cliente appunto). Inoltre il valore è misurato come un rapporto tra risultati in termini di salute (health outcomes) e costi. Qualcuno ha provato a generalizzare la formula interpretando in modo esteso il numeratore e introducendo tra gli outcomes anche l’esperienza del paziente/cliente[9]:

Qualche esempio può servire a capire perché questa formulazione sia più adatta rispetto ad altri aggettivi come Connected o Intelligent. L’esperienza insegna che spingere in modo acritico sulla connessione e la multicanalità può portare a risultati disastrosi. Se è vero che il cliente gradisce poter interagire con diversi canali, è anche vero che questo può confondere l’esperienza del paziente/cliente e creare un customer journey frammentario e frustrante, soprattutto se i diversi canali non sono gestiti in modo coerente e integrato. Lo stesso esito si ottiene talvolta utilizzando le pur promettenti tecnologie di Artificial Intelligence: i famosi chatbot, tecnologie tra le più citate e abusate, se non integrati correttamente in un contesto organizzativo che preveda l’intervento umano quando necessario, possono generare un’esperienza cliente frustrante e in ultima analisi distruggere e non creare valore. In generale, ogni volta che vi sono due soluzioni con costi simili e noi scegliamo quella che genera un incremento minore degli outcome e della patient/customer experience (magari perché attratti dalla moda dell’intelligenza artificiale o della multi-canalità acritica), stiamo distruggendo valore.

Misurare la Customer Experience

Anche la CX può essere misurata. Un indicatore applicabile a qualunque contesto e molto diffuso, pur con i suoi limiti intrinseci, è il Net Promoter Score[10] o NPS. In sintesi si chiede ad un cliente di valutare in una scala da 1 a 10 la probabilità che hanno di consigliare ad amici e parenti un dato prodotto. La caratteristica del NPS è che i voti 9 e 10 sono considerati “promoter”, quelli sotto il 6 incluso “detrattori” e gli altri neutri. Per calcolare il NPS finale si sottrae la percentuale dei detrattori a quella dei promoter. Quindi avere un NPS elevato è molto difficile. I brand top nella CX sono anche quelli con il NPS più elevato.

Alcuni esempi di NPS di aziende leader: Starbucks 77%, Amazon 62%, Airbnb 74%, Netflix 68%, Tesla ha uno stellare 97%. In sanità il NPS è uno strumento poco utilizzato, con qualche eccezione negli Stati Uniti[11].

La critica principale al NPS è che sia un indicatore troppo “povero” (si basa su una sola domanda) e che andrebbe abbinato ad altre misure. Ad esempio la Value Based Healthcare pone un’enfasi importante, oltre che sulle misure degli outcome clinici, anche sulle misure di esperienza e di outcome percepiti dai pazienti. Queste vengono definite come PREMS (Patient Reported Experience Measures)  e PROMS (Patient Reported Outcome Measures)[12]. Si potrebbe addirituttura pensare di complementare il modello introducendo delle misure di outcome relative all’ esperienza del paziente.

Senza addentrarci ulteriormente nell’ambito specifico delle misure di CX in sanità, ritengo tuttavia che abbinare indicatori specifici di contesto (come i PREMS e i PROMS della Value Based Healthcare) a indicatori più generali come l’NPS possa aiutare a oggettivare un concetto di per sé molto soggettivo, come l’esperienza dei fruitori dei servizi. Gestire bene l’esperienza dei pazienti/clienti ha impatti positivi anche dal punto di vista economico. Infatti, come dimostra uno studio di Deloitte Consulting, le strutture sanitarie con migliori risultati nei PREMS hanno anche migliori performance finanziarie[13].

Il fatto che in sanità in Italia (e non solo) si usino poco questi strumenti è indice di un problema di sistema più vasto, come vedremo nell’ultimo paragrafo.

 

Il paradosso della customer experience in un sistema universalistico

Come anticipavo nella parte iniziale, in Italia e in molti paesi europei viviamo in un sistema che contiene un paradosso importante. Da un lato la sanità per tutti e il welfare universalistico sono a mio parere una delle conquiste di civiltà più importanti della storia dell’umanità: ricordate che i primi due principi della CX in sanità sono quello di poter essere curati (accesso alle cure) e di poterlo fare in strutture adeguate (qualità della cura). Dall’altro, per mantenere questo approccio universalistico, abbiamo rinunciato ad un aspetto di competizione che è il modo migliore per stimolare il sistema verso un miglioramento continuo della CX. Infatti, in sanità abbiamo tradizionalmente concentrato gli investimenti per migliorare la compliance o l’efficienza operativa perché il sistema finanziato distribuisce risorse pubbliche in molti casi attraverso un meccanismo di tetti di budget assegnati alle strutture. Questo, unito ad una domanda non controllata che eccede sistematicamente l’offerta, non crea alcuna competizione per attrarre e ritenere i clienti del Sistema Sanitario Nazionale. Detto altrimenti: qualunque ospedale ha in quasi tutti gli ambiti più domanda di quella che riesce a soddisfare e i tetti di budget assegnati non permettono facilmente di competere per soddisfare nuove aree di bisogno. In molte strutture in cui ho lavorato i tetti di budget si esaurivano sistematicamente a fine novembre. Fanno eccezione a questa regola i pazienti solventi, ma almeno in Italia questi sono una componente molto limitata del fatturato. Se l’80 o 90% del fatturato di una struttura è garantito dal SSN ed ho più clienti di quelli che i miei tetti di budget mi permettono di gestire, non c’è un grande stimolo a investire sulla CX. A dimostrazione di ciò si può verificare che le strutture che possono vantare una CX di eccellenza sono spesso quelle a vocazione totalmente rivolta a pazienti solventi.

Non è semplice qui dire quale sia la strada per uscire da questo paradosso. Non credo che un sistema di competizione pura, sul modello americano, sia la risposta. Quello americano è un sistema che ha dimostrato sul campo di essere largamente inefficiente ed iniquo. Ma non possiamo nemmeno rimanere ciecamente abbarbicati sul sistema attuale per una serie di ragioni:

  1. Anche il sistema universalistico di molti paesi europei presenta delle forti diseguaglianze. In Italia è enorme il divario tra le regioni. E non voglio banalizzare parlando genericamente di nord e sud, perché ci sono alcune regioni del sud che hanno una buona sanità e qualcuna del nord che ha una sanità in grande difficoltà. In questo caso se si vive nella regione sbagliata vengono violati anche i primi due principi fondamentali della CX in sanità (accesso alle cure e cure di qualità).
  2. Il sistema di regole attuale, per i motivi visti sopra, non stimola la competizione positiva tra gli erogatori di servizi sanitari per il SSN e quindi l’innovazione e il miglioramento dei servizi. Questo porta ad un progressivo abbassamento della CX abbinata spesso ad un aumento dei costi non sostenibile nel medio periodo.
  3. Un CX problematica in senso lato rende difficoltose e quindi meno frequenti (o ridotte ai casi di acuzie) le interazioni tra i cittadini e le strutture sanitarie. Questo ha enormi ripercussioni: sappiamo bene che la prevenzione, le diagnosi precoci e la gestione della cronicità sono il modo più efficiente ed efficace di curare o contenere le malattie. L’esperienza del COVID-19 insegna.

L’esperienza di questi mesi di pandemia ha mostrato che cambiare è sempre una sofferenza e nessuna organizzazione umana, che sia un’azienda, un ospedale o una scuola, lo fa se non vi è costretta. Quando però ci sono le condizioni possono avvenire in poche settimane o mesi cambiamenti che normalmente avrebbero richiesto anni. Come ha dimostrato Kotter, se non capisci che il tuo iceberg si sta sciogliendo, non lo abbandoni[14]. Analogamente un sistema che non è costretto ad orientarsi al cliente non lo farà spontaneamente. È fondamentale quindi introdurre dei correttivi a livello di sistema per stimolare una competizione regolamentata e che favorisca una CX di valore. Che sia una riforma inspirata alla Value Based Healthcare e agli outcome[15], al Triple Aim[16] o ad un altro modello, l’importante è compiere il salto culturale dall’ottica a volume (“ti pago per volumi di prestazioni e attività anche prive di valore”) a quella bastata sul valore (“ti pago se fornisci degli outcome clinici e una CX di valore”). Altrimenti l’iceberg si scioglierà, che noi ne siamo coscienti o no, e potrebbe essere troppo tardi per trovarne un altro. E che gli iceberg si stiano sciogliendo, sia in senso figurato che letterale, è una delle poche certezze che questo periodo di pandemie e di sconvolgimenti climatici ci ha lasciato.

 

[1] www.aisis.it

[2] http://digitalhealthsummit.it/component/speventum/speaker/74-jonathan-manis

[3] Da patior=soffro, ossia colui che soffre, che tollera, che attende e perservera con tranquillità: https://www.etimo.it/?term=paziente

[4]  https://hbr.org/2007/02/understanding-customer-experience

[5] https://www.ttec.com/sites/default/files/eb-inside-the-connected-customer-experience.pdf

[6] https://www.contentintelligence.net/it/ci/intelligent-experience-il-futuro-della-customer-experience

[7] https://www.mckinsey.com/business-functions/marketing-and-sales/our-insights/linking-the-customer-experience-to-value#

[8] https://www.hbs.edu/faculty/Publication%20Files/20050627%20IHI%20Impact%20Meeting%2006272005%20Final-NV_c5acc589-9f69-48db-9c64-75df74dc30a5.pdf

[9] https://www.raslss.com/healthcare-shift-volume-value/#gsc.tab=0

[10] https://www.netpromoter.com/know/

[11] Si possono vedere alcuni dati di realtà statunitensi, previa registrazione gratuita, su Customer Guru (https://customer.guru/net-promoter-score/industry/healthcare-hospitals-and-care-institutions)

[12] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4089835/

[13] https://www2.deloitte.com/content/dam/Deloitte/us/Documents/life-sciences-health-care/us-dchs-the-value-of-patient-experience.pdf

[14] https://www.kotterinc.com/book/our-iceberg-is-melting/

[15] https://www.ichom.org/

[16] http://www.ihi.org/Engage/Initiatives/TripleAim/Pages/default.aspx

Panopticon, ovvero come stiamo realizzando il sogno di ogni regime totalitario

Vi invito a leggere questo articolo sulla sorveglianza digitale e sul nuovo Panopticon che ho scritto insieme a Natan/Martino:

Tecnologie per la sorveglianza di massa crescono. Che possiamo fare?

Pensando a quello che stiamo vivendo, un leader (di un regime totalitario ma anche pseudo-democratico) potrebbe scrivere:

“Viviamo in un momento particolarmente felice. Un momento di grandi opportunità. Nei prossimi mesi e anni la maggior parte dei nostri sogni diverranno realtà e questo grazie alla tecnologia e alla collaborazione di tutti gli uomini e le donne del pianeta!”

“Mai come in questo periodo è diventato facile acquisire informazioni sulle persone, su quello che fanno, quello che pensano. Siamo in grado di capire prima che sia troppo tardi anche quello che vorrebbero fare e vorrebbero pensare. Questo ci permette di guidarle verso il bene loro e dello stato, evitando i rischi insiti nella troppa libertà. E questo le persone lo hanno capito benissimo: prova ne sia il fatto che non sono più necessari i metodi antiquati e purtroppo brutali a cui dovevamo ricorrere in passato. Sono loro stesse a fornirci tutte le informazioni che ci servono!”

Siamo in un periodo storico in cui un numero sempre crescente di persone nel globo è sotto l’influenza di regimi di tipo non democratico. Il Democracy Index dell’Economist si apre con questa frase: “Nell’Indice di Democrazia del 2019 il punteggio medio rispetto alla democrazia è caduto da 5.48 nel 2018 a 5.44 (su scala da 1 a 10). Questo è il peggior punteggio medio globale da quando l’Indice è stato introdotto per la prima volta nel 2006”. Guardando i numeri, solo il 5,7% della popolazione mondiale vive nei 22 stati definiti come “democrazie complete”.

Per saperne di più sugli impatti e le prospettive… leggete l’articolo su Agenda Digitale:

 

Digital evolution, la lezione delle cattedrali romaniche

“Soprattutto in questo momento storico in cui i cambiamenti sono stati e saranno violenti per tutte le aziende e le organizzazioni, la flessibilità e l’agilità sono virtù fondamentali. Fino a prima della crisi innescata dal coronavirus, alcune aziende erano “costrette” a cambiare continuamente, altre navigavano placide come se il mondo fosse un mare tranquillo e sempre uguale. Ora quel tempo è finito. Nel mio ambito ad esempio (l’università), è cambiato completamente sia il modello operativo che il modello di business in due settimane!”

Leggi l’articolo “Digital evolution, la lezione delle cattedrali romaniche”su Agenda Digitale!

 

Coronavirus: il grande confronto tra diritto alla salute, sorveglianza, e privacy (un video dibattito e un po’ di link per approfondire…)

Interessante live streaming a cui ho partecipato ieri con Giorgia Zunino e Giuseppe Vaciago: “Coronavirus: il grande confronto tra diritto alla salute, sorveglianza e privacy”

Leggi tutto “Coronavirus: il grande confronto tra diritto alla salute, sorveglianza, e privacy (un video dibattito e un po’ di link per approfondire…)”

Big data e small data contro il coronavirus: una proposta per l’Italia

Sul tema dei dati (big o small) si è parlato tanto come strumento di controllo del coronavirus. A volte correndo il rischio di idolatrare in modo fuorviante la tecnologia. Però se usata bene la tecnologia, nel rispetto dei diritti e delle libertà personali, può essere uno strumento estremamente potente ed efficace, come alcune esperienze nel mondo dimostrano…

Leggi l’articolo su Agenda Digitale.

 

 

 

 

Trasformazione digitale, quei due killer del valore

Una riflessione sulla trasformazione digitale e sui “debiti” che questa implica.

Non c’è solo il debito tecnico in senso stretto, ma anche il “debito di customer experience”. Anche nella violenta trasformazione digitale in corso. Perché “violent delights have violent ends”…

Se volete leggere altri articoli sul digitale e quanto sta avvenendo in questi giorni:

https://www.yottabronto.net/ai-maligna-coronavirus/

https://www.yottabronto.net/coronavirus-deep-impact-10-tips-the-future/

https://www.yottabronto.net/informatico-ignoto/

https://www.yottabronto.net/oggi-ho-chiuso-bottega/

https://www.yottabronto.net/il-bello-del-digitale-ai-tempi-del-coronavirus/

https://www.yottabronto.net/ai-novissima/

L’AI maligna che ci salverà dal Coronavirus – Opportunità e dilemmi etici

Una riflessione su quello che l’intelligenza artificiale (AI) può fare per aiutarci.

La buona notizia è che ci sono ottime prospettive.

La cattiva è che ci sono implicazioni etiche importanti e da non sottovalutare…

Altre riflessioni in forma di raccolto sul tema dell’AI le potete trovare sulla pagina di NOVissima – quattro racconti sull’intelligenza artificiale.

 

PS:  al di là del titolo volutamente provocatorio, non credo che l’AI (artificial intelligence o intelligenza artificiale, sempre scritto in minuscolo però) di per sé possa essere “maligna”. Sono della scuola che pensa che l’AI sia uno strumento, anche se più sofisticato e potente di altri, e che la mente umana sia qualcosa di completamente diverso da un computer[1]. Potrei citare Searle e l’esperimento della stanza cinese[2], così come Luciano Floridi[3] e tanti altri filosofi e studiosi. Nessuno di noi direbbe mai: “Una bomba atomica maligna ha distrutto Hiroshima e Nagasaki”. Al di là di quello che il genere cinematografico/letterario della distopia ci ha mostrato, da HAL9000 di 2001 Odissea nello spazio a Terminator, da Matrix a Ex Machina, da I Robot a Westworld.

[1] In altre parole non credo al “computazionalismo”: https://en.wikipedia.org/wiki/Computational_theory_of_mind

[2] https://en.wikipedia.org/wiki/Chinese_room

[3] https://it.wikipedia.org/wiki/Luciano_Floridi

 

Novissima: quattro racconti sull’Intelligenza Artificiale

NOVissima, ovvero quattro storie sull’Intelligenza Artificiale e le cose ultime: la morte, il giudizio, l’inferno e il paradiso

Con il commento finale di Cosimo Accoto, filosofo, saggista e ricercatore affiliato al MIT.

ECCO TUTTI E QUATTRO I RACCONTI della serie riuniti in un’unica raccolta.

I racconti sono stati pubblicati in anteprima su AI4Business:

Se vuoi scoprire altri temi su tecnologia e dintorni che mi appassionano, puoi navigare il sito oppure leggere gli articoli sul Blog

G.and.A.L.F.: intervista a Radio Next – Radio 24 sul governo della trasformazione (evoluzione) digitale

Condivido il podcast dell’intervista andata in onda ieri a Radio Next (Radio 24) sul metodo G.and.A.L.F.:

Per approfondire l’approccio proposto, rimando al mio articolo “Governance della trasformazione digitale, cambiare approccio col metodo Gandalf: ecco come” su Agenda Digitale.

Nulla di particolarmente nuovo: nell’articolo non faccio altro che ripercorrere e narrare, con un filo conduttore un po’ particolare, le buone pratiche Lean e Agile applicate però al tema della governance. Ne abbiamo parlato anche all’ultimo congresso di AISIS.

Grazie a Pepe Moder per l’opportunità e ai tanti che mi hanno contattato su Linked-in condividendo impressioni e spunti!

 

 

La lezione di Israele sulla business agility Parte 2: Gerusalemme (la diversità) e il kibbutz (l’umiltà)

Seconda parte della riflessione sulla business agility (organizational agility) a partire da quattro immagini di un paese in bilico tra eccellenza e caos, Israele. L’articolo che segue è la continuazione di: “La lezione di Israele sulla business agility – Parte 1

Leggi tutto “La lezione di Israele sulla business agility Parte 2: Gerusalemme (la diversità) e il kibbutz (l’umiltà)”

La lezione di Israele sulla business agility – Parte 1: Hebron (la necessità) e Tel Aviv (l’innovazione come ecosistema)

Una riflessione sulla business agility (o organizational agility) a partire da quattro immagini di un paese in bilico tra eccellenza e caos, Israele:

  • Hebron, ovvero della necessità
  • Tel Aviv, ovvero dell’innovazione come ecosistema
  • Il Kibbutz, ovvero dell’umiltà
  • Gerusalemme, ovvero della diversità

Leggi tutto “La lezione di Israele sulla business agility – Parte 1: Hebron (la necessità) e Tel Aviv (l’innovazione come ecosistema)”

Governance della trasformazione digitale: il metodo G.and.A.L.F.

Tutti parlano di digital transformation, ma purtroppo un numero inaccettabilmente elevato di programmi di trasformazione digitale fallisce o non da i risultati sperati. Ci deve essere un modo diverso di governare il cambiamento… in questo articolo provo a ragionare su un’alternativa, il metodo G.and.A.L.F.:

Governance della trasformazione digitale: il metodo G.and.A.L.F.

Se vuoi approfondire altri temi digitali, visita il blog di yottabronto.net

 

Stella che sogna… HolyLaLaLand!

“Ho fatto un sogno”, diceva un famoso segugio mio amico.

Anche io ho fatto un sogno: ho sognato che tutta la famiglia andava in un paese lontano, pieno di gatti e senza cani! Quasi un incubo!

Poi, quando mi sono svegliata, ho trovato questo video di 10 minuti fatto da Joy su un viaggio in Israele e Giordania:

Incredibile quante cose hanno fatto mentre io mi schiacciavo un pisolino! Allora è proprio vero che il tempo scorre in modo diverso per i cani e per gli umani!

Stella

PS: mi dicono che se volete leggere il resoconto del viaggio, dovete andare invece su questo post del blog. Un po’ lungo, ma si sa: Giulio quando comincia a scrivere non si ferma più! Ora me ne torno a dormire.

Lettera ai miei figli sul futuro dell’Intelligenza Umana ai tempi dell’intelligenza artificiale: il modello Start Trek (serie classica e TNG)

Intelligenza umana e intelligenza artificiale: competizione o collaborazione? L’intelligenza artificiale soppianterà le competenze umane o le complementerà?  In questa lettera ai miei figli propongo un modello, non nuovo: quello di Star Trek (serie Classica e TNG).

Leggi tutto “Lettera ai miei figli sul futuro dell’Intelligenza Umana ai tempi dell’intelligenza artificiale: il modello Start Trek (serie classica e TNG)”

Alice nella classe capovolta: la digital trasformation dove non te la aspetteresti (grazie all’Intelligenza Collettiva)!

Ricomincia l’anno scolastico. Tante speranze, tanti mal di pancia: il rapporto tra genitori e insegnanti è sempre più difficile, i ragazzi vivono ormai con la testa ovunque tranne che in classe, scuola e tecnologie sembrano essere due concetti antitetici. Eppure, come scoprirete leggendo questo brano dei protagonisti di Yottabyte e Brontobyte, anche in (alcune) scuole sta avvenendo una vera e propria rivoluzione digitale. Basta guardare le cose capovolte.

Leggi tutto “Alice nella classe capovolta: la digital trasformation dove non te la aspetteresti (grazie all’Intelligenza Collettiva)!”

Innovazione (in sanità e non solo): e se dovessimo imparare dalle mamme e da Melinda?

L’innovazione ha molte facce, ma più ne leggo e ne parlo e più penso che stiamo vivendo il paradosso di un’innovazione fossilizzata, vittima di una visione monoculare. “Ma non esiste prospettiva senza due punti di vista”, come canta anche Fedez. Un esperimento sociale sui protagonisti di Yottabyte e Brontobyte mi ha dato alcuni spunti di riflessione per le vacanze, che condivido…

Leggi tutto “Innovazione (in sanità e non solo): e se dovessimo imparare dalle mamme e da Melinda?”