Problem Management - Best Practices in Capturing Metrics of "non-Problems"

MC_Teknaut
Tera Contributor

‎09-28-2023 02:43 PM

SN Experts,

 

I'm working to build out the Problem Management process within my organization (UTAH), and I can't help but notice that the way I capture metrics on issues that "aren't problem management candidates" may in fact not be the best practice, so here I am.

 

I was looking through the environment, and I noticed that within the PTASK (RCA type), there's a very quiet little field nested within the "Analysis Information" tab --> Cause Code. This field provides metrics that account for things like "Environmental Disaster", and "Vendor Issue". Needless to say, these aren't problems my team can fix, so in the meantime, we've been Cancelling those PRBs on the basis of "Not a valid candidate for Problem Management". That's great and all, but if there ARE in fact metrics that capture this. I have a few questions:

  1. When would you cancel a PRB?
  2. Why would you cancel it?
  3. Why would you open an RCA PTASK when you know that it's an "Environmental Disaster": There's no "Fix" for acts of nature, so seems pointless to open it in the first place...would you "Accept Risk" instead?
  4. If you DO use the Accept Risk for things like vendors or disasters, do you still open an RCA PTASK so you can choose the appropriate field?

I apologize for a string of questions. I'm simply confused as the correct use case for cancelling things that are outside of your control vs. going to open PTASKs to capture them officially.

 

I've also asked the question of why is the Cause Code practically hidden away in a PTASK? - Forum Link Here

0 Helpfuls
  • 1,141 Views
1 REPLY 1

Phil Lawton
Giga Contributor

‎09-13-2024 05:55 AM

Hi.  I'm currently looking at closure and cause codes in Problems, trying to work out what is the best approach. 

 

My thinking at the moment is that reactive Problems are all caused by one thing, an incident, and therefore maybe cause codes are redundant in Problems.  Proactive Problems are not caused by anything, so again a cause code wouldn't make any sense.   

 

Closure codes...hmmm.  I think closure codes on tasks make sense (closed complete, skipped, etc), but I'm less sure about closure codes on the problem rec itself.  Closed complete, skipped all make sense, risk accepted too...to my way of thinking most Problems are 'caused' by a number of different things, and ;solved' by executing several different actions, so a single 'caused' and 'resolved' code doesn't really fit. 

 

If anyone is reading this and is able to provide any inspiration, I would really love to hear it!

0 Helpfuls