Index:

ITIL® v3 Foundation 2011 Study Notes

1. ITIL v3 Foundation Certification Notes: Service Management as a Practice
2. ITIL v3 Foundation Certification Notes: Service Strategy
3. ITIL v3 Foundation Certification Notes: Service Strategy [2]
4. ITIL v3 Foundation Certification Notes: Service Design
5. ITIL v3 Foundation Certification Notes: Service Design [2]
6. ITIL v3 Foundation Certification Notes: Service Design [3]
7. ITIL v3 Foundation Certification Notes: Service Design [4]
8. ITIL v3 Foundation Certification Notes: Service Transition
9. ITIL v3 Foundation Certification Notes: Service Transition [2]
10. ITIL v3 Foundation Certification Notes: Service Operation and Functions
11. ITIL v3 Foundation Certification Notes: Service Operation [2]
12. ITIL v3 Foundation Certification Notes: Service Operation [3]
13. ITIL v3 Foundation Certification Notes: Continual Service Improvement
14. ITIL v3 Foundation Certification Notes: Last Minutes Revision Notes

ITIL v3 Foundation Certification Notes: Service Management as a Practice
Why IT Service Management is needed? * Higher IT service quality is always required while fewer resources are available * Users are not interested in the processes / technology, rather they just need to utilize the service to achieve business goals * As users are usually not directly responsible for the costs of IT services, they would endlessly request more and more IT services with higher and higher standards / quality * Changes to business and technology happen continually that would affect IT systems and processes * Nowadays, IT services are increasingly provided as business services to the external customers (e.g. in the past, bank customers would need to go to a local bank to request a transaction with the bank teller who would make use of the IT system to retrieve the account and record the transaction; nowadays, customers would directly make transaction online or in ATMs where the IT services are directly used by the customers) * The need to balance IT services request and quality with available resources to deliver the maximum value to the business -> IT service management

What is IT Service Management?
IT Service * A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks * e.g. Email service: business users just make use of email service for communication needs, the management, cost and risks (e.g. security, hardware, virus, etc.) are not their concerns * outcome is the result of carrying out an activity, including intended and actual results * two types of customers: internal (within the same organization) and external (outside the organization) * external services provide a more direct and visible contribution to the business outcome than internal services * [definition] IT Service – A service provided by an IT service provider. An IT service is made up of a combination of information technology, people and processes. A customer-facing IT servicedirectly supports the business processes of one or more customers and its service level targets should be defined in a service level agreement. Other IT services, called supporting services, are not directly used by the business but are required by the service provider to deliver customer-facing services. * IT Services consist of taking care the design, implementation and maintenance of all the components that are required to fulfil a business objective for the users (i.e. IT and business integration, not just IT and business alignment) * Values of IT services * Create values for the business by supporting business processes * Create values for end customers * Reduce costs / increase productivity (enhance performance) * Manage costs / risks / issues more effectively * Reduce / remove constraints (e.g. not enough bandwidth) * Facilitate achievement of outcomes (e.g. students registering for a class) * Customer Satisfaction is at the core of judgment of the quality of the services. Service costs (total cost of ownership (TOC), return on investment (ROI) or overall cost) will be a major factor to be considered by the customers. * Types of services – according to the value for customers * Core Services: required directly by customers to deliver an intended outcome * Enabling Services: needed to ensure core services can be delivered successfully, not visible to customers * Enhancing Services: created to add features / values to the customers, not essential * Types of IT services – according to the customer types * Supporting Services (infrastructure services): not directly visible to customers, managed with operation level agreements * Internal Customer facing Services: enable internal customers to carry out its business process, managed with service level agreements * External Customer facing Services: used by the external customers, can be the business process itself, managed with contracts * A service package is a collection of two or more [generic] services that have been combined to offer a solution to a specific type of customer need or to underpin specific business outcomes. A service package may consist of any types of services. The generic services used in this way can achieve economy of scale. * In case if there is a need for giving options on warranty and/or utility for components of a service package, different service level packages can be offered as service options.

Stakeholders * Stakeholders are individuals or groups that have an interest in an organization, service, or project and are potentially interested or engaged in the activities, resources, targets, or deliverables from service management. * Internal stakeholders: within the service provider organization * External stakeholders: outside customers, users, suppliers (vendors, network providers) * [definition] Service providers are organizations supplying services to one or more internal or external customers.

IT Service Management * Service Management is a set of specialized organizational capabilities for providing value to customers in the form of services. * Capabilities: functions and processes for managing services over a lifecycle * Specialized: in strategy, design, transition, operation, and continual improvement * The capabilities represent a service organization’s capacity, competency, and confidence for action. The act of transforming resources into valuable services is at the core of service management. Without these capabilities, a service organization is merely a bundle of resources that by itself has relatively low intrinsic value for customers. * [definition] IT Service Management: The implementation and management of quality IT services that meet the needs of the business. IT service management is performed by IT service providers (to internal or external customers) through an appropriate mix of people, process and information technology. * Make use of best practices (a set of generic (high level) guidelines based on the successful experiences of a number of organizations) in service management, adapt and apply for the business to save cost and improve quality * [definition] Good practice could be either an application of best practice, or an input into best practice * Types of IT Service Providers * Type I: Internal Service Provider – service providers located within the business unit, maybe several internal service providers within an organization * Type II: Shared Services Unit – supports several business units, e.g. centralized IT department * Type III: External Service Provider – delivers services to external customers * Suppliers vs Providers * suppliers only provide an element of the service which is not visible to the customer

Process * A process is a set of activities designed to turn input(s) into output(s) to accomplish a specific objective (need to be measurable, expressing in terms business benefits for business goals), often including feedback (report, measurements (metrics)) from the output to be used for process improvements * Processes may include roles, responsibilities, tools and management controls (actions, dependencies, and sequence) and are supported by the enablers (resources and capabilities). * The process is considered effective if all the objectives of the output are met. * Each process is owned by a process owner responsible for the process and improvement, ensuring the process meets the defined objectives * Once defined, processes need to be documented and controlled (repeatable and manageable) * Process Characteristics: * Measurable (performance based e.g. cost, quality, productivity, duration) * Deliver specific identifiable and countable results * Meet the expectations of the customers / stakeholders * Respond to specific events (called triggers)

Business Process, IT Process and IT Service * IT teams provide the service to enable the business process to be automated. * IT team will need to take reference to the ITIL® best practice of IT processes to deal with a particular business process * Benefits of Process Automation with IT Service: Capacity Management – Improve quality, i.e. can respond to variation in demand, less time restrictions * Optimization – handle complex tasks better * Measurement – for improvement as human factor is ruled out * Reduce costs (users can self-serve) and risks (human errors) * Knowledge Capture – reduce variations as the process is well studied and documented * The tasks should be well studied and only “simple” and routine tasks with recognizable patterns can be automated * Areas of service management ideal for automation: * design and modelling (for project and forecasting) * service catalog (capture demand for services) * pattern recognition and analysis * classification, prioritizing and routing * detection and monitoring * routine service requests
Functions and Roles * Function: A team or group of people and the tools they use (resources) to carry out one or more processes or activities * Functions are self-contained units responsible to carry out the tasks to create specific outcomes * provide structure and stability to the organization * have their own body of knowledge accumulated through experience * e.g. technical management, application management, operations management functions, service desk * [definition] Role: A set of responsibilities, activities and authorities granted to a person or team * triggers to play the role are determined by processes (by the line-manager) * one person/team can take up several roles in different context * e.g. change management role, capacity management role * Defined roles in ITIL®: * Group – a number of people performing similar activities, not formal structure * Team – a more formal structure for people working together with a common objective * Department – a formal organizational structure with a hierarchical structure * Division – a number of departments forming a self-contained unit *
Why Information Technology Infrastructure Library (ITIL®)?
ITIL® is recognized as a world-wide best-practice approach for delivering IT services and IT service management by focusing on the processes, functions, and capabilities required to support IT services in businesses. It helps organizations to gain competitive advantage by ensuring they are utilizing the best-practice approaches to IT available – helping IT services to meet the needs of the customers within the budget in an cost-effective way. There are different sources of the best practices: proprietary knowledge / internal experience, standards / industry practice and training and education / academic research.
ITIL® is considered one of the standards containing the body of knowledge in best practice and is being adapted by organizations worldwide to establish and improve capabilities in service management. * It works – as ITIL® embraces a practical approach with a common framework * Vendor-neutral – not tied to any technology, platform or industry, owned by the UK Government * Non-prescriptive – designed for all types of organizations, advocates “adopt and adapt”, doesn’t specify how the best practices are to be structured or carried out * Best practice – accumulated through experiences by service providers worldwide
ITIL® enables organizations to deliver benefits, values and return on investment on a sustainable approach. It allows a cultural shift by the adoption of standard approach to service management across the entire organization.
ITIL® standardizes the strategic approach to the management of services, the performing organizations just need to make minor adjustments to meet their business needs. This is the core of ITIL®’s approach to service management.

The ITIL® Service Lifecycle * ITIL® consists of the following components: * The ITIL® Core: a set of five publications containing the best practice guidance applicable to all organizations providing services * The ITIL® Complementary Guidance: a auxiliary set of publications (online or printed) detailing the application of ITIL® to specific industries, organization and technology platform * Organizations practicing ITIL® may get certified under ISO/IEC 20000

1. Service Strategy * Guidance for organizations on * how to think and act in a strategic manner * how to turn service management into strategic assets for strategic growth by understanding the cost and value of the services * how to clarify relationships between various services, systems, or processes and the business models, strategies, or objectives
2. Service Design * Guidance for organizations on * how to design and develop services / service management processes * how to convert strategic objectives into portfolios of services and service assets * applicable for existing services requiring changes / improvements * integrate people, process, products and partners

3. Service Transition * Guidance for organizations on * how to build and test the services * how to transit new / improved services into operation (live environment) * how to effectively realize the Service Strategy as planned in Service Design in Service Operation and control risks * how to manage changes of services / service management * combine release management, program management and risk management in the context of service management * from testing to live; from one organization to another

4. Service Operation * Guidance for organizations on * how to coordinate daily operation and deploy the services to operation * how to deliver value with quality, efficiency and effectiveness by service operation and support * how to maintain stability while allowing for changes * how to exercise reactive and proactive control * How to support operation through new models and architectures (e.g. web services, mobile e-commerce, cloud computing, etc.) * Execute the plans and measure the results * A critical capability as strategic objectives are realized in operation

5. Continual Service Improvement * Guidance for organizations on * measurement, reporting and improvement on services, processes and technology for every stage in the lifecycle * how to continually monitor, maintain and create value to users through better design, transition and operation * how to link improvement efforts and outcomes with service strategy, design, and transition through the closed-loop PDCA (plan, do, check, act) model * how to continually align to changing business needs * Combine quality management, change management and capability improvement

Conclusion: ITIL® v3 Foundation Concepts
This ITIL® v3 Foundation study note provides an overview of the components of the ITIL® framework and the ITIL® lifecycle (Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement) and definitions of terms like IT Service, IT Service Management, Process, Function and Role. he Service Strategy lifecycle stage is often considered as the core of the service lifecycle. In Service Strategy stage, the strategic approach for the whole lifecycle is identified to provide values to the customers through IT service management. Below are the important concepts and facts for the ITIL® v3 Foundation Certification.
ITIL v3 Foundation Certification Notes: Service Strategy
Purpose and Scope of Service Strategy * The purpose of Service Strategy is to define the strategic approach for service management across the whole lifecycle through understanding the business objectives and needs * Scope of ITIL®’s guide on Service Strategy covers: * defining a strategy with guidance and recommendations for the service provider to deliver services to meet business outcomes * defining a strategy for managing these services

Objectives of Service Strategy * Objectives of Service Strategy: * provide an understanding of what strategy is * identify the services, their users and the level of demand * understand the organizational capability and funding requirements, and coordinate and document the use and optimization of service assets * understand the definition of value according to the customers * provide the means to identify opportunities to provide the best services * deliver a “service provision model”, including the funding, delivery and the purposes of the services * define the processes and services that will deliver the strategic plans

Why Service Strategy is Important? * Allow the organization to understand the values of the IT services to the business outcome * Consistently provide valuable services to the customers / users by understanding the intrinsic values * Can respond to business change and give competitive capability to the organization * Know how to prioritize the services requests to bring about maximum ROI * Deliver services that are seen by the customers to be valuable (delivering business outcome and achieving business objectives)

