Transformation organisationnelle - Plan de transformation basé sur l’architecture d’entreprise – TOGAF 9 et ArchiMate

Transformation organisationnelle - Plan de transformation basé sur l’architecture d’entreprise – TOGAF 9 et ArchiMate

• 1.
  © 2015 MiguelIriart, Marcelo Zampa Transformation organisationnelle Plan de transformation basé sur l’architecture d’entreprise Miguel Iriart MBA, TOGAF 9, ArchiMate 2, PMP, CGEIT, COBIT 5, PSM, CISA, ITIL Marcelo F. Zampa MBA
• 2.
  © 2015 MiguelIriart, Marcelo Zampa Table des matières Introduction ...............................................................................................................................1 Modèles stratégiques et architecture d’entreprise..................................................................3 L’architecture d’entreprise .................................................................................................3 Le modèle d’affaires et le modèle opérationnel.................................................................5 La gestion de portefeuille de projets et la gestion de projet.............................................6 La gestion de portefeuille d’applications...........................................................................8 Gestion des capacités organisationnelles............................................................................. 10 Le cadre de référence TOGAF®.............................................................................................. 11 La méthode de développement d’architecture (ADM)..................................................... 11 ArchiMate®.............................................................................................................................. 13 TOGAF® et ArchiMate® .......................................................................................................... 13 Conclusion .............................................................................................................................. 14 Références............................................................................................................................... 16
• 3.
  © 2015 MiguelIriart, Marcelo Zampa 1 Introduction Ce document présente un survol de haut niveau des principaux éléments à couvrir pour réussir la mise en œuvre d’une transformation et modernisation organisationnelle efficace. Ce survol est basé sur les bonnes pratiques afin de produire la feuille de route technologique (roadmap) alignée sur la stratégie d’affaires et sa gouvernance. Les gestionnaires de chaque organisation ont besoin de générer et de gérer efficacement les changements organisationnels, en plus d’aligner les investissements en TI sur leurs stratégies d’affaires. La tendance actuelle nous montre que la durée de chaque cycle économique diminue en fonction des changements de la concurrence et des technologies. La mauvaise synchronisation et la faible communication entre les niveaux stratégique, tactique et opérationnel génèrent le manque d’agilité qui empêche l’organisation de s’adapter rapidement aux changements. Réussir l’implantation d’une stratégie d’affaires pour combler ces lacunes est un défi d’envergure, car, en général, les parties prenantes de ces différents niveaux organisationnels agissent en fonction de leurs propres réalités et contextes. Pour améliorer la communication entre les participants impliqués dans les processus opérationnels et les stratégies d’affaires, on utilise des modèles d’affaires. Le résultat de la réalisation de ces modèles est utilisé par l'architecture d'entreprise et, ensuite, par la conception et l’implantation des processus d’affaires. Par la suite, ces processus devront être supportés par les applications informatiques et l’infrastructure technologique. À la différence d’une architecture TI conventionnelle, ce concept d’architecture d’entreprise (AE) englobe une vision beaucoup plus large de l’organisation, donc, une vision holistique sans cloisonnement de portée. Au cours des dernières années, la gestion de l’architecture d’entreprise a évolué d'une vision exclusive de systèmes d’information, à une approche vers la gestion stratégique d’entreprises.
• 4.
  © 2015 MiguelIriart, Marcelo Zampa 2 Le parcours entre la situation actuelle et la situation cible passe à travers cette architecture d’entreprise, évolutive, de transition, qui est la base décisionnelle de chaque composante du portefeuille de projets et du portefeuille d’applications, en respectant en tout temps la capacité organisationnelle. EPM – Enterprise Portfolio Management
• 5.
  © 2015 MiguelIriart, Marcelo Zampa 3 Modèles stratégiques et architecture d’entreprise L’architecture d’entreprise L’architecture d’entreprise s’appuie sur la décision stratégique d’une organisation d’implanter une méthode structurée pour définir sa feuille de route en transformation organisationnelle et en investissement TI, en s’assurant que ces derniers respectent l’alignement stratégique sur les besoins d’affaires. Cette méthode est basée sur l’évaluation continue des services d’affaires, des processus d’affaires, des applications, et de l’infrastructure technologique qui les supporte. Le résultat de l’application de cette méthode est un plan de transformation qui présente les améliorations souhaitées au portefeuille d’applications, pour arriver à la situation cible stratégiquement définie préalablement. Il existe une relation étroite et naturelle entre : • l’architecture d’entreprise; • les modèles d’affaires et la gestion des opérations; • la gestion de portefeuille de projets; • la gestion de projet; • la gestion de portefeuille d’applications.
