Service Transition Processes Tutorial

3.2 Basic Concepts

Before we start with the core processes let us understand the concept of SDP (pronounced as S-D-P) which acts as an input to transition. SDP refers to the Document(s) defining all aspects of an IT service and its requirements through each stage of its lifecycle. A service design package is produced for each new IT service, major change or IT service retirement. The Service Design Package (SDP) contains the following information required by the service transition team: • It contains the applicable service packages (e.g. core service package, service level package) • SDP also will have the service specifications along with a service models • SDP need to have the architectural design required to deliver the new of changed service including constraints • SDP has to contain clear definition and design of each release package and detailed design of how the components will be assembled and integrated into a release package • SDP also will have the blue print of release and deployment plans • Lastly but the most important SDP will have the SACs(pronounced as S-A-C) from the customer. Let us continue to learn about few important terms of lifecycle in the next slide

3.3 Basic Concepts

So far, we have discussed about certain pointer of SDP, in this slide let us look at the basic terms used across the lifecycle We used the term SAC in our last slide which is Service Acceptance Criteria SAC is a set of criteria used to ensure that an IT service meets its functionality and quality requirements and that the IT service provider is ready to operate the new IT service when it has been deployed. Change as a term refers to the addition, modification or removal of anything that could have an effect on IT services. The scope should include changes to all architectures, processes, tools, metrics and documentation, as well as changes to IT services and other configuration items. Let’s continue with these terms in the next slide.?

3.4 Basic Concepts

In continuation to our last slide this slide further explains some more terms. Let us understand these in detail. Release is referred to one or more changes to an IT service that are built, tested and deployed together. A single release may include changes to hardware, software, documentation, processes and other components. A Release Package is a set of configuration items that will be built, tested and deployed together as a single release. Each release package will usually include one or more release units. A Release Unit can be described as the Components of an IT service that are normally released together. A release unit typically includes sufficient components to perform a useful function. For example, one release unit could be a desktop PC, including hardware, software, licenses, documentation etc. A different release unit may be the complete payroll application, including IT operations procedures and user training. So far we were introduced to various terms used in lifecycle, let us proceed to learn about the Service Transition processes in detail.

3.5 Transition Planning And Support

The ITIL 2011 publications follow a systematic and consistent approach in presenting the various aspects of each service lifecycle stage and the various processes. Within Service Transition, we shall be discussing seven processes. The first one is ‘Transition Planning and Support’.

3.6 Purpose And Objectives

It is a proven fact that proper planning is crucial for the success of desired outcome. Transition planning and support is mainly concerned with ensuring that all relevant plans for Service Transition are in place and the support and coordination activities are taken care of, to ensure smooth and successful transitioning of new, changed or retired services. The purpose of Transition Planning and Support is to provide overall planning for service transitions and to coordinate the resources that they require. The objectives of Transition Planning and Support process are to : • Plan and coordinate the resources to ensure that the requirements of Service Strategy encoded in Service Design are effectively realized in Service Operation; • Coordinate activities across projects, suppliers and service teams where required; • Establish new or changed services into supported environments within the predicted cost, quality and time estimates; • Establish new or modified management information systems and tools, technology and management architectures, service management processes, and measurement methods and metrics to meet requirements established during the Service Design stage of the lifecycle; • Ensure that all parties adopt a common framework of standard re-usable processes and supporting systems in order to improve the effectiveness and efficiency of the integrated planning and coordination activities; • Provide clear and comprehensive plans that enable customer and business change projects to align their activities with the Service Transition plans; • Identify, manage and control risks, to minimize the chance of failure and disruption across transition activities; • Ensure that Service Transition issues, risks and deviations are reported to the appropriate stakeholders and decision makers; and • Monitor and improve the performance of the Service Transition lifecycle stage. Let’s understand the scope of Transition planning in the next slide.

3.7 Scope

It is essential to define the scope of any process being implemented to ensure that people involved in executing the process are aware of what activities are included and what are excluded from the purview of the process. The scope of Transition Planning and Support includes: • Maintaining policies, standards and models for Service Transition activities and processes; • Guiding each major change or new service through all the Service Transition processes; • Coordinating the efforts needed to enable multiple transitions to be managed at the same time; • Prioritizing conflicting requirements for Service Transition resources; • Planning the budget and resources needed to fulfill future requirements for Service Transition; • Reviewing and improving the performance of Transition Planning and Support activities; and • Ensuring that Service Transition is coordinated with programme and project management, Service Design and Service Development activities. In the next slide, we will look at Transition planning value to business.

3.8 Value To Business

One of the characteristics of a process is that it delivers its primary results to a customer or stakeholder. Apart from delivering the results there are a number of benefits that are derived by following a process oriented approach. The key benefits to business from Transition Planning and Support process are : • In large organization there could be a number of changes requested by customers, management and IT support teams. An effective Transition Planning and Support process can significantly improve a service provider’s ability to handle high volumes of change and releases across its customer base as well as management requirements. • Service Transition involves a variety of activities to be performed and each of these activities needs proper planning before execution. An integrated approach to planning improves the alignment of the Service Transition plans with the customer, supplier and business change project plans. Let’ us now understand the policies of this process in the next slide.

3.9 Policies

In our last slide we discussed about the value addition to Business by Transition Planning and Support. This slide discusses the policies required in Transition Planning and Support. First, is the Service Transition Policy: Service Transition Planning and Support policies must ensure that the Services are managed and deployed as defined to deliver value to the customer. The Utility (Fit for purpose) and Warranty (Fit for use), in the customer perspective (to deliver the Business Outcome) is considered during the Transition management. Service Transition Policy should cover relevant areas of Service Transition and include specific policies like: • Implement all changes to services through Service Transition • Adopt a common framework and standards • Align Service Transition plans with the business needs • Establish effective controls and disciplines • Ensure early involvement in the lifecycle. Second is the release policy which should be defined for one or more services and include: • The unique identification, numbering and naming conventions • The roles and responsibilities at each stage in the release and deployment process • The requirement to only use software assets from the definitive media library • The expected frequency for each type of release • The approach for accepting and grouping changes into a release • The mechanism to automate the build, installation and release distribution processes • How the configuration baseline for the release is captured and verified against the actual release contents • Exit and entry criteria • Criteria and authorization to exit early life support and handover to Service Operation.

3.10 Basic Concepts

In our last slide we discussed about the value addition to Business by Transition Planning and Support. This slide discusses the policies required in Transition Planning and Support. first, comes the Service Transition Policy: Service Transition Planning and Support policies must ensure that the Services are managed and deployed as defined to deliver value to the customer. The Utility (Fit for purpose) and Warranty (Fit for use), in the customer perspective (to deliver the Business Outcome) is considered during the Transition management. Second is the release policy which should be defined for one or more services and include: • The unique identification, numbering and naming conventions for different types of release together with a description for easy management of access and rights. • It needs to have clearly defined roles and responsibilities at each stage in the release and deployment process and the expected frequency for each type of release. • Release policy should also contain the approach for accepting and grouping changes into a release, e.g. how enhancements are prioritized for inclusion. • It should have the mechanism to automate the build, installation and release distribution processes to improve re-use, repeatability and efficiency. • Policy should explain how the Configuration baseline for the release is captured and verified against the actual release contents, e.g. hardware, software, documentation and knowledge. • It is important to define the Exit and entry criteria and authority for acceptance of the release into each Service Transition stage and into the controlled test, training, disaster recovery and production environments. • Also the Criteria and authorization to exit early life support and handover to Service Operations needs to be defined. Let us now move on to the next slide on principles & concepts.

3.11 Process Activities

Now, we will look at the activities of Transition planning and support process. The Transition Planning and Support process consists of four specific activities which ensure meeting all the objectives of the process. The first activity is to ‘Define transition strategy’. This involves establishing the overall approach to organizing Service Transition and allocating resources. The second activity is to ‘Prepare for Service Transition’. This activity is mainly concerned with reviewing and accepting input deliverables, checking configuration baselines and ensuring transition readiness. The third activity is to ‘Plan and coordinate Service Transition’. It takes care of planning and coordination of release and deployment activities. The fourth activity is to ‘Provide transition process support’ which covers providing advice, administration, communication, monitoring and reporting aspects of Service Transition. We shall now discuss these activities in detail in the next few slides.

3.12 Define Transition Strategy

In our last slide we were introduced to the activities of transition, Planning and support. This slide explains the first activity in detail on how to set up the transition strategy. • The aspects to consider while setting up the Transition strategy are the Purpose, goals and objectives of Service Transition, theContext, e.g. service customer, contract portfolios etc. The Scope would include the inclusions and exclusions of transition, Planning and support. • Strategy has to consider and include the Applicable standards, agreements, legal, regulatory and contractual requirement which can be Internal and external standards. This should include the Interpretation of legislation, industry guidelines and other externally imposed requirements and all the necessary agreements and contracts that apply to Service Transition. • Who are the Organizations and stakeholders involved in transition: Whether it is Third parties, strategic partners, suppliers and service providers or the Customers and users or Service Management ,Service provider etc. • Framework for Service Transition should include the Policies, processes and practices applicable to Service Transition including process service provider interfaces (SPIs) , Roles and responsibilities, Transition resource planning and estimation, Transition preparation and training requirements, The release and change authorization and Shared resources and service to support Service Transition. • Criteria’s can be the Entry and exit criteria for each release stage, Criteria for stopping or re-starting transition activities and Success and failure criteria. Let us now move on to our next activity.

3.13 Prepare Service Transition

This slide explains the second activity in detail on how to prepare the transition. The Service Transition preparation activities include: • Review and acceptance of Inputs from the other service lifecycle stages • Review and check the input deliverables, e.g. SDP, Service Acceptance • Criteria and evaluation report • Identifying, raising and scheduling RFCs • Checking that the Configuration baselines are recorded in Configuration • Management before the start of Service Transition and Checking transition readiness Let us now move on to the third activity.

3.14 Plan And Coordinate Service Transition

Let us understand the third activity in detail on how to Plan and Coordinate the transition. It is important that the release and deployment activities should be planned in stages as details of the deployment might not be known in detail initially. Each Service Transition plan should be developed from a proven Service Transition model wherever possible. Although Service Design provides the initial plan, the planner will allocate specific resources to the activities and modify the plan to fit in with any new circumstances, e.g. a test specialist may have left the organization. Let us now move on to our next activity on providing support during transition.

3.15 Transition Process Support

Transition process support activity takes care of providing advice to all relevant stakeholders, administration, communication, and progress monitoring and reporting. Providing Advice: Different stakeholders are involved in the process of implementing new are changed services. Transition planning and support team should provide guidance on processes, supporting systems and tools to all relevant stakeholders. During project initiation, this team is also responsible for establishing the Service Transition processes as quickly as possible. Administration: The Transition Planning and Support team should provide administration for • Managing Service Transition changes and work orders; • Managing issues, risks, deviations and waivers; • Managing support for tools and Service Transition processes; and • Monitoring the Service Transition performance to provide input to Continual Service Improvement. Communication: The Transition Planning and Support team is responsible for developing the communication plan and ensuring that information requirements of all stakeholders is taken care of. The various Service Transition plans and progress reports should be communicated to all relevant stakeholders. Progress monitoring and reporting : One essential responsibility of this team is to maintain an oversight of all the transition activities to ensure that they are proceeding as per plan. Also management reports showing current status of the transitions will help in making timely decisions. Next, let us understand the roles of this process.

3.16 Roles

The generic Service Owner and Process Owner roles and responsibilities are covered in learning unit five. We will discuss here the specific roles and responsibilities pertaining to Transition Planning and Support process. • Transition Planning and Support Process Owner The responsibilities include : • Generic process owner responsibilities; • Setting the scope and policies for Service Transition; and • Overseeing the overall design of all Service Transition processes. • Transition Planning and Support Process Manager The responsibilities for this role include : • Generic process manager responsibilities; • Managing and coordinating the functions that are involved in Service Transition; • Budgeting and accounting for Service Transition activities and resources; • Acting as the prime interface for senior management for Service Transition planning and reporting; • Managing and coordinating requests for resources; • Coordinating Service Transition activities across projects, suppliers and service teams; • Ensuring that the final delivery of each Service Transition meets the agreed customer and stakeholder requirements specified in the service design package. • Service Transition Manager – some organization prefer to have this role to manage overall transition or multiple transitions. • The responsibilities are a combination of Transition Planning and Support Process owner and Transition Planning and Support manager. • Transition Planning and Support Practitioner The responsibilities include : • Maintaining and integrating plans for specific Service Transitions; • Maintaining and monitoring progress for Service Transition changes, issues, risks and deviations, including tracking progress on actions and mitigation of risks; • Maintaining records and providing management information on resource use, project/service transition progress, budgeted and actual spend; and • Communicating with stakeholders.

3.17 Triggers, Inputs And Outputs

We shall now look at the triggers, inputs and outputs relating to Transition Planning and Support process. The Triggers for this process are authorized RFCs, change proposals and budgetary planning cycle. The inputs are : • Change proposal issued by Service Portfolio for new services or major changes to existing services; • Changes raised during Service Design, Service Operation or Continual Service Improvement stages and authorized by change advisory board or other authorized roles; and • The Service Design Package consisting of release package definition and design specification, test plans, deployment plans and service acceptance criteria. The outputs from this process are : • The defined and communicated transition strategy and allocated budget for transition phase; and • Integrated set of Service Transition plans covering release plans, test plans, deployment plans and project plans. In the next slide we will understand the interfaces of Transition planning and support process.

3.18 Interfaces

Transition Planning and Support process interfaces and interacts with a number of other service management processes. Some of the key ones are discussed here. • Demand Management provides information on likely resources requirements from both short term as well as long term perspective. This is vital to build, test and deploy services that would be scalable. • Service Portfolio Management interfaces with Transition Planning and Support to get inputs on portfolio planning and decision making. It also creates and submits change proposals with respect to new services or major changes to existing services. • Business Relationship Management coordinates with Transition Planning and Support to manage appropriate communication with customers. • The key deliverable from Service Design stage is the Service Design Package. Normally design and transition activities are executed through a project approach. This requires close interactions between these two stages. • Supplier Management will ensure that appropriate contracts are in place to meet the build, test and deployment requirements. • All Service Transition processes are coordinated by Transition Planning and Support hence there is a close interface amongst these processes. • Technical Management and Application Management functions of Service Operation provide the staff required to perform various activities within Service Transition. The sourcing of these resources and allocation of tasks is coordinated by Transition Planning and Support. Let’s now understand CSFs and KPIs in the next slide.

3.19 Critical Success Factors And Key Performance Indicators

Critical success factors are the essential elements of a process that need to be taken care to ensure success of the process. Key performance indicators are used to measure the achievements with respect to critical success factors. We shall now discuss some important critical success factors and key performance indicators relating to Transition planning and support process. One essential critical success factor is ‘Understanding and managing the trade-offs between cost, quality and time’ and the related key performance indicators are : ‘Increase in the number of releases implemented that meet the customer’s agreed requirements in terms of cost, quality, scope and release schedule’; and ‘Reduced variation of actual versus predicted scope, quality, cost and time’. Another critical success factor is ‘Identifying and managing risks of failure and disruption’. The related key performance indicators are : ‘Reduction in number of issues, risks and delays’ and ‘Improved service transition success rates’. The next one is ‘Coordinating activities of multiple processes involved in each transition’ and the related key performance indicators are : ‘Improved efficiency and effectiveness of the processes and supporting systems’ and ‘Reduction in time and resources to develop and maintain integrated plans and coordination activities’. A very important critical success factor of Transition Planning and Support is ‘Managing conflicting demands for shared resources’. The relevant key performance indicators are : ‘Increased project and service team satisfaction with the service transition practices’ and ‘Reduced number of issues caused by conflicting demands for shared resources’.

3.20 Challenges And Risks

There generally exist some challenges and risks when adopting new processes and procedures. The service management teams should make every effort to identify and take appropriate steps to face these challenges and mitigate the risks. The challenges and risks pertaining to Transition Planning and Support process shall be discussed now. Let us first have a look at the challenges. • The biggest challenge for this process is - building the relationships needed to manage and coordinate various stakeholders involved in Service Transition. Ensuring the right level information sharing at appropriate times and milestones becomes critical here. • Another challenge could be ‘Coordinating and prioritizing many new or changed services’, especially when there are many parallel projects running and when there are cost and schedule over-runs. • Proactively managing resource planning by understanding the risks and issues of each project are also sometimes a major challenge. Now let us look at the risks associated with Transition Planning and Support process. The risks are: • Lack of information or inadequate information from Demand Management and Service Portfolio Management resulting in a reactive transition planning and support process with insufficient long-term planning; • Poor relationships with project and programme teams resulting in sudden and unexpected Service Transition requirements; • Delays to one transition having a subsequent effect on future transitions, due to resource constraints; and • Insufficient information to prioritize conflicting requirements. In the next section we will learn about change management.

