Implement SAP Fiori with User Analytics

[bogdannica]

You have been sold on the benefits of SAP Fiori and you are ready to take the plunge into fiorizing parts of your ERP or SRM system. Congratulations. Now what?

Where do you start? Which business workflows should you migrate to Fiori first, and why? Which of your business users would benefit the most from a Fiori experience, and how? Should you use off-the-shelf apps or build your own? Should you deploy them to your power or casual users? Should you target for desktop or mobile usage? And, as you plan to roll out the new apps, do you still need to keep the established UI in place? The best way to start answering these questions is by truly understanding your users.

As you already know, SAP's new UX offering holds the promise of simplifying your business workflows with streamlined screens and interactions, delivering a better experience to your users with a consumer-grade UI, and making the life of IT administrators a bit easier, by reducing the complexity of the underlying infrastructure. However, you might suspect that the roadmap to user experience Nirvana is not straightforward - especially if you have already experimented with other UI solutions, like NW Portal customizations, various flavors of the Business Client or even Screen Personas. Your Fiori project is bound to be a UX experiment - which will delight your users, or not.

One of the first choices you need to make is between implementing Fiori on your own or recruiting outside services. On the outsourcing track, there are plenty of options available from SAP (e.g. SAP Fiori Design rapid-deployment solution and UX Adoption and Design Services) and a plethora of third party shops, who can guide you through the full life-cycle process of designing, building and deploying your Fiori apps. If you choose the "do it yourself" model, you can leverage many of the best practices that have started to emerge from earlier implementations. (By way of example, Ingredients of a successful Fiori implementation does a fine job of describing the nitty-gritty details you need to think about when implementing Fiori.)

While there is a vast array of resources covering the technical aspects of a Fiori implementation, there is less information available about how to properly guide your project from the get-go, to maximize your chances of success as well as your impact. Many of the implementation guides you will come across will invariably state some obvious imperatives: you need to focus on your users, prioritize your business scenarios, and design the new workflows with user experience in mind - in other words, "design thinking".

That makes a lot of sense, but how exactly do you do that? That's where user analytics come in.

Before you go there

To take full advantage of Fiori's innovative UX design framework, user experience metrics need to be front and center in your Fiori project, not an afterthought.

No one embarking on a migration project can confidently say, "I don't need to know how my users are using SAP". User analytics can guide your choices every step of the way - as you plan the migration, during the design/build/test phases, and after you're live in production. The user personas inherent in your Fiori designs will be far more meaningful when derived empirically; they will dictate not only what and who you need to migrate, but also how.

Whether your Fiori project is driven by business imperatives (simplify user workflows, enable mobile access to common SAP functions, reduce training needs, improve adoption, etc.) or by IT objectives (simplify administration of IT assets), you will want to take a baseline of user adoption and experience in your current SAP environment.

• In the business-driven scenario, you will be able to uncover hidden inefficiencies in your processes, so you can design your Fiori applications around them


• In the IT-driven scenario, you want to ensure that, at the very least, you have not made the user experience worse than it was before

"Understanding your users" entails measuring of actual user behavior in your SAP system. Several KPIs are relevant for modeling user behavior, irrespective of your line of business:

1. Usage statistics - such as time spent on transactions and transaction usage frequency
   
   
   
   • These can be computed at the individual user level, as well as at the aggregate level
   
   
   
   


2. For even more insight into user behavior, consider higher resolution metrics, such as:
   
   
   
   • Time spent by users actively interacting with the application screens ("active time")
   
   
   • Time spent by the system in processing user requests ("response time")
   
   
   • Time spent without any user activity (user "think time" or "idle time")
   
   
   
   


3. Process or task complexity - which can be derived from metrics such as the number of process steps or screen interactions


4. Work interruptions - which are primarily caused by user or application errors, seen here as events that impede a workflow execution.
   
   
   
   • Error rates can be computed for transactions, screens, and even field elements (the finer the granularity, the more precisely you can identify the bottlenecks in the process)
   
   
   
   

