Service Asset and Configuration Management Tutorial

Service Asset and Configuration Management

Welcome to lesson 3 of the ITIL Intermediate RCV tutorial, which is a part of ITIL Intermediate RCV Foundation Certification course. This lesson expands on how the process of service asset and configuration management (SACM) contributes to RCV practices. The lifecycle phase emphasized in this lesson is service transition.

Let us start with the objectives of this lesson.


By the end of this ‘Service Asset and Configuration Management’ lesson, you will be able to:

  • Understand the complete overview of the purpose, objectives, scope and importance of SACM as a process to generate business value. SACM policies, principles, concepts, activities, methods and techniques in relation to RCV practices.

  • Explain the importance and use of configuration items (CIs), along with tools, activity models, CMS back-ups and historical data.

  • Review the efficient uses of SACM metrics, as well as how service operation interacts with SACM.

Let’s look at the purpose of SACM process in the next section.

Purpose of Service Asset and Configuration Management(SACM)

The purpose of SACM is to Identify, control, record, report, audit and verify service assets and configuration items, including versions, baselines, constituent components, their attributes, and relationships.
It accounts for managing and protecting the integrity of service assets and configuration items (and, where appropriate, those of its customers) through the service lifecycle by ensuring that only authorized components are used and only authorized changes are made.

It protects the integrity of service assets and configuration items (and, where appropriate, those of its customers) through the service lifecycle Other purposes will include ensuring the integrity of the assets and configurations required to control the services and IT infrastructure by establishing and maintaining an accurate and complete Configuration Management System.

Now, let’s look at the key terms of this process.

SACM - Key Terms

As we have understood it is always a good practice to understand the keywords predominantly largely being used in this process. The key terms and their description is given below:

  • Attribute - Attribute is a piece of information about a configuration item. Some of the Examples are name, location, version number, and cost. Attributes of CIs are recorded in a configuration management database (CMDB) and maintained as part of a configuration management system (CMS)

  • Audit - Audit is a formal inspection and verification to check whether a standard or set of guidelines is being followed, that records are accurate, or that efficiency and effectiveness targets are being met. An audit may be carried out by internal or external groups.

Now let us look at the objective of SACM process in the next section.

Objectives of Service Assets & Configuration Management

The objective of SACM process is to define and control the components of services and infrastructure and maintain accurate configuration information on the historical, planned and current state of the services and infrastructure.
As we have an understanding of the objective, let us look at the scope of this process.

Scope of SACM Process

Scope Asset Management covers service assets across the whole service lifecycle. It provides a complete inventory of assets and who is responsible for their control.

It includes:

  • Full lifecycle management of IT and service assets, from the point of acquisition through to disposal

  • Maintenance of the asset inventory. Configuration Management ensures that selected components of a complete service, system or product (the configuration) are identified, baselined and maintained and that changes to them are controlled.

  • It also ensures that releases into controlled environments and operational use are done on the basis of formal approvals.

  • It provides a configuration model of the services, assets, and infrastructure by recording the relationships between service assets and configuration items.

  • SACM may cover non-IT assets, work products used to develop the services and configuration items required to support the service that is not formally classified as assets.

  • Thus the scope covers interfaces to internal and external service providers where there are assets and configuration items that need to be controlled, e.g., shared assets.

In the next section, we will look at SACM process as value to the business.

Business value of SACM

Value to business involves:

  • Optimizing the performance of service assets and configurations improves the overall service performance and optimizes the costs and risks caused by poorly managed assets, e.g., service outages, fines, correct license fees and failed audits.

  • SACM provides visibility of accurate representations of a service, release, or environment that enables:

- Better forecasting and planning of changes

- Changes and releases to be assessed, planned and delivered successfully

- Incidents and problems to be resolved within the service level targets

- Service levels and warranties to be delivered

- Better adherence to standards, legal and regulatory obligations (less non-conformances)

- More business opportunities as able to demonstrate control of assets and services

- Changes to be traceable from requirements

- The ability to identify the costs of service.

Service Assets and Configuration Management Principles

Let us now look at the key principles and policies of SACM. The main policy sets out the framework and key principles against which assets and configurations are developed and maintained.

