"> ITIL4 – Page 2 – Process-Symphony – ITSM Knowledge Orchestrators

Search Knowledge

Tag: ITIL4

Service Continuity Management (ITIL 4)

Parent Process Reference Framework: ITIL 4

Service Value Stream Activities

There are NO highly impacted Service Value System(SVS) Activities for Service Continuity Management.

The medium impacted activities are:

  • Plan
  • Obtain/build
  • Design and Transition
  • Deliver and support 

Description

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 a 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 an overall business continuity management (BCM) and planning capability by ensuring that IT and services can be resumed within required and agreed business timescales following a disaster or crisis. It is triggered when a service disruption or organizational risk occurs on a scale that is greater than the organization’s ability to handle it with normal response and recovery practices such as incident and major incident management. An organizational event of this magnitude is typically referred to as a disaster.

Service configuration management (ITIL 4)

Parent Process Reference Framework: ITIL 4

Service Value Stream Activities

Highly impacted Service Value System(SVS) Activities:

  • Obtain/build
  • Design and Transition

Description

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 is needed. This includes information on how CIs are configured and the relationships between them.

Configuration item: Any component that needs to be managed in order to deliver an IT service

Configuration management provides information on the CIs that contribute to each service and their relationships: how they interact, relate, and depend on each other to create value for customers and users. This includes information about dependencies between services. This high-level view is often called a service map or service model, and forms part of the service architecture.

It is important that the effort needed to collect and maintain configuration information is balanced with the value that the information creates. Maintaining large amounts of detailed information about every component, and its relationships to other components, can be costly, and may deliver very little value. The requirements for configuration management must be based on an understanding of the organization’s goals, and how configuration management contributes to value creation.

The value created by configuration management is indirect, but enables many other practices to work efficiently and effectively. As such, planning for configuration management should start by understanding who needs the configuration information, how it will be used, what is the best way for them to obtain it, and who can maintain and update this information. Sometimes it can be more efficient to simply collect the information when it is needed, rather than to have it collected in advance and maintained, but on other occasions it is essential to have information available in a configuration management system (CMS). The type and amount of information recorded for each type of CI should be based on the value of that information, the cost of maintaining it, and how the information will be used.

Configuration information should be shared in a controlled way. Some information could be sensitive; for example, it could be useful to someone trying to breach security controls, or it could include personal information about users, such as phone numbers and home addresses.

Configuration information can be stored and published in a single configuration management database (CMDB) for the whole organization, but it is more common for it to be distributed across several sources. In either case it is important to maintain links between configuration records, so that people can see the full set of information they need, and how the various CIs work together. Some organizations federate CMDBs to provide an integrated view. Others may maintain different types of data; for example, having separate data stores for asset management data (see section 5.2.6), configuration details, service catalogue information, and high-level service models.

Tools that are used to log incidents, problems, and changes need access to configuration records. For example, an organization trying to identify problems with a service may need to find incidents related to a specific software version, or model of disk drive. The understanding of the need for this information helps to establish what CI attributes should be stored for this organization; in this case software versions and disk drive models. To diagnose incidents, visibility of recent changes to the affected CIs may be needed, so relationships between CIs and changes must be maintained.

Many organizations use data collection tools to gather detailed configuration information from infrastructure and applications, and use this to populate a CMS. This can be effective, but can also encourage the collection of too much data without sufficient information on relationships, and how the components work together to create a service. Sometimes configuration information is used to actually create the CI, rather than just to document it. This approach is used for ‘infrastructure as a code’, where information on the infrastructure is managed in a data repository and used to automatically configure the environment.

A large organization may have a team that is dedicated to configuration management. In other organizations this practice can be combined with change control, or there can be a team responsible for change, configuration, and release management. Some organizations apply a distributed model where functional teams take ownership of updating and maintaining the CIs within their control and oversight.

Configuration management typically needs processes to:

  • identify new CIs, and add them to the CMS
  • update configuration data when changes are deployed
  • verify that configuration records are correct
  • audit applications and infrastructure to identify any that are not documented.

Service catalogue management (ITIL 4)

Parent Process Reference Framework: ITIL 4

Service Value Stream Activities

Highly impacted Service Value System(SVS) Activities:

  • Engage 

Description

The purpose of the service catalogue management practice is to provide a single source of consistent information on all services and service offerings, and to ensure that it is available to the relevant audience.

The list of services within the service catalogue represents those which are currently available and is a subset of the total list of services tracked in the service provider’s service portfolio. Service catalogue management ensures that service and product descriptions are expressed clearly for the target audience to support stakeholder engagement and service delivery. The service catalogue may take many forms such as a document, online portal, or a tool that enables the current list of services to be communicated to the audience.

The full list of services within a service catalogue may not be applicable to all customers and/or users. Likewise, the various attributes of services such as technical specifications, offerings, agreements, and costs are not applicable to all service consumer types. This means that the service catalogue should be able to provide different views and levels of detail to different stakeholders. Examples of views include:

  • User views Provide information on service offerings that can be requested, and on provisioning details.
  • Customer views Provide service level, financial, and service performance data.
  • IT to IT customer views Provide technical, security, and process information for use in service delivery.

