Many organisations are beginning to realise that ITIL is not a complete solution. Although it has provided an excellent starting point, there is now a growing realisation that other steps are required in order to truly maintain and further enhance the quality of their IT Service Management capability (and thereby maximise the return on their investment in ITIL).

We at e-Quant believe that the combination of Six Sigma (including LEAN Six Sigma) and ITIL provides the perfect framework to drive forward the quality and effectiveness of IT Service Management in any organisation. By using Six Sigma alongside the ITIL framework organisations are now at last able to fully realise their investment in Best Practice.

Many followers of both ITIL and Six Sigma exhibit an almost religious zeal in advocating and defending their way as the only way to go for improving IT Service Management effectiveness and quality. However rather than being opposing approaches, e-Quant have found that ITIL and Six Sigma are in fact complementary.

ITIL essentially defines a framework for IT Service Management. It consists of a set of guidelines, mainly in the form of processes to be employed in order to manage the delivery of Services over the Service Lifecycle. These guidelines are based on industry Best Practice. It does not however, define in detail how to do this. With ITIL it leaves it to you as to how to flesh out the details of the process flows, develop efficient and meaningful process models, create the detailed required work instructions, etc.

Six Sigma (and Lean Six Sigma) on the other hand, defines a process improvement approach that drives quality improvement and reduces operational costs. It helps in analysing the true need and value of each process, and defines a methodology for continually mapping, measuring and improving the quality process. So Six Sigma tells us the HOW, but it does not specify what to do nor identify any specific Best Practices for IT Service Management.

In summary ITIL defines the ‘WHAT’ of IT Service Management and Six Sigma defines the ‘HOW’ of quality improvement. Together they make a great combination for improving the quality of IT Service Management.

Through our experience and expertise in both Six Sigma (including Lean Six Sigma) and ITIL, e-Quant have developed two primary approaches to combining these frameworks in order to deliver true benefit to IT Service Management effectiveness and quality.

These approaches are explained below:

1. Utilise Lean Six Sigma to optimise ITIL processes

By now, many of you have implemented some or all of the ITIL processes. However the simple fact is that very few will have taken the time to optimise these processes. The result being that although these processes may indeed be aligned to the ITIL framework, they are unlikely to be optimised and may therefore be costly, wasteful and a constraint on service quality.

Lean Six Sigma is essentially all about eliminating waste and increasing the efficiency and effectiveness of processes. By eliminating waste in your ITIL processes you remove duplicated effort, remove bottlenecks and constraints and eliminate those activities that do not add value. The result being not only significant IT Operational costs savings but also the removal of constraints to improving service quality.

The e-Quant approach therefore utilises the strengths of Lean Six Sigma to drive through improvements in your ITIL processes. How our approach works (and some more details of what it is) is outlined below in a series of commonly asked Questions and Answers.

Question - Is this simply an ITIL process maturity assessment / audit?
Answer - No. It is definitely not this. An ITIL process maturity assessment / audit assess the maturity of your process (e.g. Incident Management) against the recommendations of the ITIL framework. In contrast a Lean Six Sigma process optimisation is all about looking into your process(es) in detail to find areas, actions, activities, steps etc that do not add value, act as bottlenecks, and impact the efficiency and effectiveness of the process itself. They are two very different things. The important point to remember is that you can have a process which is fully aligned to the ITIL framework, but it is still not an optimised process.

Question – Is this process optimisation not done when the organisation originally establishes the process?
Answer - We have found that this is not really the case. Processes are implemented, and in some cases they are measured against a set of KPIs. However, we have found that in very few cases are the processes themselves optimised in any way.

Question – So why is it so important to optimise processes?
Answer - To eliminate waste. Waste leads to costs, delays (bottlenecks and constraints) and is a severe inhibitor to delivering a quality IT Service. If your processes are not optimised it is likely that you are wasting time, money and effort, and actually reducing effectiveness of IT Service Management in your organisation.

