ITIL for managed service providers

Transcription

1 ITIL for managed service providers Brian McCabe White Paper August 2013

2 2 ITIL for managed service providers Contents Synopsis 3 1 Managed service providers and ITIL 3 2 Service strategy 6 3 Service design 8 4 Service transition 9 5 Service operation 12 6 Continual service improvement 14 7 Summary 15 References 16 About the author 16 Reviewers 16 Acknowledgements 16 Trade marks and statements 16

3 ITIL for managed service providers 3 Synopsis This White Paper provides a practical review of real-world challenges, ideas and techniques to help managed service providers deliver services aligned with ITIL. The paper focuses on the core ITIL lifecycle stages and how all stakeholders can maximize the business benefits of adopting a structured service governance approach. Many managed service providers use ITIL as a marketing badge of industry compliance or, in some cases, claim to be formally ITIL-accredited, which is simply not possible (only individuals can be accredited organizations as a whole cannot). Most service providers rarely realize the true benefits of introducing best practice in a pragmatic, commercially sensible and clientfocused manner. Others adopt a highly mechanistic approach, following the five core ITIL publications (Cabinet Office, 2011) to the letter and in the process alienating and restricting their clients who may not be totally on board with the finer detail of these books. This White Paper will aid service providers in realizing those business benefits by encouraging them to follow the underlying ethos of ITIL to adopt and adapt the principles, thus adding value to their clients, and their own, business operations. The intended audience of this White Paper is primarily product/ service design specialists and senior operational management within managed service provider organizations. The paper will also be of interest to prospective purchasers of those services who wish to be informed of the challenges faced by the managed service provider and to understand how best to maximize the value to their own business of engaging in such a third-party relationship. Topics covered include: Constructing service offerings that are commercially viable, deliverable and add value to the receiving client organization The blending of the managed service provider s service delivery approach with that of the client and potentially other concurrent service providers while maintaining a consistent and effective set of processes, functions and tools The various staff resourcing models (dedicated, shared, on-site, remote, onshore/offshore/near-shore) adopted by managed service providers Service level management and the risk of poorly considered service level agreement (SLA) or operational level agreement (OLA) targets being achieved at the expense of client satisfaction and long-term service relationships Aligning inter-company SLAs with the client s business requirements The impact of cloud computing on traditional IT service delivery and how managed service providers must adapt their service delivery approach to stay relevant and competitive in the everything-as-a-service world Ensuring financial controls are in place to protect the managed service provider while still delivering true business value to the client Driving continual service improvement in a commercially constrained environment, such that all parties are winners. This White Paper looks at the governance considerations involved in planning for the deployment of the core ITIL disciplines across the managed service provider organization, and also the specific management considerations that can be involved in individual client engagements. The distinction between management and governance is often overlooked. In ITIL terms, management deals with making decisions and executing processes, whereas governance deals only with making sound decisions. Looking at ITIL and its adoption from the perspective of the managed service provider, this White Paper addresses each of the challenges head-on, clarifying some of the myths and misconceptions regarding best practice. It contends that ITIL can be deployed by managed service providers of all types and sizes, and within most budgets. 1 Managed service providers and ITIL Prior to Version 3 (the 2007 edition of ITIL published by the Office of Government Commerce), ITIL was primarily designed for internally delivered IT services, providing guidance for the internal help desk and associated support functions. Following the ITIL Refresh, ITIL V3 became far more relevant to external service providers, acknowledging the plethora of sourcing approaches available to the modern-day IT executive. ITIL Service Strategy (Cabinet Office, 2011) provides high-level views of IT sourcing approaches, as described in Table 1. As can be seen from the standard ITIL definitions in Table 1, managed service providers come in many shapes and sizes, and it is near impossible to provide a one-size-fits-all delivery approach to encompass this breadth of offerings. Fortunately, ITIL s ethos of adopt and adapt, coupled with its modular nature, provides an ideal baseline from which any managed service provider can construct its own service governance model. Full ITIL roll-outs have typically been the domain of the larger systems integrators, but this does not need to be the case, and many small-to-medium-sized service providers are currently missing out on the benefit of this proven best practice. This White Paper aims to dispel many of the myths that are frequently used to justify the reluctance to adopt ITIL, and provides guidance and encouragement for those who are unsure whether ITIL is appropriate for their business.

