Branimir Valentic Starting from scratch gives you the opportunity to set things up as you find appropriate. This is also true for processes. The first time I had a project task to establish a Service Asset and Configuration Management (SACM) process I felt happy, because nothing existed at that time. With little hassle and after some basic preparation we started implementing the process. At that time it sounded logical, but it was not.
What went wrong is that after we covered all assets, created relationships between them, and included other processes – it became less and less usable. Result – we had to redo the job. The point is that the beginning of the process implementation was not done properly.
I suggest that you read the article “Knowing your herd – Service Asset and Configuration Management (SACM)” to learn the basics of SACM according to ITIL.
1, 2, 3… of the SACM setup
SACM sounds complicated. It has a long and not easily understandable name, encompasses many new words (e.g., Configuration Item, Snapshot, Baseline…), and has interfaces to almost all processes in your service’s lifecycle.
But, as with many other things in life – a good foundation is the logical response to your concerns about how to implement the SACM process. Basically, there are many activities in the scope of SACM, but we can group them as follows:
- Planning
- Identification
- Control
And, that will get you to a defined and implemented SACM process. Once you are done, the operational part begins.
Figure: Stages of the SACM process setup
Planning
This is the phase where you have to have your eyes wide open. Start with the policy (by the way, that’s always a good start), which is your guideline while setting up the process and interfaces to other processes. The policy contains the scope (e.g., whole organization, or only certain parts) and objective of the process, but also defines level of control of your CIs, as well as how to integrate SACM and other processes you have in place.
The SACM plan is a product of this phase. This is the document that is produced for, e.g., a particular service and defines assets and activities for that particular service and approach to managing them. Other items that are considered in the scope of planning activities are, e.g.:
- Compliance with the standard (e.g., ISO 20000) or other internal/external regulations
- Organization setup and interfaces to other organizational units
- Tools
Identification
Well, in this phase, things are becoming complicated. In the planning stage you decided which Configuration Items (CIs – a service asset that needs to be controlled and managed) you need and how you will identify or name them. Activities performed in this stage of a process setup include:
- Selection of CIs – CIs exist on different levels (e.g., a CI can be your laptop, but also the laptop’s processor and amount of hard disc capacity). Tools can be of great help in this activity.
- Naming – make thorough preparation to find a suitable naming convention for your CIs. Make sure that CIs are uniquely named, and that you leave space for future growth of the CIs.
- Labeling – so, you identified your CIs, you have names for them, and now you have to label all your (physical) CIs. When doing this, be sure to choose a unique labeling method (e.g., bar code stickers) and durable and easily identifiable labels (e.g., make a rule of how to label different types of equipment like laptops, monitors, printers, etc.)
- Setting attributes – attributes are information that describes the CI in more detail. Mandatory attributes would be a unique identifier and CI type. There could be many non-mandatory attributes, e.g., name, version, status, etc.
- Documenting relationships – these are the parameters that describes how CIs work together to deliver the services. E.g., one CI can be connected to another CI (a laptop is connected to the router) or could be part of another CI (SW is installed on a laptop).
- Producing a baseline – a baseline is an approved configuration, and it’s used as a reference point. For example, you will audit your configuration to check whether all CIs are up-to-date. This means that you will take the status of the configuration at one moment in time and compare it with the baseline. In such way, you will see if there are differences between those two configurations.
Control
Let’s put it this way – if you make a mistake in this phase of the process setup – all previous activities are worth (almost) nothing. Once you gather all data about CIs, you should put them under control, meaning that no change, addition, or deletion of a CI is possible without approval. The easiest way to implement such control is to have one dedicated person who can make changes to CIs, and to document the exact procedure of how and in which situations that person can change CI data.
So, your SACM process is now ready for the operational stage (when the service is in the live environment and customers start using it). It’s important that all your plans are executed in process implementation as well as the operational stage.
Building on good foundations
Let me ask you something: Can you build a house without a solid foundation? Certainly not. It’s the same with your SACM process. Interfaces and cross-connections with other processes emphasize this fact even more. Just try to imagine assessment of change (find out more about change assessment in the article “Three key elements of assessment and evaluation of changes according to ITIL”) without proper information about affected CIs.
And, if you consider that your IT Service Management organization and processes are also CIs, by setting up good SACM you will create prerequisites for control and management of your services. And, believe me, your customers will respect that.
Use this free ITIL Gap Analysis Tool to assess your SACM process based on ITIL recommendations.
