ITIL as a Product

The concept of how the Infrastructure Technology Information Library (ITIL) can be used as a set of named service products was a thought that crossed my mind in the middle of a business process re-engineering exercise I was involved in some time ago – I thought I’d attempt to explore the concept a bit further here. I’m not formally trained in ITIL, so I’m only putting these ideas forward as talking points! Possibly I’m stating things that are already well understood in the ITIL world, and possibly there are companies out there already doing this. Regardless, I’ll attempt to bring through the relevance of the TMForum  eTom process map to ITIL, and hopefully some value might come out it.


ITIL and eTom compared

ITIL describes long running business processes such as Incident Management, Problem Management and Change Management. These processes can be compared in their level of abstraction to other more generalised non-ITIL specific business processes such as ‘Order to Invoice’ or ‘Credit Approval’ in that they cover a lot of organisational territory.

For example, a Change Management process definition may touch engineering, test and executive groups. Such a Change Management process would typically look much like a flowchart, with various branches of process flow extending between numerous actors and tasks.

By contrast, eTom describes processes as many small units of work and then groups these into progressively higher order sub-domains and domains. The flowchart style ‘branches of process flow’ are not quite so obvious. The reason for this is that eTom is designed as an integral component of the TMForum Frameworx Enterprise Architecture, in which business process sub-domains and domains are aligned to support the relevant matching sub-domains and domains described in the Frameworx Shared Information and Data (SID) and Telecoms Application Map (TAM).

Once this is understood, it becomes more obvious that ITIL and eTom could be used together, with one providing the high level roadmaps (ITIL), and the other (eTOM) a way to describe detailed functions that map directly to a concrete service management system architecture. The key is to be able to understand readily which detailed eTom processes support any given ITIL process.

Fortunately this is something that the TMForum and its many service provider members recognised some time ago, and have already put a lot of work into producing such eTOM-ITIL mappings.


Are complimentary business process maps actually worth putting any effort into? 

Even if these mappings are readily available, just using them must involve additional work.

So what real business justification is there for doing so?

I tend to think that the first underlying reason is that as per the above, the human understandable form of a ‘business process’ is not usually in the same ‘shape’ as what is required to implement the process across the various relevant service management / OSS systems.

For example, some years ago I developed a detailed BPMN based business process flow supporting Change Management. The aim was to cover all relevant information entities and processing activities – understandably the result was a complex diagram significantly larger than even some of the multi-page Change Management process flow diagrams that I’ve seen since.

This type of diagram is exactly what an Architect needs, and could also be of interest to line managers with specific areas of responsibility. It would be inappropriate however for customers, stakeholders, or most other participants in the process flow, who will either want to know about the high level meaningfulness of what’s happening or only the detail relevant to their specific role.


What if one of the business process maps is really a set of complex service product definitions? 

Seeing the distinction between ITIL and eTom did however make me wonder whether high level ITIL processes could be used in particular as the basis for Service Product definitions.

For example a service provider could provide Bronze, Silver and Gold levels of Incident Management responsiveness. Problem and Change Management services may be named as such and structured formally in terms of relevant project tasks such as data collection & evaluation, problem/performance analysis, solution design, implementation, documentation, acceptance testing etc.  Help Desk staff would converse with customers using only ITIL terminology (which might occur more naturally as a function of the products having ITIL themed names).

Internally, a service provider could manage their delivery using eTom processes. This would enable close mapping of process activities to the systems involved, and would also allow more direct assignment of Responsible, Accountable, Consulted and Informed (RACI) task involvements across all relevant individual roles and business units.

  • If it was possible to structure service product offerings specifically around ITIL as a theme, wouldn’t this resonate well with ICT customers who understand ITIL?
  • If it was possible deliver those products more effectively by backing them up with a service management enterprise architecture, wouldn’t that lead to greater internal efficiency (and also service system architecture gap analysis)?

The answers to these questions are probably obvious in the context of a large service provider. The point at which this style of thinking becomes relevant internally within an enterprise organisation is not quite as obvious (except perhaps when revealed in the form of a major outage!)



ITIL is a very rich and highly developed set of service management best practice descriptions. In terms of it’s usefulness to people who have day to day service management responsibilities, ITIL is clearly more immediately useful than eTom.

It seems to me that the world of Enterprise ICT service delivery is growing towards the service provider model where the need for a service system architecture that supports specific business process functions is at least recognised. It’s rare that a single OSS vendor will provide the complete service management software infrastructure for a whole organisation’s needs. By using ITIL and eTom in conjunction with each other, it becomes possible for a customer to realise their own structured service management architecture in an ITIL context, and perhaps even to leverage more value out of ITIL in terms of productisation (if they are a service provider).

Hopefully someone formally trained in ITIL can help me to better understand whether I’m just re-stating things that are already well known in the ITIL world, or how what I’m saying could be better framed in an ITIL context ?

I’d love also to hear any other comments or points of view!


With each blog entry I’m attempting to include some kind of interesting reference material that may or may not be related to B/OSS. With this entry I thought I’d mention a product of a completely different type, namely the private jet – the beginnings of which where were discussed in this Wired article titled: The Lear Jet Turns 50 – But It Almost Didn’t Make It Off the Ground.

It was great reading about the story of how a seeming disaster turned into a key turning point for them during their early days. I had no idea it was Lear who came up with the name ‘Motorola’, or that the basis of the original Lear Jet was a Swiss military aircraft (not discussed in this particular article). Although in a totally different world I thought that this was another good example of borrowing from one domain in order to gain benefit in another – as is possibly the concept of using eTom in an ITIL context!