The signal is discrete, scheduled, and operational
A kanban pull is not simply a smaller purchase order. It is a discrete demand signal tied to a production rhythm, a replenishment rule, and often a specific time window. That distinction matters when training a forecast model. A continuous order stream can suggest broad commercial demand, while a pull schedule shows what an assembly plant expects to consume at a defined point in its takt time.
For a Tier-2 or Tier-3 supplier, the useful question is rarely “What did customers buy last month?” It is closer to “Which part number will be required, in what quantity, and when will the next pull reach us?” The answer is shaped by the assembly plant’s schedule, model changeovers, container quantities, kanban loops, lead times, and the constraints recorded in the supplier’s ERP or MRP system.
This is the setting for Lean Path’s AI demand forecasting for Japanese automotive supply chains. The company keeps automotive supply chains stocked without overbuying. Its AI forecasts demand across each tier of parts suppliers, so a plant orders what the line will need, not what it panicked over last week.
Why generic demand history misses the pull signal
A standard time-series model may treat a sequence of orders as a smooth trend, even when those orders are the visible result of a production control system. In a pull environment, a sudden order increase can reflect a temporary schedule change, a kanban container reaching its reorder point, or a model changeover. It does not automatically mean that end demand has permanently risen.
Conversely, a quiet period may not indicate weakening demand. A supplier could be consuming safety stock, operating under a revised delivery cadence, or waiting for the next confirmed assembly plant pull schedule. A forecast that reads only shipment history can confuse the control mechanism with the underlying requirement.
Lean Path’s approach starts with the pull schedule and forecasts tier by tier. Its time-series model is trained on pull schedule history, seasonality, and model changeovers. The intended output is not a single number detached from production reality. It is a forward view that can be compared with current kanban quantities, replenishment lead time, safety stock, and available capacity.
The tier structure also matters. A change in an OEM schedule can affect a Tier-1 module supplier first, then a Tier-2 stamping or machining supplier, and later a Tier-3 material or process supplier. Lean Path models this signal propagation from OEM to Tier-1, Tier-2, and Tier-3, rather than treating every supplier’s order history as an isolated series.
From pull schedule to forecast input
The first technical task is to preserve the meaning of each signal. A pull quantity should remain associated with its part number, planned timing, and place in the replenishment sequence. The relevant BOM relationship may be several levels away from the assembly plant. A Tier-2 supplier making a stamped bracket needs to understand not only its immediate customer’s order, but also how that bracket appears in the larger vehicle or module schedule.
That does not mean every field in an ERP or MRP system belongs in the model. More data can add noise when it is not connected to the production event. A practical model should distinguish scheduled pulls from expedites, cancellations, inventory corrections, and one-off recovery actions. These exceptions can be important operationally, but they should not quietly redefine the normal demand pattern.
Production context is equally important. Takt time establishes the pace of the line, while a kanban loop establishes how material is replenished. A model changeover can alter the mix of part numbers without changing the total line rate. Seasonality can move demand around holidays or annual production cycles. Lead times of 8 to 14 days can turn a small schedule revision into a material purchasing decision for a supplier that must order steel, resin, or bought-in components in advance.
Lean Path does not position the forecast as a replacement for production control. The forecast is a planning input that helps teams decide whether a planned pull is consistent with recent history and known changes. Operators and planners still need to review exceptions through their normal escalation process, including an andon response when a line or supplier is at risk.
A synthetic Tier-2 example in Aichi
Consider a hypothetical Tier-2 stamping supplier in Aichi producing a bracket used in a Tier-1 seat assembly. The supplier receives a pull schedule that normally calls for 2,400 brackets per day. Its press line runs close to the expected takt time, and the supplier carries safety stock sized for its material lead time and the customer’s replenishment rules.
During an eight-week period, the assembly plant introduces a model changeover. The Tier-1 customer’s schedule shows lower demand for one bracket variant, followed by a sharp increase in another. The Tier-2 supplier sees the increase in its immediate orders, but the first two weeks are distorted by a stock adjustment and an expedited shipment. A simple order-history forecast could interpret the expedited shipment as a new baseline.
A pull-based model has a different starting point. It looks at the assembly schedule, the relevant BOM relationship, the normal kanban cadence, seasonality in the historical pull schedule, and the timing of the model changeover. It can then distinguish a short recovery action from the expected requirement after the changeover. The planner still checks press capacity, die availability, raw material orders, and PFMEA controls, but the demand estimate is less likely to be driven by one abnormal transaction.
This example is illustrative, not a claim about a named customer or a measured production result. It shows why tier notation is more than a label in a forecasting workflow. The same schedule event can appear as a finished-module requirement at Tier-1, a component requirement at Tier-2, and a material requirement at Tier-3. Forecast timing and quantity need to travel through that structure.
Forecasting should support kaizen, not bypass it
Lean production treats abnormalities as information. A forecast can support that practice when its output is visible enough to compare with actual pulls, missed kanban signals, shortages, excess inventory, and schedule changes. The useful review is not only whether the prediction was numerically close. It is also whether the error points to a change in the process, a bad master-data relationship, a missed model changeover, or an exception that should be handled separately.
That review can fit into existing kaizen routines. A planner might examine forecast error by part family, supplier tier, or changeover period. A production manager might compare predicted demand with takt time and press capacity. A quality team might check whether a recurring shortage is connected to an APQP launch activity or a PFMEA control that needs attention. These are different decisions, but a shared demand view gives them a common starting point.
Lean Path’s typical first forecast is available in week 3 of onboarding. The company’s pilot is an eight-week structured engagement covering up to 15 SKUs. This limited scope is useful for testing whether the schedule data, BOM relationships, exception rules, and operating routines are sufficiently clear before a wider rollout. The design-partner cohort is in the Japan automotive sector, and no customer names are disclosed here.
Based on design-partner pilot data, Lean Path has observed approximately 35% fewer unplanned reorders. This is a qualified pilot metric, not a universal performance guarantee. It also does not mean that every reorder is avoidable. A genuine engineering change, supplier disruption, quality hold, or sudden customer schedule revision can require an urgent response even when the forecast is functioning as intended.
Where the method reaches its limits
The approach is not claiming that an AI forecast can replace kanban governance, MRP controls, supplier communication, or the judgment of a production planner. It is not claiming that historical pull schedules can predict an unprecedented supply disruption. It is also not claiming that better prediction alone will fix inaccurate BOMs, inconsistent part numbers, missing lead times, or a safety-stock policy that has never been reviewed.
Pull-based data has its own limitations. A schedule may reflect a local inventory decision rather than final consumption. A Tier-1 supplier may change its shipment lot size without changing the vehicle schedule. A Tier-3 supplier may have too little historical data for a stable estimate. New parts, low-volume variants, tooling constraints, and launch periods can produce sparse or irregular signals. In those cases, a forecast should expose uncertainty and invite review, rather than create false precision.
The counterpoint is important: a push-oriented planning process may sometimes have more usable information than a fragmented pull process. If the pull schedule is late, incomplete, or disconnected from the BOM, a sophisticated model cannot restore the missing operational link. The quality of the forecast depends on the quality and interpretation of the signal.
For a small team working directly with customers, that is why implementation starts with the supply chain structure, not with a generic dashboard. Takeshi Yoshida, CEO & Co-Founder, Kenji Tanaka, CTO & Co-Founder, and Rika Hayashi, Head of Operations, work with design partners to understand how schedules move from the assembly plant through each supplier tier. Pull-based production teams that want to examine their own structure can contact Lean Path at [email protected].
In practice, the value of a pull-based forecast is decided at the handoff between prediction and action: whether a planner can see why demand moved, confirm the relevant kanban and BOM relationships, and adjust purchasing or production before an avoidable reorder becomes an andon event.