Pourquoi la poursuite de la vitesse crée les problèmes logiciels de demain

La pression pour livrer plus rapidement les logiciels ERP et les logiciels critiques pour l’entreprise crée souvent des coûts cachés que les organisations devront finalement résoudre, argue Carl Andrews, PDG, Original Software.

Chaque DSI a participé à une célébration de lancement. Le gâteau, les félicitations, le soulagement que quelque chose ait finalement été livré. Ce qui est moins discuté, c’est ce qui se passe dans les mois qui suivent, lorsque la pression pour livrer à temps a discrètement transféré ses coûts aux équipes chargées de maintenir ce qui a été livré.

Ceci n’est pas un problème de niche. La poursuite d’une livraison logicielle plus rapide s’accélère, et non ralentit. Les cycles de sprint sont plus courts, les fréquences de publication augmentent, et l’attente que la technologie réponde aux besoins de l’entreprise presque en temps réel est désormais standard. Aller plus vite est généralement la bonne intuition. La question est de savoir ce qui est sacrifié pour y parvenir.

Where the debt starts

devient

L’endroit où la dette commence

La dette technique arrive rarement avec un avertissement. Elle se construit à travers des décisions qui, individuellement, semblent tout à fait défendables. La documentation est reportée plus bas dans la liste de priorités parce que l’équipe doit respecter un délai. Un contournement est ajouté à une configuration ERP parce que la solution appropriée retarderait le projet. Les tests sont réduits parce que les délais sont déjà en retard

Une personnalisation est laissée en place parce que la remplacer semble trop perturbateur.

Personne ne cherche à accumuler de la dette. C’est ce qui reste après une série de décisions qui semblent raisonnables, prises sous pression. Ce qui a commencé comme quelques raccourcis devient un système plus difficile à modifier, qui se brise plus souvent et coûte plus cher à maintenir que ce que quiconque avait prévu.

Les environnements ERP sont particulièrement vulnérables. Par leur nature, ils se situent au centre de l’organisation, en connectant les finances, les ressources humaines, la chaîne d’approvisionnement, les achats et d’autres fonctions commerciales critiques. Au fil du temps, des années de raccourcis, de contournements et de modifications mal documentées créent une complexité que personne n’avait prévue, mais que tout le monde hérite. Le résultat est prévisible, même si le moment n’est pas une question qui aurait dû être détectée lors des tests, mais qui surgit dans les processus commerciaux en direct, généralement au pire moment.

Why organisations underestimate the problem

devient

Pourquoi les organisations sous-estiment le problème

Une partie du défi est que la dette technique ne se manifeste pas rarement comme un coût évident. Contrairement à un projet échoué ou à un délai manqué, la dette s’accumule progressivement. Elle se manifeste par des mises à niveau qui prennent plus de temps que prévu. Des modifications qui nécessitent plus d’efforts qu’elles ne devraient. Des équipes passent des semaines à enquêter sur des problèmes qui auraient autrefois été simples à résoudre.

Parce que ces coûts émergent lentement, ils sont souvent traités comme des incidents isolés plutôt que comme des symptômes d’un problème plus large. Les organisations ont tendance à se concentrer sur les avantages visibles de la livraison rapide tout en ignorant les conséquences à long terme de la mise en place de systèmes plus difficiles à maintenir et à évoluer.

Le résultat est que la dette technique reçoit l’attention uniquement lorsqu’elle commence à affecter les performances de l’entreprise.

The impact on innovation, productivity and resilience

devient

L’impact sur l’innovation, la productivité et la résilience

Le coût le plus important de la dette technique n’est généralement pas technique. C’est stratégique. À mesure que les environnements ERP deviennent plus complexes, les équipes IT passent plus de temps à maintenir les systèmes existants et moins de temps à livrer de nouvelles fonctionnalités. Les ressources qui pourraient soutenir des projets de transformation, des améliorations de processus ou des initiatives d’intelligence artificielle sont plutôt consommées par la résolution de problèmes, les reprises et la maintenance des systèmes.

L’innovation ralentit parce que chaque changement comporte un risque plus élevé. La productivité souffre parce que les tâches routinières prennent plus de temps à compléter. La résilience diminue parce que les systèmes deviennent plus difficiles à tester, à soutenir et à récupérer lorsqu’il se passe quelque chose de mal. Cela crée un cycle frustrant. Les organisations poussent pour aller plus vite pour rester compétitives, mais la dette créée par cette vitesse finit par rendre les changements futurs plus lents, plus coûteux et plus difficiles à mettre en œuvre.

Getting the balance right

devient

Équilibrer les choses

La réponse n’est pas de ralentir. Peu d’organisations peuvent se le permettre. L’objectif est de construire des processus de livraison qui soutiennent la vitesse sans compromettre la qualité à long terme. Cela commence par reconnaître que les activités telles que les tests, la documentation et la gouvernance ne sont pas des obstacles à la livraison. Ce sont elles qui rendent la livraison durable possible. Pour les systèmes ERP en particulier, des tests de régression robustes sont essentiels.

Cela donne aux organisations la confiance que les changements, les mises à jour et les mises à niveau peuvent être introduits sans créer de perturbations inattendues ailleurs dans l’entreprise. Combiné avec une plus grande automatisation et des tests plus précoces tout au long du cycle de livraison, cela aide à identifier les problèmes avant qu’ils ne deviennent des problèmes coûteux.

Le plus important, les organisations doivent considérer la dette technique comme un problème commercial et non comme un problème technique. Les décisions prises pour accélérer la livraison aujourd’hui influenceront le coût, la flexibilité et la résilience des systèmes pour les années à venir.

Le lancement n’est pas la ligne d’arrivée. C’est simplement le point où les conséquences à long terme de ces décisions commencent à émerger. Les organisations qui réussiront à long terme ne seront pas celles qui bougent le plus vite à court terme, mais celles qui pourront continuer à changer et à innover sans être freinées par les systèmes dont elles dépendent.