SAP Users

We’ve all had personal experiences with “usability”. A watch I purchased a few years ago seemed perfect for my needs, it could manage multiple time zones seemingly making it easy for travel and keeping tabs of country-specific times. However, I found that every time we shifted from standard to daylight savings I spent hours trying to reset my watch as the digital and analogue times always differed. The user manual I found didn’t make this 6-monthly process any easier.

A family member of mine recently spent a small fortune having a fully integrated entertainment system installed in his home. His euphoria was sadly short lived in that he just couldn’t get his head around actually operating the system and managing the separate and the universal remotes that controlled the TV, satellite box and sound system.

Having spent the last 15 years selling SAP into the mid-market, competing against the likes of Microsoft, I always came up against the objection that SAP was overly-complicated, difficult to learn and difficult to use. User experience was a “This is the way it is” approach, backed up with weeks of training courses and volumes of training manuals. I probably secured most sales when I showed examples of Excel being used as a front-end for some SAP transactions.

Why has the user experience historically been left till last?

Well I’m not sure it was left till last or if it simply wasn’t considered at all. I suggest the explosion of smartphones and user friendly apps have changed the way end users think when it comes to the type of experience they expect with enterprise software.

• Users want the consumer experience at work
• Today’s user focus is squarely on the Business Processes and not transaction processing
• Users want to be productive at their desk and on their mobile device
• Users want an intuitive solution that is easy to use – Simplicity
• Users want immediate access to all related data

20 years ago I was thrust into my first SAP project as “Super User” in within a global consumer goods organisation. I was responsible for system selection and defining user requirements for the Plant Maintenance module of SAP.  With great enthusiasm and a complete disregard to budget availability I began work with the consultants and, already-established, project team. Like many SAP projects at the time, I was probably only 2 training manual pages behind the consultant, but still deferred to his wisdom in terms of what I wanted vs what he felt the project needed.  Sadly the business didn’t get the solution we expected.

I remember first seeing the following cartoon, but I think that regardless of which side of the IT fence you sit, it has a strong element of truth and interestingly enough, it’s as relevant today as it was some 15 years ago when it first materialised.

A few years later, I decided to leverage the SAP project experience I had gained and became a SAP consultant. I very quickly found myself in the same position, the knowledgeable consultant only a few steps ahead of my customer.

Looking back now, I realise that more often than not I also tried to over-deliver and introduce features the customer didn’t actually request but ones that I thought would be well received. They typically weren’t. A clear example of this is where I was a team leader for SAP project at a national mining customer.

We were tasked with delivering an SAP solution to Job-based maintenance budgeting and planning. After analysis of current practices and considering the functional imperatives recommended by an independent maintenance advisor, we assembled a working team comprising business representatives, the maintenance process manager, consultants, developers and SAP themselves. We set about designing a functionally rich solution that met all of the documented and agreed specifications.

Our design involved using SAP Project Systems to create a WBS structure reflecting a budget hierarchy. Budget planning was carried out against this hierarchy using “statistical” maintenance orders to generate planning data and then to assign actual maintenance orders against specific budget WBS elements to reflect appropriate budget allocation. This part of the project spanned many months and required specialised system configuration, countless ABAP developments, enhancements and reports as well as a mountain of master data to deliver. But hey, this was the 1990’s where Y2K drove crazy budgets and spawned massive consulting engagements. Our team rose to the occasion and delivered a spectacular solution that in our view met the brief completely, or so it seemed.

As the overall project neared go-live, the implementation team was assigned various responsibilities in terms of delivering training and providing support for various geographies and functional areas. I was allocated maintenance budget training which was a 3 or 4 day course for all maintenance practitioners. I set off to a gold mine in the middle of the outback for my first training course armed with beautifully crafted training packs, a specialist training company had compiled, which included step-by-step instructions with detailed screenshots covering all aspects of the maintenance process. Having been a fundamental part of the design and build team, I was obviously very familiar with the process and it seemed simple enough to me. It was however only a few hours into the first day that I began to realise that perhaps we got the user experience wrong. Mid-morning on day 2 one of the maintenance planners stood up, threw his chair across the room and walked out. At this point I knew for certain that we had a problem.

News of my training course debacle quickly spread and the welcome reception I received at project headquarters the following week was memorable to say the least. The recommended solution to the problem however was as you might expect, to throw even more training resources at the users.

15 years later, terms such as “UX – User Experience” are commonplace in IT but sadly still often misunderstood, what have we as IT professionals learnt?

I can only comment on my personal experience but I firmly believe that it’s always better to deliver a solution that even if it’s only an 80% functional fit, it’s 100% usable. The best solutions I’ve been involved with have been those where there is no training manual and no formal training but rather a very user-friendly and intuitive solution built to the user’s requirements. Apple has introduced consumers to the concept of Intuitive Usability – they don’t even ship a manual with new devices.

Golden nuggets:

1. Processes are ALWAYS more complicated than people think
2. Users don’t all understand the full process – go a level up to understand the overall process objectives
3. Understand who the users are
4. Users don’t know what they want till they see it, good solutions aren’t designed by committees but rather by process experts
5. Start with the essentials and a well-designed framework and add incrementally, simplify wherever possible, remove the unnecessary
6. Understand where all data comes from and make sure all participants can easily provide input
7. Managers often require data from multiple sources and documentation to take effective actions
8. Start with the bigger picture, don’t get bogged down in transaction intricacies
9. Perception of performance, never leave the user waiting
10. Always consider mobility

Dave Cole – IQX Business Solutions, one of many SAP users

Dave Cole has been in the IT and consulting services industry for 20 years having experienced the early days of SAP, Y2K, the explosion of the internet and the hype of mobility. Having delivered SAP-centric projects across the globe, his passion as Chief Commercial Officer at IQX Business Solutions for highly effective software and solutions is making its mark on industry. Packaged user friendly process solutions such as procurement, master data management and Capex as well as  OneList Approvals developed by IQX all embody the value proposition of optimised user experience and process effectiveness.