One question eliminates more candidates than any other, and most buyers ask it too late: is your manufacturing discrete or process? Systems built for one cannot be configured into the other.
This is the question that eliminates most candidates, and it is worth settling before any demo.
Discrete manufacturing assembles countable things from countable things. A bill of materials says this many of that, an order produces a quantity of one item, and you can point at a finished unit. Machinery, electronics, fabrication, furniture, automotive components.
Process manufacturing transforms materials by recipe. A batch yields several saleable outputs at once — co-products and by-products — quantities are measured by weight or volume rather than counted, and inputs vary in potency so the recipe adjusts to the assay of what you actually received. Chemicals, food, pharmaceuticals, paint, adhesives.
The difference is not a setting. A discrete system models one output per order; a batch that yields two saleable products cannot be represented in it without lying about one of them. Buyers who discover this after purchase generally discover it during implementation, which is the expensive moment.
Rebota is discrete-only. If you run a process plant, it is the wrong product and no configuration will change that.
A routing is the sequence of operations that makes an item: which work centre, how long, in what order. It is what makes capacity, scheduling and OEE computable, and a system without real routings cannot produce any of the three however good its dashboards look.
The detail that matters more than it should: setup time is per batch and run time is per unit. Getting that wrong is the classic routing error. A 30-minute setup charged per unit turns a 500-piece order into ten days of phantom capacity — quotes get padded to cover load that was never real, and the plant looks full when it is not.
Ask to see the routing screen and check the two are separate fields with distinct meanings. Then ask what happens to a released order when the routing changes: a correct system snapshots the operations onto the order, so work on the floor never re-plans under someone mid-shift.
Vendors present traceability as a checkbox. Test it with a scenario instead.
"A customer reports a failure on unit number X. Show me every raw material lot that went into it." That is the backward walk. Then: "That lot turned out to be defective. Show me every other unit it went into." That is the forward walk, and it is the one that scopes a recall.
Many systems do the first and not the second, because the first is a lookup and the second is a graph traversal through however many production stages you have. If a system can only walk one way, a recall gets scoped by guesswork — always far wider than it needed to be, which is the expensive kind of wrong.
Also establish whether you need batch or serial. Batch identifies a lot and pairs with expiry and FEFO consumption; serial identifies one physical unit and suits anything with a warranty or a recall obligation. Your regulator usually decides, not your preference.
Every system claims production costing. The question is whether it settles.
Accumulating actual material, labour and overhead onto an order is the easy part. What makes it useful is comparing that total against a standard derived from the BOM and the routing, so the difference decomposes into material usage, material price, labour efficiency and overhead absorption. A variance you cannot decompose tells you something went wrong and nothing about what.
Ask to see a settled order with its variance breakdown. If the answer is a single actual-cost figure, you will be doing the analysis in a spreadsheet, and you will stop doing it by month three.
MRP and finite capacity scheduling are different things, and product pages routinely blur them.
MRP explodes demand through the BOM against on-hand and on-order stock and tells you what to buy and make. Most systems do this, and it is genuinely useful.
Finite capacity scheduling sequences that work against real machine and labour capacity, respecting constraints, and produces a schedule you could actually run. Far fewer systems do it, and in the mid-market almost none do it well.
If your constraint is material, MRP is what you need. If your constraint is machine hours — you can get the steel, you cannot get the press time — then MRP alone will keep producing plans your plant cannot execute. Ask specifically: does the system schedule against finite capacity, or does it assume infinite capacity and leave sequencing to a planner? Rebota does the second: there is no capacity model, and the schedule stays in a planner's spreadsheet. For some manufacturers that is disqualifying, and it should be known up front.
Everything above depends on someone recording what happened on the floor. If operators will not use the terminal, the ERP holds a plan and no actuals, and every number it produces is theoretical.
What works is narrow: start, pause with a reason code, report quantity good and scrapped. What fails is a form with fifteen fields on a screen an operator has to walk to. Ask to see the operator interface — not the supervisor dashboard — and ask how many taps a normal shift requires. Then ask whether pause reasons are a fixed list, because free-text reasons produce data nobody can aggregate.
Scrap in particular must be a stock movement rather than a note. If scrap is not a movement it is not a cost, and the first time anyone sees the number is in a year-end variance nobody can decompose.
Built and reachable: multi-level BOM with explode and where-used, routings with setup per batch and run per unit against work centres, production orders that explode the routing into shop-floor operations, an operator terminal with start, pause-with-reason and quantity reporting, OEE computed from captured time against routing standards, batch tracking with expiry and FEFO consumption, individual serial numbers with genealogy in both directions, inspection plans with recorded results and a QC gate on completion, order costing settled against standard, and MRP explosion with a shortage list.
Not built, and each is a real gap rather than a roadmap flourish: finite capacity scheduling and MPS, PLM — engineering change control, revisions, approvals — process manufacturing in any form, and multi-plant consolidation. Discrete manufacturers up to roughly ₹100 crore are well served; above that, or in any process industry, they are not.
| Feature | Accounting + stock | Generic ERP | Rebota |
|---|---|---|---|
| Bill of materials | Multi-level, explode and where-used | ||
| Routings with work centres | Varies | ||
| Setup per batch and run per unit kept separate | Often conflated | ||
| Shop-floor terminal with pause reasons | Rarely | ||
| OEE from captured time against standards | Rarely | ||
| Batch tracking with expiry and FEFO | Varies | ||
| Individual serial numbers | Varies | ||
| Genealogy in both directions | Rarely | ||
| Order costing settled against standard | Varies | ||
| MRP explosion and shortages | |||
| Finite capacity scheduling / MPS | Sometimes | Not built | |
| PLM / engineering change control | Sometimes | Not built | |
| Process manufacturing — recipes, co-products | Some | Discrete only | |
| Multi-plant consolidation | Sometimes | Not built |
Discrete manufacturers up to roughly ₹100 crore who need traceability, real routings and order costing connected to purchasing, inventory and accounts — and who currently hold production together with spreadsheets and a whiteboard.
Any process manufacturer — chemicals, food, pharmaceuticals, paint. Recipes, co-products, by-products and potency are not modelled, and a batch yielding two saleable outputs cannot be represented. Also anyone whose binding constraint is machine hours, because finite capacity scheduling does not exist here.
A tier-one ERP wins where finite capacity scheduling, PLM or multi-plant consolidation are prerequisites rather than ambitions. A dedicated process ERP wins in any recipe-driven industry. Both are genuine gaps, not positioning.
One product line, short routings, no traceability obligation and one person who knows where everything is. The case for a system strengthens sharply the first time a customer asks which lot went into their unit.
Standard times. Routings are only as good as the setup and run times in them, and gathering honest ones is weeks of work nobody budgets for. Without them there is no capacity figure, no OEE and no variance — the system runs, and reports nothing worth reading.
Settle discrete or process first; it eliminates most of the market. Then test traceability with a real recall scenario in both directions, check that setup and run times are separate fields, and ask whether orders settle against a standard. Those three questions predict more than any feature matrix.
The manufacturers who get value from an ERP invest in standard times before they invest in dashboards. It is unglamorous — timing operations, agreeing what a realistic setup actually takes, arguing about whether an operator was having a good day — and it is the foundation everything else computes from. Capacity, OEE, quoting and variance all derive from those numbers, and a system loaded with optimistic standards will confidently report that every job is late and every operator is underperforming, until people stop reading it.