4 4 ITIL for managed service providers Table 1 Main sourcing structures (delivery strategies) Copyright AXELOS Limited. Reproduced under licence from AXELOS Limited ITIL Service Strategy, Table 3.20 Sourcing structure Insourcing Outsourcing Co-sourcing or multi-sourcing Partnership Business process outsourcing (BPO) Application service provision Knowledge process outsourcing (KPO) Cloud Multi-vendor sourcing Description This approach relies on utilizing internal organizational resources in the design, development, transition, maintenance, operation and/or support of new, changed or revised services. This approach utilizes the resources of an external organization or organizations in a formal arrangement to provide a well-defined portion of a service s design, development, maintenance, operations and/or support. This includes the consumption of services from application service providers (ASPs) described below. Often a combination of insourcing and outsourcing, using a number of organizations working together to co-source key elements within the lifecycle. This generally involves using a number of external organizations working together to design, develop, transition, maintain, operate and/or support a portion of a service. Formal arrangements between two or more organizations to work together to design, develop, transition, maintain, operate and/or support IT service(s). The focus here tends to be on strategic partnerships that leverage critical expertise or market opportunities. The increasing trend of relocating entire business functions using formal arrangements between organizations where one organization provides and manages the other organization s entire business process(es) or function(s) in a low-cost location. Common examples are accounting, payroll and call centre operations. Involves formal arrangements with an application service provider (ASP) organization that will provide shared computer-based services to customer organizations over a network from the service provider s premises. Applications offered in this way are also sometimes referred to as on-demand software/ applications. Through ASPs, the complexities and costs of such shared software can be reduced and provided to organizations that could otherwise not justify the investment. KPO is a step ahead of BPO in one respect. KPO organizations provide domain-based processes and business expertise rather than just process expertise. In other words the organization is not only required to execute a process, but also to make certain low-level decisions based on knowledge of local conditions or industry-specific information. One example is the outsourcing of credit risk assessment, where the outsourcing organization has historical information that they have analysed to create knowledge which in turn enables them to provide a service. For every credit card company to collect and analyse this data for themselves would not be as cost-effective as using KPO. Cloud service providers offer specific pre-defined services, usually on demand. Services are usually standard, but can be customized to a specific organization if there is enough demand for the service. Cloud services can be offered internally, but generally refer to outsourced service provision. This type of sourcing involves sourcing different sources from different vendors, often representing different sourcing options from the above.

5 ITIL for managed service providers 5 ITIL has also been traditionally viewed as being more appropriate to IT infrastructure and telecommunications rather than software applications management providers. Again, this is a myth ITIL is relevant to all aspects of IT service delivery. Managed service providers generally fall into the following highlevel categories: Application management outsourcers (AMOs) AMOs manage off-the-shelf and custom software applications. This category includes application service providers as described in Table 1, but it is broader in definition. AMOs can also manage applications that reside on client s premises or in third-party data centres; such applications include off-theshelf and custom developed solutions. Information technology outsourcers (ITOs) ITOs manage desktops, servers, networks, printers and other supporting infrastructure. Niche providers may deliver only one of the above service types, whereas larger managed service providers will offer both either directly or through the use of partners. The term outsourcing is used in its most generic form above and refers to any external service provider. Clearly the overall service portfolio will vary greatly between managed service providers, where the focus may be on specific technologies, delivery methods or particular market sectors. In many cases, the managed service provider will itself sub-contract services to a third-party supplier as part of an aggregated service delivery model, or partner with other service providers in a consortium. ITIL, when deployed effectively, provides a highly efficient framework for such multi-faceted, multi-sourced environments. Service providers can significantly broaden their service portfolios by adopting a robust service governance model as a catalyst to partake in multi-sourced arrangements. In expanding its portfolio the managed service provider also expands the size of the available market for its services. Even in cases where the managed service provider has limited appetite to partner or sub-contract services, an effective service management approach will reduce process inefficiencies and generate opportunity for growth. As a commercial enterprise, these are clearly attractive propositions. A study by Gartner (2009) showed that just over half of the surveyed companies selected a single managed service provider for both infrastructure and applications. Managed service providers who are able to provide a greater breadth of services either directly or through effective partnership with other service providers will have access to a far broader share of the available market than those who do not. By adopting ITIL, the service providers will also communicate using a common language and have more compatible core processes than those who adopt a purely home-grown approach to service management. From a client s perspective and also that of other service providers who may be working as part of a partnership ITIL adoption builds confidence and reduces any potential resistance to engage with the managed service provider. The time taken to transition services is reduced due to the use of a common language; ongoing communication and collaboration are also far less ambiguous. From a personnel resourcing perspective, managed service providers deliver service using a range of models, including: Dedicated resources Where one or more named individuals are dedicated to work on a single client engagement. Such engagements result in a close affinity between the managed service provider s resources and the client s IT systems. Depending upon the ratio of client staff to managed service provider staff, this can often result in one of the following situations: Where the client staff outnumber the managed service provider staff, the managed service provider augments the client s own team while adopting the client s processes, tools and methodology. In such cases the managed service provider may feel that it is restricted in its ability to influence improvement and standardization of approach, with managed service provider personnel potentially going native within the client organization Where the managed service provider staff outnumber the client staff, the managed service provider has greater influence over the introduction of its own standard processes, thus driving a level of consistency for its own services but at the risk of isolating that provider from the rest of the client organization unless the integration of the two approaches is relatively seamless. Shared resources Where the managed service provider s staff can work on multiple clients in parallel, thus passing on the commercial economies of scale and breadth of experience to the client in the form of reduced costs and potentially broader technological experience. The methodology challenge for the managed service provider in this model is to construct an approach that is familiar to its own staff, regardless of which client they are working with, while not forcing the client into a totally unfamiliar way of working. ITIL provides the flexibility required to strike this balance but will require some creative thinking at times to arrive at a mix and match portfolio of service processes, functions and tools. Blended resources Where a single contract is fulfilled by a combination of dedicated and shared resources, often in a flexible model, where the headcount can go up or down based on client demand. This combination clearly carries the pros and cons of both the dedicated and shared resourcing models and, if not managed correctly, can lead to confusion within the service provider s own teams regardless of how the client operates. In the dedicated model, the resources may be physically located at the client s premises or they may be located remotely, as is usually the case with the shared model (see Figure 1). Some managed service providers (for example, break-fix hardware

6 6 ITIL for managed service providers engineers) will deliver mobile services, visiting the client location only when required. These can also be delivered using either a dedicated or shared approach. move to cloud delivery of commodity services begins to drive a convergence of application management and business process management. The remainder of this White Paper will focus on several of the key discussion points that impact on the adoption and positive contribution of ITIL within the external managed services sector. These topics will be covered under the framework of the ITIL service lifecycle stages, and in the form of responses to commonly held misconceptions regarding such service adoption, accompanied by some critical success factors specific to managed service providers. Figure 1 Resourcing matrix for managed service providers The challenge of building a robust service management approach that works in harmony with client operations is further complicated in multi-sourced engagements. Common sense dictates that having a common language can vastly simplify the creation of a coherent, multi-party service governance model. That common language is provided within the ITIL framework. Additional challenges can arise for managed service providers when their organization provides a mixture of offerings to the same client base for example, consulting or project-based services alongside ongoing managed services. The interplay between project- and service-based delivery can be a significant hurdle to service quality and client perception if not addressed correctly. Section 4 relating to service transition focuses on these challenges. The sourcing and delivery strategies mentioned above do not apply solely to IT services. Business process outsourcing (BPO) can also deliver value to end-user organizations by subcontracting specific typically back-office processes to a third party. Those services are outside the scope of this White Paper but we would expect the lines between ITOs, AMOs and BPO to become even more blurred as time progresses and the 2 Service strategy Service strategy for managed service providers is primarily a commercially focused exercise in determining the business case for both the managed service provider and its prospective customer(s). Figure 2 provides a summary of the service strategy stage of the lifecycle. Depending upon the target customer profile and engagement size, the managed service provider may define a strategy around a single large account or, more usually, create a portfolio of standard service offerings that can be tailored (typically during service design) to fit with individual customer needs. Key considerations for managed service providers are: Which services to take to market How to structure those services The delivery methodology (staff resourcing approach, on-site versus remote etc.) What type of organization will buy the service, and why The market appetite for such services, the size of the target sector, and the expected market penetration rate How much the service will cost to deliver How to charge clients, and what approach to adopt to arrive at such pricing (for example, value-based or cost-plus) while still demonstrating a tangible return on investment for the client What charging model(s) to offer for example, pay-per-use, fixed price, time and materials, shared risk/reward model? Figure 2 Lifecycle summary service strategy

