Les DPIs et DPFs sont essentiels pour faire de la transformation numérique une réalité

Dernière modification: 2020-11-25

Dans ce blogue, nous suggérons que les dirigeant principaux de l’information (DPI) et les dirigeants principaux des finances (DPF) sont essentiels pour amener une vision de transformation numérique en une réalité. Bien que la transformation numérique affecte de beaucoup les opérations d’affaires, si les changements technologiques ne peuvent se produire, cette vision ne restera qu’un rêve et ne se manifestera pas. Nous montrerons à quel point les DPF sont essentiels pour permettre à la technologie de répondre plus rapidement aux changements continus de l’entreprise, et comment l’infonuagique et DevOps sont des opportunités qui ne peuvent pas être négligées.

Note : Ce blogue fera le lien vers des documents internes de EDSC, qui ne sont malheureusement accessibles qu’au sein du réseau de EDSC.

Ce qu’implique la transformation numérique

Le 1er avril 2020, la Politique du Conseil du Trésor (CT) sur les services et le numérique est entrée en vigueur. Elle sert “d’ensemble intégré de règles qui décrit la façon dont les organisations du gouvernement du Canada gèrent la prestation de services, l’information et les données, la technologie de l’information et la cybersécurité à l’ère du numérique”. La politique soutient le mandat de la ministre du Gouvernement numérique et est guidée par un engagement envers les principes directeurs et pratiques exemplaires des Normes numériques du gouvernement du Canada.

Comme les exigences de la politique visent les administrateurs généraux, nous examinons la directive qui y est associée pour les exigences visant les agents responsables de mener les fonctions particulières (c.-à-d. la GI/TI, le service et la cybersécurité). Voici quelques statistiques réalisées par l’équipe de la stratégie TI (lien vers les données sources) :

Agent	% des exigences	Nbr d'exigences des 4 procédures obligatoires
DPI (et DPD*)	84%	229
Services	10%	0
Cybersécurité	6%	74

* Dirigeante principale des données

En mettant ainsi l’accent sur les DPI et les DPD, le CT reconnaît officiellement la nature omniprésente de la technologie dans la prestation de services aux Canadiens. Étant donné que les DPI et les DPD sont responsables d’un si grand nombre d’exigences, nous affirmons qu’ils doivent également être en mesure de déterminer comment les investissements technologiques doivent être gérés (un domaine historiquement attribué aux DPF).

Les élus reconnaissent maintenant que la technologie est au cœur de la prestation de services. Cela signifie que pour que les décideurs politiques aient un impact sur les Canadiens, ils devront passer par la prestation de technologies. Si la technologie n’est pas suffisamment réactive, le décalage entre l’élaboration des politiques et la prestation des services aura un impact direct sur la capacité des ministères à remplir leur mandat (ce qui s’est produit dans le passé et a fait la une des journaux). Les décideurs politiques à la recherche de données pour appuyer leurs décisions fondées sur des faits (c’est-à-dire la rétroaction des utilisateurs de services) les trouveront stockées dans des bases de données, gérées par des logiciels.

À EDSC, nous trouvons l’explication ci-haut articulée comme 2^ème objectif du programme de Modernisation du versement des prestations (MVP): Souplesse des politiques.

Nous voulons examiner de plus près cette relation avec la technologie, et comment les choses ont changé ces dernières années qui nous offrent de nouvelles opportunités (indice : nous parlerons d’Infonuagique et de DevOps).

Comment gérons-nous les investissements technologiques

L’utilisation de la technologie est un investissement risqué et coûteux.

Les DPFs examinent la politique du CT sur la planification et la gestion des investissements pour établir la gouvernance de la gestion des investissements “afin d’assurer que ces activités permettent une optimisation des ressources et démontrent une bonne gestion dans le cadre de la prestation des programmes”. La Directive sur la gestion de projets et programmes est l’un des documents associés à la politique, où l’on trouve les fameux points de contrôle des projets “afin d’obtenir les avantages et les résultats attendus pour les Canadiens”.

Nous réduisons les objectifs de ces instruments de politique financière aux deux suivants :

1. Gérer les risques
2. Placer les investissements là où il y a des avantages

