Migrating Operators and Skills to EDGEBIC

Migrating operators and skills to EDGEBIC is done entirely in the interface, because operators, skills, certifications, rosters and time off are not import entity types. In EDGEBIC by User Solutions you build them in dependency order, skills first, then operators, then certifications, then rosters and time off, and only then set a Required Skill on the routing steps that need one. It is a smaller job than a parts migration, and the useful discipline is to model only the labor constraints that genuinely shape your plan.

Decide what is actually a constraint

The temptation on arriving at an operator model is to enter everyone. Resist it during a migration. The value comes from the places where a person, not a machine, decides whether work can run. In most shops that is a short list: a welding process only some people are certified for, a regulated inspection with signed-off inspectors, or the one setter who can run a particular machine.

Steps that require no particular skill can stay unmodeled, and they will plan exactly as they do today. That keeps this part of the migration proportional, and it means the constraints you do enter are ones the planners will recognize as real.

Nothing here rides on an import mask

Worth stating plainly, because it changes how you plan the work.

There is no bulk load to prepare, so there is also no mask to build and no column mapping to get wrong. What you need instead is a decision list and an afternoon, ideally after work centers and shifts are loaded and the plant already schedules.

Build in this order

1. Skills. Create the catalog first. Certification checklists draw from it, so an empty catalog means nothing to tick.

2. Operators. Add each person with a display name and a required badge or payroll code. The code is the field to map from your old records, since it is the stable identifier your HR or payroll list already uses.

3. Certifications. Select an operator, open the Skills sub-tab, and add skills from a checklist. Each resulting row carries the details worth transcribing carefully:

4. Rosters. On the Roster sub-tab, add a shift and tick the weekdays the person works it. Add further rows if somebody rotates between shifts.

5. Time off. On the Time Off sub-tab, enter known ranges. Both the start and end days are inclusive, which is the detail people get wrong when transcribing a leave calendar.

6. Required skills on steps. Last, on the routing step, set Required Skill, set the operator attention value for how much of a person the running machine occupies, and optionally pin a named operator. Do this only after the certifications exist, or a step will ask for a skill nobody holds.

The expiry dates are the point

If your certifications currently live on a wall chart or a spreadsheet, the expiry column is the part that was doing invisible work. A lapsed card is normally discovered on the floor, on the morning the job was meant to run.

Once migrated, an expired certification simply stops qualifying that person at the next scheduling run, so the constraint arrives in the plan rather than in a conversation. That makes transcribing the dates accurately more valuable than transcribing the levels, which are informational in this release. Pair this with skill expiry and recertification when you train the planners.

Prove it works with one deliberate test

An entered certification is not a demonstrated constraint. Run this check before you tell anyone the model is live.

1. Pick a routing step with a Required Skill where exactly one person is certified.
2. Confirm that person's roster puts them on shift.
3. Enter a day of time off for them and reschedule.
4. Confirm the step moves off that day instead of planning as though anyone could run it.

If it does not move, work back down the chain: is the certification Active and unexpired, does the roster cover that shift, and is the Required Skill actually set on the step. This is the labor equivalent of the one-per-day test in migrating capacity and utilization settings, and it is worth doing once per skill you care about.

Leavers, joiners and history

Use Active rather than deletion. Unchecking Active on an operator removes the person from all future scheduling while keeping them for history, which matters when your migration also brought in open jobs and actuals: the record of who did what stays readable, and the plan stops offering somebody who has left.

For the migration itself, the cleanest rule is to enter current staff only. A departed operator contributes nothing to a forward plan, and the history of their work travels with the imported actuals rather than with an operator record.

The takeaway

Migrating operators and skills to EDGEBIC means building them by hand in the right order, skills, then operators with their badge codes, then certifications with accurate expiry dates, then rosters and time off, and finally Required Skill on the routing steps that genuinely need one. Model only the labor that constrains your plan, transcribe expiry dates carefully because they turn a lapsed card into a planning fact, prove one skill with a deliberate time-off test, and deactivate rather than delete when people leave. See the platform on the EDGEBIC overview, the upgrade path on the RMDB to EDGEBIC guide, and pair this with how operator skills gate work center assignment and training your RMDB team on EDGEBIC.