7 errori comuni nell'implementazione del software CPQ

Condividi questo articolo

Nel mio ruolo di Direttore R&D e Software Architect, sono stato coinvolto in varie fasi di numerosi progetti di implementazione del software. Ho iniziato con progetti più piccoli in Italia e, con il progredire della mia carriera negli ultimi 20 anni, i progetti sono diventati sempre più grandi, diffondendosi negli Stati Uniti e in Europa.

Ovviamente, come Direttore R&D di KBMax, parlo già quotidianamente con sviluppatori e integratori di sistema. Credo inoltre fermamente che dovrei parlare direttamente con i clienti effettivi e potenziali, per comprendere le loro esigenze e quindi trovare la soluzione migliore per le loro sfide uniche. Di conseguenza, a volte chiedo al nostro team di vendita di coinvolgermi nelle riunioni con i clienti.

Hai bisogno di maggiori informazioni su come iniziare con il tuo progetto di implementazione CPQ?

Ottieni maggiori informazioni e best practice su come sostenere la tua soluzione CPQ...

Ottieni la nostra guida completa all'implementazione CPQ

 

Errori di implementazione del software CPQ

UN CPQ il progetto è spesso "l'ultimo software" perché generalmente l'azienda ha già sistemi come: CRM, ERP, PLM, ecc. KBMax è generalmente la "colla" per tutti questi sistemi e il "fil rouge" di molti reparti: vendite, preventivo ufficio, ufficio tecnico e officina.

Considero il mio punto di vista un po' un osservatore esterno dell'implementazione di un progetto, ma ancora molto vicino a tutti gli 'attori'. L'elenco che segue non è esaustivo, ma agisce come una raccolta di insidie a cui ho assistito, e molte volte sono prevenibili prima che fossero pienamente realizzate. Come dice il libro 'The Art of War', "L'arte suprema della guerra è sottomettere il nemico senza combattere" - in questo caso, il nostro nemico sono queste insidie dell'implementazione.

1. Dare priorità alla selezione della tecnologia rispetto ai processi e alle persone

Una delle domande più comuni che le persone mi fanno è. "Qual è il miglior adattamento del prodotto nella scelta di un configuratore o Soluzione CPQ?" In tutta onestà, non è una questione di quale prodotto scegliere, ma a quali persone e processi aziendali ci si rivolge.

Ci sono prodotti perfettamente adatti ad essere 'configurati', ma le aziende o non hanno un processo, o il loro processo è inutilmente complesso. Questo accade in genere perché ci sono più livelli aggiunti nel tempo. Spesso è molto difficile semplificare il processo, perché significa ridurre questi livelli di complessità e il potere di alcune persone o team dell'azienda che ne fanno uso. Ad esempio, se il team di vendita vuole vendere qualunque cosa il cliente desideri, questa mancanza di vincoli creerà senza dubbio un disordine nel resto dell'azienda, in termini di ingegneria, approvvigionamento, produzione, ecc. Questi problemi non possono essere controllati se non esiste un processo (e, si spera, supportato dal software) che possa aiutare a mitigare questo rischio.

I sometimes see products that the technical department has practically made as ‘custom’, but might landed here because they’ve introduced a number of completely unnecessary options. As you try to understand why there are so many options, you discover that they exist because many years ago, a potenziale customer asked for them. It seems to some teams that by creating options and making the process complex, it communicates to their other teams and leadership, “Hey, look how smart we are!”.

Penso che ora tu veda la sfida: semplificare un processo non significa dare un servizio inferiore al cliente, ma invece lottare all'interno dell'azienda per tenere sotto controllo l'ego di ogni reparto. Potresti riconoscere questa lotta come cambio gestione. Questa riformulazione del processo aziendale critico di vendita e produzione dovrebbe mantenere la giusta attenzione sull'azienda in generale, piuttosto che sui singoli reparti o individui.

As these existing processes are discovered, and new, optimized ones conceptualized, often the idea of automation will come to mind.  But be careful not to introduce this concept too early, before a process is fully thought through. Automating a bad process only makes a bad process run faster. If a CPQ software implementation begins replicating existing, ego-driven processes, it is easy to foresee a disaster where automation is simply more quickly compounding your problems.

2. Troppa personalizzazione del processo

Completamente correlato al punto precedente: a volte le aziende hanno processi molto strani. Si scopre che hanno reinventato la ruota, ma così facendo hanno reinventato la ruota come un quadrato. Molte volte ho sentito le aziende esclamare con orgoglio che "non siamo mai riusciti a trovare un software che ci soddisfacesse, quindi abbiamo dovuto svilupparne uno nostro". Questo può essere il caso di verticali altamente specializzati come il calcolo tecnico. Tuttavia, quando sul mercato esiste un'intera categoria di software che non ritieni si applichi a te, questa potrebbe essere un'indicazione di qualcosa di più grande che è sbagliato e molto probabilmente guidato dall'ego di qualcuno.

