1 2 3 6 Previous Next

User Interface Technology

80 Posts

Bild4.jpgYou might have seen or heard it already - perfectly placed to close this interesting year 2014 - the call for proposals for the ASUG Annual Conference 2015 is open again - since Dec 8 with a deadline on January 5. And YES especially the deadline might be - at least for some of you - a critical information as for lots of you that might fall directly into vacation time... so why bother this year?


Pretty simple reasons as always – there is no better chance to share thoughts, experiences, learnings, do’s and dont’s with a large community by providing insights into your projects, approaches, implementations.. while at the same time having the chance to learn from and socialize with others that face the same challenges as you.. and to get hold of all the SAP experts on site at SAPPHIRE NOW. And if your submission is accepted, you even get a complimentary conference pass.


What is DIFFERENT this year – there is a new ASUG track for USER EXPERIENCE you can assign your proposals to. Thanks to the rising interest inside the ASUG community – forming an ASUG User Experience and Interface Influence Council as well as a Special Interest Group User Experience – this new track now allows to group all UX  or UI technology related content and make it easy for the audience to follow this hot topic.


It is pretty easy to submit your abstracts and you will find this new track directly when you are in the submission form at the top:



Besides that – if you are assigning your submission to other tracks – you can still indicate a high focus on User experience of your content by choosing a submission category UX further down below your abstract.



So I want to encourage you to grab that opportunity and submit your stories that are related to User Experience or SAP User Interface technologies.


No matter if it is related to providing single access points for users with NWBC, SAP Portal or the Fiori Launchpad, or your first steps with SAP Fiori apps or Screen Personas to make life easier for your users. Or even your own experience putting your hands down into the Floorplan Manager, the UI theme designer, the SAP Web IDE, building apps with SAPUI5 or OpenUI5… just go ahead and share it. We have also seen great value for the community out of customer presentations around understanding UX and implementing it in the DNA of an organization with all its challenges.. so the area UX is broad and the topic is really hot based on all the feedback we got from ASUG and all around the world. So make use of that opportunity.


Kind Regards and hope to meet you at SAPPHIRE NOW / ASUG ANNUAL CONFERENCE in Orlando, May 5-7, 2015






And following this great post by Aviad Rivlin, I also want to point you to these two blogs by Tammy Powlas that might provide helpful tips and tricks for a successful submission:

Principal theme of my work within the last months was UI technology and user experience. This was challenging because you it is not only a technological topic. One of the best presentations of SAP’s UX strategy and UX strategy in general is published here and explains that design innovation is in the intersection human value, business value and technological feasibility as seen here:



At an DSAG meeting Jürgen Jakowski Jürgen Jakowski explained it very well:

  • adopt
  • adapt
  • develop


From my understanding “adopt” means that you implement an SAP solution (think of Fiori for example). Adaption means extending this solution or reducing existing pain point with and technology like Personas. And In this blog entry I will discuss the last aspect of development and I will look at SAP’s technology portfolio and I want to show how this can be used to create beautiful solutions that have business value. For the creation of those solutions ABAP developers have to change their mindsets: they have to learn new frameworks, new paradigms and sometimes programming languages. Yesterday it was normal to learn about the R/3 styleguide for ABAP dynpro, to create solutions whose UI was stateful tightly integrated into the application logic – but this is not state-of-the-art any more.


“Redefine Normal Every Day”

The motto “Redefine Normal Every Day” is part of an ALS awareness campaign by Zumba Fitness in the US. In Germany this is campaign wasn’t branded and I learned about it at a sports event last weekend – and in fact as a consequence I decided to write this blog entry. I found this motto very inspiring because of the following reasons:

  • In the last decades as SAP consultants / developers we told the end users that the UIs of SAP Business Suite are standardized and so “normal”. And of course custom dialogs have to fulfill these dialog standards as well because of consistency reasons. As a consequence many ABAP developers are experts when it comes to build dialogs exactly this way and this often means according R/3 dialog standards.
  • The second aspect why this motto inspired me is that UI5 is completely different from other UI technologies of SAP: it is Open Source and you can develop application with a completely unique and extraordinary look & feel and new user interaction patterns.


Especially JavaScript and HTML5 offer many possibilities to create an extraordinary (= far from normal) user experience. In my opinion everyone should know the following visualization which I usually show every single UI developer in our UI development projects:


In my opinion the four visualizations are absolutely amazing because it uses positions, size and colors to display different dimensions of entities. With cross over you can display detail information. The different patterns and diagrams encourage the user to explore the data and graphical effects remember me of computer games which makes the whole visualization fun.


Improving Man-Machine Interaction

Above visualization not only beauty – it can promote curiosity and encourages the users to explore and understand a data set. This is a perfect example how an optimized and extraordinary UI can lead to better understanding and decision support which can be also used in business applications.

Visualization and to some effects gamification are only one example who a UI can improve man-machine interaction. But I think there are more examples which I explain in the following.


The speed of the UI can have a significant effect on interaction patters. It is absolutely necessary for exploration of huge data sets but also necessary if data from different systems are collected. This is absolutely common for call-center and front-office users who need all information about a certain customer. Traditional stateful UIs like CRM Web UI or Floorplan Manager are sometimes slow and we need AJAX-like techniques to access the necessary data.


Decision Support = Analytics + Rules + Visualization

Another interesting aspect of new UIs is enabling of decision support. What does this mean? The application shows a visualization of a business object (and perhaps context data) and applies business rules. The result is a precise message for the end user – think of following traffic light symbol for example:


Using NWBC sidepanel you can display of context information of a certain business object, apply business rules and even visualize the result using graphical representation. The decision support tool can be added to any ABAP dynpro and WDA screen using configuration (wiring) and you don’t need to enhance existing ABAP dynpro tools.


Slicing Processes and Realtime Alerting

In this subsection I would like to introduce two interesting technical features: with Configuration Framework as part of Floorplan Manager framework you can create configurable UIs. This allows to develop applications that can flexibly adapted to the skills of a specific user team. With these techniques you can develop applications that are customized to specific skills and task of a certain group of users. This can be profitably if much of work can be performed efficiently by the staff and only very complex business transactions can be assigned to expert users who work with expert UIs.

Another interesting capability of SAP’s technology portfolio is the support of ABAP Push Channels via web sockets which allow bidirectional communication between client and server.  This can lead to realtime applications and alerting which will be topic for a future blog.


The examples above showed that new UI technologies as part of SAP’s technology portfolio have outstanding properties and allow to develop completely new UIs which can help you to differentiate from competitors. And this should be besides simplification (using SAP Fiori apps & Personas) a possible cornerstone of UX strategy: develop outstanding UIs which to innovate your business. Therefore you should do the following:

  • Identify pain points in your business. Try to find out whether new UI can lead to better man-machine interaction and improves the business process?
  • Are the business processes where a new UI can lead to a huge improvement so that you are better than your competitors?


