HelpAboutBlogBOKKEDPodcastsTopicsWizardLinksBooks

Skep's Pick: The IT Skeptic Awards for 2008 This link is here because...(hover)

problem

Shit happens, or how I learned to love the incident

Complex systems are by definition broken. They will always break and sometimes they will break when everybody did what they are supposed to. Fixing the problem won't necessarily reduce the risk of another incident.

We should create the problem record right up front in an incident

A BOKKED post three months ago drew a lot of attention. It was about the disconnect between Incident and Problem Management in ITIL V3 Service Operation. [See also the ITIL Wizard stirring the pot about Major Incidents] I've just discovered a response to that post which has popped my brain with its simplicity and clarity

ITIL V3 Service Operation disconnect between Incident and Problem Management

There seems to be a major disconnect between ITIL V3 Incident and Problem Management.

Say it ain't so!! ITIL V3 Incident and Problem processes do not determine the affected service

This BOKKE (body of knowledge known error) has been posted for a day or so, hundreds of views. I was sure someone would say "no you idiot, service impact analysis is right here" but not one. It seems to be true.

Incidents overwhelm problems

Problems suffer from the important/urgent dilemma. They are very important but struggle to get attention in the less mature shops over the incoming bombardment of incidents.

This is over simplistic but cute

Defining terms in Root Cause Analysis - let's be clear what we mean

in

We have a great discussion going regarding Root Cause. As usual so much comes down to precise definition of terms. What does Root Cause mean?

Root Cause Analysis can't be done by machines

Vendors are making a fuss about their Root Cause Analysis (RCA) features in their tools. People Process Things once again: who says Root Cause is in the technology?

Syndicate content