Question - Does ITIL not provide guidance on process optimisation?
Answer – Not in any real or meaningful detail. This is one area in which ITIL does have a significant weakness. Although ITIL is very much a process based framework it does not really provide organisations with any guidance on how to manage and optimise processes.
This is why you need to combine the goals and aims of Lean Six Sigma (and use its tools) to assist ITIL.

Question – What if I have achieved IS20000 – surely this means that my processes are optimised?
Answer – No. If you have achieved ISO20000 it means that your processes adhere to the requirements of that standard. It does not mean that your processes are optimal and inefficient (the ISO20000 assessment did not audit you against these criteria).

Question - OK – I understand the need. So what is the e-Quant solution to this, and how would you utilise Lean Six Sigma to optimise my ITIL processes?
Answer – We have developed a solution that uses the accepted Lean Six Sigma model of DMAIC (Define, Measure, Analyse, Improve, and Control). We have also added an additional stage called Validate

DEFINE
The first step is to DEFINE what we want to achieve. In broad terms this is all about setting up the improvement ‘project’ in the right way, by defining the scope and purpose of the project and agreeing what processes are to be reviewed. It also defines documents and agrees what the outputs and success criteria for the project are. Finally, it details how the project is to be managed and governed, with details of project reviews, reporting, quality measures etc.

MEASURE
Once the Define stage has been agreed we move to the MEASURE stage. This is where e-Quant ensures that for each process to be optimised there is agreement as to what the process is trying to achieve, and what are the key characteristics of that process. For example, for each process we establish what the CTQs are (Critical to Quality elements of the process): that is, what are the key CUSTOMER or STAKEHOLDER performance requirements of the process. It is vital to identify the CTQ because this will lead to an understanding of what how the customer will receive value from the process and how meaningful KPIs can established for each process.

During this phase we will also look to identify the potential COPQ (Cost of Poor Quality) for each process. This provides valuable input into prioritising the improvement opportunities.

We will also make sure that the other key elements for each process have been identified – e.g. what the trigger is, how quality will be measured, that a process owner has been identified (with the requirements of this role defined) etc.

Question – but surely much of this will have been done when the process was originally defined, developed and implemented as part of an ‘ITIL implementation’.
Answer – Yes – in theory it should have been, but the problem is that ITIL does not provide any real guidance in this area. It is true that in v3 of ITIL there are some generic characteristics of each process listed (e.g. must respond to a trigger, must be measurable, must deliver value to a customer or stakeholder, and must produce a specific result). These however are quite vague, and ITIL offers no real guidance as to how these ‘characteristics’ should be defined. In addition, many IITL implementations undertaken before the release of ITIL v3 did not even have this basic guidance to assist them in the development of effective processes.

ANALYSE
After the Measure phase has been completed we start the ANALYSE phase

It should be noted that although DMAIC is presented here as a liner sequence of activities, in reality there is a high degree of cyclical activity between the phases – especially between the Analyse and Measure phases. This because the most analysis you undertake then the more this leads to potential refinement in process purpose, required KPIs etc.

The Analyse phase is all about trying to establish what is actually happening, and how the process under investigation is currently operating. By undertaking detailed analysis of the process steps (using Lean Six Sigma techniques such as Spaghetti Diagrams, Value Stream Mapping) we seek to identify the potential constraints, bottlenecks, areas of ‘overproduction’ and Non Value Add Activities in the process (this is the waste that must be removed if the process is to work efficiently and deliver true value to a Customer or Stakeholder). During this phase we also identify and quantify the true Value Add activities within the process

A Quick note on the concept of ‘Waste’

If you have waste in a process you are either incurring additional cost or / and you will be limiting the quality of service that you are able to deliver.
By identifying and eliminating waste you are improving the flow and performance of a process, thereby allowing improvements (either in the cost of undertaking the process and / or the qu7ality of service provided by the process).
In Lean Six Sigma 7 categories of Waste have been identified:
• Overproduction
• Waiting
• Transportation
• Processing
• Inventory
• Motion
• Correction
• Often there is an eight category – failing to use the potential of People

