We all know that SAP hasn’t made a name for itself as a paragon of software usability. Those of us who are end-users of SAP have known this from the day we first set to task from SAP’s Easy Access screen.
The good news is that the market has responded in a big way to the need for usable ERP software. The bad news is that the road to achieving a highly usable SAP is not easily navigable. To add to the challenge, there are a lot of usability vendors who are competing for your business (including SAP). Most talk quickly, and many make the same claims.
Unfortunately, there are no magic bullets. Therefore, it’s worth it to take the time to understand the subtleties of any given solution and how well they align with your specific situation and needs.
With that in mind, the goal of this post will be to demystify the usability journey by presenting objective facts about SAP’s mainstream usability solutions in contrast with our own, Liquid UI.
Starting the Journey
Once an enterprise has decided to pursue an SAP usability solution, there are two major components to consider:
1. Figuring out what to build
2. Figuring out how to build it
Let’s break that down a little bit.
Briefly, to the first point, figuring out what to build means identifying pain points, gathering stakeholders and end-users, using prototypes and user stories to build, test, and rebuild mockups until they serve real needs of real end users in real use cases. It’s design thinking, and it’s not proprietary. It just involves open conversations and empathy.
The second point, which is figuring out how specifically to architect the usability solution, is often the more complicated process. These are not decisions which are made in a vacuum -- they are made amidst complicated IT landscapes with real budgets and real timelines. Here are a few tips we’d like to share with you after having facilitated SAP usability solutions for almost 19 years:
Understand what your end users will be doing and where they’ll be doing it.
There is unfortunately no one-size-fits-all for SAP usability. The same solution that works beautifully for Finance or BI will not necessarily perform for Plant Maintenance or Sales & Distribution. Once you’ve decided which end user group will benefit the most from a usability solution, ask yourself:
Are the target user group’s transactions high volume, low volume, or do they contain complex controls (a dynamic UI)?
Low volume (e.g. lookup or BI: transaction completed one or two times per day): Good news! Most solutions are viable solutions if transactional volume is low.
High volume (e.g. Notifications, Work Orders, WM, transactions completed 10-50+ times per day): For these types of transactions, a shorter, non-HTML technology stack is advantageous as it mitigates latency-associated productivity loss, which undermines the gains of simplification.
Complex controls (e.g. VA01): Consider commercial sales reps, who must navigate between several SAP modules, tracking a multitude of siloed and disparate information, in order to take a sales order. This is a common scenario that begs for mistakes to be made. Also, like high-volume scenarios, certain complex controls can be slow to render with HTML or via ITS. Both process inefficiency and technical latency contribute to productivity loss and customer dissatisfaction.
Will the target user group access SAP via SAPGUI, Browser, or Mobile?
SAPGUI: Fast and secure, many usability solutions do not address the SAPGUI use case, which, to date, still represents >90% of all SAP ERP transactions
Browser: Web browsers are ubiquitous. Flexing this as a strength, there are several browser-based options on the market. However, these are typically only well suited to low volume transactions, and HTML latency is a common frustration. Also, many browser solutions do not natively extend to mobile.
Mobile: The trend toward enterprise mobility is very real. However, many mobility solutions remain browser-based, introducing problematic latency issues. Native mobile apps are faster and more powerful. While they are gradually becoming more common, only a few offer the ability to easily customize for when one size does not fit all. Also, security and device management are concerns for any mobility initiative.
Here’s a visual breakdown of how different market solutions fit specific use cases:
Understand what resources will be required to develop and maintain your usability solution.
A few things to note:
1. Solutions which alter the technology stack often require ABAP resources
2. Solutions which also require OData services and HTML5 (e.g. Fiori) require separate resources for each layer
3. Kernel dependency typically means extensive testing whenever an upgrade or patch is issued
4. Developing z*transactions or modifying Fiori apps means that SAP will no longer provide support for these transactions
Free solutions typically aren’t free
Solutions like Fiori, which claim to be free, often bring layers of embedded and unforeseen cost. Be sure to fully consider the following hidden costs of any "free" solution:
Training
1. This is the most elusive budget item which is consistently underestimated
2. Touchpoint specific solutions can require developers to learn new tools for different environments
Maintenance
1.When a solution is kernel based, defect repairs require service packs and kernel upgrades, which can make a solution inflexible and brittle
2. Addressing inflexibility incurs additional costs in terms of testing, redevelopment, and at its worst, downtime
Implementation
1. Migration to a compatible version of SAP involves consultants and partners
2. When an out-of-the-box solution doesn’t quite fit a business need, development is required to re-build business logic
3. ABAP can still be required in many cases
Understand the impact on your technology stack
As mentioned above, understanding what your end users will be doing and where they’ll be doing it will determine how much additional technology stack can affect ROI. Be sure to consider the long view of your SAP usability initiative. Are there any user groups with high transaction volume workflows on your usability roadmap?
Get clear on what your SAP roadmap looks like, and make sure major infrastructural changes are warranted.
If you’re on ECC 6 or earlier, the move to upgrade is not a small one. Make sure the move is warranted by more than just mobility or SAP usability, as these can be easily achieved with your existing SAP landscape.
To sum things up, here’s a breakdown of a few major market offerings for addressing SAP usability, including some of their features and limitations:
Learn more with us!
We’re fresh on the heels of TechEd 2016 in Las Vegas, where much of the discussion revolved around SAP usability and the new products that support it. As the dust settles post-convention, many are left with questions about how to turn their vision of SAP usability into an actionable plan.
We totally get it. And we want to help!
We’ve helped companies achieve SAP usability for almost 19 years through our innovative, non-disruptive, front-end technology. Our product continues to evolve with the marketplace, functioning as either a stand-alone usability platform, or in complement to other usability solutions, like Fiori.
If you or your end users struggle with SAP usability, we’d love to talk and find out how Liquid UI can help you meet your usability objectives!
