Mark Schwartz, stratégiste d'entreprise chez AWS, et Paul Hannan, Enterprise Technology Lead au Royaume-Uni, partagent leurs principaux conseils pour naviguer avec succès dans la transformation avec le Cloud. Sur la base de leur expérience d'accompagnement d'entreprises à travers divers parcours de transformation et d'adoption du Cloud, Mark et Paul discutent de l'importance de faire confiance à vos collaborateurs et d'adapter votre culture.
Lorsque Mark Schwartz est devenu le directeur informatique des services de citoyenneté et d'immigration des États-Unis (USCIS) au sein du ministère de la sécurité intérieure en 2010 - prenant en charge 2 000 personnes et un budget annuel de 600 millions USD - il s'est demandé comment il allait faire bouger une organisation aussi vaste.
« Le service informatique passait à la production sur un cycle de 18 mois, le programme de transformation avait dépensé environ 1 milliard USD sur un effort logiciel qui n'avait jusqu'à présent donné aucun résultat et il y avait un autre projet où, au cours des quatre années précédentes, 21 personnes avaient rien fait mais rassembler un tas de documents. Il serait juste de dire qu'il s'agissait d'une organisation à basse fréquence - une organisation où le changement se produit très lentement », a déclaré Schwartz à un public de dirigeants lors du sommet AWS à Londres en mai.
Ce n'était tout simplement pas suffisant pour une organisation qui doit souvent réagir à une vitesse folle à des changements de politique annoncés à la hâte par ses maîtres politiques.
Mais le changement a eu lieu. Au moment de son départ en 2017 pour devenir stratégiste d'entreprise chez AWS et auteur de stratégie d'entreprise acclamé, Schwartz et son équipe avaient supervisé une transformation remarquable à l'USCIS. « Certains de nos systèmes se déployaient en production trois ou quatre fois par jour au lieu d'une fois tous les ans et demi. Nous avions créé des équipes de réponse rapide que nous pouvions déployer dans tout le pays et nous faisions tourner des hackathons qui produisaient de nouvelles applications à chaque fois. Et si nous pouvons le faire à la Sécurité intérieure, vous le pouvez aussi », a-t-il déclaré.
Même les équipes dont les processus sont les plus laborieux pourraient être transformées de bloqueurs en facilitateurs d'agilité.
Selon Schwartz, déployer la technologie cloud est la partie la plus facile - mais méfiez-vous de la « paralysie de l’analyse ». « Il est simple de prendre sa carte de crédit et de faire tourner des machines virtuelles dans le cloud », a déclaré Schwartz. Mais lorsque vous sélectionnez des technologies de développement, des personnes passionnées qui préconisent des plates-formes de développement logiciel différentes, mais essentiellement similaires, peuvent vous enliser dans une « paralysie de l'analyse ». C'est une énorme perte de temps et de ressources. La réponse ? « Ne le permettez pas. Passez à autre chose. Vous avez des choses plus importantes à faire. »
C'est au niveau du processus que les choses commencent à devenir vraiment délicates. L'USCIS, par exemple, avait des processus longs et excessivement bureaucratiques dans presque tous les domaines, des portes, des contrôles et des demandes de documentation apparemment sans fin. Mais Schwartz a constaté que même les équipes dont les processus étaient les plus laborieux pouvaient être transformées de bloqueurs en facilitateurs d'agilité. L'astuce consiste à fixer les bons objectifs, puis à donner aux équipes la liberté créative de suggérer comment les atteindre. « Par exemple, nous avions une organisation d'assurance qualité (QA) qui se considérait comme le garant de la qualité en empêchant les systèmes d'entrer en production. Le responsable d'assurance qualité se faisait même appeler le Grinch ».
Il était évident que cela allait poser problème. L'équipe d'assurance qualité était passionnée par la qualité, mais pour eux, cela signifiait exiger des tonnes de documentation remplie avec autant de détails que possible, suivie de tests approfondis. Cela signifiait qu'il serait impossible d'obtenir des délais de livraison toujours plus courts. Schwartz a donc modifié les objectifs et les paramètres de l'assurance qualité. Tout d'abord, il a déclaré que la documentation devait désormais être aussi courte que possible pour transmettre les informations nécessaires. « Ensuite, je leur ai dit que leur tâche n'était pas d'empêcher la mise en production de systèmes de mauvaise qualité, mais de s'assurer que tout était construit à un niveau de qualité élevé au départ », a-t-il déclaré.
Qu'est-ce qui fait la force des vrais leaders ?