4. Demand intake and prioritization

In a large automotive OEM, a CAE portfolio rarely fails because of insufficient solver capacity. It fails because the wrong analyses get run first. Demand intake and prioritization is the discipline that converts a noisy stream of program requests — crash load cases, NVH targets, thermal duty cycles, durability road profiles — into a ranked, defensible queue that matches engineering value to available analyst hours. This chapter covers how to capture requests consistently, how to score them, and how to resolve the conflicts that inevitably surface when three vehicle programs want the same crash team in the same week.

Why Ad-Hoc Intake Breaks Down

When requests arrive by email, chat, or hallway conversation, three failure modes appear. First, incomplete requests: an NVH engineer asks for "a body-in-white modal analysis" without specifying the trimmed vs. untrimmed condition, frequency band, or boundary constraints, so the analyst either guesses or bounces it back. Second, invisible demand: work that was never formally logged consumes capacity but never appears in utilization reports, so planning is systematically optimistic. Third, priority inflation: every requester marks their item "critical," which collapses the ranking into a first-come-first-served queue driven by whoever escalates loudest.

A structured intake process fixes all three by forcing a minimum information set, creating a single visible backlog, and applying a scoring rule that is applied identically to every request.

The Intake Record: Minimum Required Fields

Every CAE request should be captured as a structured record before it enters the backlog. The fields below are the minimum that allow an analyst to estimate effort and a planner to rank without a follow-up meeting.

The "decision it informs" field is the most important and the most frequently omitted. A CAE result that does not feed a specific engineering decision — a gate review, a design change, a supplier selection — is a candidate for deferral. Requiring requesters to name the decision filters out exploratory work that belongs in a research budget, not the program backlog.

Scoring by Impact and Urgency

With records captured, ranking uses two independent axes. Impact measures how much the result changes a decision; urgency measures how soon the decision must be made. Keeping them separate prevents the common error of treating "due soon" as "important."

A practical impact score (1–5) can be built from three sub-factors:

• Decision leverage — does the result gate a design freeze (5), inform a trade study (3), or provide background data (1)?
• Program exposure — how many vehicles or variants depend on the outcome? A platform-wide result outranks a single-variant check.
• Risk of being wrong — safety, regulatory, or cost exposure if the design passes CAE but fails physical test.

Urgency (1–5) is driven by the gap between the required date and the earliest date the analysis can physically start, given model readiness. A request due in three weeks whose model will not be meshed for two weeks has low effective urgency regardless of the calendar.

Consider three competing requests in the same week for a single crash analyst:

The frontal ODB request wins on index despite lower urgency, because it gates a design freeze. The rear-impact request has the tightest slack and should be flagged for a capacity decision — either pull a second analyst or negotiate the date — rather than silently displacing the higher-impact work.

Resolving Capacity Conflicts

Scoring produces a ranked list, but the list must be reconciled against real capacity. A crash analyst who can deliver roughly 1.5 full-vehicle models per month cannot absorb four simultaneous gate-driven requests. The weekly portfolio review should compare the ranked backlog against a capacity model expressed in analyst-days per skill group — crash, NVH, thermal, durability, CFD — because these skills are not interchangeable.

When demand exceeds capacity, three legitimate moves exist. Defer the lowest-index request and communicate the new date to the requester immediately. Reallocate from a non-program or research budget if the work has strategic value. Negotiate the gate date with the program, which is a program-management decision, not a CAE decision. What must not happen is silent overload, where analysts absorb the excess through overtime and the backlog becomes fiction.

Making the Process Stick

Intake discipline survives only if it is faster than the informal alternative. Keep the request form to the eight fields above, allow submission through a lightweight web form or shared tracker, and publish the ranked backlog weekly so requesters can see where they stand. When a requester asks "why is my item below that one?", the answer should be a visible index and slack value, not a judgment call. That transparency is what converts prioritization from a political exercise into an engineering one.

Finally, review the scoring calibration quarterly. If every request scores 20+, the impact scale is too generous. If nothing ever scores above 10, the urgency definition is too strict. The goal is a distribution that meaningfully separates work, so that the top of the queue genuinely represents the analyses that most change vehicle decisions.