Migrating Your Work Center and Shift Definitions to EDGEBIC

You migrate work centers, shifts, and plant holidays to EDGEBIC through import masks, attach the calendars in the app, and verify capacity against RMDB before trusting a schedule. In EDGEBIC by User Solutions, work centers carry their identity, capacity, rates, and instance counts across through a saved mask. Shifts and plant holidays have masks of their own, though with only a few patterns per plant, keying them in is often the faster route and gives you a natural moment to confirm each one. The rule that ties it together is simple: verify capacity before you compare a single date.

Two kinds of data, and a choice about the second

Work centers and shifts are both about capacity, and both can be imported. The difference is one of volume, which changes what is worth automating.

Work centers are numerous and detailed. A plant can have dozens, each with a name, a capacity, a rate, an instance count, and a set of behavior flags. That is real data volume, so it migrates the way all bulk data does in the User Solutions line: export to Excel or CSV, map columns once in an import mask, and import. This is the same mechanism covered for routings in moving your RMDB routings into EDGEBIC, applied to work centers.

Shifts and holidays are few. Both have their own import masks, so you can carry them across as data if you prefer, but most plants run a handful of shift patterns and one holiday list, and keying those in takes minutes. Doing it by hand has a hidden benefit: it forces you to confirm each shift and holiday against what RMDB assumed, which is exactly the check you need anyway. Either route is legitimate. What you cannot import is the attachment of a calendar to a particular work center, which is set in the app whichever way the definitions arrive.

Migrating the work centers

Export your work centers and build one import mask that maps your columns to EDGEBIC's fields. The fields worth mapping carefully are the ones that drive capacity:

• Name. The identifier that routings and schedules link to. Keep it identical to what your routing export uses.
• Capacity and rate. How much the work center can do, in hours or pieces, and how fast.
• Instances. The number of identical machines. A work center with three of the same mill has three instances, and the scheduler places work across them.
• Efficiency. A factor that stretches or compresses run times to reflect real throughput.

Map these once, save the mask, and import. As with every entity, re-running the mask after a data fix is a single click, described in exporting your RMDB data to Excel for EDGEBIC.

A few behavior settings are not spreadsheet columns but flags you set on the work center in EDGEBIC after the import. The two that matter most are the bottleneck flag, which turns on Theory of Constraints anchor scheduling around that work center, and the one-job-per-day behavior for machines that can only run a single job per instance per day. These take seconds to set and are worth doing early.

Bringing across shifts, holidays, and calendars

In EDGEBIC, a shift is a named pattern of daily hours: a Day Shift that runs 08:00 to 16:00 with a break, for example, defined per day of the week. Bring your shift patterns across to match RMDB, either through the shift import mask or by keying them in, then attach them to the work centers that run them, using global shifts for the common case and per-work-center overrides where a machine keeps different hours.

Holidays and maintenance work the same way, with one caveat about where they go. Load or enter the plant holiday list, then use per-day capacity overrides wherever a specific machine or a single shift is out while the rest of the plant runs, since the current release has no per-work-center holiday or downtime screen. The result is a calendar per work center that says exactly when it is available.

However the definitions arrive, this is the moment to get capacity right. Every hour EDGEBIC schedules against comes from these definitions, so a missing holiday or a wrong shift length is the single most common source of a date that does not match RMDB.

Verify capacity before you compare dates

Here is the rule that saves migrations: verify capacity before you read a single schedule date. Effective capacity is shift hours times instances, so either one being off shifts every downstream date. If you compare EDGEBIC's dates to RMDB's before confirming capacity, you will chase date differences that are really just a calendar gap.

So the order is: set the shifts, holidays, and per-work-center calendars, then check EDGEBIC's daily and weekly capacity figures against what your current system shows, work center by work center. Reconcile any difference at the capacity level first. Only then does a date comparison mean anything. This is why the capacity check is a required step in planning an EDGEBIC pilot on one cell, and it is the difference between finite capacity scheduling that you trust and one you second-guess. The underlying idea is covered in finite versus infinite capacity scheduling.

A worked example

A shop migrates its CNC cell: five work centers, two of them with multiple instances, and one clear bottleneck at the mill.

1. Import work centers. The planner exports the five work centers, maps the name, capacity, rate, and instance columns in one mask, and imports. The mill comes in with three instances.
2. Set flags. They mark the mill as the bottleneck so it anchors the schedule, and leave the others as standard.
3. Build the calendar. They key in the single Day Shift pattern rather than building a mask for one row, attach it to the five work centers, add the plant holiday list, and zero the grinder for two days with per-day capacity overrides for planned maintenance.
4. Verify capacity. They compare EDGEBIC's weekly available hours per work center against RMDB. The mill matches. The grinder is short by two shifts, which traces to the maintenance overrides, exactly as intended. One number is off on a second work center, and they correct an instance count.
5. Schedule and compare. Now, with capacity confirmed, they schedule the cell and compare dates. The differences that remain are real, not calendar noise.

Capacity was verified before any date was read, so the date comparison was clean.

Common pitfalls

• Name drift. Routings link to work centers by name. Keep work center names identical between your work center file and your routing file, or the steps will not resolve.
• Missing instances. A work center imported with one instance when it has three reports a third of its real capacity. Confirm instance counts against the floor.
• Forgotten holidays. A single missing holiday moves every date after it. Set the full holiday list before comparing dates.
• Efficiency assumptions. If RMDB modeled a work center at reduced efficiency, reproduce that in EDGEBIC where the engine reads it: a factor on that machine's row in a work center group, or an honest per-piece time on the routing step.

The takeaway

Migrating work centers to EDGEBIC is mask-driven for the work centers, and for shifts and plant holidays too if you want it to be, since both have masks of their own. Map the work center name, capacity, rate, and instance columns once, set the bottleneck and behavior flags in the app, bring across your shift patterns and holiday list, and then verify capacity against RMDB before you read a single date. Get capacity right first and every date comparison after it is meaningful. See the platform in full on the EDGEBIC overview, read the whole path on the RMDB to EDGEBIC guide, and when the calendars are set, move on to migrating your open jobs and actuals to EDGEBIC.