4. Process mapping and SIPOC for CAE workflows
In a CAE organization, most quality escapes are not caused by a single wrong button press. They are caused by handoffs: a CAD surface that arrives with a sliver face nobody flagged, a solver deck whose boundary conditions were copied from a different load case, a post-processing contour plotted on a result set that was never converged. DMAIC begins with Define, and the Define deliverable that matters most for simulation teams is a shared, unambiguous picture of the process being improved. Two tools do that work: the SIPOC diagram (Suppliers, Inputs, Process, Outputs, Customers) and the process map with its critical-step annotations. This chapter shows how to build both for a typical automotive CAE workflow — mesh generation, solver setup, and post-processing — and how to use them to expose the inputs and decision points that actually control result quality.
Why a CAE process needs its own mapping vocabulary
Manufacturing SIPOC diagrams talk about raw material, machine settings, and dimensional inspection. A CAE process has different physics: the "raw material" is geometry and load data, the "machine" is a solver plus its discretization choices, and the "inspection" is result validation against physical expectations. If you copy a shop-floor template verbatim, the team will produce a diagram that looks correct and teaches nothing. Instead, anchor each SIPOC column in CAE-specific objects:
- Suppliers — CAD design release, the durability loads group, the materials database owner, the meshing team, IT/HPC operations.
- Inputs — geometry revision and its quality state, material cards, load spectra or boundary condition decks, mesh density targets, solver version and license, correlation test data.
- Process — the four to seven high-level steps, not every mouse click.
- Outputs — the solver deck, the results database, the post-processed report, the mesh quality report, the model build log.
- Customers — the design engineer who needs a margin number, the test engineer correlating a shaker run, the program gate reviewer.
The value of writing this down is that it forces the team to name the revision of each input. "Geometry" is not an input; "geometry release R3, exported as STEP AP242, with the weld flanges included" is an input. Most rework in CAE traces back to an input that was correct in kind but stale in revision.
Building the process map: three swimlanes, not thirty boxes
A workable process map for a structural CAE study uses swimlanes for the roles that touch the model — CAD/Design, CAE Engineer, and Reviewer/Test — and keeps the step count between eight and twelve. Below that, the map becomes a procedure document; above it, nobody reads it. The steps that deserve a box are the ones where a decision changes the downstream result: geometry cleanup sign-off, mesh quality gate, boundary condition assignment, solver convergence check, and result plausibility review.
Each box should carry three annotations that a plain flowchart omits: the critical input consumed at that step, the decision criterion applied, and the output artifact produced. For example, the mesh quality gate box is annotated with "input: cleaned geometry + density target; criterion: min Jacobian ≥ 0.3, aspect ratio ≤ 5 in the weld region, no free edges; output: mesh quality report and .bdf deck." That single annotation converts a vague step into an auditable control point.
Critical process steps: where the map earns its keep
Not every step is critical. A step is critical when a defect introduced there is expensive to detect later and cheap to prevent now. In the subframe example, five gates qualify:
| Gate | Critical input | Decision criterion (example) | Failure symptom if skipped |
|---|---|---|---|
| Geometry cleanup sign-off | STEP R3, weld flanges included | No free edges; min face ≥ 2 mm; weld flanges retained | Sliver faces force tiny elements; local stress spikes that are mesh artifacts |
| Mesh quality gate | Cleaned geometry, density target | Min Jacobian ≥ 0.3; aspect ratio ≤ 5 in welds; no free edges | Negative Jacobian aborts the run, or distorted elements inflate peak stress |
| Boundary condition check | Signed BC sheet, load spectrum rev | BC set matches signed sheet element-for-element | Wrong load case solved correctly — the most expensive class of error |
| Convergence check | Solver deck, step settings | Residual < 1e-3; energy balance error < 5% | Contours look plausible but are not converged; margins are unreliable |
| Plausibility review | Results, correlation test data | Peak stress within ±15% of test or hand calculation | Model accepted with a systematic offset that propagates to every later design iteration |
These criteria are illustrative and must be set per program; the point is that each gate has a numeric criterion and a named artifact. A gate without a number is an opinion.
From map to measurement: linking SIPOC to the Define phase
The SIPOC and process map are not decoration for the Define tollgate. They generate the measurement plan for Measure. Every critical gate becomes a candidate CTQ (critical-to-quality) characteristic with a measurable metric: mesh quality pass rate, BC mismatch count per model, convergence first-pass yield, plausibility review rejection rate. If the team cannot state how often a gate fails today, the map has identified a data collection gap — which is itself a valid Define output.
A compact working template
The following structure is deliberately small enough to fill in during a one-hour workshop with the CAE lead, the design engineer, and the test engineer in the same room. It is a starting artifact, not a final document.
CAE PROCESS MAP — WORKING TEMPLATE
Study: ______________________ Program: ______________ Rev: ____
STEP | OWNER | CRITICAL INPUT (with revision) | DECISION CRITERION | OUTPUT ARTIFACT
-----+-------+-------------------------------+--------------------+----------------
1 | | | |
2 | | | |
3 | | | |
...
SIPOC CHECK
Suppliers not yet listed: ______________________________________
Inputs whose revision is uncontrolled: _________________________
Outputs with no named customer: ________________________________
Gates with no numeric criterion: _______________________________
Current first-pass yield at each gate (if known): ______________
Common mapping mistakes in simulation teams
- Mapping the software menu, not the process. "Import, mesh, solve, view" describes the GUI, not the workflow. Steps should be named by the engineering decision they contain.
- Omitting the revision. An input without a revision is a future nonconformance. Write "load spectrum LS-07 rev C," not "loads."
- Treating post-processing as a single box. Post-processing contains at least two distinct decisions: result validation (is the solve trustworthy?) and engineering interpretation (does the margin meet the target?). They have different owners and different criteria.
- Drawing the map once and never updating it. A process map is a living control document; when a solver version changes or a new weld modeling method is adopted, the gates and criteria change with it.
With the SIPOC and annotated process map in hand, the Define phase has produced something more useful than a charter: it has produced a shared, testable description of how a CAE result is actually made, where its inputs come from, and which five decisions determine whether the number handed to design can be trusted.