operational realities
From pilot to production: why monitoring and fallback matter in factory software
A field note on why factory software pilots need monitoring, alerts, fallback processes, and operational risk controls before replacing critical manual workflows.
A pilot project can prove that a workflow works. Production has a different standard.
In a factory time-tracking pilot, a tablet issue raised the right operational question: if the mechanical punch clock is removed, what happens if the tablet stops working?
Operational constraint
At the pilot stage, a bug is inconvenient. At the production stage, a bug can affect payroll. That changes the nature of the project.
Several risks become important: employees may not know what to do when the kiosk fails, the owner may discover the problem too late, the tablet may lose network connectivity, the tablet may need WebView or Chrome updates, the app may work from a phone but not from the kiosk, and a single tablet can become a single point of failure.
Why this mattered
The next step was not only to fix the immediate tablet issue. The next step was to reduce operational risk before replacing a critical manual process.
A working pilot answers whether the workflow can work. Production asks how the business knows it is still working, who is alerted when it fails, what the fallback is, how fast recovery can happen, and what happens if payroll is affected.
What we learned
The solution is not only better code. The solution is better operational monitoring.
Technical monitoring and business activity monitoring catch different problems. A tablet heartbeat can tell whether the device is alive. Activity monitoring can tell whether the workflow is actually being used.
Implementation approach
The kiosk tablet should regularly contact the backend and report whether it has network access, whether WebView is healthy, whether the device is plugged in, and whether the battery is low. If the tablet stops reporting or remains on battery too long, alerts become possible.
Business activity monitoring can also detect the absence of expected activity. For example, if the factory shift has started and nobody has clocked in or started an activity, the system can flag a possible issue while accounting for breaks, weekends, holidays, and planned shutdowns.
Business impact
The goal is not to pretend failures will never happen. The goal is to make sure failures do not stop operations.
A production factory should avoid relying on a single kiosk. At least one fallback option, such as a second tablet or temporary manual process, should exist before a critical manual workflow is fully retired.
Workflow impact
- • Clearer readiness criteria before replacing a manual process
- • Earlier alerts when a kiosk stops reporting
- • Business-level detection when expected activity is missing
- • Reduced single-point-of-failure risk
- • A more realistic path from pilot workflow to production system
Proof assets
Planned visual examples
Next step
Need to modernize a workflow like this?
DEVTom helps SMBs build operational systems that fit real work: paper replacement, shop-floor capture, project visibility, dashboards, and internal tools that match how the business actually runs.
Start a conversationFAQ
Why is monitoring needed after a pilot?
A pilot proves the workflow can work. Production needs evidence that the workflow is still working and that someone will know when it fails.
What should technical monitoring catch?
It should catch device check-ins, network access, WebView health, power state, low battery, and failure to reach the application.
What is business activity monitoring?
It checks whether expected workflow activity is happening, such as clock-ins after a shift starts, while accounting for breaks, weekends, holidays, and planned shutdowns.
Why keep a fallback process?
A fallback prevents a device or network issue from stopping operations or affecting payroll when a manual process has been replaced.