ITIL - Service Transition Processes Tutorial

Welcome to the ninth chapter of the ITIL Foundation tutorial (part of the ITIL® Foundation Certification Training). This lesson will help you to understand the constituent processes of service transition.

Objectives

After completing this lesson, you will be able to:

  • Describe the purpose, objective and scope of transition, planning, and support

  • Explain the purpose, objective and scope of change management

  • Describe the concept of Service Asset and Configuration Management (SACM)

  • Identify the purpose, objective and scope of Release and Deployment Management

  • Explain the purpose, objective and scope of knowledge management

Introduction to Service Transition Processes

The processes in service transition phase are critical as they influence and support all stages of the service lifecycle.

Following are the processes in service transition phase:

1. Transition, planning, and support

Transition, planning, and support provides the planning and support for new or modified services and ensures an orderly transition of services.

2. Change management

Change management controls the lifecycle of all changes and ensures a balance between flexibility and stability.

3. Service Asset and Configuration Management

Service asset and configuration management provide the information required to manage CIs and assets across the service lifecycle.

4. Release and Deployment Management

Release and deployment management plans, builds, test the releases and deploys the services into the customer’s environment.

5. Knowledge management

Knowledge management gathers, analyses and shares information with the organization to increase efficiency for the future.

Transition, Planning, and Support

Transition, planning, and support is a process that includes planning and coordination for the activities involved in service transition.

Let us focus on the purpose, objective and scope of transition, planning, and support.

Purpose

The purpose of the transition, planning and support process is to:

  • Provide overall planning for service transitions; and

  • Coordinate the resources that are required to deliver the service.

Objective

Following are the objectives of the transition, planning and support process:

  • Plan and coordinate the resources to ensure that the requirements defined in service strategy phase are implemented in service design phase; in addition, ensure that the requirements are successfully released in service operation phase

  • Coordinate activities across projects, suppliers and service teams were required

  • Provide clear plans that help the customer and the business change projects to align their activities with the service transition plans

  • Establish new or modified information systems and tools, technology and management architectures and service management processes

  • Establish new or modified measurement methods and metrics to meet the requirements defined during service design phase

  • Monitor and improve the performance of the service transition phase

Scope

The scope of the transition, planning and support process is to:

  • Maintain policies, models, and standards for the activities and processes in service transition.

  • Coordinate the efforts needed to manage several transitions at the same time.

  • Prioritise conflicting requirements for service transition resources.

  • Review and improve the performance of activities related to transition, planning, and support.

Introduction to Change Management

We will now discuss change management.

Change

A change is a modification, addition or removal of anything that could impact IT services. The impact may be altering the process or adding a CI. This includes the addition, modification or removal of approved, supported or baselined hardware, network, software, application, environment, system, desktop build or associated documentation.

For example, if a server, with its defined configuration, is a CI for the customer, any addition of memory to that server constitutes a change. Changes can be made for proactive or reactive reasons.

Examples of proactive reasons include cost reduction and service improvement.

Examples of reactive reasons include solving service disruptions and adapting the service to a changing environment.

The change management process is responsible for controlling the lifecycle of all changes, from the inception to the closure of the change. It is important to manage the change because it helps to optimize the risk to business services and minimize the severity of any impact and disruption. The process also enables changes to be successful at the first attempt.

change management process in itil foundation

The image above illustrates change management.

Change Management – Overview

Change management includes changes to baselined service assets and configuration items across the entire service lifecycle.

Let us understand the purpose, objective and scope of change management.

Purpose

The purpose of change management process is to:

  • Control the lifecycle of all changes; and

  • Help in making beneficial changes with minimum disruption to IT services.

Objective

Following are the objectives of the change management process:

  • Respond to business and IT requests to ensure alignment of services with business needs

  • Ensure that changes are introduced in a controlled manner, thus optimizing business risk

  • Implement changes timely and successfully to meet business needs

  • Use the standard processes and record every change

Scope

Changes may occur in service strategy or service design phase, for example, there may be a change in the service portfolio. Changes may also occur at a tactical level in service operations phase, for example, there may be an addition of two new servers.

