Beetil

Incident Management is where most people tend to start out with their service management.

ITIL formally defines the primary goal of incident management process to be to restore a normal service operation as quickly as possible and to minimize the impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained.

In other words, get the user back up and running a.s.a.p. Remember that this does not mean that you must fix the underlying root cause to fix the incident. A quick band-aid fix in many cases will often provide you much greater return than redeveloping software etc.

At all times, remember the goal here – get the user back and up and running.

So let’s introduce Beetil and incident management.

The Incident Management Dashboard

The picture above (click on it to see a bigger version) tells it own story.

Beetil’s dashboard not only easily provides users with quick and easy ways in which to slice and dice their view, but also allows users to quickly see common incidents that can easily be cloned, and incidents recently flagged as being “of note”.

The dashboard view can be filtered by a particular user or group, and can be configured to show incidents that are “on my watchlist”.

Individual Incidents

Let’s walk through the process of logging an incident.

Incident Service – set which service the incident belongs to. You can change this, but be careful as the priorities you have set might be different across your services, and your permissioned users may be different. Upon changing the incident service, Beetil will automatically select a new priority and assignee.

Incident Owner – set who is ultimately responsible for seeing this incident through to completion. This is different to the assignee.

Incident Assignee – assign the incident to whoever needs to work upon it to get to resolutions

Incident Priority – clicking on the priority link will bring up an intuitive priority matrix to better help service desk staff ascertain the relevant priority.

Selection of a priority will automatically calculate the due date. This can be overidden by a service administrator, or if the service has been configured to have “negotiable SLAs”.

Customer – select the customer who is affected by this incident, or create a new customer to add into the customer database. Click the little “business card” to enter or edit customer details. If the customer has been permissioned to access the customer portal, an optional checkbox to “make viewable in the customer portal” will appear.

Incident Type – set what type of incident this is. i.e. bug, query, feedback, feature request. You can configure these in service administration.

Incident Category – if incident categories have been configured for this service you can categorise incidents using this field. i.e. a Desktop PC service may have categories such as CPU, Memory, Screen, Mouse, Keyboard.

Incident Occurred At – log the time the incident actually occurred. Note that this is different to the time that the incident was logged. The service resolution time is driven off of the incident occurred at time.

OK, now on to the meat of the incident.

Every incident has a symptom. Quite simply, this is what went wrong, or what’s about to go wrong. Beetil only allows updates to this field, in an effort to ensure that symptoms are kept as useful and concise as possible. This maximises re-use potential.

You can also discuss an incident. This is particularly useful when handing off incidents to various staff or support functions.

Finally, once an incident is resolved, you must populate a resolution. Put useful stuff in here about how the incident was fixed. Don’t just put “fixed” – as it’s hardly useful for anyone else.

Populating a resolution enables the “mark as resolved” checkbox. If the incident is resolved, check this box, and mark the time it was resolved. It defaults to now.

At this juncture, you may also close this incident, or if you have a closure review process you can choose to keep this unchecked.

Finally, you can add interested people to the watchlist of an incident. Simply click the people who you think might want notifying of updates to this incident, and whenever you check the “notify watchlist” checkbox when saving an incident they will be notified via email.

You can also choose to close an incident at any time for other reasons – i.e it’s a duplicate, it was perhaps fixed with a release, or it may not be simply relevant any more.

Linking to other incidents, changes, problems and releases

We like our linkages here at Beetil. From any incident you can easily search for, link to, and re-use information from other Beetils. Simply click the + buttons to go search or to create a new linked Beetil.

Audit Trails

Every little change to every Beetil is logged to keep auditors happy. Clicking on the “Full History Log” link opens a full incident history report.

More links in our getting started with Beetil series

• Setting up and configuring services
• Beetil and the Customer Portal
• Problem Management
• Change Management
• Release Management (coming soon)
• Configuration Management

Remember you can always access the help link in the top right hand corner of most pages! And you can always contact us on email at support@beetil.com, or catch us around the Campfire.

This entry was posted on Wednesday, July 15th, 2009 at 10:00 pm and is filed under Getting Started, Hints and Tips, Incident Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.