News


5 principi del successo della Soluzione di Spend Management Proof-Of-Concept


AUna Spend Management solution proof-of-concept (POC) adotta il prodotto di un fornitore in-house per assicurare che possa funzionare nel vostro ambiente Procurement e funziona in modo in cui è stato promosso

Se si sta cercando di implementare una suite completa di gestione della spesa o di una soluzione 1 modulo, lo sviluppo di un POC può fornire l’occasione per sollecitare il feedback interno sulla capacità del software, riducendo il rischio e l’esposizione non necessaria e fornendo la possibilità per gli utenti di valutare le scelte funzionali e di design nelle prime fasi del ciclo di distribuzione. Esso può anche aiutare il fornitore di software a identificare potenziali problemi tecnici e funzionali che potrebbero interferire con successo.

I fattori di successo descritti di seguito sono basati sulla vasta esperienza di Ivalua di sviluppare un POC vincente, che non solo aiuterà a gettare le basi per un POC efficace, ma anche evitare le insidie più comuni dei progetti POC, rendendo una implementazione più agevole della vostra soluzione di gestione della spesa.

  • Limitare lo scopo di un POC a una dimensione gestibile. I POC sono buoni per provare uno o due concetti, ma non prendono il posto di una implementazione. In realtà, essi ritardano l’attuazione.
    Il POC prevede la possibilità per il Procurement organisation di utilizzare la soluzione all’interno del vostro ambiente di lavoro, con i propri dati. Limitare lo scopo del POC a una dimensione gestibile (in termini di volume di dati, funzionalità e gli individui coinvolti) permette al team di progetto di completare un numero sufficiente di operazioni per determinare se il software è adatto all’utilizzo da parte del vostro organismo di reperimento, valutare quanto facilmente possono essere personalizzati o configurati e fare in modo che possa essere implementato a livello aziendale.
  • Prepare use cases that reflect your desired end-state solution and your own procurement processes. Non chiedere ai vendor di eseguire un POC in base alla loro situazione out-of-the-box
    Un POC richiede uno sforzo da parte vostra per progettare i propri use cases in base a flussi di processo con cui si ha familiarità. Use cases devono descrivere un particolare scenario di use case del sistema da parte di un utente
    Use cases devono descrivere il processo di flusso attraverso la tua soluzione di spend management in base al suo utilizzo più probabile, non spendere troppo tempo su eccezioni e situazioni ipotetiche.
  • Assegnare un tempo adeguato nel periodo POC per permettere al venditore di reagire al feedback ed effettuare le regolazioni. Assegnare un tempo adeguato. Un POC non significa semplicemente la possibilità di toccare con mano il sistema, ma è anche la possibilità di vedere come il venditore reagisce alle regole inevitabilmente richieste durante l’implementazione iniziale. Tu stai verificando non solo il software ma l’implementazione del vendor e anche i servizi di supporto del fornitore.
  • Definire la chiave di performance S.M.A.R.T, che vengono concordati da entrambe le parti e vi permetterà di ottenere la fiducia prima di impegnarsi a costi di sottoscrizione. Requisiti elaborati accuratamente, la scopo e gli obiettivi renderanno la vostra valutazione del progetto pilota un compito più facile da realizzare.
  • Coinvolgere gli user giusti nel processo di valutazione, i quali hanno tempo a sufficienza, la conoscenza e l’interesse. Assicurati di incorporare le loro preoccupazioni e facilitare la successiva adozione da parte dei community user e impostare il timbro per un’implementazione di successo selezionando utenti POC all’interno di ciascuna Business Unit, che useranno la soluzione scelta sia che si trovino dal reparto Procurement o meno.

Un software Spend Management POC è spesso il primo passo verso una implementazione di successo. In quanto tale, non dovrebbe essere utilizzato come parte del processo di valutazione, ma piuttosto per sviluppare una più profonda comprensione sia del prodotto che dell’azienda e, infine, ridurre i rischi di business. Si dovranno educare gli utenti sui requisiti, avere dei requisiti solidi e abilitare le migliori pratiche e posto le basi per una corretta implementazione.