search Il media che reinventa l'impresa

Scelta del software: è necessaria una prova di concetto (POC)?

Scelta del software: è necessaria una prova di concetto (POC)?

Da Nicolas Payette

Il 6 novembre 2024

Alcuni editori e integratori offrono un POC (Proof-Of-Concept) per convalidare la fattibilità di un progetto. Il più delle volte, questo viene richiesto dal cliente. Si tratta di una fase di comfort per rassicurare il cliente o di un'operazione obbligatoria per ridurre i rischi?

Vantaggi e svantaggi di un POC per il cliente

I vantaggi di un proof of concept (POC) per il cliente sono molteplici:

  • Sincronizzazione delle aspettative con il fornitore;
  • Migliore appropriazione del processo di implementazione;
  • Identificazione di carenze funzionali o sovrastime;
  • Una migliore comprensione dell' investimento richiesto. Un quadro più preciso consente di comprendere meglio l'investimento necessario per completare l'implementazione;
  • valutazione del partner di implementazione. Il processo POC intrinseco consente al cliente di valutare il software e il partner di implementazione.

Ci sono anche delle limitazioni al POC che devono essere notate. Questi sono:

  • Flessibilità commerciale. La flessibilità prevista da alcuni accordi POC, che consentono al cliente di rinunciare all'acquisto del software, è raramente presa in considerazione nella realtà, poiché è stato fatto un investimento significativo in termini di tempo e denaro. Inoltre, il cliente spesso decide di intraprendere un POC senza valutare appieno tutte le soluzioni, dato il basso rischio di questa opzione.
  • L'esercizio di vendita. A seconda degli accordi commerciali in vigore, il POC può essere integrato nel ciclo di vendita, per cui la capacità del fornitore di divulgare tutte queste informazioni è limitata. Inoltre, la documentazione prodotta nel POC può avere contenuti di marketing che non aggiungono valore al progetto.

Questo articolo è la seconda parte di un tutorial in due parti. La prima parte è stata dedicata all'analisi della struttura di un POC e alla sua corrispondenza con il processo di selezione.

Vantaggi e svantaggi di un POC per il fornitore

Ecco i vantaggi per il fornitore:

  • Avere un vantaggio competitivo nel processo di vendita. Il POC è un altro strumento nella cassetta degli attrezzi di vendita. Il POC può essere utilizzato per portare il cliente potenziale alla fase successiva del processo di vendita, senza che il cliente debba impegnarsi completamente.
  • Migliore implementazione e clienti soddisfatti. Un fattore di successo fondamentale per qualsiasi VAR o fornitore di software è avere clienti pronti a fungere da riferimento. Qualsiasi strumento che migliori la soddisfazione dei clienti dovrebbe essere preso in considerazione.

Ecco gli svantaggi per il fornitore:

  • Tempi di vendita. Il POC può prolungare il processo di vendita. Inoltre, la tempistica (importante per le aziende quotate in borsa) diventa più incerta, il che può portare a un'ulteriore riduzione del prezzo.
  • Richieste di consulenza sulle risorse. A causa della natura del POC, le richieste di consulenza possono essere significative e richiedere molte risorse. Di norma, per garantire che il POC si traduca in un ordine di acquisto, sono necessari consulenti più esperti.

Quando deve essere effettuato un POC?

Il POC dovrebbe essere effettuato come parte del processo di selezione quando il rischio di fallimento del progetto è relativamente alto. Il rischio può essere misurato utilizzando due variabili chiave. Queste variabili sono la complessità dei requisiti e il livello di competenza del team di selezione e implementazione (MOE). Quanto più complessi sono i requisiti del sistema, tanto maggiori sono i benefici ottenuti da un POC. La complessità può essere misurata dal numero e dalla natura dei moduli implementati, dal grado di personalizzazione, dal numero di interfacce e dalla quantità e qualità dei dati da convertire.
Il numero di moduli da implementare (ad esempio, un'implementazione puramente finanziaria rispetto a un'implementazione finanziaria + distribuzione + archiviazione) aumenta la portata dell'implementazione e quindi il rischio. Inoltre, anche la natura dei moduli da impiegare influenza il rischio. Moduli come l'automazione della forza vendita (SFA) in una suite di gestione delle relazioni con i clienti (CRM) tendono ad avere un profilo di rischio più elevato rispetto a moduli finanziari come la contabilità.
Anche il livello di competenza del team di selezione/implementazione è un indicatore importante. I fattori da considerare sono

  • Conoscenza del settore
  • Conoscenza dei processi aziendali esistenti
  • comprensione del processo di selezione del software ad alto valore
  • Conoscenza della gestione dei fornitori di software
  • Conoscenza dei sistemi ERP/CRM

Questi fattori dovrebbero essere utilizzati per misurare le competenze del vostro team. Un team altamente qualificato riduce il fattore di rischio del progetto.
La tabella seguente rappresenta questi fattori e come determinare se è necessario un POC per il processo di selezione:

Informazioni sull'autore

Robert Rudd è un consulente ERP esperto con oltre nove anni di esperienza nell'implementazione di sistemi ERP. La sua esperienza comprende anche il supporto informatico a clienti del settore finanziario e bancario. Ha implementato sistemi ERP in diversi settori, ma è specializzato nella gestione della supply chain. Rudd lavora per Scalable Data Systems, con sede in Australia. Scalable Data Systems fornisce soluzioni aziendali al mercato medio da oltre vent'anni.

Articolo tradotto dal francese