Situation Handling: How to use Responsibility Management efficiently

[Dr_Joerg_Rett]

Welcome to my blog post on how to use Responsibility Management for Situation Handling more efficiently.

You might have already set up Situation Handling as described in the blog post Situation Handling: How do I configure situation types? (3/5) and the deep dive blog post Situation Handling: Advanced Configuration of Situation Types (5-5) and noticed that there is a strong connection between the configuration of a situation type and the definition of the responsible team.

The latter blog post already gave you some dos and don’ts, like “… make sure that you don’t define contradictory filters …”. We’ll see an example of a contradictory filter in this blog post in the paragraph, “What if we add a condition to a situation type for which no team is responsible?”

But before we look at that, let’s get a common understanding. There are two perspectives: The perspective of Situation Handling and the perspective of Responsibility Management. Let’s start with the Situation Handling perspective.

How do we configure recipients for a situation type?

We define who will be informed about a situation in integrated Responsibility Management.

The Team Category links the teams to the situation type, for example, Procurement (PROC) as shown in the image above. This raises the question,  

“What is a Team Category?” 

One way of looking at a Team Category is that it simply represents a collection of one or more teams. From another point of view, it can be interpreted as a business process for which one or more teams are responsible. So, in the example shown above, the Team Category PROC links the situation type to the collection of teams responsible for procurement. This has an implication on the Responsibility Definition filter, which represents the attributes of those teams. As we can see in the image above, we can choose only attributes that are related to the Procurement business process, here Purchasing group and Plant. The same is true for the Member Function filter, which represents the tasks a team member can perform. We can select only tasks that are related to the Procurement business process, in this case, Operational Purchasing. 

Because both the team category and the situation template are closely tied to a business process, the team category for a template is fixed and cannot be altered. Just as the set of situation templates, the team categories are also provided by SAP.

As the example from procurement shows us, Responsibility Management doesn’t model hierarchical structures in the sense of manager and employee. Instead, it models hierarchies of functions and work-related responsibilities, like processing purchasing documents for a certain plant. Check out an example for procurement on the SAP Help Portal for Responsibility Management.

Now that we understand a team category as related to the business process and that responsibility definitions and member functions are finer, granular filters regarding the tasks, the next question is, 

“How do we set up a team for a certain team category?” 

Let’s follow the example shown above and set up a team for a business process in procurement. To do this, we need to open the Manage Teams and Responsibilities app. Remember that your user needs to have the business process specialist role (SAP_BR_BUSINESS_PROCESS_SPEC) assigned to it, otherwise we'll get a little error message when we attempt to open the app. When this happens, we need to contact an administrator and have them add the role to our user. 

In the filter area, we’ll see some fields we’re already familiar with, such as (Team) Category, Responsibility Definitions, and (Member) Functions. At the top right of the table area, we’ll find the Create button.

When we choose Create, the Teams page opens for editing. We can’t find a (Team) Category field, instead there’s a (Team) Type field. This raises the question,

“What is the difference between team category and team type?”

The answer is simple: The team category is related to a business process and the team type is related to a subprocess. In other words, one team category can have many team types (1:n) but one team type always has one team category (1:1). Once we open the value-help of the Type field, things become clearer.

If we enter PROC as the (team) category and hit Go button we will get two (team) types to choose from: Operational Purchasing and Strategic Purchasing. These are two subprocesses of the Procurement business process. In our example, we’ve selected Operational Purchasing since we want to create a team of people responsible for purchase orders, purchase requisitions, and the like.

If there is no team type for our category, we can create your own team type. For this our user needs to have the configuration expert role (BPC_EXPERT) assigned to it. We can find the steps for Defining a Team Type on SAP Help Portal.

As we can see in the image above, after selecting OPPUR for the Type field, the field category is filled with Procurement (PROC). Additionally, we'll give the team a name and a description.  Next, we want to shape the responsibilities in more detail. We want the members of the team to be notified only about business processes related to plant 1010.

How do we refine the responsibilities of a team?

This is where the fields in the responsibility definitions come into play.



In the image above, we can see that we’ve chosen plant 1010 as the one in the team’s responsibility. This gives us the option of having one team notified about situations related to Plant A and having another team notified about situations related to Plant B. Leaving the field empty would mean that the team is notified about the situations in any plant. Now that we’ve modelled the team’s responsibilities, it’s time to fill it with members.

How do we add members to the team?

In the Team Owners section, we should already be able find the name of our user. Further below, in the Team Members section, we can find the Create button on the left. Once we’ve pressed the button, the selection window for the business user opens.

As shown in the image above, we can then search for and select users as team members.

