Who Owns the ERP Import Routine on Your Team

The ERP import routine belongs to one named person in planning, with IT owning the export definition and the database behind it, and a written backup who has run the full cycle at least twice. The reason is not organizational tidiness. Reading an import result requires knowing whether 400 hours on a job is plausible, and only the planner has that knowledge.

EDGEBIC by User Solutions moves ERP data through saved Excel, CSV, and database import masks, which means the routine is short enough that one person can own it comfortably. This post assigns each duty, names the failure modes of an unowned routine, and gives the minimum handover that survives a resignation.

The rule that decides every case

Ownership follows consequence. Whoever bears the cost of a mistake should hold the control that prevents it.

That single test resolves almost every argument. A bad import produces a bad schedule, and the planner is the person who spends Tuesday explaining a wrong promise date, so the planner runs the import. A corrupted database costs everyone, and planning cannot restore one, so IT owns backups. The same logic covers the awkward middle: an ERP report definition affects several departments, so it belongs to the group that maintains reports, not to the planner who happens to consume one.

The duty split

The line most often drawn in the wrong place is the fifth one. Teams treat the count review as verification, which sounds like a quality task, so it drifts to whoever is free. It is actually interpretation. A run returning 34 Created, 240 Reused, and 0 Failed is healthy in a shop that adds a few parts a week and alarming in a shop whose catalog has been stable for a year. Only the planner knows which shop this is. The meaning of each outcome is in import row status.

What the owner actually does

The recurring duty is smaller than the title suggests. In a weekly cycle it is:

1. Confirm the exports landed and look current.
2. Run the masks in order: products, work centers, routings, work orders, then actuals.
3. Read the counts after each run and stop if they look wrong.
4. Run the scheduler.
5. Export the plan back for the floor.

That is about twenty five minutes. The import order matters and does not change, because routings reference products and work centers, and orders reference products. The full rhythm is in the weekly import routine, and the time budget behind it is in what an ERP integration costs in hours per week.

The failure modes of an unowned routine

Each of these has a specific smell, and each traces back to a missing name.

Nobody notices the export went stale. A report gets edited, or a scheduled job stops, and the file in the folder is three weeks old. The import runs perfectly and reports 0 Failed, because an old file is still a valid file. The counts do not catch this; a date check does, and only if someone is looking.

Two people build competing masks. Both work, they map slightly differently, and the schedule changes depending on who ran the cycle. Masks are cheap to create, which is exactly why they need one owner and names that describe the routine rather than the file.

A mapping is repaired without being recorded. Someone fixes a renamed heading on Friday, and in March nobody can explain why setup hours changed shape. A one-line note per edit prevents this entirely: see keeping a change log of import mask edits.

The count check quietly stops happening. It is the first step dropped when the week is busy, and the only step whose absence is invisible until a schedule is built on duplicated data. Making it part of the routine note rather than a habit is what keeps it.

Two arrangements that also work

The split above is the default, not the only shape. Two variants hold up well.

The one-person shop. In a plant with a single planner, that person owns everything except the database and backups. This is fine and extremely common, and the only addition it needs is the written routine note, because the concentration risk is real even when the workload is not. Give the note to whoever would cover a two week absence, and have them run one cycle a quarter.

The shop with a data analyst. Some larger operations put a business analyst between IT and planning, and it works when the analyst owns the export and the mask maintenance while the planner keeps the count review and the scheduler run. What does not work is the analyst owning the count review, because reading Created against Reused correctly requires knowing whether the shop added forty parts this month. Split at the point where shop knowledge becomes necessary and the arrangement holds.

Both variants pass the same test as the default: whoever bears the cost of a mistake holds the control that prevents it.

The minimum handover

Three artifacts protect against the person leaving, and they cost under an hour to produce.

• A routine note. Which exports, which masks, in what order, and the two checks that prove the run was good. One page.
• A mask-to-export map. Which mask reads which file. This is the note that turns a heading rename into a six minute repair rather than a hunt.
• A named backup who has run the cycle. Watching is not enough. Have them run a full cycle once, with the owner beside them, then repeat it quarterly.

None of this depends on documentation discipline holding for years. The masks themselves are saved configurations, so access and capability survive automatically. Only the reasoning needs writing down, and it fits on a page. The wider version of this exercise is documenting your plant's conventions.

Where this sits in the bigger split

The import routine is one slice of a larger question about who administers the scheduling system: the database, user roles, scheduling policy, and grid layouts each have their own natural owner. Splitting EDGEBIC admin duties between IT and planning covers the full map. Access to the export files is a separate question, because a nightly file holds customer names, prices, and labor rates: who should see your ERP export files covers where the folder belongs. What is specific to the import routine is that it looks technical and is not. The mechanics are two clicks. The judgment is the job.

Bring your current export and the person who would inherit it to a working session. Watching a full cycle end to end is the fastest way to see how little of it is technical, and where the real decisions sit. The architecture is on the EDGEBIC ERP integration page, and the engine those imports feed is on the EDGEBIC product overview.