The Data You Need Before You Schedule Anything

Scheduling software schedules exactly what you give it, which makes the state of your routings, capacities and calendars the single strongest predictor of whether the first schedule is believed or dismissed. A spreadsheet forgives a missing setup time because the human reading it fills the gap from memory. An engine does not. This guide lists the data required, in the dependency order it must be entered, with an accuracy test for each item and an honest estimate of the work involved.

This is written for EDGEBIC by User Solutions, and it applies before you buy anything: most of the audit below is worth doing during evaluation, because it tells you what your real timeline is.

The Dependency Order (and Why It Matters)

Each layer references the one above it. Entering out of order produces a first week spent on validation errors instead of scheduling.

Units of measure
   ↓
Customers          Shift calendars
   ↓                    ↓
Products          Work centers
   ↓                    ↓
        Routings (products x work centers)
                    ↓
             Open orders

A product cannot exist without a unit of measure. A routing step cannot reference a work center that has not been created. An order cannot reference a product that does not exist. This is not bureaucracy; it is the reason a greenfield setup takes a predictable shape. The greenfield setup walkthrough traces the whole sequence with real values.

Layer 1: Units of Measure

What it is: each, pounds, feet, litres. Every product needs one.

Effort: minutes.

Accuracy test: does the list match what your orders and routings actually use? A shop that quotes in feet and routes in pieces needs both, and needs to be deliberate about which is which.

Layer 2: Customers

What it is: name, code, contact. Used for prioritization and for reporting delivery performance by account.

Effort: an export from your existing system, usually.

Accuracy test: do you have the customers you actively ship to? Historical accounts can wait.

Layer 3: Shift Calendars

What it is: the working pattern. Start and end times per day of week, entered net of breaks, plus your plant holidays.

Effort: an hour if your shift pattern is simple, longer if departments differ.

Why it matters more than people expect: capacity is computed from it directly. A shift running 08:00 to 16:30 that stops 30 minutes for a break is entered as 8.0 hours. If that machine also gives up an hour to maintenance every Wednesday, Wednesday needs to read 7.0. That one hour is 52 hours a year per machine of capacity that either exists or does not, depending on whether you told the calendar about it.

Worth knowing before you start collecting: there is no downtime record to create in the current release, and no weekly recurrence anywhere in the calendar. So standing maintenance is not a separate list you enter; it is hours you decline to claim in the shift definition, or a per-day capacity override on the specific dates it happens. Collect the numbers all the same, because they have to land somewhere. Just plan to express them as shift hours rather than as a maintenance schedule.

Accuracy test: three questions.

1. Is every hour of standing maintenance and cleandown already netted out of the shift hours you are about to enter? Preventive maintenance, weekly cleandowns, safety meetings.
2. Are plant holidays entered for the next twelve months?
3. Do work centers that run a different pattern from the plant default have their own calendar?

See the calendar setup guide and shift and calendar mistakes.

Layer 4: Work Centers

What it is: each machine or station that consumes time, with three settings that drive every capacity number downstream. This is also where one-off closures live: a machine's teardown day or a de-rated week is a per-day capacity override on that work center, not a calendar record.

The capacity arithmetic they feed:

net hours = shift gross - breaks - downtime - partial holiday
capacity  = net hours x instances x utilization %

Work one through. A CNC center runs 08:00 to 16:30, 30-minute break, one hour of Wednesday maintenance, two machines, 85% utilization. Net is 7.0 hours. Times two instances is 14.0. Times 85% is 11.9 hours of real Wednesday capacity. A ten-hour job fits; a thirteen-hour job spills to Thursday. That arithmetic assumes hours are pooled and divisible, which is not true of a furnace or a paint booth, where one load owns the chamber for the day.

Effort: an hour of configuration, plus a floor walk to verify counts.

Accuracy test: walk the floor and count machines. Do not read the asset register. Then recompute two work centers by hand and compare to the configured value. See how to set up work centers and how to configure instances and utilization.

If several machines are genuinely interchangeable, they can be grouped so the schedule picks the best available member rather than pinning work to one. See how to create work center groups.

Layer 5: Products

What it is: the items you make and the materials you consume, each with a unit of measure and a type.

Effort: usually an export.

Accuracy test: is the active list actually active? Most shops import several thousand products and schedule against forty. Dead items add noise to every search and every report.

