Les facteurs de succès décrits ci-dessous sont basés sur le retour d’expérience clients ainsi qu’un savoir faire en matière de développement de POC e-Achats. Ces règles jettent les bases d’un POC e-Achats efficace et présentent les écueils à éviter lors de sa mise en œuvre.

Limiter le périmètre du POC. Un POC sert à tester quelques cas d’utilisation, il ne remplace pas la mise en mise en œuvre du projet … au contraire il la retarde. Un POC est une opportunité pour l’organisation Achats d’une société, de tester la solution dans son contexte et son environnement, en utilisant ses propres données. Limiter son scope à un périmètre « gérable » – en termes de volume de données, de fonctionnalités et d’individus impliqués – permet à l’équipe projet de réaliser dans un lapse de temps limité toutes les opérations nécessaires à démontrer l’adéquation du logiciel avec les attentes clients.

Rédiger des cas d’utilisation reflétant les propres processus achats et la solution désirée. Un POC exige un travail important afin de concevoir des cas d’utilisation spécifiques à l’organisation Achats, auxquels les cas d’utilisation standards fournis par l’éditeur ne peuvent se substituer. Ils doivent décrire des scénarios particuliers d’utilisation de la plateforme par chacune des catégories d’utilisateurs. Il est plus efficace de se concentrer sur les cas les plus probables et courants et de ne pas passer trop de temps à la formulation d’hypothèses ou cas d’exception.

Allouer suffisamment de temps pour permettre à l’éditeur de réagir aux commentaires et faire les ajustements nécessaires. Un POC n’est pas simplement une occasion de vérifier l’ergonomie et l’adéquation du système avec les attentes du client, il permet aussi d’observer comment l’éditeur réagit face aux ajustements demandés. Lors d’un POC, le logiciel sera testé ainsi que le niveau de service et de support lors de la mise en œuvre de la solution e-Achats.

Définir des indicateurs de performance du POC convenus par les deux parties. Ces indicateurs permettent d’évaluer sur des critères prédéfinis, la performance de la solution par rapport aux objectifs et de s’engager sereinement en faveur d’un éditeur.

Dans la phase d’évaluation, impliquer des utilisateurs ayant une connaissance des processus et provenant des différentes Directions qui auront à utiliser la solution. Par ailleurs, leurs commentaires et leurs attentes doivent être intégrés au POC afin de faciliter l’adoption ultérieure de la solution par la communauté d’utilisateurs.

Un POC eAchats est souvent la première étape d’un déploiement réussi. En tant que tel, il doit être envisagé comme un moyen de développer une meilleure connaissance du logiciel et de l’éditeur afin de réduire les risques auxquels l’entreprise s’expose lors de sa prise de décision finale.

Que ce soit un déploiement d’une full-suite ou d’un module unique, un POC offre la possibilité de solliciter l’avis des utilisateurs finaux sur les capacités du logiciel - dès le début du cycle de développement - et permet également à l’éditeur d’identifier en amont du projet des enjeux techniques et fonctionnels pouvant interférer avec le succès du projet. Réaliser un POC requiert donc du temps et un investissement de la part de la direction de l’entreprise mandatrice et de l’éditeur, il n’est pas systématique et dépend souvent de l’organisation Achats ou des Systèmes d’Informations. Cette phase doit permettre non seulement de vérifier que les qualités et les fonctionnalités présentées en avant-vente sont réelles mais aussi de susciter le support et l’approbation des parties prenantes dans la réalisation du projet e-Achats ainsi que de tester la réactivité et la qualité des équipes projets côté éditeur.