Les gouvernements deviennent agiles à la FISC 2018

Publié le 23 avril 2018 en Croissance économique et développement

La lenteur et la régularité gagnent parfois la course. Il y a quelque chose à dire sur le contrôle des "meilleures pratiques" dans les institutions. La difficulté avec les soi-disant "meilleures pratiques" des gouvernements est que la plupart d'entre elles ont été développées pour résoudre des problèmes que vous n'avez pas, de manière à ce que vous ne puissiez pas les utiliser. Vous devez trouver des bonnes pratiques émergentes qui résolvent les problèmes que vous avez, de manière à ce que vous puissiez les utiliser.
Cette notion a été mise en évidence lors des ateliers sur la gouvernance organisés dans le cadre du Comité de pilotage international de FreeBalance à Miami le mois dernier. Les méthodes traditionnelles de gestion de projet se sont révélées inefficaces pour les grands projets gouvernementaux. Mise en œuvre des technologies de l'information et réforme de la gestion des finances publiques. C'est particulièrement vrai lors de la mise en œuvre de systèmes de planification des ressources de l'entreprise (ERP) dans les administrations publiques. Bien que l'utilisation de logiciels d'entreprise conçus pour les pouvoirs publics, comme le Government Resource Planning (GRP), améliore les taux de réussite, il faut aller plus loin.

L'héritage, c'est ce que l'héritage fait

Les technologies patrimoniales font l'objet de nombreuses discussions au sein des administrations publiques. En moyenne, les coûts d'exploitation et de maintenance des technologies de l'information sont plus élevés dans les administrations que dans les entreprises. Le problème n'est pas tant la technologie patrimoniale que le fait qu'elle ne soit plus utilisée. la réflexion sur l'héritage. De nombreux gouvernements passent d'une technologie obsolète à une technologie patrimoniale à un moment où les entreprises se tournent vers l'informatique dématérialisée avec des applications SaaS facilement adaptables et peu coûteuses. Nous pensons qu'il y a quelque chose les soi-disant "meilleures pratiques" en matière d'informatique dans l'administration sont fondamentalement erronées.
En commençant par considérer le PRV comme une technologie de l'information, plutôt que comme une réforme et une modernisation. Ce n'est pas de l'informatique, c'est de la transformation.
Nous avons exploré ces pratiques informatiques héritées du FISC.

