Architecture d’entreprise, Analyse d’affaires et Gestion de projet – des métiers qui convergent ?

Architecture d’entreprise, Analyse d’affaires et Gestion de projet – des métiers qui convergent ?

Comme chargé de projet, vous est-il déjà arrivé :

  • de vous poser la question sur le bien-fondé de ce qui est réalisé ?
  • de constater que vous partagez parfois le même terrain de jeux que d’autres métiers ?
  • que l’arrimage du projet entre le bureau de projet, l’architecture et les lignes d’affaires semble parfois inconsistant ?

 

Ce genre de préoccupation refait surface périodiquement. Bien que le champ d’intervention du chargé de projet soit habituellement associé à l’exécution d’un projet, il arrive qu’il se questionne, à juste titre, sur son origine et l’intention stratégique qui a mené à sa mise en œuvre. Les études longitudinales récentes du PMI ont montré qu’une connaissance de ces domaines favorise le maintien de l’alignement architectural et accroît ses chances de livrer la valeur attendue[1]. En passant, avez-vous remarqué que le maintien de la certification PMI exige d’acquérir des notions en stratégies et leadership ?

Cet article veut donner un aperçu des référentiels et leur perspective pour chacun des principaux groupes avec lesquels il y a interactions dans nos projets : Architecture d’entreprise, Architecture d’affaires et Analyse d’affaires, Bureau de projet et Gestion de projet. En connaissant mieux la vision des uns et des autres, le chargé de projet pourra délimiter plus précisément son propre rôle et celui de ses collaborateurs. Comme autre bénéfice, les discussions concernant le rôle de chacun reposeront davantage sur une assise factuelle plutôt que sur des perceptions.

1- L’architecture d’entreprise

L’architecture d’entreprise soutient une organisation dans la réalisation de ses objectifs stratégiques et opérationnels. En pratique, l’architecture d’entreprise alimente la réflexion stratégique, recommande le choix des investissements et accompagne l’exécution de la stratégie d’entreprise. Elle fait ainsi le lien entre décisions stratégiques et livraison de valeur pour l’organisation.

Rôle de l’architecture d’entreprise[2]

L'architecte d'entreprise contribue au choix des projets de transformation et ainsi à la constitution du portefeuille de projets. Il s'assure pendant leur réalisation que la trajectoire définie est respectée. Lorsque le non-respect de la trajectoire est anticipé ou devient préoccupant, l'architecte d'entreprise aide à prendre les mesures adéquates. L'architecte d'entreprise est une partie prenante d'un projet car il peut en influencer l'issue. Après la transformation, il intervient dans l'évaluation du retour sur investissement.

Au gouvernement du Québec et dans l’industrie, le modèle de référence en architecture d’entreprise est souvent inspiré de celui du TOGAF[3]. Il se présente comme étant un ensemble de quatre architectures décrivant chacune une organisation selon un point de vue donné : architecture d’affaires, architecture d’information, architecture des applications et architecture technique (technologique). Deux segments transversaux complètent le modèle : la sécurité et l’interopérabilité. Ces volets et segments sont représentés à la Figure 1.

Figure 1 : Volets et segment de l’architecture d’entreprise

Les architectures des applications et techniques traduisent bien leurs liens intrinsèques avec les TI. Prises conjointement et complétées en partie par l’architecture d’information (sous l’angle des données), elles sont aussi appelées architecture TI. Par contre, les architectures d’affaires et d’information (à l’exception de l’angle des données) doivent être perçues comme faisant abstraction des TI et se concentrant uniquement sur la dimension affaires de l’organisation. Ce volet est apparu avec le temps car, à la base, le modèle avait été créé surtout pour répondre aux besoins des groupes informatiques. Cet aspect primordial est réellement plus fouillé grâce à la contribution du Business Architecture Guild qui a produit le BIZBOK (Business Architecture Body of Knowledge).

