> Choix de progiciel

Choix de progiciel : décider avant que le marché décide

Le consultant qui vous accompagne intervient auprès de la DSI comme des directions métier. Il cartographie vos besoins par domaine avant de regarder le marché, puis mesure ce qu'un progiciel couvre vraiment. Vous choisissez sur une carte, pas sur une démonstration.

Échanger sur votre choix

4 mois : la durée moyenne d'une mission.

La plupart des choix de progiciel partent de l'offre, pas du besoin

Un progiciel ne couvre jamais tout. La question n'est pas lequel choisir, mais quelle part de votre besoin il doit porter et ce qui restera spécifique. Cette part se mesure avant de rencontrer un éditeur. Après, elle se négocie contre un catalogue.

Le besoin s'écrit avec les mots d'un éditeur

Les premières démonstrations installent un vocabulaire et un découpage. Les exigences qui suivent épousent ce découpage. On compare alors des produits entre eux, et non des réponses à un besoin.

Le périmètre se découvre en cours de route

Ce que le progiciel ne fera pas apparaît au paramétrage, quand le contrat est signé. Les développements spécifiques arrivent en surcoût, et le calendrier absorbe la découverte.

Un seul prestataire finit par tenir le système

L'intégrateur qui a cadré, choisi et déployé devient le seul à savoir. La dépendance ne se décide jamais, elle s'installe.

Objectiver le besoin avant de comparer les offres

Cartographier

Les domaines fonctionnels, les acteurs de l'écosystème et les contraintes structurantes. L'existant est relevé tel qu'il tourne, pas tel qu'il est documenté.

Pondérer

Chaque exigence reçoit un niveau d'ambition et un poids, arrêtés avec le métier et la DSI. La grille existe avant le premier contact avec le marché.

Confronter

Le panorama est filtré par la grille, et non l'inverse. Couverture, intégration, hébergement, coût complet sur trois ans. Il en sort une liste courte et une recommandation argumentée.

Ce que nous ne faisons pas

Partir d'une liste d'éditeurs. Un comparatif ne devient utile qu'une fois les exigences pondérées. Avant, il classe des produits selon des critères que personne n'a choisis.

Écrire le besoin après les démonstrations. Une démonstration montre ce que l'outil sait faire, pas ce dont vous avez besoin. L'ordre compte plus que la qualité de l'analyse.

Confier le cahier des charges à un candidat. Celui qui écrit l'exigence choisit le gagnant. Nous écrivons, vous arbitrez, les éditeurs répondent.

Ce qu'un conseil indépendant change selon votre situation

Le support de votre progiciel s'arrête

Le consultant chiffre l'opportunité et la trajectoire avant que l'échéance impose le calendrier

Une décision prise tôt, pas subie

Un seul prestataire tient votre système

Le consultant cartographie les domaines et mesure ce qu'un progiciel du marché couvre vraiment

Un périmètre repris par vous, pas par lui

Les éditeurs ont déjà cadré le besoin

Le consultant réécrit l'exigence par domaine et la pondère avant toute démonstration

Une grille qui compare, au lieu de promesses à départager

Le choix devra être défendu en interne

Le consultant documente les scénarios, leur coût complet et leurs points de vigilance

Un dossier qui tient devant un COMEX

Trois types d'intervention sur un choix de progiciel

Le choix d'un progiciel recouvre plusieurs niveaux d'intervention. Trois concentrent l'essentiel de la demande.

Note d'opportunité

Le support s'arrête dans quelques années, ou l'outil ne suit plus. Personne ne sait encore s'il faut changer, ni quand, ni pour quel ordre de grandeur. Le consultant instruit la question en quelques semaines et produit une note courte, orientée décision, que le sponsor porte devant son instance. La liberté de choix et de négociation se préserve en décidant tôt.

Cadrage et choix

Le besoin n'est écrit nulle part, ou il l'est dans les termes d'un éditeur. Le consultant tient des ateliers métier et informatique, en sort une grille d'exigences pondérée par domaine, puis confronte le marché à cette grille. Panorama, coût complet sur trois ans, liste courte de un à trois scénarios. La recommandation est argumentée, et elle tient devant un COMEX.

Conduite de l'appel d'offres