The scope of change management includes:

  • Any change to all architecture, tools, metrics, processes, and documentation.

  • Addition, removal or modification of a service, Configuration Item or an associated documentation.

  • Changes to any of the five aspects of service design.

Change Model

A change model refers to a predefined set of steps, policies, and procedures for assessing, authorizing and executing a specific type of change. Change models help to save costs, minimize risk and improve the consistency of execution around changes.

A change model includes the following components:

  • Steps to handle changes, including unexpected events and issues

  • The chronological order in which these steps should be taken, with any dependency or co-processing defined

  • Responsibilities as in who should do what, including identification of change authorities who will authorize the change and decide whether formal change evaluation is needed

  • Thresholds and timescales for completion of the actions

  • Escalation procedures including who should be contacted and when

Types of Change

Following are the three types or models of change:

  • Normal change

  • Standard change

  • Emergency change

Normal change

Normal change is a change that follows all steps of the change process. It is assessed by the Change Manager and approved by Change Advisory Board or CAB.

Standard change

Standard change is a pre-approved change that has low risk. It is relatively common and follows a defined procedure or work instruction. Password reset or provision of standard equipment to a new employee is considered as a standard change.

Emergency changes

Emergency changes are defined as changes that must be addressed quickly, for example, to resolve a major incident or implement a security patch. The organization uses an advanced process for handling emergency changes. These changes should be kept to a minimum as the impact and chances of failure are more for an emergency change.

Preparing for a career in IT Service? Check out our Course Preview on ITIL Foundation here!

Key Terminologies

Some of the key terms related to service transition are remediation planning, service change, Request for Change or RFC and change proposal.

Remediation planning

Remediation planning refers to a recovery plan to a known state after a failed change or release. Before instigating the change, it is important to know if various remediation options are available. Once it is established that the remediation is viable, the risk of the proposed change is determined and appropriate decisions are taken.

Service change

Service change refers to the addition, modification or removal of an authorized, planned or supported service component and its associated documentation.

Request for Change

Request for Change is a formal request for a service change. It can be raised or issued by anyone involved in the service.

An RFC is a standard form to capture and process all changes to any Configuration Item.

Change proposal

A change proposal is raised for major changes with significant organizational or financial effects.

Change Proposal

A change proposal is utilized to communicate a high-level description of any change that has occurred. It may include multiple changes.

The change proposal is created in the Service Portfolio Management process. It is then passed to the change management team for authorization. In some organizations, change proposals may be created by the Programme Management Office.

A change proposal includes:

  • A high-level description of the new changed or retired service.

  • A business case including risks, issues, and alternatives.

  • Financial requirements and an outline schedule for design and implementation of the change.

Change Management Process – Change Flow

The image above/below illustrates different activities in the change management process.

Following are the activities:

1. The change management process starts with a Request for Change or RFC.

2. The RFC is logged in the change management system. The information is captured and tracked through to completion.

3. An initial review is performed to filter RFCs that are incomplete or incorrectly routed.

4. The RFCs are assessed. This is when the Change Advisory Board or the Emergency Change Advisory Board may be involved in business justification, impact, cost, benefit and risk of the changes.

5. The RFCs are authorized by the Change Manager.

The change requester, in turn, ensures that they have the approval in three main areas.

Following are the areas:

Financial approval: What is it going to cost and what is the cost of not doing it?

Business approval: What are the consequences to the business if the changes are not implemented?

Technology approval: What are the consequences to the infrastructure if the changes are not implemented?

6. Change management coordinates the work performed at multiple checkpoints. The change management team forwards approved changes to the relevant product experts. The experts build and test the changes as well as create and deploy releases.

7. The changes implemented are reviewed. This is called Post-Implementation Review or PIR. If the change is successful, it can be closed.

The image below illustrates change management process in ITIL Foundation.

change management process in itil foundation

A key activity of change management is an assessment of the change request by the Change Manager or Change Advisory Board.

change management example

The image above illustrates an example of change management.

Change Advisory Board

