4 signes que la preuve de concept de votre logiciel de Business Intelligence est un raté

Vous avez donc réduit les fournisseurs de logiciels de Business Intelligence que vous envisagez à une liste restreinte. Vous savez ce que votre entreprise a besoin du logiciel et vous avez une bonne idée de l'endroit où l'obtenir.

C'est un bon début, mais ce qui vient ensuite est tout aussi important : la preuve de concept. Lorsque vous achetez un logiciel, une preuve de concept revient à faire un essai routier lors de l'achat d'une voiture. Dans les deux cas, vous examinez la façon dont le produit gère les paramètres que vous rencontrerez au quotidien.

Si vous magasinez pour une fourgonnette ou un VUS, vous voulez vous assurer qu'il conviendra à vos enfants, à quelques amis et à leur équipement de soccer avant de signer.

Si vous recherchez un logiciel d'informatique décisionnelle, vous voulez vous assurer qu'il peut intégrer vos sources de données avant de vous engager.

Tout comme les signes révélateurs d'un mauvais essai routier (des freins qui grincent, un moteur qui fume ou le vendeur qui enfonce ses pieds dans le sol, à la manière de Flintstones, pour faire avancer la voiture), il existe des signes certains d'une mauvaise preuve de concept logicielle vous devez garder un œil sur.

Voici quatre signes indiquant que la preuve de concept de votre logiciel de Business Intelligence est un raté. Si vous voyez l'un de ces éléments, il est peut-être temps d'envisager un autre fournisseur.

1. Vous devez payer votre preuve de concept

Notre premier drapeau rouge est un fournisseur vous demandant de payer pour la preuve de concept. Vous seriez méfiant si un concessionnaire vous chargeait de conduire une voiture pendant 30 minutes, n'est-ce pas ? Vous devez également vous méfier des fournisseurs qui souhaitent que vous payiez pour voir dans quelle mesure leur produit intègre vos données.

L'achat d'une solution d'informatique décisionnelle n'est pas un achat unique. Il s'agit d'une relation avec le fournisseur et la communauté qui utilise son programme (pensez au support client, aux cours de formation des fournisseurs et aux forums en ligne). Par conséquent, votre fournisseur doit vous considérer comme un partenaire, plutôt que comme une simple source de revenus.

Un essai comme une preuve de concept n'est pas une transaction, mais une chance de se sentir mutuellement et de voir si les bases de la relation sont en place.

Une bonne preuve de concept est de bon augure pour un succès ultérieur

La préparation d'une preuve de concept nécessite un travail des deux parties. Le fournisseur doit créer une version de base de la solution qu'il concevra pour vous, tandis que vous devez savoir ce que vous attendez de la solution (nous en reparlerons plus tard). Au moment de la preuve de concept, l'acheteur avisé en intelligence d'affaires a déjà déterminé exactement ce dont il a besoin.

2. Le fournisseur n'utilise pas vos données

La meilleure façon de vous assurer que le programme BI que vous recherchez peut gérer vos données est de le voir gérer vos données. Tester une voiture en Floride n'a pas beaucoup de sens si vous avez besoin de voir comment elle se comporte dans le pays enneigé du Maine où vous vivez.

Assurez-vous que les tableaux de bord utilisent vos données.

L'ingénieur logiciel senior de Capterra, Venka Ashtakala, note qu'une « plus grande confiance » dans la solution est une raison majeure pour utiliser vos propres données dans le POC. Vos données "peuvent avoir des cas extrêmes ou d'autres particularités de données que les données de test peuvent ne pas avoir".

Les données que vous cherchez à alimenter dans votre programme d'informatique décisionnelle peuvent être conçues ou personnalisées d'une manière unique qui nécessite un traitement différent. "À un niveau supérieur", déclare Ashtakala, "l'utilisation de données" réelles "garantit que toute logique ou règle métier intégrée aux données sera correctement gérée par le code de preuve de concept en cours de développement".

Une preuve de concept avec vos propres données fournit le même type de minutie que vous souhaiterez lors de l'utilisation régulière du programme.

3. La preuve de concept ne démontre pas les affirmations du fournisseur

Une autre chose à garder à l'esprit lors de votre test de preuve de concept est la mesure dans laquelle le fournisseur respecte ou non ses affirmations, que ces affirmations soient uniques au POC ou qu'elles soient plus générales, des affirmations de marque.

Si un vendeur revendique un produit rapide, par exemple, cela ne devrait pas fonctionner à la vitesse d'un hamster languissant sur une roue rouillée.

Si vous voulez travailler sur une roue de hamster, c'est une autre affaire

Le raisonnement derrière celui-ci est explicite : si le fournisseur ne peut pas tenir les promesses de sa marque dans le POC, il est peu probable qu'il puisse le faire plus tard.

Même si la preuve de concept répond à vos exigences spécifiques, un produit qui se présente comme facile à utiliser ne devrait pas prêter à confusion. Cela suggère une marque incohérente, ce qui suggère en outre des problèmes futurs dans votre relation de longue date avec le fournisseur.

4. La preuve de concept ne répond pas à vos besoins

Alors que les trois premiers drapeaux rouges de cet article se concentrent sur le fournisseur, ce quatrième conseil vous ramène à vous et à votre entreprise. Une fois que vous avez identifié vos besoins, il est important d'évaluer la preuve de concept pour vous assurer qu'elle répond à ces besoins.

S'assurer que votre fournisseur répond à vos besoins est suffisamment important pour que Jason Remillard de Data443 l'appelle "le principal indicateur d'un POC échoué".

Comment savez-vous que vous avez affaire à une preuve de concept réussie ? Rémillard dit que le fournisseur aura « confirmé les exigences du client, les aura documentées, les aura revalidées avec le client » et aura demandé au client de signer chaque exigence. Ce niveau de diligence raisonnable démontre non seulement que le fournisseur connaît vos besoins, il "assure que tout le monde se concentre sur les bons efforts" et vous place dans la bonne position pour gérer votre relation avec l'entreprise qui vous aidera à devenir un fournisseur de données. conduit.

Ce niveau de rigueur du fournisseur permet une preuve de concept réussie et vous met en place pour des habitudes réussies une fois que vous utilisez régulièrement le programme. Avec des exigences bien définies et convenues, les deux parties ont « quelque chose à référencer », ce qui réduit les risques de confusion. Selon Rémillard, un document d'objectifs établis rationalise également le processus et le rend accessible au contrôle des changements.

Qu'est-ce qui fait une bonne preuve de concept ?

Avez-vous eu de bonnes (ou de mauvaises) expériences de preuve de concept lors de l'achat d'un logiciel de BI ? Partagez votre expérience dans les commentaires ci-dessous !