DIGITAL TRANSFORMATION BLOG

4445 Eastgate Mall, Suite 200
San Diego, CA 92121

1325 G Street NW, Suite 1020, Washington
DC 20005

60 E Rio Salado Pkwy, Suite 900
Tempe, AZ 85281

This practice is concerned with aligning an organization’s practices and services with changing business needs through the ongoing identification and improvement of services, service components, practices, or any element involved in the efficient and effective management of products and services. Included in the scope of the continual improvement practice is the development of improvement-related methods and techniques along with a continual improvement culture and mindset across the organization, in alignment with the organization’s overall strategy. The commitment to and practice of continual improvement must be embedded into every fiber of the organization. If it is not, there is a real risk that daily operational concerns and major project work will eclipse continual improvement efforts. The continual improvement practice also includes an update of the CSI model covered as part of ITIL v3 (see diagram below).

The purpose of this practice is to move new or changed hardware, software, documentation, processes, or any other component to live environments. Deployment management works closely with release management and change control, but it is a separate practice. In some organizations, the term ‘provisioning’ is used to describe the deployment of infrastructure, and deployment is only used to mean software deployment, but in this case the term deployment is used to mean both. In short, the Deployment Management practice is typically an IT decision to move components to live environments, whereas the Release Management practice is typically a business decision to make services and features available for use by customers. These practices can be performed separately as seen within Agile/DevOps environments and pictured in the diagram below.

This process is focused on making new and changed services and features 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 the release management work takes place before deployment, with plans in place as to exactly which components will be deployed in a release. The deployment then makes the new functionality available. The ITIL v3 process named Release and Deployment Management was separated into two ITIL 4 Practices – Release Management and Deployment Management, which will be detailed further below.

The purpose of this 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. 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. In short, the IT Asset Management practice is about understanding “content” (what we have), and the Service Configuration Management practice is about understanding “context” (the relationships between what we have).

This practice is concerned with planning and managing the full lifecycle of IT assets. 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 items 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. The ITIL v3 process named Service Asset and Configuration Management was separated into two ITIL 4 Practices – IT Asset Management and Service Configuration Management, which will be detailed further below.