Let us now focus on the Change Advisory Board.

The Change Advisory Board is a consultative body that meets regularly to help the Change Manager assess, prioritize and schedule changes. The Change Advisory Board is a group of experts with a clear understanding of stakeholder needs.

The Change Manager chairs the board. The board may include representatives from all areas of the IT service provider.

These areas are:

  • Technical support

  • Operations

  • Development

  • Service management

  • Customers

  • Other stakeholders

  • Third parties such as suppliers.

People, who are directly or indirectly affected by the changes, are a part of the Change Advisory Board.

The Emergency Change Advisory Board is a subset of the CAB organized by the Change Manager. It offers advice on emergency changes.

Change Manager – Responsibilities

Following are the key responsibilities of the Change Manager:

  • Ensuring that the process is followed, and authorizing minor changes

  • Identifying key stakeholder for the changes, coordinating with them and conducting the Change Advisory Board meetings

  • Producing the change schedule, and ensuring that all changes are scheduled without conflict and without causing a bottleneck to business requirements

  • Coordinating the change, built, test and implementation

  • Reviewing or closing changes by collating all documentation related to the changes

  • Initiating post-implementation review meetings with the CAB

7 R’s of Change Management

Now let us understand the 7R’s of change management.

There are seven questions that should be asked for proper impact assessment and understanding of the risk to benefit ratio. These questions must be asked for all changes. The change assessment cannot be completed without getting the answers to these questions. The risk to benefit ratio cannot be understood as well.

Following are the questions asked by the Change Manager or the CAB:

  • Who raised the change?

  • What is the reason for the change?

  • What is the return required for 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 others?

Change Metrics

We will now focus on how the change management process is measured through metrics.

A metric is defined as something that is measured and reported to help manage a process, IT service or activity.

Key Performance Indicator or KPI is another term used in measuring performance. It is an important metric for that process, IT service or activity. KPIs are selected to ensure that efficiency, effectiveness and cost-effectiveness are managed.

Some of the metrics used in the change management process are as follows:

Metrics

Compliance

  • A decrease in unauthorized changes

  • A decrease in emergency changes

  • Maintain the integrity of the CI’s and change

Effectiveness

  • An increase in the percentage of changes implemented

  • A decrease in disruptions, defects, and re-work

  • A decrease in changes failed

  • There should be a decrease in the number of incidents attributable to any change.

Efficiency

  • Benefits gained

  • Average time to implement

  • Increased percentage of accuracy in change estimates

Key Challenges in Change Management

Following are the key challenges faced by change management:

  • Business pressure: Organizations come up with new initiatives for their business process and may pressurize for immediate execution of these ideas.

  • Incomplete and inaccurate Configuration Management System or CMS: This leads to an incomplete and inaccurate assessment of changes.

  • Soiled technical function areas: Lack of communication channels to the technical teams make it difficult to execute a change.

  • Misunderstanding of emergency changes: Sometimes the technical team may misunderstand urgency and emergency changes.

  • Scalability across large organizations: Scalability is a big challenge because some of the CIs may not be deployable in the existing infrastructure. The change management team may find it difficult to solve this issue.

  • Vendor or contract compliance: Vendors may own the change management system or resist from following the change management process in an organization.

Service Asset and Configuration Management – Overview

Now let us discuss the Service Asset and Configuration Management process.

This process manages the service assets to support other service management processes. An organization cannot function efficiently or effectively unless they manage their assets well. These assets are vital for the functioning of the customer’s or organization’s business. Let us understand the purpose, objective and scope of SACM.

Purpose

The purpose of SACM is as follows:

  • Ensure the assets required to deliver services are properly controlled.

  • Store accurate and reliable information about the assets.

  • Ensure that the information is available anytime.

Objective

Following are the objectives of the SACM process:

  • Define and control the components of infrastructure and services

  • Maintain exact configuration records

This helps an organization to comply with corporate governance requirements, control their asset base and optimize their costs; it also helps to manage change and release effectively, and resolve incidents or problems faster

Scope

