ISO 20000


We can always ask: “What’s in a name?”. But the fact of the matter is most often than not, the name (or title) is of utmost important in setting perceptions and acceptance, when it comes to books, standards and other key documentations at least.

ISO/IEC 20000, the standard has evolved with specific focus on IT Service management.  However, in its 2011 edition of the standard, there seemed to be a clear effort to elevate the standard to a generic Service Management focus – to make it applicable to any Service organizations, IT or non-IT.

A major roadblock in this elevation and global acceptance as a generic standard could be the term that remained in its title: “Information Technology (IT)”. The standard title remains to be: “Information technology — Service management”.

I have written in an earlier post regarding the confusion that exists in this matter.

I have come across more than one organization (Non-IT) who are hesitant to adopt ISO/IEC 20000 – just because the standard title specifically refer to Information Technology infrastructure Library.

I do understand there could be internal, technical reasons within ISO to keep the title as is; however, it is also important to understand the majority of the adopters and practitioners remain unaware of (or quite understandably, don’t care) about them.

And we can also see that this is not just an issue with the ISO/IEC 20000 standard alone.

The global standard for Information Security , ISO/IEC 27001 also carries the title:  “Information technology — Security techniques — Information security management systems”. (This is retained in the latest, 2013 edition as well). (more…)

Advertisements

When the 2011 edition of the global standard ISO/IEC 20000 came into effect, there was a visible interpretation in (at least some portions of) the industry that  the standard has now made itself applicable to ‘generic Service management’ and not just IT.

But in those areas as well, there has been a split in opinion:

A set of practitioners, consultants, auditors etc who believed that ISO/IEC 20000 has really moved beyond an ITSM standard into a standard for ‘Service management in general‘. In other words, this standard can be used to benchmark and certify non-IT Service management as well.

Another set of people (including me) who were not very sure if that was really the case…

Why the interpretation came into the industry?

  • Most of the text in clauses and terminologies of the standard mentioned just ‘Service management’ and nothing specific about IT.
  • The Application Section of the standard stated:  ‘All requirements in this part of ISO/IEC 20000 are generic and are intended to be applicable to all service providers, regardless of type, size and the nature of the services delivered.’

 Then why the doubt or confusion still existed? Here are some reasons:

  • The  title of the standard still read:  ‘Information technology — Service management’
  • The Forward section of the 2011 edition talks about the summary of differences with the earlier (2005) edition of the standard such as:  closer alignment to ISO 9001; closer alignment to ISO/IEC 27001; change of terminology to reflect international usage and so on – but nothing on this significant scope change of this standard.

And more importantly, if you look closer, even the 2005 edition of the standard never mentioned anything specific to IT in most of its text, except in the title! (This in some form, justifies the point about the Forward Section mentioned in second bullet above.)

So is this a change in the standard with the 2011 edition?  Or Is ISO/IEC 20000 intended from a standard for generic service management from day 1?

If so why the title specifically says ‘Information Technology’(more…)

What is Problem management in ITSM?

When there is ’unknown underlying cause’ for ‘one or more incidents’, Problem management process is used to find the ‘underlying cause’, convert them into ‘Known Errors’ and ‘Resolve them permanently’.

Problem management can be Reactive (when it is used to do analyze and permanently fix the cause of an incident that just happened) or proactive, where  areas requiring Root cause analysis are proactively identified – through trend analysis, proactive identification of potential issues etc.

All these are fine – but have a very basic ‘problem’:  The whole set of explanations gives an impression that it is all above correcting a ‘problem’ and identifying and fixing an ‘error’.

Why this process should only address ‘Problems’ and ‘errors only? Won’t the same process useful for ‘Cause analysis’ and ‘management’ of any ‘unknown’ element in the Service management?

In a broader sense, we are discussing a process that aims at:

  • Identify an area that requires detailed cause analysis
  • Derive and document the underlying cause
  • Address the cause fully (as required) and further actions on it

Take the following scenarios as examples:

1. After a particular patch/bug-fix is implemented on a Server, the performance of the Server has improved significantly – It is an unintended outcome from the patch update. The concerned technical team is not sure ‘why’ this has happened.

It might be a good idea to do a ‘cause analysis’ in this case to identify the root cause of this positive change in Server performance and address questions like:

  • Is this positive performance change really due to the patch update?
  • If so, which element of the update has caused the improvement?
  • Can this element be used on other (similar) servers to improve the performance?
  • Can this element be included as a part of design document for such servers? (more…)

ITIL® , the best practice framework for IT Service management-  by the time it has evolved into its third version or as it is called now into the 2007 edition –  came up with a comprehensive definition of “Service” (the same is retained in its 2011 edition as well):

“Means of delivering value to the customer by facilitating the outcomes customer want to achieve, without the ownership of specific costs and risks”

