Ce texte s'adresse aux conseils et aux personnes qui engagent leur signature sur l'achat d'un système : le secrétaire et le trésorier (skarbnik) dans une administration, le président d'une société communale (spółka komunalna), le directeur financier, le chef d'entreprise. Il s'adresse aussi au responsable informatique qui prépare une procédure ou une demande de devis et souhaite savoir à quoi le conseil doit être attentif avant de valider les documents.
Pourquoi ce problème apparaît
La plupart des difficultés avec les prestataires trouvent leur origine chez le donneur d'ordre, et ce bien avant la signature. Non par mauvaise volonté : préparer un marché est un travail pour lequel l'organisation manque souvent de temps et de compétences, et les prestataires sont ravis de faciliter la tâche. Ils apportent des descriptions toutes faites, des démonstrations et des devis. Résultat : le donneur d'ordre achète ce que le prestataire sait vendre, et non ce dont il a réellement besoin. Autre problème fréquent : les décisions d'achat restent très souvent entre les mains des services métiers, tandis que l'informatique ne joue qu'un rôle de gardien de la sécurité. L'absence de normes et de stratégie informatique à long terme conduit l'organisation à effectuer des achats qui ne s'inscrivent pas toujours dans le cadre censé maîtriser le risque.
Je retrouve les mêmes erreurs dans les administrations et dans les entreprises. Seul le mode d'achat diffère, pas le mécanisme.
Douze erreurs
- Des exigences rédigées sur la base de l'offre ou de la présentation d'un seul prestataire. Cela restreint la concurrence et fige la dépendance avant même le choix du titulaire. J'en parle plus en détail dans le texte sur le risque de vendor lock-in dans le cahier des charges (SWZ).
- L'absence de propriétaire métier. Le projet a formellement un chef de projet, mais personne, muni d'un mandat du conseil, ne décide de la manière dont les processus doivent fonctionner.
- L'absence de critères de recette et de scénarios de test établis avant la signature. La recette devient alors un litige d'interprétation, au lieu d'une vérification que le livrable du projet répond aux critères de succès de la mise en œuvre.
- La méconnaissance de l'existant. Vous achetez un nouveau système sans savoir quels contrats, licences et fonctionnalités actuels font double emploi avec lui.
- Les intégrations oubliées. Avec quoi le nouveau système doit-il échanger des données, dans quel sens, quels systèmes ont un rôle de référence, quelles données, sous quels formats, et le prestataire en est-il informé, s'engage-t-il à fournir les mécanismes nécessaires et à assumer la continuité de leur fonctionnement.
- La migration des données décrite en une seule phrase. Sans préciser quelles données, sur quelle période, qui les nettoie et qui contrôle le résultat.
- Des exigences formulées comme une liste de fonctionnalités plutôt qu'une description de processus. Chaque prestataire répondra « oui » à la question de la fonctionnalité. À la question de savoir comment il traite votre cas concret, les réponses divergent.
- La comparaison du prix de départ plutôt que du coût total. La licence n'est qu'un début. La maintenance, les évolutions et les intégrations se paient pendant des années. J'explique ce mécanisme dans le texte sur le coût total de possession (TCO) et la grenouille qu'on fait bouillir.
- L'absence de règles de gestion des changements de périmètre. On ne sait pas qui signale un changement, qui le chiffre et qui l'approuve.
- Un contrat sans conditions de sortie. Aucune clause sur l'export des données, la documentation et le transfert de la maintenance à un autre prestataire. Aucun outil de maîtrise du risque.
- Un contrat de maintenance repris du modèle du prestataire. Les niveaux de service, les délais de réaction et le coût des modifications sont alors fixés par une seule partie.
- Une décision reportée jusqu'au dernier moment avant l'échéance. Quand une échéance légale ou la fin du support de l'ancien système approche, il ne reste plus de place ni pour comparer les offres, ni pour négocier.
Les erreurs un à trois sont les erreurs source. Si vous les éliminez, la plupart des autres deviennent visibles dès la phase de préparation, et non lors de l'exécution.
Pour le conseil, le conseil de surveillance ou la direction centrale, l'essentiel est de savoir si la décision de choix du prestataire repose sur une justification documentée. Les douze points ci-dessus constituent aussi une liste de questions à poser avant que le conseil ne valide les documents du marché.
Exemple pratique
Un de nos clients a reçu du prestataire de son système ERP l'assurance que l'échange de données sur les contreparties (contrahenci) avec le système de gestion du courrier en cours de déploiement (EZD/e-Doręczenia) se ferait sans difficulté. Or un système de gestion du courrier conserve le plus souvent les données de toutes les contreparties, et pas seulement celles pour lesquelles surviennent des événements économiques, c'est-à-dire celles qui deviennent clients ou fournisseurs. Tout simplement, le cycle de vie des données d'une nouvelle contrepartie commence le plus souvent bien avant la survenue de ces événements économiques.
En cours de mise en œuvre, il s'est avéré que le coût d'adaptation de l'interface API pour un échange bidirectionnel des données sur les contreparties, côté prestataire ERP, représentait 80 % de la valeur totale du projet de mise en place du circuit des documents de dépenses en intégration avec le KSeF, avec OCR, WIES, GUS, et enfin avec l'export des données vers le système financier-comptable. Cette seule intégration, faute d'avoir été précisément discutée dès le départ avec le prestataire, a pratiquement doublé le coût du projet.
Quand faire appel à un conseiller indépendant
Si vous disposez d'une équipe expérimentée ayant déjà préparé plusieurs marchés similaires, cette liste servira de contrôle. Un regard indépendant a du sens lorsque le marché est important à l'échelle de l'organisation, lorsque les exigences ont été élaborées au contact d'un seul prestataire, lorsque la décision devra être défendue devant un contrôle, un conseil ou une direction centrale, ou lorsque personne côté donneur d'ordre ne connaît ces systèmes de l'intérieur.
Je peux relire les documents avant la publication de la procédure ou l'envoi de la demande, préparer les exigences et les scénarios de test, ou évaluer les offres déjà déposées. Dans les administrations, le point de départ est un peu différent ; je le décris sur la page dédiée aux collectivités locales (JST).