At a very basic level, you will want to measure the time users spend on individual transactions or application screens, which can be rolled up to build empirical profiles for your users and transactions, respectively.

These profiles will enable you to identify:

• Actual roles performed by users, as opposed to assigned roles


• Core vs. peripheral transactions (as they relate to a user role)


• Power vs. casual users (for a given set of transactions)


• Gaps in adoption as well as process efficiency

Let's take a closer look at how these KPIs can be leveraged for your Fiori implementation.

User Profiles

A typical Fiori project will employ a design methodology centered on personas (actual users and their roles), as opposed to monolithic processes or applications. That's because Fiori applications are task-oriented. You have the opportunity to streamline the experience of your users by deploying apps that are tightly associated with their identity, without all the clutter that plagues the cross-functional applications in your legacy environment.

Assuming that personas will be an integral part of your design process - you will need to define them based on standard user attributes, such as user roles, job functions, level of experience, etc. You can further augment these profiles with user analytics.

By taking into account actual user behavior, you will be able to define personas that closely resemble the reality of your business. This means looking at how users execute transactions in the live environment and letting those insights drive your design decisions.

When defined in terms of usage patterns (metrics such as active and idle time per transaction or usage frequency), user profiles can be conceived as consisting of two parts:

• Core transactions, which are executed frequently or generate a high volume of activity


• Peripheral transactions, which are just the opposite

As you design your Fiori applications for a selected user group, be sure to establish upfront whether you're aiming to optimize the core or peripheral transactions.

• The heavily used transactions are naturally those where you can have the biggest impact in optimizing user experience and improving user productivity. However, these are also the ones that will require significant redesign and possibly extensive customization, to prevent any loss in functionality when migrating from the legacy version


• For the lightly used transactions, you may choose to go as far as putting them on life support (if not decommissioning them altogether), as you roll out more accessible, streamlined Fiori alternatives by using off-the-shelf, low touch apps, which will translate in reduced support costs in the long run

Fig. 1 User profiles based on usage statistics

User profiles augmented by actual usage statistics will not only help you better prioritize the candidate workflows for a Fiori migration, but they will also help you answer broader strategy questions related to your implementation:

• define which specific benefits your Fiori migration will target


• determine the appropriate mix between transactional, analytical, and factsheet apps


• establish whether mobilization of these apps is a hard or soft requirement

Finally, by baselining user adoption in your current SAP system, you will be able to compare it against the user adoption of the new Fiori apps, to ensure a successful rollout.

Transaction Profiles

User profiles and transaction profiles offer distinct but complementary perspectives based on the same metrics. For a given set of transactions representing a business process (e.g. Sales Quotation, Standard Order, etc) or a process step, you can identify key usage patterns across all users, as well as distinguish between how different user groups execute these transactions.

When looking at usage patterns from a transaction perspective, you can minimally identify two clusters of users: power and casual users (or strictly speaking, "heavy" and "light" users).

Your Fiori designs will need to be explicit about which user group is targeted, and how those designs will optimize their experience.

• For power users, consider if and how the current process can be successfully translated into a Fiori application that will improve efficiency without sacrificing versatility


• For casual users, who perform certain tasks infrequently or who only need to exercise a fraction of the functionality available in the current system, consider how to best wean them off the legacy application by giving them a mobile alternative, with a streamlined interface and reduced functionality

Generally, if your goal is to enable basic mobile access to common SAP functions, such as workflow approvals, information lookups, or self-service tasks - actual usage statistics will help you cluster and prioritize these functions so you can maximize the impact of conversion.

By the same token, if your goal is to streamline complex workflows, then you will want to identify "high-impact" clusters of complex transactions and power users, and rank them based on a business relevant criteria. By doing so, you can establish a clear focus for your Fiori re-design efforts, along with the KPIs that you will use to measure success.

Fig. 2 Transaction profiles based on usage statistics