La plupart des mises en œuvre de la PRG se concentrent sur la réduction des risques par le biais de la documentation et de la séparation des préoccupations.
Une pratique trop documentée
La principale stratégie d'atténuation des risques dans le cadre de la réflexion sur l'héritage est la documentation : documenter le projet, documenter l'état actuel, documenter l'état futur, documenter le plan de test, documenter le plan de projet, documenter les procès-verbaux de chaque réunion, documenter chaque étape de l'acceptation par l'utilisateur.....
Vous voyez ce que je veux dire.
Les prestataires se transforment en auteurs et en rédacteurs. La complexité de la documentation conduit à se concentrer sur les pratiques obsolètes des systèmes précédents. Davantage de code est personnalisé. L'accent mis sur la conformité signifie que les prestataires s'ancrent dans les contrats. Les projets divergent des besoins.
De plus, le temps nécessaire pour documenter, comprendre et approuver les documents entraîne des retards. Les retards entraînent une résistance accrue au changement. En effet, les documents sont une mauvaise représentation des progrès réalisés. Les gestionnaires de projets gouvernementaux hésitent à approuver les étapes parce que la documentation complexe est abstraite.
Ces pratiques signifient qu'il est certain que les mises en œuvre ne répondront pas aux besoins initiaux, qu'elles ne seront pas livrées dans les délais ou qu'elles ne coûteront pas le budget initial. Nombre d'entre elles ne parviennent pas à répondre à ces trois critères.
En outre, les analyses rétrospectives des projets suggèrent souvent qu'il aurait fallu rédiger davantage de documentation.
Séparation des préoccupations
L'idée était d'utiliser ce que l'on appelle les "meilleures pratiques". Par exemple : séparer les fabricants des intégrateurs, séparer en silos le budget, les finances, les achats, les ressources humaines et les questions fiscales.
La séparation des préoccupations signifie une mise en œuvre en dehors de la vue d'ensemble, avec des incitations différentes pour les fournisseurs, un manque d'intégration, sans couverture budgétaire complète - de nombreuses applications de dépenses fonctionnent complètement en dehors de la comptabilité d'engagement.
L'approche séparée a empêché de nombreux gouvernements d'avoir une vision holistique de l'adéquation entre les logiciels et la réforme attendue, elle a créé des incitations perverses pour les fournisseurs de services de conseil, les fabricants de logiciels, les consultants en matière de propositions et le personnel informatique.
L'absence de vision globale et d'intégration signifie que les systèmes répondent rarement aux objectifs à long terme. Le destin est un cycle de remplacement des systèmes par de nouveaux systèmes qui ne répondent pas non plus aux besoins à long terme. Comme le décrit un poste précédent:
La gestion de projet traditionnelle part du principe que les projets sont compliqués, mais prévisibles. La construction d'un pont, par exemple, peut être compliquée et nécessiter des compétences techniques en matière d'ingénierie. Les ingénieurs comprennent la résistance des matériaux, la manière de construire dans différentes conditions de sol et de gérer les changements de température. L'avancement du projet peut être prédit sur la base de projets similaires. Bien entendu, les progrès réels sont très faciles à observer.
Les mises en œuvre de logiciels d'entreprise sont complexes. Les projets de planification des ressources gouvernementales (PRG) sont transformationnels. Des experts en finances, en ressources humaines ou en passation de marchés publics sont nécessaires. Il en va de même pour les experts en informatique. Les utilisateurs ont besoin d'une formation spéciale. (Les utilisateurs de Bridge n'ont pas besoin d'une nouvelle formation). Plus important encore, les projets de planification des ressources gouvernementales transforment et automatisent les processus, ce qui provoque une forte résistance au changement.

Projets informatiques gouvernementaux en cascade

Les techniques en cascade supposent que toute la planification peut être réalisée avant que le logiciel ne soit adapté. On suppose que le résultat final du logiciel répondra aux attentes grâce à un travail de conception rigoureux.
Les projets de réforme de l'informatique et de la gestion des finances publiques sont considérés comme prévisibles. Les pratiques traditionnelles sont imposées aux entrepreneurs afin de réduire les risques perçus. Notre analyse des projets de FreeBalance, des projets d'autres entreprises et de la documentation sur la gestion de projet et la réforme de la gestion des finances publiques nous a amenés à conclure que les pratiques en cascade augmentent considérablement les risques liés au projet.
Le travail de conception, qui consiste en une analyse de la situation actuelle et de la situation future dans les documents relatifs aux exigences logicielles, prend souvent jusqu'à un an.

• L'accent mis sur la documentation ancre les mises en œuvre sur le fonctionnement des systèmes existants, plutôt que sur les objectifs des pouvoirs publics.
• L'accent mis sur la documentation entraîne une personnalisation inutile du code
• La focalisation sur les solutions inclut des "meilleures pratiques" inappropriées provenant de différents contextes, déconnectant les projets des problèmes à surmonter.
• L'accent mis sur les contrats permet de mettre l'accent sur les listes de contrôle fonctionnelles, au détriment des besoins non fonctionnels tels que la facilité d'utilisation et la facilité de gestion.

Les pouvoirs publics constatent souvent que l'analyse traditionnelle des besoins ne permet pas de mettre en évidence des exigences exhaustives. Cela s'explique par le fait que l'analyse fonctionne dans le vide, sans un contexte plus large de la manière dont les tâches gouvernementales sont réellement accomplies, des problèmes qui doivent être résolus et des pratiques émergentes qui pourraient être mises à profit pour le changement.