Nous voulons examiner de plus près #1 surtout lorsque notre Plan ministériel 2019-2020 indique que “Le Ministère est conscient que l’un des plus grands risques auxquels il est confronté est celui de ne pas prendre de risques.”¹

La méthode actuelle de gestion des investissements technologiques par points de contrôle vise un degré élevé de prévisibilité future. Avant que les travaux sur les logiciels puissent commencer, nous cherchons à clarifier les exigences et l’effort nécessaire pour les satisfaire. Cela prend généralement forme d’une production de plusieurs documents, regroupés en un plan global avant que l’autorisation d’exécution ne soit obtenue. Il fut un temps où cela était parfaitement logique car il était coûteux et long de se procurer des serveurs, de coder les modifications de logiciels dans un langage procédural, de tester ces modifications sur des serveurs de test dédiés (parfois partagés avec d’autres projets et, donc, les risques de collision entre ses projets devaient aussi être gérés), de graver les logiciels mis à jour sur un disque avec les procédures d’installation pour que quelqu’un d’autre les exécute (afin de respecter la séparation des tâches), et de s’attendre à des temps d’arrêt lorsque ces modifications sont appliquées. Si un client changeait d’avis pendant cette phase d’exécution, l’impact sur le projet était élevé.

Plus le projet est important, plus éloigné est l’avenir qui nous est requis de prévoir. Cette approche s’accompagne de quelques défis :

1. Une prévision précise est extrêmement rare : Il existe des statistiques et des rapports concernant les faibles taux de réussite des gros projets ². Bien que nous pensions qu’il ne s’agit pas nécessairement de taux de réussite. Il s’agit de la réalité que le changement est inévitable, qu’il est extrêmement rare de disposer d’une telle prévision et qu’il est presque impossible de planifier aussi loin dans l’avenir.

2. Une analyse de rentabilisation est considérée comme une attente, plutôt qu’une hypothèse : La réalisation des avantages à la fin d’un projet n’est pas une chose sûre. Un projet peut être livré dans les délais, dans le respect du budget, conformément aux exigences, mais produire des résultats négatifs. Plus longtemps l’organisation s’immobilise dans un projet, plus grand est le risque de s’immobiliser dans une idée potentiellement mauvaise.

3. Il met les TI dans un état passif : “J’ai besoin des exigences”, est quelque chose que vous avez probablement entendu vos équipes informatiques vous dire. Cela ne devrait pas être surprenant, l’organisation est encadrée pour qu’elle se comporte comme telle. La réponse du gouvernement à la pandémie est une exception à cette déclaration, où le personnel a travaillé de manière créative en temps de crise.

4. La progression est mesurée à l’aide de documents, au lieu de logiciels fonctionnels : Si après 18 mois de travail et 2 millions de dollars dépensés, nous n’avons pas de logiciel fonctionnel à démontrer, considérerions-nous que c’est un bon investissement?

Seuls les projets réussis, en production, permettent à l’organisation d’obtenir les preuves empiriques nécessaires à ses décisions fondées sur des faits.

Opportunités de changement

Le monde numérique comporte un niveau élevé de complexité et d’incertitude. Cela devrait nous inciter à rechercher une approche très différente pour la réalisation des initiatives. Un monde prévisible récompense la planification préalable et l’exécution rigide des plans. Mais un monde complexe et incertain récompense un cycle empirique d’essai, d’observation et de correction ³.

De nouvelles méthodes de développement de logiciels sont disponibles, principalement l’Infonuagique et DevOps, qui nous justifie d’adapter nos méthodes de gestion des investissements. Grâce à elles, les efforts fastidieux d’acquisition de serveurs, de codage, de test et de mise en production mentionnés ci-dessus sont considérablement réduits. Il est possible de tirer parti de cette rapidité, de faire des essais avant de s’engager et d’informer plus précisément les décisions de planification.

La pensée séquentielle classique de la planification, puis de l’exécution, se transforme en une pensée cyclique. La planification et l’exécution deviennent une symbiose où les deux s’informent mutuellement sur des périodes plus courtes.

Le résultat permet l’utilisation de données empiriques pour prendre des décisions de planification. Grâce à l’exécution, nous pouvons informer le prochain horizon de planification de l’initiative. Nous pouvons mesurer les progrès grâce à un logiciel fonctionnel réel, par opposition aux documents de planification qui contiennent souvent de nombreuses hypothèses. Nous pouvons prendre des “décisions [s’appuyant] sur une évaluation de la totalité des coûts du cycle de vie et [démontrer] une optimisation des ressources et une intendance saine”⁴.