En architecture d’entreprise, une autre notion importante concerne la reddition de comptes portant sur la performance et la conformité. Bien qu’étant significatif, cet aspect n’est pas expliqué ici mais il doit être considéré dans la perspective de la valeur obtenue par l’organisation et la mesure des bénéfices attendus.

2- L’architecture d’affaires

Selon le BIZBOK[4], l’architecture d’affaires est utilisée pour aligner les objectifs stratégiques de l’organisation à la demande tactique. Il le définit comme étant une représentation abstraite de l’organisation et de l’écosystème d’affaires dans lequel elle opère. Selon la FEAPO[5], elle représente des vues holistiques et multidimensionnelles des affaires de l’organisation (blueprints) telles que les capacités, la livraison de valeur de bout en bout, l’information, la structure d’organisation, mais aussi les relations entre ces vues et la stratégie d’entreprise, les produits et services, les initiatives de transformations et les parties prenantes. Il est donc loisible de déduire que l’architecture d’affaires est la base de l’architecture d’entreprise (alors que dans le monde TOGAF on a tendance à la réduire à sa plus simple expression). En fait, l’architecture d’entreprise, telle qu’on l’utilise la plupart du temps, ne considère l’architecture d’affaires que dans sa forme synthétique. Pourtant, elle donne la possibilité d’obtenir la vue actuelle de l’organisation, de même qu’elle aide à définir l’état souhaité et la transition pour y parvenir.

Rôle de l’architecture d’affaires

La valeur que l'architecture d'affaires livre à l'organisation est un cadre effectif de communication et d'analyse lui permettant de traduire sa stratégie en initiatives réalisables (BIZBOK version 6.5). Elle lui permet également de mettre en œuvre des transformations, de résoudre la complexité, de réduire le risque, de prendre des décisions éclairées, de faire partager une vision commune du futur aux parties prenantes et d'utiliser efficacement la technologie comme un levier.

Le modèle BIZBOK amène une perspective plus large à l’architecture d’affaires. Il est présenté à la Figure 2.

 

 

  • Les 4 domaines centraux représentent les aspects qui sont généralement les plus stables d’une organisation
  • Les 7 autres domaines correspondent à des éléments périphériques complémentaires qui peuvent varier plus souvent
  • La réponse à ces questions, dérivées de l’AE, sont utilisées pour développer différents types de plans ainsi que pour prendre des décisions d’affaires et les exécuter

 

Figure 2 : Domaines dans lesquels l’architecture d’affaires décrit une organisation

3- L’analyse d’affaires

Pour s’assurer de l’alignement avec la vision d’affaires, l’architecture d’affaires doit avoir accès ou être impliquée dans la définition de la stratégie ainsi que le choix des projets de transformation. L’analyste d’affaires est le spécialiste de l’ingénierie des besoins d’affaires. Sa présence s’avère utile lors de l’élaboration d’un dossier de décision  (exemple: étude de l’opportunité, étude de faisabilité, dossier de positionnement stratégique, dossier d’affaires). Il s’assure du bon alignement des besoins avec l’architecture d’affaires. Il est donc un joueur clé dans un projet d’étude ou avant-projet.

Le modèle des concepts clés de l’analyse d’affaires (Figure 3) proposé par le BABOK 3.0 (Business Analysis Book of Knowledge) met l’accent sur la valeur qu’apporte un changement à l’organisation. Il regroupe six domaines fondamentaux et interdépendants qui permettent de bien cerner les besoins à partir des informations analysées durant le processus de l’analyse d’affaires. Il en résulte des exigences claires.

