How Sub-Assembly Visibility Ends the Late-Component Surprise

The late component is rarely a surprise to the system, it is a surprise to the plan: in most shops the parent and its feeder are scheduled separately and joined by an offset somebody guessed. EDGEBIC by User Solutions removes the guess by scheduling a multi-level product as one job. A component with its own routing is exploded at schedule time and planned on real work centers alongside the parent, timed so it is ready when the operation that consumes it needs it.

This post covers the multi-level outcome. It sits under the EDGEBIC results guide. For the mechanism, see EDGEBIC sub-assembly scheduling explained.

Two Plans With a Guess Between Them

The classic setup: the parent assembly has its own order and its own dates. The frame it sits on has a second order, released earlier because someone decided two weeks ahead was about right.

Three things go wrong with that arrangement, and they go wrong together.

The offset is a guess and it never updates. Two weeks was right when it was set. It is not right when the frame's work center is loaded, or when the parent moved out three days, or when the order quantity doubled.

The feeder has no advocate. On the floor, the frame is just another job. It has no visible connection to the assembly that will stall without it, so when a supervisor sequences the station, the frame loses to anything with a nearer due date and a louder customer.

Nobody sees the real critical work. The parent's routing might total 18 hours. The frame's routing might be 40 hours per unit. The job that looks small is the job that is not.

The result is the scramble: the assembly cell stands ready, the frame is two operations from done, and the plan said this was fine.

One Job, Every Level

The switch that turns a component into a sub-assembly is not a checkbox. It is whether the component product has a routing.

That single rule removes the second order and the offset in one move. The child's operations compete for capacity like everything else, and the engine times them so the component lands when it is needed rather than when a planner hoped.

Both kinds are marked where you can see them. A sub-assembly carries a star in the routing grid and on the visual canvas, with a tooltip naming it as a component that has its own routing and is exploded at schedule time, plus a control to preview the child routing read-only without leaving the parent.

The Preview Is the Whole Trick

That preview does more work than it sounds like it should, because the most common multi-level mistake is assuming the parent's hours are the job's hours.

Quoting the 18 is how a nine-week job gets promised in four. Opening the preview before you quote is a thirty-second check that catches it, and it is the reason the control sits on the parent rather than three screens away.

Quantity compounds this. Quantity is how many of the component go into one parent, and it multiplies everything below: the child's operations, its hours, and its cost. A quantity of two on a frame taking 0.5 hours per unit is one hour of frame work per parent unit, and on a 100-unit order that is 100 hours of frame work in the plan rather than 50. Getting that field wrong halves or doubles a large part of the job.

What Changes on the Floor

Three things, and only one of them is about software.

The feeder gets a date that means something. Its operations are placed by the same engine, against the same calendars, so its planned start is a real reservation rather than an inherited guess.

The dependency is visible. A supervisor sequencing the child's work center can see it belongs to a parent job rather than floating alone, which is exactly the information that was missing when the frame lost the sequencing argument.

Actuals stay separate. Sub-assembly work is logged against its own operations, so a job with two levels has two levels of actuals rather than one merged total. That matters for variance: a parent running over because its child overran is a different finding from a parent running over on its own operations. See how a sub-assembly feeds its parent job.

Shared Components Become a Decidable Argument

Two parents drawing on the same sub-assembly is where planning-in-isolation fails hardest, because both planners assume they own the child's work center.

Planned together, the component's station shows the combined load. You can see which parent gets squeezed, by how many days, and decide with dates rather than volume. That does not create capacity on a short station; it makes the shortage visible early enough to do something about it, which is the only version that helps. See scheduling sub-assemblies that feed several jobs.

The heritage lineage behind EDGEBIC includes the extreme case of this problem. US Navy overhaul planning through User Solutions and RMDB coordinated more than 26,000 tasks on the USS Nimitz, which is multi-level dependency at a scale where a guessed offset between levels is not survivable. The same principle scales down: if a component has real work in it, it belongs in the same plan as the thing that consumes it.

The Honest Limits

It does not shorten the job. Exposing 40 hours of child work makes the plan longer and correct, not shorter. The gain is that you find out in the quote rather than in week six.

It needs the child routing to exist. A component whose routing was never built is treated as a material step and books no capacity, which is right for purchased parts and wrong for something you actually make. That is a data question, and it is the most common reason a multi-level plan understates itself.

Quantity is unforgiving. It multiplies everything downstream. Check it on high-volume parents before you trust the hours.

It does not plan your material purchasing. Scheduling and material planning are separate passes. A sub-assembly gets capacity; the raw material feeding it is a different question with its own lead times.

Deep structures need review, not faith. A three-level product with a shared component at level two is genuinely complicated, and the plan will be right about capacity while still being a plan a human should read before committing dates to a customer. See finite versus infinite capacity scheduling for the underlying model and how overlapping operations shorten delivery for the lever that shortens a long multi-level job.

Want to see what your own multi-level products really contain? Bring a parent routing and its components to a demo and we will schedule every level in one pass.