Event Management: Shouldn't an alert be treated by IM?

General discussion on all aspects of the IT Infrastructure Library (ITIL)
Post Reply
User avatar
ChasingSleep
ITIL Expert
ITIL Expert
Posts: 78
Joined: Mon Nov 17, 2008 7:00 pm

Wed Jan 20, 2010 9:26 am

Hello,

I am struggling with a particular part of ITIL V3 Event Management process workflow.

In this workflow, Human Intervention for an Alert is not treated by Incident Management. This is justified by saying that "the alert requires a person, or team, to perform a specific action, possibly on a specific device and possibly at a specific time, e.g. changing a toner cartridge in a printer when the level is low." (Page 41, Service Operation book)

I am not sure I agree with that.

Let's take the given example. Shouldn't it be treated by the IM process? After all, "Incident Management includes any event which disrupts, or which could disrupt, a service." (page 46, same book). So, if we get an alert saying that our printer is running out of ink, isn't it going to disrupt a service if not fixed?

I see no advantage in treating these alerts outside of IM process, but I would like to hear from you guys.

Best regards


User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Wed Jan 20, 2010 10:29 am

Isn't replacing a toner cartridge just maintenance? Perhaps different if it actually runs out of ink during a print run.

According to some people who have been bludgeoning me to death on another forum, if you call it an incident, you have to open a problem record to get at the root cause which, in the first case is people using the printer and in the second could be poor monitoring, poor planning for large print runs or low capacity of the printer, or just an unusual combination in the timing of events.

The tricky bit with printing as a service is to do with how quickly the output is needed. It would not be unusual to hold the next cartridge in readiness near the printer and then the change over ought to be quick enough that it hardly matters. If it hardly matters then it is unlikely to warrant an incident status. But, of course, this may not be true in all cases.

I would suggest the book is sound enough, but is a generalization without prejudice to what suits a particular case.
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
User avatar
ChasingSleep
ITIL Expert
ITIL Expert
Posts: 78
Joined: Mon Nov 17, 2008 7:00 pm

Wed Jan 20, 2010 10:44 am

Diarmid,

Good point. If we look at these alerts that require human intervention as just maintenance work, then I can agree that there is no need for IM.

Cheers!
User avatar
Fabien
ITIL Expert
ITIL Expert
Posts: 207
Joined: Mon Sep 26, 2005 8:00 pm
Contact:

Mon Jan 25, 2010 9:44 am

This is true. Because many events will end up at the Service Desk, their nature may be confused with incidents, or even service requests.

The V2 definition of an incident used to encompass events. I think it was fine that way. Problem Mgt and Event Mgt have the effect of reducing the complexity of work at the Service Desk. I call them "Noise Mgt" processes...

