Vers une déclaration de dépendance à l'égard des fournisseurs de logiciels ? class="sparadrap" class="sparadrap")

Vers une déclaration de dépendance à l'égard des fournisseurs de logiciels ?

Publié le en Technologie gouvernementale

De temps à autre, quelqu'un s'empare de l'air du temps dans le domaine de l'informatique d'entreprise.  Frank Scavo, président de Strativa l'a fait dans un billet de blog : L'heure de la déclaration d'indépendance des éditeurs de logiciels a-t-elle sonné ? (et un Podcast Diginomica avec une interview réalisée par Dennis Howlett). Frank a constaté une augmentation du nombre d'entreprises qui développent des logiciels personnalisés à partir de zéro. Le calcul entre la création et l'achat a-t-il changé ? Les organisations devraient-elles déclarer leur indépendance vis-à-vis des fournisseurs de logiciels indépendants (ISV) comme FreeBalance ?
Ce n'est pas tant que les organisations doivent déclarer l'indépendance de la part des ISV, car ces derniers devraient déclarer la dépendance sur les clients.
[vous trouverez ci-dessous une déclaration de dépendance des clients des éditeurs de logiciels en dix points, passez outre le contenu gouvernemental si vous n'êtes pas intéressé].

Construire ou acheter sur le marché public

Le marché de l'informatique gouvernementale se distingue du marché des entreprises par une plus grande proportion de logiciels sur mesure et de logiciels anciens. C'est ce que nous constatons sur notre marché principal : La planification des ressources gouvernementales (GRP), en particulier dans les pays en développement et les économies émergentes. Les experts en gestion des finances publiques (PFM) ont estimé que la création de systèmes d'information de gestion financière (FMIS) personnalisés était une option légitime :

Dans le podcast, M. Scavo souligne que les organisations "ne devraient pas construire un grand livre". Pourtant, le grand livre est au cœur de la gestion financière des administrations publiques. Cette situation est d'autant plus compliquée que les gouvernements utilisent la comptabilité d'engagement.
Je sais à quel point il est compliqué de construire un grand livre général avec plusieurs niveaux de contrôle des engagements globaux, et de rendre compte du "solde libre" du budget en temps réel. Je me souviens d'une conversation avec un consultant d'une société de conseil en développement bien établie, lorsque je lui ai dit que FreeBalance prenait entièrement en charge la comptabilité d'engagement. Il m'a demandé si j'en étais sûr, car la comptabilité d'engagement est très compliquée.
Pourquoi tant d'experts respectés de la gestion des finances publiques estiment-ils que les gouvernements devraient envisager de créer des systèmes de comptabilité d'engagement personnalisés ?

Comment en est-on arrivé là ?

  1. Pouvoir asymétrique
    • Scavo décrit comment les éditeurs de logiciels indépendants exercent un pouvoir énorme une fois que le logiciel a été installé.
    • Les gouvernements peuvent être enfermés dans des piles technologiques de planification des ressources de l'entreprise (ERP) composées de bases de données, d'intergiciels et de langages de programmation propriétaires (sans parler du matériel pour l'informatique en mémoire).
    • Les logiciels développés sur mesure limitent le pouvoir des vendeurs sur les gouvernementsBien qu'il puisse s'agir d'un l'illusion du contrôle
  2. Mauvais comportement des éditeurs de logiciels indépendants
    • M. Scavo décrit la manière dont certains éditeurs de logiciels indépendants tirent parti de leur pouvoir asymétrique pour adopter de mauvais comportements, appelés "wallet cracking" ("craquage de portefeuilles") (invention de Brian Sommer), notamment en poursuivant les clients, en facturant l'accès indirect et en augmentant les prix de maintenance.
    • Les gouvernements ont la responsabilité de dépenser l'argent public de manière efficace, afin d'obtenir un bon rapport qualité-prix dans les cas suivants recherche de rente le comportement des ISV ne doit pas être toléré
    • Les logiciels développés sur mesure réduisent les possibilités de recherche de rente de la part des fournisseursLes gouvernements ne peuvent toutefois pas éviter complètement les fournisseurs de technologie.
  3. Échec retentissant d'un système ERP dans l'administration publique
  4. Personnalisation du code
    • M. Scavo souligne qu'une grande partie des produits commerciaux disponibles est "inflexible" et nécessite une adaptation importante pour répondre aux besoins (et aux exigences de l'UE). Le Gartner Group est allé jusqu'à qualifier ces logiciels d'"anciens")
    • Les exigences des pouvoirs publics diffèrent considérablement des besoins des entreprises, ce qui implique de longs cycles de personnalisation du code (au point que de nombreux experts de la PFM parlent de "personnalisation sur étagère"), entraînant des problèmes de qualité, avec le coût supplémentaire de la maintenance et de la mise à jour du code orphelin.
    • Les logiciels développés sur mesure semblent avoir la même empreinte de complexité pour les gouvernements que les progiciels de gestion intégrés. (bien que, comme je l'affirme ci-dessous, le PRV soit beaucoup moins complexe).
  5. Prévisibilité des logiciels
  6. Mauvais comportement des SI
    • M. Scavo souligne également que les grands intégrateurs de systèmes sont souvent responsables des échecs de mise en œuvre, car ils poussent souvent à une personnalisation inutile afin d'augmenter les revenus - c'est un phénomène que l'on retrouve dans de nombreux pays. Michael Krigsman appelle le "Triangle du diable“
    • Les gouvernements préfèrent souvent passer des contrats avec de grands intégrateurs de systèmes, car cela leur permet d'être plus efficaces. mécanisme de réduction des risques
    • Les logiciels développés sur mesure peuvent éliminer les grands intégrateurs de systèmesBien que de nombreux projets d'applications développées sur mesure soient confiés à des prestataires de services d'information.

Les gouvernements doivent-ils faire face à deux alternatives peu reluisantes ?

Il ne s'agit pas d'un ERP COTS ou d'un FMIS développé sur mesure pour les gouvernements. Il y a l'alternative GRP, comme notre FreeBalance Accountability Suite. Government Resource Planning est un logiciel conçu exclusivement pour les gouvernements. FreeBalance est le premier GRP mondial avec des implémentations dans environ 30 pays.
Certains observateurs supposent que GRP a hérité de tous les maux du COTS. D'autres observateurs supposent que les éditeurs de logiciels indépendants de GRP ne peuvent pas rivaliser avec les principaux fournisseurs d'ERP. J'ai tiré quelques leçons de cette affaire GRP :

  1. Logiciel à domaine unique
    • Un haut fonctionnaire du ministère des finances s'est moqué de moi lors d'une conférence lorsque je lui ai dit que le logiciel FreeBalance était principalement configuré pour répondre aux besoins - c'est cette configuration qui accélère les mises en œuvre, réduit les coûts des projets (surtout par rapport aux solutions ERP), et permet une flexibilité future pour le changement, ce que nous appelons "l'innovation".activation progressive“
    • Certains observateurs ne voient guère de différence entre "configuration" et "personnalisation". différence significativeoù certains vendeurs appellent à tort les scripts de programmation "configuration". et les générateurs de code et les suites de flux de travail sont souvent présentés comme des "configurations"
    • L'accent mis sur le gouvernement nous permet de comprendre le domaine qui fait défaut à de nombreuses grandes entreprises, comme le grand fournisseur d'ERP qui dit aux clients du secteur public que les contrôles budgétaires par poste sont une "meilleure pratique"
  2. Economies d'échelle
    • Le marché des ERP a décollé dans les années 90, soutenu par les inquiétudes liées au passage à l'an 2000 et par les éditeurs de logiciels indépendants (ISV) qui ont exploité les fonctionnalités d'un marché pour les appliquer à un marché similaire, offrant une meilleure qualité et un meilleur support et réalisant des économies d'échelle par rapport aux vendeurs "best-of-breed". les logiciels pour marchés multiples sont devenus trop lourds
    • Les économies d'échelle diminuent avec l'arrivée sur de nouveaux marchés - de nombreux fournisseurs ont été rachetés pour remplir leurs portefeuilles de produits, créant ainsi ce que l'on appelle des "marchés d'exportation". Ned Lily de xTuple appelle le "Cimetière ERP"où les principaux fournisseurs doivent faire face à une complexité stupéfiante pour maintenir un grand nombre de technologies acquises
    • Les grands fournisseurs s'appuient sur des bases de données, des logiciels intermédiaires et des langages de programmation propriétaires pour enfermer les clients dans des piles technologiques - ce qui nécessite des investissements importants à un moment où les éditeurs de logiciels indépendants (ISV) agiles s'appuient sur des alternatives open source.
  3. Produit et processus intégrés
    • De nombreux éditeurs de logiciels indépendants cherchent à se développer par l'intermédiaire de partenaires VAR et d'intégrateurs de systèmes, au point de perdre la connaissance du client et de réduire les taux de réussite de la mise en œuvre, ce qui déconnecte les éditeurs de logiciels indépendants de la réalité des clients.
    • D'autre part, les éditeurs de logiciels indépendants cherchent souvent à conclure des contrats de conseil avec des clients stratégiques afin de définir les priorités en matière de produits, et je me demande souvent comment la majorité des clients se sentent lorsqu'ils ne sont pas considérés comme stratégiques.
    • Nous considérons tous les clients comme stratégiques, car, en tant que nos clients, ils ont un rôle à jouer dans la vie de l'entreprise. Président et directeur général, Manuel Pietra dit souvent : "nous n'avons qu'un seul client par pays - le gouvernement, et nous sommes là pour la vie"

Déclaration de dépendance du client

De nombreux points ont été inspirés par la L'heure de la déclaration d'indépendance des éditeurs de logiciels a-t-elle sonné ? billet de blog incluant Web APis, open source, low-code/no-code.
Les éditeurs de logiciels indépendants (ISV) devraient admettre et s'engager à servir d'abord les clients pour construire des entreprises financièrement durables.

  1. Responsabilité sociale des entreprises: Les codes de conduite des éditeurs de logiciels indépendants devraient reconnaître que les clients sont la première communauté pour les efforts de responsabilité sociale, et devraient interdire tout comportement flagrant de recherche de rente.
  2. Accessibilité des cadres: Les cadres de l'ISV doivent être accessibles aux clients afin d'améliorer le support produit, les procédures de l'entreprise et la compréhension des clients.
  3. Créer de la valeur: Les éditeurs de logiciels indépendants doivent se concentrer sur la création de valeur en tant que principal moyen de fidélisation de la clientèle et reconnaître que la valeur peut ne pas résulter de l'ajout de fonctionnalités et peut provenir d'éléments extérieurs aux produits, tels que des services ou des changements de processus.
  4. Expertise dans le domaine: Les éditeurs de logiciels indépendants ne devraient pas pénétrer de nouveaux marchés verticaux ou horizontaux sans avoir acquis une expertise dans le domaine du développement et de la gestion des produits.
  5. Mise en œuvre Gouvernance: Les éditeurs de logiciels indépendants devraient faire partie de la structure de gouvernance du programme pour les mises en œuvre importantes, plutôt que d'adopter une approche non interventionniste, afin d'encadrer les partenaires et les clients.
  6. Flexibilité et adaptabilité : Les éditeurs de logiciels indépendants devraient réduire le fardeau de la personnalisation du code grâce à une configuration sans code et à des techniques à faible code afin d'accélérer les mises en œuvre, d'améliorer les changements futurs et de réduire les coûts pour les clients.
  7. Gestion des fonctionnalités: Les éditeurs de logiciels indépendants doivent s'engager à réduire les besoins de personnalisation du code d'implémentation en définissant clairement la manière dont les fonctionnalités importantes seront ajoutées aux feuilles de route des produits.
  8. Innovation coopérative: Les éditeurs de logiciels indépendants doivent s'engager à innover en fonction des besoins des clients, en définissant clairement la manière dont l'innovation et le développement coopératifs seront facilités.
  9. Systèmes ouverts: Les éditeurs de logiciels indépendants devraient s'engager à soutenir et à utiliser des systèmes ouverts éprouvés, y compris des logiciels libres, afin d'offrir aux clients un plus grand choix de technologies tout en réduisant la dépendance à l'égard des propriétaires.
  10. Plates-formes commerciales: Les éditeurs de logiciels indépendants devraient s'efforcer de fournir des API et de réutiliser les plates-formes de produits pour permettre le développement personnalisé lorsqu'il est justifié, tout en évitant de facturer aux clients des fonctionnalités déjà payées.

Ma réflexion sur la déclaration est issue de mon blog invité de 2014 chez ZDNet : Défaillances informatiques, changements d'énergie et médias sociaux édité par Michael Krigsman. Les clients peuvent se regrouper en tirant parti des médias sociaux. À l'époque, j'avais souligné quelques changements de comportement intéressants chez les principaux éditeurs de logiciels d'entreprise :

  • SAP et Infor ont adopté la réflexion sur la conception devenir plus centré sur le client
  • Microsoft a ajouté un option de licence pour la ligne de produits Dynamics.
  • Les réactions négatives des clients ont contraint SAP à modifier sa politique de prix sur le marché de l'électricité. soutien premium et l'interface utilisateur Fiori mise à niveau.
  • Salesforce.com était repoussé dans ses tentatives d'obtenir une marque déposée pour le terme "entreprise sociale"

Depuis lors, SAP a modifié son modèle d'"accès indirect.

Les gouvernements sont-ils uniquement confrontés à la question de la construction ou de l'achat ?

M. Scavo souligne que les plates-formes d'entreprise issues de suites d'applications, telles que l'application Plate-forme de responsabilisation FreeBalanceLes logiciels libres peuvent être exploités pour développer des logiciels sur mesure. Il ne s'agit pas d'un choix binaire entre la construction et l'achat. Il existe des alternatives hybrides de construction et d'achat.
De nombreux gouvernements cherchent à créer des logiciels à l'aide d'un environnement de développement intégré (IDE) standard utilisant une technologie. Une "plate-forme de gouvernance" est une approche hybride qui inclut tous les aspects de construction des plates-formes technologiques avec la réutilisation des fonctions d'achat utilisées par le GRP COTS. De plus, le low-code/no-code peut permettre ce qui était autrefois du développement personnalisé sur les GRP Suites comme une alternative d'achat plutôt que de construction.
COTS ou FMIS sur mesure : au-delà du choix binaire

Comment les gouvernements peuvent-ils prendre la bonne décision en matière de construction ou d'achat ?

Scavo identifie un certain nombre de facteurs qui peuvent aider les gouvernements à prendre de meilleures décisions en matière de construction par rapport à la construction, que j'ai essayé de schématiser.
Construire, options hybrides et acheter

  1. Spécificité de l'industrie: De nombreuses solutions ISV ont été écrites pour d'autres marchés - Cela a des conséquences importantes pour les gouvernements qui ont des besoins très spécifiques.
    • Envisager l'achat lorsqu'un logiciel est écrit pour une fonction gouvernementale, la conception du produit est importante
    • Envisager de construire lorsqu'il n'existe pas de logiciel disponible pour la fonction gouvernementale, en particulier lorsqu'il s'agit d'un besoin statutaire unique
  2. Risque lié au produit: La mise en place de fonctionnalités complexes, telles qu'un grand livre, est risquée, et la flexibilité en matière de changement est importante - Cela a des conséquences importantes pour les gouvernements qui s'attendent à une modernisation et à une réforme futures.
    • Envisager l'achat lorsque les besoins en matière d'empreinte du produit sont complexes et que des changements futurs sont attendus
    • Envisager de construire lorsque les besoins d'encombrement du produit sont modestes et que peu de changements futurs sont attendus
  3. Risque d'intégration: Les logiciels ne doivent pas être considérés comme des boîtes noires - Cette situation a des conséquences importantes pour les gouvernements qui ne disposent pas de métadonnées et ne contrôlent pas l'intégration entre les cycles budgétaires.
    • Envisager l'achat lorsque les besoins d'intégration fonctionnelle sont importants, comme la gestion des marchés publics, des actifs et des investissements publics, où les incohérences d'interface peuvent avoir des conséquences matérielles telles que des arriérés de paiement de l'État et des dépassements illégaux de budget, ou lorsque les informations provenant du système sont essentielles pour les décideurs et la transparence budgétaire
    • Envisager de construire lorsque les fonctions fonctionnent de manière autonome et que le besoin de comptabilisation dans les systèmes financiers centraux est limité

Thèmes

Contact