7 errori comuni nell'implementazione del software CPQ

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.

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.

A volte vedo prodotti che l'ufficio tecnico ha praticamente realizzato come 'costume', ma potrebbero essere arrivati qui perché hanno introdotto una serie di opzioni completamente inutili. Mentre cerchi di capire perché ci sono così tante opzioni, scopri che esistono perché molti anni fa, a potenziale cliente li ha richiesti. Ad alcuni team sembra che creando opzioni e rendendo il processo complesso, comunica agli altri team e alla leadership: "Ehi, guarda quanto siamo intelligenti!".

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.

Man mano che questi processi esistenti vengono scoperti e quelli nuovi e ottimizzati vengono concettualizzati, spesso viene in mente l'idea di automazione. Ma attenzione a non introdurre questo concetto troppo presto, prima che un processo sia completamente pensato. L'automazione di un processo errato rende solo più veloce un processo errato. Se una Implementazione del software CPQ inizia a replicare i processi esistenti e guidati dall'ego, è facile prevedere un disastro in cui l'automazione sta semplicemente aggravando più rapidamente i tuoi problemi.

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.

Quando un cliente chiede una personalizzazione in Software CPQ, si dovrebbe davvero andare alla radice per scoprire perché pensano che sia necessario. In genere, troviamo che la personalizzazione necessaria spesso nasconde un problema di processo. Le personalizzazioni del software sono molto costose per tutte le parti e possono aggiungere fragilità. Quindi, non dare mai un "sì" nascosto alla personalizzazione di un software senza prima chiedere "perché"?

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:

• eBook: Guida all'implementazione del software CPQ
• Post sul blog: Elenco di controllo per l'implementazione di CPQ: tutto ciò di cui hai bisogno per iniziare
• Post sul blog: Configurazione del software per preventivi: disponibilità all'implementazione
• Post sul blog: Cosa dovresti fare dopo l'implementazione del CPQ?