Un outil arrive en fin de vie, un processus repose encore largement sur Excel, les équipes passent trop de temps sur des tâches manuelles, une nouvelle réglementation impose de revoir les pratiques… Le constat est « Il nous faut un nouvel outil. »
Le réflexe qui suit est tout aussi rapide : commencer à regarder les solutions disponibles sur le marché. Pourtant, à ce stade, la première question ne devrait peut-être pas être « Quel outil choisir ? », mais plutôt « De quoi avons-nous réellement besoin ? »
C’est un réflexe que j’ai rencontré dans les projets de transformation que j’accompagne : la recherche de solutions démarre alors même que la cible n’est pas encore posée. Avant de comparer les éditeurs et leurs fonctionnalités, encore faut-il avoir une vision précise de ce que l’on attend de son futur SI. Pour cela, plusieurs sujets doivent être validés en amont.
Quel périmètre doit-il couvrir ?
C’est le premier élément à cadrer : quelles entités ? Quels pays ? Quelles BU ? Quelles populations ? Pour quels usages ?
À cela s’ajoute une dimension parfois oubliée : les volumes. Combien d’utilisateurs, de transactions, de données à traiter ? Avec quelle fréquence et quels éventuels pics d’activité ?
Je l’ai vu à plusieurs reprises : ce qui ressemble à une simple question de périmètre en phase de cadrage peut devenir quelques mois plus tard une nouvelle interface à développer, des cas de gestion supplémentaires à traiter ou des populations entières à intégrer. Avec, derrière, des impacts très concrets sur le planning et le budget.
Comment doit-il s’intégrer au SI existant ?
Une nouvelle application ne fonctionne jamais seule. Quelles interfaces faudra-t-il construire ? Avec quelles applications ? Où se situe la donnée de référence ? Quel système en est maître ? Comment les flux doivent-ils circuler et à quelle fréquence ? Ces sujets sont structurants pour évaluer la faisabilité et la complexité du projet, mais aussi pour anticiper suffisamment tôt la contribution de la DSI. On sait à quel point sa disponibilité est un sujet.
Sur le terrain, les interfaces font partie des sujets que l’on pense simples au départ et qui deviennent structurants par la suite. Derrière un « il suffira de récupérer la donnée depuis l’ERP » se cachent parfois plusieurs sources, des référentiels différents ou des règles de gestion qui n’avaient pas été formalisées.
Comment veut-on fonctionner demain ?
C’est à mes yeux la question la plus importante. Avant de sélectionner une solution, il faut avoir posé ses processus actuels, identifié leurs irritants et dessiné leurs fonctionnements cibles.
Que souhaite-t-on automatiser ? Quels contrôles conserver ? Quels rôles faire évoluer ? Quelles étapes supprimer ? Quels cas de gestion sont réellement structurants ? Et quelles évolutions doit-on être capable d’absorber demain ? L’objectif n’est pas de reproduire l’existant à l’identique, ni de développer du spécifique partout. Il faut savoir ce qui peut être adapté au standard et ce qui constitue une exigence métier sur laquelle l’entreprise ne souhaite pas transiger. C’est cette vision qui permettra ensuite d’arbitrer intelligemment entre adaptation des pratiques et paramétrage de la solution.
C’est le point sur lequel mon expérience projet m’a le plus convaincue : lorsqu’une cible n’est pas suffisamment définie en amont, on se retrouvera à faire de la conception en recette voire post mise en production (j’ai écrit tout un article à ce sujet). Le projet deviendra alors bien plus coûteux et son planning d’exécution sera drastiquement rallongé.
« Vous ne choisirez plus la solution en fonction de votre cible, vous dessinerez votre cible en fonction de la solution. »
Quelles contraintes techniques devront être respectées ?
Enfin, la DSI dispose de règles qui conditionneront la sélection : stratégie SaaS ou on-premise, principes d’architecture, SSO, gestion des habilitations, RGPD, hébergement, cybersécurité, exigences de disponibilité ou encore modalités d’exploitation.
Ces contraintes doivent être connues dès le départ. Il serait dommage d’arriver au terme d’une consultation, avec une préférence largement partagée par les métiers, pour découvrir que la solution retenue ne peut tout simplement pas s’intégrer dans l’écosystème de l’entreprise.
Alors, par quoi commencer ?
Prenez le temps de définir où vous souhaitez aller. Périmètre, volumes, processus cibles, données, architecture, contraintes techniques : poser ces éléments avant de regarder le marché vous permettra de construire votre propre grille de lecture et de comparer les différentes offres sur ce qui compte réellement pour votre entreprise.
Consulter trop tôt les solutions existantes comporte le risque majeur de se laisser séduire par les fonctionnalités mises en avant lors des démonstrations et les éditeurs sont généralement plutôt bons à cet exercice. Vous ne choisirez plus la solution en fonction de votre cible mais vous allez dessiner votre cible en fonction de la solution.
Chez Insyte, nous accompagnons les entreprises dans cette réflexion amont : définir la cible, formaliser les attentes et construire le cahier des charges qui permettra ensuite d’interroger le marché avec les bonnes questions et surtout ses propres critères de choix.
À retenir
- Avant de regarder le marché, la vraie question est : de quoi avons-nous réellement besoin ?
- Périmètre et volumes se cadrent dès le départ, sous peine d’impacts lourds sur le planning et le budget.
- L’intégration au SI existant (interfaces, donnée de référence, système maître) est souvent plus structurante qu’il n’y paraît.
- Les processus cibles se dessinent avant de choisir l’outil, en distinguant standard et exigences métier non négociables.
- Les contraintes techniques de la DSI doivent être connues avant la consultation.
- Choisir l’outil en fonction de sa cible, et non dessiner sa cible en fonction de l’outil.
