Some of the definitions of terms in ISO/IEC 20000 fall short of expectations from an international standard, to say the least.
Of course, Improvements are visible such as this:
ISO/IEC 20000: 2005 defined “Service Provider” as: “the organization aiming to achieve lSO/lEC 20000”!.
ISO/IEC 20000: 2011 has a better definition: “organization or part of an organization that manages and delivers a service or services to the customer”.
However, more concerning are definitions which can create conflict or misinterpretation such as that of Incident are still existing:
The ISO20k:2011 defines Incident as: “Unplanned interruption to a service, a reduction in the quality of a service or an event that has not yet impacted the service to the customer” Though there is no official acknowledgement, it is very clear that this is adopted from ITIL® V3. But in that case, it is a case of incorrect or incomplete adoption. Here is why:
The latter part of the definition, which I underlined above says “or an event that has not yet impacted the service to the customer” – Now this dangerously equates ALL events to Incidents! An event is something that affects the service (mostly exception events causing interruption or reduction in quality) or that doesn’t affect a service (warnings and regular operation events). With this loose definition,
all three types of events can now fall under the bracket of Incidents.
It may not be a major issue of compliance from ISO/IEC 20000 context – where there is no separate Event management process. However the following questions needs clarity:
- Does ISO/IEC 20000 view entire event management process as a subset of Incident management? In such a case, the controls specified under Incident management don’t seem to be enough to take care of the requirements of an event management process.
- So will every event trigger Incident management process? I hope this is not what is implied by the standard.
- What is the meaning of the word event that is used by the standard in multiple places? Unfortunately there is no definition of the same.
Here are some other definitions in ISO/IEC 20000 that may create misinterpretations and confusions:
- Known Error: Problem that has an identified root cause or a method of reducing or eliminating its impact on a service by working around it
- Problem: Root cause of one or more incidents NOTE: The root cause is not usually known at the time a problem record is created and the problem management process is responsible for further investigation.
Problem is root cause which is not usually known at the time of problem record creation; known error is a problem with identified root cause OR a method of reducing/eliminating impact? Don’t we see a complete mix up of terms here? I do wonder how a person who is not conversant with ITIL will interpret the above definitions…
There are more definitions which could have been a bit clearer:
- Service: means of delivering value for the customer by facilitating results the customer wants to achieve (Again, clearly adopted from ITIL V3 – however, by eliminating the ‘without the ownership of specific costs and risks’ part, creates complete overlaps with Process – Might be intentional, to be consistent with perspective of Service a type of product carried by other
frameworks and standards like ISO 9000 and CMMi for Service.)
- Service component: single unit of a service that when combined with other units will deliver a complete service (Can cause multiple interpretation of ‘unit of service’ – not defined anywhere)
- Request for change : proposal for a change to be made to a service, service component or the service management system (Overlaps both Change Proposal and Request for Change which ITIL is trying to segregate)
I have written earlier the confusion created by the wrong interpretation of terminologies by auditors. These new inconsistencies could
lead to more such confusions. One wish that a bit more thought and care is put into preparation of proper terms and definitions, especially in auditable and certifiable global standards…
More importantly, the adopting organizations and auditors need to put more care in the right interpretation of the standard and its
clauses, rather than getting picky on the textual definitions of the terms.