Once you identified your target user and transaction profiles, you can go one step further and consider additional metrics to gauge the true user experience. You cannot hope to eliminate employee UX resentment and build apps that are used, without going beyond the colloquial "the interface sucks". You need to understand exactly where the pain points are and how to address them.

User Experience

If usage statistics are the cornerstone of your analytical user model, user experience metrics (such as workflow complexity or work interruptions) introduce a further degree of refinement in your model, which will help you identify specific process efficiency and user productivity gaps.

Let's consider workflow complexity, a key issue that Fiori-enabled designs are meant to address. It's one thing to know that a business workflow can be optimized based on an ideal path of execution, but it's another thing to ensure that users will always follow the ideal path. If there is one guarantee when prescribing an ideal path, it's just that - it's an "ideal".

If you're trying to re-engineer an existing workflow, you may need to step away from the process diagrams neatly laid out in your training aids and look at actual workflow executions, of actual users, in a production environment. What you will find may surprise you.

Fig. 3 Step-by-step user workflows

By sampling actual user workflows, across both your power and casual users, you can uncover hidden inefficiencies in your process, such as:

• repetitive screen interactions


• redundant or unnecessary steps


• superfluous warning messages that, at best, confuse users


• screens cluttered with unnecessary information, leading to excessive "idle" time


• scenarios that require users to switch between multiple, concurrently running applications or sessions

The goal of this workflow-level analysis is to identify opportunities to streamline specific tasks and reduce the overall time to completion. Workflows with a high degree of complexity can be a prime target for simplification through a Fiori app.

However, if you're considering off-the-shelf applications, you also need to make sure these applications are not too "streamlined", compared to the actual functions your power users need to perform. Unless you can verify that, you should be prepared to invest in heavy customizations or else these users may be better served by a "tried and tested" interface like SAP GUI.

Work interruptions caused by user or application errors can be just as obstructing. For a given process, do you know how many errors your users are likely to encounter in a typical execution? And do you know how this affects their productivity?

Each error instance (be it a benign warning message or a hard application error which forces the user to abandon the process) constitutes a work interruption. Some are more frustrating than others, but they’re always wasteful. Cumulatively, across all users and over time, even negligible interruptions will have a significant impact. By considering the error rate per process and its frequency of execution, you can determine the overall business cost in lost productivity.

Fig. 4 A transaction view of work interruptions

Identifying and ranking the error-ridden processes is only the first step. The next step is identifying and ranking the actual transactions, functional steps, and error conditions for each process, which will help you understand what exactly will be optimized through the new Fiori designs.

Simply reducing the number of steps in a process is not enough, if the typical user cannot execute the process without impediments - whether these are due to insufficient training, application usability issues, system configuration, or some other factor.

Getting visibility into the work interruptions experienced by users in your current system helps you define your Fiori designs. Extending that visibility to the new Fiori apps themselves (as you roll them out to your pilot and production users) will help you verify that the new designs are working.

When you're there

So you're ready to start your project: you are using the right KPIs, you have identified your target scenarios and users, you have a clear vision of the expected benefits, and your design and implementation teams are lined up. Before you know it, you're in production.

Have you achieved your goals? Are the new Fiori apps automatically bringing the productivity gains you expected? Are people using the new apps as you hoped they would? Was it all worth it? You can answer these questions using the same user analytics.

• If you rolled out those shiny new iPad apps to your casual users, in the hope of freeing them from the desktop, check to make sure they are not "casually" not using them, and if so, find out why


• If you were hoping to replace that obscure Z transaction with a much simpler Fiori app, find out if your users are still clinging on to the old t-code, in case you missed supporting a key function they needed


• If you attempted to reduce time to complete certain tasks through a streamlined workflow, compare it to the old workflows, to verify that's indeed the case


• If your goal was to reduce end user training needs and increase adoption by designing a "nothing can go wrong" interface,  check for errors that may go unreported and may frustrate users in the long run

In other words, when it comes to declaring your Fiori implementation a success: trust, but verify.