The scope of SACM is as follows:

  • Ensuring that all assets used during the service lifecycle are within the scope of asset management.

  • Managing the complete lifecycle of every configuration item.

The process offers a complete overview of all assets and shows who is responsible for the control and maintenance of these assets.

Configuration Baseline and Database

Now let us define two key terminologies.

Configuration baseline

A configuration baseline is the configuration of a service, product or infrastructure that is formally reviewed and agreed upon. It serves as the basis for further activities.

The configuration baseline can be changed only through formal change procedures. It captures the structure, contents, and details of a configuration. It represents a set of Configuration Items that are related to each other.

A configuration baseline is the snapshot of the configuration of a CI on a particular time interval. This can be used for comparison in the future.

Configuration Management Database or CMDB

A Configuration Management Database or CMDB is a database to store records of Configuration Items.

Following are the characteristics of CMDB.

  • One or more CMDBs can be part of a Configuration Management System.

  • The CMDB provides a logical model of the IT infrastructure as it captures CIs and the relationships between them.

  • Similar to the CMDB, there are two libraries defined as part of the Configuration Management System.

These libraries are used for controlling and releasing components throughout the service lifecycle, for example, in design, building, testing, deployment, and operations.

Take a look at the example of configuration management.

A leading organization has the following Configuration Items (CIs). Identify the attributes to be stored in CMDB.

S/N

Configuration Items

Numbers

1

Servers

20

2

Routers

40

3

Switches

50

4

Voice Gateway

10

5

Video Conferencing Units

15

Server

Server Name, Server IP, Server Model, Server Make, OS, Serial Number, Support Date, Dependencies

Router

Router Name, Router IP, Router Model, Router Make, Firmware Version, Serial Number, Support Date, Interface Name, BW Allocation, Dependencies

Switch

Switch Name, Switch IP, Switch Model, Switch Make, Serial Number, Support Date, Dependencies

Voice GW

Voice GW Name, Voice GW IP, Voice GW Model, Voice Gateway Make, Serial Number, Support Date, Dependencies

Video Conference

VC Name, VC IP,VC Model, VC Make, Serial Number, Support Date, Dependencies, Firmware Version

Definitive Media Library

Now we will discuss the Definitive Media Library.

The Definitive Media Library or DML is a secure store where the definitive, authorized and approved versions of all media CIs are stored and monitored. The DML is the only source for build and distribution. The master copies of items stored in the DML pass quality assurance checks.

The DML includes master copies of all software assets such as:

  • Scripts and codes

  • In-house and external software houses

  • Management tools and applications

  • Licenses

CMDB and DML

The image below illustrates the relationship between CIs, CMDB and Definitive Media Library.

relationship between cmdb and dml in foundation

It also explains how they are used to roll out new releases and deployments to the live environment. The big rectangle box in the image represents the CMS. The DML and the CMDB are a part of the CMS.

During a new release, authorized CIs are taken or checked out of the DML. They are then used in the development environment to create a new release. The new release is tested in the test environment before it is rolled out for deployment in the production environment.

All documentation on this release is included in the release record. The documentation is related to associated CIs in the CMDB.

Secure Library and Secure Stores

Let us now discuss secure library and secure stores.

A secure library is a collection of software, electronic or document CIs of known type and status. Access to items in a secure library is restricted.

Secure store

A secure store is a secure location where IT assets such as PCs, server, and other hardware are stored. Definitive spares are kept in the secure store.

Definitive spares

Definitive spares are spare components and assemblies maintained at the same level as the comparative systems within the live environment.

SACM – Logical Model

We will now focus on the logical model of SACM. The configuration management’s logical model of the services and infrastructure is THE model.

It is called so because it is a single common representation used by all parts of IT Service Management, and beyond, such as HR, finance, supplier, and customers.

The image below depicts the breakdown of two business services, e-banking and e-sales, into constituent IT services and components or CIs.

sacm logical model

The services provide a user experience that depends on the availability and Service Level Agreement or SLA. These services depend on IT applications, which are governed by business rules and underlying infrastructures such as data services or web services.

