Dans le monde numérique, il y a une épidémie de surproduction de solutions logicielles – un récent service de TI que nous avons visité donne généralement le feu vert à 80 projets par an – et n’en achève que 15. 

Pourquoi? Parce qu’ils proposent trop de solutions, chacune d’entre elles exigeant plus de temps et d’efforts que nécessaire.

Étude de cas :

Le directeur des systèmes d’information (DSI) a soulevé un épais cartable à la hauteur des yeux et l’a laissé tomber sur le bureau, avec un bruit sourd et un nuage de poussière. Il a prédit : « Quand je prendrai ma retraite dans dix ans, ce logiciel ne sera pas mis en œuvre, et s’il l’est, il ne fonctionnera probablement pas ».

Son équipe et ses clients ont travaillé pendant des années à la compilation d’un cahier des charges de 500 pages pour le nouveau système afin d’automatiser le processus de base de son ministère – un système de gestion des cas pour guider les analyses de rentabilité à travers un processus complexe d’examen et d’approbation.

Quelques mois plus tard, dans le même bureau, il a félicité son équipe d’avoir réduit les 500 pages d’exigences à seulement 111 pages. Six mois plus tard, lui, son équipe et ses clients ont célébré la mise en œuvre réussie d’un logiciel plus simple et plus performant, et ce, plusieurs années à l’avance et à un coût moindre que le budget prévu.

Comment ont-ils surmonté ce défi ?

Il s’avère que de nombreuses solutions logicielles sont gonflées, offrant beaucoup plus de fonctionnalités que nécessaire. Pourquoi? Parce que l’entreprise recherche des « fonctionnalités » – au lieu de comprendre d’abord en profondeur ses problèmes opérationnels qu’elle doit « résoudre absolument et sans faute ». Par conséquent, elle ne définit jamais quels problèmes opérationnels le logiciel peut résoudre et, ce qui est tout aussi important, ceux qu’il ne peut pas résoudre. En d’autres mots, elle ne définit pas les problèmes qui relèvent du DSI, et ceux qui relèvent du directeur de l’exploitation. Le DSI se retrouve donc (injustement et déraisonnablement) à devoir les résoudre tous. 

Le rapport Chaos de 2014 du Standish Group (en anglais seulement) suggère que près de 30 % des fonctionnalités sont rarement utilisées et que 50 % d’entre elles ne le sont presque jamais. 

Si nous utilisons rarement ou presque jamais ces fonctionnalités, alors pourquoi nous donnons-nous la peine de les définir, de les construire, de les tester, de les mettre en œuvre, de les enseigner et de les entretenir? Surtout alors que nos services de TI sont, en même temps, confrontés à d’énormes accumulations de tâches en souffrance?

Pour les dirigeants et les équipes en difficulté, il est presque irrésistible d’essayer d’intégrer autant de fonctionnalités que possible. Quand nous avons interrogé des clients et des professionnels de l’informatique, voici les principales raisons de cet excès de fonctionnalités :

• Occasion rare : souvent, les remplacements de systèmes ou les mises à niveau majeures n’ont lieu qu’une fois par génération (ou moins). Il y a donc une motivation à exiger toutes les fonctionnalités possibles « au cas où », car nous pourrions ne pas avoir d’autre occasion dans un avenir prévisible;
• Mauvaise compréhension : les clients ne comprennent pas les causes des principaux problèmes de leur entreprise; ils demandent donc autant de fonctionnalités que possible dans l’espoir que l’une de ces nombreuses fonctionnalités résoudra ces problèmes par magie;
• Déconnexion : les développeurs et les approbateurs des exigences sont éloignés des activités quotidiennes et ont peur de refuser des fonctionnalités, étant donné leur connaissance limitée des défis opérationnels.

Cet excès de fonctionnalités a un coût énorme :

• Essayez de suivre cette chaîne d’événements : plus il y a d’exigences, plus le projet est important, plus les coûts et les risques sont élevés, plus le niveau de gouvernance requis pour l’approuver est élevé, plus l’effort investi dans la définition du projet est important, plus le processus de définition et d’approbation prend du temps, plus les exigences deviennent désuètes, ce qui nécessite du temps et des efforts pour les mettre à jour; et, à mesure que le temps passe, plus le personnel quitte le projet, ce qui augmente encore l’effort total et le temps requis pour mettre le projet en œuvre. 
• Plus les exigences sont grandes, plus les ressources nécessaires à la mise en œuvre de la solution sont importantes (souvent environ 30 % du coût total), et plus les ressources et l’attention nécessaires au maintien de la solution sont importantes (souvent environ 50 % du coût total) – ces ressources sont en fait volées à d’autres projets importants, ce qui empêche le service de TI d’apporter de la valeur à d’autres parties des activités et du mandat de l’organisation.

