Domtar : l’exemple d’une architecture d’entreprise « utile »

04/02/2014

Farid Mheir

Farid Mheir

On me demande souvent à quoi sert l’architecture d’entreprise. Je crois avoir ici un bon exemple.

Récemment, lors d’une présentation à la Tribune des CIO du Réseau Action TI de Montréal, Michel Meunier, vice-président, technologies de l’information chez Domtar, a présenté le processus de définition du plan directeur de l’entreprise.Illustration du concept d'architecture d'entreprise

J’ai été frappé par le pragmatisme de l’approche, présentée en termes simples et non techniques. L’approche permet, semble-t-il, d’impliquer les unités d’affaires afin qu’elles priorisent et décident elles-mêmes des priorités et de l’allocation des budgets TI, sous la gouverne des TI. Pas facile à faire.

Sans surprise, c’est souvent l’oeuvre de CIO qui proviennent d’une unité d’affaires (comme M. Meunier), versus des vieux routiers de la technologie.

Représentation visuelle du processus de planification stratégique des TI

Représentation visuelle du processus de planification stratégique des TI

Domtar propose cinq étapes pour la mise en oeuvre du plan directeur. Le diagramme ci-dessus résume le processus, dont en voici les grandes lignes.

  1. Faire la liste des services TI offerts par l’équipe interne et les fournisseurs. L’emphase est mise sur la valeur offerte par l’équipe TI aux unités d’affaires, non pas sur les caractéristiques techniques (serveurs, réseau, etc.). C’est une liste qui est préparée par l’équipe TI et qui sert de base aux discussions avec les unités d’affaires. Comme le fait remarquer M. Meunier, cela permet une fois pour toute d’expliquer clairement le rôle de l’équipe TI dans l’entreprise.
  2. Évaluer le risque des services sur deux axes : l’impact sur les affaires et la criticité. On mesure ici l’importance d’un service TI pour les affaires de l’entreprise, ce qui permet de prioriser les projets en fonction des aspects essentiels pour opérer l’entreprise (dans ce cas-ci, la production de papier et autres produits connexes).
  3. Identifier les catégories d’investissement. Ici, on commence à prendre compte des contraintes technologiques et à regrouper les applications. Pour ce faire, il est essentiel d’avoir un bon registre des applications de l’entreprise (pas évident en cette ère de solutions d’informatique en nuage SaaS, par exemple)
  4. Tenir compte des contraintes et évènements TI. On tient compte ici de contraintes technologiques et temporelles, comme la fin de vie des logiciels qui exige des remplacements, faute de quoi le risque technologique devient plus important.
  5. Établir le plan directeur et le portefeuille de projets. C’est à cette étape qu’on peut mettre en place un portefeuille de projets qui, si les étapes 1 à 4 ont été suivies, reflète les priorités d’affaires et de technologie tout en tenant compte du budget.

Si le travail s’effectue dans un environnement de collaboration affaires-TI, on peut penser que l’approche fournisse une planification à laquelle tous adhèrent, la transparence étant complète sur les contraintes, les besoins et la priorisation.

Pour une meilleure compréhension de l’approche, je vous invite à consulter le sommaire de la présentation au Réseau Action TI.

Caché derrière cette exercice de planification stratégique se cachent, je crois, plusieurs livrables de l’architecture d’entreprise de Domtar. J’ai tenté ici de les identifier et de résumer comment ils sont utilisés :

  • carte des fonctions d’affaires : les services TI identifiés par Domtar représentent un sous-ensemble de cette carte, qui devrait aussi inclure les services des autres unités d’affaires (ventes, production, marketing, RH, etc.).
  • registre des applications : il est déconcertant de ne pas avoir en main un registre complet et à jour de toutes les applications de l’entreprise, avec un niveau de détail suffisant pour comprendre la fonction, l’importance pour les affaires, les propriétaires, ainsi que les contraintes technologiques et temporelles. La préparation du registre amène aussi très souvent une transparence qui permet de détecter des aberrations (comme l’utilisation de plusieurs outils pour faire la même tâche dans différentes unités d’affaires) ou des opportunités de rationalisation (quand on utilise plusieurs licences de solutions SalesForce.com ou de LinkedIn sans profiter de réduction de volume).
  • principes et règles d’affaires : c’est ici que l’on consigne les décisions globales, comme les catégories d’investissement ou la définition des risques chez Domtar. Ce sont des guides permettant de trancher entre deux projets en utilisant des règles acceptées globalement et par tous. Par exemple, les principes permettent de conserver au portefeuille de projet un nouvel outil CRM car il fournit une vision à 360 degrés du client (identifié comme aspect primordial à l’entreprise). Ces guides permettent aussi de justifier le report d’une mise à jour de serveur ou de logiciel qui ne mets pas à risque l’entreprise.
  • architecture technologique : ce diagramme (blueprint) qui coordonne graphiquement les applications, les données avec les fonctions d’affaires est essentiel pour prendre les bonnes décisions technologiques globalement. Malheureusement, je ne l’ai pas trouvé dans l’approche de Domtar, bien que selon M. Meunier, il existe et est utile dans l’entreprise. Je l’aurais utilisé, à l’étape 3 ou 4, pour comprendre l’impact et visualiser le portefeuille de projets dans le contexte technologique, en complément aux priorités d’affaires, aux efforts et aux budgets.

On voit donc que les livrables d’une bonne architecture d’entreprise représentent des actifs qui, lorsque disponibles et maintenus à jour, permettent d’accélérer certains travaux stratégiques ayant une portée d’entreprise, comme c’est le cas pour la préparation du portefeuille de projets TI et des budgets annuels.

Il est difficile de réaliser le travail d’architecture d’entreprise en même temps que cette planification, souvent par manque de temps. C’est pourquoi nous croyons que l’architecture d’entreprise doit être une activité ponctuelle, mais régulière (semestrielle ou annuelle par exemple), qui doit être réalisée par des experts externes en collaboration avec des ressources de l’entreprise, afin de fournir une documentation permanente pouvant être utilisée rapidement dans les projets stratégiques comme la planification annuelle ou l’acquisition d’une nouvelle entreprise.

Qu’en pensez-vous?


Tags: , ,
Farid Mheir

Farid Mheir

Farid Mheir est consultant en transformation numérique des entreprises chez 28angle Architecture. Site Web: scoop.it/Digital-Tranformation-of-Business
Google+ WWW
  • Semiotic

    Depuis 10 ans-Intervista produit une formation très populaire, en Architecture d’entreprise-avec John Zachman. Regretablement, même qu”elle soit la plus reconnue dans ce genre-les enterprises et gouvernements ici au Quėbec n’y assistent jamais. Meme avec une ėnorme publicité, un prix concurentielle, un crédit d’impõt et des dates à Montréal!

    J’ai cesser de prêcher ici et je me contente de former les avant-gardiste à Toronto, Calgary et à Ottawa – où l’adoption de cette pratique est vu comme essentielle. Cheque fois que voit dans les mėdias un nouveau ėcheq de project informatique au Quėbec, je me pose la question – pourquoi on boude l’enseignement ici au Quėbec?