• 6.
  © 2015 MiguelIriart, Marcelo Zampa 4 L’architecture d’affaires doit être intégrée et synchronisée avec les architectures des données, des applications et technologique. Cette intégration définit le style et la méthode utilisée pour la modélisation, le déploiement et les interrelations de chacune des composantes. L’architecture d’entreprise devrait gérer et communiquer les standards adoptés afin que les projets les utilisent et les respectent. Pour commencer la démarche de ce programme, les gestionnaires devront visualiser l’organisation dans le futur et définir : • l’état cible des affaires; • les capacités organisationnelles; • les modifications nécessaires afin de supporter la nouvelle stratégie d’affaires. L’architecture d’entreprise fait une revue des capacités d’affaires et une évaluation de l'état de préparation à la transformation organisationnelle. Elle utilise une méthode précise permettant de définir et de planifier cette transformation sur la base des principes de planification en focalisant sur les résultats. Source: TOGAF® 9 - http://pubs.opengroup.org/architecture/togaf9-doc/arch/ - 6.2.6 Relating the Management Frameworks
• 7.
  © 2015 MiguelIriart, Marcelo Zampa 5 Le modèle d’affaires et le modèle opérationnel D’abord, on doit préciser les différences entre ces deux modèles. • Le modèle opérationnel, ou de fonctionnement, représente la façon dont l’organisation réalise ses activités afin d'accomplir sa mission. Ces activités sont représentées par les processus d’affaires, d’organisation et technologiques. • Le modèle d'affaires décrit comment une organisation crée de la valeur, la délivre et la capture. À partir de ces modèles, les gestionnaires pourront modéliser l’état actuel et l’état cible en utilisant des techniques spécialisées, comme les sessions de remue-méninges (brainstorming) et autres. Les écarts entre ces deux états permettront de définir le plan de transformation et les besoins organisationnels pour y arriver. Les processus d’affaires Un processus d’affaires présente les étapes pour livrer un produit ou un service déterminé. Quand on fait référence aux activités internes d’une organisation, on parle d’un processus de type fonctionnel. Par ailleurs, si on met l’accent sur les besoins des clients, on parle dans ce cas d’un processus d’entreprise. Amélioration des processus d’affaires Toute initiative de l’organisation doit considérer les stratégies, les cycles d’affaires, l’intégration de ressources humaines, les processus et les technologies, afin de réaliser de façon efficiente un produit ou un service d’affaires. Dans un programme d’amélioration des processus d’affaires, on doit d’abord faire la cartographie de ces processus, et ensuite appliquer la technique de la chaîne de valeur afin de classifier chaque activité de chaque processus selon la valeur apportée à l’organisation. En ayant comme objectif l’optimisation de chaque processus, il faut éliminer les activités sans valeur ajoutée, et maximiser celles perçues comme nécessaires par le client (les activités avec valeur ajoutée pour les affaires). Dans une période d’austérité budgétaire ou d’instabilité économique, l’optimisation des processus d’affaires devrait faire partie des priorités de l’organisation. Les organisations doivent faire face à de nouveaux défis stratégiques et tendances informatiques. Celles qui ont déjà commencé leurs plans de transformation possèdent un avantage significatif afin d’améliorer leur performance et leur compétitivité sur le marché.
• 8.
  © 2015 MiguelIriart, Marcelo Zampa 6 La gestion de portefeuille de projets et la gestion de projet L’architecture d’entreprise matérialise le plan de transformation à partir de la réalisation d’« architectures de transition » successives. Dans ces architectures, on doit visualiser les projets et les programmes de projets alignés sur la cible finale. Cet ensemble de projets et de programmes de projets constitue le portefeuille de projets de l’organisation. Chaque composante de ce portefeuille doit soigneusement être identifiée, évaluée et priorisée, en s’assurant de toujours garder un bon équilibre organisationnel et d’avoir les capacités nécessaires pour garantir la réalisation. Le suivi fréquent de son avancement, à partir de l’établissement de points de contrôle précis et de tableaux de bord, permettra de détecter tout écart et de mettre en place les actions correctives au bon moment, si nécessaire. La gestion de portefeuille de projets est un processus décisionnel dans lequel chaque composante, projet ou programme, est constamment mise à jour et révisée. La gestion de portefeuille de projets vise à obtenir l’assurance que l’on réalise les bons projets, alors que la gestion de projet vise à obtenir l’assurance que chaque projet est réalisé correctement. Ces deux gestions sont nécessaires et complémentaires.
