Herff Jones CPQ + M3 Strategy Recommendation

Herff Jones CPQ + M3 Strategy Recommendation
Future-proofing product configuration, selling, and execution — a strategic advisory perspective. 
Strategic Recommendation
Confidential — Leadership Review
-Audie Orme, Athenity LLC
Executive Summary
Five Decisions That Will Define This Program
This is not a status update. It is a strategic recommendation. The following positions represent the critical design choices that will determine whether this CPQ implementation becomes a lasting business capability — or a costly constraint.
01 — Adopt a Hybrid Product Model
Not every product should be treated the same. Standard, configurable, and make-to-order items require distinct handling strategies.
02 — Redefine What a "Product" Is
SKU is not the universal definition of product. For configurable items, the configuration, options, and rules are the product.
03 — Elevate CPQ as 100% Business Logic Owner
CPQ is a rules engine, product modeling platform, and orchestration layer. It must be implemented accordingly.
04 — Evolve Reporting Intelligence
Replace SKU-count reporting with configuration, attribute, family, and margin-based business insight.
05 — Validate Before You Build
Several program assumptions — MDM APIs, front-end strategy, business rules — remain unvalidated. Resolve them now, not in production.
Current State Assessment
What I Observed
A candid diagnostic of the current program. These are not indictments — they are design risks that I feel like need addressing deliberately and soon.
Shared Understanding Gap
Core SMEs and project team members may not yet hold a consistent, accurate view of CPQ's true capability. Design decisions made without that shared understanding will produce a constrained implementation.
Current-State Design Bias
There is a visible tendency to design toward today's process rather than toward a better future-state operating model. That is a path to automating inefficiency, not eliminating it.
Unvalidated Assumptions
Several parameters and business rules embedded in the current design are treated as validated truths. They are not. These assumptions need explicit confirmation before they drive architecture decisions.
Consultant Scope Constraints
Current scope boundaries may be leaving major design questions unresolved — particularly around product modeling strategy, MDM, API capability, and the front-end experience layer.
Front-End Uncertainty
The digital selling experience layer I have not sufficiently evaluated. The choice made here will determine whether this becomes a modern commerce platform or a constrained tool which SwiftSell is in my opinion. 
Foundational Understanding
What CPQ Really Is
CPQ is frequently mischaracterized as a quoting screen. That misunderstanding is dangerous when making implementation decisions. CPQ is a product modeling platform, a rules engine, a guided selling engine, and a downstream orchestration layer — all at once.
The Wrong Mental Model
CPQ = a screen where a rep fills in options and gets a price.
This model leads to: minimal configuration logic, heavy manual overrides, no BOM intelligence, and no downstream automation.
The Right Mental Model
CPQ = a product intelligence layer that encodes your business rules, validates configurations, generates accurate pricing, drives BOM and routing logic, and orchestrates execution into M3.
Rules and constraint engine
Guided selling and eligibility logic
Configuration validation and pricing
BOM generation and routing triggers
Integration orchestration to M3
Product Strategy
Herff Jones Product Reality: Three Distinct Models
The Herff Jones product portfolio is not homogeneous. Applying a single implementation pattern to every product category will produce a system that serves none of them well. The first and most important design decision is segmenting the portfolio correctly.
Design principle: The segmentation model above must become the governing framework for every product modeling decision in this program. Fighting it will produce a broken architecture.
Core Recommendation
The Hybrid Operating Model
The recommendation is clear: Herff Jones should not force everything into one pattern. The right model is a deliberate hybrid that matches implementation strategy to product reality. This is both commercially smart and operationally achievable.
Standard Products
CPQ selects and calls existing reusable M3 items. No BOM generation. Stable, fast, clean.
Configurable Products
CPQ applies rules, constraints, and guided selling. Outputs validated configurations. Triggers pricing and structured M3 payloads.
Make-to-Order / ETO
CPQ generates BOM and routing logic dynamically. Full orchestration into M3. Configuration is the product record.
Why This Matters
Forcing standard products through a generation model adds cost, complexity, and error risk. Forcing MTO products through a static SKU model makes the system invisible to the real business logic. The hybrid model respects both realities.
What This Requires
An explicit segmentation exercise for the product portfolio
Agreement on which items are static vs. configurable vs. generated
Governance to prevent pattern drift over time
Integration design that supports all three paths into M3
SKU Strategy
The SKU Question: Useful Tool, Dangerous Default
Part numbers and SKUs are valuable data constructs — in the right context. The risk here is SKU-first thinking being applied universally, even to products where the meaningful unit of value is the configuration, the option set, and the rules — not a static part number.
Where SKU Remains Valid
Stable, reusable physical items with fixed BOMs
Standard catalog products ordered repeatedly
Components sourced and stocked predictably
Items with fixed pricing and no meaningful variance
Where SKU Thinking Constrains Value
Highly configurable products with option-driven outcomes
Make-to-order items where each output is unique
Products where the "thing sold" is a configuration, not a catalog entry
Reporting models that reduce product intelligence to a count per item number
Old Mindset
"Every product must have a SKU. If we can't find the SKU, we can't process the order."
New Mindset
"SKU is one representation of a product. For configurable and MTO items, the configuration record is the product. The system must support both."
Reporting Strategy
From SKU Counts to Business Intelligence
The objection is real and legitimate: "We sold 10,000 of SKU 123-56754 — how do we see that if there's no SKU?" The answer is not to abandon intelligence. It is to replace it with something far more powerful.
Today's Reporting Model
SKU-centric. Tells you volume per item number. Answers: what did we sell?
Item Number
Unit count only
Revenue by SKU
No attribute context
Order volume
No configuration insight
The Evolved Reporting Model
Configuration and attribute-driven. Answers: what did we really sell, to whom, with which options, at what margin?
Product Family
Rings, Apparel, Awards
Material / Metal
Gold, Silver, Custom alloy
Options Selected
Stone, finish, engraving
School / Program
Customer segment context
Configuration Cluster
Common combinations
Margin Driver
Options contributing to GM
Leadership note: Reporting does not degrade when you move beyond SKU-only thinking. It improves — dramatically. Configuration-based reporting exposes what is actually driving revenue, margin, and demand. That intelligence is impossible to see in a SKU count.
Architecture
Target Architecture: CPQ + M3 Integrated Stack
The architecture below reflects the full capability stack required to deliver on the hybrid model. Each layer has a distinct role. Open questions are flagged explicitly — these must be resolved, not deferred.
Front-End Strategy
The Front End Is Not a Detail — It Is a Strategic Decision
The front-end experience layer will determine whether this program produces a modern digital selling platform or a constrained internal tool that replicates today's limitations in new software. This decision deserves explicit executive attention.
Guided Selling Experience
Can the front end deliver intelligent, context-aware guidance to reps and customers? Or does it require manual knowledge to navigate correctly?
Omnichannel Readiness
Can the platform serve rep-assisted, self-service, and partner channels from a single configuration model? This is the future of B2B commerce.
AI and Analytics Readiness
Can the front end ingest AI-driven recommendations, configuration intelligence, and next-best-action guidance? This is not optional for long-term competitiveness.
Long-Term Extensibility
Is the platform open enough to evolve as business needs change? Proprietary lock-in at the experience layer is a compounding liability.
On SwiftSell and similar tools: These should be evaluated critically against long-term strategic requirements — not accepted as inherited assumptions. The front-end choice should be driven by where Herff Jones needs to go, not where it is today.
Risk Assessment
The Cost of Staying Narrow
Every program carries execution risk. But in this program, the highest risks are not technical — they are strategic. The following risks are compounding: unaddressed today, they become expensive to unwind in Phase 2.
Next Steps
Our objective for the next steps is to stabilize the foundation, validate key assumptions, and enable controlled forward progress for the CPQ + M3 program. This agenda outlines critical areas of focus.
1
Core Data Readiness
Inventory, map out ownership, identify gaps, and define a single source of truth for product structures, item masters, attribute data, and pricing logic.
2
Product Model Segmentation
Classify products into standard, configurable, and true make-to-order models, defining rules and exceptions through SME workshops.
3
Data Cleansing & Rationalization
Address duplicate SKUs, inconsistent BOMs, obsolete items, and misaligned attributes to standardize naming and structure.
4
Environment Strategy
Establish DEV, TST, and PROD environments with clear promotion paths and governance to replace the current TST-only constraint.
5
Integration & Data Access
Define API and data flow strategies between CPQ, M3, MDM, and front-end systems, including payload structures and real-time vs. batch processing.
6
Front-End Strategy Alignment
Review current front-end capabilities and define the target user experience, ensuring alignment with CPQ for configurator-driven and guided selling.
7
Reporting Model Redesign
Transition from SKU-only reporting to attribute and configuration-level insights, defining new dimensions and ensuring compatibility with M3 and analytics.
8
Sprint-Based Execution Model
Adopt short development cycles (2–3 weeks) to validate assumptions and prove out core configurations and integrations with 1-2 product models.
9
Governance & Decision Framework
Establish clear ownership, decision authority, and a process to track and validate assumptions, preventing the accumulation of unresolved issues.
Implementation Roadmap
Phased Path to a Future-Proof Platform
This is not a big-bang transformation. It is a disciplined, phased progression — each phase building on a validated foundation. The goal is to modernize correctly, not just implement quickly.
Phase 1 — Discover and Align
Complete portfolio segmentation. Validate all assumptions. Assess MDM and front-end options. Align leadership on the hybrid model. Establish governing design principles.
Phase 2 — Model and Prove
Build product models for each segment type. Prove out CPQ rules engine, reusable item calls, and BOM generation logic. Validate integration handshake with M3. Run pilot on a representative product family.
Phase 3 — Integrate and Harden
Full integration build across CPQ, MDM, and M3. Front-end layer connected. Pricing logic validated. Reporting model implemented. End-to-end testing by product segment.
Phase 4 — Scale and Evolve
Expand across remaining product families. Activate analytics and configuration reporting. Introduce AI-readiness layer. Establish a continuous improvement cadence for rules and configuration governance.
Final Recommendation
The Opportunity: Modernize Correctly
Herff Jones has the opportunity to build a CPQ and M3 capability that is strategically sound, operationally durable, and commercially competitive for the next decade. That outcome requires making several deliberate choices now — before the architecture hardens around the wrong assumptions.
Adopt the Hybrid Model
Segment the portfolio. Apply the right implementation pattern to each product type. Do not force uniformity where diversity is the correct answer.
Expand the Definition of CPQ
Ensure the entire program team understands CPQ as a product modeling and orchestration capability — not a quoting screen. That shared understanding must precede every design decision.
Resolve Open Questions Now
APIs, front-end strategy, validated assumptions, and scope boundaries are not peripheral concerns. They are architectural decisions. Treat them as such.
Design for Where You Are Going
The front end, reporting model, and product architecture should reflect the business Herff Jones is building — not the process it has today. Future AI and digital commerce readiness must be designed in, not bolted on later.
The difference between a successful CPQ program and a costly constraint is not the software selected. It is the strategic clarity brought to product modeling, integration design, and future-state ambition. That clarity starts here.
Appendix
Open Questions and Critical Assumptions to Validate
The following items represent the highest-priority decision gates in the current program. Each should be assigned an owner, a validation method, and a resolution date before architecture design advances.