Contexte
Les différents départements d'une entreprise ont chacun un fonctionnement basé sur leurs propres processus. Ces derniers se basent sur plusieurs référentiels de données (sources authentiques) qui sont propres à chaque département puisqu'ils sont liés à leurs outils spécifiques, à leur métier. Concrètement un département d'Exploitation a son fonctionnement basé sur les différents processus ITIL qui est lui-même basé sur les référentiels de gestion de la configuration (CMDB). Un département Développement est basé quant à lui sur PMI (ou Prince2) qui utilise, entre autres, un outil de la planification des projets. Un département de comptabilité doit appliquer par exemple la législation nationale sur les budgets qui imposent un fonctionnement basé sur un référentiel comptable (par ex. SAP). D'autres processus comme d'autres référentiels existent, cette liste n'étant pas exhaustive.
On s'aperçoit à un niveau transversal que ces processus sont fortement liés entre eux puisqu'ils vont tous dans le même sens : l'intérêt de l'Entreprise et de ses clients.
Par exemple l'architecture d'entreprise lors de ses analyses doit aborder des problématiques en tenant compte des processus Métier (qui gère les SI, comment et pourquoi), des systèmes d'information (quel domaine d'applications est concerné par le changement ? Quel est le planning de l'application ? Quelles données transversales sont utilisées ? ...) et enfin des technologies (sur quel serveur fonctionne l'application ? Quel réseau est utilisé ? ...). D'autres problématiques existent : le département Exploitation aimerait savoir précisément quel utilisateur (personne) est impacté lorsqu'un réseau informatique est tombé. Le département Service Achats aimerait aussi planifier la charge de ses équipes en connaissant à l'avance les projets qui vont être lancés ou les machines qui seront achetées suite à un problème de capacité.
Ces dépendances entre les processus peuvent être vues comme étant des liens entre les différents référentiels des départements. En effet chacun de ces référentiels contient une partie de la réponse. Il faut donc trouver un lieu commun pour rendre accessible tous ces liens. Cet endroit est appelé « référentiel applicatif » ou « référentiel d'entreprise » ou en anglais « enterprise architecture management system » (EAMS).
(Pourquoi applicatif ? Parce que dans une entreprise spécialisée en informatique, le point commun est les différents systèmes d'information gérés. Et un système d'information étant un ensemble d'applications, il semblait logique d'appeler en français ce système « référentiel applicatif » afin de ne pas trop « l'étiqueter » architecture puisqu'il est dédié à être utilisé par presque l'ensemble des disciplines.
)
Son rôle
Le référentiel applicatif doit pouvoir être utilisé dans les situations suivantes (liste non exhaustive) :
- Aider à documenter le SI existant (vue as-is)
- Aider à documenter le SI futur (vue to-be)
- Aider à analyser l'impact du changement du as-is vers le to-be
- Exporter ses informations à d'autres référentiels
- Aider à planifier et à suivre l'évolution du as-is vers le to-be
- Aider à documenter les standards techniques
- Représenter et maintenir les relations entre les éléments organisationnels, logiques, techniques et technologiques de notre SI
- …
Enjeux
L'enjeu de posséder un référentiel applicatif est grand puisqu'il a l'ambition d'amplifier la synergie entre les processus des départements ainsi que d’accélérer la communication de l'information.
0 commentaires:
Enregistrer un commentaire