So, Why do CPQ projects fail?
This week we’re excited to have Patrik Skjelfoss Principal Business Consultant at CPQ.se
Before co-founding cpq.se Patrik worked with Tacton CPQ for 13 years focusing on Heavy Vehicles and Manufacturing Equipment.
A little about CPQ.se
CPQ provides a true competitive advantage for manufacturers. A smooth implementation of CPQ requires the right combination of experience and expertise. cpq.se has successfully carried out CPQ-implementation projects since 2001. This has led them to become experts in the field of CPQ. Today, many large organizations seek their consulting services for updating and expanding CPQ to new divisions and business areas. Their pragmatic approach to CPQ implementation invites their customers to identify their priorities in order to quickly deliver tangible results.
CPQ.se is headquartered in Uppsala (near Stockholm), and provide their services to the entire northern European region.
New products, new opportunities but also new challenges
CPQ purchases can be an exciting time for manufacturers. Akin to turning over a new leaf from the old way products were sold to a new faster, more efficient way to work. Not only your team be able to ensure accuracy but also enable your customers to get their products fast as their accustomed to. So, why do CPQ projects fail?
CPQ projects fail without backing from senior management
The CPQ process is spread all over the enterprise and touches many groups including sales, IT, engineering, marketing, and order management. The planning and development of a CPQ solution must involve all of these organizations and must address the requirements of each group. CPQ is a knowledge-based tool, and it’s never better than the actual knowledge and data in the tool. Usually, the product expert or senior sales rep who is too busy working with deals is the person most needed for this type of project. Backing from senior management is essential, to allow for prioritization of the implementation of the CPQ over the day-to-day business tasks for all these organizations, including the busy experts.
Scope creep is an uncontrolled growth in a project’s scope after the project has begun. This is very common in CPQ projects as you learn about and define processes that quite often were never documented before. This is why it’s important to define project objectives early in the project, and refer to them as much as possible when deciding on changes to the project. It’s also important to have a defined change control process, with a steering group that has backing from senior management. There’s no easy solution to scope creep, but being aware of the problem is essential.
Aiming at 100% of sales done with CPQ
If you ask an engineer working for an elevator company how many floors the elevators can have the most, he might answer 100. However, maybe 95% of the sales have fewer than 10 floors, and all elevators above 20 floors require some engineer-to-order? So, does it really make sense to allow for 100 floors in the configurator?
We recommend aiming at 80-95% of the configurations done automatically by the CPQ software, and allowing for some manual work for the rest. The reason is that there is typically an 80-20 rule in regards to implementation, where the last 20% of the configuration complexity will take 80% of the implementation time of the tool. It is much better to focus on 80% of the sales initially in the project and to make sure there is a ready process for the other 20% of the sales.
If the project is a success, why not aim higher in the next phase of the project?
Bad data quality
A good sales configurator will use your product data existing in current systems. But how good is the quality of that data today? Do you have an organization in which all knowledge is stored in people’s heads and documentation is missing? As stated above, the output from the configurator will never be better than the input, which means you need to make an inventory of your product data and documentation. You might need to structure and systemize your product data before selecting or implementing sales configuration software. If you don’t, the implementation will probably take much longer than expected, and changes in the tool will be done multiple times back and forth before being able to release.
Too few or too many integrations
Implementing integrations take time, whatever the IT-guy will tell you. Even a standard integration may require some adaptation because the software you are already using and want to integrate to is customized. Adding integrations to all your surrounding tools will add up to a hefty budget, and with some delays added, your project might get stopped before it is released.
Hence it is important to prioritize integrations and to allow for manual integration in the early phases of the project.
Do your prices reside in ERP? Are they only changed every 6 months? Can you export them to Excel initially, to get the project going? If you can get a manual integration to work, try to push the implementation work to the future.
However, from a similar perspective pushing integrations to the future which require a large amount of manual work is also a bad idea. The manual work will cost money and may cause update errors. When selecting a vendor, make sure they have standard integrations to the essential systems you need to integrate to. Focus only on crucial integrations in the early phases to allow for a quick return on investment. Add the additional integrations in later phases, and do separate ROI calculations for the specific integrations.
The configurator cannot solve the configuration problem
The configuration is a complex subject. To put things into perspective; the number of atoms in the universe is estimated to be 10^80. A configurable product with 100 choices and 10 alternatives for each choice has 10^100 combinations. It is important to select a configurator that can solve complex configuration problems, an incorrect selection of sales configurator may lead to being forced to simplify the configuration problem too much and hence giving incorrect configurations or prices to the salesperson.
Too much focus on tangible products
A typical product does not only consist of hardware, but also other intangible products. It’s not uncommon for companies to have higher margins on services, spares, and extended warranties. These products should not be forgotten when implementing the configurator – because without these the configurator is not complete. And if the configurator is not complete, the deals will either be missing these high margin products, or the sales will simply not use the CPQ due to the missing products.
The CPQ isn’t easy to use
If the solution is difficult to use or just slow – it will fail because no one will use it. Your solution should simplify a complex process, not replace one complex process with another. There are often tradeoffs in functionality when simplicity is the primary goal. Make sure your CPQ is achieving a good balance between these two elements. Checking reviews before you select a CPQ vendor can help you learn more from real CPQ users.
The CPQ doesn’t focus on the key users
CPQ projects tend to be initiated by all other departments at companies except sales because sales are too busy working on quotes for customers. Hence the key tasks of the tool often misunderstood and not implemented properly. The most important task of a CPQ is to help the salesperson create a correct, competitive, and valid quote quickly – and what that means exactly is different for different companies. Makes sure key people from the sales department are involved in the selection and development process to ensure that their requirements are covered.
No focus on data maintenance
In most configurable products, the master data changes continuously. New options are added and old ones disappear, new suppliers emerge, prices change, etc. Often, these changes are made on a daily or weekly basis. Typically, these changes are managed in ERP or PLM systems by people not involved in the CPQ maintenance. It’s vital that master data maintenance requires a minimal amount of changes in the CPQ software. It is also equally important that an organization is set up to be responsible for the maintenance of the software because with even a minimal amount of maintenance it still needs to be tested and validated.
A partnership for manufacturing success
It’s easy to see why CPQ projects fail from time to time. The mammoth amount of work and data to get the project off the ground can at times seem daunting. This fear can be valid if you choose a CPQ vendor with lesser experience. With Tacton and CPQ.se you can put your trust in industry-leading experts who have handled complex implementations for more than 20 years with a visionary product. We’d love to help you transform your business, scheduling a demo can make your CPQ project run smoothly, and on time.