Amélioration de la performance des processus

L’amélioration de la performance des processus (figure 7.3) met en œuvre l’automa-tisation orchestrée d’un processus intra-SI, au sein duquel interviennent des acteurs humains et des applications. Les applications peuvent être légataires (Legacy), et l’interface utilisateurs se fait dans le cadre d’IHM agrégées de type portail (ou client riche sur le poste de travail), voire sur des terminaux mobiles.

Figure 7.3— Les principales briques applicatives pour améliorer la performance des processus

Plus le processus est transverse et important, plus le MDM est générateur de valeur.

Prenons un processus transverse tel que « traiter une commande » qui repose sur les données de références métier produit, fournisseur, client, organisation (site logis-tique par exemple), personne (pour les commerciaux par exemple) et sur de nom-breuses données de paramètre (objet d’imputation, devise…).

L’analyse de la mise en œuvre du MDM se fait donnée par donnée (éligibilité du MDM) et pour chaque donnée, attribut par attribut (éligibilité au référentiel).

Cette analyse répond à de multiples considérations issues du cadre de gouver-nance (voir troisième partie). Elle se fait au périmètre du projet concerné pour les critères principaux mais aussi suivant des enjeux plus larges (portefeuille projet, stra-tégie SI…) pour des critères secondaires. La prise en compte et la pondération des critères tant primaires que secondaires doit s’opérer pour tous les projets d’impor-tance car elles sont généralement à l’origine d’un chantier MDM au sein des grands projets. Ainsi, le déclenchement d’une démarche outillée de gouvernance des don-nées pourra apparaître de manière opportuniste et tactique sous l’impulsion des urba-nistes et de la DSI.

Premier zoom sur le cadre d’analyse

Pour chaque donnée, on analyse les contraintes et objectifs issus du cadre de gouver-nance (voir partie 3), comme indiqué ci-après :

La stratégie d’entreprise : si l’entreprise est dans une phase de croissance externe, on favorise par exemple l’outillage des données descriptives et constitutives de la nouvelle organisation. On considère en priorité les référentiels Employés et Organisation pour la partie descriptive mais aussi les référentiels de back office pour la partie constitutive, comme le référentiel de structures comptables afin de permet-tre la consolidation des résultats et la création des liasses fiscales.

La conformité réglementaire : il s’agit par exemple de la confidentialité des informations nominatives et des traitements associés (en rapport avec la CNIL), de la traçabilité en matière écologique ou sanitaire… Le MDM en tant que point focal permet un contrôle accru ou une meilleure indépendance entre entité et processus (séparation entre commercialisateur et distributeur comme l’impose la Commission de régulation de l’énergie, par exemple).

La qualité : voir les niveaux de qualité intrinsèques et de services évoqués dans la première partie.

La sécurité : le MDM peut être utilisé en réponse aux risques relatifs à la donnée (risque financier ou en termes d’image).

On analysera aussi les axes de mise en œuvre influençant l’architecture, exposés ci-après :

Les métiers et l’organisation : ils sont importants afin de valider l’adhérence des sous-processus amont et aval aux référentiels, et d’identifier les acteurs de ces proces-sus. On identifiera ainsi si le référentiel doit être considéré comme un référentiel tech-nique (à la charge de la DSI) ou un référentiel fonctionnel (à la charge des métiers).

Plus le référentiel est fonctionnel (besoins de contrôle, nombre de participants), plus il embarque des fonctions propres au pilotage et favorise donc le MDM. Complétée par le périmètre de donnée gérée, cette étude permet de déduire le mode d’implémentation.

L’urbanisme : en première analyse, on souligne l’importance de :

• la dispersion de la donnée (partage du paradigme) entre processus propres au projet mais aussi avec les autres grands processus de l’entreprise ;

141 7.2 Projets classiques et leurs applications

• la volatilité de la donnée (temps moyens entre modification d’instance, et nombre d’instances d’objets modifiées sur l’ensemble des instances d’objets détenues par un même paradigme).

La dispersion s’analyse en amont et aval du référentiel. En amont, il faut choisir entre les principaux types d’architecture (voir la section 4.2) mais aussi d’outillage.

En aval, apparaissent des besoins en termes de normalisation, gestion événemen-tielle et diffusion.

L’analyse répond à la maîtrise du portefeuille projet (et donc de la pérennité des applications dans le SI) afin d’identifier les périmètres de données et le mode d’implémentation à préférer. La dispersion commande ainsi le Plan de transforma-tion du référentiel, c’est-à-dire l’évolutransforma-tion par étape du référentiel (périmètre et type d’implémentation, donc fonctions) et la maîtrise des flux entrants et sortants.

La volatilité de la donnée induit une architecture agile, une intermédiation rapide (message en synchrone ou « au fil de l’eau ») et un contrôle accru du synchro-nisme.

La conduite du changement : il s’agit d’outiller directement la solution avec des outils de supports tel que l’accès direct au dictionnaire sémantique, des aides en ligne ou un contrôle de saisie.

Les méthodes et outils : on analyse les méthodes et outils existants ainsi que ceux du portefeuille projet.

Au périmètre du MDM, on analyse les différents scénarios de mise en œuvre et le périmètre des fonctions attendues en les confrontant aux autres dimensions du cadre. On en déduira un plan projet en accord avec les charges, le temps et le budget disponibles. On se pose notamment la question de l’utilisation d’un progiciel de ges-tion comme référentiel, le développement d’un logiciel spécifique ou l’utilisages-tion d’un référentiel MDM.