We’ll choose our current user, Paul Peterson, as a team member and set his function to Operational Purchasing. Other possible functions are Catalog Management and Workflow Administration. Functions represent the finest level of granularity since they can be assigned to each team member.

We’ll look at the sections Direct Sub Teams and Direct Super Teams in a separate blog post.

If we don’t find the user we want to add as a team member, it might be because that user isn’t associated with a business partner. When this happens, we need to contact an administrator and have them create the business partner. To find out more about who can be a team, we can have a look at Adding Team Members on SAP Help Portal.

Once we’ve saved the team, we’ll be asked to enable it, which we should do. Not enabling the appropriate team is common reason for not getting notifications when a situation occurs.

How can we see if a team is enabled for my situation type?

First, we can see it at the top of the Team page, we've just created.

Second, we’ll find it in the table of the Manage Teams and Responsibilities page.

Finally, it’s also indicated in the Recipients section of the Situation Type page.

Once we click on the count value, we’ll find your newly created team. I think it’s really cool that when we click on Create Team, we go directly to the Teams page of the Manage Teams and Responsibilities app. Choosing the View Team button takes us to the table on the Manage Teams and Responsibilities page. As stated earlier, our user needs to have the business process specialist role, otherwise an error message appears.

So, now that we have a team ready and enabled, we should revisit the Conditions section of the Situation Type page to see how this relates to responsibility definitions.

How do the conditions of the situation type and the responsibility definitions of the team interact?

Let’s take a look at some examples of the relationship between the conditions for a situation type and the responsibility definitions for a team and use Contract Is Ready as Source of Supply use case.

How can a team be notified about a specific condition?

We'll start by creating a situation type and set Plant to 1010 in the Conditions section.

Now, let’s scroll down to the Recipients section where the team category PROC has already been entered and where we can find the team we’ve already created, Z_TEAM_OP_PURCHASING_PLANT_1.

By selecting Plant as the responsibility definition, we are specifying that the plant in which the situation occurred should be used to find the right team with respect to responsibilities. Finally, we want the members of the team to be responsible for Operational Purchasing by selecting this as the member function.

This is the standard setup. If a purchase contract in which unassigned purchase requisitions exist for plant 1010 is created, those members of the Z_TEAM_OP_PURCHASING_PLANT_1 team who work on Operational Purchasing tasks are notified.

Let’s extend our setup a bit.

How can a second team get notifications about a second plant?

That’s easy.

In the Manage Teams and Responsibilities app, we copy the old team, give it a new name, let’s say Z_TEAM_OP_PURCHASING_PLANT_US, and change Plant 1010 to Plant 1710 in the responsibility definitions. Then we add or remove members, save, and enable the team.

Next, in the Manage Situation Types app, we add plant 1710 in the Conditions section.

Let’s check in the Recipients section.

Right, now we have two teams enabled for this situation type.

What happens if a purchase contract is created in which unassigned purchase requisitions exist for plant 1010?

Same as before.

What happens if a purchase contract is created in which unassigned purchase requisitions exist for plant 1710?

The members of the Z_TEAM_OP_PURCHASING_PLANT_US team who work on Operational Purchasing tasks are notified.

So far, someone always gets a notification if a situation occurs. But what about the cases where no notification can be expected? For example,

"What if we add a condition to a situation type for which no team is responsible?"

Let’s add another plant in the conditions table.

Now we add plant 1110 in the Conditions section.

What happens if a purchase contract is created in which unassigned purchase requisitions exist for plant 1110?

A situation will be created but no member of either team will be notified.

As the members of the two teams are not responsible for plant 1110, they shouldn’t be notified. But maybe we’re interested in the opposite case:

What if we want to notify any team in a specific category?

That’s also quite easy.

We just remove the plant from the responsibility definition in the Recipients section. Now the plant information won’t be included for the determination of responsibilities. This means both teams are notified about situations for any of the three plants.

Conclusion

In this blog post we have learned what a team category is and how it relates to a team type. We have seen how we set up a team, refine its responsibilities, add team members and enable it. By following some examples we have understood how the conditions of the situation type and the responsibility definitions of the team interact.

You want to learn more?

These are the five blog posts in a series that introduces you to Situation Handling:

• Situation Handling: What is it and why do you need it? (1/5).


• Situation Handling: Selected use cases in different application areas (2/5).


• Situation Handling: How do I configure situation types? (3/5).


• Situation Handling: How to analyze situations using Monitor Situations (4/5).


• Situation Handling: Advanced configuration of situation types (5-5).

For more information, see SAP Help Portal for Situation Handling in SAP S/4HANA Cloud and Situation Handling in SAP S/4HANA. We welcome your valuable feedback.