Who Owns What: Splitting EDGEBIC Admin Duties

Split EDGEBIC administration by the question each duty answers: IT owns where the data lives and how it survives, planning owns what the schedule says, and user accounts are the one duty they share. In EDGEBIC by User Solutions both halves live behind the same Settings tabs, which is exactly why plants end up with duties nobody owns. This post is the duty-by-duty split, and the reasoning that makes it hold up in an argument.

The individual mechanics are covered elsewhere in this cluster. This post is about who does them.

The Rule That Decides Every Case

Ask one question of each duty: does it decide where the data lives and how it survives, or does it decide what the plan produces?

The first belongs to IT, because the consequences are availability, recovery, and access. The second belongs to planning, because the consequences show up as dates the plant commits to.

That rule resolves the settings that cause the most confusion. The database provider looks like configuration and is genuinely IT. The default scheduling direction also looks like configuration and is genuinely planning, because flipping it changes whether new jobs start as early as possible or land just in time. Same screen family, different owner.

What IT Owns

The database and the server. Which provider, which server, which database. The DataSource tab shows the active connection at the top, and the choice behind it is an IT decision, covered in choosing a database as an IT decision.

Authentication. Windows authentication where possible, because it stores no password and ties access to the network identity IT already manages. Where SQL authentication is used, IT should know that the stored password is encrypted against the Windows account that entered it, so a configuration moved to another Windows user needs the password re-entered.

Backups, with a named verifier. Not just the rotation but the person who can confirm the scheduling database is genuinely in it. And the drill, because a backup nobody has restored is a hypothesis: see running a restore drill.

Upgrades. Back up first, upgrade, let the database update itself on first launch, verify before the team signs in. The routine is in upgrading safely.

The recovery path. When the application cannot reach its database it shows a recovery window with the error, an embedded connection editor, and four actions: retry, reset to the default local database, repair, or exit. IT should know what repair actually does, which is rebuild internal version bookkeeping without changing data. See database recovery and repair explained.

What Planning Owns

Import masks and their source files. A mask maps columns in a file to fields in the database, and it keeps working until the file changes. Knowing which report produces which file, and what a changed column means, is planning knowledge. IT can run a load; only planning can tell whether the result is right. See the data import governance workflow.

Master data. Work centers, shifts, holidays, products, routings, customers. Every one of these is an input the engine plans from, and a wrong value produces a confidently wrong schedule rather than an error.

Scheduling policy. The Schedule tab in Settings holds seven site-wide choices, and each one changes what the next run produces: the default direction, what happens when a backward job does not fit, which optimizer engine runs, how a short confirm is replanned, how far the engine may search ahead for capacity, whether parallel hours roll into job totals, and whether sub-assemblies schedule with their parent. Policy is read fresh on every run with no restart, so a change lands quietly and quickly. See how to configure scheduling policy.

What each role means. IT can tick permission boxes. Only planning can say whether a supervisor should be able to reschedule, which is the decision in deciding who may change the schedule.

The Duty Split

Two rows are worth a sentence each. Data clearing is destructive with no undo, so it should require two people agreeing rather than one person deciding, which is a process control rather than a permission one. And display configuration is genuinely nobody's duty but the individual's, since grid layouts and scheduler display settings save per user and change no engine math.

The Duty Neither Side Wants

Reviewing custom roles after an upgrade is the orphan in most plants, because it looks like IT work and requires planning judgment.

New permissions from a product update are granted automatically to the built-in Administrator role only. Custom roles must be granted new capabilities explicitly, which is a deliberate security-first default. The symptom of nobody owning this is a feature that works for the administrator and for nobody else, reported weeks later as a bug.

Assign it: IT flags that an upgrade introduced new capabilities, planning decides who should hold them, IT ticks the boxes. Put it on the quarterly admin health check so it happens regardless.

Write It Down Once

The split takes ten minutes to agree and stops months of quiet gaps. Add it to your written conventions, covered in documenting your plant's conventions, and hand it over intact when either side changes people, per handing over to a new IT owner.

Deployments at the US Navy, GE, and Cummins have one thing in common with a twenty-person job shop: the systems that stay healthy are the ones where every duty has a name against it. For the full administrator reference, read the EDGEBIC admin guide, and for the practice both teams are ultimately supporting, what production scheduling is.