Overlapping Operations When Changeovers Are Sequence-Dependent

On a discrete machine, EDGEBIC by User Solutions computes operation overlap as the resolved changeover time plus the transfer batch multiplied by hours per piece, which means a sequence-dependent changeover matrix does not just lengthen an operation: it moves every downstream start on that routing. The two features share one number, and the way that number is resolved and cached is the whole interaction.

If either mechanism is new, read lot streaming explained and the setup matrix explained first. For the definitional pieces, what is a transfer batch and what is a setup family cover the vocabulary. This post is about the seam between them.

The Shared Number

Two of the three overlap behaviors are relevant here.

Piece-count overlap fires when an operation carries a transfer batch above zero and its machine is not flagged as a continuous process. The downstream operation's earliest start is:

upstream start + resolved setup + min(transfer batch, order quantity) × hours per piece
                + transfer delay

Setup is in that formula, in front of the run time, because the machine must be changed over before the first piece exists.

Flow-lag overlap fires when the transfer batch is zero (or the machine is continuous-process) and a flow step is set. The downstream earliest start is simply the upstream start plus that many hours. Run hours, quantity, and setup all play no part. So the setup matrix has no effect at all on a flow-lag operation.

That asymmetry is the first thing to internalize. If your overlap is expressed in hours of head start, changeover data will not move it. If your overlap is expressed in pieces, changeover data moves it on every job.

Why the Value Is Resolved Once and Cached

The resolver that produces a changeover time walks a short chain: cold start, same product, product-level matrix cell, family-level matrix cell, then the routing default and finally the machine default. The five-level chain post covers each level. What matters here is when it runs.

It runs once, when the operation's total hours are assembled, and the answer is cached on the routing step for the rest of that scheduling run. The overlap formula then reads the cached value rather than asking again.

There is a concrete reason for that, and it is not performance. By the time the overlap is being computed, the operation's own allocation has already been written into the machine's capacity map. If the resolver ran a second time, the question "what ran on this machine most recently" would find this job's own product and return a zero changeover. The overlap window would silently shrink by the whole changeover, the downstream operation would be planned to start before its material could physically exist, and nothing in the plan would look wrong.

Caching the first answer removes that trap entirely. The operation's duration and the handoff to the next operation always agree on one changeover value.

The cache is deliberately per run. It is cleared at the start of each full rebuild and never saved, so a changeover resolved against last week's sequence cannot leak into this week's plan.

What This Looks Like With Real Numbers

Take a lathe running 100 shafts at 0.5 hours per piece, with a transfer batch of 20 and a half-hour material-handling delay. The full run is 50 hours of cutting plus whatever the changeover costs.

The lathe's own finish barely moves between those rows relative to a 50-hour run. What moves is the moment deburring can begin: two hours of spread on a single job, from a decision about job order that has nothing to do with either operation's own content.

Now scale that across a machine that runs eight jobs a day. Sequencing by changeover cost is usually sold as a way to recover setup hours. On a routing that uses piece-count overlap, it also pulls every downstream operation earlier. That second effect is invisible in a setup-hours report and very visible in a lead-time report.

Cold Start Is Not Zero

The first job scheduled on a machine in a run has no prior product, so the resolver returns a cold start and uses the routing's own setup, not zero. That is correct: the machine still needs its initial preparation even though there is no changeover from anything.

For the overlap formula, that means the first job on a machine each run gets a slightly later overlap point than a steady-state job coming off the same product would. Planners occasionally read that as a bug. It is the honest answer, and the alternative (assuming a free changeover on the first job of every run) would understate every plan.

Only the same-product case returns a genuine zero. If two different products in one family should also change over in zero minutes, the family-to-itself cell has to be entered explicitly as zero. Leaving it blank falls through to the routing default, and on a routing that streams by pieces, that default lands directly in the overlap window.

After a Partial Completion, Reality Wins

The most valuable part of the interaction shows up on reschedules.

When a job has actuals, the analysis records the product that was physically last completed on each machine and instance. The resolver consults that first, before it looks at anything in the planning state. So the changeover cost for the first remaining operation on that machine reflects what the machine actually ran, not what an earlier plan assumed it would run.

