Manufacturing CPQ Implementation: An RFP from Quote to Production

The real objective of a manufacturing CPQ implementation is not merely to produce quotations faster. In make-to-order and high-mix manufacturing, success depends on whether the specification selected by sales, the combination approved by engineering, the assumptions behind cost and price, and the delivery conditions promised to the customer can move into the order, bill of materials (BOM), routing and production instructions without changing meaning. If a quote is correct on screen but manufacturing must interpret it again, digitalisation has only moved the entrance to the same errors and rework.

This guide is for managers at machinery, equipment, electrical, component and industrial-material manufacturers operating in Thailand and ASEAN. It explains the practical sequence for defining CPQ scope, configuration rules, variant BOM and routing handoff, approvals and audit, an RFP, a bounded 90-day proof of concept, and acceptance gates. It is not a product ranking. It is a procurement framework for asking every candidate the same questions and judging them with the same evidence.

The conclusion: manufacturing CPQ must create an executable configuration contract

A useful definition of the CPQ outcome is:

A controlled configuration contract that freezes the selected product configuration, applied rules, price, cost and lead-time assumptions, approvals and revision, so ERP, PLM and MES can consume the accepted quote without manual reinterpretation.

“Contract” here is not limited to a legal document. It is the data agreement through which sales, engineering, production engineering, purchasing and the plant refer to the same configuration ID and revision and can trace what will be built, under which conditions and by which process. The customer-facing PDF is only one rendering of that agreement.

Before implementation, fix at least five decisions:

1. Which system—CPQ, PLM or ERP—is the system of record for configuration rules?
2. How will a configuration ID, revision and effective date identify the exact quoted configuration?
3. How will selected features become a variant BOM, routing, purchased items and inspection requirements?
4. Which service calculates price, cost and promise date, and who approves each exception?
5. How will post-order changes, lost quotes, requotes and engineering changes remain traceable?

If these decisions remain open while the project begins with “make quotes faster,” the sales interface may improve while engineering emails, spreadsheet specifications and ERP re-entry survive. CPQ is not a quotation-screen refresh. It is the design of quote-to-order decisions as governed data.

What a CPQ system means in manufacturing

CPQ stands for Configure, Price and Quote. In manufacturing, these three words must work as one chain.

• Configure: use attributes, options, constraints, calculations and dependencies to determine a sellable and buildable configuration.
• Price: apply option, quantity, customer, region, currency, service and discount conditions, and where needed the assumptions for cost and margin.
• Quote: present the configuration and price with a revision, approval state, commercial conditions, expiry date and attached specifications.

Microsoft’s official product-configuration documentation describes model elements including attributes, constraints, calculations, BOM lines and route operations, and explains that a configured product variant can have its own BOM and route. Oracle’s configure-to-order documentation similarly describes models, option classes, runtime choices and a manufacturing work definition derived from selected options. The lesson is not that every company must buy one of these products. It is that a sales choice cannot be governed separately from manufacturing feasibility.

Not every CPQ generates a production-ready BOM or routing. In one architecture, CPQ owns a sales configuration, PLM owns the engineering BOM, and ERP owns the manufacturing BOM and route. In another, CPQ calls the ERP variant-configuration engine. An RFP should therefore ask which system owns each rule and deliverable, not which product name appears in a diagram.

Draw the boundary before selecting functions

This boundary prevents responsibility from falling between suppliers. Replace “ERP integration included” with explicit create, change, approve, invalidate, retry and reconcile behavior for each object. For generic interface design, see our manufacturing API integration procurement guide. This article focuses on CPQ-specific configuration meaning and version control.

What to model first for make-to-order quotation automation

The first implementation task is not to reproduce the current quote template as screens. Break the process into the questions sales asks, the decisions engineering makes, and the deliverables manufacturing needs.

Translate the customer’s language into product attributes

Customers say that a machine must operate at high temperature, be easy to wash, fit an existing line or meet a certain throughput. Product logic needs material, power supply, capacity, dimensions, protection class, connection standard, control method, inspection and document-language attributes. Organise questions into three layers:

1. Use and environment: material handled, temperature, humidity, dust, washdown, hazardous area and installation country.
2. Required capability: throughput, accuracy, speed, load, range of movement and operating hours.
3. Implementation conditions: power, air, communication, installation envelope, delivery access, upstream integration and language.