Changes (Changement)L'acte de transformation en réponse à un besoin
● Quel changement sommes-nous en train de réaliser ?
Needs (Besoins)Un problème ou une opportunité à considérer
● Quels besoins voulons-nous satisfaire ?
Solutions (Solutions)Une façon spécifique de répondre à un besoin dans un contexte donné
● Quelles solutions sommes-nous à créer ou changer ?
Stakeholder (Parties prenantes)Un groupe ou un individu qui a une relation avec le changement, le besoin ou la solution
● Qui sont les parties prenantes impliquées ?
Value (Valeur)La valeur, l'importance, l'intérêt de quelque chose pour une partie prenante dans un contexte donné
● Est-ce que les parties prenantes jugent avoir une valeur ?
Context (Contexte)Les circonstances qui influencent le changement et qui permettent de le comprendre
● Dans quel contexte et solution sommes-nous ?

Figure 3 : Modèle des concepts clés de l’analyse d’affaires défini par le BABOK

L’analyste d’affaires est davantage impliqué dans la mise en œuvre de la stratégie à travers la réalisation des projets de transformation[6]. Encore des liens avec la gestion de projet ! Les liens peuvent être relevés en scrutant les domaines d’activités de l’analyste d’affaires.

  • L’analyse des besoins d’affaires permet de les préciser. Un chargé de projet devrait apprécier sa chance d’avoir avec lui un analyste d’affaires – Le spécialiste des besoins d’affaires. Qui croit sérieusement qu’une meilleure compréhension du besoin à l’origine d’un projet n’améliore pas ses chances de réussite ?
  • D’après les pratiques recommandées par le BABOK– qui est un guide plus restreint que le BIZBOK-, l’analyste d’affaires étudie le contexte, évalue les risques et ébauche la stratégie de transition.
  • La formulation des exigences permet de préciser la portée du projet et faciliter la réalisation de la structure de découpage du projet.

4- La gestion des projets

Le Project Management Institute (PMI) définit un projet comme étant  ‘’une action temporaire entreprise dans le but de créer un produit, un service ou un résultat unique’’.  Son exécution est graduelle et met en relation trois contraintes fondamentales : les coûts, les délais et la portée / qualité. Un projet résulte d’un besoin d’affaires.

Le bureau de projet et la gestion de portefeuille des projets

Comme les organisations conduisent plusieurs projets à la fois, une structure de gouvernance – le bureau de projet – a été créée. Comme beaucoup de projets ont une nature transversale, le bureau est souvent localisé au sein de la direction informatique qui, de par sa mission, a l’habitude de traiter des dossiers horizontaux. Assez souvent, les chargés de projets ont un  bagage dans le domaine des TI et sont en lien avec les lignes d’affaires.

Rôle du bureau de projet

Le bureau de projet regroupe les différentes initiatives retenues par l’organisation dans un portefeuille de projet. Il les priorise en fonctions de leurs dépendances et produit des indicateurs d’état pour la direction. Il est aussi responsable de normaliser les pratiques en gestion de projet, du suivi des bénéfices et de l’accompagnement métier. Les chargés de projet relèvent le plus souvent du bureau de projet.

La valeur que le bureau de projet livre à l'organisation est un cadre de communication et d'analyse global qui permet d’assurer un suivi d’ensemble des initiatives (coûts, portée, échéanciers et bénéfices). Il améliore l‘usage des ressources suivant la capacité de réalisation et améliore la cohérence des décisions en lien avec la vision et les plans stratégiques de l’organisation.

Le chargé de projet

La livraison d’un projet relève du chargé de projet. Il doit s’assurer que le mandat est exécuté en tenant compte des trois contraintes. Au démarrage, les principales modalités d’un projet sont généralement définies dans un mandat qui identifie le contexte de réalisation, la structure de gestion prévue et les rôles associés, la portée de ce qui est à livrer, les biens livrables et une planification sommaire.

Rôle du chargé de projet

Les responsabilités du chargé de projet incluent : la gestion de l’équipe de réalisation, la planification, le budget et les biens livrables produits selon la portée prévue. Ici, la portée du projet est déterminée en tenant du contexte organisationnel, de son alignement avec les objectifs stratégiques et des besoins prioritaires à satisfaire. Par comparaison aux groupes d’architectures et d'analyse d'affaires, sa contribution est centrée sur l’exécution, plutôt que sur la conception des projets.

