Incident tracking

Incident tracking

[Lawrence Bottorff]

[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 443 bytes --]

Re: Incident tracking

[Russell Adams]

On Thu, Feb 27, 2020 at 04:55:30PM -0600, Lawrence Bottorff wrote:
> 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,

You can structure your file any way you like.

You might consider either:

----------------------------------------------------------------------

 - Organize tickets by time, adding to the bottom, but tagging them against
 machines by serial or something similar

* Tickets

** TODO Fix it again                                               :MACHINE_X:

** DONE Eat a sock                                                  :DRYER_2:

----------------------------------------------------------------------

 - Organize tickets by machine first, then time

* Tickets

** Machine X

*** TODO Fix it again

** Dryer 2

*** DONE Eat a sock

YMMV. You can do reporting on either with column views.


------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Incident tracking

[Tim Cross]

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

Re: Incident tracking

[Samuel Wales]

i have no right to respond as i have 483 scheduleds and 28 deadlines
and i get lost even trying to get one thing done per week, but i just
wanted to add to the advice so far.

there is org-edna for dependencies.  org-depend also, but i think it
lacks the feature of scheduling a remote org-id header once a local
one is doneified.

it is useful to stick inactive timestamps at boh on headlines, so you
can do all sorts of things like visually bisect to find what you are
looking for, search only the visible headlines, etc.  this makes for
good logging.  [others will recommend date trees instead.]

i like this type of discussion as we have had few of them in the last
8 years or so and there is much insight for usage and even fodder for
better features or refactoring, i think.

gtd is too labor-intensive for myself, but others will suggest reading
materials if you think it fits.

org is flexible so it's really a toolkit for figuring out your own
structures.  i'd suggest not getting too fancy at first because yagni
sometimes applies.

===

i find it useful to think of my org forest as an ontology of
representations of preferably physical objects that become canonical
locations in it.

thus, your washer is one holon [subtree] and you always know where to
refile to for it.  then you don't need tags as much; you can use org
id links to make the forest a digraph.  location determines identity.

this is in contrast to, for example "stuff to do for maintenance".

-- 
The Kafka Pandemic

What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

Re: Incident tracking

[Lawrence Bottorff]

[-- Attachment #1: Type: text/plain, Size: 2085 bytes --]

I can see that an "incident" can be seen as a TODO; indeed, anything event
can start as a TODO, then move on in status to one of your other
org-todo-keyword entries. Question: When I start the TODO process, and then
update the status, once or more times, finally, perhaps with DONE, is there
a record of this "Werdegang," this process?

On Thu, Feb 27, 2020 at 7:50 PM Samuel Wales <samologist@gmail.com> wrote:

> i have no right to respond as i have 483 scheduleds and 28 deadlines
> and i get lost even trying to get one thing done per week, but i just
> wanted to add to the advice so far.
>
> there is org-edna for dependencies.  org-depend also, but i think it
> lacks the feature of scheduling a remote org-id header once a local
> one is doneified.
>
> it is useful to stick inactive timestamps at boh on headlines, so you
> can do all sorts of things like visually bisect to find what you are
> looking for, search only the visible headlines, etc.  this makes for
> good logging.  [others will recommend date trees instead.]
>
> i like this type of discussion as we have had few of them in the last
> 8 years or so and there is much insight for usage and even fodder for
> better features or refactoring, i think.
>
> gtd is too labor-intensive for myself, but others will suggest reading
> materials if you think it fits.
>
> org is flexible so it's really a toolkit for figuring out your own
> structures.  i'd suggest not getting too fancy at first because yagni
> sometimes applies.
>
> ===
>
> i find it useful to think of my org forest as an ontology of
> representations of preferably physical objects that become canonical
> locations in it.
>
> thus, your washer is one holon [subtree] and you always know where to
> refile to for it.  then you don't need tags as much; you can use org
> id links to make the forest a digraph.  location determines identity.
>
> this is in contrast to, for example "stuff to do for maintenance".
>
> --
> The Kafka Pandemic
>
> What is misopathy?
>
> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
>

[-- Attachment #2: Type: text/html, Size: 2672 bytes --]

Re: Incident tracking

[Russell Adams]

Lawrence

On Fri, Feb 28, 2020 at 09:26:06AM -0600, Lawrence Bottorff wrote:
> I can see that an "incident" can be seen as a TODO; indeed, anything event
> can start as a TODO, then move on in status to one of your other
> org-todo-keyword entries. Question: When I start the TODO process, and then
> update the status, once or more times, finally, perhaps with DONE, is there
> a record of this "Werdegang," this process?

You can set Org to capture the timestamp when you change the item to DONE.

As a consultant I frequently timestamp all of my work by inserting an inactive
timestamp each time I switch tasks or return to the computer. That way in the
agenda view I can review what happened and when.

If you are more interested in automated time reporting, Org has options for that
too. See clock-in and clock-out.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3