• 9.
  © 2015 MiguelIriart, Marcelo Zampa 7 Relation entre la planification stratégique, les opérations, les projets, les programmes et le portefeuille de projets. Source: Figure 3-3 - The Standard for Portfolio Management – ©2006 Project Management Institute, Inc. Un programme est défini comme un groupe de projets apparentés, de sous- programmes et d’activités de programme, dont la gestion est coordonnée afin d’en tirer des avantages que n’apporterait pas une gestion individuelle. Guide PMBOK – Cinquième édition – © PMI Certains facteurs peuvent indiquer la présence d’une problématique dans la gestion du portefeuille de projets, telles que l’existence d’une quantité élevée de projets, une faible valeur ajoutée pour l’organisation ou un manque d’alignement sur les objectifs stratégiques. La gestion de portefeuille de projets doit être placée au cœur de la gouvernance de l’organisation. Relation entre les composants de l’AE
• 10.
  © 2015 MiguelIriart, Marcelo Zampa 8 La gestion de portefeuille d’applications Certaines situations liées à l’évolution des stratégies d’entreprise ou aux tendances de l'industrie informatique sont à l’origine des scénarios de duplication des services et des applications, de la sous-utilisation ou de la désuétude, avec un important impact sur les coûts opérationnels de l’organisation et sur la charge de travail de l’équipe de support technologique. Exemples de situations liées à : l’évolution des stratégies d’entreprise Exemples de situations liées aux : tendances de l'industrie informatique - les regroupements et les fusions; - les acquisitions; - la diversification; - le commerce électronique; - l’externalisation; - les nouveaux canaux de distribution; … - le Web 2.0 et 3.0; les services Web; le Cloud; - le “bureau mobile”; - SOA; - l’Open Source, la virtualisation; - ERP et CRM; - les réseaux sociaux; … La réalisation d’une cartographie d’applications va permettre d’identifier les sources de ces situations problématiques. L’optimisation du portefeuille d’applications, de même que la gestion de leur cycle de vie, doit faire partie des priorités stratégiques de l’organisation afin de minimiser les dépenses opérationnelles et d’entretien. Ainsi, des économies potentielles (de 10 à 20 %) pourraient être investies pour la réalisation de nouvelles initiatives. En règle générale, pour une moyenne ou grande entreprise : • 20 % des applications pourraient être consolidées en éliminant les fonctionnalités superflues; • 20 % des applications pourraient être remplacés ou retirés. La gestion de portefeuille d’applications (GPA) doit exécuter d’une manière rigoureuse les activités suivantes : • cartographier les applications; • les catégoriser par différents critères, p. ex. : - type d’application (stratégique, opérationnelle, de support, etc.); - alignement sur l’AE et sur la valeur stratégique; - coûts de maintenance; - type de développement (maison ou achat), et autres. • pondérer et donner un score à chaque application à partir des données quantitatives et qualitatives. Cette technique va permettre de positionner les applications sur les axes stratégiques de l’organisation, afin d’identifier et d’évaluer une stratégie adaptée à chacune (p. ex. : migrer, retirer, standardiser, consolider, etc.). Cette veille technologique sur les applications doit être faite continuellement, ce qui permettra aux organisations d’assurer la qualité de leur portefeuille d’applications, leur productivité et un alignement optimal sur les stratégies d’affaires.
