Documenting Your Plant's EDGEBIC Conventions

A plant's EDGEBIC conventions document is one page covering seven things: naming rules, master data ownership, mask sources, role meanings, scheduling policy decisions with reasons, renamed labels, and the standing rules. In EDGEBIC by User Solutions every current setting is discoverable from a Settings tab, and none of the reasoning is. This post is what to write down so the second year of running the system looks like the first.

If you are assembling a handover pack, this document is the largest item in it; see handing over to a new IT owner. If you are running the system day to day, it is what stops five people making the same decision five ways.

1. Naming Rules

Start here, because naming is the convention with a direct effect on the plan.

Import masks match rows to existing records by name. So a work center that arrives as Mill 2 in one file and Mill-2 in another becomes two work centers, each with its own capacity, its own shifts, and its own scheduled load. Nothing warns you. The plan simply reflects a plant with more machines than you own, and the mistake is hard to trace because no screen shows one machine split in two.

Write the rule for three things: work centers, products, and job numbers. Be specific about separators and case. Then note where the rule is enforced, which should be in the source file rather than in the application, because the file is where the next load comes from. If you rename anything in the application later, see how to rename a work center and fix the source file in the same hour.

2. Who Owns Which Master Data

This section is short and prevents a specific, silent failure.

Saves follow a last-write-wins contract: if two people save the same record within the same window, the second overwrites the first with no warning and no error, including fields the second person never touched. That behavior is explained in full in what happens when two admins save the same record. The protection is not a setting, it is ownership.

So name an owner per area: work centers and shifts, products and routings, customers, orders. One name each. Collisions need two people in the same row at the same time, and clear ownership makes that rare enough to forget about.

3. Which File Feeds Which Mask

For each import mask, record three things: what it loads, which file and which report produces that file, and who owns it when the layout changes.

That third column is the one that matters. A mask keeps working until its source file changes, and files change without telling anybody: a renamed column, an added field, a rebuilt export. Knowing whose phone to pick up turns a broken load from an afternoon into ten minutes.

Add one warning while you are here, because it catches people repeatedly: a routing import wipes and recreates a product's steps on each run, so each product's complete routing must live in one file. A routing split across two files leaves an incomplete routing behind, and the symptom appears later as a job that will not schedule. The governance around all of this is in the data import governance workflow.

4. What Each Role Means

List the roles that exist, one line each on what the role is for, and who approves a change to it.

Then record the duty attached to them: after every upgrade, review the custom roles, because new permissions from a product update are granted automatically to the built-in Administrator role only. Custom roles must be granted new capabilities explicitly. Without that line in writing, the review does not happen, and the symptom arrives months later as a feature only the administrator can see. Role design itself is covered in the four roles most plants need.

5. The Scheduling Policy Decisions, With Reasons

The Schedule tab in Settings holds seven site-wide choices: the default direction stamped on new jobs and quotes, what happens when a backward job does not fit, which optimizer engine runs, how a short confirm is replanned, how far ahead the engine may search for capacity, whether parallel hours roll into job totals, and whether sub-assemblies are scheduled with their parent.

Anyone can read those seven values in half a minute. Nobody can read why. Write one line per setting: the value, the date it was chosen, and the problem it solved. This section is the highest-value paragraph in the document, because policy is read fresh on every scheduler run with no restart, which makes it easy to change and easy to change back by someone who never knew the reason. See how to configure scheduling policy.

6. Renamed Labels

If your plant says cell rather than work center, the Localization tab lets an administrator rename on-screen text: tab captions, button labels, column headers. That is a good idea and a documentation hazard at the same time, because every guide, every training note, and every support conversation still uses the default vocabulary.

So record the renames. A two-column list of default term and your term saves a new planner from hunting for a screen that exists under another name. The mechanics are in how to rename on-screen labels.

7. The Standing Rules

Half a dozen lines that never change and are forgotten anyway.

Keep It to One Page, and Review It Quarterly

The failure mode of documentation is length. A twelve-page runbook is written once and read never; one page gets reread, corrected, and handed over.

Review it at the same sitting as your access and policy review so it never drifts more than a quarter out of date, per the quarterly admin health check. Systems at the US Navy, GE, and Cummins have outlasted the people who commissioned them for one unglamorous reason: somebody wrote down what was decided and why. For the full administrator reference, read the EDGEBIC admin guide, and for the practice this document ultimately protects, what production scheduling is.