Jump to content

Managing Major Incidents within Hornbill

Recommended Posts

Hi all,

Just looking for some advice on how Hornbill users manage major incidents.

  • When receiving the initial report of a major incident (highest priority) should this simply remain as a single incident record with a linked problem record to determine the root cause?
  • Should any further reports of the same major incident be raised as incidents also & linked to the P1 - how should they then be prioritized? Obviously not P1.
  • Is there a way to automatically update/resolve child incidents linked to the major incident?
  • Is there a way to utilize e-mail templates for business-wide progress updates on major incidents?
  • Once the major incident is resolved a major incident report needs to be created, is there a way of integrating this into BPM?

Thanks in advance 

Share this post

Link to post
Share on other sites

Hi @dwalby

Thanks for your post.  Interesting topic.  It will be great to hear about the different approaches from other Hornbill users.  Here are a few points from my perspective, but I'm sure that each environment will have a slightly different view on how Major Incidents are managed.

  • Single incident record vs Problem Record:  My definition of a major incident is one that causes severe user or business impact.  This is an event that should be rare.  When a major incident occurs it is an All Hands on Deck situation.  I would look to ensure that all the teams, managers, etc, are notified with some responsibilities around confirming that it is a major incident and not a false alarm.  (there are some nice SMS integrations that would work well with this type of communication).  This may then follow with some communications to the end users.  To me a Problem Record is secondary in the process.  Possibly after response to the major incident, if the incident has not been immediately resolved, or maybe it has been partially resolved, it might be time for Problem Record to do root cause investigation and have it available for the ''Me too'' scenario for users.  (There is a planned change in Hornbill that will allow a problem or known error record to be automatically raised from an incident using the BPM)
  • Should further reports of the same incident be raised as new incidents:  I see the incidents as a record between support and an individual.  If a user reports an issue, an incident record should be created so that you can maintain that communication with that individual.  The prioritization of that incident is a good questions.  You don't want to raise another incident with a priority of Major Incident to start another set of notifications going out... or maybe you do.  
  • Resolving linked tickets: You would have options here depending on how you want to work.  In Administration you can define relationship types between the different types of requests.  This would give you the option to link an incident to another incident that has been prioritised as a major incident or an existing problem record.  The BPM then has options to update linked requests which includes the ability  to resolve.
  • Business wide email notifications: I'm not sure if there are specific functions or features in Hornbill for a company wide email.  However, if you have distribution lists set up on your email server, as part of your Major Incident process you could send an email to a distribution group.  A BPM triggered email can use templates.
  • Major Incident Report using BPM: I would think that this may depend on what you want to send and who you want to send it to.  This might be an email that goes out to selected recipients that simply contains the details of the resolution.  If something more detailed is needed, then maybe a task would be generated for someone to create a document in document manager that describes the issue, resolution, lessons learned, changes needed, etc. 
  • Like 1

Share this post

Link to post
Share on other sites

@James Ainsworth - Thanks for the response on this it certainly clarifies a few things. I'll be reviewing our BPMs with major incidents in mind and will try to post back here with any findings.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now