When a customer asks for a customization in CPQ software, one should really go to the root to find why they think it is required. Generally, we find that the needed customization is most often hiding a process problem. Software customizations are very expensive for all parties and can add fragility. So, never give a blanketed “yes” to a software customization without asking first, “why”?

3. Mancanza di coinvolgimento delle parti interessate per favorire l'adozione

Coinvolgere tutte le parti interessate è molto importante, ma può anche essere pericoloso. L'ultimo interlocutore è l'azienda. Tuttavia, non pianificare l'adozione da parte dell'utente o ottenere il consenso dell'utente finale come parte del processo decisionale garantirà il fallimento.

Allo stesso tempo, non puoi nemmeno lasciare che gli utenti decidano unilateralmente la soluzione. Come disse Henry Ford, "Se avessi chiesto alle persone cosa volevano, avrebbero detto cavalli più veloci".

La chiave qui è bilancia. Leadership, capi dipartimento e membri del team devono tutti avere voce in capitolo nella progettazione del nuovo processo. L'equilibrio è spesso ciò che distingue un'implementazione del software CPQ di successo da una fallita.

4. Non cerco il miglior prodotto MVP

Puoi trovare la definizione di MVP (Minimum Viable Product) ovunque, quindi non voglio sottolineare molto qui aggiungendo un'altra definizione. Il prodotto più complesso in azienda non è un buon candidato come non è un buon candidato, un prodotto banale. Probabilmente il miglior candidato è un nuovo prodotto di media complessità, perché è quello con meno bias.

5. Sottovalutare la quantità di sforzo

Questa trappola è in genere dovuta al fatto di non aver raccolto con cura i requisiti del progetto. Come tecnico, penso che sia molto facile sottovalutare il tempo necessario. Generalmente, moltiplico quello che penso sia lo sforzo per un fattore due. Come mai? Lo aggiungo come "tempo politico". È molto facile perdersi in discussioni e riunioni per estrarre informazioni dalle persone, invece di fornire requisiti adeguatamente documentati in anticipo. Alla gente piacciono le riunioni lunghe e improduttive e non so perché.

6. Non comprendere l'intento e i limiti delle applicazioni

Quando molte applicazioni software sono coinvolte e collegate come parte di un processo, reparto o azienda, è spesso difficile capire "chi sta facendo cosa". Non sto parlando di semplici zone grigie. Sto suggerendo che ogni applicazione software dovrebbe essere utilizzata per ciò per cui è stata progettata. Ad esempio, è molto comune dimenticare lo scopo di uno strumento ETL (Extract Transform Load) e fingere che ogni software sia responsabile del push e del pull dei dati. Quando vengono utilizzate molte applicazioni, scoprirai che alcune sono più flessibili, mentre altre no. È ovviamente più facile piegare un software più flessibile per eseguire attività che non è destinato a svolgere. Tuttavia, ciò non significa necessariamente che dovresti.

7. Overselling delle vendite

Qui, sto parlando di noi – KBMax come azienda di software. Non vendiamo un sogno. Scopriamo che il problema dell'overselling è notevolmente diminuito dalla nostra transizione dalla tradizionale licenza perpetua a un modello cloud (SaaS).

In genere, quando un venditore vende una licenza perpetua, è interessato a completare la transazione del software e avviare con successo un progetto iniziale con il cliente. Dopodiché, il cliente non è più "il problema del venditore". In un modello SaaS, tuttavia, la vendita deve essere sia una vittoria iniziale che continua. Solo i clienti con un software potente che esegue un'implementazione di successo torneranno per i rinnovi, che è l'unico modo in cui le aziende SaaS possono essere redditizie.

Altri assassini di progetti classici

Ci sono molti altri problemi di implementazione che un progetto di implementazione del software CPQ può incontrare: budget bassi/variabili, scarsa gestione del progetto, mancanza di piani di manutenzione, scarsa conoscenza della tecnologia, scarsa qualità del software, ecc. Questi sono pericolosi e importanti a cui prestare attenzione in quanto possono facilmente mandare in crash un progetto, ma secondo me sono abbastanza ovvi e facili da individuare. In ogni caso, non sono specifici per l'attuazione del CPQ in modo specifico.

Condividere un modo migliore per implementare il software CPQ

KBMax ha alcune ottime risorse per aiutarti a iniziare il tuo progetto CPQ. Abbiamo un fantastico eBook e una serie di post sul blog che fanno luce su alcune best practice per iniziare:

Pubblicato in: CPQ
 
it_ITItalian