3.23 Change Management

Change is an inevitable part of organizational existence. Service providers are required to implement changes to meet the evolving business needs, market competitiveness, technology transformations or just to fix bugs and issues identified. Whatever be the reason, it is important that changes are systematically managed in order to optimize risk exposure, minimize impact, make implementations successful at first attempt and to keep all stakeholders informed in a timely manner.

3.24 Purpose And Objectives

The purpose of Change Management is to control the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services. The key objectives of Change Management are : • To respond to the customer’s changing business requirements while maximizing value and reducing incidents, disruption and re-work; • To respond to the business and IT requests for change that will align the services with the business needs; • To ensure that changes are recorded and evaluated, and that authorized changes are prioritized, planned, tested, implemented, documented and reviewed in a controlled manner; • To ensure that all changes to configuration items are recorded in the configuration management system; and • To optimize overall business risk. Let us now understand the scope of change management in the next slide.

3.25 Scope

In our last slide we discussed about the purpose of Change Management. This slide explains the scope of Change Management. The Figure shows a typical scope for the service Change Management process for an IT department and how it interfaces with the Business and suppliers at strategic, tactical and operational levels. It covers interfaces to internal and external service providers where there are shared assets and configuration items that need to be under Change Management. Service Change Management must interface with Business Change Management (to the left in Figure 4), and with the supplier’s Change Management (to the right in the Figure). This may be an external supplier with a formal Change Management system, or with the project change mechanisms within an internal development project. The Service Portfolio provides a clear definition of all current, planned and retired services. Understanding the Service Portfolio helps all parties involved in the Service Transition to understand the potential impact of the new or changed service on current services and other new or changed services. Strategic changes are brought in via Service Strategy and the Business Relationship Management processes. Changes to a service will be brought in via Service Design, Continual Service Improvement and the service level management process. Corrective change, resolving errors detected in services, will be initiated from Service Operations, and may route via support or external suppliers into a formal RFC. In the next slide we will look at Change management value to the business.

3.26 Value to Business

Changes to IT services and components may sometimes have a negative impact on business through service disruption or not meeting business requirements. Adopting Change Management process results in innumerable benefits to the business. The key benefits are : • Protecting the business and other services from negative impacts and risks, while implementing required changes; • Implementing changes that meet the customers’ agreed service requirements while optimizing costs; • Contributing to meet governance, legal, contractual and regulatory requirements by providing auditable evidence of Change Management activities; • Reducing failed changes and therefore service disruption, defects and re-work; • Reducing the number of unauthorized changes and disruptions; • Delivering changes promptly to meet business timescales; • Tracking changes through the service lifecycle and to the assets of its customers; • Contributing to better estimates of the quality, time and cost of change implementation; • Assessing the risks associated with the transition of services; • Improving productivity of staff by minimizing disruptions; • Reducing the mean time to restore service by timely and successful implementation of corrective changes; and • Liaising with the business change process to identify opportunities for business improvement. In the next slide we will look at the policies of change management.

3.27 Policies

In our last slide we discussed about the Value to Business of Change Management. This slide explains the policies required for Change Management. Increasing the success rate of changes and releases requires Executive support for implementing a culture that sets stakeholder expectations about changes and releases and reduces unplanned work. There must be policies and standards defined which make it clear to the internal and external providers what must be done and what the consequence of non-adherence to policy will be. Policies that support Change Management include: • Creating a culture of Change Management across the organization where there is zero tolerance for unauthorized change • Policies will be responsible for Aligning the service Change Management process with Business, project and stakeholder Change Management processes and Prioritization of change, e.g. innovation vs. preventive vs. detective vs. corrective change • Establishing accountability and responsibilities for changes through the service lifecycle • Segregation of duty controls and managing the Change windows – enforcement and authorization for exceptions • Establishing a single focal point for changes in order to minimize the probability of conflicting changes and potential disruption to the production environment • Preventing people who are not authorized to make a change from having access to the production environment • Integration with other Service Management processes to establish traceability of change, detect unauthorized change and identify change related incidents • Performance and risk evaluation of all changes that impact service capability • Performance measures for the process, e.g. efficiency and effectiveness. In the next slide let us look into the key concepts of change management.

3.28 Key Concepts

Before we move on to discuss the Change Management process activities, let us have a quick look at some of the key concepts relating to this process. An understanding of these concepts will enable understanding the rest of this module in a better way. • Change: The addition, modification or removal of anything that could have an effect on IT services. This definition of change includes changes to services, configuration items, architectures, processes, tools, metrics and documentation. • RFC: A request for change and represents a formal proposal for a change to be made. This is normally a form containing details of the proposed change. • Change proposal: Provides a high-level description of major changes that involve significant cost, risk or organizational impact and is usually initiated by Service Portfolio Management. • Change record: A record containing the details of a change. Each change record documents the lifecycle of a single change and is created for every request for change that is received. • CAB: Change Advisory Board, is a body that exists to support the authorization of changes and to assist Change Management in the assessment, prioritization and scheduling of changes. The constitution of Change Advisor Board might change based on the type and category of changes being assessed. • Standard change: Is a pre-authorized change that is low risk, relatively common and follows a procedure or work instruction. • Emergency change: A change that must be implemented as soon as possible to avoid impact to business or disruption of services. • Normal Change: Any service change that is not a standard change or an emergency change and follow all the defined steps of the Change Management process. • Change Model: Is a repeatable way of dealing with a particular category of change. A change model defines specific agreed set of steps to handle changes belonging to a category. Let’s discuss the activities of change management in the next few slides.

3.29 Activities

In our last slide we understood the Key Concepts of Change Management. This slide explains the Activities, Methods and Techniques of Change Management. This slide provides approaches to managing service changes effectively by addressing the tasks carried out to achieve and deliver controlled change. The Overall Change Management activities include: • Planning and controlling changes. • They are responsible for Change and release of scheduling. • One of the critical components is managing the Communications. • Change Management team has to playi a key role in Change decision making and change authorization. • Change Management is responsible for Ensuring that there are remediation plans for critical changes. • Change Management has to ensure effective Measurement and control is in place and on the basis of the metrics Management reporting is to be published. • Change Management has to establish the skill for Understanding the impact of change. • And lastly Change Management is responsible for triggering any continual improvement action. Let us now move on to our next slide.

3.30 Process Flow For Normal Change

In the last slide we understood the Activities, Methods and Techniques of Change Management. This slide explains the Key activities of Change Management model. This flow chart shows the sample flow of Change Management process. We will learn about the individual activities in detail in the next few slides.

3.31 Process Activities

Before we get into the details of the activities for Change Management, let us see what these activities are. These activities include Firstly to create RFC (Request for Change or Change Request), the second activity is to record RFC followed by the third activity, reviewing the RFC. Assessing and evaluating the change is the fourth activity and to authorize change, build and test it is the fifth activity. Coordinating the change build and test is the sixth activity. The seventh activity is to authorize change deployment followed by the eighth activity which it to coordinate change deployment and lastly the ninth one is to review and close the change record. So now we know the activities involved for change management let us learn about each activity in detail.

3.32 Create and Record RFC

Lets us begin with the first activity of Change Management. At first the change is raised by a request from the initiator – who could be an individual or organizationalgroup that requires the change. For example initiator can be the Problem Manager, Service Owner or the CSI Manager. Once the request is raised the same has to be recorded with all details pertaining to the change, which is the next step of change management activities.

3.33 Review of the RFC

In our last slide we discussed about creating and recording RFC activities of Change Management. This slide explains Second activity of Change Management which is review of the RFC. While verifying the RFC there are certain cautions to be taken. Verification by the stakeholders is done if the RFCs are totally impractical, repeats of earlier RFCs, accepted, rejected or still under consideration, or there are incomplete submissions. For example There could be inadequate description. RFC is raised without necessary budgetary approval Raised RFC could be against the organizations’ strategy Or it can be a situation when the requester is not authorized to raise such a request Let us continue on this activity in the next slide.

3.34 Assess and Evaluate the change

The third step within the Change Management process is to ‘assess and evaluate the change’. • Change Management is responsible for ensuring that every change is evaluated before authorizing the change. Assessment of each category of change should be assigned to a clearly identified change authority. • For significant changes, the evaluation can be formally handled by the Change Evaluation Process. There should be well defined criteria to determine when the change evaluation is needed and this criteria should be documented in the relevant change model. • The key aspects to be consider while performing the ‘assess and evaluate change’ activity are: – Impact Assessment - The seven R’s of impact assessment is a good tool to perform a proper impact assessment of changes. These seven R’s are discussed in the next slide. Apart from other aspects, the impact assessment should primarily look at the impact of the change on customer’s business operations and on other services that run on the same infrastructure. – It is advised to use the best practice of ‘risk-based assessment during evaluation of change’. Before authorization of change, it should be evaluated to ensure that risks have been managed and that predicted and actual performances match the business requirements. – Assess and evaluate change activity includes ‘allocation of priorities’ to proposed changes. Prioritization is used to establish the order in which changes should be considered for authorization and implementation. The priority of a change is derived from the agreed impact and urgency. – This activity should also ‘assess the remediation plan’. It is important to develop a remediation plan to address a possible failure of the change or release. Next, we will look at the seven R’s of change management.

3.35 The Seven R's of Impact Assessment

The potential impact on the services of failed changes and their impact on service assets and configurations need to be considered. Generic questions like the ‘seven Rs’ provide a good starting point. The following questions must be answered for all changes. Without this information, the impact assessment cannot be completed, and the balance of risk and benefit to the live service will not be understood. This could result in the change not delivering all the possible or expected Business benefits or even of it having a detrimental, unexpected effect on the live service. Let’s look at these seven R’s: • Who RAISED the change? • What is the REASON for the change? • What is the RETURN required from the change? • What are the Risks involved in the change? • What RESOURCES are required to deliver the change? • Who is RESPONSIBLE for the build, test and implementation of the change? • What is the RELATIONSHIP between this change and other changes? Many organizations develop specific impact assessment forms to prompt the impact assessors about specific types of change. This can help with the learning process, particularly for new services or when implementing a formal impact assessment steps for the first time.

3.35 The Seven R's of Impact Assessment

The potential impact on the services of failed changes and their impact on service assets and configurations need to be considered. Generic questions like the ‘seven Rs’ provide a good starting point. The following questions must be answered for all changes. Without this information, the impact assessment cannot be completed, and the balance of risk and benefit to the live service will not be understood. This could result in the change not delivering all the possible or expected Business benefits or even of it having a detrimental, unexpected effect on the live service. Let’s look at these seven R’s: • Who RAISED the change? • What is the REASON for the change? • What is the RETURN required from the change? • What are the Risks involved in the change? • What RESOURCES are required to deliver the change? • Who is RESPONSIBLE for the build, test and implementation of the change? • What is the RELATIONSHIP between this change and other changes? Many organizations develop specific impact assessment forms to prompt the impact assessors about specific types of change. This can help with the learning process, particularly for new services or when implementing a formal impact assessment steps for the first time.

3.36 Authorize the Change Build and Test

The next activity is to ‘Authorize the change build and test’. • Every change must be authorized by the appropriate change authority for build and test. The generally defined authorities are - change manager, Change Advisory Board, Emergency Change Advisory Board, IT steering group or Business Executive Board. • The levels of authorization required depend on the type, size, risk and potential business impact of the change. The level at which a change is authorized should rest where accountability for accepting risk and remediation exists. • Multi-stage changes may require multiple approvals at the “stage-gates” of the change implementation. Where changes are rejected, the reason for rejection should be clearly mentioned and the requestor of change informed. In case disputes arise over change authorization or rejection, there should be a formal approach to appeal to higher levels. Let’s understand the change authorization model in the next slide.

3.37 Change Authorization Model 4 Levels

Formal authorization is obtained for each change from a change authority that may be a role, person or a group of people. The levels of authorization for a particular type of change should be judged by the type, size or risk of the change, e.g. changes in a large enterprise that affect several distributed sites may need to be authorized by a higher-level change authority such as a global CAB or the Board of Directors. The culture of the organization dictates, to a large extent, the manner in which changes are authorized. Hierarchical structures may well impose many levels of change authorization, while flatter structures may allow a more streamlined approach. A degree of delegated authority may well exist within an authorization level, e.g. delegating authority to a change manager according to pre-set parameters relating to: Anticipated business risk Financial implications Scope of the change (e.g. internal effects only, within the finance service, specific outsourced services). Each organization should formally document its own change authorization hierarchy. All change authorities should be documented in the CMS. If the change assessment at level 2, 3 or 4 detects higher levels of risk, the authorization request is escalated to the appropriate higher level for the assessed level of risk. The level at which change is authorized should rest where accountability for accepting risk and remediation exist. Should disputes arise over change authorization or rejection, there should be a right of appeal to the higher level. Changes that have been rejected should be formally reviewed and closed. Let us now proceed to understand the next activity coordinate change deployment.

3.38 Coordinate Change build and test

Now let us move to the fifth activity, coordinate Change, build and test. Let us understand this activity in more detail. All the authorized RFCs should be passed on to the relevant technical groups for building the changes. It is best practice to do this in a formal way so that it can be tracked, e.g. using work orders. Change Management has the responsibility for ensuring that changes are implemented as scheduled. Remediation (correction of errors) procedures should be prepared and documented in advance, for each authorized change, so that if errors occur during or after implementation, these procedures can be quickly activated with minimum impact on service quality. Authority and responsibility for raising remediation is specifically mentioned in change documentation. Change Management has an oversight role to ensure that all changes that can be are thoroughly tested. In all cases involving changes that have not been fully tested, special care needs to be taken during implementation. Testing may continue in parallel with early live usage of a service – looking at unusual, unexpected or future situations so that further correcting action can be taken before any detected errors become evident in live operation. The implementation of such changes should be scheduled when the least impact on live services is likely. Support staff should be on hand to deal quickly with any incidents that might arise. In the next slide let us look at Authorizing change deployment.

3.39 Authorize the Change Deployment

Formal authorization is obtained for each change from a change authority that may be a role, person or a group of people. The levels of authorization for a particular type of change should be judged by the type, size or risk of the change, e.g. changes in a large enterprise that affect several distributed sites may need to be authorized by a higher-level change authority such as a global CAB or the Board of Directors. The culture of the organization dictates, to a large extent, the manner in which changes are authorized. Hierarchical structures may well impose many levels of change authorization, while flatter structures may allow a more streamlined approach. A degree of delegated authority may well exist within an authorization level, e.g. delegating authority to a change manager according to pre-set parameters relating to: Anticipated business risk Financial implications Scope of the change (e.g. internal effects only, within the finance service, specific outsourced services). Let us now proceed to understand the next activity coordinate change deployment.

3.40 Coordinate Change Deployment

In our last slide we discussed about the seventh activity of Change Management. This slide explains the eighth activity i.e. coordinate Change deployment. Change Management has the responsibility for ensuring that changes are implemented as scheduled. This is largely a coordination role as the actual implementation will be the responsibility of others. Deployment will involve resources from the Release and Deployment Management Remediation procedures should be prepared and documented in advance, for each authorized change, so that if errors occur during or after implementation, these procedures can be quickly activated with minimum impact on service quality. The evaluations from the 7Rs may be used for ensuring the feasibility of the remediation plan (in the current situation) It is Change Management’s responsibility to ensure that the Alignment to the service requirements mentioned in the RFC to the releases being deployed is taken care of.. Let us now look at the last activity of change management in the next slide.

3.41 Review and Close Change Record

The final step within the Change Management process is to ‘Review and close change record’. All changes must be formally closed and this formal closure involves conducting certain key activities. These activities may vary based on type of change and are generally defined in the change model. We shall be discussing these activities from a normal change perspective. • Before a change is closed, it should be evaluated to ensure that actual performance is acceptable and that there are no unacceptable risks. If the performance and risks are acceptable, the change is presented as a completed change for stakeholder agreement. In case there are any unacceptable risks, the change authority is advised to take further actions as required. • A formal review meeting, as part of CAB meeting, is conducted. This is to discuss and establish that: – The change has had the desired effect and met its objectives; – Users, customers and other stakeholders are content with the results; – There are no unexpected or undesirable side-effects to functionality, service levels and warranties; – The resources used to implement the change were as planned; – The deployment plan worked correctly; – The change was implemented on time and to cost; and – The remediation plan functioned correctly, where deployment was rolled back. • The review also checks to confirm that the Configuration Management System and the configuration records in the CMDB have been updated to represent the correct status, attributes and relationships of changed configuration items. • Where required, a post implementation review report is produced before closing the change. • The status in the change record is updated as ‘Closed’.

