Branimir Valentic Talking about implementation of anything related to ITIL (be it a process, function, tool, report … etc.) always raises many questions. Although that’s good for consultants (there are always potential customers), people inside the IT Service Management (ITSM) organization feel – trapped.
There are processes that are not complicated (at least in the beginning) for the implementation. A bit of logic, i.e., common sense, some theoretical knowledge … and you are ready. Incident Management belongs to this category. On the other side are processes that need thorough preparation, a lot of experience, tools … and who knows what. Well, this is partly true, but – let’s not overcomplicate things.
How does SACM fit?
When talking about complexity of implementation, the Service Asset and Configuration Management (SACM) process belongs at the upper end of the complexity scale. I’d like to claim that I’m talking about my own opinion, but the fact is that many of my clients believe the same.
SACM is crucial for many other ITSM processes, which makes the implementation even more challenging. This means that the quality of the implemented SACM process influences the efficiency of other processes. Why is that? SACM is like a diet – in this or some other way you’ll manage to lose the targeted amount of weight, but then the difficulties begin – how to keep that weight off for the long term. Applied to SACM – you implement the process and populate the CMDB (Configuration Management Database, read the article Knowing your herd – Service Asset and Configuration Management (SACM) to learn more about the CMDB), but then the “party” starts. Changes, new requirements, incidents … they all influence the content of the CMDB and you have to fight really strongly to avoid inconsistency (e.g., change data of your Configuration Items that are not recorded in the CMDB).
5 questions
By doing consulting and webinars, I get in touch with many people in ITSM. Some of them are highly skilled (and I can learn from them as well), and some of them are at the beginning of their “ITSM journey.” What is common to all of them is that they have questions when we discuss SACM. Here is a selection of the five most commonly asked:
1. How is SACM related to other processes?
More or less, all ITSM processes use (and benefit from) implemented SACM and particularly CMDB, foremost Incident Management, Problem Management, and Change Management (as the most visible ones). That’s because the services you provide are composed of service assets (HW, SW, people, process or other documentation, etc.). Most of them are CIs, which need to be managed. Managed means – to know exactly which CIs you have, which SW version, where your HW is located, what is the relation between HW and SW or different HW components … etc. This brings the idea to implement SACM before other processes. I would say this is correct, if possible. If not, leave some room while implementing, e.g., Incident Management for future SACM implementation. Learn more in the article Three main activities to set up ITIL Service Asset and Configuration Management.
2. Which tools should I use?
I usually get questions like what kind of (e.g., open source or not, how many ITIL supported processes … etc.) tool, which is always hard to answer precisely because organizations have different needs and budgets. If you need to integrate a lot of processes and interfaces to other tools as well as making a lot of customizations – open source is not the best fit. But, for smaller organizations and their needs – there are a lot of pretty good open-source tools; but, be aware – you get what you pay for. Additionally, discovery tools can help you to fill in the CMDB (as well as with snapshots, i.e., audits). When choosing a tool, take care about interfaces to other tools (e.g., ticketing system, fixed asset register, i.e., ERP). Read the article Free tools for ITSM – supporting IT Service Management for zero tool cost to learn more.
3. How do I measure efficiency?
Here we get to KPIs (Key Performance Indicators) and CSFs (Critical Success factors). CSFs are derived from goals set through ITSM implementation, and are descriptive. KPIs are parameters you will measure. Or, you can think of CSFs as groupings of KPIs with the same target. For example, your CSF is establishment of an accurate CMS, and a respective KPI is your CMDB audit result, which must show that less than 3% of CIs contain faulty or inconsistent information. When you decide about CSFs and KPIs, try to stay as practical as possible and don’t generalize; make KPIs measurable and make everyone involved agree on them. And, define CSFs and KPIs for both a SACM process as well as for the CMDB.
4. How do I determine the scope?
I.e., what to include in the CMDB and how far to go (i.e., breadth and depth). That’s a very important question. It will guide all further activities. Unfortunately, there is no one-size-fits-all solution; that is, every organization must define these for itself. Analyze what kinds of information you need to, e.g., assess changes or resolve incidents. For example, if you need information about a user’s laptop and the laptop’s processor or amount of RAM – that would be your CIs. If you don’t need that information – they are not. E.g., you need to upgrade all PCs to a new OS. So, most probably you need information about the PC’s processor and amount of RAM.
5. How do I start the implementation?
Without going into every organization’s details (and they could differ, e.g., having a tool capable of supporting SACM and CMDB, or having in place some of the ITSM processes), I would say – start with a good plan. Your plan should include reference to the regulation (if needed), scope of the implementation, tool description, roles and responsibilities definition, nomenclature (for the CI’s identification and labeling) … etc.
Is that all?
No, it’s certainly not. Since SACM covers most of the processes and service assets, we could spend much more time on debating about different aspects of the implementation. And, that’s one half of the story. The other one begins once you are in the operational environment. In that stage there are even more challenges and pitfalls. But, they have a common root – implementation of the process. Depending on implementation, you’ll make your life either easy or terrible on a daily basis. The only certain thing is – it depends on you, and that chance shouldn’t be missed.
Use this free ITIL Gap Analysis Tool to see how your SACM process fit to ITIL recommendations.