La cible est connue, reste à la faire chiffrer. Le consultant écrit un cahier des charges qui décrit des besoins et non un produit, qualifie les répondants, dépouille et instruit le choix de l'intégrateur. Le périmètre confié au progiciel et celui qui reste spécifique sont tranchés avant la consultation, pas pendant.

Le profil de votre consultant

Tous les consultants ne sont pas indépendants des éditeurs. Quelques traits distinguent ceux que nous mobilisons sur les choix les plus engageants.

Agnostique

Pas de préférence pour un éditeur. Le bon périmètre pour un progiciel est celui que votre besoin justifie, pas celui que son catalogue couvre.

Bilingue

Comprend le processus métier et l'architecture d'intégration qui le portera. Traduit une exigence métier en critère évaluable, et une contrainte technique en risque de calendrier.

Sceptique

Une démonstration n'est pas une preuve de couverture. Vérifie chaque exigence contre la grille, et écrit ce que la solution ne fera pas.

Transparent

Documente les critères, leur pondération et les écarts au fil de la mission, pas à la fin. La décision se relit un an plus tard, par quelqu'un qui n'était pas là.

Démarche d'une mission de choix de progiciel

Un comité de pilotage valide et clôt chaque phase avant d'engager la suivante.

Parler à un consultant

Cadrer

Figer le périmètre, les axes d'analyse et leur pondération, les acteurs à mobiliser. Ce qui reste hors périmètre s'écrit au même moment que ce qui y entre.

Matérialiser le besoin

Des ateliers métier et des ateliers informatique, deux heures chacun, préparés sur pièces et non sur page blanche. Il en sort une grille d'exigences pondérée par domaine, une cartographie fonctionnelle et une cartographie applicative. Les éditeurs n'entrent qu'après, une fois la grille arrêtée.

Étudier le marché

Le panorama est filtré par la grille, et non l'inverse. Chaque solution est évaluée sur la couverture fonctionnelle, la capacité d'intégration, l'hébergement et la sécurité, et le coût complet sur trois ans. Il en sort une liste courte de un à trois scénarios.

Décider

Une note courte, orientée décision, avec une recommandation argumentée et ses points de vigilance. Les livrables de la mission en constituent les annexes.

Questions fréquentes

Faut-il choisir le progiciel ou l'intégrateur en premier ?

Le périmètre d'abord. Tant que la part du besoin confiée au progiciel n'est pas arrêtée, les deux choix se contaminent : l'intégrateur oriente vers son catalogue, et le progiciel impose son découpage. Le périmètre se tranche avant la consultation, et il s'écrit dans le cahier des charges.

Combien de solutions faut-il comparer ?

Une liste courte de un à trois scénarios. En dessous, il n'y a pas de choix à instruire. Au-delà, la comparaison devient un exercice documentaire que personne ne relit. Le filtrage se fait sur la grille pondérée, pas sur le nombre de candidats.

Un conseil indépendant coûte-t-il plus cher qu'un cadrage par l'intégrateur ?

Le cadrage par l'intégrateur est rarement facturé. Il se paie dans le périmètre retenu et dans les développements spécifiques découverts après la signature. La question n'est pas le coût du cadrage, mais celui des écarts qu'il évite.

Peut-on garder son progiciel actuel ?

C'est un scénario comme un autre, et il doit figurer dans la comparaison. Une fin de support n'impose pas un remplacement : elle impose une décision. Le maintien a un coût et un horizon, qui se chiffrent au même titre que les autres.

Qui doit participer aux ateliers ?

Le métier qui exécute le processus et la DSI qui portera l'intégration, séparément. Les ateliers métier qualifient l'exigence et son niveau d'ambition. Les ateliers informatique traitent l'hébergement, les interfaces et la sécurité. Mélanger les deux produit des réunions où chacun attend son tour.

Que se passe-t-il si le besoin évolue après le choix ?

La grille pondérée reste le document de référence. Un besoin nouveau se compare à ce qui a été arbitré, et la décision se relit avec ses critères d'origine. C'est l'intérêt d'avoir écrit les pondérations avant les démonstrations.

Un choix de progiciel à instruire ?

Un premier échange pour cadrer la question, sans engagement.

Échangeons sur votre projet de progiciel