3.42 Process Flow For Standard Deployment Request

Now, in this slide we will look at the process flow for standard deployment request. After a change has been built and tested and the deployment procedure has been used successfully one or more times, then it may be appropriated to use a standard deployment request change model for future deployments of the same change. This is much simpler than the full change management process flow. The figure on the slide is an example for this kind of standard change. In the next slide we will see an example of process flow for standard operational change request.

3.43 Process Flow For Standard Operational Change Request

This slide is an example of process flow for standard operational change request. Low risk changes may be delegated to service operation staff as part of change authority. The change model for this kind of standard change is simple. The flow creates a process involving RFC, implementing the change, review of the changes and closing of the change record. Let us move to the next slide on roles of the change management process.

3.44 Roles

We will now look at different roles and responsibilities relating to Change Management. • Change Management Process Owner The responsibilities include : • Generic process owner responsibilities; • Designing change authority hierarchy and criteria for allocating RFCs to change authorities; • Designing change models and workflows; and • Working with other process owners to ensure that there is an integrated approach to the design and implementation of change management, service asset and configuration management, release and deployment management, and service validation and testing. • Change Management Process Manager The responsibilities of the Change Management process manager are : • Generic process manager responsibilities; • Planning and managing support for change management tools and processes; • Maintaining the change schedule and projected service outage; and • Coordinating interfaces between change management and other processes – especially service asset and configuration management and release and deployment management. • Change Initiator The responsibilities include : • Identifying the requirement for a change; • Completing and submitting a change proposal if appropriate; • Completing and submitting the Request For Change; • Attending CAB meetings to provide further information about the RFC or change proposal if invited; and • Reviewing change when requested by change management, and specifically before closure. • Change Practitioner The responsibilities of a Change Practitioner are : • Verifying that RFCs are correctly completed; • Allocating RFCs to appropriate change authorities based on defined criteria; • Submitting requests for evaluation to trigger the change evaluation process; • Formally communicating decisions of change authorities to affected parties; • Monitoring and reviewing activities of teams and functions that build and test changes to ensure that the work is carried out correctly; and • Publishing the change schedule and projected service outage and ensuring that they are available when and where needed. • Change Authority The responsibilities of Change Authority are : • Reviewing specific categories of RFC; • Formally authorizing changes at agreed points in the change lifecycle; • Participating in the change review before changes are closed; and • Attending CAB meetings to discuss and review changes when required. • CAB Member The responsibilities of a CAB member are : • Participating in CAB meetings; • Authority to represent a particular group or function; • Preparing for CAB meetings by circulating RFCs within their own group and coordinating feedback; • Reviewing RFCs and recommending whether they should be authorized; • Reviewing successful and failed changes; • Reviewing unauthorized changes; • Reviewing the change schedule and providing information to help identify conflicts or resource issues; and • Reviewing the projected service outage and providing feedback on the impact of planned outages. • CAB Chair The responsibilities include : • Deciding who should attend CAB meetings; • Planning, scheduling, managing and chairing CAB meetings; • Selecting RFCs for review at CAB meetings, based on the change policy; • Circulating RFCs in advance of CAB meetings to allow prior consideration; • Convening emergency change advisory board meetings for consideration of emergency changes; and • Selecting successful and failed changes for review at CAB meetings.

3.45 Triggers

This slide explains the triggers and process interfaces of Change Management. Firstly, let us understand the various process triggers. Requests for change can be triggered throughout the service lifecycle and at the interfaces with other organizations, e.g. Customers and suppliers. There will also be other stakeholders such as partners that may be involved with the Change Management processes. Typical examples of types of change that trigger the Change Management process are described here. First are the Strategic changes where Service strategies require changes to be implemented to achieve specific objectives while minimizing costs and risks. There are no cost-free and risk-free strategic plans or initiatives. There are always costs and risks associated with decisions such as introducing new services, entering new market spaces, and serving new Customers. These can be Legal/regulatory change, Organizational change etc. Second is Change to one or more services: Changes to the planned services (in the Service Portfolio) and changes to the services in the service catalogue will trigger the Change Management process. These include changes to: Service catalogue, Service package. Third is Operational change It is important to know the distinction between different types of requests that will be initiated by users. These types of request will depend on the nature of the organization and services and may include requests such as password reset, access request or request to move an IT asset. Service Operations staff will also implement corrective and preventative changes, through the standard change procedure, that should be managed through Change Management, e.g. server re-boot, which may impact a shared service. Fourth are the Changes to deliver continual improvement When CSI (pronounced as C-S-I) determines that an improvement to a Service is warranted, an RFC should be submitted to Change Management. Changes such as changes to processes can have an effect on service provision and may also affect other CSI initiatives. Point to be noted here is that some strategy and service changes will be initiated by CSI. Let us learn more about the process interfaces of Change Management.

3.46 Inputs and Outputs

Changes may be submitted as an RFC, often with an associated change proposal that provides the detail of how the change will happen, e.g. approach to implementing a legislative change. The change proposal will be based on a change model and will provide more detail about the specific change proposed. The Inputs include: • Policy and strategies for change and release • Request for Change • Change proposal • Plans – change, transition, release, deployment, test, evaluation and remediation • Current change schedule and PSO (Projected Service Outage) • Current assets or configuration items, e.g. baseline, service package, release package • As-planned Configuration baseline • Test results, test report and evaluation report. Let us understand the outputs of Change Management. Outputs from the process will be: • rejected and approved RFCs • new, changed or disposed assets or configuration items, e.g. baseline, service package, release package • CMS/CMDB Update (this refers to the update of a CIs,Status, Attributes) • adjusted PSO(pronounced as P-S-O) (Projected Service Outage) • updated Schedule of Change • change decisions, actions, documents, records and reports Let us continue this in the next slide.

3.47 Interfaces

Let us understand the first interface Integration with Business change processes: Where appropriate, the Change Management should be involved with Business programme and Business project management teams to ensure that change issues, aims, impacts and developments are exchanged and cascaded throughout the organization where applicable. This means that changes to any Business or project deliverables that do not impact services or service components may be subject to Business or project Change Management procedures rather than the IT service Change Management procedures. However, care must be taken to ensure that changes to service Configuration baselines and releases do follow the Change Management process Program and project management: Program and project management must work in partnership to align all the processes and people involved in service change initiatives. The closer they are aligned, the higher the probability that the change effort will be moved forward for as long as it takes to complete. Change Management representatives may attend relevant Project Board meetings. Sourcing and partnering arrangements should clearly define the level of autonomy a partner may have in effecting change within their service domain without reference to the overall service provider. Sourcing and partnering Sourcing and partnering include internal and external vendors and suppliers who are providing a new or existing service to the organization. Effective Change Management practices and principles must be put into place to manage these relationships effectively to ensure smooth delivery of service. Also, Effort should be put into finding out how well the partners themselves manage change and choose partner and sourcing relationships accordingly. Interfaces within Service Management: the Service Management processes may require change and improvements. Many will also be involved in the impact assessment and implementation of service changes Service Asset and Configuration Management refers to: The Configuration Management System which provides reliable, quick and easy access to accurate Configuration information to enable stakeholders and staff to assess the impact of proposed changes and to track changes work flow. This information enables the correct asset and service component versions to be released to the appropriate party or into the correct environment. As changes are implemented, the Configuration Management information is updated. The CMS may also identify related CI or assets that will be affected by the change, but not included in the original request, or in fact similar CI or assets that would benefit from similar change. Problem Management Problem Management is another key process as changes are often required to implement workarounds and to fix known errors. Problem Management is one of the major sources of RFCs and also often a major contributor to CAB discussion. IT Service Continuity IT service Continuity has many procedures and plans should be updated via Change Management to ensure that they are accurate, up to date and that stakeholders are aware of changes. Security management Security Management interfaces with Change Management since changes required by security will go via Change Management process and security will be a key contributor to CAB discussion on many services. Every significant change will be assessed for its potential impact on the security plan. Capacity and Demand Management Capacity and Demand Management is a critical aspect of Change Management. Poorly managed demand is a source of costs and risk for service providers because there is always a level of uncertainty associated with the demand for services. Capacity Management has an important role in assessing proposed changes – not only the individual changes but the total impact of changes on service capacity. Changes arising from Capacity Management, including those set out in the capacity plan, will be initiated as RFCs through the change process. The service portfolio management process prioritizes and charters strategic changes, and submits change proposals for these. Change proposals will be key input for long term planning and to authorize related RFCs. Some change requests will require analysis by the service portfolio management process, potentially adding to service pipeline. Each organization should define criteria for deciding whether these requests are managed as part of change management process or are passed to service portfolio management. Let us now proceed to look at the CSfs and KPIs of this process.

3.48 CSFs and KPIs

The service management team should identify appropriate critical success factors and key performance indicators for each process. These should be in-line with the objectives of the process. Change Management is all about having proper control on all the components of a service. We shall now discuss the critical success factors and related key performance indicators pertaining to this process. The first and foremost critical success factor of Change Management is ‘Responding to business and IT requests for change that will align the services with the business needs while maximizing value’. The related key performance indicators are ‘Increase in the percentage of changes that meet the customer’s agreed requirements’ and ‘The benefits of change exceed the costs of change’. Another critical success factor is ‘Optimizing overall business risk’. The related key performance indicators are ‘Reduction in the number of disruptions to services, defects and re-work caused by inaccurate specification, poor or incomplete impact assessment’ and ‘Increase in change success rate’. Another important critical success factor is ‘Ensuring that all changes to configuration items are well managed and recorded in the configuration management system’. The related key performance indicators are ‘Reduction in number of audit compliance issues for the change management process’; and ‘ Reduction in number and percentage of discrepancies found by service asset and configuration management verifications and audits’.

3.49 Challenges and Risks

Identifying and documenting challenges pertaining to each service management process enables the organization to develop counter measures thereby building efficiency right from early stages of process implementation. • The biggest challenge for Change Management is ensuring that every change is recorded and managed. Senior management support is the best way to manage this challenge. • Another key challenge is to gain support from customers, users and IT staff. These stakeholders may feel that this process is more bureaucratic and time-consuming. Change Management must make sure to establish that it adds value and helps better management of change implementation. • In some organizations Change Management may be viewed as just operational change authorization process. Change Management needs to be involved early in the service lifecycle to reap the real benefits of this process. • In large organizations, one key challenge could be to agree and document the many levels of change authority that are needed. The remedy to this challenge is to define and document the scope of Change Management and establish required change models. Let’s understand the risks in the next slide.

3.50 Challenges and Risks

All process related risks should be identified, recorded, analysed and managed. This is essential for building process efficiency and achieving higher maturity levels. The risks relating to Change Management process are : • Lack of commitment to the change management process by the business, IT management and IT staff; • Implementation of changes without the use of change management; • Change assessment being reduced to box ticking; • Introduction of delays to change implementation without adding sufficient value; • Insufficient time being allowed for proper assessment of changes and implementation of changes; • Insufficient resources for assessment, planning and implementation of the changes required by the business; • Lack of clarity on how change management should interact with other service management processes and project management; and • Excessively bureaucratic change management processes that introduce more delays to required changes.

3.51 Service Asset and Configuration Management

IT organizations and service providers require various assets for delivering services to the customers. It becomes essential for these organizations to manage and control the service assets to ensure provision of reliable, efficient and scalable services. Service Asset and Configuration Management is the process concerned with ensuring that Configuration Items are identified, baselined and maintained and that changes to them are controlled. It also provides a configuration model of the services and service assets by recording the relationships between configuration items.

3.52 Purpose And Objectives

The purpose of Service Asset and Configuration Management is to ensure that the assets required to deliver services are properly controlled, and that accurate and reliable information about those assets is available when and where it is needed. This information includes details of how the assets have been configured and the relationships between them. The objectives of Service Asset and Configuration Management are to : • Ensure that assets under the control of the IT organization are identified, controlled and properly managed throughout their lifecycle; • Identify, control, record, report, audit and verify services and other configuration items, including versions, baselines, constituent components, their attributes and relationships; • Account for, manage and protect the integrity of Configuration Items through the service lifecycle by working with change management to ensure that only authorized components are used and only authorized changes are made; • Ensure the integrity of CIs and configurations required to control the services by establishing and maintaining an accurate and complete configuration management system; • Maintain accurate configuration information on the historical, planned and current state of services and other CIs; and • Support efficient and effective service management processes by providing accurate configuration information to enable people to make decisions at the right time. In the next slide we will look at the scope of SACM process.

3.53 Scope

The scope of Service Asset and Configuration Management includes management of the complete lifecycle of every configuration item. We shall look at the definitions of Service Assets and Configuration Items later but it is important to understand that every configuration items is a service asset, but all service assets are not configuration items. Only those service assets that need to be managed and controlled to deliver services are considered as configuration items. Let us now go a bit deeper to understand the scope of Service Asset and Configuration Management. The scope covers : • Identifying, baselining and maintaining Configuration Items and ensuring that changes to them are controlled; • Ensuring that releases into controlled environments and operational use are done on the basis of formal authorization; • Providing a configuration model of the services and service assets by recording the relationships between configuration items; and • Interfaces to internal and external service providers where there are assets and configuration items that need to be controlled. In the next slide we will learn about the SACM value to business.

3.54 Value to Business

Service Asset and Configuration Management is critical for the success of many other processes. The benefits of implementing and adhering to this process span across the lifecycle phases. We shall now be looking at the value derived by business from this process. Service Asset and Configuration Management provides information about services, releases, infrastructure and environments that enables : • IT staff to understand the configuration and relationships of services and the configuration items that provide them; • Better forecasting and planning of changes; • Successful assessment, planning and delivery of changes and releases; • Resolution of incidents and problems within the service level targets; • Delivery of service levels and warranties; • Better adherence to standards, legal and regulatory obligations; • More business opportunities as the service provider is able to demonstrate control of assets and services; • Traceability of changes from requirements; • The ability to identify the costs of a service; • Reduced cost and time to discover configuration information when it is needed; and • Proper stewardship of fixed assets that are under the control of the service provider. In the next two slides we will understand the policies and principles of SACM.

3.55 Policies and Principles

Establishing policies and principles for a process helps conveying management intentions and ensures that the process activities and performance are aligned to the objectives of service management and the business. Some key principles relating to Service Asset and Configuration Management are : • Ensuring that service asset and configuration management operations costs and resources are commensurate with the potential risks to the services; • The need to deliver governance requirements, such as software asset management, ISO/IEC 20000 or COBIT; • The need to deliver the capability, resources and warranties as defined by the service level agreements and contracts; • The requirement for available, reliable and cost-effective services; • The requirement for clear economic and performance criteria for interventions that reduce costs or optimize service delivery; • The application of whole-life cost appraisal methods; • The transformation from ‘find and fix’ reactive maintenance to ‘predict and prevent’ proactive management;

3.56 Policies and Principles

• The requirement to maintain adequate configuration information for internal and external stakeholders; • The level of control and requirements for traceability and auditability; • The application of continual improvement methods to optimize the service levels, assets and configurations; • Provision of accurate configuration information for other business and service management processes; • Integration of service asset and configuration management with other processes; • Migration to a common Configuration Management System architecture; and • Level of automation to reduce errors and costs. Now, let’s look at the key concepts of SACM.

3.57 Key Concepts

Before moving further, it is essential to understand some key concepts and definitions relating to Service Asset and Configuration Management. Service Asset: Is any resource or capability that could contribute to the delivery of a service. There are nine types of service assets, viz., Financial Capital, Infrastructure, Applications, Information, Management, Organization, Processes, Knowledge and People. Configuration Item: Is any service asset that needs to be managed in order to deliver an IT service. Information about each configuration item is recorded in a configuration record within the Configuration Management System and is maintained throughout its lifecycle. Configuration items are under the control of Change Management. Configuration Management System: Is a set of tools, data and information that is used to support service asset and configuration management. It is part of the overall Service Knowledge Management System and may include information about incidents, problems, known-errors, changes and releases. Configuration Record: A record containing the details of a configuration item, throughout its lifecycle. Configuration records are stored in a Configuration Management Database which is part of the Configuration Management System. Configuration Management Database (CMDB): A database used to store configuration records throughout their lifecycle. It stores attributes of configuration items, and relationships with other configuration items. Configuration Model: A representation of the services, assets and infrastructure along with the relationships between configuration items. This enables other processes to access valuable information and perform proper impact assessment. The next slide gives an example of CMS.

3.58 Key Concepts: Configuration Management System

