These two huge operations came to Data Capture Institute with similar problems to solve: the tracking of millions of assets (lowest replaceable units or LRUs) which change location and undergo repair by many technicians.
Below is some of the advice we have passed along and utilized in designing their very complex systems. In this tutorial, we will address the special challenges of enterprise-wide fixed asset tracking, because we find a great deal of current interest in this bar code-driven application among our other clients as well. In point of fact, pieces of our fixed asset tracking system have been developed by us for several years.
There are special challenges in labeling assets that have been installed and in use for many years, or even decades, and setting up a continuous scanner-based tracking system integrated with new and legacy databases. These assets are often quite varied and geographically far-flung. In spite of this, vital information regarding details of enterprise assets such as original purchase date and price, asset manufacturer, current location, repair frequency, or upgrade status often resides in files on different computers running dissimilar operating systems. Regardless of this, a true fixed asset tracking and reporting system will have to provide timely reports to many inquirers across a broad category of financial and physical details.
The ability to track assets from the time of acquisition until retirement is crucial for high productivity and accurate financial reporting in business. Without bar code, asset tracking has been inaccurately performed while consuming expensive personnel resources over an extended period of time. Companies who have replaced traditional asset tags with bar code labels report reductions in fixed asset inventory expense of as much as seventy-five percent, with far greater record accuracy.
While asset tracking using bar code has many features in common with those listed for other tracking designs, consider the following advantages of a bar code-based, modern, database linked, asset tracking system:
Transportable assets can be checked and assigned easily.
Physical assets tracked by bar code can include furniture, office and data processing equipment (terminals, PC, typewriters, calculators), telephones, art work, and even modular offices. A PC or minicomputer host located in the controllers department can manage the processing involved for a single site or even business division. Assets are usually scanned and recorded in batches using a portable bar code terminal equipped with either a wand or laser scanner. Assignable assets issued and returned through a central storeroom can be recorded with each change of assignment by a scanner and terminal, networked to the host computer. In this design, all assets are continually reported through a single database.
Some businesses require tracking components within an asset. For example, a personal computer may have certain options, like extended memory or installed software, used for a time in one department, then reassigned to another. The labeling methods, software, and database for this application must be chosen with additional care to assure label visibility to a scanner, and a file structure capable of detailing the lowest replaceable unit (LRU) of a system.
Maintaining and operating a fixed asset tracking system is easier that initializing one, in most situations. If the organization has been in business without such a system, the first challenging task is to apply labels to existing assets and accurately link those assets with an adequate item description. Digging out the asset records of purchase dates and values, or repair histories and up-grade incidents, can make this a complex challenge even for a small organization. As a result some organizations will begin a detailed fixed asset tracking system by capturing the relevant date for all new assets, and treat older assets by whatever less precise methods have been used in the past. This approach is especially appealing if the value of fixed assets is increasing rapidly and if those assets depreciate over a short time period such as three years.
As with other bar code based control systems, many tracking features and information system configurations are possible. For any particular application, which features can be justified against the added costs of the system, or complexity to operate, must be decided. Frequently, it is more practical to create and operate several simple bar code asset tracking systems with data from each entered to its own dedicated database than to design and operate a master system which is designed to do many tasks. For example, developing a master tracking system to manage an active tool crib and also maintain extensive corporate fixed assets in a shared network and database would be challenging. Two separate bar code based systems may be easier to design, implement, operate, and adapt to future functional changes.
The most challenging, and therefore the most interesting (and costly) fixed asset tracking systems are those that span a large enterprise. Fundamental decisions to be made before entering an enterprise-wide application include:
What bar code label design should be chosen?
Should all fixed asset labels be the same size, or scaled to the size of the asset?
Should a new asset transaction database be developed, and have this provide the front-end to a data warehouse linked to other relevant asset files?
What database architecture and network operating system (NOS) will link asset sites and inquiry terminals most efficiently over the next ten years?
With what degree of exactness will assets be located within the enterprise?
These and a hundred more issues arise and must be dealt with before a comprehensive enterprise-wide fixed asset tracking system can be installed. If assets to be tracked are valued at hundreds of millions or even billions of dollars on a balance sheet, an effective tracking system may cost ten million dollars or more to implement.
An enterprise-wide fixed asset bar code based tracking system has to have a number of functional steps in order to fulfill the requirement for dynamic, real time reporting and operational control. This fact divides the general solution into five levels, as illustrated in Exhibit 1.
First of all, as with every bar code data collection system, a great deal of time has to be spent on the label(s) design at the initiation on the project. Next, consideration of the data collection terminals, applications and scanning instruments must be made in the context of the people who will record the assets locations and activities. After that, the size of the bar code events database and any special connectivity considerations must be determined. Then, a data warehouse must be developed and interfaced to the bar code events database, since large enterprises typically have legacy computers with historical data related to the assets to be tracked. Finally, routine asset reports must be developed from the data warehouse and unique query capabilities must be offered to all enterprise managers with a "need to know," so dynamic information related to every enterprise asset can be continually discovered.
The primary label driving fixed asset bar code tracking is the label applied to each unique asset to be included in the traceable inventory. In a large open system this label has to be unique, that is non-repeatable, and it should be applicable to any size or class of asset. Other traditional label rules apply, of course, including the following: use the largest possible "X" dimension, provide good bar height, assure good initial print quality, and use face coating and adhesive backing that will survive for the life of the asset.
Currently, many manufacturers of high value products apply their own serial number bar codes during final product assembly. For instance, this tutorial is being created on a PC with a bar code that says "XB60314K4KR"! In a perfect world, all manufacturers would have gotten together by now to agree on a serial number system with no overlapping serial number series, from one manufacturer to another. This has not happened, although some pockets of industry activity have developed serial number standards in vertical markets such as telecommunications. Consequently, with no assurance that the sequence "XB60314K4KR" will not appear on some other asset within a large enterprise, the prudent system designer must create a new bar code.
In 1995, the Uniform Code Council (UCC) adopted a new Application Identifier (AI) to satisfy this requirement for world wide unique asset identification. The UCC has assigned AI (8004) for asset serial number identification. (Its principle characteristics are included in a sidebar within this article.) Translated into bar code, this label is shown in Exhibit 2. Hopefully, my PC maker will adopt the UCC-EAN 128 application identifier (8004) as a prefix in the future, add their UCC manufacturer code, and then use "XB60314K4KR", and the uniqueness of their label will be assured.
After the design of the asset label, described above, the next most important point of project emphasis should be on choosing the correct portable data terminal (PDT) for the fixed asset tracking system personnel to use. Usually the personnel recording asset locations have been hired and trained for a task quite different than reading bar codes and performing other data entry steps. Consequently, the PDT interface must be easy to operate and intuitive in the performance of every application. For instance, in a business that depends on complex operating assets such as computer or communications components, it is essential to rapidly replace a failed component with a spare.
Next, a technician must complete certain steps required to replace the "spare" that was just used in substitution for the failed item so that this exchange-and-repair process can continue indefinitely. Technicians currently spend a great deal of clerical time filling out paperwork to provide the paper path for asset tracking or, more likely, the asset track is lost. If bar code based fixed asset tracking is introduced with an easy-to-use intuitive PDT, the transition from paper to bar code goes smoothly. DCI has seen a number of systems where the PDT and application software for tracking were too complex to follow or understand by a technician. The resulting bar code asset tracking was disappointing, to say the least.
Portable data terminals have gone through a series of evolutionary stages over the twenty years of their development. Stage one was a device bar code professionals refer to as a "brick" with scanners attached. Stage two produced a "brick-on-a-stick," or PDT with integrated scanner and handle. We are now at stage three in this evolution, where PDT and pen computing features are combined to present pleasant, easy to understand, guided dialogue between an operator and his or her task. Interchangeable scanning devices are desirable, and the ability to add a lot of on-board memory is required as applications expand. As with all portable data collection applications, sometimes batch data collection and reporting is sufficient, while other applications require continuous radio frequency (RF) connectivity. The next two issues of this journal will cover the subject of portable data collection devices in greater depth than we have room for here.
DCI almost always recommends the use of a dedicated host processor to "front end" a bar code data collection application. In a bar code based, enterprise-wide, fixed asset tracking system there are many benefits to a separate, events-based, dedicated database and almost no disadvantages. This should be a relational database which offers the end user an image of simplicity and ease of understanding. Information appears to be arranged in a form that is logical to the human mind. The events to record to this database follow the pattern of fundamental scanning rules. That is, scan and record whenever the following occurs:
Following the scan, append the database record with the date, the time and the individual's identification who performed the activity.
These events comprise the records that the database will record and report when queried. The decision to be made in sizing the database revolves around how many historical transactions should be retained in the database before summary records are passed on to the data warehouse or an archive tape. Today, disk memory is so inexpensive that one should err on the side of keeping too many records in the events database, rather than too few. Terabytes of disk memory are cheap, by any historical measure, and data access time is mainframe-fast on servers costing as little as $50,000.
Direct event reporting from the events database is certainly possible and will frequently satisfy query or report requirements. For instance, when a list of assets by location is desired, or a list of activities by an individual for productivity review, the events database will provide an immediate response. In a large enterprise, however, fixed asset reports may require computer access to legacy systems running older databases which contain asset depreciation information or engineering upgrade and revision activity, for example. In order to satisfy these "decision support" requirements, a data warehouse is necessary.
A data warehouse is the virtual repository of all enterprise information required to provide decision support applications. Today, corporate executives and business analysts rarely use a simple, predefined set of parameters or categories of data. The data required to solve a specific business problem often requires access to historical files not contained in a relational database. Relational databases are not well suited to the time-oriented analysis required for reports that plot equipment performance or operating efficiency over long periods of time. Relational databases, such as the events database, usually go back a limited period of time, such as three months or one year.
The investment in a bar code based, enterprise-wide, fixed asset tracking system will be substantial. The large enterprise may have traceable assets worth billions of dollars on which shareholders expect an investment return of twenty percent or more. One would expect, then, to budget $10 million, or more, to bring these assets under continuous visibility to allow continuous operational analysis. Client-server information technology (IT) is well suited to permit executive or business analyst access to either the events database or the data warehouse, through mainstream networking.
Exhibit 3 is a simplified diagram of this architecture, from bar code label to a PC on any desktop. Looking at the current momentum of data warehouse development to better refine sales and marketing analysis, it may be possible for fixed asset tracking to piggyback on the same data warehouse, network and PC terminal infrastructure, thus sharing costs and accelerating the delivery of systems with higher IT investment returns.
Copyright 1996 Data Capture Institute Inc.
Other Data Capture Institute case studies:
