Simulated decision case · 02 / 07

When AI Forecasting Solves the Wrong Problem

This simulated case shows why a broad AI forecasting initiative can miss the decision level that actually drives operational value. Intake responses can reveal frequent “infeasible” plans, spreadsheet translation between product variants and components, and recurring engineering-change surprises. Those statements do not prove that information flow is the binding constraint. Stage 2 would test the hypothesis using planning-run logs, product-to-component mappings, forecast-versus-actual records and change-effectivity data. The directional decision is FIX and re-scope. Make plan constraints explainable first, then run a bounded component-risk forecasting pilot on the small set of long-lead and high-service-impact parts where the decision can be measured.

What does this case show? A general demand forecast can look sophisticated while missing the component-level decision and structural information-flow problem that actually creates risk.

01 · Organisation and value

Business context and management question

Organisation and value proposition

A mid-sized manufacturer of configurable industrial equipment. Sales plans in finished-product variants, while purchasing and production are constrained at component level. Firm orders extend only a short distance into the future, while some components require much longer commitments. Product configurations and engineering changes add another layer of uncertainty.

Management question

Should management fund a broad AI demand-forecasting tool and planning copilot, or is the initiative aimed at the wrong level of the problem?

Relevant value-chain context

The problem sits at the push-pull boundary between order-driven assembly and forecast-driven long-lead procurement. The highest-risk decisions happen where product variants must be translated into components, buffers and supplier commitments.

02 · Approaching the real problem

From symptom to a testable problem hypothesis

Early signals visible through intake

The following items may be reported during the initial intake or interviews. They are not treated as measured performance values.

  • The planning engine frequently declares a plan infeasible without explaining the blocking constraint.
  • Excess inventory and component shortages occur at the same time.
  • Forecast accuracy appears acceptable at aggregate product level but breaks down at component level.
  • Product-to-component translation depends on spreadsheets and expert memory.
  • Engineering changes are discovered late in the planning cycle.
  • Planners spend more time translating data and re-running plans than making decisions.

Priority problem hypothesis

Initial intake, interviews and limited document signals may make the following hypothesis a priority. It is not presented as a confirmed root cause until it is tested against operational evidence.

The working hypothesis is that the binding constraint may be information flow, decision level and explainability before it is forecasting technique. Sales and operations speak different data languages. The system says “infeasible” but does not explain why. A structural gap exists between the firm-order horizon and long procurement lead times. Better aggregate forecast accuracy cannot remove that gap. The value opportunity may lie in segmenting critical parts correctly, exposing why a plan fails and translating engineering changes into component risk.

Customer and internal value to be validated

The following are value hypotheses, not achieved or validated outcomes.

Customer value: Customers expect both configuration flexibility and a reliable delivery date. If component risk is discovered late, flexibility becomes a source of uncertainty rather than value.

Internal value: Planner time may be recovered, poorly designed safety stocks can be challenged, critical shortages can become visible earlier and key-person dependency can fall.

03 · AI alignment

From the first AI reflex to a value-aligned design

01 · First reflex

Proposed technology

Purchase a broad demand-forecasting tool and a planning copilot.

02 · Alignment gap

Why should it be reconsidered?

  • Forecast quality is not measured at the component level where the decision is made.
  • The reason a plan fails is invisible. A copilot may only add a new interface over a black box.
  • The horizon gap is structural and cannot be closed by forecasting alone.
  • Product-to-component mapping and engineering-change data are not managed as reliable data products.
  • One broad pilot can hide high-risk component segments inside a low-risk population.
03 · Priority direction

Explainable Component-Risk Planning Pilot

The AI role, human decision boundary, data readiness and measurement logic are designed together. No scale decision is made without pilot evidence.

Public boundary: This page shows the decision logic. It does not publish MoreSight’s detailed question architecture, scoring rules or project analysis templates.
04 · Opportunity map

AI options derived from the real problem

This table is not an investment decision or a definitive ranking. Priority and evidence readiness are reassessed during Stage 2.

Opportunity hypothesisAI roleValue connectionEvidence readinessDirectional priority
Plan infeasibility explanation engineDetect + ExplainReduce trial-and-error and expose hidden constraintsPlanning logs and a reason taxonomy requiredHigh; first validation candidate
High-risk component demand and risk forecastPredict + ExplainManage shortage and excess exposure in a bounded segmentComponent-level forecast and actuals requiredHigh; bounded pilot candidate
Engineering-change impact alertDetect + SimulateSee transition risk earlierEffectivity and BOM governance requiredMedium; after foundations
General planning copilotGenerate + RecommendEasier interfaceDoes not solve the root-cause or data gapsLow; current scope not recommended

Priority initiative to test if evidence supports it

The design below is not a solution commitment. It is a pilot hypothesis to be validated.