While multiple views of the service catalogue are possible, the creation of separate or isolated service catalogues within different technology systems should be avoided if possible as this will promote segregation, variability, and complexity.

For the service catalogue to be perceived as useful by the customer organization it must do more than provide a static platform for publishing information about IT services. Unless the service catalogue enables customer engagement by supporting discussions related to standard and non-standard service offerings and/or automates request and order fulfilment processes, the chances of its ongoing adoption as a useful and meaningful resource are minimal. For this reason, the views of many organizations on the service catalogue are focused on the consumable or orderable elements of service offerings. These are often called request catalogues.

Release Management (ITIL 4)

Parent Process Reference Framework: ITIL 4

Service Value Stream Activities

Highly impacted Service Value System(SVS) Activities:

  • Design and Transition

Description

The purpose of the release management practice is to make new and changed services and features available for use.

Release: A version of a service or other configuration item, or a collection of configuration items, that is made available for use.

A release may comprise many different infrastructure and application components that work together to deliver new or changed functionality. It may also include documentation, training (for users or IT staff), updated processes or tools, and any other components that are required. Each component of a release may be developed by the service provider or procured from a third party and integrated by the service provider.

Releases can range in size from the very small, involving just one minor changed feature, to the very large, involving many components that deliver a completely new service. In either case, a release plan will specify the exact combination of new and changed components to be made available, and the timing for their release.

A release schedule is used to document the timing for releases. This schedule should be negotiated and agreed with customers and other stakeholders. A release post-implementation review enables learning and improvement, and helps to ensure that customers are satisfied.

In some environments, almost all of the release management work takes place before deployment, with plans in place as to exactly which components will be deployed in a particular release. The deployment then makes the new functionality available.

In a DevOps environment, release management is often integrated with the continuous integration and continuous delivery toolchain. The tools of release management may be the responsibility of a dedicated person, but decisions about the release can be made by the development team. In a more traditional environment, releases are enabled by the deployment of the components. Each release is described by a release record on an ITSM tool. Release records are linked to CIs and change records to maintain information about the release.

Problem Management (ITIL 4)

Parent Process Reference Framework: ITIL 4

Service Value Stream Activities

Highly impacted Service Value System(SVS) Activities:

  • Deliver and Support
  • Improve 

Description

The purpose of the problem management practice is to reduce the likelihood and impact of incidents by identifying actual and potential causes of incidents, and managing workarounds and known errors.

  • Problem:  A cause, or potential cause, of one or more incidents.
  • Known error: A problem that has been analysed but has not been resolved.

Every service has errors, flaws, or vulnerabilities that may cause incidents. They may include errors in any of the four dimensions of service management. Many errors are identified and resolved before a service goes live. However, some remain unidentified or unresolved, and may be a risk to live services. In ITIL, these errors are called problems and they are addressed by the problem management practice.

Problems are related to incidents, but should be distinguished as they are managed in different ways:

  • Incidents have an impact on users or business processes, and must be resolved so that normal business activity can take place.
  • Problems are the causes of incidents. They require investigation and analysis to identify the causes, develop workarounds, and recommend longer-term resolution. This reduces the number and impact of future incidents.

Monitoring and event management (ITIL 4)

Parent Process Reference Framework: ITIL 4

Service Value Stream Activities

Highly impacted Service Value System(SVS) Activities:

  • Deliver and support

Description

The purpose of the monitoring and event management practice is to systematically observe services and service components, and record and report selected changes of state identified as events. This practice identifies and prioritizes infrastructure, services, business processes, and information security events, and establishes the appropriate response to those events, including responding to conditions that could lead to potential faults or incidents.

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

The monitoring and event management practice manages events throughout their lifecycle 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 that are 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 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.

Not all events have the same significance or require the same response. Events are often classified as informational, warning, and exceptions. Informational events do not require action at the time they are identified, but analysing 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 yet have been experienced.

The processes and procedures needed in the monitoring and event management practice must address these key activities and more:

  • 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 the use of designed-for-purpose monitoring tools
  • establishing and maintaining thresholds and other criteria for determining which changes of state will 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

IT Asset Management (ITIL 4)

Parent Process Reference Framework: ITIL 4

Service Value Stream Activities

Highly impacted Service Value System(SVS) Activities:

  • Design and Transition
  • Obtain/build

Description

The purpose of the IT asset management practice is to plan and manage the full lifecycle of all IT assets, to help the organization 

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

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. These are typically devices that were not traditionally thought of as IT assets, but that now include embedded computing capability and network connectivity. 

Understanding the cost and value of assets is essential to also comprehending the cost and value of products and services, and is therefore an important underpinning factor in everything the service provider does. IT asset management contributes to the visibility of assets and their value, which is a key element to successful service management as well as being useful to other practices. 

IT asset management requires accurate inventory information, which it keeps in an asset register. This information can be gathered in an audit, but it is much better to capture it as part of the processes that change the status of assets, for example, when new hardware is delivered, or when a new instance of a cloud service is requested. If IT asset management has good interfaces with other practices, including service configuration management, incident management, change control, and deployment management, then the asset status information can be maintained with less effort. Audits are still needed, but these can be less frequent, and are easier to do when there is already an accurate asset register. 

