Neven Zitek My personal view on ITSM was always in favor of Change Management being at the center of IT operations, because it enables you to perform changes in a controlled manner, allowing beneficial changes to be implemented with minimal (or no) disruptions to the service. Because everything we do can be classified as some form of change, this is where the service value comes from. Changes are performed on assets, or their configuration, ergo Change Management can’t exist without Service Asset and Configuration Management (SACM). You can read more about SACM in the following blog post: Three main activities to set up ITIL Service Asset and Configuration Management before we dive into the SACM Plan, which is a good foundation for any successful SACM implementation.
Purpose and scope
The purpose of the SACM Plan is to describe and define service assets, as well as activities and approaches to manage them across the lifecycle. Therefore, the SACM Plan should state the scope (i.e., service), activities, related processes and documentation that will be regulated, and how.
Internal and external regulation
As mentioned before, managing changes is one of the most important things we do in IT organizations; therefore, there is a strong possibility that our ability to perform them may already be regulated by internal policies, especially regarding business systems or applications (e.g., the financial and sales system and apps must not be disturbed in period x – y due to annual budgeting and planning activities, i.e., “Change freeze”).
If your IT organization is certified or following any standards (e.g., ISO/IEC 20000) that cover or overlap with SACM activities, such regulations or policies should be listed in your SACM Plan as well.
CI nomenclature
A Configuration Item (CI) is arbitrarily defined as the smallest configurable unit within the service. For example, in Managed Desktop service, we can declare a computer (with all of the predefined software) to be a CI. If all of the computers are the same, used in same manner and for the same purpose, this approach could actually work. In general, you want to split a service into Cis, which will likely be changed (e.g., hardware (CPU, HDD, RAM) and software). Since defining and naming CIs is an arbitrary process, it should be stated in your SACM Plan for future reference.
Relationships
Relationships describe how the configuration items work together to deliver the services. These relationships are held in the Configuration Management System (CMS) – this is the major difference between what is recorded in a CMS and what is held in an asset register. The relationships between CIs are maintained to provide dependency information. For example:
- A CI is a part of another CI – this is a “parent–child” relationship, e.g., email software is part of the operating system.
- A CI is connected to another CI – e.g., a server is connected to a local network (LAN).
- A CI uses another CI – e.g., email software uses email server software.
- A CI is installed on another CI – e.g., email software is installed on a desktop PC.
Processes, organization, and tools
Just as in any process, in order to make our SACM work we need some resources and roles: SACM process manager, configuration analyst, librarian, etc. Such roles with role descriptions and responsibilities should be listed in our SACM Plan.
Because the service lifecycle is filled with relationships and dependencies between processes, any related processes should be identified and listed in the SACM Plan as well. For example, Change Management can’t function at all without SACM.
If any tools will be used to support SACM activities (e.g., track purchases, configurations, changes, etc.), those should be identified and listed in the SACM Plan as well.
Baseline and verification
A configuration baseline is the configuration of a service, product, or infrastructure that has been formally reviewed and agreed, which thereafter serves as the basis for further activities and can be changed only through formal change procedures. The SACM Plan should contain a formal definition of that point in time, as well as any future plans on verification activities regarding CI configuration.
Definitive store and DML
You can read more about the Definitive Store and Definitive Media Library (DML) in this blog post: ITIL Definitive Software Library and Definitive Hardware Store. Suffice to say that the SACM Plan should reflect any Definitive Store and DML references.
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 will be a mismatch with the physical world. No CI should be added, modified, replaced, or removed without an appropriate controlling documentation or procedure being followed. The SACM Plan should reflect how you plan to maintain control (i.e., which roles and processes (e.g., Change Management) are responsible for maintaining control over the SACM).
You can’t manage what you can’t control
This last section of the SACM Plan is the place where the strong relationship between SACM and Change Management becomes clearly visible. While SACM will define and record service dependencies (assets and asset configurations), Change Management will define how we manage changes to them in a predictable and controlled manner that will ensure little or no service disruptions.
According to the ISO/IEC 20000 model, Configuration Management and Change Management are core processes of service control; therefore, there is no successful Service Management without service control mechanisms in place, and Service Asset and Configuration Management is only the first step in the right direction.
