What’s so Simple about SAP Software (Part 1)?

Why is SAP doing this?  SAP’s intent is get all of us to think of SAP first when we think of enterprise IT that is both powerful (the ‘run’) and both good looking and a pleasure to use (the ‘simple’).  The campaign has been so prevalent that it’s successfully become a tenet of how the company is changing it’s products and marketing them.  They’ve decided that simplifying their solutions will yield market gains and could, along with greater performance delivered by HANA, provide the next wave of SAP driven innovation.

But to those of us that work hands-on with the software, what does simple mean?  And will S/4HANA really simplify their customer’s business?

Making the UI Simple

To me, the simplification that SAP is attempting is focusing on two fronts.

The first is the frontend and that’s a murky area.  Let’s review SAP’s history on the frontend to figure it out.  First, we start with SAPGUI.

SAP’s track record in the GUI area has been mixed over the years.  On the one hand, SAPGUI was/is light; it would work without issue back when we remotely dialed in over a telephone line.  The drilldown path is seamless, and there is enough nuance in the display area for it to be pleasing to work with (as compared to other enterprise IT applications).  I’ve worked with Oracle’s frontend for a few SAP implementations that replaced Oracle Financials and by comparison, SAPGUI was far better.  I was genuinely shocked at how bad Oracle’s GUI was.  With all of Oracle’s acquisitions, the GUI wasn’t unified and they made the switch to a browser based solution before browsers had the technology to run a feature rich frontend to an enterprise application backend.

On the negative side, the personalization in SAPGUI isn’t sufficient.  SAP led an effort years ago to personalize the GUI with global values, screen variants, transaction variants, table controls, SAP Enjoy and the Easy Access Menu (complete with Favorites) but it always felt incomplete to me.  Why do I have to re-do the same table controls in DEV, QA, and PRD?  Why can’t I easily move this personalization between systems?  Clients?  And different customers?

The oldest complaint against SAPGUI was that it was too busy and complex particularly for an occasional user to navigate.  That was the most common complaint… that an occasional user who logged in a few times a year to approve the budget for their department, or approve sick time, etc.; they had a hard time figuring out where to go and what to do.  So many fields on so many tabs!  This last one is the bigger issue and one SAP has dealing with for years.  There are a few ways around this but they have their downsides.

One, GuiXT is a great tool and every customer I’ve worked with that uses it, loves it.  But you have to license it.  $$.

There were other techniques within SAPGUI itself to simplify screens using the previously mentioned screen variants and transaction variants but to attempt to edit even the top 100 screens would take too long to work through.  I don’t think any customer thinks that is a worthwhile endeavor particularly when you factor in that there has got to be some go-forward support for these custom variants.  To most customers, it’s easier and cheaper to write-up a good training document than to edit a screen.  #true.  So, we’re still stuck with SAPGUI.

All of those legitimate complaints aside, I’ve always thought the criticism, while somewhat accurate, was completely misplaced.  When you wade into this topic area you have to understand that there is great variety amongst the end users that engage with SAP software and this has to be factored into the design decisions regarding screens.  i.e., know your audience.  The user base at any customer represents an entire spectrum running from frequency of use, to area of focus, to the complexity of the process they are working in.  There’s just no way that you can design a screen — FB50 Post Journal Entry — that will be well received by both a power user who punches out 50 entries a day for every conceivable financial posting, and a first time user writing a simple two line entry.  SAP made their choice and focused on functionality and it’s one I agree with.  That’s the 80% of the user base that SAP should target.

Haven’t we done this before?

My concern with the SAP frontend area is that SAP’s track record in getting off of SAPGUI hasn’t gone well.  They introduced the NetWeaver Business Client (NWBC) which was supposed to have a lot of advantages, the biggest being that it was going to standardize and harmonize the UI landscape.  At the time, we had so many options between NW Portal, CRM, SAPGUI, Java, BEx Analyzer (Excel) and NWBC itself.  NWBC was to provide a single desktop based access point to anything SAP related.  But NWBC was never widely adopted.  The problem is that I’ve only been to a single customer in my 22+ years of working on SAP that used it.  Everyone continues to plug along with SAPGUI (myself included) which means we/they are still jumping around between VA01, a CRM screen, a BI report, etc.  SAP has re-branded it as SAPBC and it’s still part of their solution.  But, of the three S/4HANA implementations that I’ve worked on in the past 2 years, all three are using SAPGUI.  I just haven’t seen any broad adoption of SAPBC in the market.

SAP later released a solution called Personas.  The big leap with Personas was that it abstracted away from the normal GUI layer by placing itself on top of the underlying SAP screen.  From there, you could edit just about everything… hide/show fields, change labels, change colors, move fields, re-format data entry fields, merge screens, automate steps…  dang!  It was the ultimate in flexibility too!  You just dragged, dropped, outlined and WYSIWYG’d your way through it… and you had a new entry screen for ME21N!  The first impediment to Personas’ nirvana was that it required a license.   It’s one thing to charge customers an additional license for an extra module or solution but when they view the item as core functionality that should already be included in the base purchase… well, you don’t end up selling a lot of Personas licenses.  Secondly, it required Silverlight which Microsoft promptly discontinued about 2 years after Personas first launched.  #badtiming

