No-Code et activation progressive dans la planification des ressources gouvernementales
Il y a quelques années, l'un de nos clients m'a dit : "Tous les gouvernements pensent qu'ils sont différents, mais nous sommes vraiment différents ! "Tous les gouvernements pensent qu'ils sont différents, mais nous sommes vraiment différents !" S'il y a une chose que nous avons apprise après presque 40 ans de relations exclusives avec le secteur public, c'est que les processus gouvernementaux sont différents. Différents d'un gouvernement à l'autre. Différents au sein d'une même administration. Très différents de ceux des entreprises. Et qu'ils sont en constante évolution.
L'adaptation de logiciels commerciaux (COTS) à des organisations gouvernementales peut s'avérer une expérience très insatisfaisante. Les projets de logiciels d'entreprise dans l'administration sont un échec cuisant et des méthodes de mise en œuvre complexes. Nombreux sont ceux qui, dans l'industrie technologique, considèrent ces difficultés comme le "coût des affaires". "C'est comme ça", etc.
Pourquoi faut-il qu'il en soit ainsi ? Pourquoi les logiciels COTS ne peuvent-ils pas s'adapter facilement à l'évolution des besoins ?
Cet article de blog décrit notre voyage vers une "activation progressive"et l'approche "sans code".
La plupart des logiciels COTS utilisés pour Planification des ressources publiques (GRP) nécessite une personnalisation importante du code. Le développement de logiciels, utilisant généralement des langages de programmation propriétaires, permet aux gouvernements de répondre à des exigences personnalisées. Mais cela a un coût.
De nombreux experts en gestion des finances publiques (PFM) ne voient pas de différence entre la configuration et la personnalisation, et qualifient souvent toute adaptation de "personnalisation". Nous parlons de la différence depuis un certain temps. Et l'industrie nous a rattrapés en définissant la configuration comme une personnalisation "sans code". L'utilisation de logiciels d'assistance pour faciliter le développement du code est désormais appelée développement "low-code". Je préfère le terme de "configuration", mais ce spectre "no-code" à "full-code" est un modèle utile.
Entreprise Compounding Software Technical Debt (dette technique logicielle)
La personnalisation du code s'accompagne de coûts élevés et l'avenir défis en matière d'adaptabilité. La personnalisation génère dette technique.
Les logiciels génériques, tels que les progiciels de gestion intégrés (ERP), sont très adaptables grâce à l'utilisation de langages de programmation propriétaires tels que le ABAP et PL/SQL. Il est vrai que le logiciel ERP n'est pas un terrain vague de configuration :
- Configuration de paramètres standard tels que les années fiscales, les devises, les fournisseurs, etc.
- Marché vertical des démarrages rapides pour faciliter la mise en œuvre, bien qu'il n'y en ait que peu qui s'appliquent au secteur public
- Meilleures pratiquesles logiciels, provenant principalement du secteur privé, intégrés dans des logiciels qui pourraient s'appliquer à certaines fonctions gouvernementales, tant qu'une réforme juridique n'est pas nécessaire.
Les gouvernements acquièrent des composition la dette technique par le biais d'une personnalisation complète du code. La personnalisation d'un code faible augmente également la dette technique.
La dette technique comprend
- Complexité de la mise en œuvre de l'articulation complète des besoins et du déploiement similaire à un développement entièrement personnalisé, nécessitant la coordination des équipes de programmation et l'instauration d'une assurance qualité complète.
- Complexité de la maintenance après la mise en œuvre augmente parce qu'il y a des codes orphelins qui doivent être pris en charge par des ressources internes, ce qui n'est pas de la responsabilité du fabricant
- Complexité de la mise à niveau lorsqu'il s'agit de tirer parti des fonctionnalités des nouvelles versions, car le code personnalisé doit être examiné et rationalisé en fonction de la nouvelle version.
- Complexité du changement par la nécessité de comprendre le code orphelin avant de s'engager dans le changement
La personnalisation du code peut créer non seulement une dette technique. La technologie peut limiter les possibilités de réforme. C'est ce que nous appelons le "fossé technologique“.
Les signes du fossé technologique en jeu sont les suivants :
- Pauvre délai d'obtention des résultats pour les mises en œuvre
- Pauvre temps de changement pour les systèmes
- De nombreux contrats à coût élevé le personnel gérer les systèmes
- Erreurs fréquentes du système et qualité problèmes
- Capacité limitée d'exploiter les données à d'autres fins en raison de l'absence de ouverture en raison du verrouillage des technologies propriétaires
- Limitée l'intégration des sous-systèmesmême parmi les produits d'un même fabricant
A Groupe Gartner l'analyse a constaté que les logiciels qui n'ont pas été conçus pour s'adapter à l'avenir coûtent aux organisations environ 50 fois les investissements initiaux sur une période de 15 ans.
Dette technique de la planification des ressources gouvernementales
Les gouvernements sont confrontés à des mises en œuvre plus complexes que les entreprises.
Les mises en œuvre de logiciels d'entreprise par les pouvoirs publics sont plus complexes :
- Beaucoup plus de lignes d'activité d'un gouvernement national ou infranational, que les conglomérats d'entreprises
- Contraintes importantes en matière de capacités humaines en matière de technologie, de projet et de connaissances fonctionnelles
- Une gestion des performances plus complexe les structures et la planification, parce que le gouvernement n'a pas de résultat comme "...".le bénéfice ou la perte“
- Une plus grande diversité des pratiques en raison d'exigences légales
- Une planification plus complexe à travers pluriannuel les budgets qui créent des contrôles dans les systèmes pour comptabilité d'engagement
- Préoccupations politiques importantes pour mise en œuvre dans le secteur public
Les gouvernements ont également une empreinte de changement plus large que les organisations du secteur privé :
- Plus de réorganisations après les élections, et des remaniements ministériels
- Plus de réformes juridiques parce que de nombreuses procédures du système sont fixées par la loi, et que les lois changent - par exemple : passage à la comptabilité d'exercice, soutien au compte unique du Trésor, réforme des marchés publics, réforme de la fonction publique
- Plus de changements dans les processus en plus de la réforme juridique
- Plus de normes internationales comme le CDMT, l'IPSAS, le COFOG, le GFS et les SDG, en plus de soutenir certaines normes du secteur privé.
- Contraintes organisationnelles plus larges y compris les intérêts particuliers qui s'opposent au changement
- Utilisation accrue des anciennes technologies de l'État, ce qui rend le changement coûteux, bien qu'il soit grevé d'une charge de travail importante. des coûts d'exploitation et de maintenance élevés
Conception de la dette technique de la planification des ressources de l'administration
La conception du produit entraîne une dette technique ou une valeur ajoutée technique. Une conception efficace permet de trouver des solutions élégantes aux problèmes des clients. Notre focalisation sur le gouvernement nous a libérés de nombreuses contraintes liées aux logiciels d'entreprise.
La conception pour le web-natif FreeBalance Accountability Suite™ a débuté au milieu de l'année 2006. Nous avons examiné un grand nombre des contraintes auxquelles sont confrontés les fabricants de logiciels d'entreprise et nous avons tiré quelques conclusions :
- Fonctions gouvernementales: Manque de fabricants de logiciels complet les fonctions gouvernementales en raison de la nécessité de vendre des logiciels à de nombreuses industries, ou marchés verticauxdans plusieurs classes de logiciels (ERP, CRM, SCM, HCM, etc.), ou marchés horizontauxet dans l'ensemble de l'Union européenne. pile logicielle (base de données, serveur d'application, logiciel intermédiaire, etc.)
- Cycle budgétaire: Les fabricants de logiciels n'ont pas pris en charge l'intégralité du cycle gouvernemental de la gestion de l'information. politique, planification budgétaire, engagements et obligationspour toutes les applications de dépenses et de recettes
- Adaptabilité: Les fabricants de logiciels se sont appuyés sur personnalisation du code parce que les logiciels ont souvent été conçus à l'origine pour les entreprises
- Métadonnées: Les fabricants de logiciels ont eu des définition des données des problèmes au sein des suites de produits qui compromettaient l'intégration et des contrôles, souvent à partir de l'entreprise acquisitionstout en fournissant des la localisation, en particulier pour les langues
Notre première décision a été de développer un plate-forme spécifique au gouvernement avec un unifié conception. La suite de produits a été développée sur la base de notre Carte des composantes de la gestion des finances publiques.
Nous avons profité de l'occasion pour nous attaquer aux contraintes technologiques existantes en réécrivant notre logiciel pour le web. Nous avions beaucoup appris de la migration de notre ancien logiciel du Canada vers d'autres pays :
- Fonctions gouvernementales: Notre orientation nous a permis de construire complet Les fonctions gouvernementales dans l'ensemble de la carte des composantes de la PFM parce que, avec des mesures appropriées, la PFM est un élément essentiel de la stratégie de développement. horizontale fonctionnelleen ignorant d'autres marchés et en développant un système ouvert pouvant prendre en charge de nombreuses piles logicielles.
- Cycle budgétaire: Notre objectif nous a permis de soutenir l'ensemble de la cycle budgétaire, ce qui fait que toutes les demandes conscient du budget
- Adaptabilité: Nous avons compris la dette technique de l'État, et nous avons élargi le champ d'action de l'État. configurabilité de manière significative par rapport à nos versions précédentes
- Métadonnées: Nous avons réalisé que les métadonnées devaient être unifiéNous avons également réalisé qu'il devait y avoir une meilleure façon de localiser les produits de l'entreprise et de les intégrer à la configuration.
Configuration et activation progressive
FreeBalance a réussi à mettre en œuvre rapidement des logiciels. Notre première mise en œuvre, en Kosovo, a pris 26 jours. Le système opérationnel de l'époque comprenait des contrôles budgétaires, l'impression de chèques et une structure de plan comptable. Les fonctions comptables sont apparues plus tard. Il en a été de même pour la trésorerie et les contrôles décentralisés. L'approche de configuration des versions précédentes du logiciel FreeBalance a permis des gains rapides. Nous avons réalisé que nous pouvions "activer progressivement" n'importe quel gouvernement vers des fonctions de finances publiques avancées, comme c'est le cas pour le gouvernement du Canada.
Depuis l'achèvement de la première version de notre site web FreeBalance Accountability Suite en 2009, nous avons constaté un besoin croissant d'activation progressive.
Les gouvernements recherchent le progrès et la modernisation, soutenus par les systèmes GRP pour :
- Réforme de la gouvernance: GFP, audit, service public, marchés publics et réforme fiscale
- Gouvernement ouvertTransparence du budget, de la fiscalité, de la passation des marchés, des recettes et des résultats grâce à des mécanismes participatifs
- DécentralisationLa décentralisation fiscale : l'agence et la décentralisation fiscale infranationale, la déconcentration
- Automatisation de la technologieEfficacité de l'automatisation, alertes en cas d'exception, intelligence artificielle
- Transformation numériqueLa migration de l'homme vers l'homme des systèmes d'enregistrement aux systèmes d'engagement, aux systèmes d'intelligence et aux systèmes d'innovation
- Modernisation des performancesla budgétisation des programmes, les structures de performance, les effets et les résultats
Avantage de l'intégration des produits et des services
J'ai rencontré un haut fonctionnaire du Trésor d'un pays africain qui utilisait un système ERP de niveau 1 pour la gestion financière. Le système était encore en phase pilote après deux ans. Il m'a accusé d'appartenir à l'une de ces "entreprises occidentales" qui demandent des millions de dollars par an aux gouvernements pauvres, simplement pour payer la maintenance des logiciels. La maintenance d'un logiciel qui n'a pas encore été mis en œuvre. J'ai expliqué que notre système utilisait une approche de configuration pour accélérer les mises en œuvre. Il s'est mis à rire. Il ne croyait pas du tout que c'était possible. Il connaissait parfaitement la façon dont se déroulaient les mises en œuvre des ERP dans les administrations publiques.
FreeBalance a bénéficié d'une attention particulière portée aux gouvernements. Notre logiciel peut être massivement configurablepar rapport à un logiciel générique.
Il existe une autre caractéristique unique de FreeBalance. Un grand nombre de nos premiers clients internationaux ont passé des contrats avec de grandes sociétés d'intégration de systèmes. Nous étions un fournisseur de logiciels, avec quelques responsabilités de sous-traitance. Nous avons découvert que notre implication dans le projet était proportionnelle à sa réussite. Nous avons également constaté que nos partenaires n'avaient pas transmis à l'administration de nombreuses demandes de modification de fonctionnalités. Notre feuille de route n'était pas alignée.
L'approche traditionnelle des feuilles de route des logiciels d'entreprise se fait par l'intermédiaire de partenaires d'intégration, avec un second canal par le biais du support produit. Les fabricants de logiciels sont souvent déconnectés des besoins des clients. Les fabricants qui soutiennent de nombreux marchés verticaux manquent souvent d'expertise, de sorte que la "loterie des fonctionnalités" favorise souvent certains marchés par rapport à d'autres.
Notre approche est très différente.
Notre politique est de participer à toutes les mises en œuvre. Nous comprenons le marché gouvernemental. Nous travaillons avec des sociétés d'intégration de systèmes. Nos équipes chargées des produits et des services sont intégrées de telle sorte que nous procédons à toute personnalisation nécessaire du produit. Et cette personnalisation fait partie de notre code commercial dans la version suivante. Il n'y a pas de code orphelin.
Les fabricants traditionnels de logiciels d'entreprise établissent des feuilles de route à long terme pour leurs produits. Il s'agit d'une approche acceptée. Cela n'a aucun sens, mais "c'est comme ça". Les besoins des clients et la technologie évoluent tellement que prévoir les caractéristiques d'un produit pour les 3 à 5 prochaines années ressemble davantage à un jeu de hasard. Surtout avec un tel niveau de détail.
Je sais - les clients sont conditionnés aux feuilles de route. Les clients potentiels veulent voir notre feuille de route à 5 ans. Notre feuille de route à 10 ans. Je suppose que c'est pour voir si des fonctions nécessaires manquantes pourraient être en cours d'élaboration. Nous montrons aux gouvernements la carte des composants de PFM et leur expliquons que nous sommes prêts à faire n'importe quoi et à adapter le logiciel pour répondre à leurs besoins. (Tant qu'il ne s'agit pas d'une mauvaise pratique).
Notre approche consiste à élaborer une feuille de route détaillée sur trois ans, basée sur l'expérience approfondie de nos clients. Et sur nos recherches en matière de gouvernement et de technologie. Nous la présentons chaque année à notre Comité directeur international de FreeBalance (FISC). Les participants au FISC modifient les priorités de la feuille de route et ajoutent des éléments.
Cela comprend les produits et les services.
L'activation progressive réduit la dette technique
FreeBalance est un entreprise sociale. Notre mandat est de construire prospérité d'un pays intelligent grâce à une gouvernance fondée sur la technologie. Les gouvernements ne peuvent pas construire la prospérité lorsqu'ils sont endettés techniquement par les systèmes d'information. La technologie doit permettre de réformer la gouvernance.
Cette approche de configuration, qui permet une activation progressive, comprend
- Paramétrage des règles de gestion
- Flux de travail sans code
- Plan comptable configuré sur plusieurs années
- Métadonnées unifiées
- Champs de données supplémentaires
- Fichier linguistique unique (plutôt que des ensembles linguistiques rigides)
- Configuration de la terminologie
- Aide adaptable grâce à un système intégral de gestion du contenu