Re: Incident tracking

[Tim Cross <theophilusx@gmail.com>]

This is a fairly open question with a wide range of possibilities. If
there is an existing incident management workflow, I would probably
start by seeing how that could be replicated using org-mode facilities.

I would start with a new org file and begin by listing your functional
and non-functional requirements. Perhaps assign a priority to each
requirement or use something like MoSCoW prioritisation to each (Must,
Should, Could, Wont) to each. Then go through all the Must requirements
and see how best to use org to satisfy them, then the should, etc.

If you wanted, you could then come back to the list and show the
requirements and your proposed org-mode solution or ask for an org-mode
based solution and you may get some more substantive responses. As it
stands, the possibilities are too broad/open for any real advice.

A lot will depend on what or how you want to use the incident tracking
system. For example, a priority might be just in tracking and responding
to incidents or it might be to report on incidents or using the
incidents to build up a knowledge base to help resolve incidents faster
by making it easier to find known solutions, identifying reoccurring
incidents that identify underlying problems etc.

Org provides most of the key building blocks, but you may need to put
some effort into reporting and summarising data. I would try to keep it
fairly simple to start with and add functionality as it becomes evident
it is required.

Areas which will likely be good starting points might be

- Capture templates. Standardising how data is captured will really help
  in further processing and reporting. Capture templates can be really
  useful for this.

- Custom TODO states. You probably need TODO states which are more
  'natural' for incident management. For example, instead of TODO,
  STARTED and DONE, you may want to define something like NEW,
  CONFIRMED, TRIAGED/FIX, RESOLVED etc. Any existing incident management
  workflow will likely provide good choices.

- TAGS are likely going to be critical for classification, assignment
  and reporting on incidents. My only advice here would be to be
  conservative when it comes to creating new tags. Too many tags is
  often worse than too few.

- Assigning unique ID numbers to each incident. You will likely have
  repeat incidents or multiple incidents with the same unerlying cause.
  Being able to link incidents or define relationships between them will
  likely be useful.

It may also be worthwhile looking at some existing incident management
solutions. Some of these have good ideas and may provide some valuable
guidance. In many cases, the same principals can be implemented in org
without too much effort.


Lawrence Bottorff <borgauf@gmail.com> writes:

> What would be the best way in the Emacs org-mode world to "keep track" of
> "incidents" that might happen in, e.g., a factory setting? Let's say a
> piece of equipment has various things in its life that happen to it:
> breakdown, warning, maintenance, etc. that you want to keep track of in an
> org-mode way. Would it be something in the TODO/GTD realm, or something
> custom?
>
> LB


--
Tim Cross