• 11.
  © 2015 MiguelIriart, Marcelo Zampa 9 Par ailleurs, une GPA efficace permet d’assurer l’alignement entre le portefeuille d’applications et le portefeuille de projets, ce qui représente une diminution des coûts et des risques associés à la réalisation des projets. Ratio du budget d’entretien vs les nouvelles initiatives • En général, la plupart du budget TI est consacrée à la maintenance des applications (+/- 80 %), et seule une partie minime (+/- 20 %) est affectée aux nouvelles initiatives. • Chaque organisation doit établir son propre ratio d’utilisation du budget (p. ex. 70/30, 60/40, etc.) selon les axes stratégiques définis par la direction stratégique.
• 12.
  © 2015 MiguelIriart, Marcelo Zampa 10 Gestion des capacités organisationnelles Pour réaliser efficacement le plan de transformation organisationnelle, l’organisation doit identifier et bâtir ses propres capacités, et ce, pour chaque domaine essentiel. L’organisation doit s’assurer que chaque capacité dont elle dispose réalisera ses responsabilités de façon efficace et efficiente, et qu’elle arrivera au niveau de maturité requis afin de garantir la réalisation du plan de transformation. • Il y a différents cadres de référence de maturité pour chaque domaine de l’architecture d’entreprise. • On trouve le cadre de maturité d’architecture dans le référentiel TOGAF® 9 1 , ainsi que la description des rôles et compétences 2. • Le modèle OPM3® (Organizational Project Management Maturity Model) du PMI est le cadre de maturité pour la gestion de portefeuille, de programmes, et de projet. Source: Figure 2 - EA Domain Positioning – Livre: Enterprise Architecture Good Practices Guide: How to Manage the Enterprise Architecture Practice - Jaap Schekkerman – © IFEAD 1 TOGAF ® - http://pubs.opengroup.org/architecture/togaf9-doc/arch/ - 51. Architecture Maturity Models 2 TOGAF ® - http://pubs.opengroup.org/architecture/togaf9-doc/arch/ - 52. Architecture Skills Framework; 52.6 Generic Role and Skills of the Enterprise Architect; 52.6.3 Key Characteristics of an Enterprise Architect
• 13.
  © 2015 MiguelIriart, Marcelo Zampa 11 Le cadre de référence TOGAF® « TOGAF® est un cadre d’architecture – Le cadre d’architecture de l’Open Group (The Open Group Architecture Framework). En résumé, TOGAF® est un outil d’aide à l’appropriation, à la production, à l’utilisation et à la maintenance des architectures. Il se fonde sur un modèle de processus itératifs faisant appel aux bonnes pratiques et à un actif architectural réutilisable. TOGAF® 9 peut être utilisé pour développer une large gamme d’architectures d’entreprise. TOGAF complète d’autres cadres conceptuels (frameworks) et peut s’utiliser conjointement avec eux. » 3 The Open Group est un consortium de normalisation neutre vis-à-vis des fournisseurs et des technologies (c'est-à-dire qu'il ne dépend pas d'une firme ou d'une technologie en particulier) composé de plus de trois cents organisations membres. 4 Une façon de vulgariser un cadre de travail (framework) d’AE est de définir l’AE comme une méthode pour tracer le parcours vers les résultats. À l’intérieur de chacune de ses phases de réalisation, on intègre et recommande l’utilisation de différents domaines de connaissances, d’autres cadres5 (p. ex. PMBOK®, ITIL®, COBIT®, etc.), de bonnes pratiques et de techniques existantes dans chaque domaine, pour définir un plan de transformation harmonisé, efficace et efficient, afin d’arriver à l’état cible défini par les objectifs et orientations de la stratégie d’affaires de l’entreprise. La méthode de développement d’architecture (ADM) Parmi toutes les parties du cadre de référence TOGAF, l’ADM est celle qui mérite un traitement préférentiel dans ce document. « L'ADM, qui est le fruit des contributions d'un grand nombre d'architectes, est le cœur de TOGAF. Il s'agit d'une méthode permettant d'élaborer des architectures d'entreprise propres à chaque organisation. Elle est spécifiquement conçue pour répondre aux exigences de l'entreprise. L'ADM décrit : • Une démarche fiable et éprouvée permettant de développer et d'utiliser une architecture d'entreprise. • Une méthode de développement d'architectures à des niveaux différents (affaires, applications, données, technique) qui permet à l'architecte de bien prendre en compte un jeu complexe d'exigences. • Des recommandations concernant les outils utilisés dans le développement d'une architecture. » 6 3 TOGAF™ Version 9 – Guide de Poche – The Open Group 4 Wikipedia 5 Source : http://pubs.opengroup.org/architecture/togaf9-doc/arch/ - 2.10 Using TOGAF with Other Frameworks http://pubs.opengroup.org/architecture/togaf9-doc/arch/ - 5.3 Adapting the ADM 6 TOGAF™ Version 9 – Guide de Poche – The Open Group - 2.1 Qu'est-ce que l'ADM ?