Typical principles include:

  • Ensuring that Asset and Configuration Management operations costs and resources are commensurate with the potential risks to the services

  • The need to deliver corporate governance requirements, e.g., software asset management, Sarbanes-Oxley, etc.

  • The need to deliver the capability, resources and service warranties as defined by the service level agreements and contracts

  • The requirement for available, reliable and cost-effective services

  • The requirement for clear economic and performance criteria for interventions that reduce costs or optimize service delivery, e.g., lower maintenance costs

  • The application of whole-life cost appraisal methods

  • The transformation from ‘find and fix’ reactive maintenance to ‘predict and prevent’ proactive management

  • The requirement to maintain adequate asset and configuration information for internal and external stakeholders

  • The level of control and requirements for traceability and auditability

  • The application of continuous improvement methods to optimize the service levels, assets and configurations

  • Provision of accurate asset and configuration information for other business and Service Management processes

  • Integration of Asset and Configuration Management with other processes

  • Migration to a common asset and CMS architecture

  • Level of automation to reduce errors and costs.

Moving on let us look into the concepts of SACM.

Basic Concepts in SACM

Now let's discuss some of the basic concepts of the process.

  • Service Asset: Any resource or capability that could contribute to the delivery of a service. Examples of service assets include a virtual or a physical server, a software license, a piece of information stored in a service management system, or some knowledge in the head of a senior manager.

  • Configuration Item (CI): A configuration item (CI) is a service asset that needs to be managed in order to deliver an IT service. Examples of CIs include Service lifecycle CIs, Service CIs, Organization CIs, Internal and external CIs or Interface CIs.

  • Configuration Record: A Set of attributes and relationships about a CI. Configuration records are stored in a configuration management database (CMDB) and managed with a configuration management system (CMS). It is important to note that CIs are not stored in a CMDB; configuration records describe CIs that are stored in the CMDB.

  • Service Knowledge Management System (SKMS): A Set of tools and databases that are used to manage knowledge, information, and data. Many configuration items are available in the form of knowledge or information, and these are typically stored in the SKMS – for example, a service level agreement(SLA), a report template or a definitive media library. The SACM process is not responsible for managing the SKMS. Some items in the SKMS will be owned and managed by the SACM process, but others will be owned and managed by other processes or people.

Let us now move on to discuss configuration management starting with a configuration model in the next section.

Wish to know more about ITIL Intermediate RCV? Consider watching our Course Preview here!

A Logical Configuration Model

Configuration Management delivers a model of the services, assets and the infrastructure by recording the relationships between configuration items as shown in the picture below.
Configuration Management Model

This enables other processes to access valuable information, such as:

  • To assess the impact and cause of incidents and problems

  • To assess the impact of proposed changes

  • To plan and design new or changed services

  • To plan technology refresh and software upgrades

  • To plan release and deployment packages and migrate service assets to different locations and service centers

  • To optimize asset utilization and costs, e.g., consolidate data centers, reduce variations and re-use assets.

The real power of Configuration Management’s logical model of the services and infrastructure is that it is THE model – a single common representation used by all parts of IT Service Management, and beyond, such as HR, finance, supplier, and customers.

In the next section, let us look configuration management system.

Configuration Management System (CMS)

To manage large and complex IT services and infrastructures, Service Asset and Configuration Management requires the use of a supporting system known as the Configuration Management System (CMS).

Some of the features of CMS are:

  • The CMS holds all the information for CIs within the designated scope. Some of these items will have related specifications or files that contain the contents of the item, e.g., software, document or photograph. For example, a Service CI will include the details such as supplier, cost, purchase date and renewal date for licenses and maintenance contracts and the related documentation such as SLAs and underpinning supporting contracts.

  • The CMS is also used for a wide range of purposes, for example, asset data held in the CMS may be made available to external financial Asset Management systems to perform specific Asset Management processes reporting outside of Configuration Management.

  • The CMS maintains the relationships between all service components and any related incidents, problems, known errors, change and release documentation and

  • may also contain corporate data about employees, suppliers, locations and business units, customers and users.

In the next section, let us look at the use of data and information in CMS.

The Architectural layers of the CMS.

The figure below shows how the CMS covers the data and information layers of the knowledge/information/ knowledge hierarchy.
Architectural Layer of the CMS

At the data level, the CMS may take data from several physical CMDBs, which together constitute a federated CMDB. Other data sources will also plug into the CMS such as the definitive media libraries. The CMS will provide access to data on asset inventories wherever possible rather than duplicating data. Configuration information evolves as the service is developed through the service lifecycle.

