Time to push User Experience to the Foreground on ASAP Implementations
The Problem
This is just a quick blog to highlight what I see as a glaring omission, or at least, not well defined enough from the default ASAP Implementation Methodology, which is the inclusion of user experience (UX) roles, processes and deliverables. Now while the old SAP user interface and interaction didn’t have much room to move, and people rarely took time to think through navigation taxonomys, leaning towards training people in transactions; SAP has moved on and we need to update. e.g. The coming of age of NWBC, Floorplan Manager, Business Objects, SAPUI5, Neo, Mobility, plus so much more.
Now if it was a Portal implementation, at least the navigation gets a big focus, and usually the Portal consultant does have that UX design experience (at least selecting nice colours, rounded corners and the like 😛 ); but for a greenfield ERP implementation, especially at smaller sites that do not have 5 thousands plus users; it’s easy for a system integrator to go into standard ERP implementation mode and not factor this in.
Now you might say that standard SAP is best practice, and why would you change SAP (hopefully you don’t say that with a straight face if you’ve ever implemented SAP before); well then how would you tackle:
- Position/Role based navigation (or at least user based navigation)
- Branding (Internal and External)
- Occasional SAP Users versus Professional SAP Users (I call them SAP Process Centric Users and differentiate them mostly by the fact that they use SAPGUI and requires training, while the Occasional SAP Users don’t, leveraging more intuitive functionality like ESS)
- Patterns for custom development (e.g. Use Floorplan Manager in ABAP developments)
- Workflow email formatting, or even what email address the workflow emails come from…
- Integration with internal or external “Portals”.
- Use of dedicated clients versus zero-footprint installs
- Logos in clients.
- etc.
So there is talk of Visualisation and Portal in ASAP, plus mention of products such as iRise, but this is not enough – we’re talking about taking care of our end-users, who are really the main stakeholders in terms of success right???
The Solution
Put simply, there needs to be the right roles, processes, deliverables and change management tasks within ASAP throughout the project, and in all phases. UX is not a polish you do at the end, and trust me, if you don’t get the vision of UX agreed to and understood across an implementation team early; you’ll face plenty of resistance for the remainder of the project. You also need to remember, System Integrators typically refer to ASAP as the methodology they use on projects, but for most customers; SAP is one big scary, “so complicated I must not be able to comprehend it” piece of software; that they see this big piece of IP called ASAP Methodology, and think “well I suppose that covers everything” and start to second guess their instincts as to why UX has been such a focus on all previous “implementations” they’ve done.
Why is this so important?
With enough vision, and planning, getting a good user experience is easy. It’s actually mostly about intuitiveness and consistency in a way (it’s not but go with it); but with so many new toys coming out from SAP; you need to be fully across what software can and can’t do; and how all the pieces of the puzzle fit together for you or your customer if you are the SI (since we don’t want disjointed SAPGUI and Web Dynpro screens any more – and please don’t say the words webgui/ITS).
A great topic to bring up Matt. I wish SAP would push this more - both internally and externally. I hit my head against a wall whenever I bring up usability - and that's even with the managers at a customer site. No one seems interested so there's no wonder so many users hate the sap experience!
yeah, they say: "they (the users) will get used to it" 😐
Hey Matt,
I can't comment on ASAP methodology (or at least I won't) but I can tell you that I know of implementation teams that have literally spent hours deciding what the From address should be when SAP Workflow sends an email. Formatting the text is another biggie too.
If you can't put your message into a reasonably well formatted email, I'll give you until the count of three before users complain that the system is sending them 'spam'.
Cheers,
Sue
Great post Matt!
I'm sure if you ask any end-user they would agree that this is important. A friend told me about an interesting comment while evaluating NWBC with users. A user said that it was not needed because they already had the needed transactions memorized. However, for some reasons things always seem to go wrong when an experienced person leaves.. An intuitive user experience is an investment in the future, not in the right now.
-Brian
Jason - I think SAP are raising the issue, but not for existing or greenfield implementations, with more focus on HANA, analytics and Mobility projects. i.e. The Sales focused areas. That said, if the customer is still expecting the same old SAP, then it's a hard sell regardless as it does cost (up front at least, and boy does it cost if you don't address it too).
Susan - Great feedback - Definitely a keeper in terms of examples! Sometimes consultants need to spend some time supporting the system they implemented to really understand these types of things. That said, hours deciding on email addresses does sound a little frustrating and overkill but I probably shouldn't judge 😉
Brian - Your last line sums it up completely. And just because you are stuck with a lot of clunkiness from bits of "timeless software", doesn't mean you can't help out a user with a side-panel, some logical navigation, or even providing the information via the right channel!
Thanks all for your feedback and support for this issue.
Cheers,
Matt
Great post Matt and a topic that is very top-of-mind for me.
I have a radical suggestion. Brace yourself because this is way out there! 😈
What about we get the people that are tasked with delivering the SAP system to sit down and talk to the people that will have to use it?
I know, I know, it does seem like an extreme step to take - but I think it is worth a go. 😏
Cheers
Graham Robbo
I hear you Graham though I'd stress it's bigger than that as you need a role (or two or three) that looks at the overall experience (an extension of a solution designer/architect/developer) who understands how all the bits and pieces can fit together, including prototyping what is possible and making sure it can be done within the timeframes.
i.e. It's very easy to say, we're going to use NWBC, OBN, FPM patterns, SAPUI5, Lanes Pages, HTML5 All in One Inbox, BO Dashboards via BI Launchpad and side panels, no ITS, with security based on roles rolling up to positions, corbu, plus embed this all in SharePoint, and all available on the iPad, but when you start to see all the people that are impacted by these statements, plus the fact no one has ever done all that in anger - you have one hell of an uphill battle to contend with.
So absolutely agree with your radical/extreme step to take..Rule #1 is show the end users what it will look like potentially and often, getting continual feedback; but rule #0 is set the scene of how this will all work, and prototype the risks early so that you can demo it to all impacted (including the SI). Then put that person in charge 😈 and repeat the message often, and don't let the consultants turn back to old habits.
Well, at least give them hire/fire power for consultants... 😉
SAP - Feel free to plagiarise the above in the ASAP methodology...
Cheers,
Matt
Total cost of acceptance ought to be a project metric. I.e. through either development, training or configuration you must make the system acceptable to end users. Whichever is the cheapest option is likely to be the path taken, and I'm afraid that will mean ITS reports being surfaced occasionally, especially when things like standard delivered ODP reporting have go be built by a different team and end up as dreaded wricef items... ( that was a long sentence without enough punctuation!) UX really only gets a look in when user acceptance of the system is the most important thing, and I'm afraid in a world where RDS and fixed price implementations are commonplace, this is happening less.
today at Mastering SAP HR I presented on what can happen when you have a little leeway to make the system acceptable. It doesn't cost much, but it does cost more than just making the system "work". It depends on the si you are working with ( use me I care about ux 🙂 and your views wrt the cost benefit of good ux. It should be part of any negotiated deal that users must accept the system before final payment, not just that system works... as per the castle, tell me I'm dreaming! 🙂
We definitely do have a disconnect. Do a Portal implementation, and the money flows. Buy Personas and the money flows. Do an implementation on NWBC and no one thinks that UX is a requirement any more.
But as you have personally shown, it doesn't take much to make a big difference. The cost of an unacceptable system versus an acceptable one is a lot, and for a fact, the unacceptable one is the more expensive in the long run (unless you've gone overboard)...
In terms of how to negotiate this...I reckon you put your principles and policies together and the enforce them as part of contract arrangements. Not sure you can put a metric together about UX except for compliance to the vision unfortunately. That said, any ideas what could be used as a measurement?
Thanks for the input and keep on dreaming! I still do...
Matt, thanks for sharing, excellent point.
Hate to beat the dead horse but well, New SCN is unfortunately an example of what could happen when user experience is not given enough thought or not the right users are engaged.
If someone tried just simple "role playing" (e.g. "I'm a new user trying to post a question in ABAP forum") we might have ended up with a site that did not require a manual to use. Sigh...
Hi Jelena,
Well you're probably now talking about the importance of design thinking/empathy based development rather than UX, as I imagine SCN had plenty of UX roles on the project (and did attempt these role playing scenarios albeit to questionable benefit).
It's funny, that SCN is probably similar to an SAP implementation because with the introduction of Jive as the underlying platform, a lot of what made SCN great, suddenly had to be retrofitted into a mostly out of the box solution (analogy ERP). And when this happens, compromise on UX has to happen.
Regardless, you make a very good point!
Cheers,
Matt
Is the use of NWBC and Floorplan Manager the best approach for new developments today? Do you still develop for SAP GUI?
"don't say the words webgui/ITS" do you mean, never use it?
Thank you.
Hi Leandro,
I just saw I didn't reply to your questions so after a months of delay, my 2 cents reply:
Is NWBC and FPM the best approach for new developments? Well, it depends I suppose. Consider the audience involved, how they interact with SAP, but if you consider a professional user or ESS user without a Fiori capability in place, then this is definitely a pretty good way forward, but there is the issue if the support team doesn't have FPM skills but regardless, I still say yes it is! For occasional users, UI5 might start to sneak in, but you would want a good resource to build it with experience in producing a consistent UI5 solution and not a first try at UI5.
SAP GUI still has it's place. if you just need a file downloaded, or basic report for a power user - absolutely just do it (maybe use an ALV at least). But any reasonable size solution probably should avoid module or report programming.
And in regards to webgui/ITS - Yep - Avoid at all costs. While a great technical solution for web enabling SAPGUI, if you have to do something like this for occasional users who don't use SAPGUI, look at Personas or something.
Apologies for the delay in reponding,
Matt
Hi Matt,
I'm sure I read this post when you wrote it but I just stumbled across it again and so much of it rings true I felt I had to comment this time around. So my main question to you...
"One year after you wrote this, do you feel that much has changed?"
I am certainly seeing more awareness within organisations that UX is an important part for any successful system implementation. So at least from my perspective we have recognised the problem, but I am just not sure that the solution is that clear (yet). I see my role as someone who tries to pull all the options into a cohesive and consistent solution, sets the general UI strategy and educates people (customers and SIs) about what is possible (I find that many seasoned SAP people are still pretty much unaware of what can be done). Like you say it doesn't have to be overly burdensome to arrive at a good UX but you need to set direction early, get everyone onboard and constantly make sure that the team stays on track. I hate to see UX be the thing that gets sacrificed when a project gets down to crunch time.
Anyway they are some of my current thoughts.
Cheers,
Simon
Hi Simon,
Well one thing, the SI partner I worked with talked about doing this type of work on projects at Mastering this week, so I take that as a good sign, albeit it was more mobility focused. But yes - this is still really important. While we wait for Fiori to be delivered for every SAPGUI screen to give users less than 3 screens to do absolutely anything; a good consistent, intuitive navigation will make a huge difference to acceptance. For example, I quite like how SAPGUI screens work and get frustrated when a GUI status is empty, or someone doesn't use f5 for create, f6 for change and f7 for display - the consistency was what converted me over time.
Now getting everyone on board - well that is still a challenge. Think teaching OO to 3.X ABAP'ers who don't want to learn it. It's not only getting the message across, but getting them to accept that they want to follow your message. Then there is reality of how much is spent on UX on a project. Unfortunately there is no WRICEF for UX so unless you factor the cost in, and the PM (both customer and SI) fully support embracing UX principles and strategies; you're going to be fighting an up hill battle. Governance is key (from the customer side) with agreement at the beginning from all parties.
Regardless, it must be done is my opinion for significant impacting projects!
Cheers,
Matt
"Now getting everyone on board - well that is still a challenge. Think teaching OO to 3.X ABAP'ers who don't want to learn it." Very true. Many people really don't wanna learn. They say OO is useless when actually they never used it. One person I know that think this way also thinks that it is ok to clone objects ...
off-topic question. do you have some post discussing why most SAP projects always take longer to complete? when companies start to get ROI? steps for successful SAP implementations? Thank you. =)
Hi Leandro,
Sorry to hear about that one person, but at least having differing opinions is good provided people consider the arguments against their opinions, or try it out as you say.
In answer to your question, that's a much bigger question that many have attempted to answer previously. I was at a small consultancy in the US once that actually did achieve nearly all of that, and while it was a very powerful yet not too large Triple A-Team that added quite a significant amount of getting the completion and ROI in check (including nice bonuses to get in on time); there is much more to this. e.g. Politics, expectation management (unrealistic benefits/expectations), a bad apple (e.g. A critical component being implemented incorrectly either from poor requirements, or poor skills/knowledge), management (e.g. micro-management), morale, location, relocated versus fly-in/fly-out, training to stakeholders too brief, and/or too late, methodology (or lack of), buying too many solutions, buying the wrong solution, horrible legacy data/systems for data conversion, lack of cohesion between teams such as change management, training, management, technical, functional/process, under budgeted, etc....
In other words, there are too many dimensions to do this perfectly each time, but I will say, the committed A-Team (both System Integrator and Client Stakeholders) with good management, without too much politics or change request overload due to clients not understanding what they need/are getting - goes a long way to achieving the perfect outcome in my opinion.
Cheers,
Matt
Excellent reply Matt. Thanks a lot. I'll add two more reasons:
1. Don't hire experienced, competent people. Implement SAP is a huge thing. Try to save money with cheaper workers is the worst thing a company can make.
2. Customize too much. You are buying a software, if you change it too much or it has too many things missing, then it's better to develop your own sw. You can't have too much gaps. Ideally, everything should be done only with parametrization.