Saving a major technology investment
And not taking the re-platforming bait
I’ve talked many times about the high volume of product failures over the years; but there are also a number of delivery/execution failures that can occur within the consumption chain of the product. A technology failure could be due to a poor implementation, a misaligned selection process, or simply a bad product with a great sales development team. Other times, organizational factors, procedures, or lack of best practices could play a role in the perception of a technology’s performance or scalability.
This becomes a real problem when enterprises look back at a multi-million dollar implementations and the subsequent recurring fees paid to a software vendor.
Should you re-platform, or should you dig a little bit deeper?
If you don’t understand what is driving the poor performance at the right level of abstraction, the risk you face is replicating the same set of circumstances all over again.
This is a real story, but the names and circumstances have been changed for confidentiality.
The Situation
A number of years prior, a global company had invested considerable sums implementing a configure, price, quote (CPQ) platform to support a large and growing portfolio of highly configurable products. It was initially rolled out in parts of North America and to certain business units, and the original intention was to roll it out globally. This roll out, however, was repeatedly delayed due to a variety of issues that created a perception that the platform couldn’t scale.
The vendor was brought in at an additional cost to evaluate the situation. Obviously, their focus was on the capabilities of the platform, and they could find nothing wrong with its ability to perform according to spec. Shortly after that, I was asked to take a look.
I didn’t represent the vendor. In fact, I didn’t know all that much about the platform. I had very little time to execute. But, I was armed with questions! Would that be enough?
Coming in, all I knew was that there was a concern about scaling the existing platform globally, and that they were considering another massive investment in time and money to re-platform. On the surface, that seemed fair, but I hadn’t asked any questions yet, so I really didn’t know.
The Problem & The Target
During the course of the initial interviews, I was able to get up to speed on unfamiliar terminology and activities that were being performed. It seems like every company is able to come up with their own language!
Within the first few days, I was able to identify 3 core issues:
Management of the entire ecosystem around CPQ was laborious and time-consuming
There was a growing (already large) backlog of regression testing stories
The product catalog and pricing complexity had been carried forward from legacy systems
So basically, there were a combination of factors - ranging from the product catalog, operations, to technology delivery - which contributed to the problem. Three separate areas that don’t always play well together. That’s likely why they were where they were.
I’m going to do a little math here:
OO + NT = EOO
Or, an old organization introducing new technology results in an expensive old organization. The ideal, and the target, is to create a nimble new organization without incurring additional cost. What comes next should have been incorporated into the original roll-out. Who knows why these things are overlooked. Probably the perceived cost.
The Analysis
Time and Energy
The company was constrained by a highly manual process with duplication of efforts across teams and systems.
Price books were entered manually, and separately, into the CPQ platform and the Order to Cash (OTC) platform
The QA was performed in silos and with limited cross-team collaboration. The resulting issues were not discovered until a product was in production
CPQ rule configuration was complex, and duplicative, due to the initial constraints of the platform. However, those were lifted, and no one took notice (including the vendor).
Resources in sales operations used were at 75% capacity when entering new price books, updating existing price books, and entering sales promotions throughout the year. Also, the sales compensation rules were entered and maintained separately in CPQ and OTC platforms.
Can’t Catch Up
The backlog of regression testing stories seemed too large to shrink, but as it grew, the challenge grew, and the production errors became even more costly.
Testing responsibilities spanned multiple teams who were each using different tools and methods, making collaboration and reuse challenging, if not impossible
Few testing scripts had been written, so each net-new feature (however small) required a complete testing scenario to be created (instead of updated). As a result, they were rarely addressed
Undue Complexity
The product catalog and pricing complexity had been carried forward over time.
Historical pricing controls were not replicated in CPQ, resulting in pricing errors and added cycle time. A look-back integration was possible, but had never been attempted.
The product catalog was derived from the constraints of legacy systems. As new systems came online, opportunities to rationalize legacy processes and structures were missed
The replication of similar products and services across business units caused duplicate of effort for the managing team. Quick fixes were employed which had long term implications
No centralized, enterprise-scale billing and compensation strategy had been implemented. Account hierarchies could not be established, when required
Manual entries resulted in unpredictable errors. Doing so in multiple systems could result in different errors in each system and were nearly impossible to identify prior to processing the first sales order. This posed a serious QA challenge.
The Countermeasures
This is going to sound overly simple, but at the end of the day, we need to make the trade-offs between reducing cost, and preserving value.
Automate
A price book is created for each product and contains pricing and sales compensation information. The existing process looked like this:
While the suggested approach does not attempt to simplify the price book entry into the OTC system (that would require some more work), this concept suggests treating OTC as the product master, entering price books once, and having CPQ consume the needed (and mastered) data in real-time, or near real-time (or whatever made sense).
Simplify
The CPQ platform had introduced a more efficient means to build configuration rules, and this capability had gone unnoticed. Specifically, the legacy approach was extremely verbose, and required new code for each product, and each variation/attribute. It would look something like this:
Whereas the relatively new (to the platform, not to efficient coders) approach was constraint based, and was far more efficient. It would look something like this:
The business value here was thus:
It significantly reduced go-to-market lead-time
They could do more with current resources
They would establish a product master in the OTC platform
There would be a reduction in data entry errors
Rules could be simplified and would scale with new products
The existing platform could support the new approach 👈 👀
Shrink the testing script backlog to ZERO
This absolutely had to be done in order to scale the platform out to additional business units and regions. I recommended the following:
Build a temporary team of skilled resources that can properly design, estimate and build regression testing scripts on a common platform. Attack the current testing story backlog and reduce it to ZERO
Plan to automate the entire life cycle where feasible to reduce the need for manual interventions. Integrate automated test scripts with automated code movement tools in order to shrink the cycle time by eliminating timing gaps (computers never sleep)
Industrialize the new approach into Center of Excellence (CoE) designed to support the delivery process going forward 👈 👀
Assess the current state of product, pricing and billing strategy
I won’t go into a lot of detail here since these were only guidelines for a rather complex future project. But the following principles were highlighted (and detailed):
Align cost to serve
Support simple, clear and consistent pricing
Simplify and strengthen the product catalog
Rationalize the portfolio (and align across business units)
This was also a critical issue that contributed to global scaling, but it was easy to take a pass on in the near term because this work would have delayed the roll-out even longer. Would the delay be critical? Without knowing more about that platform and its content, I can’t say. But, I believe that I addressed this conceptually up there somewhere 👆
The bottom line
We are often instructed to look in one direction, and if we do, we can miss the real underlying problems. A vendor is not motivated to look beyond their platform because it’s beyond their competency and responsibility. A client may not be motivated to look beyond their authority or purview, because…politics. But when big decisions have to be made, those constraints can be dangerous. It’s extremely important to see/understand the larger end-to-end process.
Local optimization leads to global sub-optimization
I say this a lot, because it’s always true. It doesn’t need to be complex, or politically charged. It just needs to make sense to everyone involved. Your job is to help make sense of it.
Multiple groups (and Executives) were able to get behind this analysis in a matter of weeks, not months, or years. It took years to get there, but now they had a high level road map for saving their investment and getting to their desired future sooner, rather than never.