Often there are separate mechanisms for managing different service lifecycle stages as well as different means of managing different applications and platforms. The CMS typically contains configuration data and information that combined into an integrated set of views for different stakeholders through the service lifecycle as illustrated in the figure.

It, therefore, needs to be based on appropriate web, reporting, and database technologies that provide flexible and powerful visualization and mapping tools, interrogation and reporting facilities. Many organizations are already using some elements of SACM, often maintaining records in documents, spreadsheets or local databases, and some of these may be used in the overall CMS.

Automated processes to load and update the Configuration Management database should be developed where possible to reduce errors and optimize costs. Discovery tools, inventory and audit tools, enterprise systems and network management tools can be interfaced to the CMS. These tools can be used initially to populate a CMDB, and subsequently to compare the actual ‘live’ configuration with the information and records stored in the CMS.

In the next section, let us look at the components of CMS process.

Major Components of Configuration Management System

There are four major components of CMS, and they have been explained below:

  • Secure libraries 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. Libraries are used for controlling and releasing components throughout the service lifecycle, e.g., in design, building, testing, deployment, and operations.

- A secure store is a location that warehouses IT assets are stored. It is identified within SACM, e.g., secure stores used for desktop deployment. Secure stores play an important role in the provision of security and continuity – maintaining reliable access to equipment of known quality.

  • The Definitive Media Library:

- The Definitive Media Library (DML) is the secure library in which the definitive authorized versions of all media CIs are stored and protected. It stores master copies of versions that have passed quality assurance checks. This library may, in reality, consist of one or more software libraries or file-storage areas, separate from development, test or live file-store areas. It contains the master copies of all controlled software in an organization.

- The DML should include definitive copies of purchased software (along with license documents or information), as well as software developed on site. Master copies of controlled documentation for a system are also stored in the DML in electronic form.

- The DML will also include a physical store to hold master copies, e.g., a fireproof safe. Only authorized media should be accepted into the DML, strictly controlled by SACM. The DML is a foundation for Release and Deployment Management.

- The exact configuration of the DML is defined during the planning activities.

The definition includes:

- Medium, physical location, hardware, and software to be used, if kept online – some Configuration Management support tools incorporate document or software libraries, which can be regarded as a logical part of a DML

- Naming conventions for file storage areas and physical media

- Environments supported, e.g., test and live environments

- Security arrangements for submitting changes and issuing documentation and software, plus backup and recovery procedures

- The scope of the DML, e.g., source code, object code from controlled builds and associated documentation

- Archive and retention periods

- Capacity plans for the DML and procedures for monitoring growth in size

- Audit procedures

- Procedures to ensure that the DML is protected from erroneous invalid or unauthorized change (e.g., entry and exit criteria for items).

  • Definitive spares

- An area should be set aside for the secure storage of definitive hardware spares. These are spare components and assemblies that are maintained at the same level as the comparative systems within the controlled test or live environment. Details of these components, their locations and their respective builds and contents should be comprehensively recorded in the CMS.

- These can then be used in a controlled manner when needed for additional systems or in the recovery from incidents. Once their (temporary) use has ended, they are returned to the spares store or replacements are obtained.

  • Configuration baseline and Snapshot

- A configuration baseline is the configuration of a service, product or infrastructure that has been formally reviewed and agreed on, that thereafter serves as the basis for further activities, and that can be changed only through formal change procedures. It captures the structure, contents, and details of a configuration and represents a set of configuration items that are related to each other.

Establishing a baseline provides the ability to:

- Mark a milestone in the development of a service, e.g., Service Design baseline

- Build a service component from a defined set of inputs

- Change or rebuild a specific version at a later date

- Assemble all relevant components in readiness for a change or release

- Provide the basis for a configuration audit and back out, e.g., after a change.

There is a Snapshot of the current state of a configuration item or an environment, e.g., from a discovery tool. This snapshot is recorded in the CMS, and it remains as a fixed historical record. Sometimes this is referred to a footprint. A snapshot is not necessarily formally reviewed and agreed on – it is just a documentation of a state, which may contain faults and unauthorized CIs. One example is where a snapshot is established after an installation, perhaps using a discovery tool, and later compared to the original configuration baseline.

Activities of Asset Management

Fixed assets of an organization are assets which have a financial value, can be used by the organization to help create products or services and have a long-term useful life.

For an IT service provider, these may include data centers, power distribution and air-handling components, servers, software licenses, network components, PCs, data, information etc.

Most organizations have a process that manages these assets. This process is usually called fixed asset management or financial asset management.

