Managing Major Incidents within Hornbill

[dwalby]

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 

[James Ainsworth]

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. 

[dwalby]

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

[dwalby]

@James Ainsworth - Just a further thought on this, would it be possible to somehow display additional fields in the 'Request Details' section when a request it categorised as a Priority 1/Major Incident during the BPM?

E.g.

Existing: Summary
Existing: Description
Major Incident Detail: Timeline of Events
Major Incident Detail: Subsequent Investigation
Major Incident Detail: Additional Preventative Actions
etc.

That way all of the major incident detail can be captured and represented in one form?

[James Ainsworth]

Hi @dwalby

I'm not sure if this is possible or if I understand correctly, but is your suggestion to allow for conditional fields, including custom fields, within the details section of a request?  For example if the request is a Major Incident show fields X, Y, and Z otherwise keep them hidden?     

[dwalby]

@James Ainsworth - sorry didn't explain it very well but yes, essentially if the request is a major incident show fields X, Y & Z within the request details section.

[James Ainsworth]

This is an interesting idea.  I will have a look into it.  As mentioned, I'm not sure if it is possible at this point but maybe it is something we can investigate and provide in the future.

[dwalby]

Thanks @James Ainsworth - it'd be useful as all of the relevant information would be contained within the incident request, rather than some information breaking out into e-mail communication or Major Incident report Word templates outside of Hornbill.

[dwalby]

@James Ainsworth Sorry to chase on this, did you manage to find out if this was possible?

[James Ainsworth]

Hi @dwalby

I'm afraid I haven't had a chance to look at this yet.  I do have it in my list of things to look at, but I can't say at the moment if it will be something we can proceed with. 

James

[Dan Munns]

@dwalby with the details section you could set a custom field with the header you want (e.g. System Affected) mapped from either the PC or a human task capture.

If you set the field as per the screen shot the extra detail fields will not show unless they are populated. And they will only be populated if the request is logged as a major incident (if you set the BPM up that way) 

Once you have added the required field in the design view you can then edit the field to get these options. 



So if you have a PC with a set of conditional questions which only show if the incident is logged as a major incident or you have a human task which asks the same question as an outcome etc. you can then have an update custom fields node to map those answers to the relevant custom fields which will then show on the details pane.

Hope that makes sense. 

[dwalby]

@Dan Munns thanks for this, I was thinking it could be achieved by doing something like this. I'll need to experiment with it a bit, but it seems like this could work.

[Dan Munns]

@dwalby it works well for us as the department that uses this particular BPM has about 10 / 15 conditional fields they need in the details pane depending on a large number of data points collected during PC and analysts work. 

At the most they only ever have about half of them showing so this way just reduces the clutter of blank fields. 

You just need to remember what field is mapped to what variable (speaking from frustrated experience lol)