Skip to Content

Web-based MRP for SMEs: what it changes and what to define first

Multiple users, shop floor, mobile, ERP connection: what web-based production software brings compared with a spreadsheet or installed software, and the seven points to define.
March 31, 2025 by
Web-based MRP for SMEs: what it changes and what to define first
Planitools

A plan on the scheduler's PC, software installed on two office computers, and a workshop running on sheets printed each morning: that is the real equipment of many SME manufacturers. Web-based production software for SMEs, available from a browser on any computer, tablet or phone, changes this organisation more than you might think. For the better, and sometimes for the worse, when the project is poorly scoped.

Our discussions with production and supply chain managers show a recurring gap between what plants need and the tools they are given. This article describes what web-based production software brings compared with a spreadsheet or installed software, what to define before starting a web MRP development, and the pitfalls we have seen close in on projects that had started well.

Spreadsheet, installed software, web-based MRP: three models

CriterionExcel spreadsheetInstalled softwareWeb-based MRP
Simultaneous accessOne person at a timeEquipped computers onlyEvery device, nothing to install
Shop floor and mobilePaper printoutsRarely, or through a separate moduleTablet, touchscreen, phone
Where the data livesIn the file, duplicatedLocal databaseOne central, shared database
Software updatesManual, by copying filesComputer by computerOnce, for everyone
Connection to the ERPCopy and paste, Power QueryDedicated connectorAPI, files, SFTP, EDI
Dependence on the deviceCompleteStrongNone: a browser is enough

What web-based MRP changes in practice for an SME

Several users, a single version of the truth

The planner, the workshop manager and the buyer look at the same plan, up to date, at the same moment. No more “which version have you got?”. When a manufacturing order is moved, everyone sees it, including the screen on the line concerned.

The shop floor joins the loop

A web application opens on a tablet beside the machine or on a touchscreen at the end of the line. The operator scans the manufacturing order at the start and end of an operation, declares a quantity, a batch or an incident, and progress is reported in real time. Actual time is compared with standard time without re-keying. This is what turns production software into a genuine shop floor tracking tool, without machine sensors.

Mobile and multi-site

A production manager checks progress from their phone; a second site works on the same database. For an SME with two workshops or a remote warehouse, this is often the first visible benefit.

Connecting to the ERP becomes natural

A web application exposes and consumes APIs: reading manufacturing orders and stock from the ERP each morning, sending back quantities produced and time spent in the evening. When the ERP has no API, a file exchange over SFTP or an EDI flow does the job. We have set out the options in the article how to connect two production management applications.

An end to parallel spreadsheets

When the official tool can no longer keep up, teams build workarounds in Access or Excel. Information becomes fragmented, reliability drops and the time lost handling data grows. This is especially visible at sites belonging to a large group: IT decisions are centralised, plants sometimes wait years for a feature, and they end up improvising. Web-based production software designed with the people who run operations gives these needs a single home again. Independent SMEs have the advantage of being able to decide quickly; they still need to scope the project.

What to define before a web MRP development

Projects that go off track have almost always skipped one of these seven steps.

  1. Division of roles with the ERP. Who is the master of items, bills of materials, manufacturing orders, stock, purchasing? Usually the ERP. The web-based software reads, proposes, tracks, and sends back facts: quantities, times, batches. Writing this division down in black and white avoids the worst trap: two systems that each believe they are the master.
  2. Master data. Items, routings, work centres, standard times, working calendars. If it is wrong or incomplete, no application will make up for it. Cleaning up master data is part of the project.
  3. Data flows. For each exchange: direction, frequency (real time, hourly, nightly), format (API, CSV, EDI), and who is responsible when an error occurs.
  4. Users and their devices. An office screen, a workshop tablet and a phone are not designed in the same way. The shop floor needs large buttons, barcode scanning and three actions, not a forty-column table.
  5. Written business rules. Scheduling priorities, grouping (by tooling, by allergen, by colour), rounding, minimum batch sizes. What is in the scheduler's head must be on paper before it goes into the code.
  6. Hosting and access. Where the application and the database run, who makes the backups, who manages accounts, and what happens if the internet connection drops in the workshop.
  7. Rollout. A first useful release, on one line or one workshop, with paper printouts in parallel while the teams get to grips with it. Our lessons learned from rolling out production software on the shop floor covers this phase in detail.

Pitfalls we have seen on projects

  • Trying to rebuild everything. Rebuilding stock or purchasing management in the web-based software when the ERP already handles them. The result: two stocks, two versions of the truth.
  • Designing the shop floor like an office. A screen designed for the planner and installed on a packing line will not be used.
  • Forgetting the fallback mode. No network, flat tablet, server under maintenance: what does the operator do? A back-up printout is better than a workshop at a standstill.
  • Depending on one person. The developer, in-house or external, must deliver documented code and a handover procedure.
  • Neglecting data migration. Work in progress, open manufacturing orders and batches in stock must exist in the new tool on the day it goes live.

Develop, or choose an existing web product?

Developing web-based MRP software is justified when the process is genuinely specific, and existing products have been tested on your cases and have failed on precise points. In other cases, a web product designed for SMEs, whose rules can be configured or programmed, brings multiple users, the shop floor and the ERP connection without the risks of a bespoke project. We have laid out the full decision grid in the article custom MRP software for SMEs. The French business site Journal du Net also offers a list of criteria for choosing MRP software (in French).

What we see in real workshops

The benefit of web-based production software is not primarily technical. It comes down to one thing: shop floor staff become contributors of information instead of mere recipients. An operator who scans a manufacturing order produces more accurate data than any estimate from the office, and does so with no extra effort. Successful projects start small (one line, one workshop, three screens), put the ERP at the centre and keep the paper printouts going for a few weeks. Those that fail wanted the complete application before the first scan.

Conclusion: getting web-based MRP right in an SME

Web-based production software for SMEs brings multiple users, a connected shop floor, mobile access and a natural link with the ERP. It does not remove any of the scoping work: roles with the ERP, master data, flows, workstations, written rules, hosting, gradual rollout. Well scoped, it puts an end to parallel spreadsheets; poorly scoped, it adds one more.

This is the need that Planitrack meets: a web application for time and operation tracking, with barcode scanning by handheld scanner or phone, real-time progress of manufacturing orders and drag-and-drop scheduling, connected to any ERP or fed by Excel. Our page simple production management software for SMEs presents the whole offer; you can also ask us for a demo.