Let me explain. All requests related to interruption or degradation of service arrive at the Service Desk. From there they are captured and prioritized. (Notice I just said "they". I didn't call them a specific name)

On one hand, some of those have an impact and they may indicate that there is an underlying issue to resolve. Instead of bogging down a Service Desk analyst in getting the issue fixed, we say that his job is only to restore service and let others deal with the underlying issue (Problem).

On the other hand, we now know that we can get the systems to report immediately. Since those don't necessarily require customer contact, and some aren't service disruptions, we don't want Service Desk analysts to get bogged down in dealing with them either. So we call them events.

It's noise management, really. The bottom line is the following, and it's a management principle: you want to get work done for the least amount of money.

While we always talk about functional escalation in incident management (the process of transferring the handling of an incident from a generalist to a specialist), we often fail to show that the real purpose is for highly skilled specialists to delegate most of the work down to general analysts and customer service specialists, who generally make less money, in order to maximize the use of the human assets for the company.

Event Management plays a role in that.
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek
User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3639
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Mon Jan 25, 2010 10:49 am

EM is a subset of IM and if people RTFM and use the FAQ, they can JFDI.

Meanwhile the PM is FDL while the CM is ROTFLMAO while the SD manager sings... TLA TLA...
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
User avatar
Landerson
Newbie
Newbie
Posts: 4
Joined: Mon Jan 25, 2010 7:00 pm
Location: Salford, UK

Wed Jan 27, 2010 11:20 am

Sure there is a Joke in this thread somewhere...

How many ITIL professionals does it take to change a toner cartridge...?

The punch line is obvious...

None! Because they were all rubbish and got fired, after they spent too much time arguing over what to do with a printer alerting its toner cartridge running low. The paymasters decided the best way to hand this NOISE was to outsource the support of the print infrastructure to a 3rd party... After many bids the outsourced service provider is selected, then it’s discovered that there's a few more printer than were in the initial proposal and thus renegotiation: the service level agreements. Eventually after a few months, service levels didn't improve in fact they diminished so much, execs and mid level manages decided to take printing matters in to their own hands. They purchased a whole verity of desktop printer and couple of MFDs, all printer purchases, the execs claimed the costs back through business expenses and continued happily printing... Until one afternoon, a blinky flashy light from a Deskpro 50000 catches the eye of an exec. Not knowing what to do about the blinky flashy light the exec places a call through to the service support desk. Unfortunately the Service desk informs the exec that support for printers is provided by a 3rd party company. The exec at this point has had enough and the blinky light is becoming so irritating, the exec decided to pay a visit to the exec of Enterprise Release & Configuration Management. The ER&CM Exec understands the frustration and allocates the company IT guru specialist to go take a look (as a special favour). The IT guru specialist goes to execs office, looks at the blinky flashy light and then inserts paper!

The end…

Well its not really the end…

The question ChasingSleep posted illustrates and reflects my own opinion of the ITIL v3core texts. I bought them after I passed my ITIL v3 exam and try as I might, they bore the hell out of me and I haven’t progressed through them.

Google ‘Atwell Williams - ITIL Certification Series’ listen to his podcast series, its on version ITIL 2 but its still very excellent. Then make everyone in your office listen to the series.

Then go to you tube and lookup W Edwards Deming, watch a little of the content.. Then read a little about him..

Take half aday to do the above.. Then go do your exam, no I’m joking..

Fabien, your comment made me hang my head and go OH NO!!

In fact you’ve had a prefound effect on me that has made me write my response..

“It's noise management, really. The bottom line is the following, and it's a management principle: you want to get work done for the least amount of money”

Come on… Businesses deserve better than this… A management principle!!! You call it a Management principle??... I call it a CASH COW for someone, folk out there that love milking such things. MOO MOO “set the alert to 60%” MOO MOO no “40%” MOO MOO…



My solution for this… would be first of all ‘think’: reduce waste = reduce cost

Alerts are manufactures methods of informing. Not noise… DINK DINK DINK
(DATA IS NOT KNOWLEDGE) (use the info)

My solution = Use the info and do not waste anything..

“Get the IT gurus to automate everything! Document it the process and measure the process.”

AUTOMATED PROCESS:

IF Printer Toner Cartridge alerts 90 % usage;

Alert ->send to->> ERP system

If ERP has Toner cartridge in stock = YES;
Do nothing;
Await 99% Alert

Else If ERP Toner cartridge in stock = NO
Then order stock
Await 99% Alert

If 99% Usage alert received

Raise a work request to Facilities management

Facilities mgt Recycle toner cartridge

END.
User avatar
Marcel
Senior Itiler
Senior Itiler
Posts: 63
Joined: Wed Sep 20, 2006 8:00 pm
Location: USA

Mon Feb 08, 2010 11:27 pm

Although I have seen a lot of organizations where events are commonly handled through incident management, I think there is a distinction to be made. An event is not the same as an incident, but an event may be indicative of an incident.

Events typically pertain to changes in status or usage of CIs. For example, you may monitor a file system for its utilization and capture every event where file system utilization crosses certain thresholds (going up and down). You may set thresholds at 60%, 75%, 90%, 95%, and 99% full. You may decide that you want to see alerts only at the 75% and higher thresholds. Reaching 60% or 75% may still be considered normal operation without immediate danger, but you may decide that at these levels you do want to proceed and increase file system space. You may also decide that reaching a 95% or higher threshold is pretty close to impacting a service and therefore should be considered an incident. By pretty close I mean that there may be little time left for corrective action before you experience an actual impact. Your response may be the same: add more space (for simplicity I ignore the option of cleaning up obsolete files).

There are a few things to take note of here:
1) the way you respond to certain 'non-incident' events may be the same as how you respond to actual incidents (in this example: add space)
2) capturing this event data is useful for capacity management and pro-active problem management and encompasses more than just incidents
3) it is up to you where and how you draw the line between event and incident management and to determine what events do or do not constitute an incident in your organization
4) the reason to make an explicit distinction between event and incident management for some organizations is just about reporting; it allows them to make a distinction between pro-active (event mgmt) and reactive (incident mgmt) behavior
Manager of Problem Management
Fortune 100 Company
ITIL Certified
Post Reply