Knowledge platform

Cases & Insights.

Practical explorations of CPQ, digital transformation, and technology in industrial environments.

The intention

Good ideas for digital transformation begin with the challenges people face in their daily work. Future cases will begin with realistic industrial or business problems, examine the process and constraints, and develop possible digital solutions.

Each piece will be original, generalized, anonymized, or fictional. The aim is to demonstrate thinking and methods without presenting employer or customer systems, data, processes, or intellectual property as my own.

01 / Growing library

A place for problems worth exploring.

Short, practical explorations of industrial processes and digital solutions. Newest entries first.

Case 6

One product. Three systems. Four names.

An interface can transfer data perfectly and still transfer the wrong meaning.

The same product begins its digital journey in different forms.

Sales records it in CRM as part of a commercial product family. During quotation creation, CPQ represents it as a configurable model with options and rules. Once the order is placed, ERP expects one or several material numbers. Engineering may know it by another technical designation linked to drawings and specifications.

CRMCommercial product family
CPQConfigurable model
ERPMaterial numbers
ENGINEERINGTechnical designation

Each description can be correct within its own context. The difficulty begins when the information has to move.

The data arrives. The meaning does not.

A technically successful interface can transfer every required field without an error. But it cannot decide whether a commercial product family corresponds to one configuration, several configurations or a complete material structure.

It cannot know which technical designation is still valid after a product change. It cannot determine which system should correct the information when two definitions no longer agree.

Without agreed relationships, integration simply transports uncertainty faster.

Shared meaning does not require identical structures

The goal is not to force CRM, CPQ, ERP and engineering systems to describe a product in exactly the same way. Each system serves a different purpose and therefore needs a different view.

The important work is to define how those views relate to one another. A commercial family may lead to several configurable models. One configuration may create multiple material positions. A technical designation may connect the result to a particular drawing or specification.

These relationships are not merely technical mappings. They are business knowledge.

Ownership is part of the architecture

Every important definition and mapping needs a responsible owner. When a product changes, someone must know which systems are affected, who updates the relationship and how the change is validated.

Data governance can sound abstract. In daily work, however, its absence appears as repeated data entry, manual corrections, inconsistent reports and employees asking which value they should trust.

A reliable integration therefore needs more than an interface. It needs shared definitions, clear ownership and a controlled way to keep relationships current.

The perspective

When systems agree on how their different views relate, a handover becomes more than a transfer of fields. The information keeps its meaning as it moves through the process.

Before systems can exchange data, the organization must agree on what that data means—and who keeps that meaning current.

Case 5

CPQ structures the quotation. AI unlocks the knowledge behind it.

In plant engineering, quotation quality depends not only on software and rules, but also on whether the right technical knowledge can be reached at the right moment.

Creating a quotation for an industrial plant is rarely a simple matter of selecting a product and calculating a price.

Technical specifications, previous project experience, product limitations, engineering standards, commercial conditions and customer-specific requirements may all influence the final solution. Some of this knowledge is structured in systems. Much of it, however, remains distributed across documents, emails, spreadsheets, previous quotations and the experience of individual employees.

CPQ can bring structure to this complexity.

It can guide product configuration, apply defined pricing logic, control mandatory selections, support approvals and generate consistent quotation documents. But CPQ can only apply the knowledge that has already been understood, formalized and maintained.

This is where AI could become an important supporting layer.

One question instead of a long search

Imagine that approved technical documentation, product guidelines, lessons from previous projects and internal engineering knowledge could be accessed through one controlled knowledge environment.

Instead of searching through folders, contacting several departments or comparing old documents, an employee could ask:

“Which technical conditions must be checked before offering this equipment for this application?”

Within seconds, AI could bring together the relevant information, explain the reasoning and point to the original approved sources.

The same knowledge could be accessed simultaneously by quotation teams, engineering, sales and other authorized employees—without depending on the availability of one particular expert.

CPQ and AI have different strengths

CPQ is valuable where decisions must be repeatable, controlled and traceable. It can enforce known configuration rules, calculations and workflows.

AI is valuable where knowledge is extensive, partly unstructured and difficult to locate quickly. It can help employees find relevant information, connect related documents and recognize when additional clarification may be necessary.

Used together, they could create a stronger quotation environment:

  • CPQ structures the configuration and commercial process.
  • AI makes the technical knowledge behind that process easier to reach.
  • Employees provide judgment where the situation cannot be fully standardized.

AI could also support the further development of CPQ itself. By identifying recurring questions, frequently used technical explanations and common exceptions, it could help teams recognize which knowledge should eventually become a formal configuration rule or a defined process step.

A shared knowledge base must still be trustworthy

Bringing information under one roof is only useful when employees can trust what they receive.

The underlying documents must be approved, current and clearly owned. Access rights must be respected. Answers should show their sources, and technically critical decisions must remain subject to expert verification.

AI should not silently invent engineering knowledge or replace responsibility. Its purpose should be to make existing organizational knowledge accessible, understandable and reusable.

The perspective

The future of quotation creation may not be one system attempting to do everything.

It may be a combination in which CPQ manages structured decisions, AI provides access to accumulated knowledge, and experienced employees remain responsible for technical judgment.

CPQ can structure what an organization already knows. AI can help that knowledge reach the person who needs it—in seconds rather than hours.

Case 4

When production progress is only visible after asking

A process is not truly transparent when its status exists only in conversations, spreadsheets and individual updates.

The situation

A production order moves through several stages: preparation, material availability, manufacturing, quality control and dispatch.

Each department knows its own part of the process. But there is no shared view showing what has been completed, what is delayed and what requires attention.

