Due to the easy recognition that a service offers a modular approach to assembling supporting facilities for operations at any scale, the concept of “services” is a hot topic at many levels of organizational production. In turn, that makes the experience o using services a top priority in the consideration of operational and production performance.
This leads to a quick appreciation of why difficulties in service utilization become so prominent in an organization: services in effect become the “API” that is provided to the workforce for exploiting industrial-grade support of their efforts — in particular, the support provided by any enabling automation technology.
Since worker operations power the progress of maintenance, change and exploration, any expectation of competitively advancing rests on how well workers can leverage their resource. Thus, Performance is inhibited by interruptions of that leverage, which means that performance is also constrained by the capability to manage incidents.
Inspired by that prominence, the topic of incident management stays in the foreground alongside most other considerations of competitive advantage. However, even though the above understanding is commonplace, somehow the matter of how to define, track and handle incidents falls into debate.
We think this ambiguity starts at the level on which organizations demand accountability, which in turn subjects the issue to any preferences or habits of sub-organizations given responsibility along with the accountability. Many of these preferences and habits are institutionalized in local terminology, which brings up the need for a frame of reference that allows different specializations to identify when one of them is actually talking about the same thing or working on the same thing as is another one.
A SINGULAR CLARIFICATION
One hugely important observation is that an incident is largely psycho-logical. Unlike an mere unspecified difficulty which could simply be tolerated, it has to be noticed in order to be managed (accounted for), and it has to be defined in order to be noticed.
In general, an “incident” is:
- a detected significant departure from …
- a condition of an activity, …
- where that condition was defined by the expectations of a known intent.
Yet, while detection is, by definition, always involved, reporting the detection is not. There can be a very significant difference between the presence of incidents and awareness of the incidents by any parties other than the immediate directly affected party.
In general, the management distinction of “an incident” has value in terms of the prevention of an incident and/or the response to the incident.
Prevention demands a clear view of the environmental dynamics that allow or cultivate activity without incidents. Options are mainly in the design, distribution, and prerequisites of the contact between workers and their various resources.
Response requires understanding, weighing and prioritizing relevant options to regain (resolve) a systemic stability in the interactions that accompany normal uninterrupted effectiveness. Options are:
- Circumstantial – a recovery of superficial user progress for the moment
- Relational – a restoration of prescribed reliability on an underlying dependency
- Fundamental — a re-engineering of the intended permanent infrastructure
Different parties should be able to map their existing roles and scope of authority to the design/distribution/prerequisites of prevention, or likewise to the recovery/restoration/re-engineering of response.
A COMMON-SENSE STANDARDIZATION
To assure that there is a commonality of perspective across those multiple points of view, we go to the fact that the operational environment discovered and exploited by workers is to some degree found ad hoc (which creates opportunities), and to some degree commissioned by design (which creates expectations). We also recognize that the environment at hand is typically far more extensive than any worker’s practical familiarity with it. Consequently, there is a degree of uncertainty about what will occur, while there is a degree of prescription about what should occur. This is the normal condition in which incidents are found.
The following lays out a common-sense understanding of how to recognize incidents and approach them from both the proactive and responsive standpoints, simultaneously. That kind of recognition allows the organization to be working on the environment continually with the ability to systematically compare intents to actuals in a closed loop of service production, deployment and service feedback. In this view, any whole or part of a service is a logical item to be addressed, since a service may itself be composed of other services, and the exposure of any service may be specifically significant at the whole or component level.
This version of the framework predicts the possibility of 49 generic types of incidents, completely without any binding reference to a particular organizational entity or infrastructure. Example: From one moment to the next, the likelihood of an “access error” may be greater or lesser than an “output omission”, but standard guidance predicts that both can occur depending on prevention and response.