Remédier à l'échec de l'ERP d'un gouvernement : Quand la politique et la technologie s'affrontent class="spip")

Remédier à l'échec de l'ERP d'un gouvernement : Quand la politique et la technologie s'affrontent

Phénix en chute libre ou Phénix en ascension ?

Nouvelles sur le système central de paie du gouvernement du Canada utilisant PeopleSoft ERP, de plus en plus souvent appelé ironiquement le "système de paie".Système de paiement Phoenix"est décourageant. Les CBC rapporte que 228 000 cas subsistaient à la fin du mois de juillet. Des milliers de nouveaux cas ont été ajoutés au cours du mois, ce qui a entraîné une réduction nette de 18 000 cas. Le mois d'octobre a été marqué par une réduction nette de 18 000 cas. Le gouvernement s'était engagé en juin de l'année dernière à résoudre les problèmes avant la fin du mois d'octobre.. Mon fil twitter montre une grande frustration chez les fonctionnaires. Beaucoup se demandent pourquoi le problème ne peut être résolu.
Cette mise en œuvre de l'ERP est devenue très politisée. Les communications du gouvernement sont vagues. La presse politique ne connaît pas la technologie et n'est pas en mesure de poser les bonnes questions. Le public ne sait pas quel est le problème, ou quels sont les problèmes.
Je pense qu'il est grand temps que le gouvernement explique le ou les problèmes technologiques sous-jacents. Sinon, cela conduit à des spéculations sans fin. Le manque de transparence nous laisse supposer que le gouvernement du Canada n'a fait preuve d'aucune compétence dans la gestion du projet Phoenix. J'ai rencontré de nombreux fonctionnaires canadiens spécialisés dans les technologies de l'information qui possèdent d'excellentes compétences en matière de gestion de projet et de connaissances technologiques. Les projets ERP et leur complexité avec des taux de réussite décourageants dans les administrations publiques. Il y a modèles qui ont émergé d'autres échecs d'ERP gouvernementaux : livraison tardive, dépassement de budget, peu d'avantages escomptés - certains projets abandonnés. C'est un vœu pieux que de penser que contrôle ministériel fera renaître magiquement le phénix de ses cendres.
Je vais donc spéculer sur ce qui pourrait être le problème en me basant sur les éléments suivants modèles dans des circonstances similaires, couvrant ces aspects :

  1. Incitations
  2. Qualité
  3. Gestion de projet
  4. Meilleures pratiques
  5. Formation
  6. Technologie ERP
  7. Remplacement
  8. Évolutivité

Je conclurai en m'interrogeant sur les raisons pour lesquelles tout le monde devrait se préoccuper de cette question.

1. Quand les incitations concourent à l'échec des GovTech

L'équipe de projet du gouvernement a reçu des primes en fonction des étapes franchies. Il s'agit d'une incitation toxique à la production. D'une part, elle encourage les fonctionnaires à jouer avec les résultats et, d'autre part, elle crée un mécanisme de pression pour l'approbation des prestataires. Elle crée un environnement dans lequel les la définition du succès peut être compromise. Cela peut conduire les équipes de mise en œuvre à fournir une portée et une qualité qu'elles considèrent comme satisfaisantes, mais pas les utilisateurs.
Les fournisseurs peuvent tirer parti de l'obligation de respecter les délais pour fournir des services de moindre qualité ou moins étendus. Les très grands fournisseurs savent comment tirer parti des contrats. Ils disposent de services juridiques capables de passer au peigne fin les détails des contrats. D'après mon expérience, il y a toujours des écarts entre les exigences de l'appel d'offres et les besoins du gouvernement. Il se peut que l'étendue des fonctions qui ont généré des problèmes n'ait pas été bien formulée. Il peut y avoir un écart important entre l'objectif contractuel légal fixé pour le fournisseur et le besoin réel.
Je soupçonne que les incitations accordées à l'équipe gouvernementale chargée de la mise en œuvre impliquent que la direction comprenait que le projet était risqué. Il me semble que l'approche en matière de passation de marchés a consisté à nier l'échec en faisant appel à un fournisseur unique, PeopleSoft, le principal progiciel de gestion intégrée des ressources humaines, et en veillant à ce que seules les grandes entreprises d'intégration de systèmes puissent répondre aux critères de qualification des vendeurs. C'est la façon de penser "personne n'a jamais été licencié en achetant...".

2. Phoenix est-il assailli par les insectes ?