The infrastructure is housed in a datacenter and connected by a network. This might not be the actual architecture of the services, but logically such a model lets the customers and service providers give an overview of end-to-end services.

This is enabled by the Configuration Management System.

The relationship between CMDB, CMS, and SKMS

The image below represents the relationship between CMDB, CMS and Service Knowledge Management System or SKMS.

relationship between cmdb, cms and skms in foundation

Service Knowledge Management System

Service Knowledge Management System is the complete set of integrated repositories or databases used to manage knowledge and information.

The SKMS includes CMS, tools, and databases. The SKMS stores, manages, updates and presents all information that an IT service provider needs. The information helps the IT service provider to manage the full lifecycle of services.

The purpose of the SKMS is to provide quality information so that informed decisions can be made by the IT service provider.

The SKMS consists of the following information:

  • The experience of the staff

  • Records of peripheral matters, for example, the user numbers and behavior, and the organization’s performance figures

  • Suppliers’ and partners’ requirements, abilities and expectations

  • Typical and anticipated skill levels of the user

CMS

The CMS is maintained by Service Asset and Configuration Management and is used by all IT Service Management processes.

Following are two major components of the CMS:

CMDB: It stores configuration details of the IT infrastructure.

Known Error Database or KEDB: It is the database created by problem management. The database is used by the incident and problem management.

Introduction to Release and Deployment Management

Release and Deployment Management or RDM is one of the phases of service transition. This process aims at building, testing and delivering the capability to provide the services specified by service design.

In the context of ITIL,

  • A release is a set of new or changed Configuration Items that are tested and implemented into production.

  • Release management is responsible for planning, scheduling and controlling the movement of new or changed services, in the form of a release package. This applies to both the testing and live production environments.

  • Deployment management is responsible for the movement of new or changed hardware, software, documentation or other Configuration Items into the live production environment.

  • Release management is responsible for planning and scheduling the release. Deployment management is the team that implements the changes.

Let us discuss some facts related to release units and release packages.

A release unit is a part of the service or infrastructure included in the release, in accordance with the organization’s release guidelines.

For example, an organization may decide that the release unit for business-critical applications is a complete application. It ensures that the testing is comprehensive.

Release Package

A release package is a single release unit or a structured collection of release units. It includes all elements of a service. These elements are infrastructure, hardware, software, applications, documentation, knowledge and so on. A release package comprises the release unit of a business critical application, documentation, operations and end-user training.

Release and Deployment Management – Overview

An effective RDM enables the service provider to add value to the business by delivering changes faster. It also helps the service provider to deliver changes at optimal cost and minimized risk.

Let us focus on the purpose, objective and scope of Release and Deployment Management.

Purpose

The purpose of the Release and Deployment Management process is to plan, schedule and control the build, test, and deployment of releases. The purpose is also to deliver new functionalities needed by the business while ensuring that the integrity of existing services is protected.

Objective

The objective of the Release and Deployment Management process is to:

  • Define Release and Deployment Management plans and get the customers’ and stakeholders’ consent on those plans.

  • Create and test release packages comprising related Configuration Items that are compatible with each other.

  • Make sure that all release packages can be tracked, installed, tested, verified, uninstalled or withdrawn.

  • Record as well as manage risks, deviations, and issues related to a new or changed service so that necessary corrective actions can be taken.

  • Ensure that there is knowledge transfer.

This enables the customers and users to optimize the service and support their business activities.

Scope

The scope of Release and Deployment Management is to:

  • Define processes, systems, and functions to package, build, test and deploy a release into production.

  • Establish the service specified in the Service Design Package or SDP before handing it over to service operations.

  • Include all Configuration Items required to implement a release.

Release Policy

Let us now discuss the release policy.

The release policy is the primary strategy for releases and is derived from the service design phase of the service lifecycle.

