Skip to Content

Exceptions in High Volume Systems

Exceptions in IS-U

With this blog I try to start a discussion about exceptions in high volume systems like IS-U (SAP for Utilities industry solution) and how they can be handled.

First a few words to introduce myself:
I started working with SAP IS-U in 1999 with the introduction of an IS-U system at the utility company I worked at that time. In 2001 I joined SAP Netherlands and became IS-U consultant. In the beginning I focused on the production side of the process and got in contact with parallel processing, logs and the related problems. In 2003 I went to Palo Alto for testing one of the 1st EMMA releases and met the development team that worked on EMMA. The contact stayed and during my SAP period I was extending my knowledge and network in this area. In August 2007 I left SAP to start my own company and focus on exception management and still working for international customer sites to help implement “Exception Management“.
In this blog I will take IS-U as example because of my background and experience in that area but the issue with exception management will be valid in many other high volume systems and environments.

In the IS-U processes many exceptions occur. Some are important and need to be handled and managed quickly, some only offer information and can be used for reporting, and some are complete useless. In these exceptions lie huge risks when they are not managed properly.
The big challenge is:

  • to find the important exceptions,
  • to work on them consistently and efficiently,
  • to solve them and use there the informational ones
  • and get rid of the useless exceptions.

SAP is not very good in doing so but is trying to improve. In the FICA (Financial Contract Accounting) environments like IS-U, SAP offers a framework that has great possibilities to take care of most of the above mentioned tasks. For a successful use of the framework the way it’s implemented is very important; some customer coding is inevitable.

First some words about the framework called EMMA or BPEM. One of the first confusing things: is it EMMA or BPEM? But what’s in a name in the SAP World? In the mean time I do not try to explain the difference, EMMA (Enhanced Message Management Analyses) was the old name. In the IS-U area the name EMMA was replaced by the business name BPEM meaning “Business Process Exception Management”. BPEM as a name covers the functionality more than EMMA does and it is less technical, but in the system there is nothing called BPEM. Everything related to the framework, from transaction to tables have EMMA somewhere in the name. So don’t worry too much about the name, just one of SAP’s tricks, like they did with ERP or mySAP or ERP or ECC6, BW and BI or with XI and PI, who knows? I prefer to call the exceptions management framework EMMA.

EMMA is easy explained to many people, they understand the functionality immediately; at least that is what they think. EMMA has a huge potential and can be a big cost saver for the customers in High Volume systems, like IS-U is. The big problem I see in the field is that understanding EMMA means more than only understanding the core functionality, it requires a philosophy! More is needed than a quick and basic implementation! Customers need to ‘buy in’ to the philosophy; they have to go the whole way, meaning implementing EMMA as complete as possible. Then they have to accept that EMMA is a live product where in the first period of use a lot of work is needed to complete the implementation. It is very important that ‘the business’ supports this EMMA implementation. A complicating factor is that standard SAP delivery of EMMA is missing essential functionalities and SAP seems not to be willing to invest in this missing functionality. All of this makes that EMMA is in some implementations more a problem than a solution.

Some or most customers start implementing basic EMMA and get confronted with a result nobody wants, millions of “EMMA-Cases” telling them at least something is wrong in the process. Based on this they then start building own, non-integrated functionalities to close the gaps. This leads to an (other?) inefficient process with more overhead and less solutions. Few customers build nice extensions to the standard EMMA, but that is not supported by the SAP Standard giving the well-known issues during an upgrade. Also EMMA is still changing, in the ECC604 SP1 release there is a whole new EMMA coding released, far more stable and with more functionality.

Let’s go through a few steps and point out the important topics and the right and wrong approach with some statements related to existing customer situations.





Basic Implementation

As basic as possible

Implement all expected, possible or available exceptions

The real time system will tell you what Exceptions come up; use that information to configure EMMA. Useless to spend time on Exceptions that will never occur.

Basic Implementation

Create solution processes

No solution process

Without a solution process EMMA is useless and has proven to most of the times create chaos.

Basic Implementation

Populate Suppress Table

No entries in Suppress Table

Suppressing useless messages will give a clean log and non-discovered exceptions will be detected more easy


Start simple

Integrate EMMA with other systems (third party or CRM)

Integration with other systems can be done when the use and philosophy of EMMA is clear


Work EMMA Cases from EMMACLS

Create own interface (in CRM?)

EMMACLS offers flexible interface that can be used as the user inbox


Specialists approach on limited number of case categories.

End to End Customer Journey view

IS-U is a production environment where some jobs have to be done in time, efficient, quick and consistent. The end to end view will dilute this process. If the E2E view is very important, the system is in a chaos already and EMMA is most possibly badly implemented.


The above list is based on the start of use of EMMA – and of course incomplete – but only shows some simple and sometimes naive pitfalls that are seen at many EMMA implementations. They all lead to massive production of EMMA cases where no one knows what to do with them or what the actual status is. At the end of the day, experts have to come in to delete the excessive amount of cases and set up processes to improve the situation. At that point in time on a running system it is not an easy job and hard to change things to the better.

Implementing EMMA efficiently is not an easy way to go and it does not come cheap, but when it would be done it would be THE cost cutter in the process. I have seen examples where 125 up to more than 2000 agents extra were working only on the exceptions backlog, using external non-integrated tools and word documents to tell them what to do. Needless to say this is an unwanted situation. A well implemented EMMA, even the standard one with the known gaps could do lots of good work in those situations and reductions of 50% or more are realistic. For that more is needed than only producing a standard overview like shown below.

EMMACLS, not the best viewEMMACLS, not the best customer view

For this first blog I think it is enough. I will soon bring more entries in this blog about the implementation and the possible improvements. But before I close this entry I want to point out another opportunity related to EMMA, being the use of the available SAP Business Intelligence information. Based on EMMA KPI’s can be produced on efficiency of teams, processes, agents etc. Above this the BI information can be used in the solution processes of EMMA as shown below (with thanks to Axel Memminger)

Integration of BI in standard IS-U Outsorting

I will go to this more deeply in one of the next Blogs.

OK this is the end of my first Blog Entry in the BPX community, I hope you will enjoy it and will give your valued comments.

To be expected:
Gaps in Exception Handling
BI Implementation
BI Integration
3rd Party products

Hans Kardol
Independent Sr. SAP EMMA/BPEM Consultant

Tel.: +31 613295357

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

    This is an excellent view of EMMA/BPEM for someone who’s just starting off in this area. I have known Hans for a few months now and his knowledge on EMMA/BPEM is unparalled. I would like to see some more technical stuff on this blog soon. Maybe a complete cycle of a EMMA case.


  • Great to see a blog on EMMA.The use of EMMA depends to a great extent on the understanding of business processes and how to best into SAP. Find below some areas wherein EMMA can be used:
    1.Disconnection Services
    2.Arrears,Payments,Security Deposit followup
    3.Final Billing exceptions
    4.Unauthorised Usage
    5.Write off