Due dates and SLAs for Problems

It'd be great if Problems weren't just implemented as essentially join records to link up multiple incidents (i.e. reactive).

It's perfectly common to discover problems in the environment that have not resulted in Incidents.  Without any ability to define automations, SLAs, or even basic due dates, Problems in the system become a black hole until an Incident occurs and you say "oh yeah, we were going to fix that."

One particular use case we have: Vulnerability Management.  We uncover a few dozen vulnerabilities during a scan and would like to manage remediation to our standard (for example 90% resolution in 30 days for Critical).  These are not Incidents - nothing is broken.  They may result in Security Incidents if we don't take care of them.

Currently we're mangling Incidents to deal with this. It works, but it introduces clutter etc.

Thoughts?

Parents
  • This is spot on, we want to move forward with implementing Problem Management, however after testing I noticed it can be a blackhole where problems can goto the grave. To add on to Caitken's comment about Change, that there also seems to be an abandoned module, as it's difficult to customize notifications, approvals/non approvals, and other things to personalize the experience in a very simple way.

Reply
  • This is spot on, we want to move forward with implementing Problem Management, however after testing I noticed it can be a blackhole where problems can goto the grave. To add on to Caitken's comment about Change, that there also seems to be an abandoned module, as it's difficult to customize notifications, approvals/non approvals, and other things to personalize the experience in a very simple way.

Children
No Data