This may come as a shock, but finding the low-hanging fruit does not always mean settling for simplicity. The easiest fruit to pick may not be the juiciest when it comes to implementing an automatic identification and data collection system.
Here’s why.
The low-hanging fruit may be found in standalone applications. That’s fine if you’re just testing out a new technology, but silo applications may also be dead ends. In other words, they can’t be leveraged to facilitate the next step in a more comprehensive program or as part of a re-reengineering plan.
Admittedly, some low-hanging fruit applications, such as asset tracking and management, may be well worth pursuing as standalone applications. With proper planning and execution, such applications could provide additional benefits for very little cost.
So, what should you be looking for?
Let’s take a look at asset management as an example. To do that, we’ll use the five Ws of journalism: who, what, when, where, why.
Who touches the asset, what are they doing with it, when do they do it, why do they do it and how do they do it?
In the case of medical equipment in a healthcare environment, it may seem fairly straightforward. A nurse (who) may set up an infusion pump (what) per a physician’s order (when) at a patient’s bed side (where) to deliver saline or medication (why).
It would appear that a real-time locating system would suffice. But, infusion pumps and other medical equipment have to be calibrated, serviced or maintained on a regular schedule.
Verifying that a specific piece of equipment has been physically touched by an authorized healthcare professional or service technician is also important. In the case of service technicians, we also need
to know what they’ve done, why and when.
In this case, requiring the worker to read a secondary identification code on the item, most likely from a barcode label, would provide proof that the equipment has actually been touched by the employee.
Another useful standalone application would be tool-room management. Using a barcode or RFID tag on tools in a tool room (where) would speed checkout or return (when) and provide positive ID of the employee (who). It would indicate not only the type of tool but the exact tool (what). This would allow you to track usage for a particular task (why), quickly identify missing tools and possibly permit forecasting of wear, replacement or, if applicable, calibration or maintenance requirements.
Another good standalone application is job costing. Recording how much time a particular job took also requires the five Ws for one or many different employees.
And, here’s where the leverage comes in. In all three applications, we assume that we know the who. But, without a valid AIDC ID badge program, the who is harder to manage. So, a critical component in the development of both standalone and integrated applications is the who—an ID badge.
How could we use the who? We could use it for access control, time and attendance, activity recording, job costing, process verification and other functions. Thus, employee ID provides a key point of leverage for virtually every other application.
Admittedly, this is a simplistic example, but it’s just intended to illustrate the point that there may be places where the requirements of a number of applications overlap, rather like a Venn diagram. Those areas are the points of leverage where you can get the greatest return because one implementation has many uses.
And, that fruit’s very juicy.
Bert Moore
[email protected]