De nombreuses organisations ne maîtrisent pas bien leurs principaux problèmes ou les causes de ces derniers avant de définir leurs besoins. Et c’est tout autant un problème opérationnel fondamental qu’un problème relevant du DSI.

Quels défis les logiciels peuvent-ils résoudre ?

Les processus de gestion hautement transactionnels (traitement de masse ou personnalisation de masse) sont définis par des arbres de décision et des règles opérationnelles qui peuvent être codés dans un logiciel pour fournir un degré élevé d’automatisation. Le traitement des transactions de masse comme les déclarations d’impôts, les prestations de retraite, etc., sont souvent de bons candidats pour une automatisation sérieuse.  

Cependant, les tâches nécessitant une réflexion approfondie (p. ex. élaboration ou examen d’analyses de rentabilité, de politiques, de stratégies, de correspondance, etc.) sont beaucoup moins à même de tirer profit des solutions numériques. Dans le cadre du processus d’examen et d’approbation des analyses de rentabilité que le DSI mentionné au début de cet article essayait d’automatiser, après un examen approfondi du processus par le personnel à l’aide de la méthode Lean, ils ont repéré neuf défis à « résoudre absolument et sans faute » (Figure 1.0).

Une fois que l’équipe pluridisciplinaire du DSI a dressé cette courte liste de défis et évalué si la technologie actuellement disponible pouvait les résoudre, ils ont réalisé que s’attendre à ce que des solutions numériques résolvent tous leurs problèmes était un rêve illusoire. Seuls 20 % environ des problèmes pouvaient être résolus par les logiciels. L’équipe a estimé que chaque analyse de rentabilité effectuée sur son système a fait l’objet d’au moins 7,5 semaines d’efforts évitables – multiplié par un volume annuel de plus de 300 analyses de rentabilité. Le fait de ne pas résoudre ces problèmes a un coût très élevé.

Et aussi utile qu’Agile/Scrum puisse être en permettant de fournir deux fois plus de logiciels en deux fois moins de temps, sans d’abord comprendre profondément les problèmes de l’entreprise et leurs causes, cette discipline méritoire se limite souvent à « construire la mauvaise chose plus rapidement, avec moins d’efforts ».

Chaque heure passée à mieux comprendre le processus que vous tentez de numériser pourrait vous faire gagner dix heures ou plus d’efforts par la suite, tout en libérant le personnel de la TI et des activités principales pour qu’il puisse apporter plus de valeur à votre secteur d’activité et ailleurs.

Si vous êtes un DSI, cette approche peut vous aider à satisfaire davantage de clients et à vous débarrasser de votre propre pile de tâches en souffrance. Si vous êtes un client de TI, une meilleure compréhension de vos propres problèmes opérationnels et de leurs causes peut vous permettre d’obtenir plus rapidement le système souhaité, avec une plus grande probabilité qu’il fonctionne réellement une fois livré. Comme l’a dit un autre DSI en examinant la liste des causes profondes de son client : « Ce n’est plus un projet de 300 000 $ qui doit passer par notre processus d’approbation et prendre deux ans pour être mis en œuvre. Il s’agit plutôt de quatre jours de travail pour un analyste commercial et un codeur pour améliorer notre système actuel ».

Dans ce domaine de contenu, nous couvrons les sujets suivants :

• Pourquoi les solutions logicielles sont souvent livrées en trop
• Le coût de la sur-livraison
• Déterminer les résultats à atteindre pour la solution logicielle
• Créer un énoncé de problème efficace avec vous et votre client
• Déterminer les interrelations entre les causes et les causes profondes
• Comprendre le flux des processus, les tâches en souffrance et les trois principales décisions Lean
• Comprendre la demande de valeur par rapport à la demande d’échec/travail évitable, et quantifier le coût de ce dernier
• Comprendre un large éventail de causes généralement invisibles d’un mauvais rendement 
• Travail algorithmique c. travail heuristique – et comment les logiciels peuvent résoudre ces problèmes
• Comment établir des exigences qui définissent les problèmes à être résolus par le client et ceux qui peuvent être résolus par l’automatisation – afin de créer une solution numérique simplifiée et rationnalisée