In our last slide we understood the basic concepts of SACM process. This slide explains the Pictorial representation of CMS. This Figure shows how the CMS covers the Data and information Integration layers of the knowledge/information/knowledge hierarchy explained in later modules, Knowledge Management. At the Data level, the CMS may take Data from several physical CMDBs, which together constitute a federated CMDB. The integrated CMDB may also incorporate information from external data sources such as HR database or financial database. The CMS will provide access to this external Data wherever possible rather than duplicating Data. Let us consider an Example of multiple Configuration Management databases: In the commonly encountered partially outsourced service provider, some elements of the Service Management will be outsourced while others will remain in house, and different elements may be outsourced to different external suppliers. For example the network and hardware support may be handled by supplier A, environment and facilities management by supplier B, and multiple applications suppliers and incident management handled internally. The service desk will access information to assist them from the CMS, but that system will derive its Data input from discrete repositories – each one a CMDB – owned and maintained by the three parties but working together to supply a single consistent information set. Configuration information evolves as the service is developed through the service lifecycle. Often there are separate mechanisms for managing different service lifecycle stages as well as different means of managing different applications and platforms. The CMS typically contains Configuration Data and information that is combined into an integrated set of views for different stakeholders through the service lifecycle as illustrated in this Figure. It therefore needs to be based on appropriate web, reporting and database technologies that provide flexible and powerful visualization and mapping tools, interrogation and reporting facilities. The CMS is part of an SKMS that includes data, information integration, knowledge processing and presentation layers. The presentation layer of the CMS will contain views and dashboards that are required by people who need access to configuration information. Many organizations are already using some elements of SACM, often maintaining records in documents, spreadsheets or local databases, and some of these may be used in the overall CMS. Automated processes to load and update the Configuration Management database should be developed where possible so as to reduce errors and optimize costs. Discovery tools, inventory and audit tools, enterprise systems and network management tools can be interfaced to the CMS. These tools can be used initially to populate a CMDB, and subsequently to compare the actual ‘live’ Configuration with the information and records stored in the CMS. In the next slide let us look at the Configuration Model.

3.59 Key Concepts: Configuration Model

In our last slide we understood the representation of CMS. This slide explains the Key Concepts of Configuration model. Configuration Management delivers a model of the services, assets and the infrastructure by recording the relationships between configuration items as shown in this Figure. This enables other processes to access valuable information, e.g.: To assess the impact and cause of incidents and problems To assess the impact of proposed changes To plan and design new or changed services To plan technology refresh and software upgrades To plan release and deployment packages and migrate service assets to different locations and service centers To optimize asset utilization and costs, e.g. consolidate Data centers, reduce variations and re-use assets. The real power of Configuration Management’s logical model of the services and infrastructure is that it is the model – a single common representation used by all parts of IT Service Management, and beyond, such as HR, finance, supplier and Customers. The next slide is in continuation of the previous slide on key concepts of configuration model.

3.60 Key Concepts

Let’s continue understanding few more important concepts relating to Service Asset and Configuration Management. The Definitive Media Library : Is one or more locations in which the definitive and authorized versions of all software configuration items are securely stored along with associated licenses and documentation. Generally these refer to the master copies of purchased software as well as those developed in-house and have passed quality assurance checks. Definitive spares: Are spare hardware components and assemblies that are maintained at the same revision level as the systems within the controlled test or live environment. Details of these components are also recorded in the Configuration Management System and should be managed in the same way as other fixed assets. Configuration baseline: Is the configuration of a service, product or infrastructure that has been formally reviewed and agreed, and any further change can be made only through change management. It captures the structure, contents and details of a configuration and represents a set of configuration items that are related to each other. Snapshot: Is the current state of a configuration item or an environment. This snapshot is recorded in the Configuration Management System and remains as a fixed historical record. It is also referred to as a footprint. Configuration snapshots are normally captured through discovery tools. Moving ahead, let us now discuss about the process activities of SACM.

3.61 Process Activities

In our last slide we understood the Key Concepts of Configuration model. This slide explains the Activities, Methods, Techniques of SACM process. High-level activities for Asset and Configuration Management which we will be discussing in detail in later slides are shown here. The basic SACM process activities consist of: 1. Management & planning 2. Configuration identification 3. Configuration control 4. Status accounting AND 5. Verification & audit Moving on let us look at each activity in the next few slides in detail.

3.62 Management and Planning

In our last slide we discussed about the activities for Asset and Configuration Management process. This slide explains the first activity, Management and Planning There is no standard template for determining the optimum approach for SACM. The management team and Configuration Management should decide what level of Configuration Management is required for the selected service or project that is delivering changes and how this level will be achieved. This is documented in a Configuration Management Plan. Often there will be a Configuration Management Plan for a project, service or groups of services, e.g. network services. These plans define the specific Configuration Management activities within the context of the predominant Service Asset and Configuration Management strategy. The level of Data will depend on the Organizational requirement. Neither too much, nor too less. In real world, the Service Management tool needs to support CMDB related automation and integration to other processes, to ensure accuracy in the CMS and the benefit of information sharing respectively. Let us now move on to our next activity on Configuration Identification.

3.63 Configuration Identification

In our last slide we looked at the first activity, Management and Planning of SACM process. This slide explains the second activity Configuration identification Configuration identification Focuses on determining and maintaining the naming and version numbering of assets and CIs, relations and the attributes. The most important activities of Configuration identification are: • Defining and documenting criteria for the selection of CIs and the components within them • Select the configuration items and the components that compose them based on documented criteria • Select the configuration items and the components that compose them based on documented criteria numbers for identification purposes • Specify the relevant attributes of each configuration item • Indicating when each CI will be placed under Configuration Management • Identifying the “owner” of each CI Moving on let us discus the third activity, Configuration control in the next slideSlide

3.64 Configuration Control

Having identified all configuration items, the next logical step is to enforce proper control of these items. The ‘Configuration Control’ activity • Ensures that there are adequate control mechanisms over the CIs, while maintaining a record of changes to CIs, versions, location and ownership. Any lapse or deviation will result in a mismatch between the information in Configuration Management System and the physical environment. • Well defined and documented policies and procedure should be in place to manage service assets and configuration items. As there are a number of ways in which a configuration item can be changed, it becomes even more important to have specific procedures for each type or category of configuration item. • It should be ensured that no Configuration Item can be added, modified, replaced or removed without following the agreed procedure. This is where the involvement of Change Management plays a significant role. • There are situations where configuration items are transferred from one party to another, for example, from project team to support team or from current supplier to a new supplier. It should be ensured that the control is passed with accurate configuration information, documentation and records. Let’s understand the next activity of SACM which is Status accounting and reporting.

3.65 Status Accounting and Reporting

• During the lifecycle configuration items move from one state to another. ‘Status accounting and reporting’ activity is concerned with ensuring that all configuration data and documentation is recorded as each Configuration Item progresses through its lifecycle. At each lifecycle status change the Configuration Management System should be updated with the reason, time stamp and person who made the status change. • It provides the status of the overall configuration of a service and its environment as the configuration evolves through the service lifecycle. This can be directly linked to the evolution of a service from Service Design phase to Service Operation phase. New services are designed, built, tested, and deployed into live environments. Later many changes and improvements can happen to align the services to meet changing business requirements. Configuration Status Accounting ensures recording of all the relevant statuses in the Configuration Management System. • Status reporting provides the current and historical data concerned with each Configuration Item, which in turn enables tracking of changes to Configuration Items and their records. Various types of configuration reports may be required across the service lifecycle. These reports may pertain to individual configuration items, a complete service or the service portfolio itself. Some service asset and configuration reports are also required by financial management for budgeting, accounting and charging activities. Next, let us look at Verification and audit activity.

3.66 Verification and Audit

Service assets and configuration items form the essence of service provision and management. Though identified as one of most important processes, Service Asset and Configuration Management is also the most difficult process to implement and manage. The complexity of IT environments, especially in large organisations, poses a challenge in identification, recording and controlling all the relevant service assets and configuration items. This is where ‘verification and audit’ activity is of significant importance within the overall Service Asset and Configuration Management. As part of this activity a series of reviews and audits are planned and conducted to : Ensure that there is conformity between the documented baselines and the actual business environment to which they refer; Verify the physical existence of Configuration Items and to check that the records in the Configuration Management System match the physical infrastructure; and Check that release and configuration documentation is present before making a release. Configuration audits should be considered at the following times: Shortly after changes to the Configuration Management System; Before and after changes to the IT services or infrastructure; Before a release or installation to ensure that the environment is as expected; Following recovery from disasters and after a ‘return to normal’; At planned intervals; At random intervals; and In response to the detection of any unauthorized Configuration Items.

3.67 Roles

We will now discuss the roles pertaining to Service Asset and Configuration Management. • SACM Process Owner The responsibilities of SACM process owner are : • Generic process owner responsibilities; • Agreeing and documenting the scope for SACM, including the policy for determining which service assets should be treated as configuration items; and • Working with other process owners to ensure there is an integrated approach to the design and implementation of SACM, change management, release and deployment management, and knowledge management. • SACM Process Manager The responsibilities include : • Generic process manager responsibilities; • Accountable to the organization for stewardship of fixed assets of the organization that are under the control of IT; • Defining and agreeing the service assets that will be treated as configuration items; • Ensuring that configuration data is available when and where it is needed to support other service management processes; • Planning and managing support for SACM tools and processes; and • Coordinating interfaces between SACM and other processes, especially change management, release and deployment management, and knowledge management. • Configuration Analyst The responsibilities of this role are : • Proposing scope for service asset and configuration management; • Supporting the process owner and process manager in the creation of principles, processes and procedures; • Defining the structure of the configuration management system, including CI types, naming conventions, required and optional attributes and relationships; • Training staff in SACM principles, processes and procedures; and • Performing configuration audits. • Configuration Librarian The responsibilities of a configuration librarian are : • Controlling the receipt, identification, storage and withdrawal of all supported CIs; • Maintaining status information on CIs and providing this as appropriate; • Archiving superseded CIs; • Assisting in conducting configuration audits; and • Identifying, recording, storing and distributing issues relating to service asset and configuration management.

3.68 Inputs and Outputs

We know that every process takes defined inputs and turns them into defined outputs. A number of predefined set of activities are performed between these two points. The quality of activities executed and outputs produced are invariably dependent on the quality of inputs received. We shall now look at the inputs and outputs relating to Service Asset and Configuration Management. The inputs to Service Asset and Configuration Management are : • Designs, plans and configurations from service design packages; • Requests for change and work orders from change management; • Actual configuration information collected by tools and audits; and • Information in the organization’s fixed asset register. Outputs: • New and updated configuration records; • Updated asset information for use in updating the fixed asset register; • Information about attributes and relationships of configuration items, for use by all other service management processes; • Configuration snapshots and baselines; • Status reports and other consolidated configuration information; and • Audit reports. Let us now proceed to understand the interfaces of SACM process.

3.69 Triggers

In our last few slides we learned the Inputs, Outputs and KPIs of SACM process. This slide explains the Triggers and Interfaces of SACM process. Updates to asset and Configuration information are triggered by change requests, purchase orders, acquisitions and service requests. The interfaces are explained in the next slide.

3.70 Interfaces

In continuation to our last slide this slide explains the Interfaces of SACM process. By its very nature – as the single virtual repository of Configuration Data and information for IT Service Management – SACM supports and interfaces with every other process and activity to some degree. Some of the more noteworthy interfaces are: • Change Management – identifying the impact of proposed changes • Financial management – capturing key financial information such as cost, depreciation methods, owner and user (for budgeting and cost allocation), maintenance and repair costs • ITSCM(pronounced as I-T-S-C-M) – awareness of assets the Business services depend on, control of key spares and software • Incident or problem or error – providing and maintaining key diagnostic information; maintenance and provision of Data to the service desk • Availability management in detection of points of failure. The relationship with change and release and deployment is synergistic, with these processes benefiting greatly from a single coordinated planning approach. Configuration control is synonymous with change control – understanding and capturing updates of the infrastructure and services. Let’s now look into the critical success factors, challenges and risks of the SACM process.

3.71 CSFs and KPIs

We will now discuss the critical success factors and key performance indicators relating to Service Asset and Configuration Management process. • ‘Accounting for, managing and protecting the integrity of CIs throughout the service lifecycle’ is considered as an important critical success factor for this process. The relevant key performance indicators are ‘Improved accuracy in budgets and charges for the assets utilized by each customer or business unit’; ‘Reduction in the use of unauthorized hardware and software, non-standard and variant builds that increase complexity, support costs and risk to the business services’; and ‘Reduced number of exceptions reported during configuration audits’. • Another critical success factor is ‘Supporting efficient and effective service management processes by providing accurate configuration information at the right time’. The relevant key performance indicators are: ‘Improved speed for incident management to identify faulty CIs and restore service’; ‘Improved ratio of used licences against paid-for licences’; and ‘Reduction in risks due to early identification of unauthorized changes’. • Another essential critical success factor for this process is ‘Establishing and maintaining an accurate and complete configuration management system’. The key performance indicators are: ‘Reduction in business impact of outages and incidents caused by poor service asset and configuration management’; ‘Increased quality and accuracy of configuration information’ and ‘Improved audit compliance’. The last topic in this structured discussion is ‘Challenges and Risks’ relating to Service Asset and Configuration Management process. Let us discuss them in the next slide.

3.72 Challenges and Risks

The challenges are: • Persuading technical support staff to adopt a checking in/out policy – as this is considered as an unnecessary overhead and might impact responsiveness of support teams. The remedy to this challenge is to educate the concerned staff about the importance and benefits derived by adopting such policies. • Attracting and justifying funding for Service Asset and Configuration Management is another key challenge. This is because business does not see a direct relevance and benefit from this process. Financial Management for IT should ensure proper allocation of funds by developing overall budgets. • An attitude of ‘just collecting data because it is possible to do so’ is another challenge which would lead to data overload resulting in unproductive effort and expenses. Mapping data to process objectives and requirements is the best way to curb this challenge. • Lack of commitment and support from management who may not understand the importance of this process in supporting other processes. Presentations and seminars on best practices in service management will be a good response for this challenge. The risks associated with the Service Asset and Configuration Management are : • The temptation to consider this process as technically focused. Proper education on service management best practices and concepts is the way to mitigate this risk. • Degradation of the accuracy of configuration information over time can be another risk. Ensuring regular verification and audits can eliminate this risk. • Setting the scope too wide or too narrow may lead to benefits not aligned to effort and costs spent. This will normally mature over a period of time and with experience. • The Configuration Management System becomes out of date due to the movement of hardware assets by non-authorized staff. Regular physical audits should be conducted with discrepancies highlighted and investigated to mitigate this risk.

3.75 Release And Deployment Management

We will now proceed to make a detailed study of the fourth process within the Service Transition stage of the Service lifecycle -the ‘Release And Deployment Management’ process.

3.76 Purpose And Objectives

The purpose of Release and Deployment Management process is to plan, schedule and control the build, test and deployment of releases, and to deliver new functionality required by the business while protecting the integrity of existing services. The objectives of this process are to: • Define and agree release and deployment management plans with customers and stakeholders; • Create and test release packages that consist of related configuration items that are compatible with each other; • Ensure that the integrity of a release package and its constituent components is maintained throughout the transition activities, and that all release packages are stored in a Definitive Media Library and recorded accurately in the Configuration Management System; • Deploy release packages from the Definitive Media Library to live environment following an agreed plan and schedule; • Ensure that all release packages can be tracked, installed, tested, verified and/or uninstalled or backed out if appropriate; • Ensure that organization and stakeholder change is managed during release and deployment activities; • Ensure that a new or changed service and its enabling systems, technology and organization are capable of delivering the agreed utility and warranty; • Record and manage deviations, risks and issues related to the new or changed service and take necessary corrective action; • Ensure that there is knowledge transfer to enable the customers and users to optimize their use of the service to support their business activities; and • Ensure that skills and knowledge are transferred to service operation functions to enable them to effectively and efficiently deliver, support and maintain the service according to required warranties and service levels. In the next slide we will learn about the scope of RDM process.

3.77 Scope

In our last few slides we discussed about the goals, objectives and Purpose of Release and Deployment process. This slide explains the Scope of Release and Deployment process. The scope of Release and Deployment Management includes the processes, systems and functions to package, build, and test and deploy a release into production and establish the service specified in the Service Design Package before final handover to service operations. In the next slide we will discuss about the Business value of Release and deployment process.

3.78 Value to Business