The policy includes the following components:

  • Description of the release with its unique identification, numbering and naming conventions; it indicates the types of releases and how they are identified and tracked

  • The roles and responsibilities related to each stage of the process; it helps to identify the activities and the persons accountable and responsible for such activities in the release and deployment process

  • The expected frequency related to each type of release

  • The approach in which changes should be accepted and grouped into a release

  • The mechanism followed to automate the build, install and release distribution processes for improvement, repeatability, reuse, and efficiency; the policy statement typically identifies the use of automation in release and deployment

Following are some more components of the release policy:

  • How the configuration baseline for the release is captured and verified against the contents of the actual release, for example, hardware, software, documentation, and knowledge; this refers to how the release and deployment process manages the integrity of the CI change and CMDB.

  • Entry and exit criteria, and authority for accepting the release at each stage of service transition and into the controlled training, test, production, and disaster recovery environments

  • Criteria and authorization to exit early life support and handover to service operations

Types of Releases

The three types of releases are major, minor and emergency releases.

Major release

A major release contains large proportions of new functionalities. It is also known as a major upgrade that supersedes any preceding minor upgrade. A typical example of a major release is windows service packs.

Minor release

A minor release contains small enhancements and fixes. A minor release or upgrade supersedes previous emergency fixes. A typical example of a minor release is upgrading the routers to the latest version.

Emergency release

An emergency release is linked to an emergency change.

A typical example of emergency release is Microsoft releasing an emergency patch to protect Windows from malicious attacks.

A key concept in Release and Deployment Management is the approach taken to deploy the releases.

We will focus on such approaches in this lesson.

Release and Deployment Approaches

In the release design, different considerations apply with respect to the way in which the release is deployed.

The most frequently occurring options for the rollout of releases are big bang versus phased, push versus pull and automated versus manual approaches.

Big Bang Approach

The big bang approach refers to the new or changed service being deployed to all user areas in one operation. It is often used when introducing an application change and consistency of service across the organization, which is considered as important. The negative aspect of the big bang approach is that it increases the risk and impact of a failed release.

Example: Installing the office software for 500 users at one stretch

Phased Approach

The phased approach means that the service is deployed to a part of the user base initially. Then this operation is repeated for subsequent parts of the user base via a scheduled rollout plan.

This approach applies to many scenarios such as in retail organizations. In such organizations, services are introduced into the stores’ environment in manageable phases.

Push Approach

The push approach is used where the service component is deployed from the center and pushed to the target locations.

Example: Pushing the Antivirus software upgrades to the connected PCs from the server

Pull Approach

The pull approach is used for software releases.

The software is made available in a central location, and users are free to bring the software to their own location as and when required.

Example: Informing the employees to pull the software from the server when required

Automated Approach

The automated approach refers to automating releases using technology, which ensures consistency.

The time required to provide a well-designed and efficient automated mechanism may not always be available or viable.

Example: The common live updates from the vendors for their laptops or desktops

Manual Approach

The manual approach refers to distributing a release manually.

It monitors and measures the impact of many repeated manual activities as they are likely to be inefficient and error-prone.

Example: Installing the required Microsoft Office upgrades when required

RDM Phases

Let us now focus on the four phases of Release and Deployment Management.

The four phases in RDM are:

  • Release and deployment planning

  • Release, build and test

  • Deployment

  • Review and close

The image below shows the RDM phases involved.

rdm phases in itil foundation

Release and deployment planning

In the first phase, which is ‘release and deployment planning’, plans are created for developing and deploying a release. This phase starts with change management authorization to plan a release. It ends with change management authorization to create the release.

Release, build and test

In the second phase, which is ‘release, build and test’, the release package is built, tested and checked into the DML.

This phase starts with change management authorization to build the release. It ends with change management authorization for the baseline release package to be checked into the DML. This is done by Service Asset and Configuration Management. This phase occurs once for each release.

Deployment

In the third phase, which is ‘deployment’, the release package in the DML is deployed to the live environment. This phase starts with change management authorization to deploy the release package to one or more target environments.

The phase ends with handing over the release package to service operation functions and early life support. There may be many separate deployment phases for each release, depending on the planned deployment options.

Review and close

In the last phase, that is ‘review and close’, experience and feedback are captured. In addition, performance targets and achievements are reviewed, and lessons are learned. This marks the end of the Release and Deployment Management process.

