Many of you know I am passionate about finding the optimum way of delivering a better UX for SAP customers. It’s reflected for instance in my presentation on Pragmatic Paths to optimise your SAP User Experience which I delivered at a local SAP User Group Conference last year.
The other day I stumbled across an interesting slide (below) from SAP depicting the valid UI clients for a S/4HANA implementation. Of course this slide is subject to the usual SAP disclaimers that it reflects the ‘current state of planning and may be changed by SAP at any time’.
This slide raised for me some very interesting questions. What User Interface (UI) clients would people out there in the Twitterverse advocate implementing for a greenfields on-premise S/4HANA implementation? Looking at the slide above it seems SAP is promoting two options.
I have my own opinions on this, but I thought I would first test my thinking without telegraphing my opinions by releasing a Twitter poll.
Here are the results ….
Firstly, if you are not familiar with the technologies described, you can find more comprehensive descriptions from SAP at these links …
SAP Fiori Launchpad (abbreviated as Fiori Lpad in the poll) – link here.
SAP Enterprise Portal (abbreviated as Portal in the poll) – link here.
SAPGUI for Windows (abbreviated as GUI or GUI Win in the poll) – link here.
SAP Business Client (formerly NWBC, abbreviated as Bus Client 6 in the poll) – link here.
Secondly, if you think the options should have been more descriptive, or there should have been more options, I was restricted by character limits imposed by Twitter and a limit of only four options for a poll.
Finally a voting sample of 75 votes from Twitter is good, but just a drop in the ocean compared with the overall SAP ecosystem. Consider that when interpreting these results.
Let's share my opinions on each of these results. Note that these are opinions only, and I would be interested in hearing your own in the comments.
Option 1: Fiori Launchpad + SAP Portal + SAPGUI for Windows
Fiori Launchpad is of course the strategic mechanism to deliver Fiori apps. Fiori represents SAP’s new user experience and the go forward approach for solutions such as S/4HANA. The sticking point is that SAP has yet to provide the full suite of Fiori apps that would negate needing to ever use any of its hundreds of thousands of older SAP GUI and even Web Dynpro screens. Therein lies the conundrum. How do you surface those older technologies? Via Fiori Launchpad you can in fact launch Web Dynpro applications, as well as SAPGUI transations surfaced within the browser using SAPGUI for HTML technology. But SAPGUI for HTML has existed now for over a decade, yet when given the choice, SAP customers have preferred the more performant SAPGUI for Windows client.
Here, when referencing SAP Portal I am referring to the on-premise installation of SAP Portal, not the cloud portal offering on HANA Cloud Platform that is something altogether different. SAP boasts over 10,000 implementations of SAP Portal, so I can imagine there is quite a following in relation to skillsets and consultants (heck, I myself was once a certified SAP Portal consultant). I can’t help but think that some proportion of the votes for this option was swayed by SAP Portal consultants wishing to ‘go with what they know’ – just my opinion, I could be completely wrong here. The interesting question is whether you would justify standing-up a new on-premise SAP Portal for a greenfields implementation of S/4HANA.
Pros:
If you are looking to make use of broader features offered by SAP Portal (such as collaboration features or mashing SAP with non-SAP content), you might consider this. That said, many existing customers already have a solution to deliver intranet and collaboration features in their landscape (eg. using Sharepoint) and only run an SAP Portal to serve as an applications portal (to surface SAP applications in a role-based manner). Where that is the case their needs may be met solely with SAP Fiori Launchpad.
You will possibly need a Java server to run services such as ADS (Adobe Document Services) to support Adobe-based form printing, and arguably an SAP Portal has traditionally provided the platform for just that. However for the ADS scenario you now can alternatively utilise a cloud-based service instead, using SAP Forms as a Service on HCP .
Cons:
Assuming you are delivering the Fiori Launchpad within SAP Portal, this increases the payload to be deployed to the client. I personally view Fiori Launchpad as being something akin to the next generation ‘applications portal’ for SAP, and in embedding this with SAP Portal we end up with a ‘portal in a portal’ scenario – along with the associated impacts to network usage and time to render for the user.
You are running and supporting additional infrastructure associated with the SAP Portal.
You now have potentially three entry channels for users …. Fiori Launchpad (unless it is embedded within SAP Portal, which I mention above is not my favored approach), SAP Portal, and native SAPGUI for Windows. That’s ludicrous in an age where we are striving for simplicity for end users.
This is not listed as an option in the SAP slide at the top of this post.
Option 2: Fiori Launchpad only (incorporating SAPGUI for HTML, Web Dynpro etc.)
This option advocates for what SAP’s strategic direction is … a fully browser-based (zero client installation) approach. In fact when you look at the SAP slide above this is the only option for customers implementing S/4HANA Cloud Edition.
Pros:
This is the simplest deployment approach and least costly to support. The entry point for all applications is via Fiori Launchpad and there is no need to rollout a thick client to desktops. All you need is for users to access the URL in a browser.
This single Fiori Launchpad client can be supported across various devices and form factors (although the underlying technologies differ in support – whilst SAP Fiori apps generally can run on desktops, tablets and mobiles, SAPGUI for HTML and Web Dynpro ABAP technologies tend to be supported only on desktops).
Since Fiori Launchpad is SAP’s strategic direction, it is likely that SAP’s near term investment in integrating and aligning new cloud acquisitions such as SuccessFactors, Ariba etc. will be focussed on Fiori Launchpad.
SAP is seeking to implement ‘visual harmonization’ such that SAPGUI for HTML screens will be themed in future to look more like Fiori applications.
Cons:
Use of SAPGUI for HTML scenarios may be inferior in performance (and thereby UX) terms than the native SAPGUI for Windows. For casual users this may not be of any concern, but for users who spend most of their day in the system this might make a difference.
It is still unclear how Fiori Launchpad alone will effectively surface a large number of applications to any given end user. I’ve worked with customers where some key roles needed 100 – 200 menu options. That translates to many tiles in Fiori Launchpad. That being said, I’m hoping the Fiori 2.0 design concepts might help to alleviate this concern. This blog by Jakob Marius Kjaer nicely articulates the problem.
Option 3: Fiori Launchpad + GUI Windows
In some ways this option is similar to the SAP Portal + GUI Windows combination that many customers have implemented in the past.
Pros:
It is likely you will use SAPGUI for Windows within your project team anyway. For instance I can’t see Basis administrators using anything else. And as one Twitter respondent mentioned you need it to use some developer tools such as ADT (Eclipse based ABAP Developer Tools). But the question is would you also deploy the SAPGUI for Windows to end users? And if so where would you draw the line? – all users or only so-called expert users? And if justifying the need for SAPGUI for Windows why not go for option 4 which delivers Business Client 6 with SAPGUI for Windows embedded?
Cons:
This implies you will be deploying a client installation (SAPGUI for Windows) to the desktops of some or all of your end users.
SAPGUI for Windows is not supported on tablets or smartphones.
This breaks the user experience because users may need to open Fiori Launchpad to access some functions whilst opening SAPGUI for Windows to open other functions.
This combination isn’t even mentioned in SAP’s slide above. And don’t forget for my poll the question was framed around a greenfields customer (one that hasn’t used SAP before). Putting SAPGUI for Windows in front of new end users (even if they might be expert users) isn’t really in my mind the path to success in this day and age.
Option 4: Fiori Launchpad + Business Client 6 (embeds SAPGUI for Windows)
Here when we mention Business Client 6 we are referring to the thick client Business Client 6 desktop edition, which also comes with SAPGUI for Windows embedded (with a unified installation).
Pros:
You have a number of options here. The important thing is that Business Client 6 provides a modern conduit to surface a native SAPGUI for Windows experience alongside the Fiori launchpad experience. Tiles in Fiori launchpad can be configured to launch native transaction codes in SAPGUI for Windows. It is for this reason that Business Client 6 is recognised in the SAP slide.
You can deliver role-based access to both casual and expert users alike. Both Fiori Launchpad and Business Client 6 incorporate role-based concepts, whether you are using the tile-based approaches in Fiori Launchpad or the classic accordian menu index page in Business Client 6, or unifying the two by launching the Fiori Launchpad within Business Client 6.
Certainly Business Client 6 offers some advantages to the previous option 3 (SAPGUI for Windows only) because it delivers some nice usability advantages such as good support for role-based access, easy transaction discovery (via search), and side panel assistance. Whilst at the same time you can still deliver when needed a native SAPGUI for Windows experience.
Cons:
This implies you will be deploying a client installation to the desktops / laptops of some or all of your users. Of course SAP offers a unified installer for Business Client 6 with SAPGUI so this is not dissimilar to option 3 above. But similar to option 3 above, would you deploy this to all users or only expert users?
You need to setup and configure potentially two clients, which is additional work.
SAP Business Client is not supported on tablets or smartphones, nor is it supported on non-Windows environments such as Macs, so you will need to support those channels via Fiori Launchpad alone.
Business Client mandates the use of (currently) Internet Explorer when surfacing web applications. However SAP’s new Fiori apps are optimised for Chrome. So you lose some flexibility in your browser choice when surfacing Fiori apps via Business Client.
Other Thoughts
It is important to note that for S/4HANA Cloud Edition customers, SAP only supports the use of Fiori Launchpad standalone in the browser. That means that when any traditional SAPGUI user interfaces need to be accessed, these will be via SAPGUI for HTML embedded in Fiori Launchpad. If you believe in SAP’s cloud story and it’s success in the near to medium term, then I would have expected you to vote for option 2, because why should the thinking for an on-premise deployment be any different? Yet the smallest proportion (17%) of respondents in the Twitter poll voted for option 2.
Instead the majority of respondents (40%) interestingly voted for option 4 – a combination of Fiori Launchpad and Business Client 6. What’s not clear is how respondents would prefer to deploy that combination. In that regard, here is a plausible option from my perspective …
Deploy Fiori Launchpad via browser to casual and general users across desktops / tablets / smartphones. For smartphones potentially leverage optimisation approaches such as SAP Fiori Client app or similar.
Deploy Business Client (with embedded SAPGUI for Windows) in a unified installation as a limited deployment to expert users on their desktops. Expert users to be defined based on role (eg. roles generally requiring use of SAPGUI transactions in the system for over 2 hours per day). If you find very few expert users fall into this category, then it might make sense to revert to option 2. Apply some basic role-based filtering concepts to deliver role-based menus with minimal effort.
The choice of including Business Client in the mix in the Twitter poll results is interesting as it telegraphs a nervousness amongst respondents about the ability of SAP to fully replace SAPGUI transactions anytime soon. Business Client is effectively a technology that provides a smoother transition from the traditional SAPGUI for Windows technology towards web-based applications such as SAP Fiori as it supports both approaches within a single shell. Many of you will know that I have blogged about the benefits of Business Client in the past. If however all applications were SAP Fiori apps (SAP’s vision), there would arguably be no need for Business Client.
SAP consultants have traditionally not been ‘user centric’. Rather they have been function centric, or delivery centric. As long as a function can be delivered and the requirement ticked off (however unusable it may be) that’s long been the approach for SAP implementations. But times are changing, user demands are changing, and we all also need to change the way we see and deliver SAP UX to our customers. The big question is how willing the ecosystem of SAP implementers and consultants is to let go of older approaches and make way for the new.
Comentarios