Enterprise Mobile App Development: Use Cases and the Project Process

What is an enterprise mobile app?

An enterprise mobile app is one a company builds to run its own processes from a phone or a handheld terminal. Its users are known: the field sales representative, the warehouse operator, the service engineer, the auditor or the manager who approves.

These apps do not work in isolation. Their value comes from data entered where the work happens reaching the central system at the same moment. The field representative enters the order while standing with the customer, and nobody types it again at the office.

How it differs from a consumer app

A consumer app addresses a wide, undefined audience and is measured by downloads and time spent. In an enterprise app the number of users is known, and the app is successful to the extent that it lets the work get done.

That difference shows up in the design. The priority is completing a transaction in as few steps as possible without error: a warehouse operator wearing gloves needs large targets, while a field representative needs the step they repeat dozens of times a day to be short.

Distribution differs too. An enterprise app can be published in a public store, or it can be delivered only to company devices through enterprise distribution. Store rules and processes change over time, so this heading is planned at the start of the project against how things stand then.

Field sales and customer visit apps

For field teams the problem a mobile app solves is a clear one: what is captured at the customer is not re-entered at the office in the evening. The visit plan, customer history, current price list and stock availability are on the phone; the order is entered on the spot and lands in the central system as a document.

Collections, visit notes and photographs are gathered on the same screen. What is known about a customer then accumulates in the system rather than in a representative's notebook.

Warehouse, barcode and handheld terminal apps

In the warehouse a mobile app usually runs on a handheld terminal. Goods receipt, put-away, picking, transfers and counting are done by scanning barcodes, and the stock movement is created at the moment of the transaction.

The critical requirement here is accuracy: which item a scanned barcode maps to, which record is selected where serial or batch tracking applies, and what the system does on a mis-scan are all defined up front.

Technical service and maintenance apps

For service teams the app takes the work order into the field. The engineer sees the job assigned to them, the address, the unit's fault history and its warranty status on the phone.

When the job is done, the work carried out, the parts used and the time spent are recorded, and the customer signs on the device. Once that is written back to the central system as a service call and a stock movement, invoicing rests on the record rather than on what anyone remembers at month end.

Manager approvals and field data capture

For managers the most common use of a mobile app is approval. Pending purchase requests, discount exceptions or leave requests are listed, the decision is taken on the phone and the process moves on without waiting.

In audit and field data capture scenarios, inspection forms are filled in on the device. With photographs, location and time added to the record, what you end up with can be verified afterwards.

iOS, Android and the platform decision

Which platforms the app runs on and how it is built is a decision made against the requirements. No single approach is better on every project.

We look at these headings when deciding: which device capabilities the app will use (camera, barcode, location, printing), the expected performance, whether offline working is needed, the target platforms, who will maintain the app, and the scope of the project.

A warehouse app doing heavy barcode scanning and a manager's app used a few times a month do not have the same technical requirements. So we make the platform decision from the project's requirement list rather than as a general preference.

Offline working and synchronisation

In a warehouse, on a production floor or at a customer out of town, the connection is not always good. If the app is expected to keep working in those conditions, it has to hold data on the device and send it once connectivity returns.

The real work in that scenario is not the transfer but managing conflicts: preventing the same record being created twice, deciding which version wins when the device and the centre disagree, and defining where records that could not be sent will collect.

ERP integration, permissions and security

Behind a mobile app there is usually an ERP or another corporate system. Item, price, stock and account data are read from it, and transactions created in the field are written back. On the SAP Business One side we make that connection through the service interfaces shipped with the product.

Permissions matter even more on mobile: each user should see only their own region, their own warehouse or their own customers. Because devices get lost, session management, protecting data held on the device and being able to cut access remotely are also part of the design.

The project process

Mobile projects run one step longer than desktop or web projects, because testing on real devices and distribution are stages in their own right.

• Discovery: which user does which job, under what conditions?
• Scenario design: screen flows, and how many steps the most repeated transaction takes
• Interface and integration design: which data is read and which transactions are written back
• Development, with working versions shown at short intervals
• Testing on real devices: barcode, camera, location and offline scenarios
• User acceptance testing: the person who does the job trying it in the app
• Distribution: store publication or enterprise distribution
• Go-live, training and support through the opening period

Requirements that drive the cost

What enlarges a mobile budget is usually not the screen count but the technical requirements below. Establishing early which of them are genuinely needed keeps the scope predictable.

• Offline working and synchronisation
• Barcode, QR, camera, signature, location or printing
• Number of supported platforms and the range of devices
• Role count and permission rules
• Number of systems integrated with, and the direction of data
• Notification scenarios
• Distribution method and corporate device management
• Post-go-live maintenance and keeping up with platform updates

Conclusion

The success of an enterprise mobile app depends far less on how the screens look than on whether the job can be completed in full in the field. That, in turn, comes down to how well the app fits the system behind it.

If you are considering moving field, warehouse, service or approval processes to mobile, we can work out together what happens on the device and what stays at the centre.

Frequently asked questions