Values must include units. “100” is not a valid engineering input unless the model says whether it means kg/h, pieces/min or something else. Japanese, English, Thai and Vietnamese interfaces may show different labels, but the attribute ID, unit and enumeration IDs must remain common. Never use translated display text as an integration key.

Separate hard constraints, soft constraints and calculations

• Hard constraint: a physical, safety, regulatory or required-interface condition that prevents an invalid configuration from being completed.
• Soft constraint: a recommendation involving standardisation, margin, stock or lead time that can proceed through controlled exception approval.
• Derived calculation: an equation that obtains capacity, quantity, dimension, labour or price elements from inputs.
• Completeness rule: a control that prevents submission until mandatory questions, drawings or confirmations are present.

If everything becomes a prohibition, exceptional orders escape to email and spreadsheets. If everything becomes a warning, CPQ becomes a checklist. Every overrideable rule needs a reason, approver, expiry, affected BOM/routing elements and a decision on whether the exception may be reused.

Give every rule evidence and an owner

“This motor requires that inverter” is not enough for maintainability. Keep a rule ID, description, expression, result, source document, product family, region, effective start and end, author, technical approver and test cases together.

When expert experience is captured, do not publish oral convention unchanged. Check it against design standards, historical defects, cost conditions and supply constraints. CPQ can expose tacit knowledge; it cannot prove that the tacit rule is correct. Governance must state who will approve its future changes.

Connecting the configurator to variant BOMs and routings

The most important manufacturing CPQ acceptance scenario is not “the PDF was produced.” It is “manufacturing deliverables were reproduced from the exact accepted configuration.”

Make the configuration snapshot the order baseline

Freeze the following as one snapshot when a quote is issued:

• Opportunity ID, quote ID and quote revision.
• Configuration ID, model revision and rule revision.
• All inputs, selections, derived values, exclusions and overrides.
• Price-list revision, currency, exchange-rate treatment, discounts and cost reference date.
• Promised specifications, quantity, delivery assumptions, warranty and service.
• Technical, sales, finance and other approval states with timestamps.
• Generated quotation, specification and attached drawing revisions.

Microsoft’s sales-transaction documentation illustrates quote states such as Draft, Active and Revised and the use of revision IDs. An RFP should express the required behaviour independently of a vendor’s terminology: a quote sent to the customer must not mutate when rules or price lists later change, and a revision must show what changed.

Build a mapping from sales configuration to manufacturing configuration

A sales option does not always equal one part. One selection may add several components, a machining operation, an inspection and a document. Multiple customer choices may determine one subassembly.

Test routing, resources and inspection as well as BOM lines. Oracle’s documentation gives an example of creating a configured-item work definition from a model, selected options and transactional attributes. That does not prescribe one architecture, but it demonstrates why acceptance cannot stop at a parts list.

Five checks that prevent a valid quote from becoming an unbuildable order

1. Completeness: required attributes, documents and customer responses are present.
2. Consistency: there are no exclusive selections, insufficient capacity or incompatible standards.
3. Master-data existence: required items, operations, resources, suppliers and documents exist for the target plant.
4. Revision validity: the selected revision is effective on the expected order and production dates.
5. Executability: long-lead items, capacity, special engineering and test-facility assumptions are exposed.

If CPQ does not calculate feasibility alone, it must receive checks from ERP, PLM, planning or MES. Specify whether an unavailable service allows save-only, permits a controlled warning, or blocks customer submission. The most dangerous behaviour is silently promising against stale values.

Defining data responsibility across ERP, MES, CRM and PLM

CPQ often sits among several systems, so ownership matters more than connector count.

CRM inputs and outputs

CRM is commonly the record for customers, opportunities, activities and probability, but not necessarily for configuration rules. CPQ receives the opportunity ID and returns the quote number, configuration status, amount, margin band, approval state, expiry and document links. Define the idempotency key and the treatment of opportunity merges, copies and account changes.

PLM boundary

When PLM governs product structure and engineering change, CPQ should use an approved sellable view. Development parts and unapproved rules must not become sales options. A special order can create an engineering task; PLM returns the approved result to a configuration revision. Converting one special solution into a standard option remains a separate change process.

Siemens describes a common variant-management backbone across disciplines. Regardless of platform, the principle is that sales and engineering should not maintain separate names, rules and revisions for the same decision.

ERP boundary

