I would have written a summary myself, however I think this summarizes the document well!
In continuation with some definitions of Data Analytics and Analysis here, the following graphic came up after a small discussion of how and when the Analysis and Analytics components play a role.
Will write more about various methodologies and tools as I learn more!
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.
San Jose based IT company ZL Technologies, recently filed a case against Gartner challenging the very popular Gartner “Magic Quadrant”.
As per ZL Technologies website,
ZL Technologies, a San Jose-based IT company specializing in cutting-edge enterprise software solutions for e-mail and file archiving, is challenging Gartner Group and the legitimacy of Gartner’s “Magic Quadrant.” In a complaint filed on May 29, 2009, ZL claims that Gartner’s use of their proprietary “Magic Quadrant” is misleading and favors large vendors with large sales and marketing budgets over smaller innovators such as ZL that have developed higher performing products. The complaint alleges: defamation; trade libel; false advertising; unfair competition; and negligent interference with prospective economic advantage.
Read more here.
Read some detailed points of view and analysis of this situation here on the ZDnet blog.