• 14.
  © 2015 MiguelIriart, Marcelo Zampa 12 Les phases de l’ADM de TOGAF Les activités de l'ADM phase par phase 7 Phase ADM Activité Phase préliminaire Préparer l'organisation pour la réussite des projets d'architecture TOGAF. Entreprendre les activités de préparation et de démarrage nécessaires pour aligner les recommandations d’affaires sur une nouvelle architecture d’entreprise, incluant la définition d’un cadre d’architecture et les outils propres à l’organisation, avec la définition des principes. Gestion des exigences Chaque stade d'un projet TOGAF fait appel à des exigences d’affaires et valide ces dernières. Les exigences sont identifiées, stockées et délivrées comme entrants et sortants des phases ADM concernées, qui traitent et hiérarchisent ces exigences. A. Vision de l'architecture Définir la portée, les contraintes et les attentes d'un projet TOGAF. Créer une vision de l'architecture. Définir les parties prenantes. Valider le contexte d’affaires et créer la définition du chantier d'architecture. Obtenir les approbations. B. Architecture d’affaires C. Architecture des systèmes d'information D. Architectures techniques Développer les architectures à trois niveaux : • Affaires • Systèmes d'information (applications et données) • Technologique Dans chaque cas, développer les architectures initiale et cible, et analyser les écarts. E. Opportunités et solutions Effectuer une première planification de mise en œuvre et une première identification des modalités de livraison pour les Building Blocks identifiés lors des phases précédentes. Identifier les principaux projets de mise en œuvre et les regrouper dans les architectures de transition. F. Planification de la migration Analyser les avantages et les risques financiers. Développer un plan détaillé de mise en œuvre et de migration. G. Gouvernance de la mise en œuvre Assurer la supervision de la mise en œuvre. Préparer et diffuser les contrats d'architecture (Comité de gouvernance de la mise en œuvre). Vérifier que le projet de mise en œuvre respecte l'architecture. H. Gestion du changement d'architecture Assurer un suivi continu, et prévoir un processus de gestion des changements garantissant que l'architecture réponde aux besoins de l'organisation et qu’elle rende maximale la valeur ajoutée pour les affaires. 7 TOGAF™ Version 9 – Guide de Poche – The Open Group - Tableau 3
• 15.
  © 2015 MiguelIriart, Marcelo Zampa 13 ArchiMate® ArchiMate® est un langage de modélisation, ouvert et libre, pour l'architecture d'entreprise. Il est supporté par différents fournisseurs. Il fournit des instruments pour permettre aux architectes d'entreprise de décrire, d’analyser et de visualiser sans ambigüité les relations entre les domaines d'affaires. Pour cette raison, il est rapidement devenu le langage standard pour réaliser cette modélisation. Le cadre de référence TOGAF® et ArchiMate® sont tous les deux des standards ouverts, supportés et harmonisés par The Open Group. TOGAF® et ArchiMate® Le langage ArchiMate 2.0 met l’accent sur la description des quatre domaines d’architecture de TOGAF (affaires, données, applications et technologie) ainsi que sur leurs relations et dépendances, et les extensions pour modeler la Motivation et la planification de la migration et de l’implantation, afin d’implémenter toutes les composantes de la méthode ADM de TOGAF. Source : Figure 5 : Relation entre TOGAF et ArchiMate Livre : ArchiMate® 2 Certification Guide Source : Figure 6 : Relation entre ArchiMate et l’ADM de TOGAF Livre : ArchiMate® 2 Certification Guide • TOGAF et ArchiMate sont naturellement complémentaires. • ArchiMate est aussi complémentaire à tous les autres langages et notations de modélisation, tels qu’UML et BPMN. Chacune de ces modélisations a ses particularités et avantages, et possède des fonctionnalités complémentaires à celles d’ArchiMate. • Autres possibilités d’utilisation d’ArchiMate : la modélisation des risques d’entreprise, l’ajout d’attributs pour faciliter la gestion des applications, l’évaluation des coûts des stratégies, la réalisation des analyses d’impact, etc.