It carries out activities such as:

  • Identifying each asset, including unique naming and labels

  • Identifying and recording asset owners

  • Maintaining an asset register that includes details of all fixed assets

  • Understanding the purchase cost, depreciation and net book value of each asset

  • Helping to protect the assets from damage, theft, etc.

  • Carrying out regular audits to ensure the integrity of fixed assets.

Many configuration items that are managed by the service provider are fixed assets of the organization (or of their customer), and the service provider is responsible for protecting these assets in line with overall organizational policies.

In the next section, we will discuss the Software Asset Management.

Software Asset Management

Software asset management (SAM) is responsible for the management of software, software licenses and codes for activating software – whether these are installed on computer systems or held as copies that could be installed. SAM includes management, control, and protection of software assets and the risks arising from their use. Effective SAM is dependent on the use of appropriate tools, including a CMS and a definitive media library (DML).

The next section shows a pictorial representation of the relationship between DML and CMDB in the CMS.

The relationship between the DML and a CMDB in the CMS.

The following image gives you the pictorial depiction of the relationship between the DML and CMS which has have been explained earlier under components of Configuration management system.
Relationship between DML and CMS

In the next section, let us look at the activities of Asset and Configuration Management activities.

Asset and Configuration Management Activities

High-level activities for Asset and Configuration Management are shown in the example of an activity model in the figure below.

The activity model illustrated in the figure is often used where there are many parties, or suppliers and activities need to be established to obtain the configuration information and data from third parties.

We will discuss each activity in the next section.

Asset and Configuration Management Activities

The figure shown below gives the details of different activities of asset and configuration management.
Asset and Configuration Management Activities
The activities are described as follows:

Management Planning

There is no standard template for determining the optimum approach for SACM. The management team and Configuration Management should decide what level of Configuration Management is required for the selected service or project that is delivering changes and how this level will be achieved. This is documented in a Configuration Management Plan.

Often there will be a Configuration Management Plan for a project, service or groups of services, e.g., network services. These plans define the specific Configuration Management activities within the context of the overarching Service Asset and Configuration Management strategy.

Configuration identification

The configuration identification process activities are to:

  • Define and document criteria for selecting configuration items and the components that compose them

  • Select the configuration items and the components that compose them based on documented criteria

  • Assign unique identifiers to configuration items

  • Specify the relevant attributes of each configuration item

  • Specify when each configuration item is placed under Configuration Management

  • Identify the owner responsible for each configuration item.

Configuration control

Configuration control ensures that there are adequate control mechanisms over CIs while maintaining a record of changes to CIs, versions, location and custodianship/ ownership. Without control of the physical or electronic assets and components, the configuration data and information there will be a mismatch with the physical world.

No CI should be added, modified, replaced or removed without appropriate controlling documentation or procedure being followed. Policies and procedures need to be in place.

Status Accounting and Reporting

Each asset or CI will have one or more discrete states through which it can progress. The significance of each state should be defined in terms of what use can be made of the asset or CI in that state. There will typically be a range of states relevant to the individual asset or CIs.

Verification and Audit

The activities include a series of reviews or audits to:

  • Ensure there is conformity between the documented baselines (e.g., agreements, interface control documents) and the actual business environment to which they refer.

  • Verify the physical existence of CIs in the organization or in the DML and spares stores, the functional and operational characteristics of CIs and to check that the records in the CMS match the physical infrastructure

  • Check that release and configuration documentation is present before making a release.

Before a major release or change, an audit of a specific configuration may be required to ensure that the customer’s environment matches the CMS. Before acceptance into the live environment, new releases, builds, equipment and standards should be verified against the contracted or specified requirements. There should be a test certificate that proves that the functional requirements of a new or updated CI have been verified, or some other relevant document (e.g., RFC). Plans should be made for regular configuration audits to check that the CMDB and related configuration information is consistent with the physical state of all CIs, and vice versa.

Physical configuration audits should be carried out to verify that the ‘as-built’ configuration of a CI conforms to its ‘as-planned’ configuration and its associated documents. Interrogation facilities are required to check that the CMDB and the physical state of CIs are consistent. These audits should verify that correct and authorized versions of CIs exist, and that only such CIs exist, and are in use in the operational environment.

From the outset, any ad-hoc tools, test equipment, personal computers and other unregistered items should either be removed or registered through formal Configuration Management. Registration or removal will be via the Change Management process and has to prevent the authorization of non-acceptable CIs or the removal of CIs that may be supporting business processes.

Unregistered and unauthorized items that are discovered during configuration audits should be investigated, and corrective action should be taken to address possible issues with procedures and the behavior of personnel. All exceptions are logged and reported.

In the next section, let us look at the information management considerations for SACM.

How about investing your time ITIL Intermediate RCV Course? Click to watch the Course Preview!

Information Management considerations for SACM

Information management is an integral part of any process in Service management. Here are the key points that one needs to consider for information management

  • Backup copies of the CMS should be taken regularly and securely stored. It is advisable for one copy to be stored at a remote location for use in the event of a disaster. The frequency of copying and the retention policy will depend on the size and volatility of the IT infrastructure and the CMS. Certain tools may allow selective copying of CI records that are new or have been changed.

  • The CMS contains information on backup copies of CIs. It will also contain historical records of CIs and CI versions that are archived, and possibly also of deleted CIs or CI versions. The amount of historical information to be retained depends on its usefulness to the organization.

  • The retention policy on historical CI records should be regularly reviewed, and changed if necessary. If the cost to the organization of retaining CI information is greater than the current or potential value, do not retain it, taking note of relevant regulatory and statutory requirements in relation to retention of records.

  • Typically, the CMS should contain records only for items that are physically available or could be easily created using procedures known to, and under the control of, Configuration Management. When Configuration Management has been operating for a period of time, regular housekeeping should be carried out to ensure that redundant CI records are systematically archived.

Moving on, let us look at the triggers, inputs, and outputs of SACM.

SACM Process Triggers, Inputs, and Outputs

Updates to asset and configuration information are triggered by change requests, purchase orders, acquisitions and service requests. This section shows you what all trigger input and the output for the same.

Inputs to service asset and configuration management include:

  • Designs, plans, and configurations from service design packages

  • Requests for change and work orders from change management

  • Actual configuration information collected by tools and audits

  • Information in the organization’s fixed asset register.

Outputs from service asset and configuration management include:

  • New and updated configuration records

  • Updated asset information for use in updating the fixed asset register

  • Information about attributes and relationships of configuration items, for use by all other service management processes. This information should be presented in appropriate views for each audience

  • Configuration snapshots and baselines

  • Status reports and other consolidated configuration information

  • Audit reports.

In the next section, let’s discuss the interfaces of SACM process.

SACM Service Management Interfaces

By its very nature – as the single virtual repository of configuration data and information for IT Service Management – SACM supports and interfaces with every other process and activity to some degree. Some of the more noteworthy interfaces are:

  • Change Management – identifying the impact of proposed changes

  • Financial management – capturing key financial information such as cost, depreciation methods, owner and user (for budgeting and cost allocation), maintenance and repair costs

  • ITSCM – awareness of assets the business services depend on, control of key spares and software

  • Incident/problem/error – providing and maintaining key diagnostic information; maintenance and provision of data to the service desk

  • Availability management – in the detection of points of failure.

The relationship between change and release and deployment is synergistic, with these processes benefiting greatly from a single coordinated planning approach. Configuration control is synonymous with change control –understanding and capturing updates to the infrastructure and services.

Let us now look at the Critical Success Factors (CSF’s) and Key Performance Indicators (KPIs) of this process.

SACM Critical Success Factor(CSFs) And Key Performance Indicators(KPIs) ( 1 of 3)

The following list includes some sample CSFs for SACM Process. Each organization should identify appropriate CSFs based on its objectives for the process. Each sample CSF is followed by a small number if typical KPIs that support the CSF.

These KPIs should not be adopted without careful consideration. Each organization should develop KPIs that are appropriate for its level of maturity, its CSFs and its particular circumstances. Achievement against KPIs should be monitored and used to identify opportunities for improvement, which should be logged in the continual service improvement(CSI) register for evaluation and possible implementation.

To understand better, let us take one CSF which states:

  • Accounting for managing and protecting the integrity of CIs throughout the service lifecycle.

So the supporting KPIs would be:

  • Improved accuracy in budgets and charges for the assets utilized by each customer or business unit

  • Increase in re-use and redistribution of under-utilized resources and assets

  • Reduction in the use of unauthorized hardware and software, non-standard and variant builds that increase complexity, support costs, and risk to the business services

  • Reduced number of exceptions reported during configuration audits, based on urgency/priority/change type

  • Increase in scores in the survey of stakeholder satisfaction for the change management process

  • Increase in the accuracy of predictions for time, quality, cost, risk, resource and commercial impact