Soyons réalistes : depuis des décennies, les gouvernements mettent en œuvre des logiciels commerciaux pour répondre à leurs besoins en matière de GRP et de PFM. Les pratiques héritées du passé ont entravé le succès. Cela se produit à un moment où les gouvernements sont mis au défi de se transformer numériquement. Mettre en œuvre des systèmes mobiles centrés sur le citoyen. Améliorer la prestation de services grâce au numérique. Intégrer les réseaux sociaux. Mettre en œuvre la blockchain et l'intelligence artificielle.

Les gouvernements sont confrontés à un point d'inflexion stratégique. Les pratiques dominantes en matière d'informatique gouvernementale limitent la réussite de la transformation numérique.

L'évolution agile du gouvernement

Les gouvernements, comme les grandes entreprises, exploitent de nombreux systèmes informatiques. Les préoccupations légitimes en matière de sécurité, de performance, de qualité et de fiabilité signifient que les gouvernements ont besoin d'une gouvernance informatique solide. Le passage d'une mise en œuvre en cascade à une mise en œuvre agile ne doit pas compromettre la gouvernance informatique. Les Groupe Gartner,  par exemple, recommande une bimodal approche de la technologie de l'information : "La bimodalité consiste à gérer deux styles de travail distincts mais cohérents : l'un axé sur la prévisibilité, l'autre sur l'exploration. Le mode 1 est optimisé pour les domaines qui sont plus prévisibles et bien compris. Il se concentre sur l'exploitation de ce qui est connu, tout en rénovant l'environnement existant pour l'adapter au monde numérique. Le mode 2 est exploratoire, expérimente pour résoudre de nouveaux problèmes et est optimisé pour les domaines incertains..”

De nombreux observateurs estiment que le bimodal ne va pas assez loin. L'analyste Dion Hinchcliffe, par exemple, affirme que "le monde réel de la technologie et les activités qui la font fructifier ne peuvent pas être compartimentés dans une structure duale." Une approche multimodale peut s'avérer plus fructueuse. Ou en envisageant des processus plus agiles pour la mise en œuvre et des processus plus rigides après la mise en œuvre.

L'agilité dans le monde réel

Comment les géants de l'internet développent-ils des solutions innovantes ? Quels sont les modèles pertinents pour les gouvernements ? Existe-t-il des modèles de réussite spécifiques aux gouvernements ? Telles sont les questions que nous avons posées après avoir diagnostiqué les problèmes de mise en œuvre du GRP et de l'ERP dans le secteur public. Les modèles de réussite ont conduit à la mise à jour de notre méthodologie agile, A-i³+qM^TM.

Nous avons constaté que nos expériences positives de mise en œuvre s'alignaient sur les techniques agiles pratiquées par les entreprises Internet innovantes. Elles s'alignent également sur les pratiques émergentes en matière de développement des pays. Les modèles de réussite s'articulent autour de quatre dimensions :

