Il y a deux semaines, lors d’un échange de vues avec un DSI d’une entreprise de taille moyenne, la question de la gouvernance de l’architecture du SI est arrivée sur la table. Quels avantages devait-il attendre de la mise en oeuvre d’un nouveau processus qui consommerait des ressources et du budget ?
Est-ce vraiment nécessaire lorsque la charge des changements occupe pleinement ses équipes ? L’utilité des architectes au sein des projets est indiscutable, mais les tenir à l’extérieur avec comme résultat d’alourdir les plans de réalisation n’est pas une option séduisante.
Sa première priorité n’est pas d’être Cobit ou ITIL, mais d’être vraiment aligné avec la stratégie des métiers de son entreprise.
Comme consultant, je n’étais chaud d’évoquer le rejet des bonnes pratiques au bénéfice d’une vue à court terme. Mais, mon interlocuteur n’était-il pas dans le vrai après tout ?
Pour lui, la valeur de la gouvernance d’architecture dépendait de ce que l’entreprise pouvait obtenir en retour. En effet, quand la DSI est organisée en équipes de gestionnaires d’application responsables du changement pour leur domaine, mettre en oeuvre des processus transverses semble contribuer à augmenter les dépendances et les risques de prpojets.Selon la maturité du système d’information de l’entreprise, il y a un niveau de gouvernance d’architecture appropriée.
Niveau un
PME avec progiciels pour la comptabilité, la paie, l’administration des ventes et la gestion de production. Plusieurs points de vente et plusieurs usines. Chaque service ou département se concentre sur son processus propre et échange des fichiers avec les autres lorsque c’est nécessaire.
Niveau de gouvernance : l’architecture technique pour rationaliser le matériel utilise et l’achat
Niveau deux
Même entreprise qui désire relier ses progiciels avec un middleware tel un Message Orienté Middleware ou un moniteur de transfert de fichier automatisé pour améliorer le back-office et la statistique. Chaque département veut avoir un retour plus rapide sur ses performances.
Niveau de gouvernance : l’architecture d’application pour permettre des capacités de change
Niveau trois
Même entreprise qui voudrait superviser ses clients depuis ventes jusqu’à la livraison, à travers les points de vente et les usines. Par exemple dans le cadre du développement de capacités de business intelligence.
Niveau de gouvernance : l’architecture de l’information pour partager des informations signifiant à travers des progiciels différents
Niveau quatre
Même entreprise qui voudrait industrialiser ses Business Processes
Niveau de gouvernance : la Business architecture pour soutenir, améliorer et automatiser les processus métier
Souvent, pendant leur histoire, les sociétés passent à travers chacun de ces niveaux. Sauter au niveau suivant exige d’améliorer les compétences IT . En revanche, le bond de 2 niveaux exige une vraie transformation des processus. En général, les très grandes entreprise sont au niveau quatre et démontrent un niveau de maturité élevé de leur processus de gouvernace, mais prêter attention à celle du SI d’une PME, permet d’identifier le niveau approprié de gouvernance d’Architecture , et améliorer la réussite de la mise en oeuvre.