- Home
- Blog
- ERP Integration (EDGEBIC)
- Infor Scheduling Gaps (And How EDGEBIC Fills Them)
Infor Scheduling Gaps (And How EDGEBIC Fills Them)
Infor is a strong system of record for materials, cost, and commitments, but many plants report that the day-to-day sequencing decision still happens in a spreadsheet, because the questions a planner answers each morning are finite capacity questions: which orders fit this week, what a rush order displaces, and when the constraint work center actually runs out of hours. The fix is not replacing Infor. It is adding a finite capacity layer beside it that reads the data the ERP already holds and hands executable dates back.
EDGEBIC by User Solutions is that layer. This post walks the gaps plants report, why they exist in any business-first ERP, and how each one is filled with a specific mechanism rather than a brochure claim. For the data-flow mechanics, the companion post is the complete Infor integration guide.
Why the gaps exist at all
An ERP's job is to be right about money and material: what was planned, what was committed, what it cost. A scheduler's job is to be right about time: what runs where, when, in what order, on which machine, with which operator. Those are different computational problems, and the second one grows hard fast. Sequencing 900 open orders across 60 work centers with shifts, changeovers, shared machines, and skill constraints is a constraint problem that a transactional data model was never designed to solve.
So the gap is structural rather than a defect. It shows up as a familiar pattern: dates come from lead-time offsets, the floor runs from a document one person maintains, and the two drift until a customer call reconciles them. The discipline distinction between planning material and scheduling capacity is standard in the operations management body of knowledge maintained by ASCM, and the general version of the story is in where ERP falls short on scheduling. Here is the Infor-plant version, gap by gap. If you are also evaluating Infor's own advanced planning tier, the head-to-head comparison is RMDB versus Infor APS.
Gap 1: dates that assume capacity exists
The first question, finite versus infinite capacity, decides whether a date means anything. Infinite-capacity logic stacks work into a week without asking whether the hours exist. Finite-capacity logic refuses to plan 60 hours onto a machine with 40 available and pushes the overflow to when capacity is real.
How EDGEBIC fills it: every schedule is finite capacity by construction. Work centers carry instance counts, shift calendars, efficiency, utilization caps, holidays, and downtime, and the engine resolves available hours day by day before it allocates anything. A job that does not fit this week lands where it fits, and the date it produces is one the floor can hit. When you want the just-in-time answer instead of the safe one, backward scheduling from the due date is a per-job choice.
Gap 2: work center capacity flattened into one number
Most ERP data models describe a work center as a capacity figure. A cell of three identical mills becomes one resource with a bigger number, which is right in a weekly total and wrong every day, because it will plan one job that occupies the whole cell where three could run side by side.
How EDGEBIC fills it: machine instances are first-class. A work center holding three mills means three simultaneous jobs, and the engine chooses between load balancing across instances and dedicating one machine per job per day when long changeovers make that the correct rule. Work center groups go further: a named pool of interchangeable machines that the engine re-shops on every reschedule, with a per-member efficiency factor so a slower older machine takes proportionally longer. The mechanics are in how EDGEBIC picks the best machine in a pool.
Gap 3: no sequence-dependent setup logic
One setup time per operation cannot express the reality that changeover cost depends on what ran immediately before. Plants running coatings, colors, alloys, or tooling families lose whole shifts to sequencing nobody can see, and no single column in any export can capture it.
How EDGEBIC fills it: a sequence-dependent setup matrix per work center, organized by setup families so you maintain dozens of entries rather than thousands of part-to-part pairs. The optimizer then sequences compatible work together and orders families to reduce total changeover, using mathematical optimization with a proven optimality gap plus a multi-run layer guaranteed never worse than the baseline schedule. Recovered setup time is capacity you have already paid for. The concept post is what a setup family is.
Gap 4: the constraint is invisible until it is late
Every plant has a constraint resource. Without finite loading, its overload appears only as a wave of late orders weeks later, by which point the decision window has closed. Finding and protecting the constraint is the highest-return move in scheduling, and the method is covered in production bottleneck identification.
How EDGEBIC fills it: flag the work center as a bottleneck and the engine anchors schedules around it, scheduling backward into the constraint and forward out of it with protective buffers, which is the Theory of Constraints pattern applied to a real routing. Capacity views then show the constraint's load by day, so an overloaded Tuesday is visible while there is still time to move something.
Gap 5: multi-site plans that cannot see each other
This one is specific to larger Infor estates. Sites that share machines, share operators, or hand work between plants are usually planned independently, because each site's data lives in its own view. The result is a plan per site and no plan for the network, so the transfer step between plants is either invisible or padded with a fixed allowance nobody revisits.
How EDGEBIC fills it: one database can hold every site's work centers, grouped by department, so the engine balances load across resources it can actually see. Inter-site transport rides on the routing step as transit days, which keeps the shipping week visible on the Gantt rather than hidden inside a longer operation. When two sites plan genuinely independently, separate databases keep each planner's screen focused, and the choice is a scheduling decision rather than a licensing one.
Gap 6: reschedule churn nobody trusts
The complaint that quietly kills adoption is not a missing feature, it is churn: a re-run that moves jobs already set up, restarts work that is halfway done, or produces a plan the floor recognizes as fiction. Once that happens twice, supervisors stop reading the system.
How EDGEBIC fills it: two guarantees, both structural. Completed work is never moved by a reschedule, because an operation with recorded actual start and end is historical fact and no mode or setting will shift it. And every scheduled job runs from a frozen snapshot of the routing it was planned with, so a mid-stream engineering change never silently rewires work in progress. On top of both, scheduling modes let you re-plan only new jobs and leave everything else untouched.
Gap 7: what-if answers that take an afternoon
Inserting one hot order displaces others, which displaces others. A human cannot recompute several hundred downstream operations, so the honest answer to "what slips?" is a guess, and the guess is usually optimistic.
How EDGEBIC fills it: rescheduling is a computed operation, and quote simulation lets you test a promise date before you make it. Insert the candidate order, run the scheduler, and read the displaced dates. The whole what-if loop is minutes, which changes who gets to ask the question: sales can ask it during the call rather than after it.
The integration question, answered honestly
The objection to any layer beside the ERP is the data bridge. This product line answered that decades ago, and the answer is deliberately unglamorous: reusable import masks that read the Excel, CSV, and database exports Infor already produces. You map columns once, and every later run is two clicks. Routings import in two passes so operation sequences wire themselves. Unit conversion (minutes to hours at 0.016667, hours per 100 pieces at 0.01) lives inside the mask. Every row reports Created, Updated, Reused, or Failed with a per-run log.
There is no certified connector, no middleware server, and nothing installed inside the ERP, which means nothing to re-certify at upgrade and nothing that cares which Infor product line a given site runs. The full architecture is on the ERP integration page, and the same method applied to other platforms is covered in the Microsoft Dynamics and Global Shop Solutions versions of this post.
This is not a new bet. User Solutions has integrated scheduling with ERPs this way since 1991, including Cummins scheduling across 33 locations from AS400-era data, BAE Systems, and a Fourth Shift integration at Plastilite Corporation that ran Monday to Friday with the ERP vendor itself recommending the add-on.
Three checks that predict how fast this pays off
Each takes minutes and none requires buying anything.
Routing coverage. Pull routings for your ten highest-volume parts. Do they carry an operation sequence, a work center, hours per unit, and a setup time? If yes, you can schedule on day one. Missing setup times are survivable: a zero-setup step simply contributes no changeover time, and the gap becomes visible in the results.
Machine truth. Count real machines per work center and compare with what the ERP records. Every center where the counts disagree is capacity you are currently misrepresenting in both directions.
Date honesty. Sample 20 recently shipped orders and compare promised dates with actual ship dates. That spread is your current scheduling error and becomes the baseline you measure against. Plants that skip this step cannot prove the improvement they can feel.
A 30-minute test
Export three files: work centers, routings for your five highest-volume parts, and this week's open orders. Bring them to a demo. Mapping the columns live takes minutes, and the first finite capacity schedule from your own data answers the only question that matters: do these dates look like your plant? The EDGEBIC product overview and the ERP scheduling add-on page cover the rest, and the field-level detail is in the Infor to EDGEBIC data mapping reference.
Because the daily sequencing decision is a constraint problem, not a record-keeping problem. An ERP is built to be right about materials, cost, and commitments; a scheduler is built to be right about which machine runs what, in what order, on which shift. When the second question is answered outside the system, the spreadsheet becomes the real schedule and the promised dates drift away from it. That is a category gap rather than a product flaw.
No. The standard pattern is a scheduling layer beside the ERP rather than instead of it. Infor stays the system of record for materials, procurement, costing, and financials. A finite capacity tool reads the items, work centers, routings, and open orders the ERP already holds, builds an executable schedule, and hands dates back. No ERP process or authorization has to be redesigned.
Through reusable import masks fed by the Excel or CSV exports your environment already produces. You map an export's columns to EDGEBIC fields once; every later run is two clicks, and each row reports back as Created, Updated, Reused, or Failed with a per-run log. There is no certified connector, no middleware, and nothing installed inside the ERP, so an upgrade has nothing to break.
Yes, because the interface is a file rather than an API. Infor spans several manufacturing product lines and a group of plants often runs more than one, especially after acquisitions. Each site only has to produce four exports to Excel or CSV, and the same import masks read them. There is no product-line qualification step and no version matrix to maintain.
Expert Q&A: Deep Dive
Q: We run Infor at four sites, the schedule is technically in the ERP, and every plant manager still keeps a private spreadsheet. What would actually be different?
A: Three things become computed instead of estimated. First, capacity: every open order loads against the actual shift hours and machine counts of every work center, so an overloaded week shows as a number rather than as late jobs a month later. Second, sequence: with a setup matrix in place the engine orders compatible work together, which returns changeover hours you are currently paying for. Third, cascade math: inserting a rush order and pressing reschedule recomputes every downstream operation with routing logic intact, while operations that already have recorded actuals are preserved exactly. The four private spreadsheets lose their reason to exist because the system now answers the question each of them was invented to answer.
Q: One of our sites runs three identical grinders that the ERP records as one work center with a bigger capacity number. Does that really change the schedule that much?
A: It changes it by a factor. A work center modeled as one resource with a tripled capacity number can look correct in a weekly total while being wrong every single day, because it will happily plan one job that occupies the whole center when three jobs could physically run side by side. EDGEBIC models the count of identical machines as instances, so three grinders means three simultaneous jobs, with the engine either load balancing across them or dedicating one machine per job per day when changeovers make that the right rule. On a constraint work center, that difference typically shows up as several days of apparent lead time that were never real.
Frequently Asked Questions
Ready to Transform Your Production Scheduling?
User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.

User Solutions Team
Manufacturing Software Experts
User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.
Share this article
Related Articles
Connecting EDGEBIC to Your ERP Database With a SQL Source
How to point a scheduled EDGEBIC integration at a read-only ERP query instead of a file: testing the connection, previewing columns, checking the mask fits, and the stored-password rule that catches most teams out.
EDGEBIC ERP Integration: The Complete Guide
How EDGEBIC integrates with any ERP: eight import masks, three source options, a documented data mapping, and the weekly rhythm that keeps a finite capacity schedule current.
Closing ERP Work Orders That EDGEBIC Still Thinks Are Open
Your ERP closing a work order is invisible to EDGEBIC. There is no status column on the order mask, and a job whose every step is done is not closed automatically. Here is the closing pass that keeps your numbers honest.
