Section 8.4. Step 3: Building Business Cases

8.4. Step 3: Building Business Cases

A business case developed for a specific application area is a living and dynamic entity rather than a static, one-time action. Therefore, you need to revisit a business case periodically to account for the impact of the existing factors that might change over time and to incorporate the impact of the new factors (for example, a competitor offering similar but superior capabilities or RFID mandates from new customers and business partners). Also upon review, you can examine a business case to determine how closely it reflects reality (as evident from the associated pilot implementations and proof of concepts). At this point, you can adjudge that the business case correctly captures the impact of its constituting factors.

The following subsections discuss the sample factors mentioned earlier in the section "Step 2: Determining Potential Application Areas."

8.4.1. Benefit

Benefit represents one of the most important factors in building an RFID business case in most any enterprise. You should analyze the benefit factor even if you are planning a slap-and-ship type application. This section discusses a way to quantitatively determine a benefit based on analyzing business flows of the application area under consideration. Other schemes are also certainly possible. This method consist of the following two steps:

1.	Creation of business-flow diagrams
2.	Determination and analysis of RFID impact points

Apart from quantizing the RFID benefit, this method can also provide some estimates of RFID cost, too. These are discussed next.

8.4.1.1. Creation of Business-Flow Diagrams

The business might not have formal business-flow diagrams for its operations yet. Now is the time to create these artifacts. Several characteristics of the process might become evident just from analyzing these diagrams. Figure 8-2 shows an example business-flow diagram. The nodes in this diagram represent major processing steps in the flow, which in turn can contain several substeps. Each nodes implies a corresponding business use case. Figure 8-3 shows such an example use case. This diagram provides other benefits besides those associated with RFID justification. For example, redundant or inefficient processes or substeps might become evident from a review of the flows and associated substeps. Thus, the business can begin to improve its efficiency even before it has started using RFID for efficiency gains!

Figure 8-2. An example business-flow diagram.

Figure 8-3. An example use case.

If these business use cases do not exist, these should be created now (see Figure 8-3). The business-flow diagrams and the associated use cases should not be created in haste. Even if the business has these flows and the use cases currently documented, it is important to validate these with the actual business operations to ensure their accuracy. Also, the flow diagrams and the associated use cases should include all the applicable processing steps and substeps, respectively.

8.4.1.2. Determination and Analysis of RFID Impact Points

The business flows documented in the previous step can now be used to determine the processing steps that RFID will impact. Figure 8-4 shows how the example flow of Figure 8-1 might be affected when RFID is integrated into the business processes.

Figure 8-4. An example business-flow diagram impacted by RFID.

Figure 8-5 shows how the example flow of Figure 8-2 might be affected for a slap-and-ship solution.

Figure 8-5. An example business-flow diagram impacted by a slap-and-ship solution.

From Figure 8-5, it is evident that the adoption of RFID does not change the existing business processes. One additional step is all that is generally required. Although this might work for the short term, long-term use of this solution is not recommended (as previously pointed out). The following explains one good reason for this. Figure 8-6 shows what the use case associated with the slap-and ship step might look like.

Figure 8-6. An example slap-and-ship use case.

If you compare the estimated completion times of the use cases in Figures 8-3 and 8-6, you can see that an additional 17 minutes 20 seconds is incurred when a slap-and-ship type solution is used for a single pallet. If a distribution center ships between 1,000 and 1,500 pallets a day, a cost overhead of 288.9 to 433.3 hours/day is incurred in total. Suppose that the business is spending $10 every hour on labor cost. Then, an amount of $2,888.90 to $4,333.30 will be spent on labor cost alone every day. This translates into a cost overhead of $751,114.00 to $1,126,658.00 per year, assuming a 260-day work year (not including RFID hardware cost, cost of implementation, and so on). This cost could be offset by savings in other areas, such as reduction of shrinkage, increase in shipping accuracy, and so on, not to mention that the company is now complying with the RFID mandate of the largest customer(s). Had the business decided to integrate RFID with its operations, however, it might have saved money together with meeting its customers' RFID mandate (as discussed next).

Adoption of RFID might require new processing steps, and therefore new business use cases (associated with these new steps) might be introduced in the flow. RFID adoption can also lead to introduction of new subprocessing steps for an existing business case. The use cases associated with the impacted and newly introduced processes now need to be analyzed for benefit. How can you discover these impact points? How do you determine whether new processing steps are needed? The answers to these questions lie in a comprehensive understanding of the specific business variables involved and creating a judicious tradeoff among them. The latter depends on the business type and characteristics and is therefore beyond the scope of this book. However, a simple illustration will now be provided as a guide. Figure 8-7 shows how the use case in Figure 8-3 might change. You can estimate the savings, for example, by taking the difference in time taken to complete this and the original use case for one shipment. You can multiply this difference by the number of shipments that a distribution center receives each day. This saved time can then be translated into savings of labor overhead and associated expenses.

