service improvement

IT service build is not a factory

There is a widespread idea in IT that IT is a factory, repeatably turning out code which can be treated as identical products on some kind of optimisable production line. This is only true for parts of our IT world: e.g. standard requests, standard incidents and changes, bug fixes. It's usually not true of building IT services.

Improve first

Improve first. Measure, plan, manage, define and standardise later.

The Tipu Framework

ImageTipu is an approach to planning and executing service improvement. Find out more at http://www.basicsm.com/tipu.

Tipu has its own Framework to allow us to organise our thinking and have something to compare other frameworks to. All the ITSM philosophers who follow this blog will be interested in it: the Framework attempts to be more complete than ITIL or COBIT. It is also intended to be a generalised Service Management framework not an ITSM one. There is no IT-specific content, in line with my new book Basic Service Management. Your feedback is of course welcomed. See what you can do with it - it is Creative Commons licensed.

Great paper on failure of complex systems

It is not often you read something that completely changes the way you look at IT. This paper How Complex Systems Fail rocked me. Reading this made me completely rethink ITSM, especially Root Cause Analysis, Major Incident Reviews, and Change Management.

Excellent customer service: weapon or burden?

How often is excellent customer service a competitive weapon and how often is it just an unnecessary cost burden on the organisation?

Where does continual service improvement end? An important ITIL question

Service Management is always on about Continual Service Improvement, as if this was a holy grail and an assumed permanent state of change. What seems inadequately discussed is where does it end? Do we improve forever? Surely not. We must encounter diminishing returns until eventually we are just gilding the lily. Is the "to-be" always different from the "as-is"? or rather is it always sufficiently different to justify doing something about it?

Syndicate content