• 16.
  © 2015 MiguelIriart, Marcelo Zampa 14 Conclusion La solution à la problématique présentée commence par le démarrage d’un plan d’architecture d’entreprise, en ayant comme objectif principal l’obtention d’une feuille de route de la transformation organisationnelle et technologique alignée sur la stratégie d’affaires. Les résultats recherchés par le plan de transformation organisationnelle basé sur l’architecture d’entreprise se résument à l’agilité, la transparence, la maximisation des bénéfices, la minimisation des coûts et la réduction des risques.
• 17.
  © 2015 MiguelIriart, Marcelo Zampa 15 Pour assurer le succès de la transformation organisationnelle et sa pérennité dans le temps, le plan doit tenir compte de : • l’évaluation de l’état de préparation de l’organisation face à la transformation d’affaires, l’évaluation de la capacité organisationnelle, et la gestion des risques liés à cette transformation 8 ; • la maîtrise des processus d’affaires jusqu’au niveau de maturité choisi afin de donner à l’organisation l’agilité nécessaire pour livrer efficacement ses produits et ses services; • une gestion efficace du portefeuille d’applications mettant l’accent sur la valeur ajoutée organisationnelle; • une gestion de projet rigoureuse qui vise à obtenir l’assurance que l’on réalise correctement les projets, afin d’obtenir les bénéfices escomptés; • une gestion de portefeuille de projets efficace et optimisée en tenant compte de la capacité organisationnelle et de la gestion des résultats; • l’utilisation des meilleures pratiques et des cadres de référence reconnus internationalement, comme TOGAF® et ArchiMate® (pour l’AE), PMBOK® (pour la gestion de projet), ITIL®, COBIT® et autres. Finalement, nous préconisons une approche basée sur l’intégration et l'alignement de toutes ces différentes disciplines, indépendantes et complémentaires, pour que l’organisation soit équipée de tous les éléments nécessaires (stratégies, processus, méthodes, techniques et outils), afin de garantir la réussite de la transformation organisationnelle visée. 8 http://pubs.opengroup.org/architecture/togaf9-doc/arch/ - TOGAF® - 7. Phase A: Architecture Vision - 7.4.4 Evaluate Business Capabilities - 7.4.5 Assess Readiness for Business Transformation - 7.4.10 Identify the Business Transformation Risks and Mitigation Activities
• 18.
  © 2015 MiguelIriart, Marcelo Zampa 16 Références 1. TOGAF® Version 9.1 - © 2011, The Open Group 2. TOGAF® 9.1 – http://pubs.opengroup.org/architecture/togaf9-doc/arch/ - © The Open Group 3. TOGAFTM Version 9 – Guide de Poche, © 2009, The Open Group 4. ArchiMate® 2.1 – Specification - © 2012, The Open Group 5. ArchiMate® 2.1 - http://pubs.opengroup.org/architecture/archimate2-doc/toc.html © The Open Group 6. ArchiMate® 2.0 – A Pocket Guide - © 2012, The Open Group 7. Guide du corpus des connaissances en management de projet (Guide PMBOK®) – Cinquième édition – © 2013, PMI 8. The Standard for Program Management (PgMP®) - Third Edition – © 2013, PMI 9. The Standard for Portfolio Management - Third Edition – © 2013, PMI 10. Organizational Project Management Maturity Model (OPM3®) – Third Edition - © 2013, PMI 11. Enterprise Architecture Good Practices Guide: How to Manage the Enterprise Architecture Practice - Jaap Schekkerman – © 2008, Institute For Enterprise Architecture Developments TOGAF® et ArchiMate® sont des marques enregistrées par The Open Group. PMBOK®, OPM3®, PgMP® sont des marques enregistrées par Project Management Institute Inc. Les auteurs ont fait les démarches qu’ils ont estimées nécessaires pour obtenir les autorisations des détenteurs des droits d’auteur (copyright) du matériel inclus dans cette œuvre. Dans le cas d’un oubli involontaire, on demande au détenteur d’accepter nos excuses et de nous contacter pour régler dans les plus brefs délais cette situation.