Skip to Content

Implementation considerations when configuring SAP Event Management

For those of you who don’t know what SAP Event Management is, take a look at my blog Supply Chain Event Management (SCEM) Described.

In short, it’s SAP’s way of allowing you to track the status of your application objects across your process across your process landscape (including external to SAP). On top of that we are able to put in the PLAN as to when we need to have each step of the process performed. We can then react when the process does not follow that PLAN. We can also react to unexpected issues occurring during the process. With tight integration to the Alert framework and Workflow we have a great mechanism to raise awareness of these issues. With the tight integration with BI we can also inform the top brass just how well we are performing (or not).

In Short, SAP EM allows you to manage your processes by EXCEPTION!!!

Now, how do I go about designing an SAP EM solution?

I have a spreadsheet that I complete at each client and I’ll go through what I’m looking for at each step right here.

  1. I put together a high level process flow diagram of the required process

    a. I seperate events into 2 categories: Expected events (e.g. Delivery Create) vs. unexpected events (those that we don’t expect to happen every time the process is executed – E.g. Credit Block)

    b. I highlight the events that make up a potential Key Performance Indicator (KPI) e.g. Time between Order complete and Delivery Create

  2. For each set of events that logically make up a status grouping, I depict it as such. e.g. Delivery create, delivery pick, pack and PGI all belong to the shipment group whereas Order create, credit block on / off, order complete are all part of the order processing group

    a. This is important because this becomes your status profile entries in SAP EM. I do in fact display each status in SAP EM on the pictorial as well and relate the events that trigger the particular status. e.g. The Delivery create event message is triggered when a delivery is created and when it gets to SAP EM it generates the delivery create message against my Delivery Event Handler (EH) and updates the status of the Delivery group (through the status profile) to the value Delivery Created. The Rule Set is used to configure this update of the status attribute.

  3. List out the status values that can occur when unexpected events occur and when events don’t occur when they should. e.g. Late events make the status go to “Delivery Creation Late”
  4. That’s it for the process flow diagram. I now proceed at filling out my event mapping template as follows:

    a. List all your events in the first column. Next to each state whether they are expected or unexpected. This drives your expected evet profile and also serves as your list forthe creation of event codes

    b. I have another column whichhas a unique number indicating whether the overdue monitor checks this event or not. At the bottom of the template I have the cross reference between that number and what it needs to do when this event goes overdu. e.g. Set the Delivery Status as Late. This serves as my overdue monitor rule set instruction

    c. I then have a couple of cloumns telling me the system and source document for the event. E.g. Sales Order header -> ECC

    d. There is a column for any calculations that must occur in SAP EM. i.e. Some events are not generated in an application system but rather configured in SAP EM. e.g. You have the expected event Invoice create occur 2 hours after you receive the Delivery PGI message

    e. I have another special column to highlight an event that is updated by another event. If the time is manipulated by another event then I specify time and the event that is to modify it. I also put in whether this event updates parameters or not. List the parameters.

    f. List the corresponding Status Attribute Name and corresponding status value that the event relates to

    g. In a notes column detail out the trigger mechanism of the events and note any sort of detail that will help the developer. This is where most of the effort lies.

  5. On a seperate tab I workout what the status profile needs to look like. This is done purely on what status values the client would like to be informed of during the process
  6. Another tab seperates all the parameters which are the data attributes of the event handler we are tracking. E.g. Delivery number, Ship to account, ship to City

    a. List the source of the parameter

    b. List whether it’s an information or control parameter. In addition if it’s a control parameter can you break it down into a system parameters. You use system parameters for fields that you will be searching on frequently as they give you the ability to index them making these searches faster

    c. List any manipulation of the parameters that may occur. E.g. Concatenation

    d. List the Table / fields where the data resides in the application system (if applicable)

    e. On this tab I also list the authorization fields that are required. Similarly for the filter object fields

  7. A seperate tab for your Identifiers

    a. Tracking IDs
    b. Query IDs
    c. Specify their length and type

  8. A seperate tab detailing Alert requirements
  9. A seperate tab detailing workflow requirements
  10. A seperate tab detailing BI requirements

    a. Fields to be extracted
    b. Events to be extracted and which durations to measure for the events. e.g. Time between when the Delivery created was created and when it was supposed to be created.
    c. Groups of events and their durations to be measured. e.g. Time that the delivery was created to the time that the delivery was PGI’d

  11. Have a tab to store your test data
  12. Have a tab to list your standard set of design questions together with their answers. E.g. Will I use the out of the box scenarios or will I be customizing the delivered scenarios?
  13. Lastly put your document version control on the 1st tab

I would say that if you complete this list of requirements in detail and hand it over to a competent SAP EM developer they’d be able to perform 90% of the development and configuration without question.

The majority of the effort in SAP EM is actually in getting the events to raise when they are supposed to be raised. Take care on events that “partially” occur. e.g. A delivery is partially picked. 

Be specific in the template on how and when these events are to be triggered.

Have a happy “SAP Event Management” day!!!

1 Comment
You must be Logged on to comment or reply to a post.
  • Hi Kevin,

    I have read many of your blogs about SAP EM and you have convinced me about the added value of the product but so far I have only encountered articles positioning it on the area planning and execution processes within logistics.

    Do you have other experiences using SAP EM within other industries/processes that logistics?

    Also in terms of license wise, what kind of license model is applicable for SAP EM?

    Many thanks,

    Roberto Viana