Broken Signals (Part 2): Why connected apps won’t work for operations
In part 1 of this blog I discussed why companies operating in industrial environments cannot, and should not, expect a reliable wireless connection for their operations staff.
Apps for operations require up-to-date enterprise data such as work orders, equipment status, certification information etc. This data is typically stored in large, complex Enterprise Resource Planning (ERP) systems.
Many ERP companies have developed mobile solutions that connect directly to the ERP system, in a similar manner to a desktop PC. While this often works well in retail environments, the connected assumption doesn’t hold for the kind of industrial operations environments described in Part 1.
Long delays caused by frequent connection timeouts and failures, mean users resorting to using paper instead, or in the worst case, not being able to work at all.This strong dependency on an ‘always on’ connection renders the application completely useless when no connection is available. However, complete loss of connection is not the only concern. Degradation in the quality of a Wi-Fi or GPRS signal can make a connection-dependent application extremely frustrating to use.
Spartan’s Phalanx App Store for Operations has been built from the ground up to work even when no connection is available. Whether fully disconnected for long periods or just drifting in and out of connection, Phalanx users are able to continue working uninterrupted. This is enabled by a number of key design principles:
• Cache operational data on the mobile device for offline use. If your operations require an up-to-date cache, then do this as often as possible. Otherwise this should be done at a rate that’s economical and sufficient for your operations; relatively static data can be synchronized less frequently than data with a high churn rate.
• Queue server updates while offline for later delivery. The user should be able to continue working even when offline, safe in the knowledge that the server will be notified of work progress when the connection is re-established. This is what we expect from other apps that support disconnected mode (email for example).
• Monitor the state/quality of the connection. Use this to guide decisions on when to fall back to your data cache or prefer to hit the server for fresh data. Quality metrics can also help to streamline the user experience by avoiding calls that are likely to lead to long delays as heavyweight server calls time out.
• Support offline creation of work. If a mobile user is not able to connect to receive work orders, allow them to create work on demand. This work can be reconciled later, based on business rules on the server or at the ERP interface.
These principles are independent of the type of mobile device and the technology used to build mobile apps. Whether your device base is iPhone, Android or Windows Mobile, whether you support Bring Your Own Device (BYOD) or deploy specialized rugged industrial devices to cater for your harsh environments, whether running device native apps or mobile web apps, these principles provide the foundation to support disconnected operations.rk on demand. This work can be reconciled later, based on business rules on the server or at the ERP interface.
For a case study on how Balfour Beatty replaced paper with mobile apps, barcodes and RFID tags, download by clicking here…