7 ITIL for managed service providers 7 How to ultimately drive business value for the managed service provider s organization and for the client business; and how to measure and report this value. Many managed service providers will launch services without considering all of these aspects, often resulting in a substandard and/or failed service offering. The service strategy processes ensure that the managed service provider thoroughly qualifies a service offering before committing precious marketing and service development funds to the initiative. Some popular misconceptions The IT services my company delivers will not work with ITIL. All IT service delivery models can benefit from ITIL-aligned service governance. ITIL s philosophy of adopt and adapt provides a flexible framework of best-practice guidance which the managed service provider can tailor to fit with its own operations, introducing ITIL in a phased and pragmatic manner. This is true whether the managed service provider is delivering support for a commoditized product or managing a highly customized solution, or whether it is resourcing the service with dedicated personnel or using a shared pool of people resident on the other side of the world. It makes no difference whether the managed service provider is charging for the service on a pay-per-use or fixed-price basis, or any combination of these; a pragmatic adoption of ITIL best practice will undoubtedly deliver benefit to the managed service provider and its clients. The same rules of ITIL adoption apply to managed service providers as they do to end-user organizations. The managed service provider must: Create an achievable, detailed and measurable plan for process adoption. Without such a plan the managed service provider will not know when it has been successful Obtain senior management buy-in to the plan and the required resources (monetary, effort, tooling etc.). Otherwise, the risk is that the scope may be changed or, worse still, the programme may be cancelled if such a commitment has not been received Nominate an owner who is responsible and accountable for the introduction of this best practice. A focal point is vital for measuring progress against the plans and also to act as mediator in the case of any uncertainty Clearly communicate the plans to all stakeholders, ensuring that all parties are aware of the plans and the progress made against those plans Perform a post-implementation review and embark on a programme of continual service improvement. Lessons can always be learnt from any programme of work. These should be documented and communicated to relevant parties. The review also forms the baseline for future enhancements. This does not have to be a sizeable programme of work for a smaller managed service provider wishing to adopt, for example, a best-practice incident management process. There is a wealth of public domain knowledge and advice available, backed by an ever-maturing and affordable set of tools to assist the managed service provider on this journey. Cloud computing signals the end of ITIL for service providers Technological advancements will inevitably move at a pace with which the best-practice methodologies appear unable to keep in step. ITIL is no exception to this and the pure logistics of regularly updating such a significant body of work should not be underestimated. That said, The Stationery Office the publisher of the five core ITIL publications recognizes this and regularly produces complementary materials to ensure that the content remains current. Additionally, the core publications are structured in such a way that they will continue to be highly relevant to a broad array of existing and emerging technologies. A commonly held misconception is that the apparent paradigm shift towards cloud computing renders the rigour of ITIL redundant. Nothing could be further from the truth, although a level of interpretation and updating of the underlying common sense approach may be necessary to cater for such technological evolution. At a time when service components are being supplied from disparate and often faceless web-service providers, core business applications are being rented in multi-tenanted deployments, and data can reside on the other side of the world from the end-users, the need for a strong service governance model, backed by flexible service management processes, is more important than ever. Cloud computing introduces many benefits to end-user organizations who need to be agile, have few capital assets and pay only for what they consume. That said, the risks of moving to this new service approach are plentiful. A strong service governance approach may not solve all of these, but at least the organization will have an understanding of where such risks lie and will be able to mitigate them in the most appropriate manner. In a world where cloud-based managed service providers will probably never meet with their end-users there is a temptation for the managed service provider to feel isolated from the user base. As a result the managed service provider may not feel as obligated to deliver against those users expectations as they were in the traditional pre-cloud delivery model. This is a dangerous attitude to adopt, especially as the marketplace for such services continues to expand exponentially on an almost daily basis. Competition will be strong and only those managed service providers who do not overlook the continued need for robust and business-grade service governance models will survive. Collaboration in the cloud not only requires common technology platforms, it also requires common delivery methods. The need for managed service providers to communicate with their clients using a common language and for their predominantly remote clients to feel comforted by the adoption of such methods is possibly more important in the cloud environment than it has ever been before.