• Intégration des produits: Les méthodologies de mise en œuvre de GRP et d'ERP sont traditionnellement séparées des méthodologies de développement de produits. De plus, le code des logiciels COTS est rarement adapté par le fabricant pour répondre aux besoins du client. Un code personnalisé orphelin est développé à la place. FreeBalance intègre la mise en œuvre et le développement de produits depuis des décennies. Le code personnalisé complète notre logiciel COTS. Cette approche fonctionne de la même manière que DevOpsun processus de développement logiciel agile.
• Ateliers: Le contexte est essentiel à la réussite d'une réforme. Nous avons découvert que les documents et les rapports racontent rarement l'histoire de la réforme du secteur public. C'est en faisant participer les gens qu'on le découvre. Nous avons également découvert que les fonctionnaires n'étaient pas exposés aux contextes de la réforme : des pratiques bonnes et appropriées plutôt que des "meilleures pratiques" irréalistes ou des pratiques très médiocres héritées du passé. L'engagement des utilisateurs et des équipes de projet était nécessaire. FreeBalance a développé des ateliers d'engagement en tant que maigre pour communiquer le contexte. En outre, nous avons tiré des enseignements de l'approche émergente du "canevas", comme le Modèle d'entreprise (Business Model Canvas)L'objectif est de créer des structures d'ateliers spécifiques à chaque gouvernement.
• Storyboards: La structure des spécifications de FreeBalance a été révisée en 2008 pour refléter l'approche des composants réutilisables, que nous appelons "entités gouvernementales". Cela inclut l'articulation de l'entité et des paramètres de l'entité. Ces paramètres permettent une configuration massive. L'interaction entre les entités est définie. En effet, les entités sont réutilisées entre les applications. Tout cela est parfaitement logique pour nos développeurs de produits, mais reste abstrait pour les experts en gestion des finances publiques. Nous avons développé une approche de storyboard pour faciliter le développement des spécifications en utilisant une approche de la réflexion sur la conception. Cette méthode a été étendue dans notre méthodologie agile actualisée. (Démonstration lors de Ateliers FISC 2018.)
• Gestion du changement: La gestion du changement organisationnel est particulièrement difficile dans les administrations publiques. Nous avons appris de la L'approche de l'adaptation itérative pilotée par les problèmes (PDIA) de l'Agence européenne pour la sécurité et la santé au travail (ESA). École Kennedy de Harvard. La PDIA va bien au-delà de la gestion du changement. La technique a une approche idéale, axée sur le gouvernement, de l'identification des parties prenantes (agents) et des approches en matière de communication. Nous avons également découvert que la valeur du changement est rarement communiquée de manière efficace aux agents de changement potentiels ou aux futurs utilisateurs. Nous nous sommes rendu compte que la Canevas de proposition de valeur est un outil idéal. (Démonstration lors de Ateliers FISC 2018.)

A-i³+qM^TM s'appuie sur des modèles de réussite pour une méthodologie agile complète qui comprend également :

• GESCED: Une version adaptée de la stratégie d'entreprise  PESTLE (politique, économique, social, technologique, juridique, environnemental) pour le contexte gouvernemental. (Démonstration lors de Ateliers FISC 2018.)
• Agile: Une version adaptée de Kanban et Scrum pour un développement itératif
• Faire du développement différemment: Une approche agile, avec une manifeste, pour le développement progressif des gouvernements, qui comprend le PDIA

Résultats de la mise en œuvre de la méthode agile

A-i³+qM^TM couvre l'ensemble du cycle de vie du projet, en commençant par notre proposition aux gouvernements. Nous évaluons les facteurs de risque en amont, tels que les contraintes du programme, les contradictions entre les exigences et les mauvaises pratiques. Cela détermine notre approche du risque et éclaire la négociation du contrat.

La clé A-i³+qM^TM La caractéristique du projet est l'itération des processus de base qui sont livrés en série dans le cadre d'une cascade. Ces processus parallèles commencent par une formation obligatoire au produit. Les équipes de projet gouvernementales doivent voir les capacités du système en action. Cela permet d'organiser des ateliers de configuration et de personnalisation. La capacité est construite en parallèle. Les configurations sont approuvées lorsqu'on les voit à l'œuvre. Il en va de même pour le code personnalisé. Les progrès sont visuels.

A-i³+qM^TM accélère la mise en œuvre en ancrant les projets sur les aspirations de gain et sur les capacités du nouveau système. Configuration n'a pas besoin de beaucoup de documentation, mais seulement d'un plan de sortie de la suite de responsabilité FreeBalance. Le développement personnalisé le processus réduit la complexité pour les experts de la GFP afin d'articuler et de valider les besoins.

A-i³+qM^TM Le processus de développement personnalisé comprend

