View source for Migrating to Next Best Action Designer

Migrating to Next Best Action Designer / ← Migrating to Next-Best-Action Designer

You do not have permission to edit this page, for the following reasons:

• The action you have requested is limited to users in one of the groups: Users, editor, pegaemployee.
• The action you have requested is limited to users in one of the groups: pegaemployee, editor, Administrators.

---

You can view and copy the source of this page.

{{Design pattern |E-mail notification sent=True |Title=Migrating to Next-Best-Action Designer|Description=Considerations when migrating to Next-Best-Action Designer|Version=8.5|Applications=Pega Customer Decision Hub|Capability Area=Next Best Action|Owner=Allan Brooks }} == Introduction == This article highlights various points to consider when planning to migrate an existing Pega Customer Decision Hub™ project to Next-Best-Action Designer. It assumes the decision to migrate has already been made. If you are still deciding whether or not to adopt Next-Best-Action Designer, consult your Client Success Manager to arrange a Solution Alignment Workshop to explore the benefits to your project. Worldwide, there are different styles of Decision Management solutions implemented in Pega Platform™, using versions 6, 7, and 8. The following article is a collation of experiences from real migration exercises to provide you with general areas for consideration when planning to migrate to Next-Best-Action Designer. With "Keeping Current" in mind, it is always recommended to carry out this migration in the latest version of Pega Platform. === Intended Readers === * Lead Decisioning Architect * Lead System Architect * Business Architect * Product Owner === Scenario === The scenario assumes the following: * An existing Pega Customer Decision Hub or Pega Marketing implementation in Pega Platform 7.x / 8.x * Not using Next-Best-Action Designer * Intending on updating to version 8.5 or higher to adopt Next-Best-Action Designer <blockquote>'''Note:''' This article assumes you have the knowledge of Pega Customer Decision Hub (version 8.5 or higher) and Next-Best-Action Designer knowledge. For more information on these topics, see [https://academy.pega.com/certifications#p-d27ff75a-4333-4b3f-b43b-1b14c5b21b39 Decisioning Consultant Mission] on Pega Academy.</blockquote> ===Required Roles=== {| class="wikitable" |+ NBA-D Migration Required Roles !Role !Remit |- |Lead Decisioning Architect | |- |Lead System Architect | |- |Business Architect | |- |Product Owner | |} ===Before you begin=== The main areas for migration: # Deciding on transformation or complete solution rewrite # Environment preparation # Application preparation # Rule migration # Logic transformation # Testing and deployment # Organizational realignment == Deciding on Transformation vs Complete Solution Rewrite == === Using Pega Platform version 6? === * Start fresh on updated environments === Using Pega Platform version 7 or higher? === # Analyze how ready the project and business are for Next-Best-Action Designer decision management. # Consider the current Pega Customer Decision Hub framework being used. # Compare the current framework to the latest Next-Best-Action Designer framework. The latest Solution Alignment Workshop goes through more than 60 subsequent questions grouped into the following categories: * Current capabilities within the team * Data availability for Pega Customer Decision Hub * Taxonomy structure * Using Next-Best-Action Designer related rule artifacts such as Actions, Treatments, and Constraints * The resemblance of decision management to the Engagement Policies, Analytics, and Arbitration * Business thinking customer-centric being always-on in omnichannel Next Best Action * Operations in place today * Gap analysis for what existing logic needs to be extended into Next-Best-Action Designer For example: * Is there a single framework for all actions or are you using Pega Marketing Campaigns for several actions at a time? * Are all actions (or propositions) in the existing framework still valid? * Is the business logic reusable or tailored for single use cases? * Is there a meaningful Proposition Hierarchy for Issues and Groups allowing for next best action Arbitration? [[File:NBADesignerFlow.png|Next-Best-Action Designer top level flow|alt=A diagram showing the top level flow of Next-Best-Action Designer|none|frame]] If your existing project does not fit the latest next best action framework, now might be the time to start fresh in Next-Best-Action Designer to take full advantage of its new features. If the current framework resembles the latest Next-Best-Action Designer framework, transformation is possible. However, there may be additional overhead in extending the Next-Best-Action Designer framework where required. During this time, it is recommended to discard logic that is no longer needed or not Pega best practice. == Preparing your environment == === Platform Version - Keeping Current === With the concept of "Keeping Current" in mind, it is always recommended to carry out this migration in the latest version of Pega Platform (at minimum, the recommended version is 8.5.3). # Update to latest Pega Platform version following all update steps. ## Perform Hotfix Catalogue run. ## Commit all required hotfixes. ## Install all Customer Decision Hub hotfixes. ##* Customer Decision Hub hotfixes are not included in the Hotfix Catalogue run. For more information on hotfixes, see [https://community.pega.com/knowledgebase/articles/required-pega-customer-decision-hub-and-pega-marketing-hotfixes Required Pega Customer Decision Hub Hotfixes] on Pega Documentation. # If you are using a vertical Pega Customer Decision Hub application (Pega Customer Decision Hub for Communications, Pega Marketing for Finance): ## Update your vertical application. ## Ensure all vertical hotfixes are installed. # Use the Upgrade Validate Tool in Revalidate and Save mode for existing decisioning rules. This ensures that the rules have the correct metadata in the underlying XML. === Environment Sizing === Ensure the environment is sized for carrying out outbound next best actions. This is a batch process that processes all customers and actions in one batch. If the project mainly used segments and Pega Marketing Campaigns, this will be an important consideration, as outbound next best actions will become more resource intensive, especially while concurrently serving inbound next best action requests. For more information on how to request Hardware Sizing from Pega, see [https://academy.pega.com/topic/submitting-hardware-sizing-estimate-request/v1 Submitting a Hardware Sizing Request] on Pega Academy. === Data structure and provisioning === ==== Data Structure ==== Next-Best-Action Designer provides a user-friendly interface for configuring business logic. This works best when data is provided as follows:<blockquote><code>{field Name}={field Value}</code></blockquote>Data provided as Key Value pairs can still be used with Next-Best-Action Designer. However, this adds a layer of complexity for operators when configuring business logic. <blockquote><code>{field Name}={Name value} {field Value}={Value value}</code></blockquote>Changing the data structure is a major decision, but it is worth considering the benefits in usability during a migration to Next-Best-Action Designer. ==== Data Provisioning ==== Next-Best-Action Designer serves inbound and outbound requests. Outbound requests are often scheduled and can be run closely to a data update to ensure timely data is used. Inbound requests are not scheduled and can happen around the clock. Therefore, consider how data can be kept as up to date as possible for ensuring uptime during heavy outbound batch runs. ==== Multi-level data ==== If you perform multi-level decisioning, but you have only specified other levels through associated data, now you should consider specifying those as additional contexts in the Context Dictionary. To do so, take advantage of multilevel decisioning in Next-Best-Action Designer. == Preparing your application == === Remove old Next-Best-Action Designer configurations === It is common for Next-Best-Action Designer instances to have been created either accidentally or during testing or training. If an operator in Pega Marketing clicks on the Next Best Action button on the navigation pane, a Next-Best-Action Designer model instance can be created. In rare situations, some applications were shipped with Next-Best-Action Designer instances, for example Pega Marketing For Communications with demo artifacts has several Next-Best-Action Designer model instances. To remove old Next-Best-Action Designer Configurations: # For environments updated from versions 7.3 - 8.2 to 8.3+, Pega Platform will try to update the existing Next-Best-Action Designer instance. Since Next-Best-Action Designer has not been used before, it is best to start with a fresh model. # If you are already using the Engagement Policy tab on Action rules, you will need to perform an Next-Best-Action Designer update. For more information on the process, see [https://community.pega.com/knowledgebase/articles/pega-marketing-and-pega-customer-decision-hub-reference-materials/upgrading-next-best-action-designer Upgrading NBA-Designer] on Pega Community. '''Note:''' This is required as the Proposition Filters belong to Next-Best-Action Designer # Check ''Rule-PegaMKT-NBA-Model'' for instances. ## You cannot withdraw the instances, you have to delete them using ''InsKey'' Activity. ## To find ''InsKeys:'' ### Navigate to class ''Rule-PegaMKT-NBA-Model.'' ### View '''Instances'''. ### Go to '''Clipboard''' → '''User Pages''' → '''''pgRepPgSubSectionpzViewInstancesB'' → ''pxResults.''''' ==== Issue: Next-Best-Action Designer strategy names are already used or customized in the client ruleset ==== Some projects may have created strategies that use the same name as strategies used by Next-Best-Action Designer. Client strategies should be renamed and the original withdrawn, to allow Next-Best-Action Designer to find the indented rules provided by it. One method of identifying strategy rules present in the client ruleset and ''PegaMKT-Engine'' Ruleset is to create a report showing the overlap: # Save as the out of the box ''GetStrategies'' report. # Remove Columns ''pzInsKey'' and ''pyRuleSetVersion.'' # Add the following filters: #*''pyRuleSet'' is equal to ''PegaMKT-Engine'' #* ''pyRuleSet'' is equal to your rule set name # Rules in this report in your ruleset should be renamed and originals withdrawn. [[File:Report_to_identify_NBA-D_rule_names_in_use_in_your_own_ruleset.png|alt=Screenshot of the report showing overlap in rule names|none|thumb|650x650px|Report to identify Next-Best-Action Designer rule names in use in your own ruleset]] === Disable Dynamic System Setting (DSS) LegacyMode === If updating from versions 7 to 8, the Dynamic System Setting '''LegacyMode''' must be set to <code>false</code>. This may cause existing strategies to start failing, and may become apparent in unit tests that start to show a lot of failures. === Using Revision Manager === When using Revision Manager, you should perform the migration outside of the revision manager and to save the generated artifacts, including context dictionary, in the overlay ruleset. The ruleset version can be deployed back into the Revision Manager environment which will pick up the latest rules in the next revision. You will need to make the next-best-action model rules available to the overlay. Add the following rule types: * ''NBA Hierarchy'' * ''NBA Channels'' * ''NBA Definition'' * ''NBA Constraints'' <blockquote> '''Important:''' Consider 1:1 Operations Manager for managing your revisions. </blockquote> === Access Group === Ensure the operator access groups have access to the Pega Customer Decision Hub portal. Consider the Access Group Design Time Ruleset Version, which determines where system generated rules are saved at Design Time. ==== Access Group DesignTime Ruleset Version ==== The DesignTime Ruleset Version defined on the AccessGroup is where the Next-Best-Action Designer generated rules will be created and updated. This must be configured to the desired unlocked Ruleset Version (RSV). If previously you were using branches for all of the development, you need to consider a new development model. Consider 1:1 Ops Manager to remove the need for operators to consider the RuleSet Version they need to work in. == Rule migration == The following are the two most common scenarios for existing implementations: * The client is using Proposition Data Decision Request (DDR) rules for the Issues/Groups along with 1-3 proposition filters for each Issue/Group. * The client is using a customized framework where the eligibilities are configured as metadata within the proposition DDR rules and applied programmatically using custom code. For other more complex scenarios, it is best to reconsider starting fresh, if the existing framework deviates too much from the Next-Best-Action Designer Framework. === Taxonomy === First step is to configure the Taxonomy for Next-Best-Action Designer. If the existing hierarchy will remain as is, then you can just map the existing Issues and groups in the Taxonomy tab. If the hierarchy is going to change significantly, then it would be worthwhile considering starting fresh instead of migrating. Once the taxonomy has been configured, you can start configuring the engagement policies for Top Level, Issue, and Group Level. This needs to be done prior to migrating actions to ensure the underlying Next-Best-Action Designer strategies and proposition filters have been generated. If the project has been using Treatments in the Proposition Hierarchy, do not include the Issue "Treatments". Any other operations Issue Groups such as those used for action templates, should not be included in the Taxonomy. For more information on action templates, see [https://wiki.pega.com/index.php/Action_Flow_Template Action Templates] on Pega Wiki.<blockquote>'''Tip:''' Encourage the Business Owner to take advantage of the Issue Group description and Nickname columns in Next-Best-Action Designer to describe Actions. </blockquote> === Migrating Propositions to Actions === ==== Proposition Migration ==== Migrating propositions to Actions requires following the steps below. <blockquote>'''Note:''' It is advisable to conduct this exercise for one Issue/Group at a time</blockquote> # Prepare a mapping of all existing proposition eligibilities to Next-Best-Action Designer's Eligibility, Applicability, and Suitability. # Export CSV files for each Issue/Group Decision Data Record rule. # Import the CSV files to each Issue/Group as Actions, using the import Actions option in the Pega Customer Decision Hub portal. For more information on importing actions, see [https://academy.pega.com/topic/creating-actions/v1 Creating Actions] on Pega Academy. # Mark all properties and when rules needed for the engagement policies as '''Relevant Records'''. #* If you are using strategies, you need to add the Custom Field to the History tab '''NBACategory''' and Eligibility/Applicability/Suitability. # Manually configure each Action's Eligibility, Applicability, and Suitability criteria as per the prepared mapping created in Step 1. # Run a baseline simulation using the old proposition filters, and another using the Next-Best-Action Designer strategies to verify that the engagement policies have been mapped correctly. In case the number of propositions to be migrated is very large, you should create custom activities to automate the migration. This requires strong Lead System Architect (LSA) experience to be able to reverse engineer the logic executed when creating an Action and reusing it for a one time migration. An example of this can be done as follows: # Create a custom activity that iterates over existing proposition filters and exports to a file the existing eligibility criteria as per the example below assuming all existing criteria is built as when rules. The complexity of this step depends on how many proposition filters there are per group, and whether the logic is built as when rules only, or a combination of when rules and eligibility builder criteria. If it is too complex, then creating the file manually is advisable. # Create a custom dataflow and activity that processes the file prepared in the previous step and creates the Action for each proposition and maps the Eligibility/Applicability/Suitability criteria as defined in the file. Example file with prepared Eligibility/Applicability/Suitability assuming all criteria is defined as when rules: {| class="wikitable" |pyIssue |pyGroup |pyName |E_Logic String |E_DefaultBehavior |E_RuleReferences |A_Logic String |A_Default Behavior |A_RuleReferences |S_LogicString |S_DefaultBehavior |S_RuleReferences |- |Sales |Payment |Action1 |A AND B |TRUE |R101,R148 |A AND !B |TRUE |R1213,R1004 | | | |- |Sales |Payment |Action2 | | | | | | | | | |- |Sales |Mortgages |Action3 | | | | | | | | | |- |Service |Mortgages |Action4 | | | | | | | | | |- |Upsell |CreditCard |Action5 | | | | | | | | | |- |Upsell |CreditCard |Action6 | | | | | | | | | |} ===== Treatment Migration ===== In case treatments are in use, you will need to migrate treatments to the out-of-the-box treatments. Note that treatment level eligibility is only supported in version 8.6 or higher. For cases where the out-of-the-box treatments are not fitting, use the '''Other''' treatment type. For more information on how to configure and use the '''Other''' treatment type, see [https://community.pega.com/knowledgebase/articles/pega-customer-decision-hub-user-guide/86/adding-additional-channels-next-best-action-designer Adding additional channels to Next-Best-Action Designer] on Pega Documentation. === Logic Transformation === It is best to not deviate too much from the Next-Best-Action Designer framework, as it has best practices for omnichannel decision management embedded within the framework. As such, it is important to evaluate the business requirements and challenge them where necessary, to avoid adding too much complexity on top of the framework. In cases where the requirement is valid, you can use one of the available extension points within the framework to add the needed logic. A comprehensive list of all available extension points can be found at [https://community.pega.com/knowledgebase/articles/pega-customer-decision-hub-user-guide/86/nba-strategy-framework-extension-points NBA Strategy framework extension points] on Pega Documentation. Find some key considerations to plan for when migrating the logic below: ==== Constraints ==== Key considerations when migrating constraints, is to note that Group Level constraints supersede Action Level constraints. As such, if the contact policy does not apply to all actions in a group, do not create it on the group level and apply it on the individual actions. Adding more tracking periods for use in contact policies is possible and well documented at [https://community.pega.com/knowledgebase/articles/pega-customer-decision-hub-user-guide/86/adding-more-tracking-time-periods-contact-policies Adding more tracking time periods for contact policies] on Pega Documentation. Note that in addition to configuring the constraints and additional tracking periods, you will also need to build a custom dataflow and strategy to prepopulate the '''ActionInsights''' dataset prior to going live with the Next-Best-Action Designer framework. This is only required if the existing framework is already live on production, to ensure contact policies are applied post migration without impact on the customers. You can create a dataflow that simulates the '''ProcessSuppressions''' dataflow using the Interaction History fact table as a source, but that could pose performance issues if the size of the fact table is too large. A better approach would be to create a dataflow that uses the Customer Table as the source, and a custom strategy that uses the Interaction History Summaries for the predefined tracking periods to calculate the suppressions per customer, then send them to the '''ActionInsights''' DataSet. Below is an example of such a dataflow and strategy. <blockquote>'''Note:''' After completing this step you must ensure that the '''ProcessSuppressions''' dataflow is executed with every new response captured, so that the suppressions continue to be calculated prior to turning on the Next-Best-Action Designer Framework.</blockquote> [[File:Action_Insight_migration_DF.png|alt=Example data flow for migrating constraints data|none|frame|Example data flow for migrating constraints data]] Example Strategy: [[File:ActionInsightsStrategy.png|alt=An example strategy prepopulating the ActionInsights dataset|none|frame|An example of a custom strategy]] ==== Adaptive Models and Arbitration ==== If adaptive models are already in use, it is best to reuse the existing models within the Action Scoring extension point. If the client is interested in using the new predictions built into the Next-Best-Action Designer framework, you can configure the out-of-the-box adaptive models with predictors, and enable them initially in shadow mode until they have collected enough responses to turn them on and discard the old models. For projects not using adaptive models, this is a good moment to encourage using them, as their value has been proven with many clients. A common pattern is an A/B test configuration to compare the performance of the adaptive models versus the current arbitration framework, to prove their value before turning them on for all customers. == Test Plan == Unit Testing and Simulation Testing will be essential in validating the correctness of all migrated artifacts. Use simulation testing to establish a baseline using the old strategy framework, and compare it with a simulation run on the migrated logic to ensure the Next-Best-Action Designer framework is giving the expected results. <blockquote>'''Note:''' It is advisable to split the simulation tests per Issue/Group.</blockquote>Performance Testing is another key test that is essential to ensure the new framework performs within the expected service-level agreement (SLA). Again, make sure you have a baseline performance test to compare it with the Next-Best-Action Designer framework tests. One key consideration for performance optimization, is whether your context dictionary utilizes a single level or a multilevel hierarchy. If you are have a single level customer hierarchy, then it is best to remove the '''NBA_TopLevel_AllActions''' strategy from the '''Trigger_NBA_TopLevel''' strategy, as it is only needed for multilevel hierarchies and this change improves the overall execution time significantly. == Deployment Plan == Define a deployment plan early on before starting the migration, so that the work can be planned accordingly. Avoid a radical migration, if the existing framework is already live on production for multiple channels. One key consideration, is the possibility to split the Action and Treatment migration from the Logic Transformation into two phases: # For phase 1, you can focus on completing the migration of all propositions into actions, and only configure the Taxonomy and Engagement Policy tabs of Next-Best-Action Designer. Once this phase is completed, you can simply use the Next-Best-Action Designer Engagement Policy strategies "Trigger_H_NBA_Issue" within your existing framework, and discard the old constructs where engagement policies were being applied. This approach also allows the migration of one Issue or Group at a time, and promoting them to production while work continues on migrating the remaining Issues/Groups. For more information on the Issue and Group level strategies, see [https://community.pega.com/knowledgebase/articles/pega-customer-decision-hub-user-guide/86/trigger-strategy Trigger strategy] on Pega Documentation. # Once phase 1 has been completed you can move on to phase 2, where the logic transformation will take place. Once the migration and testing for this phase is complete, it is best to go live on inbound first, then outbound shortly after. This is primarily to give time to verify the performance and correctness of the results. Another more cautious approach, could be to turn on one channel at a time, or, alternatively, to go live on a pilot group of customers first, before scaling up to the entire base.

Return to Migrating to Next-Best-Action Designer.