Perché tanti progetti di digital transformation si sono conclusi con fallimenti colossali o con una produzione di valore infinitamente più piccola di quella ipotizzata?
Esporrò di seguito 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”.
Il metodo G.and.A.L.F., ovvero da DevOps a GovOps
Prima di approfondire le mie tesi e di entrare nel merito del metodo G.and.A.L.F.[1] , facciamo un passo indietro.
Una volta, tanto tanto tempo fa, esisteva 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.
Tesi numero 1: 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:
- 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].
- 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].
- 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].
- 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].
- 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à].
- 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].
- 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: perché Churchill aveva ragione
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 tradizionale 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:
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” di Wiley – M. H. 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.
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” di M. H. 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.
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.
| TEMA | Approccio Top Down (mondo waterfall) | Approccio G.and.A.L.F. (mondo Lean/Agile) | Esempi/note |
| Stime tempi e risorse | Stime definite dal top management, sia su risorse che su tempi di implementazione, che diventano poi milestone indiscutibili | Le stime devono sempre essere fatte (non solo validate) da chi eseguirà il lavoro. Questo è un principio cardine di ben noti framework Agile come SCRUM | Un esempio molto interessante dello SCRUM è il Planning Poker[15] |
| Boundary Objects | Ci sono “oggetti” di comunicazione pre-costituiti e rigidi. Non è importante creare ponti tra le culture, la cultura dominante impone i suoi modelli comunicativi | Gli “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 note | I boundary objects sono un concetto sociologico. Non posso approfondirli qui, ma vi rimando ad un articolo che ho scritto qualche tempo fa per ISACA[16] |
| 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 è pericolosa | Vi 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 “Concilio” e “Compagnia” nei principi) tra la parte alta della Governance e quella operativa | Potrebbero essere necessari comunque dei trasduttori tra il formalismo previsto dalle aziende anche in virtù di obblighi normativi e l’approccio snello |
| Valori e outcome | In 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 aziendale | Grande 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”[17] |
| Feedback | Il feedback è raccolto in modo discreto in alcuni momenti, ma spesso viene utilizzato per confermare le scelte già fatte | Utilizzo 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 lavoro | L’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[18] |
| Organizzazione IT | Fortemente gerarchica, sia a livello aziendale che nell’ambito Sistemi Informativi | Esiste 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 outcome | Ci 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[19] |
| Piano Strategico dei Sistemi Informativi | Documento formale e pluriennale che definisce nel dettaglio strategia e piani di sviluppo | Documento 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)
_____________________________________________________________________
- 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. ↑
- Si veda ad esempio “Big Mind” di G. Mulgan ↑
- Per approfondire il tema dell’Andon (e da lì si apre il mondo del Lean)↑
- Teal Organisation ↑
- Fiume Brandivino o Brandywine definisce il confine orientale della Contea nel mondo di Tolkien.
- 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.
- “Leading Change” – Harvard Business School Press – di J. P. Kotter ↑
- “Agile IT Organization Design: For Digital Transformation and Continuous Delivery” – Addison-Wesley Professional – di Sriram Narayan ↑
- Sull’extreme programming si può partire da qui ↑
- “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win” – IT Revolution – di G. Kim, K. Behr, G. Spafford. ↑
- Agile Manifesto ↑
- “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 ↑
- Governance for Agile Delivery” del National Audit Office dello UK ↑
- https://www.computerweekly.com/opinion/Six-reasons-why-the-NHS-National-Programme-for-IT-failedhttps://drive.google.com/file/d/1xAo0k_xAHaphbsCJW0wzg3Npnd42OfMt/view ↑
- 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. ↑
- A Social Approach to IT Governance: Incorporating Boundary Objects↑
- M. E. Porter, E. O. Teisberg (2006). Redefining Health – Harvard Business School Press ↑
- “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 ↑
- “Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage of Human Consciousness” – Ed. Nelson Parker – di F. Laloux ↑
AISIS (Associazione Italiana Sistemi Informativi in Sanità – www.aisis.it) è un’associazione senza fini di lucro, nata nel 2003 con lo scopo di favorire una crescita dell’attenzione sulle problematiche connesse all’innovazione digitale in Sanità, intesa come leva strategica di cambiamento delle aziende sanitarie pubbliche e private. Rappresenta una realtà costituita da oltre 500 soci che si propone come catalizzatore/facilitatore di percorsi di formazione, di eventi di networking e di alleanze tra tecnologi, utenti e decisori, perché la digitalizzazione e la trasformazione digitale della sanità creino valore per tutti gli stakeholder. In particolare AISIS è attiva sulla formazione dei suoi membri tramite l’eHealthAcademy (www.aisis.it/e-health-academy-2018). Insieme al LifeTech Forum organizza inoltre un evento annuale, il Digital Health Summit, che riunisce tutti gli stakeholder della sanità digitale (www.digitalhealthsummit.it). Il prossimo Digital Health Summit sarà a Milano (Palazzo delle Stelline) dal 9 all’11 ottobre 2019 e sarà focalizzato sulla “Value Based Digital Care”.
Inoltre AISIS si avvale di collaborazioni internazionali importanti, come quella con CHIME (www.aisis.it/chimecentral-org) ed organizza study tour all’estero e altri momenti di incontro tra e-Leader tecnici e non tecnici.
