10 Things you should think about when selecting a mobile solution for SAP PM/CS

When it comes to the SAP modules PM (plant maintenance) and CS (customer service) it is kind of a no-brainer to bring the systems directly into the hands of the user in front of the asset in form of a mobile application. There are many drawbacks with paper/pen on the one side (media breaks will lead to a slower process, users are not as well informed as they could be, and typing the data into SAP later leads to errors) and with the SAP GUI on the other (complex user interface, works only online with a good network connection, walking back and forth to a desktop PC costs time).

Once the decision is made to introduce a mobile application for the field workers, the right solution must be picked. This is not an easy endeavor, as SAP alone currently offers four solutions for this case (SAP Work Manager, SAP Asset Manager, SAP Fiori and SAP Field Service Management).

The following article will discuss the ten most important things that you need to consider when looking at mobile solutions for SAP PM/CS.

1. User Friendliness — can you work with it?

In my opinion, the most important criteria for any software — how easy is it to work with it? Rolling out a mobile app to field works often means dealing with a highly diverse user base. You face people for which it is easy to work with software and others who hate it.

Make sure the application is not transaction-based but follows the natural flow of how the users work. Check how many interactions are required to reach important information or to create new data like time and material confirmations.

The application should contain the information that is important to the user, not more. Anything on the screen that is not required is distracting the user (look at the SAP GUI, users are overwhelmed with all the fields presented to them).

2. Is the solution responsive and platform-independent?

Nothing beats the usability of a native mobile application, written specifically for the target device and operating system. However, in the case of enterprise solutions, there are multiple reasons why not going this way.

Having a native application is limiting the device selection to just one operating system. If a 2nd device/OS is added, a rewrite is required. But let’s say that the software provider is offering different native apps, tailor-made for different operating systems, the UI will be different. This makes the support via the IT department more difficult. People switching devices have to re-learn how to use the app. Because of these reasons, I am always leaning to solutions that have the same user interface across different operating systems and that needs to be developed only once. One of the most common frameworks for platform-independent apps is Apache Cordova; it is used as the basis for many solutions for SAP PM/CS.

Also, a good app for your field service technicians should be responsive. This means it should automatically adjust to the screen size of your device and run without changes on smartphones, tablets and laptops. A common technology for a responsive user interface is for example SAP UI5.

3. Does the solution cover all your functional requirements?

When looking into a solution for mobile plant maintenance or customer service, you need to match the existing functionality with your requirements. Here it is important to plan ahead — at the beginning, it is maybe enough to just have access to functional location and equipment header data, but you might require access to characteristics or measurement points in the future.

I recommend making a plan and roadmap beyond the initial go-live and see if all of this is available in the products that you evaluate.

4. Multi-Language support and support for different user groups?

If you plan an international rollout of the mobile app, it needs to be able to support multiple languages. This comes in two dimensions: First the data from SAP — can order types, user status, equipment descriptions etc. be displayed in the language of the user? And second, are the labels on the UI available in different languages. Also, check the number and date format for different regions so that users do not get confused.

Make sure you are easily able to change the labels within the application. If your users are talking about assets or machines instead of equipment’s, it should be possible to rename it.

5. Scalability, data volume and performance?

Again, you must plan ahead. Think about the maximum number of potential users and the maximum data volume for the new mobile solution.

Adding more users means more stress to your systems — if you have a middleware, make sure it can handle the number of concurrent mobile users. If there is no middleware and the devices connect directly to SAP, check how much additional load each user is adding to the system. You might need to add more SAPS to your SAP instance.

When it comes to the data volume, requirements can be quite different. Some organizations only have a small number of functional locations and equipment’s, others have a lot. Take the sub-objects also into account. 5.000 equipment’s might not seem a lot, but if you have 10 characteristics for each of them, we talk about 50.000 records. Can the mobile solution (and its middleware) handle that?

To keep the data volume per device as small as possible, make sure the solution can filter data between SAP and the mobile device to send the minimum amount of data.

Performance is a very important factor and an essential part of the user experience. Of course, the interaction with the UI (save data, screen changes, searches etc.) should be nearly instantly. In the case of an offline application, the synchronization should be fast as well. Check the solution to understand:

• How can data be restricted/filtered?
• Can objects/tables that are not required be disabled?
• Can attributes/fields that are not required be hidden?
• How is the data sent over the network? What format is it in? Is it zip compressed?
• If attachments like photos or documents are sent, can they be compressed?

From my experience, solutions with a middleware can be faster than a direct connection to SAP.

6. Offline support — working without network

Another important aspect is the availability of the application. Apps can be categorized the following way:

• Always online - all actions and business logic are executed on the server-side. No connection, no access. Most browser-based applications like SAP Fiori are in this category.
• Partially offline - the application has a cache for a limited amount of data. This allows the user to do small things like setting a user status or creating a time confirmation for a previously loaded order. But access to large data sets would not be possible.
• Full offline support - the application has a datastore on the mobile device. All required data and all functions are available even without a network connection. In general, full offline applications have a better performance as data is stored on the device and does not need to be requested over the network.

The right application form depends on your situation and how critical the process is for you.

7. Configurability, re-use of SAP customizing

Mobile apps should always depend on the customizing of your SAP PM or CS module. Customers usually spent a lot of time to customize their system to their requirements. You do not want to re-do all of this a 2nd time for the mobile world. If you configured the notification types in SAP, the mobile app should automatically take them into consideration.

On the other side, the mobile app should allow you also to do additional configuration that goes beyond the SAP customizing. What functionality should be available (should the user be able to create orders and equipment’s on the mobile device?), what screens, tabs and fields should be displayed?

The more you can remove from the app, the better. I am following the philosophy that the best user interface is one that does not exist. At the end, the technician should work on the asset he is inspecting, not looking into his smartphone or tablet.

Check these two points when you look for a mobile app.

8. Technology and Enhancements

It is important to check the technological foundation of the mobile solutions that you evaluate. I think you should make sure that everything is built as much as possible on open standards and not on proprietary technologies.

Open standards are important because it will be much easier to find skilled and experienced resources to support you with the installation, implementation and the support of our mobile landscape.

It is also important that a mobile application is not written in stone. It must offer a way to change and enhance the standard functionality to optimize it for your specific process. Maybe you have z-tables or -fields in your SAP system that are essential for you. It must be possible to include them also in your mobile app.

9. Reference Customers? Experience of your implementation partner

Not only the mobile software is important, but also the people that will implement it. Enterprise mobility is a special field and it requires a lot of know-how in this area to implement a solution successfully. Check how many projects the implementation partner has done in the area of mobile PM/CS. Are there reference customers you can talk to?

10. SAP Integration, S/4HANA support, certification?

Last but not least, how is the SAP integration done? Are you looking at a solution that was made with SAP in mind, or is it one that is generic and has a loose integration with your ERP system?

I always recommend that SAP should be the leading system and that the mobile app is just another user interface for it. I am not a big fan of field service solutions next to SAP that just integrates a little bit. Often this requires double maintenance of master data and customizing.

Even if you still run ERP 6.0, you should think ahead and make sure that any new software that you implement is supporting S/4HANA.

As a final thought, look at the available solutions and ask if they are SAP certified. This will give you the guarantee that an addon you need to install in your system will not cause any harm.

Here you have the in my opinion ten most important things you need to check when looking for a mobile solution for your SAP PM/CS. If you still need help, feel free to get in touch with me via post@alexander-ilg.de