At e-Quant, through our experience in using Lean Six Sigma for the optimisation of IT Service Management processes we have refined the above, to give the following categories of waste specific to ITIL and IT processes in general:
• Duplication
• Processing
• Uncertain Ownership / Participation
• Unnecessary Inactivity
• Unnecessary (Non Value) Activity
• Complexity of throughput
• Complexity of activity
• Validity of purpose (not meeting CTQs etc)

These are primary areas of ‘waste’ that we identify during the Analyse phase

IMPROVE
This is where e-Quant develops and presents the proposed solution (primarily this will consist of an optimised process flow); this will include the priorities for improvement complete with rationale and justifications. This requires formal sign-off prior to implementation. Where appropriate, this phase may also involve a pilot of the revised process.

Again, there is likely to be iteration and cyclical feedback into the Analyse and Measure phases, leading to, a revision of the proposed solution.

CONTROL
This is where the agreed solution is implemented. The revised process(es), procedures etc ‘go live’. This will involve ensuring full staff training in the new process, handover of control documentation, measuring the success of the implementation and the new processes and the project as a whole

Key within this phase is the need to carefully measure the output from the process to ensure that the defined CTQs of the process are (Critical to Quality elements) being captured, measured and achieved.

At the end of this phase the benefits of the process optimisation are formally defined, documented and signed off.

VALIDATE
The last phase is one that e-Quant have added to the traditional Lean Six Sigma approach in order to ensure the on-going validity of the optimised processes that have been developed and implemented.

It involves the on-going and periodic review of the process in order to ensure that it remains fit for purpose, that it meets the defined CTQs (and that the defined CTQs remain valid), and that the process is constantly being optimised by identifying and removing all waste.

This phase can either be undertaken ‘in-house’ by the appointed process owner or e-Quant can undertake it as part of a regular process validation exercise.

By undertaking this last activity your process optimisation is undertaken as part of a Cycle of Continual Improvement, and it therefore underpins of the major principles and aims of ITIL itself.

Question – you mention ITIL processes a lot. But can this approach be taken to improve other, maybe ‘non-ITIL’ processes
Answer – Yes - absolutely. Our approach applies to any IT (and non IT!) processes. So it is not restricted to organisations that have adopted ITIL processes.

Question – How do I find out more, and whether this approach will suit my organisation?
Answer – Contact us at enquiries@e-quant.co.uk and we can give you more information on our approach, the benefits etc, and we can determine if might be of benefit to your organisation.

2. Drive IT Operational Improvement by combining Six Sigma & ITIL

Six Sigma was originally developed as a set of practices designed to improve manufacturing process quality by eliminating Defects (so – when you reach the level of SIX sigma, you will only have 3.4 Defects Per Million Opportunities (DPMO) in your manufacturing process).

e-Quant have developed an approach that combines the disciplines, principles and tools of Six Sigma with the common ITIL processes in order to facilitate IT Operational Improvements.

Question – I can understand how this relates to Manufacturing, but not IT. For example, I can appreciate what a Defect is in the manufacturing process, but what could a Defect be in IT?
Answer – This is a very important point. Remember the key aim of Six Sigma is to identify the causes of Defects and to remove them – thereby improving quality. In IT Terms a Defect could be a number of things. For example, any of the things below could be classed as a Defect in IT Terms:

• A Service Outage
• A breach of SLA
• A customer complaint
• Unacceptable Customer satisfaction feedback
• A missed internal Service Target (as specified in an OLA)
• A Change Related Incident
• A Change that fails to be implemented successfully (e.g. on time and on budget)
• An error in the integrity of data in the CMDB
• etc

We have found it useful to initially limit what is defined as a Defect to something that can adversely impact Customer Satisfaction with IT performance. This gives a clearer indication to what areas should be the initial focus for investigation of Defects.

