An EDGEBIC migration needs six roles filled, and only two of them are technical: a sponsor, a project lead, data owners, an extract owner, a validating planner, and machine owners. In EDGEBIC by User Solutions the import masks are built by mapping columns in the interface rather than by writing code, so the center of gravity sits with the people who understand the data rather than with developers. In a small shop three people can cover all six responsibilities, provided the responsibilities themselves are not skipped.
The six roles
| Role | Owns | Typically |
|---|---|---|
| Sponsor | Scope decisions and the go or no-go call | Owner, plant manager, operations director |
| Project lead | The sequence, the schedule, the open-questions list | Lead planner or scheduler |
| Data owners | One per master file: items, customers, routings | Planner, engineering, sales admin |
| Extract owner | Producing files out of the current system | IT, ERP administrator, or the person who knows the database |
| Validating planner | Deciding whether the new plan is right | The most experienced planner |
| Machine owners | The configuration no file contains | Setters, supervisors, machine operators |
Sponsor
The sponsor exists to settle arguments quickly. Migrations stall on scope questions that are not technical at all: whether to bring across dormant part numbers, whether the pilot cell is the right one, whether a routing that nobody trusts gets cleaned up now or later. Someone needs the authority to decide in a day rather than a fortnight.
The sponsor also owns the go-live call, which should be a judgment about trust rather than a date. That is the standard set out in completing the cutover.
Project lead
The lead owns the sequence: which imports run in which order, what gets verified after each, and what is deliberately deferred to after cutover. A phased plan is what keeps this manageable, and a phased migration plan plus a week by week timeline are the shapes to work from.
This is a planner's job more often than a project manager's, because most of the daily decisions require knowing what the data means.
Data owners
Assign one named owner per master file rather than one owner for all data. Items, customers and routings usually live with different people, and the questions that arise are specific: which unit of measure is right, whether two customer records are the same customer, whether a routing step's hours are per piece or per batch.
The owner's real job is deciding what is correct, not typing. That is why the cleanup in a data quality audit and cleaning your data before importing belongs to them: a migration is the one moment when fixing a long-standing data error is cheap.
Extract owner
Somebody has to get the data out of the system you are leaving, as xlsx, csv, txt or tsv. That is the technical half of the work, and it is bounded: a set of extracts, produced once for the load and then repeatably if you keep the old system running in parallel.
Be specific about what you are asking for. The routing extract in particular has a constraint worth passing on: all steps for one end product must arrive in a single file, because a re-import replaces that product's routing per run. Grouping the extract by end product is easier than fixing it later.
Validating planner
This is the role most often missing, and the most important one. Loading data successfully proves the files parsed. It does not prove the plan is right.
The validating planner takes a known set of orders, schedules them, and compares the result against what the plant would actually do: the dates, and just as importantly the work center loading. Capacity errors are the ones that hide, which is why the check is load first and dates second, exactly as migrating capacity and utilization settings and validating a migrated schedule describe.
Give this person the authority to say not yet. A migration that goes live on a plan nobody senior has vouched for tends to end with the floor running from a printed sheet.
Machine owners
Several kinds of configuration are not in any file, because the old system never held them:
- Which machines genuinely form an interchangeable pool, and how much slower one is for a class of work.
- What the real changeover time is between two product families, in each direction.
- Which certifications actually gate which operations, and whose are due to expire.
That knowledge is collected by asking named people about named machines. Schedule those conversations after the bulk load, so answers can be tested against a working plan rather than accepted on faith. This is the input for migrating work center groups, migrating your setup matrix and migrating operators and skills, none of which arrive on an import mask.
Two supporting tasks worth naming
Install and accounts. Someone handles the installation and the datasource choice before any data moves, per preparing your install, and sets up users. Permissions come from roles, so the decision to make is which roles exist and who belongs to them, not which checkboxes each individual gets.
Training. Plan it as part of the migration rather than after it, aimed at the planners who will live in the system daily. Training your RMDB team covers the shape.
The takeaway
Staff an EDGEBIC migration with a sponsor who settles scope, a project lead who owns the sequence, a named data owner per master file, an extract owner to produce the files, a validating planner with the authority to say not yet, and machine owners who supply the configuration no export contains. Small shops fill all six with three people, which is fine as long as loading and validating stay separate steps rather than one action. See the platform on the EDGEBIC overview, the upgrade path on the RMDB to EDGEBIC guide, and pair this with an EDGEBIC migration checklist and planning an EDGEBIC pilot on one cell.
Expert Q&A: Deep Dive
Q: We are a twenty-person shop. Do we really need six roles?
A: You need the six responsibilities, not six people. In a shop that size it commonly collapses to three. The owner or plant manager is the sponsor and settles scope questions in the moment they arise, which is a real advantage over a large organization. The lead planner runs the project, owns the routing data, builds the masks and validates the resulting plan, because in a shop that size that person already holds most of the knowledge the migration needs. One person with system access produces the exports and does the install. What you should not do is collapse the validating role into the same act as the loading role without pausing between them. Even when it is the same person, load the data, then deliberately stop, schedule a known set of orders, and check the plan against what you know the plant does. The separation is a step in the process rather than a headcount, and skipping it is what turns a fast migration into an untrusted one.
Q: Who owns the decisions that a data file cannot answer?
A: The machine owners, and this is the part most plans underestimate. Several kinds of configuration are not in any file because your old system never held them. Which machines genuinely form an interchangeable pool, and how much slower one of them is for a class of work. What the real changeover time is between two product families, in each direction. Which certifications actually gate which operations. That knowledge sits with setters, supervisors and the people who run the machines, and it has to be collected by asking rather than by exporting. Build it into the plan as interviews with named people against named machines, scheduled after the bulk load so there is a working plan to test the answers against. Treating it as a data-entry task assigned to whoever has time is how a migration ends up with plausible numbers that nobody on the floor recognizes.
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
Migrating to EDGEBIC: The Complete Guide
The full path from RMDB, EDGEBI, a spreadsheet, or a whiteboard to EDGEBIC: what carries forward, what is hand-built, the import order, and how to validate the first schedule.
Migrating Your Tools and Fixtures to EDGEBIC
Tools and fixtures are not one of the eight import masks, so you build the list by hand. Here is what to enter, the quantity rule that ruins schedules when it is wrong, and where tools belong in the migration sequence.
Rehearsing Your EDGEBIC Migration Load
The data load is a repeatable operation, not a one-shot event. Every entity type is safe to re-import, and a reset takes you back to an empty plant, so plan to load your data three times before go-live.