[section_title title=Come avviare un progetto IT: perché è necessario partire dal POC – Parte 2]
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.