8 8 ITIL for managed service providers The view that ITIL will become more rather than less important as IT continues to evolve at such a rate is not confined to cloud computing. It is equally applicable to other hot topics such as bring-your-own-device (BYOD), Big Data and other hype-curve resident technologies. Critical success factors for service strategy The factors that will make a managed service provider s service strategy successful centre around the identification of a viable market need and the production of a service package that: Has the support of the key stakeholders within the service provider organization Is marketable and attractive to the target client sector Is commercially viable for the managed service provider, and any partners or sub-contractor organizations who may be involved in the eventual delivery of the service Adds business value to both the managed service provider and the receiving client s business operations Is capable of being successfully delivered. 3 Service design For managed service providers the service design lifecycle stage is where ideas turn into reality, whether this is the instigation of a new service or service line, or the review of enhancements to existing services. Figure 3 provides a summary of the service design stage of the lifecycle. Key activities for managed service providers as part of service design include: Using the service package as input to the process; this ultimately results in one or more detailed service design packages Registering the services within the service catalogue, or noting them for future registration, depending upon local policies Recruiting third-party suppliers where required Constructing baseline SLAs, OLAs and underpinning contracts Addressing any specific service management requirements Considering the key requirements of availability, capacity, security and service continuity Considering systems and event management requirements and specifying measurement, alerting and reporting systems. Some popular misconceptions My clients have their own processes so they won t use mine. A blended service management approach is often required in commercial engagement models. By adopting the core ITIL principles the managed service provider is better positioned to engage in such discussions with its client from a position of knowledge and strength. Elements of both the client s and the managed service provider s processes can then be engineered to work in harmony during the service design and service transition stages for the specific client engagement. Simply because a client has its own service governance model does not exclude the introduction of ITIL-aligned managed service provider processes quite the opposite, in fact. Service strategy actively encourages client organizations to engage with providers who are compliant with ISO/IEC standards. Doing so helps clients minimize the risk from outsourcing of the affected services. Managed service providers who follow ITIL are more likely to be successful in the supplier selection process of those clients than those who do not. Customers always complain if I m hitting the SLAs it can t be that bad. SLAs need to be aligned to the critical success factors of the business. If there is a mismatch when the SLAs are agreed during service design then the service will invariably fail to meet the overall business objectives. Figure 3 Lifecycle summary service design

9 ITIL for managed service providers 9 Focusing too much on mechanistically adhering to SLAs can be damaging to the client relationship and the end-user service as a whole if (a) the service is not viewed in its entirety, and (b) if the SLAs themselves do not adequately align with the overall business objectives. SLAs vary greatly depending upon the services being offered. For product-based managed service providers or providers who deliver largely commoditized services, these are typically rigid agreements leaving little room for negotiation. These providers generate value for their own businesses by having a large number of near-identical client engagements. At the other end of the scale, managed service providers who provide highly customized services combining a range of service components into a bespoke offering for a single client will inevitably need to negotiate a specific set of SLAs for that one engagement. Internal OLAs and underpinning contracts with sub-contractors need to be negotiated in parallel to ensure the risk profile remains acceptable. At the same time, managed service providers should not lose sight of the need to remain commercially competitive and deliver value to all stakeholders. This is a difficult balance to strike and is the first point in the relationship where the sales pitch can easily turn into far more challenging discussions. These negotiations generally set the tone for the lifetime of the service, and it is vitally important that they are undertaken in a professional and consultative manner. They should not promise too much nor devalue the overall service proposition. The managed service provider must ensure all SLA targets adhere to the SMART acronym (Specific, Measurable, Achievable, Relevant and Time-bound), and avoid being inadvertently coerced into continuing the inevitably more ambiguous messaging that may have shrouded the sales cycle up to that point. The key business benefits communicated during that sales process need to be reflected in the SLA. If the SLA bears little or no resemblance to the business case then it will either be dismissed out of hand by the client or, even worse, the managed service provider and client will be working to totally different agendas. Poorly constructed SLAs can result in the situation where a managed service provider is measuring and reporting on metrics that have no direct influence on the success (or otherwise) of its client. This is where one of the core doctrines of ITIL to align IT with the business has been disregarded and the relationship between the managed service provider and the client will undoubtedly suffer as a result. The construction of SLAs can be time-consuming, and rightly so. It is dangerous to view the SLA as part of the clerical activities of drawing up contracts, under the misconception that these things will be corrected later. The managed service provider should also review the SLAs, OLAs and underpinning contracts on a regular basis during service operation, especially during periods of significant business change or IT system change, to ensure that the business alignment remains. In this way, continued consistency of the IT services and the business objectives is maintained and, for the managed service provider, it also generates opportunities for incremental revenue. Section 4 highlights how a clear service scope, coupled with a structured change management process, can make the difference between commercial success and failure for the managed service provider. Critical success factors for service design The factors that will make a managed service provider s service design successful are: A successful translation of the business case from service strategy into a more tangible service design package The construction of a consistent set of agreements that align with the intended services, and protect the managed service provider while delivering value to all stakeholders Measurement and management systems, with supporting processes, to ensure that a baseline for continual service improvement can be defined Buy-in from all stakeholders and confirmation that the business objectives defined in service strategy are still attainable as the process moves to the service transition stage. 4 Service transition Service transitions come in various guises for managed service providers, each of these bringing its own specific considerations and opportunities. Figure 4 provides a summary of the service transition stage of the lifecycle. The three most common types of transition in a managed service provider business are: New systems coming into service for the first time. These break down into two sub-categories: Those that have been developed or constructed by the managed service provider s own organization and are now moving into the service operation stage. We will term these build-and-run transitions for the purposes of this paper. A new system that has been developed by the client or another third-party organization for which the client is now requesting service from the managed service provider. Existing systems for which the managed service provider is inheriting support responsibilities, either from another third-party provider or from an insourced team as part of a (selective) outsourcing arrangement Major change to systems already supported by the managed service provider.

