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, 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.
From an efficiency and logistical standpoint, this process has multiple potential bottlenecks. For instance, development and testing time must be carefully coordinated by system owners to avoid conflicts for field teams because tests might affect production environments (which can lead to disastrous results). System owners also need to be cautious when overwriting the production environment with a new test environment because overwriting can, if done incorrectly, result in payouts based on test results rather than reality.
To overcome these change management challenges, sales operations teams must look to application lifecycle management (ALM).
What is Application Lifecycle Management?
ALM—the term applies to both a set of business processes and a feature of the Anaplan platform—allows sales organizations to efficiently manage the development, testing, deployment, and ongoing maintenance of models and sales plans. On the Anaplan platform, ALM enables system owners to introduce changes without disturbing day-to-day business operations so that the owners can more thoroughly test different scenarios prior to production.
ALM also allows system owners to distinguish between structural information and production data. Structural information refers to things like a model’s configuration settings, non-production lists, module formulas, and dashboard layouts. In a sales performance management setting, examples include incentive plan calculation logic, crediting rules, and quota-approval processes. By contrast, production data refers to operational data that changes often and is used to drive decision-making in the model. Examples of production data can include sales metrics, sales reps’ metadata, customer accounts, and targets.
Understanding Anaplan model types
If you choose to use ALM on the Anaplan platform, you will work with a few different types of models. Those models are described in the figure below; here’s how they may look in a quota-planning scenario:
- 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
|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|
|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|
|Use this model to test connections with other systems.||Deployed||Production-like||Production-like||Optional|
Multiple types of models are used in ALM environments. We recommend using the first three model types (DEV, UAT, and PROD) in all ALM situations, while the rest are optional.
How does ALM help with sales performance management?
From a competitive business standpoint, ALM offers sales professionals an effective, streamlined way to manage frequent changes while safeguarding against errors. ALM’s ability to easily deploy changes between models creates an environment in which effective testing can occur and be applied without disrupting production.
With ALM, sales performance management system owners can confidently adapt to the growing needs of an ever-changing sales organization. Learn more about how ALM can improve your business and see what is unique to Anaplan’s ALM by reading the datasheet.