Many of my recent consulting interactions with service organizations and their customers has been making one strong statement:Visibility_Page_Header

Service Portfolio needs to be brought into a larger mainstream role over Service catalogue in service provider scenarios. Or in other words, Service Catalogue might have to have a larger scope than just the ‘live and currently offered services’.

First, let us set the context here:

ITIL® has been clear on one aspect:

  • Service Catalogue is the only part of the service portfolio published to customers (ITIL® Service strategy publication).
  • Also the diagram in figure 2.6 in the same publication indicates Service catalogue as the only portion of the Portfolio that is visible to customer

In a typical IT Service management scenarios (especially in external, retail service scenarios), this is more or less logical and accurate.

However, in today’s world of ‘so-called’ Business-IT integration (which ITIL® has been describing from its 2007 edition onward), will this be sufficient?

Let us look at the two scenarios of service providers:

a) An Internal IT Provider:

In this scenario, the business units are the key customers for the Service provider (internal IT department or a shared service unit). In this case, if only the Service Catalogue is visible and used in interactions with the customers, will that suffice for an effective business-IT integration?

It is quite apparent that a visibility into the Service Pipeline is highly essential to achieve effective levels of business and IT integration. In the internal Service scenario, the pipeline will be largely driven by the business strategy and priorities, and hence it is important for the business to have a visibility into the Service Pipeline of IT in order to understand and fine-tune (if and as required) the IT’s strategy and capabilities to ensure alignment to business.

So it is clear that, in an internal service scenario, the Service Portfolio (selective portions of the same, in some cases, where applicable) need to be visible to the ‘customer’ organization to ensure proper alignment and integration.

 b) An External Service provider:

Recently I happened to have interactions with the external customers of an IT solution/service provider. One of the key challenges that were repeatedly voiced by the key stakeholders in customer organization was:

  • Lack of visibility into the future solutions that the solution/service provider was planning to offer and/or the roadmap for the existing solutions/services in terms of enhancements and features.

Why is this important to the customer organization? (more…)

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…)

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…)