Herff Jones CPQ to M3 Manufacturing Roadmap

Herff Jones CPQ to M3 Manufacturing Roadmap
From sales configuration to manufacturing-ready product structures
SteerCo Discussion Draft | April 2026
These Questions Must Be Answered Early to Protect the Timeline
Critical Open Decisions
1. Integration Baseline
Is the current CPQ-to-M3 handoff nonexistent, order-only, or partially automated through ION / API? The answer changes the near-term architecture.
2. Recurring Variant Policy
For Bucket 2, should recurring combinations become unique M3 item numbers or variants? This drives template strategy and naming conventions.
3. Source of Truth for Item Masters
Is M3, MDM, or another system the source of truth for material and item masters? Unresolved, this blocks every data-definition activity.
4. BOM / Routing vs. Descriptive Impact
For Greek Pins* and Nursing Pins*, which configuration options actually change BOM or routing versus only affecting description or price?
5. Definition of Proof of Concept Success
Will success be measured by BOM accuracy, MO-release speed, reduced manual touches, or time to onboard new families? Agreement is needed before testing begins.
6. Bucketing Governance Level
Should bucket classification be governed at product family, style, SKU, or exception-based hybrid level? The answer determines scope of the classification work.
Unresolved answers here will push broader completion beyond August.
The Required Data.
Manufacturing-side completion requires five distinct data layers, all of which must be defined, owned, and governed before templates can be built and tested.
1
Customer-Facing Configuration Inputs
CPQ questions, values, options, defaults, exclusions, dependencies, pricing conditions
2
Derived Manufacturing Attributes
Plating path, stone / insert logic, backing / fastener logic, finish, route-selection flags, packaging flags, time-factor drivers, inspection flags
3
M3 Master Data
Parent / family items, component items, work centers, operation codes, UOM, facilities, costing inputs, order-type defaults, status / release settings
4
M3 Template Logic
Product structure headers, BOM skeletons, routing skeletons, formulas for quantities and operation times, selection matrices, alternate materials, alternate routings, effectivity and release criteria
5
Governance Data
Source-of-truth by field, owner by field, versioning rules, change approval, effectivity dates, test ownership, release approval criteria
Do not ask manufacturing to enumerate every theoretical combination. Define the controlled data needed to build what is actually sold.

KPI Dashboard and Gate Criteria
Program KPIs — Ongoing Tracking
Gate Criteria Summary
Gate 1 — Mid-April
Bucket operating model approved. Proof of Concept scope locked. Classification level confirmed. Owners and cadence established.
Gate 2 — End of May
Common manufacturing attribute model approved. Source-of-truth matrix approved. Template strategy confirmed. Master data gaps documented.
Gate 3 — End-June
Proof of Concept build complete . Regression pack executed. Rule parity matrix validated. Handoff mechanism confirmed.
Gate 4 — TBD
Proof of Concept validated end-to-end. KPI targets met. Governance and release controls ratified. Scale plan approved.
The Path Is Aggressive but Manageable for a Proof of Concept. It Is Not Trivial for Full Completion.
April — August 2026 Roadmap
Gate 1 — End of April
Scope, Proof of Concept families, and bucketing level locked
Gate 2 — End of May
Common attribute model and source-of-truth matrix approved
Gate 3 — End of June
Proof of Concept built/validated and regression pack ready.
Gate 4 — August
Scale plan approved