SAP moved Personas off of Silverlight and it now no longer requires a separate license but it feels like the damage has been done.  It’s still a great solution and a free one too, but now I’m seeing another issue; time/money.  SAP projects are more rushed and understaffed than at any time that I’ve seen and customers aren’t going to spend more time and money to redo an order entry screen.  Should they?  Do they see the benefit?  Sure, no doubt about it.  Maybe they could save 2 minutes per order being created and increase it’s accuracy.  For the typical international SAP customer… you do the math.  That could equate to real dollars in end-user productivity being saved.  But during an implementation, these kind of initiatives just get pushed to the wasteland of all unfinished project implementation work; it’s called Phase 2.  Sometimes Phase 2 never happens.

Another factor is the skill set.  Personas is easy to work with but it’s not a core skill of most functional consultants.  We’re still configuring the frontend process via field status and screen layouts.  Once that’s done, we’re rushed on to the next phase and we don’t get a chance to actually optimize what we just built.

Up Next: Fiori and SAPUI5

Now, SAP is pushing Fiori as their new frontend solution.  The benefits are numerous:

• Role based and persona centric design and navigation
• An ‘apps’ approach to navigation and information discovery
• Better search, collaboration and feeds
• Support for multiple devices (i.e., desktop and mobile)
• Better theming and brand personalization
• Multiple platform support
• Better support for analytics
• Support for extensibility
• oData support

SAPUI5 is another factor.  The recent SAPUI5 roadmap was released and this has even more reason to be excited by what is possible with engaging with SAP systems, SAP and external data, and information visualization.

The Key Question

Is this time any different?  I think it is for a few key reasons.

First, the support for multiple devices is huge.  We are way past the point where business users across the user spectrum have been using smartphones and tablets in addition to their PCs for data entry and exploration.  We’re all using smartphones and laptops, some are using tablets, and I see Microsoft Surface computers everywhere I go.  It’s time that the big enterprise IT applications, which serve as the backbone of most organizations, provide a single UX technology that can be accessed on any device.  Define once with multiple use-cases…  that’s the future… err… the present too.

Secondly, the ‘apps’ approach that SAP has chosen also fits in nicely with how we engage as consumers.  An obvious question that we here all the time is in purchasing; “Why is it so hard to create a PO (even in a SAP training class) but I can go to Amazon.com and intuitively search, buy, ship and pay for anything I want?”  It’s a fair point and Fiori is meant to adopt some of these consumer driven designs.

Finally, SAP is aggressively pushing Fiori in a way that they never did with NWBC.  For instance, in S/4HANA Finance, you (initially) had to use Fiori to create a house bank.  The old transaction to create it via SAPGUI had been removed.  Also, it’s clear from a reporting perspective that SAP is re-doing their reports and pushing all of the new stuff to Fiori.  The first time I read the S/4HANA Simplification List for Project Systems (PS), I was shocked to see that SAP is labeling all of their PS reports and reporting tools as ‘not target architecture’.  They’re going to replace all of it with new Fiori-only apps (reports) and it’s coming soon.  The legacy reports in S/4HANA are no faster even if you’re running on HANA.  You only get the HANA performance boost if you’re running the Fiori reporting app.  As I write this, I’m not sure that I’m looking forward to that transition but I know it’s a transition I’m going to have to go through.  I don’t expect for it to be optional.

Does SAPBC + Fiori + Personas Simplify the Frontend?

So where are we now and where is this all headed?  What was previously a single item that the Basis or Network team would mass install (SAPGUI) is now an entire solution area.  Business/IT professionals are actually specializing in it.  SAP Business Client + Personas + Fiori = UI Nirvana.

I think Fiori can get us there if you get into complex areas like external data sources or other systems such as BI.  Mobile?  Data Visualization?  Yes, it’s all better on Fiori and UI5.  But, I’m an operational guy who works with engineers, accountants, and project managers on how to get more out of SAP.  For them, the data entry side… creating GL accounts, maintaining the cost center hierarchy, creating a large complex project, or entering in an accounting document with 100 line items..???  The technology being presented itself doesn’t simplify those processes.  If the screens have been simplified it’s just because a savvy frontend designer took a fresh look at how GL accounts are created… because FB01 is the same in S/4HANA as it is in R/3 release 2.2g!  [Rant:  In the Chart of Accounts, why oh why, is the Field Status Group, which might be the single most important and researched field on the account, located on a tab labeled “create/bank/interest”?  Makes no sense to me].

The issue is that if SAP creates this awesome UX toolset and they are able to present data in a way that gets the customer base excited… well you’ve got to bring along all the old stuff with it in order to make it work.  You can’t show a global spend analysis dashboard app and not bring along the vendors and materials that drive it and you don’t have enough time to re-do all of those screens and interactions at the initial S/4HANA release.  I had a great conversation with some other SAP Mentors on this topic.  Julie Plummer (@JuliePlummer20) from SAP Product Management cleared up a lot of the UI fog for me with this one tweet.