Fase 1: Comprendere lo stato attuale

Garantire la sponsorizzazione esecutiva

Senza una sponsorizzazione esecutiva visibile, i progetti tendono a bloccarsi quando si verificano decisioni o compromessi significativi. Prima di impegnarsi in una strategia, identificare uno sponsor esecutivo designato che comprenda la portata del cambiamento, abbia approvato l'impegno delle risorse e possa coinvolgere gli stakeholder in ambito commerciale, finanziario, legale e IT.

Formare il Core Team

Assegnare un piccolo team interfunzionale che possa dedicare tempo coerente al progetto. Evitare di suddividere l'attenzione tra altre priorità durante le fasi attive del progetto. Un team centrale tipico include:

• Amministratore Salesforce: Gestisce la configurazione, le organizzazioni Sandbox e l'esecuzione tecnica.
• Titolare del prodotto o catalogo: Conosce la struttura dei prodotti commerciali e ha autorità decisionale sulle modifiche del catalogo.
• Lead delle operazioni di reddito o analista aziendale: Traduce i requisiti aziendali in decisioni di progettazione Salesforce.
• Architetto IT o integrazione: Possiede il panorama dell'integrazione e l'inventario del codice personalizzato.
• Sponsor esecutivo: Offre visibilità, rimuove gli ostacoli e mantiene il progetto allineato alle priorità aziendali.

Il team centrale deve comprendere l'intero ciclo di vita dal prodotto alla cassa e tutta la tecnologia sottostante.

Valutazione dell'organizzazione Salesforce CPQ

Prima di definire l'ambito o l'approccio di migrazione, valutare l'organizzazione Salesforce CPQ corrente. Utilizzare gli strumenti di migrazione disponibili, inclusi gli strumenti di early adopter come Forsys, IdeaHelix o Prodly, per valutare la complessità dell'organizzazione Salesforce nelle dimensioni più rilevanti per la pianificazione della migrazione. La valutazione deve rispondere a queste domande.

• Quanti prodotti, bundle, regole di prodotto e attributi esistono nel catalogo, quanti sono utilizzati attivamente e il catalogo viene razionalizzato?
• Quali regole di calcolo dei prezzi, quali script del plug-in Apex per il calcolatore dei preventivi sono disponibili e quale logica aziendale contengono?
• Quanti abbonamenti e asset attivi esistono, quanti sono pronti per l'elaborazione e qual è la loro struttura di dati?
• Quale codice personalizzato e layout di pagina vengono utilizzati?
• Quali integrazioni fanno riferimento agli oggetti CPQ e quali dati vengono trasmessi?

Punti deboli dell'implementazione del documento CPQ

Prima di iniziare la migrazione, indicare le limitazioni e le soluzioni per i documenti nell'implementazione CPQ corrente. Queste informazioni definiscono i criteri di successo del progetto. Acquisire questi punti.

• Problemi di prestazioni o scalabilità: Tempi di calcolo dei preventivi, ritardi nel caricamento delle pagine e colli di bottiglia delle approvazioni.
• Lacune di funzionalità: Requisiti aziendali che CPQ non può soddisfare o può soddisfare solo con uno sviluppo personalizzato significativo.
• Soluzioni CPQ: Passaggi manuali, fogli di calcolo offline o sistemi shadow che compensano le limitazioni di CPQ.
• Frizione di integrazione: Dati che non fluiscono in modo pulito tra CPQ e i sistemi a valle.
• Miglioramenti del processo: Processi che devono essere aggiornati o ottimizzati prima della migrazione. I processi complessi migrati così come sono rimarranno ugualmente complessi nel nuovo sistema. Utilizzare questa opportunità per semplificarli.

Questi punti deboli diventano i criteri di successo per la migrazione. Determinare i criteri di successo prima di passare alla fase 2.

Avvio della riparazione della qualità dei dati

I Problemi di qualità dei dati sono più costosi da risolvere durante la migrazione rispetto a prima. Avviare la riparazione in anticipo, indipendentemente dalla strategia di migrazione selezionata. Concentrarsi innanzitutto su queste aree.

• Prodotti duplicati o ritirati ancora contrassegnati come attivi nel catalogo.
• Denominazione degli attributi incoerente nelle linee di prodotti o nelle unità operative.
• Esaminare i dati del listino costi CPQ per individuare potenziali duplicati. Per conservare i record dei costi storici, creare un campo personalizzato per la data finale effettiva e compilare questa data prima della migrazione.
• Record orfani, ad esempio abbonamenti senza account controllanti o voci preventivo senza preventivi controllanti.
• Creare un insieme di record abbonamento che devono essere migrati insieme. Non è necessario eseguire la migrazione degli abbonamenti annullati.
• Record asset incompleti o incoerenti che possono influire sulla migrazione di Customer Asset Lifecycle Management (CALM).
• Il campo ProductSellingModelId nei record Voce listino prezzi è di sola lettura dopo la creazione iniziale dei record Voce listino prezzi. Se si esegue la migrazione a Gestione del reddito senza specificare un modello di vendita prodotti al momento della creazione, si otterranno record Voce listino prezzi che non possono essere corretti dopo la migrazione senza creare record. Assicurarsi quindi che i modelli di vendita prodotti siano mappati correttamente prima della migrazione. Contattare l'Assistenza clienti Salesforce se è necessario l'accesso in modifica per modificare il modello di vendita prodotti nei record Voce listino prezzi.
• Mentre CPQ utilizza i tipi di record per identificare i record correlati a CPQ, Gestione del reddito utilizza i record Assegnazione utilizzo app per identificare i record generati da Gestione del reddito. Affinché le operazioni del ciclo di vita degli asset abbiano esito positivo, il record Assegnazione utilizzo app deve essere compilato per tutti i record transazione, ad esempio preventivi, ordini e asset.
• In Salesforce CPQ, gli attributi possono essere assegnati direttamente ai prodotti. In Gestione del reddito, attributi da ereditare tramite una classe di prodotto. Poiché gli utenti CPQ non avranno classi di prodotto, è necessario crearle sistematicamente durante la migrazione raggruppando i prodotti con insiemi di attributi identici.
• In Salesforce CPQ, è possibile creare più voci di costo per ogni prodotto e ogni valuta, incluse voci di costo unitario zero. In Gestione del reddito non è possibile creare record Voce listino costi duplicati o lo stesso codice ISO valuta. Questa differenza causa errori di migrazione.

Elenco di controllo Fase 1

Prima di passare alla Fase 2, verificare di aver completato queste operazioni.

• La sponsorizzazione esecutiva è attiva e l'impegno delle risorse è approvato.
• Viene creato un team centrale con ruoli definiti e capacità sufficiente.
• Una valutazione dell'organizzazione Salesforce CPQ viene completata e il team comprende il profilo di complessità.
• I punti deboli dell'attuale implementazione di CPQ sono documentati e il team ha una definizione condivisa di successo.
• Vengono identificati Problemi di qualità dei dati significativi ed è stata avviata la correzione.
• Il responsabile account Salesforce è coinvolto e le opzioni di licenza e assistenza sono note.

Dopo aver completato tutti gli elementi della fase 1, passare alla fase 2.