I’m part of SAP S/4HANA Regional Implementation Group, my area of focus is procurement. The SAP S/4HANA RIG have been supporting several hundred customers on their journey to SAP S/4HANA. This allows us to get a good impression of the challenges customers face and which topics are important to them.
The adoption of innovations is becoming more important for customers when moving from SAP ERP to SAP S/4HANA. SAP Fiori is a fundamental requirement for enabling end users to consume innovations. For example, SAP Fiori gives end users access to new features like the embedded analytics for operational reporting. One of the first SAP Fiori apps in procurement, introduced with SAP S/4HANA 1511, was the simplified purchase request application, “F1643 Create Purchase Requisitions”. This application was a part of the process of transitioning functionality from SAP SRM to SAP S/4HANA and the functionality has been extended since. For example, the app allows end users to request items by searching using a photo or picture.
My colleague, Jocelyn Dart, used the SAP Fiori procurement application as an example of the new user experience. For example, demonstrating how the insight to action navigation works (link to blog) in SAP S/4HANA.
Customer reached out to us, because they had some challenges understanding the new features and functions and defining the best approach rolling out SAP Fiori in the procurement area. The intention of this blog to share examples of the challenges customers faced. This will help you to prepare for your project.
In the first section of this blog, I’ll share with you some of the key principles, which influence the design of the features and functions. I’ll then share some of the challenge’s customers experienced. The last section will provide some general recommendations.
Note:
- The blog is based on the SAP S/4HANA release 1909.
- Each release will bring new innovations and updates, which you should consider for your implementation. This means these examples may not be valid for your project.
- I’m using the term “innovation” broadly to mean new features and/or functions which didn’t exist in SAP ERP.
Important: It is not the purpose of this blog to provide a full and conclusive list of innovations, or of the differences between SAP ERP and SAP S/4HANA, or the different SAP S/4HANA releases. The objective of this blog is to make you aware that there are differences and it is important to understand them to avoid issues in your project.
The driving factors of innovation
The purpose of this first section is to share aspects which are influencing the design of SAP S/4HANA Sourcing & Procurement. These factors are general guidelines for all areas. It will help you to better understand the current design and what impact this has to SAP S/4HANA .
You’ll learn about two important factors in the next two chapters, the speed of innovation and the process design which are driven by the SAP S/4HANA Cloud.
Speed of innovation driven by SAP S/4HANA Cloud
The way solutions are being consumed by customers has changed. Customers want the option to consume solutions which best suit their specific needs. Our new Intelligent Enterprise solution, SAP S/4HANA, was designed allowing customers to consume the solution the way they want. This means you can consume the solution in the traditional On Premise way or as a true Software as a Service solution in the Cloud.
The introduction of SAP S/4HANA as a Cloud solution is a major driver. It has a major influence on the innovation cycle and design. This section will focus on the innovation cycle.
SAP S/4HANA Cloud, essentials edition is always available on the latest version and platform for our customers. For example, SAP releases a new release of SAP S/4HANA Cloud, essential edition every quarter. The last releases were 1911 (November 2019), 2002 (February 2020), 2005 (May 2020) and the next one planned for 2008 (August 2020). This allows cloud customers to expand their processes and adopt the latest innovations in short cycles.
The speed of innovation may not suit all customers. The deployment option allows you to choose how quickly you want to adopt changes. The major update for SAP S/4HANA On Premise is shipped on a yearly basis. You can choose if you want to upgrade yearly or within the standard maintenance window.
New features and functions are developed following the Cloud release cycle. Meaning that SAP makes new features and functions available on a quarterly basis for SAP S/4HANA Cloud and this is based on the latest platform. The general approach is to include the new features and functions in the next planned release.
For example, new innovations shipped with the last 4 SAP S/4HANA Cloud releases, 1911, 2002, 2005 and the planned 2008 release, are planned to be made available with the next planned On Premise release SAP S/4HANA 2020.
Important: It is not guaranteed that all features of a Cloud release will be available in an release. You need to check the official roadmaps and the What’s new documentation for the specific release on SAP Help Portal – SAP S/4HANA – What’s New.
Some new innovations are only available for SAP S/4HANA due to the larger solution footprint. New innovations would then be included in the yearly release cycle.
This means that you will see a two-speed innovation cycle for SAP S/4HANA – Cloud and On Premise – and you need to check carefully which features and functions are available for your release.
Process design driven by SAP S/4HANA Cloud
SAP communicated that it will follow the “Cloud First” approach. You learned about the innovation cycle for the different SAP S/4HANA releases showing the influence in the previous chapter. Another important aspect is the influence this has on the actual business processes design and innovations.
The expectation of a cloud solution is that the implementation time is shorter, compared to an On Premise implementation, and it is easier for end users to work with the solution.
The SAP S/4HANA Cloud, essentials edition is a very good example on the influence this customer expectation has on the design. Some of the changes are:
- The user interface is based on SAP Fiori and end users are accessing the solution using an internet browser. The SAP GUI is not available to end users and consultants adjusting the settings. A lot of configuration changes are now done using dedicated SAP Fiori applications.
- The system is shipped with a preconfigured setup of standard end to end business processes. You can find the information about the available end to end processes in the Best Practices Explorer.
- The configuration options have been redefined to make it easier for customers to setup and enable the business to own some of the setup.
- The solution is provided with standard help information built in via the Web Assistant. For example, with videos showing how an application works, how to navigate the system and with help explaining the standard features.
You may want to check out the blog from my colleague Hannes Defloo explaining the setup of the user assistant in SAP S/4HANA .
The changes above have an impact on the setup of the system. They have an impact on the actual end to end business processes as well.
The business process in SAP S/4HANA Cloud, essentials edition is defined to enable simple processes and allowing a quick role out. The user experience is mainly driven by new SAP Fiori apps. These applications are designed to support the specific needs of an end user with the necessary functionality. SAP Fiori brings a more precise fit of task to role than GUI. So looking at this from a traditional SAP GUI transaction an SAP Fiori screen may only provide a subset of known functionalities. This is intentional – the aim is to only provide what this user needs in the context of their business role. So in context of the end to end business process this simplified User Interface still provides all the features required. This design may need to be considered when looking at this process when implementing SAP S/4HANA On Premise. You will be given an example in the next section of this blog. At this stage it is important to understand that SAP Fiori apps are designed for specific use cases and a more precise fit to the specific tasks of each business role.
You can find further information in section “5 – SAP Fiori apps should support every feature from the equivalent SAP GUI transactions” in Jocelyn’s blog SAP Fiori for SAP S/4HANA – Top 10 Myths & Misconceptions to Avoid.
The Cloud solution is based on the latest technology innovations and data model improvements. The business processes are built to take advantage of the latest. For example, it means that end to end processes need to be developed and support these data elements from start to finish. This means a process starting in a project and then linked to processes in procurement and sales need to be aligned. Even process with other integrated solutions need to follow this principle. The end to end processes are described in the Best Practices Content.
This is of course something you expect to be supported by a solution. Your key take away should be that processes are defined on the latest data model for a specific end to end business process.
The last aspect you need to keep in mind is that you need to use SAP Fiori apps to configure the latest features and functions in SAP S/4HANA. This was mentioned already in bullet point 1 of this section. It should be easier for you to setup or adjust the system based on your business needs. An example in the procurement space is the introduction of the flexible workflow. You can access the setup via a dedicated SAP Fiori app such as F3794 Manage Workflows for Centrally Managed Purchase Requisitions, assuming you are authorized. There are currently 20 of these Manage Workflow apps, with each app covering a specific workflow. The application gives you a lot of option to define the rules for the approval, e.g. when someone needs to approve and who. There are some options to add additional custom code. Compared to the old approach the need for development should be limited.
In this chapter you learned that SAP Fiori apps are designed to support specific business needs and that the developments for the SAP S/4HANA Cloud are based on the latest data models and technologies. You also learned that SAP Fiori access is required to configure new features like the flexible workflow.
What to consider when adopting innovations
You will see three examples. Each example will take a look at an aspect you should evaluate for your SAP S/4HANA project when planning to adopt an innovation.
Evaluate the features supported by the SAP Fiori app
Your project may have decided to use SAP Fiori whenever possible. This is an approach which more and more customers are following. It is great to see that the new user experience is seen as an added value moving to SAP S/4HANA.
At the same time, it is very important to evaluate, if the specific SAP Fiori app supports your business needs. I mentioned in the first section of this blog that “… SAP Fiori apps are designed for specific use cases”. The use case in procurement is based on the defined end to end business process for SAP S/4HANA Cloud. The application needs to support the specific needs and address the needs of the envisioned end user.
When you are looking at this from the point of view of a consultant planning to setup the same process for SAP S/4HANA , this specific use case may or may not make sense. One reason is that the way this process was setup at many customers was different in SAP Business Suite, and you may not yet be ready to shift to the new business process.
Now take a look at the example of the SAP Fiori app F0842A Manage Purchase Orders. This screen shot has been taken from an SAP S/4HANA release 1909. The fields included in the “Basic Data” area are Supplier, Currency and Language Key. One field many customers are expecting to see is a drop-down list with a selection of Document Types for the Purchase Order.
Screen Shot of SAP Fiori application “F0842A Manage Purchase Orders”, from an SAP S/4HANA release 1909. The screen shot has been taken from an SAP demo system.
This option is not available on the screen and many people assume this is standard with the SAP GUI and would be standard with SAP Fiori.
You still have the option to use different document types throughout your procurement process. You can still configure them to your specific needs in SAP S/4HANA . In case you are moving from SAP ERP to SAP S/4HANA, for example using a system conversion, your processes would still work. The consequence is that you will need to use the traditional user experience, e.g. SAP GUI, to meet your specific business requirements.
Coming back to the end to end business processes in SAP S/4HANA Cloud. The processes for the cloud release was simplified when it was first made available. This means that the system was provided with a standard setup. In our example, this setup came predefined with one single document type for purchase orders, type NB. This setup could not be changed by you. This kept the setup simple and still the end to end process worked. The configuration restriction allowed to simplify the screen and remove the document type field, because there was only one and end users didn’t need to make any changes.
This SAP Fiori app was made available with SAP S/4HANA . With SAP Note 2541224 – Document type in Fiori app “Manage Purchase Orders” this option is explained.
The SAP Fiori app can be used. However it might influence the user interface you need to roll out to your end users for your needs.
The business processes of the SAP S/4HANA Cloud, essential edition is changing. With the first release this year, SAP S/4HANA Cloud, essential edition 1911 the drop-down list allowing you to choose a Purchase Order document type was introduced. This is explained in SAP Note 2873100 – New Purchase Order Document type.
Screen Shot of SAP Fiori application ““F0842A Manage Purchase Orders”, from an SAP S/4HANA Cloud, essentials edition release 2005. The screen shot has been taken from an SAP demo system.
Enabling this field on the end user screen means, that you are now able to create different document types based on the standard type NB, with the same field selection key. For example, you can use the type NB as a template to create the custom type ZNB. This is a standard practice in SAP ERP projects. It is planned that this functionality will be made available to SAP S/4HANA customers with release SAP S/4HANA 2020.
It is important to note that SAP Fiori is designed to support specific features and functions. SAP GUI still supports use cases which SAP Fiori doesn’t and will not support. Equally SAP Fiori supports use cases that SAP GUI doesn’t and will not support, such as flexible workflow.
In the case of F0842A Manage Purchase Orders it means you can only create copies of document type NB. In case you are further adjusting the configuration of the document type you will need to use SAP GUI to manage a purchase order process.
For your user experience design, you need to keep in mind that SAP has implemented a business logic making sure that when business users select a specific purchase order they will automatically be guided to the SAP Fiori app or SAP GUI transaction which supports the features of the specific purchase document.
To summarize this first aspect, understand your choice of business process influence the design of your user experience. If you are not ready to adopt the new or changed business processes during your initial implementation, look to adopt them when upgrading your system in the future.
Check the use case of the application
In order to start consuming innovations, you will need to access them via SAP Fiori apps. I mentioned before that SAP Fiori apps are being developed for specific use cases. SAP moved away from the old SAP GUI concept to develop one application that meets all requirements. The SAP GUI one-size-fits-all approach resulted in applications that are often very complex and don’t really fit anyone. The result is that you may find several applications for a certain process step. Again, keep in mind that each application is developed for a specific business user’s role and the available functionality may vary.
In some instances, only one application is available and designed for a specific use case. In this example we’ll look at the SAP Fiori app “F3149 Manage Catalog Items”. We received a few questions about whether this application provides all the capabilities for managing the content of a procurement catalog.
The first step of understanding the use case of a new SAP Fiori app is to check the information we publish in the SAP Fiori Library. Look for the specific application, in our case “F3149 Manage Catalog Items”. This will give you a first impression of the functionality of the application, e.g.:
“… Key Features
With this app, you can do the following:
- View catalog items based on material group, price, supplier, and catalog
- Filter catalog items based on editing status, using filter criteria such as locked by other users, unsaved changes by other users, and so on
- Select any item and click + to create a new catalog item
- Click any row to view contextual information related to a catalog item
- Navigate to the object page to view contextual information related to the supplier …”
There is often a link to documentation of the application giving you more details about the intended use of the application, e.g. “Read more in App Documentation”.
You’ll find screen shots of the application giving you some impression of look and feel.
Screen Shot of SAP Fiori application “F3149 Manage Catalog Items”, from an SAP S/4HANA Cloud, essentials edition release 2005. The screen shot has been taken from an SAP sandbox system.
Screen Shot of SAP Fiori application “F3149 Manage Catalog Items”, from an SAP S/4HANA Cloud, essentials edition release 2005. The screen shot has been taken from an SAP sandbox system.
Screen Shot of SAP Fiori application “F3149 Manage Catalog Items”, from an SAP S/4HANA Cloud, essentials edition release 2005. The screen shot has been taken from an SAP sandbox system.
In some cases, it may also help to better understand the intended use of an application looking at the related end to end business process. In this case the SAP Fiori application was introduced to support the process described in the Best Practices Scope item “Proposal of New Catalog Item (2XW)”. On the webpage you will find the business benefits, e.g.:
“… Business benefits:
- Propose catalog item during the purchase requisition process
- Ease the purchaser transactions
- Receive better suggestions for free text items into catalog items
- Improve and automate purchaser notifications …”
Once you have the information you will need check if your use case can be fulfilled by the respective SAP Fiori app.
The initial question was: does this application provides the all the capabilities for managing the content of a procurement catalog? The initial use case for this application was giving purchasers the option to create catalog items to reduce the need to raise free test requests and further automating the procurement process. There are no mass upload tools available or support mass changes to a larger number of items. The conclusion is that the application doesn’t provide the functionality you may expect from a Catalog Content Management solution. You need to keep in mind that the management of the content should ideally be done by the provider of the content and be shared in a catalog or in an XML file you can import your catalog.
Evaluate fit of the out of the box content
One of the benefits you will get moving from SAP ERP to SAP S/4HANA are the embedded analytics. You will be able to see analytical information on the same screen as transactional information. End users can easily adopt these reports to their needs, for example by using filter settings to define what information is relevant for them. This assumes that end users have been given the required authorization.
SAP ships several standard reports, which you can leverage. You can see some example reports in the below screen shot.
Screen Shot of reports on the SAP Fiori Launchpad, from an SAP S/4HANA Cloud, essentials edition release 2005. The screen shot has been taken from an SAP demo system. Check the reports available for your specific release by checking the information on SAP Help Portal – SAP S/4HANA product page.
The reports are based on the latest data model and need to support the business processes supported in our SAP S/4HANA Cloud. After the reports have been made available for Cloud customers they are, in general, made available in the following release. I mentioned the topic of the data model earlier “The Cloud solution is based on the latest technology and data model.”
It is important that you understand that the supported capabilities supported by SAP S/4HANA are broader compared to the Cloud. On the screen shot you can see that two reports are being highlighted. Both reports are related to “service procurement”. I’m using this example, because the SAP S/4HANA Cloud, essentials edition only supports the new data model. The solution is based on the latest technology and using the latest data model should make common sense. SAP S/4HANA supports the new data model for services, customers often use the term “lean services”, and the data model for service master, known from SAP ERP.
Note:
I’m not going to explain the exact differences or when which model should be used in this blog.
It is important that you understand the importance to evaluate if the standard report includes the data model you are using for your end to end business processes or not. In our example the standard reports would provide end users with visibility of the spend using the new service data model. This means you need to adjust, define reports which are looking up the data for the old data model, of service master, when your processes are based on this data.
Several customers only noticed this while they did the User acceptance Testing, which is very late in a project. Avoid such late findings and make sure you carefully evaluate your business processes during the Explore phase of your project.
Summary and general recommendation
You have learned that it is important to understand the features and functions supported by the respective SAP Fiori apps. The capabilities of the applications are changing. New applications are being introduced and old ones are being enhanced. Some of these enhancements are made available by introducing a new SAP Fiori version, for example you will find the option to download data to Microsoft Excel added on a lot of applications by moving from SAP Fiori 2.0 (SAP S/4HANA 1610 to 1809) to SAP Fiori 3 (SAP S/4HANA 1909 or higher).
This means you should evaluate whether an application meets your business requirements for the specific business users. The outcome of this evaluation might be that you may need to use some screens with a more traditional SAP look and feel, at least in the short term. Keep this in mind when you set expectation especially when defining an SAP Fiori first approach.
You also learned that it is important to understand the purpose of an SAP Fiori app. They have been designed to support a specific business need. This may perfectly fit your situation, or it may still be able to be used as a stepping stone on the way to introducing a a more feature-rich solution for your needs.
In the last section you learned that it is important to check if the out of the box functionality does support your end to end business process or if changes are required. This should be part of the Explore phase. We often make assumptions on our experience and as a consultant it is important to understand that SAP S/4HANA is different compared to SAP ERP.
Make sure you define a roadmap when you move to SAP S/4HANA. The initial implementation is a first step. Innovations are being introduced with each release and in case you want to adopt one of these innovations you need to be able to upgrade to this release.
Check with your SI partner or reach out to SAP Services in case you have any questions or need help.
You’ll find much more on our SAP Fiori for SAP S/4HANA wiki
Brought to you by the SAP S/4HANA RIG
Related Blogs:
SAP S/4HANA Procurement – Considerations for customers with SAP SRM
