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
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.
Posted: Tue Jan 13, 2009 5:49 am Post subject: Initiating Problem Tickets
Would there be any reason a Service Desk or Incident Analyst would create a Problem ticket or is that left up to the Problem Coordinator? How does the relationship between the Service Desk Manager and Problem Coordinator/Manager work - in other words - what is the Service Desk believes there is a problem and it needs to be logged. Do they communicate their beliefs to the Service Manager, Problem Coordinator or is it really up to the Problem Mgmt team to determine?
There are some logical relationships between Incident and Problem Management functions but fundamentally you've hit the nail in terms of what ITIL is all about:
ITIL is a framework from which you pick the bits that suit you best. As it's unlikely your department is structured (in terms of people) exactly around ITIL you should then look to take on the parts that are achievable for you, given the shape of your department. Not every detail of ITIL is achievable for any given organisation.
So, although you should leave problem management to your Problem Coordinator, the way you choose to allow the Service Desk to flag up potential problems is up to you. The exact procedure of this is something only you can determine as we here on the forum do not know what it's like in your organisation. Just make it crystal clear, i.e. if more than five incidents about viruses in the same day - raise a problem ticket. That sort of thing.
Just remember some of the ground rules:
Incident Management and Problem Management cannot be run by the same person or group. Often have a political conflict of interest, i.e. IM like to show how many tickets they've managed to process/manage/fix etc, whilst Problem Management looks to reduce occurrence of Incidents either in tackling intra-week problems (e.g. a virus outbreak) or long term via analysis of incident trending etc.
Incidents do not become problems (they are a ticket attributed to a problem log/ticket).
Incident Management/Service Desk can raise a problem, to be reviewed by the Problem Coordinator, but they do not decide that it IS a problem.
The service desk must never feel afraid/unwelcome to raise a problem ticket as it's better to be safer than sorry.
Hope this helps,
UJ _________________ Did I just say that out loud?
Is this really a legitimate answer? It certainly isn't a professional one.
If you want people on these forums they have to be comfortable that they can ask a question, no matter how basic it may seem, without fear being nasty replies like this.
Joined: Sep 16, 2006 Posts: 3110 Location: London, UK
Posted: Sat Feb 14, 2009 1:45 am Post subject:
Entivo
When some one asks a really basic question like ' what is ITIL' or other real basic questions that can be found really easy - a simple google search etc can provide the answer, they, in my not so humble opinion, get what they deserve
I dont reward laziness by providing the answers; I also note that several others here feel the same way
If someone is interested in a topic - regardless of the topic or subject, a few searches on thenet can provide useful information
If when some one posts, they clearly have not done any searches... why should the forum reward them with their laziness.
The answer that dchell was seeking found in the Service Support manual under Incident Management as well as in Problem Management
or in the V3 books under the relevant sections.
the answer about segregation of duties for IM and PM are also in any training manual as this is a key division of labor for IM & PM
In addition, reading other threads about PM & IM would also provide the question
A lot of information about ITIL Best practices, courses, exams, certification, what is covered etc etc are available at the 'authorized sites for the relevant subject matter' _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
I certainly don't want to enter into a row or debate about this, however please bear in mind a few things.
1. Not everyone has access to the blue and red books. My boss keeps them locked away (heaven forbid I might want to actually learn something that he already knows).
2. Access to ITIL documentation isn't readily available (for free anyway) on the WWW. True, there are lots of ITIl oriented sites, but very few want to give you something for nothing these days.
3. What the guy is asking is how the dynamic works between IM and PM. This is not clearly explained in the ITIL books and is open to interpretation (after all, it IS adopt and adapt). I think the guy just wanted to know what others are doing in this area. No harm in that.
4. Someone else managed to post a decent reply, rather than just "RTFM". You could have written something a bit more reserved if you thought he was wasting your time. I guess it's about tolerance at the end of the day. I just thought "RTFM" was a bit harsh on the guy.
I guess the guy could go and buy his own book(s) and come back here a bit more informed. The thing is that sometimes we all ask a dumb question and shouldn't be lambasted for it.
I have loads of questions rolling around my head when it comes to PM but I dare not ask them on here in case someone makes me look like a right t1t.
Remember the person in the car behind you when you were learnign to drive, beeping his horn? You have become that man. (cr4p analogy I know but it's the best I can do at this time on a monday morning!).
Joined: Sep 16, 2006 Posts: 3110 Location: London, UK
Posted: Mon Feb 16, 2009 9:25 pm Post subject:
Entivo
Yes, I do see your point and in some respects I do agree that shootign from the hip w/RTFM was a bit short.
However, if he had said that he had taken the time to look at a) his course material if he took foundation b) the Blue & Red books and stated that he had an issue with the book *theory8 and the real world *practice*
I probably would not have shot from the hip _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: May 25, 2008 Posts: 413 Location: Sydney, Australia
Posted: Tue Feb 17, 2009 8:56 am Post subject:
entivo wrote:
I have loads of questions rolling around my head when it comes to PM but I dare not ask them on here in case someone makes me look like a right t1t.
So long as you don't look like a left t1t _________________ DYbeach
ITIL V3 Release, Control & Validation,
ITIL V3 Operation SUpport & Analysis
PMI CAPM (R)
"In times of universal deceit, telling the truth will be a revolutionary act." George Orwell
Joined: Sep 16, 2006 Posts: 3110 Location: London, UK
Posted: Tue Feb 17, 2009 6:24 pm Post subject:
entivo,
Ask the questions. My own recommendation - is when you ask the questions - remember the fact that you should explain that you have done due diligence or work...
Example
What is Problem management and how I can be a problem mgr
gets you the GoG responses
I am currently doign system admin for unix for the past 3 years. i like it but as i have done foundation course, i got an interest in doing PM roles for unix
this shows all that you have brain but are stuck _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Oct 07, 2007 Posts: 441 Location: Jakarta, INA
Posted: Wed Feb 18, 2009 10:55 am Post subject: Re: Initiating Problem Tickets
Now all is going off-topic
Back to the main question (if dchell is still around)
Quote:
Would there be any reason a Service Desk or Incident Analyst would create a Problem ticket or is that left up to the Problem Coordinator? How does the relationship between the Service Desk Manager and Problem Coordinator/Manager work - in other words - what is the Service Desk believes there is a problem and it needs to be logged. Do they communicate their beliefs to the Service Manager, Problem Coordinator or is it really up to the Problem Mgmt team to determine?
The answer first thing would probably be "it depends".
But there are two ways to raise a problem ticket from incident management/service desk, as far as I know:
1. If SD/IM finds that the incident is recurring and repeatable
2. If SD/IM couldn't find the resolution of an incident in the known error db, plus they cannot solve the incident within their capability, even after the full IM path has been done (escalated to level 2 and/or 3 depending on how you set your IM process)
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Thu Feb 19, 2009 1:20 am Post subject: Re: Initiating Problem Tickets
asrilrm wrote:
2. If SD/IM couldn't find the resolution of an incident in the known error db, plus they cannot solve the incident within their capability, even after the full IM path has been done (escalated to level 2 and/or 3 depending on how you set your IM process)
This is an interesting point. I think we can refine it a little:
An incident is resolved when the service, or level of service is restored or when the threat to that service is removed. At this point it is irrelevant (although of considerable future importance) whether we understand what caused the incident.
Now, if we do not understand the cause, we have to make a judgement call: do we think it was a unique event, or do we thing that it may happen again; if it does happen again, what will be the cost? From this we decide whether to raise a problem. This is why it is often thought that problems are raised when an incident has repeated, because that is when we can be more confident that there is something needing fixed.
However, if our support staff have failed to resolve the incident, that is a different situation. The service is still down, or still going slow, or still threatening to collapse, or whatever.
Now what is required is continuing escalation of the incident, quite possibly using some of the techniques (and, in some cases, staff) associated with problem investigation and resolution activities and possibly calling on third party expertise. But it is still an incident from the management perspective. The priority is still restoration, unless a business decision is made to live with the situation, because the costs are disproportionate. This, then, would be the "workaround" and the incident could be closed. _________________ "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
I am on the Problem Manager Practitioner course next week, so hopefully I will get the chance to discuss the whole thing with others.
What I struggle with at the moment is how to actually go about establishing the root cause of a problem, as in what tools are available to me etc. How far I should be going as the problem manager and how much I should be leaving to others.
Also, where the tech staff are separate from my staff (service management) how do I influence how much time and effort the tech staff spend looking at problems as opposed to business as usual stuff (i.e. project work, patches, upgrades, migrations etc etc).
I fairly comfortable with the PM process, it's just how to go about making it happen.
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