Dealing with Different Speeds

With UI5 and some parts Floorplan Manager SAP separated the UI from the backend – it is exactly the Vishal Sikka’s concept of “timeless software”. One core principle is that you can change the UI independently. This is a huge advantage even in the development phase: one the OData  service is stable you will make any changes without changing the backend. So the UI frontend has a different development speed compared to the backend.


When developing business applications it is often necessary that the business logic can be changed quickly. In our development projects we decided to use the chance to renovate the backend and to control the backend process using rule systems created using BRFplus since this is very easy and agile to change. With solutions like DSM you can even perform hot deployment into production.


I think this a general best practice: usually we have best of breed systems landscapes and the backend systems are not that agile compared to systems at the “edge”. Today you can put edge innovation systems as well as backend systems into the cloud which gives you more agility. But the speed of the slowest systems (and in many cases they will we onPremise) dictates the speed for changing the system landscape. So it is a wise decision to get more agile in the backend and separation of business processes and business logic is the right step since the latter can be changed very easily. In the last year I wrote many blogs about this topic and even on a very detailed technical level so feel free to read some of them if you are interested in this topic.



So let me come to a conclusion:

  • In the center of SAP’s UI strategy is UI5 and can use it to develop Fiori-like Apps and use it even in Web Dynpro in HTML islands. So this technology is a cornerstone of SAP’s UI technology so UX strategy.
  • Besides UI5 the SAP technology portfolio offers many interesting technologies which can help you to differentiate from your competitors. In my opinion the combination of different technologies is most important since you can benefit from synergy effects: HANA can speed up the OData services and so the UI tremendously using search functions. And another very promising technology are business rule frameworks since you can need them also to enable decision support but you can also use them to make the backend more agile.


So the synergy of all mentions technologies in the blog entry can help you to differentiate from your competitors and you makes it possible to “redefine normal every day”.

The common usage patterns are of primary interest for both SAP and our customers.


  • On the one hand this information is highly valuable for SAP as an input into how we formulate the best strategy and approach to prioritise our own design, development and improvement initiatives.
  • On the other hand it should also be the basis for our customers to prioritise what transactions they target for improvement.


I want to share my own personal experience.


For years now I have been involved in discussions on this topic.  Right at the outset we are confronted by a variety of views on the best terminology to use and how effectively one can segment usage patterns.


A promising avenue that I have just became involved in is to look at enterprise data sets and analyse these with big data analytics.  The jury is still out on what will emerge as a working model.


I list five usage patterns below and the ‘time in the system’ increases in a descending order from 1 to 5 below:


Common Usage Patterns.png







1. Self Service Usage: Simple tasks such as booking leave, time entry, but also the approvals type transaction.

2. Reporting: Consumption of report outputs, as opposed to report creation & analysis.

3. Knowledge: This is a broad category that emphasises usage of system outputs as part of a knowledge area.  The main work of this type of usage is not inside the application.

4. Professional: This is another broad category that emphasises usage of system functionality, including report creation and analysis.

5. Heavy: This is a broad category that covers from repetitive system transactions (e.g. entering invoices) to a large range of transactions.  The common denominator is that these usage patterns account for the majority of system usage.


The five usage patterns above are broad usage patterns and serve as a general indication of what I have observed with many customers.

