Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: LKuester
New Today: 37
New Yesterday: 64
Overall: 148290

People Online:
Visitors: 45
Members: 1
Total: 46 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - who gets problem, incident or change ticket here?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

who gets problem, incident or change ticket here?

 
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management
View previous topic :: View next topic  
Author Message
rockon
Newbie
Newbie


Joined: Feb 22, 2007
Posts: 13

PostPosted: Wed Sep 12, 2007 4:08 am    Post subject: who gets problem, incident or change ticket here? Reply with quote

Hi,
We just started using ITIL base ticketing tool but our organization has no proper Incident or Problem management yet. That is not something I have control over but I have questions need your input to make sure we are doing it properly. Wink Our situation is sometimes we have to block a user's internet access without the user's knowledge and it involves many areas' coordination, and we need to have a good process:

1) Our Network services managed all user connections, so when a piece of hardware they monitor is not reachable, they will open an Incident ticket while investigating the issue - often before any of the users call our Helpdesk. Shouldn't they open a Problem ticket here directly since they are investigating root cause and the hardware will affect multiple users.

2) If the hardware is malfunctioning, then they will open a Problem ticket and then a Change ticket to get it replaced.

3) But very often, a hardware not reachable is caused by one single user (this is a know issue with the switches we have that can't handle certain traffic type but no budget to replace them yet), so Network Services will disable the port to bring the switch back working. They often open a Problem/Change ticket for it because they are modifying the configuration of a CI and they forward the Change ticket to the area support person to identify the user and check the client PC. They keep the incident ticket.

4) Network Services thinks they should keep the original Incident ticket and forward the Change or Problem to the area support person but in my opinion, they should keep the Problem/Change and open or forward the Incident ticket to area person, so area support person and Network Services have tickets they each own and if the user calls the helpdesk, then the central helpdesk can look up history from the ticket to follow up with the user.

I hope it is clear. Please re-write this process if you see fit. Thanks in advance.
Back to top
View user's profile
JoePearson
Senior Itiler


Joined: Oct 13, 2006
Posts: 116
Location: South Africa

PostPosted: Wed Sep 12, 2007 5:37 am    Post subject: Reply with quote

Hmm. I'm going to reserve judgement on whether a hardware failure detected by IT staff is a problem, or something else. I don't think ITIL is very precise in this area.

At least, when monitoring detects that a device can't be reached, you have an event, not necessarily a problem.

My thinking here is that problem management activities are significant, team-based activities, and there is room (just not spelled out in ITIL) for "incidents" raised by IT staff - or automation - and following a similar process to incident mgt. There's an idea (see for example Fig 5.4 in ITIL V2 Service Support) that the normal flow is Incident -> Problem -> Known Error -> RFC. But RFCs can be raised directly from Incidents - a Problem is not a necessary step, as the rest of that chapter shows.

The main focus of your question is really about workflow management of the tasks related to the incident, problem or change. Many tools allow multiple tasks to be created under one incident, problem or change record. In this scenario, the tasks are forwarded to the relevant areas - the original record is not routed anywhere. But if your tool doesn't allow this then you'll have to think again. (I am not actually answering your question, just giving you more to think about.)

- The incident stays open until it is resolved. But it only needs to be routed if there is work to do on investigation, diagnosis, determining the resolution, or closing it.
- If an RFC is raised, the incident should remain with the original owner (whether this should be "Network Services" or a service desk function is another question), and the change should be forwarded to the team who will implement it (after following your change authorisation processes of course).
- If the resolution requires multiple people to do changes, then raise multiple change records - or one record with a set of attached tasks.

I am not sure I understand your item 4. If a team "keeps" the problem/change and forwards an incident - what is the incident for? It sounds more like a change task or a work request.

Joe
Back to top
View user's profile Visit poster's website
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3318
Location: London, UK

PostPosted: Thu Sep 13, 2007 1:02 am    Post subject: Reply with quote

My first question is


Do you have a Service Desk that is the interface and communciation point of contact between the customers (users) and the IT environment ?

According to ITIL, the Service Desk owns all incidents regardless of what group is trying to solve / resolve the incident.

In the example, the network group is acting as the SD by 1 ) recognize an incident (ITIL), create a ticket and assign it to the appropriate Resolver group.

Therefore, they 'own' the incident ticket and they and only they should complete the incident once the resolver group has resolved (close) the incident.

The network group is acting as an arm of the Service Desk (Role)
If so, the Service Desk
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
BigYounks
Newbie
Newbie


Joined: Jul 24, 2007
Posts: 3

PostPosted: Thu Sep 13, 2007 1:53 am    Post subject: Reply with quote

I think the first step is for your department to define exactly what a "problem" is. For instance, in my environment, we have set up 3 distict rules which govern wether something is a candidate for Problem Managment.
1) The event at hand must have been abated via a temporary fix or work around.
2) There must NOT be a known permanent fix prior to escalating to the problem manager.
3) There must have been an open incident ticket on the event prior to escalation to the problem manager.

In your example, the network engineers know there is an issue with their appliance...but they still need to submit an incident so it's in the system. If they bring it down, users will begin calling and you can link calls to one incident (believe me, your help desk will thank you for the heads up.) If the network engineers KNOW the appliance is faulty and not simply something wrong with the IOS, then we have a known error and no root cause analysis needs to be done (unless you plan on putting it back into the infrastructure.) A Change is submitted, the hardware replaced, calls associated with the ticket are verified to be resolved, and the incident closed.

