SIMPLE Fiori apps for COMPLEX business processes

SAP has been talking the language of simplification for several years now, and of course its customers have been screaming for many years that SAP is too hard, especially for occasional users. And in fact, here at Arch, we’ve made a business out of making SAP easier since 2004.

But driving simplification is a really important business driver. Delivering intuitive apps drives user satisfaction, increased productivity and process efficiency. And as a sideline it reduces training costs too.

However, there is a fundamental challenge, because real life isn’t simple.

Firstly, SAP transactions and processes, designed to support many different types of organisation and industry, are complex by their nature. Otherwise there would be no need for simplification.

Secondly, business processes and requirements are also complex. To illustrate: As organisations have driven cost savings through headcount reduction, job definitions have grown, and thus we expect more from our employees.

So we have complex systems AND complex processes, and the burning need for simple solutions.

There are a number of approaches we can take.

1. Firstly, re-design the business process. Given that existing business processes may be designed around SAP transactions and document flows, this can mean a move away from transactional data entry, and the ability to design processes that are de-coupled from the SAP updates eventually triggered.
2. Secondly, deliver different solutions for different user communities. Perhaps some communities are best served by a different app or approach to others.
3. Thirdly, replace complex transactions with multiple simple apps. So instead of delivering a like-for-like replacement with Fiori, we split down the requirement into several intuitive apps.

There are challenges with all three approaches.

1. Business Process Re-engineering in the new world is hard. In the past it was comparatively easy as we were moving organisations to standard SAP processes. But defining new processes, largely independent of the underlying SAP update is a totally new challenge.
2. Different solutions might mean different processes, not just different apps. Adding multiple solutions might actually serve to increase the overall complexity, which undermines the whole point.
3. Delivering multiple simple apps requires building and managing a growing library of Fiori apps. This can create its own problems.

So, how do we overcome these challenges, and deliver simplification in a complex world?

Methodology

Firstly let’s consider a methodology to directly address each challenge.
Process
We start with imaging the new business process. Here we need to embrace new ways of working, and throw away the old rule book. This can’t be IT-led, as the tail cannot wag the dog.

So we begin with workshops, in which we explore options and consider the art of the possible. This is not a traditional requirements gathering exercise, but a semi-educational session during which we can look at event-driven processes, collaborative working, how analytics can support decisions or user priorities.

We need to consider the entire business process – how do we notify users? How do we manage delegates? How do we handle exceptions?

This isn’t something that we can do to you – we can only open up your mind – turn on the light if you like. And equally you can’t do it to yourself, as your employees are too close to the existing solutions. So by its nature it has to be a collaborative process.

App
When we come to the design of the app itself, we have to design around USERS, not existing processes, or SAP transactions, or BAPIs.

This is the so called ‘design-thinking’ part of the methodology, encouraged by SAP, where we design ‘personas’ to represent real business users, understand their particular needs, and build an experience to deliver those needs.
So we need to throw away SAP terminology and the entry of meaningless fields. We are not constrained by the current process or the SAP transaction.

This might seem a little far-fetched, perhaps even like a consultancy feathering their own nest, but this is unbelievably valuable. In fact we’ve dedicated our session in September to this in order to give it sufficient time.

Again, this needs a collaborative approach, because on the one hand you need to have knowledge of the business need, and on the other you need to have the distance from the current process to provide the perspective.

Multiple Simple Apps
Now let’s consider breaking up existing transactions into multiple apps. On the one hand, we don’t want the cost of maintaining 100 apps, and on the other hand we don’t want the cost of maintaining a single uber app that does everything. So clearly a sensible balance has to be struck.

The use of overview screens can help – in this way apps can be grouped without cluttering up the LaunchPad main view. And apps can be designed with common components, and with the ability to branch from one app to another, so that what is presented to the user is simple – and in fact may look like a single app, but behind the scenes the solution is designed with more than one.

You might argue that this comes down as much to common sense as to expert knowledge, but in our experience, organisations ask for a price for an app. And when an organisation gets a price for an app, there is a tendency to try to cram as many requirements as possible into the app – on the basis that it’s what the current system does. That’s an approach that sacrifices the usability and simplification that introducing the app is supposed to deliver, so it is deeply flawed. Our role as a third party is to guide you in such tough decisions, providing our own perspective.

Software

So far I’ve focused on methodology, but fundamental to our approach is our product, Stelo, which delivers essential functionality for the delivery of great Fiori solutions.

Stelo provides the framework for decoupling the app process from the SAP back-end. That enables us to have the freedom for business process re-design, and design for the user.

Stelo provides standardisation so that multiple apps can share resources, making it easier to build and manage your own library of custom apps.

And Stelo includes many out-of-the-box features so that custom Fiori apps are cheaper to deliver, or just better.

So with our approach, the consulting methodology delivers the simplification, while the software handles all the complexity. With both, we deliver simple Fiori apps for complex business processes.

Check out our recent webinar to see this in action.