Le Proof of Concept pour évaluer un Logiciel – Par Franck Le Tendre, Directeur Général de SynerTrade

stickman success

Le processus de sélection d’un éditeur de logiciels est souvent décrit par les chefs de projets ou les analystes comme l’un des exercices les plus difficiles qu’une organisation puisse avoir à appréhender. L’effort de faire venir des éditeurs, de sortir des collaborateurs de leurs tâches quotidiennes, d’écouter des présentations « prêtes à l’emploi », de comparer ses notes et de sélectionner un produit parmi d’autres représente à lui seul un coût si significatif que la conclusion de ce processus peut souvent être le non-choix. Essayer en plus d’obtenir l’adhésion des utilisateurs finaux ne fait qu’ajouter au délai, au coût et à l’effort. Il n’est ainsi par rare de voir le coût indirect lié au processus d’évaluation représenter à lui seul jusqu’à 25% du prix du logiciel considéré. Certaines études indiquent que ces entreprises qui choisissent un logiciel établissent plus ou moins malgré elles les conditions d’un projet défaillant en créant des prérequis qui ne sont pas bien compris ou mal partagés avant le démarrage du projet, en formant des utilisateurs finaux sur la base d’une version non définitive du logiciel, en changeant les spécifications métiers pendant les phases de configuration du logiciel, ou en imposant des méthodologies qui empêchent l’application des bonnes pratiques.

Un « Proof Of Concept » doit s’utiliser comme une étape du projet d’implémentation. Il permet au comité d’évaluation de s’épargner les présentations « prêtes à l’emploi » et de se focaliser sur la compréhension réelle des capacités de l’outil et de la société éditrice. Dans le cycle d’achat, l’étape de Proof Of Concept permet à l’entreprise de mieux se focaliser sur les sujets importants, de créer les conditions d’une meilleure adoption par la communauté des utilisateurs, d’initier le changement, d’implémenter les bonnes pratiques et de poser les bases d’un déploiement réussi.

Qu’est-ce qu’un Proof Of Concept?

Un Proof Of Concept est un test d’un logiciel applicatif basé sur la construction d’un prototype architecturé autour de processus métiers documentés. C’est la première étape du processus d’implémentation qui clarifie les besoins métiers et les attendus en matière de configuration. Le Proof Of Concept requiert de donner accès au logiciel dans l’environnement du client afin de s’assurer de son bon fonctionnement selon la promotion qu’en a fait l’éditeur. Les livrables d’un Proof Of Concept incluent, en général, un document de cadrage qui détaille les processus métiers et les bonnes pratiques, des tests approfondis sur les capacités du logiciel et de l’éditeur, ainsi que des plans de formation et une communication qui facilitent l’adoption des utilisateurs, et enfin des documents d’architecture (mapping des données, interfaces, règles de conversions, etc.). Au final, définir un Proof Of Concept en tant qu’étape du projet, permet de confronter les utilisateurs aux enjeux métiers.

Quand faut-il lancer un Proof Of Concept ?

Du fait du périmètre et de la complexité, le Proof Of Concept intervient plutôt vers la fin du cycle de vente et se prolonge comme le premier jalon du projet d’implémentation. Il en résulte qu’une organisation ne devrait travailler à cette étape qu’avec un seul éditeur, et ce pour une myriade de raisons : les coûts et les efforts importants dédiés à la compréhension des capacités de la solution logicielle, le temps dépensé à recueillir les besoins métiers, la réallocation des ressources humaines, les dépenses de voyages, les efforts pour produire la documentation des processus, la profondeur des tests et le niveau d’implication de l’éditeur… A contrario, si le Proof Of Concept intervient plus tôt dans le cycle, une entreprise devra réaliser en double la première étape de l’installation et du paramétrage du logiciel. Il en résultera au final que les coûts, les efforts et l’utilisation des ressources seront décuplés et que cela créera une plus forte probabilité de « non-choix ». Positionner le Proof Of Concept comme la première étape du projet est une bonne pratique qui implique de devoir finaliser le processus de sélection avec un seul éditeur ; il va sans dire qu’il est dans l’intérêt de l’entreprise de prévenir le deuxième éditeur de la situation dans l’hypothèse où l’éditeur retenu faillirait à bien dérouler le Proof Of Concept. Au final, mettre le Proof Of Concept en première étape du projet permet de comprendre les attentes métier sur une base méthodologique qui donnera le ‘la’ à une implémentation réussie.

Créer un Proof Of Concept

