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: RSnodgras
New Today: 36
New Yesterday: 55
Overall: 148158

People Online:
Visitors: 50
Members: 0
Total: 50

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 - Is this fair?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Is this fair?
Goto page 1, 2  Next
 
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion
View previous topic :: View next topic  
Author Message
Tiddles
Newbie
Newbie


Joined: Oct 16, 2013
Posts: 15

PostPosted: Thu Oct 17, 2013 1:45 pm    Post subject: Is this fair? Reply with quote

Please pardon my question as it could be quite naiive. We're getting an ITIL system put in soon but from what I can tell it's only a half baked system with very limited functionality to start with. Overtime the functionality will improve and there will be functionality for things like change management, knowledgebase etc. Suffice to say change management in relation to the new system has been pretty much non-existent but we're getting it anyway like it or not.

The system will initially be configured to have incident and problem management. From my understanding the way it works is that a user reports an incident and there is an SLA in place that governs when the incident must get resolved. Unfortunately not all incidents can be resolved easily by the first line support with many of these turning into problems to be dealt with by the problem team. The problem here (ha! ha!) is that the SLA for the incident continues to click on even though an associated problem record has now been opened for the incident. Now in a worst case scenario a fix for the problem might be only be inplemented as a result of the product release cycle of a 3rd party vendor like Microsoft. This could be anything up to 6 months maybe more especially if you have a policy of not immediately installing cumulative updates and patches to avoid bug issues. Is this fair for the problem team as they will likely have SLA breaches galore? Have I missed something? Could it be that when an incident graduates to a problem a new set of SLAs is supposed to click in? How do you fairly account for 3rd party release cycles. Obviously when a fix is dependent on a 3rd party fix then it's completely beyond your control. Are you supposed to just wear it on the chin?: "Yeah most of my incidents/problems are breached but it's Microsoft's fault?" Anyway I would be grateful if someone could shed some light on this? and apologies if this is a really dumb question as I'm a complete novice to ITIL. Perhaps most of you have thick skins and don't care too much about breaches.
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Thu Oct 17, 2013 6:00 pm    Post subject: Reply with quote

Tiddles....

Hmm.

Actually, to be honest.. that is what is SUPPOSE to happen... in theory

However, let me explain

The Incident is there for the service being impacted... If the service is restored by hook or crook - then the incident should be closed as the service is restored - which was the point of the incident

A problem record is raised when warranted and is done in PARALLEL to the incident process. A problem record is NOT related to the incident and can still be live even if the Incidnet is closed

The SLA is Service Level Agreement which is and should ONLY be tied to the Incident processing.

Problem mgmt should not have any SLA linkage as there is no determination when the unknown root cause is found

I also read this as the process is misusing the Incident / Problem relationship

If the iIncident cant be resolve by the first level team, then it is escalated as an Incident to the next level up and up as required - as the Serivce restoral is the goal

The Problem process should be involved ONLY if the cause is UNKNOWN and needs to be identified so a solution can be created to solve the cause - regardless of how long it takes

If the incident CANT be restored until the problem team finds the solution, then that is the breaks, the SLA is breached.... but it is breached only for that item

Remember, the Calculation for the SLA is monthly not daily

A breach on the 2nd of the month when compared to the entire month of non breaches loses its strength - of course depending on how large
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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


Joined: Oct 16, 2013
Posts: 15

PostPosted: Thu Oct 17, 2013 6:47 pm    Post subject: Is this fair? Reply with quote

Ok I have done a little bit of ITIL digging and the consensus seems to be that problem resolution is not timed unlike Incident resolution. It also appears just because an Incident is complex (required lots of changes, testing etc) or simply takes a long time to resolve (eg. waiting for a 3rd party release cycle) does not mean it is automatically escalated to a problem. So I'm guessing you have just grin and bear it. My sense is if something is escalated to a problem then at least from a perception perspective it doesn quite look as bad beause of the universal acknowlegdegment that problems are not subject to SLAs. So isn't there an incentive to escalate to a problem where possible. Am I reading this right? Why doesn't the ITIL documentation provide better guidance for things like this? All it seems to be is a bunch of principles and little else.
Back to top
View user's profile
Tiddles
Newbie
Newbie


Joined: Oct 16, 2013
Posts: 15

PostPosted: Thu Oct 17, 2013 6:59 pm    Post subject: Reply with quote

Thanks John for that comprehensive explanation. Unfortunately I didn't see it before I posted my follow up. Anyway all my fears have been realised. As you probably realised I'm not from 1st level support. I'm further down the chain and expect only to be hit with incidents which will almost always break SLAs because of their nature. Doesn't do much for morale to see a page filled with red broken SLAs. Might be time to look for a new job! I have too much pride for this caper! Very Happy
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Thu Oct 17, 2013 10:57 pm    Post subject: Reply with quote

