Projet ERP en crise : schémas typiques et solutions

De nombreuses entreprises considèrent que leur projet ERP a échoué dès que les dates de mise en service ont été reportées à plusieurs reprises et que le budget est dépassé depuis longtemps. Selon une étude menée par Horváth Dans le cadre des transformations SAP S/4HANA, 60 % des projets dépassent le budget et le calendrier prévus (Horváth, 03/2025). Connaître les schémas typiques d’une telle crise permet d’intervenir plus tôt, plutôt que d’attendre de consulter la liste des budgets restants pour réagir.

Les raisons les plus courantes de l'échec d'un projet ERP

Horváth a analysé les transformations SAP S/4HANA et est parvenu à une conclusion sans appel : 60 % des projets dépassent le budget et les délais prévus ; en moyenne, ils durent 30 % plus longtemps que prévu initialement (Horváth, 03/2025). Même lorsque la mise en production a finalement lieu, il subsiste souvent des lacunes non résolues.

L'une des raisons réside dans la conception même des projets. Selon cette même étude, 78 % des entreprises interrogées indiquent que la transformation porte sur un trop grand nombre de thèmes à la fois (Horváth, 03/2025). Un projet ERP qui, parallèlement à la migration du système, doit également régler la question de la structure organisationnelle, du reporting et de plusieurs problèmes hérités du passé, perd la concentration dont un programme de cette envergure a besoin.

Une deuxième observation montre à quel point cet effet est profond. La Computerwoche rapporte, en s'appuyant sur un rapport de l'ISG, que seules 18 % des entreprises repensent réellement leurs processus dans le cadre de la migration, tandis que 49 % reprennent les anciens processus pratiquement sans les modifier (Computerwoche, 02/2026). Ceux qui utilisent le nouveau logiciel comme l'ancien passent à côté d'une grande partie des avantages réels et paient néanmoins l'intégralité des coûts du projet.

Ces cinq causes se manifestent rarement isolément. Une portée trop importante du projet complique la gestion de projet, une équipe de gestion de projet surchargée repousse sans cesse les décisions, et l'absence de décisions réduit à son tour la durée de la phase de test. Celui qui ne remédie qu’à l’une de ces causes, tandis que les autres persistent, ne fait généralement que repousser le véritable problème de quelques semaines. Cet article explique comment limiter dès le départ l’augmentation de la portée d’un projet Mettre fin à la dérive des objectifs : comment redonner une structure aux projets.

Quelles mesures adopter pour sortir de la crise des progiciels de gestion intégrés (ERP) ?

La première étape consiste à dresser un état des lieux objectif, indépendamment de l’organisation du projet telle qu’elle a été mise en place jusqu’à présent. Ceux qui rendent compte eux-mêmes de l’avancement du projet ont tendance à présenter les progrès de manière plus optimiste qu’ils ne le sont en réalité, surtout lorsque leur propre poste dépend d’une issue positive. On ne peut en tenir rigueur à personne, mais cela ne change rien au fait que les chiffres doivent finalement correspondre à la réalité. Un regard extérieur sur le budget, la couverture des tests et les décisions en suspens jette les bases indispensables à toute planification pertinente. Sans cette étape, toute planification ultérieure reposera sur des chiffres déjà en décalage avec la réalité.

Il en résulte une distinction claire entre ce qui est indispensable et ce qui est facultatif. Les thèmes qui ne faisaient pas initialement partie du projet doivent être replacés dans un projet distinct, même si cela peut s'avérer gênant et décevoir les parties prenantes. Un projet ramené à son essence initiale redevient plus facile à piloter.

Les phases de test et de migration des données doivent ensuite faire l'objet d'un calendrier spécifique et réaliste, plutôt que d'une simple marge de manœuvre prévue à la fin du projet. Si l'on n'effectue les cycles de migration dans leur intégralité pour la première fois que peu avant la mise en production, on découvre les problèmes liés aux données trop tard pour pouvoir les résoudre de manière méthodique.

Enfin, les décisions en suspens doivent être identifiées et assorties d’une date butoir. Un engorgement décisionnel se résout rarement par la multiplication des réunions ; il faut le plus souvent une gouvernance de projet efficace, avec une seule personne habilitée à trancher définitivement une question en suspens. Parfois, la sortie de crise passe par le remplacement du partenaire chargé de l'exécution. Cet article explique comment mettre cela en œuvre de manière conforme sur les plans juridique et technique. Changer de prestataire en cours de projet : les aspects juridiques et techniques.

Foire aux questions

À quels signes peut-on reconnaître dès le début qu'un projet ERP a échoué ?

Les premiers signes avant-coureurs sont des échéances reportées à plusieurs reprises, une liste croissante de questions techniques non résolues et des phases de test systématiquement raccourcies dans le calendrier dès que le temps vient à manquer. De même, une proportion croissante de solutions de contournement dans le quotidien du projet indique que la planification initiale ne correspond plus à la réalité. Un autre signal réside dans le ton des rapports d’avancement. Lorsque des chiffres sont remplacés par des formulations vagues, c’est généralement le chiffre précis que personne ne souhaite mentionner qui fait défaut.

Renégocier ou rompre les négociations ?

Cela dépend de la cause. Si le problème tient à l'étendue du projet, aux ressources ou au calendrier, il est généralement possible de renégocier, par exemple en réduisant l'étendue des fonctionnalités ou en reportant la mise en service. Si le problème réside dans le choix du système lui-même ou dans le recours à un prestataire ne disposant pas de l’expérience nécessaire, renégocier ne fait souvent que retarder la réapparition du même problème. Dans les deux cas, il faut tenir compte du même calcul : ce que coûtera la poursuite du projet à partir d’aujourd’hui et ce que coûterait un nouveau départ.

Qui devrait réaliser cette analyse ?

C’est une personne ou une équipe qui n’est pas responsable du déroulement du projet jusqu’à présent qui fournit l’évaluation la plus impartiale. Celui qui dirige son propre projet depuis des mois a rarement le recul nécessaire pour reconnaître ouvertement ses propres erreurs d’appréciation, même avec la meilleure volonté du monde. Les auditeurs externes apportent en outre une perspective comparative par rapport à d’autres projets, ce qui permet de situer l’ampleur et l’urgence de la situation. En interne, ce rôle ne peut être assumé que si la personne chargée de l’audit peut prouver qu’elle n’a aucun intérêt personnel dans le résultat, ce qui est rarement le cas dans la pratique.

Un projet ERP en crise a besoin de quelqu’un qui prenne les rênes et tranchent les décisions restantes. Pour cela, torck met à disposition ses propres équipes de développement et de projet à Maxhütte-Haidhof, Vienne et Rabat, et gère elle-même l’aspect technique de la restructuration, au lieu de se contenter de fournir un simple rapport supplémentaire. Le partenaire contractuel est la société allemande torck GmbH. Si vous avez besoin d'un deuxième avis sur votre projet ERP, vous pouvez en faire la demande dans un Premier entretien .

Prendre rendez-vous