Key Concepts and Definition - Value Consideration * Value is defined by customers based on how far the objectives can be matched, the value will change over time * the customers will determine the mix of features according to their budget * IT service values are usually intangible * business outcomes, preferences and perceptions of the customers are used to evaluate the services * if generated value (what the services achieved) > cost input (what the service cost), the service IT provided is perceived to be valuable

Utility and Warranty * Utility is the functionality offered by a product or a service to meet a specific customer need / required outcome (what the service does / fit for purpose) * Warranty provides the assurance that a product or service will meet the agreed requirements (e.g. service level agreement or contract), be reliable in terms of both security and continuity (how the service is delivered / fit for use)

Assets, Resources and Capability * Asset is any resource or capability * Customer asset: asset used by a customer to achieve a business outcome * Service asset: asset used by a service provider to deliver services to a customer * Resources are the direct inputs for the production of services e.g. money, infrastructure items, applications, information, people (capital expenditure as a physical asset). * Capabilities are the assets that represent the organization’s ability / knowledge to do something to achieve value, e.g. management, organization, processes, ability to coordinate, control, people’s experience and skills. * Capabilities require resources to deliver value.

Governance * Governance ensures that policies and strategy are actually implemented, and that required processes are correctly followed. Governance includes defining roles and responsibilities, measuring and reporting, and taking actions to resolve any issues identified. * Where IT and business meet -> operate together according to direction and policies to achieve objectives * Governance Structure: Corporate Governance > Corporate Compliance > IT Governance > IT Compliance > IT Service Management * Corporate governance is about promoting corporate fairness, transparency and accountability * IT governance is the responsibility of the board of directors and executive management. It is an integral part of enterprise governance and consists of the leadership, organizational structures and processes that ensure that the organization’s IT sustains and extends the organization’s strategies and objectives * Compliance ensures that a standard or set of guidelines is followed, or that proper, consistent accounting or other practices are being employed * Service management must include corporate governance standards and policies * Corporate governance provides the control for the Service Strategy * ISO / IEC 38500 is the international standard for corporate government in IT * The strategic policy also plays a significant role in continual service improvement (CSI)

Risk Management in Service Management * only covers the basic risk management approach * must be complementary to the corporate approach to corporate risk management * steps in risk management (a repetitive activity) * identifying risks – document all potential risks in risk register, to be managed through continual service improvement lifecycle stage * analysis of risks – quantitative and qualitative analysis * managing risks – action plans should be tailored for all the risks in the risk register

Patterns of Business Activity * Pattern of Business Activity (PBA), i.e. activities that are repeated within the organization with a pattern (e.g. daily server load, weekly utilization of space or annual pattern of peak seasons), needs to be identified and documented in the form: * Classification: type of PBA and its origins, type and impact of outcomes, the workload * Attributes: frequency, volume, location and duration * Requirements: performance, security, privacy, tolerance for delays, warranty * Service Asset Requirements: the demand for resource and capability

Conclusion: ITIL® v3 Foundation Service Strategy
This ITIL® v3 Foundation study note deals with more in-depth description and concepts of the Service Strategy, the first stage in the ITIL® Service Management Lifecycle. In particular, terms like utility, warranty and value creation, assets, resources and capability, governance, risk management, patterns of business activity (PBA) are touched upon.
Important processes of the Service Strategy phase for the ITIL® v3 Foundation Certification exam are covered here, including: service portfolio management, financial management, business relationship management. The purpose, objectives, and scope of the processes and their importance in the Service Strategy lifecycle stage are addressed.
Service Portfolio Management Process * Purpose of SPM: ensure the appropriate mix of services to meet customer requirements, the information (e.g. investment, interaction with other services) in the service portfolio clearly define the services and link them to business outcome providing the capability for alignment across the whole lifecycle to deliver value * Objectives of SPM * a process to allow management of overall service provision – to review, control (how and when to provide the service), improve or retire a service * maintain the definitive portfolio of all services provided including the business needs and achieved outcomes * assist in judging the value of new service requests and review of investment * allows the organization to understand the value of IT services to business goals * Scope of SPM * all the services in current use, in planning or having been retired * track investment and expenditure on all services and determine whether they are delivering value throughout the whole lifecycle * Output of SPM: Service Portfolio * the complete set of services managed by a service provider (representing all the commitments and investments) * three sections: * pipeline section – pre-operational services, conceptual services (will be provided if resource is unlimited) * service catalogue section – customer-facing, live operational services * retired section – retired services * to ensure correct funding for all IT services across pipeline (development) and service catalogue (maintenance) sections

Financial Management for IT Services Process * Purpose: to secure enough funding for all the IT services (design, develop and deliver) and to control IT expenditures by balancing quality and cost, thus avoiding commitment to services that are not financially viable * Objectives * define the financial framework to manage cost, apply financial control, report expenditure and recover cost from customers (if applicable) * study the financial impact of new / changed organizational strategy * secure enough funding for IT services (need to align with the overall financial management of the organization) and provide financial forecasts in respond to needs and changes * work with service assets and configuration management process to ensure all assets are maintained and all costs recorded * Scope * ensure the financial practices within IT is consistent with organizational standards so that other business units will have an understanding of how IT is funded * three main processes with two cycles (planning / annual vs operational): * Budgeting – predicting and managing exceptions of income and expenditure * Accounting – establishing unit costs and recoding the expenditure with cost breakdown * Charging – establishing pricing policy and billing the customers (if any)

Business Relationship Management Process * Purpose of BRM: to establish relationship between the service provider and customers and to ensure customers satisfaction by responding to changing requirements and managing customer expectation * Objectives of BRM * understand customers’ needs and prioritize services accordingly to meet user requirements * maintain good communication * handle conflicts and complaints effectively * identify changes in business environment and technology that could impact services * ensure customer satisfaction * Scope of BRM * focus on high level perspective of whether the service meets business needs * seek to understand customer requirements and business objectives * keep track of changes in technology and environment and advise users on these * understand the use of services on offer * measure level of customer satisfaction and respond to complaints * work with other service management processes and functions for information gathering, etc. * BRM – strategic, to drive overall customer satisfaction vs Service Level Management – tactical, meeting agreed levels of service in operation

Business Case * A business case is the justification for a significant item of expenditure. The business case includes information about costs, benefits, options, issues, risks and possible problems. * A business case is a tool for decision planning and support for understanding the likely consequences of a business decision in quantitive or qualitative terms * Information can be captured from the Service Portfolio with sound financial management * Business cases are built in Business Relationship Management process and evaluated in Service Portfolio Management process * Structure of a business case 1. Introduction – business objectives 2. Methods and assumptions – define the boundaries (e.g. time, context) 3. Business impacts – financial and non-financial (image, satisfaction, etc.) consequences 4. Risk and contingencies 5. Recommendations * Business objectives and business impacts are closely linked and may have one-to-many / many-to-one relationship.

Conclusion: ITIL® v3 Foundation Service Strategy Processes
This ITIL® v3 Foundation study note mentions a number of Service Strategy processes: * Service Portfolio Management – provides information for the whole service lifecycle * Financial Management – manages costs and budgets for the whole service lifecycle * Business Relationship Management – provides high-level, strategic interface with customers

The Service Design lifecycle stage is an important area as the design is often accountable for the success or failure of the services. The Service Design stage begins with customer requests and ends in service design ready for the transition phase. Below are the important concepts and facts for the ITIL® v3 Foundation Certification.

Purpose, Objectives and Scope of Service Design * Service Design is involved in both planning new services and changing existing services to ensure service strategy are fulfilled. * A service needs to provide utility and warranty (level of service, including security, service continuity, capacity, etc.) in order to deliver value. Poor design means the service cannot deliver both utility and warranty. * Service Design requires planning (e.g. risk management) to be successful. * Good design aligns the outcome to business objectives with a lower total cost of ownership of the service and smooth service transition and operation. It also allows continual improvement of service by gathering useful metrics. The processes are also designed to be efficient and effective.

Purpose of Service Design * The purpose of Service Design is to deliver a new service / service amendment that can deliver the strategic outcome required the design of both the services and the service management processes need to be included. * Need to ensure the service will run within budget and meet/exceed customer requirements.

Objectives of Service Design * Deliver a service that would require little improvement later on by learning from lessons learned of previous projects.

Scope of Service Design * Consider not only the current requirements but also future needs (e.g. take advantage of technical advancements, can be easily adapted to future needs) * Describes how to identify requirements (functional and service level) and ensure the delivery of such requirements * Processes include: * Design coordination * Service catalog management * Service level management * Availability management * Capacity management * IT service continuity management * Information security management * Supplier management * Note: these processes may be involved in more than one phase in the lifecycle

Key Output of Service Design – Service Design Package * A service design package consists of one or more documents that describe all aspects of the service throughout its lifecycle, for use in transition (as requirements for testing) and operation of the service. * Documents of a service design package may include: * Original agreed business requirements for the service (but not the organizational business strategy) * How the service will be used * Key contacts and stakeholders * Functional requirements * Management requirements * Service level requirements * Technical design of the new or changed service including hardware, software, networks, environments, data, applications, technology, tools, and documentation * Sourcing strategy * New or changed processes required to support the service * Organizational readiness assessment – need for training and supplies * Service lifecycle plan, including the timescales and phasing, for the transition, operation, and subsequent improvement of the new service * Service program – an overall plan of the lifecycle of the service * Service transition plan * Service operational acceptance plan * Service acceptance criteria (SAC) * Another output is service solution

Service Composition
Services are composed of the following elements (utility, warranty, resources and capabilities): * the business processes involved * utility requirements as well as governance / reporting requirements * service level agreement / supporting requirements * technical components and how they are linked as well as environmental requirements * the applications to provide functional requirements as well as the data required * dependencies with other services * service management processes

