Offline apps series: How to build an offline app successfully in SAP

Share This Post

Reading Time: 6 minutes

Blog 1: Discovery

Outline

SAP is changing its business suite, giving it a face lift with their new S/4HANA product and of course this will bring advantages in many ways to the SAP user community – especially for the office based users.

However, if the natural habitat of your SAP user is not the office or a desktop I still need something more to fill the gap:

“How can I get SAP to come to my workplace, where I happen to be?”

“How does the app work if I can’t ensure I have connection to my corporate network all the time?”

“I need tough devices when I am out and about. Which should I use?”

In the following blog I will reflect on my experience of building offline enabled apps for mobile devices. I hope to give you an idea how to approach the task and what to consider when putting the infrastructure and security into place and building the first mobile app using Neptune Platform.

I will provide 4 separate blogs which get you from discovery all the way to deployment.

Blog 1: Outset + Discovery
Blog 2: Design
Blog 3: Infrastructure
Blog 4: Build + Summary

Identifying mobile use cases

In the first blog, we want to understand the user or user group for whom we are trying to build the app and how to arrive at a design specification which can be taken further.

First and foremost, identify user groups which could benefit most from mobile apps. This is the most critical topic in mobile app development. Don’t try to build your first app to suit everyone. You should build a new app for every user group, otherwise your user acceptance will suffer.

One user scenario means one app.

There are generally following groups emerging:

Blue collar workers, i.e., users whose typical work place is not at a desk, for example maintenance technicians, production line operators or warehouse clerks. They are usually interested in work lists with jobs assigned to them personally.
Supervisors, i.e., users who monitor the technician workforce. They are interested in assigning work, monitoring progress and like to see performance dashboards to quickly identify problems when work is taking longer than expected.
White collar staff, e.g., managers who need to approve purchase or HR-related requests, who need analytical insights with dashboards and drill down functions.
Point of sales solutions like in retail for order take – especially when configurable products are involved or mobile sales forces who need to log customer visits, complaints or taken orders.
Service providers like public service staff, nurses or staff in education who provide citizen, patient or student services on site.

I am sure you can add many more examples.

List the scenarios. For each user group describe in a few words the scenario you are thinking of.

Describe the environment in which the app will be used. This is also an important qualifier to distinguish web app from mobile app development.

Is the user working in a rugged area like a shop floor or a warehouse, in shipping or transportation?
Is the user or on customer site, citizen site or generally outside the office?
Do we have access to a stable internet connection? Do we have a good 3G or wi-fi connection or are we in the countryside – like at a utility facility? Are there interferences expected – like in a boiler room or heavy steel constructions? Or no connection at all – like in a plane in flight? In other words, do I need to be able to run the app offline?
Is the site restricted or regulated? ATEX areas with intrinsic danger of explosions of environmental gas or solids, e.g., a petrol stations or flour mill?

Evaluate business value and effort. Provide high level estimates on how simple or complex the scenario of effort is, e.g., by naming the data objects and source systems which need to be involved. Rate them from low (1) to high (5) effort. Furthermore, provide high level estimates on your perceived business value – low (1) to high (5) as well.

Consider the following areas when evaluating the business value by addressing them in a mobile app:

Prioritise and roadmap all scenarios. Create a scatter matrix which describes effort and business value. This will give you a quick overview of where to start your journey towards a complete mobile app suite for your business. As a guideline, you would start with one or two of the apps in the “quick wins” quadrant.

Build the business justification for your first use case and seek funding.

User focus

For each scenario, focus on the user and build a complete picture of what is required.

Create a template and fill it in for the identified use cases and scenarios. Do it for as many scenarios as you think, start with any scenario and it should help you in understanding which one involves the most effort of change, but has the highest business value and will form the foundation of defining your first mobile app.

SAP’s framework of Design Thinking is quite helpful and they provide toolkits in their SAP Partner pages (if you got access to those). My version is certainly borrowing from it, but based mostly based on my 20-year experience of implementing and supporting SAP solutions. And if you ask me to distil into a nutshell, it is keeping the end-user at the forefront of your thoughts:

Describe a day in the life of the user.

Main checklist for me compromises of the following:

Who is the user we are addressing? Describe the user or user group clearly.

What does a day in a life of the user entail? Shadow the user’s activity. Let them explain their tasks end-to-end.

What are the issues and pain points? Reflect those issues in the broader picture of the organisation. Do we need to change the process before or after the affected user?

What are their touch points? Who is passing information to them, what information, how and when? Document the process flow clearly in swimming lanes with triggers, events and process steps.

Collect data samples, forms and printouts they use covering the most common processes as well as the obscure ones. They build the foundation of your test cases.

What would make the biggest difference to them?

Mobile Journey

As already mentioned, manage the functional scope of your first mobile app implementation. Draw the boundaries and pick a “low-hanging-fruit” from your list of use cases. After all, mobile app development is a journey and not a single event.

Map out the journey of which apps should be built first, even which features are nice and can be implemented at a later stage. The first apps will teach you how to design an app, how to implement it and allow you to learn from user feedback.

Map out the journey of many incremental app build and improvement projects.

Keep in mind that every app individually demands a short, focused project burst to turn your investment into business value ‘as you move along in your mobility journey’ – this is the best way to get management buy-in for continuing your journey and only requires a comparatively small amount of capital investment at a time.