Explainable Component-Risk Planning Pilot

  • Business decision: Which critical components are at shortage or excess risk from future orders and changes, and which constraint makes a proposed plan infeasible?
  • Primary users: Planning, purchasing, engineering change management and sales operations.
  • Inputs: Planning-run logs, product-to-component mapping, forecast and actuals, lead times, single-source status, inventory, open orders and effectivity dates.
  • AI functions: Classify and explain constraint reasons, forecast critical-component risk, and compare scenarios and buffer effects.
  • Outputs: Plan-failure reason, ranked risk list, forecast confidence interval, proposed buffer or alternative action and identified data blind spots.
  • Human decision boundary: The AI does not set buffers or place purchase commitments automatically. Planning and purchasing approve the recommendation. Engineering validates change impacts.
  • Measurement logic: Track first-pass plan acceptance, planner rework time, forecast error in the pilot segment and combined excess-plus-shortage exposure.
05 · Evidence and claim boundary

What can intake show, and which claims require data?

Areas the intake can direct

  • A signal that sales and operations work at different data levels.
  • Reports that planners lose time to unexplained infeasible outcomes and manual translation.
  • A hypothesis that the stated forecasting problem includes component-level and horizon mismatches.
  • A signal that ownership of forecast quality, planning parameters and engineering-change readiness may be fragmented.

Evidence required for Stage 2

  • Planning-run logs and failed-plan outputs.
  • Forecast-versus-actual data at product and component level.
  • Lead-time, single-source, inventory and open-order records.
  • BOM, configuration and effectivity data.
  • Engineering-change workflow and late-discovery records.
  • Planner time spent on manual translation and re-runs.

Analyses possible when evidence is available

  • Compare forecast error at product and component levels.
  • Build a failure-reason taxonomy and concentration analysis from planning logs.
  • Segment long-lead, single-source and high-service-impact components.
  • Conduct a time study or log analysis of planner re-runs and manual translation.
  • Compare the bounded pilot against baseline using shortage and excess exposure.

Claims we will not make without evidence

  • The true level of forecast accuracy or inventory cost.
  • That information flow is definitively the binding constraint.
  • That AI forecasting will reduce inventory or planner time by a stated amount.
  • That the copilot has no value or that the re-scoped initiative should be scaled.

Readiness gaps and risks

The following are readiness hypotheses that require document and process review.

  • Plan-failure reasons are not logged consistently.
  • Product-to-component mapping lacks version and effectivity governance.
  • Ownership of forecast quality and planning parameters is fragmented.
  • Critical-component segmentation is not defined.
  • The human action that should follow each model output is not embedded in process.

Decision language by evidence level

  • Stage 1: Provisional FIX / re-scope. Do not expand the broad forecasting and copilot programme until the decision level and data foundation are confirmed.
  • Stage 2: If component-level data and planning logs support the hypothesis, issue an evidence-supported START for explanation plus a critical-component pilot.
  • After the pilot: Consider gradual SCALE only if forecast calibration, planner rework and inventory exposure improve together.
06 · Validation plan

Move to the next defensible decision in 90 days

This plan is adapted to data access and client scope. Stage 1 alone does not include implementation or outcome validation.

PeriodPurposeMain actions
Days 1–30Make the decision level and constraint visibleBuild a component-level baseline, create the plan-failure reason taxonomy and identify the long-lead, single-source, high-service-impact component set.
Days 31–60Fix data and ownership foundationsVersion the product-to-component mapping, establish the engineering-change workflow, and assign owners for forecast quality and planning parameters.
Days 61–90Run a two-part bounded pilotDeliver a plan-explanation view and a critical-component forecasting pilot with pre-agreed scale-or-stop thresholds.

Recommended validation measures

  • First-pass plan acceptance rate.
  • Time spent on manual translation and re-runs.
  • Forecast error in the pilot component segment.
  • Number of engineering changes discovered late.
  • Excess and shortage exposure index.
07 · Decision gate

When should management Scale, Iterate or Stop?

Scale

Forecast or risk ranking improves measurably in the pilot segment and planner rework falls.

Iterate

The risky-component list is useful, but the explanation or action design is not.

Stop

Product-to-component mapping and effectivity data cannot be governed reliably, or business ownership cannot be established.

Decisions management must make

  1. Which components will be forecast-driven and which will be order-driven?
  2. Who owns plan-failure reasons and product-to-component data?
  3. Should the first investment go to forecasting or explainability?
  4. Which pilot result would earn the right to expand to more component groups?

Transferable lesson: Forecasting value depends not only on accuracy. It depends on measuring the right object, at the right time horizon and at the level where a real decision is made.

Disclosure: This is a simulated composite case. Organisation characteristics, circumstances, data and outcomes have been altered, combined or synthetically generated. It does not represent a specific organisation or client engagement. Numerical examples are not achieved client results.
Your initiative

Which decision does your AI project deserve?

Assess the available evidence, business value and implementation conditions together.

Start a Business Value Review