Il POC viene spesso descritto dai project manager o dagli analisti funzionali come uno dei processi più ardui che un’organizzazione debba affrontare: la selezione di un software provider è infatti un’operazione molto complessa. Convocare i fornitori partecipanti al processo di selezione, coinvolgere numerosi collaboratori che devono allontanarsi dal loro lavoro quotidiano, ascoltare le presentazioni commerciali, comparare le soluzioni e scegliere la soluzione ottimale: tutto questo rappresenta un costo significativo e la maggior parte delle volte si conclude con una non-scelta. Franck Le Tendre, Vp Western Europe & Ceo France di SynerTrade, stila il vademecum utile alle aziende per decidere in fretta e in maniera efficace.
Spesso i costi indiretti connessi al processo di valutazione rappresentano fino al 25% del prezzo del software. In aggiunta a tutti questi costi di selezione è sempre più difficile ottenere il sostegno degli utenti finali. I costi elevati del processo di valutazione uniti alla difficoltà di comprensione dei prerequisiti e alla difficoltà nel coinvolgimento degli utenti finali possono essere i presupposti di progetti fallimentari che non andranno a buon fine.
Il “Proof of Concept” dovrebbe essere un passaggio fondamentale durante la fase iniziale di scelta di un sistema, prima dell’implementazione della soluzione, in quanto permette a chi deve occuparsi della valutazione delle soluzioni di evitare presentazioni generiche e di focalizzarsi sulla reale comprensione del fabbisogno da parte del provider.
Nel processo d’acquisto, il “Proof of Concept” consente alle aziende di focalizzarsi sui fattori importanti al fine di creare le condizioni favorevoli per un maggiore utilizzo del software da parte degli utenti finali, l’avvio di un percorso di change management interno, l’adozione di best practice e la possibilità di porre le basi per un progetto di successo.
Cos’è un proof of concept? Un Proof of Concept è un test di un’applicazione software basato sulla costruzione di un prototipo ideato a partire da processi di business. È il primo passaggio del processo di implementazione che mette in luce i bisogni di business e le aspettative sulla configurazione. Si concretizza nella messa a disposizione di un accesso alla piattaforma in un ambiente configurato per il cliente per dimostrare l’aderenza della piattaforma alle esigenze raccolte in una prima fase e la corrispondenza alla presentazione ufficiale del provider.
I deliverable di un Proof of Concept includono un documento che dettaglia il processo di business e le best practice, concretizzati attraverso test sulle capacità del software e del provider, come anche piani di formazione e comunicazione per ottimizzare l’adozione dell’utente, e documenti sull’architettura del software (mapping dei dati, interfacce, regole di conversione). In sostanza, la definizione del Proof of Concept è quella di una fase di progetto che permette di raccogliere pareri concreti sulla corrispondenza del software alle esigenze di business.
Quando è opportuno lanciare un Proof of Concept? A causa della sua complessità, il Proof of Concept viene fatto alla conclusione del ciclo di vendita, e si prolunga fino al primo passo dell’implementazione del progetto. L’azienda dovrebbe lavorare con un unico provider per varie ragioni: i costi e gli sforzi elevati volti a capire le capacità delle soluzioni del software, il tempo necessario per comprendere i bisogni del business, l’assegnazione di risorse, il costo degli spostamenti, gli sforzi per produrre documenti di processo, i test sullo spessore e sul livello d’implicazione del provider.
D’altro canto, se il Proof Of Concept è avviato all’inizio del ciclo di vendita, l’azienda deve duplicare i primi passi di installazione e configurazione e, alla fine, i costi, gli sforzi e le risorse verrebbero moltiplicati con un’alta probabilità di non scelta.
Posizionare il POC come prima fase del progetto è un’ottima pratica che garantisce di finalizzare il processo di selezione con un unico provider. Inutile dire che è interesse dell’azienda fare in modo che il provider non fallisca nell’implementazione e nell’estensione finale del POC.
Infine, il Proof of Concept come primo passaggio permette di capire le necessità di business su base metodologica e definire i passi di una implementazione di successo.
Come creare un Proof of Concept. Come detto in precedenza, il POC è un’applicazione di test studiata sulla base di documenti che descrivono i processi di business. La pianificazione del POC dovrebbe essere correttamente costruita e proporzionale al piano globale di progetto. Ad esempio, un’implementazione della durata di 8 mesi non dovrebbe includere una fase POC che duri più di 2 mesi.
Come fase iniziale di implementazione, il primo task è la redazione di un documento funzionale che includa un grafico e un piano di progetto, la definizione di workshop formativi studiati, un lavoro sui dati (regole di conversione, interfacce, etc.) e la descrizione degli scenari di test. I risultati devono includere un piano di progetto dettagliato e la relativa matrice RACI, i materiali formativi, documenti funzionali e tecnici, sviluppo e produzione dell’ambiente, l’analisi dei gap e l’ambiente di test.
Il piano di progetto è solitamente fornito dal provider e guidato dall’organizzazione. La formazione sul prodotto permette ai team dell’organizzazione di familiarizzare con il setup del software e ovviamente di formare gli utenti finali. L’analisi dei gap viene generalmente avviata alla fine della sessione di formazione e può occasionalmente risultare da un RfI (Request for Information) o da un RfP (Request for Proposal). È importante lavorare sullo sviluppo o su un ambiente di test prima di spostarsi verso l’area di produzione. La maggior parte delle volte, il test include l’accettazione sia dell’utente che della tecnica. L’accettazione dell’utente è particolarmente importante quando si deve valutare le funzionalità o i processi nei quali i risultati devono essere binari (accettati o rigettati). Per esempio, se il prodotto può analizzare i dati da 4 approcci analitici, la risposta non può solo essere “sì” o “no”. Anche gli User Acceptance Tests (UAT) sono utili per ottenere l’adesione dei key user, specialmente se sono influenti.
Nel frattempo i test devono misurare le abilità tecniche delle soluzioni in termini di tempi di risposta e rapidità delle principali richieste. Alla fine, il POC dovrebbe permettere di testare il provider come “partner”; ad esempio possiede le abilità e gli esperti per guidare il cambiamento? È in grado di spiegare le best practice all’interno dell’organizzazione? In questo modo, definire il POC come fase iniziale dell’implementazione permette di semplificare le priorità di business quando si arriva alla configurazione del software.
Come condurre un POC efficace. Il POC tradizionalmente avviene negli uffici dei clienti. Ideale sarebbe predisporre uno spazio dedicato per fare in modo che gli utenti finali possano organizzare meeting per effettuare il set-up del POC nelle migliori condizioni. È importante che l’azienda dedichi risorse a questa fase perché la valutazione del POC è essenziale all’adozione degli utenti finali.
Secondo il tipo di impegno contrattuale, le responsabilità dell’azienda si focalizzeranno sulla gestione complessiva del progetto. Ciò include la gestione del perimetro, dei costi e delle scadenze del POC. Il gruppo in valutazione del POC deve rendersi disponibile a fornire tutti gli input necessari a definire il quadro, comunicare con gli utenti finali per promuovere la scelta e il giusto livello di motivazione, partecipare attivamente alla configurazione del software e svolgere gli scenari di test.
Per quanto riguarda il provider del software, le responsabilità includono la fornitura del documento della struttura, l’apporto di best practice, la configurazione del software, la correzione di potenziali anomalie e il coordinamento delle attività di test. Pertanto, definire il Proof of Concept come un passaggio iniziale indispensabile del progetto di implementazione è il miglior modo per adottare best practice fin dall’inizio.