ERP may own items, customer conditions, price, inventory, procurement, cost, order and production. SAP’s CPQ integration documentation describes synchronising product data from the back office, using configuration and pricing services, and combining quote and configuration data when a configurable quote is transferred to S/4HANA. The general lesson is not to rebuild existing knowledge casually inside CPQ, but to identify where the knowledge is maintained and record which version was invoked.

Interfaces must include more than the happy path:

• Create, revise, cancel, reopen, lose and convert-to-order.
• Idempotent handling of the same request.
• Conflict detection for stale configuration and price revisions.
• Retry and reconciliation after partial failure.
• Units, currency, tax, rounding and time zone.
• Reason, authority and audit evidence for manual correction.

MES handoff

CPQ should normally not instruct machines directly. ERP and PLM establish the order and manufacturing definition, while MES unfolds that definition for execution. If customer specifications originating in CPQ affect work instructions, inspections or traceability, carry the configuration ID and requirement ID into the production order. Acceptance should show the required values and documents at the correct operation, instead of expecting an operator to interpret a free-text specification PDF.

Our make-to-order production management guide covers planning, progress and change control after order acceptance. Use both guides to draw a clear end point for CPQ and starting point for production management.

Approval and audit are broader than discount approval

Manufacturing CPQ approvals control technical and delivery risk as well as price.

Divide the approval matrix into four dimensions

Triggers may combine amount, rule override, margin band, promise date, region, family and contract condition. Decide whether an originator may self-approve, how delegation and overdue items work, what a request for change does, and what happens when an approved quote is edited. Microsoft’s workflow documentation provides examples of approve, reject, request-change, delegate, final-approver and disallow-self-approval behaviour. Write required controls in the RFP rather than naming a feature.

Audit data to retain

• Who changed which value, when, and the before/after values.
• Rule revision, price revision and cost reference used.
• Difference between calculated and manually overridden values, with reason.
• Approval condition that fired and the decision evidence.
• Customer document linked to its configuration snapshot.
• Quote revision converted to an order and every subsequent request for change.

A screen that shows only the latest value is not an audit trail. Business users need searchable, exportable evidence with defined retention, privacy, access and deletion controls.

Fifteen requirements for a manufacturing CPQ RFP

1. Product-family scope and exclusions

Describe scope through option count, rule complexity, special-order rate, impact on BOM/routing and sales regions—not revenue alone. State what the PoC excludes.

2. As-is and to-be scenarios

Include copy, revise, customer change, reopened loss, post-order change and promotion of a special solution into a standard option.

3. Attribute, term and unit dictionary

Require attribute ID, display label, type, unit, enumeration, translation, owner and source. Display languages may change; identifiers must not.

4. Rule lifecycle

Require rule type, revision, effective date, source, authoring, review, approval, release, retirement, test and impact analysis.

5. Configuration session

Define save-and-resume, collaborative editing, locking, copy, comparison, difference, expiry and re-evaluation after model revision.

6. Price, cost and margin

Identify the record, refresh, currency, tax, rounding, plant, quantity, service, discount, override and failure-stop behaviour.

7. Promise date

Separate fixed lead time, item lead time, stock, capacity, outsourcing and engineering effort. “Lead-time calculation supported” is not comparable.

8. Document generation

Cover quote, specification, conditions, drawing, approval information, language, template revision, regeneration and e-signature handoff.

9. Variant BOM and routing

Require mapping from sales selections to parts, quantities, operations, inspections, documents and special engineering tasks, with a stop for missing mappings.

10. ERP, PLM, CRM and MES integration

For every message, state direction, timing, key, revision, retry, conflict, reconciliation, monitoring, manual recovery and owner.

11. Approval and segregation of duties

Test commercial, technical, supply and risk conditions, delegation, timeout, escalation, self-approval and post-approval edits.

12. Authorisation and security

Include role, site, product and account restrictions, SSO, administrator operations, API credentials, backup, logs and leaver procedures.

13. Performance and availability

Define measured conditions for representative rule evaluation, document creation, concurrency, external waits, timeout and degraded operation.

14. Migration and quality assurance

State what moves from spreadsheets and legacy systems, how rule equivalence is proven, and how Golden Configurations and regression tests are maintained.

15. Operational handover and exit

Contract for editable models, settings, code, API specifications, tests, learning material, licences, data export, successor migration and end-of-support conditions.

A response matrix that makes CPQ RFP answers comparable

