wiki

Changes

GC Enterprise Architecture/Framework/BusinessGuide (view source)

Revision as of 15:41, 21 January 2022

12,253 bytes added ,  15:41, 21 January 2022
m
no edit summary
Line 1: Line 1: −
 
+
{{OCIO GCEA Header}}
 
<multilang>
 
<multilang>
−
@en|
+
@en|__TOC__
    
== Business architecture ==
 
== Business architecture ==
Line 7: Line 7:  
<br>
 
<br>
 
=== Design services digitally from end‑to‑end to meet the Government of Canada users and other stakeholders’ needs ===  
 
=== Design services digitally from end‑to‑end to meet the Government of Canada users and other stakeholders’ needs ===  
−
 
+
<br>
−
* <b>Clearly identify internal and external users and other stakeholders and their needs for each policy, program and business service</b>
+
==== Clearly identify internal and external users and other stakeholders and their needs for each policy, program and business service ====
    
In order to ensure that a service will be able to meet the users and stakeholders' needs, it needs to understand what needs it is trying to provide service for, who their users and stakeholders are, both internal and external. <br>
 
In order to ensure that a service will be able to meet the users and stakeholders' needs, it needs to understand what needs it is trying to provide service for, who their users and stakeholders are, both internal and external. <br>
Line 123: Line 123:  
* <b>reuse common business capabilities, processes and enterprise solutions from across government and private sector</b>
 
* <b>reuse common business capabilities, processes and enterprise solutions from across government and private sector</b>
    +
If there is a business capabilities, processes or enterprise solution that can be utilized in creating the service, eg. perhaps during the exchange of information from working groups, community of practices, workshops or even from working with private sectors, that are proven to work, we should consider using it prior to inventing our own. </br>
 +
This will optimize the time required to build the approach or the solution. Rather than having to proof the concept or solution actually works, use the ones that have a proven record. </br>
    
     <b>How to demonstrate that the project fulfils this framework:</b>
 
     <b>How to demonstrate that the project fulfils this framework:</b>
Line 132: Line 134:  
* <b>publish in the open all reusable common business capabilities, processes and enterprise solutions for others to develop and leverage cohesive horizontal enterprise services</b>
 
* <b>publish in the open all reusable common business capabilities, processes and enterprise solutions for others to develop and leverage cohesive horizontal enterprise services</b>
    +
Going back to the previous point on thinking at an enterprise level, one of the ways to enable a service that we build across the GC is by having it published in the open for other departments to see and re-use. Then and only we can create a cohesive horizontal enterprise services to create a cohesive experience to the users / stakeholders. </br>
    
     <b>How to demonstrate that the project fulfils this framework:</b>
 
     <b>How to demonstrate that the project fulfils this framework:</b>
Line 140: Line 143:       −
@fr|
+
@fr|__TOC__
 +
 
 +
 
 +
== ARCHITECTURE OPÉRATIONELLE ==
 +
L’architecture opérationnelle est un aspect essentiel à la réussite de la mise en œuvre de l’architecture cible de l’écosystème intégré du GC. La stratégie architecturale préconise une approche pan gouvernementale où les TI sont harmonisées avec les services opérationnels et les solutions sont fondées sur des composantes réutilisables mettant en œuvre des capacités opérationnelles afin d’offrir une expérience utilisateur cohérente. Par conséquent, il est essentiel de bien comprendre les services aux entreprises, les besoins des intervenants, les possibilités d’améliorer la cohésion et les possibilités de réutilisation à l’échelle du gouvernement. Par le passé, ces éléments n’étaient pas une priorité. On s’attend à ce que la culture et les pratiques en matière de TI doivent changer pour que l’architecture opérationnelle, en général, et ces éléments soient une priorité.
 +
 
 +
 
 +
=== Conception entièrement numérique des services pour répondre aux besoins des utilisateurs du gouvernement du Canada et des autres intervenants ===
 +
 
 +
==== * Identifier clairement les utilisateurs internes et externes et les autres intervenants et leurs besoins dans le cadre de chaque politique, programme et service opérationnel ====
 +
 
 +
