This section provides information about the relationship between the Tivoli Change and Configuration Management Database (CCMDB) and Tivoli Asset Management for IT products.
Both CCMDB and Tivoli Asset Management for IT are designed to help you manage the components of your IT infrastructure, but in different ways. As its name implies, CCMDB emphasizes change and configuration management, whereas the emphasis of Tivoli Asset Management for IT is on asset
management. A certain amount of overlap exists between these management disciplines, and to some extent, the modules unique to each product can be made to work for the other product. In this section, we discuss what you can manage with each set of functionality.
Asset management is mostly concerned with financial aspects and responsibility, whereas configuration management is concerned with relationships and
dependencies between items. Both what is managed and how it is managed can differ between the disciplines.
Some items may have high visibility in asset management but little importance to configuration management, and vice versa. In asset management, the cost most likely determines the importance of an asset - either replacement cost or book cost. In configuration management, the number and kind of functional
dependencies probably determines an asset’s importance. A free software installation may be ignored by asset management but is integral to configuration management. Or a standalone punch-in device for employees must be tracked in asset management, but configuration management can effectively ignore the device.
On the discovery side, CCMDB relies on Tivoli Application Dependency Discovery Manager (TADDM) that reports asset inventory as well as
dependencies between the configuration items to almost any desirable depth.
Tivoli Asset Management for IT, on the other hand, includes a Deployed Asset Module designed to work with TLCM, which specializes in license management, or with any discovery tool that your organization has in place. These general discovery tools usually show the software that is installed on a piece of hardware, but otherwise, they do not trace dependencies between the software
components. The TADDM specialty is discovery of dependencies, whereas the
Chapter 8. Asset reconciliation 159 other tools may be more appropriate for resolving inventory in relatively
nontechnical terms adapted for asset tracking.
IBM plans to continue to integrate its discovery tools in the years ahead and will enhance the ability to coordinate discovery tools with deployment tools such as Tivoli Provisioning Manager. With Tivoli Asset Management for IT V7.1 and CCMDB, you can leverage the shared Tivoli process automation engine to see all aspects of an item from different viewpoints.
The primary means provided in Tivoli’s process automation engine for relating CIs and the asset management entities of Asset, Item, and Location, are links provided on the CI, available through the CI application. Similar links are provided on the work order-based applications (Work Order Tracking, Activities and Tasks, Changes, and Releases). In the work order applications, no
necessarily direct relationship between the CIs and the asset management entities exists, although values can be filled in where a relationship has been configured on the CI.
No means for directly relating Deployed Assets entities from Tivoli Asset Management for IT to Actual CIs from CCMDB currently exists. The most effective way to manage the relationship between these discovered entities is through authorized entities, using reconciliation. CIs are reconciled to Actual CIs, and Deployed Assets are reconciled to Items or Assets. A relationship is
maintained only between the Items or Assets and the authorized CIs and is implied through the reconciliation links to the discovered records. Whether the link is to item or asset depends on whether the asset is managed through the Assets application or Inventory application.
To the people responsible for managing these links, this sounds like a lot of work.
If the requirement were to manage, reconcile, and link every record, it would take too much effort for anyone. However, each organization must strike a balance between the value of the information being managed and the cost of managing it.
Part of the reason for reconciling records before linking them is that it is assumed that fewer records must be manage after reconciliation. Your organization should discuss and document guidelines about the records that must be managed and how to manage them:
Discovered assets usually hold a subset of information from the discovery tool, filtered by ITIC during transfer.
Assets usually hold a subset of information from deployed assets, only consisting of equipment and software that is kept on fixed assets books or managed through procurement.
Actual CIs hold a subset of records managed in TADDM, filtered during transfer.
CIs hold a subset of Actual CIs consisting of only those items whose configuration must be actively managed.
The links between CIs and Asset or Item only must be maintained for target items.
If your organization is small or just starting out with the management disciplines, it makes sense to limit the management of relationships between asset and configuration management entities to only a few target items, where such management is required. It might be needed in the following scenarios:
Asset managers may want to look at the total cost of ownership of a software program or platform, as traced through its dependencies.
IT technical managers may want access to financial data for context in making quick configuration management or capacity management decisions.
Discovery administrators may want to compare data sets between TADDM and other discovery tools for reconciliation purposes. The extent to which this is required depends on the factors listed in 8.2.4, “Redundancy” on page 142.
Change records are being used that reference both asset and CI records.
Configuring the relationship in the CI application allows for auto-filling of the information about the ticket and work order-related applications.
Configuration managers may want to trace asset moves and status from the CI.
8.7.1 Linking procurement records with CIs
It is easiest to create reliable links between discovered and authorized records soon after receiving the assets. If procurement, or at least receiving, is performed through Tivoli’s process automation engine, the inventory or asset record (or both) are tied to the procurement record. Unique information is recorded about the record such as serial number, machine name, MAC address, and asset tag.
Two paths can be followed for linking assets or inventory records to CIs. The CI can be created directly from an asset record, or it can be “promoted” from an Actual CI record after discovery takes place.
Technicians are more likely to prefer promotion of records because of the amount of detail that can be transferred automatically into the CI record. The main piece of unique or near-unique information that is in common between the asset record and the CI is the machine name. Once machines are matches, the software installed on the machines can be matched.
The machine name can be kept on the asset record as an added attribute or as a specification for IT classifications for networked assets. Technicians who
Chapter 8. Asset reconciliation 161 configure the asset network names probably have the asset physically in front of them, so they can read the serial number or asset tag, find the asset record created at receipt, and enter the name that they configure. A week or a month later, when the TADDM information is promoted to CI, an asset record is waiting to be linked to it. Periodic checking can be performed to ensure that all eligible asset and CI records are linked.
Different classification structures can be used for assets or Item Masters and for CIs. Synchronizing the asset classification structures to the common data model classifications can aid in linking records that are otherwise unidentifiable.
The CI includes two location fields. The Location field next to the Asset field on the CI window refers to the location of the asset named, if any, and is updated when the asset is moved. The CI Location field is provided in case a different location structure must be used for CIs and assets.
When you create an incident or change record, do you reference the asset or the CI or both? The answer to this question can depend on who is creating and reading the change record. A service desk analyst is most likely to have access to asset information through the serial number or tag reported by the user, whereas a change record is more likely to be created by a technician familiar with CI records. In either case, the missing information can be filled in before the record is marked complete. Configuring CI information provides a quick
cross-reference for dependencies, and configuring asset information supplies a reference for financial aspects that can be used in transactions and total cost reporting. Configuring the relationship between the asset and CI in the CI application means that one can be auto-filled from the other in these referring applications.
If an asset is taken out of service, it may be transferred to a storeroom or moved to a designated Operating Location, and the status changed according to whether it is being disposed of or repaired. The change in location is reflected on the CI record, and the link to the asset can be used to check the status.
What does it mean to configure an Item Master to a CI? A single Item Master is configured to the CI, but that does not imply a one-to-one relationship between them. CIs are generally used to show instances, while Item Masters represent a catalog entry. The main reason for the link is to show how the CI can be replaced.
If multiple Item Masters can be ordered as replacements, this information is provided in the Alternate Items section of the Item Master application (not on the CI). The Item Master can exist in various storerooms, lots, and bins in inventory, but because the CI record is only concerned with configuration, only the Item Master reference is needed. Locations and CI Locations are limited to Operating Locations and are used mostly in conjunction with asset references, not with Item Master references.
© Copyright IBM Corp. 2008. All rights reserved. 163