Key Elements of Service Design * People * Processes * Products * Partners
People
* the availability and capability of the people using or supporting the service * training needs analysis and budgeting for training are to be considered
Processes
* new service may require additional processes (e.g. authorization / procurement services) * all processes should be documented with the interfaces in between * identify changes required to existing services
Products
* the service itself plus the technology and tools used in design or support
Partners
* specialist suppliers / vendors which are managed through supplier management process
Major Aspects of Service Design * Service solutions * Tools and systems for management information * Architectures * Measurement systems * Processes
Service Solutions * the functionality offered by the service itself * deliver the solution within the technical and financial constraints, and corporate rules * the approach must be structured but flexible enough to accommodate future changes
Tools and Systems for Management Information * these are used to support and automate processes (e..g quality management system, information security system) * ensure the service will integrate with existing management tools and systems
Architectures
* compatible with existing architectural platform and technical standards * [definition] Architecture is defined as the fundamental organization of a system, embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution.
Measurement Systems * collecting metrics to allow assessments for efficiency and effectiveness
Processes
* any services will require processes – existing or new * either change the processes to suit the service design or vice versa
Conclusion: ITIL® v3 Foundation Service Design
This ITIL® v3 Foundation study note discusses how Service Design fits in the service lifecycle, its purpose, objectives and scope as well as the output – service design package. Factors to be considered during service design are also mentioned including four key elements (people, products, processes, and partners) and five aspects (the solution itself, the processes and management information systems to support it, the architecture, and the metrics).
An important process of the Service Design phase for the ITIL® v3 Foundation Certification exam is covered here: service level management (SLM). The purpose, objectives, and scope of the processes and their importance in the Service Design lifecycle stage are addressed.
Service Level Management Process * Purpose of SLM: ensure that all current and planned IT services are delivered to agreed achievable targets (service level agreement) using an objective measurement through discussion and negotiation with customers * primarily concerned about the warranty aspects (security, capability, availability, service continuity), if accurately captured, will translate into “quality” of the service * Objectives of SLM * define, document, agree, monitor, measure, report, and review how well the IT service is delivered * ensure specific and measurable targets are developed * work with business relationship management to build a working relationship with thecustomers * ensure customers have a clear and unambiguous expectation of the service level * ascertain customer satisfaction through surveys, interviews, etc. with an agreed satisfaction score * improve services through a cost-effective and proactive way * Scope of SLM * includes the performance of existing services and the definition of required service levels for planned services (service level requirements) for expectation management * agreed in the form of service level agreement (SLA) for warranty * when 3rd parties are involved, operation-level agreements (OLA – for internal units) and underpinning contracts (external) are also required * NOT including utility * review with customer for the service quality (better with face-to-face meetings), SLA might be re-negotiated depending on the circumstances * Activities involved: * Designing SLA frameworks
Using the Service Catalog as an aid, SLM must design the most appropriate SLA structure to ensure that all services and all customers are covered in a manner best suited to the organization’s needs, e.g. multi-level SLA, etc. * Determine, negotiate, document and agree requirements for new or changed services in SLRs, and manage and review them through the service lifecycle into SLAs for operational services.
Once the Service Catalog has been produced and the SLA structure has been agreed, a first SLR must be drafted. It is advisable to involve customers from the outset, and to produce a first outline draft of the performance targets and the management and operational requirements, as a starting point for more detailed and in-depth discussion. * Monitor and measure service performance achievements of all operational services against targets within SLAs. * Measure and improve customer satisfaction.
There are a number of important ‘soft’ issues that cannot be monitored by mechanistic or procedural means, such as customers’ overall feelings. For example, even when there have been a number of reported service failures, the customers may still feel positive about things, because they may feel satisfied that appropriate actions are being taken to improve things. * Review and revise underpinning agreements and service scope.
IT service providers are dependent to some extent on their own internal technical support teams or on external partners or suppliers. They cannot commit to meeting SLA targets unless their own support team’s and suppliers’ performances underpin these targets. * Produce service reports.
As soon as the SLA is agreed and accepted, monitoring must be instigated and service achievement/misses reports must be produced. The SLA reporting mechanisms, intervals and report formats must be defined and agreed with the customers. Exception reports are needed whenever there are incidents. * Conduct service reviews and instigate improvements within an overall Service Improvement Program/Plan (SIP).
Periodic review meetings must be held on a regular basis with customers (or their representatives) to review the service achievement in the last period and to preview any issues for the coming period. It is normal to hold such meetings monthly, or as a minimum, quarterly. * Review and revise SLAs, service scope and underpinning agreements.
All agreements and underpinning agreements, including SLAs, underpinning contracts and OLAs, must be kept up-to-date. They should be brought underChange and Configuration Management control and reviewed periodically, at least annually, to ensure that they are still current and comprehensive, and are still aligned to business needs and strategy. * Develop and document contacts and relationships with the business, customers and stakeholders.
It is very important that SLM develops trust and respect with the business, especially with the key business contacts. Using the Service Catalog, especially the Business Service Catalog element of it, enables SLM to be much more proactive. * Develop, maintain and operate procedures for logging, action and resolving all complaints, and for logging and distributing compliments.
The logging procedures are often performed by the Service Desk as they are similar to those of Incident Management and Request Fulfilment. * Output of SLM: Service Level Agreement (SLA) * Mutli-level SLAs – Service Level SLA (may include multiple classes e.g. gold, silver, bronze), Customer Level SLA, Corporate Level SLA * Periodic review of the SLA is required * Red (target breached), amber (target threatened), green (target reached) are commonly used in service level management monitoring charts (SLAM charts) * In case of identifying issues, service improvement plan (SIP) would need to be drafted and agreed upon for further actions. The SLM would work with the CSI manager on the issue. * Whether an SIP is required depends on the cost of improvement actions and the business benefit * Interface with Other Processes * Business relationship management * This process ensures that the service provider has a full understanding of the needs and priorities of the business and that customers are appropriately involved/represented in the work of service level management. * Service catalogue management * This process provides accurate information about services and their interfaces and dependencies to support determining the SLA framework, identifying customers/business units that need to be engaged by SLM and to assist SLM in communicating with customers regarding services provided. * Incident management * This process provides critical data to SLM to demonstrate performance against many SLA targets, as well as operating with the fulfilment of SLA targets as a CSF. SLM negotiates support-related targets such as target restoration times and then the fulfilment of those targets is embedded into the operation of the incident management process. * Supplier management * This process works collaboratively with SLM to define, negotiate, document and agree terms of service with suppliers to support the achievement of commitments made by the service provider in SLAs. Supplier management also manages the performance of suppliers and contracts against these terms of service to ensure related SLA targets are met. * Availability, capacity, IT service continuity and information security management * These processes contribute to SLM by helping to define service level targets that relate to their area of responsibility and to validate that the targets are realistic. Once targets are agreed, the day-to-day operation of each process ensures achievements match targets. * Financial management for IT services * This process works with SLM to validate the predicted cost of delivering the service levels required by the customer to inform their decision-making process and to ensure that actual costs are compared with predicted costs as part of the overall management of the cost effectiveness of the service. * Design coordination * During the service design stage, this process is responsible for ensuring that the overall service design activities are completed successfully. SLM plays a critical role in this through the development of agreed SLRs and the associated service targets which the new or changed service must be designed to achieve.

Key Concepts and Terms
Service Level Requirements (SLR) * represents what is required by the customer in an objective way for a particular aspect of the service based on business objectives (e.g. checkout capability increase by 20% over the existing system) * high level SLRs are formulated during Service Strategy to consider the value of the service while details SLRs are developed during Service Design * need to be agreed with by both customer and IT development team * form an important part of the service design specifications * testing criteria need to be developed for testing

Service Level Agreement (SLA) * Based on the work done with SLR, SLA describes the service and the quality measures by which the delivery of that service will be judged (in plain terms to avoid confusion), telling what is and is not provided * signed by the provider and the customer and monitored by both through reporting (with enough details) * trending in the service level must also be monitored to ensure quality * Contents of SLA: * description of the purpose and scope of the document (location, date, what’s included and not) * support service and period * level of availability, reliability, service continuity and security and the measurement metrics (to reflect the level of service experienced by the customer) * If the service support involves other internal units or external parties, operation-level agreements and underpinning contracts are also required before signing of the SLA * Operation-level Agreements (OLAs) – straightforward agreement to specify the realistic level of support to another internal unit, legal jargons are not needed * Underpinning Contracts (UCs) – contractual and therefore legally enforceable agreements, sufficient monitoring and reporting are needed * Structure of SLA: * Service-based – each SLA refers to only one service (organization-wide service) * Customer-based – an SLA for a customer * Multilevel – include corporate, customer and service levels

Conclusion: ITIL® v3 Foundation Service Design
This ITIL® v3 Foundation study note provides a discussion on the purpose, objectives and scope of service level management process. The various types of documents including service level requirements (SLR), service level agreements (SLA), operational-level agreement (OLA) and underpinning contract (UC) are also explained.
An important process of the Service Design phase for the ITIL® v3 Foundation Certification exam is covered here: service level management (SLM). The purpose, objectives, and scope of the processes and their importance in the Service Design lifecycle stage are addressed.

Service Level Management Process * Purpose of SLM: ensure that all current and planned IT services are delivered to agreed achievable targets (service level agreement) using an objective measurement through discussion and negotiation with customers * primarily concerned about the warranty aspects (security, capability, availability, service continuity), if accurately captured, will translate into “quality” of the service * Objectives of SLM * define, document, agree, monitor, measure, report, and review how well the IT service is delivered * ensure specific and measurable targets are developed * work with business relationship management to build a working relationship with the customers * ensure customers have a clear and unambiguous expectation of the service level * ascertain customer satisfaction through surveys, interviews, etc. with an agreed satisfaction score * improve services through a cost-effective and proactive way * Scope of SLM * includes the performance of existing services and the definition of required service levels for planned services (service level requirements) for expectation management * agreed in the form of service level agreement (SLA) for warranty * when 3rd parties are involved, operation-level agreements (OLA – for internal units) and underpinning contracts (external) are also required * NOT including utility * review with customer for the service quality (better with face-to-face meetings), SLA might be re-negotiated depending on the circumstances * Activities involved: * Designing SLA frameworks
Using the Service Catalog as an aid, SLM must design the most appropriate SLA structure to ensure that all services and all customers are covered in a manner best suited to the organization’s needs, e.g. multi-level SLA, etc. * Determine, negotiate, document and agree requirements for new or changed services in SLRs, and manage and review them through the service lifecycle into SLAs for operational services.
Once the Service Catalog has been produced and the SLA structure has been agreed, a first SLR must be drafted. It is advisable to involve customers from the outset, and to produce a first outline draft of the performance targets and the management and operational requirements, as a starting point for more detailed and in-depth discussion. * Monitor and measure service performance achievements of all operational services against targets within SLAs. * Measure and improve customer satisfaction.
There are a number of important ‘soft’ issues that cannot be monitored by mechanistic or procedural means, such as customers’ overall feelings. For example, even when there have been a number of reported service failures, the customers may still feel positive about things, because they may feel satisfied that appropriate actions are being taken to improve things. * Review and revise underpinning agreements and service scope.
IT service providers are dependent to some extent on their own internal technical support teams or on external partners or suppliers. They cannot commit to meeting SLA targets unless their own support team’s and suppliers’ performances underpin these targets. * Produce service reports.
As soon as the SLA is agreed and accepted, monitoring must be instigated and service achievement/misses reports must be produced. The SLA reporting mechanisms, intervals and report formats must be defined and agreed with the customers. Exception reports are needed whenever there are incidents. * Conduct service reviews and instigate improvements within an overall Service Improvement Program/Plan (SIP).
Periodic review meetings must be held on a regular basis with customers (or their representatives) to review the service achievement in the last period and to preview any issues for the coming period. It is normal to hold such meetings monthly, or as a minimum, quarterly. * Review and revise SLAs, service scope and underpinning agreements.
All agreements and underpinning agreements, including SLAs, underpinning contracts and OLAs, must be kept up-to-date. They should be brought underChange and Configuration Management control and reviewed periodically, at least annually, to ensure that they are still current and comprehensive, and are still aligned to business needs and strategy. * Develop and document contacts and relationships with the business, customers and stakeholders.
It is very important that SLM develops trust and respect with the business, especially with the key business contacts. Using the Service Catalog, especially the Business Service Catalog element of it, enables SLM to be much more proactive. * Develop, maintain and operate procedures for logging, action and resolving all complaints, and for logging and distributing compliments.
The logging procedures are often performed by the Service Desk as they are similar to those of Incident Management and Request Fulfilment. * Output of SLM: Service Level Agreement (SLA) * Mutli-level SLAs – Service Level SLA (may include multiple classes e.g. gold, silver, bronze), Customer Level SLA, Corporate Level SLA * Periodic review of the SLA is required * Red (target breached), amber (target threatened), green (target reached) are commonly used in service level management monitoring charts (SLAM charts) * In case of identifying issues, service improvement plan (SIP) would need to be drafted and agreed upon for further actions. The SLM would work with the CSI manager on the issue. * Whether an SIP is required depends on the cost of improvement actions and the business benefit * Interface with Other Processes * Business relationship management * This process ensures that the service provider has a full understanding of the needs and priorities of the business and those customers are appropriately involved/represented in the work of service level management. * Service catalogue management * This process provides accurate information about services and their interfaces and dependencies to support determining the SLA framework, identifying customers/business units that need to be engaged by SLM and to assist SLM in communicating with customers regarding services provided. * Incident management * This process provides critical data to SLM to demonstrate performance against many SLA targets, as well as operating with the fulfilment of SLA targets as a CSF. SLM negotiates support-related targets such as target restoration times and then the fulfilment of those targets is embedded into the operation of the incident management process. * Supplier management * This process works collaboratively with SLM to define, negotiate, document and agree terms of service with suppliers to support the achievement of commitments made by the service provider in SLAs. Supplier management also manages the performance of suppliers and contracts against these terms of service to ensure related SLA targets are met. * Availability, capacity, IT service continuity and information security management * These processes contribute to SLM by helping to define service level targets that relate to their area of responsibility and to validate that the targets are realistic. Once targets are agreed, the day-to-day operation of each process ensures achievements match targets. * Financial management for IT services * This process works with SLM to validate the predicted cost of delivering the service levels required by the customer to inform their decision-making process and to ensure that actual costs are compared with predicted costs as part of the overall management of the cost effectiveness of the service. * Design coordination * During the service design stage, this process is responsible for ensuring that the overall service design activities are completed successfully. SLM plays a critical role in this through the development of agreed SLRs and the associated service targets which the new or changed service must be designed to achieve.

Key Concepts and Terms
Service Level Requirements (SLR) * represents what is required by the customer in an objective way for a particular aspect of the service based on business objectives (e.g. checkout capability increase by 20% over the existing system) * high level SLRs are formulated during Service Strategy to consider the value of the service while details SLRs are developed during Service Design * need to be agreed with by both customer and IT development team * form an important part of the service design specifications * testing criteria need to be developed for testing