10 10 ITIL for managed service providers Figure 4 Lifecycle summary service transition Without doubt, the most challenging of all the above is the build-and-run transition. There are many reasons for this, including: The client believes, quite correctly, that it is receiving continuity of services from a single service provider for both the build and run elements. In the majority of cases, however, the project to build the solution will have been executed by a separate division of the service provider organization from the one that is destined to run it for the longer term. The project team s objectives are typically to complete the work as promptly and efficiently as possible so that it can move to the next engagement as soon as user acceptance has been achieved. The support organization aspires to inherit a system that has been rigorously tested, is fully documented and will attain a steady support state in record timing. There is clear scope for a misalignment of objectives here. The client, as mentioned previously, is dealing with a single organization so does not anticipate a handover of responsibilities between groups and is unlikely to want to fund such a handover as part of its service transition fee. To add further risk, the client s perception is often that, because the service provider is not simply walking away, it does not need to undertake a rigorous level of user acceptance testing as the managed service provider will still be around to fix any issues after the go-live date. If the service is not correctly designed earlier in the lifecycle and managed appropriately during the actual transition, all of these factors will combine to make a very dangerous situation where the client s first impressions of the managed service provider are irreparably damaged at the outset. A formal and transparent service transition project is vital for the successful navigation of this lifecycle stage. ITIL dictates that value can only be delivered when both utility and warranty are present (see ITIL s value formula depicted in Figure 5). Warranty ensures that a service is fit for use and utility ensures that it is fit for purpose. Without warranty, for example, a payroll system may calculate people s salaries correctly, but that is of no value if the system is unavailable each pay day, or performs so slowly that people are not paid on time. Conversely, if a system is technically robust but functionally flawed, this is also of no overall benefit. In build-and-run transitions the two phases can sometimes concentrate too heavily on one aspect of the value function, only for the service transition phase or, worse, issues with the production system to highlight this imbalance too late in the day. There is no single silver bullet to ensure success on build-andrun transitions. However, some combination of the following techniques will help minimize the risk of major failure: Ensure that the service transition activities are agreed, documented and clearly communicated during the service design stage. Figure 5 Services are designed, built and delivered with both utility and warranty Copyright AXELOS Limited. Reproduced under licence from AXELOS Limited ITIL Service Transition, Figure 2.2

