Que faut-il savoir sur « Principe général de l’approche bottom-up » ?
Extrait de Économie du système d’information
L’approche bottom-up part d’un constat simple : souvent, dans l’entreprise, les SI et leurs bases de données sont déjà en place, au moins partiellement.
Les équipes utilisent diverses applications (ERP, CRM, outil de paie, etc.), et ces applications hébergent nécessairement des tables et des entités de données représentant des « choses » que l’entreprise manipule au quotidien.
Autrement dit, si l’on veut savoir quels objets métiers sont gérés, il suffit parfois de regarder ce qui existe déjà dans les bases de données et de regrouper/analyser ces éléments sous un angle métier.
Concrètement, on procède par inventaire des logiciels et de leurs schémas de données (voire de leurs API, si elles sont documentées), puis on s’efforce de recenser :
Quelles tables correspondent réellement à des objets métiers (par exemple, la table t_client ou v_clt pour un client).
Quels attributs, relations ou règles de gestion y sont associés (par exemple, les statuts d’une commande, les règles de facturation, etc.).
Comment ces données sont échangées entre les différentes applications (flux EDI, interfaces, ESB, microservices, etc.).
Cette approche présente l’avantage d’être très concrète : on part de l’existant, donc on réduit le risque d’omettre des objets métiers déjà couverts par les systèmes.
Elle est aussi plus rapide dans certains cas, en particulier si l’organisation ne dispose pas d’une cartographie de processus actualisée, mais qu’elle a un inventaire applicatif relativement complet.
En revanche, l’un des grands défis de la bottom-up est de ne pas tomber dans l’excès de détail purement technique, et de réussir à « remonter » au sens métier de chaque entité.
C’est ce qui distingue un simple recensement de tables d’une véritable identification des objets métiers.