Service Level Agreement (SLA) * Based on the work done with SLR, SLA describes the service and the quality measures by which the delivery of that service will be judged (in plain terms to avoid confusion), telling what is and is not provided * signed by the provider and the customer and monitored by both through reporting (with enough details) * trending in the service level must also be monitored to ensure quality * Contents of SLA: * description of the purpose and scope of the document (location, date, what’s included and not) * support service and period * level of availability, reliability, service continuity and security and the measurement metrics (to reflect the level of service experienced by the customer) * If the service support involves other internal units or external parties, operation-level agreements and underpinning contracts are also required before signing of the SLA * Operation-level Agreements (OLAs) – straightforward agreement to specify the realistic level of support to another internal unit, legal jargons are not needed * Underpinning Contracts (UCs) – contractual and therefore legally enforceable agreements, sufficient monitoring and reporting are needed * Structure of SLA: * Service-based – each SLA refers to only one service (organization-wide service) * Customer-based – an SLA for a customer * Multilevel – include corporate, customer and service levels

Conclusion: ITIL® v3 Foundation Service Design
This ITIL® v3 Foundation study note provides a discussion on the purpose, objectives and scope of service level management process. The various types of documents including service level requirements (SLR), service level agreements (SLA), operational-level agreement (OLA) and underpinning contract (UC) are also explained.
Other processes of the Service Design phase for the ITIL® v3 Foundation Certification exam are covered here, including: service catalog management, availability management, information security management, supplier management, capacity management, IT service continuity management and design coordination. The purpose, objectives, and scope of the processes and their importance in the Service Design lifecycle stage are addressed.

Service Catalog Management Process * A service catalogue is a database or structured document with information about all live IT services, including those available for deployment. The service catalogue is part of the service portfolio and contains information about two types of IT service: customer-facing services that are visible to the business and supporting services required by the service provider to deliver customer-facing services. * The service catalogue has different views for different people (users, IT, etc.) – two-view(business service/technical service) or three-view (wholesale customer, retail customer and supporting services). * Purpose: provide and maintain a single source of consistent information on all operational / ready-to-deploy services, used by customers and IT, essential to service management * Objectives * the production and maintenance of the service catalogue * documenting the details of the service, status, interfaces and dependencies (obtained from Configuration Management System), often in service packages (solution) * the info is made available in a suitable format to authorized persons * Scope * all services in production or will be transitioned to production * create definitions and descriptions of services / service packages * may optionally include services that can be requested

Availability Management Process * Poor availability is the primary cause for customer dissatisfaction. * A firm understanding of the effect of downtime to business processes should be well studied * Customer satisfaction is not only about availability but the perception on how IT responds to issues and understands business processes from customer’s perception * Vital Business Function (VBF) should have a high availability * [definition] Availability is the ability of an IT service or other configuration item to perform its agreed function when required. Any unplanned interruption to a service during its agreed service hours (also called the agreed service time, specified in the service level agreement) is defined as downtime. * Availability Formula (use the agreed service time in calculation):

* Since availability management is primarily concerned about customer satisfaction, the definition on service uptime (whether it is end-to-end or just the service) should be agreed by the customer by balancing the cost and availability * Need to identify vital business function (VBF) for high availability need to justify the higher cost * Purpose: take the necessary steps (improvements) to deliver the availability requirements defined in the SLA in a cost-effective way and timely manner, taking into accounts current and future needs * Objectives * create annual or bi-annual plans for fulfilling availability requirements (useful for budget allocation) * monitor availability * provide availability-related advice throughout service lifecycle * assess risks on availability for change requests * take proactive steps to improve and optimize availability of end-to-end services * Scope * covers the design, implementation, measurement, management, testing and improvement of IT service and component availability (reduce availability issues throughout the service lifecycle) * make sure availability is duly considered in service design * should be applied to all operational services and technology, particularly those covered by SLAs. * monitor and measure availability according to SLA (if available) * include both reactive (monitoring by event management, investigating downtime incidences) and proactive (identifying and managing risks) activities * all information is recorded in the availability management information system * an on-going process, finishing only when the IT service is decommissioned or retired * Concepts of availability: * [definition] Reliability is a measure of how long a service, component, or CI can perform its agreed function without interruption– measured by mean time between failures / incidents * good quality components / good suppliers * Resilience: designing the service so that a component failure does not result in downtime * with redundancy (component failure won’t affect the system) * Maintainability: (internal) how quickly the fault can be overcome, measured by mean time to restore service (MTRS)NOT mean time to repair (MTTR) * * e.g. with spare parts on site * [definition] Serviceability is the ability of a third-party supplier to meet the terms of its contract – the time taken by the contractor to restore the service (external – including maintainability and/or reliability requirements) * involves two key elements: * Reactive activities these involve the monitoring, measuring, analysis and management of all events, incidents and problems involving unavailability. These activities are principally performed as part of the operational roles. (Service Operation phase) * Proactive activities these involve the proactive planning, design and improvement of availability. These activities are principally performed as part of the design and planning roles. (Service Design phase) * service availability (end-to-end service) vs. component availability * continuous availability = 100% availability, impossible to maintain

Information Security Management Process * Information security is the management process within the corporate governance framework, which provides the strategic direction for security activities and ensures objectives are achieved. * To identify and mitigate information (data stores, databases and metadata) security risks * Information security is integral to service design * Information security must be an integral part of all services and systems and is an ongoing process that needs to be continuously managed using a set of security controls * Statistics show that the large majority of security incidents stem from human errors (intended or not) or procedural errors, and often have implications in other fields such as safety, legal or health * Purpose * to ensure IT security meets the overall business security requirements through availability, integrity and confidentially * information is made available to only authorized persons when needed * data integrity – protected from corruption and unauthorized alternation * Objectives * To protect the interests of those relying on information, and the systems and communications that deliver the information, from harm resulting from failures of confidentiality, integrity, and availability. * Scope * all aspects of information security * define protection levels (including technical and physical) with security policy and plans * identify risks and implement countermeasures * understand regulatory and organizational requirements * Output * Information Security Policy (produce and maintain), including: * Use and misuse of IT assets policy * An access control policy, a password control policy * An email policy, an Internet policy, an antivirus policy, a remote access policy * An information classification policy, a document classification policy * A policy for supplier accessing to IT service, information, and components * A copyright infringement policy for electronic material * An asset disposal policy * A records retention policy * Information Security Management System (ISMS) – standards, management procedures and guidelines supporting the information security policies * Available to all customers * Referred to in all SLRs, SLAs, OLAs, underpinning contracts and agreements * Educate all staff about the policy and their responsibilities * Need to be formally reviewed at least annually

Supplier Management Process * Supplier Management is the process responsible for obtaining value for money from suppliers, ensuring that all contracts and agreements with suppliers support the needs of the business and that all suppliers meet their contractual commitments. * Supplier performance is directly related to service performance, therefore in the service design phrase * Purpose * ensure suppliers provide value for money by managing the contracts with suppliers driven by a supplier strategy and policy from Service Strategy * Objectives * ensure suppliers deliver the service paid for which aligns to the business objectives (as well as SLRs and SLAs) * control the cost of the contract by using objective selection criteria * manage relationship with suppliers – the relationship is owned by an individual within supplier management * Scope * select supplier and agree to the terms of the contracts * review contracts for improvement * monitor and manage supplier performance especially the suppliers providing critical services through supplier categorization – strategic, tactical, operational and commodity suppliers * risk identification * Output * supplier policy

Capacity Management Process * Capacity Management is responsible for ensuring that the capacity of IT services and the IT infrastructure is able to meet agreed current and future capacity and performance needs in a cost-effective and timely manner. * Purpose * understand current and future service capacity (both hardware and software) needs and ensure delivery of that level of service * one way to ensure future need is to allow easy and timely increase in capacity when needed * Objectives * develop a detailed plan on the current and expected future requirements and actions steps to fulfil these * consider implication of change requests on capacity * take proactive measures to improve performance at a reasonable cost * Scope * ensure sufficient capacity all the time (including seasonal fluctuations) * reduce capacity to save costs if service need dwindles * include technical, application, operation and human resources consideration * monitor pattern of business activity to understand the demands * suggest and enact proactive improvements through metrics feedback from the service * Sub processes * Business Capacity Management – to calculate and forecast needs according to the business plan * Service Capacity Management – to understand how the use of individual live services vary over time and deliver agreed capacity for individual services * Component Capacity Management – to understand the utilization and capabilities of all components for end-to-end service, to clear bottleneck * Output * Capacity Plan * captures the current and future requirements and proposes action steps for the 12 to 18 months ahead and to be reviewed at least annually * introduction – current capacity and issues, scope of the plan, assumptions * management summary * possible scenarios – reasons, capacity requirements and possible outcomes (forecast) for individual services * recommendation and Contents
IT Service Continuity Process * IT service continuity management (ITSCM) is responsible for the continuity of the IT services required by the business in times of disasters or extreme events to recover the IT services. (Less significant incidents are dealt with by Incident Management Process.) * Included as one element of the business continuity plan (BCM) (also: human resources continuity plan, financial management continuity plan, etc.) * Purpose * identify and manage the risks to the IT services * agree with the business for the minimum requirement of service in case of a disaster * Objectives * to reduce the chance of a disaster occurring at all by identifying the risks to IT services and implementing cost-effective countermeasures to reduce or remove the risk * to have a plan to restore an acceptable level of service according to agreed timescales * to review continuity plan from time to time by carrying out business impact analysis (BIA) and risk re-assessments * Scope * Focus on major events with a catastrophic impact (e.g. fire, flood, explosion, etc.) * provide the technical facilities to enable critical services to perform in time of disasters * agree on policies and plans and test the plans * carry out business impact analysis to manage risks * develop a strategy for service continuity to align to business continuity strategy * Sub processes * Business Impact Analysis – identify key services that need continuity at different time of the day/month/year and clarify relative importance of individual services * Risk Assessment – to compile a list of evaluated risks and propose countermeasures * These will ensure the provision of IT service continuity in a cost-effective way * Output * IT service continuity plan * adopt a lifecycle approach: initiation, requirements & strategy, implementation, operation

Design Coordination Process * Service Design not only involves providing the utility but also the warranty (including availability, security, continuity and capacity), which requires interface with other activities and processes.

* Purpose * carry out the coordination of the many different activities of service design to avoid complications and misunderstanding * Objectives * to ensure all aspects of the design (architecture, processes and metrics) to provide utility and warranty to meet business requirements for now and in future * to resolve conflicts in demand in case of simultaneous competing projects including resources and time conflicts * to ensure everyone is clear about the requirements for handing over between different lifecycle (e.g. service design package to transition phase) * to check whether all requirements are met and repeatable design practices are used * to reduce risks associated with complexity of projects * to compile the service design package within inputs from various processes * Scope * cover all activities in design and ensure consistency across them for new, existing and retiring services (usually for large projects but according to guidelines of individual organizations) * Output * service design package * suggestions for improvements for service design stage

Conclusion: ITIL® v3 Foundation Service Design
This ITIL® v3 Foundation study note gives an introduction to the various essential processes to the Service Design phrase of the service lifecycle. These processes are important to an effective design, i.e. a service which fulfills the utility and warranty needs of current and future business requirements.
People aspect of the Service Design phase of the ITIL® v3 Foundation Certification exam are covered here, including roles and responsibilities of process owner, process manager, process practitioner and service owner, the RACI (responsible, accountable, consulted, informed) responsibility model and how staff can acquire the skills to work effectively.

Roles and Responsibilities in Service Management * roles may be combined, shared or spilt according to organization needs but there is only one service owner and one process owner * role is NOT identical to the title * may adopt the Skills Framework for the Information Age (SFIA) for describing job titles, roles and responsibilities * one task may touch several processes, e.g. submit a change request for a capacity issue * A role is a set of responsibilities, activities and authorities assigned to a person or team. A role is defined in a process or function.

Service Owner * each service has a single service owner to accountable for delivering the service across all process areas in an effective and efficient manner * accountable to customer and IT director / service management director * Responsibilities: * represent the service * work with all IT groups and process owners to deliver, support and improve the service to the required standards according to business objectives * work with customers to understand the requirements, raise RFC and solve issues * monitoring and reporting * study impacts on the service by changes in other services / environments * maintain the service catalogue entry * ensure the process conforms to all policies * as a primary stakeholder in all the processes involved with the service

Process Owner * accountable for a single process (for all affecting services) * Responsibilities: * ensure the process works efficiently and effectively * develop the process strategy, policies and standards * design the process and improve its design, document the process * design the metrics to be collected and monitor for efficiency * ensure the availability of resources and capabilities to carry out the process * responsible for the consistency of the process application

Process Manager * responsible for managing the actual implementation of the process * Responsibilities: * liaise with process owner * manage staff available and suitability * work with other process managers * monitor the process metrics to suggest improvement (seek feedback from process practitioners)