Detailed Implementation Plan by Week — April Through August 2026
This view reinforces that the compressed timeline is aggressive. Tightened phases do not mean reduced work — all critical actions remain in scope.
April and May Are About Scoping, Simplification, Mapping, and Data Truth
Scope and Rationalize (April)
Confirm the operating model by bucket across the organization
Decide classification level: family, style, SKU, or exception-based hybrid
Map priority product groups, styles, and SKUs into Bucket 1, 2, or 3
Identify low-volume combinations to collapse into Bucket 1 Standard
Prioritize product families by business value and configuration complexity
Lock Greek* and Nursing* as confirmed Proof of Concept scope
Establish owners, meeting cadence, and governance decision rights
Define the Manufacturing Model (Late April – May)
Reuse existing CPQ questions and outputs already built — do not rebuild
Define derived manufacturing attributes by family: what is commercial-only vs. manufacturing-relevant
Create source-of-truth matrix by field across CPQ, M3, MDM, and Operations
Identify material, item, routing, and work-center master data gaps
Define family item / template strategy for Bucket 2 Proof of Concept families
Define recurring variant policy: when to promote combinations into reusable variants
Define naming conventions, effectivity rules, and change-control process
June and July Is Where the Manufacturing Model Gets Built and Tested
Phase 3 — Build and Prove
M3 Template and Product Structure Build
Define M3 product structure headers for Greek Pins* and Nursing Pins*
Define BOM skeletons and routing skeletons for Proof of Concept families
Define formulas for component quantities and operation times
Define selection behavior, feature / option logic, and drawing measurements where relevant
Define alternate materials and alternate routings where appropriate
Confirm interim handoff mechanism while integration remains limited
Rule Parity and Test Execution
Create CPQ-to-M3 rule parity matrix covering all Proof of Concept configuration options
Build representative test scenarios covering BOM, routing, costing, and MO readiness
Validate BOM accuracy across configuration combinations
Validate routing accuracy and operation time formulas
Validate costing impact and manufacturing order readiness
Execute regression pack before any Proof of Concept sign-off
No duplicate rule logic without explicit ownership, traceability, and a corresponding test case. Every rule that lives in both CPQ and M3 is a governance liability until it has a clear owner and a test.
⚠️ Placeholder Names — Subject to Change: Terms marked with * (e.g., Greek Pins*, Nursing Pins*) are placeholder product family names used for scoping purposes only. The exact product and family names are not yet locked and will be updated before final presentation. Search for * to locate all instances.
The Proof of Concept Should Prove the Pattern, Not Boil the Ocean
Greek/Nursing* Pins — Why These Families
Representative configuration complexity for Bucket 2
Known customer-facing options: organization / school, metal / plating, stone or no stone, finish, backing / guard, engraving, size / dimensional factor, packaging
Options with proven BOM and routing impact — not purely descriptive
Manageable scope that can be completed within the Proof of Concept window
Configuration Impact on Manufacturing
Success Metrics
95%
BOM First-Pass Accuracy
95%
Routing First-Pass Accuracy
0/1
Human Touches per MTO-free Order
Additional metrics: manual touches per order, time to create manufacturing-ready structure, MO release without manual intervention, rule defect rate.
August Exit Criteria
Proof of Concept rules validated end-to-end for both families
Representative scenarios tested with documented results
Governance and release controls approved by SteerCo
User training completed, defect log closed
Next-wave family list prioritized and resourced
The Program Fails Without Explicit Ownership
Governance and Decision Rights
R = Responsible | A = Accountable | C = Consulted | I = Informed
A Validated Proof of Concept by August Is Credible. A Broad Full Completion Is High Risk.
Realistic by End of August 2026
Bucket model operational for priority families
Priority products classified into Bucket 1, 2, or 3
Common manufacturing attribute model defined and approved
M3 template pattern built and validated for Proof of Concept families
CPQ-to-M3 rule parity proven for Greek Pins* and Nursing Pins*
Proof of Concept validated end-to-end with documented test results
Governance, regression controls, and scale-wave plan in place
Likely Unrealistic by "Completion" Without Scope Reduction or Resource Increase
All configurable families fully industrialized across the landscape
All master-data issues fully remediated
All Bucket 2 logic automated end-to-end
All manual or manufacturing intervention removed from Bucket 2 orders
Enterprise-wide regression completed across all configurable families
Full manufacturing-side completion for the full product portfolio
Critical Dependencies That Can Slip the Target
Unresolved source-of-truth decisions · Family-to-bucket mapping delays · Material and item master cleanup backlogs · Delayed M3 template decisions · Limited testing capacity · Unresolved integration baseline · Hidden Bucket 3 work misclassified inside Bucket 2 scope
Define August as "Proof of Concept proven and scale-ready," not "everything complete." Setting an unrealistic September target risks delivering nothing of lasting value. A governed Proof of Concept with a clear scale path is the right first outcome.
What SteerCo Needs to Approve Now
SteerCo Decisions
1
Approve the Operating Model by Bucket
Confirm Bucket 1 Standard, Bucket 2 Configurable, and Bucket 3 MTO as the governing framework.
2
Approve the Simplification Rule
Build what is sold. Do not over-engineer theoretical combinations. Promote repeating combinations to reusable variants.
3
Approve Proof of Concept Scope
Confirm Greek Pins* and Nursing Pins* as the first proof of concept families for Phase 3 and Phase 4.
4
Approve Source-of-Truth and Ownership Model
Confirm system-of-record assignments across CPQ, M3, MDM, and Operations for all critical data fields.
5
Approve the April-to-August Roadmap and Stage Gates
Ratify the four phases, four stage gates, and workstream ownership as presented.
6
Approve the Definition of August Success
Validated Proof of Concept plus scale-ready framework — not all families complete by September.
Define. Map. Prove. Scale.
Appendix A
Sample CPQ-to-M3 Mapping Table — Configurable Pin Products
Appendix B
Data Object Inventory by System
This table defines where each data object lives, who owns it, and whether a manual exception process currently fills gaps that should be systematized.
Observation: Manual exception processes currently fill the gaps where CPQ and M3 are not connected. Each ⚠️ row represents a governance and quality risk that the canonical model and template architecture directly address.
Appendix C
Each Bucket Needs a Different Execution Pattern
Decision rule: If only a limited number of predefined combinations are sold repeatedly → Bucket 1. If customer choices change materials or routing within known rules → Bucket 2. If manual intervention or new design is required → Bucket 3. Do not force Bucket 3 work into Bucket 2 automation.
Appendix D
Reuse CPQ Questions. Derive Manufacturing Values. Translate Only What M3 Needs.
Core Design Principle
1
Layer 1 — CPQ
Customer questions, commercial rules, guided selling, pricing, sellability checks, output values
2
Layer 2 — Common Attribute Model
Derivation logic, normalization, rule parity mapping, reduction of duplicate logic, source-of-truth by field
3
Layer 3 — M3 Execution Objects
Family item / template, product structure header, BOM lines, routing operations, formulas, alternate materials, alternate routings, recurring variants
Sample mapping — configurable pin product: