| Incident report is an important communication tool to keep all stakeholders aware of disruptions in a production environment. Timely report gives people the confidence that their business is in good hand.
After a disruption of service that impacts business operations and performance, a customer would be keen to know if the IT team has taken steps to avoid recurrence. An incident report will provide information that give the customer assurance that their interests are being taken care of.
When writing the report, honesty and integrity is important. Do not distort the facts and push away responsibilities. As a service owner, you are responsible for the end-to-end availability and reliability of your service.
There are 3 important fields that must be in there:
- Timeline (down to the minutes) of the incident occurrence
- What steps were taken to bring the service up
- What are the next action items that are needed to prevent event of this nature from happening again. You have to include a planned date for implementing the changes.
Incident report is a useful tool for the operations team to document the failure timeline, actions taken to recover the services (workarounds) and what are the actions to be taken to prevent similar incident from happening again.
Incident reports contain vast amount of useful information that we can use for on-going support of the system. Collectively, the reports form a knowledge base that IT Support staff reference and provide quick fix to recurring problems while waiting for the permanent fix to be applied. With that in mind, it is essential to create a central repository and portal system that allows storing, searching and retrieval of past incident reports.
I recommend for starter (if you do not have an integrated ITSM system), you can utilize Microsoft InfoPath forms and SharePoint to build a standalone Incident Report System. The InfoPath forms will be hosted on SharePoint portal. Each form submitted can be tagged for easy search (just like the tag cloud found on the right side of this blog). Users can also search for submitted forms by entering keywords (such as customer name, business name, nature of the problem, etc) and/or date range. Dashboards and reports can be created to give management an overview of the availability and reliability of the IT services. The possibilities are endless.
Submitting an incident report does not mean your job is done. One must always seek closure to all incidents. You are required to set up regular review sessions to follow through the corrective actions that were communicated in the report. Some solutions require a full scale project to implement permanent fixes to a problem while others require simple change in parameters or business logic. The change management process must be strictly followed to minimize change failures and disruption to operation. I would suggest that the change request reference the incident report number and vice versa (this can be automated through the same portal and form system described earlier).
Incident report is one of the deliverable of Incident Management process. This article gives you an idea on how it is being applied in real life though there are many other ways to get things done depending on the environment you are in. Reading books to implement best practices will not get you too far because the framework is generic in nature. It takes an experience consultant or manager to identify gaps in the organization, customizing the process and building the support organization structure to make it work for you.
If you need advise on how to develop the incident reporting system and/or setting up ITSM in your organisation, please feel free to discuss with me.
Do you know of any web app online that can be used in a browser, that has the functionality to allow logging of incident reports and such?
There are quite a number of tools out there. You may want to look at this: http://www.manageengine.com/products/service-desk/ which my company is using. However, be aware that as your organization service maturity improves, tools that are useful now may not be scalable for your needs. However, that said, we can’t over invest in a tool at the early stage.