We’re a multi-division manufacturing company trying to establish enterprise-wide CAD data standards, but each division has evolved its own classification system over the years. Division A uses ISO-based part classes, Division B uses internal commodity codes, and Division C uses a hybrid approach.
The challenge is attribute mapping when CAD data moves between divisions or when we need enterprise-wide reporting. A ‘Material’ attribute in Division A maps to ‘Base_Material’ in Division B and ‘Primary_Substance’ in Division C. We’ve tried creating a master attribute mapping table, but maintaining it is a nightmare as divisions continue to add custom attributes.
Our classification admin tools in Windchill seem capable of handling this, but we haven’t found a scalable governance model. How have other enterprises tackled cross-division attribute standardization? Is it better to force convergence on a single schema, maintain mapping layers, or federate the schemas with integration adapters? What role do the classification admin tools play in your solution?
Carlos, the namespace approach is intriguing. How do you handle cross-division BOMs where parts from different divisions need to work together? Don’t the namespace prefixes break the attribute matching logic in assembly validation rules?
We faced exactly this problem three years ago across seven divisions. Forcing convergence failed spectacularly - too much organizational resistance and legacy system dependencies. We ended up implementing a canonical attribute model using Windchill’s classification hierarchy. Each division maps their local attributes to the canonical model through classification nodes. The classification admin tools let us define the mapping rules once, and they apply automatically during CAD checkin. It’s not perfect, but it eliminated the manual mapping table maintenance.
After working with multiple global manufacturers on this exact challenge, I can offer a comprehensive framework:
Attribute Mapping Standards - The Three-Layer Model:
The most successful approach I’ve seen uses three distinct layers:
-
Local Schema Layer: Each division maintains their native classification and attributes unchanged. This minimizes disruption and respects domain expertise. Division A keeps ISO classes, Division B keeps commodity codes, Division C keeps their hybrid.
-
Canonical Schema Layer: Define a minimal enterprise canonical model - aim for 40-60 core attributes that truly need to be standardized (Material, Finish, Compliance attributes, etc.). Resist the temptation to make this comprehensive. It should cover only what’s needed for enterprise-level operations: procurement, compliance reporting, cross-division sourcing.
-
Context-Specific Views: Create mapping views for specific business contexts (cross-division BOMs, enterprise reporting, procurement catalogs). These views pull from the canonical layer but format data according to the consuming system’s needs.
Classification Admin Tools - Implementation Pattern:
Windchill’s classification tools are your implementation engine:
- Use classification hierarchies to represent both local and canonical schemas
- Implement attribute mapping through classification node inheritance - local nodes inherit from canonical nodes
- Leverage attribute value mapping tables for enumerated attributes (e.g., Division A’s ‘Steel_304’ maps to canonical ‘Stainless_Steel_304’)
- Use classification attributes’ ‘External Mapping’ feature to maintain bidirectional sync between local and canonical values
The key technique: make the canonical mapping automatic and invisible to division users. When a Division A engineer classifies a part using their familiar ISO classification, the system automatically populates the canonical attributes in the background. They never see or interact with the canonical layer directly.
Cross-Division Governance - Practical Framework:
Governance is where most implementations fail. Here’s a workable model:
- Federated Authority: Divisions own their local schema completely. The enterprise governance board owns only the canonical schema.
- Quarterly Review Cycle: New canonical attributes can be proposed quarterly, not continuously. This batches requests and forces prioritization.
- Addition Criteria: New canonical attributes must demonstrate value across at least 3 divisions or be required for regulatory compliance. This prevents bloat.
- Deprecation Process: Canonical attributes unused for 12 months are automatically flagged for review and potential deprecation.
- Local Autonomy: Divisions can add local attributes freely without governance approval. Only canonical additions require board review.
This model works because it respects division autonomy while establishing enterprise standards where they truly matter. The classification admin tools provide the technical foundation, but the governance framework ensures sustainable operation.
Implementation Roadmap:
Start with a pilot involving 2-3 divisions and 20-30 canonical attributes. Prove the model works before scaling. Use the classification admin tools to implement the mapping infrastructure, but invest equal effort in establishing the governance board and processes. Technical perfection without governance buy-in leads to abandonment. Governance commitment with adequate technical tools leads to success.
The most critical success factor: executive sponsorship for the governance model. Divisions will resist standardization unless there’s clear business value and top-down support for the effort.
Great question. Cross-division BOMs do require special handling. We implemented a ‘cross-division view’ classification that maps the namespaced attributes to a common set for interoperability scenarios. It’s essentially a materialized view of the canonical model, but only activated when parts from multiple divisions are assembled together. The assembly validation rules operate against this cross-division view rather than the raw attributes. It adds a layer of complexity, but it’s localized to the integration points rather than forcing it everywhere.
I’ve implemented both canonical models and namespace approaches at different clients. Here’s what I’ve learned: the technical solution matters less than the governance model. You need a cross-division attribute governance board that meets regularly to review new attribute requests, approve additions to the canonical model, and deprecate obsolete attributes. Without governance, any technical approach will eventually collapse under the weight of uncontrolled growth. The classification admin tools are powerful, but they’re enablers, not solutions. They make it possible to implement whatever governance model you choose.