Habituellement, le chargé de projet relève d’un directeur de projet, lui-même placé sous l’autorité d’un comité directeur pouvant accepter ou refuser les biens livrables et donner des orientations spécifiques au projet. La livraison des projets s’effectue suivant un cadre méthodologique qui se base sur les meilleures pratiques adaptées le plus souvent du PMI et son référentiel : le PMBOK®. Le Modèle de gestion de projet proposé par le PMBOK® comprend cinq groupes de processus du démarrage à la clôture qui se déclinent en 10 domaines de connaissances, comprenant un total de 43 processus distincts (voir Figure 4).



ÉtapesProcessusNbre de domaines concernés
Démarrage22
Planification2410
Exécution107
Clôture11
Surveillance, Maitrise des modifications1210
Total49Max. 10

Figure 4 : PMBOK® – Modèle de gestion de projet

Le chargé de projet met l’accent sur l’efficacité de la réalisation du projet et sa conformité au mandat (dans le respect des balises prévues : budget, temps et portée). Ce qui explique son souci constant de garder le projet en ligne avec sa portée initiale. Les tiraillements que connaissent parfois les projets proviennent souvent de la différence de perspective entre le chargé de projet et les gens d’affaires. Considérant la durée de vie de la solution, on comprend qu’ils veulent parfois prendre plus de temps en implantation afin de réfléchir encore un peu sur les besoins réels et la solution considérée (au détriment de l’échéancier, du budget ou de la portée).

Impact de l’agilité

Lorsque le projet arrive à l’étape de réalisation, jusqu’à maintenant, on attendait du chargé de projet qu’il se concentre uniquement sur les trois contraintes, sans réellement remettre en question la finalité d’un projet. La réalisation reposait alors sur une vision déterministe plutôt qu’adaptative. Avec l’arrivée des méthodes agiles (au cœur du PMBOK® v6 et le Agile Practice Guide), il est maintenant accepté que la portée puisse être variable. De la part du chargé de projet cela demande une certaine flexibilité dans sa prestation. Il est plus que souhaitable qu’il acquiert un minimum de connaissances sur les approches d’analyse d’affaires et d’architecture d’entreprise pour lui faciliter la tâche (et possiblement réduire les demandes de changement !).

5- Perspective et particularités

Une fois que l’on connait un peu mieux les univers de chacun des domaines que sont l’architecture d’entreprise, l’analyse d’affaires et la gestion des projets, il reste à tenter de décrire comment ces métiers s’agencent entre eux. Le schéma de la Figure 5 est une tentative de représentation des particularités et points communs présentés sous forme de diagramme de Venne.

 

Figure 5 : Essai d’agencement des métiers

6- Conclusion

Au point de vue de l’usage des ressources informationnelles comme levier de transformation, cette représentation sommaire correspond à l’arrimage optimal que cherchent à atteindre les organisations performantes. En regardant de plus près, on voit pourquoi le chargé de projet réalise parfois que ce qu’il doit livrer résulte de différentes perspectives qui s’entrecroisent à plusieurs niveaux. On ne peut plus se contenter de juste livrer des projets, il faut savoir d’où ils viennent !

Une meilleure compréhension des métiers qui sont à l’origine des projets favorise le maintien de leur alignement stratégique et facilite leur réalisation. Si chacun joue son rôle efficacement, les tiraillements que l’on vit parfois dans nos projets seront réduits puisque l’on saura ce qui appartient à chacun et ce qui doit faire l’objet d’une collaboration.

