Skip to Content
SAP EM monitors your processes and compares your plan for the process with what actually happens in order to uncover exceptions. By doing this you allow your organization to manage their processes by exception. To get an overview of what SAP Event Management is review my blog “An Overview of SAP Event Management
In order to show you exactly how it works I will run through the scenario described below.

The Process Scenario

I will use a 6 step process to describe how SAP EM be used to monitor and react to exceptions in the process. The process spans 3 different partners and different systems. The process is described as follows referring to figure 1 below:
Step 1 – Business Partner 1 performs the task on an SAP system. Once step 1 is complete 2 tasks are kicked off also for Partner 1. These are steps 2a and 2b and they are performed in parallel.
Step 2a is performed in SAP whereas Step 2b is performed on the web. On completion of step 2b a check is performed and if successful the process continues by sending communications to 2 separate partners, namely Partner 2 and Partner 3.
Both partners receive our message and start their respective tasks, namely Step 3a performed by Partner 2 in their SAP system and Step 3b performed by Partner 3 on their mobile device.
Once both these steps are completed communication is sent back to partner 1 to launch the final step in the process which is Step 4 performed on the web.
/wp-content/uploads/2012/10/sapem1_63782.jpg
Figure 1
The Process Plan
Each one of these steps is planned to be performed by their respective partners and at a particular time.
For this scenario I will only deal with the time and partner plan but it applies equally to locations and measurements. E.g. Step 2a could be planned to occur at location A. Also the step could require the temperature to be 3 deg Fwhen it is executed. This would be an example of a planned measurement.
Refer to Figure 2 as I describe the “plan”.
When the first step is executed by partner 1 an RFC is called to the SAP EM system to create an Event Handler (EH). This EH stores all the expected events together with their times, partners, locations and measurements associated with them.
The “Plan” (A) is stored against the EH. Each of the 6 described expected events are stored in SAP EM.
Figure 2
Executing the Process
STEP 1 – The first step is executed and the following happens in SAP:
  • SAP checks to see if the event is relevant for SAP EM communication
  • Once it has been determined that it is relevant, it collects all relevant data to be extracted and attached to the event
  • An RFC is then called to send the event to SAP EM (1)
  • In SAP EM the event is matched against all relevant Event Handlers and posted against the expected event
  • Step 1, as shown in figure 3, is an event that occurred within the planned time by the correct partner so the status of the EH, which depicts the status of the process, reflects a normal state. An example could be: “STEP 1 executed on time”.
Figure 3
Time goes by…
STEP 2b – (as shown in figure 4), is an event that occurred (2) within the planned time by the correct partner so the status of the EH reflects a normal state. An example could be: “STEP 2b executed on time”.
Figure 4
Time goes by…
STEP 2a – (as shown in figure 5), is an event that has not occurred (3) within the planned time by the correct partner so the status of the EH is updated to reflect an exception state. An example could be: “STEP 2a NOT executed on time”. How does SAP EM do this?
SAP EM has a periodic job running called the Overdue Monitor. The overdue monitor interrogates expected events that are past their expected dates. I.e. When time (3) arrived step 2a was declared overdue and the overdue monitor executes pre-configured tasks to update the status of the EH accordingly and possibly issue an alert or raise a workflow to bring awareness to the exception. Exception monitors would then address the alert or workflows to get the respective process back on track.
Figure 5
Time goes by…
STEP 3b – (as shown in figure 6), is an event that has occurred (4) within the planned time by the correct partner so the status of the EH is updated to reflect a normal state. An example could be: “STEP 3b executed on time”. It’s possible to have different stages for your status messages. In our example I could configure a separate stage for partner 3 and have its value as “STEP 3b on time” and in addition have another status related to the EH showing the status at Partner 1 as “STEP 2a NOT on time”.
Figure 6
Time goes by…
STEP 3a – (as shown in figure 7), is an event that has occurred (5) outside of the planned time by the correct partner so the status of the EH is updated to reflect an exception state. An example could be: “STEP 3a executed LATE”. When the event is loaded against the EH it checks the plan and sees that it is late and thus executes a set of pre-defined tasks. These tasks can, once again, update the status, issue an alert or raise a workflow. The exception monitors will once again pick up on the exception and address it should action need to be taken to get the process back on track.
Figure 7
Time goes by…
STEP ??– (as shown in figure 8), is an event that has occurred (6) that was not planned at all (it is an unexpected event) so the status of the EH is updated to reflect an exception state. An example could be: “DELAYED”. When the event is loaded against the EH it executes a set of pre-defined tasks. These tasks can, once again, update the status, issue an alert or raise a workflow. The exception monitors will once again pick up on the exception and address it should action need to be taken to get the process back on track. For a delayed event the exception monitors may even adjust the planned dates and times for the remaining expected events.
Figure 8
Time goes by…
STEP 4 – (as shown in figure 9), is an event that has occurred (7) within the planned time by the INCORRECT partner so the status of the EH is updated to reflect an exception state. An example could be: “STEP 4 executed by wrong partner!”. When the event is loaded against the EH it checks the plan and sees that it was supposed to be performed by Partner 1 but the event said that Partner 2 executed the event. On receipt of the exception event a set of pre-defined tasks is executed that can, once again, update the status, issue an alert or raise a workflow. The exception monitors will once again pick up on the exception and address it should action need to be taken to get the process back on track.
Figure 9
Now that the process is complete we can run an extraction to SAP NetWeaver BW where we will analyze the effectiveness of our processes. Each partner can be given visibility to the SAP EM process to gain insight in to the entire process as well as have them exposed to the exceptions that are applicable to them so that they can address them.
Figure 10 shows the extraction to SAP NetWeaver BW where the KPI reporting, trend analysis and partner performance can be viewed. In our example we can view the following details:
  • Cycle times between the execution of events between any of the steps. E.g. Average time between STEP 1 and STEP 4
  • Number of processes where STEP 3a was executed on time vs. late. I.e. Difference between planned time for STEP 3a vs the actual time we received the event
  • As a % show how many orders had an exception status. i.e. Gives you an idea how many orders had to be manually addressed
  • Per partner what % of orders were executed according to plan?
Figure 10
Conclusion
Having gone through the full process and showing how it relates in SAP EM you should be able to see just how SAP EM enables companies to manage their processes by exception.
In the above example, the only time we needed human interaction was when we had an exception condition. In addition, these exceptions are immediately delivered to the responsible person, together with all the detail they need to correct the issue. I.e. We collapse the time between exception and resolution. It’s a proactive approach vs. a reactive on non active response.
One more point to mention is the different systems that are able to send evens to SAP EM. We have 3rd party systems, SAP, mobile devices and web apps communicating with SAP EM via XML web services.
Manage your processes by exception and provide visibility to your process partners…
If you have any questions just let me know!
To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply