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: AhmedMoor
New Today: 39
New Yesterday: 83
Overall: 141561

People Online:
Visitors: 47
Members: 2
Total: 49 .

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 - Would Alerting be a Problem Mgmt ticket or a Request?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Would Alerting be a Problem Mgmt ticket or a Request?

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


Joined: Aug 19, 2012
Posts: 1

PostPosted: Sun Aug 19, 2012 4:34 pm    Post subject: Would Alerting be a Problem Mgmt ticket or a Request? Reply with quote

The Major Incident team takes a high impacting call. After they restore service, they open a Problem ticket for alerting to prevent the issue from developing into a major incident. The Problem Mgmt team rejects the ticket because they say it is a Request and not a task to diagnisos root cause.

Question: Should the Incident team be making alerting requests through problem managment after it was discovered it would have reduced the downtime or would it be a Request?

Thanks
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Mon Aug 20, 2012 8:14 pm    Post subject: Reply with quote

What is "alerting"?

What is a "problem"?

What is "problem management"?

What is an "alerting request"?

The quotation marks are to indicate that I am asking about your organization's definitions, not some book answer.

If I can understand what you mean I can apply logic to your question.

Is your definition of a "major incident" confined to level of impact? - If so, you may have other issues to resolve.
_________________
"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
Back to top
View user's profile Send e-mail
Boydness
Itiler


Joined: Aug 03, 2012
Posts: 24

PostPosted: Thu Aug 23, 2012 10:50 pm    Post subject: Reply with quote

Diarmid wrote:


The quotation marks are to indicate that I am asking about your organization's definitions, not some book answer.

If I can understand what you mean I can apply logic to your question.



I agree with Diarmid, without a clear understanding of the dynamics related to your company's terms, it is difficult to respond.

I will hazard a guess that the situation is:
An incident occurs with high user impact, the incident is assigned to a dedicated team that responds to that Incident to restore service. The Major incident team notifies Problem Management of the Incident for possible problem management review. Problem Management rejects the exchange for some specified reason.

So, the exchange is the issue. The criteria should be specified for the exchange and the manner in which it is submitted should also be defined.
Problem Management should be responding to Problems that involve reducing the overall restoration time.

The criteria you may consider adding:
No KEDB entry with restoration action/workaround exists for Incident
Meantime to detection for Incident exceeds X amount of time
etc
And specify the manner in which those are submitted to Problem management for review.

The "no KEDB entry" may have been the criteria that would be utilized in this situation. It is Problem Management's responsibility to ensure that KEDB entries exist for utilization by Incident management to facilitate the timely (rapid) restoration of the service. Your Major Incident team may have determined the workaround or even started to isolate a root cause within their restoration efforts, if so, a problem request is submitted or a Problem record is opened and assigned to Major Incident to document the information that the Major Incident team found related to the Incident.

You could also train and designate the supervisor of the Incident Management team to document (the first several steps of the process) and make the 'Valid Problem Decision', thus allowing Major Incident to directly open the Problem Record and document their findings (maybe even the preliminary analysis findings, if the restoration actions went that far). Then it is Problem Management's responsibility to pick up the ball at assigning problem analysts for the Preliminary Analysis and/or handling the 'Viable Business Reason to Continue' Decision.


Boydness
Back to top
View user's profile
Sammy024
Newbie
Newbie


Joined: Jan 14, 2014
Posts: 4

PostPosted: Wed Jan 15, 2014 8:14 am    Post subject: Reply with quote

Yes what is ALERTING here..... But the time where Major Incident can become a problem is where:
After reading the PIR you see that that the root cause was not found, and Workaround was used to restore the service ----- in this case it can be logged as a problem record to find the permenant fix.
Back to top
View user's profile
Boydness
Itiler


Joined: Aug 03, 2012
Posts: 24

PostPosted: Wed Jan 15, 2014 8:31 am    Post subject: Reply with quote

Sammy024 wrote:
Yes what is ALERTING here..... But the time where Major Incident can become a problem is where...


Sammy please be mindful of your phrasing, an Incident does not become a Problem. An Incident is only ever an Incident. Yes, an Incident can be an input/trigger into the Problem process. A Problem record does not require an Incident record, it could be triggered by Change, etc. Separate records/tickets are required for each process, so an Incident does not become anything other than an Incident.
Back to top
View user's profile
MadhavaVermaDantuluri
Newbie
Newbie


Joined: Jan 29, 2014
Posts: 14
Location: Delhi, India

PostPosted: Thu Jan 30, 2014 2:37 pm    Post subject: Problem alerts Reply with quote

We should send the notification alerts and convince the problem team to provide a sign-off authority upon review of the first alert.
Back to top
View user's profile Visit poster's website
Boydness
Itiler


Joined: Aug 03, 2012
Posts: 24

PostPosted: Fri Jan 31, 2014 12:17 am    Post subject: Reply with quote

The Problem Management process should have criteria to consider if the Problem Request (that was triggered by the Incident) is related to an already established Known Error or if there are merits to further investigation (which would "validate" the Problem Request). So, depending on the resources and other factors, an example of a valid Problem Request (triggered/involving a single Incident) might meet the criteria of being a Priority 1 Incident that had no known Restoration Action (no KE entry), had no Return to Service after 4 hours (or some other duration), requested by senior leadership (or specific roles), and/or other relevant criteria.

Now to be clear, a validated Problem Request simply means that the organization is going to invest some resources into performing a Preliminary Analysis. The PA will be a quick analysis to determine the information to use in the Proceed Further decision (Viable Business Reason to Continue). That information is provided to those that will be making the decision to actually begin the Root Cause Analysis (RCA).

The Problem Request may be valid, the PA may show that that there is a potential unknown root cause that could create the situation where there will be the possibility of a future incidents, but the is no Viable Business Reason to Continue at this time. It is essentially deciding about investing hundreds of man-hours into investigating something that management is willing to live with in the near term and the financial impact is relatively low. The decision may be not to continue unless another incident is potentially attributed to the Problem record within the next X number of days (because the PA did not find another older potentially related Incidents). Leadership decides to treat it as a one-off until more is known and hopefully the next time it happens Incident Management is positioned to capture more data/logs/information the next time, so that the Problem Management process has more to utilize when the Problem record is reviewed again later.

Incident and Problem Management typically have a difficult relationship unless this part of the process is properly structured and well understood among the different levels and tiers. The process is not initially asking for the problem to be "fixed", it is only concerned with validating if their is a NEW (valid) problem, what is readily known about this potential issue (PA), and is their value in devoting resources to investigating the potential issue (VBR to Continue).
Never start the process where the process appears as a hand-off and a VBR by the receiving tier. The recording/documentation through VBR needs to be well defined and controlled externally to those performing the tasks. Also, once that portion of the process is better understood by the personnel in the different level and tiers there will be less resistance to "a new problem" potentially involving their group. Especially, because that new problem may only be a single symptom of something much larger. An incident involving a Real Time Service (RTS) may not be an issue with the service itself but might be a symptom of a local network issue somewhere.

Boydness
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.