Mark Schwartz, stratega aziendale di AWS e Paul Hannan, responsabile di tecnologia aziendale del Regno Unito, condividono i loro migliori consigli per navigare con successo nella trasformazione per il cloud. Sulla base della loro esperienza di coaching aziendale attraverso diversi percorsi di adozione e trasformazione per il cloud, Mark e Paul discutono dell'importanza di fidarsi del proprio personale e di adattare la propria cultura.
Quando Mark Schwartz diventò CIO di US Citizenship and Immigration Services (USCIS) presso il Department of Homeland Security nel 2010 – assumendosi la responsabilità di 2.000 persone e un budget annuale di 600 milioni di dollari – si chiese come mai avrebbe fatto a far muovere un'organizzazione così vasta.
"Il reparto IT stava iniziando la produzione con un ciclo di 18 mesi, il programma di trasformazione aveva speso circa 1 miliardo di dollari per utilizzare un software che, fino a quel momento, non aveva prodotto risultati. In un altro progetto, nei quattro anni precedenti, 21 persone non avevano fatto altro che assemblare un mucchio di documenti. Sarebbe giusto dire che era un'organizzazione a bassa frequenza – in cui il cambiamento avviene molto lentamente", disse Schwartz a un pubblico di dirigenti al Summit AWS di Londra a maggio.
Ciò non era sufficiente per un'organizzazione che spesso doveva rispondere a una velocità vertiginosa ai cambiamenti politici annunciati frettolosamente dai suoi leader politici.
Ma alla fine è stato un successo. Quando, nel 2017, lasciò questa organizzazione per diventare stratega aziendale presso AWS, nonché un acclamato autore di testi dedicati alla strategia aziendale, Schwartz e il suo team erano stati testimoni di una notevole trasformazione in USCIS. “Alcuni dei nostri sistemi venivano distribuiti alla produzione tre o quattro volte al giorno anziché una volta ogni anno e mezzo. Avevamo creato team di risposta rapida che potevamo mettere in campo in tutto il Paese e stavamo eseguendo hackathon che producevano ogni volta nuove applicazioni. E se possiamo farlo alla Homeland Security, puoi farlo anche tu”, disse.
Anche quei team con i processi più laboriosi potrebbero essere trasformati da inibitori a fattori abilitanti di agilità.
Secondo Schwartz, l'implementazione della tecnologia cloud è la parte facile – ma attenzione alla ‘paralisi dell'analisi’. "È semplice estrarre la carta di credito e avviare alcune macchine virtuali nel cloud", ha affermato Schwartz. Ma nel momento in cui selezioni tecnologie di sviluppo, persone entusiaste che sostengono piattaforme di sviluppo software diverse – ma essenzialmente simili – possono impantanarti con la ‘paralisi dell'analisi’. È un'enorme perdita di tempo e risorse. La risposta? “Non permetterlo. Lancia una moneta e vai avanti. Hai cose più importanti da fare.
"È dal lato del processo che le cose iniziano a diventare davvero complicate. USCIS, ad esempio, aveva processi prolissi ed eccessivamente burocratici in quasi ogni area – gate, controlli e richieste di documentazione apparentemente infiniti. Ma Schwartz scoprì che anche quei team con i processi più laboriosi potevano essere trasformati da inibitori a fattori abilitanti di agilità. Il trucco sta nel fissare gli obiettivi giusti e poi dare ai team la libertà creativa di suggerire come raggiungerli. “Ad esempio, avevamo un'organizzazione di garanzia di qualità (QA) che faceva in modo di assicurare la qualità impedendo che i sistemi entrassero in produzione. Il capo del QA si faceva persino chiamare il Grinch."
Chiaramente, questo sarebbe stato un problema. Il team QA ci teneva molto alla qualità, ma per loro ciò significava richiedere di compilare risme di documentazione con il maggior numero di dettagli possibile, seguite da test approfonditi. Ciò significava che sarebbe stato impossibile ottenere tempi di consegna sempre più rapidi. Di conseguenza, Schwartz cambiò gli obiettivi e i parametri del QA. In primo luogo, decise che la documentazione doveva ora essere quanto più ridotta possibile per trasmettere le informazioni necessarie. "Poi, dissi al team QA che il suo compito non era quello di impedire che i sistemi di bassa qualità entrassero in produzione, ma garantire che tutto fosse costruito iniziando già con un alto livello di qualità", affermò.
Cosa rende grandi i bravi leader?