Comme indiqué précédemment, un Proof Of Concept est un test d’un applicatif architecturé à partir de documents détaillant les processus métiers. Le planning du Proof Of Concept devrait être correctement établi et proportionnel au planning global du projet. Par exemple, un projet d’implémentation de 8 mois ne devrait pas inclure une phase de Proof Of Concept supérieure à 1,5/2 mois. Comme il s’agit de la première étape de l’implémentation, la première tâche recouvre la rédaction d’un document de cadrage fonctionnel qui inclue la charte et le plan projet, la définition des ateliers de formation, des ateliers de design, un travail sur les données (règles de conversion, interfaces, etc.), et enfin la description des scénarios de tests. Les livrables devront inclure un plan projet détaillé et son RACI (matrice Responsible, Accountable, Consulted, Informed), les supports de formation, le document de cadrage fonctionnel et technique, un environnement de développement et de production, une analyse d’écarts, et les scénarios de tests. Le plan projet est généralement fourni par l’éditeur et conduit par l’organisation. La formation produit permet aux équipes de l’organisation de se familiariser avec le paramétrage du logiciel et évidemment de former les utilisateurs finaux. L’analyse des gaps est généralement conduite à l’issue des sessions de formation et peut à l’occasion découler d’un RFI (Request For Information) ou d’un RFP (Request For Proposal). Il est également important de travailler sur un environnement de développement (ou de test) préalablement à la migration vers l’environnement de production. Dans la plupart des cas, l’étape de ‘testing’ inclut les phases d’acceptance des utilisateurs ainsi que de la technique ; l’acceptance utilisateur est notamment importante lorsqu’il s’agit d’évaluer des fonctionnalités ou un processus où le résultat devra être binaire (accepté ou rejeté). Par exemple, le produit peut-il analyser des données sur plus de quatre axes analytiques : la réponse ne peut-être que ‘oui’ ou ‘non’. Les tests d’acceptance (UAT) sont également utiles pour obtenir l’adhésion des utilisateurs clés, surtout si ces derniers sont influenceurs auprès de leurs pairs. Les stress test, quant à eux, doivent mesurer les capacités techniques de la solution en matière de temps de réponse et de rapidité des principaux traitements. En dernier lieu, le Proof Of Concept devra permettre de tester l’éditeur en tant que « partenaire » ; par exemple, a-t-il des compétences et des experts pour accompagner le changement ? Est ce qu’il a les facultés de déployer les bonnes pratiques dans l’organisation ? A-t-il l’expérience pour nous assister dans les développements des workflows ? etc. Ainsi, définir le Proof Of Concept comme une étape de l’implémentation permet de solidifier les besoins métiers à l’heure de configurer le logiciel.

Conduire un Proof Of Concept

Le Proof Of Concept se déroule traditionnellement entre les murs du client. Un espace dédié devrait être préparé pour les utilisateurs finaux afin qu’ils puissent se retrouver et dérouler le Proof Of Concept dans les meilleures conditions. Le groupe devrait être constitué d’un mix « d’inter et d’intra » départements : les « inters » sont ces domaines susceptibles d’être affectés par la suppression des silos d’information ou par des interfaces ; les « intra-départements » sont intéressés par l’acceptation des utilisateurs finaux. Les ressources leur étant affectées devraient être bien respectées au sein de cette communauté car leur acceptation du nouveau système est largement corrélé à l’adoption de l’ensemble des utilisateurs finaux. Selon la nature des engagements contractuels, les responsabilités de l’organisation porteront sur la gestion globale du projet. Cela inclut la gestion du périmètre du proof of concept, son délai et son coût. L’organisation concernée devra également être disponible pour fournir l’ensemble des ‘inputs’ nécessaire à la définition du cadrage, communiquer avec les utilisateurs finaux pour favoriser l’adoption et le bon niveau de motivation, participer activement à la configuration du logiciel, et dérouler les scénarios de tests. Quant à l’éditeur de logiciel, ses responsabilités incluent la fourniture du document de cadrage, le déploiement des bonnes pratiques, la configuration/paramétrage du logiciel, la correction des (éventuelles) anomalies, et la coordination des activités de ‘testing’. Ainsi, définir le Proof of Concept comme une étape du projet d’implémentation est un moyen d’adopter les bonnes pratiques dès le départ.

Conclusion

Un proof of concept, en tant qu’étape de l’implémentation, est le premier pas vers un projet réussi. En tant que tel, il ne faudrait pas l’envisager durant le processus d’évaluation, mais plutôt comme un moyen de développer une compréhension approfondie du logiciel et de l’éditeur, et, ultimement comme un moyen de limiter les risques projet. Il permettra de former les utilisateurs à l’outil et aux enjeux métiers, il consolidera les spécifications fonctionnelles, il intégrera les bonnes pratiques et il servira de tremplin à un projet réussi.

Related Topics
Author
By
@coesteve1
Related Posts

Readers Comments


