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!
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!
Another good link to read through would be this from isixsigma which has an overview of the Ishikawa
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.