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.
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???
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).