That flows straight into the overlap formula. A downstream operation waiting on a partially completed upstream operation is timed from the real changeover the floor is about to perform.

There is a second reschedule behavior worth knowing. When the upstream operation is already in progress, the overlap is not projected from the formula at all if the piece counts say otherwise. Logged piece counts are summed day by day, and if the transfer batch threshold has already been crossed, the downstream start is set to the end of the shift on the crossing day rather than to a formula result. The formula is a projection used only until real piece counts exist. How actuals flow into the schedule covers the wider mechanism.

Synchronized Machines Do Not Re-Resolve

A synchronized secondary machine mirrors its partner's schedule, and its changeover is stamped as inherited rather than resolved independently. That is correct by definition: the two machines are performing one physical setup at the same time on the same fixture, so resolving a second changeover for the mirror would double-count it.

The practical read is that the audit column on a mirrored row will always say the value came from the parent. Do not go looking for a matrix hit there.

Four Configuration Conflicts the Report Catches

Because both mechanisms write into the same handoff, the anomaly report carries specific checks for the combinations that are legal to enter and ambiguous in intent. The anomaly checks explained covers the full catalog; these four are the ones relevant here.

The last one deserves emphasis because it is easy to configure with good intentions. Both overlap models return their result as the successor's gate, replacing whatever the queue calculation produced. If an operation genuinely needs both an overlap and a physical handling wait, express the wait as a transfer delay, which is added on top of the overlap window, rather than as queue time, which is discarded. The queue and transit mistakes post has the longer treatment.

Verifying the Two Features Agree

Two columns tell you everything after a run.

The setup source column names where the changeover came from: a product-level cell, a family-level cell, the routing default, the machine default, a cold start, a same-product zero, or a mirror. Product and family hits are shown at full brightness and the rest muted, so a machine that should be running on matrix data and is showing routing defaults everywhere is visible at a glance. That usually means one of the two products in the pair has no family assigned, because a family lookup needs both sides.

The setup reason column carries the sentence version, naming the two products or families and the minutes.

If the sources look right and the overlap still looks wrong, check the order quantity against the transfer batch, then check whether the machine is flagged continuous-process. Those two account for most of it. Setup matrix mistakes and lot streaming mistakes list the rest with symptoms.

Practical Sequence for Setting Both Up

1. Decide the overlap model per operation first. Countable pieces on a discrete machine means a transfer batch. A continuous stream means a flow lag in hours, and the setup matrix will not touch it.
2. Build changeover families before individual product overrides. Families carry roughly all of the useful data at a fraction of the cell count, and the product level exists for genuine exceptions.
3. Enter the family-to-itself zero cells explicitly wherever consecutive different products in one family really do change over for free.
4. Set the transfer batch to a real sublot the floor will actually move, not to a number that happens to divide the order.
5. Run a full reschedule after matrix edits so cached changeover values are cleared and rebuilt.
6. Read the setup source column and confirm matrix hits appear on the non-first jobs in each machine's sequence.

One sizing note on step four. A transfer batch that is too small produces an overlap the floor cannot honor, because nobody is moving four pieces at a time across the shop. A batch that is too large collapses toward a serial wait, and at or above the order quantity it is a serial wait exactly. The useful range is the smallest quantity your material handling will actually move as a unit: a full tote, a full rack, a full pallet layer. Ask the people who move the parts rather than dividing the order quantity by a number that looks tidy.

Both features are opt-in per operation, and both do nothing until you configure them, so there is no rush and no risk in staging the rollout one machine at a time. Start with the machine where changeovers hurt most, which is usually the one where the sequencing argument gets loudest.

For the broader picture of how a step's timing is assembled, how EDGEBIC composes step timing traces the whole chain from allocation to handoff. For the other pairings that catch planners out, from machine pools meeting parallel operations to transit and operators, the feature interactions that surprise people catalogs fourteen of them with the symptom, the reason, and the fix. For the full feature map, see the complete guide.