11 ITIL for managed service providers 11 Ensure that the client is fully informed of the complexities in any service transition of this type. It is tempting to oversimplify this process, especially during the sales cycle, but well-informed and mature clients will be supportive of the challenges if they feel part of the project rather than being left ill-informed of the risks to their business and personal reputations. The managed service provider should ensure that the client fully understands its own responsibility to undertake an appropriate level of user acceptance testing and due diligence of the system before permitting it to go live. This can be encouraged through the introduction of as built clauses (where the client pays for any remedial actions for defects which were not highlighted in its acceptance of the solution), SLA amnesties and other such techniques. However, these can appear punitive if not positioned in the overall context of striving for joint success. Do not underestimate the elapsed time or resource requirements to enable a knowledge transfer between the different parts of the service provider organization. Well in advance of the project actually commencing, agree at what point the project team will be released from its obligations. That trigger point is often the end of user acceptance testing and the managed service provider becomes responsible for a system of which it has limited knowledge before it has even gone live. One way to avoid this is to include service transition and early life support (ELS) as integral phases within the build project plan and not to allow the project team to exit the client engagement until such time as the system has attained pre-agreed service performance targets (volume and severity of defects raised, number of incidents logged etc.). Provide financial incentives for the stakeholders to work collaboratively during the service transition: Clients may benefit from a reduced project or service fee if they actively participate In larger service providers the build and run teams may operate under separate internal profit-and-loss controls and this can frequently drive incorrect behaviours unless checked. All parties must be encouraged to work toward the single shared goal of successful transition. Promote a one-team approach by seeding members of the support organization into the project team, or rotating staff members from projects into support on a project-by-project basis. This also helps to transfer knowledge into the ongoing support functions. Ensure that the key foundations for achieving warranty are not overlooked in the build phase. A business application may deliver utility, but it should not enter into production if: It is not being proactively monitored by an effective event management system It has not been load-tested to ensure sufficient capacity Failover to the secondary data centre has not been tested to confirm business continuity Clients who are not actively involved in the transition process may focus their testing primarily on the utility aspect. The warranty aspects of the solution should be considered at the design stage and built into the transition plan so as not to be inadvertently overlooked or intentionally bypassed. Other non-build-and-run transitions are much less complicated to manage into service and generally include a sub-set of the considerations above. Some popular misconceptions Service transition is the responsibility of the managed service provider. This is incorrect. As with all aspects of a multi-party service, all stakeholders have a joint responsibility to ensure success. A single-team approach with clear objectives and cross-party responsibilities is vital to the success here. A RACI model showing who is responsible, accountable, consulted and informed is an excellent technique to help govern service transition activities. Change management is a bureaucratic and time-consuming process that is normally circumvented in some way. This is also clearly incorrect. The statement above applies if the change management process is badly designed and implemented, but change management should form a vital part of a strong service management ecosystem. As a managed service provider is a commercial organization, the change management (and also request fulfilment) process can help it to achieve incremental revenue. In most cases, the managed service provider can charge more money for changes and enhancements to systems. A client will be happy to fund these changes as long as they are adding measurable value to its operations. On the other hand, when individuals circumvent the change management process (typically by including it as part of incident management or problem management), not only do they risk damaging the overall stability of the solution but they also give the client free incremental benefits for which they could be charging more money. An effective change management system, backed by a well-structured education campaign, can often make the difference between the success and failure of a service engagement between the managed service provider and the client. One way of making the change management process more usable and streamlined is to actively encourage the development of a library of standard service requests for more commonly occurring system changes. The managed service provider can then potentially automate these activities, promoting such features as self-service provisioning, to minimize risk for the client and maximize its own commercial benefit.

12 12 ITIL for managed service providers The customer has its own change management process so we don t need our own. The choice of whose system and processes are to be used is not clear-cut and is not necessarily a simple discussion about whether to use one or the other. There will indeed be cases where clients have mature and robust change management processes already in place. Using these can be the logical choice from a client governance perspective, especially in multi-sourced arrangements where the client has to consider a broader impact footprint than the single service that the managed service provider may be delivering. However, such processes will have been designed by the client, for the client, and may not take into consideration the service provider s requirement to manage its own risk and control its own commercial implications. Hence, the managed service provider must undertake a gap analysis of the client s processes in the light of its own requirements and either augment this with its own additional processes or, in some situations, work with both change management systems should the need arise. Of course, there will be occasions when one or other system fulfils all the stakeholders requirements, in which case the single-system approach is fine. The managed service provider must not, however, settle for a single system which fulfils most but not all of its own internal governance requirements. This is a key decision which affects the commercial balance of an agreement, so it should be considered during the service design stage when contracts and SLAs are being constructed. Release management is part of the change management process. ITIL correctly states that a release comprises one or more change requests so, by definition, these are two distinctly separate but related processes. Unfortunately, this concept is not upheld by the majority of the software tool vendors who provide IT service management products. Consequently the process evolves into one where release management is either dropped as a separately defined discipline altogether, or into a one-to-one mapping between change requests and release results. Such compromises can introduce issues whereby, for example, one change needs to be released into multiple environments and is not accurately tracked, or where a release could legitimately be partially rolled back due to the failure of a single change. The lack of granularity in tracking such activities can cause confusion and increases the risk of incorrect results being assumed and catalogued as such in the configuration management system (CMS). The ability to track the status of all configuration items (CIs) accurately through the change management and release management processes is vitally important to the integrity of the overall service. To manage change effectively you must have a single, consolidated configuration management system. This is incorrect on two footings. Firstly, the lack of a formal CMS can, if permitted, be used as an excuse for bypassing the change management process and introducing the resultant issues described above. Change management is still a mandatory discipline and can function, albeit to a more limited extent, without the presence of a CMS. Secondly, the once-held view that configuration management was predicated on having a single master database, the configuration management database (CMDB) that contains all CI metadata, is no longer represented in ITIL best practice. A federated model, whereby configuration data is maintained in an array of controlled sources (paper files, spreadsheets, databases, version control systems etc.), is equally compliant with best practice. What is more important is that the content of those repositories is maintained in a controlled manner that accurately reflects the real-world status of the systems in which those CIs are used. Critical success factors for service transition The factors that will make a managed service provider s service transition successful are: A clearly defined service transition process where all stakeholders share the same goals and are actively encouraged to achieve them in a collaborative manner A usable, non-bureaucratic, yet enforced change management process, supported by an effective CMS A clear set of acceptance tests for the service being agreed during the service design process and managed under a robust validation and testing process. 5 Service operation The service operation lifecycle stage contains those processes most commonly associated with the work of managed service providers. This is particularly so in the case of incident management, which is where most providers start on their ITIL adoption journey. Figure 6 provides a summary of the service operation stage of the lifecycle. Clearly there is more to ITIL and good service management than the reactive management of incidents. Service operation begins where service transition leaves off and, as mentioned in section 4, a successful transition can itself continue well into production, running in the form of early life support (ELS). It is, however, vitally important that ELS is managed in accordance with the service operation framework, with all potential defects being tracked through incident management and problem management (where required), potentially also looping back into change and release management. Without this, the perception of the service will be

