EDGEBIC + Fourth Shift Integration FAQ: 12 Questions Sites Ask First

These are the questions long-running Fourth Shift sites ask first, answered without hedging: any installation that can export a file can integrate, nothing is installed inside the ERP, legacy exports with no heading row are handled by design, and the scheduling model stays yours even if the ERP changes later. Every answer stands alone.

EDGEBIC by User Solutions is the current generation of the scheduling line whose Fourth Shift work is the best documented in the family. The end-to-end version is the complete Fourth Shift integration guide, and the field-level detail is in the Fourth Shift mapping reference.

Will EDGEBIC work with our version of Fourth Shift?

If your installation can produce an Excel file or a delimited text file, it works. There is no version matrix and no supported-release list, because the integration reads exports rather than calling an API. Legacy export habits are handled by mask settings rather than by preparation work: a file with no heading row maps by column position, quoted text values have their own option, and comma, semicolon, tab, or space delimiters are all supported. Extra columns you do not need are simply left unmapped and ignored.

Is EDGEBIC a native or certified Fourth Shift connector?

No, and the honest version of that answer is worth stating clearly. EDGEBIC integrates through reusable import masks, the same way it integrates with every ERP. What belongs to the Fourth Shift story specifically is heritage: the ERP vendor recommended the User Solutions scheduler to its own customer at Plastilite Corporation, and that integration was completed in one working week. That proof belongs to the earlier Resource Manager DB generation and is claimed as exactly that. What EDGEBIC inherits is the architecture, now feeding a much stronger engine.

Is a file-based integration risky for a system we depend on?

It is the low-risk option, precisely because nothing touches the ERP. No installation inside Fourth Shift, no schema change, no integration account, no service writing into it. Exports are read-only outputs your team already produces. The worst outcome of a bad import is a bad EDGEBIC schedule, which you fix by correcting the file and running again. For an install that has been stable for a decade, that asymmetry is worth more than automation.

Is the 5-day figure realistic for us?

The 5-day figure is the documented Plastilite case, not a blanket guarantee, and it deserves that framing every time it is quoted. What repeats is the method rather than the exact duration: export what the ERP already holds, map the columns once, import in dependency order, schedule, then tune. Sites with reasonably clean routings routinely see a first finite capacity schedule from real data in the first session, and spend the rest of the week making it match the floor. The full account is in the 5-day integration story.

Our routings live partly in the ERP and partly in people's heads. Do we need a data project first?

No. Integrate first and clean as you go. Routings carrying only operation names, sequence numbers, and rough hours still produce a first schedule you can criticize, and criticism is what turns vague data debt into a specific defect list. A wrong hours-per-unit shows up as a job finishing implausibly early; a missing setup shows up as a machine that appears to change over for free. Because a routing re-import wipes and recreates that product's steps, each corrected file replaces the last and version drift never accumulates.

What if our export has no column headings?

Turn off the header-present option on the mask and map each field by column position instead. Older scheduled extracts frequently emit raw delimited data with no header row, and positional mapping exists for that case. The positions are stored on the mask permanently, so the weekly routine is identical to a headed file: pick the mask, run it, read the counts.

Our times are in minutes. Does someone convert them every week?

No. Set a conversion factor on that mask column once (0.016667 for minutes to hours, 0.000278 for seconds) and the multiplication happens during import on every run. A 30-minute setup cell lands as 0.5 hours automatically, and the per-run log records every row if you want to audit it. Eliminating weekly hand-reshaping is the reason masks exist at all.

Can an import disturb jobs already running?

No, for two independent reasons. Every scheduled job carries a frozen snapshot of the routing it was planned with, so re-importing a corrected routing affects future jobs and leaves work in progress alone. And recorded work is never moved: an operation with an actual start and an actual end is historical fact that no run, mode, or setting will shift. Imports also never schedule anything, so nothing moves on the Gantt until you press the button.

Our machines are not interchangeable because of tooling. Does that model?

Yes, in two ways depending on the shop. Where a family of machines can run the same work at different speeds, put them in a work center group with per-member efficiency factors: the scheduler compares real finish times rather than rotating work around the pool, and it re-shops the pool on every reschedule for operations that have not started. Where only certain machines can physically run a part, express that as alternates on the routing step, or as a group containing only the capable machines. This is the same modeling problem the Plastilite case was built around: presses holding different combinations of molds.

What if we replace Fourth Shift in a few years?

You re-map the masks and keep everything else. The scheduling model lives in EDGEBIC rather than in the ERP: work centers and their capacity, calendars, routings, the setup matrix, machine pools, operator skills, and the schedule history. A new ERP means new export files and one mapping session, not a new scheduling project. That portability is a direct side effect of never having built an ERP-specific connector, which is worth remembering when a connector sounds more sophisticated than a file.

Who runs it, and on what?

The planner runs it, in about twenty minutes a morning, with no IT involvement after the initial setup. There is no server integration to monitor and no scheduled job that can fail silently. EDGEBIC runs on a local database out of the box, and sites that prefer a managed server can run it against SQL Server instead: the daily routine is identical either way. The daily Fourth Shift and EDGEBIC scheduling workflow walks the loop.

What do we get that the ERP module never offered?

Finite capacity across real shifts and real machine counts, alternates and parallel work centers, work center groups that re-shop on every reschedule, a sequence-dependent setup matrix, operator skills, lot streaming with transfer batches, backward scheduling per job for just-in-time work, Theory of Constraints anchoring around the bottleneck, and mathematical optimization with a proven optimality gap. The engine is mapped on the EDGEBIC product overview, and the ERP integration architecture shows where the boundary between ERP facts and scheduling model sits. For how a site gets started, read a Fourth Shift site's first week with EDGEBIC, or bring your own export to a demo and settle it with your data.