Question – So I can use this approach to drive through IT Operational Improvements by – for example – identifying the cause of Service Outages and eliminating these causes?
Answer – Put simply – Yes. To use the example of Service Outages (although it also applies to all types of Defect listed above). The e-Quant approach would be to use the Six Sigma framework to identify the Service Outages that would need to be investigated (in Six Sigma terms these would be the Natural Cause Variations). Then to identify the root cause of the Service Outages that are to be investigated, we would use the ITIL Problem Management process (and also possibly Availability Management).Once the root cause has been analysed and a permanent resolution identified, we would use the ITIL Change & Release processes to implement.

Question – So Six Sigma identifies the Defects that should be investigated, and ITIL does the root cause investigation and implements the resolution.
Answer – Yes. You could say that Six Sigma identifies the areas for improvement, and ITIL delivers the improvement. To provide a little more detail.

Specifically for Service Outages Six Sigma drives successful reactive problem management through its DMAIC (Define, Measure, Analyze, Improve, and Control) framework. The table below shows the DMAIC methodology and illustrates the connection to ITIL service management practices.

DMAIC and Connection to ITIL for Service Outage improvement

Question – But is this not ‘overkill’? Why use Six Sigma at all? Why not simply follow the general advice of guidance and investigate the root cause of all recurring Incidents, and all major service outages?
Answer – Because this type of ‘scattergun’ approach is not based on any form of analysis as to the real benefits of investigating certain type of outages, and may therefore bring no real operational benefit (and waste the time of valuable IT Resources).

The value of the Six Sigma approach is that it uses statistical techniques to accurately identify those occurrences of the Defect that need to be investigated in order to reduce the frequency and impact of the Defect. The key in this is to understand the ‘process variation’, and know when to take action (and when not to take action) in order to reduce the variation (and thereby reduce the frequency and impact of the Defect)

As ITIL offers no real advice or guidance on the how to identify the most beneficial occurrences of a Defect to investigate, this is where ITIL derives great benefit from being combined with Six Sigma.

In fact you even get a very important ‘secondary’ benefit, when using Six Sigma to analyse the type of service outages (Defects) to be investigated by Problem Management. This is you are also able to identify the type of service outage that requires the involvement of the Availability and/or IT Service Continuity ITIL processes, for the purpose of undertaking a Risk Assessment and possibly implementing Countermeasures to reduce future Likelihood and/or Impact of that type of outage. This becomes possible because Six Sigma provides the opportunity to differentiate between service outages that can be classed as Natural Cause (and which are investigated through Problem Management), and those that are classed as Special Cause (and which require investigation using Availability and/or IT Service Continuity Management).

Question – So how would it work for other Defects – apart from Service Outages?
Answer – Using the same principles, but employing the Six Sigma tools and the ITIL processes that are appropriate for the improvement of that specific Defect – whether it be poor customer satisfaction survey results, breached SLAs, etc.

Question – So, my aim would be to reduce all Defects to 3.4 Defects Per Million Opportunities (DPMO), therefore achieving the level of Six Sigma?
Answer – Not necessarily. As part of the initial consultation phase we would try to establish the appropriate ‘level of Sigma’ that you wish to achieve for each type of Defect. For example, for some defects, you might be satisfied with Sigma Level e.g. 4, which equates to 6,210 DPMO.

Question – How will I know what to aim for?
Answer – we work through this in detail as part of the initial consultation. Not only do we identify and verify the Defects you wish to investigate and improve, we also determine such things as the acceptable (target) DPMO, the Critical to Quality (CTQ) requirements that your customers have for services (that are impacted by the Defects), and the number of Defect Opportunities (any event that provides a chance of not meeting a CTQ).

Question – How do I find out more, and whether this approach will suit my organisation?
Answer – Contact us at enquiries@e-quant.co.uk and we can give you more information on our approach, the benefits etc, and we can determine if might be of benefit to your organisation.