4 Segni che il tuo software di business intelligence Proof of Concept è un disastro

Quindi hai ristretto i fornitori di software di business intelligence che stai considerando a una lista ristretta. Sai di cosa ha bisogno la tua azienda dal software e hai una buona idea di dove trovarlo.

Questo è un ottimo inizio, ma ciò che viene dopo è altrettanto importante: il proof of concept. Quando si acquista un software, un proof of concept è come fare un giro di prova quando si acquista un'auto. In entrambi i casi, stai osservando come gestisce il prodotto nelle impostazioni che incontrerai quotidianamente.

Se stai acquistando un minivan o un SUV, assicurati che si adatti ai tuoi figli, ad alcuni amici e alle loro attrezzature da calcio prima di firmare.

Se stai acquistando un software di business intelligence, vuoi assicurarti che possa integrare le tue origini dati prima di impegnarti.

Proprio come i segni rivelatori di un brutto giro di prova (freni che stridono, motore che fuma o il venditore che infila i piedi nel pavimento, in stile Flintstones, per far muovere l'auto), ci sono segni sicuri di un cattivo software proof of concept devi tenere d'occhio.

Ecco quattro segni che il tuo software di business intelligence proof of concept è un disastro. Se vedi qualcuno di questi, potrebbe essere il momento di prendere in considerazione un fornitore diverso.

1. Devi pagare per il tuo proof of concept

La nostra prima bandiera rossa è un venditore che ti chiede di pagare per il proof of concept. Saresti sospettoso se una concessionaria ti addebitasse di guidare un'auto per 30 minuti, giusto? Dovresti essere ugualmente diffidente nei confronti dei fornitori che vogliono che tu paghi per vedere quanto bene il loro prodotto integra i tuoi dati.

L'acquisto di una soluzione di business intelligence non è un acquisto unico. È una relazione con il fornitore e la comunità che utilizza il loro programma (pensa all'assistenza clienti, ai corsi di formazione del fornitore e ai forum online). Pertanto, il tuo fornitore dovrebbe considerarti un partner, piuttosto che una semplice fonte di reddito.

Una corsa di prova come prova del concetto non è una transazione, ma un'opportunità per confrontarsi e vedere se le basi della relazione sono a posto.

Un buon proof of concept fa ben sperare per il successo successivo

La preparazione per un proof of concept richiede il lavoro di entrambe le parti. Il fornitore deve creare una versione base della soluzione che progetterà per te, mentre tu devi sapere cosa vuoi dalla soluzione (ne parleremo più avanti). Al momento del proof of concept, l'esperto acquirente di business intelligence ha già determinato esattamente ciò di cui ha bisogno.

2. Il venditore non utilizza i tuoi dati

Il modo migliore per assicurarti che il programma BI che stai acquistando sia in grado di gestire i tuoi dati è vederlo gestire i tuoi dati. Provare a guidare un'auto in Florida non ha molto senso se hai bisogno di vedere come si comporta nella terra innevata del Maine dove vivi.

Assicurati che i dashboard utilizzino i tuoi dati.

Venka Ashtakala, ingegnere software senior di Capterra, osserva che una "maggiore fiducia" nella soluzione è una delle ragioni principali per utilizzare i propri dati nel POC. I tuoi dati "potrebbero avere alcuni casi limite o altre particolarità dei dati che i dati di test potrebbero non avere".

I dati che stai cercando di inserire nel tuo programma di business intelligence possono essere progettati o personalizzati in un modo unico che richiede un trattamento diverso. "A un livello superiore", afferma Ashtakala, "l'utilizzo di dati 'reali' garantisce che qualsiasi logica o regola aziendale incorporata nei dati verrà gestita correttamente dal codice proof of concept in fase di sviluppo".

Un proof of concept con i tuoi dati fornisce lo stesso tipo di accuratezza che vorresti quando usi il programma su base regolare.

3. Il proof of concept non dimostra le affermazioni del venditore

Un'altra cosa da tenere a mente durante il test di prova del concetto è la misura in cui il fornitore soddisfa o meno le proprie affermazioni, indipendentemente dal fatto che tali affermazioni siano esclusive del POC o siano più generali affermazioni di branding.

Se un venditore rivendica un prodotto veloce, ad esempio, non dovrebbe funzionare alla velocità di un criceto che languisce su una ruota arrugginita.

Se vuoi lavorare su una ruota per criceti, tuttavia, questa è un'altra questione

Il ragionamento alla base di questo è autoesplicativo: se il venditore non è in grado di mantenere ciò che il suo marchio promette nel POC, è improbabile che sarà in grado di offrire in seguito.

Anche se il proof of concept soddisfa i tuoi requisiti specifici, un prodotto che si pubblicizza come facile da usare non dovrebbe creare confusione. Suggerisce un marchio incoerente, che suggerisce ulteriormente problemi futuri nella tua relazione di lunga data con il venditore.

4. Il proof of concept non soddisfa le tue esigenze

Mentre le prime tre bandiere rosse in questo pezzo si concentrano sul venditore, questo quarto suggerimento riporta i riflettori su di te e sulla tua attività. Dopo aver identificato le tue esigenze, è importante valutare il proof of concept per assicurarti che soddisfi tali esigenze.

Garantire che il tuo fornitore soddisfi le tue esigenze è abbastanza importante che Jason Remillard di Data443 lo definisce "l'indicatore principale di un POC fallito".

Come fai a sapere che hai a che fare con un proof of concept di successo? Remillard afferma che il fornitore avrà "confermato i requisiti del cliente, documentato, riconvalidato con il cliente" e fatto approvare dal cliente ogni requisito. Questo livello di due diligence non solo dimostra che il fornitore conosce le tue esigenze, ma "assicura che tutti siano concentrati sugli sforzi giusti" e ti mette nella posizione giusta per gestire il tuo rapporto con l'azienda che aiuterà il tuo percorso per diventare dati- guidato.

Questo livello di accuratezza del fornitore costituisce un proof of concept di successo e ti prepara ad abitudini di successo una volta che usi regolarmente il programma. Con requisiti ben definiti e concordati, entrambe le parti hanno "qualcosa a cui fare riferimento", il che riduce la possibile confusione. Secondo Remillard, un documento di obiettivi stabiliti snellisce anche il processo e lo rende suscettibile di cambiare il controllo.

Cosa rende un buon proof of concept?

Hai avuto esperienze di proof of concept buone (o cattive) durante l'acquisto di software BI? Condividi la tua esperienza nei commenti qui sotto!