Dans le premier exemple ci-dessus (figure 2), nous avons obtenu une version du logiciel après 18 mois. Dans le deuxième exemple (figure 3), nous pourrions avoir obtenu cinq versions dans le même laps de temps (si nous avions décidé de les mettre en production). À chaque itération, le client, le responsable du produit et les équipes produit ont tous appris un peu plus sur les besoins des utilisateurs, la complexité de l’adaptation du logiciel à ces besoins et la dette technique accumulée pendant tout ce temps. Ces informations sont utilisées comme preuves empiriques pour planifier avec plus de précision le prochain cycle d’itération.

Ces itérations rapides de produits sont permis par DevOps (alimenté par les technologies infonuagiques).

Cette possibilité est offerte si nous comprenons d’abord en quoi les logiciels sont différents des autres types d’investissements. Principalement, que le logiciel consiste en un assemblage de nombreux composants⁵, chacun potentiellement capable de fonctionner indépendamment des autres, et qui fournit des services les uns aux autres (on commence alors à voir que les machines sont aussi des utilisateurs). La décomposition de grandes solutions technologiques en parties plus faciles à gérer (qu’elles soient appelées produits ou applications, parfois comparés aux blocs Lego) signifie que le travail de plusieurs équipes peut commencer sans qu’il soit nécessaire d’avoir résolu l’ensemble du casse-tête à l’avance ou de devoir résoudre le problème en une seule pièce. Si vous avez entendu le terme “Monolithe”, c’est ce dont nous nous efforçons de nous éloigner car il entrave notre capacité à réagir rapidement et est trop souvent la cause de collisions entre projets.

La relation symbiotique planification-exécution ci-dessus devrait être autorisée conformément aux exigences suivantes de la directive du CT sur la gestion des projets et programmes :

(favoriser le changement) 4.2.6 Lorsqu’un changement opérationnel est nécessaire afin d’atteindre les résultats opérationnels, s’assurer que la portée des travaux des projets et des programmes comprenne l’ensemble des activités et des extrants requis en vue de concrétiser le changement

(itératifs et Agile) 4.2.8 Appliquer, selon le cas, des méthodes et des principes incrémentiels, itératifs, souples [Agile] et axés sur les utilisateurs pour la planification, la définition et la mise en œuvre du projet

(décisions fondées sur des faits) 4.2.18 Mettre en place, dès le début du projet, un plan des points de contrôle du projet conforme au cadre ministériel qui; (4.2.18.1) documente les décisions qui seront prises à chaque point de contrôle, les éléments probants et les renseignements requis à l’appui des décisions aux points de contrôle, les critères utilisés pour évaluer les éléments probants et la gouvernance des points de contrôle

Actuellement, le CT ne fournit que des directives et lignes directrices concernant la gestion des projets et des programmes, laissant aux ministères le soin d’adapter eux-mêmes les pratiques de gestion de projets à un monde de produits. C’est là que nous constatons un renforcement de la relation DPF - DPI.

L’équipe de stratégie TI de EDSC souhaite trouver d’autres ministères qui se penchent sur les mêmes problèmes, qu’ils s’efforcent de les résoudre ou même qu’ils aient trouvé des solutions.

Quelques travaux en cours à l’EDSC pour favoriser ces opportunités

L’équipe de stratégie TI de EDSC travaille actuellement sur un ensemble de stratégies visant à faire évoluer l’organisation vers une réduction des risques liés à la technologie afin d’accélérer la flexibilité de l’entreprise.

(Documents présentement disponibles en anglais seulement)

1. Target IT Solution Delivery Model: a strategy to move the organization towards same day software deployment in order to dramatically improve service delivery agility.
2. Adopt, Build, Buy: a strategy that seeks to resolve the oversimplification approach of buying or building software.
3. Continuous Improvement: a strategy to transform ESDC into a high-performing organization through the continuous improvement of daily work.
4. Micro-Acquisition (GCDevExchange 2.0): a strategy that seeks to provide the department and suppliers with a lightweight, low dollar value (< $10k) contract amount, acquisition process.

Références