Did you know that you can run an in-depth analysis of Situation Handling with the Monitor Situations – Extended app?

For example, take a look at your projects: Which ones are internal and which ones are external? With an optimization of your configuration with the Manage Situation Types – Extended app and the analysis using the Monitor Situations – Extended app, you will be able to draw better conclusions about your changing business processes.

Let’s quickly check where you are so far: You’ve discovered the extended framework, modelled your own situation use cases, and maybe you’ve already monitored them – well done. You might have captured all issues for a use case in one situation type. Now you may ask yourself, “How can I analyze situations on a deeper level?”. Either the number of situation instances created may be too big for a decent analysis or the use case has a certain characteristic that you want to analyze in-depth.

Here’s the answer: For both cases, the solution is to split the general situation type into several smaller ones, which improves the analysis.

My name is Joerg Rett, and I work on data and analytics for Situation Handling. In this blog post, I’ll show you how you use the Monitor Situations – Extended app to improve the configuration of custom situations.

Use the Monitor Situations – Extended app to compare variants of situation types

When you start with Situation Handling for your use case it might be difficult to judge the configuration beforehand. You might not be able to foresee how many situation instances will be created in the days to come. That’s why you may have chosen a configuration that doesn’t overwhelm the responsible user with too many notifications, but makes sure they don’t miss out on important issues requiring their attention. Most of all, you want to make sure you can analyze how issues progress over time using your configuration.

Let’s look at some examples: Picture this, you’ve configured a situation type that informs your colleagues about purchase contracts which are about to expire. Since the number of new situation instances has been increasing recently, you might ask yourself, are the issues involving value contracts or quantity contracts increasing?

Or consider this: You’ve configured a situation type that informs project managers about commercial projects which are still insufficiently staffed. The number of created situation instances has been increasing here too. This time you might ask yourself, are the number of issues for internal projects or customer projects increasing?

Remember, a situation template serves as a blueprint for creating a situation type and includes all the elements that you need to define your use case. The number of situation instances that are detected depends mostly on the conditions defined in the situation type. In other words, conditions are the control buttons you use to influence the sensitivity of situation types.

You can use this not only to limit or increase the number of situation instances but also to create two or more situation type variants with different condition filter settings. How can this help? By comparing these situation types with each other over time, you can see whether a certain characteristic causes an increase in the number of issues.

Monitor Situations – Extended is the right app for this kind of analysis on a finer granularity. Want to see how that’s done? Keep reading. Let’s take a look at the use case “Unstaffed Resource Requests for Projects” presented by Ana Gonçalves in her blog post.

Unstaffed Resource Requests for Projects

A short recap: Project managers need to plan their resources to manage their projects. Resource management also includes staffing personnel accordingly.  If projects are not staffed in a timely manner, they can be delayed.

Here, Situation Handling helps inform project managers about projects with unstaffed resources at a specific time before the start date.

Imagine the number of issues is slowly increasing.

How would you become aware about this?

You’ll have a look into the Monitor Situations – Extended app.

Analyzing timelines in Monitor Situations – Extended

Once you open Monitor Situations – Extended you’ll see a line chart with the number of activities for situation instances per day for the current year. So, the first step is to drill down into the situation type that relates to the use case of “Unstaffed Resource Requests for Projects”. The situation type ID, here YY1_UNST_RESOURCE_REQUEST_2_ALL_PROJ, will be your first filter setting.

Since when has the number of issues been slowly increasing? You don’t know? Maybe start with a small time range like Last and use it in the Activity Date/Time filter field. In contrast to the predecessor app, Monitor Situations described in my earlier blog post, in Monitor Situations – Extended you can benefit from the Smart Filter Bar with DateRangeType which already comes with a lot of predefined date ranges.

Since you want to see the trend for newly created situation instances, you can continue with the Activity Type filter, restricting it to Instances . Situation instances can be created only once while activities that update the instance can occur several times.

You won’t need the other filter fields, such as Instance Status, Anc. Obj. Sem. Key and Anc. Obj. Key Text, so remove them to have a bit more space for the chart and the table. This is useful if you’re working with devices that have a small display.

After choosing Go, you’ll see the time-series data for situation instance activities in the smart chart and smart table. If you’d prefer a column chart rather than a line chart, you can adjust it in the chart area with the chart icon.

You can already see that the number of newly occurring situation instances is increasing.

Now it’s time to prepare an in-depth analysis of the situation instances and check whether the increase is for customer projects, internal projects, or both types of projects.

How could you get more insight into this?

Use the Manage Situation Type – Extended app to create variants of situation types

The idea is to create two variants of an existing situation type, one for customer projects and one for internal projects, and to disable the existing one. This way you can visualize how the variants compare against each other and the existing one.

The process is fast and simple. Just mark the existing situation type which deals with all project types in Manage Situation Types – Extended, here YY1_UNST_RESOURCE_REQUEST_2_ALL_PROJ, and select Copy. Once the object page opens, you provide a different situation type ID, such as YY1_UNST_RESOURCE_REQUEST_2_CUST_PROJ, and adjust the name and description accordingly.