La manière dont 89 000 cas ont été traités en juin n'est pas claire. J'ai l'impression qu'ils ont été traités par des solutions de contournement dans le système et par des transactions financières en dehors du système. Y a-t-il des bogues dans le système qui génèrent des problèmes ? Si c'est le cas, est-ce dû à des règles de gestion incorrectes ou à certaines fonctions du système ? L'ajout de 71 000 nouveaux cas en un mois implique que les bogues des règles ou des validations qui sont en cause n'ont pas été corrigés.
De nombreuses entreprises d'intégration de systèmes reprochent aux clients une communication incomplète lors de la définition des besoins. Cela semble inconcevable dans le cas présent. Les règles de rémunération du gouvernement du Canada ne sont pas un mystère. Elles sont compliquées mais bien comprises. De nombreuses personnes employées par le gouvernement connaissent ces règles, tout comme de nombreuses personnes du secteur privé. Par exemple, de nombreux ministères et agences gouvernementales ont utilisé le logiciel FreeBalance pour la budgétisation des salaires et le contrôle de la qualité de l'ancien système de paie.

3. Les projets sous tension deviennent des tragédies grecques

La réponse habituelle de la direction aux projets soumis à des contraintes est le renforcement de la surveillance. Le contrôle de la gestion entraîne la multiplication des réunions et des rapports. Elle perturbe le déroulement du projet. Elle augmente la probabilité d'échec, comme dans une tragédie grecque, en essayant d'éviter l'échec. Il est inévitable qu'Œdipe tue son père et que son projet ERP ne soit pas livré à temps.
La gestion de projet en situation de stress conduit souvent à suivre le jugement de la personne la moins qualifiée sur le plan fonctionnel et technique au sein de l'équipe, à savoir la personne la plus âgée. La voix du personnel techniquement et fonctionnellement compétent est souvent noyée dans la surveillance, la paperasserie et les comités.
La tragédie des commissions est qu'elles rendent compte à d'autres commissions. Les décisions sont de plus en plus souvent prises par des personnes qui manquent de connaissances et de contexte.
La réponse habituelle des comités est la suivante : plus de personnel, plus d'heures de travail. Le personnel supplémentaire est ajouté trop tard dans le projet. Ce personnel n'arrive jamais à se mettre au diapason, interrompant constamment la productivité. Pendant ce temps, le fait de travailler plus longtemps aggrave les problèmes de qualité, introduit de nouveaux bogues et paralyse le projet.

4. Quand les "meilleures pratiques" sont les pires

Les marchés publics reposent souvent sur la notion de délais prévisibles alignés sur le cycle budgétaire. Les contrats publics types pour les logiciels d'entreprise comportent des étapes définies sur la base de projets antérieurs utilisant des technologies différentes. Les paiements sont effectués à ces étapes définies. Tout projet dont les étapes ne sont pas strictement définies est considéré comme risqué. Cela signifie que la plupart des gouvernements évitent d'utiliser les méthodologies agiles dans le cadre d'achats informatiques complexes. Les écarts entre les exigences et les besoins réels font l'objet d'ordres de modification. Les ordres de modification coûtent de l'argent. Les coûts supplémentaires sont évités. Il en résulte des coûts beaucoup plus élevés à long terme en raison de l'inadéquation avec les besoins.
La prévisibilité est également associée à la documentation et à la supervision. Les entreprises d'intégration de systèmes passent beaucoup de temps à rédiger des analyses d'écart, des spécifications, des cas de test, des plans d'acceptation, alors que le succès est souvent mesuré par le nombre d'arbres détruits et le nombre de réunions auxquelles on assiste. Cela compromet la réussite du projet. Il ne s'agit pas de dire que la documentation doit être évitée. C'est plutôt que la documentation en tant que cérémonie entrave souvent la réussite du projet. Par exemple, le processus de documentation utilise souvent le système existant comme point d'ancrage plutôt que le système de remplacement. Les équipes passent donc plus de temps à déterminer et à documenter la manière dont le nouveau logiciel fonctionnera comme le logiciel remplacé. L'approche la plus optimale consiste à identifier les problèmes que l'ancien logiciel a résolus et à déterminer si le logiciel de remplacement résout ces problèmes. Il s'avère souvent que le nouveau logiciel offre des moyens plus élégants de résoudre les problèmes.
Les pouvoirs publics précisent souvent la composition de l'équipe du projet d'intégration du système. Il s'agit notamment du nombre d'années d'expérience avec le produit choisi ou dans le domaine des ressources humaines. Il se peut que cela n'ait pas inclus la compréhension de la paie au sein du gouvernement du Canada, ou des gouvernements en général. En outre, les gouvernements précisent souvent le nombre de personnes que doit fournir l'entreprise d'intégration. Ces équipes de projet peuvent devenir encombrantes et nécessiter un fonctionnement en silos avec de fréquentes réunions contextuelles entre les groupes. En matière de mise en œuvre de logiciels, le plus est rarement le mieux.

