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

THE ITIL BOOKS

The five ITIL books can be obtained directly from the publisher's website:
HERE

Or as downloadable PDFs: HERE

Current Membership

Latest: ShellaKnat
New Today: 41
New Yesterday: 95
Overall: 217045

People Online:
Visitors: 141
Members: 3
Total: 144 .

Login
Nickname

Password

Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

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.


Search



Languages
Select Interface Language:


Advertising
Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - New Here - Complex situation which I need some help with
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

New Here - Complex situation which I need some help with

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


Joined: May 19, 2016
Posts: 2

PostPosted: Fri May 20, 2016 11:50 am    Post subject: New Here - Complex situation which I need some help with Reply with quote

Hi all

I am new to this whole process of ITIL and trying to understand the whole process. We have an Incident Manager and a Problem Manager who are both fairly new to the business so don't fully understand the business and it's customers but both have lots of ITIL experience. PM has been here for 6 months and was brought in because the company decided to go the ITIL route. I am the application support TL and as such my department has taken on the task of sorting out and getting Problem Management up and running in the organisation. Brief background. We are basically a company owned by a number or organisations within the same industry, so we provide the software and hosting capabilities to >20 organisations. Kind of like the IT arm for >20 different companies. In the past anyone of these would raise a ticket with Service Desk who consisted of 1st and 2nd level support to provide application level support for the funds. Often it would involved data issues or debugging into the code to find what was actually the cause of the issue. This indepth stuff would be the task for my team and as such we provided 3rd level support. The team consists of developers and they would do indepth analysis to find out why something was wrong. Often it's because during coding there is a certain scenario that is missed (it's a complex software system), but to find why the record/s were incorrect often involved days of debugging and half the time actually finding the root cause to isolate what the specific scenario was. We also often have situations where the fault is only replicable on a certain customers database and no where else. This has been the way of things being done for the last 15 years.
With the introduction 5 months ago of ITIL, not only is my team responsible for 3rd level Incident support but we also now have to do Problem Management. The new PM says that in all cases there are 3 resolutions for an Incident,
1 the incident is fixed,
2 there is a workaround provided in which case a Problem ticket can be raised to investigate root cause and possibly fix (usually a software coding change)
3 we accept risk because we can't find the issue within SLA on the incident, close the incident and raise a problem ticket to investigate if we do need to make a coding change.

All good, except most of our incidents are those funny cases where to actually find what is wrong would involve indepth debugging and analysis which might lead to a code change being needed. An example is where one of our companies(healthcare funds) have memberships. Something is wrong on a portion of those memberships. It could be 1 member, it could be 5 etc. Incident gets logged detailing the error. Goes through 1st and 2nd level who investigate all the data and can find nothing wrong. escalated to us as 3rd level. To actually find what is wrong we need to do indepth debugging as we can't isolate the cause easily. We can't replicate the issue as we don't know the exact details of what is causing the issue, so we often need to use the funds Data and do debugging down deep into the code to isolate the exact set of scenarios that are involved in causing this issue. 9 times out of 10 it turns out to be a specific scenario that to fix would require a code change. To determine this though, we would have really find root cause. These are done though on the incident and subject to SLA's which mean that generally we blow SLA's all the time which makes our funds mad. PM is saying that we should be creating problem tickets when we decide we need to do indepth analysis, but this would mean we are just making the issue larger because we end up with huge amounts of Problem tickets over 1 incident that may only affect a small amount of data which is not what problem management is about. The catch 22 is that the fund want an answer and they need to be able to fix it or get a workaround. At least 60% of our Incidents that come through are like this because our software system is really complex with a really large amount of rules and scenarios and one little data issue can cause an issue for the fund.

So sorry for the long winded post, but you need to have history to understand it's not clear cut by any means. I am looking for a bit of advice on this scenario where there is no answer to an incident unless we do indepth analysis which can take days. The answer might turn out that there is no workaround and a code change needs to be done anyway. Is the right process to create a Problem ticket when we know this is potentially what is going to happen, or do we do it on the incident and just keep blowing SLA's?

Also another thing we are doing is that the Problem Ticket is used to capture all the information that is needed to do a Software change through the whole development and testing phase and only once the software changes are done and everything is tested and it is ready to be released is a Change Record done. I believe this is incorrect as well?

Any assistance would be appreciated. I become more confused every day.
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Fri May 20, 2016 4:27 pm    Post subject: Reply with quote

First, ITIL is just a set of advice in order to have IT Service Management in an organisation work effectively and efficiently.

Now to the processes -

Incident - an incident should be raised for every one of these failure to deliver service - (application data or form fault). The incident means that the service (application) is not being delivered as agreed.

Incident Management is solely concerned with the service being restored as quickly as possible (within the SLA).

An incident may be resolved if - 1 the service is restored or 2 - If the user / customer is provided a work around that allows the service to work - although at a lower level of service capability.

Problem Management is supposed to be independent of IM - mainly because the goals are completely diffent

IM - restore service
PM - what is the unknown cause for an incident or more appropriate a set of incidents (reactive PM) or work to investigate historical incidents and infrastructure to find weak components. (proactive)

In addition, an incident should not be closed just because a problem has been raised for it. That is just asinine.

That said - an example here

An application (customised) calculates the total + tax incorrectly for one of the forms after a mjor release or upgrade of the application.
A user sees this in production
raises a fault - correct process
fault is investigated by N line support - correct process
it is determined that the code has an error and needs to go to the development team - correct process

A problem record is NOT appropriate here as you know the cause

The solution - work around - is developed to allow the users to use the form
The application development team is tasked through Application Defect management process - part of Software Development Lifecycle - to make the new solution.
If the work around can be delivered quickly, the incident should be resolved as the user can continue to work

The escalation to Defect mgmt should be recorded in the Incident so that the incident can be cross referenced in the SDLC when the new code is developed and tested - ie one of the tested will use the example in the incident.

What is missing is a wholely separate Defect mgmt process that is similar to Problem mgmt - and may even be a sub set

Please come back with comments. I will provide advice as I have a similar situation in my org - and we have it sort of solved

I am not consulting as that is a fee based endeavour; however, I will provide my advice

Recommend: Join LInkedIn and then the Forum called The ITIL Group. It is mine
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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


Joined: May 19, 2016
Posts: 2

PostPosted: Mon May 23, 2016 10:14 am    Post subject: Reply with quote

HI John

Thanks so much for the reply. I agree, that makes more sense. Our Problem Manager keeps saying that App Support is responsible for defect management as well, so we have a tiny team responsible for 3rd level support, defect management and Problem Management as well. The problem is that our ticketing system that is used for everything only has SI's SR's PR's and CR's in it and they use this for everything so an Incident has to stay open/be used for everything or it has to be a Problem ticket. There is nothing else. I will definitely join your group on LinkedIn. Going to find it now. Thanks
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Mon May 23, 2016 3:45 pm    Post subject: Reply with quote

You need to separate Problem Management from Defect management

The development teams should use a tool oriented to application developments - JIRA, Git etc

What also needs to happen is that the IM and PM processes get a policy and process document that deals properly with the issues that are application development in difference to other IT
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
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.