Changing CCMS attributes - cutting down on Alarm Fatigue

[keohanster]

Changing the attributes of CCMS Monitors – cutting back on Alarm Fatigue

Alarm Fatigue  is a real thing.  Think about it, in a medical environment (I hope you've never experienced this) there are all kinds of monitors hooked up to the patient, to alert staff if something goes wrong.  The problem is, with all these things beeping and binging, the people in charge of your health care can become desensitized to these very alarms, at times with very serious repercussions.

While I am not comparing medical care to running your SAP(SRM) system, I fear that sometimes, we produce more alerts than are necessary.

Background:  In SRM7, the application monitors can throw exceptions which, in your own particular implementation are not necessary.  In my example, we are using Application-Controlled Workflow (AC) and have our own linkage to events (inherited from SRM5).

When a user changes a Shopping Cart for example, the system is configured to deliver an error message if ‘no workflow is found’ – but we have this situation under control with our custom workflows.  There is (I suppose) no real harm in these extra notifications, except that they create a lot of noise, which can lead to 'SRM Monitor Fatigue'.http://en.wikipedia.org/wiki/Alarm_fatigue

NB: Check with your Basis team before doing this!  They may have more insight into these alerts than you do.

NB2: I am not a CCMS expert. I am a simple Workflow Developer. Don’t take anything I say here as gospel, and please don’t ask me for any details on CCMS!

Having said that, I went into transaction RZ20.

Drill into ‘Approval’ under SAP EnterpriseBuyer Monitors

Select the SAP EnterpriseBuyer Monitors and drill into Approvals.

Then choose ‘Open Alerts’.  The next screen shows you the details of each alert.  Click on the '+' to open the alerts and see which ones are in a red status.

On this screen, choose one of the alerts (for BUS2121, for example) and choose Properties.

On the following screen, we change the ‘When should a message cause an alert’ to ‘NEVER’.

These changes are not transportable – at least they were not for me.  They needed to be manually done in each system.

Result?   My SRM colleague has fewer application errors which require his/her attention.  Those application errors that do occur are ‘real’ – not just false alarms.

Have you done anything to eliminate Alarm Fatigue today?

Cheers.