Do opposites really attract?
Service management has evolved from humble beginnings as a “help desk” supporting the operational back office to handle internal IT support tickets. Today it is a modern solution which has shifted service management to the front office to empower the end users beyond IT tickets while providing the business services context. IT Asset Management has also evolved to bridge both the operational and business teams, shifting from a dysfunctional to an essential partnership with Service Management.
“An incentive is a bullet, a key: an often tiny object with astonishing power to change a situation.” (Steve D. Levitt, Freakonomics, 2010)
I reference this quote because as an analytical person who studied Economics, I enjoy the principles of supply and demand, and cause and effect. I agree with Mr. Levitt about how incentives (or what others may call “drivers”) play an important role in our lives on many levels, both personally and professionally. In this blog, I explore the professional side, more specifically, how incentives have driven IT Asset Management and Service Management to become a modern family.
To Be or Not to Be?
Now some may argue that these two disciplines have been married for years, while others attest that at best they should just remain friends; however, in my nearly 20 years of experience in this industry, I’ve seen the shift as the incentives have overtaken the prior roadblocks and perceptions, driving increased adoption in many cases out of necessity. A few of the most common incentives/drivers for this alignment are:
- IT Department’s Pressure to Justify/Maintain Existence (aka Digital Transformation) – End users have more options and less patience today as compared to previous years. They expect a user experience in the business world similar to the social world. IT departments are forced to adapt to become the broker of services, not just the provider of services and support in order to combat shadow IT.
- “The Sum is Greater than the whole of its parts” – The alignment of IT Asset Management and Service Management benefits multiple teams by improving efficiencies (ex. duplicate effort in managing similar/overlapping data) and sharing information. Don’t get me wrong, I still see many organizations with disparate data, teams and processes, but I see more organizations driving towards a more consolidated, efficient and aligned approach than I have seen in the past (i.e. rationalization). More organizations are overcoming the hurdles when multiple groups converge on similar, but different needs. Once organizations have a clear understanding of the common but different requirements (think venn diagram), they expose joint opportunities to share some of the processes, people and technologies.
- Empowering End Users – In keeping with the theme of addressing the expectations of end users in this Digital Transformation, the underlying need is to empower the users who both support and power the business. From the support perspective, there is tremendous value in providing these back office users (i.e. Service Desk) with enhanced information to more effectively and efficiently handle support and service needs. From the end user perspective, there is power in providing these business users with relevant information (ex. assigned device and device details) to quickly and intuitively request, receive and/or address support or service needs. This ties back to the first point to empower users in order to mitigate shadow IT.
Why the cold feet?
So why do some organizations co-parent instead of get hitched when it comes to Service Management and IT Asset Management? I see three primary reasons for the resistance to alignment:
- Challenge 1: Interpretation – There are a range of definitions across an array of sources, including standards (ex. ITIL) and industry analysts. ITIL provides a solid definition from the Service Management side, but provides limited coverage on IT Asset Management. The International Association of IT Asset Managers (IAITAM) is a great source of information covering the breadth and depth of IT Asset Management. In many cases, there is room for interpretation at both the higher and lower levels of these disciplines. Please refer to the definitions section below to start the discussion and evolve the alignment. To learn more about how to build a successful Asset Management program: 7 Key Steps, please refer to this blog.
- Challenge 2: Intent – One challenge is addressing the perception that a configuration management database (CMDB) supports an organization’s asset management requirements. In my experience, this is typically not the case. Depending on the maturity levels, there are different processes, data points, goals, etc. for configuration management and configuration items vs. asset management and assets, but it mainly boils down to “intent” and outcomes. Similar to an asset management repository, a CMDB for many had initially become a dumping ground for data and inflated expectations. This was typically driven by a lack of planning across one or all of the key pillars: organization, process and technology.
- Challenge 3: Technology – Many solutions in this industry originally evolved from the help desk. In many cases, IT Asset Management was not initially considered or it was assumed that the CMDB would support the same requirements as needed for ITAM. Many organizations eventually felt like they were trying to fit a square peg into a round hole and either heavily customized their service management solution or accepted the limitations at the expense of not meeting their full set of ITAM requirements. There is no need to compromise.
Recommendation: To overcome these common hurdles, establish a cross-functional team and define your service and asset management requirements. This will initiate the discussion for alignment and flush out the differences and similarities in order to determine the necessary people, processes and technologies necessary to meet your needs. Make sure you establish a phased approach with a focus on mutual success in the initial phases to establish momentum and confidence in results.
Two Hearts Beating as One
To first understand the differences, we must understand the intent and goals behind these disciplines. To assist with the dialog to drive alignment, below are several definitions you may choose to use to start your cross-team discussions or you can also choose other sources as referenced above (ex. IAITAM, ITIL, etc.).
What is Configuration Management?
In simple terms, Configuration Management is a Service Management process which is part of the high level Service Asset and Configuration Management process to manage the Configuration Items including their lifecycle and relationship to other CIs in the CMDB to ultimately improve and/or maintain a high level of service. Typically, from a high level data perspective, the focus is on key identifiers (ex. name, tag, serial number, etc…), configuration and relationships.
ITIL v3 Definition: The process responsible for maintaining information about configuration items required to deliver an IT service, including their relationships. This information is managed throughout the lifecycle of the CI. Configuration management is part of an overall service asset and configuration management process.
What is IT Asset Management?
In simple terms, Asset Management is about managing assets, their lifecycle, costs and terms to optimize/minimize costs while mitigating risk. Typically, from a high level data perspective, the focus is on the key identifiers (ex. name, tag, serial number, etc…), lifecycle (i.e. status), ownership (ex. PO number, owner and associated organizational information (ex. cost center, department), costs and terms.
Gartner’s Definition: ITAM entails collecting inventory, financial and contractual data to manage the IT asset through its lifecycle. ITAM depends on robust processes, with tools to automate manual processes. Capturing and integrating auto-discovery/inventory, financial and contractual data in a central repository for all IT assets enables the functions to effectively manage vendors and a software and hardware asset portfolio from requisition through retirement, thus monitoring the asset’s performance through its lifecycle. (Source: Gartner IT Glossary, 2015)
What is a Configuration Item (CI)?
In simple terms, a CI is an object/item stored within the CMDB which ideally is under some level of management/change control. The primary goal of a CI is to track/manage its relation and impact to a business service; however, lower mature organizations may create a CI simply based upon what is discovered by their discovery tool. The higher mature organizations will focus on value, change control and process to identify and manage CIs. CIs may vary widely in complexity, size and type. They should be selected in accordance with established selection criteria, grouped, classified and identified in such a way that they are manageable and traceable throughout the service lifecycle. Configuration types are likely to include: Service lifecycle CIs, service CIs, organization CIs, internal CIs, external CIs, interface CIs.
ITIL v3 Definition: Any Component that needs to be managed in order to deliver an IT Service. Information about each CI is recorded in a Configuration Record within the Configuration Management System and is maintained throughout its Lifecycle by Configuration Management. CIs are under the control of Change Management. CIs typically include IT Services, hardware, software, buildings, people, and formal documentation such as Process documentation and SLAs.
What is an Asset?
At a high level, it is almost always about the money. An asset typically represents an object/item which the organization is tracking for the purposes of managing cost and/or mitigating risk. The source for high mature organizations is typically from procurement, advanced ship notices (ASNs), etc.–sources which identify ownership. The low maturity organizations may lean on discovery sources to initially identify their assets and ideally develop more mature processes and policies to gain better control over their assets, shifting from reactive to proactive management. I’ve included ITIL’s definition of an asset, which is more slanted towards the definition of a CI than what most organizations I’ve encountered view as assets.
ITIL v3 Definition: Any Resource or Capability. Assets of a Service Provider include anything that could contribute to the delivery of a Service. Assets can be one of the following types: Management, Organization, Process, Knowledge, People, Information, Applications, Infrastructure, and Financial Capital.
What is a Configuration Management Database (CMDB)?
The CMDB holds “live” environment configurations. Any authorized changes to Configuration items should be notified and recorded in the CMDB. The CMDB holds all the information for CIs within the designated scope of Configuration Management. The CMDB is used to maintain the relationships between all service components and any related incidents, problems, known errors, change and release documentation. It can be used for a wide range of purposes and typically contains configuration data and information that can be combined to provide an integrated set of views to satisfy stakeholder needs throughout the service lifecycle.
Can an Asset be a CI and a CI also be an Asset? What is the difference between a Configuration Item (CI) and an Asset?
This is a very common question. Yes, there can be commonality between CIs and assets. It starts with the core information (i.e. name, model, location, owner, etc.), but then some of the extended data for a CI is not critical and/or relevant for an asset and vice versa. The Enhanced CMDB within Remedyforce supports both the overlap and separation, depending on each organization’s own definition of these two and eliminates data duplication and synchronization issues. As a result, organizations have full control over the CI and asset views along with which users have access to these views. Organizations can also choose to only manage CIs or assets.
Another way to explain the difference is to understand the intent and goals of each. At a high level, a Configuration Item (CI) is a term used within the Service Management and Configuration Management disciplines. Quite simply, a CI by virtue of a relationship forms a service that delivers a value to a service consumer. An asset may have some common data elements (ex. Device name, tag, etc…) but the focus is more on the financial and contractual aspects. That said, this shift to a modern family is exposing the synergies and how asset management is shifting from a traditional asset view to more of a service oriented view, which tends to fall on the Service Management side. Below is a high level comparison of the general differences between Assets and Configuration Items (CIs):
In summary, evaluate your Service Management program to understand Asset Management’s current role. If you have two teams with disparate people, processes and systems, I encourage you to establish a cross-functional team to discuss opportunities for alignment and efficiencies. The results will benefit everyone, not only your service management and asset management teams, but also your end users and/or customers who have high expectations. Embrace the modern family.