Oracle Fusion : un core model doit organiser les écarts, pas les ignorer.
Standardiser un programme international suppose de distinguer ce qui doit être commun, ce qui peut varier et qui a l’autorité pour décider.
Publié le · À propos des dates
Mis à jour le
Le point de vue Spark
Un core model utile ne cherche pas à supprimer toute différence. Il définit ce qui doit être commun, les variations admises et la façon de décider des exceptions. Sans cette gouvernance, chaque vague risque de reconstruire le débat.
- Distinguer obligation locale, besoin métier et préférence historique.
- Relier chaque écart aux processus, aux données et aux tests concernés.
- Donner un responsable et une règle de réexamen aux exceptions.
1. Définir le commun avec un niveau de détail exploitable
« Tous les pays suivront le même processus » semble clair, mais ne précise pas les responsabilités, les données nécessaires ni les règles d’approbation. Un standard doit permettre à l’équipe de réalisation de savoir ce qu’elle peut configurer et ce qui doit être arbitré.
Nous proposons de décrire le socle commun sous trois angles : le résultat métier attendu, les règles partagées et les variations explicitement admises. Une règle de contrôle peut rester commune alors que les acteurs ou les modalités d’exécution diffèrent selon l’organisation.
Oracle propose des mécanismes de partage des données de référence, avec des ensembles communs ou spécifiques selon le besoin. Leur existence ne détermine pas la politique de l’entreprise : il reste à décider quelles données partager et sur quel périmètre. Voir la documentation Oracle sur les Reference Data Sets.
2. Qualifier un écart avant de choisir sa solution
Une demande locale mérite d’être comprise avant d’être acceptée ou rejetée. Une habitude n’a pas le même poids qu’une obligation documentée ; un besoin commun à plusieurs entités ne doit pas nécessairement devenir une série d’exceptions isolées.
| Nature de la demande | Élément à obtenir | Décision à préparer |
|---|---|---|
| Obligation locale | Exigence précise confirmée par le responsable compétent. | Comment la satisfaire sur le périmètre concerné ? |
| Besoin opérationnel | Usage, conséquence et utilisateurs concernés. | Variation locale ou évolution du standard ? |
| Préférence historique | Raison de conserver le fonctionnement actuel. | Adapter le processus ou accompagner le changement ? |
| Contrainte temporaire | Dépendance et condition de disparition. | Exception limitée avec responsable et réexamen. |
Cette classification organise la discussion ; elle ne remplace ni une analyse réglementaire locale ni la validation fonctionnelle. Le registre doit conserver les éléments qui justifient la décision, et pas seulement son résultat.
3. Exemple : deux demandes proches, deux réponses différentes
L’intérêt du registre est de permettre à la vague suivante de comprendre cette logique. Elle peut réutiliser une décision si les conditions sont comparables, ou faire apparaître une différence qui justifie un nouvel examen.
4. Suivre le coût complet d’une exception
Un écart accepté ne s’arrête pas au paramétrage. Il peut modifier une interface, une donnée de référence, un rôle, un support de formation ou un scénario de test. La décision doit donc rendre visibles les contributions nécessaires.
Nous recommandons de relier chaque exception à sa couverture de test et à son propriétaire. Si une règle change, l’équipe doit pouvoir retrouver les entités concernées et les validations à reprendre. Une décision conservée dans un compte rendu isolé est difficile à exploiter lorsque plusieurs vagues se chevauchent.
- Identifier les objets et processus affectés.
- Nommer le responsable de la décision et celui de la réalisation.
- Documenter les tests du fonctionnement commun et de sa variation.
- Prévoir les conséquences pour la documentation et le support.
Une exception temporaire doit avoir une condition de sortie vérifiable. « À supprimer plus tard » n’organise aucun travail. Le réexamen peut être associé à la disponibilité d’une interface, à une évolution organisationnelle ou à une prochaine décision de programme.
5. Le registre minimal pour la prochaine vague
- Demande : quel usage ou quelle exigence motive l’écart ?
- Périmètre : quels processus, entités et données sont concernés ?
- Options : quelles réponses ont été comparées ?
- Arbitrage : qui décide, sur quels éléments et avec quelles réserves ?
- Réalisation : quelles modifications et validations sont nécessaires ?
- Réexamen : à quelle condition la décision doit-elle être revue ?
Le core model devient ainsi un outil de réalisation et de transmission. Les différences restent visibles, mais elles ne sont plus traitées comme une succession de négociations sans mémoire.
Source et périmètre
La référence Oracle décrit un mécanisme de partage des données. La gouvernance, la grille et le scénario présentés sont des propositions éditoriales Spark ; ils ne constituent pas une prescription Oracle ni un cas client.