Hope this helped,

Dave Younker
Problem Manager, Maritz Inc.
dave.younker@maritz.com
Back to top
View user's profile
jpgilles
Senior Itiler


Joined: Mar 29, 2007
Posts: 123
Location: FRance

PostPosted: Thu Sep 13, 2007 10:18 pm    Post subject: Re: who gets problem, incident or change ticket here? Reply with quote

rockon wrote:
1) Our Network services managed all user connections, so when a piece of hardware they monitor is not reachable, they will open an Incident ticket while investigating the issue - often before any of the users call our Helpdesk. Shouldn't they open a Problem ticket here directly since they are investigating root cause and the hardware will affect multiple users.

This is by definition an INCIDENT: an event that affects or may affect the service.


Quote:

2) If the hardware is malfunctioning, then they will open a Problem ticket and then a Change ticket to get it replaced.

this (hardware malfunctionning) can be considered as a PROBLEM

Quote:

3) But very often, a hardware not reachable is caused by one single user (this is a know issue with the switches we have that can't handle certain traffic type but no budget to replace them yet)....


This is also a PROBLEM ....

Quote:

, so Network Services will disable the port to bring the switch back working.)....

This si a WORKAROUND, so the problem just above is now a KNOWN ERROR.

Quote:

They often open a Problem/Change ticket for it because they are modifying the configuration of a CI and they forward the Change ticket to the area support person to identify the user and check the client PC. They keep the incident ticket..)....

I am not sure I would consider it a change unless the STATUS of ports IS part of your CMDB (and I would definitely not include this in a CMDB)

Quote:

4) Network Services thinks they should keep the original Incident ticket and forward the Change or Problem to the area support person but in my opinion, they should keep the Problem/Change and open or forward the Incident ticket to area person, so area support person and Network Services have tickets they each own and if the user calls the helpdesk, then the central helpdesk can look up history from the ticket to follow up with the user. ..)....

to me, you should open an incident for every single occurence (*). Once the service is back on, the incident is closed.
The problem (switch locked when traffic type X passes through..) is open once and will stay open until you implement the change that will resolve it: either change the software, the hardware or whatever the solution is...
and it stays open in status "known error"

(*) it is very important: the number of incidents may finally make somebody take the decision to put the money in to solve the issue....

This is my vision, hope it can help you.

best regards

JP
_________________
JP Gilles
Back to top
View user's profile Send e-mail
rockon
Newbie
Newbie


Joined: Feb 22, 2007
Posts: 13

PostPosted: Fri Sep 14, 2007 1:58 am    Post subject: Reply with quote

Thank you all for the input. They are all very helpful. I happened to be at a ITIL seminar yesterday and the consultant thinks that since Network Services is opening a ticket on the network component level, it should be a Problem ticket but the consensus here is an Incident, then a Problem. After reading your posts, I think Incident is correct since what if it is just a short power failure and the switch recovers in a few minutes or someone go in the wiring closet and trip the power cord.. the IT infrastructure has no issue here.


I also would like to ask your opinions:

1) Do you think changing a switch port status from Enable to Disable constitute a Change ticket or just a Incident here? We also have requests to Activate/deactivate an ethernet jack depending upon the occupancy. We don't have CMDB yet, so not sure if these type of incident and request are too small to be a Change.

2) Since our Service Desk software does not automatically notify our helpdesk staff when an incident is open outside of their area, do you think Network Services should keep the parent Incident ticket and open the a child ticket for our helpdesk to investigate who the user is and able to notify user the issue before they call?

Thank you again.
Back to top
View user's profile
JoePearson
Senior Itiler


Joined: Oct 13, 2006
Posts: 116
Location: South Africa

PostPosted: Thu Sep 20, 2007 12:50 am    Post subject: Reply with quote

rockon wrote:
I also would like to ask your opinions:

1) Do you think changing a switch port status from Enable to Disable constitute a Change ticket or just a Incident here? We also have requests to Activate/deactivate an ethernet jack depending upon the occupancy. We don't have CMDB yet, so not sure if these type of incident and request are too small to be a Change.


If the status change was uncontrolled then it's an Incident (and/or an Event). If it was intentional - which is what I think you mean - how can you treat it as an incident?

I would say it's a Change in theory, but provided you have controls such as making sure there is no active device on the port / jack then you could treat it as a Standard Change (known, low impact). This would follow a simplified change process (in ITIL 3 terms, it might be covered under IT Operations Management - not clear on that yet).

rockon wrote:
2) Since our Service Desk software does not automatically notify our helpdesk staff when an incident is open outside of their area, do you think Network Services should keep the parent Incident ticket and open the a child ticket for our helpdesk to investigate who the user is and able to notify user the issue before they call?


This sounds like a good plan, but it would be better if there was a clear separation between ownership of incidents and workflow of tasks. Did you see my question in my earlier reply?
JoePearson wrote:
I am not sure I understand your item 4. If a team "keeps" the problem/change and forwards an incident - what is the incident for? It sounds more like a change task or a work request.

If you manage work requests via child tickets that would be better than opening new incidnet/problem tickets.
Back to top
View user's profile Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.