13 ITIL for managed service providers 13 Figure 6 Lifecycle summary service operation that it is not truly live, and introducing a formal process will be much more difficult at a less clearly defined later stage in its evolution. From a client perspective, the key processes of event management, incident management, problem management and request fulfilment are all present to ensure that value is delivered to their end-users. This statement also stands in the case of the managed service provider and, additionally, the correct application of these disciplines enables the managed service provider to commercially manage the account in a far more effective manner. ITIL s definitions of these processes (see the glossary in ITIL Service Operation) provide a framework within which the managed service provider can draw clear demarcation lines between those elements of the service that are included and those that are not. By adopting and, where necessary, liberally quoting ITIL processes, the managed service provider can successfully navigate discussions which might otherwise have been far more challenging had the processes appeared to be the managed service provider s own policy rather than industry best practice. Adopting an effective problem management approach can reduce the amount of labour the managed service provider is required to provide to service the client and allows them to potentially redeploy that resource on other revenuegenerating activities. Once a managed service provider has a clear library of service requests it can subtly encourage the client to use these, thereby cutting down on any unnecessary administrative overhead from processing such changes through change management and release management. The managed service provider can then benefit from automation and self-service techniques to further reduce the resource demand and associated operating costs. Although these actions may appear slightly underhand, they would not be successful if the managed service provider did not deliver value to the client s business as a result. Both parties also benefit from continual service improvement and, when the agreement eventually becomes due for renewal, are more likely to wish to continue the relationship and look at more creative ways of ensuring that the services evolve rather than become static and wither in the light of business change. Some popular misconceptions It s just a ticketing system. To managed service providers, an effective ITIL implementation is clearly more substantial and more beneficial to all parties than simply taking a standard helpdesk application and renaming the ticket entity as an incident. Any managed service provider who thinks that by introducing incident management and using the correct terminology it will be instantly aligned with ITIL is sadly mistaken. Although this is undoubtedly a step in the right direction, it is by no means where the managed service provider should be aspiring or planning to be. Only by coupling incident management with the other processes is the true benefit realized. Although IT systems naturally tend to excite technologists, choosing the correct service management tool should be the final step in determining the managed service provider s service approach. The overriding business case, the core processes, the desired outcomes and the marketability of the approach need to be considered prior to starting to look for platforms to help fulfil these. Rest assured, there are many tools out there to choose from once the managed service provider has decided on its own service governance approach. Another common tools-based consideration for the managed service provider is whether it should integrate its own service management systems with those of the client and potentially other third-party providers. The benefits of such integration are clear in that it provides a single, consistent view of the service and eradicates the effort and risk of double-keying data into multiple systems. However, the challenges of achieving such a seamless integration should not be overlooked and these are rarely considered in sufficient detail before embarking on such a project. Common failings include:

14 14 ITIL for managed service providers Systems having conversations with each other without any human involvement. For example: Thank you for your request. Here is your incident ID. Thank you for your request. Here is your incident ID and so on Tightly integrated systems limiting agility and restricting future development of the core service management application Underestimating the complexity of mapping the different workflows and request status changes between the systems Complex systems interfaces being developed and maintained for a relatively low volume of actual transactions. As with all projects, the user requirements and business case for change should be clearly documented and agreed prior to embarking on any form of development activity. With the increase of multi-sourced service engagements and the upsurge in cloud-based service management tools, there is undoubtedly a business case for a common standard or hub for integrating such applications. Until then, the basic rules of any software project undertaking should apply. Problem management is just incident management without SLAs. Problem management and incident management are fundamentally different both in their reasons for being and the way in which they operate. Primarily through ignorance of the very tangible benefits which an effective problem management process can bring to a service, two things can happen: Managed service providers can unscrupulously redesignate incident records as problem records to avoid any related SLA targets Clients can demand artificial time-bound restrictions on the resolution of problem records, thus turning them back into incidents and not actually addressing the root cause. More appropriate key performance indicators can be used to help guide problem management without negating the benefit that it brings. These generally measure the overall problem management process rather than individual incidents, and are calculated over an extended period of time when compared to incident management. This has a key positive influence on continual service improvement. Critical success factors for service operation The factors that will make a managed service provider s service operation successful are: A clear and conjoined set of processes governing each of the core service operation processes. Each must comply with the underlying ITIL principles An event management solution that tests and reports on metrics which are aligned with the SLA and business objectives of the IT service Proactive service operation in the form of an effective problem management approach. 6 Continual service improvement The two underpinning principles of ITIL are to align IT with the business and to drive continual service improvement (CSI). These remain just as relevant in commercial service management relationships as they are in traditional insourced delivery operations. Figure 7 provides a summary of the CSI stage of the lifecycle. To improve a service you first need to be able to measure it and report against a relevant set of metrics. Accurate and timely measurement is dependent upon deploying tools and reports that not only review the system being managed (performance times, availability etc.) but also report on the service management processes (SLA adherence, incident ageing, problem management ratios etc.). Additionally, the subjective measurement of client perception is of equal, if not greater, importance to the more mechanistic measurement of system and process metrics. In a managed service provider/client relationship, SLA compliance levels count for little if the key client contacts do not actually enjoy working with the managed service provider. Gauging customer satisfaction is a vital component in ensuring that the service is continuing to deliver value in the eyes of the individuals who will ultimately have a say in whether the service agreement is renewed when it has run its term. Figure 7 Lifecycle summary continual service improvement