ITIL is just a set of advice

The crux of the issue is that your org has not defined their processes properly and documented such
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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


Joined: Oct 16, 2013
Posts: 15

PostPosted: Fri Oct 18, 2013 6:49 am    Post subject: Reply with quote

I must be missing your point because it now seems you are contradicting yourself. In your first response it all seemed cut and dry. An incident remains an incident until it is resolved. There is no fairness or equity to it or mitigating circumstances. If you're stuck with more difficult incidents or there is hefty release management or change management processes associated with them then that's bad luck and you just wear it. Are you implying there is some kind of mitigating 'get out' clause by amending your process. You seem to suggesting that different types of incidents could be implemented such as Incident requiring no change management, incidents requiring release management, incident requiring 3rd party action, etc all covered by different SLAs. Is this what you mean or are you inferring that organisations need to take good hard look at themselves and maybe go light in release management, change management, configuration management to some degree in order to achieve faster resolution times. I have to say from my reading of ITIL so far there seems to be a disconnect between the desire to restore services as soon as possible whilst still maintaining good practises in terms of release management. Our system is so critical to our organisation that I can't see them ever streamlining the processes that are already in place.
Back to top
View user's profile
Tiddles
Newbie
Newbie


Joined: Oct 16, 2013
Posts: 15

PostPosted: Fri Oct 18, 2013 12:04 pm    Post subject: Reply with quote

I think I'm finally getting it. I am trying to turn an incident into some kind of pseudo change request incident which obviously isn't the way to do things. Instead there needs be some kind of process that puts an incident into either a pending state (if there is no known workaround) or it is closed if there is a workaround. Assuming the former there is then the option for RFC and/or problem management. I'm guessing in terms of SLAs there must be some kind of gentlemen's agreement that if an RFC or PM is involved then you look the other way or perhaps it is even formally specified in the SLA. Not sure if this is how it works in the real world but this seems plausible to me and it addresses all my original concerns. ll my original concerns.
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Fri Oct 18, 2013 5:57 pm    Post subject: Reply with quote

Tiddles

ITIL is in itself contradictatory. Hence my response so

First, each process has its requirements, inputs, outputs, controls, etc

IM is considered with the service being delivered to the customer in accordance with the agreed level of service being delivered to the customer. And has a set of actions to make sure the customer's service is being delivered as agreed.

So IM process is linked to the Service Level Agreement and the purpose or goal is to make sure the service is as it is agreed. Nothing more nothing less

Change Mgmt (CM) is a control process. It authorizes work to be done. You can have a CM for projects and developments - which has a different scope / purpose than an Operational one. An operational one's sole purpose is to Protect Production from the Idiots in IT.

Release (RM) is an action process. It defines how something is installed in it. Now, RM's scope can include application development, system development, etc. .depending on the requirements. RM requires some control.. but not at the level of CM. As part of RM, there may requirements filtered down from CM - ie proof of testing, deployment tests, etc etc. RM has to define and control those - not necessarily do them

PM does two distinct roles - Reactive and Proactive. Proactive is easy. ProPM looks at the incident history, CI history, equipment history and checks to see if there are areas where faults and failures can be prevented. Single point of failures and faulty / unreliable h/w. s/w etc should be found, identified, and removed where agreed and possible.

RePM is different. RePM waits for IM & the SD to provide it potential work to solve. So a incident that occurs every 39.75 hour for 3 months in a row.. is a trend that needs to be looked at? While IM restores the service once the 39.75 marker has been hit. RePM tries to determine WHY it is happening and trying to come up with a solution that has to be tested in line with RM and if successful deployed to production in line with CM.

Config Mgmt (CfM) is a control and admin process. The IT CIs - s/w, h/w etc - needs to be identified, mapped, records and tracked against IM & PM activities so that future IM and PM activites can look at the history of the said CI

Capacity is straight forward
Availability is merely calculatiing the relative mathematicial availability of the service against the contracts the services are related to and keeping up
Continuity is DR .. keeping a service alive after a major catastrophe

Now back to your issue.

If you are 3rd or 4th Line IM Support, I would look at the SLAs and the response times for the lower levels to see if there is disconnect.

For example - is 2nd and 3rd and 4th ONLY involved when there is a SLA Breach or what
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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


Joined: Oct 16, 2013
Posts: 15

PostPosted: Fri Oct 18, 2013 9:37 pm    Post subject: Reply with quote

