The SAP S/4HANA RIG supported 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.
Most procurement processes in SAP S/4HANA work very similar to SAP ERP, when comparing the processes enabled by SAP GUI (Graphical User Interface). This makes transitioning from SAP ERP to SAP S/4HANA easier, when using the approach of a system conversion. You can decide the level of change you want to include. A move has to include the must changes. This allows you to manage the speed of change by introducing changes step by step and focusing on those that are adding business value by improving current practices. A side effect is that the initial investment is protected, and the project can focus on the technical transition.
The approach of focusing on the technical transition has one major downside. This approach limits the value add of the project. We see that more and more businesses are questioning this approach and want to see value for the money spent. It is therefore great to see that the conversation has moved on from a pure technical discussion. The focus has shifted to include and show change by adopting innovations and making sure the business can take advantage of new features and functions in the future. A central part of the adoption of innovation is the introduction of SAP Fiori.
We, SAP, mentioned that we are on a journey and that we have further homework to do when SAP S/4HANA 1511 was introduced. With the focus on the UI (User Interface) side the area of service procurement seems to be getting more attention from customers. We receive more questions and requests for guidance one what to do and why certain things work in a certain way.
The intention of this blog is to introduce the topic of service procurement in SAP S/4HANA. We will start by taking a look at the ways service are represented in SAP ERP. The focus will be on the purchase order and service confirmation. The second part will look at the change that was introduced with SAP S/4HANA. The last section will provide a summary and some general recommendations.
Note:
- This blog will be a high-level introduction and only look at some selected examples.
- Process will be simplified and some features, although important, not covered. For example, it will not cover the functionality of limits in service orders.
- The blog is based on SAP S/4HANA 2021.
- Each release will bring new innovations and updates, which you should consider for your implementation. This means information in this blog needs to be re-evaluated for your project.
- Please make sure you consult your SI partner or reach out to SAP Services to define your specific approach and/or long-term roadmap.
Important: It is not the purpose of this blog to provide a full and conclusive approach which every customer should follow, 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.
Introduction to Service procurement
The procurement of materials is generally the focus when defining a procurement process. Materials are comparably easy to define and the cost of shipping of a standard item can be included in the overall cost without too much effort. We are looking here at a simple case. Let’s take the example of a smartphone. It is not too difficult to specify smartphone. You will be able to define the colour, size of the display, the memory, etc. The price for a standard smartphone can be negotiated and the shipping cost for this item can be defined. Once this has been defined end users can order this smartphone and the process and the cost is known at the time of order.
When ordering services this process becomes more complex. Let’s take the example of ordering consulting. It could be any other service like a car inspection. At a first glance the process will look pretty much the same. It is possible to define the cost for an hour and may define the skills of the consultant. The next steps will start to differ from ordering a material like a smartphone. You will need to estimate how many hours of consulting you will need. This adds some uncertainty. We are now adding an assumption that the consultant will need to travel to your place of work to provide the service. This means you will need to estimate the travel cost. While it is possible to estimate the cost based on the past or looking up current prices on webpages, the final cost is only known once the service has been provided. I’m aware that there are strategies to reduce additional cost and reduce the unknown.
The key takeaway is that it is easier to streamline the process of materials compared to services, mainly due to unknown cost.
Service procurement in “SAP ERP”
I’m going to use the term “SAP ERP” for the ways service procurement was implemented in the past decades in an SAP R/3 or SAP Business Suite system. Let’s look at 3 examples how a service can be represented in a system and how this has changed over the years. Again, this is a simplified way of looking at it.
Material type DIEN
A simple way to represent a service, as a master data element in SAP ERP was to use a material. This was done by introducing the material type “DIEN”. The term “DIEN” is the abbreviation of the German word Dienstleistung, which in English means service. This type allowed to represent a service in the system in a simple way.
The following screen shot shows a material line item which is of type “DIEN”. The description of the material master was defined as “Service Type DIEN” for the purpose of this process. It has no item type and is assigned to a cost centre. In this example the purchase order was created with the request of 100 hours. The price of one hour is assumed to be $10 USD.
NOTE:
This example assumes a tax of zero. This is not the standard and tax would need to be included. It is only done to simplify this process and this example.
The confirmation of this purchase order would then be done in the transaction MIGO, which is used and was designed to confirm the receipt of materials. In this example the end user confirms that 22 hours of this service have been provided.
Looking at the purchase order, the confirmation that the service was provided is reflected in the purchase order history for the line item. This means that there is an open quantity of 78 hours.
Using the quantity field to represent price
The above approach allowed to extend the existing material master and use it to represent a service. The approach created some challenges. One of these challenges was that companies wanted to have better control of the money the service represented and to better manage potential unknown costs when ordering the service.
This example shows a free text item. Although it is free text, the item will be handled in the same way as the service item of type ‘DIEN’ in our first example. The key difference is that the purchase order quantity field is being used to represent the value of the order. The price of one item is $1 USD. This means the order has a value of $1000 USD.
NOTE:
This example assumes a tax of zero. This is not the standard and tax would need to be included. It is only done to simplify this process and this example.
The process follows the same approach as in our first example. The key difference is that with the confirmation of a quantity of 180 EA means that the services cost was $180 USD. This means it is possible to confirm the Dollar value of the service provided rather than the hours/quantity, which in the two examples meant a difference of $10 USD. This value may be higher depending on the actual cost for an hour of service.
The confirmation for the line item on the purchase order history tab shows the confirmed quantity, value.
SAP ERP Service master data
The above approaches provided a possible way to represent services in procurement process. For simple services procurement processes the model was sufficient and worked. In several cases this approach didn’t cater for the specific business needs. SAP introduced a new data model to better support the needs for more complex service procurement scenarios as well as for the ones we looked at in our first two examples.
The service master data is independent from the material master concept. It allowed to break down services in small parts and structure them, if needed. It is possible to define service models with multiple hierarchies if this was required. These service models could be defined in the system as master data or could be transferred from a catalogue.
In this example we have one line item which includes one service master item, which is named “Consulting Service”. We will only use one level and one item for this example.
The confirmation of this service is not done in the transaction we used in the previous examples. You will need to confirm that the services had been carried out in a separate transaction ML81N. The service is confirmed by creating a service entry sheet. In this example we are only confirming the hours provided. This concept provided more flexibility and allowed adding additional items, cost.
Looking at the purchase order history for this item, you will see that we didn’t only create the service entry sheet. We also created a confirmation in the system, which was done automatically by the system.
These 3 examples have been simplified to provide an impression of the ways services are represented in a system and how service procurement changed over time. In most cases limits will be used to better manage the cost of services. This was not included in these demo’s as it would add additional complexity as mentioned in the introduction of the blog.
Service procurement in SAP S/4HANA
You saw that there are different ways of representing a service in a purchase order. These models addressed specific business needs. With the acquisition of other solutions in the past years further complexities were added.
Some of the complexities we saw in implementations have been:
- Customers wanted one transaction to confirm materials and services and not separate screens.
- The addition of new solutions caused challenges in the integration. For example, the data model of systems wasn’t consistent. Services data model in system A was different to the one in system B. This means data had to be mapped or in some cases the integration for some process steps wasn’t possible.
- Different approaches were being used for ordering services.
- The master data had to be maintained using different transactions.
The introduction of SAP S/4HANA gave the opportunity to rethink the way services procurement could be done in the system and address the challenges customers have raised over the past years.
Key changes in SAP S/4HANA
The key change was the change of the master data concept in SAP S/4HANA. The change affected the material master, service master and the master for articles. The master data elements are now being represented as product types. The new service master is called “Product Service”. The name of this blog already indicated that this will be the strategic direction and focus in the area of service procurement.
You may have read or heard the term “Lean Service” or Simple Service” for the new service data model. This term may have been correctly painted the picture for the supported processes. This meant that some started talking about “Complex Services” to express missing features. This is misleading, because it creates the impression that a second data model would be required to address specific needs. This is not the case. The data model “Product Service” has been created to support the business needs for services regardless of being “lean”, “simple” or being “complex”.
For now, it is important to understand that a new service data model was introduced with SAP S/4HANA.
The objective of this new data model was to address the challenges customers raised, as you read in the previous chapter. Let us take a look what the new data model changes include:
- The new material and service master are based on the same data structure. They allow the representation of data in the way business require them. This simple change will allow end users to confirm services and materials on one single app. Making it easier to confirm for example the service for a truck inspection, because as an end user you can now see all the services being provided and the materials being used to carry them out.
- This new data model is planned to be introduced in SAP solutions. One single model regardless of origin of the solution. For example, the data model is being used by SAP Fieldglass and the Best Practices integration between SAP S/4HANA and SAP Fieldglass is based on this data model. This helps you with the integration of our solutions and reduce the effort of the implementation and ongoing support.
NOTE:
The introduction and alignment across SAP solutions is not done overnight and not yet introduced in all SAP solutions or every released version. It is for example not planned to introduce this data model in SAP ERP. It is important to check the solution and version being used for the supported features and functions.
- With the new data model customers should be able to use one approach to best represent a service in the system and across the full end to end business process.
- There is now only one way of maintaining the master data of services, materials and articles. This should make it easier for the end users to maintain the information and manage it.
We looked at 4 points that have been addressed with the introduction of the new data model. This should give you an impression on why the new data model was introduced.
Challenges moving to the new service model
You learned that SAP introduced a new data model for services and that this should address some of the challenges customers may have experienced when implementing the process in their systems.
You might think that all sounds nice, and it is good to know, but “What does this mean for me?” or “What does this means for my customer?”. This blog will not deep dive into this. The main purpose of this blog is giving an introduction and answering those question will be the subject of a future blog.
The following two points discuss the challenges to be considered for service procurement and are important to understand. The reason is that these are essential, and customers often raise this with us:
Point 1)
The old service data model from SAP ERP is still available and supported in SAP S/4HANA. This means that customers using a system conversion approach can continue to run their processes without major disruption. This gives existing customers the option to adapt the new service model when they think it supports their business needs and it can be done in a separate project. Reducing the complexity and the effort for the initial move to SAP S/4HANA.
In this context it is important to mention that these processes are not part of the compatibility scope and will be supported even after the deadline of the 31st of December 2025 for the compatibility scope. It is as well important to understand that it is not planned to provide new features or functions. This includes the support for the old service data model for transactions SAP Fiori apps.
Customers looking at a greenfield implementation should consider adopting the new service model, when possible.
Point 2)
New features and functions in SAP S/4HANA are developed with a cloud first approach. Something you may have read or heard before. This approach has an impact on customers looking at adopting the SAP Fiori apps and still using the old service data model.
The transactional SAP Fiori apps are initially developed for our SAP S/4HANA Cloud, public edition. This solution is being shipped and implemented with the latest supported data models and features and functions. In the context of the service master, it means that only the new data model is available in this system. The old data model, meaning the service master from SAP ERP, is not available. The SAP Fiori apps have been developed with the focus on the new data model. The old data model is not supported. This means when you see “service” on an SAP Fiori screen, only the new data model can be used. There is no issue with this approach for public edition customers. It is a challenge for customers wanting to use the old services data model with SAP Fiori apps.
Here are two examples showing an SAP Fiori app for creating purchase requisitions and one for managing, creating purchase orders:
This is causing some confusion. One reason is that the SAP GUI supports the old and the new data model. The other is that in several cases it was planned to adopt SAP Fiori as much as possible and address the complaints by end users by introducing a simplified User Experience. This often is an expectation, and this may now not be realised.
There are further challenges adopting new feature. For example, the new standard operational reports are based on the new data model, and they may therefore not include all the data expected in a report. This means some adjustment is required to include spend data based on the old service procurement data model.