15 ITIL for managed service providers 15 The managed service provider should also be reporting metrics for its own internal continual service improvement, with a focus on doing more for less, driving improved services to the client with a lower cost base for delivering those services. Process and technology efficiencies can often make the difference between commercial success and failure for a managed service provider. The client should encourage the managed service provider to succeed as, without that success, there will be no service and all stakeholders will suffer. The managed service provider and the client should regularly discuss improvement initiatives in the form of service improvement plan review sessions. These discussions may form part of the normal service review cycle or they may be held during a periodic specific improvement-focused session. The accurate measurement of, and striving for improvement in, service metrics has taken on added significance with the advent of performance-based payment incentives. In this model, managed service providers are either rewarded for improved service levels or penalized for lack of improvements as promised. This kind of risk/reward model, where the service provider is rewarded based on delivering real business benefit, is only possible when the measurement system aligns IT with that business, and is trusted by all parties. Any managed service provider who is unable to measure service metrics at such a level will disqualify itself from potential business, as event management and reporting capabilities are now critical not only to technological wellbeing but also to the future growth and success of the managed service provider s business. The Deming Cycle of Plan-Do-Check-Act (see Figure 8) and the ITIL seven-step improvement process have never been as important as they are today in a modern relationship between a client and its managed service provider. Continual quality control and consolidation Maturity level ACT CHECK PLAN DO Figure 8 Plan-Do-Check-Act cycle Plan Project plan Do Project Check Audit Act New actions Timescale Business IT alignment Effective quality improvement Consolidation of the level reached i.e. baseline Copyright AXELOS Limited. Reproduced under licence from AXELOS Limited ITIL Continual Service Improvement, Figure 2.8 To help drive CSI, many service providers now reward their personnel with a bonus payment or other such incentives based on these measurements. This can be a highly effective way of delivering value to the client while also protecting the managed service provider s continued relationship with the customer. A popular misconception Continual service improvement? It must be monthly report time. Continual service improvement the production of service reports and the overall review of service performance should not just be a daily activity that is performed solely because it is a contractual commitment between the managed service provider and the client. It must focus on acting on the findings of the service performance reports, communicating actions and progress against these to all involved parties, and driving a steady rate of controlled, forward-momentum change. Critical success factors for continual service improvement The factors that will make a managed service provider s CSI successful are: A measurement and reporting solution that is trusted and aligned with business goals A communications and education programme based on encouraging continual service improvement, with shared goals for all parties Client buy-in to allow the managed service provider to benefit from driving improvement. 7 Summary In recent years ITIL has become far more applicable to commercial service management engagements and, when introduced in a considered manner, will actively contribute to the success and wellbeing of all stakeholders. Managed service providers who fail to adopt this best practice will find themselves being disqualified from business opportunities, becoming incompatible with other providers who deliver to the same clients, and failing to capitalize on the delivery efficiencies of the common-sense approach of ITIL. Managed service providers who have previously paid lip service to ITIL, using it primarily as a marketing badge, are now being exposed by better-educated buyers who are demanding tangible evidence of robust service management discipline and showing a willingness to reward those providers based on shared business success. There are potential pitfalls along the road to deployment, but a pragmatic and staged approach leveraging the wealth of knowledge available in the ITIL publications and other public domain sources will ensure a rewarding path to opportunity and service success.

16 16 ITIL for managed service providers References Cabinet Office (2011). ITIL Continual Service Improvement. The Stationery Office, London. Cabinet Office (2011). ITIL Service Design. The Stationery Office, London. Cabinet Office (2011). ITIL Service Operation. The Stationery Office, London. Cabinet Office (2011). ITIL Service Strategy. The Stationery Office, London. Cabinet Office (2011). ITIL Service Transition. The Stationery Office, London. Gartner (2009). User Survey Analysis: Economic Pressures Drive Cost-Oriented Outsourcing, Worldwide, Available from About the author Brian McCabe is a chartered IT professional with over 25 years experience of delivering IT systems. Originally from a technical background, Brian is an ITIL Version 3 Expert and an official reviewer of ITIL Continual Service Improvement (Cabinet Office, 2011). Brian specializes in building and growing service delivery organizations and is a director of the London-based Oracle specialist consulting and services firm, Mokum Change Management. Acknowledgements Sourced by TSO and published on Our White Paper series should not be taken as constituting advice of any sort and no liability is accepted for any loss resulting from use of or reliance on its content. While every effort is made to ensure the accuracy and reliability of the information, TSO cannot accept responsibility for errors, omissions or inaccuracies. Content, diagrams, logos and jackets are correct at time of going to press but may be subject to change without notice. Copyright TSO and Crown. Reuse of this White Paper is permitted solely in accordance with the permission terms at Centre/White-Papers/ A copy of these terms can be provided on application to Best Management Practice White Paper Permissions, TSO, St Crispins, Duke St, Norwich, Norfolk, NR3 1PD, United Kingdom. Trade marks and statements ITIL is a registered trade mark of the AXELOS Limited. Reviewers AXELOS Limited and TSO would like to thank Lou Hunnebeck (Third Sky Inc.) and Jonathan Wright for reviewing this White Paper.