IT Service Management Starts with?

According to Mark Schouls, the three processes that IT Service Management starts with are Change Management, Configuration Management and Release Management.

Release Management – Proper release management, which defines the process of building and releasing software, results in a greater success rate in the provisioning of software and hardware to the business, and perhaps more importantly, results in a perceived improvement in the quality of service. Bringing consistency and documented processes to software and hardware releases minimizes downtime, reduces support costs, improves resource utilization and increases confidence across all levels of management.

Configuration Management – Enacting configuration management processes gives organizations a single view of all corporate assets, including their dependencies and interrelationships. Having one federated repository as a point of reference ensures accuracy and eliminates time-consuming duplication of efforts.

Change Management – Codifying change management practices helps organizations better align IT services to business requirements. With rigid processes in place, they eliminate rogue changes, thereby reducing risk and improving user productivity. To undertake change management initiatives, businesses must first accurately assess risk, understand the impact due to any change, analyze resource requirements and make adjustments to align resources as required. At that point they can enact a formal method for approving changes.

Read more of this article on ITSMwatch here.

I would also put Incident Management in this list. IT has to exist in the organization in some form or the other right from the start. Incident Management is one of the key bridges between the IT and its users. It gives a first hand information about the issues which are being faced by the users and would be a key driver for a lot of changes that would be done to restore services.

Relationship between ITIL Processes – 1

Basic! yes! very! But don’t be surprised if there are people who have been managing these processes and still do not completely understand these relationships.

This diagram however cannot be termed complete and there is a lot that can be added to it. Will write about the process relationships in detail in the next few posts!

Fish-bone aka Cause-and-effect aka Ishikawa

I had first heard of Ishikava diagram in the Analyse phase of a Six Sigma project, and wondered about its usage in IT because at time I had learnt only about the manufacturing side of the usage. Over time, I used this diagram very effectively in technical support and service desk process improvements. The key benefit of using this diagram was to be able to identify all impacting factors and then eleminate the not so important ones to reach the vital few. (It of course required more than the Ishikawa, but it sure was the starting point). A very practical usage of this diagram/technique is visible while doing RCAs in the Problem Management Process. I am also going to use this to develop a CoD model in near future!

Click here to read through some simply written instructions of Ishikawa usage in ITIL space by Hank Marquis or click here to download the pdf.

Another good link to read through would be this from isixsigma which has an overview of the Ishikawa

When is it an incident?

Rob England in a recent post brought up the topic of distinction between a Call and Incident in the ITIL V3 Books! I then went to the book and started reading through the IM Process and did not really find a classification there, which Rob also confirmed in his update on the post here.

Now if I look at it closely, ITIL V3 book in a way achnowledges that the source of an Incident can be more than one places, e.g. Event Management, Web Interface, User Phone Call, Email technical staff, but really does not talk about where a call or an event would become an Incident (Fig 4.2 in the Service Operations book)

In my experience with two IM Processes here is how it worked

1. The User Interfacing process was Call Management (based off IBM EOPs) and it determined where the call should go and be tracked. In case of an Incident, it would trigger an incident management process for service restoration and incident resolution, for the rest, it would either end at the Service Desk as a question which was answered or a first contact resolution or would trigger a request fulfillment process. This was based on IBM EOPs, which I felt were much more comprehensive and implementable than ITIL recommended processes.

2. Everything that comes to the Service Desk is a Service Management ticket, and becomes an incident ticket only when its determined that it is an interruption to service and has an SLA impact

In both the cases, there was a many to one relationship between the calls/SM tickets to Incidents… multiple calls could be logged or multiple SM tickets could be logged for the same issue if there were multiple users calling or logging tickets themselves using a web interface, however these tickets would be associated with one single master incident which would then be published and pursued  for resolution and service restoration.

From an ITIL V3 perspective, I think one would have to leverage on the Event Management process to be able to log events and then classify them into Incidents, however leaves the How-To questions, and Service Requests aside, and does not tell how to deal with them.