Comment combler l'écart mémoire des projets ERP [Livre blanc]

En transformant les conversations de projet éparses en quelque chose que vous pouvez réellement consulter, pour que les décisions remontent à celui qui les a prises, et que les risques soient détectés tant qu'ils restent exploitables.

Principaux enseignements

• Les projets ERP accumulent la documentation. La plupart ne peuvent toujours pas dire ce qui a été décidé, ou pourquoi, en moins d'une minute.

• L'écart mémoire se manifeste durement à 5 points : vente vers livraison, intégration en cours de projet, récupération d'un programme en difficulté, gouvernance de direction, et transition vers le support.

• Le risque apparaît dans les conversations informelles des semaines avant qu'il ne figure dans un rapport de statut.

• Un dossier d'enregistrements de réunion est de la matière brute, pas un historique consultable.

• Corriger cela signifie remonter une décision jusqu'à celui qui l'a prise et pourquoi, à la demande.

Les projets ERP perdent les décisions qui comptent

Les projets ERP perdent les décisions qui comptent parce que le raisonnement qui les sous-tend vit dans des discussions éparses, des threads Teams incomplets et la tête d'une ou deux personnes. Aucun registre unique ne les relie. Eric Lampron, qui a dirigé la livraison ERP pendant 25 ans, appelle cela l'écart mémoire des projets ERP.

À quoi cela ressemble-t-il dans un vrai programme?

Le défi d'Eric était la corvée administrative : suivre tous les éléments ouverts et chasser chaque boucle qui ne s'était pas fermée.

Il s'appuyait fortement sur quelqu'un d'autre pour tenir les détails tandis qu'il tenait la vue d'ensemble. Cela fonctionnait, mais cela signifiait aussi que la mémoire du projet vivait dans la tête d'une personne.

Remplacez le nom d'Eric par n'importe qui. Chaque programme ERP a une personne vers laquelle tout le monde est orienté. Un nouveau consultant se joint en cours de projet, on lui dit d'aller la trouver et il brûle 3 semaines à reconstruire une histoire qui existe déjà quelque part. Personne ne peut littéralement la consulter parce qu'elle est coincée dans la tête de quelqu'un.

Où l'écart mémoire frappe-t-il le plus fort?

Le document d'Eric nomme 5 transitions où le contexte s'érode rapidement.

Vente vers livraison. La vente passe des mois à apprendre exactement ce qui inquiète un client. Presque rien de cela ne survit dans le cahier des charges signé.

Intégration en cours de projet. Les nouveaux membres de l'équipe reçoivent un lien SharePoint et un nom à déranger. Ils obtiennent la trace écrite, pas l'histoire.

Récupération d'une implémentation en difficulté. Un nouveau SI arrive et doit reconstituer des mois d'histoire à partir de fragments avant même de pouvoir diagnostiquer ce qui s'est cassé.

Gouvernance de direction. Le risque émerge généralement dans les ateliers et les conversations informelles des semaines avant d'atteindre un journal formel RAID (risques, hypothèses, problèmes et dépendances que la plupart des programmes sont censés mettre à jour).

Projet vers support. Le support hérite de tickets et de contournements sans pouvoir dire un correctif temporaire d'une particularité permanente de la façon dont l'entreprise fonctionne réellement.

Eric approfondit tous les 5 points dans le document complet. [Téléchargez L'écart mémoire des projets ERP ici.]

Pourquoi les comités de direction détectent-ils le risque si tard?

Le risque commence souvent par de petits signaux : la même question se pose trois fois, personne ne possède clairement le problème ou une salle reste silencieuse au lieu de repousser.

L'équipe entend souvent le murmure des semaines à l'avance. Et pourtant, la plupart des rapports ne capturent que le cri, quand le problème est déjà bruyant et clair.

Est-ce un problème de documentation?

La plupart des programmes noient déjà sous la documentation. Ajouter plus n'aidera pas.

Une transcription de réunion est de la matière brute dans un dossier. La transformer en mémoire signifie pouvoir poser une question, obtenir une réponse ancrée dans ce qui s'est réellement passé et remonter n'importe quelle décision directement jusqu'à celui qui l'a prise.

Si l'un de ces points ressemble à votre programme, il pourrait être utile de vous poser cette question inconfortable :

Que se passe-t-il quand la personne qui sait n'est pas là, et que personne d'autre ne peut reconstituer ce qui s'est réellement passé?

Eric a construit ce cadre exactement pour ce moment, donc si vous n'aimez pas la réponse à cette question, vous pouvez faire quelque chose à ce sujet.

[Téléchargez L'écart mémoire des projets ERP ici.]

Questions fréquemment posées

Quel est l'écart mémoire des projets ERP?

L'incapacité à reconstituer, à partir de preuves réelles, comment un projet ERP a atteint son état actuel. Les programmes accumulent la documentation et ne peuvent toujours pas répondre aux questions historiques basiques rapidement.

Où le contexte des projets ERP se perd-il le plus souvent?

5 points : la transition vente-vers-livraison, l'intégration des nouveaux membres de l'équipe en cours de projet, la récupération d'une implémentation en difficulté, la gouvernance de direction, et la transition de l'équipe de projet vers le support.

Pourquoi les risques sont-ils détectés tard dans les comités de direction ERP?

Le risque émerge généralement dans les ateliers et les conversations informelles des semaines avant d'atteindre un rapport officiel. La plupart des rapports de statut ne capturent les problèmes qu'une fois qu'ils sont déjà visibles.

Un écart mémoire de projet est-il simplement un problème de documentation?

Les programmes contiennent déjà beaucoup de documentation. L'écart réside dans l'incapacité à reconstituer les décisions et leur raisonnement à partir de ce pile quand quelqu'un en a besoin.