Effective Release and Deployment Management enables the service provider to add value to the Business by: • Delivering change, faster and at optimum cost and minimized risk • Assuring that Customers and users can use the new or changed service in a way that supports the Business goals • Improving consistency in implementation approach across the Business change, service teams, suppliers and Customers • Contributing to meeting auditable requirements for traceability through Service Transition. Well-planned and implemented release and deployment will make a significant difference to an organization’s service costs. A poorly designed release or deployment will, at best, force IT personnel to spend significant amounts of time troubleshooting problems and managing complexity. At worst, it can cripple the environment and degrade the live services. Moving on let us discuss the policies and principles of this process.

3.79 Policies

Policies are management intentions and subtle rules to ensure that process activities are aligned to process and service management objectives. With respect to Release and Deployment Management the policies help the organization achieve the correct balance between cost, service stability and agility. Two examples of Release and Deployment Management policies are discussed here. • All changes and releases must be fully tested under a realistic load before they are deployed. We are aware of the consequences of deploying releases without testing or with insufficient testing. This will lead to increased effort and cost towards troubleshooting and fire-fighting incidents and problems during Service Operation, frequent service disruptions and reduced customer satisfaction. This policy ensures against all these impacts. • Another policy could be that ‘all changes to the service will be packaged into annual releases and the only permitted changes between these releases will be to resolve problems that have a major impact on the business’. This police tries to bring in a sense of discipline amongst business and IT teams to plan and implement change as per defined release and deployment schedules rather than adopting ‘as-and-when required’ approach. This will also result in cost efficiency and better management of releases. Let us understand the key concepts of this process in the next slide.

3.80 Key Concepts

There are a number of key concepts we need to acquaint with before we proceed to discuss the process activities. • A Release is one or more changes to an IT service that are built, tested and deployed together. A single release may include changes to hardware, software, documentation, processes and other components. • A Release unit is a set of components of an IT service that are normally released together. A release unit typically includes sufficient components to perform a useful function. For example, a payroll application along with IT operations procedures and user training will form a release unit. • A Release Package is a set of configuration items that will be built, tested and deployed together as a single release. Each release package will usually include one or more release units. • Deployment is the activity responsible for movement of new or changed hardware, software, documentation, process, etc. to the live environment. • Early Life Support is a stage in the service lifecycle that occurs at the end of deployment and before the service is fully accepted into operation. During this stage the service provider reviews key performance indicators, service levels and monitoring thresholds and may implement improvements to ensure that service targets are met. The service provider may also allocate additional resources for incident and problem management during this period. • The various approaches to release are: Big Bang vs. Phased, Push vs. Pull and Automation vs. Manual. • In Big Bang approach the new or changed service is deployed to all user areas in one operation. This will often be used when introducing an application change and consistency of service across the organization is considered important. In case of Phased approach the service is deployed to a part of the user base initially, and then this operation is repeated for subsequent parts of the user base via a scheduled deployment plan. • A push approach is used where the service component is deployed from the centre and pushed out to the target locations. A pull approach is used for software releases where the software is made available in a central location, but users are free to pull the software down to their own location at a time of their choice or when a user workstation restarts. • Automation approach is used to ensure repeatability and consistency of deploying releases. It is also more cost efficient. Manual approach is adopted only when releases are to be deployed on fewer systems or the procedure requires more human intervention. Manual releases are sometimes error–prone and may slow down deployments. Let us look at the few more concepts in the next slide.

3.81 Key Concepts

• Release design options and considerations : Service Design will define the approach to transitioning from the current service to the new or changed service or service offering. It will select the most suitable release and deployment models that include the approach, mechanisms, processes, procedures and resources required to build, test and deploy the release on time and within budget. • Release and deployment models will include the following aspects : • Release structure covering the overall structure for building a release package and the target environments; • The exit and entry criteria, including mandatory and optional deliverables and documentation for each stage; • Controlled environments required to build and test the release for each release level; there will be multiple logical and physical environments through the service transition stage mapped to different physical environments available to the transition team; • The roles and responsibilities for each configuration item at each release level; • The release promotion and configuration baseline model; • Template release and deployment schedules; • Supporting systems, tools and procedures for documenting and tracking all release and deployment management activities; and • The handover activities and responsibilities for executing the handover and acceptance for each stage of release and deployment management. Moving on, in the next few slides we will learn about the activities of RDM process.

3.82 Process Activities

There are a number of activities performed under Release and Deployment. These activities can be aligned to the four phases of – Release and deployment planning, Release build and test, Deployment and Review and close. Let us go phase by phase and discuss the activities in each phase. We shall stat with ‘Release and Deployment Planning’. This phase basically starts in Service Design stage of service lifecycle and the Design Coordination process ensures that all the release and deployment plans are incorporated in the Service Design Package. • The first activity within this phase is to ‘Prepare Release and Deployment plans’. These plans become part of the overall transition plan and contain information covering: 1.Scope and content of the release; 2.Risk assessment and risk profile for the release; 3.Organizations and stakeholders affected by the release; 4.Stakeholders that may authorize the change at each stage of the release; 5.Team responsible for the release; 6.Deployment schedule for the release; 7.Approach to working with stakeholders and deployment groups. • The next activity is to ‘establish pass/fail criteria’ for the release. These criteria are used to check if the release has met the documented specifications and requirements at each authorization point. It is important to communicate these criteria to relevant stakeholders well in advance to set expectations correctly. • The next activity is to ‘develop build and test plans’. The individual build and test plans are developed based on the Service Design Packages, design specifications and environment configuration requirements. These plans establish the approach and procedures to building, testing and maintaining the controlled environments prior to deployment in live environments. • Another activity within the Release and Deployment Planning phase is ‘Financial and commercial planning’. This activity is concerned with ensuring that adequate funding is available and all contracts and licences are in place for the build and test phase. We shall now discuss in detail the ‘Release Build and Test’ phase. This phase starts with Change Management authorization to build the release and ends with Change Management authorization to check-in the baselined release packages into the Definitive Media Library. The activities executed during this phase are : • Create release and build documentation : All the relevant procedures, templates and guidance to receive components and to build an integrated release package are documented. • Acquire and test input configuration items and components : Is concerned with acquiring configuration items and components from projects, suppliers, partners and development groups. Ensuring that proof of license can be demonstrated and establishing that all items are correct and have genuinely been ordered or required, are some of the important tasks within this activity. • Build and Package release : This activity ensures that the release package is built in a standard, controlled and reproducible way in line with the solution design defined in the Service Design Package. • Build and manage test environments : Dedicated build and test environments are established for assembling, building and testing the release components as well as the release package. • Service testing and pilots : Testing aims to build confidence in the service capability prior to final acceptance. The test criteria reflect the anticipated conditions in which the service is expected to operate and deliver benefit. Pilot releases are made to detect if any elements of the service is not able to perform as required and to identify any gaps/issues in service management. • Service rehearsals : are performed just before deployment of the service. It is a simulation of as much of the service as possible in an extensive and widely participatory practice session.

3.83 Process Activities

The third phase is ‘Deployment’. This phase is responsible for movement of new or changed hardware, software, documentation, processes, etc. to the live environment. The activities in this phase are : • Plan and prepare for deployment – While the overall approach to planning the deployment is prepared during the first phase ‘Release and Deployment Planning’, the detail implementation plan is developed during this phase. • Assess readiness of target groups is the activity of identifying issues and risks, anticipated impacts and gaps that need to be filled. • Specific deployment plans are developed which include identifying resources to perform deployment and early life support activities. • Perform transfer, deployment and retirement takes care of executing the deployment as detailed in the deployment plan. The steps involved are : • Change/Transfer of financial assets including supplier agreements, new licenses or renewals, annual maintenance agreements and transfer of intellectual property. • Transfer/Transition of business and organization activity involves establishing the final organization structure, communicating the changed roles and responsibilities, adherence to new policies and practices and creating awareness on continuity plans and procedures. • Deploy processes and materials is the activity of publishing the new or changed processes and procedures and ensuring that all people involved are trained on these new process and procedures. • Deploy service management capability is concerned with deploying processes, systems and tools to the service provider teams responsible for service management. • Transfer service – is the act of passing the ownership and control of the service to the new organization or service provider. • Deploy service involves carrying out activities to distribute and install the service, supporting services, applications, data, information, infrastructure and facilities. • Decommissioning and service retirement is an important step to ensure that those services or service components that have been identified for decommissioning and retirement are systematically removed from live environments. This involves taking into account any security, confidentiality, licensing, environmental, regulatory and contractual requirements. • Remove redundant assets – where services have been retired, the assets not required any more need to be identified and removed. These may later be allocated for other services. This ensures savings in license fees and utilization of spare capacity. • Verify deployment – involves verifying that users, service operation functions, staff and stakeholders are capable of using the services as expected. Feedback needs to be gathered and report on issues faced and incidents logged should be created. • Remediate / Back out release is performed based on decision taken due to milestones not met, deployment steps failed or verification indicates that deployment is not successful. • Early life support is the systematic way of transitioning new or changed service to service operation in a controlled manner. The last phase is to ‘review and close’. This consists of two levels of review and closure : • Review and close deployment part takes care of documenting the experiences and feedback of customers, users, service providers and release and deployment teams; review of risk register to identify residual risks and their mitigation plans; removal of redundant assets and performing a post implementation review. • Review and close service transition part is concerned with checking that all transition activities are completed and ensuring that accurate metrics were captured. A transition report is produced to summarize the outcomes, lessons learned as well as achievements.

3.84 Roles

Let us now take a look at the Release and Deployment Management related roles : • Release and Deployment Management Process Owner The responsibilities are : • Generic process owner responsibilities; • Designing release models and workflows; and • Working with other process owners to ensure there is an integrated approach to the design and implementation of change management, service asset and configuration management, release and deployment management, and service validation and testing. • Release and Deployment Management Process Manager The responsibilities of this process manager are : • Generic process manager responsibilities; • Planning and coordinating all resources needed to build, test and deploy each release, including resources from other functions such as technical management or application management; • Planning and managing support for release and deployment management tools and processes; • Ensuring that change authorization is provided before any activity that requires the authorization, for example before a release is checked in to the definitive media library or before it is deployed to a live environment; and • Coordinating interfaces between release and deployment management and other processes, especially change management, SACM, and service validation and testing. • Release Packaging and Build Practitioner The responsibilities are : • Helping to design the release package, during the service design stage of the service lifecycle, in conjunction with personnel from other teams and functions; • Establishing the final release configuration, including knowledge, information, hardware, software and infrastructure; • Building the release; • Testing the release prior to independent testing; • Establishing and reporting outstanding known errors and workarounds; and • Providing input to support change authorization for check-in of the release to the DML. • Deployment Practitioner The responsibilities of a deployment practitioner are : • Helping to plan the deployment, during the service design stage of the service lifecycle, in conjunction with personnel from other teams and functions; • Ensuring that all deployment activities have been authorized by change management; • Carrying out the final physical delivery of the deployment; • Coordinating release documentation and communications, including training and customer, service management and technical release notes; • Providing technical and application guidance and support throughout the release process, including known errors and workarounds; • Providing feedback on the effectiveness of the release; and • Recording and reporting deployment metrics to ensure that these are within agreed SLAs. • Early Life Support Practitioner The responsibilities are : • Providing IT service and business functional support from deployment to final acceptance; • Ensuring delivery of appropriate support documentation; • Providing release acceptance for provision of initial support; • Providing support to assist the service desk in responding to incidents and errors detected within a new or changed service; • Adapting and perfecting elements that evolve with final usage; • Embedding activities for a new or changed service; • Dealing with final transition of the service to service operation and continual service improvement; • Monitoring incidents and problems and undertaking problem management during release and deployment, raising RFCs as required; and • Providing initial performance reporting and undertaking service risk assessment based on performance. • Build and Test Environment Manager The key responsibilities of the Build and Test Environment Manager are : • Ensuring that service infrastructure and application are built to design specification; • Planning the acquisition, build, implementation and maintenance of ICT infrastructure; • Ensuring that all components are from controlled sources; • Developing an integrated application software and infrastructure build; • Delivering appropriate build, operations and support documentation for the build and test environments; and • Building, delivering and maintaining required test environments. As we have an understanding of the roles, let us look at the triggers, inputs and outputs of RDM in the next slide.

3.85 Inputs and Outputs

Let us now discuss the inputs and outputs of Release and Deployment process. The release process commences with receipt of an approved RFC to deploy a production-ready release package. Deployment commences with receipt of an approved RFC to deploy a release package to a target deployment group or environment, e.g. Business unit, customer group and/or service unit. The Inputs are: • Authorized RFC • Service package, SLP, SDP, including service model and SAC • IT service Continuity plan and related Business Continuity plan • Service Management and operations plans and standards, Technology and procurement standards and catalogues • Acquired service assets and components and their documentation • Build models and plans • Environment requirements and specifications for build, test, release, training, disaster recovery, pilot and deployment • Release policy and release design from Service Design and • Exit and entry criteria for each stage of release and deployment. The outputs are: • Release and deployment plan • Completed RFCs for the release and deployment activities • Service notification • Updated service catalogue with the relevant information about the new or changed service • New tested service capability and environment including SLA and • Service Transition Report. Moving ahead let us look at the KPIs, interfaces and triggers of Release and deployment process.

3.86 Interfaces

The interfaces of RDM with other processes are: • Service Design Coordination – process creates service design packages. Release and deployment management also plays a vital role in production of SDP. Plans and packages should be developed and document during the service design stage of the service lifecycle, and service design coordination will ensure that these are documented in the SDP. • Transition Planning and Support – provides the framework for release and deployment management to operate in, and transition plans provide the context for release and de3ployment plans. • Change Management – RDM must be tightly integrated with change management. Change management provides the authorization for the work that is carried out by RDM and RDM provides the actual execution of many changes. • Service Asset and Configuration Management – RDM depends on data and information in the CMS and provides many updates to the CMS. It is important that these updates are coordinated and managed properly as otherwise the data will not be kept up to date. • Service Validation and Testing – RDM must coordinate with service validation and testing, to ensure that testing is carried out when necessary and that builds are available when required by service validation and testing.

3.87 CSFs and KPIs

We will now look at some of the important critical success factors and key performance indicators relating to Release and Deployment process. ‘Defining and agreeing release plans with customers and stakeholders’ is one critical success factor for ensuring that plans are aligned to business timelines and requirements. The related key performance indicators are : ‘Increased number and percentage of releases that make use of a common framework of standards, re-usable processes and supporting documentation’; and ‘Increased number and percentage of releases that meet customer expectations for cost, time and quality’. The next one is ‘Ensuring integrity of a release package and its constituent components throughout the transition activities’. The relevant key performance indicator are : ‘Reduced number of Configuration Management System and Definitive Media Library audit failures related to releases’; ‘Reduced number of deployments from sources other than the Definitive Media Library’; and ‘Reduced number of incidents due to incorrect components being deployed’. Another critical success factor that can be of great significance is ‘Ensuring that the new or changed service is capable of delivering the agreed utility and warranty’. The key performance indicators are : ‘Reduced variance from service performance required by customers’; ‘Number of incidents against the service’; and ‘Increased customer and user satisfaction with the services delivered’.

3.88 Challenges and Risks

Proactive approach is one of the key elements of ITIL framework. Identifying the critical success factors, key performance indicators, challenges and risks are key for successful process implementation, execution and improvement. We shall now discuss the Release and Deployment process related challenges and risks. The challenges relating to Release and Deployment process are: • Developing standard performance measures and measurement methods across projects and suppliers; • Dealing with projects and suppliers where estimated delivery dates are inaccurate and there are delays in scheduling service transition activities; • Understanding the different stakeholder perspectives that underpin effective risk management for the change impact assessment and test activities; • Building a thorough understanding of risks that have impacted or may impact successful service transition of services and releases; and • Encouraging a risk management culture where people share information and take a pragmatic and measured approach to risk. Release and Deployment related risks include : • Poorly defined scope and understanding of dependencies in earlier lifecycle stages which may lead to scope creep during release and deployment management; • Using staff who are not dedicated to release and deployment management activities, especially for large projects and releases; • Failing to use the release and deployment management process to manage service retirement; • Inadequate finances; • Inadequate controls like lack of corporate policies or no licenses tracking system; and • Risks relating to management of organizational and stakeholder change. Next, we will learn about Service validation and testing process.

3.89 Service Validation And Testing

Service validation and Testing is the “Quality Assurance” part of the service solution. The utility and warranty of service delivered in live environment reflects the efficiency and effectiveness of this process. While validation ensures meeting business requirements, testing is concerned with meeting specifications.

3.90 Purpose And Objectives