“Standard,” “customised” and “integrated” can mean different things to each supplier. Require these columns for every requirement:

Use buyer-provided representative configurations instead of the supplier’s polished sales demo. Demonstrate missing mandatory options, prohibited combinations, old revisions, unavailable pricing service, rejected approval, missing BOM mapping and duplicate transmission.

A bounded 90-day PoC: prove one family end to end

This is a TOMAS TECH planning example, not a promise that every enterprise deployment finishes in 90 days. Limit the exercise to one product family, representative configurations and selected interfaces, with evidence for a Go/No-Go decision.

Select the right product family

A very simple product hides production risk; the most difficult product buries platform evaluation in unique engineering. Choose a medium-complexity family with standard options, dependent rules, price variation, approvals, BOM/routing differences and a small number of exceptions. A frequently quoted product with visible engineering rework is often suitable.

If production data cannot enter the PoC, anonymise it while preserving hierarchy, units, missing-data patterns and revision behaviour. Do not certify the solution with perfect sample data.

Acceptance gates: judge business evidence, not a function list

Gate 1: configuration quality

• A configuration with missing mandatory conditions cannot be submitted.
• A prohibited combination is blocked with an understandable reason.
• A non-standard exception requires reason and approval.
• The same inputs and model revision reproduce the same result.
• Opening an old quote does not silently replace its model revision.

Gate 2: price and promise control

• Price, cost, currency, quantity, tax and rounding assumptions are traceable.
• A manual override retains authority, reason, difference and approval.
• A failed price or date service is not treated as a successful stale answer.
• The customer-issued revision remains unchanged after master-data updates.

Gate 3: manufacturing handoff

• An ordered configuration ID and revision are registered exactly once downstream.
• BOM lines, quantities, operations, inspections and documents match expected results.
• Missing items, routes or mappings are detected and returned to an accountable owner.
• A revised quote conflicting with an old production instruction is detected.

Gate 4: approval and audit

• Correct paths execute for technical, commercial and supply triggers.
• Originator, delegate, overdue, return and resubmission scenarios are reproducible.
• Post-approval changes invoke reapproval or the explicitly defined rule.
• User, rule, price, document and integration history can be traced from one opportunity.

Gate 5: operability

• Customer administrators can govern attributes, translations, rules and effective dates.
• Regression tests run automatically or through a reproducible procedure.
• Monitoring, retry, reconciliation, backup and restore are demonstrated.
• Owners exist for training, access requests, incidents and change requests.

The acceptance record needs requirement ID, precondition, action, expected result, actual result, evidence link, defect ID, retest and approver. “It worked in the demo” is not evidence.

Local requirements for a Thai operation

Multilingual means master-data governance, not screen translation

Sales may work in English, headquarters in Japanese and the plant in Thai. Product names, attributes, options, warnings, quote terms and work instructions cross languages. Keep a common technical ID, define translation ownership, review, effective date and fallback behaviour, and maintain an approved glossary so free translation cannot alter the specification.

Clarify currency, tax and rounding responsibility

For THB, JPY and USD quotations, distinguish exchange-rate source and date, price-list currency, display currency, cost currency and rounding. Local specialists and finance should make tax decisions. CPQ should reproduce approved rules and retain which rule was applied.

Reconcile headquarters rules with local supply

A globally standard configuration may face different available parts, certifications, lead times and service capability in Thailand. Separate global rules from plant or market overlays. Avoid copying the complete rule set into every location for independent modification.

Verify BOI eligibility rather than infer it

Thailand’s BOI publishes official Smart and Sustainable Industry information. A CPQ project is not automatically eligible for an incentive. If it is included in an investment plan, confirm the current announcement, activity, deadline and eligible investment with BOI or qualified advisers.

Eight common manufacturing CPQ failures

1. Finishing with automated quote PDFs

If BOM, routing and order entry remain manual, the main bottleneck remains. Run the PoC through manufacturing handoff.

2. Maintaining separate sales and engineering rules

Implementing the same prohibition independently in CPQ and PLM creates revision drift. Define one record and one distribution mechanism.

3. Prohibiting too many exceptions

Special orders move back to email. Structure exceptions and retain approval, impact and reuse decisions.

4. Using current prices with stale costs

When price, cost and margin refer to different dates, approval loses meaning. Show timestamps and define recalculation conditions.

