To replace Excel shop-floor tracking, start by finding which business rules and physical events the workbook captures that your ERP does not currently handle well. Then move one workflow into a supported, maintainable interface. Recreating every tab as a web page can preserve the same confusion with a different login.
A useful first project is a digital work-order traveler: an operator opens or scans the order, sees the relevant operation and instructions, and records material use, progress, or an exception. A traveler follows the work through its steps. The important result is a reliable transaction and handoff, not merely a more attractive production report.
This article covers capturing work as it happens. If your question is whether an order has the prerequisites to start, use our manufacturing clear-to-build dashboard guide. Readiness depends on trustworthy records; the workflow below addresses how those records get created and corrected.
What the Reddit workflows reveal
In a manufacturing thread seeking an easy-to-implement MES, the author already had SAP. They described production reports in Microsoft Forms, work orders assembled with Excel/VBA and BOM lookups, Power BI reporting, and a SharePoint shipping workflow. Crucially, they said the shipping process worked quite well. The entire workaround stack was not a failure.
The requested functionality was broad: routings, quality records, scheduling, downtime, and instructions on tablets. Commenter u/sr000 cautioned that available functionality does not make implementation easy. That distinction matters when scoping a project: a list of features is not yet a usable production process.
In the discussion about smaller manufacturers building Excel “ERPs”, commenters described systems growing incrementally around immediate needs. u/gmankev noted that spreadsheets can preserve nonstandard handling that formal systems fail to capture. u/Captain_Nerdrage described a planning workbook bridging a mismatch between ERP work-order structure and material flow. Those experiences argue for understanding the workbook before removing it; their reported performance outcomes are not benchmarks for your plant.
Classify each spreadsheet by the job it performs
A workbook can be a report, a planning model, a transaction log, or all three. Separate those roles before deciding what to replace. A report that reads approved data has a different risk profile from a sheet where several people independently change production quantities.
Ask the maintainer to demonstrate a normal shift and a difficult exception. Observe manual copy-and-paste steps, hidden lookup tables, macros, colour conventions, and adjustments made outside formulas. A red cell might mean “buyer has called the supplier,” not merely “late.” That meaning needs an explicit record if the workflow moves.
| Workbook role | What to preserve | Possible next step |
|---|---|---|
| Read-only production report | Useful filters and definitions | Keep it connected to approved data |
| Planner's scenario model | Allocation and sequencing assumptions | Separate proposed plans from committed changes |
| Operator transaction log | Event identity and correction history | Evaluate a supported capture interface |
| Informal exception list | Owner, reason, next action | Add an owned queue to the existing workflow |
Document who can change each rule and who understands it. If only one person can explain the macro, the first deliverable may be a rule inventory and recovery instructions. Rewriting undocumented logic before understanding it can turn a maintainability problem into an operational mistake.
Diagnose why the official entry path is being bypassed
In a small manufacturer's ERP replacement discussion, the author reported that scrap, rework, and checks were tracked outside the system because entry was too slow during production. Commenter u/RockCrawler1436 asked what the spreadsheets made usable and whether the entry problem was latency or cumbersome screens. Those are different defects with different remedies.
Observe the real action. Does the operator walk to another computer, search for the order again, enter the same identifier twice, or wait for a response? Does the available transaction even represent a partial completion or an off-standard operation? Staff may be bypassing a missing business concept rather than resisting data entry.
Measure the full path on the actual device, including login and error recovery. Avoid adopting a universal seconds-per-transaction threshold from a comment. A useful standard is one the production team has tested against the frequency and context of its own work.
Fixing a workstation, simplifying an existing screen, or changing when a transaction is recorded may solve the problem. A custom application becomes more defensible when a specific gap remains after that investigation.
Data integration and completing a task are different requirements
The fourteen-software manufacturing thread includes a nested reply observing that API-connected systems can still require fourteen logins to accomplish useful work. The original post describes duplicated histories and uncertainty about which record is correct. The login observation is a commenter's criticism, not a measured count across manufacturers.
Use it as a demonstration requirement: ask an operator to complete one task from beginning to end. Can they identify the order, consult the right instruction, report the event, and see whether it was accepted? A dashboard that links to five other applications may help discovery while leaving this transaction path unresolved.
A focused interface should preserve the identity of the person acting and respect destination permissions. Reducing repeated login friction does not justify shared credentials or indiscriminate write access. Where an action must remain in another application, make the handoff and return status clear.
Require the project to name the old action it will retire. “Connect SAP to a database” describes plumbing. “Stop re-entering this approved operation result from the shift sheet” describes an outcome staff can verify.
Choose one production event for the first build
Begin with a frequent event that has a clear owner and destination. Material issue, material return, operation progress, or a corrective-work request can each be a bounded starting point. Combining all of them immediately increases the number of rules that must be agreed and tested.
For the chosen event, identify the order, operation, item or lot where relevant, quantity and unit, location, actor, and time. Distinguish the time work happened from the time it was entered. If the interface proposes defaults, show the ones that affect the transaction before confirmation.
Represent exceptions explicitly. A material move between jobs, a damaged component, and an incorrect earlier entry are not interchangeable quantity adjustments. Each should follow the plant's approved process and preserve why the change occurred.
Keep submitted, accepted by the destination, and rejected states separate. “Saved on tablet” should not tell a planner that the ERP balance has changed. Operators need a clear indication of whether further action is required, and the integration owner needs a queue for rejected transactions.
Work through partial completion, scrap, and rework
Consider a hypothetical order for twenty assemblies. During the selected operation, sixteen units are accepted, two are scrapped, and two await rework. The example stipulates these categories; your plant must define how its own process records them.
A single field saying “quantity complete: twenty” loses useful distinctions. Conversely, recording sixteen complete and leaving the other four unexplained makes the next shift reconstruct what happened. The capture interface should preserve the three outcomes and their relevant reasons or references.
If the two reworked units are later accepted, record that transition against the earlier event or identified units. Do not count them as two entirely new assemblies without the relationship. The approved ERP or MES transaction design determines how the records and quantities change.
Also test correction. If the operator entered the wrong scrap quantity, the reviewer should see the original event and the correction. Silently editing yesterday's total makes a later discrepancy difficult to explain. The aim is an intelligible history, not an assertion that every plant needs the same accounting or production model.
Keep work instructions tied to the operation and revision
A link to a shared folder can still leave the operator choosing among several PDFs. The handoff should identify the instruction approved for the relevant operation and show its revision. Preserve the document owner and the process for withdrawing a superseded instruction.
Decide what happens when instructions change after a job is released. Some changes may apply to future orders; others may require review of work already underway. The responsible engineering or quality role must define that rule. The application should not infer it from the latest upload timestamp.
Show a clear route for reporting an unclear or missing instruction. A screenshot or note can support that report, but the operator should not have to invent a replacement procedure to finish the software task. Keep the question connected to the order so the next shift can see it.
This requirement can often be met by existing execution software. Validate the actual operation-to-document relationship in a demonstration rather than assuming a document attachment feature solves revision control.
Compare native features, a focused app, and a broader MES
The discussion about ERPs making daily manufacturing easier contains strong disagreement. Some commenters dismiss ERP shop-floor functionality; u/No_Fault_6618 describes using a heavily customized system, and u/r2k-in-the-vortex emphasizes implementation and process quality. These opinions do not establish that every ERP is unsuitable or that every plant needs an MES.
SAP's own Production Operator Dashboard training describes configurable operator interfaces for recording production, consulting work instructions, collecting data, and consuming inventory in SAP Digital Manufacturing. That is a concrete existing option to evaluate. It does not mean the Reddit author's SAP installation already includes or is configured for that product.
Compare candidates using the same event and difficult cases. Configure the existing product when it covers the workflow adequately. Consider a focused app when the gap is limited and supported integration access exists. Evaluate broader MES scope when the requirements are tightly coupled across execution and quality and would otherwise require rebuilding substantial functionality.
Ask who maintains mappings, screens, permissions, and updates after launch. Include those responsibilities in the decision alongside implementation and licensing costs; do not rely on an unverified price or a claimed deployment time from a forum.
Low-code still needs realistic data and connectivity tests
The Microsoft tools mentioned in the MES thread make low-code a plausible option to investigate. They do not establish that a form backed by any data source will behave correctly for every production dataset.
Microsoft's Power Apps delegation guidance explains that nondelegable queries can process only a limited portion of a data source: the default is 500 records, configurable up to 2,000. A search can therefore miss a valid record if the app's query and source are not designed appropriately. Test with representative volume, not just a small demonstration list.
Microsoft also documents offline-first support for Dataverse-based canvas apps. Verify the supported client and limitations for the chosen design. An app opening on a tablet does not by itself establish the offline behavior you need.
Test disconnection during submission, repeat taps, device restart, and conflicting updates. Show pending events to the user and define what work can proceed with stale data. The right answer may be to stop a particular transaction until connectivity returns rather than promising every operation works offline.
Use maintenance as a focused boundary case
The small-team CMMS discussion describes preventive maintenance in Excel working reasonably well while corrective work gets lost in calls and emails. It is a useful example of a narrower problem than replacing the whole maintenance process.
Commenter u/SUNFACRANE recommends demonstrating the system with a technician and paying attention to mobile use and work-order closure. Other replies prefer different CMMS products; one argues for improving spreadsheets. Several vendors disclose their affiliations. The thread supports testing adoption and the close-out path, not declaring a product winner.
A first scope could therefore capture a corrective request against an asset and track ownership through closure, while retaining the functioning PM process initially. Keep production reporting and maintenance requests distinct even if they share the same device. A machine interruption can create related records without turning a maintenance technician's note into an approved production disposition.
Retire the old tracker through a controlled handover
Run a bounded comparison with the established process. Select representative orders and agree which source owns each field during the pilot. Avoid letting two teams independently edit competing totals without a plan to reconcile them.
Record mismatches and their cause: missing event, wrong unit, duplicate submission, changed routing, or delayed destination confirmation. Resolve the cause before expanding. A total that matches only after an undocumented manual adjustment is not evidence that the workflow is ready.
Agree an exit condition for the duplicate tracker. For example, the selected event types must be captured, corrections must remain understandable, and designated staff must be able to resolve failures. Preserve an appropriate archive and recovery process, then remove the unnecessary entry task.
Measure the time spent recording work, correcting it, and rebuilding information for the next shift. Include support effort and false exceptions. More submitted forms is not the goal; a more complete operational record with less reconstruction is.
Scope a shop-floor capture project with Pavado
Pavado can help document the logic in an existing Excel/VBA tracker and implement a focused operator interface, barcode workflow, supported system integration, or native configuration. AI may help with a specific document task, but material transactions and permissions need explicit business rules.
Bring one tracker, a redacted work order, and an example of a physical event that is recorded late or in several places. The first useful deliverable is a rule inventory, event map, prototype of the operator action, and acceptance cases covering corrections and failed submissions.
Use the shop-floor workflow review on this page to describe what your team has to enter twice or reconstruct at shift change. A worthwhile first build preserves the rules that keep production moving and removes one avoidable recording burden.