To App or Not To App…

From a business perspective, I see two major benefits in building our own app: ease of use and paperless operations.

We want to build an app in a way that fully supports the process flow. When you need to execute a specific workflow using the standard SAP GUI, it often involves initiating multiple transactions in succession and entering information in complex screens. This requires extensive user training. Therefore, it is preferable to perform screen actions in an intuitive manner, allowing the process flow to be followed seamlessly, without the user even noticing. A well-defined process and procedure description are essential before embarking on the construction process.

The second significant advantage of an app is that it can typically be used on a mobile device. Using SAP GUI transactions on a mobile device is usually not successful because these transactions are not optimized for paperless use. In the case of SAP Plant Maintenance (PM), transactions assume that a paper version of a work order is available. All paper-based registrations are then duplicated in the SAP system afterward. This final step can be eliminated by not performing administrative tasks on paper initially but by registering information directly on-site in the SAP system using an app.

When considering these two specific benefits, it doesn’t make sense to build apps to support all (in this case) Plant Maintenance processes. Experience has shown that the apps that initially provide the most value are as follows:

1. An app that supports the reporting process for malfunctions, and
2. An app that assists the technician during the execution and feedback of maintenance tasks.

All other processes in the Plant Maintenance workflow can be smoothly executed using standard SAP GUI transactions. If you still prefer not to use SAP GUI, it’s better to opt for a complete mobile solution or use standard SAP Fiori apps.

For a large pharmaceutical organization, newITera was tasked with building these apps as part of an optimization initiative. But what needs to happen before you can start building them?

First and foremost, a decision needs to be made regarding the architecture. It is crucial that the apps are easily accessible. This is especially important for the reporting app, as it needs to be used by employees throughout the entire company. For this client, the decision was quickly made to build the app in SAP Fiori because they already use the SAP Fiori Launchpad to support other business processes. For the average user, it won’t be a problem to find and launch the reporting app. The technician app will be used by a much smaller group but is also easy to locate. Furthermore, authorizations can be used to control which users can see and use which apps.

Additionally, as mentioned earlier, it is an absolute requirement to create a well-defined process and procedure description. It is of utmost importance that all requirements are clearly and comprehensively described and that a technical solution is available for them (such as specific standard software for barcode scanning or single sign-on checks).

What is involved in creating a maintenance report? And what challenges arise in creating a proper report? You want to be able to use the app on location. Recognizing and locating the relevant equipment in the system is often a challenge. Placing barcodes on the equipment and ensuring that they can be scanned via the app provides a good solution to link the report to the correct equipment. Additionally, mobile devices allow for the immediate capture of photos of the situation, which can be attached to the report. For the follow-up of the report, it is easy for the user to see the status of the report at a glance. This prevents the need for additional communication with the maintenance department.

The second app is more focused on providing information for the purpose of the tasks a technician needs to perform and reporting hours, materials, and findings. The technician should be able to easily locate the assignments assigned to him. The information that he would normally see on a work order form should then be accessible through the app. This solves the problem of having additional information available on-site. All digital documents associated with the installation, equipment, or work order can be displayed via the app.

Some of the functionality requested is straightforward and user-oriented, but other functionality is influenced by internal, local, and even international regulations, of which the requester may not have specific knowledge. For example, consider the requirements and standards for electronic signatures (is a ‘DHL scribble’ sufficient, or does a username/password check need to be performed?). In such cases, experts from within the organization may need to be consulted to specify the specific requirements related to regulations. The goal is to avoid building an application that cannot be used because it cannot be validated.

The answer is no. User-friendliness and intuitive use have not been taken into account yet. What does this mean? The goal is for a user to be able to use the functions in the app correctly and at the right time with minimal or no training. If the user does not immediately see what to do, the effectiveness of the app will decrease significantly. In the worst case, the app may not be used, even though all the functionality is available.

This requires defining specific screen layouts and automatic steps for actions within the app. A term often used in this context is “user experience.” In addition to functional and technical expertise, newITera can provide this knowledge. Our experts, based on feedback from functional and technical consultants, create a mock-up to provide a sense of how the app will support the process. This proposal is discussed and potentially adjusted. The real application is then built based on the mock-up. Once the initial version is available, it can be used for a shake-down. Sessions are conducted with potential end-users, where a structured approach is used to observe how they use the app, which can even be done online. Subsequently, expectations and results are discussed through workshops in small groups. Based on all the findings, a final version is developed. This version is made available to end-users during an upgrade release of SAP. After the app is put into use, it falls under the application life cycle process.

Apps also require continuous improvement. Bugs can be reported and promptly addressed. The business is encouraged to request new functionality. Upon approval, the development of new functionality is scheduled for a specific internal SAP release. Not all requested functionality will automatically be available for the next release. Prioritization is based on added value and available development capacity. In this way, newITera, together with our client, ensures that the apps we develop for them perform optimally, have a high level of user-friendliness, and support the business in the desired manner.

If you find this subject matter interesting and are ready to start building apps yourself and/or support in doing so, consider joining us. Please contact my colleague Luuk. He will be happy to provide you with more information.