The purpose of Service Validation and Testing is to ensure that a new or changed IT service matches its design specification and will meet the needs of the business. The objectives of Service Validation and Testing are to : • Provide confidence that a release will create a new or changed service that delivers the expected outcomes and value for the customer within the projected costs, capacity and constraints; • Quality assure a release, its constituent service components, the resultant service and service capability delivered by a release; • Validate that a service is ‘fit for purpose’; • Provide assurance that a service is ‘fit for use’; • Confirm that the customer and stakeholder requirements for the new or changed service are correctly defined and remedy any errors or variances early in the service lifecycle; • Plan and implement a structured validation and testing process that provides objective evidence that the new or changed service will support customer’s business and stakeholders requirements, including the agreed service levels; and • Identify, assess and address issues, errors and risks throughout service transition. Let’s understand the scope of SVT process in the next slide.

3.91 Scope

The scope of Service Validation and Testing includes : • All services throughout the service lifecycle to quality assure any aspect of a service and the service providers’ capability, resources and capacity to deliver a service or release successfully; • Interfaces with suppliers, customers and partners to ensure end-to-end service; • Testing of new or changed services or service components developed in-house; • Support release and deployment process by performing appropriate levels of testing; and • Evaluation of detailed service models to ensure that they are fit for purpose and fit for use before being authorized to enter service operation. In the next slide we will understand the SVT process value to business.

3.92 Value To Business

Like all the processes that we have discussed so far, Service Validation and Testing process is of key value to business. Let us understand this in detail: As we know that Service failures can harm the service provider’s Business and the customer’s assets and result in outcomes such as loss of reputation, loss of money, loss of time, injury and death. The key value to the Business and Customers from Service Testing and Validation is in terms of the established degree of confidence that a new or changed service will deliver the value and outcomes required of it and understanding the risks. Successful testing depends on all parties understanding that it cannot give, indeed should not give, any guarantees but provides a measured degree of confidence. The required degree of confidence varies depending on the customer’s Business requirements and pressures of an organization. Now, let’s learn about the policies and principles of this process in the next slide.

3.93 Policies And Principles(1 of 4)

In our last slide we discussed about the Business value of Service Validation and Testing. From this slide onwards the Policies and Principles of Service Validation and Testing process will be discussed. Let us discuss policies first. The policies for service validation and testing process will reflect requirements from service strategy and service design and should help service validation and testing staff to meet the expectations of the business. Typical policy statements might include All the tests must be designed and carried out by people who are not part of design and development Test pass and fail criteria must be documented in a service design package which is called SDP before start of any testing and every test environment must be restored to a known state before starting the testing Test library and reuse policy creating provides benefits as the nature of IT service management is repetitive. Integrating testing into project and service lifecycle helps to detect and remove functional and non-functional defects as soon as possible and reduces the incidents in live environment Adopt a risk based testing approach aimed at reducing risk to the service and customer’s business Engage with customers, users and service teams throughout the project and service lifecycle to enhance their testing skills and capture feedback on the quality of services and service assets Establish test measurements and monitoring system to improve the efficiency and effectiveness of service validation and testing Automate using automated testing tools and systems in particular for the complex systems and critical changes requirement with shorter duration. In the next slide we will continue to look into the policies of service validation and testing

3.94 Policies And Principles(2 of 4)

As I said we continue to look into other policies. Service Quality Policy, As per the policy, Senior leadership will define the meaning of service quality and Service Strategy discusses the quality perspectives that a service provider needs to consider. In addition to service level metrics, service quality takes into account the positive impact of the service (utility) and the certainty of impact warranty. The four quality perspectives are: • Level of Excellence • Value for money • Conformance to specifications • Meeting or exceeding expectations Second policy is the Risk Policy, Different customer segments, organizations, Business units and service units have different attitudes to risk. Where an organization is an enthusiastic taker of Business risk, testing will be looking to establish a lower degree of confidence than safety as critical or regulated an organization might seek. The risk policy will influence control required through Service Transition including the degree and level of validation and testing of service level requirements, utility and warranty, i.e. availability risks, security risks, continuity risks and capacity risks. Moving on to the third policy which is Release Policy, this emphasizes on the point that the type and frequency of releases will influence the testing approach. Hence Frequent releases such as once-a-day drive requirements for reusable test models and automated testing is paid attention. The fourth policy is the Change Management Policy, the use of change windows can influence the testing that needs to be considered. For example if there is a policy of ‘substituting’ a release package late in the change schedule or if the scheduled release package is delayed then additional testing may be required to test this combination if there are dependencies. Let us look at the last policy which is service transition policy in the next slide.

3.95 Policies And Principles(3 of 4)

This slide is about Service Transition Policy The Service Transition Policy which talks about, the validation and testing policies need to adhere to the overall Service Transition policies. Some of the policies include • Define and implement a formal policy for service transition • Implement all changes to services through service transition • Adopt a common framework and standards • Maximize re-use of established processes and systems • Align service transition plans with the business needs • Establish and maintain relationships with stakeholders • Establish effective controls and disciples • Provide systems for knowledge transfer and decision support • Plan release packages • Anticipate and manage course corrections • Proactively manage resources across service transitions • Ensure early involvement in the service lifecycle • Provide assurance of the quality of the new or changed service • Proactively improve quality during service transition Let’s continue to discuss the principles in the next slide.

3.96 Policies And Principles(4 of 4)

In continuation to the Policies, this slide talks about the Principles of Service Validation and Testing process. Let us understand the concept of service, “A service” is defined by a service package that comprises one or more service level packages (SLPs) (pronounced as S-L-Ps) and re-usable components, many of which themselves are services, e.g. supporting services. The service package defines the service utilities and warranties that are delivered through the correct functioning of the particular set of identified service assets. The next principle is design of a service, it is related to the context in which a service will be used (the categories of customer asset). The attributes of a service characterize the form and function of the service from a utilization perspective. • The Service Design Package defines the agreed requirements of the service, expressed in terms of the service model and Service Operations plan that provide key input to test planning and design and lastly the • Service models show how service assets interact with customer assets to create value. Service models describe the structure of a service (how the configuration items fit together) and the dynamics of the service (activities, flow of resources and interactions). A service model can be used as a template or blueprint for multiple services. Like all other processes, in the next slide let us look into the key concepts of Service validation and testing.

3.97 Key Concepts

In this slide we will learn some of the key concepts of service validation and testing Service Quality and Assurance: Is delivered through verification and validation, which in turn are delivered through testing or by comparison or review against standards and specifications. Validation confirms that the requirements for a specific intended use or application have been fulfilled. Also it provides confidence that a system or service is able to accomplish its intended goals and objectives. For Ex: Capacity and demand Verification is confirmation, through the provision of objective evidence, that specified requirements have been fulfilled. For Ex: service asset meets its specification Test Strategy: Defines the overall approach to organizing testing and allocating testing resources. A test strategy may cover the whole organization, a set of services or an individual service. Involvement of appropriate stakeholders must be ensured while developing test strategies to get their buy-in for the approach. Some of the activities are • Translating service requirements and service design into test requirements and test models. • Establishing best approach to optimize the test coverage • Translating the service acceptance criteria into entry and exit criteria at each level of testing • Translating risks and issues from the impact, resource and risk assessments into test requirements • Identification of skills, people and defining roles and responsibilities • Understanding mandatory and optional deliverables • Defining managing, monitoring and controlling the testing activities SAT or Service Acceptance Testing starts with verification of the service requirements. The stakeholders who signs off include business customers, users, suppliers and service providers. In the next slide we will continue to learn the key concepts.

3.98 Key Concepts

This slide is about test model, testing perspectives and levels of testing. A Test Model consists of a test plan, information on what is to be tested and the test scripts that define how each element will be tested. It ensures that testing is executed consistently in a repeatable way that is effective and efficient. It also: • Provides traceability back to the requirements • Enables auditing through test execution, evaluation and reporting • Ensures test elements can be managed and changed Effective validation and testing focuses on delivery as per requirements based on users, deploy, and operating perspective. Testing Perspective includes • Service design—functional, management and operational • Technology design • Process design • Measurement design • Documentation • Skills and knowledge Building each level of testing to be performed is very important so as to meet the entry and exit criteria using different test model. V-Model is one of the examples. In the next slide we will discuss the V-model description.

3.99 Key Concepts: Service V - Model

In continuation to the last slide let us discuss about the Service V-Model. The figure on the slide is the representation of the V-model. Testing is related directly to the building of service assets and products so that each one has an associated acceptance test and activity to ensure it meets requirements. This involves testing individual service assets and components before they are used in the new or changed service. Each service model and associated service deliverable is supported by its own re-usable test model that can be used for regression testing during the deployment of a specific release as well as for regression testing in future releases. Test models help with building quality early into the service lifecycle rather than waiting for results from tests on a release at the end. Using a model such as the V-model builds in Service Validation and Testing early in the service lifecycle. It provides a framework to organize the levels of configuration items to be managed through the lifecycle and the associated validation and testing activities both within and across stages. The level of test is derived from the way a system is designed and built up. This is known as a V-model, which maps the types of test to each stage of development. The V-model provides one example of how the Service Transition levels of testing can be matched to corresponding stages of service requirements and design. The left-hand side represents the specification of the service requirements down to the detailed Service Design. The right-hand side focuses on the validation activities that are performed against the specifications defined on the left-hand side. At each stage on the left-hand side, there is direct involvement by the equivalent party on the right-hand side. It shows that service validation and acceptance test planning should start with the definition of the service requirements. For example, Customers who sign off the agreed service requirements will also sign off the service Acceptance Criteria and test plan. Let us now move on to our next slide, and look at the activities, techniques & methods.

3.100 Key Concepts

This is the last slide about the key concepts of service validation and testing. Testing approaches and techniques is about different approaches that can be combined to meet the requirements of different types of service, service model, risk profile, skill levels, test objectives and levels of testing. Example includes document review, simulation, scenario testing, prototyping and regression testing. Design considerations aims to develop test models and test cases that measure the correct things in order to establish whether the service will meet its intended use within the specified constraints. Different types of testing includes • Service requirements and structure testing - Stakeholders are service provider users and customers. • Service level testing - Stakeholders are service level managers, operational managers and customers. • Warranty and Assurance tests - It is fit for use testing (Availability, Capacity, Continuity and Security) • Usability testing - Stakeholders are users and Maintainers. • Contract and regulation testing is mainly about Audits • Compliance testing, for example fraud check • Other testing’s are service management testing, Operational tests like Systems, services and Regression Testing Let us move to the next slide and discuss the Process activities, methods and techniques.

3.101 Activities, Methods, Techniques: The Process

This slide is about Process activities, methods and techniques. The test activities are not undertaken in a sequence. Several activities may be done in parallel, for example, test execution can begin before all the test design is complete. The activities are Validation and test management, plan and design ,test verify, test plan and test design, prepare test environment, perform tests, evaluate exit criteria and report and lastly test clean up and closure. Let’s list out them once again in the next slide.

3.102 Process Activities

The validation and test management activities include planning test resources, prioritizing and scheduling, monitoring progress, managing incidents, problems and errors, capturing configuration baseline, test metrics collection, analysis, reporting and management. Plan and design test include resourcing, understanding the resource requirements, skills, capacity, scheduling milestone, handover, delivery, budgeting and funding. Verify test plan and test design ensures test model delivers adequate and appropriate coverage, covers integration part and test scripts are accurate and complete Prepare test environment is about planning, building and baseline the test environment. Perform test carries out the test using manual and or automated scripts. Testers record failures and report the same. The deliverables include results showing proof of testing, problems, errors and issues, resolved problem and sign off. Evaluate exit criteria and reports the service meeting the requirement and baseline configurations into the CMS. Test clean up and closure ensures test environment is cleaned up or initialized. In the next few slides we will be discussing each of these activities in detail.

3.103 Validation And Test Management

In continuation to our last slide this slide explains the first Activity: Validation and test management of Service Validation and Testing process. Test management includes the planning, control and reporting of activities through the test stages of Service Transition. These activities include: • Planning the test resources • Prioritizing and scheduling what is to be tested and when • Management of incidents, problems, errors, non-conformances, risks and issues • Checking that incoming known errors and their documentation are processed • Monitoring progress and collating feedback from validation and test activities • Management of incidents, problems, errors, non-conformances, risks and issues discovered during transition • Consequential changes, to reduce errors going into production • Capturing Configuration baseline • Test metrics collection, analysis, reporting and management. Test management includes managing issues, mitigating risks and implementing changes identified from the testing activities as these can impose delays and create dependencies that need to be proactively managed. Let us now proceed to look into the next activity, Plan and design test.

3.104 Plan And Design Test

In our last slide we discussed about: Validation and test management of Service Validation and Testing process. This slide explains the second Activity: Plan and design test. Test planning and design activities start early in the service lifecycle and include: • Planning of adequate Resourcing • Preparing for the Hardware, networking, staff numbers and skills, capacity etc. • Identifying the Business/customer resources required, e.g. components or raw materials for production control services, cash for ATM services • Supporting services including access, security, catering, communications • Design and plan the Schedule of milestones, handover and delivery dates • Acknowledge the Agreed time for consideration of reports and other deliverables • Agree on the Point and time of delivery and acceptance • And lastly arranging and planning the financial requirements – budgets and funding. Moving on, in the next slide we will learn about Verifying test plan and design.

3.105 Verify Test Plans And Test Design

Verify test plan and test design is the third activity of Service Validation and testing process. Verifying the test plans and test design is essential basically to ensure that: • The test model delivers adequate and appropriate test coverage for the risk profile of the service • The test model also covers the key integration aspects and interfaces, e.g. at the SPIs • And to ensure that the test scripts are accurate and complete. The next slide talks about preparing test environment.

3.106 Prepare Test Environment

In our last slide we discussed about the third activity: Verify test plan and test design of SVT process. This slide explains the fourth Activity: Prepare test environment of Service Validation and Testing process. This process is responsible to prepare the test environment by using the services of the build and test environment resource and also use the release and deployment processes to prepare the test environment where possible; Capture a Configuration baseline of the initial test environment. Now let us proceed to learn about performing tests.

3.107 Perform Tests

In our last slide we discussed about the fourth Activity: Prepare test environment of SVT process. This slide explains the fifth Activity: Perform tests of Service Validation and testing process. Once planning and preparation is done the team has to start the tests. Team has to carry out the tests using manual or automated techniques and procedures. Testers must record their findings during the tests. If a test fails, the reasons for failure must be fully documented. Testing should continue according to the test plans and scripts, if at all possible. When part of a test fails, the incident or issues should be resolved or documented (e.g. as a known error) and the appropriate re-tests should be performed by the same tester. In the next slide we will look at the graphical representation of the test activities.

3.108 Perform Tests - Activities Involved

In continuation to the activity Perform tests, this slide shows the flow chart of the activities. The picture shows the various test activity on the basis of which tests flow proceeds. We have already discussed few steps in previous slides Perform test may results in incident or issue or risk. If there are no such incidents then we can look for exit criteria. If any incident or issue or risk found during perform test, resolve incidents and issues, mitigate risks and look for exit criteria. The diagram shows all the steps. In the next slide will continue to discuss the remaining activities.

3.109 Evaluate Exit Criteria And Report

The next activity is to ‘evaluate exit criteria and report’. This will determine if the Service Validation and testing can be treated as completed or not and if test environments and resources can be released or not. In this activity : • The actual results are compared to the expected results; • The results are interpreted in terms of pass/fail; risk to the business/service provider; or if there is a change in a projected value; and • A report is produced by gathering the test metrics and summarizing the results of the tests.

3.110 Test Clean Up And Closure

In our last slide we discussed about the Sixth activity: Evaluate exit criteria of SVT process. This slide explains the seventh and last activity: Test clean up and closure of Service Validation and testing process. The Tester team has to ensure that the test environments are cleaned up or initialized. Team has to review the testing approach and identify improvements to input design or build, buy or build decision parameters and future testing policy or procedures. Let us now move on to our next slide on roles involved in this process.

3.111 Roles

We shall now cover the roles and responsibilities relating to Service Validation and Testing process. • Service Validation and Testing Process Owner The responsibilities are : • Generic process owner responsibilities; • Defining the overall test strategy for the organization; and • Working with other process owners to ensure that there is an integrated approach to the design and implementation of change management, change evaluation, release and deployment management, and service validation and testing. • Service Validation and Testing Process Manager The responsibilities of this process manager are : • Generic process manager responsibilities; • Helping to design and plan testing conditions, test scripts and test data sets during the service design stage of the service lifecycle, to ensure appropriate and adequate coverage and control; • Allocating and overseeing test resources, ensuring that test policies are adhered to; • Verifying tests conducted by release and deployment management or other teams; • Managing test environment requirements; • Planning and managing support for service testing and validation tools and processes; and • Providing management reporting on test progress, test outcomes, success rates, issues and risks. • Service Validation and Testing Process Practitioner The responsibilities are : • Conducting tests as defined in the test plans and designs, and documented in the service design package; • Recording, analysing, diagnosing, reporting and managing test events, incidents, problems and retest dependent on agreed criteria; and • Administering test assets and components. In the next slide we will discuss about the trigger, inputs and outputs of the SVT process.

