This story was originally posted on the Intagnent blog as Using Anaplan’s Application Lifecycle Management to Manage Changes to Your Models.With a rapidly evolving business environment, it’s important for sales organizations to prioritize agility in order to mitigate the impact of unforeseen market dynamics. Being aware of the relationship between potential disruptions and corporate business goals will greatly improve an organization’s ability to be proactive rather than reactive. Refinements in strategies, new products, and team growth can impact any successful sales organization, and responding to them requires careful planning and strategy. In sales performance management (SPM), activities that affect the bottom line the most include planning and implementing new incentive plans, aligning and configuring new territories, identifying and qualifying new targets, and introducing new business processes. SPM software (which includes incentive compensation management software, sales territory management, and quota planning systems applications) was created to help sales organizations manage changes and react quickly, but many organizations struggle to manage these types of changes from inception to final rollout even when equipped with SPM software. Let’s look at incentive compensation management (ICM) as an example use case. A typical sales compensation plan follows these steps heading into a new selling year:
- Requirements: Introduce incentive plan changes or new plans.
- Development: Implement plan changes in the software.
- Testing: Verify plan changes by business users.
- Deployment: Migrate plan changes into production and configure them.
- The DEV model is used to implement requirements you identify for the new quota-setting scheme. This model is owned by the model builders.
- The UAT (user acceptance testing) model is used to test the quota-setting functionality, quota-adjustment process, and quota-assignment process. This model is owned by the testers, who normally are on the sales operations team.
- The PROD model is the field-facing model that supports the actual quota-setting and approval processes using production data and configuration. This model is normally owned by the sales operations team.
Figure 1: Type of models
|Model type||Description||Model mode||Data||Data volume||Usage|
|DEV||Use this model for making changes to formulas, list structure, modules, and dashboards||Standard||Sample or test data||Small||Recommended|
|UAT||Use this model to allow end users or contributors to validate any changes made to your model before it goes into production||Deployed||Production-like||Production-like||Recommended|
|PROD||This is the model that users actively work in to manage business data. Upstream and downstream data integration to other production systems should use this model.||Deployed||Production||Production||Recommended|
|QA||If you follow a rigorous quality assurance (QA) or test process, use a dedicated QA model for testing before changes are released to production.||Deployed||Production or test||Production-like||Optional|
|Performance testing||Use a separate model to validate that your changes have acceptable performance before releasing to production. Depending on model and workspace size, this model may be kept in archived mode when not in use.||Deployed||Production-like||Large||Optional|
|Data integration testing||Use this model to test connections with other systems.||Deployed||Production-like||Production-like||Optional|