Let’s get this out of the way: SAP software packages are functionally robust and capable, and are typically excellent solutions for a vast number of companies – companies with complex processes. There is no doubt about that.
However, the standard UI environment with an out-of-box SAP product appears to be an afterthought – and as such, frequently impedes a corporation’s ability to gain the user adoption that is so critical to justifying a project’s cost. This concern has arisen for me specifically with CRM and WebDynPro, but really, in nearly all of the SAP apps on which I’ve worked.
But all is not lost! The SAP applications can have the user experience as extraordinary as the processing power it provides. As user experience architect with specialized skills in SAP implementation, I know it can be done. However, I’ve encountered a number of commonplace mistakes that impede a project, and risking the successful development of a usable interface to properly match the solid backend.
Overcoming these hurdles begins first with expecting them, and then addressing them with the best interest of the business in mind.
Treating Usability Like a Feature
The classical manner of shepherding a robust user experience is to consider the user and the UI right from the start, making it an integral part of the software or web app. It’s simply not a viable approach to “add” usability as if it’s a component, and yet, frequently SAP implementations seem to require doing just that.
Here’s an example: with a large Pharma client, we tested some prototypes (options A, B, and “C” – which was really SAP CRM out of the box). During testing, we found that potential users were virulently opposed to an implementation of the SAP standard product. User comments even included a vehement “don’t you DARE give us that! It’s HORRIBLE!” Awkward moments there, as the SAP engineers had – basically – banked on using that “horrible” interface.
Unfortunately, Usability is not something that can be easily slapped on top of the application when the users reject it. It requires time, study, and informed design. The rule here: Compromise. If the initial battle is won (the SAP powers that be accept that usability needs to be addressed) and some usable features are deployed, the effort risks being an arduous and expensive one. However, some usability done right is better than no usability at all. It’s also better than a lot of work that gets thrown away because it doesn’t work.
Unfortunately, with great success the UX pro can become unpopular with some SAP engineers. It is a small price to pay if the business sees the return that great SAP usability provides.
Leaving Usability to Phase II…or Phase X
Some companies using SAP have allowed the UI to march along with a largely out-of-box implementation, leaving critical usability issues to be addressed later (if they ever actually get around to it). If you’re preparing to implement SAP, tackle Usability early!
If you haven’t, you’re one of many. The general feedback I hear time and again, is: “This SAP implementation was so expensive – just GET IT OUT THE DOOR!” Fine, it’s out the door – now who’s gonna use it?
Leaving Usability to be tackled at the end means that a usability engineer has to decide what battles are worth fighting for in the budget (because so much work has to be redone on the interface) and what things are best being left to compromise. There’s no real solution if you’re playing catch up, but the best approach is to: Prioritize.
Ensure that the Usability work that is packed in makes the greatest impact on the user experience. By demonstrating work savings and driving adoption (as well as increased revenue potentially), you can justify enhancing Usability later. Just make sure that the initial work is done properly so that it creates the building blocks for the future.
A Perception Problem
Sometimes, when someone hears that you implement workable UX solutions within SAP, they become immediately cynical, suspicious that you’ve developed a few new buttons that make SAP “usable” while really looking like all the others they’ve seen. Not true! It’s possible to use a straightforward user-centric approach but with a finesse that, while hard to get right, pays off by getting a more natural interface to blend into the strengths of SAP.
For companies that desire to get their installation of SAP as close to OOB as they can get it (read: it’s too expensive to modify), resolving UX issues with these apps is often a tailor-made affair (potentially expensive, too). The first project like this is frustrating and hard to win, but you will come to appreciate what SAP applications can do as well as how they can be modified to act and look.
The only way to approach this: Patience. Get through the first project, and you’ll see that SAP is a robust platform that gives a usability engineer a lot of material to work with all within a predictable software environment. Over time pain points like tables and alignment become familiar, and myriad solutions can be held as options in reserve for when they’re best utilized.
The Good News
So what’s the resolution to these challenges? There is no easy answer, but your best results will come with an experienced UX team that can compromise, prioritize, and work patiently together.
A usability engineer can be heavily stymied without supporting UI developers as well as graphics designers who can interpret not only the users’ needs, but also incorporate the vast valuable components of SAP. This flexibility comes with experience – and the best teams, like those at Excellis, have it in spades.
Leave a Reply