While listening to the User Experience Keynote of Sam Yen during TechEd 2014 in Las Vegas (http://tinyurl.com/kuwt5jj) with the topic: The Users Strike Back: The Force Behind a New SAP Experience, I was quite surprised by a quick demo of Caroline Welsh about SAP.Drive .


Even though the tool is quite interesting and accessible for everyone with a s-user or scn-account, the demo was just a 3:55 min walk-through.

You can watch the demo as part of Sam Yens keynote here:



Nevertheless, I catched the URL to the tool (it was shown less than 5 s during the whole demo...):



What is Drive.SAP?

The goal of Drive.SAP is to get prompt feedback on your design during an iterative project approach.


Or in SAP words:

Drive.SAP is an award-winning user experience application that enables SAP user researchers, product owners, and anyone working on design artefacts to validate and improve the user experience of SAP products.


Drive.SAP studies are simple to create and an ideal research tool that enables you to gather specific feedback from third parties, such as colleagues or customers, on images of your design artefacts.


The days are over when you sent screenshots in mails or via dropbox to get feedback from your customers end users, businness people or colleagues via mail, phone, chat or as annotated screenshots. At least that is the promise of Drive.SAP.


Let's see if the tools really fullfills this purpose.


How does it work

According to the "award-winning" usability of Drive.SAP, it should not be necessary to create huge how-to documents or videos. Depending on how you define award-winning, the tool at least made it to the category "People’s Choice Honorable Mention" in the UX Awards 2014 Winners list.



Nevertheless, the usability of the tool is really good and intuitive which is important for the participants who just want to provide feedback.


So, how to get started?

First you need to fire up your Chrome or Safari browser since a big annoying popup reminds you that Firefox or other browsers are not working:


On the Help page you can read that IE10 should also work fine. At least on IE11, I got the same popup. We will see what the future brings.


The initial steps are actually quite easy: Create a study and upload your screens you want feedback for.


Using drag and drop, you can re-arrange the screens to  get the final screen flow you want to show to the participants. After that, you can specify for each screen which kind of feedback you want to get and also add a question to it like "Do you want to see the password in plain text?".



Participants can answer in a free-text form or set marking points on the screen to highlight their feedback. After adding questions to EVERY screen, you are able to publish your study.

Attention! Once you have published the study, you will not be able to edit it anymore. So please ensure that you have the right order of the screens and added the right questions.


You can now share the study link to everyone you want feedback from. Unfortunately, there is currently no way to secure the study with a password. So your customer should be aware that everyone knowing the URL is able to see it. Currently, it is not possible to participate in a study without a scn- or s-user.


The good usability is shown especially for the feedback process. Before participating in the actual study, the participant gets a nice popup with some tips and tricks how to use the application.



Depending on the type of answers selected during creation (free-text or marker), the user can add responses to the questions or set four types of markers.


  • Like: simple Like icon + possibilty to add some text to it
  • Issue: yellow sign with an exclamation mark + possibility to add some text to it
  • Speech bubble: add some text
  • Arrow: to mark a position without adding text

That's it for the participant. He or she can decide in the top menu to allow displaying the name or staying anonymous.


The feedback can now be seen by the study creator.

What are the benefits

During the quick check of the tool, I can see the following benefits:

  • A tool with an easy and state-of-the-art user experience just doing its job
  • Easy way to collect feedback from various people gathered through ONE channel
  • It is now fun to provide feedback!


What needs to be improved

  • You need a scn- or s-user
  • No password protection to secure studies
  • Help page is currently clearly written for SAP internal employees including SAP internal links
  • No support address or contact outside of SAP
  • Browser compatibility popup



The purpose of Drive.SAP is very simple but a huge advantage if you can use it in projects with a clear design focus. Good to see that SAP is on the right way to create simple but useful apps. Sure, there is quite some work to do but as SAP is not promoting the tool currently (try to search for Drive.SAP at google and you will find just a few hints...), I expect that they are working on it right now.


Personally, I will try the tool in one of our next user centered projects to see how it works in real life.


What are your thoughts on that? Have you already tried it?

UI5 rules the SAP universe. There is a plethora of new tools and infrastructures provided by SAP (HANA database, HANA Cloud Platform (Java), Server Side Javascript in XS, Core Data Service and much much more). But the actual king for me is UI5. Though it’s not much more than a set of libraries and styles in a technology which has been there for ages. Whether it’s a brilliantly composed infrastructure, I can’t judge – as I don’t really know the alternatives. But it doesn’t matter: UI5 it the user interface technology which is being pushed by SAP intensively and which will surely be highly attractive to millions of SAP GUI-accustomed users out there. Hardly any end user can judge the impact of business logic being executed as a stored procedure inside the HANA database or the flexibility of running an infrastructure on HCP. But everybody can look at a UI5-based simplified user interface he once knew in the SAPGUI and say “that looks fresh – and it even works on my phone. Awesome!”. Therefore, I consider UI5 as the driver for business application renovation for the next years.

It’s not about SAP GUI vs. HTML5

Alright, beautiful new world, here you are. I’m learning JavaScript and will somehow manage to deal with an un-typed programming language. I’ll simply expose my business logic as OData via Gateway, as UI5 is based on this protocol. Should not be a big deal, should it? But slowly, second thoughts creep into minds of those developers who actually implemented transactional applications in the past. Some asked related questions quietly also this year in Berlin. Questions like “what about locking”? This addresses one major change in application development caused by the OData-protocol: Applications are supposed to be stateless. And not having exclusive locks which provide a server-side state about who’s under control of which instance is part of that. It struck me also this year was, how little SAP and the brilliant heads available in the sessions actually seem to care about this change and how easy this questions is answered with “there are only optimistic locks”. And I’m even more surprised by how relaxed the developers having asked this question accept the answer.
For me, this change in paradigm is huge! Let me explain why.

Stateless business applications

In the classical SAP development world (=ABAP, until just recently), applications were stateful: The application server knew about the state of the transaction in process. While saving, the state was committed to the database. Locks were either resolved or a new transaction started immediately based on the last image of the previous “transaction” including its locks. To me, this behavior seems absolutely appropriate for business applications: Multiple persons operating on the same data expect to exclusively work on it once they’ve successfully started to perform operations on the data. In our project, even a late exclusive locking (on first write access, not on clicking the “edit”-button) needed some explanation to the users before they could accept it as a feature (not as a bug). I do not know whether this expectation really is a need for business applications or whether it’s just something (SAP) users got used to throughout the years – I believe it’s both. In addition to resolving concurrency, users expect that a system validates their input. And in some cases, does not only prevent further processing, but also the saving of inconsistent states.

In a mobile world, where connectivity to the application server may not be as stable as in a wired office, this interaction pattern is not appropriate: The server must not hold a state which might be lost after the connection was lost or which leaves objects in a locked state as the transaction cannot be completed. At maximum it is acceptable to read data with some mechanism which informs the client that data which he has read is out-of-date as someone else has changed it (optimistic locks). The OData-protocol, upon which UI5 is based, implies such a stateless behavior. While the actual frontend-developer (those brilliant youngsters juggling with the Javascript) simply can rely on the model to which they bind the UI to be stateless while the grey-haired ABAP-developers who are glad to have mastered ABAP-OO are now confronted to fulfil the provisioning side of the protocol.

And there’s no in-built-support for enabling a stateless application-backend.

Figure 1: Evidence: The youngster with his responsive app and a group of fanboys and the grey-haired frustrated ABAPer - picture taken at TechEd 2014, Berlin

Options for stateless backends

Before I go on, let me say very clearly: I don’t know of any silver-bullet-application-design-pattern. I wanted to sketch some ideas which came to my mind and I want your feedback on them.

Assuming data has been read optimistically on opening the UI, the questions is what happens on write (“save”). I’d expect the optimistic read lock to be promoted to an exclusive one once a PUT or a POST are being transformed into backend modifications. If this locking is successful, other optimistic locks on these instances would be deleted. Thus, on a subsequent change from one of the other sessions, the backend could detect the concurrent change and then…

Dismiss concurrent changes

The most simple of the options surely is to inform the user that changes to the instances he wants to modify have occurred. Whether the current data is re-read automatically or whether the user is given a chance to actively refresh his UI is subject to what’s more acceptable to the user. Depending on the complexity of the operations performed, this interaction pattern can in fact be acceptable. Particularly for one-click actions and data which is actually owned by one user, this seems to be appropriate. No wonder leave-requests is the new “hello world” of the business applications.

Push channel

With a bit more of effort, the backend could provide a mechanism for actively notifying owners of deleted read-locks about changes which have occurred by another user. This limits the frustration as less data entered might be lost, but the mechanism remains: Simply inform the user and afterwards, dismiss his changes.


Knowing that concurrent changes might occur, one could also prepare the model for concurrent updateability: With an active/inactive-mechanism which allows to have multiple inactive versions for different users, the system could basically allow parallel operations on (parts of) the same data. A dedicated interaction with the system (e. g. an action “merge”), the always save-able inactive version of the business data which may even have been modified in several steps by the user could be merged with the active one. During this process, the backend can remember the changes done and include this in the algorithm once another session which has read and modified the original data pushes its changes to the backend. In this pattern, not even an optimistic lock would be required – but the merge-mechanism may be tricky to implement depending on the scenario. I believe that this interaction however would be most acceptable for users being used to stateful applications.

Is ABAP (and Web Dynpro ABAP) dead?

With the new world relying on Javascript in the frontend and the OData-protocol, it’s obvious that neither on the frontend nor on the backend ABAP is required anymore. You can even implement business applications with the UI5-look which are based on a completely non-SAP backend or you could use one of the other weapons SAP has in its technology arsenal for you (Enterprise Java on HCP, server side Javascript with XSJS or simply XSOData). But still, you could stick to good old ABAP and expose the service via Gateway. And from my point of view, there are good reasons to do this: ABAP (not as language, but as infrastructure) offers mature tools needed for business applications: A programming model which has first-level-citizens optimized for tabular data, a sophisticated authorization management integration, a brilliant change and transport system and much more.

I have sketched some options for a stateless backend, but honestly, I believe that still for transactional applications, the exclusive locking of a stateful application and the business transaction which allows to save only consistent data will remain the most required interaction pattern for complex use cases. In addition, connectivity has improved vastly over the past years and will surely be enforced more and more also with high-speed networks. Therefore, I believe that many new business applications will also be stateful at least in the next five to ten years. And if this is the case, the usage of the ABAP-based Floorplan Manager is appealing to me: Personalization capabilities are extremely powerful, the controls are optimized for the needs of business users, a real WYSIWYG editor is available and last but not least, the programming model is well established.

Consequently I guess we’ll have multiple types of applications based on OData and UI5 or FPM to exist side-by-side. Key with respect to user experience will be to provide styles for both the UI-technologies which don’t expose the difference in the application pattern to the user. Based on the use case, either a stateful or a stateless application may be launched without the user noticing any difference.

Importance of frameworks

Whatever your architectural decision looks like: To me it’s obvious that you need an application framework which helps you to implement generic consumers in order to fulfil different contracts. Whether it’s about providing generic feeders for the FPM UIBBs or about exposing the model as OData – having a metamodel in place will help you tremendously. Also these contracts evolve or the consumer (UI5, kapsel container offline plugin) require new aspects of the protocol to be implemented. Want samples: $expand, $top, delta tokens,… With the consumption technology evolving, it’s essential to have a technological foundation which keeps the pace.  From my personal experience, I’d even say it’s not possible to actually implement this from scratch on your own. Luckily, we don’t have to (those who followed my previous posts know what’s coming): With BOPF, SAP provides a framework which has a strong metamodel optimized for the delevopment of business applications. There have been consumers around (the Floorplan Manager BOPF integration (FBI), the Gateway BOPF Integration (GBI), Post Processing Framework, … ) which leveraged the benefits of this model driven approach. However, these components have been established based on the needs of business applications built upon BOPF (majorly SAP Transportation Management). This lead to the sad fact, that these components only supported the set of features needed in the consuming applications, not in support of all features possibly required by the consumption technology (e. g. there is no FBI feeder for the Form Repeater UIBB, $expand is not supported by GBI).

But with SP8, this has changed tremendously: SAP now provides an abstraction layer called SADL, the service adaptation definition language. This runtime artifact consumes various types of metadata and provides generic adaptors to the latest UI-technologies. And what’s best: It’s being developed in close cooperation with the consumer-technologies (FPM, Gateway). Personally, I’ve got huge expectations with respect to SADL really making BOPF timelessly consumable software.

The only thing which I don’t understand at all: Why is an application framework based on well established technology not being promoted at TechEd? Of course, this is not as sexy as showing new UI controls, as integrating IoT-sensor data or as aggregating zillions of BSEG-items within the blink of an eye, but in the end, it (still) is all about business applications. So why not show how to actually enable developers to get this done? Maybe next year, when SAP cares more about actual application development. This year’s keynote was a step into this direction, at least I keep telling this to myself.

Let me tell you about an interesting event organized by Dutch SAP user organization (VNSG) yesterday. The User Experience and the Custom Development focus groups joined forces and set up yesterday’s meeting about Fiori. The idea was to have Dutch customers present their experience, but unfortunately we couldn’t convince any of them to stand up to present. On the other hand, we had Marcel Smits, who is Fiori Factory Lead inside SAP EMEA, to tell what he learned about Fiori implementations at 90 customers.




Marcel introduced Fiori and emphasized the importance of great design, which creates an emotional connection with the end users. He talked about SAP’s goal to unify the UX for all SAP software. This means that the Fiori UX will be rolled out to all solutions. Not the Fiori technology, just the Fiori user experience. His first presentation focused on the Fiori apps roadmap per LoB where planned innovations are listed for the coming half a year and future innovations beyond half a year. Basically SAP releases a new wave of apps in each quarter. What we can notice is that the apps are getting more specific for certain tasks, some of them cover more complex processes, which took SAP more time to simplify. He made an interesting comment about a new WDA app for cost center hierarchy, which was released as WDA, because it was too complicated for the Fiori paradigm. Another interesting detail was about the My Benefits app, which is primarily created for the US market and therefore cannot be implemented “as plug and play” for the Netherlands. Marcel took some time to explain why some apps require HANA, while others don’t. He mentioned various reasons such as the use of HANA search models, use of HANA Live and the case of Fiori apps which require re-written, HANA-optimized backend logic.


Marcel shared his experience in Fiori implementations. He organized it along the 3 phases of UX adoption:

  1. Advise - What is my strategy and roadmap?
  2. Launch - How can I get started with deploying Fiori?
  3. Accelerate - How can I accelerate deployment of Fiori?


This presentation gave a very good overview and gave some very specific details at the same time. He talked extensively about the value of good design and he introduced the UX Value Calculator which can be used to quantify the benefits of great UX, in this case Fiori, and express the value in Euros based on many factors such as time saving of management. He talked about security around Fiori. Most SMEs use reverse proxy and SAP Web Dispatcher and larger organizations with more complex requirements implement SMP and Mocana. We had some conversation about SAP Notes, Marcel suggested to check them weekly, because they bring fixes, but also new functionality – which should be evaluated by customers. His advice was to keep track of all manual installations steps in Dev to speed up the setup of QA and Prod. Regarding project approach, he emphasized the importance of project management and he recommended the agile approach if at least 2 sprints can be defined in a project.

Aviad Rivlin, PM and SAP Mentor from SAP Labs Israel joined us virtually and presented via SAP Connect. He introduced the Fiori Launchad and gave a live demo. He defined FLP as “Intuitive, modern and easy to consume single point of access for bus applications and content”. He explained the 4 deployment options: ABAP (Gateway), JAVA (Enterprise Portal), Cloud (HCP) and HANA. He expects most customer to use the ABAP option, because it supports all Fiori apps. FLP in the portal works the same way, but the underlying technology is the portal and the Fiori apps run on the ABAP Front End Server. In case of HCP, the connectivity to on premise backend systems is provided by the Cloud Connector and the Fiori apps themselves run on HCP. He got questions about the future of FLP in relation to the SAP Portal so he spent quite some time explaining SAP’s UI client convergence plan covering alignment between Portal and FLP.


Wim Snoep and Leo van Hengel presented how to change and create Fiori apps. Wim talked about extensibility on 3 levels: backend (ABAP or HANA XS), Gateway/OData and front-end. He mentioned that modifications can be as simple as styling, but can mean introducing new functionality. He described his project approach consisting of 4 phases:

  1. Mockup
  2. Build services
  3. Build screens
  4. Test



Leo gave a nice live demo of Web IDE running on HCP trial. For many participants it was very interesting, because this was the first time they saw this new tool.

Finally Henny Claessens talked about his experience at AppHaus Heidelberg. This short presentation, more like a pitch, was nice to hear about this SAP initiative. It is basically a creative environment where SAP designers, developers, and customers can work together on new, innovative products in multidisciplinary teams. It aims at merging engineering and art. The Design Thinking workshop where Henny participated was about how to bring design education to SAP customers and partners in the form of DesignEd.




As far as I know this was the first time that students (from Amsterdam University of Applied Sciences) joined a VNSG meeting. We were happy to accept them to learn about Fiori.

You have your UX Strategy in place and now the question is what do we improve?


We already made the point that the topic of UX involves a number of elements that are linked or dependent on each other.  From the front-end interface, connecting to an application that renders a system process, based on a business process, with master and transactional data, to the technology platform and architecture.


It follows that with so many moving parts, we need a methodology to bring all these elements together – we need a Roadmap.  The main driver for a roadmap approach is the fact that any solution requires the availability of UI components.  These components change over time and are influence by other components.  So a solution that is not feasible today may be feasible in a few months due to a change or update to the landscape.


Key Principles


1. Focus on Value


Improving UX for the sake of it does not serve much purpose.  For this reason we believe this should be a targeted effort to identify
the business value opportunities.  In my blog 03 I discuss the balanced scorecard approach to UX value and that applies here.  Business value accrues either from value opportunities – introducing a new capability that adds new value, or by solving UX pain points that have a business impact.


2. Focus on Data


Data is the golden thread to discover the value opportunities.  Data also needs interpretation and understanding so this process also requires interaction with users.  The data helps us to follow a method of prioritisation, so that we consider the whole but find a way to identify the best opportunities.  At the end, the data is what we use to justify as well as to quantify the business value.


3. Transactions, End Users & Landscape


We derive our target value opportunities by focussing on the transactions to prioritise, which end user groups to prioritise as well as what the landscape capability offers.  I want to reiterate the end user again.  We are looking to solve the UX pain points of user groups / roles that offer business value.  We are not looking to change a few transactions within the whole of SAP.


4. Time-boxing


As a principle we recommend that you set a time limit on this exercise to avoid  the ‘paralysis by analysis’ trap.  The resources need to be prepared and available for this exercise.


The Stages


We follow a 3 stage approach: Discover > Assess > Roadmap.  Between the Assessment and Roadmap stages we have a decision point where our recommended solutions require approval before they are planned for user coherence and integration into the SAP roadmap.



UX Roadmap.png




During the Discovery stage the aim is to generate as much information as possible and to evaluate this in a way to drive a prioritisation of transactions in the first instance and then of end users.  We consider multiple types of information for this exercise and in practice this depends on what information is available within a reasonable time.  This stage ends with a consolidated list of transactions and users in scope.


During the assessment stage we assess firstly what ‘Out of the Box’ solutions are available from SAP and then consider the appropriate enablement solutions.  The enablement solutions involve the design and build of the solution for the transaction and the users.

The second part of the process is to validate the initial assessment results.  For this we utilise a basic set of validation criteria: Desirability; Feasibility and Viability.  The result of this stage is a set of recommendations.


We recommend an approval step before proceeding to the last stage.  The UX Roadmap is created firstly by developing a user coherence plan and then creating the UX roadmap that integrates the UX solutions, UI components and end users.


Lastly please note that this methodology requires a cyclical approach that every cycle will target the priority areas and over time will drive a UX transformation of your SAP estate.

On Tuesday of the week before Las Vegas SAP TechEd && d-code it was windy in Sydney. In fact it was very windy. A serious low pressure system was passing over us and bringing winter-like conditions to much of eastern Australia. In parts of the Blue Mountains - just east of Sydney - snow cut roads and railway lines, trees were down everywhere, etc. All this on the second week of October - well into our spring and very unseasonal.


Someone sent out a tweet - sorry I can’t remember who - that drew my attention to http://earth.nullschool.net. This is a site built by Cameron Beccario, @cambecc, that provides a visualisation of global weather conditions, ocean currents and ocean surface temperatures.


On Tuesday 14th October eastern Australia looked like this - except animated of course.

Screen Shot 2014-10-28 at 5.33.59 pm.png


I spent a bit of time playing with the user interface because it was so much fun and so interesting. You can adjust the altitude to see the wind conditions at different levels right up to the jet stream and stratosphere. Move forward and back in time to see changes. Modify the map projection to see the whole world in one page. Etcetera.


Screen Shot 2014-10-28 at 5.39.38 pm.png


As I looked to see how Cameron had built this I was pleasantly surprised to find that he had made the project available on GitHub for anyone who wanted to make use of it under a MIT License. Great - I couldn’t clone it quick enough.


Looking at the code I was amazed. Firstly it was primarily only Javascript and SVG. Wow. Secondly I noted how many other projects and resources Cameron had leveraged to produce his awesome “earth” visualisation.


Javascript libraries included Node, D3, backbone, and when. The mapping data came from Natural Earth, a public domain dataset, weather data from the US National Weather Service, etc.


I knew Clint Vosloo and Chris Rae were planning to enter DemoJam the following week with an entry called Swell Analytics. Swell Analytics used an API supplied by MagicSeaweed that provides Surf conditions from all over the world. I thought Camerons' “earth” visualisation would be a great starting point for the UI which would allow the user to search around the world for a surf spot and then drill down to get the surf conditions in detail.


I added the OpenUI5 library to Camerons’ project and a single Javascript call that triggered my code and passed the selected map coordinates. When my code was called it instantiated an OpenUI5 dialog box that ran as part of the “earth” visualisation but independent from it.


The map coordinates were passed to a web service that returned the nearest Surf Spots monitored by MagicSeaweed. When the user selected one it then called the MagicSeaweed API to get the surf conditions for that spot.


The MagicSeaweed API returns all surf condition reports for the spot over the past few days, including weather charts and forecasts. By moving quickly through these charts I could produce an animation effect that looked pretty cool.



Once completed I handed over the code to Clint & Chris to plug in their components. These included historical analysis of the surf spot and analysis of related social media feeds using HANA.


I had spent less than 2 hours on this - but there is clearly more than two hours work in the result. A true example of collaborative development. I have not met Cameron or the people who worked on D3, or backbone, or Node. I don’t know anyone at the National Weather Service or Natural Earth. But we all worked to produce this outcome and I am deeply grateful to all of them. So are Clint & Chris.


That is why GitHub, and other services like it, are so important to developers today. That is why SAP CodeExchange was so important and why it was so disappointing that it was killed with little notice. For developers to truly collaborate we need a distributed revision control, change control, call it what you will service, and associated tools, to support us. That is also why SAPLink is so important - a great collaborative project totally driven by the community.


Most important of all is the developers who share their work, outcomes, and experience with the rest of the developer community and thereby make the whole greater than the sum of the parts. They allow minnows to stand on the shoulders of giants to produce great outcomes.


If you don’t know what Git is I think it is time you found out.


You can watch a replay of the Swell Analytics Demo here.

Graham Robinson

SAPUI5 === Golf

Posted by Graham Robinson Oct 28, 2014

I was fortunate to be invited to participate in the Blogger Program at SAP TechEd && d-code last week. I had a busy week of meetings and meet-ups, keynotes, briefings, etc. and I also did a couple of presentations on SAPUI5.

Several times I found myself trying to explain to people why this web development stuff is so hard.

My pitch went something like this.

"This SAPUI5, Javascript, oData, Gateway stuff is not as easy as some people make out. It is not just opening up the manual and doing a bit of reading. Neither is it taking a few OpenSAP courses or doing a few tutorials and you will have it covered. Learning the syntax of Javascript is not enough. Learning all the SAPUI5 controls off by heart is not enough. Knowing how to use transaction SEGW to model your Gateway service and then falling back onto good old ABAP to do the heavy lifting is not good enough either."

"All this stuff takes time to learn, time to get experienced with, and requires time to fail. You will not get this right the first time - or the second - or the third. As you learn more you will come up with new, and better, techniques to achieve what you want to achieve. Sometimes these new techniques will be developed because you realise you could have done something better. Sometimes a colleague will share his techniques and you will find pieces of them better than yours. Sometimes you will learn from others sharing via SCN or Stackoverflow."

"Also the underlying technology will change - and you will need to change to adapt to it. For example, the whole way that SAPUI5 does in-app navigation changed in release 1.16 and, while the previous techniques will still work, the new way needs to be absorbed and understood."

"It is all about experience. And the only way to get experience is to do it. Then do it again, and again, and again. Refactor old code to adopt new techniques. Share and learn from others. Always be looking for better ways. Rely on proven design patterns rather than create your own."


You get the idea I hope.


So, I am in this meeting with Sam Yen. Sam is the Global Head of Design and User Experience at SAP. He is largely responsible for SAP’s focus on design, and design thinking, and the end-user. He is a designer - I am a techie. Sam listens to me struggling for several minutes to describe how important I think experience will become with SAPUI5 developers and he sums it up in two words.


“It’s golf”.


Don’t you hate that?



Graham Robinson

SAPUI5 Momentum

Posted by Graham Robinson Oct 27, 2014

I was fortunate to be invited to participate in the Blogger Program at  SAP TechEd && d-code last week. I had a busy week of meetings and meet-ups, keynotes, briefings, etc. and I also did a couple of presentations on SAPUI5.


One of my takeaways from the event was that there is growing recognition amongst the SAP developer community that this SAPUI5 thing might be something of some relevance to them. In my opinion this is a good thing.

Screen Shot 2014-10-27 at 11.00.18 am.png

Technical people, especially Developers, are a pretty sceptical bunch and need time to understand new technology releases and to build trust that they will serve them well. And for SAP UI Developers this is especially so due to many false starts in this area over the past decade. The obvious example is WebDynpro which has never really gained much traction. There are two main contributors to this. The first is that SAP never seemed to get on board themselves - for example the only WebDynpro transaction I recall using much is SOAMANAGER. The second reason is that WebDynpro screens never seemed like the answer the end users' were calling for.


SAP are certainly committed to SAPUI5 - and committed to oData too which is an important thing to be recognised. SAPUI5 is SAP's "go to" technology for building user interfaces across their entire product range. Tangble evidence of this is that the number of available Fiori apps has now passed 500 and this initiative continues to have a strong focus.


And the screens produced with the SAPUI5 libraries do look pretty good. In an area where people can be very subjective it is hard to find anyone who does not like the cool blue Fiori-style. It goes beyond the look of each individual control too. The SDK has tons of examples that shown in the context of a full application. In this way they are also serve as part of a more subtle campaign to guide the developers, who typically aren't great UI designers, in how to combine these fundamental UI components into complete applications with suitable aesthetics. Essentially the demo apps that show how things work also serve as part of more holistic design patterns, thereby encouraging a consistency that would be impossible if every developer went their own way.

Screen Shot 2014-10-27 at 11.22.52 am.png


As mentioned, I twice presented an ASUG session that was designed to help the total newcomer to SAPUI5 understand where it fits in relation to other web technologies as well as the rest of the SAP technology stack. Those who attended the second session got a smoother "user experience" as a self inflicted technical issue disrupted things a little in the first - but in both sessions there were many in the room who realised SAPUI5 was an important technology they needed to add to their skill set.


Don't be fooled by any personal scepticism or jeering from the sidelines. The SAPUI5 libraries are very good and can stack up beside the others popular JavaScript libraries. The data binding stuff is very slick. As John Patterson, whose opinion I highly respect, says - "It just works!". I am also coming to appreciate the way SAP has implemented the MVC design pattern and there is no doubt the library has an extensive set of very sophisticated controls.


So let me suggest a few tips about how you can start on the road to becoming a true SAP Web Developer. Others will have their own suggestions and I encourage them to put them in the comments.


  1. Learn the fundamental web technologies of HTTP, HTML, CSS and especially JavaScript. As you do so consider why HTTP is on this list. Hint - I didn't say find out what these things are, I said "learn".
  2. Learn how to use the debugging tools of your favourite web browser. I recommend Google Chrome but ultimately it is a personal choice. Knowing the purpose of these tools and how they work will help you with Step 1. Not to mention debugging tools can be handy during the development lifecycle - but you knew that right?
  3. Download the OpenUI5 SDK from GitHub, install it, and start reading. There are tons of guides, examples, etc. and all the code is there too.
  4. Setup your own personal development environment on your local machine. Improve it the second time. And the third. Etcetera.
  5. Start building stuff because Steps 1 through 4 won't make you a web developer. It is a skill that requires considerable familiarity before you become even a little bit competent. It takes time, practise, evaluation, etc. and lots and lots of refactoring.


There are of course plenty more things you need to learn and do to successfully add SAP Web Developer to your resume - I have planted some seeds in this article if you look close enough.


And let me close by pointing out how important the right attitude and an inquisitive mind are. Chris Solomon captures this aspect better than I ever could in his recent post My path to learning OpenUI5.....deeper down the rabbit hole and back again!


I am lucky enough to be spending a few days in the Nevada desert at SAP TechEd and d-code 2014 in Las Vegas. Yesterday I sat in on a roundtable/panel discussion hosted by Michael Falk covering UX Strategy Implementation. The participants (including Damean Chen) had some great experiences of implementing a UX strategy at their organisations. In this quick bog post I’d like summarise some of the key points that I took away from the session.


Understand the User Journey

Everyone agreed that this was of paramount importance. There is no substitute to getting to know real users, not proxies, not people who “think” they know what the users want, but real honest to god users of the system. Understand them, understand their needs, wants and hopes, spend time with them and build “a day in the life” scenario and you will be much more successful.


It’s not all about the User Interface

In fact the UI is only one piece of the puzzle albeit an important one. An example of something that greatly effects the UX is Single-Sign-On (SSO). It’s just something that when it works everyone is happy. It’s a bit like the war on terror, get it right and you get no praise but get it wrong and you’ll know about it… fast.


Have a UX Centre of Excellence

Sounds scary eh..? A UX COE… boo! But seriously having somewhere to turn for guidance and direction to make the right choices and provide UX services is the right thing to do. It provides consistency and governance, driving forward your UX strategy.


Be Agile

Oh no, not agile… really. Yes really… in fact it makes perfect sense, being agile means you try stuff out early (on real users) and get their feedback, then you fix stuff and make it better and test it out again (on real users), then rinse and repeat. Duh… simple.


Start Early

Start usability testing with the design (hey this can fit in with being agile… see above). Fixing stuff in the design is much easier than fixing it in the code after User Acceptance Testing just before go live. Do yourself a favour start early.


Expect to have a Cross Functional Team

Good UX is the intersection of Human Values (People), Technology and Business Goals. Guess what to be successful you need to have people from all 3 of these areas in your team - think of them as your 3 musketeers!


Pick something that will have Real Business Impact (credit to Jocelyn Dart for this insight)

It’s tempting to start small and easy (e.g. Leave Request) - do a proof of concept and see what happens hoping it will drive wider adoption. But be careful, you’re better off choosing something that has a real impact on your business, something that matters, improving something that matters, something that people use a lot will give you way more bang for your buck. It may be a bit more risky but hey we’re in Vegas so roll the dice baby.


I’m afraid I had to leave the session before the end due to another commitment I needed to run to so there are no doubt more golden nuggets of wisdom I missed out on. Thanks to everyone on that panel, it was great. Please add your thoughts and comments below

You may by now be well aware that one of the key recommendations for all our customers is to develop your own UX Strategy.

Why do we make this recommendation? 

Let me highlight a few key reasons:

1. Execution of Enterprise Strategy

Your enterprise will have a number of strategies in place that are also in the process of execution.  As a simple example:

  • Enterprise Strategy: How does your enterprise deliver value; Achieving which outcomes?
  • IT Strategy:  How does IT support your enterprise strategy and outcomes?
  • SAP Strategy: How does SAP support the IT Strategy and outcomes?
  • SAP UX Strategy: How does SAP User Experience support the SAP Strategy and outcomes?

There is a hierarchy of strategies in action that all drives towards execution of the enterprise strategy and achieving the defined outcomes.  This leads logically to the primary purpose of the SAP UX Strategy.

2. Business Value

The primary purpose of UX improvement is to deliver Business Value.  Please reference topic 03 in my blog series were I discuss this in more detail. It should be clear that to support delivery of the SAP Strategy, we need to fully determine the appropriate mixture of business values to target within a defined period of time.

3. Assessment Guidance

The SAP UX Strategy should be executed through the process of developing an SAP UX Roadmap and implementing the defined actions.  During the process of developing a UX roadmap we have to make recommendations.  One of the functions of your UX Strategy is therefore to provide guidance during this assessment process.

For example, what is your principle around the topic of remote working?  Do you want to provide your user with offline access to the business application?  Your UX Strategy should incorporate architectural principles to provide guidance for these decisions.

4. Landscape:

UX improvements operate within a technical and landscape context.  For larger enterprises, your enterprise architecture are under governance control to ensure stable and available business applications.  The pace of UX improvements are clearly impacted by the availability of the required technical and landscape components and these can usually not be changed on short notice.

An example here is your internet browser.  This is a UX relevant component for using particular UI technologies.  SAP UI5 is based on html5 and there are compatibility issues with browser versions.  In this case, defining your UX Strategy should help ensure that you have appropriate policies and strategies in place that govern all UX relevant components.

Overview of Strategy

A strategy can be defined as a plan of action designed to achieve future goals.  Any strategy is anchored by two states; where are you now and where do you want to go.  The current state should include an assessment of both the internal and external environments.  The future state sets out a desired future vision.

In between these two states is where the tyre hits the road!  A good strategy sets direction – how do we move from the current state to the future state – and must be actionable.  To be actionable it should therefore describe the practical aspects with sufficient detail so that is actionable.

Customer SAP UX Strategy

In this blog I discuss the topic from an SAP perspective only, but clearly you may require a corporate UX strategy and the SAP strategy will in this case be a specific supporting strategy.

I want to highlight one particular section that I expect to find in your UX Strategy:  End Users.

Ultimately the value of SAP starts by how successful your end users are in their use of SAP applications.  Here the expression GIGO applies = Garbage In Garbage Out.  It is a bit more complex than just this, but I trust you understand the point here.  Let’s consider a few implications.

1. Adoption: At the basic level we need users to use SAP and not use unofficial processes and products.  In this case an enterprise is not able to gain a clear and accurate picture with an audit trail of what is happening in their business.

2. Compliance: We need users to use SAP in accordance with the defined processes and policies.  The business case to invest in SAP is based on assumed use of SAP.  The enterprise and IT strategies are dependent on the execution within a defined framework.

3. Value Add: The above point may sound very rigid.  I want to share two considerations.

(a) A very capable end user should be able to add value through their effective use of SAP by making good business decisions and taking timely action.

(b) We recommend that enterprises actively work on gaining insight into the use of SAP and how this may be improved.  Please note that this is a very wide topic that straddles enterprise policies, business processes, system process, data, information and technology. 

The end user and how they use SAP is where user experience ultimately sticks in your enterprise.  The user does not per se care about which technology they use.  They do care about how easy it is to use and how effective they can full-fill their role.

One last point: If you take this into account it should be clear that UX should be improved through identifying the priority user groups / roles to target with a holistic SAP solution for all their SAP use.

SAP UX Explorer

This is a very good reference source for customers and supports our ‘Experience SAP’ source.  I work regularly with my colleague Juergen Jakowski who has written a section around customer UX strategy which I highly recommend for your consumption:


Also see under the ‘Documents’ section the presentation with notes on the topic.

This is the second blog in a series that will look at the following five perspectives that are changing in the SAP world:



Two years ago, I wrote this blog series during SAP TechEd 2012 that explored which options SAP customers had when looking to improve the user experience of their SAP users.


The good news is that the options have not really changed, but the great news is that SAP has taken what were “technical frameworks” at that point  and incorporated them into products. Specifically, Fiori has gained momentum and, in line with Sam Yen’s UI strategy, it is now being used for all new applications (that I know of) and is being used to renew many more. Beyond this, SAP has continued to invest in SAP Screen Personas, which can be used to simplify or tweak SAPGUI and has removed the dependence on SilverLight – so it’s much easier to deploy.


I have even heard people whispering that this dynamic duo (Fiori/Personas) might become the primary way SAP Users interact with SAP – providing an additional option to classic SAP GUI.


Fiori - LaunchPadPersonas - Select Functional Location



Having said that, SAP GUI 7.40 just shipped, including the “Fiori Style” Blue Crystal Theme, and more interestingly, the 7.40 release that comes bundled with SAP NetWeaver Business Client (NWBC). This blog by my fellow SAP Mentor John Moy highlights the value SAP NetWeaver Business Client can add to classic SAP users. It is also worth remembering that many classic SAP GUI screens have been improved with Web Dynpro ABAP via Enhancement Packages (see this example for Plant Maintenance in EhP 6). Finally, look at Personal Object Worklists (POWL), which can help an SAP user understand which objects in the system need their attention (e.g “Purchase Orders past Goods Receipt Date for My Vendors”).


So we start to see a future where power users might use NWBC (hosting a variety of UI technologies) and casual users access content via Fiori LaunchPad/Fiori and Personas. The icing on the cake is the SAP Web IDE (this was formerly called “SAP River – Rapid Development Environment”) to extend existing applications and develop new ones.




So there are plenty of options - you can browser them all at the SAP UX Explorer.


So where do you start?


First Step:  Understand Your Problems


Plenty of people complain about “using SAP,” but not so many have really done any analysis on where the specific problems exist. So a logical first step is to perform an analysis of what is driving the problems.


I would suggest you start by creating a matrix that maps your user community and rates the level of problems users have. For the top three areas, you can start to assess what could be done to help and start to build the business case for a new user interface (I discussed a framework for doing this in the 2012 blog series).


Second Step:  Understand the Options


The second step, which can run in parallel with the first one, is to understand what the option are. OpenSAP can help here with courses on SAP UX strategy and SAP Fiori. You can also read the SAP UX Strategy and use SCN daily to engage with others who have already started their journey.


Third Step:  Hardware and Software


Depending on what you decide, some options will already be available in your landscape (quick wins), while others will require you to adjust your SAP landscape roadmap.


For proof of concepts, you might look at the Cloud Appliance Library or invest in your own innovation system. HANA Enterprise Cloud and HANA Cloud Platform also offer options for fast and lower-cost deployment options. Find more details in my next Cloud blog later this year.


Fourth Step: Create an Implementation Programme


Finally the rubber needs to hit the road. You need to create an implementation plan!


One good thing about most of the UX solutions is they can be run in parallel (not recommended for long term TCO, though). So you can select the best business case for UX renovation and work from there.




If you go through the above process, I predict two things:


  1. You’ll find a user interface solution you already have, or which could be adopted quickly.
  2. The user experience that most of your users get today will be radically transformed – and at the end of your three-to-five year roadmap, most users will never have heard of SAP GUI (even though some will still use it via NWBC or Personas).

I would like to see every customer of SAP gain a level of user experience with SAP that satisfies their users and
realises real business value. 
This is an ambitious goal and all my experience points to one fact: realising this is a journey and not a destination.  The reasons are simple – user expectations are increasing and what success looks like is evolving.  Underlying this are an number of factors.


External to SAP are a number of mega trends that affects people, organisations and society's expectations, for example the
consumerisation of IT.


Internal to SAP are a number of forces as a result of SAP responding to the external environment and our stated goals:

(1) The SAP Software Portfolio has increased at a pace since the mid 1990's, fuelled by technology evolution of the web and major
acquisitions by SAP.

(2) Innovation by SAP led to the development of the global standard in business applications, powered by in-memory computing, cloud, analytics and mobility.

(3) SAP is fundamentally transforming its User Experience across this vast SAP portfolio and the pace of this change is accelerating.


For our customers there is one particularly important implication.  The future of SAP is business applications in the cloud, on an in-memory based platform, consumed anywhere by all stakeholders.  The key question is when are you planning to switch over?

This decision is integral to your IT and resulting SAP Strategy.  Are you an early adopter or part of the early majority?   At the time of writing we are probably nearing the end of the early adopter stage.  That means if you are not yet planning for such a transition you probably already fall within the late majority segment of customers.


Adoption Curve.png


The reason for including this in the first blog is to make it clear that there is a transition journey for SAP customers and the underlying architecture separates those customers on the high road from those on the low road.  Both are valid, as long as you have defined this
strategy.  If you have not yet then I strongly recommend that this is a top priority for 2015.

When we consider the topic of UX improvement we should also understand where in the lifecycle of the application we operate.


User Experience Lifecycle


The lifecycle of user experience follows the lifecycle of application software.  The classical model remains valid:


1. PLAN: Business Strategy > IT Strategy > SAP Strategy > UX Strategy > SAP (incl. UX) Roadmap with software selection.


During this first stage UX is particularly relevant when it comes to ‘Software Selection’.  Business requirements require you to translate and execute in accordance with your strategy.  This may or may not result in SAP being selected as the recommended software.


2. BUILD: Design/Blueprint > Realise / Configure > Prepare for Go-Live / Test > Go-Live / Deploy


During this stage you have the opportunity to consider the UX of the applications in scope.  The process is similar to that described in RUN below apart from that it needs to integrate into your Implementation Plan with multiple integration points.


3. RUN: Operate and Support the application; Upgrades / Patches; UX Improvements


During the operate stage of applications you plan updates/patches and upgrades to maintain the applications.  The key opportunities during this stage are functional improvements and user experience improvements,


In this context, SAP developed an improvement framework for UX based on an SAP estate in operate mode.


SAP UX Improvement Framework


UX Improvment Framework.png


The improvement framework is divided into 4 phases:


1. Understand & Learn


This phase focuses on 2 components that drive the major outcome of establishing a customer UX Strategy.  Understanding is based on gaining knowledge and insight on multiple topics, specifically SAP information such as our UX Strategy as well as customer strategy details.  Knowledge of the respective sides helps SAP and our customer to formulate an initial customer UX strategy. 


There is no substitute for practical experience of SAP UX solution components in the customer landscape.  This experience validates the principles, values and limitations of User Experience and takes the initial UX Strategy and turns this into a final customer UX Strategy.  Note that the UX Strategy document should be considered a living document and updated on the cyclical basis.


2. Discover & Plan


Now we need to execute on strategy.  The key questions to answer are what should we improve to gain what value, for which user, and with which solutions do we achieve it?


To answer these questions SAP developed the UX Roadmap methodology that (a) Discover the priority transactions, appropriate end users, UX pain points, and Landscape components; (b) Assess the options and make solution recommendations; (c) Develop an outline business case for each solution and submit for approval; and (d) create the SAP UX Roadmap by integrating all UX and UI components in line with the customer SAP Roadmap.


3. Realise & Measure


During this stage we plan and execute the SAP UX Roadmap.  This involved technical activities as well as design and build activities for each solution component.  Part of this plan also involves planning for user coherence based on the recommended UI clients and theming.  The ultimate outcome of this stage is the delivery of UX improvements to end user groups and measuring the effectiveness of these improvements.


4. Sustain


Improving the User experience of SAP will not be a one-off activity for most of our customers.  It is better to view UX Improvements in the same light as you view application and landscape maintenance.  The key question is always to seek business value.


The ability to execute this approach requires a capability from our customer to work across the UX lifecycle.  A capability from an organisational point of view is made up of people, processes, tools and governance.  Lastly, design also requires the appropriate space.  The outcome of this stage is to establish User Experience as both a capability as well as embed it into your organisation culture.


Filter Blog

By author:
By date:
By tag: