Organizations are increasingly trying to combine what were traditionally separate IT Asset Management ITAM) and IT Service Management (ITSM) functions. These business processes may also assume other names such as IT Cost Management, Business Service Management, and others. The motivation for combining processes may be driven by the implementation of a tool or suite of tools that incorporates both ITAM and ITSM, or the desire to integrate the data from two (or more) different systems used by ITAM and ITSM teams.
Coming from an ITAM, and not an ITSM background, it is useful to understand some common ITSM processes, and how they feed into ITAM processes. The following are two common ITSM objectives and considerations for the ITAM teams: the Request Fulfillment process and the organization of Business Services or Business Service Management (BSM). Both are usually carried out in ITSM initiatives, as opposed to ITAM initiatives, but may have impact on the ITAM team. It can also be useful for ITAM teams to have some awareness of these ITSM processes, in order to identify opportunities to leverage each other’s systems and data.
In the ITAM world, it can be useful to view operations simply in terms of the IT asset lifecycle. This can be used as a simple way to understand IT Asset Management since it’s conceptualized as a linear timeline of the asset from the time it is sourced, through the time it is managed/used, until it is decommissioned and disposed.
Request Fulfillment typically lives in the ITSM, and not the ITAM world, and is related to the Service Catalog in the ITIL framework for IT Service Management. On an IT asset lifecycle chart, this is at the very beginning of the ITAM lifecycle.
In ITSM, the process is typically an end-user making a request and that request ultimately being fulfilled. In ITAM, this translates to a new asset entering the environment and capturing all of the data attributes we need to capture for ITAM purposes.
The Request Fulfillment process works like this:
- An end-user requests an item, for instance, a new laptop computer
- A request approval process is initiated where managers in an organization typically approve or reject the request
- The item is sourced; either taken from existing stock or procured, usually through the use of a purchase order
- The item is in transit (either from the manufacturer or supplier in a procured item, or transferred from the stock room, for existing stock items)
- When the item arrives at its destination, it is received. Receiving is a typical ITAM function
- The item is configured and deployed to the end user who ordered it or the person it was ordered for
Considerations for ITAM include defining hooks that should have into the ITSM system. A hook is a trigger or integration of the process and/or data between ITSM and ITAM. In the case of Request Fulfillment, for the ITAM system, we need to track the following:
- Creation of the new asset (when the asset is procured and not taken from stock)
- Change in the asset location
- Change in the asset status
- Change in the asset assigned user
The ITAM system need not be concerned with aspects of the request process, which is in the ITSM domain. However, ITAM would need to capture the attributes such as location, status, or assigned user. These may also be tracked in the ITSM system as well, but that depends on the overall architecture of the ITAM and ITSM systems architecture.
Business Service Management
Business Service Management (BSM) manages IT assets collectively as sets of business services. Each of these services consists of a set of people, processes, and technology assets. Organized in this way, costs and service level agreements are aggregated into high level services which can be more easily understood by upper management to make high level business decisions.
An example of a business service may be “Email,” or “E-Commerce site.” These services each contain a number of IT components, individually called Configuration Items (CIs) in ITSM, for instance individual servers or software, and optimally a defined service level agreement. For instance, the service must be in operation 99% of the time, 365 days out of the year. This may be a server, software installation, or database.
In the ITSM world, organizing IT components into services has several advantages. It provides a separation of the business concern, the service, from the individual IT components. The relationships between individual items is defined for proposes of assigning cost and maintaining operational uptime.
Considerations for ITAM focus on the relationship of CIs to assets and may be viewed like this: a CI is an IT asset from the operational perspective such as how much disk or memory a server has. An asset is that same item from the financial perspective such as its cost or depreciation schedule. In combined ITAM/ITSM systems, assets and CIs can sometimes have a 1-to-1 relationship, but in the case of fixed assets, commonly used in accounting systems, a fixed asset may be 100 computers, managed as a single unit financially, while each individual server is considered an individual CI.
In these scenarios, the data elements and relationships can get complicated, so it’s important to have these well thought out and understood by those implementing and maintaining the ITSM and ITAM tools.
In this case, the individual CIs, their relationships to each other and the overall business service, are the responsibility of ITSM. For ITAM, we are interested in those CIs that also have financial attributes such as cost that we need to track in ITAM. Those assets contain the cost information, and by having those relationships, we can cost out the entire service. By having that cost information, we can also predict the cost of service outages or outages of different components in the system.
Certainly some of these goals of ITAM and ITSM are intertwined, so it’s a good idea for the ITAM professional to have some knowledge of the common ITSM processes.