Process Practitioner * responsible for carrying out the process activity (can also be the process manager) under the guidance of the process manager * Responsibilities: * understand and complete the process activities * work with process stakeholders to ensure correctness * produce records of the process activities * identify improvements

The RACI Model * identify the responsibilities and accountabilities for each process task to avoid confusion * The RACI model: * Responsible – people (at least one) who “get the job done” by actually carrying out the task * Accountable – one person (only one) who owns the task and ensures that the quality of the work meeting the requirements * Consulted – people (if any) who are consulted for their opinion / expertise over a process activity * Informed – people (if any)who are updated for the progress of the activity * The process owner is accountable for the end-to-end process (including all activities) * The RACI matrix | Person A | Person B | Person C | Person D | Activity 1 | AR | C | I | I | Activity 2 | A | R | C | C | Activity 3 | R | A | I | | Activity 4 | A | R | C | I | * Clarifying the level of involvement within the process * Helping to understand what should be included in the operation-level agreement * Clarifying the workflow and handoff points * Points to note: * Ensuring that the process, roles, responsibilities and documentation are regularly reviewed and audited * Interfacing with line management, ensuring that the process receives the necessary staff resources. Line management and process owners have complementary tasks; they need to work together to ensure efficient and effective processes. Often it is the task of line management to ensure the required training of staff.

Competence and Training * Staff need to understand their role and the importance and the relationship to other processes * The ITIL® Qualifications scheme provides a roadmap for staff to understand and apply the ITIL® framework * Education and training develop the capabilities of the people * Training include: * knowledge of the business * customer service skills and people skills * knowledge for their roles and the organization policies and procedures * analytical skills

Conclusion: ITIL® v3 Foundation Service Design
This ITIL® v3 Foundation study note discusses the key roles in IT service management: service owner, process owner, process manager and process practitioner. The RACI matrix is also touched upon in which RACI stands for responsible, accountable, consulted and informed.
The Service Transition phase of the ITIL® v3 Foundation Certification exam is covered here with an introduction of Service Transition and the Change Management Process. Service Transition is concerned with the delivery of a new / changed service into operation.

Purpose, Objectives and Scope of Service Transition * All stakeholders need to be considered in the transition planning to ensure customers satisfaction of the service * Provide a consistent and managed approach to reduce risks and enhance efficiency and effectiveness of service introduction

Purpose of Service Transition * The purpose of Service Transition is to ensure that the agreed services are now delivered from service design to service operation effectively (deployment)

Objectives of Service Transition * Plan and manage changes to services (either introducing new or retiring existing services) and to deploy the new services successfully to support business objectives while ensuring the integrity of all existing services * Ensure the service can be operated and supported according to the service design * Manage the risks associated * Set the expectations of the business with testing on the performance * Provide knowledge and info of the service / service assets to relevant people to ensure smooth operation

