Stand between the two lines in a small enclosure plant and you can see both screens at once. The ERP terminal by the office door lists this week’s works orders, each with a status of released, in progress or complete. The screen projected above the lines shows a spreadsheet with one row per works order and a dozen or more columns, some filled red, some carrying a note in capitals that says do not start. The floor reads the second screen. Nobody reads the first one unless they have to post something.

Someone senior has now asked why the plant still needs the spreadsheet when the ERP already holds every order, and what would replace it. The short answer is that the ERP records what has been posted about each works order, while the team has to run the work that happens between one posting and the next. The spreadsheet holds three things the ERP view does not: the working state of each job right now, the operation’s own rules about what may happen next, and a way for each person to find what is theirs to do. Anything that replaces it has to hold all three and read the ERP rather than copy it. A tool that only captures state has moved the spreadsheet, not replaced it.

What the ERP view is recording

An ERP works order is a transaction record. It is created from a sales order or a plan, it carries master data such as the part, the routing, the quantity and the due date, and it moves through a lifecycle the vendor has defined. Most mid-market ERPs expose something like planned, released, in progress, complete and closed. The names vary, so check yours. What moves the order from one status to the next is a posting: a release, an operation confirmation, a material issue, a completion.

Between postings, the status does not change. A works order released at 07:30 on Monday and confirmed complete on Wednesday afternoon reads as released, or as in progress, for the whole of the time in between. Nothing is wrong there. The ERP is accountable for the record of what was done and what it cost, and a record is supposed to sit still until something happens that is worth recording. What ERP software covers sets out that accountability, which is worth having to hand when you explain to the ERP owner that the gap described here is not an ERP failure.

The trouble is that the work happens in that still period. Whether the kit has been picked, whether QA has approved the first-off, whether the customer has signed the label proof, which line has the job and what step it is on: none of those is a posting, so none of them changes the status. The ERP view is accurate and almost silent about where the job actually is.

What the spreadsheet is holding

The spreadsheet in this setting is a grid with one row per job, maintained by one or two people, whose columns were added one at a time. Each column exists because the operation found out, usually the hard way, that it needed to know something the ERP status did not tell it. Nobody sat down and designed it.

Take a specific case, which is illustrative throughout: the figures are chosen to be consistent with each other, not measured at any plant. A manufacturer of electrical enclosures runs two assembly lines and releases about 40 works orders a week, eight a day. One planner maintains the line board, projected between the lines, with 14 columns. Sorted by what each column is doing, they fall into three kinds.

Kind A columns are copies. They exist so the board can be read without a second screen, and every one of them is keyed by hand from the ERP release list. Kind B columns are working state: facts about a job that are true right now and will change during the day. Kit status moves from none to partial to complete as stores pick it. First-off approval appears when QA initials the cell. A hold reason appears and then clears. None of these is a posting, and none of them has anywhere to live in the ERP’s lifecycle.

Kind C is the interesting one. A red fill on a row due within two days whose kit is incomplete is a rule: this job is at risk and needs attention before anything else. A “do not start” note against a job whose first-off is outstanding is a rule: the line may not begin production until QA has approved the first piece. The priority number is a rule about order. But the spreadsheet cannot enforce any of them. It can only display them, and depend on every reader interpreting the colour the same way, and on the colour being current.

The weekly effort shows how much of the planner’s time each kind takes. Five copied columns across 40 jobs is 200 cells keyed. Six working-state columns across 40 jobs is 240 cells, and each is touched about twice, once when set and once when the step completes or the hold clears, so 480 edits. Three rule columns across 40 jobs is 120 recolours and re-prioritisations. That is 800 manual edits a week by one person, and 200 of them are copies of data the ERP already holds.

Why the spreadsheet fails as the plant grows

The board is current only as often as its maintainer polls the floor. In the enclosure plant the planner refreshes the copied columns from the ERP release list at 07:30, then walks both lines and the stores at 10:00 and again at 15:00 to update working state. Between walks, every decision anyone makes from the board runs on the state as it stood at the last one.

On a normal Monday, at 10:40, line 2 finishes a job and the line lead looks up at the board to choose the next one. The board, current as of 10:00, shows works order 4471, due Tuesday, with kit partial, and works order 4478, due Thursday, with kit complete. The lead applies the board’s rules exactly as written: do not start a job whose kit is incomplete, and take the highest-priority job that is startable. They start 4478.

In fact 4471’s kit was completed at 10:20. The stores team finished the pick and recorded it where they always do, on the paper pick card, which the planner transcribes onto the board at the next walk-round. 4478 runs for three hours. 4471 starts after 14:00, and its Tuesday due date is now at risk. Throughout, the ERP shows both works orders as released. Nothing in the ERP was wrong, and nothing in the ERP could have shown the difference.

Nobody broke a rule. The board’s rules were applied correctly to state that was 40 minutes stale, because the working state exists in only one place and that place is updated on one person’s cadence. On this plant’s schedule the gap between reality and the board can reach five hours on any day. On this Monday it was 40 minutes and it still cost a due date. Nobody has to be careless for this to happen. As volume grows there are more jobs, more decisions between walk-rounds and more people reading the same grid, so correct decisions on old information are made more often.

The copies have their own failure. If the ERP’s due date on 4471 moves, or the quantity changes after a customer call, the board does not know. Someone has to notice and re-key. Every copied cell is a place where the ERP and the board can drift apart, and the board has no way of telling you when they have.

And the single grid serves nobody particularly well. The line lead wants the startable jobs for line 2 in priority order. QA wants the first-offs awaiting inspection. The planner wants holds and due-date risk. All three are looking at the same 14 columns and 40 rows and finding their own subset by eye. The per-person view is the third thing the spreadsheet is trying to do, and it is the one it does worst.

