What Changes by Day 90

By day 90 the delivery numbers finally start telling you the truth, because jobs quoted under the new schedule have now been quoted, built, and shipped under it. Month one is data correction and conflict prevention. Month two is rhythm. Month three is the first honest read on whether your promise dates and your delivered dates have converged. This guide covers what has moved, what to switch on now, and how to measure it without flattering yourself.

It assumes you have come through the first month described in what changes in the first 30 days with EDGEBIC by User Solutions. If your day 30 looked nothing like that, the diagnosis section at the end applies first.

The Timeline of When Things Move

Different results respond at different speeds, and the order is consistent enough to plan around.

The two rows at the bottom are the ones leadership asks about first and the ones that respond last. Setting that expectation at go-live is the single most useful piece of implementation management you can do.

What Should Have Moved by Now

Delivery, on the right cohort

At day 90, do not look at aggregate on-time percentage. Split it.

Pre-go-live cohort: jobs promised on dates computed from the old capacity model. Some of those promises were never achievable and no scheduling system makes them so retroactively.

Post-go-live cohort: jobs quoted from an actual scheduled simulation against committed capacity. This is the group that tests whether the system works.

If the post-go-live cohort is shipping on time while the aggregate lags, the implementation is working and the metric is diluted. Report both.

The documented ceiling for this class of improvement in the User Solutions record is GE Railcar, which took on-time delivery from 30% to over 90%. That is a specific plant over a specific period, not a forecast for yours, but it establishes that the mechanism has room to run.

Quoting accuracy

This is the cleanest day 90 measurement, and most shops never take it. For every job quoted after go-live that has now shipped, record the promised date and the delivered date. The distribution of that difference is the most direct read on whether your capacity model matches your floor.

If promised and delivered are converging, quoting is now running off reality. See how a quote becomes a promise date and quote simulation explained.

If they have not converged, the usual cause is not the software: it is that sales is still getting dates from somewhere else. Check.

Start variance

Compare planned start to actual start across all jobs for two weeks. This number is more diagnostic than finish variance because it isolates cause.

Jobs that start late at one specific work center point to a capacity assumption that is wrong at that work center. Jobs that start on time everywhere but finish late point to routed hours or setup allowances that are understated. Two different fixes; start variance tells you which one you have. See reading the Gantt planned vs actual.

Planner time

By now the planner should be running the schedule rather than repairing the model. If they are still net negative against their spreadsheet time, that is a data backlog rather than a workflow problem.

What to Switch On in Months Two and Three

Deliberately leaving capabilities off during go-live is good practice, because a schedule nobody trusts yet plus a feature nobody understands yet produces an argument rather than a gain. Day 90 is when several of them earn their place.

The optimizer

Turn this on once the baseline schedule is trusted, not before. The reason to wait is that an optimizer improves the schedule you give it; if the underlying routing data is wrong, it optimizes the wrong problem confidently.

Two things about it are worth stating precisely to your team. The multi-run layer evaluates dozens of complete alternative schedules and is guaranteed never worse than the baseline: if none of them beats what you have, it returns what you have. The exact solver layer goes further and reports a proven optimality gap, so the result carries a statement about how close to optimal it is rather than a claim of perfection. And nothing is applied until a planner reviews the comparison and accepts it. See the optimizer guide and why the optimizer returned the same schedule, which is a normal and honest outcome rather than a fault.

Lot streaming

If you have multi-step routings where a downstream operation could start on a partial quantity, overlapping them shortens elapsed job time without adding capacity. This is one of the few mechanisms that genuinely compresses lead time rather than just re-ordering work. See lot streaming explained and what a transfer batch is.

Bottleneck anchoring

If you have a genuine constraint (one machine that governs plant output), scheduling around it deliberately is a different discipline from scheduling everything evenly. Flag it and anchor to it. See how to flag and schedule around a bottleneck and production bottleneck identification for finding it in the first place.

Scenarios and what-if

By month three you have enough confidence in the base model that a what-if comparison means something. Adding a shift, buying a machine, or accepting a large order can now be tested against the real committed load rather than argued about. See how to build and compare scenarios.