3.112 Triggers, Inputs And Outputs

The trigger for testing is a scheduled activity on a release plan, test plan or quality assurance plan. The key Inputs to the process are: • The service package – This comprises a core service package and re- usable components, many of which themselves are services, e.g. supporting service. It defines the service’s utilities and warranties that are delivered through the correct functioning of the particular set of identified service assets. It maps the demand patterns for service and user profiles to SLPs. • SLP – One or more SLPs that provided a definitive level of utility or warranty from the perspective of outcomes, assets, patterns of business activity of Customers (PBA). • Service provider interface definitions – These define the interfaces to be tested at the boundaries of the service being delivered, e.g. process interfaces, organizational interfaces. • The Service Design Package – This defines the agreed requirements of the service, expressed in terms of the service model and Service Operations plan. It includes: • Operation models (including support resources, escalation procedures and critical situation handling procedures). • Capacity or resource model and plans – combined with performance and availability aspects. • Financial or economic or cost models (with TCO, TCU). • Service Management model (e.g. integrated process model as in ISO/IEC 20000)(pronounced as I-S-O-I-E-C twenty thousand). • Design and interface specifications. • Release and deployment plans – These define the order that release units will be deployed, built and installed. • Acceptance Criteria – These exist at all levels at which testing and acceptances are foreseen. • RFCs – These instigate required changes to the environment within which the service functions or will function. The direct output from testing is the report delivered to service evaluation. This sets out: • Configuration baseline of the testing environment • Testing carried out (including options chosen and constraints faced) • Results from those tests • Analysis of the results, e.g. comparison of actual results with expected results, risks identified during testing activities. After the service has been in use for a reasonable time there should be sufficient Data to perform an evaluation of the actual vs. predicted service capability and performance. If the evaluation is successful, an evaluation report is sent to Change Management with a recommendation to promote the service release out of early life support and into normal operation.

3.113 Interfaces

Testing supports all of the release and deployment steps within Service Transition. Although this module focuses on the application of testing within the Service Transition phase, the test strategy will ensure that the testing process works with all stages of the lifecycle: • Working with Service Design to ensure that designs are inherently testable and providing positive support in achieving this; examples range from including self-monitoring within hardware and software, through the re-use of previously tested and known service elements through to ensuring • Rights of access to third party suppliers to carry out inspection and observation on delivered service elements easily • Working closely with CSI to feed failure information and improvement ideas resulting from testing exercises • Service Operation will use maintenance tests to ensure the continued efficacy of services; these tests will require maintenance to cope with innovation and change in environmental circumstances • Service Strategy should accommodate testing in terms of adequate funding, resource, profile etc. Let us understand the CSFs and KPIs in the next slide.

3.114 CSFs And KPIs

Critical success factors should be determined for each process and they should be aligned to the objectives of the process. Key performance indicators relevant to each critical success factor need to be developed and achievements against them should be monitored and measured. This will help in assessing the maturity of the process and identify improvement opportunities. Some examples of critical success factors and key performance indicators pertaining to Service Validation and Testing shall be discussed now. ‘Understanding the different stakeholder perspectives that underpin effective risk management for the change impact assessment and test activities’ can be a critical success factor aligned to the process objective of ‘Confirm customer and stakeholder requirements’. The related key performance indicators are ‘Roles and responsibilities for impact assessment and test activities have been agreed and documented’; and ‘Increase in satisfaction ratings in stakeholder survey of the service validation and testing process’. Another example of critical success factor can be ‘Providing evidence that the service assets and configurations have been built and implemented correctly in addition to the service delivering what the customer needs’. The relevant key performance indicators are : ‘Increased percentage of service acceptance criteria that have been tested for new and changed services’; and ‘Increased percentage of services for which build and implementation have been tested, separately to any tests of utility or warranty’. ‘Achieving a balance between cost of testing and effectiveness of testing’ is a very important critical success factor that needs to be considered. The related key performance indicators are : ‘Reduced variance between test budget and test expenditure’ and ‘Reduction in business impact due to delays in testing’.

3.115 Challenges And Risks

We shall move on to the challenges and risks pertaining the Service Validation and Testing process. The one biggest challenge for this process is getting the appropriate level of funding. Insufficient funding of testing phase results in : • Inability to maintain a test environment and test data that matches the live environment; • Insufficient staff, skills and testing tools to deliver adequate testing coverage; • Projects overrunning and allocated testing time frames being squeezed to restore project go-live dates but at the cost of quality; • Development of standard performance measures and measurement methods across projects and suppliers; and • Projects and suppliers estimating delivery dates inaccurately and causing delays in scheduling service transition activities. Risks relating to Service Validation and Testing are : • Unclear expectations from stakeholders and ambiguous objectives being set for different types of tests; • Lack of understanding of the risks related to insufficient testing, not meeting entry and exit criteria and non-involvement of relevant stakeholders; and • Resource shortages, which may result in delays to scheduled tests and may also impact other service transitions. Let us now move on to learn about the change evaluation process.

3.118 Change Evaluation

One of the key activities of Change Management is to authorize changes at various stages of a change lifecycle. To make a decision whether to authorize or not is based on the assessment and evaluation of the change. While for some changes a normal impact and risk assessment may be sufficient, for others a separate evaluation may be required to take an informed authorization decision. It is Change Evaluation process that provides the required information to Change Management for taking the appropriate decision.

3.119 Purpose And Objectives

The purpose of Change Evaluation is to provide a consistent and standardized means of determining the performance of a service change in the context of likely impacts on business outcomes, and on existing and proposed services and IT infrastructure. The objectives of Change Evaluation process are to : • Set stakeholder expectations correctly and provide effective and accurate information to Change Management to ensure that changes which adversely affect service capability and introduce risk are not transitioned unchecked; • Evaluate the intended effects of a service change and as much of the unintended effects as is reasonably practical given the capacity, resource and organizational constraints; and • Provide good quality outputs so that Change Management can expedite an effective decision on whether or not to authorize a service change. Let’s understand the scope and value to business in the next slide.

3.120 Scope And Value To Business

It is interesting to note that the Scope of Change Evaluation is limited to only significant changes that require a formal evaluation to provide the change authority with advice and guidance on authorization decisions. It should be noted that this evaluation will take place only at the specific request from Change Management. We shall now look at the value derived by Business from Change Evaluation process. • Change Evaluation establishes the use made of resources in terms of delivered benefit and this information will allow a more accurate focus on value in services being developed and deployed. • Continuous service improvement can benefit a lot from Change evaluation as it provides the ability to analyze future improvements to the process of change and the predictions and measurement of service change performance.

3.121 Policies

As policies represent management intentions and are directed towards service management objectives, they help processes to perform more efficiently. The following policies apply to the Change Evaluation process: • Service designs or service changes will be evaluated before being transitioned.Every change must be evaluated, but only significant changes will use the formal change evaluation process and the criteria for this must be defined to identify which changes are in scope of this process. • Change evaluation will identify risks and issues related to the service that is being changed, and to any other services or shared infrastructure. • Any deviation from predicted to actual performance will be managed by the customer or customer representative by : • Accepting the change even though actual performance is different from what was predicted, • Rejecting the change, or • Requiring a new change to be implemented with revised predicted performance agreed in advance.

3.122 Principles

In our last slide we discussed about the Policies of change evaluation process. This slide explains the Principles and basic concepts of the change evaluation process. The following principles shall guide the execution of the evaluation process: • As far as it is reasonably practical, the unintended as well as the intended effects of a change need to be identified and their consequences understood and considered. • A service change will be fairly, consistently, openly and, wherever possible, objectively evaluated. • Change Evaluation will be used by the Change Managers for all Major Changes. The basic concept of evaluation process is that, it uses the Plan–Do–Check–Act (PDCA) model to ensure consistency across all evaluations. Let us look at the other key concepts in detail in the next slide.

3.123 Key Concepts

We shall now look at some key concepts relating to Change Evaluation. This would help us understand the subsequent topics on Change Evaluation in a better way. PDCA stands for Plan-Do-Check-Act and the evaluation process should use this model to ensure consistency across all evaluations performed. Performance refers to the utilities and warranties of a service. Basically this represents the value of the service from a customer perspective. Performance Model is a representation of a service that is used to help predict performance. Predicted Performance is the expected performance of a service following a service change. Actual Performance: The performance achieved following a service change. Evaluation Report is a report generated by the change evaluation process, which is passed to change management. It comprises of risk profile, deviations report, recommendation and a qualification statement.

3.124 Process Activities

Now we shall discuss the various process activities pertaining to Change Evaluation. • The first step is to plan evaluation. As the evaluation of significant changes requires collating inputs on intended effects and unintended effects from various perspectives, it needs proper planning. There could be a need to interact with various stakeholders and review all relevant documents to get the required inputs. Hence the Change Evaluation process uses the Plan-Do-Check-Act model for performing evaluations. • The next step is to understand the intended effects of the change. The request for change, change proposal, associated documentation, customer requirements and service design package should be carefully analysed to understand fully the purpose of the change and the expected benefit from implementing it. • Understanding the unintended effects of the change is the next activity performed. To identify the full impact of the service change, it is essential to analyse the additional effects which are not expected or planned for. The unintended effects are hard to predict and identify and may not be beneficial. In the sense they may have negative impact on other services, customers or users. The most effective way of identifying the unintended effects is by discussion with all stakeholders. • Once the intended effects and unintended effects have been identified and documented, the subsequent activity is evaluation of predicted performance. Using customer requirements, acceptance criteria, predicted performance and the performance model, a risk assessment is carried out and an interim evaluation report is submitted to Change Management. • Evaluation of actual performance is the next activity. The actual performance information is collected and evaluated. As evaluation can be requested by Change Management at various stages of change implementation, the extent to which actual performance can be evaluated depends on current stage of the change. An interim evaluation report is submitted to Change Management. • Based on the interim evaluation reports, wherein the identified risks are also listed, Risk Management activity is initiated. All risks are analysed and mitigation plans, where possible, are implemented. The ones that cannot be addressed will remain as residual risks. • Finally an evaluation report is produced which constitutes the Risk Profile, Deviations, a qualification statement, a validation statement and a recommendation. This information is utilized by Change Management for taking authorization decisions.

3.125 Roles

We will now discuss the roles and responsibilities pertaining to Change Evaluation process. • Change Evaluation Process Owner The responsibilities of the this process owner are : • Generic process owner responsibilities; and • Working with other process owners to ensure that there is an integrated approach to the design and implementation of change management, change evaluation, release and deployment management, and service validation and testing. • Change Evaluation Process Manager The responsibilities are : • Generic process manager responsibilities; • Planning and coordinating all resources needed to evaluate changes; and • Ensuring that change evaluation delivers evaluation reports and interim evaluation reports in time to ensure that change authorities are able to use them to support their decision-making. • Change Evaluation Process Practitioner The responsibilities are : • Using the service design and the release package to develop an evaluation plan as input to service validation and testing; • Establishing risks and issues associated with all aspects of the service transition, e.g. through risk workshops; and • Creating an evaluation report as input to change management. Let us now understand the triggers, inputs, outputs and interfaces of change evaluation in the next slide.

3.126 Triggers, Inputs, Outputs and Interfaces

The Trigger can be: • Request for evaluation from Change Management. Let us know look at the Inputs: • SDP, including service charter and SAC • Change proposal • RFC, change record and detailed change documentation • Discussions with stakeholders • Test results and report. Similarly the Outputs include: • Interim evaluation report(s) for change management • Evaluation report for change management. Lastly, the Interfaces of change evaluation with other process lifecycle stages include: • Transition Planning and Control • Change Management • Service Design Coordination • Service Level Management & Business Relationship Management • Service Validation and Testing. In the next slide we will understand the CSFs and KPIs of change evaluation process.

3.127 CSFs and KPIs

One of the best ways for achieving process objectives is to identify and establish the critical success factors and key performance indicators. The following are some sample critical success factors and key performance indicators pertaining to Change Evaluation Process. • One vital critical success factor is that ‘Stakeholders have a good understanding of the expected performance of new and changed services’. This ensures proper evaluation, testing and subsequent delivery of the service. The related key performance indicators are : ‘Reduced number of incidents for new or changed services due to failure to deliver expected utility or warranty’ and ‘Increased stakeholder satisfaction with new or changed services as measured in customer surveys’. • Another important critical success factor is that ‘Change management has good quality evaluations to help them make correct decisions’. The relevant key performance indicators for this critical success factor are : ‘Increased percentage of evaluations delivered by agreed times’; ‘Reduced number of changes that have to be backed out due to unexpected errors or failures’; and ‘Reduced number of failed changes’. Let’s now move on to understand the challenges and risks of this process.

3.128 Challenges and Risks

There are various types of challenges and risks associated with processes and service management activities. Identifying them at the initial stages of the service lifecycle and reviewing and taking appropriate actions regularly is the key for efficient service management. The challenges related to Change Evaluation process are : • Developing standard performance measures and measurement methods across projects and suppliers; • Understanding the different stakeholder perspectives that underpin effective risk management for the Change Evaluation activities; • Understanding and being able to assess, the balance between managing risk and taking risks; • Measuring and demonstrating less variation in predictions during and after transition; • Taking a pragmatic and measured approach to risk; • Communicating the organization’s attitude to risk and approach to risk management effectively during risk evaluation; • Building a thorough understanding of risks that have impacted or may impact successful transitioning of services and releases; and • Encouraging a risk management culture. Risks associated with Change Evaluation process are: • Lack of clear criteria for when change evaluation should be used; • Unrealistic expectations of the time required for change evaluation; • Change evaluation personnel with insufficient experience or organizational authority to be able to influence change authorities; and • Projects and suppliers estimating delivery dates inaccurately and causing delays in scheduling Change Evaluation activities. In the next few slides we will learn about next activity which is Knowledge management.

3.129 Knowledge Management

The saying ‘Knowledge is Power’ is highly relevant to IT service management as well. During the service lifecycle a lot of data, information and knowledge are generated and accumulated. The Knowledge Management process ensures systematic gathering, categorizing and storing of data, information and knowledge. This results in extraordinary benefits to the organization, service provider and the business. We shall now discuss this process in more depth to get a complete understanding of various concepts and activities involved.

3.130 Purpose And Objectives

The purpose of Knowledge Management process is : • To share perspectives, ideas, experience and information; • To ensure that these are available in the right place at the right time to enable informed decisions; and • To improve efficiency by reducing the need to rediscover knowledge. The objectives of Knowledge Management are to: • Improve the quality of management decision-making by ensuring that reliable and secure knowledge, information and data is available throughout the service lifecycle; • Enable the service provider to be more efficient and improve quality of service, increase satisfaction and reduce the cost of service by reducing the need to rediscover knowledge; • Ensure that staff have a clear and common understanding of the value that their services provide to customers and the ways in which benefits are realized from and the use of these services; • Maintain a service knowledge management system that provides controlled access to knowledge, information and data that is appropriate for each category of audience; and • Gather, analyse, store, share, use and maintain knowledge, information and data throughout the service provider organization. Let’s now proceed to understand the scope of knowledge management in the next slide.

3.131 Scope

Knowledge Management is one process that can virtually cross boundaries and benefit the complete organization if properly implemented. However our discussion on the scope of knowledge management will be limited to IT service management. • Knowledge Management is relevant to all lifecycle stages; • The scope includes oversight of the management of knowledge, information and data from which the knowledge is derived; and • Excludes detailed attention to the capturing, maintenance and use of configuration data which will fall within the scope of Service Asset and Configuration Management.

3.132 Value to Business

As stated earlier, Knowledge Management can be of immense value to the organization, service provider and the business. We shall now look at the benefits derived by the Business by adopting Knowledge Management. Successful and efficient management of data, information and knowledge will result in : • Conformance with legal and other requirements; • Documented requirements for retention of each category of data, information and knowledge; • Defined forms of data, knowledge and information in a fashion that is easily usable by the organization; • Data, information and knowledge that is current, complete and valid; • Data, information and knowledge to the right people at the right time; and • Disposal of data, information and knowledge as required. Moving on, let’s understand the policies and principles.

3.133 Policies and Principles (1 of 3)

