ITIL describes itself as a ‘good practice’ for providing value to customers in the form of services. However, ITIL is not the only ITSM practice around, but it has proved to be the most successful.
At the very least it can be seen to provide a systematic checklist of the activities you might expect to see in an organisation providing IT services, with supporting process models for performing them. Furthermore, the terminology of ITIL provides a consistent language for vendors and their customers to use in interpreting service components. Many customers understandably take comfort when dealing with a vendor who is following ITIL, or a similar set of recognised best practices.
Additionally the model appears to support a nexus of ITSM organisations, unified in providing value to end customers through a cascade of service level agreements, operational level agreements and underpinning contracts.
The relationship between the service management frameworks of multiple players is increasingly a critical feature of providing effective services. Hosting, data communications, service desk, operations and application support are more likely than ever to be provided by a third party or an internal service provider with a limited line relationship to the internal customer.
As a result an implementation or adaptation of an ITSM lifecycle must consider all the service providers in the value chain in order to be effective. Nowhere is this more important than in outsourcing IT-enabled business processes or otherwise seeking to achieve significant IT service transformation.
The risks of failing to adequately deal with this complexity can be significant. In extreme cases the business case for the transformation can be nullified. In one example I came across the per capita cost of providing IT services to the employees of the outsourced company was greater than that of providing the same services to the employees of the outsourcer, but this had failed to be included in the calculations.
Furthermore latency associated with distances, bandwidth-hogging applications and demarcation disputes over incidents contributed to reduced service levels and lower productivity by the outsourced company’s employees. Effectively, through outsourcing, a new service needed to be designed, and should have been part of the development of the original business case.
I mention demarcation disputes, and this is a common feature of service management frameworks involving multiple vendors, but is easily avoidable by designing end-to-end incident management processes and factoring in the capacity and availability implications of multiple parties combining to provide end services. For example, an end-user may report an error to their local service desk, which hands it off to application support who then identify an outage at the hosting site.
In many contracts with data centres, the incident is only opened once they have been informed, not when it was originally reported. This in itself is not an issue, but if the incident, service level and other relevant management processes have not factored this in, the service levels are unpredictable.
Another area of potential variance between expected and actual service levels occurs if multiple vendors are involved in request management. A simple change may involve approvals from multiple application owners and third parties, scheduling of resources from multiple organisations and updating of records of configuration items (CIs) in multiple databases.
On the one hand this is a relatively easy issue to address early in the design of the service, but since the engagement of new vendors often takes place when apparently mature ITSM processes are in place, the impact is often overlooked or understated.
An answer to some of these concerns would seem to be to put in place penalty clauses, but I would argue that this does not address the root causes of unacceptable service variation. There are many good reasons why penalties are increasingly the exception rather than the norm.
The contract negotiations become bogged down in discussing the triggers and dimensions of the penalties, the discussion can undermine trust and ultimately any vendor making guarantees embodied in penalties would want to factor in the cost of the penalties into the contract. Most importantly, penalty clauses can be a smokescreen for disguising a Heath Robinson designed integrated ITSM.
One important caution to note is that, in the same way many companies have multiple organisations involved in delivering services; their vendors operate the same way. Understanding of the service value chain should not end with the vendors’ themselves. Be prepared to risk assess the involvement of the vendors own vendor value chain, and ensure that the right to audit key suppliers of your own vendors is written into any contracts.
Although there are other risks to effective implementation of end-to-end ITSM, the final pitfall that is easily overlooked concerns security when multiple vendors are involved. I led the remediation for a root cause analysis following a major incident for a Fortune 500 company, and was surprised to find that root level access to the company’s critical ERP systems was shared across dozens of individuals in four companies, spanning eight countries, with minimal controls in place.
The original design of the ERP system pre-dated the incrementally more pronounced outsourcing of hosting, operations, basis services and application support. However the necessary transformation of the services to maintain adequate security controls had not taken place, despite the apparently comprehensive security management system in place.
One feature of ITIL’s definition of service is that outcomes are facilitated on behalf of the customer without them owning component costs or underlying risks. In practice, this may be true once a service is operational, but a company considering outsourcing or changing their vendor landscape must do the due diligence to understand the underlying costs, complexity and risk associated with their service requirements and be prepared to redesign services as appropriate.
Perhaps the worse way to implement a cross-vendor ITSM is to simply trust to luck that the vendors will address pre-existing deficiencies and not add any new ones. However that is still the preferred approach of many organisations.
Many companies will approach tier one vendors in the belief that these organisations are in the business of delivering service management excellence even for large-scale, complex services. It may be true that in some cases only a limited number of vendors have the capability to take on provision of these services, but in my experience all the tier one vendors have participated in a number of unsatisfactory deals.
The most common reason I have seen is that the customer is not prepared to put in sufficient effort to design end-to-end services themselves, whilst the vendors are unwilling to extend the scope of their remit towards helping the customer understand their part in making the deal a success - largely because it may make their bid uncompetitive.
If the customer does not have the resources to undertake the necessary assessments to understand the re-design requirements, they should employ a consultancy to do so on their behalf. It is not an option to skimp on this part and my own belief is that all organisations who outsource IT services should retain a core of competence in performing appropriately specialised service design and assessment.
It will save them a lot of pain downstream, will avoid them undertaking sourcing agreements where the commercial expectations are unachievable and, most important, will enable them to design efficient services that can truly delight the end customers.
