Automated CAD change order processing reduced engineering cycle time by 35% through Windchill MCO integration

PLM Windchill
, , , , , , , ,
1

I want to share our successful implementation of automated MCO (Manufacturing Change Order) processing that significantly reduced our engineering change cycle time.

The Problem: Our manual MCO process was creating bottlenecks. Engineers would check in revised CAD files, then manually create change orders, identify impacted assemblies, attach documentation, and route for approval. This took 2-3 days per change on average, and errors were common - missing impacted parts, incorrect routing, incomplete documentation.

The Solution: We implemented automated MCO processing that triggers on CAD check-in:

// Trigger on CAD check-in event
public void afterCheckIn(WTPart part) {
    MCOAutoProcessor.detectChanges(part);
    MCOAutoProcessor.analyzeImpact(part);
    MCOAutoProcessor.createWorkflow(part);
}

The automation handles CAD change detection by comparing new and previous versions, performs impact analysis across the BOM structure, generates documentation automatically, and routes the workflow to appropriate reviewers.

Results: We achieved 35% reduction in average change cycle time (from 2.8 days to 1.8 days), 90% reduction in routing errors, 100% consistency in impact analysis coverage, and significantly improved documentation quality.

The system now processes 40-50 changes per week with minimal manual intervention.

2

The workflow routing automation is what interests me most. How do you determine the right approvers? Our routing rules are complex - different approval chains for different part classes, dollar thresholds, customer-specific parts, etc. Does your system handle that level of routing complexity?

3

How did you approach the impact analysis automation? That’s the part we struggle with most. Our BOM structures are complex with multiple levels, and determining which downstream assemblies are truly impacted by a component change requires significant engineering judgment. Can automation really handle that effectively?

4

Good question. We implemented filtering rules in the change detection logic. The system checks for geometric changes above a threshold (0.1mm for dimensions, 1% for mass properties), material or specification changes, and BOM structure modifications. Pure metadata changes or minor cosmetic updates don’t trigger MCO creation. We also have a whitelist of change types that always require MCOs regardless of magnitude, like material changes for safety-critical parts.

5

Impact analysis was definitely the most challenging piece. We use a multi-layer approach. First, structural impact identifies all assemblies that directly use the changed part. Then functional impact checks if the change affects interfaces, mounting points, or critical dimensions that downstream assemblies depend on. Finally, we have configurable rules for different part types - for example, fastener changes have different impact scope than housing changes. The system flags high-confidence impacts automatically and escalates uncertain cases for engineering review. About 75% of changes can be fully automated, while 25% need human judgment.

6

This is impressive! How do you handle false positives in change detection? We tried automated change detection but found it flagged too many insignificant changes like metadata updates or minor cosmetic edits that don’t warrant formal MCOs.

7

What kind of documentation does your automation generate? In our manual process, engineers create detailed change descriptions, engineering justifications, and sometimes test plans. That seems difficult to automate since it requires understanding the engineering intent behind the change.

8

Let me provide comprehensive details on our implementation that addresses all these questions:

MCO Automation Architecture: Our solution integrates with Windchill’s event management framework to trigger on CAD check-in events. The automation workflow consists of five main stages that execute sequentially:

1. CAD Change Detection: The system performs geometric comparison between new and previous CAD versions. We extract key properties including:

  • Dimensional changes (length, width, height, diameter)
  • Mass properties (mass, volume, center of gravity)
  • Material specifications
  • Surface finish requirements
  • Interface geometry (mounting holes, connectors)

Change detection uses configurable thresholds to filter insignificant variations. Our threshold configuration:

// Threshold settings
geometricTolerance = 0.1mm
massPropertyTolerance = 1.0%
surfaceFinishChanges = always_trigger
materialChanges = always_trigger

We categorize changes as critical (always require MCO), significant (require MCO if impact exists), or minor (documentation only, no formal MCO). This filtering reduced false positives by 85% compared to our initial implementation.

2. Impact Analysis Automation: Impact analysis operates in three phases:

Phase 1 - Structural Impact:

Query all assemblies that reference the changed part using Windchill’s structure management API. This identifies direct usage relationships. For parts with multiple occurrences, the system tracks each usage context separately.