Thanks again John. It's amazing what you can learn in very a short time. It turns out today I discovered that the SLA clock in our system will stop when an incident goes into a pending state, eg waiting for a customer , a problem record is opened or change request is opened. So all my concerns were unfounded. Exactly why it took them 4 months to arrive at this decision is beyond me. It seems elementary to me and what I've moaning about the whole time. It has the hallmarks of a system implementation where everything is made up as you go along. Today I also had my first real look at the system and it became obvious how clunky the whole thing is. It seems like the whole thing is just a dozen data buckets which you then have to manually link together but with no true integration. For example, if you create an incident and then want a problem record, you create the problem in a separate screen, go back to the incident window, search for the problem you just created and link it. But from the incident screen you can't just click on the associated problem and expect it to be opened for edit. To do that you have search for it again and open it separately. The whole system is like this. There are tabs galore so to find anything like journal notes, tasks etc you end up having to look under every rock to see if anything is there. So makes you hunger for a spread sheet where all relevant information is available at a glance or a click. Man what a mess!
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Sat Oct 19, 2013 6:21 pm    Post subject: Reply with quote

remedy? the tool?
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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


Joined: Oct 16, 2013
Posts: 15

PostPosted: Sun Oct 20, 2013 3:50 pm    Post subject: Reply with quote

As usual I dig around more and find my question has already been debated ad nauseum. It seems ITIL hardliners stick to their guns by insisting incidents stay open with clock ticking till resolved whereas those in the field of battle appear to favour clock stopping in certain circumstances.
Back to top
View user's profile
Tiddles
Newbie
Newbie


Joined: Oct 16, 2013
Posts: 15

PostPosted: Sun Oct 20, 2013 4:47 pm    Post subject: Reply with quote

Remedy? We'll I'm going to try and put a positive spin on this and say the system is a diamond in the rough and things will get better overtime. The tool? It's called Cherwell. Not sure how this product stacks up against other systems but like I said maybe it will get better with time. My understanding is that it is highly configurable so may be the clunkiness can be configured out of it as more effort is expended on it. Incidentally after more reading of the ITIL framework I can't locate the section where it deals with SLA clock stopping when pendings are in place for change requests, problem solving processes. Is this another case of ITIL again not being prescriptive. I'm guessing everyone does their own thing to suit their own circumstances but I was wondering whether clock stopping was the normal practise for service desks. Afterall how you can you possibly predict how long a problem solving process is going to take etc. Seems obvious to me. Why would do it any way?
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Mon Oct 21, 2013 4:03 am    Post subject: Reply with quote

Tiddles...

first.. I know it is not your name because we LI'd if I recall

I picture either a little incontinent cat or a small Pekinese dog or other barking rat at the keyboard.. I don't know why.....

First, ITIL is not a standard so tell the so called Hardliners to cease.

ITIL is a set of advice. and guideance

That said, in regards to incidents, you have to look at the picture from a statistical, process and tracking point of view

1 - The Incident is opened at a specific Date & Time
2 - The incident is passed to one or more internal groups
3 - it is escalated to external vendor
4 - It is escalated customer for more information to help diagnose issue to restore service
5 - it is closed as the service has been restored

so in that 5 steps you can have several different clocks

1st one the life of the ticket
Open DTG Close DTG difference. This is an absolute number. If it is open for 100 days...It is open for 100 days
2nd working life time.
The ticket is dealt with within the 1st hour by the 1st level support
2 hours w/in to the 2nd level and
4 hours to the 3rd level.
The SLA and the classification has this as milestones. .....
The ticket is put in a holding pattern while you ask the customer for more information or confirmation of something
The working life of the ticket is on HOLD because you are waiting for some one else to do something. You track HOW Long it is in pending and don't let it languish
Same applies to sending the issue to an external vendor .. you have to wait

So you are tracking several different time calculations to report on

Now, if your Mgmt team is smart, the calculation of tickets that are escalated to external vendors are identified in the contract explicitly so at the end of the month, you can separate these in the monthly calculations
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Mon Oct 21, 2013 4:05 am    Post subject: Reply with quote

Tiddles

PM should never have an SLA as there is no specific time based goal .. unlike Incident

Nor should change be SLA'd
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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


Joined: Oct 16, 2013
Posts: 15

PostPosted: Mon Oct 21, 2013 5:03 am    Post subject: Reply with quote

No, more like a shell shocked world war 1 soldier who has been gassed and has trench foot. I work for a very small organisation where we have limited resources and essentially we cover all bases from support to development. When you say problem manager, service manager, change manager, etc we don't even have cut board cut outs for those guys. Nor will we ever. All this red tape and processes is another layer of overhead the internal IT area has to deal with. Anyway thanks for that breakdown of time. Just hope our system can easily do such a break down because that kind of information would be very useful. Otherwise times will be skewed and give the wrong picture. It answers my original question about fairness. Now there is fairness. Just had a horrible thought, maybe the system can't do it, and doing it manually will be another one of my jobs. Yikes!
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion All times are GMT + 10 Hours
Goto page 1, 2  Next
Page 1 of 2

 
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.