Comment préparer son entreprise au choix d'un système workflow/BPM/RPA/ERP/CRM sans créer de dépendance envers le fournisseur ?

Ensuite, consignez par écrit les exigences qui protègent contre la dépendance : export des données et de l'historique des dossiers dans un format ouvert, API documentée, processus formalisés selon la norme BPMN, droit à votre propre configuration et règles claires de sortie du contrat. Nommez les risques que vous êtes capables d'identifier aujourd'hui. Ne soyez pas naïfs : listez tous les risques. Comparez les offres sur vos propres scénarios et en coût total sur plusieurs années (investissement plus coûts opérationnels récurrents). Licences, renouvellements, formations, maintien de l'équipe, évolutions, migrations. Demandez-vous enfin quelle est la probabilité que le fournisseur perde ses consultants clés, décide de remplacer administrateurs et développeurs par de l'IA, ou cesse de prendre en charge le système d'exploitation actuel.

Cet article s'adresse aux dirigeants d'entreprises et de spółki komunalne (sociétés à participation publique locale) qui souhaitent structurer la circulation des documents, des factures de charges, des contrats ou des demandes, et qui doivent choisir un système workflow, c'est-à-dire un outil qui fait avancer un dossier d'une personne à l'autre selon des règles établies. Trois voies s'offrent généralement : une plateforme BPM prête à l'emploi, un outil low-code ou un système développé sur mesure ; les principes ci-dessous valent pour chacune d'elles. Il intéressera aussi les directeurs financiers, car ce sont généralement eux qui paient les conséquences d'un mauvais choix.

Pourquoi la dépendance au fournisseur se crée dès le départ

La dépendance résulte rarement d'une seule mauvaise décision. Elle commence généralement plus tôt que l'entreprise ne le remarque : les processus sont décrits dans l'outil du fournisseur plutôt que dans des documents propres à l'entreprise ; les données et l'historique des dossiers sont dans un format difficile à extraire ; seul le partenaire d'implémentation connaît la configuration ; et le contrat détaille longuement la mise en œuvre mais reste muet sur ce qui se passe lorsque l'entreprise souhaite partir. Au bout de quelques années, changer de système coûte plus cher que de le maintenir, même s'il ne répond plus aux besoins.

Étape 1. Décrivez les processus avant de parler aux fournisseurs

Avant de rédiger un appel d'offres, il convient de décrire les circuits que le système devra traiter : qui déclenche le dossier, qui le valide et dans quel ordre, quelles sont les exceptions et les seuils (par exemple un circuit différent au-delà d'un certain montant), quels sont les délais, et quelle trace de décision doit subsister en cas d'audit. Le mieux est de le consigner selon la norme BPMN, comprise par différents outils. Ainsi, la description du processus appartient à l'entreprise, et non au système.

Sans une telle description, on compare des présentations de fournisseurs, pas des solutions. Chaque démonstration paraît convaincante, car le fournisseur y montre son meilleur scénario, pas votre exception la plus complexe.

Étape 2. Vérifiez ce que vous possédez déjà

Une partie des circuits peut souvent être prise en charge par des outils que l'entreprise possède déjà : CRM, systèmes métier, système de gestion documentaire ou suite bureautique. Parfois, l'analyse conclut qu'un nouveau système n'est pas nécessaire, et qu'un changement de procédure ou de configuration suffit. Cet inventaire révèle aussi les intégrations que le nouveau système devra gérer, par exemple avec le système financier-comptable et le KSeF (système national polonais de facturation électronique), ainsi que les points où l'information se perd aujourd'hui. En savoir plus : inventaire des systèmes informatiques.

Étape 3. Les exigences qui protègent contre la dépendance

Ces exigences méritent d'être inscrites dans l'appel d'offres comme conditions, et non comme simples souhaits :

1. Export des données et de l'historique des dossiers dans un format ouvert et documenté, à tout moment et sans frais supplémentaires.
2. API documentée pour l'intégration avec d'autres systèmes, avec le droit pour d'autres prestataires de l'utiliser.
3. Processus consignés selon une norme (BPMN), exportables et reproductibles ailleurs.
4. Droit de configuration par votre propre équipe ou par un partenaire au choix, avec documentation des modifications.
5. Règles de sortie du contrat : période de transition, aide à la migration des données et coût connu à l'avance.
6. Choix du partenaire de maintenance : possibilité, après la mise en œuvre, de changer de prestataire sans perdre le support de l'éditeur.