See how to set up products.

Layer 6: Routings (the Hard One)

What it is: the sequence of operations each product goes through, with hours per piece, setup time, and any queue or transit time between steps.

This layer is where implementations succeed or stall, so it gets the most detail.

The four fields that matter most

Operation sequence. Which step follows which, and which steps can run in parallel. A routing that says three steps when the shop runs four produces a schedule that is short by one operation's duration on every job. Products built from sub-assemblies add a level to this, and exploding those feeder jobs into the same plan is what stops a parent job from looking smaller than it is.

Hours per piece. The run time. A job's duration is computed as setup time plus hours per piece times quantity, so an error here scales with order size. A 0.20 standard against a 0.30 reality is invisible on a job of ten and half a day wrong on a job of five hundred.

Setup time. Discussed below, because it deserves its own treatment.

Queue and transit time. The waiting between operations, and any physical movement between locations. Setting these too generously stretches every job; setting them to zero produces schedules the floor cannot execute. See queue and transit times explained.

The accuracy test that actually works

Print twenty routings. Take them to the people who run those jobs. Read the numbers out loud and ask whether they are right.

You will get three kinds of answer. "That's about right" (fine). "That's never been right, it takes twice that" (fix it, and note that the standard has been wrong for years and probably drove your quoting too). "We don't do that step any more" (fix it; a phantom step consumes phantom capacity every time it schedules).

One day of this work is the highest-return day in the entire project.

Setup time deserves its own paragraph

A flat setup allowance per operation is enough to start. What you cannot do is skip the question, because setup is frequently the largest block of work nobody planned.

If your changeover time depends on what ran before, capturing that from-to relationship is the most valuable data collection you will do. In EDGEBIC's documented paint booth example, going light to dark costs 60 minutes and going dark back to light costs 240 minutes for a full solvent purge. A flat 30-minute allowance charges 90 minutes across three jobs where the floor lives through 510. Load the true times and the plan becomes honest; sequence like to like and the same three jobs drop from 330 changeover minutes to 90.

You do not need a value for every product pair. Products that behave the same way group into setup families, and the matrix is built between families rather than between individual items, which keeps it maintainable at hundreds of products. See what a setup family is and how to build a setup matrix.

Effort for the routing layer: this is the real project. Budget by product family rather than by total item count, and expect the first family to take longest.

Layer 7: Open Orders

What it is: what is due, in what quantity, by when, for whom.

Effort: an export, usually daily or weekly thereafter.

Accuracy test: are the due dates real, or are they defaults nobody maintains? A schedule sequenced against fictional due dates optimizes the wrong thing with great precision.

See how sales orders drive demand.

Getting It In

Data arrives through configurable import masks for Excel, CSV or database sources. You map each source column onto a target field once, save the mapping under a name, and reuse it for every subsequent import. Masks exist for products, work centers, customers, sales orders, routings, actuals, receipts and resources.

Two details save time. A conversion factor handles the classic mismatch where your source file stores setup time in minutes while the schedule stores hours. And the routing import runs in two passes, so the sequencing links between operations resolve after all rows are read rather than requiring your file to be in a particular order. Each run writes a log recording the outcome of every row (created, updated, reused, skipped or failed), which is what turns a failed import from a mystery into a list.

There is no certified turnkey connector to any named ERP. What exists is an import and export path that works with any system able to produce a file, which in the User Solutions record has included Fourth Shift, Macola and AS400 environments across the product line's history. See import masks explained and how routings import in two passes.

The Readiness Scorecard

Score each row before committing to a go-live date.

Any row scored "not ready" is project work, and putting it on the plan honestly is what makes a timeline credible. The documented 5-day Plastilite integration in the User Solutions record happened because clean exports were available; your pace depends on this scorecard rather than on the software. See the real risks in a scheduling implementation.

Start Here

The two highest-value pre-purchase tasks are the twenty-routing audit and two weeks of changeover logging at your worst machine. Both are free, both take about a day of attention, and together they tell you your real timeline and the size of your opportunity. How much capacity are you already losing gives the arithmetic for the second one.

When you have both, contact US and bring them. We will load your real routings into EDGEBIC and show you the schedule your own data produces, which is a more useful demo than any prepared one. For the outcomes that data quality protects, see the measurable results guide.