Use of proper CIs in INCs

An open discussion on issues related directly or primarily to the service or help desk.
Post Reply
User avatar
whitestyle
Itiler
Itiler
Posts: 8
Joined: Wed Jul 04, 2012 8:00 pm
Location: St.Petersburg, Russia

Thu Jul 05, 2012 3:10 am

Hi colleagues

Having implemented Configuration mgmt, Incident Mgmt, Change mgmt, Knowledge mgmt, Problem mgmt, one of the HOT discussions in our company is how we register requests (INC, PRB, CHG) using our Service Configuration tool.

The main question is what does CI mean (in your IT system)? Symptoms or cause or solution? How do you work with CIs? How do you analyze incidents (if you do)?

For example, your customer is calling your Service Desk asking how to get access to application X? You answer: "Access to the application X is granted through IT Service Request. Please submit a request through IT Service Portal." So the customer go and submit IT Service Request.

The question is - how do you log this call/incident? Customer called and asked simple "How to" question. The service (access to applications) is presented in your Service Request system. You have a CI for the Service Request system itself, and, you have a CI for the Application X. Should you select Service Request susyem or Application X as the CI for the incident?

Many thanks to those who can share experience and thoughts in this matter.


User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Thu Jul 05, 2012 12:46 pm

whitestyle,

I cannot understand your claim to have implemented these things if you do not know how to handle an incoming call. Implementing them involves developing procedures for just such activities.

CI means not a lot in an IT system. It means much more in an IT service.

A customer or user asking a how to question is asking for guidance/information. If you want to know how many such requests you receive, then you set up a category for this type of call. If you want to know what system or service or function each call relates to then you can set up attributes or sub-categories to hold the information.

If you want to link the call to specific CIs then you can do so. You do it if it is useful to you. You can link none, one, two or more CIs to a single call if they are relevant and recording them is useful to you.
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
User avatar
whitestyle
Itiler
Itiler
Posts: 8
Joined: Wed Jul 04, 2012 8:00 pm
Location: St.Petersburg, Russia

Fri Jul 06, 2012 8:41 am

Diarmid

Many thanks for your prompt answer.

Let me explain my concern: people in Service Desk register same incidents (see my example in the initial post) using different CIs. E.g. somebody use CIs of Business Applications (or other IT services) which the access is required to, and others use CIs of the Service Request system (which is Service-Now).

Yes, we do have a categories for the guidance/information. In both cases people use the "information" category, but different CIs.

It's clear that there are two ways to associate incidents with configuration items:
■Using the Configuration Item reference field
■Using the Affected CI's related list

The Configuration Item reference field is usually used when there is a single, primary Configuration Item that is the cause of the incident.
The Affected CI's related list can hold multiple entries. It is often used to record which configuration items have been affected by the incident, which is simply symptoms.

So, in practice, we use a CI either indicating cause of the incident or symptoms.

Let me provide you with the following example from the Service-Now wiki:
A load-balancer in a data center is no longer operational. The CI field may have the specific server which has run out of memory, and the Affected CI related list may have a list which includes the load-balancer, the data center, the servers which depend on that load-balancer, and business services which are impacted by the missing server.

Another example from the real life: suppose your customer is calling ou reporting that his personal information (phone) in Outlook is incorrect. You know that the phone field is synchronized with Active Directory. You open AD and change the phone number. The next day the new phone number is available in the Outlook. Which CI would you use? Outlook? AD?

My question is: how do people from this forum use CIs, Services, categories? What they indicate in their incidents? At my previous company we used Remedy Ticketing system and 3 fields to categorize an incident:
Category, Type, Item (CTI)

When we opened a new incident we set initial CTI (usually what a customer came with). When a resolution group closed the incident they used final CTI for the same incident. So we had both.

I wonder if the same practice is used by anybody else.

Many thanks in advance for sharing ideas.
User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Mon Jul 09, 2012 1:15 pm

whitestyle,

I hate to get pedantic (that's not true - I love being pedantic), but a CI does not cause an incident and is not a symptom of an incident.

Oh, I understand what you mean and that this is "just shorthand", but I think that looking at it like that is leading you astray in your analysis.

The reasons you need to know that a particular server has failed and how you need to deal with it are different from the reasons you need to know about other affected servers and and different again from the reason you need to know about what services are affected.

The key point I'm trying to make here is that the term "CI" is not mentioned in that last paragraph.

I come back to my first response: you record the information that will be useful to you, whether in the management and resolution of the incident or in the maintenance of valuable history or both.

So, for your second example (Outlook or AD?):

1. If you want to effect a managed change to AD (new phone number), then it will certainly be useful to record that the incident response includes a change request to the AD.

2. If you want to know how much "pain" outlook gives you over time, then it will certainly be useful to record that this incident/request was related to the use of outlook.

3. If you want to know how much "pain" is caused by the growing use of phones as computers (say), then you will certainly want to record that this was an incident/request related to the use of a phone.

4. You might also want to break this down to different user departments or different types of users in case that alerts you to some underlying problem of administration or training, for example.

The point is that the decision of what to record has to be based on what you want to achieve and has little to do with what I, or anyone else on the forum,might want to achieve from such a system.

The most important thing to get right is to make sure that all staff record incidents according to the same rules every time. If you do that first, then at least you will have some information to take forward. At the moment where some do one thing and others another thing, you have no useful records whatsoever from a management perspective.

Policy and objectives must precede procedures. Why before what.
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
User avatar
whitestyle
Itiler
Itiler
Posts: 8
Joined: Wed Jul 04, 2012 8:00 pm
Location: St.Petersburg, Russia

Tue Jul 10, 2012 6:11 am

Diarmid, I've got your point, thanks.

Performing incident trends analysis (in order to find problems) I need to have both in one INC record: business service which is down for business user and an IT service which affected this business service.

Perhaps, It would be better to discuss this question in Problem management discussion on this Forum.
Post Reply