Should You Trust Your ERP's Standard Times?

Import your ERP's standard times as they are, schedule with them, then compare planned hours against actual hours and correct only the standards that are both wrong and consequential. Re-timing before the first import delays the project by months and usually re-times the wrong operations, because the standards that matter are the ones at busy work centers, not the ones people have opinions about.

EDGEBIC by User Solutions schedules with the hours you supply and records what actually happened when you import labor transactions, which makes the comparison available per job and per work center. This post is the method for using that comparison, plus the checks worth running before any actuals exist.

Why the instinct to re-time first is wrong

Three reasons, and the third is the one that changes minds.

It is unbounded. A shop with 400 routings and 1,600 operations cannot re-time in a quarter, and the project stalls waiting for something that was never going to finish.

It optimizes the wrong things. People re-time the operations they think about, which are the visible ones. The operations that matter are the ones at the work centers that constrain the plant, and those two sets overlap less than expected.

Wrong standards are still useful. A schedule built on imperfect standards is dramatically better than no schedule, because most of the value comes from sequencing against real capacity rather than from perfect durations. A center loaded to 160 percent next Thursday is loaded to 160 percent whether the underlying standards are 10 percent off or not.

The loud errors, findable before any actuals

Four failures are visible from arithmetic alone, and all four are common in exports that have never been used for finite scheduling.

A standard of zero. An operation with zero hours imports without complaint and schedules as a zero duration step. It is not rejected because zero is a legitimate value in some models, but it is almost never what anyone intended. Sort the imported routing by hours ascending and look at the bottom.

A units error. The most damaging and the least visible. A standard time column that carries minutes where the model expects hours makes every operation sixty times longer, and nothing about the file looks wrong. A conversion factor on that column fixes it: minutes to hours is 0.016667, seconds to hours 0.000278. The mechanism is in what a conversion factor is.

A per-lot standard read as per-piece. Same column, same units, entirely different meaning. A standard quoted per lot of 100 needs 0.01 to become per piece, and a schedule built on the wrong reading is off by two orders of magnitude while looking completely plausible.

Setup folded into run time. When the ERP holds one combined number, the setup portion scales with quantity, so a 1.5 hour setup on an order of 500 becomes 750 hours of phantom work. Splitting them is covered in handling combined setup and run time from your ERP.

The check that finds all four is the same one: take a part whose operations you know and compute what an order should total. Three operations at 0.25, 0.40, and 0.10 hours per piece with 1.5 hours of setup on the first, on an order of 200 pieces, totals (0.25 + 0.40 + 0.10) x 200 = 150 run hours plus 1.5 setup, so 151.5. If the import produces 9,090 you are in minutes. If it produces roughly 2.5 a per-lot standard is being read as per-piece.

The quiet errors, found with actuals

Once labor hours flow in, the comparison does the work. A job's planned hours sit beside its actual hours, and a pattern across many jobs at one work center is the signal worth acting on.

What to look for, in order:

The fourth row deserves care. Standards are sometimes padded on purpose, to cover an inspection nobody recorded or a fixture change that happens half the time. Cutting the padding without finding out why it exists reproduces the original problem. Ask the supervisor before changing the number.

Getting the actuals in is a mask like any other. It matches on job, work center, and date, and re-importing a corrected file overwrites the dates it carries, so a fixed timesheet can be re-run safely. The path is in importing ERP labor transactions as actuals.

Fix by impact, not by size of error

This is the whole discipline in one line. A standard 30 percent wrong at a work center running at 40 percent load costs almost nothing, because the slack absorbs it. The same error at the center that constrains the plant moves every promise date behind it.

So sort the correction list by where the load actually is:

1. The two or three centers with the highest utilization. Fix those standards first, and stop when they are close.
2. Operations that appear on many routings. One correction propagates widely.
3. Everything else, opportunistically. As jobs run and the comparison keeps producing evidence.

Most shops find a small number of operations carry most of the total error. That turns a re-timing project into about a week of targeted work, which is a completely different proposition from re-timing 1,600 operations.

What not to do

Do not apply a blanket factor. Drift is not uniform, so scaling every standard by 0.8 makes most routings worse while improving a few, and it destroys your ability to tell which is which.

Do not change standards in two places. Decide whether the ERP or the schedule owns the number, and keep it there. If the ERP owns it, corrections go into the ERP and arrive on the next routing import. If the schedule owns it, the routing import should stop overwriting hours. Both are workable and mixing them is not: see choosing the system of record for each scheduling field.

Do not wait for perfect standards before scheduling. The comparison that tells you which standards are wrong only exists once you are scheduling and collecting actuals against a plan.

The honest limit

The application does not re-estimate standards for you. It schedules with what you give it, records what happened, and puts the two side by side. The judgment about what a gap means, whether a wrong standard, an unrecorded second setup, or a training issue, stays with the people who know the shop. That is the right place for it, and it is also why the correction list stays short: a human sorting by impact stops at the operations that matter, where an automated pass would not.

Bring a routing export and, if you have them, one month of labor hours to a working session. Watching planned and actual line up for a job you know is the fastest way to see which of your standards are worth a second look. The import layer is on the EDGEBIC ERP integration page, and the engine those hours drive is on the EDGEBIC product overview.