ITIL

The IT Infrastructure Library www.itil.co.uk

The uselessness of ITIL process maturity assessment

I'm looking at a "classic" process maturity assessment done by a consulting firm for a client, and what a useless document it is. I'm not saying who sent it to me or why or where from. That isn't important here because so many assessments are similar. Compare yours.

The report analyses 8 practices. It doesn't say why those eight. ITIL has 27 or so, COBIT about 40. They are a typical eight: Incident, Request, Problem, Change, SACM, SLM, Knowledge, Catalogue.

ITIL doesn't add overhead

I'm intrigued by the endless repetition of the chant "ITIL slows things down". No it doesn't. Doing things properly slows things down.

The difference between ITIL and COBIT for consultants: four words

As a consultant, COBIT is my first-choice body of knowledge for my engagements. I go to it first* to assess, to frame, to define, to justify, to audit. I turn to ITIL second, when I need more detail, or when I need the authority of the holy of holies to justify what I suggest. There are two reasons for this:

The state of ITIL

Some time ago I did some research for APMG on the state of ITIL. Now the resulting white paper has been published.

ITIL training fun and games at itSMFUK conference - and an end to competition?

The IT Skeptic hears on the grapevine that the ITIL training industry may be having a few meetings of its own at the itSMF UK conference next week. And the topics of conversation may bear on the continued competition between Examination Institutes (EIs).

Lean IT and ITIL

One sees a few remarks in the webisphere that suggest folk don't get the relationship between Lean IT and ITIL (thanks to my friend Bob Grinsell, RIPOFF #1, for reminding me of this issue by his comment on the itSMF USA forum). Lean is a method. ITIL is a framework. These are different things for different purposes.

Riddle me this: matching ITIL theory to the real world

Calling all you ITIL theorists, philosophers, pontificators and pundits. Marty is back: our follower from the real world, trying to make sense of ITIL on its home grounds, the operations of big iron batch computing. Marty asks what happens after a service is restored? What does ITIL call the function of undoing the damage done while a service was unavailable? I have a view - of course - but I'm going to stay quiet - for a while- and hear what everyone else thinks. So have at it.

Does ITIL explain the difference between an Alert and an Event?

Help me please. I'm thrashing around in the morass of Service Operation, trying to get crystal clear on the difference/relationship between an Alert and an Event. Anyone?

P.S. we did skirt around this discussion before

ITIL 2011 persists with the dangerous concept of supporting services

Not only has ITIL V3.1 2011 not fixed the problems with business-vs-technical services, they have gone the wrong way and reinforced the problem. I will fight to the death to say there is no such thing as internal supporting "services", because I care about ITSM.

DevOps and ITIL

Recently I had a few things to say about DevOps. In a nutshell, DevOps is a niche approach to service design and delivery, which won't have much impact in the near future on traditional Operations of core systems. The concept of better integration between Dev and Ops is good, but the cultural issues and most of all the risks speak against it. And the way some people interpret it is downright dangerous. Now I want to zoom in to look at the relationship between DevOps and ITIL.

Syndicate content