Avoid CPQ Model Conversion Failures: Involve Your Modeling Team Early

Automation seems like the answer - until it builds something no one wants to use.

Many SAP-to-Tacton conversion projects start with the same dream: build a tool that reads SAP rules and spits out working CPQ models. But if you don't involve your modelling team early, you risk creating models that are technically correct but practically useless. In this part of our series, we explore why automation alone isn’t enough and how to make sure your modelers aren't just an afterthought.

Here’s how it usually happens.

A development team is tasked with creating an automatic rule converter. They reverse-engineer the SAP structure, design a parser, and maybe even output test models. At first, things look promising - until they hand the results over to the modelling team. That’s when the problems begin.

• The model structure doesn’t match the logic used by sales.
• The naming conventions are off.
• Features are grouped in strange ways that don’t match how products are actually sold.
• Modellers can't debug or maintain the new structure.
• Worse: the result is untrustworthy, so it never gets used.

This isn't just a workflow issue - it’s a strategic failure. Because while automation can handle repetitive tasks and rule syntax, only experienced modelers can tell you what should be modeled, not just what can be.

CPQ modelling is about more than constraint translation. It’s about understanding how customers interact with the product, how to guide users, what needs to be selectable or driven, and how to future-proof the structure. That’s domain knowledge. And it doesn’t live in your parser.

At cpq.se, we’ve seen projects where hundreds of hours were spent building conversion tools, only to find that the output had to be rebuilt by hand. It’s not because the logic was wrong - it’s because the model wasn’t usable.

So how do you avoid this?

Start by bringing the modelling team in from the beginning. Before you write a single line of conversion logic, sit down with the people who build and maintain your CPQ models.

• Review your current manually built models.
• Understand what works and what doesn’t.
• Identify common patterns, reuse components, and modeling approaches.
• Ask what kind of output format would actually save time - not just technically, but in daily work.

This collaboration also addresses another key issue: fear.

To a product modeller, automation might feel like a threat. “Will the tool replace my work?” But in reality, the modeller's expertise becomes even more critical. You need their input to guide the conversion logic, validate the results, and ensure the models remain flexible and correct over time.

One more point: you’ll need ongoing communication. Your automated tool will never get it perfect the first time. There will be questions. Lots of them. You need a feedback loop so your tooling evolves with the real-world requirements of the CPQ implementation.

In summary: a CPQ model generated without modeller involvement is like documentation written by someone who never used the system. It might tick the boxes, but it won’t work in practice.

In our next post, we’ll dig deeper into one of the biggest mistakes in rule conversion: translating every SAP precondition into a CPQ constraint - when there’s usually a better way.

Need a practical plan for building CPQ models with automation and human insight?
Talk to Magnus or Patrik about how cpq.se tackles model-driven projects: https://www.cpq.se/meetcpqse

Also read: https://www.cpq.se/the-cpq-blog/tacton-studio-modeling