La même logique s'applique au RPA, à l'ERP et au CRM

Ces principes valent pour tout système qui structure le travail de l'entreprise. Mais à chaque fois, il convient de commencer par la question de ce que l'on veut obtenir, car la réponse détermine si l'on choisit la bonne catégorie d'outil.

RPA. La première question est : pourquoi le RPA plutôt que le BPM ? Le robot logiciel reprend des tâches répétitives effectuées par un humain dans les systèmes existants, mais ne modifie pas le processus ; le BPM, lui, structure le processus lui-même. Si l'objectif est de décharger les équipes de la ressaisie de données entre systèmes, un robot peut suffire. Si l'objectif est un circuit de traitement des dossiers nouveau et plus court, le robot a souvent tendance à figer l'ancien. Le robot dépend aussi des écrans et des formats des autres systèmes : toute modification de ceux-ci peut l'arrêter, d'où l'importance de connaître le coût de maintenance des scénarios et d'en conserver la description hors de l'outil de l'éditeur.

ERP. La question clé est ici : voulons-nous que l'ERP nous apporte des bonnes pratiques et des processus prêts à l'emploi, ou qu'il soutienne nos propres processus, ceux qui construisent notre avantage concurrentiel ? Dans le premier cas, il vaut mieux s'en tenir au standard du système et limiter les personnalisations, car chacune complique les mises à jour et le changement de partenaire. Dans le second cas, un ERP simple complété par un système BPM agile donne parfois de meilleurs résultats, permettant de faire évoluer les processus différenciants sans toucher au cœur du système. Dans les deux cas, les données financières, logistiques et RH, ainsi que les intégrations avec le KSeF et les banques, doivent pouvoir être extraites intégralement, avec leur historique.

CRM. Avant de comparer les offres, il faut définir ce que l'on entend par CRM : structurer les processus de relation client, développer une vente multicanal, ou mettre en place une plateforme de prospection commerciale. Ce sont trois projets différents, avec des utilisateurs, des intégrations et des indicateurs de succès distincts. Quelle que soit la variante, l'export de la base clients avec historique des contacts et des consentements, ainsi qu'une API vers les systèmes de vente et de service client, devraient être une condition de l'appel d'offres, pas une option.

Étape 4. Comparez le coût total, pas le prix de la licence

Les offres méritent d'être comparées en coût total sur plusieurs années : achat et mise en œuvre, maintenance et licences, évolutions et coût de sortie du contrat. La licence la moins chère s'avère parfois la plus coûteuse en troisième année, lorsque chaque modification de processus devient une commande payante auprès d'un seul partenaire. La comparaison se fait idéalement sur vos propres scénarios : demandez à chaque fournisseur de traiter le même cas complexe tiré de votre entreprise. Pour en savoir plus sur l'évaluation des offres : évaluation des offres et entretiens avec les fournisseurs.

Étape 5. Réception et contrat de maintenance

Le système doit être réceptionné selon des scénarios de test et des critères convenus à l'avance, et non sur la base des seules déclarations du fournisseur. Le contrat de maintenance doit préciser les délais de correction des erreurs, qui apporte les modifications et à quel coût, et confirmer les clauses relatives à l'export des données et à la sortie du contrat.

Un exemple tiré de la pratique

Au sein d'un groupe de filiales d'un groupe international, l'entreprise utilisait un système ERP centralisé, tout en ayant besoin d'automatiser des processus financiers du domaine procure-to-pay, et ce conformément aux directives d'achat du groupe (corporate purchasing guidelines). La tentation était forte de se tourner vers les outils collaboratifs du groupe, mais ceux-ci se sont révélés assez coûteux et ne répondaient ni aux exigences d'indépendance, ni à celles d'une sortie facile en cas de problème.

Lors des réunions avec les parties prenantes, nous avons préparé une description détaillée des besoins, allant au-delà des fonctions standards des solutions prêtes à l'emploi. Nous avons élaboré plusieurs modes d'intégration alternatifs avec les systèmes métier, ainsi que des mécanismes limitant le risque de dépendance à un seul fournisseur. Le résultat a été une stratégie applicative cohérente, fondée sur des standards, et un environnement où de nouveaux circuits naissent de manière agile, par prototypage lors de réunions courtes avec les propriétaires de processus, y compris non techniques. Cet environnement vient compléter le système ERP : il offre une grande flexibilité là où l'entreprise se différencie, sans les coûts de grandes implémentations.