The 90-Day Measurement Sheet

Take the same four baseline numbers plus two new ones. Report them side by side with the pre-implementation set.

Two rules for filling it in honestly. Use the same definitions you used at baseline, even if you have since found better ones. And report the number that did not move alongside the ones that did, because a report where everything improved reads as marketing and gets discounted accordingly.

For the measurement protocol itself, see what to measure before buying scheduling software and the job shop scheduling ROI evidence.

What a Struggling Implementation Looks Like at 90 Days

Three symptoms, each with a specific cause and fix.

Symptom: the planner overrides the schedule regularly. Log every override with a one-line reason for two weeks. Sort into judgment overrides (a customer moved a date, a specific operator is unavailable) and data overrides (a setup time that is always wrong, a work center whose capacity is misconfigured). Judgment overrides are the job. Data overrides are a backlog, and clearing it is usually a day of work.

Symptom: actuals logging is patchy. Rescheduling quality depends entirely on knowing what has actually been done. If operators are not logging consistently at day 90, the cause is almost never the interface: it is that nobody has shown them what their logging changes. See getting the floor to trust the schedule and actuals logging mistakes.

Symptom: two versions of the schedule still exist. The published one and the supervisor's private list. This is the deepest failure because it makes every other improvement invisible. The fix is not a memo; it is a run of consecutive weeks where the schedule is right and visibly corrected when it is not.

The Second-Order Changes Nobody Puts on a Scorecard

Three things shift by month three that no metric captures and that leadership usually notices before the numbers do.

Meetings get shorter. The production meeting that used to spend forty minutes reconciling competing versions of what is running now spends ten confirming exceptions. The reconciliation was never the point of the meeting; it was the tax on not having a shared plan.

Arguments become questions. "Why is this job late?" changes from an accusation with several plausible answers into a question with a traceable one. When a schedule records the decisions it made, the conversation moves from blame to cause. See why did my job jump after a reschedule.

The planner's attention moves forward. This is the compounding benefit and the hardest to price. A planner who is no longer reconstructing Monday can look at the fourth week out, question a quoted date before it is committed, or notice that one work center has been quietly over-loaded for a month. In the documented User Solutions record, Homestead Furniture went from 40 hours a week of scheduling effort to 2, and the recovered attention is at least as valuable as the recovered hours.

The Day 90 Review Meeting

One hour, with the planner, a supervisor, and whoever sponsored the project. Four questions, in this order.

1. Which numbers moved, and which did not? Use the sheet above. Present the flat lines alongside the moving ones.
2. What are we still overriding, and why? Read the override log. Anything appearing three or more times is a data item to fix, not a habit to tolerate.
3. What did we defer at go-live, and is it time? The optimizer, lot streaming, bottleneck anchoring, scenarios. Take one, not four.
4. Who owns what for the next quarter? Confirm the three named people are still the three named people, because job changes silently orphan the master data role more often than anything else.

Write the answers down. At day 180 this document is the only reliable record of what the shop looked like at 90 days, and memory will have quietly revised it.

What Day 90 Does Not Tell You

Lead time reduction is usually a months three to six story, because it depends on flow changes rather than sequence changes. Inventory and work in process respond to staging behavior over a longer period. And the compounding benefit (a planner whose attention is free for next quarter rather than this Monday) does not appear on any dashboard.

In the documented User Solutions record, Technical Glass Products reported a 4% capacity gain alongside a two-week lead time reduction, and Cummins ran the approach across 33 locations. Those are outcomes of the mature state, not the 90-day state. The ASCM body of knowledge treats scheduling maturity as a progression rather than an event, which matches what implementations actually look like.

Next

If day 90 looks healthy, the work shifts from implementation to ownership: someone owns the master data, someone runs the schedule, someone reviews the anomaly report weekly. Who does what after the scheduler goes live sets out the split.

If it does not look healthy, start with the override log and the actuals rate. Both are diagnostic and both are fixable.

For the full set of documented mechanisms behind each result, see the measurable results guide. To have your own numbers scheduled and compared against the plan you publish today, contact US with a real routing and a week of orders, and see what EDGEBIC produces.