4. Baseline cost and resource assessment

Before any optimization target can be set, the occupant safety program must be measured as it actually exists today. A baseline assessment is not a budget review; it is a structured audit that traces every dollar, every engineering hour, and every test asset back to a specific safety activity. Without this traceability, cost reduction proposals become guesswork, and savings claimed in a business case cannot be defended during finance review. This section defines what a defensible baseline contains, how to construct it from typical enterprise data sources, and how to validate the result before it is used as the reference point for all subsequent optimization work.

What the Baseline Must Capture

A complete occupant safety baseline has three cost layers and one resource layer. The direct material layer covers airbags, seat belts and pretensioners, steering columns, seat structures, instrument panel energy absorbers, head restraints, and the sensors and wiring that trigger these systems. The engineering and development layer covers CAE analyst time, physical test engineers, restraint system designers, and the validation campaigns they execute. The tooling and capital layer covers sled bucks, fixture fabrication, crash-test dummy fleet depreciation, and high-speed camera and data acquisition assets. The resource layer is not monetary: it records how many sled tests, full-vehicle barrier tests, and CAE solver licenses are consumed per program milestone.

These layers must be separated because they behave differently under optimization. Material cost scales with production volume and supplier negotiation; engineering cost scales with headcount and program timing; test asset cost scales with the number of validation loops. A single blended "safety cost" figure hides exactly the levers that later chapters will pull.

Data Sources and Extraction Method

Baseline data rarely sits in one system. A practical audit pulls from four sources and reconciles them:

• Bill of Materials (BOM) with cost roll-up — extract every part flagged to an occupant safety function, using the program's commodity codes rather than part-name keyword searches, which miss items such as seat frame reinforcements that carry restraint loads.
• Engineering time-tracking or program labor allocation — map each engineer's charged hours to a WBS element for the safety workstream. Where time tracking is coarse, use a documented allocation percentage and record the assumption explicitly.
• Test facility records — sled and barrier test logs, including setup labor, dummy calibration, and post-test teardown, not just the test execution day.
• Capital and depreciation schedules — the portion of test equipment and tooling amortized against this program.

A common failure mode is double counting: supplier tooling appears both in the piece-price amortization and in the capital schedule. The audit must define, in writing, which layer owns each cost element. The rule used in most organizations is that anything embedded in the supplier's piece price stays in the material layer, and only company-owned assets appear in the capital layer.

Normalizing the Data

Raw totals are not comparable across programs or across time. Normalize to a per-vehicle basis for material and tooling, and to a per-milestone basis for engineering and testing. For example, if a program plans 180,000 units over its life and the occupant safety material content totals USD 41.2 million, the normalized material baseline is approximately USD 229 per vehicle. Engineering effort of 26,400 charged hours across five milestones normalizes to 5,280 hours per milestone. These normalized figures are what allow a later optimization to be compared fairly against the baseline.

Currency, labor rates, and overhead factors must be frozen at a stated date. A baseline that mixes rates from different fiscal years cannot support a credible savings claim.

Worked Example: Auditing One Restraint Subsystem

Consider auditing the frontal restraint subsystem of a mid-size program. The audit team extracts the following, all figures illustrative:

The audit then verifies each line against its source document. The airbag module costs are confirmed against the current supplier quotation letter, not the original nomination price, because material cost drift between nomination and current date is common. The CAE hours are reconciled against the time-tracking export, and any hours charged to a generic "safety support" code are either reassigned or excluded with a note. The sled test count is confirmed against the facility log, and tests that were reruns due to instrumentation faults are flagged separately, since they represent recoverable waste rather than planned validation.

Validating the Baseline

A baseline is only trustworthy after three checks. First, completeness: sum the audited elements and compare against the program's total safety cost center. A variance greater than roughly five percent indicates a missing or misclassified element. Second, consistency: confirm that the same cost element is not counted in two layers. Third, reproducibility: a second analyst, given the same source documents and the same written allocation rules, should arrive at the same normalized figures within a small tolerance.

The SVG below summarizes the audit flow and the reconciliation decision points that determine whether a cost element is accepted into the baseline.

Common Audit Pitfalls

Three pitfalls recur in occupant safety baselines. The first is using nomination cost instead of current cost for supplier components; material prices drift with raw material indices and volume changes, and a stale figure understates or overstates the baseline. The second is ignoring engineering hours buried in other workstreams, such as body structure engineers who spend part of their time on restraint load paths. The third is treating all tests as planned validation, which conceals rework and inflates the apparent cost of legitimate validation.

Deliverable: Baseline Audit Record

The audit should produce a single controlled record that later optimization work references. A minimal but complete structure is shown below; the fields are the ones that must be defensible, not a generic template.

Baseline Audit Record — Occupant Safety Program
Program ID:            [program code]
Baseline freeze date:  [YYYY-MM-DD]
Rate basis:            [fiscal year, labor rate, overhead factor]

Layer 1 — Direct Material
  Part / commodity code | current unit cost | volume basis | source doc
  ...
  Subtotal per vehicle:  USD [value]

Layer 2 — Engineering & Development
  WBS element | charged hours | allocation rule | source
  ...
  Subtotal per milestone: [hours]

Layer 3 — Tooling & Capital
  Asset | amortized amount | program share | source
  ...
  Subtotal: USD [value]

Layer 4 — Resource Consumption
  Sled tests (planned / rework) | barrier tests | CAE license hours
  ...

Rework subcategory (flagged separately):
  Reruns: [count] | Aborted tests: [count] | Late-change loops: [count]

Validation results:
  Completeness variance vs cost center: [%]
  Double-count findings: [list or none]
  Reproducibility check: [pass / fail, second analyst]

Assumptions and exclusions:
  [explicit list]

Once this record is frozen, it becomes the denominator for every optimization ratio in the remainder of the program. The next step is to use the normalized figures to identify which layers and which specific elements offer the largest recoverable opportunity, which is the subject of the following section.