\n| Fermeture des centres de messagerie<\/td>\n | D\u00e9cision de fermer les centres de messagerie et de passer \u00e0 la messagerie instantan\u00e9e comme canal de communication principal<\/td>\n | \n\n- \u00c9valuer l’impact de la fermeture sur le personnel et les processus<\/li>\n
- \u00c9laborer des plans de formation du personnel pour une utilisation efficace de la messagerie instantan\u00e9e<\/li>\n
- Tenir compte des \u00e9conomies potentielles issues de la fermeture et les prioriser en cons\u00e9quence<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
\n| Personnel<\/td>\n | Les personnes impliqu\u00e9es dans la mise en \u0153uvre du plan et\/ou touch\u00e9es par les changements<\/td>\n | \n\n- Identifier les r\u00f4les et responsabilit\u00e9s du personnel impliqu\u00e9 dans la mise en \u0153uvre<\/li>\n
- \u00c9valuer l’impact des changements sur le personnel<\/li>\n
- \u00c9laborer des plans de formation ou de r\u00e9affectation du personnel selon les besoins<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
\n| Messagerie instantan\u00e9e<\/td>\n | La nouvelle technologie introduite dans le cadre du plan de mise en \u0153uvre<\/td>\n | \n\n- \u00c9valuer les avantages et inconv\u00e9nients de l’utilisation de la messagerie instantan\u00e9e comme canal de communication principal<\/li>\n
- \u00c9laborer des plans de formation du personnel \u00e0 l’utilisation efficace des messageries instantan\u00e9es<\/li>\n
- Prioriser la messagerie instantan\u00e9e comme mesure d’\u00e9conomie de co\u00fbts<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
\n| Co\u00fbt<\/td>\n | Les implications financi\u00e8res du plan de mise en \u0153uvre<\/td>\n | \n\n- \u00c9valuer les co\u00fbts associ\u00e9s \u00e0 la mise en \u0153uvre du plan<\/li>\n
- Consid\u00e9rer des mesures d’\u00e9conomie de co\u00fbts telles que l’utilisation de la messagerie instantan\u00e9e<\/li>\n
- \u00c9laborer des plans pour surveiller et g\u00e9rer les co\u00fbts tout au long de la mise en \u0153uvre<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Encore une fois, il s’agit simplement d’une des fa\u00e7ons possibles de r\u00e9g\u00e9n\u00e9rer la matrice sur la base de la technologie mise \u00e0 jour, et les facteurs, descriptions et d\u00e9ductions r\u00e9els utilis\u00e9s dans la matrice d\u00e9pendront du sc\u00e9nario d’affaires sp\u00e9cifique trait\u00e9.<\/p>\n \u00a0<\/p>\n Matrice consolid\u00e9e des \u00e9carts, des solutions et des d\u00e9pendances<\/h2>\nLa matrice consolid\u00e9e des \u00e9carts, des solutions et des d\u00e9pendances est une technique utilis\u00e9e dans le processus de d\u00e9veloppement d’architecture TOGAF pour identifier et regrouper les \u00e9carts dans le domaine d’architecture, \u00e9valuer les solutions potentielles et les d\u00e9pendances li\u00e9es \u00e0 ces \u00e9carts.<\/p>\n Cette technique aide les architectes \u00e0 prioriser leurs t\u00e2ches et \u00e0 identifier les domaines o\u00f9 les solutions peuvent avoir l’impact le plus important. En regroupant les \u00e9carts, les architectes peuvent mieux comprendre les relations entre eux et identifier des solutions qui traitent plusieurs \u00e9carts simultan\u00e9ment.<\/p>\n La matrice est \u00e9galement utile pour planifier et cr\u00e9er des paquets de travail. Les d\u00e9pendances identifi\u00e9es peuvent aider \u00e0 piloter la cr\u00e9ation de projets et \u00e0 informer la planification de migration dans les phases E et F du processus de d\u00e9veloppement d’architecture. Cela garantit que les projets sont correctement prioris\u00e9s et align\u00e9s sur les objectifs commerciaux.<\/p>\n Dans l’ensemble, la matrice consolid\u00e9e des \u00e9carts, des solutions et des d\u00e9pendances est un outil pr\u00e9cieux pour les architectes \u00e0 utiliser tout au long du processus de d\u00e9veloppement d’architecture, leur permettant d’identifier les \u00e9carts, les solutions et les d\u00e9pendances, de prioriser leurs t\u00e2ches et de piloter une planification et une ex\u00e9cution de projet efficaces.<\/p>\n Exemple<\/h3>\nVoici un exemple de la mani\u00e8re dont la matrice consolid\u00e9e des \u00e9carts, des solutions et des d\u00e9pendances pourrait \u00eatre utilis\u00e9e :<\/p>\n Supposons que, pendant la phase d’analyse des \u00e9carts du processus de d\u00e9veloppement d’architecture, l’\u00e9quipe d’architecture a identifi\u00e9 plusieurs \u00e9carts dans l’architecture actuelle. Ces \u00e9carts incluent :<\/p>\n \n- Absence d’un r\u00e9f\u00e9rentiel centralis\u00e9 de donn\u00e9es clients<\/li>\n
- D\u00e9finitions de donn\u00e9es incoh\u00e9rentes entre les unit\u00e9s commerciales<\/li>\n
- Int\u00e9gration limit\u00e9e entre les syst\u00e8mes CRM et de traitement des commandes<\/li>\n<\/ol>\n
Pour cr\u00e9er une matrice consolid\u00e9e des \u00e9carts, des solutions et des d\u00e9pendances, l’\u00e9quipe d’architecture regrouperait ces \u00e9carts et \u00e9valuerait les solutions potentielles et les d\u00e9pendances. Par exemple :<\/p>\n Voici \u00e0 nouveau l’exemple, avec des num\u00e9ros ajout\u00e9s dans la premi\u00e8re colonne :<\/p>\n \n\n\n| #<\/th>\n | \u00c9cart<\/th>\n | Solutions potentielles<\/th>\n | D\u00e9pendances<\/th>\n<\/tr>\n<\/thead>\n | \n\n| 1<\/td>\n | Absence d’un r\u00e9f\u00e9rentiel centralis\u00e9 de donn\u00e9es clients<\/td>\n | Mettre en place un data lake pour les donn\u00e9es clients<\/td>\n | D\u00e9pend de la r\u00e9solution des d\u00e9finitions de donn\u00e9es incoh\u00e9rentes<\/td>\n<\/tr>\n | \n| 2<\/td>\n | D\u00e9finitions de donn\u00e9es incoh\u00e9rentes entre les unit\u00e9s commerciales<\/td>\n | \u00c9tablir un cadre de gouvernance des donn\u00e9es et un mod\u00e8le de donn\u00e9es commun<\/td>\n | D\u00e9pend de la mise en \u0153uvre d’un lac de donn\u00e9es<\/td>\n<\/tr>\n | \n| 3<\/td>\n | Int\u00e9gration limit\u00e9e entre les syst\u00e8mes CRM et de traitement des commandes<\/td>\n | Mettre en \u0153uvre un bus de services d’entreprise (ESB) pour permettre l’\u00e9change de donn\u00e9es en temps r\u00e9el<\/td>\n | D\u00e9pend de la mise en \u0153uvre d’un cadre de gouvernance des donn\u00e9es et d’un mod\u00e8le de donn\u00e9es commun<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Dans cet exemple, la matrice montre qu’il est n\u00e9cessaire d’adopter une approche en plusieurs \u00e9tapes pour combler les lacunes relatives aux donn\u00e9es clients, en passant par la r\u00e9solution des incoh\u00e9rences de donn\u00e9es, la mise en \u0153uvre d’un lac de donn\u00e9es, l’\u00e9tablissement d’un cadre de gouvernance des donn\u00e9es et d’un mod\u00e8le de donn\u00e9es commun, puis enfin la mise en \u0153uvre d’un ESB pour permettre l’\u00e9change de donn\u00e9es en temps r\u00e9el.<\/p>\n Cette matrice peut \u00eatre utilis\u00e9e pour planifier les paquets de travail, identifier les d\u00e9pendances et prioriser les projets dans les phases E et F. Par exemple, l’\u00e9quipe d’architecture pourrait privil\u00e9gier la mise en \u0153uvre du cadre de gouvernance des donn\u00e9es et du mod\u00e8le de donn\u00e9es commun comme premi\u00e8re \u00e9tape pour combler les lacunes identifi\u00e9es, car il s’agit d’une d\u00e9pendance pour la mise en \u0153uvre du lac de donn\u00e9es et de l’ESB.<\/p>\n Tableau des incr\u00e9ments de d\u00e9finition de l’architecture<\/h2>\nLe tableau des incr\u00e9ments de d\u00e9finition de l’architecture est une technique utilis\u00e9e dans le cadre d’architecture The Open Group (TOGAF) qui permet aux architectes de planifier et de suivre le d\u00e9veloppement d’une architecture d’entreprise au fil du temps. Le tableau liste les diff\u00e9rents projets qui contribueront au d\u00e9veloppement de l’architecture, et attribue \u00e0 chaque projet des livrables sp\u00e9cifiques qui seront r\u00e9alis\u00e9s par incr\u00e9ments au fil du temps.<\/p>\n Le but de ce tableau est de cr\u00e9er une feuille de route qui d\u00e9crit la s\u00e9quence pr\u00e9vue des architectures de transition, qui sont des \u00e9tats interm\u00e9diaires de l’architecture atteints \u00e0 des moments pr\u00e9cis durant le processus de d\u00e9veloppement. Chaque architecture de transition repr\u00e9sente une \u00e9tape de l’architecture plus compl\u00e8te et plus proche de l’\u00e9tat final que l’\u00e9tape pr\u00e9c\u00e9dente.<\/p>\n En divisant le processus de d\u00e9veloppement en livrables incr\u00e9mentaux et en les attribuant \u00e0 des projets et des d\u00e9lais sp\u00e9cifiques, le tableau des incr\u00e9ments de d\u00e9finition de l’architecture aide les architectes \u00e0 :<\/p>\n \n- Planifier le d\u00e9veloppement de l’architecture d’entreprise de mani\u00e8re structur\u00e9e et ma\u00eetris\u00e9e<\/li>\n
- S’assurer que chaque projet est correctement s\u00e9quenc\u00e9 et que chaque incr\u00e9ment est achev\u00e9 dans les d\u00e9lais<\/li>\n
- Identifier les d\u00e9pendances potentielles et les conflits entre diff\u00e9rents projets<\/li>\n
- Fournir une vue d’ensemble claire du processus de d\u00e9veloppement, qui peut \u00eatre partag\u00e9e avec les parties prenantes afin de s’assurer que tous sont align\u00e9s sur les objectifs et le calendrier du projet.<\/li>\n<\/ol>\n
Dans l’ensemble, le tableau des incr\u00e9ments de d\u00e9finition de l’architecture est un outil puissant qui peut aider les architectes \u00e0 g\u00e9rer des projets complexes d’architecture d’entreprise et \u00e0 garantir qu’ils soient men\u00e9s \u00e0 bien et termin\u00e9s dans les d\u00e9lais.<\/p>\n Voici un tableau des incr\u00e9ments de d\u00e9finition de l’architecture mis \u00e0 jour qui regroupe \u00e0 la fois les informations sur les incr\u00e9ments et les dates de d\u00e9but :<\/p>\n \n\n\n| Nom du projet<\/th>\n | Incident 1 \u2013 Date de d\u00e9but<\/th>\n | Incident 1<\/th>\n | Incident 2 \u2013 Date de d\u00e9but<\/th>\n | Incident 2<\/th>\n | Incident 3 \u2013 Date de d\u00e9but<\/th>\n | Incident 3<\/th>\n | Incident 4 \u2013 Date de d\u00e9but<\/th>\n | Incident 4<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Syst\u00e8me CRM<\/td>\n | T1 2023<\/td>\n | Architecture conceptuelle<\/td>\n | Q2 2023<\/td>\n | Architecture logique<\/td>\n | Q3 2023<\/td>\n | Architecture physique<\/td>\n | Q4 2023<\/td>\n | Syst\u00e8me enti\u00e8rement op\u00e9rationnel<\/td>\n<\/tr>\n | \n| Entrep\u00f4t de donn\u00e9es<\/td>\n | Q1 2023<\/td>\n | Architecture conceptuelle<\/td>\n | Q2 2023<\/td>\n | Architecture logique<\/td>\n | Q3 2023<\/td>\n | Architecture physique<\/td>\n | Q4 2023<\/td>\n | Syst\u00e8me enti\u00e8rement op\u00e9rationnel<\/td>\n<\/tr>\n | \n| Plateforme de commerce \u00e9lectronique<\/td>\n | Q2 2023<\/td>\n | Architecture conceptuelle<\/td>\n | Q3 2023<\/td>\n | Architecture logique<\/td>\n | Q4 2023<\/td>\n | Architecture physique<\/td>\n | Q1 2024<\/td>\n | Syst\u00e8me enti\u00e8rement op\u00e9rationnel<\/td>\n<\/tr>\n | \n| Application mobile<\/td>\n | Q2 2023<\/td>\n | Architecture conceptuelle<\/td>\n | Q3 2023<\/td>\n | Architecture logique<\/td>\n | Q4 2023<\/td>\n | Architecture physique<\/td>\n | Q1 2024<\/td>\n | Syst\u00e8me enti\u00e8rement op\u00e9rationnel<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Dans ce tableau mis \u00e0 jour, chaque projet comporte quatre incr\u00e9mentations, et chaque incr\u00e9ment a une date de d\u00e9but repr\u00e9sent\u00e9e par un trimestre et une ann\u00e9e. Cela permet \u00e0 l’architecte de planifier une s\u00e9rie d’architectures de transition et de suivre les progr\u00e8s vers la r\u00e9alisation du syst\u00e8me enti\u00e8rement op\u00e9rationnel pour chaque projet.<\/p>\n Par exemple, le projet CRM System d\u00e9bute en Q1 2023, et chaque incr\u00e9ment suivant d\u00e9bute au trimestre suivant. Le tableau indique que l’incr\u00e9ment Syst\u00e8me enti\u00e8rement op\u00e9rationnel est pr\u00e9vu pour Q4 2023. Cela permet \u00e0 l’architecte de planifier et de suivre les progr\u00e8s vers la r\u00e9alisation du syst\u00e8me enti\u00e8rement op\u00e9rationnel pour le projet CRM System.<\/p>\n De m\u00eame, le tableau indique les dates de d\u00e9but pour chaque incr\u00e9ment des trois autres projets. Cela aide l’architecte \u00e0 planifier et \u00e0 suivre les progr\u00e8s vers la r\u00e9alisation du syst\u00e8me enti\u00e8rement op\u00e9rationnel pour chaque projet, et \u00e0 identifier d’\u00e9ventuels conflits ou d\u00e9pendances entre les diff\u00e9rents projets.<\/p>\n Tableau d’\u00e9volution de l’\u00e9tat de l’architecture de transition<\/h2>\nLe tableau d’\u00e9volution de l’\u00e9tat de l’architecture de transition est une technique utilis\u00e9e dans le cadre d’architecture The Open Group (TOGAF) pour d\u00e9montrer l’\u00e9tat propos\u00e9 des architectures d’une organisation \u00e0 diff\u00e9rents niveaux \u00e0 l’aide d’une taxonomie d\u00e9finie, telle que le Mod\u00e8le de r\u00e9f\u00e9rence technique (TRM) de TOGAF. Ce tableau est un outil visuel qui aide les architectes \u00e0 identifier les services de la taxonomie utilis\u00e9s dans l’entreprise, puis \u00e0 lister les architectures de transition et les transformations propos\u00e9es pour ces services.<\/p>\n Le tableau doit inclure une liste de tous les Blocs de construction de solution (SBB) et d\u00e9crire leur impact et leur contribution aux services mentionn\u00e9s. Les SBB doivent \u00e9galement \u00eatre marqu\u00e9s pour montrer leur contribution \u00e0 l’\u00e9volution de l’architecture d’entreprise. Par exemple, si une nouvelle capacit\u00e9 est introduite, elle sera marqu\u00e9e comme \u00ab nouvelle \u00bb ou \u00ab conserver \u00bb dans le tableau. Si une capacit\u00e9 est en cours de transition vers une nouvelle solution, elle sera marqu\u00e9e comme \u00ab transition \u00bb. Et si une capacit\u00e9 est remplac\u00e9e, elle sera marqu\u00e9e comme \u00ab remplacer \u00bb.<\/p>\n Le tableau d’\u00e9volution de l’\u00e9tat de l’architecture de transition fournit une image claire des changements qui auront lieu dans l’architecture d’une organisation au fil du temps. Il permet aux architectes de voir comment leurs changements propos\u00e9s affecteront les services de l’organisation et comment ils contribueront \u00e0 conduire l’organisation vers son \u00e9tat cible. En utilisant ce tableau, les architectes peuvent s’assurer que leurs changements propos\u00e9s s’alignent sur les objectifs et buts de l’organisation et qu’ils peuvent \u00eatre mis en \u0153uvre efficacement.<\/p>\n Exemple<\/h3>\nVoici un exemple de ce \u00e0 quoi pourrait ressembler le tableau d’\u00e9volution de l’\u00e9tat de l’architecture de transition en fonction des colonnes que vous avez mentionn\u00e9es :<\/p>\n \n\n\n| Sous-domaine<\/th>\n | Service<\/th>\n | Architecture de transition 1<\/th>\n | Architecture de transition 2<\/th>\n | Architecture de transition 3<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Ventes<\/td>\n | Gestion des commandes<\/td>\n | \u00c9tat actuel<\/td>\n | \u00c9tat de transition<\/td>\n | \u00c9tat cible<\/td>\n<\/tr>\n | \n| Ventes<\/td>\n | Gestion des clients<\/td>\n | \u00c9tat actuel<\/td>\n | \u00c9tat de transition<\/td>\n | \u00c9tat cible<\/td>\n<\/tr>\n | \n| Finance<\/td>\n | Fournisseurs<\/td>\n | \u00c9tat actuel<\/td>\n | \u00c9tat de transition<\/td>\n | \u00c9tat cible<\/td>\n<\/tr>\n | \n| Finance<\/td>\n | Clients<\/td>\n | \u00c9tat actuel<\/td>\n | \u00c9tat de transition<\/td>\n | \u00c9tat cible<\/td>\n<\/tr>\n | \n| RH<\/td>\n | Paie<\/td>\n | \u00c9tat actuel<\/td>\n | \u00c9tat de transition<\/td>\n | \u00c9tat cible<\/td>\n<\/tr>\n | \n| RH<\/td>\n | Gestion des avantages<\/td>\n | \u00c9tat actuel<\/td>\n | \u00c9tat de transition<\/td>\n | \u00c9tat cible<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Dans cet exemple, la premi\u00e8re colonne liste les sous-domaines au sein de l’organisation, tels que les ventes, la finance et les ressources humaines. La deuxi\u00e8me colonne liste les services sp\u00e9cifiques dans chaque sous-domaine, tels que la gestion des commandes, les paiements et la paie. Les colonnes restantes repr\u00e9sentent les diverses architectures de transition, qui pourraient inclure l’\u00e9tat actuel, l’\u00e9tat de transition et l’\u00e9tat cible.<\/p>\n Chaque cellule du tableau serait ensuite remplie avec les informations pertinentes pour ce service et cette architecture. Par exemple, la cellule relative \u00e0 la gestion des commandes et \u00e0 la colonne de l’\u00e9tat actuel pourrait contenir une description de l’architecture actuelle utilis\u00e9e pour g\u00e9rer les commandes, tandis que la cellule relative \u00e0 la gestion des commandes et \u00e0 la colonne de l’\u00e9tat cible pourrait d\u00e9crire l’architecture propos\u00e9e pour g\u00e9rer les commandes \u00e0 l’avenir.<\/p>\n Technique d’\u00e9valuation de la valeur m\u00e9tier<\/h2>\nLa technique d’\u00e9valuation de la valeur m\u00e9tier que vous avez d\u00e9crite est une m\u00e9thode utile pour \u00e9valuer et prioriser diverses initiatives ou projets commerciaux. En utilisant une matrice bas\u00e9e sur les dimensions valeur et risque, les entreprises peuvent \u00e9valuer leurs options selon des crit\u00e8res objectifs align\u00e9s sur leurs objectifs strat\u00e9giques.<\/p>\n La dimension de l’indice de valeur, qui inclut le respect des principes, la contribution financi\u00e8re, l’alignement strat\u00e9gique et la position concurrentielle, aide \u00e0 d\u00e9terminer les b\u00e9n\u00e9fices et opportunit\u00e9s potentiels qu’un projet peut apporter \u00e0 l’entreprise. La dimension de l’indice de risque, qui inclut la taille et la complexit\u00e9, la technologie, la capacit\u00e9 organisationnelle et l’impact d’une d\u00e9faillance, aide \u00e0 identifier les risques et d\u00e9fis potentiels auxquels un projet pourrait \u00eatre confront\u00e9.<\/p>\n Exemple<\/h3>\nEn attribuant des poids individuels \u00e0 chaque crit\u00e8re, les entreprises peuvent d\u00e9terminer l’importance relative de chaque crit\u00e8re dans le processus de d\u00e9cision. Cela permet de s’assurer que les facteurs les plus critiques re\u00e7oivent une plus grande pond\u00e9ration dans l’\u00e9valuation.<\/p>\n \u00a0<\/p>\n ![](\"https:\/\/guides.visual-paradigm.com\/wp-content\/uploads\/2023\/03\/28_sample.png\"\/) <\/p>\n
Enfin, il est important d’\u00e9tablir les crit\u00e8res de d\u00e9cision avant de conna\u00eetre les options. Cela garantit que le processus d’\u00e9valuation reste objectif et coh\u00e9rent, et que toutes les options sont \u00e9valu\u00e9es selon les m\u00eames crit\u00e8res. Cela aide \u00e9galement \u00e0 pr\u00e9venir les biais et les pr\u00e9f\u00e9rences personnelles d’influencer le processus de d\u00e9cision.<\/p>\n | | | | | | |