Implémentation de logiciel : le Proof of Concept

Il fait partie des étapes du processus d’implémentation d’un logiciel au sein d’une entreprise dans un environnement client défini. Le but est de s’assurer du bon fonctionnement du programme selon les promesses de l’éditeur. Le test comprend des livrables et documents d’architecture qui devront faciliter l’adoption par les opérateurs.

Ce processus permet en outre de tester le logiciel avant la phase de lancement d’un prototype plus avancé. Cet avant-prototype souvent simplifié au maximum permet aux éditeurs de se faire une idée concrète des besoins réels du marché. Cela représente une étape moins abstraite qu’une simple étude de marché.

À quel moment lancer le Proof of Concept ?

La commercialisation d’un logiciel obéit à un certain cycle de vente. Le Proof of Concept intervient idéalement vers la fin de ce cycle et se présente comme la base du projet d’implémentation. Ainsi, il est important à cette étape pour une entreprise de ne travailler qu’avec un seul éditeur. Il est question de réduire les coûts, les efforts des ressources humaines liées à la compréhension souvent complexe des programmes.

La mise en place du POC à une étape jeune du cycle de vie du logiciel expose l’entreprise à certains risques. Notamment lors des phases d’installation et de paramétrage du logiciel ou de l’ERP. Cela implique une sollicitation accrue des ressources de votre entreprise. Pour l’éditeur, cela représente le risque de s’exposer à un rejet du programme de la part de l’entreprise en test.

Comment créer un Proof of Concept ?

Comme expliqué précédemment, le Proof of Concept est un test dont les fondations sont axées sur des fiches détaillant les processus métiers d’une entreprise. Ce test doit respecter certaines étapes clés pour une réussite complète.

• Un planning en tenant compte de celui de l’ensemble du projet de l’entreprise.
• Rédaction d’un document définissant de façon exhaustive le projet à venir. Avec une charte, plan, règles …
• Une description avancée des scénarios de tests.

L’objectif final du POC sera de tester l’éditeur en tant que partenaire fiable. Comme par exemple sa capacité à disposer des compétences permettant d’accompagner la transformation. Le POC aura pour but de combler les besoins métiers au moment de l’implémentation.

Les risques d’opter pour un logiciel ou un ERP sans passer par le POC

L’erreur que commettent certains DSI consiste généralement à opter pour un ERP en se basant uniquement sur une démo. Les slides délivrés par les commerciaux promettent bien sûr un fonctionnement et une réponse adaptée aux besoins métiers. Cependant, il est toujours nécessaire de confronter le produit en le mettant à l’épreuve des besoins et des processus. Le risque est de se retrouver avec un logiciel ne répondant pas aux besoins et n’assurant pas la couverture fonctionnelle nécessaire.

Votre entreprise dispose certes de profils métiers compétents. Toutefois, il peut être nécessaire de faire intervenir ces profils lors de tests axés sur une feuille de route bien établie. Ne pas passer par cette phase d’épreuve ne permettra pas de soulever des questions relatives à des problèmes auxquels les destinataires de la solution n’auront même pas été confrontés.

Par ailleurs, ne pas effectuer de POC expose votre entreprise au risque d’opter pour un éditeur/intégrateur sans vous assurer de son professionnalisme. Il est important de vous assurer que l’éditeur a pris en compte les spécificités de vos besoins métiers en optant pour une phase de tests grandeur nature.

Opter pour un Proof of Concept vous procure donc un certain nombre d’avantages. Cela permet en effet d’identifier les limites fonctionnelles et d’appréhender les processus de façon optimale. Mais aussi d’avoir une meilleure vue d’ensemble des investissements requis, sans oublier une évaluation préalable de votre éditeur/intégrateur.