Démonstration SAP Activate — tutoriel de bout en bout
Importez le pack SAP Activate et pilotez une migration fictive ECC 6.0 → S/4HANA Cloud Public pour Northwind Retail Group à travers les six étapes.
Objectif
À la fin de ce tutoriel, vous aurez importé le Pack Scrydon SAP Activate (Demo) dans votre tenant, créé une nouvelle instance pour le projet fictif de migration Northwind Retail Group ECC 6.0 → S/4HANA Cloud Public, piloté le projet à travers les six étapes SAP Activate (Discover → Prepare → Explore → Realize → Deploy → Run), et produit un rapport de sortie hypercare signé.
Anika Schroeder, Directrice de Programme chez Northwind Retail Group, et le Dr Stefano Bassi (Architecte Solution DXC) sont les personnages fictifs principaux. La migration sur 12 pays, le budget de 16,9 M€, le passage en production BeNeLux Wave 1 — tout est fictif — et n'existe que pour donner au flow SAP Activate un récit concret à illustrer.
Le pack SAP Activate est distribué sans personas dans le manifeste du modèle. Chaque tâche peut être assignée à n'importe quel utilisateur au moment de la création de l'instance ; le récit de démo utilise des rôles nommés fictifs pour illustrer le flow. Le pack distribue également un sous-répertoire d'ontologie vide aujourd'hui (objectTypes: []) ; une itération future pourrait ajouter les types d'objets Sprint, Backlog, RicefwObject, QGate pour que les tâches émettent des instances typées interrogeables entre les vagues.
Prérequis
Vous disposez d'un déploiement Scrydon avec les surfaces agentic et ontologie activées. Définissez les variables d'environnement suivantes dans votre shell pour l'étape d'import :
export SCRYDON_URL="https://<your-scrydon-url>"
export ORG_ID="<your-org-id>"
export SESSION_COOKIE="$(cat ~/.scrydon/session-cookie)"Étape 1 — Télécharger le pack
Télécharger sap-activate-demo-3.0.0.scrydon-pack.tar.gz
mkdir -p sap-activate-tutorial && cd sap-activate-tutorial
curl -O https://docs.scrydon.com/static/process-pack-examples/sap-activate-demo-3.0.0.scrydon-pack.tar.gzLe pack fait environ 4 Kio.
Étape 2 — Inspecter le pack
bunx @scrydon/sdk-authoring pack inspect sap-activate-demo-3.0.0.scrydon-pack.tar.gzPack:
Package: sap-activate-demo@3.0.0
Contents: ontology@3.0.0, process-flow@3.0.0
Install order: ontology → process-flow
ontology: sap-activate-demo@3.0.0
process-flow: sap-activate-demo (6 stages)Étape 3 — Téléverser le pack
curl -X POST "$SCRYDON_URL/api/packs/import?organizationId=$ORG_ID" \
-H "Cookie: $SESSION_COOKIE" \
-F "file=@sap-activate-demo-3.0.0.scrydon-pack.tar.gz"La réponse 200 porte le nouveau processTemplateId et une branche d'ontologie stub.
Étape 4 — Créer une nouvelle instance de projet
Naviguez vers $SCRYDON_URL/process-flows. La carte SAP Activate (Demo) apparaît sous le tag Enterprise Implementation. Cliquez sur Nouveau depuis le modèle, nommez l'instance Northwind Retail S/4HANA Cloud Migration.
L'instance s'ouvre en vue tracker par défaut. Six couloirs d'étapes apparaissent :
- Discover — 10 tâches (évaluation stratégique).
- Prepare — 10 tâches (mise en place du projet, gouvernance, sandbox).
- Explore — 12 tâches (ateliers fit-to-standard, backlog).
- Realize — 12 tâches (exécution des sprints, WRICEF, tests).
- Deploy — 7 tâches (bascule, mise en production).
- Run — 6 tâches (hypercare, optimisation).
Les étapes sont séquentielles (stageFlow: "sequential"), les tâches au sein d'une étape s'exécutent en parallèle là où le DAG le permet. Chaque étape se termine par une tâche Validation Q-Gate — la porte formelle SAP Activate.
Étape 5 — Discover : cadrer la stratégie
L'étape Discover est la phase d'évaluation stratégique. Anika et le comité de pilotage parcourent 10 tâches :
| Tâche | Entrée démo |
|---|---|
| Identifier les objectifs stratégiques métier et IT | Cinq objectifs stratégiques O-1 … O-5 (voir charte du projet) |
| Animer l'atelier SAP Discovery Assessment | Atelier commun DXC + NW les 24–25 fév. 2026 |
| Cartographier le paysage des processus métier as-is | 412 magasins × 12 pays sur ECC 6.0 depuis 2008 |
| Cartographier l'architecture IT as-is | Inventaire LeanIX ; 47 transactions Z personnalisées identifiées |
| Réaliser la correspondance scénarios métier / solution | Hypothèse greenfield-first confirmée |
| Vérifier la disponibilité à la conversion du SAP ERP actuel | ECC 6.0 EOM 2027 ; prêt pour conversion avec réserves |
| Sélectionner la stratégie d'implémentation | Greenfield (avec pont d'archivage FI) |
| Sélectionner l'option de déploiement | S/4HANA Cloud Public (locataire unique 12 pays) |
| Créer la feuille de route stratégique et le dossier de valeur | Plan 18 mois, 3 vagues de 4 pays |
| Téléverser la documentation de l'état actuel | Inventaire + cartographies des processus as-is |
Anika ouvre ensuite Validation du comité de pilotage sur la stratégie — l'action approval bloquant le Q-Gate. Le CFO Pieter Vandermeer signe en tant que sponsor exécutif.
Étape 6 — Prepare : mettre en place la gouvernance du projet
L'étape Prepare est celle où le projet passe de la stratégie à l'exécution. Anika pilote 10 tâches de mise en place :
Télécharger 01-project-charter.md — Charte du projet Northwind Retail Group : périmètre, gouvernance, calendrier 18 mois en 3 vagues, budget de 16,9 M€, top-5 des risques.
Les 10 tâches comprennent la création du WBS, la définition du RACI pour l'équipe projet de 47 personnes, le provisionnement du tenant sandbox SAP Best Practice (utilisé pour les ateliers fit-to-standard à l'étape suivante), la mise en place des outils Solution Manager + Signavio + LeanIX, et l'intégration des 47 membres de l'équipe. L'étape se termine par la Validation Q-Gate Prepare.
Étape 7 — Explore : ateliers Fit-to-Standard
L'étape Explore est celle où se déroule l'essentiel du projet — les ateliers Fit-to-Standard (F2S) cartographient les processus as-is sur les périmètres SAP Best Practice, l'analyse des écarts identifie les objets WRICEF, et le backlog est signé par les parties prenantes.
Télécharger 02-fit-to-standard-outcomes.md — Résultats du cycle F2S 1 pour MM + SD + FI (atelier de 5 jours, 12–16 mai 2026). 84 % de l'as-is correspond 1:1 aux Best Practices ; 7 objets RICEFW identifiés ; 31 tables Z personnalisées consolidées en une seule technique de condition.
Les 12 tâches d'Explore guident l'équipe à travers chaque aspect : animation des ateliers, documentation des écarts, architecture cible, cartographies des interfaces, stratégie de tests, analyse des besoins de formation, analyse d'impact du changement, et plan de chargement des données. L'étape se termine par la Validation Q-Gate Explore — Anika, Cindy (FI), Sofie (SD), Marek (MM), Dr. Bassi (DXC), et l'observateur audit Jürgen.
Étape 8 — Realize : construire, tester, préparer la bascule
L'étape Realize est la plus longue (37 semaines dans le plan de projet). 12 tâches couvrent :
- Configurer le système SAP selon le backlog — configuration sprint par sprint de MM, SD, FI, CO, EWM, AA, PP.
- Développer les objets WRICEF — les 7 objets backlog d'Explore.
- Charger les données maîtres et transactionnelles — dans le tenant QA.
- Exécuter les tests unitaires, d'intégration, UAT — trois couches de tests.
- Exécuter les tests de migration de données / répétition générale — répétition complète de bascule de 60 heures en QA.
- Préparer le plan de bascule — voir l'étape 9.
- Développer les matériaux d'adoption et de formation — réseau de changement de 87 magasins pour la Wave 1.
L'étape se termine par la Validation Q-Gate Realize, qui est le go/no-go formel pour la bascule. Cette porte exécute un workflow human-in-the-loop (« Approuver la transition vers Deploy ? ») : pendant l'attente, l'action workflow et l'en-tête de l'instance affichent « En attente d'acceptation Human-in-the-loop » (pas un générique « En cours ») et nomment le réviseur, de sorte qu'il est clair que l'exécution est en pause sur une personne plutôt que bloquée. Celui que vous avez mappé au persona réviseur de la porte sur cette instance est notifié (et peut approuver) ; si personne ne détient ce persona, cela revient au rôle org du même nom. Le réviseur approuve ou rejette directement depuis la notification (Notifications → cliquez sur la revue → Approuver/Rejeter), et l'instance avance vers Deploy. Conseil : si vous attendez une notification mais ne la recevez pas, vérifiez que votre utilisateur est mappé au persona réviseur — être owner de l'organisation n'est pas la même chose que détenir le persona/rôle « admin ».
Étape 9 — Deploy : bascule et mise en production
L'étape Deploy exécute le plan de bascule. Pour la Wave 1 (BeNeLux, 87 magasins) :
Télécharger 03-cutover-plan.md — le plan de bascule de 60 heures : gel d'ECC NL/BE/LU sam. 18h00 CEST, migration des données maîtres et transactionnelles tout au long du dimanche, activation du tenant de production S/4 dim. 12h00, validation, et ouverture aux magasins lun. 06h00 CEST.
Les 7 tâches Deploy guident la phase de bascule étape par étape. L'action approval sur Go/No-Go Final à T-12 heures est le dernier point de réversibilité. La vague se termine quand les magasins transactent avec succès sur S/4HANA Cloud Public.
Étape 10 — Run : hypercare et transition BAU
L'étape Run couvre la période d'hypercare de 14 jours pour chaque vague + la transition vers le fonctionnement habituel. 6 tâches :
- Surveiller la porte KPI — temps de clôture du cycle, taux d'erreur order-to-cash, taux d'approbation automatique du réapprovisionnement prédictif, variance de réconciliation GL.
- Trier les incidents hypercare — P0 < 15 min, P1 < 1 h, P2 < 4 h.
- Sync war-room quotidien — équipe projet complète pendant les 7 premiers jours, puis un jour sur deux.
- Validation par pays — les propriétaires de processus par pays acceptent formellement S/4.
- Émettre le rapport de sortie hypercare — voir ci-dessous.
- Transition vers le backlog BAU — les améliorations différées passent au backlog permanent de l'étape Run.
Télécharger 04-hypercare-exit-report.md — Rapport de sortie hypercare Wave 1 (BeNeLux) : 14 jours, 47 tickets (0 P0, 3 P1, 11 P2, 33 P3+), les quatre KPI de porte de sortie au vert dès le jour 5.
Run est une étape récurrente — une fois la Wave 1 sortie de l'hypercare, le projet repart en Deploy pour la Wave 2 (DACH), puis à nouveau pour la Wave 3. La même instance porte chaque vague à travers Deploy → Run comme des fils de sous-tâches séparés.
Trois variantes d'erreur à observer
| Erreur | Comment la déclencher | Ce que cela signifie |
|---|---|---|
STAGE_DEPENDENCY_NOT_MET | Ouvrir Validation Q-Gate Realize avant que toutes les tâches Realize soient terminées. | stageFlow séquentiel appliqué. |
TASK_DAG_BLOCKED | Essayer de démarrer Exécuter le User Acceptance Testing (UAT) avant que Exécuter les tests d'intégration (environnement QA) soit terminé. | dependsOnTaskSlugs appliqué. |
Q_GATE_REJECTED (modélisé comme rejet approval) | Rejeter Validation Q-Gate Explore. | L'instance n'avance pas ; le backlog retourne à l'étape Explore avec un commentaire de rejet. |
Personnaliser le pack
Le plan de projet de Northwind Retail diverge du pack distribué sur trois points : la structure WBS, le regroupement des vagues par pays, et les définitions des KPI d'hypercare. Trois chemins de personnalisation :
- Forker le pack en TypeScript. Copiez
packages/sdk-authoring/src/process-flows/examples/sap-activate-demo/index.tsdans votre propre projet SDK, modifiez, changezpackage.idettemplate.slugvers une valeur personnalisée (ex.northwind-s4-migration), et reconstruisez avecbunx @scrydon/sdk-authoring pack build src/pack.ts --outDir dist. - Ajouter des contributions d'ontologie typées. Une version future pourrait ajouter les types d'objets
Sprint,Backlog,RicefwObject,QGate,KPIsous leontology/manifest.jsondu pack pour que les tâches émettent des instances typées — rendant « montrez-moi tous les objets RICEFW sur toutes les vagues » ou « quels incidents hypercare remontent à un Q-Gate spécifique » interrogeables. - Assigner des personas au moment de l'instance. Le pack est distribué sans personas ; chaque instance peut câbler ses propres personas spécifiques à l'organisation dans l'interface agentic lors de la création de l'instance du modèle.
Si vous forkez, changez le slug et le package.id pour les différencier de sap-activate-demo pour éviter les collisions avec le pack d'exemple s'il est jamais importé dans le même espace de travail.