Accueil / TAOM™ pour la transformation SAP

TAOM™ pour la transformation SAP

Solution · Transformation SAP

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.

Du SAP Best Practice à l’examen en atelier, puis fit ou écart, d’où une exigence motivée et enfin la configuration ou un WRICEF.

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.

Un écart sans justification ne vaut rien. C’est pourquoi la chaîne reste visible pour chaque écart : étape → exigence client → écart → piste de solution → objet de livraison. Qui demandera plus tard pourquoi une extension existe trouvera la réponse sur le processus.

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.

Chaîne allant du SAP Best Practice à l’analyse TAOM, à l’enrichissement, à l’exigence et au WRICEF, à la réalisation et au processus approuvé, jusqu’au référentiel de processus existant.

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.

Sur l’état de la connexion, dit franchement : Type de ticket, priorité, statut, composant, version et responsable sont portés par l’élément et enregistrés avec lui – c’est la préparation du transfert vers Jira. Il n’existe pas de synchronisation continue à ce jour. Détails sous Integrationen.

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.