SAP Environmental Health and Safety Management (EHSM) comes packed with features to track everything from incidents to safety observations.
At ConvergentIS, we often work with our clients to bring the most important features to UI5. Here are some of the things we’ve learned along the way that can help when implementing a UI5 solution.
1. Get The Design Right — Upfront
While it can be tempting to jump in and copy all of the fields available on the current user interface to the new application, take this opportunity to simplify and streamline both the application and processes surrounding the app. Throughout the lifetime of the app, different requirements can emerge that necessitate mandatory fields; as more time goes on, these requirements become outdated and irrelevant. We hear clients say things like, “We’re forced to enter that field, but we don’t use it anymore”.
We work to gather stakeholders as well as both frequent and infrequent users of the app to understand the entire picture. After that, we move quickly from the current state and begin mapping out where want to be.
Ultimately, there’s always a trade-off between what details need actually be reported and the speed at which the data can be entered.
2. Define The Platform
Once the problem is understood, it’s important to consider how incidents and other safety observations will be tracked. Some important questions to consider are:
Will users always be near a connected computer or will an offline application be required?
Will there be experts who help scan or enter in physical cards or can that data be entered on a user’s own device?
3. Plan How To Get The Data To The Application
The Business Object Processing Framework (BOPF) is the programming engine under the hood and it is extremely powerful. However, anyone who’s worked with the BOPF can attest to the challenges of getting up to speed and learning how to use it most efficiently.
It’s important to take time to map out how the BOPF data structure will map to your oData. Consider building out reusable components so that custom code isn’t required for every single dropdown or lookup and build your oData so it can be expanded to future requirements. While it can be a large amount of up-front work, mirroring the structure of the BOPF will pay off in the long term.
Shameless plug: If you don’t want to build the BOPF to oData mapping, we have an accelerator package that helps manage all of the locking, errors, creation and saving in oData.
4. Take a look at how things can be pre-populated for users
Out of the box EHSM doesn’t auto-fill too much. We’ve found that we can accelerate the entry of something like an incident by defaulting information (country or location) and reducing choices (i.e. time zones) so that the user doesn’t have to filter through hundreds of options.
Also, we’ve found that systems with a HANA backend can support a fuzzy search using ABAP CDS views in order to speed up the users’ lookups. On systems without HANA, consider sending and caching frequently used fields