Que faut-il savoir sur « Illustration par un cas pratique » — Annexe 3 : Identification des objets métiers méthodologie ?
Extrait de Économie du système d’information
Imaginons une PME qui a grandi par rachats successifs, accumulant plusieurs logiciels hétérogènes : un CRM maison, un petit ERP pour la gestion comptable, un outil tiers pour la logistique, et quelques feuilles Excel pour le suivi de production.
Elle ne dispose pas d’une grande culture de modélisation des processus, mais elle a une équipe SI consciencieuse qui tient à jour un inventaire des applications, de leurs principales tables et de leurs interconnexions.
En se plongeant dans cet inventaire, la DSI repère :
CRM : tables client, prospect, opportunité, rdv, etc.
ERP comptable : tables facture, ecriture_comptable, compte_tiers, etc.
Outil logistique : tables commande, livraison, stock, etc.
Fichiers Excel : onglets « planning de production », « ordres_fabrication.xls », etc.
En examinant ces éléments, on identifie plusieurs objets métiers récurrents : client, commande, facture, article (ou produit), stock, ordre de fabrication, etc..
Puis on les regroupe sous des appellations unifiées (parfois, la table est nommée client, ailleurs v_clt, ailleurs t_personne, et pourtant il s’agit du même concept).
Ainsi, la DSI formalise un dictionnaire commun d’objets métiers.
Elle détermine ensuite quels attributs et quelles relations sont pertinents pour parler d’un client (ex. le client a un historique de commandes, il possède un identifiant unique, un segment de marché, etc.).
Peu à peu, la compréhension de l’existant s’améliore, et l’entreprise peut en profiter pour rationaliser certaines données doublons ou mal structurées.