From All-Day Replan to a Coffee Break

Planning time is spent on two very different activities: arithmetic and judgement. Software should take all of the first and none of the second. Capacity checking, sequencing, and cascade recalculation are mechanical work that a planner does slowly and a scheduler does in a run. Deciding which overload to solve with overtime and which with a phone call is the part worth a planner's day.

EDGEBIC by User Solutions is built on that split. This post breaks down where planning hours actually go, which mechanism replaces each block, what the documented time-to-value looks like, and what stays firmly manual. It sits under the EDGEBIC results guide.

Where the Planner's Week Goes

Ask a planner running a spreadsheet system to account for a week and the answer usually splits four ways:

Three of those four rows are arithmetic. In most shops they consume the overwhelming majority of the week, which means the planner has the least time for the only part that needs a human. Planner hours are also a real cost line, and one of the easier ones to move: see manufacturing cost reduction for where it sits against the others.

The heritage record for compressing those three rows belongs to the User Solutions line that EDGEBIC succeeds: Homestead Furniture reduced scheduling time from 40 hours a week to 2. That is not a promise about your plant. It is evidence about what happens to the mechanical rows when a machine does them.

Block One: Stop Retyping Data

The first block is pure plumbing. Orders live in the ERP, routings live in a document, hours live on timecards, and somebody moves them by hand.

EDGEBIC takes master data through configurable import masks: Excel, CSV, or a database read, mapped column by column to products, work centers, routings, sales orders, and actuals. Schedules and dates go back out the same way. There is no certified connector for any named ERP, and that is the honest description: if your system can export a file, it can feed the scheduler, and the mapping is configured once rather than rebuilt each time.

The heritage evidence for how fast this piece can move: Plastilite completed a Fourth Shift integration in five days on the User Solutions line, a vendor-recommended integration built on exactly this export-and-import approach.

At the other end, actuals from the shop floor arrive through kiosk logging rather than a transcription step. Operators start and complete work; hours and pieces roll up per day automatically. Nobody types a timecard into a spreadsheet, which removes both the hours and the transcription errors.

Block Two: The Plan Is a Run, Not a Build

The second block is the one that gets described as "doing the schedule," and it is entirely mechanical: for every operation on every open order, find a machine, check the shift calendar, check the holidays and downtime, check what else is booked, place it, then cascade every downstream operation.

That is the scheduling run. It resolves capacity day by day, handles multi-shift spillover, respects instance counts and utilization percentages, and chains dependent operations in the correct order. What a planner produces in a day on a whiteboard, and can only produce approximately, the engine produces completely.

The sequencing part is worth separating out, because it is the piece humans do worst. In the documented paint booth case, three jobs sequenced by due date carry 330 minutes of changeover and overflow the shift; the same three sequenced light-before-dark carry 90 minutes and finish with three hours to spare. A planner can find that on three jobs. On forty jobs across twelve machines, nobody can, which is what the optimizer is for. It runs inside a time budget you pick (10, 30, or 60 seconds), returns a comparison rather than a change, and is clamped never worse than the plan you already have.

Block Three: Reacting Costs a Run, Not an Afternoon

The third block is the expensive one, because it recurs. Every disruption means redoing block two.

The documented breakdown case shows what replaces it. A mill fails Wednesday morning. The milling operation was planned for 31 hours with 10.5 already logged across Monday and Tuesday. The supervisor blocks that machine for the day, the planner reschedules the job, and the engine does the following without further input:

• Preserves the finished saw operation exactly as recorded
• Preserves the 10.5 logged hours on the mill operation
• Replans the outstanding 20.5 hours from Thursday, skipping the blocked Wednesday
• Cascades the grinder and the inspection behind the new mill end
• Records the change with its old and new dates in the audit log

Final completion moves from July 21 to July 23, against a due date of July 25. The manual equivalent is an afternoon of recalculation, and it produces an answer nobody fully trusts because nobody can verify a cascade by hand.

Two features make the reaction cheap rather than merely fast. Completed work is never moved, so a reschedule cannot damage history, and scoped scheduling modes let you touch one job or only new orders instead of rebuilding the plant. A reschedule you can run without fear is a reschedule you run when you need it rather than once a week.

Block Four: The Part That Should Get Longer

The judgement row is the one worth protecting, and a good outcome is that it grows.

What the planner reviews after a run: the red days in the capacity view, the Late Jobs list with its blocker hints, the anomaly checks flagging structural data problems, and the plan-versus-actual variance that says which routings have drifted. Each of these is a question with a number attached and a decision that only a human can make.

One smaller time saving hides here and adds up: every report column in EDGEBIC carries its own plain-language definition, so the meeting time normally spent arguing about what a column means and reconciling it against somebody's private spreadsheet mostly disappears. See why every column carries its own definition.

Setting Expectations Honestly

The planning cycle does not shorten on day one. It lengthens.

Loading products, work centers, shifts, calendars, and routings is real work with no shortcut. The first honest schedule usually exposes a backlog that the previous infinite-capacity plan was hiding, and that generates a round of uncomfortable conversations rather than a saving. Both of those are the diagnosis arriving, not the software failing.

The compression comes once the rhythm settles: schedule, execute, log actuals, reschedule, review the exceptions. By then the three mechanical blocks are machine work and the planner's week is mostly the fourth row.

The Rhythm That Replaces the Rebuild

What a compressed planning cycle looks like in practice is a short repeating loop rather than a weekly project.

Daily, a short pass. Run the new-orders mode so arrivals get scheduled without disturbing today's plan. Scan the next 14 days for red capacity days. Read the Late Jobs list. Act on the handful that need a decision.

Weekly, a longer pass. Run a wider reschedule of unstarted work, optionally with an optimization comparison, and accept it if the deltas justify the movement. Review the Reschedule History for a pattern. Check plan against actual on two or three work centers and correct any routing that has visibly drifted.

On an event, one scoped run. A breakdown or a rush order triggers a reschedule for the affected jobs only, then a read of the resulting exposure list.

The point of naming the rhythm is that it is bounded. Each element has a defined trigger and a defined output, which is what turns planning from an open-ended activity into a scheduled one. It also makes the planner's absence survivable, because a documented loop can be run by a second person for a week without the plan degrading.

What the Software Cannot Do Alone

It cannot clean your data. Routings, hours per unit, setup times, instance counts, and calendars have to be loaded and maintained by someone who knows the floor. A schedule computed over wrong data is fast and wrong.

It cannot automate the decisions. Whether to authorize a Saturday, delay a customer, or decline an order is judgement with commercial consequences. The software brings the numbers to that decision earlier and more completely, which is the actual saving.

It cannot fix upstream data entry. If orders arrive by email and get typed in by hand, that time stays spent regardless of how the scheduling works.

It cannot replace floor discipline. Actuals only flow if operators log them. A kiosk nobody uses recreates the transcription problem in a new place.

It cannot compress the first month. Setup takes what it takes, and any vendor promising otherwise is describing a demo rather than an implementation.

Want to see where your own planning week goes? Bring one week of your planner's calendar and a copy of the current spreadsheet to a demo, and we will run your real orders through a scheduling run while you watch.