You create the variation of the situation type in the section Situation Triggers / Batch-Based Trigger. The name of the trigger is still Periodical Resource Request Check, but in the Conditions section you add an additional filter for the Project Type.

The value is set to C for customer project.

As this situation type will react only on resource requests regarding customer projects, you can also adjust the message text.

Finally, you can also adjust the Navigation Actions by removing the link to the app to maintain internal projects.

After you’ve saved and enabled the type, you do exactly the same thing again, but this time for an internal project by setting the filter to I for Project Type.

At this point you have three situation types enabled, two specialized types, one for internal projects, one for customer projects, and one general for both projects.

Since you didn’t change Batch Job Scheduling, all types will look for new or changed situation instances as defined in the general type, for example, once a day.

If you left them all enabled, new situation instances would be created twice, along with the notifications. So, the first thing you want to do is to disable the general situation type responsible for all projects. This is YY1_UNST_RESOURCE_REQUEST_2_ALL_PROJ. If you do this, new situation instances will be created only for the two specialized situation types.

But what about the existing situation instances in the general situation type? Well, you have to delete them. Otherwise these situation instances would be replicated for the two specialized situation types during the upcoming batch trigger. As a consequence, the business user would see two situation texts for the same business object.

You can do this in the Manage Situation Types – Extended app by selecting Manage Instances.

There you select all Instances and choose Delete.

You could also have deleted the whole general situation type and with it all its situation instances. In this case you would have also lost the historic data of the respective activities. In the following section you’ll see that it makes sense to keep those historic activities to better analyze the trend.

As previously mentioned, the batch job scheduling of the two specialized situation types will take place twice a day. To judge whether the trend continues, you’ll need to collect data for several days.

Finally, after collecting data for four days you go back to the Monitor Situations – Extended app.

Comparing variations of situation types with Monitor Situations – Extended app

First, you adapt the filter area and choose Adapt Filters and then Sit. Template ID as an additional field. The fields Instance Status, Anc. Obj. Sem. Key, and Anc. Obj. Key you have already removed previously. With the Sit. Template ID filter you can narrow down the data to those types related to the “Unstaffed Resource Requests for Projects” use case. With the filter for Situation Type ID, you can look at data from a single type.

If you’re familiar with the filter fields of the predecessor app, Monitor Situations, you’ll see that the number of fields has increased. This provides new drill-down options and new insights. For example, instead of filtering by the situation type IDs, you can now filter by situation template. This is the same for the general and the specialized types.

Some fields have simplified labels, for example, Description of Activity Type was renamed to Activity Type. The source that indicates who or what triggers an activity like has been renamed from Description of Activity Trigger to Activity Source.

Back to your analysis. Now that you selected the fields, let’s use them. First choose a Sit. Template ID like YY1_UNSTAFFED_RESOURCE_REQUESTS_2 to capture all situation types that you’ve copied from this template. This means you need to leave the Situation Type ID field empty.

To see the effect of a single general type versus two specialized types even better, choose the stacked column chart for the chart area.

Great! Now you can clearly see that it’s the number of situation instances created for the customer project that is increasing day by day. The number for the internal projects remains constant.

Analyzing and optimizing the use of the Monitor Situations – Extended app – a short summary

The key take-away for you is that the Monitor Situations – Extended app lets you evaluate whether the occurrence of situations is a trend. Once you’ve gained insights, you can create variants of a situation type by adding a condition to the Manage Situation Types – Extended app. Finally, you can further investigate the behavior of these types through the Monitor Situations – Extended app.
In this example you have seen an analysis of time series data for eleven days. Imagine that if you increase the time period to one year you might be also able to observe seasonal effects.

In this example you also saw that the number of issues were increasing. Instead, you might observe some peaks in the data that can pose a problem to your business process and require further investigation of the root cause.

The control buttons you have been using to influence the sensitivity of situation types are the filter elements of the type’s conditions. This means that you can create only situation types variants based on the available filter elements. Which elements are available is determined by the situation objects the scenario uses. Ultimately, the situation object depends on the underlying CDS views. So, it’s wise to take future data analysis into consideration when you’re creating your own custom CDS views as shown in Ana Gonçalves’ blog post.

Want to learn more or refresh your knowledge about Situation Handling?

More blog posts about Situation Handling are available:

• Custom Situation Cases: Configure your own use cases (1/6)
• The Power of Reuse – Custom Situation Configuration
• Fine-Tuning Custom Situations: Closing Behavior of Situation Instances
• Fine-Tuning of Custom Situations: Configure the Layout of My Situations – Extended
• Custom Situation Handling Use Case for Professional Services: Unstaffed Resource Requests

For more information, see SAP Help Portal for Situation Handling – Extended Framework for SAP S/4HANA and SAP Community for Intelligent Situation Handling. We welcome your valuable feedback.