5. Producing a BOM but not a route or inspection plan

An option may add assembly, testing or software configuration. Accept parts, operations, inspection, documents and engineering tasks together.

6. Omitting regression tests for rule changes

One condition can break a distant configuration. Maintain Golden Configurations covering valid, prohibited, boundary and override cases.

7. Treating “API available” as integration complete

An endpoint is not safe business processing. Test configuration ID, revision, idempotency, conflict and error ownership.

8. Defining PoC success after the demo

A polished demonstration becomes subjective. Agree gates, allowed defects, open conditions and Go/No-Go authority before work begins.

FAQ: CPQ systems, cost, ERP integration and PoC

What is CPQ for manufacturing?

It converts customer requirements into a buildable configuration, calculates price and conditions, and creates an approved quote. Its manufacturing value comes from reusing the configuration in BOM, routing, inspection and order processes.

How is CPQ different from a quotation system?

A general quotation system usually centres on items, quantities, unit prices and documents. CPQ governs option dependencies, prohibited combinations, derived values and conditional pricing. Compare acceptance scenarios rather than labels, because product scope varies.

Should product rules live in CPQ or ERP?

There is no universal answer. Decide from the existing variant configurator, PLM, pricing architecture and organisational capability. Avoid duplicate ownership and retain the rule revision used by each quote.

Can CPQ automatically generate a variant BOM?

It depends on the product and architecture. CPQ may hold a conditional BOM, call an ERP/PLM configurator, or pass the sales configuration downstream for BOM creation. Test quantities, operations, inspections and documents as well as parts.

How should we compare CPQ implementation cost?

Compare licences, modelling, rule preparation, migration, ERP/PLM/CRM integration, documents, languages, testing, training, operations, changes, upgrades and exit data over the same period and scope. Fix product families and interface count before requesting quotes.

What should a 90-day CPQ PoC prove?

For one representative family, prove requirement input, rule evaluation, price, approval, documents, configuration revision, order, BOM/routing handoff, negative behaviour and audit end to end. The objective is a method and data-quality Go/No-Go decision, not full enterprise deployment.

What should appear first in a CPQ RFP?

Target families, rule ownership, configuration identity and revision, downstream deliverables, approval responsibility and acceptance scenarios. Starting with screen lists postpones the hardest ownership decisions.

Can CPQ work when we have many specials?

Yes, if you separate standard selection, parametrically calculable variation, engineering-approved exceptions and true custom engineering. Manage custom work as tasks and deliverables instead of pretending every request is already a standard option.

Should generative AI create product rules automatically?

AI can help extract candidate rules and tests from documents, but people remain accountable for rules involving physics, safety, cost and supply. Do not publish generated rules without evidence, ownership, revision control and regression tests.

Summary: contract for no reinterpretation after order, not only faster quotes

Manufacturing CPQ implementation is not simply a faster sales-entry project. It creates a traceable flow from customer requirements through product rules, pricing, approval and configuration revision into variant BOM, routing, inspection and production instructions, so the plant executes the same promise the customer accepted.

An RFP should ask for scenarios and evidence covering representative configurations, exceptions, revision, service failure, rejected approval and missing manufacturing mapping—not a list of feature names. A bounded 90-day PoC should take one family end to end and apply five gates: configuration quality, price and promise control, manufacturing handoff, audit, and operability.

TOMAS TECH can help define a CPQ concept for Thai plants and sales operations, shortlist a representative product family, inventory rules, prepare the RFP response matrix, draw ERP/PLM/MES boundaries, structure the 90-day PoC and build acceptance cases. You can start the discussion before selecting a product through our contact page.

References

• Microsoft Learn: Product configuration models overview
• SAP Help Portal: SAP CPQ Integration Guide — Technical Overview
• SAP: S/4HANA Sales Order Integration for Quote 2.0
• Oracle: Overview of Configure-to-Order
• Oracle: How You Create a Configured Item Work Definition
• Microsoft Learn: Manage quote, order, and invoice
• Microsoft Learn: Configure approval processes in a workflow
• Siemens: Teamcenter Product Configurator
• Thailand BOI: Smart and Sustainable Industry guide

Note: the 90-day PoC, RFP items and acceptance gates are TOMAS TECH planning examples, not a guarantee of the same duration or result for every company. Confirm legal, tax, BOI eligibility and contractual matters for the applicable product, country and customer with qualified specialists.