Application dans un exemple concret

Reprenons notre exemple sur le processus « traiter une commande ». Notre entre-prise est un industriel, ses clients sont des distributeurs spécialisés répartis dans le monde entier. Les équipes commerciales gèrent l’ensemble de leurs activités pendant leurs déplacements clients. L’entreprise est stable et ne prévoit pas de procéder à un changement de périmètre (rachat/fusion) dans l’immédiat. Le DSI se souvient pourtant des impacts apparus lors de la dernière réorganisation interne.

L’objectif de l’entreprise est d’améliorer les délais de traitement des commandes, des factures et de leur recouvrement.

Force de vente, logistique et comptabilité sont les trois activités principales con-cernées par la refonte du processus. La force de vente doit pouvoir gérer en mode connecté ou non connecté ses offres, ses clients et ses commandes. La logistique doit améliorer sa réactivité par une meilleure maîtrise des stocks et des expéditions. La comptabilité doit automatiser l’édition et la relance des factures, proposer une

auto-matisation complète à ses principaux clients et améliorer la maîtrise des crédits clients.

L’ensemble des processus dispose d’indicateurs de pilotage pour en apprécier la performance.

L’outillage métier prévu repose sur un progiciel CRM (orienté SFA, Sales Forces Automation) pour la force de vente et un second progiciel de gestion pour la logisti-que et la comptabilité (PGI). Le SI dispose déjà d’outils d’urbanisation comme un EAI. Une première maquette SOA sur BPM a été réalisée en prévision d’une straté-gie SI plus générale. Les processus transverses sont outillés par BPM et orchestrateur.

Un portail de e-commerce existe déjà et ne sera que peu modifié car il répond aux besoins clients mais l’ensemble des flux d’alimentation sera revu.

Concernant les données de référence, les catalogues produit et les offres sont gérés dans le frontal Force de vente, offrant une déclinaison locale pour chaque pays.

Les stocks sont rafraîchis « au fil de l’eau » depuis le progiciel de gestion dans le CRM. Les données clients sont acquises principalement par le frontal Force de vente et complétées dans le progiciel de gestion par la logistique et la comptabilité. L’orga-nisation est décrite dans le progiciel de gestion, seuls les commerciaux sont identifiés dans l’outil de CRM/SFA.

Après analyse, les choix suivants sont établis :

• Gestion des produits et offres maintenue dans le CRM/SFA avec flux de synchronisation entre SFA et le PGI. Le CRM/SFA offre un taux de couver-ture des besoins du PGI proche des 100 %, les adaptations en « spécifique » sont mineures.

• L’acquisition des clients est réalisée dans le CRM/SFA et le PGI, avec comme particularité que le SFA est seul apte à « créer », le PGI ne peut que

« compléter » une donnée qu’elle reçoit (cela simplifie l’orchestration des synchronisations amont). Un référentiel Client, suivant une architecture de coopération, est prévu. La force de vente n’a ainsi qu’un unique outil gérant le mode connecté ou non.

• Le référentiel offre des capacités DQM pour s’assurer de l’unicité et de la normalisation stricte des données. Ces capacités sont aussi utilisées lors de la reprise afin de constituer le référentiel initial à partir des sources des différents pays. Le chargement initial du PGI et du SFA est réalisé par extraction du référentiel, puis les flux amont entre SFA, PGI et référentiel sont déployés. Le DQM outille aussi les indicateurs de pilotage du référentiel.

• Le référentiel offre la possibilité de reconstituer les hiérarchies clients ; ainsi la vue des groupes est possible. Cette aptitude offre, via un développement spéci-fique adossé au PGI, la possibilité de mieux gérer les encours de crédit. En effet, la somme des crédits possibles alloués aux différents établissements de vente peut dépasser celle allouée à la branche régionale ou au groupe en entier. La vision reconstituée des filiations permet de refuser un crédit à un établissement, non pas parce que son propre encours possible est dépassé, mais parce que celui de sa maison mère l’est.

143 7.2 Projets classiques et leurs applications

• Un logiciel LDAP spécifique est alimenté par le référentiel client afin d’ouvrir les droits à l’automatisation des transactions financières.

• Le référentiel propose, en outre, des capacités de recherche et d’édition au travers du portail d’entreprise sous client léger.

• Les flux amonts sont outillés en ESB, une partie des processus est portée en BPM, les flux aval utilisent EAI, ESB et ETL en fonction de la cible.

• L’organisation et les sites sont modélisés et gérés dans le PGI au périmètre du projet. Le DSI préfère envisager un futur projet de refonte du SI Ressources humaines pour créer un véritable référentiel Organisation et Employés.

• Les urbanistes désiraient se doter d’un référentiel de paramètres, mais malgré les risques concernant la transcodification et sous la pression des métiers et de l’équipe BI, ils ont dû renoncer. Chaque table de paramètre est acquise et gérée dans les applications, l’intermédiation est mise à jour manuellement pour les transcodifications. Le BI assure l’historisation des tables et possède sa propre gestion des transcodifications.

On aboutit au SI illustré par la figure 7.4, tandis que la situation idéale du point de vue gestion des données de références est donnée à la figure 7.5.

Figure 7.4— SI défini par l’analyse pour outillage du processus «Traiter une commande»

Figure 7.5— SI cible défini par l’analyse pour outillage du processus «Order to Cash»