Choix de logiciel : un Proof Of Concept (POC) est-il nécessaire ?
Certains éditeurs et intégrateurs vous proposent un POC (Proof-Of-Concept) pour valider la faisabilité d'un projet. Le plus souvent c'est le client qui en fait la demande. Est-ce une phase de confort pour rassurer le client ou est-ce une opération obligatoire pour réduire les risques ?
Avantages et inconvénients d'un POC pour le client
Il existe un certain nombre d'avantages concernant la preuve de concept (POC) pour le client, voici les principaux :
- La synchronisation des attentes avec le fournisseur ;
- Une meilleure appropriation du processus de mise en œuvre ;
- L’identification des déficiences fonctionnelles ou de la surévaluation ;
- Une meilleure compréhension des investissements requis. Un cadre plus précis permet de mieux comprendre l'investissement requis pour compléter la mise en œuvre ;
- L’évaluation du partenaire de mise en œuvre. Le processus inhérent POC permet au client d'évaluer le logiciel et le partenaire de mise en œuvre.
Il existe également des limites de la POC qui doivent être notées. Ce sont :
- La flexibilité commerciale. La flexibilité intégrée à certains arrangements POC qui permettent au client de pouvoir se retirer sans acheter le logiciel est rarement considérée dans la réalité, car un investissement important en argent et en temps a été effectué. Par ailleurs, le client prend souvent la décision de se lancer dnas un POC sans évaluer complètement toutes les solutions en raison du faible risque de cette option.
- L’exercice de vente. Selon les accords commerciaux en place, le POC peut être intégré au cycle de vente, de sorte que la capacité du fournisseur de divulguer l’intégralité de cette information est restreinte. En outre, la documentation produite dans le POC peut avoir un contenu marketing qui n'ajoute aucune valeur au projet.
Cet article est le deuxième volet d'un tutoriel en deux parties. La première partie était consacrée à l’analyse de la structure d'un POC et la manière dont elle correspond au processus de sélection.
Avantages et inconvénients d'un POC pour le vendeur
Voici les avantages pour le fournisseur :
- Avoir un avantage concurrentiel dans le processus de vente. Le POC est un autre outil dans la boîte à outils de vente. Le POC peut être utilisé pour faire passer le client potentiel à l’étape suivante du processus de vente sans que celui-ci n’ait à s’engager pleinement.
- Meilleures mise en œuvre et clients satisfaits. Un facteur de réussite clé pour tout VAR ou fournisseur de logiciels est d'avoir des clients prêts à servir de référence. Tout outil qui améliore la satisfaction du client doit être examiné.
Voici les inconvénients pour le vendeur :
- L’échéancier de la vente. Le POC peut prolonger le processus de vente. En outre, l’échéancier (important pour les sociétés cotées en bourse) devient plus incertain, ce qui peut entraîner une nouvelle baisse de prix.
- Les demandes de conseils en ressource. En raison de la nature de la POC, les demandes de conseils peuvent être importantes et consommatrices de ressources. En règle générale, des consultants plus expérimentés sont tenus de veiller à ce que le POC donne lieu à un bon de commande.
Quand doit être réalisée un POC ?
Un POC doit être réalisé dans le cadre du processus de sélection lorsque le risque d'échec du projet est relativement élevé. Le risque peut être mesuré par l’intermédiaire de deux variables clés. Ces variables sont la complexité des exigences et du niveau d'expertise au sein de l'équipe de sélection et de mise en œuvre (MOE). Plus les exigences du système sont complexes, plus les avantages obtenus à partir d’un POC sont importants. La complexité peut être mesurée par le nombre et la nature des modules mis en œuvre, la part de personnalisation, le nombre d'interfaces et la quantité et la qualité des données à convertir.
Le nombre de modules à mettre en œuvre (par exemple, une mise en œuvre uniquement financière par rapport à une mise en œuvre financière + distribution + stockage) augmente l’étendue de la mise en œuvre, et donc du risque. En outre, la nature des modules à employer influe également sur le risque. Les modules tels que l'automatisation des forces de vente (SFA) dans une suite de gestion de la relation client (CRM) ont tendance à avoir un profil de risque plus élevé que les modules financiers tels que les comptes débiteurs.
Le niveau d'expertise au sein de l'équipe de sélection/mise en œuvre est également un indicateur important. Les facteurs à prendre en compte sont :
- La connaissance du secteur
- La connaissance des processus opérationnels existants
- La compréhension du processus de sélection du logiciel de grande valeur
- La connaissance de la gestion des fournisseurs de logiciels
- La connaissance des systèmes ERP/CRM
Ces facteurs doivent être utilisés pour mesurer les compétences de votre équipe. Une équipe des plus compétentes permet de réduire le facteur risque pour le projet.
Le tableau ci-dessous représente ces facteurs et la façon de déterminer si une POC est requise pour le processus de sélection :
Au sujet de l’auteur
Robert Rudd est un conseiller expert en matière de solution ERP avec plus de neuf années d'expérience dans la mise en œuvre des systèmes ERP. Son expérience comprend également les technologies de l'information qui prennent en charge les clients dans le secteur financier et bancaire. Il a mis en place des systèmes ERP dans un certain nombre d'industries, mais il est spécialisé dans la gestion de la chaîne d'approvisionnement. Rudd travaille pour la société Scalable Data System basée en Australie. Scalable Data Systems met en œuvre des solutions d'entreprise pour le marché intermédiaire depuis plus de vingt ans.