L’approche preuve de concept en BI : pièges et astuces

Dans toutes les organisations où j’ai eu la chance d’intervenir, il y a toujours eu de nombreuses bonnes idées d’intégration de données et de présentation de l’information sous toutes ses formes. Par contre, certaines fois, les entreprises ont été réticentes à aller de l’avant avec de nouveaux projets d’intelligence d’affaires. Parfois, il s’agissait d’une question budgétaire, d’autres fois c’était une crainte découlant d’un manque d’information ou de connaissances. Une des façons de contourner ce genre de problème pourrait être d’employer l’approche de la preuve de concept (proof of concept [POC]) et nous découvrirons pourquoi dans le présent article. De plus, il sera possible de voir certains pièges à contourner pour être en mesure de livrer efficacement une preuve de concept.

Pour commencer, définissons ce qu’est une preuve de concept. Une POC est la réalisation d’une partie restreinte d’un projet de plus grande envergure. Il peut s’agir de la livraison d’un prototype fonctionnel ou non. De plus, la preuve de concept doit avoir une date de fin précise ainsi qu’une portée bien définie.

Avantages & Astuces

Visibilité accrue

• Comme nous l’avons mentionné précédemment, la preuve de concept constitue un petit projet en soi. De ce fait, il s’agit de la plateforme idéale pour pouvoir valider les dépendances, les hypothèses et la séquence des étapes de réalisation d’un projet. C’est également le bon moment pour mieux définir les requis les moins précis. Comme la portée est petite, les répercussions des éléments non prévus ou indépendants de la volonté de l’équipe de réalisation s’en trouvent amoindries. Il est ainsi beaucoup plus facile de réagir et de s’ajuster en cours de route.
• La POC peut également constituer une excellente solution pour démontrer la faisabilité d’un projet d’intelligence d’affaires. Effectivement, le fait de pouvoir présenter des résultats concrets et ainsi offrir une meilleure visibilité très rapidement à la direction permet de démontrer concrètement les avantages et ainsi augmenter l’engouement par rapport au projet!

Diminution des risques et des coûts

• Comme la preuve de concept possède une date de fin déterminée et qu’elle peut être jetée si elle ne répond pas aux besoins de l’organisation, parfois il n’en faut pas plus pour diminuer la réticence de certaines personnes d’influence ou de certains départements face au projet.
• Lorsque vient le temps d’ajuster les plans d’un projet ou de mieux définir les requis avec les clients, les répercussions financières sont beaucoup moins grandes étant donné la nature courte de la preuve de concept.
• Les organisations doivent parfois demander l’expertise de fournisseurs externes. En plus de démontrer la faisabilité, la POC peut également servir à tester et à évaluer si l’équipe externe est apte à livrer de la qualité. Pour les projets d’intelligence d’affaires, il ne faut pas sous-évaluer l’importance de la dynamique d’équipe. Cette dernière peut faire la différence entre le succès et l’échec de projets d’importance.
  

Pièges à éviter

• Comme dans tout projet d’intelligence d’affaires, il faut s’allier à des partenaires motivés à nous aider à livrer la solution dans les délais souhaités. C’est encore plus vrai lorsque l’on parle de POC! En effet, comme la preuve de concept possède de courts délais, il faut que la livraison de cette dernière soit une priorité pour tous les acteurs afin d’assurer son succès. Une évaluation des priorités des acteurs clés au succès de la POC est donc très importante au cours des premières rencontres de démarrage.
• L’approche par prototype fonctionnel comporte également un risque important. Dans ce type de POC, l’équipe de réalisation veut toujours livrer une solution fonctionnelle. Cette situation a pour fâcheuse conséquence de faire augmenter la portée du projet, car, au fur et à mesure que l’équipe de projet rencontre des enjeux, il est très facile de les ajouter à la portée de peur que la solution ne soit pas fonctionnelle. Dans ces situations, il faut respecter la date de fin prévue au plan de projet et opter plutôt pour la créativité en utilisant des raccourcis stratégiques.
  
• Un autre piège à éviter avec la POC est la mauvaise communication de sa nature et de sa résultante. Il ne faut pas promettre que la preuve de concept constitue le début d’un projet d’intelligence d’affaires et que ce qui sera livré à la fin de cette dernière pourra être déployé tel quel dans l’organisation tout entière. Bien souvent, la POC est effectuée sans test exhaustif ou sans que les paramètres ne soient conformes aux normes de l’organisation.
  
  

N’oubliez pas qu’une preuve de concept n’utilise pas obligatoirement les mêmes paramètres que ne le ferait un projet complet d’intelligence d’affaires. Par exemple, on peut créer un modèle de données plus simple, une sécurité moins exhaustive, un ETL beaucoup moins rigoureux, etc. Gardez à l’esprit que la POC se veut une démonstration de la faisabilité d’un projet de plus grande ampleur. Faites-vous un plan de projet avec une portée précise, déterminez une date de livraison et respectez ces paramètres. La livraison de la POC, c’est bien souvent l'analyse de rentabilisation (business case) dont vous avez de besoin pour vous permettre de passer à la prochaine étape!

Dans votre organisation, avez-vous obtenu de beaux succès avec les preuves de concept?