Skip to Content

Background

What is SAP Event Management? Read the following blogs to read what SAP EM is all about before continuing. In short:

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.

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.

image

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 F when 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.

image 

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”.

 image

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”.

 image

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.

image

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 stagefor 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”.

image

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.

image

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.

image

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.

image

Figure 9

 

Now that the process is complete we can run an extraction to SAP NetWeaver BI 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 BI 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?

image

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 SAP, mobile devices and web apps communicating with SAP EM via RFC, XML or Java / .NET connector.

Manage your processes by exception and provide visibility to your process partners…

To report this post you need to login first.

8 Comments

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

  1. Madhu Vadlamani
    Dear Sir,
      I tried to understand the task posted by you . It is little difficult for me . If you give some basic introduction what  is event management is helpful for all.

    Regards,
    Madhu.

    (0) 
    1. Margaret A Hilsbos
      Also, it would be very helpful to mention at the beginning, what system components and versions are needed for what you are describing. I take it EM is part of BPM but since we don’t have BPM this blog is not helpful to us. But there is event handling in good-old-fashioned SAP Workflow so I thought this blog might be about that, that is why I opened it, from an email of blogs about SAP Business Workflow. I then had to read a bit to realize that this must not be applicable to our environment. It would be nice if that were clear up front.

      Please note my critique here probably applies to 90% of blogs posted on SDN, it is not just you!

      (0) 
      1. Kevin Wilson Post author
        I actually wanted to stay out of the system description this time and just talk the concept of how SAP EM works. I do have an upcoming blog where I will talk explicitly on the implementation options for SAP EM but it was not relevant to this post.

        Just to clarify, EM is absolutely not a part of BPM. I have a blog on SDN just on this topic or you can see the differences at http://www.erpgenie.com/sap-event-management/explaining-the-difference-between-solution-managers-bpmon-business-process-monitor-and-sap-event-management-saps-best-kept-secret.

        I also have another where I describe the difference between SAP EM and Workflow (http://www.erpgenie.com/sap-event-management/differences-between-workflow-and-sap-em)

        These are great comments because if some people feel this way and it’s the wrong perception then I have to do my best to clear up that perception.

        As a workflow guy who know workflow well, I can definitely say that there is space for both. As mentioned in the blog, when an exception is uncovered it is typical to have that resolution resolved using workflow. Workflow is used to enforce work gets done whereas SAP EM is used to uncover the work that needs to be done… i.e. the exceptions

        (0) 
  2. Ranjita Kar
    Hi ,

        I am a newbie for SAP EM and this document gave me a basic overview of how EM works .

    Thanks for sharing the knowledge .

    Regards,
    Ranjita

    (0) 
  3. Kem Miller
    Is there any integration between SAP EM and SolMan BP Monitoring?  There seems to be some overlap of functionality.  Should both be used?
    (0) 
    1. Kevin Wilson Post author
      Yes there is in fact an overlap. See the wiki at http://wiki.sdn.sap.com/wiki/display/SCM/SAP+EM+as+compared+to+Solution+Manager%27s+BPMon for some details.
      in short BPMon can monitor business processes but by exception only. It does not monitor an instance of a process and assign a status to that instance as it flows through the process. It only gets on the BPMon radar if it goes through an exception. Initially BPMon was all focussed on technical aspects of the solution but they have added process specific checks now (e.g. Delivery PGI without invoice). SAP EM does this but also tracks normal statuses. You can use BPMon to track issues in your process (in a batch mode) and would be used by the backoffice, technical staff. You would use SAP EM to track the status of your process and react to exceptions immediately. This can be used by the back office, functional reps (procurement, production, sales) and customer service to enquire about the status of the process.

      I have proposed both solutions to a client previously because they had the need to check performance and status of their order to cash process. BPMon for the technical aspects (jobs running, transaction performance, …) and SAP EM for WIMO (Where is My Order)
      Thanks
      Kevin

      (0) 
  4. Anonymous
    Can you please let me know if EM has to be licensed separately and if so, what is the official product name?  Is it part of Netweaver Business Process Management?
    (0) 

Leave a Reply