SAP Digital Transformation – Do you get it?

Organisations that embrace digital transformation can accomplish extraordinary results. In this article I explore what constitutes digital transformation and discuss some thoughts about what it means for SAP customers, posing the question ‘do you get it?’.

Digital Transformation means different things to different people. To some, it’s just the new term for BPR: Basically the same old stuff we’ve been doing for 20 years, but with a new bag of tricks. To others it’s just a buzz word, but an important one because it’s something that organisations are willing to dedicate budget to. Or it’s what comes from replacing technologies with shiny new products, like SuccessFactors, Hybris or Leonardo.

For the purpose of this article let me define the term:
Digital Transformation is the process of embracing new technologies to re-invent the way we get work done.

This means there are two aspects to consider – technology and new ways of working.

Technology

New technology is, of course, what makes it possible.
The big drivers are big data, cloud and mobilisation. Together with Internet of Things this enables us to collect much more data in many more ways. It enables us to be better informed than ever before, so we can react more quickly and make better decisions. It enables us to build new solutions, to disrupt existing markets, to define new markets.

In simple terms, we can do stuff now that we couldn’t do before.

New ways of working

Defining new ways of working is where the rubber hits the road. And here’s why – because people don’t get it.
And worse than that, people don’t get that they don’t get it. They think that they get it, but really, they don’t get it.

Doing things differently, for us SAP users, means not using the SAP transactions. It means not using the traditional SAP processes, but instead having the freedom to design something that can take our organisations somewhere else. Twenty years ago we spent our lives getting people on to using standard SAP processes, and now the new challenge is to get them off. Don’t believe me? Then you don’t get it.

Digital transformation is not about deploying a couple of Fiori library apps, or replacing an SAP transaction with a simplified Fiori equivalent. If it is transformational then by definition it must be about doing something different, or doing something differently. And, semantics aside, that means not doing the same thing. The prize of digital transformation comes not from people using different software, but from people doing different work.

And that’s such a mind-set change that, for most SAP professionals, it’s really challenging. So on that basis I expect you to be really challenged. And if you’re not really challenged, then probably you just don’t get it.

Let me illustrate this with something completely standard and ordinary, like purchase order approval.

Let’s imagine a user persona for someone who requests stuff, say Fred. Fred doesn’t know a lot about the SAP system, but his job involves consuming stuff – consumables – and he needs to make a request when he’s close to needing more. He needs something that’s really easy. He doesn’t want to learn about SAP Purchase Organisations, or Plants. He doesn’t want to have to search 100,000 product records to find the stuff he wants. It’s a million miles away from creating a purchase requisition in SAP.

Create a Purchase Requisition in SAP

Now let’s imagine a user persona for someone who manages purchasing requests, say Jack. He understands about source lists, vendors, info records and contracts. He can set all this up in order to create a purchase order on the system. And in fact he needs to go through all this in order to get an order into the system before it is approved. In fact it’s a full-time job, and the same amount of effort is required for a purchase order that gets approved as for a purchase order that gets rejected.

Other employees are involved in yes/no approval processes for each individual purchase order. They are typically managers with budget ownership. They have little basis on whether to approve or reject a request. They don’t have the ability to see everything holistically – the current requests, the expected requests, the historical requests so that they can see the impact of approving an individual request. They don’t have the ability to see at a glance what the stuff cost last time, or graphical pricing history. So in reality, they entirely rely on Jack, and every request is approved.

But this is a standard SAP process. “Best practice!” What’s the alternative?

Well, we start with some design-thinking. And we end up throwing away standard transactions for creating purchase requisitions, throwing away Fiori Library apps for purchase order approvals, throwing away the current business process, and instead designing a new way of working.

Perhaps we have a custom Fiori app for Fred. This app shows Jack what he’s previously requested and received. It shows him only the products that he’s interested in. It makes no mention of purchasing groups, company codes or plants. It’s designed for Jack. It’s really simple and anyone can use it.

Perhaps we have a custom Fiori app for Jack too. Perhaps this shows Jack all the outstanding requests, and the approval status. Perhaps it shows Jack best prices for each item on the request based on the existing source lists and info records. Perhaps it highlights items where master data is missing. Let’s imagine that Jack can display each request, including additional SAP-derived data, so that he can ensure it has everything in place to generate a purchase order. And let’s imagine that Jack can push out costed requests for approval, or that business rules dictate that many requests by-pass Jack completely and go straight out for approval.

And perhaps we have a custom Fiori app for the budget managers. One which provides analytics side-by-side with the list of requests, such that budget managers can make an informed decision. Once a request has been approved, then a purchase order can be automatically generated and released.

So in this new world, we’ve considered each user touch-point of the entire process, and added value at every step. All the data is handled securely within the SAP system at every stage. The resulting business document – the released purchase order – is exactly the same as before. But the business process is new and crucially we are not front-ending a SAP transaction but delivering a different way of working, in terms of process and user experience. And in fact, that’s all we’ve been doing at Arch for 15 years.

All About Fiori

Now, over the past 15 years, the toolset we have available has changed completely.

In the old world we’d expect heavy system users to use SAPGUI, and we’d look for easier UIs like interactive forms for those processes that impact occasional users, to provide them with something simple and intuitive.

Now SAP gives us launchpad – a single, easier way to get to everything we need, be it in the cloud or on premise, using a range of technologies. We also have overview screens – dashboards, designed around specific roles, providing real-time analytics, easy traffic light graphics to highlight problems or potential issues, to change how we prioritise and approach our tasks, and help us make better informed decisions. And we have Fiori apps, to provide the simpler, user-friendly experience.

So our updated toolset is Fiori LaunchPad for everyone. Fiori for everything. Fiori Overview Pages for heavy system users. SAP Personas where we still want to use SAPGUI but improve it. And application-specific solutions like SuccessFactors where we need them.

So crucially this means that literally you can throw away everything. Every single process and system interaction is up for grabs. Let me say that again: Every single process and system interaction is up for grabs. Do you get it?

The Fiori paradigm changes everything. It’s absolutely central for the creation of new ways of working; it is the platform on which you can start to deliver digital transformation. And where, of course the starting place may lie in the LaunchPad, the value lies in Overview Pages and custom apps.

Overview Pages provide a huge opportunity to define new jobs, where the ‘way in’ to a business process is through an analytical card. So when we are designing these new ways of working, our starting point is the role-based dashboard.
Custom apps enable us to define tailored, optimised user experiences for new business processes. So our natural second place to focus is each user touch-point in the process.

A new way of blueprinting

In the past we defined the business process and then we added in a great user interface, and then we worried about reporting in phase 2. Or, on occasion, never.

But in the new world, in order to embrace digital transformation, we need to start with the reporting first: We have to decide what information the user needs, and what will spur them into action. So first we must design the analytics, and then the user interface and then the custom process. Consider the example above: Most organisations would focus on the data entry app for Fred, and trigger the normal SAP process from it. Who would start the blueprinting conversation with the analytics needed by each persona to transform how they can do their job? That’s what I’m advocating.

So unless you change how you go about blueprinting, you’re doing it wrong: In order to embrace digital transformation, we have to change how we do blueprinting. And that’s really challenging, so expect to be challenged.

Do you get it?

Back in 1996 we started Arch to be a small team of experts: specialists in a world where larger companies offered a big team with ‘average’ skills. Now it seems, more than ever, organisations need a small team of experts because the others just don’t get it.

There is something to get here. Vendors who supply a library of off-the-shelf apps don’t get it. Customers who buy the off-the-shelf apps don’t get it. The squadrons of cheap consultants and developers provided by Systems Integrators don’t get it.

Right now is a time of enormous opportunity for those who do get it. And if you get it, give Arch a call.