Deux architectes informatiques de ma connaissance m’ont récemment expliqué comment ils sont parvenus à augmenter leur taux de service de 21 à 88 % en un peu moins de 2 ans.
Ces deux jeunes gens travaillent dans une équipe de 7 personnes qui a en charge de maintenir et faire évoluer les règles de sécurité sur des équipements de protection du réseau de leur entreprise. En effet, la croissance du besoin en connexions depuis ou vers l’extérieur de l’entreprise accroît également le risque que quelqu’un de malveillant puisse s’introduire dans le système d’information. Par exemple, lorsqu’une entité Métier souhaite mettre en place une nouvelle application qui va utiliser le Web, elle s’adresse à cette équipe pour obtenir un module de sécurité qui permettra à l’application de fonctionner de manière sécurisée.

Le processus qui permet d’obtenir cette protection se décompose en plusieurs étapes :

1. L’entité métier exprime son besoin en décrivant le type d’application et de connexions qu’elle souhaite utiliser.

2. Les architectes informatiques qualifient ce besoin pour le retraduire en un besoin technique.

3. L’équipe de production coordonne la mise en place de 3 composantes techniques avec d’autres équipes IT :

• une première équipe installe le premier composant,
• une deuxième équipe installe le second,
• enfin, l’équipe de production récupère l’instance créée avec les deux composantes pour y ajouter une politique de sécurité.

4. L’équipe de production renvoie les informations du module de sécurité à l’entité métier demandeuse.

L’équipe se doit de tenir un engagement de service qui consiste à mettre à disposition une demande de ce type en moins de 20 jours ouvrés. En 2016, leur taux de réussite dépasse tout juste les 20 % ! Ils décident alors de mettre en place une démarche Lean sur ce processus et 18 mois plus tard, après plusieurs PDCA réalisés, ils arrivent à 88 % des demandes satisfaites en moins de 20 jours.
Un exemple de variabilité réside dans les nombreux allers-retours nécessaires entre le métier et l’équipe d’architectes. Un nombre important de requêtes se retrouvent ainsi suspendues, voire abandonnées !

Un premier PDCA les conduit à se rendre compte qu’il n’existe qu’un seul formulaire pour 2 types de demande (création ou modification), ce qui conduit inévitablement à des informations manquantes et/ou mal renseignées. Le simple fait de créer 2 formulaires distincts leur a permis de diviser par 6 les requêtes en suspens et donc d’accélérer leur délai de réponse. Comme le précise l’un d’entre eux : « C’est une action simple mais elle facilite vraiment la vie des entités métiers. Cependant, il y avait encore beaucoup d’allers-retours ».

Un deuxième PDCA les a conduits à replacer en amont une équipe déjà existante pour vérifier que la demande est complète. Pour ce faire, ils ont construit une checklist pour les différents cas. Cette checklist permet également d’expliquer aux entités métiers le juste nécessaire à fournir en fonction de leur demande et ainsi d’éviter de reproduire les mêmes erreurs.

Ils présentent ensuite leurs différentes idées de numérisation dont en particulier l’idée d’automatiser ce processus. En effet, même s’ils ont stabilisé le processus à 20 jours ouvrés, ce délai reste encore très long pour les clients. Aussi ont-ils entrepris une analyse de toutes les tâches pour voir ce qui est fait manuellement et identifier ce qui peut être automatisé.

Au-delà de ce beau succès, il faut y voir une réflexion Lean sur l’automatisation d’un process avec le Lean management.
Dans la pensée commune, automatiser un processus permet de réduire les erreurs et de le rendre plus rapide. Certes ! Mais au final, combien de processus une fois automatisés se révèlent réellement plus rapides ?
Si ces deux architectes informatiques avaient décidé d’automatiser tout de suite le processus, que serait-il arrivé ? Les entités métiers auraient eu à disposition un outil informatique dans lequel elles auraient sans doute continué à se tromper dans les informations à fournir. Et les allers-retours auraient persisté pour corriger et compléter la demande. Au mieux auraient-ils réussi à accélérer ces allers-retours !
Le Lean nous dit qu’il faut d’abord stabiliser le processus en réduisant sa variabilité. Dans cet exemple, ils ont pris le parti de travailler d’abord sur la qualité des informations en entrée du processus (le « Matériau » du 4M). Les différents PDCA qu’ils nous ont présentés ont permis de stabiliser le délai de réponse autour de 20 jours. Ils ont également réduit quelques gaspillages. Et ensuite, seulement ensuite, ils ont décidé de l’automatiser progressivement et par parties pour accélérer sa vitesse. Sur la partie demande, ils ont tiré profit du travail réalisé pour construire la checklist et créé le portail de demande adéquat où les informations demandées sont comprises des entités métiers.

Et vous ? A l’ère du digital, comment envisagez-vous l’automatisation de vos processus ?

Retrouvez les dates des prochaines sessions de formation agile à Lille sur Efidev. Découvrez l’ensemble de nos formations au Lean et à l’agilité dans notre catalogue.