Fonctionnel et amont
Vue métier du système : quels rôles, quels processus, et par quels modules applicatifs y répondre - avant toute décision technique.
Ma contributionLe projet en quelques mots
Le client fictif est un grand groupe agroalimentaire d'environ 20 000 salariés dont le système financier, un SAP ECC vieillissant, doit être remplacé par SAP S/4HANA Finance. Le périmètre est volontairement circonscrit à la finance : comptabilité générale et tiers, contrôle de gestion, trésorerie, consolidation du groupe et notes de frais.
Notre cabinet comptait six consultants, chacun responsable d'un lot du dossier d'architecture, avec une revue croisée avant intégration finale.
Socle conceptuel et règles
Vue d'ensemble et structure de la cible, caractéristiques attendues, décisions d'architecture et principes directeurs.
Autres membresPiliers applicatifs
Accès utilisateurs, cœur financier, intégration, systèmes externes, données et plateforme d'extension.
Autres membresInfrastructure
Architecture physique, hébergement multi-sites et plan de reprise d'activité.
Autres membresMes deux schémas
Mon lot consistait à produire la couche que le client peut lire et valider sans être informaticien. Deux vues complémentaires, du général au détail.
Tracer chaque case à une parole du client
Le risque, sur ce genre de schéma, n'est pas d'oublier des fonctions : c'est d'en ajouter trop. Un outil comme SAP sait tout faire, et il est tentant de remplir la carte de tout ce qu'il propose. L'équipe s'est donc imposé une règle simple, formulée autour d'un exemple historique : le Vasa, ce navire de guerre suédois coulé lors de son voyage inaugural pour avoir accumulé les exigences ajoutées en cours de construction.
Concrètement, toute fonction inscrite sur la carte devait pouvoir être rattachée à une phrase prononcée par le client, en entretien ou en séance de cadrage. Une case qui ne trace à rien est une sur-spécification.
J'ai appliqué cette règle en confrontant mes deux schémas aux comptes rendus d'entretien. Sept écarts en sont ressortis, classés par priorité, et tous ont été intégrés à la version finale :
- Un référentiel des taux de change et la gestion des devises parallèles, le client ayant longuement insisté sur ce sujet alors que les schémas ne l'effleuraient.
- La séparation des tâches et l'authentification, explicitement demandées en séance sécurité mais absentes du volet administration.
- Un domaine transverse de données de référence - plan comptable, référentiel tiers, structure du groupe - jusque-là éparpillé entre plusieurs modules.
- Le masquage des données de direction, seul moyen de traduire l'exigence de confidentialité en fonction concrète.
- La preuve d'archivage retournée par la gestion documentaire, le client exigeant un double stockage avec accusé.
- Le périmètre de consolidation du groupe, dont les mécaniques étaient présentes mais pas la définition.
- Un reporting extra-financier, laissé grisé en trajectoire : une piste évoquée par le client, montrée sans y sur-investir.
Ce que la défaite nous a appris
Nous avons perdu la battle
Le jury attendait majoritairement une architecture technique. En équipe, nous avions décidé de l'inverse : réduire la part technique pour investir l'essentiel de notre effort dans l'architecture fonctionnelle. Le travail était rigoureux, traçable et défendable - mais il répondait à une question qui n'était pas celle qui était posée.
Synthèse du projet
Travail réalisé
La vue fonctionnelle complète d'un système financier : une architecture en trois couches reliant métiers, modules et socle technique, et une carte détaillée des fonctions croisée avec sept rôles utilisateurs - le tout justifié écart par écart face aux besoins exprimés par le client.
Ce que le projet m'a apporté
Une première immersion dans la posture de conseil : mener un entretien de cadrage, transformer des paroles de client en exigences, et défendre ses choix devant un jury. Et une leçon durable sur l'écart entre bien répondre et répondre à la bonne question.