Avec la maturité, l’architecture d’affaires va bien au-delà des principes d’affaires et des processus d’affaires. La faiblesse de l’architecture d’affaires dans une organisation peut avoir plusieurs conséquences, comme le réflexe d’être en mode solution, plutôt que d’alimenter la réflexion, clarifier les besoins, utiliser les outils pour s’assurer qu’ils sont alignés afin de livrer de la valeur. Être tout de suite en mode solution ne favorise pas la mise en place, le développement d’une architecture d’entreprise ou encore l’accroissement de sa maturité. Or, l’architecture d’entreprise (architecture d’affaires) «est utilisée pour prévoir les ressources et procéder aux modifications requises avant que les problèmes ne surviennent» (VGQ, 2017). Donc, il urge de changer de cap et laisser place à l’architecture d’affaires : c’est elle qui propose les projets de transformation, compte tenu de sa connaissance de l’organisation et de son implication dans la stratégie d’entreprise.

Présentation des auteurs

Aurel Randolph, Ph. D.
Conseiller en architecture d’affaires et Conseiller en architecture d’entreprise, Gouvernement du Québec

M. Randolph a à son actif plus d’une vingtaine d’années d’expérience dans le domaine des ressources informationnelles, notamment en livraison de solution d’affaires et en gestion de projet. Au fil des années, il a développé une expertise en architecture d’entreprise, principalement en architecture d’affaires et en architecture d’information. M. Randolph est également chargé de cours à l’école Polytechnique de Montréal.

Adresse  aurandoj@yahoo.fr

 

Marc Lafontaine, PMP
Conseiller d’affaires et en gestion de projet au sein de l’équipe Multiforce

M. Lafontaine cumule plus de 30 années d’expérience en gestion des RI dans les secteurs public et privé. Son savoir-faire a été mis à profit à titre de chef de projet dans des dossiers d’envergure qui intégraient des aspects technologiques et humains (gestion de projet, dossiers d’affaires, architecture d’entreprise et accompagnement stratégique).

Titulaire d’un baccalauréat en administration des affaires (option systèmes d’information), il détient aussi un certificat en philosophie. Depuis plusieurs années il s’implique au sein du PMI Lévis-Québec et il siège au conseil d’administration à titre de vice-président communications.

Références

[1]Notamment:  e-Davies, T. (2015). Putting talent management at the heart of organizational PPM development. Paper presented at PMI® Global Congress 2015—EMEA, London, England. Newtown Square, PA: Project Management Institute. Voir aussi ‘’logitudinal studies’’ sur le site du pmi.org

[2] Le Rapport du Vérificateur Général du Québec à l’Assemblée nationale du Québec, Hiver 2017, Chapitre 9 – Portrait de la gouvernance et de la gestion des technologies de l’information au gouvernement du Québec, identifie que l’architecture d’entreprise est la principale lacune des organisations, alors qu’elle est nécessaire pour aligner les TI sur leurs besoins. Son importance est telle qu’elle est « utilisée pour prévoir les ressources et procéder aux modifications requises avant que les problèmes surviennent ». Pour cette raison, « il est essentiel d’avoir une bonne architecture d’entreprise afin de disposer d’une compréhension adéquate de l’environnement actuel d’affaires et des TI, notamment en matière de processus d’affaires, d’information et d’applications».

[3] The Open Group Architecture Framework

[4] BIZBOK version 6.5

[5] Fédération des organisations des professionnels en architecture d’entreprise (FEAPO), 2017, Definitions of types of architecture — an inter-organizational definitions of Application, Business, Data, Technical, and Enterprise Architecture. [En ligne] http://feapo.org/68-2/ Aussi disponible à : http://c.ymcdn.com/sites/www.businessarchitectureguild.org/resource/resmgr/FEAPO_Adopted_Architecture_D.pdf

[6] http://www.redsen-consulting.com/fr/inspired/business-analyse/ba-ou-ba

Article précédent
Les candidatures pour les élections au conseil d’administration 2018 sont ouvertes
Article suivant
Impacts de la Loi 135 et la gestion des projets

Articles liés

Menu