Pour s'assurer qu'un service sera en mesure de répondre aux besoins des utilisateurs et des parties prenantes, il doit comprendre à quels besoins il essaie de fournir le service, qui sont leurs utilisateurs et parties prenantes, à la fois internes et externes.<br>
 +
 
 +
Une fois les besoins, les utilisateurs et les parties prenantes définis, un fournisseur de services peut alors créer une cartographie des parties prenantes pour mieux comprendre la relation entre le service et les utilisateurs et parties prenantes, c'est-à-dire. comment un changement dans un composant affecte l'autre. <br>
 +
 
 +
À partir de là, le fournisseur de services peut effectuer une analyse des besoins de ses utilisateurs et parties prenantes pour développer un programme, une politique ou un service qui répond à leurs besoins (cette pratique peut également être connue sous le nom d'exigences des parties prenantes ou de cartographie des valeurs). <br>
 +
 
 +
Cet exercice peut également aider à définir les limites/portée du programme/politique/service pour mieux gérer les attentes de leurs utilisateurs/parties prenantes. <br>
 +
 
 +
  <b>Comment démontrer que le projet remplit ce cadre :</b>
 +
      * résumer les besoins et les résultats de chaque intervenant clé externe et interne dans le cadre de l'architecture
 +
      * démontrer comment l'architecture est axée sur les besoins et les résultats des parties prenantes internes et externes
 +
    <b>Outils :</b>
 +
      * Business case
 +
      * Cartographie des parties prenantes (acteurs, rôles, unités organisationnelles) et exigences des parties prenantes
 +
      * Résultats
 +
      * Carte des processus métier
 +
      * Flux de valeur et cartographie de la valeur
 +
</br>
 +
 
 +
==== * Inclure les exigences de la politique qui s’appliquent à des utilisateurs en particulier et à d’autres groupes d’intervenants, comme l’accessibilité, l’analyse comparative entre les sexes plus et les langues officielles, dans la création du service ====
 +
Pour s'assurer qu'un service peut être utilisé par tous ses utilisateurs, il est important de noter les exigences spécifiques pour des utilisateurs spécifiques et, dans cette mesure, il est important de prendre note et d'appliquer la politique qui régit les normes de service lors de la fourniture du service à un groupes d'utilisateurs.</br>
 +
Cela permettra à son tour au service d'être étendu et plus inclusif pour tous ses utilisateurs.
 +
 
 +
    <b>Comment démontrer que le projet remplit ce cadre :</b>
 +
      * Décrire quelles politiques contraignent l'architecture
 +
      * Décrire l'impact positif et négatif de la politique sur l'architecture pour répondre aux besoins des parties prenantes
 +
      * Décrire comment l'architecture prend en charge l'éventail complet de la conception de services et de l'expérience utilisateur
 +
    <b>Outils :</b>
 +
      * Principes de conception de l'interface utilisateur
 +
</br>
 +
 
 +
==== * Effectuer une évaluation de l’incidence algorithmique (EIA) pour appuyer les activités d’atténuation des risques lors du déploiement d’un système décisionnel automatisé conformément à la Directive sur la prise de décisions automatisée ====
 +
 
 +
Lorsqu'un service dispose d'une automatisation dans le système pour la prise de decision, il est essential que le service effectue l'EIA pour s'assurer que le résultat de cette prise de décision est impartiél et équitable, et que l'impact de cette decision serait le mëme qu si la décision est prise manuellement, mais plus rapidement. </br>
 +
L'utilisation de ce type de système doit suivre de près la directive sur la prise de décision automatisée.
 +
 
 +
    <b>Comment démontrer que le projet remplit ce cadre :</b>
 +
      * Fournir le niveau d'impact basé sur l'achèvement de l'AIA conceptuel
 +
      * Décrire comment l'architecture répondra aux recommandations de l'AIA
 +
      * Décrire comment l'architecture répond aux exigences de la directive pour le niveau d'impact
 +
    <b>Outils :</b>
 +
      * Résultats AIA (conceptuels)
 +
</br>
 +
 
 +
==== * Modéliser la prestation de services opérationnels du début à la fin afin d’assurer la qualité, de maximiser l’efficacité et d’optimiser les gains d’efficience dans tous les canaux (p. ex., processus allégé) ====
 +
 
 +
Lors de la création d'un service, assurez-cous que la prestation de service est modélisée de bout en bout pour vous assurer que les utilisateurs peuvent réellement tirer parti du service offert. </br>
 +
Parcourez la carte des processus métier étape par étape pour vous assurer que tous les points/nœuds au sein du processus se comportent comme prévu, entraînant le résultat escompté.</br>
 +
Assurez-vous que tous les points/nœuds du processus sont optimisés.</br>
 +
Créez tous les scénarios positifs et négatifs possibles qui peuvent éventuellement se produire. </br>
 +
Ensuite, passez en revue différents scénarios possibles pour vous assurer que le service est toujours fourni correctement et efficacement.</br>
 +
 
 +
    <b>Comment démontrer que le projet remplit ce cadre :</b>
 +
      * Résumer la livraison de valeur au client à travers l'écosystème d'affaires de l'architecture et la contribution de chaque partie prenante à la valeur
 +
    <b>Outils :</b>
 +
      * Carte des processus métier
 +
      * Évaluation de l'impact sur l'entreprise
 +
      * Flux de valeur et cartographie de la valeur
 +
</br>
 +
 
 +
=== Architecte axé sur les résultats et stratégiquement aligné sur le Ministère et le gouvernement du Canada ===
 +
 
 +
==== * Déterminer les services opérationnels, les résultats et les stratégies du Ministère et du GC qui seront abordés ====
 +
 
 +
Pour s’assurer que le gouvernement du Canada offre le meilleur service à ses citoyens, les services fournis doivent être cohérents, c’est-à-dire. le travail effectué par chaque ministère doit se compléter afin d’éviter les chevauchements et d’assurer la continuité du service d’un ministère à l’autre.</br>
 +
Pour qu’un service soit significatif, il doit être lié au moteur de la raison pour laquelle le service est requis et au résultat attendu d’un mandat ministériel.</br>
 +
Le service peut avoir une incidence directe ou indirecte sur le mandat, mais il faut justifier les besoins du service par rapport au mandat réel du ministère.
 +
 
 +
    <b>Comment démontrer que le projet remplit ce cadre:</b>
 +
    * Décrire les stratégies du GC et du ministère que l’architecte aligne et/ou implémente
 +
    * Décrire la contribution de l’architecture à la réalisation des résultats appropriés de la stratégie
 +
    <b>Artifacts:</b>
 +
    * Conduisent
 +
    * Résultats (intimidants et ultimes)
 +
    * Services aux opérationnel (externe)
 +
</br>
 +
 
 +
==== * Établir des mesures pour les résultats opérationnels déterminés tout au long du cycle de vie d’un investissement ====
 +
 
 +
Une fois que nous savons à quel résultat un service est lié et s'il affecte ou non directement le résultat attendu, nous devons être en mesure de justifier l'effort requis pour créer le service par rapport au résultat exercé par le service.</br >
 +
Nous avons besoin d'un moyen de quantifier l'impact de ce service / d'établir une métrique pour ce service. </br>
 +
Il s'agit d'une étape importante pour garantir que nous pouvons hiérarchiser correctement les efforts pour identifier et créer le bon service qui est de haute priorité avec le budget alloué.</br>
 +
 
 +
    <b>Comment démontrer que le projet remplit ce cadre :</b>
 +
      * Quelles sont les mesures utilisées pour s'assurer que les résultats sont atteints
 +
      * Quelles données sont requises pour les métriques et identifier comment les lacunes dans les données seront comblées.
 +
    <b>Outils :</b>
 +
      * Flux de valeur (mesurer les KPI liés aux bénéfices, aux résultats et aux objectifs)
 +
</br>
 +
 
 +
==== * Traduire les résultats opérationnels et la stratégie en répercussions sur les capacités opérationnelles dans le modèle des capacités opérationnelles du GC pour établir un vocabulaire commun entre les organisations, le développement et les opérations ====
 +
 
 +
Une fois que nous avons compris les résultats et la stratégie pour y parvenir, nous devons les traduire en implications en termes de capacités commerciales. Historiquement, le Business Capability Model est un vocabulaire commun entre l'entreprise, le développement et l'exploitation.</br>
 +
Lorsque le plan véhiculé est compris par l'aménagement et l'exploitation, il sera plus facile d'obtenir le système requis. </br>
 +
Avoir une communication ouverte entre les différentes équipes aide également à obtenir la bonne solution qui correspond étroitement aux besoins de l'entreprise.</br>
 +
 
 +
    <b>Comment démontrer que le projet remplit ce cadre :</b>
 +
      * Décrire les capacités commerciales impliquées dans la réalisation de chaque résultat
 +
    <b>Outils :</b>
 +
      * Évaluation de l'impact sur l'entreprise
 +
      * BCM départemental
 +
      * GC BCM (correspondance à D BCM)
 +
      * Flux de valeur
 +
 
 +
=== Promotion de l’habilitation horizontale de l’entreprise ===
 +
 
 +
==== * Repérer les possibilités de rendre possibles des services opérationnels horizontaux à l’échelle du GC et d’offrir une expérience cohésive aux utilisateurs et aux autres intervenants ====
 +
 
 +
Dans la création de tout service, nous devons toujours revenir en arrière pour penser aux utilisateurs/parties prenantes. Se mettre à la place des utilisateurs/intervenants. Si nous sommes à l'extrémité de réception du service, quel genre d'expérience obtenons-nous lorsque nous essayons d'obtenir le service. L'utilisateur a-t-il besoin de savoir où obtenir des services associés, ou pouvons-nous lui fournir un service transparent, un service cohérent ? Comment offrir une bonne expérience aux utilisateurs / parties prenantes ? </br>
 +
Nous devons commencer à penser davantage au niveau de l'entreprise, en commençant d'abord au niveau du département. Comment pouvons-nous activer ce service dans tout le département ? Y a-t-il une possibilité de réutiliser ce que nous avons dans d'autres domaines du département ? Que devons-nous faire pour tirer parti de ce processus ? </br>
 +
Nous devons nous connecter à une communauté de pratiques, à un réseau d'expertise ou à d'autres groupes de travail afin d'échanger des informations, comprendre les différents obstacles rencontrés par les autres, tirer des leçons des expériences des autres, partager les leçons apprises, apprendre des autres comment ils surmontent des obstacles dans leur travail, partagez vos solutions avec les autres. </br>
 +
 
 +
    <b>Comment démontrer que le projet remplit ce cadre :</b>
 +
    * Résumer les opportunités départementales / GC où l'architecture pourrait être réutilisée
 +
    * Résumer les architectures départementales/GC qui ont un impact ou influencent la capacité de l'utilisateur à vivre une expérience cohérente
 +
        (quels sont les plans pour garantir que l'utilisateur a une expérience cohérente à travers ces architectures et l'écosystème)
 +
    <b>Outils :</b>
 +
    * Capacité d'affaires
 +
    * Modèle de flux de valeur départemental
 +
    * Projets à Value Stream Script
 +
</br>
 +
 
 +
==== * Réutiliser les capacités opérationnelles, les processus et les solutions d’entreprise communs provenant de l’ensemble du gouvernement et du secteur privé ====
 +
 
 +
S'il existe des capacités, des processus ou une solution d'entreprise pouvant être utilisés pour créer le service, par ex. peut-être que lors de l'échange d'informations provenant de groupes de travail, de communautés de pratiques, d'ateliers ou même de travaux avec des secteurs privés, qui ont fait leurs preuves, devrions-nous envisager de les utiliser avant d'inventer les nôtres. </br>
 +
Cela permettra d'optimiser le temps nécessaire à la construction de l'approche ou de la solution. Plutôt que d'avoir à prouver que le concept ou la solution fonctionne réellement, utilisez ceux qui ont fait leurs preuves. </br>
 +
 
 +
    <b>Comment démontrer que le projet remplit ce cadre :</b>
 +
      * Décrire le plan et l'approche pour normaliser la réalisation de la capacité commerciale afin qu'elle puisse être réutilisée au sein du ministère et du GC
 +
    <b>Outils :</b>
 +
      * Projets à valoriser Stream Script
 +
      * Carte thermique des capacités commerciales
 +
</br>
 +
 
 +
==== * Publier en mode ouvert tous les processus, les capacités et les solutions d’entreprise communs réutilisables pour que les autres puissent élaborer et tirer parti de services d’entreprise horizontaux cohérents ====
 +
 
 +
Pour en revenir au point précédent sur la réflexion au niveau de l'entreprise, l'une des façons d'activer un service que nous construisons dans l'ensemble du GC est de le faire publier en public pour que les autres ministères puissent le voir et le réutiliser. Alors et seulement nous pouvons créer des services d'entreprise horizontaux cohérents pour créer une expérience cohérente pour les utilisateurs / parties prenantes. </br>
    +
    <b>Comment démontrer que le projet remplit ce cadre :</b>
 +
      * Décrire le plan pour permettre à d'autres organisations du secteur public de réutiliser la capacité commune
 +
    <b>Outils :</b>
 +
      * Carte thermique des capacités commerciales
 +
      * Projets à Value Stream Script
   −
=== Architecture opérationnelle ===
  −
L’architecture opérationnelle est un aspect essentiel à la réussite de la mise en œuvre de l’architecture cible de l’écosystème intégré du GC. La stratégie architecturale préconise une approche pangouvernementale où les TI sont harmonisées avec les services opérationnels et les solutions sont fondées sur des composantes réutilisables mettant en œuvre des capacités opérationnelles afin d’offrir une expérience utilisateur cohérente. Par conséquent, il est essentiel de bien comprendre les services aux entreprises, les besoins des intervenants, les possibilités d’améliorer la cohésion et les possibilités de réutilisation à l’échelle du gouvernement. Par le passé, ces éléments n’étaient pas une priorité. On s’attend à ce que la culture et les pratiques en matière de TI doivent changer pour que l’architecture opérationnelle, en général, et ces éléments soient une priorité.
  −
{| class="wikitable"
  −
|'''Conception entièrement numérique des services pour répondre aux besoins des utilisateurs du gouvernement du Canada et des autres intervenants'''
  −
|
  −
* Identifier clairement les utilisateurs internes et externes et les autres intervenants et leurs besoins dans le cadre de chaque politique, programme et service opérationnel;
  −
* Inclure les exigences de la politique qui s’appliquent à des utilisateurs en particulier et à d’autres groupes d’intervenants, comme l’accessibilité, l’analyse comparative entre les sexes plus et les langues officielles, dans la création du service;
  −
* Effectuer une évaluation de l’incidence algorithmique (EIA) pour appuyer les activités d’atténuation des risques lors du déploiement d’un système décisionnel automatisé conformément à la Directive sur la prise de décisions automatisée;
  −
* Modéliser la prestation de services opérationnels du début à la fin afin d’assurer la qualité, de maximiser l’efficacité et d’optimiser les gains d’efficience dans tous les canaux (p. ex., processus allégé).
  −
|-
  −
|'''Architecte axé sur les résultats et stratégiquement aligné sur le Ministère et le gouvernement du Canada'''
  −
|
  −
* Déterminer les services opérationnels, les résultats et les stratégies du Ministère et du GC qui seront abordés;
  −
* Établir des mesures pour les résultats opérationnels déterminés tout au long du cycle de vie d’un investissement;
  −
* Traduire les résultats opérationnels et la stratégie en répercussions sur les capacités opérationnelles dans le modèle des capacités opérationnelles du GC pour établir un vocabulaire commun entre les organisations, le développement et les opérations.
  −
|-
  −
|'''Promotion de l’habilitation horizontale de l’entreprise'''
  −
|
  −
* Repérer les possibilités de rendre possibles des services opérationnels horizontaux à l’échelle du GC et d’offrir une expérience cohésive aux utilisateurs et aux autres intervenants;
  −
* Réutiliser les capacités opérationnelles, les processus et les solutions d’entreprise communs provenant de l’ensemble du gouvernement et du secteur privé;
  −
* Publier en mode ouvert tous les processus, les capacités et les solutions d’entreprise communs réutilisables pour que les autres puissent élaborer et tirer parti de services d’entreprise horizontaux cohérents.
  −
|}
      
</multilang>
 
</multilang>
Retrieved from "https://wiki.gccollab.ca/Special:MobileDiff/44695...62190"