Produire les artefacts n’est pas le problème. Les garder reliés, si.
Best practices, résultats d’atelier, décisions fit-to-standard, variantes, exigences, écarts, objets WRICEF, spécifications, tickets, cas de test, documentation. Chacun propre pour soi – et à la fin, plus personne ne sait pourquoi telle chose a été construite.
L’essentiel
Du standard à votre solution – de façon traçable
Un projet SAP part du processus métier et se retrouve très vite dans les applications, la configuration et les développements. TAOM garde visible le point de départ métier.

Fit-to-standard
Un résultat d’atelier vaut plus qu’un compte rendu
Ce dont on discute en atelier
- 01Qu’est-ce qui convient ?
- 02Qu’est-ce qui ne convient pas ?
- 03Quelles différences organisationnelles existent ?
- 04Quelles modifications système sont nécessaires ?
- 05Quelles interfaces sont concernées ?
- 06Quels rapports ou formulaires manquent ?
Où cela appartient
Ces réponses sont attachées à l’étape où elles sont apparues – pas dans un fichier portant la date de l’atelier.
La ligne de compte rendu devient un contexte d’entreprise que l’on comprend encore six mois plus tard.
WRICEF
Des objets de développement avec leur provenance
Les développements spécifiques sont le plus souvent tenus à l’écart du modèle. Dans TAOM, ils sont attachés à l’activité et à l’exigence dont ils sont issus.
Workflow
Des déroulements pilotés dans le système.
Report
Rapports et listes.
Interface
Interfaces vers d’autres systèmes.
Conversion
Reprises de données et migration.
Enhancement
Extensions du standard.
Form
Formulaires et documents.
Le sigle importe peu – selon le projet, d’autres découpages sont possibles. Ce qui compte, c’est la traçabilité : besoin métier → exigence → objet de développement → réalisation.
Périmètre
Signavio peut rester où il est
Qui exploite une plateforme de processus établie n’a pas à la remplacer. TAOM se place à côté et fournit ce qui manque entre la découverte et la réalisation.

Jusqu’à la preuve
On teste contre le besoin métier
La chaîne jusqu’à l’approbation
- 01Processus
- 02Exigence
- 03Réalisation
- 04Exigence de test
- 05Cas de test
- 06Résultat
- 07Approbation
Pourquoi cela compte
Sinon on teste contre la spécification – donc contre ce que quelqu’un a écrit, non contre ce dont on avait besoin. Si la chaîne reste reliée, on peut vérifier les deux.
Lors de la recette, on peut ainsi montrer quel besoin métier est couvert par quel cas de test.
Projets typiques
Où cela s’emploie
- 01Transformation S/4HANAGreenfield comme brownfield, avec une comparaison traçable au standard.
- 02Programmes de template globalUn noyau, beaucoup de pays – des écarts justifiés plutôt que tolérés.
- 03Ateliers fit-to-standardLes résultats atterrissent sur l’étape plutôt que dans le compte rendu.
- 04Harmonisation des processusRendre les variantes visibles avant de les fusionner.
- 05Gestion des WRICEFDes objets de développement avec provenance et priorité.
- 06Test et validationDu besoin métier jusqu’à la preuve.
Commencer
Avec un processus du projet en cours
Prenez un déroulement qui passe de toute façon en fit-to-standard. Le relever, le confronter au standard, nommer l’écart, en déduire l’exigence – et voir si le lien tient.