Add Your Comment

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

In The News

Le Proof of Concept pour évaluer un Logiciel – Par Franck Le Tendre, Directeur Général de SynerTrade

stickman success 6th octobre, 2015

Le processus de sélection d’un éditeur de logiciels est souvent décrit par les chefs de projets ou les analystes comme l’un des exercices les plus difficiles qu’une organisation puisse avoir à appréhender. L’effort de faire venir des éditeurs, de sortir des collaborateurs de leurs tâches quotidiennes, d’écouter des présentations « prêtes à l’emploi », de comparer ses notes et de sélectionner un produit parmi d’autres représente à lui seul un coût si significatif que la conclusion de ce processus peut souvent être le non-choix. Essayer en plus d’obtenir l’adhésion des utilisateurs finaux ne fait qu’ajouter au délai, au coût et à l’effort. Il n’est ainsi par rare de voir le coût indirect lié au processus d’évaluation représenter à lui seul jusqu’à 25% du prix du logiciel considéré. Certaines études indiquent que ces entreprises qui choisissent un logiciel établissent plus ou moins malgré elles les conditions d’un projet défaillant en créant des prérequis qui ne sont pas bien compris ou mal partagés avant le démarrage du projet, en formant des utilisateurs finaux sur la base d’une version non définitive du logiciel, en changeant les spécifications métiers pendant les phases de configuration du logiciel, ou en imposant des méthodologies qui empêchent l’application des bonnes pratiques.

Un « Proof Of Concept » doit s’utiliser comme une étape du projet d’implémentation. Il permet au comité d’évaluation de s’épargner les présentations « prêtes à l’emploi » et de se focaliser sur la compréhension réelle des capacités de l’outil et de la société éditrice. Dans le cycle d’achat, l’étape de Proof Of Concept permet à l’entreprise de mieux se focaliser sur les sujets importants, de créer les conditions d’une meilleure adoption par la communauté des utilisateurs, d’initier le changement, d’implémenter les bonnes pratiques et de poser les bases d’un déploiement réussi.

Qu’est-ce qu’un Proof Of Concept?

Un Proof Of Concept est un test d’un logiciel applicatif basé sur la construction d’un prototype architecturé autour de processus métiers documentés. C’est la première étape du processus d’implémentation qui clarifie les besoins métiers et les attendus en matière de configuration. Le Proof Of Concept requiert de donner accès au logiciel dans l’environnement du client afin de s’assurer de son bon fonctionnement selon la promotion qu’en a fait l’éditeur. Les livrables d’un Proof Of Concept incluent, en général, un document de cadrage qui détaille les processus métiers et les bonnes pratiques, des tests approfondis sur les capacités du logiciel et de l’éditeur, ainsi que des plans de formation et une communication qui facilitent l’adoption des utilisateurs, et enfin des documents d’architecture (mapping des données, interfaces, règles de conversions, etc.). Au final, définir un Proof Of Concept en tant qu’étape du projet, permet de confronter les utilisateurs aux enjeux métiers.

Quand faut-il lancer un Proof Of Concept ?

Du fait du périmètre et de la complexité, le Proof Of Concept intervient plutôt vers la fin du cycle de vente et se prolonge comme le premier jalon du projet d’implémentation. Il en résulte qu’une organisation ne devrait travailler à cette étape qu’avec un seul éditeur, et ce pour une myriade de raisons : les coûts et les efforts importants dédiés à la compréhension des capacités de la solution logicielle, le temps dépensé à recueillir les besoins métiers, la réallocation des ressources humaines, les dépenses de voyages, les efforts pour produire la documentation des processus, la profondeur des tests et le niveau d’implication de l’éditeur… A contrario, si le Proof Of Concept intervient plus tôt dans le cycle, une entreprise devra réaliser en double la première étape de l’installation et du paramétrage du logiciel. Il en résultera au final que les coûts, les efforts et l’utilisation des ressources seront décuplés et que cela créera une plus forte probabilité de « non-choix ». Positionner le Proof Of Concept comme la première étape du projet est une bonne pratique qui implique de devoir finaliser le processus de sélection avec un seul éditeur ; il va sans dire qu’il est dans l’intérêt de l’entreprise de prévenir le deuxième éditeur de la situation dans l’hypothèse où l’éditeur retenu faillirait à bien dérouler le Proof Of Concept. Au final, mettre le Proof Of Concept en première étape du projet permet de comprendre les attentes métier sur une base méthodologique qui donnera le ‘la’ à une implémentation réussie.

Créer un Proof Of Concept