Figure 8-7. An example use case impacted by RFID.

If you compare the estimated completion times of the use cases in Figures 8-3 and 8-7, you can see that a savings of 1,035 35 = 16 minutes 40 seconds can be achieved when RFID is used for a single pallet. Therefore, a 96 percent reduction in processing time can be achieved in this case for a single pallet. This is in absence of any exception conditions. If a distribution center handles between 1,000 and 1,500 pallets a day, and 80 percent of the time the conditions are exception free, a savings between 277.78 and 416.68 hours/day can be achieved for this particular use case. Suppose that the business is spending $10 every hour on labor cost. A savings of $2,777.80 to $4,166.80 every day can potentially be achieved on labor cost alone. This translates into an annual cost savings of $722,228 to $1,083,368; assuming a 260-day work year. Individual exception conditions can similarly be analyzed to find out the associated savings.

An in-depth discussion of the business variables constitutes the core material of this section.

To reiterate from the previous discussion, when a nontrivial RFID solution is put into production in an enterprise, it almost always affects its existing business processes. Some subprocesses might get streamlined and thus provide efficiency gains, whereas some other subprocesses might need to include additional processing steps, which might impact their efficiency rates. These extra steps are introduced because of some or all of the following factors:

• Commissioning a tag

• Attaching a tag

• Reading a tag

• Taking corrective measures

• Education and training

• Recycling a tag

You can break down several of the preceding variables further into their constituting subvariables. The following subsections discuss these variables individually.

NOTE

Some of the variables can prove difficult, if not impossible, to analyze using only pen and paper. Designers should be prepared to get their hands dirty by actually using RFID products in trial/pilot setups. This should help them determine the parameters that, in turn, will enable them to make the right business decisions. Chapter 9, "Designing and Implementing an RFID Solution," provides more details on this subject.

8.4.1.2.1. Commissioning a Tag

A tag has to be commissioned (that is, created and uniquely associated with the tagged object record) with some useful data before it can be used in the application. The main questions the designers should ask here are as follows:

• At what points in the existing operations can a tag be created?

• Does a new "tag creation" process step need to be introduced in which the tags will be created or can this be done as a part of an existing process?

If the business is currently producing bar codes at some specific point(s) in its operations where the RFID application is going to be used, these should be the first choice for tag creation points. Although the specific business requirements might not favor using these as tag creation points, nevertheless these should at least be considered before a decision is made. (The goal here is to avoid creating any additional process related to tag creation so as to avoid introducing additional processing steps to the existing operations. Therefore, you might need additional personnel to staff this step and extra time to physically coordinate the created tags to pass on to the next step.) In fact, you should try to combine tag creation with bar code writing as one step. How can you do so? Recall from Chapter 1, "Technology Overview," that an RFID printer can print a smart label, which is a combination of a bar code and RFID tag (together with some free-form descriptive text) in one single physical label. Therefore, if you can supplement existing bar code printers with these printers, you can print both the bar codes and RFID tags in one integrated step.

8.4.1.2.2. Attaching a Tag

Tag attachment is the logical next step after tag creation. However, this step might not immediately follow tag creation. Some intermediate subprocess(es) might be executed before a tag can be attached to the appropriate items. Again, designers should ask the following fundamental questions:

• At what points in the existing operations can a tag be attached?

• Does a new "tag attachment" process step need to be introduced in which the tags will be attached or can this be done as a part of an existing process?

If a business is currently attaching bar codes at some specific point(s) in its business operations, these should be the first choice at which to attach the tags. Again, the goal is to avoid creating a separate process to attach a tag, so as to avoid adding a processing step to the existing operations. You might need additional personnel and time to attach the tags to the items, which will most likely increase operational costs that might not be justified in the long run. To avoid getting caught in this scenario, you should combine the tag and the bar code attachment into one step. If the designers have already decided to use smart labels and the business already has a bar code attachment step in its process, you should use this attachment step to attach this smart label, too. Be aware, however, that you might need to attach the smart label with some precision so that the RFID reader(s) can successfully read the embedded RFID tag. For example, if the business has historically just slapped the bar code on items at random spots, you might need to limit their attachment to only specific areas to increase the readability of the attached RFID tag. In the beginning, you might introduce a small delay when attaching the smart label to the item as compared to the time taken originally to attach a bar code label to the same item. However, as workers gets used to properly positioning the smart label on the item, this delay might become negligible. In addition, you can use automatic RFID tag applicators to avoid incurring any delay associated with the tag attachment process.

8.4.1.2.3. Reading a Tag

As important as the tag creation and attachment steps are, the next logical step of reading a tag is equally important. The main questions to ask here are as follows:

• At which points in the operation does the tag data need to be read?

• Do any existing operations need to be altered to do this?

Clearly, the sole reason the business is putting tags on items is because the business wants to read and use the tag data at some point in its operations. A business might consider itself in compliance with "RFID-enabling" mandates by attaching RFID tags to its products and then having some one else (for instance, its customers) read and use the tag data. Even in this scenario, however, a business still needs to read the tag data at some point other than the validation performed by the reader/printer upon tag creation. The additional read(s) will confirm tag validity and whether it contains the relevant data that other parties (its customers) want. Therefore, just slapping an RFID tag on a business product does not mean that the business is RFID-enabled.

At which points (choke points) should businesses read the tags? Application requirements determine the "right" points. For instance, is the application used to determine the types of items being loaded into the pallet or the types of items being loaded into the loading truck? In the first case, the tag read might occur at the pallet loading stage, whereas in the latter case it might be done during the truck loading stage (at a dock door, for example).

Next, you must determine whether to alter existing business operation steps at the read point. Suppose, for example, that the tags need to be read when on a moving conveyor on their way to inventory. Do you need to slow down the conveyor so that all tags can be properly read? Will doing so affect business efficiency? It depends. You might find that improved tag read accuracy leads to better inventory management, which in turn might more than offset this efficiency loss. Designers need to use RFID in an experimental setup to determine these factors.

8.4.1.2.4. Taking Corrective Measures

Any RFID solution, even a trivial RFID system, requires implementers to take corrective measures, mainly involving the following two types of actions:

• Corrective actions associated with a bad tag write/attachment/read

• Corrective actions associated with rectifying the improper outcomes of a business operation

The first type of action is required with any RFID system, regardless, for example, of whether Class 0 EPC (tag data is already written by the manufacturer) or Class 0+/1 EPC (tag data is written by the business) tags are used. What happens if the tag is bad or the RFID printer/reader fails to write the tag data completely? The latter might happen, for instance, if a relatively large amount of data needs to be written to the tag (because the chance of this occurring increases with the increase in data size) or the printer may not be configured properly. The only solution to this problem is to write another tag and discard the bad tag, at a cost of additional time to create the new tag and additional resources in the form of manual intervention to discard the tag so that it does not reenter the operation flow. An RFID printer will automatically print a new tag with the same data and mark the old tag as invalid. However, if you cannot attach a valid tag properly to an item, you should strip off this tag from item before attaching another one. Why? Because although a reader cannot read this invalid tag most of the time, some readers might actually be able to read it sometimes. Therefore, if you do not strip off the invalid tag, the item will end up having two unique identifiers. Although the misplaced tag can simply be ignored (for example, by not associating it with the item), the dual (potentially) identifiers might lead to unexpected side effects. For example, suppose a correctly placed tag is put right on the top of this misplaced tag; in this case, the latter might prevent proper reading of the former. Another effect is that the back end might trigger false alarms when a reader reads a misplaced tag. To prevent these occurrences, you should strip off the misplaced tag, and then either attach it properly or use a new tag. Note that in the latter case, you must produce a new tag (adding to the time and resource requirements of the operation). What happens if a reader cannot properly read a tag after you have attached the tag? In this case, you might need to develop auxiliary processes to correct a read problem (additional processing steps). However, the auxiliary process(es) might not mean an overall operative loss. The results gained by properly reading the tags might provide substantial benefit that outweighs the overhead associated with these auxiliary steps.

The determination of improper outcomes of business process(es) is one of the chief benefits of using an RFID system. Suppose, for instance, that tagged cases of a product are being loaded into a truck for delivery to a customer's warehouse. Some cases might be loaded for which the customer has not placed an order. An RFID application can automatically check the shipment validity by reading the tag data from such a case and comparing it with the customer order. Whenever a mismatch is found, the RFID application can trigger a visible or audible alarm to alert the floor personnel. Additional processes must be devised to rectify such mistakes. Although these measures might add time and resource overhead, the aggregate savings achieved by correcting such errors can prove substantial, resulting in significant savings even after factoring in the cost of rectification steps.

8.4.1.2.5. Education and Training

