When a screen should not live inside the ERP

There is a scene that repeats in almost any plant. Somebody standing at a bench, wearing gloves, finishes a manufacturing order and has to report three figures: how much came out, how much was scrapped, and a note. To do that they open the ERP on a shared tablet, navigate to the order, find the field, enter it and validate.

Three figures. Fourteen taps.

The easy conclusion is that the ERP is badly designed. It is not. An ERP is designed for the person who needs to see everything — the one who plans, the one who costs, the one who audits — and for that person every field on screen is useful information. The problem is not the design: it is that we are asking one tool to serve two users with opposite needs.

This article is about how to decide when to separate them and — more importantly — when not to.

The four questions

Before drawing anything, it helps to answer four things about the person who will use the screen. Not about the process: about the person.

1. How many fields do they touch daily, out of how many they see?

This is the question that settles the argument fastest. Count the fields that person modifies and divide by the ones they have in front of them.

A buyer touches twenty fields out of thirty: the full view serves them. A line operator touches two out of sixty. That ratio — two in sixty — is the real measure of how much noise you are asking them to filter, eight hours a day, in a hurry.

Once the ratio drops below one in ten, the screen has stopped being a tool for that person. It is an obstacle they have learned to work around.

2. How many people, and with what access?

Here comes the figure that often decides the whole project: how many of those people need an ERP account, and how many should never have one.

A warehouse supervisor does: they look things up, correct them, decide. Forty shop-floor operators who only report progress do not — not because of the cost, though that counts too, but because every account is one more surface where something can be touched by mistake.

And there is an even clearer case: people who do not work at your company. A distributor placing an order, a supplier checking a purchase order. That person is never going to have an account in your ERP, and it is not a technical limitation: it is that they should not have one.

3. On what device, and in what posture?

The key word is posture, not device. These are not the same:

• Seated at a computer, with keyboard and mouse and no rush.
• Standing at a bench, in gloves, with a scanner in hand and a queue of boxes waiting.
• On their own phone, belonging to somebody who is not your employee, on whatever connection they happen to have.

An ERP is built for the first. The other two call for large buttons, few steps and a screen that does not move between one entry and the next.

4. What happens if they get it wrong?

The last question is about blast radius. If that person mistypes a number, what breaks? If the answer is "a produced quantity that gets corrected later", the risk is low. If it is "a transfer got validated and moved stock across three warehouses", the risk is that you gave too much screen to somebody who only wanted to report.

Restricting by permissions solves part of it. But a permission removes the button; it does not remove the noise of the other fifty fields.

The ladder, from the bottom up

With those four answers, the decision becomes a ladder. The rule is to climb one rung at a time, and only when the previous one fell short.

Rung 1 — A view of your own. A list or a form with the fields that matter, a default filter, and the rest hidden. It is built with Studio, without programming, and it solves most of the cases people frame as "I need an app". Always start here.

Rung 2 — A view with an action. The same, plus a button that does the whole step in one operation: enter the quantity and validate, rather than enter, save, hunt for the button, validate. Studio accepts code in server actions, so that button can do considerably more than people assume.

Rung 3 — The portal. Odoo ships a portal for outside parties: customers and suppliers who consult their own documents without being internal users. If what you need is for somebody external to see what is theirs, this rung is often enough, and almost nobody tries it before jumping to the next one.

Rung 4 — A separate application that connects. It lives outside the ERP, talks to it, and presents only the process. It is the rung that solves everything, which is exactly why it gets chosen too early.

What rung four costs

Here is the part rarely said in a sales meeting, and worth saying before you start rather than after.

A separate application is another server to pay for, monitor and update. It is another door to administer, with its passwords and its joiners and leavers. It is one more thing that can go down on a Tuesday morning. And it has no magical offline mode: if the ERP does not answer, the application does not operate either, because the single source of truth is still the ERP — which is a virtue, not a defect, but one to know about in advance.

None of that is expensive compared with the problem it solves when the problem is real. All of it is ruinously expensive when the problem was solvable at rung one and nobody tried.

The way to get this wrong is not choosing rung four. It is never having tested rung one.

A two-minute test

If the discussion stalls, one test unsticks it: sit next to the person and count the taps.

Do not ask whether they find it hard — they will always say they are used to it. Count how many taps they need for the thing they do fifty times a day, and how many of those taps are about the data versus about finding the data.

If out of fourteen taps two are the entry and twelve are navigation, you know the size of the problem. And if that navigation is solved by a default filter, you also know you do not need an application.

What does not change when you separate them

One warning that covers the whole article: separating the screen does not mean separating the data.

The temptation, once you have a separate application, is to give it a database of its own "so it runs fast". The moment the same information lives in two places, the two can disagree — and they will. The day they disagree, nobody will know which one is right.

The application presents the process. The ERP remains the only thing that knows.

How we solved it

We built three applications on exactly this ladder, and each one reached rung four for a different reason.

The Operations Portal climbed on questions 2 and 3: forty operators who only report progress, on their feet and in gloves. The B2B Distributor Portal climbed on question 2 in its clearest form: they are customers, not employees, and they are never going to be ERP users. OneButtonPrint climbed on question 1: at the packing bench the ratio between what gets touched and what gets seen is one to many, and the saving is in the taps.

None of the three installs into Odoo. They live outside and connect, which is what makes them work alike on Odoo Online, on Odoo.sh and on-premise.

And on plenty of other projects the answer was rung one: a view with the right fields, built with Studio in an afternoon. Those have no page in the catalogue, but they are the majority.

If you have a process where somebody fights a screen every day, the conversation starts by counting the taps. Tell us which one it is.