However, it seems to be still unclear (or missing the opportunity) in defining ‘IT service’ and  ‘IT Service Provider’ clearly.  As per the 2011 edition, the definitions are:

“IT service:  Services delivered by an IT Service Provider”

 “IT Service Provider: A service provider providing IT Services to internal or external customers”

Talk about Circular references!

 Can’t we have some better definition or at least better insights into understanding what an ‘IT Service’ is?

No, I don’t have a well thought out definition of ‘IT Service’ on offer here; not yet. However here are some thoughts that might lead us to defining ‘IT service’ better:

What is Information Technology (IT)?

Technology used to:  Process information, Store Information, Transfer information, or Present (visualize, for example) business information.

So the ‘outcome’ expected by customer or business from “IT” (as a provider of service) can be described through:

  • Process, Store, Transfer or Present business information as required by the business
  • While ensuring key aspects like Reliability, Security and Cost-effectiveness

Any systems/technology and/or activity which facilitate the above outcome described above,

  • Without the need of  business/customer to own, manage or worry about the specific risks and  costs of the underlying technology, assets, activities etc.

can be an “IT Service”.

With this context , one possible perspective of looking at IT Service can be as below: (more…)

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:

(more…)

While IT evolved through cycles of improved capabilities, complexities and business dependency, IT Service providers started realizing and embracing the concept of IT Service Management.

 The approach of extending IT Services (in terms of facilitated business outcomes) to the business/customer, and relieving them from the complexities of the technology and operations behind it, has definitely put IT in a right track of Business-IT alignment and Integration. Various frameworks and standards like ITIL®, ISO/IEC 20000, COBIT etc has played a very crucial role in bringing the Service perspective into IT.

IT was “Infrastructure” management or “Application management” or “Operations” management. The concept of IT Service Management has shifted the mainstream focus from those underlying responsibilities and components to ‘Services’ (facilitating of business outcomes). The approach enabled the business and Customers to focus on “What” they receive in terms of outcomes from IT; rather than on “How” they were delivered.

Then the Cloud burst happened. I mean then the concept of ‘Cloud’ evolved!

The IT industry – probably deprived of using favourite technology discussions by all these “Service” talks in mainstream – grabbed it by both
hands; some even behaving as if this is one of the biggest invention after fire! Debates are all around – will frameworks like ‘ITIL’ survive such a cloud burst?

Many didn’t realize – or tend to ignore the fact that all these mainstream focus on Cloud in business circles is moving the whole Business-IT relationship a step back – to the era of “Infrastructure” management.

Cloud in ITSM
Change in ITSM with Cloud

Let us not forget the expected output of IT to business is still in the same lines as the “pre-cloud times” (!) – A facility to send emails, a business application functionality, a workflow capability, an automated information processing and so on. The “What” remains the same. Of course, the “How” is changed by Cloud – for the better, in terms of efficiency, scalability and cost-effectiveness; or at least supposed to be so.

On a lighter note, we can say – ‘CLOUD are not really beneficial to mankind and the world – but the RAIN is’!

 Having said this – the concept of Cloud is a significant development in IT. It can bring in huge advantages that can get converted into business value of IT. The complexities and challenges associated with Cloud need to be assessed and addressed. The benefits of this new way of managing IT need to be highlighted.

All these are essential; but not at the cost of shifting focus from the all-important business outcomes of IT. Hence the whole Cloud adoption will gain huge benefits by adopting ITSM best practices and standards into the complexities and capabilities of Cloud, rather than resisting or writing them off.

SLA is nothing new to any service provider. Everybody (well, almost) has at least one, with their clients. Of course there are those who say we don’t have SLAs as our customers didn’t ask for it.

While drawing up an SLA, a service provider are exposed to, and very often falls into traps like:

  • Going with the “Standard” SLA (standard to whom?)
  • Agreeing to what customer asked. (Customer is the king!)
  • Taking over ‘existing’ SLA from current service provider (typically as part of transition in outsourced contracts)
  • Adopting ‘best practices’ from industry!!! (best practices on SLA targets?)

One cannot emphasize enough, how important it is to have a closer look of each SLA parameter that you are going to commit ( or in many case, have committed already!).

Each of the SLA parameters need to be assessed (BEFORE committing to or agreeing with customer) for aspects like:

  • Does the parameter really reflect what is important to the customer?
  • How important this parameter is, to the service and to the customer/users?
  • Does the service provide has capabilities in place to provide those levels at the current cost/pricing framework?
  • Can the parameter be quantified?  (Quantified parameters are measured on data, Qualitiative are measured through perceptions!)
  • Can this be measured? (feasibility, having the right tools, resources, time)

There could be many such aspects added into the assessment, but the above would give a good starting point.

Let me take a couple of examples (kind of funny, but actual scenarios that I came across) to illustrate the need of such an assessment: (more…)