Policies build efficiency into processes. The type of policies and their applicability mostly depend on the organization culture. With respect to Knowledge Management the generic policies are : • Knowledge and information needed to support the services will be stored in a way that allows them to be accessed by all staff when and where they are needed. This policy ensures availability of right information to the right people at the right time. • All policies, plans and processes must be reviewed at least once per year. This helps in ensuring that documents in Service Knowledge Management System are current, relevant and accurate. • All knowledge and information should be created, reviewed, approved, maintained, controlled and disposed of following a formal documented process. This policy ensures a process oriented approach to knowledge management. Let’s continue to understand these policies with couple of diagrams in the coming slides.

3.134 Policies and Principles (2 of 3)

In continuation to the last slide let us learn more about the Policies and principles of Knowledge Management process. Knowledge Management is typically displayed within the Data-to-Information-to- Knowledge-to-Wisdom (DIKW) structure, the figure on the slide represents this structure. The use of these terms is set out here. Data is a set of discrete facts about events. Most organizations capture significant amounts of Data in highly structured databases such as Service Management and Configuration Management tools or systems and databases. The key Knowledge Management activities around Data are the ability to: • Capture accurate Data • Analyze, synthesize, and then transform the Data into information • Identify relevant Data and concentrate resources on its capture. Information comes from providing context to Data. Information is typically stored in semi-structured content such as documents, e-mail, and multimedia. The key Knowledge Management activity around information is managing the content in a way that makes it easy to capture, query, find, re-use and learn from experiences so that mistakes are not repeated and work is not duplicated. Knowledge is composed of implied experiences, ideas, insights, values and judgments of individuals. People gain knowledge both from their own and from their peers, expertise, as well as from the analysis of information (and Data). Through the blend of these elements, new knowledge is created. Knowledge is dynamic and context based. Knowledge puts information into an ‘ease of use’ form, which can facilitate decision making. In Service Transition this knowledge is not solely based on the transition in progress, but is gathered from KMS: which is a set of tools and databases that is used to manage knowledge, information and Data. The Service Knowledge Management System includes the Configuration Management System, as well as other databases and information systems. The Service Knowledge Management System includes tools for collecting, storing, managing, updating, analyzing and presenting all the knowledge, information and Data that an IT service provider will need to manage the full lifecycle of IT services. Indirect measurements experience of previous transitions, awareness of recent and anticipated changes and other areas that experienced staff will have been unconsciously collecting for some time. Wisdom gives the ultimate discernment of the material and having the application and contextual awareness to provide a strong common sense judgment. Let us now move to the next policy.

3.135 Policies and Principles (3 of 3)

Specifically within IT Service Management, Knowledge Management will be focused within the Service Knowledge Management System (SKMS) concerned, as its name implies, with knowledge. Underpinning this knowledge will be a considerable quantity of Data, which will be held in a central logical repository or Configuration Management System (CMS) and Configuration Management Database (CMDB) (refer to the figure on the slide). However, clearly the SKMS is a broader concept that covers a much wider base of knowledge, for example: • The experience of staff • Records of peripheral matters, e.g. weather, user numbers and behavior, organization’s performance figures • Suppliers’ and partners’ requirements, abilities and expectations • Typical and anticipated user skill levels. Moving ahead, let us look into the the key concepts of Knowledge Management process in the next slide.

3.136 Key Concepts: SKMS Contents

In our last few slides we learned about the Policies and principles of Knowledge Management process. This slide talks about Key Concepts of knowledge management. SKMS contents at each layer are shown in the picture here. Data layer consists of all the Data in the enterprise, such as CMDB, incident records, problem records etc Information layer extracts the relevant information from the Data layer. From the information layer knowledge is acquired by the knowledge processing layer. SKMS will gather the appropriate experience from the presentation knowledge layer. In the next slide we will look at the activities, methods and techniques of this process.

3.137 Process Activities

This slide gives you the list of activities, methods and techniques for knowledge management process. They are: • Knowledge management strategy • Knowledge transfer • Data and information management • Using the Service Knowledge Management System We will learn each activity in detail in next few slides.

3.138 Knowledge Management Strategy

In our last slide we were introduced to the Activities, Methods, and Techniques of Knowledge Management process. This slide talks about the first activity of Knowledge Management i.e (pronounced as that is)Knowledge Management strategy. Knowledge management strategy is the first activity. An overall strategy for Knowledge Management is required. Where there is an organizational approach to Knowledge Management, initiatives within Service Transition, IT Service Management or other groupings should be designed to fit within the overall organizational approach. In the absence of an organizational Knowledge Management approach, appropriate steps to establish Knowledge Management within Service Transition or within IT Service Management will be required. But even in this case developments should always be established with a view to widen practicable span of Knowledge Management – covering direct IT staff, users, third party support and others likely to contribute or make beneficial use of the knowledge. The strategy – either in place in the wider organization or being developed – will address: • The governance model • Organizational changes underway and planned and consequential changes in roles and responsibilities • Establishing roles and responsibilities and ongoing funding • Policies, processes, procedures and methods for Knowledge Management • Technology and other resource requirements In the next slide we will discuss about knowledge transfer, the second activity.

3.139 Knowledge Transfer

Let us now understand the activity Knowledge transfer: Traditionally knowledge transfer has been based on formal classroom training and documentation. In many cases the initial training is provided to a representative from a work group who is then required to cascade the knowledge to their working colleagues. Other techniques are often appropriate and form useful tools in the Service Transition armory. Techniques worth considering include the following. • Different people learn in different ways, and the best method of transferring and maintaining knowledge within the Service Management and user community will need to be established. Learning styles vary with age, culture, attitude and personality. • Knowledge Visualization aims to improve the transfer of knowledge by using computer and non- computer-based visuals such as diagrams, images, photographs and storyboards. It focuses on the transfer of knowledge between people and aims to transfer insights, experiences, attitudes, values, expectations, perspectives, opinions and predictions by using various complementary visualizations. • Knowledge transfer aims to ensure that staffs are able to decide on the correct actions to deliver their tasks in any foreseeable circumstances. For predictable and consistent tasks, the procedure can be incorporated within software tools that the staff uses within those tasks. • Formally launching a new or changed service can create an ‘event’ that enhances the transfer of knowledge. Technology-based events such as Webinars offer the ability to deliver a high profile knowledge delivery mechanism with the ability to retain it online and deliver it subsequently to other locations and new staff. Internet and intranet portals can deliver equivalent messages in an ongoing fashion and allow discussion forums to question and develop knowledge. • Regular communicating channels, once established, are useful in allowing knowledge to be transferred in smaller units – incrementally rather than ‘big bang’ can be easier to absorb and retain. They also allow for progressive training and adaptation to circumstance and time periods. Crucially these techniques can be made entertaining and targeted at specific groupings. Moving ahead, let us learn about Data and information management of Knowledge management process.?

3.140 Managing Data, Information and Knowledge

Data and information management refers where Knowledge rests on the management of the information and Data that underpins it. To be efficient this process requires an understanding of some key activities shown here: First is Establishing Data and information requirements. The activities should be planned and implemented in accordance with applicable organization policies and procedures with respect to the Data and information management process. Efficiency and effectiveness are delivered by establishing the requirements for information. Sensible considerations, within the constraints determined as described above, might include: Establishing the designated Data and information items, their content and form, together with the reason, Encouraging the use of common and uniform content and format, Establishing the requirements for Data protection, privacy, security, ownership, agreement restrictions, rights of access, intellectual property and patents with the relevant stakeholder, defining the consistency and access levels. Second is to Define the information architecture. In order to make effective use of Data, in terms of delivering the required knowledge, a relevant architecture matched to the organizational situation and the knowledge requirements is essential. This in turn rests on: • Creating and regularly updating a Service Management information model that enables the creation, use and sharing of information that is flexible, timely and cost-effective • Defining systems that optimize the use of the information while maintaining Data and information integrity • Adopting Data classification schemes that are in use across the organization, and if necessary negotiating changes to enable them to deliver within the Service Management area Third is to Establish Data and information management procedures. When the requirements and architecture have been set up, Data and information management to support Knowledge Management can be established. The key steps required involve setting up mechanisms to: • Identify the service lifecycle Data and information to be collected • Define the procedure required to maintain the Data and information and make it available to those requiring it • Store and retrieve the data Fourth step is Evaluation and improvement. As with all processes, the capture and usage of Data and information to support Knowledge Management and decision making requires attention to ongoing improvement, and the service improvement plan will take as relevant input the following: • Measurement of the use made of the Data and information management through Data transactions • Evaluation of the usefulness of the Data and information, identified by relevance of reports produced • Identification of any Data or information or registered users that no longer seem relevant to the organization’s knowledge requirements. So far, we have discussed about knowledge management stratergy, transfer and data information management. In the next slide we will discuss about SKMS.

3.141 Using the SKMS

This slide highlights the details on using the Service Knowledge Management System (SKMS). Providing services to Customers across time zones, work cycles, and geographies requires good knowledge sharing across all locations and time periods of Service Operations. A service provider must first establish a Service Knowledge Management System that can be shared, updated and used by its operating entities, partners, and Customers. Implementation of a Service Knowledge Management System helps reduce the costs of maintaining and managing the services, both by increasing the efficiency of operational management procedures and by reducing the risks that arise from the lack of proper mechanisms. All training and knowledge material needs to be aligned to the Business perspective. Materials that can be included are: • The Business language and terminology and how IT terminology is translated • The Business processes and where IT underpins them • Any SLAs, and supporting agreements and contracts that would change as a result of the new Service Transition – this is especially important for the service desk analysts whose target at support transition will be to sustain service; if classifications are accurate this will facilitate the whole process. Let us now move to next slide to discuss further on this.

3.142 Using the SKMS

In continuation to our last slide about using the Service Knowledge Management System, this slide further explains the concept. For those in the Service Transition process a good way of consolidating or understanding is to either spend time in the development areas, taking part in some of the testing processes, or to spend time in the Business at the receiving end of the Service Transition to understand the process from the Business perspective. There are various Useful activities such as: • Involvement Development, Requirement mapping or Testing • Log analysis • Vendor programs/ seminars Similarly, Various Useful materials will include: • The Process maps to understand all the integrated activities • Any known error logs and the workarounds – again particularly important for the service desk • Updated Business and other public calendars. This summarizes the activities, methods and techniques. In the next slide we will look at the inputs, outs and KPIs of Knowledge Management process.

3.143 Roles

Let us now look at the roles and responsibilities related to Knowledge Management process. • Knowledge Management Process Owner The responsibilities are : • Generic process owner responsibilities; and • Creating overall architecture for identification, capture and maintenance of knowledge within the organization. • Knowledge Management Process Manager The responsibilities of this process manager are : • Generic process manager responsibilities; • Ensuring that all knowledge items are made accessible to those who need them in an efficient and effective manner; • Planning and managing support for knowledge management tools and processes; • Encouraging people throughout the service provider to contribute knowledge to the service knowledge management system; and • Acting as an adviser to business and IT personnel on knowledge management matters, including policy decisions on storage, value, worth etc. • Knowledge Management Process Practitioner The responsibilities are : • Identifying, controlling and storing any information deemed to be pertinent to the services provided that is not available by other means; • Maintaining controlled knowledge items to ensure that they are current, relevant and valid; and • Monitoring publicity regarding the knowledge information to ensure that information is not duplicated and is recognized as a central source of information etc.

3.144 Triggers, Inputs and Outputs

We shall now try to understand the triggers, inputs and outputs of Knowledge Management. Within service management there are innumerable activities that can trigger the knowledge management process. This is a process that spans across lifecycle and hence every activity can result in an interaction with it. A few examples of the relevant triggers are mentioned here. • Business relationship management storing the minutes of a customer meeting; • Updates to the service catalogue or service portfolio; • Modification of a service design package; • Creation of a new or updated capacity plan; • Receipt of an updated user manual from a supplier; • Creation of a customer report; and • Updates to the Continual Service Improvement register. The inputs to this process are: • All knowledge, information and data used by the service provider; and • Relevant business data. The Knowledge Management process outputs are: • Knowledge required to make decisions and to manage the IT services; • Errors detected during transition along with their workarounds; • Information captured by service operation staff, especially incident and problem management staff; and • Information captured by service transition staff. In the next slide we will understand the interfaces of knowledge management.

3.145 Interfaces

The process Interfaces are shown here: • Service Operations: Errors within the service detected during transition will be recorded and analyzed and the knowledge about their existence, consequences and workarounds will be made available to Service Operations • Operations staff: Front-line incident management staffs, on service desk and second-line support, are the point of capture for much of the everyday IT Service Management Data. • Problem management staff will be key users of collected knowledge and typically responsible for the normalization of Data capture by means of developing and maintaining scripts supporting Data capture within incident management. • Transition staff: Service Transition staff captures Data of relevance through all lifecycle phases • CSI and Service Design: Service Transition staffs capture Data and information: Relevant to adaptability and accessibility of the service as designed, to be fed back, via CSI to Service Design ‘Course corrections’

3.146 CSFs and KPIs

Critical success factors and key performance indicators are typical service management components that ensure identifying, monitoring and measuring the most important aspects of a service. The Knowledge Management related critical success factors and key performance indicators are discussed here. • The most important critical success factor for this process is ‘Availability of knowledge and information that helps to support management decision-making’. • The related key performance indicators are : ‘Increased number of accesses to the Service Knowledge Management System by managers’; and ‘Increased percentage of Service Knowledge Management System searches by managers that receive a rating of good’. • Another critical success factor we can think of is ‘Reduced time and effort required to support and maintain services’. • The related key performance indicators are : ‘Increased number of accesses to the SKMS by service operation teams’; ‘Increased percentage of incidents solved by use of known error database’; and ‘Increased results in knowledge management satisfaction survey of service operation teams’. • The next one is ‘Successful implementation and early life operation of new and changed services with few knowledge-related errors’. • And the related key performance indicators are : ‘Reduced number of incidents and problems categorized as ‘knowledge-related’’; and ‘Increased percentage of successful service transitions’. • ‘Reduced dependency on personnel for knowledge’ is also a very important critical success factor. • The relevant key performance indicators are : ‘Increased number of times that the SKMS is accessed’; ‘Increased percentage of SKMS searches that receive a rating of ‘good’ by the user’ ; and ‘Increased scores in regular customer satisfaction surveys for knowledge management’. Let’s understand the challenges and risks of knowledge management in the next slide.

3.147 Challenges and Risks

Implementing Knowledge Management and continuous management of this process is a very difficult task. It requires a high level of senior management support, acceptance and adherence by majority of the staff and dedicated teams to manage it. The key challenges faced by the Knowledge Management are : • Justifying the effort that would be needed to create a consistent architecture for managing data, information and knowledge; • Each group or team within the service provider may own and manage information that they use and may see Knowledge Management as an overhead and interference in their work; • To make all the stakeholders understand the added value that a more holistic approach to knowledge management can bring; and • To continue to demonstrate the value of Service Knowledge Management System. The risks associated with implementing and sustaining Knowledge Management are : • Focusing on the supporting tools, rather than on the creation of value; • Insufficient understanding of what knowledge, information and data are needed by the organization; • Lack of investment in the tools and people needed to support the Service Knowledge Management System; • Spending too much effort on knowledge capture with insufficient attention to knowledge transfer and re-use; • Storing and sharing knowledge and information that are not up to date and relevant; and • Lack of support and commitment from stakeholders. With this we have come to the end of learning unit 3, let us quickly recap in the next slide.

3.148 Learning Unit 3 Summary

To summarize on the topics covered so far, we learnt that: • The Transition Planning & Support process is responsible for providing overall planning for service transitions and to coordinate the resources that they require. • Change Management ensures controlling the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services. • Service Asset & Configuration Management ensures that the assets required to deliver services are properly controlled, and that accurate and reliable information about those assets is available when and where it is needed. • Release & Deployment Management takes care of planning, scheduling and controlling the build, test and deployment of releases, and to deliver new functionality required by the business while protecting the integrity of existing services. • Service Validation & Testing ensures that new or changed IT services match the design specifications and also meet the needs of the business. • Change Evaluation tries to provide a consistent and standardized means of determining the performance of a service change in the context of likely impacts on business outcomes, and on existing and proposed services and IT infrastructure. • Knowledge Management ensures improving efficiency of Service Management by reducing the need to rediscover knowledge and making available the right information to right people at the right time to enable informed decision making Next is the quiz section, attempt all the questions before moving to the next unit on Managing people through service transition.

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

We use cookies on this site for functional and analytical purposes. By using the site, you agree to be cookied and to our Terms of Use. Find out more

Request more information

For individuals
For business
Name*
Email*
Phone Number*
Your Message (Optional)

By proceeding, you agree to our Terms of Use and Privacy Policy

We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Email*
Phone Number*
Company*
Job Title*

By proceeding, you agree to our Terms of Use and Privacy Policy