Three candidate fixes, judged by what each holds

Once the columns are sorted, each candidate replacement can be judged by which of the three kinds it actually holds, and you can put a precise question to whoever is proposing it.

Putting it in the ERP usually means adding a status or a custom field. That holds one more piece of working state, a kit-complete flag say, and it holds it in the system of record, which is a real gain. It does not by itself add the rule: nothing stops line 2 starting a job whose flag is unset, unless the ERP’s workflow tooling can express that condition and act on it. It does not by itself give each role its own view, unless the ERP can filter and present the same orders differently for the line lead, QA and the planner. Whether your ERP can do both is a question for its owner, with your kind C columns in hand: can this system express these three rules as conditions, and show each of these three roles only what they need? Some can. Do not assume the answer either way.

A workflow or business-process tool holds state and routes steps well. It will capture kit status, first-off approval and holds as form fields, and move a job from one step to the next with a record of who did what. What to ask is what its rules can see. If “kit complete” is judged against stock and pick data that live in the ERP, and the tool does not read the ERP, then the check stays manual: someone looks it up and ticks the box, and the double-keying continues with a licence fee attached. The question for the vendor is exact: can your rules reference data held in our ERP, and can you read our works orders rather than have us re-enter them?

An operational layer is the third option, and the next section describes one. Before that, the cases where none of this is needed. If most of your columns are kind A, the board is a report, and a saved ERP view or report replaces it with nothing further to buy. If kind B is small and the team is one planner and one line in one room, the spreadsheet is adequate, provided the people doing the work update it at the point of work instead of waiting for a walk-round, and it is cheaper than anything else. If the ERP’s own tooling can express your rules and give each role its own view, use it. A separate layer earns its cost when kinds B and C are substantial, when the rules need to see ERP data, and when more than one role needs a different view of the same jobs.

The same Monday on an operational layer

Keel is an operations platform shaped around how your business works. It turns your processes into clear, guided work for your team, with your rules and checks built in, and gives you the structure to run consistently as volume grows while keeping the freedom to change how you operate. For the planner in the enclosure plant, that means the line board becomes a system the floor updates as work happens, instead of a grid one person polls. For the lean lead who put the board up in the first place, it means the board stays a board, visible and owned by the team, without the walk-round.

Suppose the enclosure plant implemented this on Keel. Each role would have its own view of the same 40 jobs. The line lead on line 2 sees the jobs that are startable on their line, in priority order, and nothing else. QA sees the first-offs awaiting inspection. The planner sees holds and due-date risk across both lines. All three views are drawn from one set of job records, so there is no separate grid for each of them to keep current.

At 10:20, stores finish picking 4471 and mark the kit complete on a task in the same system, in place of the paper pick card. At 10:20, 4471 becomes startable and appears in the line 2 queue above 4478, because it is due sooner. At 10:40 the lead looks at the queue and starts 4471. The rule that governs this, do not start until kit is complete and first-off is approved, is a check on what appears as startable. A red cell asks the line lead to notice it and remember what it means. The check asks nothing of them.

The five copied columns are not keyed at all. Works order number, part, customer, quantity and due date are read from the ERP, so when the ERP changes, the board changes. When line 2 completes 4471, the completion posts back, so the ERP’s transaction record stays the record and the planner stops being the plant’s human integration layer. Where the ERP was silent between postings, it now receives the posting it wants when the work is done, and the operation has the working state it needs in the meantime.

Three things in Keel make this possible. It supplies tailored operator experiences, so the line lead’s queue and QA’s inspection list are built for those people, with only the columns they use. It supplies workflows that combine human steps such as marking a kit complete with processing steps such as reading the ERP and posting a completion. And it supplies business rules expressed in code, which is why the readiness check can reference exactly what this plant needs it to, including data read from the ERP, beyond a fixed set of configuration choices. Code needs implementation, testing and maintenance, which is the cost of that exactness.

What the implementation must build for this plant is the job model and its working states, the specific readiness and priority rules, the three role views, and the integration that reads works orders and stock from this plant’s ERP and posts completions back. Keel does not ship a line board, a kit-status rule or a connector to any named ERP. Keel leads the implementation and agrees the handover with your team; what Keel supplies sets out that division of work. The readiness rule itself, what makes a job permitted to start, is covered in depth in production control, and the principle of designing the view around the person doing the work is the subject of finance and operations systems.

An implementation costs design, build and maintenance that a spreadsheet never asked for. In exchange the operation’s rules become enforceable and changeable in one place, the working state is updated by the person doing the work at the moment they do it, and the planner’s 800 edits a week become time spent improving the process rather than transcribing it. Whether that exchange is worth making depends on how large kinds B and C are on your own board.

What to do with your own spreadsheet this week

Print the column headings and sort them into the three kinds. It takes an afternoon. For each column ask: is this a copy of something the ERP holds, is it a fact about the job that changes during the day, or is it a colour, an ordering or a note that tells the reader what must be true before the next step? Some columns will be two things at once. A due date with a red fill is a copy plus a rule, so count it twice.

Then decide per kind. Kind A columns should be read from the ERP, and the first question is whether a saved view or report already does that. Kind B columns should be updated at the point of work by the person doing it, and visible to everyone at once; ask who currently updates each one and how long after the fact. Kind C columns should become checks. Write each one out as a sentence beginning “a job may not … until …”, because that sentence is what you will hand to whoever builds the replacement.

Take the kind C sentences to your ERP owner and ask whether the ERP can express them and act on them, and whether it can show each role its own list. If it can, that may settle it. If kinds B and C are substantial and the rules need to see ERP data, bring the whole sort to a requirements conversation. Bring your spreadsheet’s column list to a conversation with Keel and we will work through what should be read, what should be held and what should be enforced.