Chapitre 8 – Guide de choix des architectures et solutions
8.2 Choix de solutions
Figure 8.1— Rappel des principaux critères de choix d’architectures
8.2 CHOIX DE SOLUTIONS
Nous avons évoqué plusieurs types de solutions et leurs besoins associés au chapitre 5. Nous nous focalisons ici sur la gestion des données de référence afin de déterminer si elle doit être effectuée par :
• un développement spécifique ;
• un progiciel métier (ERP, CRM) ;
• une solution de MDM (que l’on peut assimiler à un progiciel spécifique pour la gestion des données de référence).
Le tableau 8.2 et la figure 8.2 donnent quelques éléments de choix.
Notons à nouveau que les sous catégories d’outils MDM peuvent répondre diffé-remment aux critères exprimés ici. Notre analyse ne prend pas en compte cette seg-mentation. De plus, une solution MDM couvre, à notre sens, les applications référentielles MDM ainsi que le DQM ; nous ne faisons donc pas la distinction.
Figure 8.2 – Critères différenciateurs entre MDM, développements spécifiques et progiciels
Tableau 8.2— Guide de choix de solutions
Critères Commentaire
Modélisation
L’entreprise travaille-t-elle plus par définition de ses objets ou par alignement ?
Existe-t-il déjà un modèle d’objet métier pour le paradigme concerné (pivot, développements
spécifiques…) ?
Dans le cas de la définition ou de l’intégration d’un modèle existant, le MDM et le développement spécifique sont seuls à offrir suffisamment de flexibilité. Le spécifique demande une modélisation physique, contrainte par le relationnel. Le MDM se contente généralement d’une modélisation logique ou offre une modélisation flexible (XML).
Dans le cas de l’alignement, MDM et progiciel répondent au besoin. Les solutions progicielles viennent toutes avec un modèle et une méthode d’alignement. Les MDM arrive généralement avec des modèles pré-intégrés servant d’accélérateur.
Évolutivité du modèle
Le périmètre du paradigme concerné sera-t-il mis en œuvre par itération ? L’objet est-il appelé à évoluer fréquemment ou reste-t-il stable dans le temps ?
Dans le cas d’une évolutivité forte ou d’une mise en œuvre par itération, le MDM et le développement spécifique sont préférables. Les contraintes de modélisation du spécifique limiteront cependant son évolutivité à moyenne échéance.
Les solutions progicielles contraignent des périmètres de mise en œuvre (au niveau modèle, droits, règles, cohérence).
163 8.2 Choix de solutions
Gestion d’états multiples
Les cas d’utilisation, au long du cycle de vie métier de la donnée, sont-ils nombreux, multipliant ainsi les états que la donnée doit supporter ?
Seul le MDM permet la gestion de multiples états de la donnée avec les combinaisons de règles et de droits propres à chaque état.
Le développement spécifique est disqualifié.
Particularités métier fortes L’objet à supporter est-il très spécifique, propre à un métier peu répandu ? (cas des administrations)
Le développement spécifique semble être le plus indiqué, mais en apparence seulement. Le MDM offre en mode projet la flexibilité de la modélisation et une plus grande maîtrise des métadonnées (modèle et sémantique) et permet à terme plus de flexibilité pour l’évolution.
Volumétrie
Quel est le nombre d’occurrences de l’objet ou d’ID ?
Quel coefficient multiplicateur doit être appliqué en raison de l’historisation ?
La volumétrie en nombre d’objets peut aller de quelques centaines d’occurrences à plusieurs centaines de millions d’enregistrements.
Sur les fortes volumétries (plusieurs millions), les progiciels seront distancés en capacité de gestion, si ce n’est en nombre d’enregistrements.
Les solutions MDM ne sont pas toutes équivalentes face à la volumétrie et une étude particulière pour telle ou telle solution de tel ou tel éditeur devra donc être menée, d’autant plus si les capacités
fonctionnelles attendues incluent des recherches complexes. Certaines solutions supportent cependant de très fortes volumétries (dizaines de millions).
Le développement spécifique peut tirer son épingle du jeu sur les très grandes volumétries (plusieurs dizaines voire centaines de millions), couplées à des attentes particulières (modèle ou fonctions).
Taux de couverture des progiciels La couverture offerte par le modèle de donnée du progiciel en pourcentage du nombre d’attributs, ainsi qu’en criticité des attributs détenus, est-elle importante ?
L’écart entre le modèle détenu et la cible, ainsi que les fonctions ou règles à développer n’impliquent-ils pas un éloignement trop important du standard du progiciel ?
Le taux de couverture fonctionnel et celui du modèle doivent être maximaux pour être compatibles avec la mise en œuvre d’un progiciel.
Les écarts sont gênants pour le support et les montées de version.
Gestion des droits – nombre intervenants
Les intervenants humains ou machines sont-ils nombreux, multipliant les profils ?
Les droits doivent-ils être gérés avec précision, sur des périmètres très segmentés ou en multipropriété ?
Plus les profils et les besoins de maîtrise des droits sur la donnée sont importants, plus le MDM permet une gestion fine (au niveau attributs, fonctions, par rapport aux valeurs) et aisée (profils, groupe de profils, duplication de profils pour création…).
Critères Commentaire
Applications connectées – amont Plus le nombre d’applications source est important, plus le MDM est préférable. Que ce soit en coopération pour la maîtrise transactionnelle ou en consolidation pour les capacités de déduplication et de key mapping.
Applications connectées – aval Plus le nombre d’applications cibles est important, plus le MDM offre de flexibilité en termes de mode de connexion, de décorrélation avec les sources, de gestion des processus de synchronisation.
Flux « fil de l’eau » Les solutions progiciel ou MDM supportent mieux le « fil de l’eau ».
Les progiciels induisent souvent des traitements « fil de l’eau » ou synchrones.
Le MDM reste favori face au progiciel pour les fonctions supplémentaires qu’il apporte (gestion événementielle).
Flux ordonnancés – en masse Les flux ordonnancés et/ou en masse ne sont pas tellement différenciateurs.
Léger avantage cependant au MDM qui offre toujours sa flexibilité et intègre la gestion événementielle.
Mode classique, par extraction ou duplication sur le spécifique.
Mode classique sur les progiciels.
Fonctions qualité
La solution doit-elle couvrir des besoins de standardisation complexe (adresse, acronyme, abréviation) ou de déduplication ?
Seule la solution MDM offre un support complet à la qualité (en lien avec le DQM).
Le développement spécifique en fin de chaîne, de l’information s’il est couplé à un DQM, peut offrir un certain niveau de qualité en redressement (cas du BI standard).
Le progiciel n’offre pas de fonction qualité.
Historique IT
Les compétences et les habitudes de la DSI sont-elles plus orientées spécifique ou progiciel ?
Les entreprises ayant une forte culture du développement spécifique et/ou ayant de nombreuses applications et compétences internes pour gérer le spécifiques passeront plus difficilement au progiciel ou au MDM.
Si le pas est franchi, il se fera au bénéfice du MDM plutôt que du progiciel. Les progiciels sont généralement supportés par les métiers.
Administration – métiers ou IT L’administration de la solution de gestion des données de référence est-elle réalisée par les métiers ou l’IT ?
Si les équipes d’administration pressenties sont IT alors le MDM et le développement spécifique sont plus adaptés. Le MDM reste préférable car il offre des fonctions propres à l’administration.
Si les équipes d’administrations sont métiers, alors elles ont tendance à préférer les progiciels. Mais ce point sera contrebalancé au profit du MDM si les intervenants métier sont nombreux.
Critères Commentaire
165 8.2 Choix de solutions
Stratégie DSI – urbanisme – SOA L’entreprise est-elle dotée d’une cellule d’urbanisme ? Les préceptes de la discipline influent-ils sur le SI ? La démarche référentielle répond-elle à une vision d’ensemble, généralisée ? La DSI est-elle engagée dans une stratégie IT orientée SOA ? ou du moins profite-t-elle des outils urbanisants (par exemple, EAI) ?
Le MDM est une réponse logique d’urbaniste, d’autant plus adaptée que la démarche est généralisée (certains outils MDM peuvent couvrir de multiples paradigmes).
Idem dans le cadre d’une stratégie SOA, le MDM est considéré comme une brique constitutive de cette stratégie.
Besoin de gestion multi-entité, multimétier ou métier, mono-entité
La solution doit-elle couvrir plusieurs métiers, plusieurs entités
organisationnelles ?
Plus la solution est répartie entre entités et sur plusieurs métiers, moins le progiciel est adapté.
MDM et spécifique restent utilisables, avec un net avantage pour le MDM du fait de ses capacités de gestion (droits) et de contextualisation.
Coût – ticket d’entrée
L’entreprise a-t-elle estimé les coûts d’un projet référentiel à leurs justes valeurs ou a-t-elle tendance à considérer que cela revient à mettre une simple base dans une partie du SI ?
Le spécifique semble toujours offrir un coût facial moindre. Cela reste vrai sur de petits projets.
La mise en place d’un progiciel pour le métier (un CRM par exemple) peut aussi être ressentie comme l’opportunité d’utiliser celui-ci sans générer de coûts supplémentaires.
Seule une approche tactique permet la diminution de ce ticket d’entrée pour le MDM, sans l’annuler.
Coût - ROI/TCO Sur des projets de plus grande ampleur, l’analyse ROI/TCO profitera au MDM grâce à la diminution des points de gestion multiples dans le SI et l’amélioration des processus métier consommateurs (plus étendue qu’avec un simple progiciel qui n’améliore que ses propres processus).
Immaturité « processus » de l’entreprise
L’entreprise a-t-elle déjà documenté et outillé ses grands processus (par exemple, «Order to Cash») ? Ces processus ont-ils déjà été améliorés ?
Dans une entreprise qui n’en est qu’au début de l’outillage de ses processus, il y a beaucoup plus de valeur à générer par la mise en place des progiciels qui vont les structurer que par l’outillage de la donnée. On utilise dans une telle phase les progiciels comme référentiel.
Seule exception, quand le processus métier est un processus de gestion de données (par exemple référencement produit dans la grande distribution, ou gestion des catalogues pour les services achats), on outille préférentiellement avec une solution MDM adaptée.
Maîtrise des processus
La solution de gestion de données de référence outille-t-elle les processus d’acquisition de la donnée ?
Ces processus sont-ils complexes, font-ils participer de multiples proffont-ils intervenants ?
Le développement spécifique est disqualifié.
Le progiciel couvre les seuls processus prévus à son périmètre.
Avantage donc au MDM qui généralement favorise la modélisation des processus d’acquisition.
Critères Commentaire
La figure 8.3 résume les conclusions pour le choix de solutions.
Figure 8.3 – Principaux critères et choix de solutions