Comme indiqué précédemment, un Proof Of Concept est un test d’un applicatif architecturé à partir de documents détaillant les processus métiers. Le planning du Proof Of Concept devrait être correctement établi et proportionnel au planning global du projet. Par exemple, un projet d’implémentation de 8 mois ne devrait pas inclure une phase de Proof Of Concept supérieure à 1,5/2 mois. Comme il s’agit de la première étape de l’implémentation, la première tâche recouvre la rédaction d’un document de cadrage fonctionnel qui inclue la charte et le plan projet, la définition des ateliers de formation, des ateliers de design, un travail sur les données (règles de conversion, interfaces, etc.), et enfin la description des scénarios de tests. Les livrables devront inclure un plan projet détaillé et son RACI (matrice Responsible, Accountable, Consulted, Informed), les supports de formation, le document de cadrage fonctionnel et technique, un environnement de développement et de production, une analyse d’écarts, et les scénarios de tests. Le plan projet est généralement fourni par l’éditeur et conduit par l’organisation. La formation produit permet aux équipes de l’organisation de se familiariser avec le paramétrage du logiciel et évidemment de former les utilisateurs finaux. L’analyse des gaps est généralement conduite à l’issue des sessions de formation et peut à l’occasion découler d’un RFI (Request For Information) ou d’un RFP (Request For Proposal). Il est également important de travailler sur un environnement de développement (ou de test) préalablement à la migration vers l’environnement de production. Dans la plupart des cas, l’étape de ‘testing’ inclut les phases d’acceptance des utilisateurs ainsi que de la technique ; l’acceptance utilisateur est notamment importante lorsqu’il s’agit d’évaluer des fonctionnalités ou un processus où le résultat devra être binaire (accepté ou rejeté). Par exemple, le produit peut-il analyser des données sur plus de quatre axes analytiques : la réponse ne peut-être que ‘oui’ ou ‘non’. Les tests d’acceptance (UAT) sont également utiles pour obtenir l’adhésion des utilisateurs clés, surtout si ces derniers sont influenceurs auprès de leurs pairs. Les stress test, quant à eux, doivent mesurer les capacités techniques de la solution en matière de temps de réponse et de rapidité des principaux traitements. En dernier lieu, le Proof Of Concept devra permettre de tester l’éditeur en tant que « partenaire » ; par exemple, a-t-il des compétences et des experts pour accompagner le changement ? Est ce qu’il a les facultés de déployer les bonnes pratiques dans l’organisation ? A-t-il l’expérience pour nous assister dans les développements des workflows ? etc. Ainsi, définir le Proof Of Concept comme une étape de l’implémentation permet de solidifier les besoins métiers à l’heure de configurer le logiciel.

Conduire un Proof Of Concept

Le Proof Of Concept se déroule traditionnellement entre les murs du client. Un espace dédié devrait être préparé pour les utilisateurs finaux afin qu’ils puissent se retrouver et dérouler le Proof Of Concept dans les meilleures conditions. Le groupe devrait être constitué d’un mix « d’inter et d’intra » départements : les « inters » sont ces domaines susceptibles d’être affectés par la suppression des silos d’information ou par des interfaces ; les « intra-départements » sont intéressés par l’acceptation des utilisateurs finaux. Les ressources leur étant affectées devraient être bien respectées au sein de cette communauté car leur acceptation du nouveau système est largement corrélé à l’adoption de l’ensemble des utilisateurs finaux. Selon la nature des engagements contractuels, les responsabilités de l’organisation porteront sur la gestion globale du projet. Cela inclut la gestion du périmètre du proof of concept, son délai et son coût. L’organisation concernée devra également être disponible pour fournir l’ensemble des ‘inputs’ nécessaire à la définition du cadrage, communiquer avec les utilisateurs finaux pour favoriser l’adoption et le bon niveau de motivation, participer activement à la configuration du logiciel, et dérouler les scénarios de tests. Quant à l’éditeur de logiciel, ses responsabilités incluent la fourniture du document de cadrage, le déploiement des bonnes pratiques, la configuration/paramétrage du logiciel, la correction des (éventuelles) anomalies, et la coordination des activités de ‘testing’. Ainsi, définir le Proof of Concept comme une étape du projet d’implémentation est un moyen d’adopter les bonnes pratiques dès le départ.

Conclusion

Un proof of concept, en tant qu’étape de l’implémentation, est le premier pas vers un projet réussi. En tant que tel, il ne faudrait pas l’envisager durant le processus d’évaluation, mais plutôt comme un moyen de développer une compréhension approfondie du logiciel et de l’éditeur, et, ultimement comme un moyen de limiter les risques projet. Il permettra de former les utilisateurs à l’outil et aux enjeux métiers, il consolidera les spécifications fonctionnelles, il intégrera les bonnes pratiques et il servira de tremplin à un projet réussi.

By
@coesteve1
backtotop