Today, few organizations have the capacity, maturity, and forethought to build a scalable quote-to-cash (QTC) system, the bridge between CRM and ERP, when they are just getting started.
This means that by the time a QTC strategy becomes part of a company's growth and efficiency roadmap, there are already expectations regarding how sales opportunities should (or should not) be moved through the workflow. The longer a company has operated without an overarching quote-to-cash system, the more fraught with potential pitfalls a QTC implementation becomes.
By setting up an effective change management framework, organizations can avoid those pitfalls and maximize the benefits of a quote-to-cash system, while minimizing the inevitable disruption it can cause the organization.
A simple way of looking at a quote-to-cash strategy is in three stages:
- Configure Price Quotation (CPQ): a sales opportunity is defined and pricing and discounting is determined
- Contract Lifecycle Management (CLM): the approved offer is presented to the customer in a template contract
- Enterprise Resource Planning (ERP): the customer-accepted offer is implemented and billed
In every organization, each of these stages has an obvious owner. Finance or Marketing might own CPQ for example, and Operations and Accounts Receivable the ERP. Any one of those groups could be the overarching quote-to-cash project owner, and would look to functional stakeholders upstream or downstream in the workflow, to help define the majority of the system's requirements. However, this approach only exacerbates the blind spots to which an implementation of this nature is prone. Plus, it cannot be overstated just how deeply integrated a quote-to-cash workflow will be into all areas of the business, not just sales.
Since all major business groups should be represented in the gathering of requirements for a quote-to-cash platform implementation, those requirements must be collected using a common vocabulary. By way of example, a Regulatory group would know a product by the nomenclature used by a regulator, while an Operations stakeholder might use a former name that aligns with how the product is referred to in a legacy provisioning system. Both are right, yet quote-to-cash system requirements can't be effectively gathered and understood until a common vocabulary is agreed upon and adopted.
Another way to surface hidden requirements is through linear mapping of an opportunity as it flows through the sales cycle. In order to do so, start with a simple acquisition order and describe the steps a "happy path" opportunity would take from customer identification to scoping to pricing and onward. Then, for each step along the happy path, think in terms of potential spurs into other groups or processes. This linear mapping would then be duplicated for each different sales scenario: an upsell, a renewal, an incremental order, etc.
With these rough proxy workflows in hand, each stakeholder group could be asked to identify (in the same common vocabulary) areas in which they have active impact, and areas on which they are reliant on the output. This would also be an opportunity to identify parallel or adjacent business processes that are not directly in scope for change through the quote-to-cash implementation. Additionally, when gathering requirements from any stakeholder, it is critical to encourage blue-sky thinking.
Another strategy for uncovering potential blind spots in a QTC implementation is to invite stakeholders to identify the least intuitive parts of their jobs. Using the 80/20 rule, the oddities and exceptions of the current workflow will probably require the greatest degree of solutioning and compromise in the new. Finally, don't be afraid to ask for requirements that don't exist. The more of these anticipated requirements the system can accommodate, the more future-proof it will be.
An additional technique for ensuring a smooth transition to the new system is to identify the way the data within the system is structured and what limitations there are to those structures. For example, if the quote-to-cash system is going to integrate to a billing system that uses nine-digit account numbers to identify unique customers, there is no point in developing a unique customer identifier in the quote-to-cash system.
Obviously, no business is going to stop the sales pipeline, or product evolution because it is rolling out a quote-to-cash system. Building out capacity to incorporate these evolving conditions is vital to the success of any quote-to-cash project. These evolving conditions are more likely to be non-disruptive to the roll-out if they can be shaped to match the system's proposed design. In order to accomplish this, awareness of the upcoming quote-to-cash system launch and how best to frame new products, pricing, and processes to seamlessly integrate into the system is required. By identifying the source of these new requirements and constantly reinforcing the structure and methodology that ensures they can be easily accommodated into the new system, much future rework and costly delays can be avoided. Additionally, this discipline sets the groundwork for steady-state governance of the system once it has been launched.
As soon as system functionality and user experience is relatively firm, it is time to turn the focus toward roll-out communications and training, which should be viewed as a series of changes to underlying business processes. If well-designed, the resulting user experience inside the quote-to-cash system should be intuitive and require very little explanation. However, be sure to look for any non-intuitive outliers, which will come from stakeholders and can be an organization's super-users inside the test environment. Their feedback should shape the resulting communications and training focus. No project is going to account for every scenario, so this is also the time to consider workarounds, and how best to communicate them.
When planning the roll-out, think about the most logical way for different user groups to access support. War rooms are popular, but not always optimal if they are not staffed with experts in all areas of system functionality and process flow. Other options could include supports cases that triage to the appropriate team or existing collaboration tools with topic-specific help groups.
Change management isn't an activity that happens after a quote-to-cash project has been scoped, built, and delivered. It should inform the transformation inherent in the project itself, so that the change is organic to the needs of the business, and the quote-to-cash system becomes simply the tool by which those needs are met.
About the Author
Michelle Asselin is the director of Deal and Contract Management at Rogers Communications. Michelle helps develop and oversee the contract strategy for the enterprise business unit.
