Chapter 6 - ITIL management practices

Technical management practices

Deployment management Infrastructure and platform management Software development management

Error control

Error control activities manage known errors—problems in which initial analysis has been completed. This usually means that faulty components have been identified. Error control also includes identification of potential permanent solutions that might result in a change request for implementation of a solution, but only if this can be justified in terms of cost, risks, and benefits.

ITSM today: High-velocity service delivery

High-velocity service delivery influences all the practices of a service provider, including general management practices, service management practices, and technical management practices. The high-velocity service delivery paradigm includes: ●Focus on fast delivery of new and changed IT services to users ●Continual analysis of feedback provided for IT services at every stage of their life cycle ●Agility in processing the feedback, giving rise to continual and fast improvement of IT services ●An end-to-end approach to the service life cycle, from ideation, through creation and delivery, to consumption of services ●Integration of product and service management practices ●Digitization of IT infrastructure and adoption of cloud computing ●Extensive automation of the service delivery chain

Problem management involves three distinct phases

Identifying problems Problem control Error control

Who resolves incidents?

Incidents may be diagnosed and resolved by people in many different groups, depending on the complexity of the issue or the incident type. ●Some incidents will be resolved by the users themselves. Use of specific self-help records should be captured for use in measurement and improvement activities. ●Some incidents will be resolved by the service desk. ●More complex incidents will usually be escalated to a support team for resolution. Typically, the routing is based on the incident category, which should help to identify the correct team. ●Incidents can be escalated to suppliers or partners, who offer support for their products and services. The most complex incidents—and all major incidents—often require a temporary team to work together to identify the resolution. This team may include representatives of many stakeholders, including the service provider, suppliers, users, and others. ●In some extreme cases, disaster recovery plans may be invoked to resolve an incident. Disaster recovery is described as part of the service continuity management practice.

Information security management Activities

Information security management interacts with every other practice. Information security is critically dependent on the behavior of people throughout the organization. Many processes and procedures are required to support information security management, including: ●An information security incident management process. ●A risk management process. ●A control review and audit process. ●An identity and access management process. ●Event management. ●Procedures for penetration testing, vulnerability scanning, etc. ●Procedures for managing information security-related changes, such as firewall configuration changes.

Customer views on availability

Many organizations calculate percentage availability based on MTBF and MTRS, but these percentage figures rarely match customers' experience and are not appropriate for most services. ●Other factors that should be considered include: Which vital business functions are affected by different application failures ●The point at which performance becomes so slow that the service is effectively rendered unusable ●When must the service be available, and when can the service provider carry out maintenance activities?

mean time between failures (MTBF)

Measures how frequently the service fails. For example, a service with an MTBF of four weeks fails, on average, 13 times each year.

mean time to restore service (MTRS)

Measures how quickly service is restored after a failure. For example, a service with an MTRS of four hours will, on average, fully recover from failure in four hours. This does not mean that service will always be restored in four hours, as MTRS is an average measure over many incidents.

Big bang deployment:

New/changed components are deployed to all targets at the same time. This approach is sometimes necessary when dependencies prevent simultaneous use of both old and new components (e.g. there could be a database schema change that's not compatible with previous versions of some components).

Activities Capacity and performance management

*Service performance and capacity analysis* ●Research and monitoring of the current service performance ●Capacity and performance modeling *Service performance and capacity planning* ●Capacity requirements analysis ●Demand forecasting and resource planning ●Performance improvement planning

Three types of change

Standard changes: Normal changes: Emergency changes:

Activities of Monitoring and event management

●Identifying what services, systems, CIS, or other service components should be monitored, and establishing the monitoring strategy ●Implementing and maintaining monitoring, leveraging both the native monitoring features of the elements being observed, as well as use of designed-for-purpose monitoring tools ●Establishing and maintaining thresholds and other criteria for determining which changes of state is to be treated as events, and choosing criteria to define each type of event (informational, warning, or exception) ●Establishing and maintaining policies for how each type of detected event should be handled to ensure proper management Implementing processes and automations required to operationalize the defined thresholds, criteria, and policies ●In active monitoring, tools will poll key CIs, looking at their status to generate alerts when an exception condition is identified. ●In passive monitoring, the CI itself generates operational alerts.

Problems are different than incidents

●Incidents: Have an impact on users or business processes, and must be resolved so that the service can be restored and normal business activity can take place. ●Problems: The causes of incidents. Problems require investigation and analysis to identify the causes, develop workarounds, and recommend longer-term resolution. This serves to reduce the number and impact of future incidents.

Planning and designing the incident management process

●Low-impact incidents must be managed efficiently to ensure that they do not consume too many resources. ●Higher-impact incidents might require more resources and more complex management. There are usually separate processes for managing major incidents, and for managing information security incidents.

Availability management activities include:

●Negotiating and agreeing on achievable targets for availability ●Designing infrastructure and applications that can deliver required availability levels ●Ensuring that services and components are able to collect the data required to measure availability ●Monitoring, analyzing, and reporting on availability Planning improvements to availability

Change control vs. organizational change management

●Organizational change management manages the people aspects of change to ensure that improvements and organizational transformation initiatives are implemented successfully. ●Change control is usually focused on changes in products and services.

Problem management

●Reduce the likelihood and impact of incidents by identifying actual and potential causes of incidents ●Manage workarounds and known errors

Some of the key requirements for successful SLAs are:

●They must be related to a defined "service" in the service catalogue. Otherwise, they're merely individual metrics with no real purpose, and don't provide adequate visibility or reflect the service perspective. ●They should relate to defined outcomes, rather than mere operational metrics. This can be achieved through balanced bundles of metrics, such as customer satisfaction and key business outcomes. ●They should reflect an agreement—engagement and discussion between the service provider and the service consumer. It's important to involve all stakeholders, including partners, sponsors, users, and customers. ●They must be simply written and easy to understand and use for all parties

Service configuration management

A configuration item (CI) is any component that must be managed in order to deliver an IT service. The purpose of the service configuration management practice is to: ●Ensure that accurate and reliable information about the configuration of services—and the CIs that support them—is available when and where it's needed. ●This includes information on how CIs are configured and the relationship between them.

Business impact analysis (BIA):

A key activity in the practice of service continuity management that identifies vital business functions (VBFs) and their dependencies. These dependencies might include suppliers, people, other business processes, and IT services. BIA defines the recovery requirements for IT services, which include RTOs, RPOs, and minimum target service levels for each IT service.

Service-level agreements

A service-level agreement (SLA) is a documented agreement between a service provider and a customer that identifies both services required and the expected level of service. SLAs have long been used as a tool to measure the performance of services from a customer's point of view, and it's important that they are agreed upon in the wider business context. Using SLAs can present many challenges; often they don't fully reflect the wider service performance or the user experience.

Disaster recovery plans:

A set of clearly defined plans related to how an organization recovers from a disaster and returns to its pre-disaster condition, in consideration of the four dimensions of service management.

A successful sourcing strategy requires:

A thorough understanding of an organization's objectives ●The resources required to deliver that strategy. ●The environmental (e.g. market) factors. ●The risks associated with implementing specific approaches.

Finding workarounds

A workaround is a solution that reduces or eliminates the impact of an incident or problem for which a full resolution is not yet available. Some workarounds reduce the likelihood of incidents occurring. Every documented workaround should include a clear definition of the symptoms to which it applies. In some cases, application of a workaround can even be automated.

Identifying problems

Also known as Problem Identification Problem identification activities identify and log problems, including: ●Performing trend analysis of incident records ●Detection of duplicate and recurring issues by users, service desk, and technical support staff ●During major incident management, identifying a risk that an incident could recur ●Analyzing information received from suppliers and partners ●Analyzing information received from internal software developers, test teams, and project teams It's worth noting that other sources of information can also lead to problems being identified.

Asset

An asset is any financially valuable component that can contribute to the delivery of an IT product or service.

Incident management

An incident is an unplanned interruption to a service or reduction in the quality of a service. The purpose of the incident management practice is to minimize the negative impact of incidents by restoring normal service operation as quickly as possible. Incident management can have an enormous impact on customer and end-user satisfaction, and on how customers and users perceive the service provider.

General management practices

Architecture management Continual improvement Information security management Knowledge management Measurement and reporting Organizational change management Portfolio management Project management Relationship management Risk management Service financial management Strategy management Supplier management Workforce and talent management

Availability management

Availability is the ability of an IT service or other configuration item to perform its agreed function when required. The purpose of the availability management practice is to ensure that services deliver agreed levels of availability to meet the needs of customers and users.

Service management practices

Availability management Business analysis Capacity and performance management Change control Incident management IT asset management Monitoring and event management Problem management Release management Service catalogue management Service configuration management Service continuity management Service design Service desk Service-level management Service request management Service validation and testing

The role of release management in deployment

Communication regarding deployments is a function of release management.

Continuous delivery:

Components are integrated, tested, and deployed when they're needed. This provides frequent opportunities for customer feedback loops.

Embedding continual improvement

Continual improvement is the responsibility of everyone in the organization. It's critical that everyone understands that active participation in continual improvement activities is a core part of their job. Those people in the highest levels of the organization must take responsibility for embedding continual improvement into the way that people think and work. When third-party suppliers serve as part of the service landscape, they should also be part of the improvement effort. The contract for a supplier's service should include details of how they will measure, report on, and improve their services over the life of the contract.

Pull deployment:

New/changed software is made available in a controlled repository. Users choose when to download the software to client devices. This allows users to control the timing of updates. This can be integrated with service request management to enable users to request software only when it's needed.

Approaches used for deployment

Phased deployment: Continuous delivery: Big bang deployment: Pull deployment:

Problem control

Problem control activities include problem analysis, and documenting workarounds and known errors. Problems are prioritized for analysis according to the risk they pose and are managed as risks according to their potential impact and probability It's not essential to analyze every problem; it's far more valuable to make significant progress on the highest-priority problems than to investigate every minor problem the organization is aware of. it's important to analyze problems from the perspective of all four dimensions of service management.

Service continuity management versus incident management

Service continuity management focuses on those events that are considered by the business to qualify as a disaster. Less significant events are dealt with as part of incident management or major incident management. The distinction between disasters, major incidents, and incidents needs to be predefined, agreed upon, and documented with clear thresholds and triggers for activating the next response-and-recovery tier without resulting in unnecessary delay and risk.

swarming

Swarming is the act of many different stakeholders working together initially, until it becomes clear which of them is best placed to continue, and which can move on to other tasks.

About ITIL management practices

The ITIL SVS includes 14 general management practices, 17 service management practices, and three technical management practices, all of which are subject to the four dimensions of service management In ITIL, a management practice is a set of organizational resources designed for performing work or accomplishing an objective.

The change schedule

The change schedule is used to help plan changes, assist in communication, avoid conflicts, and assign resources It can also be used after changes have been deployed to provide the information needed for incident management, problem management, and improvement planning.

Continual improvement in the SVC

The continual improvement practice is involved in all service value chain activities: ●*Plan: *The continual improvement practice is applied to planning activities, methods, and techniques to ensure they are relevant to the organization's current objectives and context. ●*Improve: *The continual improvement practice is key to this value chain activity. It structures resources and activities, enabling improvement at all levels of the organization and the SVS. ●*Engage, design and transition, obtain/build, and deliver and support: *Each of these value chain activities is subject to continual improvement, and the continual improvement practice is applied to all of them.

Recovery time objective (RTO):

The maximum acceptable and allowable period of time following a service disruption before lack of business functionality severely impacts an organization. This is the maximum agreed-upon time within which a product or activity must be resumed, or resources must be recovered.

Phased deployment:

The new/changed components are deployed to just part of the production environment at a time (e.g. to users in one office or one country). This operation is repeated as often as necessary until the deployment is complete.

Recovery point objective (RPO):

The point to which information used by an activity must be restored to enable the activity to operate upon resumption.

IT asset management

The purpose of the IT asset management practice is to plan and manage the full life cycle of all IT assets, to help the organization: ●Maximize value for stakeholders ●Control costs ●Manage risks ●Support decision making about purchases, reuse, retirement, and disposal of assets ●Meet regulatory and contractual requirements The scope of IT asset management typically includes all software, hardware, networking, cloud services, and client devices. In some cases, it may also include non-IT assets, such as buildings or information, where these have a financial value and are required to deliver an IT service. IT asset management can include operational technology (OT), including devices that are part of the Internet of Things (IoT). These are typically devices that were not traditionally thought of as IT assets, but that now include embedded computing capability and network connectivity.

Capacity and performance management

The purpose of the capacity and performance management practice is to ensure that services achieve agreed and expected performance, satisfying current and future demand in a cost-effective way. The capacity and performance management practice usually deals with the service performance and the performance of the supporting resources on which it depends, such as infrastructure, applications, and third-party services. In many organizations, capacity and performance management also covers the capacity and performance of the personnel.

Change control

The purpose of the change control practice is to maximize the number of successful service and product changes by ensuring that risks are properly assessed, authorizing changes to proceed, and managing the change schedule.

general management practices - Continual improvement

The purpose of the continual improvement practice is to align the organization's practices and services with changing business needs through the ongoing improvement of products, services, and practices, or any element involved in the management of products and services.

Deployment management

The purpose of the deployment management practice is to: ●Move new/changed hardware, software, documentation, processes, or any other component to live environments. ●It may also be involved in deploying components to other environments for testing or staging.

The origins of the practices are as follows:

●*General management practices: *Practices adopted and adapted for service management from general business management domains. ●*Service management practices: *Practices developed in service management and ITSM industries. ●*Technical management practices: *Practices adapted from technology management domains for service management purposes by expanding or shifting their focus from technology solutions to IT services

Information security management

The purpose of the information security management practice is to protect the information needed by the organization to conduct its business. This includes: ●Understanding and managing risks to the confidentiality, integrity, and availability of information ●Understanding other aspects of information security, such as authentication (ensuring someone is who they claim to be) and non-repudiation (ensuring that someone can't deny that they took an action) The required security is established by means of policies, processes, behaviors, risk management, and controls, which must maintain a balance between: ●*Prevention: *Ensuring that security incidents don't occur. ●*Detection: *Rapidly and reliably detecting incidents that can't be prevented. ●*Correction: *Recovering from incidents after they are detected.

Monitoring and event management

The purpose of the monitoring and event management practice is to: ●Systematically observe services and service components ●Record and report selected changes of state identified as events ●Identify and prioritize infrastructure, services, business processes, and information security events ●Establish the appropriate response to those events, including to conditions that could lead to potential faults or incidents The monitoring and event management practice manages events throughout their life cycle to prevent, minimize, or eliminate their negative impact on the business. ●The monitoring part of the practice focuses on the systematic observation of services and the CIs that underpin services to detect conditions of potential significance. Monitoring should be performed in a highly automated manner, and can be done actively or passively. ●The event management part focuses on recording and managing those monitored changes of state defined by the organization as an event, determining their significance, and identifying and initiating the correct control action to manage them. Frequently, the correct control action will be to initiate another practice, but sometimes it will be to take no action at all, other than to continue monitoring the situation. Monitoring is necessary for event management to take place, but not all monitoring results in the detection of an event.

Release management

The purpose of the release management practice is to make new and changed services and features available for use. Release management is often staged, with pilot releases being made available to a small number of users to ensure everything is working correctly before the release is given to additional groups.

Service continuity management

The purpose of the service continuity management practice is to ensure that the availability and performance of a service are maintained at sufficient levels in case of disaster. The practice provides a framework for building organizational resilience with the capability of producing an effective response that safeguards the interests of key stakeholders and the organization's reputation, brand, and value-creating activities. Service continuity management supports business continuity management (BCM) and planning capability by: ●Ensuring that IT and services can be resumed within required and agreed-upon business timescales following a disaster or crisis. ●It's triggered when a service disruption or organizational risk occurs on a scale greater than the organization's ability to handle it with normal response and recovery practices (e.g. incident management and major incident management).

Service desk

The purpose of the service desk practice is to capture demand for incident resolution and service requests. It should also be the entry point and single point of contact for the service provider with all of its users. Service desks provide a clear path for users to report issues, queries, and requests, and have them acknowledged, classified, owned, and actioned.

Service request management

The purpose of the service request management practice is to support the agreed quality of a service by handling all predefined, user-initiated service requests in an effective and user-friendly manner. Each service request may include one or more of the following: ●Request for a service delivery action (e.g. providing a report, replacing a toner cartridge) ●Request for information (e.g. how to create a document, what the office hours are) ●Request for provision of a resource or service (e.g. providing a phone or laptop to a user, providing a virtual server for a development team) ●Request for access to a resource or service (e.g. providing access to a file or folder) ●Feedback, compliments, and complaints (e.g. complaints about a new interface, compliments to a support team)

Service-level management

The purpose of the service-level management practice is to set clear business-based targets for service levels, and to ensure that delivery of services is properly assessed, monitored, and managed against these targets. Service-level management provides end-to-end visibility of the organization's services, which is achieved by: ●Establishing a shared view of the services and target service levels with customers ●Ensuring that the organization meets the defined service levels through the collection, analysis, storage, and reporting of the relevant metrics for the identified services ●Performing service reviews that ensure the current set of services continues to meet the needs of the organization and its customers ●Capturing and reporting on service issues, including performance against defined service levels The skills and competencies required for service-level management include: ●Relationship management ●Business liaison ●Business analysis ●Commercial/supplier management

Supplier management

The purpose of the supplier management practice is to: ●Ensure that the organization's suppliers and their performances are managed appropriately to support the seamless provision of quality products and services. ●This includes creating closer, more collaborative relationships with key suppliers to uncover and realize new value and reduce the risk of failure. Activities that are central to the practice include: ●Creating a single point of visibility and control to ensure consistency: This should include all products, services, service components, and procedures provided or operated by internal and external suppliers, including customers acting as suppliers. ●Maintaining a supplier strategy, policy, and contract management information. ●Negotiating and agreeing contracts and arrangements: Agreements should be aligned with business needs and service targets. Contracts with external suppliers might require negotiation or agreement through the legal, procurement, commercial, or contracts functions of the organization. For an internal supplier, there should be an internal agreement. ●Managing relationships and contracts with internal and external suppliers: This should be done when planning, designing, building, orchestrating, transitioning, and operating products and services, through working closely with procurement and performance management. ●Managing supplier performance: Supplier performance should be monitored to ensure that the terms, conditions, and targets of their contracts and agreements are met while aiming to increase the value for money obtained from suppliers and the products/services they provide.

Relationship management

The relationship management practice should apply to all relevant parties. This means that the practice should contribute to all service value-chain activities and multiple value streams. The purpose of the relationship management practice is to: ●Establish and nurture the links between the organization and its stakeholders at strategic and tactical levels. ●This includes the identification, analysis, monitoring, and continual improvement of relationships with and between stakeholders. The relationship management practice ensures that: ●Stakeholders' needs and drivers are understood, and products and services are prioritized appropriately. ●Stakeholders' satisfaction is high, and a constructive relationship between the organization and stakeholders is established and maintained. ●Customers' priorities for new or changed products and services, in alignment with desired business outcomes, are effectively established and articulated. ●Any stakeholders' complaints and escalations are handled well through a sympathetic, yet formal, process. ●Products and services facilitate value creation for service consumers as well as for the organization. ●The organization facilitates value creation for all stakeholders, in line with its strategy and priorities. ●Conflicting stakeholder requirements are mediated appropriately.

Sourcing, supplier strategy, and relationships

The supplier strategy, sometimes called the sourcing strategy, defines the organization's plan for how it will leverage the contribution of suppliers in the achievement of its overall service management strategy.

Methods, models, and techniques

There are many techniques that can be employed to assess the current state, such as strength, weakness, opportunity, and threat (SWOT) analysis, a balanced scorecard review, internal and external assessments and audits, or even a combination of techniques.

Emergency changes:

These are changes that must be implemented as soon as possible (e.g. to resolve an incident or implement a security patch). Emergency changes are not typically included in a change schedule, and the process for assessment and authorization is expedited to ensure they can be implemented quickly. As much as possible, emergency changes should be subject to the same testing, assessment, and authorization as normal changes, but it may be acceptable to defer some documentation until after the change has been implemented. Sometimes, it will be necessary to implement the change after less testing because of time constraints. There could also be a separate change authority for emergency changes, typically including a small number of senior managers who understand the business risks involved.

Normal changes:

These are changes that must be scheduled, assessed, and authorized following a process. Change models based on change type determine the roles for assessment and authorization. Some normal changes are of low risk; the change authority for these is usually someone who can make rapid decisions, which is often accomplished using automation. Other normal changes are very major, and the change authority could be as high as the management board (or equivalent). Initiation of a normal change is triggered by the creation of a change request. This can be created manually, but organizations that have an automated pipeline for continuous integration and continuous deployment often automate most steps of the change control process.

Standard changes:

These are low-risk, preauthorized changes that are well understood and fully documented, and can be implemented without needing additional authorization. They're often initiated as service requests but may also be operational changes. When the procedure for a standard change is created or modified, there should be a full risk assessment and authorization, as for any other change. This risk assessment does not have to be repeated each time the standard change is implemented unless there's a modification to the way it's carried out.

Continual improvement register (CIR)

To track and manage improvement ideas from identification through to final action, organizations use a database or structured document called a continual improvement register (CIR). There can be more than one CIR in an organization, as CIRs can be maintained on individual, team, departmental, business unit, and organizational levels. It doesn't matter exactly how the information in a CIR is structured, or what the collections of improvement ideas are called. What's important is that improvement ideas are captured, documented, assessed, prioritized, and appropriately acted upon to ensure that the organization and its services are always being improved.

event

any change of state that has significance for the management of a service or other CI. Events are typically recognized through notifications created by an IT service, CI, or monitoring tool.

problem

defined as a cause—or potential cause—of one or more incidents. A known error is a problem that's been analyzed but not resolved.

release

defined as a version of a service or other CI—or a collection of CIs—that's made available for use.

service level

defined as one or more metrics that define expected or achieved service quality.

Performance

is a measure of what is achieved or delivered by a system, person, team, practice, or service.

service request

is a request from a user (or their authorized representative) that initiates a service action that has been agreed on as a normal part of service delivery.

A practice

is a set of organizational resources designed for performing work or accomplishing an objective. These resources are grouped into the four dimensions of service management

Change

is defined as the addition, modification, or removal of anything that could have a direct or indirect effect on services.

service capacity,

is defined as the maximum throughput that a configuration item (CI) or service can deliver.

Service performance

is usually associated with the number of service actions performed in a time frame, and the time required to fulfill a service action at a given level of demand. Service performance depends on service capacity,

Release schedule

release schedule is used to document the timing of releases. It should be negotiated and agreed upon with customers and other stakeholders. Staging of a release is often achieved using what are called "blue/green releases" or "feature flags."

Activities of Incident management

●*Improve: *Incident records are a key input to improvement activities, and are prioritized in terms of both incident frequency and severity. ●*Engage: *Incidents are visible to users, and significant incidents are also visible to customers. Good incident management requires regular communication to understand the issues, set expectations, provide status updates, and agree that the issue has been resolved so that the incident can be closed. ●*Design and transition: *Incidents may occur in test environments, as well as during service release and deployment. The practice ensures that these incidents are resolved in a timely and controlled manner. ●*Obtain/build: *Incidents may occur in development environments. Incident management ensures that these incidents are resolved in a timely and controlled manner. ●*Deliver and support: *Incident management makes a significant contribution to support. This value chain activity includes resolving incidents and problems.

Events Classification

●*Informational events: *Do not require action at the time they're identified, but analyzing the data gathered from them at a later date may uncover desirable, proactive steps that can be beneficial to the service. ●*Warning events: *Allow action to be taken before any negative impact is actually experienced by the business, whereas exception events indicate that a breach to an established norm has been identified (for example, to a service level agreement). ●*Exception events: *Require action, even though business impact may not have been experienced.

different types of supplier relationships between an organization and its suppliers

●*Insourcing: *The products/services are developed and/or delivered internally by the organization. ●*Outsourcing: *The process of having external suppliers provide products and services that were previously provided internally. Outsourcing involves substitution—the replacement of internal capability by that of the supplier. ●*Single source or partnership: *Procurement of a product or service from one supplier. This can be either a single supplier who supplies all services directly or an external service integrator who manages the relationships with all suppliers and integrates their services on behalf of the organization. These close relationships (and the mutual interdependence they create) foster high quality, reliability, short lead times, and cooperative action. ●*Multisourcing: *Procurement of a product/service from more than one independent supplier. These products/services can be combined to form new ones the organization can provide to internal and external customers. As organizations place more focus on increased specialization and compartmentalization of capabilities to increase agility, multisourcing is increasingly a preferred option. Traditionally, organizations managed these suppliers separately across different parts of the organization, but there is now a move toward developing an internal service integration capability or selecting an external service integrator.

Activities of Change control

●*Plan: *Changes to product and service portfolios, policies, and practices all require a certain level of control. The change control practice is used to provide this. ●*Improve: *Many improvements require changes to be made. These should be assessed and authorized similarly to all other changes. ●*Engage: *Customers and users might need to be consulted or informed about nature of the changes being handled. ●*Design and transition: *Many changes are initiated as a result of new or changed services. Change control activity is a major contributor to transition. ●*Obtain/build: *Changes to components are subject to change control, whether they're built in house or obtained from suppliers. ●*Deliver and support: *Changes can have an impact on delivery and support. Information about changes must be communicated to personnel who carry out this value chain activity. They may also play a part in assessing and authorizing changes.

Business-oriented measurements

●*User outage minutes: *Calculated by multiplying incident duration by the number of users impacted, or by adding up the number of minutes each user is affected. This works well for services that directly support user productivity (e.g. email service). ●*Number of lost transactions:*Calculated by subtracting the number of transactions from the number expected to have happened during the time period. This works well for services that support transaction-based business processes (e.g. manufacturing support). ●*Lost business value: *Calculated by measuring how business productivity was impacted by the failures of supporting services. This is easily understood by customers and can be useful for planning investment in improved availability. However, it can be difficult to identify which lost business value was caused by IT service failures and which resulted from other causes. ●*User satisfaction: *Service availability is one of the most important and visible characteristics of services and has a great influence on user satisfaction. It's important to ensure that users are satisfied with service availability in addition to meeting formally agreed availability targets.

For example, an organization aiming to deliver and improve its services faster than others should consider:

●Agile project management ●Agile financial management ●Product-based organizational structure ●Adaptive risk management, and audit and compliance management ●Flexible architecture management ●Specific architecture technology solutions, such as micro-services ●Complex partner and supplier environments ●Continual monitoring of technology innovations and experimenting ●Human-centered design ●Infrastructure management focused on cloud computing

Key activities of continual improvement

●Encouraging continual improvement across the organization. ●Securing time and budget for continual improvement ●Identifying and logging improvement opportunities. ●Assessing and prioritizing improvement opportunities. ●Making business cases for improvement action. ●Planning and implementing improvements. ●Measuring and evaluating improvement results. ●Coordinating improvement activities across the organization.

three important points for Incident management

●Every incident should be logged and managed to ensure that it's resolved in a time frame that meets the expectations of the customer and user. ●Target resolution times should be agreed upon, documented, and communicated to ensure that expectations are realistic. ●Incidents should be prioritized according to an agreed-upon classification to ensure that incidents with the highest business impact are resolved first.