RMDB to EDGEBIC: A Feature-Parity Map

EDGEBIC covers the finite capacity scheduling features you rely on in RMDB, renames a few, and adds several that RMDB never had, so the move is an upgrade rather than a loss. EDGEBIC by User Solutions is the next-generation successor to RMDB, EDGEBI, and RMX, built on the same scheduling logic and the same User Solutions heritage. This parity map is for the plant lead who is worried a feature will disappear. It sorts every major RMDB capability into three buckets: carries over as-is, equivalent under a new name, and genuinely new.

The short answer, then the map

Most of what your schedulers do every day in RMDB is core scheduling: routings, work centers, finite capacity, forward and backward passes, alternates, shift calendars. All of that carries forward. The interface is new and a few terms changed, which is why a terminology crosswalk is worth reading alongside this. But the scheduling model is the same lineage, so your judgment about what a good schedule looks like transfers directly.

The one honest caveat: parity on paper is not parity proven. A shop-specific report or a hand-built convention needs to be confirmed on your own data during a pilot. The map tells you where to look. The pilot tells you it works.

Carries over as-is

These features exist in EDGEBIC with the same behavior you know. The data comes in through built-in Excel and CSV import masks, which cover shifts and plant holidays as well as products, work centers, customers, sales orders, routings, and actuals. Attaching a calendar to a particular work center is done in the application.

If a capability is in this table, you do not relearn it. You learn where it lives in the new interface, which the pilot handles.

Equivalent under a new name

A handful of things do the same job under a different label. This is where a plant lead usually gets nervous, because a missing menu item reads as a missing feature. It is not. See the full crosswalk for the complete list; the pattern is that the concept survived and the wording modernized.

The practical move here is simple: when a scheduler says "I cannot find X," check the crosswalk before concluding X is gone. In nearly every case the feature is present with a clearer name, and the confusion is vocabulary, not capability.

Genuinely new in EDGEBIC

This is the part that makes the upgrade worth doing rather than merely surviving. RMDB gave you a solid finite capacity schedule. EDGEBIC adds capabilities that were not in the RMDB generation.

A scheduling optimizer. Beyond the default greedy schedule, EDGEBIC can run a multi-run search that tries many complete orderings and returns the best, guaranteed never worse than the baseline. A mathematical optimizer with a proven optimality gap is also available, so you can see how close a plan is to optimal instead of guessing. This is new capability, not a rename.

Work center groups. A named pool of interchangeable machines that a routing step can target as one capability, with the engine shopping the pool by strategy. It composes with the alternate work centers you already used, and it is shipped today.

Operators and skills. A per-operator hours model with skills, so the schedule respects who is certified and rostered, not just which machine is free. Also shipped.

A shop-floor kiosk with actuals. Operators report starts, completions, and hours from the floor, and those actuals feed the next reschedule. Completed work is never moved by a reschedule, which is a documented guarantee, so your history stays intact.

Lot streaming with transfer batches. Overlap a downstream operation before the upstream finishes, driven by piece counts, which shortens flow on the jobs where it applies.

None of these replace an RMDB feature. They extend what the schedule can express.

How parity gets proven

Do not take this map on faith for your plant. Prove it. The reliable method is the same one every phased migration uses:

1. Export your RMDB master data to Excel and import it through the masks.
2. Pick one busy cell and schedule it in EDGEBIC.
3. Reconcile that schedule against RMDB for the same jobs, and explain every difference.

A difference is almost always a data gap (a missing setup time, an omitted routing step), not a missing feature. When the cell matches your team's judgment, parity is proven on your data and you expand. This reconciliation step is documented in detail in validating a migrated schedule against RMDB.

The honest boundaries

Two things are worth stating plainly. First, ERP data movement is through flexible Excel, CSV, and database import-export masks, not a native certified connector, so if you pictured a one-click sync from your ERP, the reality is a mapped mask you configure once. Second, a custom RMDB report or macro is rebuilt in EDGEBIC as an export or report rather than lifted verbatim. Neither is a scheduling gap; both are setup tasks you scope during the pilot.

The takeaway

For RMDB to EDGEBIC feature parity, the core scheduling model (finite capacity, routings, work centers, forward and backward passes, alternates, and calendars) carries over, a few items change names without changing behavior, and the optimizer, work center groups, operator skills, and shop-floor actuals are new on top. Confirm parity on your own data with a one-cell pilot rather than trusting the map alone. See the platform on the EDGEBIC overview, read the upgrade path on the RMDB to EDGEBIC guide, and start with what carries forward from RMDB to EDGEBIC.