Scope of Service Transition * Provide guidance on the development and improvement of the required capabilities * Provide guidance on service transition between internal and external service providers including relationship between strategy, design and transition (also considers service retirement and transfer of services between service providers) * Provide guidance on management of transition for the coordination of all activities involved (among different projects) * Communicate with all parties concerned
Processes of Service Transition * Knowledge Management * Transition Planning and Support * Change Management * Service Asset and Configuration Management (SACM) * Release and Deployment Management * Service Validation and Testing (*not covered in ITIL® v3 Foundation exam) * Evaluation (*not covered in ITIL® v3 Foundation exam)
Change Management Process * A change is the addition, modification or removal of anything that could have an effect on IT services * Change requests are submitted as Requests for Change (RFC), the degree of formality of the RFC depends on the extent of the change * Change Records are to be used to capture the details of the lifecycle of the changes making references to the configuration items affected (stored in configuration management system), one change record for each individual change * No change should be approved without a back-out or remediation plan (to restore the initial configuration) * Remediation’s are actions taken to recover after a failed change or release. Remediation may include back-out, invocation of service continuity plans, or other actions designed to enable the business process to continue. * Purpose: to control the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services. * uncontrolled changes might cause a surge in incidents * to consider all aspects (intended and unintended) a change may bring * Objectives * to keep abreast of and support the changes in the business environment (by reducing incidents, disruption and rework) * to ensure that changes are recorded and evaluated, and that authorized changes are prioritized, planned, tested, implemented, documented and reviewed in a controlled manner as recorded in the configuration management system (CMS) * to optimize risk (balance between risk of doing and risk of not doing) * to control the assets of the infrastructure * Scope * cover everything from configuration items (servers, infrastructure, documentation, services and configuration), management systems and tools, processes, metrics, solution and architecture from design strategy to continual service management excluding organization and business changes, and minor operational changes * manage all changes in a controlled manner on all levels (strategic, tactical and operational) by making reference to the service portfolio * Change management is not responsible for the coordination of processes for the successful implementation of projects; this will be handled through the planning and transition support process. * Output * change schedule (CS, also an input) * projected change outage (PSO) * remediation plan * ITIL® recommends the use of a change model or change process model to handle changes in a consistent manner: * Steps for handling the change * The order in which the steps should be carried out, including any dependencies * Responsibilities throughout the process * Timescales * Escalation procedures * Types of Changes * Standard Change – a change to a service or other configuration item, which has preauthorized approach to its execution, well understood for risks, follow a standard procedure with a predefined trigger * e.g. installation of a new computer * RFC not required, logged as service requests * enhance the effectiveness of change management * records need to be reviewed regularly * Emergency Change – a change in response to or in order to prevent a business-critical error * need to have a clear definition of the authority levels associated with emergency changes (e.g. emergency change advisory board (ECAB) * may not have enough time for extensive testing * documentation may need to be updated afterwards * risk of failure is high * Normal Change – * Typical flow (all information stored in SKMS): * Create the request for change (RFC) -> trigger the creation of the change record * Review the RFC – sufficient information, appropriate budget, is it practical by the change manager * Assess and evaluate the change (after approval of RFC) – need Change Proposal? * 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? * Authorize the change – by a change authority usually CAB, update the change schedule and projected service outage (PSO) with a remediation plan * Plan updates – build and test * Coordinate change implementation – to ensure changes are deployed as scheduled * Review and close the change – pass the acceptance criteria: success -> close the change record; failure -> remediation plan or workaround * Change Proposal: submitted for major change that involves significant cost, risk or organizational impact, before the new/change service is chartered, normally created by Service Portfolio management. Change proposals include a high-level description of the change, a detailed business case (including risk assessment) and schedule for design and implementation. When authorized, the service is chartered. * RFC should specify the details of the change, including the risks, benefits, costs, and proposed schedule for implementation, depending on guidelines. * Change Advisory Board (CAB) * determine whether normal changes should be authorized * include people from business and technical sides, stakeholders to reflect a balanced view * Change management process is an trigger for change evaluation process * Change management involve the assessment of a large number of other processes (e.g. capacity, IT service continuity, security, etc.)

Conclusion: ITIL® v3 Foundation Service Transition
This ITIL® v3 Foundation study note touches upon the definition, purpose, objectives and scope of Service Transition. The Change Management Process, which is an important process in service transition stage, is also covered together with the concepts of change management include the types of changes (standard, emergency and normal changes), change models and change advisory board.
Other processes of the Service Transition phase for the ITIL® v3 Foundation Certification exam are covered here, including: release and deployment management, knowledge management, service asset and configuration management, transition planning and support. The purpose, objectives, and scope of the processes and their importance in the Service Transition lifecycle stage are addressed.

Transition Planning and Support Process * a key process for Service Transition * covers the interface between service transition, project management and business engagement * needs to work with * Technical Management Function: provides resources for managing the infrastructure * Application Management Function: provides resources for managing applications * Purpose: to plan and coordinate the transition activities across different processes at a high level with coordination of resources and capabilities (availability and schedule) * Objectives * plan, coordinate and monitor resources and various parties for the transition and associated activities within the budget and timeframe * establish new requirements for management information systems and tools and other management systems * ensure repeatable processes (a framework) are adopted during transition of different services * identify and manage risks according to organization risk management framework * Scope * plan future transition needs * maintenance of policies and standards * provide transition guidance and plan for achieving business goals * coordinate and prioritize resources for multiple transition needs * review and improvement current process and plan for future transition needs * Not including the detailed plans for building, testing and deployment

Service Asset and Configuration Management Process * control over the assets under IT management in an efficient and effective manner * Purpose of SACM: to ensure the control of IT assets for services by having an accurate record of the assets and their relationships and configuration * Objectives * ensure proper management of IT assets through identification, recording (with historic data) and control (verification) * manage the integrity of configuration items (CIs) which are controlled by change management * an item of infrastructure that is managed to deliver a service * all configuration items are service assets, but not vice versa (e.g. knowledge of technician is asset but not configuration item) * create a configuration management system * holds all information about CIs and their relationship * may make use of automatic tools to capture the data * four layers: Presentation, knowledge processing, information integration, data * Scope * all configuration items (CIs) * identify and apply control to elements of the infrastructure that are to be managed as service assets * baseline, maintain and control through change management all CIs with a configuration management system (CMS) in configuration management databases (CMDBs) * any interfaces with internal and external configuration items (e.g. shared assets), e.g. license management * Activities * 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 overarching Service Asset and Configuration Management strategy. * Configuration identification * Define and document criteria for selecting configuration items and the components that compose them * Select the configuration items and the components that compose them based on documented criteria * Assign unique identifiers to configuration items * Specify the relevant attributes of each configuration item * Specify when each configuration item is placed under Configuration Management * Identify the owner responsible for each configuration item. * Configuration control
Configuration control ensures that there are adequate control mechanisms over CIs while maintaining a record of changes to CIs, versions, location and custodianship/ownership. Without control of the physical or electronic assets and components, the configuration data and information there will be a mismatch with the physical world. No CI should be added, modified, replaced or removed without an appropriate controlling documentation or procedure being followed. * Status accounting and reporting each asset or CI will have one or more discrete states through which it can progress. The significance of each state should be defined in terms of what use can be made of the asset or CI in that state. There will typically be a range of states relevant to the individual asset or CIs. A simple example of a lifecycle is: development or draft — approved — withdrawn. The way CIs move from one state to another should be defined, for example, an application release may be registered, accepted, installed or withdrawn. * Verification and audit
The activities include a series of reviews or audits to: * Ensure there is conformity between the documented baselines (for example, agreements, interface control documents) and the actual business environment to which they refer * Verify the physical existence of CIs in the organization or in the DML and spares stores, the functional and operational characteristics of CIs and to check that the records in the CMS match the physical infrastructure * Check that release and configuration documentation is present before making a release * Definition of Terms * Service Asset – any resource or capability that could contribute to the delivery of a service * Configuration Item – a service asset that needs to be managed in order to deliver an IT service * Configuration Record – a set of attributes and relationships about a CI in configuration management databases (CMDBs) * Configuration Model – a model of the services, assets, and infrastructure of each configuration item and their relationships to each other for planning and decision use * One of the most crucial factors is to define the level of detail required to manage configuration items successfully * Categories of CI suggested by ITIL® include: * Service Lifecycle CIs – documents that provide information on the plans and requirements for the services, including costs and benefits * Service CIs – service capability and service resource assets; service model, package, etc. * Organization CIs – documentation relating to organizational policies or standards * Internal CIs – internal assets such as software or hardware * External CIs – external customer requirements and agreements * Interface CIs – documentation relating to end-to-end service provision across multiple service providers * Definitive Media Library (DML) * consists of a number of software libraries or file storage areas (physical or electronic), which are managed and kept separate from the live, test, or development storage areas * stores master copies of versions that have passed quality assurance checks * Requires policies for retention, security, backup, archive, etc. * Definitive Spares * spare components and assemblies that are maintained at the same level as the comparative systems within the controlled test or live environment * Configuration Baseline * the configuration of a service, product or infrastructure that has been formally reviewed and agreed on * Snapshot * the current state of a configuration item or an environment * snapshots are recorded in the CMS and remain as fixed historical records

Knowledge Management Process * control over the assets IT manages in an efficient and effective manner * Purpose: to ensure timely retrieval of relevant ideas, perspectives, experience, and information to the correct audience for informed decision making (facilitate reuse of knowledge) * Objectives * improve decision making by providing correct and timely information * reuse of knowledge for efficiency and effectiveness * maintain a service knowledge management system (SMKS) * [definition] SKMS is a set of tools and databases that is used to manage knowledge, information and data. The SKMS includes the configuration management system, as well as other databases and information systems. The SKMS includes tools for collecting, storing, managing, updating, analysing and presenting all the knowledge, information and data that an IT service provider will need to manage the full lifecycle of IT services. * manage the data and information * Includes sources such as the service portfolio, definitive media library, information in SLAs, OLAs and contracts, budgets, cost models, and service improvement plans, error information, etc. * gather, store, analyse and share knowledge * Scope * the management of data and information across the service management processes * share of information with customers and users * NOT including the detailed collection and maintenance (in Service Asset and Configuration Management) * Data-Information-Knowledge-Wisdom Structure (DIKW) * data – raw facts, e.g. date and time of incidents * information – data in context, e.g. average time between incidents * knowledge – apply experience (the tacit experiences, ideas, insights, values and judgements of individuals), context, and understanding to the information analysis, e.g. average time between incidents increased by 10% when a new service is introduced * wisdom – apply the knowledge with common-sense judgement / contextual awareness for improvement or better results, e.g. the increase in average time between incidents is due to poor documentation

Release and Deployment Management Process * Purpose: the build, test, and deployment of the release is successfully delivered with minimal adverse impact to business and other services * to ensure the process is planned, scheduled and controlled * Objectives * to define and agree on deployment plan with stakeholders * create and test release packages * maintain the integrity of the release packages (store in definitive media library) * ensure the new / changed services meets utility and warranty needs * capture lessons learned * ensure knowledge transfer to users and IT staff (support and operation) * Scope * the processes, systems, and functions required to deliver a release into production * build, ensure testing and deploy the release to the utility and warranty requirements * handover of service to operation teams * manage all CIs and things related to the release * Release Policy * should be defined for the release of each service / group of service * specify the types of releases that need to be controlled e.g. major release, minor release, emergency release * outlines the roles and responsibilities, use of definitive media library, customer expectation, acceptance criteria, authorization requirements, criteria for handover, etc. * Four Phases of Release and Deployment * Release and Deployment Planning – begins with planning a release and ends with change authorization to create the release * Release Build and Test – the release package is built, tested, and checked into the DML, end with authorization to include the package in DML * Deployment – deploy the package from DML and handover of service to operation, early life support might be needed for faster response and knowledge transfer * Review and Close – capture lessons learned and address issues * Big bang versus Phased * Big-bang option – 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. * 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 roll out plan. This will be the case in many scenarios such as in Retail Organizations for new services being introduced into the stores environment in manageable phases. * Push and Pull * A push approach is used where the service component is deployed from the centre and pushed out to the target locations. In terms of service deployment, delivering updated service components to all users – either in big-bang or phased form – constitutes ‘push’, since the new or changed service is delivered into the users environment at a time not of their choosing. * 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 choosing or when a user workstation restarts. The use of ‘pull’ updating a release over the internet has made this concept significantly more pervasive. A good example is virus signature updates, which are typically pulled down to update PCs and Servers when it best suits the customer, however at times of extreme virus risk this may be. * Automation versus Manual * Whether by automation or other means, the mechanisms to release and deploy the service components should be established in the release design phase and tested in the build and test stages of the new or changed service. Automation will help to ensure repeatability and consistency. The time required to provide a well designed and efficient automated mechanism may not always be available or viable. If a manual mechanism is used it is important to monitor and measure the impact of many repeated manual activities as they are likely to be inefficient and error prone. Too many manual activities will slow down the release team and create resource/capacity issues that affect the service levels.
Other Processes of the Service Transition * Service Validation and Testing Process: to ensure the service will perform as specified and be designed through service strategy and service design through testing and validation with customers * Change Evaluation Process: to check the predicted performance against the actual performance achieved by the new or changed service

Conclusion: ITIL® v3 Foundation Service Transition
This ITIL® v3 Foundation Certification study note discusses a number of management processes for Service Transition: transition planning and support, knowledge management, service asset and configuration management, release and deployment management. The purpose, objectives and scope of the processes are also included. These processes work together to allow the release of services into operational environment in a controlled manner, with minimal disruption to business. The Service Operation phase of the ITIL® v3 Foundation Certification exam is covered here with an introduction of Service Operation and how service operations are organized through four functions: Technical Management Function, Application Management Function, Operations Management Function and Service Desk Function. Service Operation is concerned with the delivery of service to the required standard.

Purpose, Objectives and Scope of Service Operation * Output of all previous phrases (service strategy, design and transition) becomes visible in service operation and begins delivering benefits to the business * Service operation spans a much longer period until the service is retired * The majority of IT staff is involved in this phrase * Benefits – savings, less incidents and downtime, automation to save staff requirements * Communication is very important

Purpose of Service Operation * The purpose of Service Operation is to deliver the agreed level of end-to-end service (through the service level management process) to the organization, including the maintenance and management of the services (e.g. updates, back up, etc.), within the operational budget. * Many processes from the previous phrases actually take place in this stage (e.g. service level management, capacity and availability management, etc.)
Objectives of Service Operation * Deliver the expected service (according to SLA) for customer satisfaction and delivery business values * Minimize incidents and disruptions * Control access to IT services through access management process

Scope of Service Operation * Includes the “processes, functions, organization, and tools” that are used to deliver and support the agreed services for business benefits * Collects performance data for continual service improvement * The ITIL® book provides guidance on * Service – all activities to deliver the service * Service Management Process – includes event, incident, problem and access management and request fulfilment * Technology – manage the technology (network, platform, database, etc.) to deliver the service * People – supporting staff

Functions * Function: a logical concept that refers to the people and automated measures that execute a defined process, an activity or a combination of processes or activities * ITIL® names 4 main functions (technical management, application management, operations management functions, and the service desk) that are responsible for carrying out all the lifecycle processes

Technical Management Function * to manage and develop the IT infrastructure, including the groups/teams that provide infrastructure support * organization aligned to the technology, e.g. mainframe management, web management, database administration * Staffing * technical managers – lead, decision-making, ensure training of staff * team leaders – assist technical manager * technical analysts/architects – identify the knowledge and expertise, document, train staff and users * technical operator – perform day-to-day operation * Role * manage the IT infrastructure * provide enough skilled supporting staff for the whole lifecycle from strategy to operation and service improvement * guide and support operations staff members * Objectives * provide technical infrastructure for business processes and solve issues * plan on new / improved service requirements

Application Management Function * involved in every stage of the service lifecycle of application, from ascertaining the requirements through design and transition and then operation and improvement * Role * manage the IT applications * ensure staff have the appropriate knowledge for the application management for the entire lifecycle * come up with application strategy * design the application * transit application to operation * support for operation * carry out training needs analysis and provide the training to technical and operation staff * Objectives * identify requirements for applications (utility and warranty) * design, assist in deployment and support applications * identify and implement improvements * Staffing * Application Manager / Team Leaders – lead and manager, assess training needs, report * Application Analysts / Architects – determine needs, develop operation models for optimal balance of performance vs resources * vs Application Development * development focuses on utility / management focuses on utility and warranty * development: one-time / management is concerned about the lifetime of the application * development: focus on software development / management: operation and improvement * management is needed for applications developed externally

IT Operations Management Function * carry out day-to-day activities for the delivery of the services to ensure SLA is met – i.e. provide quality service in an efficient and cost effective manner * Technical and Application Management Functions define the activities to be carried out by Operations Management Function * Objectives * maintain the “status quo” to achieve infrastructure stability * identify opportunities to improve operational performance and save costs * initial diagnosis and resolution of operational incidents * Staffing * IT Operations Manager – lead and manage, report * Shift Leaders – coordinates with other shift leaders for smooth handling of IT operations * IT Operations Analysts – determine the most effective ways to carry out IT operations * IT Operators – perform IT operations such as monitoring, back up, console operation, etc. * primarily concerned about stability and availability * ensure staff receive proper training on operations management * overcome failures (less complex) to minimize business impact, complex issues are to be dealt with by Technical and Application Management Functions

IT Operation Control * monitor the operational events of the IT infrastructure (console management) * scheduling and management of batch jobs (including backup, centralized printing and maintenance)

Facilities Management * responsible for physical IT environment (including power supply, UPS, power for disaster recovery sites, air conditioning) * work with third parties on data centre projects

Service Desk Function * responsible for dealing with a variety of service activities through calls, web interface or reported events * the single point of contact for users of IT services * critical for customer satisfaction as it is most visible * Staffing * need good communication skills and basic technical knowledge of all services * understand business processes and their impact in order to prioritize support * Objective * provide a single point of contact (SPOC) for all IT assistance needs * coordinate actions across all IT departments, on behalf of the user, keeping communication flowing back and forth * Resume services by solving simple incidents such as resetting password, providing instructions, etc. * prioritize support service needs * receives, handles, escalates and reports incidents / requests where appropriate * communicate with users on changes and incidents * monitor performances against SLA (including third-party providers) * Organization * Local Service Desk – co-located with users in the office, efficient but expensive, need more coordination among different service desks within the organization * Centralized Service Desk – economy of scale, better coordination, knowledge and mind sharing, no direct physical interaction with users * Virtual Service Desk – physically separated service desks linked together with a common system to log issues and communications, allocation of calls based on workload * Follow the Sun – similar to virtual service desk, allocation of calls based on time of day for 24-hour support, great for global organization * Specialized Service Desk Groups – need to specify the type of incidents on the user side to reach the support staff to allow faster resolution
Conclusion: ITIL® v3 Foundation Service Operation
This ITIL® v3 Foundation study note touches upon the definition, purpose, objectives and scope of Service Operation. Four main types of functions are also discussed, namely Technical Management Function, Application Management Function, Operations Management Function and Service Desk Function. Service Desk Function can be organized into local, centralized, virtual, follow the sun and specialized groups.
Other processes of the Service Operation phase for the ITIL® v3 Foundation Certification exam are covered here, including: Incident Management Process and Problem Management Process. The purpose, objectives, and scope of the processes and their importance in the Service Operation lifecycle stage are addressed. Definition on some generic concepts is also discussed: incident, impact, urgency and priority, problem, workaround, known error and known error database (KEDB).
Requests vs. Incidents vs. Problems * Requests are not incidents as no service has been impacted * Incident Management Process and Problem Management Process are two of the most important processes in ITIL® and are often the first ones to be implemented * Incident Management – fix faults as quickly as possible, to resume service, incidents will NEVER become problems * Problem Management – find the root cause to prevent faults from happening again, to improve overall quality and free up resources needed to deal with repeated incidents

Incident Management Process * An incident is defined as an unplanned interruption to an IT service, a reduction in the quality of an IT service, or a failure of a CI (configuration item) that has not yet impacted an IT service. * Incident Management is responsible for progressing all incidents from reporting to closing – usually the responsibility of service desk. * Purpose * to restore normal service operation (defined in SLA) as soon as possible and minimize impact to business operations * Objectives * ensure all incidents are responded (logged, managed, resolved and reported) efficiently with standard procedures according to business priority * improve customer satisfaction * Scope * handle all incidents (event which disrupts, or which could disrupt, a service), either by service desk reports or event management tool alerts * Concepts and definitions * Timescales – time is of essence, need to log the time and seek improvement * Incident Models – incident templates with the necessary steps to resolve commonincidents, allow faster resolution (stored in the SKMS) * Major Incidents – define what constitutes a major incident and follow pre-defined procedures, need to inform users on the progress * Incident Status – the current status of the incident * Open – identified and logged * Assigned – sent to a support team * Allocated or In Progress – a support technician has been allocated * On Hold – cannot contact the user * Resolved – completed the work but not confirmed by the customer or awaiting automatic closure * Closed – accepted by the user * Expanded Incident Lifecycle – used by the service design availability management process and within CSI, breaks down each step for closer examination to examine the impact of incidents * Impact – a measure of the effect of an incident, problem, or change on business processes. Impact is often based on how service levels will be affected. Impact and urgency are used to assign priority * Urgency – a measure of how long it will be until an incident, problem or change has a significant impact on the business * Priority – a category used to identify the relative importance of an incident, problem or change, based on impact and urgency. High priority (Priority 1) is given the an incident with high impact and high urgency. * Lifecycle of Incidents * Incident Identification – realize an incident before the user notices / reports with event management (a reactive process) * Incident Logging – log ALL incidents for service-level management reporting and problem management * unique reference number * incident category, impact, urgency and priority, symptoms, steps to resolution and known errors * time from logging to closure * how to identify * Incident Categorization – use a simple categorization for effective implementation * Incident Prioritization – consider business impact and urgency, to be completed in a pre-agreed time depending on the priority, may change during the lifecycle * Initial Diagnosis – the service desk to diagnose the fault and try to resolve it with the known error database (by problem management), incident models or other tools (incident matching) * Incident Escalation – the incidents are owned by service desk (need to track till closure) * functional escalation – service desk unable to solve the incident within a given time * hierarchic escalation – inform management of major incidents / incidents not progressing based on SLA target time * Investigation and Diagnosis – try to find out what has happened and how to resolve * Resolution and Recovery – test potential resolutions to ensure the incident has been solved without causing adverse consequences * Incident Closure – contact user to verify and review categorization, finish documentation. Closed incidents may be re-opened if the incident re-surfaces again. Any appropriate function can close the incident. * Interfaces with other stages * [Service Design] Service Level Management, Information Security Management, Capacity Management, Availability Management * [Service Transition] Change Management, Service Asset and Configuration Management – to identify impact of problems * [Service Operation] Problem Management, Access Management – security breaches / unauthorized access

Problem Management Process * A problem is defined as an underlying cause of one or more incidents. The cause is not usually known at the time a problem record is created, and the problem management process is responsible for further investigation. * A known error is a problem that has a documented root cause and a workaround. Known errors are created and managed throughout their lifecycle by problem management. Known errors may also be identified by development or suppliers. * A workaround is a way of reducing or eliminating the impact of an incident or problem for which a full resolution is not yet available, workarounds for known errors are documented in known error records. The problem will remain open in this case as the problem is fully resolved. * Problem Management is the process to investigates the root cause of incidents and implements a permanent solution / workaround to prevent them from happening again * Not visible to the users / business * Incidents will not become problems, they must be handled separately * Although incident and problem management are separate processes, they are closely related and will typically use the same tools, and may use similar categorization, impact and priority coding systems. This will ensure effective communication when dealing with related incidents and problems. * The time to resolve problem cannot be defined in SLA * Purpose * to document, investigate, and remove causes of incidents * to provide workarounds * Objectives * prevent problems from happening * eliminate recurring incidents * minimize impact of incidents that cannot be prevented * Scope * diagnosis the root cause of incidents * take steps to eliminate them (with other processes, in particular change management process) * document problems, workarounds and resolutions (maintain the known error database) for more effective handling of similar incidents * Output * Known errors (and entry to KEDB) * Workarounds * Resolutions (may include RFCs) * Concepts and definitions * Reactive and Proactive Activities – trigger by incidents reporting / analysis of incident trends * Problem Models – handle problems that have not and will not be resolved (e.g. the cost of a permanent resolution is too high) by some pre-defined workaround * Lifecycle of Problem Management * Detecting Problems – identify problems in reactive / proactive ways * Logging Problems – log in the problem record (link to the incidents) * Categorizing Problems – same categorization as incident management * Prioritizing Problems – depends on impact and urgency * Investigating and Diagnosing Problems – uses CMS and KEDB * [in some cases] Identifying a Workaround – provides the workaround to service desk for resolving the incident and reassesses the priority * Raising a Known Error Record – after the root causes has been identified and workaround/solution found for future reference * Problem Resolution – implement the solution through change management (as emergency change) * Problem Closure – a permanent solution has been tested and implemented so that the problem will not occur again (user confirmation NOT needed) * Major Problem Review – lessons learned for proactive problem detection * Interfaces with other stages * [Service Strategy] Financial Management for IT Services – to determine whether solution is financially justified * [Service Design] Availability Management, Capacity Management, IT Service Continuity Management, Service Level Management – problem management supplies the information for solving problems handled by these processes * [Service Transition] Change Management, Service Asset and Configuration Management – to identify impact of problems, Release and Deployment Management– implement the change, Knowledge Management – KEDB * [Continual Service Improvement] The Seven-Step Improvement Process – actions are entered into CSI register

Conclusion: ITIL® v3 Foundation Service Operation
This ITIL® v3 Foundation study note touches upon the definition, purpose, objectives and scope of two important processes of Service Operation, namely the Issue Management Process and the Problem Management Process. These two processes also work with processes in other stages of the service lifecycle to provide high quality IT services. Key ITIL® concepts are examined, including: incident, impact, urgency, priority, problem, workaround, known error, known error database (KEDB).
More processes of the Service Operation phase for the ITIL® v3 Foundation Certification exam are briefly examined here, including: Event Management Process, Request Fulfilment Process and Access Management Process. In addition, the definitions for Event, Alert and Service Request are provided.

Event Management Process * Modern systems make use of event monitoring tools to monitor configuration items for signals and irregularities * active monitoring tools – actively seek responses to confirm correctness (e.g. ping) * passive monitoring tools – detect events generated by CIs * [definition] An event can be defined as any change of state that has significance for the management of a configuration item (CI) or IT service or an alert/notification created by the IT service * the changes are not limited to failure or faults * alerts are events that are faults or breaches of thresholds * An exception can either be an incident, problem or RFC * Better to detect proactively than waiting users to report errors * Purpose * to detect events, understand what they mean, and take any necessary action (the basis on operational monitoring and control) * in case of failure, an incident would be logged * Objectives * detect events and carry out correct response (including automated processes or notification to staff I/C) * provide information for assessment against SLA target and service reporting (for improvement) * provide trigger for execution of processes and operations management * Scope * any aspects of service management that need to be controlled / automated * CIs are monitored for availability and automated updates * license use * monitor environmental conditions (e.g. smoke detection) * security * Monitoring vs Event Management * Monitoring – detect notifications from event management and check status actively * Event Management – generating and detecting events (for monitoring) for IT services and infrastructure

Request Fulfilment Process * The process for handling service requests for standard services, equipment, or information raised by users through the service desk * e.g. “Is the service available at weekends?”, “How do I get training on this application?”, “We have a new member of staff starting. Can you set them up on the system?” * [definition] A Service Request is a formal request from a user for something to be provided * Purpose * to manage the lifecycle of all service requests from the users * Objectives * provide efficient fulfilment of simple requests to meet the requirements of the business, often through standard procedures (request models) * maintain user satisfaction through effective handling of standard requests * Scope * any requests or just standard IT requests (vary from organization to organization) * some organizations may use incident management process to handle requests * may provide a self-help support capability to users to improve quality and reduce costs
Access Management Process * The process of granting authorized users the right to use a service while preventing access to unauthorized users * aka Rights Management or Identity Management * Purpose * to implement parts of the security policies defined in Information Security Management * to keep the access privileges up-to-date * Objectives * manage access rights to services * ensure all requests for access are verified and authorized and dealt with efficiently * Scope * efficient execution of information security management policies to protect the confidentiality, availability (made available) and integrity (CIA) of data and intellectual property * Steps * Request Access * Request Verification / Authorization * Grant Access * Monitor – identity status, logging and tracking access, removing or restricting rights * Concepts/Definition * Access refers to the level and extent of a service’s functionality or data that a user is entitled to use. * Identity refers to the information about the user that distinguishes them as an individual, and which verifies their status within the organization. By definition, the Identity of a user is unique to that user. * Rights (also called privileges) refer to the actual settings whereby a user is provided access to a service or group of services. Typical rights or levels of access include read, write, execute, change, delete. * Services or Service groups. Most users do not only use one service, and users performing a similar set of activities will use a similar set of services. Instead of providing access to each service for each user separately, it is more efficient to be able to grant each user – or group of users – access to the whole set of services that they are entitled to use at the same time. * Directory Services refers to a specific type of tool that is used to manage access and rights.

Conclusion: ITIL® v3 Foundation Service Operation
This ITIL® v3 Foundation study note touches upon the definition, purpose, objectives and scope of more processes of Service Operation, namely the Event Management Process, Request Fulfilment Process and Access Management Process. Key ITIL® concepts are examined, including: event, alert and service request.
Continual Service Improvement affects all stages of service management. It aims to improve the overall service in an organization in a continual manner. The Seven-Step Improvement Process is introduced as the major process for the Continual Service Improvement stage of the ITIL® service lifecycle.

Service Measurement * Measurements are critical to the success of continual improvement * all processes must be measurable in an objective way * role of measurements: * assessment of the current status * identification of improvement areas * assessment of the improvements made * types of measurements * availability * reliability * performance * Critical Success Factor (CSF) is something that must happen if an IT service, process, plan, process, or other activity is to succeed * no more than two to five CSFs per process for manageable results * Key Performance Indicators (KPI) are used to measure whether the critical success factors are achieved * no more than five KPIs, two to three KPIs in the early stage when maturity level is low * can be quantitative (e.g. cost) or qualitative (e.g. customer satisfaction) * check whether a KPI is fit for use – relevant, accurate and useful * Types of Metrics * a metric is a scale of measure that allows you to define what is to be measured * e.g. percentage reduction of unsuccessful changes, average cost of testing a change * Technology Metrics – associated with managing service components using monitoring systems, e.g. availability and performance * Process Metrics – captured in terms of the CSFs and KPIs, to assess quality, performance, value, and compliance of the process * Service Metrics – a measure of the end-to-end service performance, results from technology and process metrics

Purpose, Objectives and Scope of Continual Service Improvement * Continually searching for enhancement to improve the whole lifecycle, including CSI for cost saving and enhanced capability * a closed-loop feedback system, based on the Plan, Do, Check, Act (PDCA) model specified in ISO/IEC 20000, is established and capable of receiving inputs for change from any planning perspective

Purpose of Continual Service Improvement * to continue to support the business with IT services in response to changing business needs * including all processes, management, 3rd party suppliers * to seek ways to improve service effectiveness, process effectiveness and cost effectiveness

Objectives of Continual Service Improvement * ensure correct and ample measurements are collected from processes * recommend improvement opportunities by reviewing and analyzing measurements from processes * review service level achievements by comparing to SLA * improve the cost effectiveness and efficiency of IT service without affecting the quality

Scope of Continual Service Improvement * all aspects of the service lifecycle, from strategy through design, transition, and operation * overall health of IT service management * alignment of IT services to business development by measuring values of CSI and conducting customer satisfaction survey * maturity and capability of the organization and people by carrying out maturity assessments and compliance audit * continual improvement of all aspects

ITIL® Continual Service Improvement Approach 1. Identify the vision that drives the improvement initiative – alignment with business strategies 2. Objective assessment of the current state – baseline of business, people, process and technology * baseline is verified snapshot of the environment at a particular time * baseline is to be captured at regular intervals 1. Identify an achievable target – better in smaller steps 2. Identify actions to meet the target – process / technology improvement, staff training, etc. 3. Measure the achievements – review whether targets are met with measurements like maturity matrix 4. Keep on improving
Output of Continual Service Improvement * CSI Registry * record all individual improvements as improvements may be made concurrently * is a service asset managed by the service knowledge management system (SKMS) * includes: ID, Relative size, Timescale, Description, Priority, KPI metric and Justification * Improvement Program Documentation
Deming Cycle (PDCA Cycle) * proposed by W. Edwards Deming 1. Plan – planning the activity for improvement (define metrics and measurements) (for governance control) 2. Do – implementing a new project for improvement initiatives 3. Check – checking and reviewing results of the improvement through measurements 4. Act – implementing modifications / corrective actions to the actual process and to determine whether a new project is needed

Seven-Step Improvement Process * While these seven steps appear to form a circular set of activities, in fact, they constitute a knowledge spiral. * Purpose * to define and manage the steps required to implement improvements successfully * identify and define the measurements and metrics * gather, analyze and report the data * manage the implementation * Objectives * identify improvement opportunities in cost and quality with financial justification (a business case if more complex) * identify the measurements and metrics * continually review services to ensure they are aligned with business objectives * Scope * analyze performance and capabilities throughout the lifecycle (maturity) * make the best use of latest technology * improve organizational structures

Seven Steps (DIKW Model) 1. Identify the Strategy for Improvement (Wisdom) * Establish the overall vision for the business – how to best benefit the business? * all initiatives being considered are entered into CSI register 1. Define What You Will Measure (Data) * confirm a finalized improvement measurement plan with service strategy and service design * perform gap analysis to identify improvements 2. Gather the Data (Data) * monitor and capture exceptions, resolutions and trends with the data 3. Process the Data (Information) * process data into information (analysed in context) 4. Analyse the Information and Data (Knowledge) * understand the trend in data and the reasons behind * compare data to KPIs and targets 5. Present and Use the Information (Knowledge) * present in the correct format with the appropriate details according to audience types: * Customers – meet targets? * senior IT management – CSFs and KPIs * internal IT – KPIs to help planning improvements * suppliers – KPIs of their own services 6. Implement Improvement (Wisdom) * implement the improvement (including submitting a business base if required) * a new baseline is established after the improvement and the whole cycle begins anew

Conclusion: ITIL® v3 Foundation Continual Service Improvement
This ITIL® v3 Foundation study note touches upon the definition, purpose, objectives and scope of Continual Service Improvement. The Seven-Steps Improvement Process is introduced together with the Deming Cycle (Plan-Do-Check-Act), the DIKW model as well as measurement.

Revision
Listed here are the key concepts and facts for the ITIL® v3 Foundation Certification Exam. I used this as the last minute revision notes for my ITIL® Foundation exam just before the exam.
Service Management as a Practice * ITIL® is best practices guidance. ITIL® should be used with other best-practice approaches, e.g. standards, industry practices and proprietary knowledge to tailor for the particular needs of an organization. * Why ITIL® is successful: ITIL® is based on the approach of “adopt and adapt.” ITIL® is successful because it is no prescriptive, vendor-neutral best practices for service lifecycle. * Services groups: i) core (business-critical services); ii) enabling (support the core services); iii) enhancing (add value to the core). * Types of customers: i) internal customers (based in the same organization as the service provider); ii) external customers (outside of the organization of the service provider). * Service types: i) Type I (internal, within individual business units); ii) Type II (shared, providing services shared across a number of business units); iii) Type III (external, providing services to external customers). * Stakeholder types: i) customers (individuals or groups that buy goods or services); ii) users (use the services on a daily basis); iii) suppliers (external parties providing services that support / enable IT services). * Characteristics of processes: measureable, respond to a trigger, deliver a specific result and deliver to a customer or stakeholder * Definitions of the important terms: service, IT service, outcome, service management, IT service management and IT service provider. * Automation improves efficiency and effectiveness. Automation and the use of technology enable process enhancement and improvements. * Core stages of the service lifecycle: i) service strategy, ii) service design, iii) service transition, iv) service operation, v) continual service improvement. * ITIL® core publications are supplemented with complementary guidance. The complementary guidance can be specific to particular industries or provide context for adoption.
Service Strategy * Purpose, objectives and scope for the Service Strategy: purpose – provide the strategy for the service lifecycle; objectives – the definition of strategy and governance control; scope – define a strategy to meet the customer’s business objectives and to manage services. * Definition of utility and warranty: utility – ensures that the service is fit for purpose; warranty – ensures that the service is fit for use. Both are important to ensure delivery of value to customers. * Definition of resources and capabilities: resources – used in the delivery of a service (e.g. financial capital, human resources); capabilities – the organization’s ability to perform and achieve value (e.g. processes, tacit knowledge). * Role of governance: provides the structure and standardization for management of services * Role of risk management: ensures a repeatable and manageable process for dealing with risks (risk management is to identify, document, analyze and mitigate against the likelihood of risks to a project / service). * Patterns of business activity (PBA): important to understand the strategic and tactical approaches for the management of resources and capabilities efficiently and cost-effectively to realize organizational goals. * Service portfolio management process: ensures an appropriate mix of services being delivered and developed. * Components of service portfolio: i) service pipeline (services in the making); ii) service catalog (customer-facing view of the live operational services); iii) retired services (decommissioned services). * Financial management process: i) budgeting (plans IT services expenditure); ii) IT accounting (account for the expenditure on IT services); iii) charging (charges the customer for IT services). Financial management is central to understanding value for services. * Business case: a tool for decision making on whether an IT service is to be developed. * Business relationship management: connects customer and service provider at a strategic level. * Business relationship management vs service level management: business relationship management focuses on strategic relationship with the customer whereas service level management is operational.
Service Design * Purpose, objectives, and scope of service design: consider how the service will be run and managed when it is operational for both new and changed services. * Good service design is valuable to business: ensures services fulfil the business requirements of capacity, continuity, availability and security. Good design also ensures smooth transition to operation. * Key output – service design package * Four p’s – people, processes, products and partners * Five key aspects of service design – STAMP: i) Solution (fulfils the business requirement and enables the business process); ii) management information systems and Tools (ensure that the right information is available when required); iii) technical Architecture; iv) Measurements (ensure the service is functional as intended); v) new and changed Processes (that need to be developed, including both business processes and service management processes). * Purpose, objectives, and scope of service level management (SLM): SLM ensures that new and current IT services are (to be) delivered to agreed specific and measurable targets * Basic concepts of service level management: definition of service level requirements and the role of targets in assessing the level of service being delivered * Difference between service providers and suppliers. * SLM activities: definition and documentation of service level targets and negotiation with the business and with stakeholders to agree on targets that are both challenging and yet achievable. * Underpinning contracts and operational level agreements: to ensure that targets are achievable * SLAM report (RAG report): monitor, measure and review service level achievements * SLA structures: service-based, customer-based and multilevel SLAs * Service level management: builds a relationship with the business units by understanding their requirements and how it delivers a service that meets these requirements (note: service level manager and the business relationship manager build relationships with the business on different levels). SLM tracks customer satisfaction levels and takes action to improve them. * Interface between SLM and other process: e.g. business relationship management, incident and request management, supplier management and continual service improvement. * Service catalog: a database or structured document for all live IT services, including those available for deployment, forming one of the three service portfolio elements. Two types / views of services – customer-facing services and supporting services. * Service catalog service information: service details, status, interfaces, and dependencies and the way in which this information is used by other processes, such as service level management. * Availability: end-to-end availability, measurement of availability takes into account only agreed service time (excluding agreed downtime and out-of-hours availability). * Availability concepts: reliability (how long a service functions without interruptions); resilience (component failures without affecting service); maintainability (how quickly a service can restore); serviceability (how quickly a third party can response and fix the failure) * Information security policy: it is the responsibility of the information security manager to then ensure the required level of protection (as determined by business) is provided * Confidentiality (restricting access to data to authorized users), integrity (maintaining data free of any corruption or unauthorized change) and availability (able to be accessed when required) of data. * Supplier management: understand the link between underpinning contracts as part of service level management and the management of suppliers * Different categories of suppliers: strategic, tactical, operational and commodity * Capacity management: provides the current and future capacity and performance that the business requires, when it requires it, and at a cost it can afford. * IT service continuity management (ITSCM): responsible for providing an agreed level of service in the event of a major disruption to normal working conditions as part of business continuity management and prevent or reduce the impact of such an event. * Design coordination: provides a single point of coordination and control for all service design activities and processes, compiles the service design package and ensures quality and consistency across designs and conformance of designs to governance requirements. It also ensures the successful handoff of a service from strategy to design / transition. * Roles and responsibilities of service owner: accountable for ensuring the delivery of the service and liaise with process owners to ensure service standard * The roles and responsibilities of the process owner, the process manager and the process practitioner: i) process owner (only one) – accountable for ensuring the successful delivery of a process across all services and takes a lead role in ensuring that the process outcomes match the objectives; ii) process managers (can be several) – responsible for managing the day-to-day implementation of the process by the process practitioners; iii) process practitioner – responsible for carrying out the process tasks under the direction of the process manager(s). * Purpose of the RACI model (Responsible, Accountable, Consulted and Informed): define roles and responsibilities within processes, only one person can be accountable for each activity and every activity must have at least one responsible and one accountable person.
Service Transition * Purpose, objectives and scope of service transition: purpose – ensure new, modified or retired services meet the expectations of the business as agreed; objectives – to plan and successfully manage releases into production, ensuring good knowledge transfer and expectation setting for the delivery of the new or modified service; scope – includes planning, build, testing, evaluation, implementation and deployment of new or modified services into operation or the retirement of services. * Service transition provides value to the business: deliver changes that are planned, built, tested, evaluated, implemented and deployed according to expectation and specification * Purpose, objectives and scope of change management process: purpose – to provide controlled change; objectives – to manage changes in a controlled manner, manage risk and meet the needs of the business; scope – only IT changes * Change model: used to assist with management of the process by providing a set of predefined steps for commonly identified situations. * Standard change: follows a change model that responds to a predefined trigger and has low risks. * Emergency change: follows an adjusted process flow, assessment and authorization may include ECAB, testing may be reduced and documentation may be completed later on. * Normal change process flow steps and activities * All changes should be documented in an RFC, and this should be logged in a change record, which is captured as part of the CMS. * A change proposal is needed if the change has a major impact on business in terms of risk, cost, or resources. * Assessment of changes: include benefits, costs, risks, resources and relationships for the change. * Output of change process: change schedule (CS) and projected service outage (PSO) – used to communicate change timescales and impact with stakeholders. * Remediation plan: allows mitigation against potential failure and return to normal if a change fails. * Changes authorization: changes are authorized by the change authority with consideration of the size, risk, cost and business impact of the change. * Change management: responsible for the coordination of the deployment of the change; need to work with release and deployment management. * Once a change has been deployed, it would be reviewed. The change record is closed if it meets the acceptance criteria for success. * Change advisory board (CAB): responsible for assessing changes and making recommendation for authorization. * Purpose, objectives and scope of the transition planning and support process: ensures that all transitions are managed efficiently. * Purpose, objectives and scope of the service asset and configuration management process: ensures accurate and reliable information about the assets are captured. * Configuration management system: integrates information about the infrastructure and provide a comprehensive view of the configuration items (CI) and their relationships * Configuration model: provides a model of the services, assets, and infrastructure by capturing the details of each configuration item and their relationships; Configuration baseline: the state of the infrastructure at a specific point that is reviewed and agreed upon, to be used for trending, comparison and planning. Snapshot: capture of the infrastructure at a point in time. * Definitive media library: a specific secure area set aside for managing software media (including physical and electronic stores for master copies and documents) * Purpose, objectives and scope of knowledge management: ensures knowledge is available in the right place at the right time to enable informed decisions, reducing the need for knowledge rediscovery. * DIKW model: Data-Information-Knowledge-Wisdom is used to transition from data to information to knowledge to wisdom * Service knowledge management system: an overarching system for managing knowledge relating to service management by integrating all the existing data sources from service management processes * Purpose, objectives and scope of the release and deployment management process: ensures that releases are planned, scheduled and controlled for successful deployment of services into production. * Release policy: describes the manner in which releases will be carried out and provides definitions for release types * Four phases of the release and deployment management process: i) release and deployment planning, ii) release build and test, iii) deployment and iv) review and close.
Service Operation * Purpose of the service operation: to deliver the services that have been designed and transitioned as efficiently as possible. Escaped faults will be identified and resolved and service will be optimized and in line with the SLAs agreed previously. * Service operations ensure that the business benefits from the service as planned by delivering the services efficiently and within service targets. * Service operation functions: technical management, application management, IT operations management, and the service desk. * Technical and application management functions: provide resources to the other lifecycle stages and specify the operational tasks that service operation staff members should carry out. * Application development vs. application support * Operations management: operations control (e.g. console management) vs. facilities management (e.g. monitoring environmental conditions). * Service desk function: skills and attributes that service desk staff members should possess – business awareness, technical awareness, customer focus, etc. * Service desk structures: local, central, virtual, and follow the sun * Purpose and objectives of incident management: a reactive process to reduce downtime by resolving incidents quickly (to restore service but not to identify the cause). Definition of terms: major incidents, incident models, an incident, a problem and a service request. * Priority = business impact x urgency * Incident and problem models * Lifecycle of an incident and escalation types * Purpose, objectives and scope of problem management: a problem is the unknown, underlying cause of one or more incidents; problem management is to find the root cause of incidents and remove it to prevent recurrence * Workaround and a known error: some problems might not resolved if it is not cost-effective to implement the fix (known error as stored in known error database ), workaround would be created to bypass the errors * Even vs. alert: events (a change of state that has significance for the management of a CI) and alerts (a failure or a breach of a threshold) * Role of event management in automation: passive and active monitoring to reduce downtime * Purpose objectives and scope of access management: not just granting access but also restricting or removing it as required.
Continual Service Improvement * Purpose, objectives, and scope of Continual Service Improvement: to ensure IT services are in line with business needs and not simply to meet service targets, to be carried out on a regular basis for all service areas. * Steps of the CSI and Deming cycle: CSI – identify the approach taken to manage a service improvement initiative and ensure it to meet the objectives of the business. Deming Cycle – Plan, Do, Check, and Act. * Purpose of the CSI register: to track and manage improvement initiatives taken by the IT service provider, maintained by the CSI manager. * Types of measures: critical success factors and key performance indicators * Three types of metrics: technical, process, and service: interact to provide a complete measurement of the service * Baselines: function as a comparison basis to verify improvement. * Seven-step improvement process: used to manage gathering, analysis and presentation of data. * Relationship between seven-step improvement process and the DIKW knowledge model / Deming cycle.