Let us look at couple more CSF’s and relevant KPI’s in the next two sections.

SACM CSFs And KPIs ( 2 of 3)

Let us take the next CSF which states:

  • Supporting efficient and effective service management processes by providing accurate configuration information at the right time.

So the supporting KPIs would be:

  • Percentage improvement in maintenance schedule over the life of an asset (not too much, not too late)

  • Improved speed for incident management to identify faulty CIs and restore service

  • Reduction in the average time and cost of diagnosing and resolving incidents and problems (by type)

  • Improved ratio of used licenses against paid-for licenses

  • Improvement in time to identify poor-performing and poor-quality assets

  • Reduction in risks due to early identification of unauthorized change

  • Reduced percentage of changes not completed successfully or causing errors because of poor impact assessment, incorrect data in the CMS, or poor version control.

SACM CSFs And KPIs (3 of 3)

In this section, let us take the next CSF which states:

  • Establishing and maintaining an accurate and complete configuration management system (CMS)

So the supporting KPIs would be:

  • Reduction in business impact of outages and incidents caused by poor service asset and configuration management

  • Increased quality and accuracy of configuration information

  • Improved audit compliance

  • Shorter audits as quality configuration information are easily accessible

  • Fewer errors caused by people working with out-of-date information

So far, we looked at the triggers, inputs, outputs, interfaces, CSfs and KPIs of SACM. In the next section, let us look at the risks and challenges of this process.

The challenges and risks of SACM

Challenges to SACM include:

  • Persuading technical support staff to adopt a checking in/out policy – this can be perceived as being a hindrance to a fast and responsive support service. If the positives of such a system are not conveyed adequately, then staff may be inclined to try and circumvent it. Even then, resistance can still occur. Placing this as an objective within their annual appraisal is one way to help enforce the policy.

  • Attracting and justifying funding for SACM, since it is typically out of sight to the customer units empowered with funding control. In practice, it is typically funded as an ‘invisible’ element of Change Management and other ITSM processes with more business visibility.

  • An attitude of ‘just collecting data because it is possible to do.’ This leads SACM into a data overload which is impossible, or at least disproportionately expensive, to maintain.

  • Lack of commitment and support from management who do not understand the key role it must play supporting other processes.

Risks to successful SACM include:

  • The temptation to consider it technically focused, rather than service and business focused, since technical competence is essential to its successful delivery

  • Degradation of the accuracy of configuration information over time that can cause errors and be difficult and costly to correct

  • The CMS becomes out of date due to the movement of hardware assets by non-authorized staff. Half-yearly physical audits should be conducted with discrepancies highlighted and investigated. Managers should be informed of inconsistencies in their areas.

Looking to learn more about ITIL Intermediate RCV? Why not enroll in our Course!

Typical SACM activities performed on a daily basis by SO

Service asset and configuration management are primarily covered in ITIL Service Transition, but there are some aspects that service operation staff will be involved on a day-to-day basis.

Examples of these include:

  • Informing service asset and configuration management of any discrepancies found between any CIs and the CMS

  • Making any amendments necessary to correct any discrepancies, under the authority of service asset and configuration management, where they involve any service operation components or services

  • Labeling and tagging physical assets (e.g., serial numbers and barcodes) so they can be easily identified

  • Assisting with audit activities to validate existence and location of service assets.

Responsibility for updating the CMS remains with service asset and configuration management, but in some cases operations staff might be asked, under the direction of service asset and configuration management, to update relationships, or even to add new CIs or mark CIs as ‘disposed’ in the CMS, if these updates are related to operational activities actually performed by operations staff. Operations staff may also assist service asset and configuration management activities by communicating changes in state or status with CIs impacted by incidents.

With this we have come to the end of the learning unit 3, let us quickly summarize in the next section.


In this learning unit, we have covered topics on:

  • Purpose, objectives, and scope of the SACM process

  • Basic concepts, principles, and activities of SACM process

  • Details about key concepts of CI, CMDB, CMS, and DML

  • Triggers, inputs, and outputs

  • Interfaces with other service management processes

  • CSFs and KPIs for the process

  • Challenges and risks and the typical SACM activities carried out in Service Operation

The next lesson focuses on Service Validation and Testing.

  • 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
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*
Work Email*
Phone Number*
Job Title*