Take a look at the example of release management below.

release management example

Introduction to Knowledge Management

We will now discuss the next process in service transition phase, which is knowledge management.

The ability to deliver a quality service or complete a process depends on the ability of those who are involved in it. The ability depends on their understanding of the situation, consequences, and benefits, which are collectively called the knowledge of that particular situation.

Following are the facts related to knowledge management:

  • Knowledge management provides support for the capture and effective publishing of knowledge that surfaces during service transition and other phases.

  • The quality and relevance of the knowledge rest on the accessibility, quality and continued relevance of the underpinning data and information available to the service staff.

Knowledge Management - Overview

Knowledge management is significant in the service transition phase. This is so because testing and validation data is gathered in this phase prior to release into the live environment. Let us now understand the purpose, objective and scope of knowledge management.

Purpose

The purpose of the knowledge management process is to:

  • Share perspectives, ideas, experience, and information.

  • Make sure that the information is available at the right time and in the right place.

This helps to make informed decisions, and improve the efficiency by minimizing the need to rediscover knowledge.

Objective

The objective of knowledge management is to:

  • Improve the quality of management decision-making by ensuring that secure and reliable information is available for the service lifecycle.

  • Ensure that the right information is delivered to the appropriate place or person at the right time to enable informed decisions.

  • Maintain an SKMS that offers controlled access to information, knowledge, and data that are appropriate for each audience.

Scope

The scope of knowledge management is to:

  • Provide knowledge throughout the service lifecycle.

  • Manage knowledge, information, and data on the identity of stakeholders, available timescales or resources and acceptable levels of risk and performance expectations.

Knowledge management is visualized using the Data-Information-Knowledge-Wisdom structure.

Data-Information-Knowledge-Wisdom

Data-Information-Knowledge-Wisdom or DIKW is the heart of the knowledge management. Effective sharing of knowledge requires the development and maintenance of SKMS. This system should be available to all information stakeholders and suit all information requirements.

Some facts related to DIKW are given below:

Data is a set of discrete facts. Most organizations capture significant amounts of data every day in the form of metrics. Information comes from providing context to data. This requires capturing various sources of data and applying meaning or relevance to the set of facts, for example, reports on metrics.

Knowledge comprises the experiences, ideas, insights, and judgments from individuals. This requires the analysis of information and is applied to facilitate decision-making. The use of wisdom enables an organization to direct their strategy and growth in competitive market spaces.

Wisdom provides the ultimate understanding of the material. Developing an awareness of the application and context enables a strong common sense judgment. Quantitative data from metrics are transformed into qualitative information.

Knowledge is obtained by combining information with experience, context, interpretation, and reflection. It can be used to make the right decisions, which leads to wisdom. Tools and databases can be used to capture data, information, and knowledge, but wisdom cannot be captured in this way.

Wisdom is a concept relating to the abilities to use knowledge for making correct judgments and decisions.

graph of dikw

The image above gives a graphical representation of DIKW.

Curious about the ITIL Foundation course? Watch our Course Preview for free!

Summary

Let us summarize what we have learned in this lesson:

  • The purpose of the transition, planning and support process is to provide overall planning for service transitions.

  • Change management covers changes to baselined service assets and configuration items across the service lifecycle.

  • Service Asset and Configuration Management provides the information required to manage CIs and assets across the service lifecycle.

  • The purpose of RDM is to plan, schedule and control the build, test, and deployment of releases.

  • Knowledge management ensures that the information is available in the right place and at the right time.

Conclusion

Next, we will look at the tenth chapter, Service Operations Tutorial.

Find our ITIL® Foundation Online Classroom training classes in top cities:


Name Date Place
ITIL® Foundation 27 Aug -31 Aug 2018, Weekdays batch Your City View Details
ITIL® Foundation 7 Sep -8 Sep 2018, Weekdays batch Chicago View Details
ITIL® Foundation 24 Sep -28 Sep 2018, Weekdays batch Dallas View Details
  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Name*
Email*
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

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

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