Loading
Implementatiebenaderingen

Implementatiebenaderingen

Er is niet één correcte manier om de volgorde van een livegang van Omzetbeheer te bepalen. De juiste aanpak is afhankelijk van de grootte, complexiteit, risicotolerantie en de migratiestrategie van uw bedrijf. Elk van deze vier benaderingen vertegenwoordigt een andere manier om te migreren naar Omzetbeheer.

Big Bang

Alle mogelijkheden binnen het bereik gaan gelijktijdig live voor alle betrokken gebruikers in één onderhoudsvenster.

Hier zijn enkele belangrijke aspecten van de Big Bang-aanpak.

  • Het gehele omzetteam migreert tegelijkertijd naar Omzetbeheer. Er is geen periode van dual-system werking.
  • Voer meerdere "dry-run cutovers" uit in een sandbox zodat uw team de volgorde kan oefenen voordat de productie live gaat.
  • Planning van terugdraaien is essentieel. Definieer en test uw terugdraaiprocedure voordat u overgaat tot een Big Bang Cutover.
  • Een succesvolle Big Bang levert de schoonste uitkomst van één systeem, één gegevensmodel en geen onduidelijkheid over waar records moeten worden gemaakt.

Pilot-first

Een representatieve subset van het bedrijf, zoals een productlijn, een geografie of een gedefinieerde groep verkoopvertegenwoordigers, gaat als eerste live. De bredere implementatie volgt nadat u de proef hebt gevalideerd en eventuele problemen hebt opgelost.

Hier zijn enkele belangrijke aspecten van de Pilot-First-aanpak.

  • Kies een proefbereik dat echt de bredere omgeving vertegenwoordigt. Een te eenvoudige proef brengt niet de problemen aan het licht die belangrijk zijn voor de volledige implementatie.
  • Behandel de proef als een investering in proces en configuratie. De pilot produceert een geteste en gevalideerde configuratie en een team dat de go-live heeft doorlopen voordat de bredere implementatie begint.
  • Gebruik feedback van de pilot om de proces- en configuratiebeslissingen voor volgende cohorten vorm te geven. De pilot is een leeroefening, niet alleen een vroege go-live.

Brug

Alle nieuwe klanten gaan onmiddellijk live in Omzetbeheer. Bestaande CPQ-contracten blijven in CPQ. Migreer op natuurlijke wijze naar Omzetbeheer bij verlenging of wijziging, of via een gepland migratiecohort in de loop van de tijd.

Hier zijn enkele belangrijke aspecten van de Bridge-aanpak.

  • Met deze benadering realiseert uw bedrijf onmiddellijk waarde voor Omzetbeheer voor nieuwe deals, terwijl het bestaande installatiebestand in een gemeten tempo wordt beheerd.
  • CPQ-licentiebehoud is belangrijk in een brugstrategie. De bestaande installatiebasis blijft CPQ-toegang vereisen totdat elke record is gemigreerd.
  • Uw team gebruikt twee systemen parallel voor een bepaalde periode. Zorg voor duidelijke richtlijnen voor verkoop- en operationele teams over welk systeem welk transactietype afhandelt. Zie Co-existentie beheren tijdens de overgangsperiode.
  • Handhaaf verlengingsautomatisering en activumbeheer voor contracten die afkomstig zijn uit CPK in CPK, totdat u die records naar Omzetbeheer migreert.

Op cohort gebaseerd

In plaats van het hele bedrijf in één keer live te gaan, kunt u de implementatie indelen in gedefinieerde cohorten. Elk cohort doorloopt onafhankelijk het volledige go-liveproces, waarbij lessen van elk cohort het volgende informeren.

Hier zijn enkele belangrijke aspecten van de op cohort gebaseerde benadering.

  • Veel voorkomende benaderingen voor segmentering zijn onder meer op geografie of rechtspersoon, op klantsegment of op verkoopbeweging (direct versus partnerkanaal).
  • Elk cohort is een opgenomen go-live-event met zijn eigen gegevensmigratie, integratietests, gebruikersacceptatietests (UAT) en cutover-plan.
  • Tegen de tijd dat volgende cohorten live gaan, heeft uw team het proces meerdere malen uitgevoerd en is de configuratie goed begrepen. Deze ervaring heeft de neiging om progressief soepelere go-live-events te produceren.
  • Cohortgebaseerde implementatie is een natuurlijke oplossing voor bedrijven met meerdere regio's of entiteiten waarbij regionale verschillen in prijsstelling, belasting of levering betekenen dat elk cohort echt verschillende vereisten heeft.
 
Wordt geladen
Salesforce Help | Article