Using inventory for compliance

It is best to leave calculations of license compliance to specialized tools such as TLCM and not infer compliance from inventory.

One difficulty in using an inventory model for software is that licenses are subject to compliance-related rules in addition to the accounting rules enforced in inventory. The compliance-related rules do not follow the simple logic of issues and transfers. The following are examples:

򐂰 Software with a license having machine scope cannot be transferred to another machine. Therefore it is not appropriate for such software to be issued to any machine other than the one designated on the license.

򐂰 Software with a license having capacity units of Processor Value Units (PVUs) can be installed only on machines with appropriate capacity.

򐂰 Software licensed with capacity units of concurrent users cannot effectively be accounted for in terms of installations. In this case, the accounting involved in issuing the license to an asset is probably inappropriate because the charges are related directly to a machine that is shared among departments.

The only case where this is appropriate is when a single department uses the

Account name Purpose

Receipts Price Variance This account is useful when you use the standard cost, and the receipt price in another storeroom differs from the vendor cost or the standard cost in the issuing storeroom (Standard Receipt

Adjustment). You can create this

transaction as a secondary transaction to a material receipt transaction.

Invoice Variance Currency Variance

Purchase Variance When using a budget and you want to use commitment accounting, you can customize Maximo Asset Management to use this account to store differences between PO costs and invoice costs.

Chapter 9. Tracking software inventory 169 machine and software or a single department absorbs costs by mutual agreement with the other departments.

򐂰 Issuing a software item from inventory to show where the software is installed is misleading when the inventory balance is interpreted as an indication of excess remaining capacity in non-installation licenses.

Even for installation licenses, inventory balances can give misleading

impressions if they are interpreted as an indicator of compliance. For example, the most common Microsoft installation licenses require the license to be assigned to both a machine and a primary user. Thus, compliance may require ensuring that neither the number of installed machines nor the number of users with access exceed the number of licenses. Because only the number of installations is easily discoverable, additional measures must be enforced at the time of installation to ensure compliance, such as checking the usage of the machine.

Whether a license is consumed on installation depends on the license type and the type of installation being performed. Table 9-3 lists examples.

Table 9-3 Licenses consumed on installation License type Installation Implied access to the files must be licensed.

In the inventory model, if it does not make sense to decrement the capacity of a license for an installation, it is possible to manually adjust the count of items in inventory to approximate license capacity. For instance, a license based on Named Users can be received into inventory and simply incremented or decremented each time an additional user is requested.

This procedure does not enable compliance checking, but it does leverage the existing inventory functionality so that work orders can reserve and consume the software as a material, automatically incrementing the balance and charging the appropriate GL codes. In this example, however, the count of items in inventory representing license capacity is thrown off by issuing the item to one or more assets to represent installation.

Showing software installations as spare parts issued to assets introduces serious compromises to the attempt to use inventory to track license capacity. In

Generic Oracle Named User server installation

No consumption Named Users are countable and may be

Chapter 9. Tracking software inventory 171 a Tivoli Asset Management for IT-only scenario, we have several sound but incomplete scenarios for using inventory to track license compliance:

򐂰 Installation licenses only

Use inventory to track software subject to installation licenses only, and issue the software to a hardware asset to show installation. This may generate appropriate accounting transactions depending on the accounts assigned to assets and storerooms, and inventory balances will reflect outstanding installation capacity. A clear procedure must distinguish between licenses that can be managed this way and those that cannot, such as using a different branch of classification to distinguish those kinds of software that can be reconciled as installations.

򐂰 Installations only

Use inventory to track software subject to all kinds of licensing, but do not use inventory balances at all to determine compliance or charge-back. Use issues to hardware assets to show installations. This scenario may be appropriate for organizations that do not use charge-backs and that have no other

mechanism for tracking authorized installations.

򐂰 Countable capacity only

Use inventory for all kinds of licenses, but do not issue to assets to show installations. Instead, issue to GLs, work orders, assets, and locations only for the purpose of creating charge-back transactions using the standard cost, average cost, or most recent cost features of inventory. This scenario might be appropriate in an environment where procurement is performed in Tivoli Asset Management for IT, but reconciliation is performed in CCMDB.

Although in general, we do not recommend tracking compliance through inventory, inventory can still be a useful tool for managing charge-backs and tracking authorized use of licenses.