5. L'énigme de la formation

Les porte-parole du gouvernement ont indiqué que le manque de formation était l'une des causes de l'échec du projet. les causes profondes du problème. Le gouvernement a pris en charge la formation de l'intégrateur de systèmes, IBM. Cette approche n'est pas déraisonnable dans la mesure où le personnel de l'administration a une plus grande expérience pratique de la paie. Cependant, de nombreux projets souffrent de cette tactique utilisée pour réduire les coûts. Les coûts de formation peuvent sembler terriblement élevés dans une proposition de grande envergure. Il s'agit d'un poste budgétaire qui peut faire tache d'huile et qu'il est facile de réduire pour diminuer les coûts.
Une formation suffisante est nécessaire pour tirer le meilleur parti d'un logiciel d'entreprise. Le personnel de l'intégrateur de systèmes connaît souvent beaucoup mieux le nouveau produit, et la formation dispensée par le personnel du gouvernement peut être inférieure à la norme. "Les programmes de formation des formateurs peuvent aboutir à ce que les aveugles dirigent les aveugles. En outre, la formation aux logiciels d'entreprise suppose un minimum de connaissances dans le domaine qui peuvent ne pas exister (même si les clients insistent sur l'existence de ces connaissances). Il est souvent difficile pour les fonctionnaires d'extraire une formation générique d'un contexte commercial pour en tirer des leçons pour l'administration.
Le manque de formation est-il une cause fondamentale ? Comment le manque de formation peut-il entraîner des calculs invalides, y compris le fait que certains fonctionnaires ne reçoivent pas de salaire ? Il devrait y avoir une validation de la saisie des données et des rapports d'exception indiquant que des personnes ne sont pas payées. Les rapports budgétaires devraient également indiquer tout écart entre le salaire prévu et le salaire réel. Il semble que le manque de formation contribue à des centaines de milliers de cas, mais qu'il n'en soit pas la cause première.

6. Lorsque la technologie héritée est remplacée par l'ERP hérité

Le projet Phoenix fait l'objet d'un malentendu courant. La plupart des observateurs pensent que le système a été "développé" par IBM. Le gouvernement du Canada a passé un marché exclusif avec PeopleSoft. C'est une déclaration officielle du Conseil du Trésor. IBM est devenue la société d'intégration des systèmes à l'issue d'une procédure de mise en concurrence. Le problème est que le gouvernement tente d'éliminer la dette technique causée par les logiciels existants en acquérant un système ERP existant. Cela signifie que tomber dans "faillite technique"a été retardée. Mais l'horloge de l'apocalypse informatique fait tic-tac.
Il ne sert pas à grand-chose de remplacer les anciens systèmes par ce que l'Union européenne a décidé de faire. Groupe Gartner appels "ancien système ERP"Les gouvernements ont souvent besoin de plus de personnalisation en raison de réglementations législatives particulières. Les gouvernements ont souvent besoin de plus de personnalisations en raison de réglementations législatives uniques. Ces personnalisations introduisent un nouveau code. Plus le code est modifié, plus le risque de problèmes de qualité est élevé. Plus de bogues. Perte d'intégrité des données.
Le problème de la qualité des systèmes ERP hautement personnalisés s'aggrave avec le temps. Les modifications de la législation entraînent une plus grande personnalisation. La personnalisation rend les mises à jour de produits difficiles car le code orphelin doit être examiné en détail pour voir ce qui doit être modifié. Si les personnalisations sont la cause première de ce problème, les les problèmes ne feront qu'empirer.

7. Remplacement et mythe du portefeuille

L'amélioration de l'intégration et la réduction des coûts totaux sont des propositions de valeur typiques pour de nombreux projets ERP à grande échelle. Et pourtant, de nombreux projets gouvernementaux visant à remplacer plusieurs systèmes par un système unique entraînent des dépassements de coûts importants. Dans ces circonstances, des problèmes de gestion du changement peuvent se poser. J'ai l'impression que les décideurs informatiques ne comprennent souvent pas pourquoi différents systèmes ont été ajoutés en premier lieu. Ces systèmes peuvent avoir besoin de fonctionnalités importantes qui augmentent l'empreinte de la personnalisation.
Il est logique que les fonctions informatiques centralisées réalisent des économies d'échelle positives par rapport à de nombreux systèmes individuels. On peut raisonnablement s'attendre à ce que la formation et la maintenance d'une solution intégrée unique soient inférieures à celles de plusieurs solutions fonctionnant de manière différente avec des technologies différentes. Ce n'est pas toujours le cas dans la pratique. Tout d'abord, les systèmes ERP ont tendance à être plus complexes. Nous savons d'expérience qu'il faut plus de personnel pour exploiter et maintenir un grand système ERP qu'un ensemble d'applications personnalisées et COTS. Deuxièmement, de nombreuses solutions ERP ne sont pas unifiées. Cela est dû aux nombreuses acquisitions réalisées par les fournisseurs d'ERP, de sorte qu'il existe de nombreuses technologies et bases de code dans ces solutions. Les fournisseurs d'ERP déploient des versions monolithiques de modules qui utilisent la même technologie et la même base de code. Cela nécessite une gestion des métadonnées et des stratégies d'intégration lorsque le même logiciel est utilisé, car la définition d'un élément dans un module diffère de celle des autres. Le coût total à long terme peut être plus élevé avec un seul ERP patrimonial qu'avec un portefeuille d'applications.
Il y a aussi quelque chose de fondamentalement différent dans les systèmes ERP à l'échelle du gouvernement. Dans de nombreuses organisations gouvernementales, des retours négatifs se produisent lorsque les petits départements et agences se débattent avec des processus standardisés très complexes conçus pour des départements beaucoup plus importants. Cela peut également entraîner une augmentation de la charge de travail pour les départements et les agences dont les processus sont légitimement uniques. Par exemple, une entité gouvernementale traitant de questions de sécurité nationale a des critères de recrutement très complexes.

8. Quand l'échelle ne passe pas

Les grands systèmes de paie posent des problèmes d'évolutivité. En effet, chaque paie nécessite l'application de milliers de règles. Le gouvernement du Canada comptait plus de 258 000 fonctionnaires fédéraux en avril 2016.. Ce chiffre n'inclut pas le nombre de fonctionnaires retraités qui perçoivent des pensions. Il est donc important d'assurer la mise à l'échelle du système pour les activités de paie les plus intenses. PeopleSoft repose sur une technologie propriétaire. La mise à l'échelle de PeopleSoft nécessite probablement une méthode propriétaire d'équilibrage de la charge pour les processus par lots. Cette méthode n'est peut-être pas très élégante par rapport à certaines des techniques disponibles aujourd'hui. Mais elle devrait être évolutive, à moins que, comme dans le cas de certaines mises en œuvre de Services partagés Canada, les ressources informatiques fournies ne soient insuffisantes.

Pourquoi est-ce important ?

Phoenix est l'un des nombreux grands projets informatiques du gouvernement du Canada qui n'ont pas répondu aux attentes, de même que le projet de l'Union européenne. projet unique de gestion de contenu web, le Projet de courrier électronique de Services partagés Canada, et autres  Il s'agit de argent public qui ont été gaspillés. Il semble que ces mises en œuvre coûteront plus cher au gouvernement que si le statu quo était maintenu. Cela n'augure rien de bon pour les futurs grands projets informatiques du gouvernement du Canada.
Certains observateurs pensent que les fonctionnaires ont trop de droits. Une personne m'a répondu par twitter qu'il devrait y avoir beaucoup moins de fonctionnaires au Canada. Il semblait dire que les fonctionnaires qui perdaient leur maison, qui ne pouvaient pas payer leurs médicaments ou leur éducation le méritaient bien. Il semble y avoir un manque d'empathie en dehors de la région de la capitale nationale. Cette notion de bureaucrates improductifs et sans nom est un mythe. Il est vrai que les fonctionnaires canadiens bénéficient de bons régimes de retraite, mais nombre d'entre eux gagnent moins que leurs homologues du secteur privé.
J'observe que les fonctionnaires ont connu des vagues de réduction des effectifs, de redimensionnement, de services partagés et d'externalisation telles qu'il serait difficile de distinguer la qualité et l'efficacité du travail entre le secteur public et le secteur privé. Bien sûr, il y a des bureaucrates officiels dans le gouvernement, mais il y en a aussi beaucoup dans le secteur privé. Des entreprises comme Blackberry et Blockbuster ont commis des erreurs graves.
Le taux de personnel motivé par une mission est bien plus élevé dans l'administration que dans le secteur privé. La plupart des fonctionnaires que j'ai rencontrés sont là pour apporter un changement positif. C'est une chose dont on parle rarement. Cela devrait être le cas.
 

Thèmes

Contact