To understand the current situation, someone must call a colleague, send an email or compare several spreadsheets.

More data does not automatically create visibility

The necessary information may already exist, but it is distributed across systems, documents and departments.

The first improvement is not necessarily a large new platform. It is to define a small number of meaningful status points that everyone understands:

  • What stage has the order reached?
  • What is currently blocking progress?
  • Who is responsible for the next action?
  • When was the information last updated?

Make exceptions visible

A useful digital overview should not require employees to monitor every order continuously. It should help them recognize the orders that need attention.

Delays, missing materials, unresolved quality issues or overdue approvals should become visible early—before they affect the following production steps or the delivery date.

Support decisions, not just reporting

Production transparency is valuable when it helps people act. The purpose is not to create another dashboard, but to provide reliable information at the moment a decision is needed.

The strongest solution may be a shared status view, an automated notification or a connection between existing systems. The right technology depends on where the information already exists and how employees use it.

The takeaway

A transparent production process does not show everything. It makes the next necessary action clear.

Case 3

When production knowledge exists only in people’s heads

Practical experience creates value only when it remains available to the people who need it.

Imagine a production line where an experienced operator knows that a machine behaves differently under certain material, temperature or operating conditions.

The operator recognizes early warning signs, makes small adjustments and prevents the process from becoming unstable. These decisions are based on years of experience—but much of that knowledge has never been documented.

When another shift takes over, the same situation may be handled differently. If the experienced operator is absent, employees may need to investigate a problem that someone else already knows how to solve.

The result can be longer interruptions, inconsistent product quality and repeated troubleshooting.

Not every observation belongs in a manual

The first reaction might be to document everything. But collecting information without a clear purpose can create additional work without making production more reliable.

I would begin by asking:

  • Which situations repeatedly depend on individual experience?
  • Which observations help identify a problem before it becomes critical?
  • What information does the next shift actually need?
  • Which adjustments can be standardized, and which still require human judgment?

The goal is not to replace experience with instructions. It is to identify the knowledge that should remain available beyond one person or one shift.

Make knowledge accessible during the work

Useful production knowledge should be easy to record and easy to find.

Depending on the situation, this could mean a structured shift handover, a digital logbook, clear troubleshooting guidance or a notification linked to specific operating conditions.

The solution should fit naturally into the work. If documenting an observation takes too long, employees may avoid it. If too much information is collected, the important signals become difficult to find.

Experience remains essential

Digital tools can help preserve observations, reveal recurring patterns and make proven responses available to other employees.

They cannot replace the judgment of experienced operators. Their value lies in helping practical knowledge travel across shifts, teams and time.

The takeaway

Production becomes more resilient when valuable experience is not limited to the person who first gained it.

Digitalization should not replace practical experience. It should make that experience available when and where it is needed.

Case 2

When an exception becomes the everyday process

A temporary workaround can outlast the problem it was created to solve.

An industrial team introduces an additional manual check after a delivery error. Initially, the reason is clear: prevent the same mistake while the underlying issue is investigated.

Months later, the check is still there. Every order passes through it, even though the original issue has been resolved. New employees learn the step, but nobody explains when it is actually needed.

What began as an exception has become part of the everyday process.

Before making it digital

The obvious improvement might be to automate the check. But first, it is worth asking:

  • What problem was this step introduced to solve?
  • Does that problem still exist?
  • Is the check necessary for every order, or only certain situations?
  • What would happen if it were removed?

Some checks remain essential for quality, safety or contractual requirements. Others continue simply because nobody has revisited the reason behind them.

Keep the purpose, reconsider the routine

If a check is still needed, it may be possible to apply it only when specific conditions are met. If it compensates for unreliable information earlier in the process, improving that information may be more useful than adding another automated control.

The aim is to preserve necessary safeguards while reducing work that no longer serves a clear purpose.

The takeaway

Digital transformation is an opportunity to reconsider existing routines before building them into a new system.

Before asking “How can we automate this step?”, ask “Why is it still part of the process?”

Case 1

Before automating a quotation, find where it waits

Why a faster document does not always mean a faster quotation process.

When a quotation takes too long, automating the document is often the first idea. It is a visible, repetitive task—and a natural place to look for improvement.

But is that really where most of the time goes?

Imagine a fictional equipment supplier whose quotation takes five working days to reach the customer. Preparing the document takes two hours. Between the initial request and the final release, the quotation waits for technical clarification, updated supplier prices and commercial approval.

A faster document generator would save some time. The waiting would remain.

Where I would start

Before choosing a tool, I would follow a quotation from the customer’s request to its release and ask:

  • What information is missing when the work begins?
  • Where does the quotation wait for a decision?
  • Which information is entered more than once?
  • Why does work return to an earlier step?

The aim is to distinguish time spent working from time spent waiting. Both matter, but they require different solutions.

A repetitive calculation might benefit from automation. An unclear approval responsibility needs a clearer decision process. Missing technical inputs may require better questions at the start.

Then choose what to automate

Once those dependencies are understood, tools such as CPQ can support structured inputs, consistent calculations and document generation.

Sometimes, however, the most useful first improvement is smaller: an agreed checklist, a clearly assigned responsibility or a visible status showing what is missing and who needs to act.

The takeaway

Quotation speed depends on more than how quickly a document is produced. It also depends on how smoothly information and decisions move through the process.

Before asking “What can we automate?”, ask “Where does the work wait—and why?”

The foundation is on the homepage.

Read the personal story, explore the CPQ expertise behind this platform, and see how I approach digital transformation.

Return to the homepage ↖