Ti trovi qui:
Dynamic Revenue Orchestrator come livello orchestrazione integrazione
Le integrazioni CPQ sono in genere da punto a punto, con connessioni dirette da CPQ a un sistema ERP (Enterprise Resource Planning), a un sistema di fatturazione o a una piattaforma di provisioning. Ogni connessione viene gestita, monitorata e soggetta a interruzioni in modo indipendente in caso di modifiche. Nell'ambito della migrazione a Gestione del reddito, considerare il panorama dell'integrazione come uno stream di lavoro dedicato. Cogliere l'occasione per ripensare l'architettura anziché limitarsi a rimappare le connessioni.
In un ambiente CPQ tradizionale, quando viene effettuato un ordine, il middleware o il codice personalizzato devono determinare le azioni a valle richieste, ad esempio il provisioning del prodotto, la notifica all'ERP, l'attivazione della fatturazione e l'aggiornamento della piattaforma di provisioning. Questa logica in genere si applica a più integrazioni da punto a punto che possono essere difficili da mantenere nel tempo. Dynamic Revenue Orchestrator (DRO) sostituisce questo approccio agendo come livello di orchestrazione singolo in cui tutte le operazioni a valle vengono coordinate e monitorate.
Funzionalità dei livelli di orchestrazione
DRO funge da livello di coordinamento centrale per l'evasione post-ordine.
- Un'unica posizione per definire le azioni richieste dopo l'invio di un ordine, inclusi provisioning, evasione, trigger di fatturazione e aggiornamenti ERP e la loro sequenza.
- Un'area di disegno visiva in cui il piano di orchestrazione è visibile ai team operativi. Anziché la logica nascosta nel middleware o nell'Apex personalizzato, il flusso di evasione viene progettato, monitorato e gestito da un'unica posizione.
- Punti di integrazione nativi per i sistemi a valle. Anziché richiedere una propria integrazione personalizzata nel record Ordine, DRO scompone l'ordine commerciale in operazioni tecniche di evasione. Ogni operazione trasporta esattamente i dati necessari al sistema a valle nella struttura prevista.
- Ogni fase del flusso di evasione ha uno stato. Le condizioni di rischio, in cui una fase rischia di non rispettare i contratti sui livelli di servizio (SLA), vengono evidenziate automaticamente. I team operativi possono visualizzare l'intera immagine a valle da un'unica visualizzazione senza passare da un sistema all'altro.
Per le aziende che attualmente gestiscono provisioning, aggiornamenti ERP e trigger di fatturazione tramite integrazioni separate da CPQ, DRO rappresenta un significativo miglioramento dell'architettura. Questo approccio è rilevante per le aziende di telecomunicazioni, servizi tecnologici e produzione in cui l'evasione coinvolge più team interni o fornitori di terze parti. La complessità distribuita su molte connessioni è consolidata in un unico modello di orchestrazione visibile.
Implicazione pratica
Si consideri un'azienda che vende un abbonamento software con le seguenti dipendenze a valle.
- Un ERP che deve riconoscere il reddito
- Un sistema di fatturazione che deve avviare la pianificazione della fattura e
- Piattaforma di provisioning che deve attivare la licenza.
In CPQ, queste dipendenze in genere richiedono tre integrazioni separate, ciascuna attivata dal record Ordine e dalla gestione indipendente delle modifiche. In Gestione del reddito con DRO, l'ordine commerciale viene effettuato contemporaneamente. DRO lo scompone in tre operazioni di evasione orchestrate, una per ogni sistema a valle e ciascuna con il payload tecnico corretto. Se l'ordine viene modificato, DRO riorchestra automaticamente le operazioni a valle. Il team operativo visualizza tutte e tre le operazioni, il loro stato ed eventuali condizioni di rischio in un'unica area di disegno. Non sono necessarie modifiche della logica middleware.
Integrazione ERP
L'integrazione ERP è una delle aree di maggior impatto da affrontare durante la migrazione.
- In Gestione del reddito, Order e OrderProduct sono oggetti Salesforce standard. Le integrazioni ERP che attualmente fanno riferimento a oggetti personalizzati CPQ devono essere rimappate a questi oggetti standard come parte della migrazione.
- Per le aziende che utilizzano DRO, gli aggiornamenti ERP possono essere attivati come operazioni di evasione orchestrate anziché come integrazioni dirette. Questo approccio semplifica il modello di integrazione e garantisce che gli aggiornamenti ERP siano sequenziati correttamente all'interno del flusso di evasione più ampio.
- La rimappatura degli identificatori dei campi di integrazione, ad esempio ID ordine e ID contratto, è un'attività di migrazione chiave. Affrontare questa attività come stream di lavoro esplicito.
- Utilizzare Gestione fatture per semplificare l'integrazione trasferendo i record Fattura da Gestione del reddito al sistema ERP.
Integrazione del sistema di fatturazione
L'integrazione del sistema di fatturazione richiede una valutazione deliberata durante la migrazione.
- Se si utilizza un sistema di fatturazione di terze parti insieme a CPQ, valutare se le funzionalità di fatturazione native di Gestione del reddito possono sostituirlo. Il consolidamento in un'unica piattaforma semplifica notevolmente l'architettura.
- Se si mantiene un sistema di fatturazione esterno, i trigger di fatturazione possono essere modellati come operazioni di evasione DRO, offrendo al team operativo la visibilità dell'avvio della fatturazione all'interno della stessa area di disegno orchestrazione del provisioning e dell'ERP.
- I flussi di lavoro di riconciliazione delle fatture e dei pagamenti devono essere convalidati nuovamente nell'ambito dei criteri di accettazione in tempo reale.
Integrazione del sistema di provisioning
L'integrazione del provisioning è una delle aree in cui DRO offre il valore operativo più diretto.
- Il provisioning è il punto in cui il valore dell'orchestrazione di DRO viene percepito più direttamente. L'ordine commerciale descrive l'acquisto del cliente. DRO lo traduce nella specifica tecnica necessaria al sistema di provisioning.
- Per le aziende con decomposizione di prodotto complessa in cui un singolo prodotto commerciale richiede più azioni di provisioning tecnico, la mappatura della decomposizione di DRO gestisce questa operazione in modo nativo, eliminando la necessità di logica di traduzione personalizzata nel middleware.
- Gli SLA di provisioning possono essere definiti a livello di operazione DRO e le condizioni di rischio vengono evidenziate automaticamente quando un'operazione rischia di non raggiungere l'obiettivo.