Phase 2 - Functional Impact:

Analyze whether changes affect part interfaces that downstream assemblies depend on. We maintain interface definition data in custom attributes:

  • Mounting interface geometry and locations
  • Electrical connector specifications
  • Fluid/pneumatic port configurations
  • Critical dimension chains that affect assembly fit

The system compares interface specifications between versions. If interfaces change, all assemblies using those interfaces are flagged as impacted. This catches non-obvious impacts that structural analysis alone would miss.

Phase 3 - Classification-Based Rules:

Apply part-class-specific impact rules. Examples:

  • Fastener changes: Impact only direct parent assembly
  • Housing changes: Impact entire product family
  • PCB changes: Impact electrical systems and test equipment
  • Safety-critical parts: Trigger extended impact analysis including test plans

About 75% of changes have clear, automatable impact scope. The remaining 25% involve engineering judgment - these are flagged for manual impact review by the part owner before MCO creation proceeds.

3. Documentation Generation: Automated documentation includes:

Change Summary Report:

  • Geometric changes with before/after comparisons
  • Material specification changes
  • Mass property deltas
  • Visual comparison using Windchill visualization services (highlighted differences)

Impact Assessment:

  • List of impacted assemblies with usage context
  • Interface change summary
  • Downstream testing requirements
  • Manufacturing process impacts (if tooling is affected)

Engineering Intent Capture:

We prompt engineers during CAD check-in to provide change rationale through a custom dialog. This captures:

  • Reason for change (defect fix, performance improvement, cost reduction, etc.)
  • Expected benefits
  • Risk assessment
  • Testing recommendations

This input feeds into the generated documentation, combining automated technical analysis with human engineering context. Documentation generation time dropped from 45 minutes (manual) to 2 minutes (automated).

4. Workflow Routing Automation: Routing rules are configured in a decision matrix that considers:

  • Part classification (purchased, manufactured, safety-critical)
  • Change magnitude (minor, significant, critical)
  • Cost impact threshold (under $10K, $10K-$50K, over $50K)
  • Customer-specific requirements
  • Regulatory implications

The system evaluates these factors and constructs an approval chain dynamically:


// Pseudocode - Routing logic:
1. Determine part classification and change magnitude
2. Query routing matrix for applicable approval chain
3. Add cost approvers if financial impact exceeds threshold
4. Add customer representatives for customer-specific parts
5. Add regulatory reviewers if compliance-critical
6. Construct workflow with parallel reviews where possible
// Result: Optimized approval path with appropriate reviewers

Parallel routing is used where reviews are independent (e.g., cost approval and technical review can occur simultaneously). Sequential routing is enforced where dependencies exist (e.g., technical approval must precede manufacturing approval).

The routing matrix is maintained through a configuration interface, allowing change management administrators to update rules without code changes. This flexibility was critical for adoption.

5. Continuous Improvement and Monitoring: We track automation effectiveness through metrics:

  • MCO creation time (manual vs. automated)
  • Routing accuracy (correct approvers on first try)
  • Impact analysis completeness (missed impacts caught in review)
  • False positive rate (MCOs created unnecessarily)
  • Cycle time from change detection to approval

Monthly reviews of these metrics drive refinement of detection thresholds, impact rules, and routing logic.

Implementation Lessons: Start with high-volume, low-complexity changes to prove the concept. We began with fastener and hardware changes where impact scope is predictable. After demonstrating value and reliability, we expanded to more complex part types.

Maintain human oversight for engineering judgment. Full automation isn’t appropriate for all scenarios. Our system escalates uncertain cases to engineers rather than making questionable automated decisions.

Invest in configuration flexibility. Hard-coded rules become maintenance nightmares. Our routing matrix and impact rule configuration interfaces allow business users to adapt the system as processes evolve.

Results Summary: After 18 months of operation:

  • 35% reduction in average MCO cycle time
  • 90% reduction in routing errors
  • 40-50 MCOs processed per week (previously 25-30 due to backlog)
  • 85% reduction in false positive MCO creation
  • 100% consistency in impact analysis coverage
  • Engineering time savings of 15-20 hours per week

The automation paid for itself in 8 months through reduced engineering overhead and faster change implementation.