Education and training plays an important part in determining the success or failure of an RFID system; therefore, never overlook this factor when designing a change to any business process. Operations personnel might know different process flows and steps associated with such flows (and might even hold these dear to their heart). For example, if a manual inventory-tracking method (pen and paper) is currently used, you might find it hard to do away with this artifact overnight in favor of an RFID solution that tracks inventory automatically. In addition, you might encounter baseless fear and suspicion that the RFID technology is being used to monitor and control employee activity (which might lead to employee demoralization). To eliminate this fear, you need free and open discussion about the technology. In addition, proper training is essential to reduce hardware damage and system downtime and to ensure the proper use of the system. For example, a forklift driver might unknowingly slam a pallet against the warehouse walls to stack it. As a result, however, the attached pallet tag might be damaged besides (or positioned in such a way that readers cannot read it). You must educate the forklift driver about the impact of his operation style on the RFID system and train the driver in alternative, nondestructive, pallet-stacking procedures. You can also proactively plan training. For example, if you plan to use a new forklift type with the roll out of the RFID system, you can plan operator training in advance. The advance training will enable your forklift operators to perform their duties without disrupting operations or damaging RFID hardware.

8.4.1.2.6. Recycling a Tag

Typical RFID applications do not recycle tags. However, tag recycling can drastically reduce the hardware cost associated with an application and therefore its total cost of ownership (TCO). After all, the cost of tags is generally the only recurring hardware cost for any RFID application that does not recycle them. Although tag recycling might seem like a good idea, you must answer the following questions satisfactorily before making a recycling decision:

• What are the business drivers to justify recycling a tag?

• At which points can a tag be retrieved for recycling?

• What steps are required to recycle the tag and subsequently put it back in use?

The business justification for recycling depends on several factors, including the following:

• Additional personnel required. You might or might not need additional personnel, depending on the operations' characteristics and recycling strategy.

• Personnel training. Although frequently overlooked, some form of training is generally needed for the operations personnel to properly collect and recycle tags. Unless your personnel is properly trained, you risk damage to the tags during the recycling phase.

• Processing cost. Typically, some processing cost is associated with a tag (as discussed next).

• Operations characteristics. One of these is the physical distribution footprint of the operations. Recycling a tag is more realistic for operations that have small physical distribution footprints than for those that are geographically widely distributed. Tag recycling is more realistic for a business operation housed under a single roof than one that spans several geographic regions.

• Resources needed to change any business processes. You must determine whether you need to adjust any existing business processes to accommodate the recycling process. If so, you must calculate the required additional resources (for example, time, money, and personnel) needed to handle these changed processes.

• Cost of impacting existing business processes. Do you need to adjust any operations parameters (for example, the rate at which a delivery truck is loaded, or the speed of a moving conveyor)? If so, how will these changes affect the overall efficiency of the operations?

All these listed factors have the potential to add to operating costs. Do the savings from recycling tags outweigh the total cost associated with these factors? If so, the designers should definitely consider the recycling option. If the application is using expensive active (or even passive) tags, designers should seriously consider recycling.

Assuming that tag recycling can be justified, at what point in the operation will the tags attached to the items be collected? Generally, you should collect tags at the end of the life cycle of a tagged item. Depending on the definition of a life cycle of an item, this might be when the item is rolling off of an assembly line (in case of an automobile) or when it is ready to be recycled (a chemical drum). This collection will most likely introduce additional processing steps in the business operations. However, the savings achieved via recycling might more than compensate for the overhead associated with these additional steps.

After you have collected the tags, how do you make them usable again? You might think that, at a minimum, you need to erase the data on the tag. However this is not true. If the end of the life cycle of the tagged object means that the object is "dead and done" as far as the operations is concerned, you can just reuse the tag identifier on the object for a new, live object that is about to begin its life cycle. Suppose, for example, that a tag with a unique identifier is associated with the vehicle identification number (VIN) of an automobile to track it on an assembly line during its build. When the finished vehicle rolls off the assembly line, the vehicle no longer exists (in the context of the assembly line), and therefore this tag can be associated with the VIN of another vehicle that is about to be built. If this tag only contains a unique identifier, it can be reused without any change. However, if this tag contains vehicle-specific data (for example, VIN, custom features such as leather upholstery, color, and so on) relevant to the original vehicle, this data needs to be erased before the tag can be reused. In addition, if the tag requires specialized mounting fixtures, these might have to be fixed so that the tag can be remounted properly on another item. As a result, this step can potentially introduce additional substeps in the processing, too. As mentioned previously, however, savings achieved by recycling the tags might more than compensate for the overhead associated with these additional steps.

8.4.2. Cost

Cost is intimately associated with almost every variable of an RFID system. The following main factors contribute to the total cost incurred in development of an RFID application:

• Business process changes. Inherent in any business process change is the potential requirement of additional resources. These resources might take the form of extra personnel or extra time to complete particular tasks(s), resulting in loss of productivity that might directly translate to lost revenue and so on.

• RFID hardware. The readers and antennas are a one-time investment associated with an RFID application. However, tag cost can be a recurring overhead if the tags are not recycled. In fact, with regard to an RFID application TCO, tag cost is a major area of concern.

• Application software and hardware. Typically, these are one-time investments. However, hardware and software licensing, upgrades, and maintenance costs can be a source of recurring cost.

• Services. This has several components. First, the RFID readers and antennas (and controllers) must be connected and set up properly, and the network infrastructure might need to be enhanced to connect the readers. Suitable portals and structures might need to be built to host the readers in the read zones. In addition, the RFID hardware setup might need to be fine-tuned to exploit its maximum potential. Second, the application software might need to be built or customized, and the interfaces to the back-end systems need to be built. Third, testing needs to be done before such an application can be deployed in production. These are only a sample of items that a services component involves. The challenge of accurately estimating the cost of this variable increases with the complexity and scale of the RFID application.

• Training and education. This variable generally gets the least attention during the business justification process. However, after the system is up and running in production and the services consultants have moved on to their next projects, the necessity of training to maintain the application might become painfully obvious. You can avoid this "late wake-up call" by building an expert team that you can entrust with such responsibility. In addition, company personnel can "shadow" the services consultants and actively participate with them in the design and implementation of an RFID application.

• Maintenance. Typically, the cost of maintaining an RFID application represents the principal share of its TCO. The cost of the tags is a recurring overhead. Even if the tags are recycled, new tags might have to be ordered to replace the ones damaged during recycling. Spare tags, reader antennas, readers, controller hardware, sensors, actuators, and annunciators, among other items, must be ordered to replace defective/damaged hardware. The cost of both vendor and internal technical support, bug fixing, and enhancements is generally an integral part of the maintenance phase. During an RFID system cost analysis, do not overlook or underestimate maintenance costs.

Figures 8-8 through 8-11 provide some example cost estimates based on actual RFID projects.

Figure 8-8. An example estimate of tag costs associated with a project.

Figure 8-11. An example estimate of services costs associated with a project.

Figure 8-9. An example estimate of reader costs associated with a project.

Figure 8-10. An example estimate of software costs associated with a project.

Cost is probably the most important variable of all, but it can prove difficult to estimate this variable accurately because of the many variables involved. In the heat of "RFID-enabling," companies might underestimate the cost and overestimate the benefits associated with such an effort. One way to avoid this situation is to start small and achieve "RFID-enablement" by approaching the final solution in a series of controlled iterations and use the experience gained at successive iterations. By doing so, you can constrain the cost at each step, which will result in better cost accuracy and estimation compared to if you just build the entire application in a single monolithic step.

8.4.3. Risk

Risk is inherent in any real-world project; only the degree of risk varies. When assessing the risk of using RFID in an application area, you must consider how the introduction of the technology will impact the business. The amount of expected downtime in operations to rectify hardware issues, side effects of a bad tag read operation, the consequences of not being able to read a tagged item in situations such as when it is packed to deep inside a pallet, your customers' perception of the technologyall these can have a substantial bearing on the company bottom line, customer loyalty, and reputation. In certain situations, although the bottom-line risk might be low, the risk of tarnishing a brand image might prove to be a risk that a company can ill afford. How can you determine risk objectively? An empirical way to do this is to evaluate the application risk point scale of 1 to 5 (where 1 represents very low, and 5 represents very high). Input from the members of the cross-functional team, together with the guidance from the experts, can help you to accurately determine the risk involved in an application area.

8.4.4. Complexity

The complexity involved in an RFID application can be hard to estimate theoretically. You can gain a general idea of the complexity from the requirements (for example, from the business flows and use cases) and scope of the application. To validate the complexity assumption, however, hands-on experimentation will most likely be necessary in the form of proof of concepts. At this point, you might need the help of vendors, experienced integrators, and consultants. The implementers and the experts should, in the end, agree on the evaluation. You can use the empirical scale used for measuring the risk of a business case when measuring complexity, too.

8.4.5. ROI Timeline

Although an RFID system might offer solid benefit within a tolerable cost, risk, and complexity range, the ROI timeline might prove substantial. Various factors impact ROI, including obtaining government/regulatory body/union approval, receiving consensus from the important stakeholders, determining and following bureaucratic procedures for necessary clearance, and so on. Whereas an ROI timeline for an application area might be as little as a couple of months, it might also be more than one year for certain applications.