Inventory Management System

Section Table of Contents

1. INVENTORY MANAGEMENT
1.1. INTRODUCTION TO INVENTORY MANAGEMENT
1.1.1. DEFINITION
1.1.2. SCOPE
1.1.3. MISSION
1.1.4. OBJECTIVES
1.1.5. FUNCTIONAL AREAS.
1.1.6. INTEGRATED INVENTORY MANAGEMENT SYSTEM
1.1.7. SMC DISCIPLINE INTERFACES
1.1.8. INVENTORY MANAGEMENT DISCIPLINES AND INTERFACES

1.2. PROCESS DESCRIPTION

1.2.1. NETWORK
1.2.2. SYSTEM
1.2.3. INVENTORY MANAGEMENT PROCESS
1.2.4. INVENTORY MANAGEMENT FLOW

1.3. PROCESS FLOW.

1.3.1. 1. NON-CONTROLLED ACR ENTRY:
1.3.2. 2. CONTROLLED ACR ENTRY:
1.3.3. IMPLEMENTATION OF INVENTORY MANAGEMENT
1.3.4. SYSTEM ENVIRONMENT
1.3.5. NETWORK ENVIRONMENT
1.3.6. DATA REQUIREMENTS FOR INVENTORY MANAGEMENT
 1.3.7. INVENTORY MANAGEMENT DATA MODEL
1.3.8. COLLECTING, MONITORING AND REPORTING DATA
1.3.9. INVENTORY MANAGEMENT RECORD HIERARCHY

1.4. DISCIPLINE RELATIONSHIPS

1.4.1. BUSINESS FUNCTION INTERFACES
1.4.2. SYSTEM MANAGEMENT INTERFACES

1.5. INVENTORY MANAGEMENT TOOLS

1.5.1. ASSET MANAGEMENT AT THE SYSTEM TO SERVER LEVEL
1.5.2. INDUSTRY STANDARDS
1.5.3. DOWNSTREAM NETWORK SERVER CONFIGURATION AND INVENTORY
MANAGEMENT

1.6. ROLES AND RESPONSIBILITIES

1.6.1. INVENTORY MANAGER
1.6.2. INVENTORY CLERKS

1.7. PROCESS EVALUATION

1.7.1. PRESENT SYSTEM WEAKNESSES
1.7.2. RECOMMENDATIONS FOR IMPROVEMENT
Section List of Figures

FIGURE 1. ASSET MANAGEMENT PHASES AND OPERATIONS

FIGURE 2: OVERVIEW OF INVENTORY MANAGEMENT FUNCTIONAL AREAS.
FIGURE 3: OVERVIEW OF AN INTEGRATED INVENTORY MANAGEMENT SYSTEM.
FIGURE 4: SMC DISCIPLINE INTERFACES .
FIGURE 5: INVENTORY MANAGEMENT SYSTEM - OVERVIEW OF PROCESS
FIGURE 6: INVENTORY SYSTEM FLOW DIAGRAM
FIGURE 7: INVENTORY MANAGEMENT DATA MODEL
FIGURE 8: INVENTORY MANAGEMENT RECORD HIERARCHY
FIGURE 9: ASSET MANAGEMENT AT THE SYSTEM TO SERVER LEVEL
FIGURE 10: DOWNSTREAM NETWORK SERVER AND INVENTORY MANAGEMENT
1. Inventory Management

1.1. Introduction to Inventory Management

1.1.1. Definition

Inventory Management is an enterprise-wide discipline concerned with the identification and

tracking of Information Services (IS) hardware and software assets. Its three main areas of
concern are:

Acquisition.
Redeployment.
Termination.

Can be sorted by: Equipment Type,

Disposition, and Location
Pick-Up List
Equip. Type: Disp: Location:
PC A Bldg 3, Rm 203
Start PC R Bldg 1, Rm 405
PC T Bldg 2, Rm 501

Disposition = A

Acquire Purchase Install Add to Master

Equipment Order Equipment Master Inventory Inventory
Equipment is being Actively used
Disposition = R N, Exceptions List Generated

Re-deploy Compare to Y
Work Pick-Up Warehouse
Master Inventory
Equipment Order Inventory Inventory
Equipment is moved to new location
Perform Service
Services Order
Disposition = T

Terminate Work Service Ready-to-Sell Purchase Release Finance

Equipment Order Order Order Form Form
Inventory
Equipment is Sold or Disposed of Marketing & Sales

End Archive

Figure 1. Asset Management phases and operations

Acquisition procedures are established to assist personnel in procurement of software and
hardware products. Its main purpose is to ensure that proper justifications are performed and that
financial guidelines are followed. Acquisitions require Purchase Orders to track and authorize
the purchase, while the actual installation of equipment is performed by the Infrastructure or
Facilities Management Department. Once added to the environment, a Master Inventory record
is created to describe the newly added equipment and its components (i.e., Pentium IV PC with
512 MB or RAM, a 40 GB Hard Drive, CD Drive, Floppy Drive, Sound and Video Cards, a 56
KB Modem and a 10/100 Ethernet Connection, etc.). Inventory records can be used to calculate
the resale price of existing equipment, when planning for an upgrade / replacement or reduction
in size. The Inventory Report can be used to inform buyers of your stock and obtain bids on the
purchase of your surplus equipment.

Redeployment procedures are responsible for ensuring that assets are tracked when moved from
one location to another and that budgetary considerations are adjusted as needed. Should a
product be moved in from its original owner, then the Inventory System is updated to reflect the
new location and owner. In this case, the old product is deleted from the original owner's budget
and added to the new owner's budget. If equipment is being deployed from one person, or
location, to another, then a data wipe operation must be performed to insure that sensitive
business, personal and/or medical information has been deleted. If data wiping procedures are
not performed in accordance to Department of Defense standards, then the company is open to
legal and civil penalties as defined in a number of laws (i.e., Sarbanes-Oxley, Gramm-Leach-
Bliley, HIPAA) Redeployment requests can generate transportation activity (pick-up and
delivery of equipment), facilities management activity (disconnecting device, data wipe,
reconnecting device, etc.), inventory management update, and service activities associated with
the device(s) being moved.

Termination is responsible for deleting the asset from the inventory when it is discontinued, or
replaced. The owner's budget will be updated to reflect the asset termination and the asset will
no longer be listed when location reports are generated. Whenever equipment is being
terminated (even if for donation to charities or employees) a data wipe operation must be
performed to eliminate any sensitive information from the hard drive. Additionally, a certified
vendor must be utilized to insure that the computers components are disposed of in an
environemtally friendly manner. This scrapping process must be certified, so that legal and civil
penalties are no longer the responsibility of the terminating firm but rather the scrapping
organization.

The Inventory System is maintained within a data base that ties an asset to its owner and defines
the location where the asset resides. The relative importance of the asset is added to the
inventory record in a Criticality field (i.e., Criticality = 1-5, where 1 is "Most Critical") and the
current status of the equipment is indicated via a status field (A=Active, R=Redeploying,
D=Donated, T=Terminated, etc.). Based on this information the contingency planning specialist
can plan asset recoveries needed to support critical business operations and the facilities
management group can schedule work events associated with equipment status changes (i.e.,
from A to R, or A to T, or A to D, etc.).
Like all data bases, the Inventory System will only be effective if its information is kept current.
To ensure the accuracy of the Inventory System, while not adding too great a burden to company
personnel, every effort must be taken to implement processes that maintain inventory data with a
minimum work effort from personnel. To that end, we suggest automated form tied to equipment
status and criticality changes, so that facilities management and business continuity planning can
adjust their functions accordingly.

Inventory Management provides:

Up-to-date information about data processing resources through the creation and
archiving of records in a centralized repository.

Financial records specific to a single component, or groups of components.

Component Status Indicators to identify a component as Active (A), Redeployed (R ),

Donated (D), or Terminated (T).

Component Criticality definition (1-5, with 1 being most critical).

Service records for all components in the inventory.

Data used to support configuration diagrams of the hardware and software components
contained within specific locations, or the entire data processing environment.

Reports can be generated from the Inventory and Asset Management Systems that would
project the amount of revenue that can be generated through the sale of surplus equipment, or
to define the number of components that have a criticality rating of 1 so that you can project
the costs associated with maintaining duplicates of critical equipment at reovery sites.
Combining the two reports would allow you to reroute equipment being scheduled for
termination to the Recovery Facility and eliminate the additional costs associated with
purchasing duplicate equipment in support of recovery needs.
1.1.2. Scope

The Inventory Management discipline encompasses all system and data network elements from
the mainframe to the server level throughout the enterprise.

All mainframe and data network based hardware and software assets must be identified and
entered into the Inventory System. Any changes to these environments must be reflected in the
Inventory System.

Financial and technical product information must be available through the Inventory System, as
needed to support the functional responsibilities of personnel within the finance and contracts
management departments.

Asset criticality must be included with asset descriptive and financial information, so that the
Recovery Management department is supplied with the information it requires. Recovery
actions must be implemented to safeguard critical assets.

Asset status must be included in the Inventory Management system, so that the component(s) can
be serviced in adherence to legal, environmental, business, and industry requirements. This
process should be used to drive the facilities management department via form routing when
components change status from active to redeploy, donate, terminate, of scrap. An audit trail of
activities associated with equipment status changes and associated actions must be maintained to
certify actions and eliminate legal and civil exposures.

The Standards and Procedures Manual section relating to Inventory Management must be created
and published. This section must describe the process by which assets are identified, entered into
the Inventory Management System, tracked, and finally deleted. All information needed by
personnel to perform Inventory Management functions must be clearly described within this
S&P Manual section.
1.1.3. Mission

The mission of an Inventory System is to provide a Central Asset Repository of information used
to define assets and relate the asset to its; owner, location, and relative importance. This
information will provide personnel with data needed to support their job functions, for example:

Facilities Management will be able to plan Heating, Ventilation and Air Conditioning
(HVAC) requirements, as well as power and floor space needed to support equipment listed
in Asset Repository for a specific location. To also perform the functions needed to adhere to
legal, environmental, business, and regulatory requirements associated with equipment
redeployment and termination.

Financial Services will be able to budget for asset procurement, depreciate assets over
time, and complete tax documents. A report of equipment and their resale value can be used
to aid in planning equipment upgrades and to reduce the Total Cost of Ownership
associated with equipment.

Contracts Management will be able to negotiate vendor discounts and enterprise

agreements. Additional vendor agreements may be required to support transportation and
warehousing, equipment service and reconfiguration requirements, data wipe services and
products, buyers, and scrap dealers.

Contingency Planning personnel will be able to develop recovery plans for mainframe
and office assets contained within the Inventory System, based on the assets relative
importance (as stated within the Criticality field). Surplus equipment may be utilized to
support recovery operations, if needed.

Technical personnel will be able to resolve problems more quickly with the information
contained within the Inventory System, because they will have a listing of the assets
contained within a location.

The Inventory System should be integrated within the everyday functions performed by
personnel associated with entering and maintaining asset information. The system will reduce
the effort devoted to asset management, while supplying many personnel with the information
they need to perform their functional responsibilities.
1.1.4. Objectives

The objective of Inventory Management is to manage the physical and logical properties of I/S
resources and their relationship, while ensuring that service level commitments are achieved.
This process will:

Ensure efficient and timely identification of vital corporate assets.

Assist in managing the enterprise-wide inventory.

Provide a common repository for asset protection.

Plan and control the proliferation of assets across the enterprise.

The objectives of Inventory Management are:

To identify and track all data processing assets in an Inventory System Repository.

To define the process by which assets are identified and maintained in the Inventory
System.

To provide Inventory System access to all necessary personnel (data entry, update
and deletion).

To provide a full range of reports that will satisfy informational requirements.

To document the Inventory Management System within the Standards and

Procedures Manual.

To provide training to personnel responsible for supporting the Inventory

Management System.
1.1.5. Functional Areas.

The functional areas that interface with an Inventory Management System are:

Inventory Management Departments Inventory Management is divided into

many separate areas of responsibility.

Finance

Inventory Management
Contracts

Mainframe Mid-Range PC / LAN Communications Fixed Assets

Voice Data Network

Hardware

Software

Facilities Common areas of concern

faced by each department
Vendor

Financial

Figure 2: Overview of Inventory Management functional areas.

All of the functional areas listed above can utilize the information contained within the Inventory
Management System's Central Asset Repository of information. Additionally, the Recovery
Management area could utilize inventory information to identify an assets criticality (especially
when the asset's location and owner are identified within the Inventory Management System).
Through the use of reports generated from the Inventory Management System's Repository, it
would be possible to obtain a listing of all "Most Critical" resources, by location and group. This
report would then serve as the basis of a Business Recovery Plan.
1.1.6. Integrated Inventory Management System

To successfully implement an Inventory Management System, it is necessary to integrate it

within the everyday functions performed by company personnel. That is, when a user wants to
order equipment or software, they would call up the Inventory Management System screen
associated with Acquisition. The same types of processes should be available for Redeployment
and Termination of assets. Should a user request the acquisition of a specific type of asset, then
it could be possible for the inventory system to determine if the asset is already in surplus, or if it
should be purchased under an existing Volume Purchase Agreement with a vendor.

Inventory Management
Process Flow Users make requests for resources
(either hardware, software, or fixed
assets such as furniture). To ensure
USER USER accuracy of Inventory, all requests
must be via system connected
terminal.

Inventory Management

Inventory Control Financial Management

Management
Financial profile of inventory is
Inventory of assets is controlled by the
provided to Financial Management,
Inventory Control Manager.
who recommend purchasing techniques
Enterprise design agreements are
Reports that will result in discounts (i..e.,
validated by this person, who also Repository
Volume Purchase Agreements, or
ensures that all asset guidelines are
specific vendors).
adhered to.
Hardware,
Software,
Fixed Assets, All reports deemed
by Location necessary to support
and Criticality system and informational
requests.

Figure 3: Overview of an integrated Inventory Management System.

The utilization of Inventory Management Systems to control the purchase and installation of
assets can aid in the control of the business environment, while assisting in the assignment of
personnel to perform asset related work functions. This methodology will result in a work-flow
and asset management system.
1.1.7. SMC Discipline Interfaces

The Systems Management and Controls disciplines that will interface with the Inventory
Management System are illustrated within the diagram listed below.

SMC Organization
Systems Management
and Controls (SMC)

Batch Service Level Recovery Change

Management Management Management Management

Inventory EDP Security Problem

On-Line Management Management Management
Management

Configuration
Management Vital Records
Management

Capacity
Management

Performance
Management

Figure 4: SMC Discipline Interfaces .

The disciplines interfacing directly with Inventory Management and their functional
responsibilities are:

Capacity Management (i.e., PC memory and speed, DASD size, etc.).

Performance Management (speed and usage information).

Change Management (version and release information, benchmark, testing, etc.).

Recovery Management (recovery planning for critical assets and sizing requirements for
recovery facilities).
 Service Level Management (Service Level Definitions - SLD's and Service Level
Reporting - SLR of user processing and service requirements).

Problem Management (troubleshooting, pathway, version and release information, etc.).

Configuration Management (hardware, software, location, HVAC requirements, power,

water, floor space, etc.).

1.1.8. Inventory Management disciplines and interfaces

The Inventory Management function is responsible for tracking all assets, from Mainframe based
to Data Network based, that are connected to the data center or data network. In each case, the
Inventory Management Systems must be able to:

Identify the asset and its serial number;

Associate the asset with its owner and location;
Relate the asset to its vendor; and
Track the maintenance level of the asset.

The ideal Inventory Management System should also:

Provide financial information related to an asset;

Define the criticality of the asset; and
Supply history information for the asset.

The Inventory Management System interfaces with the following departments:

Finance;
Contracts;
Systems Software;
Production Services; and
Facilities Management.

1.2. Process Description

The process of Inventory Management receives input from Systems Management Controls
(SMC) disciplines and other functions within the I/S organization as well as other areas
throughout the enterprise.

The vehicle used to control the Inventory Management discipline is Change Management.
Without adequate Change Management the integrity of an Inventory Management process cannot
be ensured. These SMC disciplines and functions encompass both system and data network
elements and feed the Configuration Management discipline.
Inventory Management inputs can come from either the Network or System area and can
include a variety of input methods:
1.2.1. Network

The Network area must account for new acquisitions installed into the configuration.
Because the complexity of todays networks makes tracking new acquisitions difficult, it
is advisable that tracking be accomplished through the use of discovery type applications
which monitor and interrogate asset changes automatically. This type of tracking would
capture vital product data (VPD), or perform product identification which is generally
imbedded on PC-type products by the manufacturer.

1.2.2. System

Within the system area changes to the physical environment are systematically reported
through the integrated change process. This discipline incorporates all hardware and
software reconfigurations or updates. All inputs to the centralized data base will be
subject to the change process.

The following page contains an overview of the Inventory Management process.

1.2.3. Inventory Management Process

PROCESS INPUTS:

Service Level Management, Capacity and Performance Management,

Change Management, Problem Management, Batch Management,
On-Line Management, Recovery Management

New Asset Asset Network System

Acquisition Re-Deployment Termination Alert Re-Configuration

Data Center Record, System Management

System Record, To
Inventory Assurance Process
Hardware Record, Configuration
Software Record, Repository
Data Base Management
Service Record,
Financial Record.

R/O R/W Reports

Hard Copy, or
On-Line Viewing Add / Delete / Edit via on-line Display

Figure 5: Inventory Management System - Overview of Process

 The above provides an Overview Diagram of the Inventory Management process, while the
following illustration provides a Flow Diagram of the Inventory Process.

1.2.4. Inventory Management Flow

SMC
No Create
Disciplines Data Center No Generate
Data Financials
Record Physical
Center ?
? Inventory
Non-Controlled Record
Reports
Entry Yes Yes
Controlled
Entry

System No Create
Record System Financial No Create
Unformatted
Generate ? Record Record Financial
Asset
Change Yes ? Record
Request
Record
Yes

Create
Validate Hardware Generate
Validate
Data Software Financial
Data
Elements Record Reports
Elements

Create
Yes
No Yes Features Features Close Change
Accepted No
? Record Record
? Formatted?
Authorized? No

Yes

Does Config. Yes

Update
Change
Configuration
?
Data Base Generate
Physical
No
Configuration
Reports

Figure 6: Inventory System Flow Diagram

1.3. Process Flow.

The process is entered as a Controlled or Non-Controlled Asset Change Request (ACR)
as follows:

1.3.1. 1. Non-Controlled ACR Entry:

ACR received by any method other than the Change Control process.

- Confirm all necessary information is available about the asset.

- Request is reviewed locally for acceptance.
- Problems documented and returned for resolution.
- ACR accepted and authorized.
- Request forwarded to Change Control process for input as a Controlled
ACR.
1.3.2. 2. Controlled ACR Entry:

Validate all data elements are present in the Change Record.

Review by all I/S organizations accountable for asset control.
Problems documented and returned for resolution.
ACR accepted and authorized.
Update Inventory Repository data base.
Create data center record associated with the asset.
Create system record associated with the asset.
Create component record associated with the asset.
Create feature records associated with the asset.
Generate physical configuration reports and distribute.
Create financial records if appropriate.
Generate financial reports if appropriate.
Generate physical inventory reports and distribute.
Close the change record.

1.3.3. Implementation of Inventory Management

Efficient processing and operations management start with an integrated approach that
links all facets of system management together. Inventory Management is just one of the
disciplines. Each augments the other, and provides the ability to effectively manage a
large systems environment.

Accurate inventory data is vital. A lack of such data affects the other Systems
Management disciplines ability to function. The automated element of inventory
management monitors the enterprise-wide data network processing environment for
change, while the system environment relies on the change process (which may or may
not be fully automated) for accurate input.

The products and tools that comprise the Inventory Management System use data
network definition information, Vital Product Data, local configuration definitions and in
some cases, discovery applications to arrive at inventory information.

This process must embrace the following areas to be effective:

1.3.4. System Environment

Today the system programmer can define hardware configurations for multiple
MVS/ESA operating systems through Hardware Configuration Definition (HCD). HCD
reduces complexity and shortens the time required to successfully define an I/O
configuration by providing a panel-driven interface, panel defaults, and data entry
validity checking.
Dynamic reconfiguration management allows the support organization to implement
system configuration changes without interrupting system service. System availability is
increased by eliminating the need for an IPL to change the hardware configuration, or to
 change the software definition for devices, control units, and channel paths. This ability
to dynamically reconfigure works in conjunction with HCD and allows the new system
configuration to be implemented without interruption.

Enterprise Systems Connection (ESCON) Manager enhances user control and

manageability in an ESCON architecture environment when changing ESCON Director
(ESCD) configurations. The changes are entered at a host processor rather than at the
local ESCD consoles in the mainframe environment.

HCD and ECSON are highly dynamic tools that can effect configuration changes easily
and swiftly. However, there are no automation techniques currently in use which update
the inventory data base. Updates to the inventory data base require manual intervention,
therefore, it is important that these interfaces to HCD and ESCON be constantly
monitored and proper change control exercised to maintain asset integrity.

1.3.5. Network Environment

The complexity of the network environment requires an integrated set of facilities to store
and display network configuration data for all network resources. This includes OSI,
TCP/IP, SNA, Ethernet, and any other network resources. These facilities are tailored
for network operational use and contain information that is pertinent to hardware and
software inventories (e.g., Vital Product Information).

When dealing with large networks the immediate problems associated with the collection
of asset information is enormous and therefore, subject to significant errors. If the
configurations are too complex, they become impossible to manage or understand. The
typical network is composed of many nodes extending to many different topologies. The
technique commonly used to manage networks is to break up the larger networks into
smaller, manageable units. Once the management of these clusters is underway, you can
proceed to manage several clusters from a higher node in the configuration hierarchy.
This allows for greater control and accuracy.

On the other hand, if the configurations are too granular, the system can become a
collection of small configurations with no relationships established between each other.
For example, when defining a large 3745 network, we first define the lines, along with
their drops, as separate configurations, then connect these lines to the 3745 in another
configuration. This logic can be applied to other layouts as well, including the
client/server arena.
Although the industry direction is to automate network asset control as much as possible,
managing the entire configuration does not necessarily have to be automated from the
start; especially within the enterprise. It is our primary purpose to reduce the amount of
manual work and the possible human errors typically found in current network
configuration and asset management processes. Therefore, the technique presented here
does not provide the Company with the complete automation process for the entire
enterprise configuration. Rather, we recommend that you begin the initial steps for
replacing much of the tedious work of entering and updating configuration data manually.
1.3.6. Data Requirements for Inventory Management
To ensure a consistent, centralized and integrated control, as described in the previous
section, a common data model must be built. This will ensure a consistent reporting
process to the inventory data base regardless of where the data is stored.

In the event of incomplete record information, the inventory management area must re-
solicit, or advise the responsible asset area of the missing data elements. This reentrant
approach provides a disciplined strategy to build a reliable inventory.

The structure illustrated in the next diagram allows the description of hierarchical
relationships among data centers, systems, components, service organizations, and
financial data. By entering descriptions of the hardware and software system
components, along with information about their status and support data, a data base can
be built which supports parent/child relationships.
The figure on the next page shows the interrelationship between component records:

1.3.7. Inventory Management Data Model

Inventory Management Data Model

Data Center
Record

System
Record

Hardware Service Software

Component Record Component

Features Features

Hardware Software
Financial Financial
Record Record

Figure 7: Inventory Management Data Model

The following items are required from asset sources to support an integrated
Configuration Management approach.

1. Data Center Record.

This record contains on-line information about the data processing centers, the system
name, location codes, emergency phone numbers, managers, and contact names. The
software and hardware components, and system records will refer to this record.

2. System Record

This record contains information relative to each processing system within the processing
center. This record should contain the system names by LPAR, location codes, operator
names, support numbers. Software and hardware components can refer to this record.

3. Service Record

This record contains the service organizations data. Maintaining service organization
records is advantageous when a user is displaying a record of a failing component. This
record should contain the name, location, prime-shift phone number, off-shift phone
number, hardware and software representatives name, and contact phone numbers, and a
description of the service organization. Hardware and software components can refer to
this record.

4. Financial Record

Helpful information in this record assists in warranty and service incidents. Hardware
financial records contain a user financial id, a financial type, and a description. For
software records the same information is required in addition to a license type record
entry.

5. Hardware Components

For hardware component records a consensus must be reached on the hardware types to
be managed. A hardware model record for each hardware type will be created and all
common hardware components will be entered using this template. This record should
contain the following information:

Component ID,
Product Number
Serial Number,
Generic device type,
Model,
Manufacturer,
Owner,
Install Date,
Location,
Maintenance Vendor,
Contract type,
Component status,
Component Criticality
Component description.

In some instances a hardware subcomponent record must be entered. A subcomponent

can be thought of as a feature that can be a stand-alone component and has mobility in
the inventory (for example, 3726, 3727, external hard disks). This will allow
subcomponents to be removed or moved from their hardware component or attached to
another component. This record should contain a subcomponent status code and a
description.

6. Software Components

For software component records a consensus must be reached as to what level of installed
software will be within the scope of the asset data base. For example, is the workstation
(PC-based) software to be managed? If so, are we to account for all application software
or just operating system software?

The answers to these questions are linked to what kind of information the user support
groups require to provide service to the client. In a centralized Help Desk environment,
all user application software, including maintenance levels, are maintained. This
provides up-to-date information to the Help Desk personnel about the user environment
and adds greatly to their productivity.

A software model record for each component contains an ID, maintenance level, program
type, status and a description. A typical software record should contain the following
information:

System (application runs on),

Product Number
Name,
Model,
Vendor,
Serial Number,
Renewal Date,
License Type,
Contract Type,
Maintenance Level,
Description.

7. Feature Components Record

This record identifies associated features and relates these features back to other records.
 8. Model Component Record

The industry uses this type record as a productivity tool to greatly enhance the ability to
build large data bases quickly with minimum data entry errors.

Model records themselves do not hold configuration data, but they make the entry of data
easier by allowing the creation of component records from models that hold information
common to a number of components (or subcomponents) of the same type.

The model capability also provides the ability to build one or many relationships between
model features and hardware or software components. Features that are common to
many components can be contained in a single model feature record that is referred to by
many component records.

1.3.8. Collecting, Monitoring and Reporting Data

1. Monitoring and Reporting Data

Once the inventory data base has been built it will be used to satisfy the following
requirements

Determine bypass and recovery procedures when a failing component has been identified.

Determine the level of a component, and also other components that are affected when a
problem occurs.
Establish relationships between a component and any problem or change record in the
data base.
Search for any components meeting specific characteristics, such as all terminals in a
network and the locations to which they are assigned.
Generate reports on specific configuration information, including but not limited to the
following:

- Hardware or software components with related features,

- Physical inventory by location,
- Hardware and software configuration maps, and
- Service reporting for maintenance contracts, warranty, and invoice
tracking.

2. Collecting Data

The Record Hierarchy in the following diagram indicates that component records refer t
data center, system, service, and financial records. These four records are informational
components. This means they must be created prior to creating the component records
(hardware, software). It saves time because these records must be defined before they
can be referenced in component records. This allows you to establish connections as you
create the records.
1.3.9. Inventory Management Record Hierarchy

Inventory Management Record Hierarchy

Center, System, Service and Financial records must

be created before you can reference them in the
Center System Service Financial component records

Hardware / Software Hardware / Software

Component Model Component Direct

You can create

a component from
a Model record Hardware
Subcomponent

Model Record link relationship to

Component hardware component record.
Component

Hardware / Software Hardware / Software

Parent / Child Parent / Child

Relationship Relationship

Model Feature Feature Connection

Subcomponent Model etc. Hardware / Software Parent / Child Hardware / Software
Relationship

Figure 8: Inventory Management Record Hierarchy

1.4. Discipline Relationships

To ensure the integrity of the process, Inventory Management must interface with
multiple business and I/S system management functions. The interface to these
functions provides the foundation for strong Inventory Management practices.

1.4.1. Business Function Interfaces

Some of the more common business functions that interface with Inventory Management
include:
Purchasing
This resource manages all information systems requirement identification through the
procurement process. Inventory Management provides input to Purchasing in terms of
system and network standard asset information.
Accounts Receivable / Payable Department
This function collects usage data and bills information System (I/S) expenses to the
appropriate users. It supports accounting, budget planning, tracking of project costs, and
other activities. Inventory Management provides financial records as input to the
Accounts Receivable / Payable process and vice versa. This two-way interface occurs
with the approval and submittal of billings for payment.
 I/S Management Committees

These groups investigate tools and services to provide policy information and translate
that data into recommendations for I/S productivity improvements and services.
Inventory Management will provide input to these groups in terms of product standards
and technology strategies.

Strategic Planning Committees

These groups deal with long-range planning and the integration of I/S objectives with the
business objectives of the enterprise. Inventory Management provides an interface to
Strategic Planning by providing insight into device migration patterns, trends, and
direction, and the Strategic Planning Committees provide information back to the
disciplines as well.

Security Department

This function manages the registration or enrollment of people and programs to access
controlled I/S resources. Inventory Management provides input about device
configurations and security interfaces to this functional area.

User Support Groups

Since these groups are responsible for their equipment acquisition, they must be
compliant with the inventory process. Tracking the acquisition of network and computer
equipment at the local level can be difficult without their full participation. To ensure
accountability of such purchases, provisions should be made for a periodic physical
inventory of such groups to ensure a level of inventory integrity.

Client Support Services

These groups define the services that will be needed to support the I/S clients within the
enterprise. Within Services Management are two key areas:

1 1. Help Desk - This area provides a single point of contact for clients to request
services and obtain resolutions for problems.

2 2. Service Level Planning - this area identifies the agreement between the I/S
organization ad the user community that defines the level of service. The service
level agreement is also used to define policies for operations and performance
management.

1.4.2. System Management Interfaces

The Inventory Management discipline is dependent upon various disciplines and functions
within the enterprise in achieving its objectives. These disciplines and functions and the
assumptions related to their tasks are listed below:
 Change Management

Coordinates the various tasks performed in configuration change and testing across the data
processing environment. Any changes to the I/S environment that affect Inventory Management
are input from this discipline.

Problem Management

Assists the I/S organization in locating, identifying, and resolving inventory problems. The
Problem Management discipline will provide input to Inventory Management as problems arise
that require changes to resolve conflicts.

Facilities Planning

Required to participate in the Problem or Change process as they pertain to the physical
environment and is accountable for any actions required to comply with the inventory
management process. It is essential that this group provide input to Inventory Management and
vice versa, to ensure changes in physical asset configurations are noted.

1.5. Inventory Management Tools

Inventory Management uses network definition information, Vital Product Data (VPD), local
configuration data bases and, in some cases, discovery applications in order to arrive at inventory
information.

The following list of Inventory Management tools was accumulated after conducting a general
survey of large corporations in the area. The participants represented large corporations with an
annual I/S budget of over $100M. The survey solicited information about how they performed
Problem, Change, and Inventory Management and what techniques and tools were used to
accomplish tasks in the two areas that follow.

Those products which are specifically mentioned were approved by the vast majority of
participants. We also list major Inventory Management functions that can be fulfilled by any
number of products, but do not specifically mention a product by name.

1.5.1. Asset Management at the System to Server Level

The major components that provide the collection and reporting vehicles for Inventory
Management from the system level out to the network server level include:

VTAM and NetView

VTAM and some specialized features of NetView are responsible for maintaining the
necessary linkages to the physical asset, whether it is within the system complex or out to
the server level on the network.
Centralized Data Bases
 All assets and their associated information are stored in a centralized data base. Editing
and browsing capability are available through an on-line menu driven, front-end that
provides restricted security access, if necessary. This security is provided through any
number of host-based security packages.

Network Configuration Application (NCA) / MVS

NCA/MVS is a useful tool for migrating existing stand-alone (PC-based) inventory

control data bases to host-based formats. It should be noted that in some cases
conversion utilities have been written to convert these stand-alone environments into a
data base file structure.

Enterprise Physical Connection Tool (EPCT)

EPCT is a useful product for building configuration data bases and producing physical
and logical diagrams. The figure below illustrates the usage of these tools within the
process.

Asset Management at the System to Server Level

Creates Configuration Drawings

NCS / MVS
Creates Configuration Drawings
EPCT
Data Base Repository for
all Assets (Mainframe through Centralized
Data Network) Asset Data Bases

VPD CMDS Collect Data NetView

Status Monitor - VTAMLST
VTAM

NETVIEW AUTOBRIDGE

* Alert / Problem Reporting

Remote Controller 3174 * Automated / Manual Bridge
* Serial Number
Remote to Info/Man
* Type / Model
Controller
P - Primary Connection
P S
S - Secondary Connection
Remote Terminal
* Serial Number
* Type / Model

Figure 9: Asset Management at the System to Server Level

1.5.2. Industry Standards

Centralized Inventory Data Base Repository

The industry uses any number of system management products which integrate the entry
of Problem, Change, and Inventory Management into a common, centralized data base
repository. However, these integrated products must interface to the tools listed below
to facilitate the automation ad centralization of an asset management data base repository.

VTAM Version 3.4 (Planning and Reference Guide - SC31-6124)

VTAM Version 3.4 is a telecommunication access method that works in conjunction with
MVS/ESA Version 4 to support non-disruptive addition of channel-connected
communications controllers and SNA cluster controllers.

NetView Ver. 2 Rel. 3 (Users Customization Guide - SC34-4336)

Network Manager which will provide:

1. NetView Bridge Adapter (NetView Bridge Adapter Reference - SC34-4336)

A component that provides a set of application-to-application interfaces
that will provide an effective means of connecting NetView to external
data bases.

2. Status Monitor Function

Collects status information about SNA resources such as hardware data
(from VTAMLST) and reports to a centralized data base.

3. NetView Autobridge Version 1 (Users Guide - SC34-4318)

NetView Autobridge will allow the flow of configuration and change data
from NetView to a centralized Data Base Repository.

4. RODM - Resource Object Data Manager

The Resource Object Data Manager will provide services that enable
systems and network management. The facility is used by NetViews
multi-vendor graphic enhancement and automation platform. These
services will be used to create configuration drawings of the asset data
base.

5. Network Configuration Application/MVS (NCA/MVS) Version 1 (Users

Guide - SC31-6149)
Network Configuration Application/MVS is a configuration application
for use on an MVS platform. It provides for collection of information
about equipment, circuits and software; has the ability to create
configuration representations for components in all types of network
topologies; and allows for creation of abstracts to represent relationships
 of components. A utility function transforms this data into the format
required by the Resource Object Data Manager Facility in NetView
Version 2 Release 3 for graphic views.

6. Enterprise Physical Connection Tool (EPCT) (Users Guide - SC23-0546)

This DB2-based asset collection and physical drawing product will
provide the capability to draw physical and logical topologies of system
and network complexes. EPCT is a locally developed application written
by the ISSC Corporation in C Language and provides browsing an editing
capability on-line. This product can be ordered as an PRPQ through the
IBM Corporation.

1.5.3. Downstream Network Server Configuration and Inventory Management

The following figure illustrates a downstream view of Network Configuration and Inventory
Management.

Downstream Network Server and inventory Management

Data Base Repository Centralized Configuration INDUSTRY PENETRATION

Data Base
PVCS - INTERSOLV
VPD DMDS Collect Data NETVIEW LANFOCUS - IBM

Status Monitor - VTAMLST VTAM

Machine Serial Number WAN SERVER

Model / Type
Automation Stops
at the Server Level

AUTOMATED

MANUAL

This Layer Requires Additional Software To

Support Configuration Management

Figure 10: Downstream Network Server and Inventory Management

Asset management below the server level has not been widely implemented throughout the
industry today. WAN environments have their own unique challenges. Most host-based
products require an additional layer to bridge beyond the server level. The products listed below
are seeing some industry penetration and promise to be viable tools in the coming months ahead.
 PVCS Configuration Builder Series (Product of INTERSOLV Corporation)

The PVCS series covers all key functional areas for configuration management:

Version Management,
Build Management,
release Management, and
Report Generation.

These functional areas are available across all types of files including source code, text,
or documentation files, graphic or binary files. With PVCS Series development teams
can:

Recreate a system, or component of a system at any time and prevent inadvertent errors
and code changes with version management.

Rebuild an entire system when any component is changed without having to remember
complete relationships about elements of the system.

LANFocus Management / 2 (Product of the IBM Corporation)

This family of products provides System Management principles to LAN attached

workstations having OS/2 and DOS installed. The products provide a platform which
includes a programming interface for the creation of system management applications.
This includes applications which address the disciplines of problem management,
performance management, and configuration management.
1.6. Roles and Responsibilities

1.6.1. Inventory Manager

Responsible for maintaining the Inventory in a current and accurate state. Role is
responsible for both mainframe and network resident devices and software components.
Interfaces with Systems Management disciplines and Financial department.
1.6.2. Inventory Clerks
Responsible for maintaining the Inventory Data Base Repository and for guarantying the
information contained within the Repository is accurate and in a current state. Information is
data entered, or entered via automated tools. If automated tools are used, then clerks must be
knowledgeable in program products used as a tool.

1.7. Process Evaluation

1.7.1. Present System Weaknesses

There is presently no Centralized Repository for asset information, because Inventory

Management is performed by many various groups (i.e., mainframe, communications,
data network, etc.). A consolidation of these data bases into a centralized Inventory
Repository should be planned.

When migrating to a centralized repository, automated tools and interfaces should be

developed, so that any acquisition, redeployment, or termination of assets will have to
accomplished through the automated system. This will reduce the effort presently
performed by personnel and guaranty the accuracy of the Inventory repository.

1.7.2. Recommendations for Improvement

Create a Centralized Repository of Inventory information.

Utilize Automated Tools and Front-end to the Inventory Repository.
Integrate the Inventory Repository with the everyday asset functions performed by
personnel, such as:

Asset Acquisition,
Asset Redeployment,
Asset Termination,
Lease and Contract Maintenance,
Volume Purchase Agreements, etc.

Utilize a Criticality indicator to relate assets and their criticality for disaster recovery
purposes. This will allow for reports that list all most critical resources for a specific
location, by type and costs.
Formulate a committee to investigate methods for improving Inventory Management and
implement the most rewarding suggestions from the committee.