IT asset management helps to optimize the use of valuable resources. For example, the number of spare computers an organization requires can be calculated based on service level agreement commitments, the measured performance of service requests, and demand predictions from capacity and performance management. 

Some organizations discover a need for IT asset management after a software vendor requests an audit of licence use. This can be very stressful if the required information has not been maintained, and can lead to significant costs, both in carrying out the audit and then paying any additional licence costs that are identified. It is much cheaper and easier to simply maintain information about software licence use as part of normal IT asset management activity, and to provide this in response to any vendor requests. Software runs on hardware, so the management of software and hardware assets should be combined to ensure that all licences are properly managed. For the same reason, the management of cloud-based assets should also be included. 

Incident Management (ITIL 4)

Parent Process Reference Framework: ITIL 4

Service Value Stream Activities

Highly impacted Service Value System(SVS) Activities:

  • Engage
  • Deliver and support

Description

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 is an unplanned interruption to a service or reduction in the quality of a service. 

Incident management can have an enormous impact on customer and user satisfaction, and on how customers and users perceive the service provider. Every incident should be logged and managed to ensure that it is resolved in a time that meets the expectations of the customer and user. Target resolution times are agreed, documented, and communicated to ensure that expectations are realistic. Incidents are prioritized based on an agreed classification to ensure that incidents with the highest business impact are resolved first. 

Organizations should design their incident management practice to provide appropriate management and resource allocation to different types of incident. Incidents with a low impact must be managed efficiently to ensure that they do not consume too many resources. Incidents with a larger impact may require more resources and more complex management. There are usually separate processes for managing major incidents, and for managing information security incidents. 

Information about incidents should be stored in incident records in a suitable tool. Ideally, this tool should also provide links to related CIs, changes, problems, known errors, and other knowledge to enable quick and efficient diagnosis and recovery. Modern IT service management tools can provide automated matching of incidents to other incidents, problems, or known errors, and can even provide intelligent analysis of incident data to generate recommendations for helping with future incidents. 

It is important that people working on an incident provide good-quality updates in a timely fashion. These updates should include information about symptoms, business impact, CIs affected, actions completed, and actions planned. Each of these should have a timestamp and information about the people involved, so that the people involved or interested can be kept informed. There may also be a need for good collaboration tools so that people working on an incident can collaborate effectively. 

Incidents may be diagnosed and resolved by people in many different groups, depending on the complexity of the issue or the incident type. All of these groups need to understand the incident management process, and how their contribution to this helps to manage the value, outcomes, costs, and risks of the services provided: 

  • Some incidents will be resolved by the users themselves, using self-help. 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, etc. 

Change control (ITIL 4)

Parent Process Reference Framework: ITIL 4

Service Value Stream Activities

Highly impacted Service Value System(SVS) Activities:

  • Obtain/build
  • Design and Transition
  • Deliver and support
  • Improve 

Description

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

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

The scope of change control is defined by each organization. It will typically include all IT infrastructure, applications, documentation, processes, supplier relationships, and anything else that might directly or indirectly impact a product or service. 

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

Change control must balance the need to make beneficial changes that will deliver additional value with the need to protect customers and users from the adverse effect of changes. All changes should be assessed by people who are able to understand the risks and the expected benefits; the changes must then be authorized before they are deployed. This assessment, however, should not introduce unnecessary delay. 

The person or group who authorizes a change is known as a change authority. It is essential that the correct change authority is assigned to each type of change to ensure that change control is both efficient and effective. In high-velocity organizations, it is a common practice to decentralize change approval, making the peer review a top predictor of high performance. 

Capacity and performance management (ITIL 4)

Parent Process Reference Framework: ITIL 4

Service Value Stream Activities

Highly impacted Service Value System(SVS) Activities:

  • Improve 

Description

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. 

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

Service performance is usually associated with the number of service actions performed in a timeframe and the time required to fulfil a service action at a given level of demand. Service performance depends on service capacity, which is defined as the maximum throughput that a CI or service can deliver. Specific metrics for capacity and performance depend on the technology and business nature of the service or CI. 

The capacity and performance management practice usually deals with service performance and the performance of the supporting resources on which it depends, such as infrastructure, applications, and third-party services. In many organizations, the capacity and performance management practice also covers the capacity and performance of the personnel. 

The capacity and performance management practice includes the following activities: 

  • service performance and capacity analysis: 
  • research and monitoring of the current service performance 
  • capacity and performance modelling 
  • service performance and capacity planning: 
  • capacity requirements analysis 
  • demand forecasting and resource planning 
  • performance improvement planning. 

Service performance is an important aspect of the expectations and requirements of customers and users, and therefore significantly contributes to their satisfaction with the services they use and the value they perceive. Capacity and performance analysis and planning contributes to service planning and building, as well as to ongoing service delivery, evaluation, and improvement. An understanding of capacity and performance models and patterns helps to forecast demand and to deal with incidents and defects. 

Next Page » « Previous Page