• Le personnel des services sur site de FreeBalance élabore des scénarios et des cas d'utilisation de manière interactive avec les clients.
• L'équipe de gestion des produits de FreeBalance valide ces données à l'aide de ses connaissances technologiques et identifie d'autres moyens d'étendre les entités gouvernementales à d'autres exigences de la carte des composantes de la PFM.
• Les storyboards et les cas d'utilisation validés sont approuvés par les clients.
• Le personnel chargé de la gestion des produits FreeBalance élabore les spécifications
• Le développement des produits FreeBalance valide les spécifications avant de développer le code.
• Le personnel des services sur site de FreeBalance contribue à l'assurance qualité pour s'assurer que le résultat répond aux besoins du pays.
• Les tests d'acceptation par le client valident l'utilisation du code en production (ou démontrent la nécessité d'adapter les spécifications).

La répétabilité est un défi majeur pour toute méthodologie. A-i³+qM^TM comprend des outils de processus pour répétabilité.

• Toile: Grand espace de travail visible, généralement un mur ou un grand tableau blanc, qui peut être déployé en ligne, en suivant une série d'étapes d'atelier pour le brainstorming et la prise de décision.
  Il peut également être déployé en ligne
• Conseil d'administration: Grand espace de travail visible, généralement un mur ou un grand tableau blanc, qui peut être déployé en ligne, représentant de manière dynamique les activités en cours.
  Il peut également être déployé en ligne
• Plans d'exécution: Description d'une configuration FreeBalance comprenant l'articulation des règles de gestion et des flux de travail, le développement personnalisé spécifique au pays, les rapports et les interfaces.
  Décrit tout développement personnalisé spécifique au pays
• Modèles: Modèle de document pour la création d'artefacts de projet

Annexe : A-i³+qM^TM Description

Les caractéristiques de la A-i3+qM sont :

• Accéléré en éliminant le plus grand nombre possible de processus en cascade qui conduisent à des problèmes de projet. Il s'agit notamment de la documentation inutile et des plans de projet détaillés, au profit d'ateliers et d'étapes de processus courtes. La taille des équipes est réduite afin de faciliter la communication avec les clients et de réduire les frais de coordination.
• Intégré par le biais d'une méthodologie unique pour soutenir le développement et la mise en œuvre des services. Cette méthodologie est intégrée aux exigences du client par le biais des processus centrés sur le client. Cela permet d'assurer la transparence entre le personnel du client, les responsables de la mise en œuvre et l'équipe de développement. Les équipes de mise en œuvre et de développement de produits sont intégrées selon les pratiques DevOps.
• Itératif d'être réactif aux changements des clients et de la mise en œuvre en utilisant des phases. La méthodologie s'appuie sur le meilleur des méthodes éprouvées de développement de logiciels et de services "allégés", avec des ateliers, des itérations courtes, des récits d'utilisateurs, des jalons et la possibilité de montrer les progrès accomplis. Ces techniques sont étendues au-delà de l'organisation de développement aux services de mise en œuvre, ce qui permet de tirer parti des gains de productivité et de la capacité à réagir aux exigences des clients.
• Mise en œuvre-Cette méthodologie est axée sur la réussite de la mise en œuvre par le client, plutôt que sur une version du logiciel qui atteint des objectifs internes et arbitraires. Cette méthodologie est axée sur la réussite de la mise en œuvre par le client, plutôt que sur une version logicielle qui atteint des objectifs internes ou arbitraires. La mise en œuvre et le développement du produit sont gérés par un bureau de gestion de programme.
• Qualité L'approche de FreeBalance garantit que le logiciel est publié et pris en charge conformément aux bonnes pratiques des produits commerciaux sur étagère (COTS) avec des tests d'unité, de système, de stress et de régression. La qualité est intégrée à la mise en œuvre, FreeBalance effectuant des tests basés sur les environnements des clients.