Define and Pilot Solution


This phase bridges the gap between identification of a business problem and wide-scale deployment of a solution to solve that problem. This is a critical link in any enterprise-wide deployment. It provides an opportunity to test the solution in a more controlled environment while preparing detailed plans for a full-scale roll-out. Although it may seem that focusing on the pilot first can slow down the deployment process, skipping this step can lead to costly consequences. For example, improper problem definition leading to a suboptimal solution may not be caught until the wide-scale roll-out of the solution. At that point, the company may have to engage in costly reengineering efforts. Worse, the lost time and money can adversely affect the enterprise's competitive positioning. On the other hand, a well-defined solution can be developed and deployed rapidly, leading to faster time to market.

Key factors to consider in this phase are as follows:

  • Technical Architecture: Definition of a robust and scalable technical architecture is critical in this phase. If the systems can't handle the amount of data generated through RFID tags or if there is no decision support system set up to process this data, the solution won't be as effective. The architecture should support business needs 24/7 through high availability. It should also specify the right data models (data to be captured and processed) that are flexible and expandable, so the solution can interact with various existing applications. This ensures that all applications have access to the same data (also known as data synchronization), so decisions are not made based on stale data. In the case of the Woolworths Plc. pilot, the technology and business architectures were designed to collect and integrate asset-tracking data from barcode, RFID systems, and GPS (Global Positioning System) to construct an overall asset visibility solution. After the position of a truck (carrying goods) was determined through a GPS, the distribution center (DC) was able to pinpoint the location of the goods in real-time by looking up the RFID data from the loading dock to determine which goods were in which truck. As a truck stopped at a Woolworths store and unloaded its goods, the RFID readers in the store would detect the change and update the central system in the DC. The central system would continue to track the truck, but would show an updated list of goods inside the truck. Last but not least, the architecture should adhere to industry standards to avoid vendor lock-in and ensure investment protection from changing standards or proprietary technology that becomes obsolete.

  • Business and Organizational Architecture: If the right business and organizational architecture is not set, the project may never move past the pilot state. The goals of various stakeholders should be aligned and attached to the project. The right business processes should be set up to leverage the data collected. Rules of engagement and accountability should be clearly established to avoid confusion and drive quick decision-making. Detailed process flows should be developed here. A check should be performed to make sure that the solution still supports the strategic direction of the company. For example, when Sun Microsystems deployed an internal RFID pilot in its manufacturing plant (see Sun Microsystems case study described in Appendix A), it created a virtual team consisting of members from the manufacturing unit, Sun's professional services consultants, and engineers from the RFID product team to assemble the right skill set in one team. The team shared the same goal of rolling out the pilot and validating the cost-benefit scenario. Due to the right level of skill set and goals, the team was able to achieve its objective in the desired timeframe.

  • Risk Identification and Mitigation Plan: Risk is inherent in any project. Even the best laid plans can go wrong. Risks can be internal to the organization or external. For example, internally, an architect may miss a delivery deadline for the architecture, delaying the testing phase and risking on-time completion. At an external level, the supplier may run into production issues, affecting the delivery time to the enterprise. Another risk is the time required to convert stand-alone business applications into network-centric applications so they can receive data from the RFID system and use it properly. A well-crafted risk identification and mitigation plan identifies potential internal and external risk factors and provides solutions to minimize or nullify their impact on the schedule. At the very least, such a plan should be developed for deliverables in the critical path of the project.

  • Cost-Benefit Analysis (Detailed): A detailed cost-benefit analysis should be carried out in this phase to make a final go/no-go decision as well as to determine payback period (the amount of time needed for a project to pay for itself). The shorter the payback time, the more attractive the project from a financial viewpoint. This analysis also sets the stage for negotiations with vendors. This is a very important area, so a whole chapter has been dedicated to this topic (see Chapter 7).

  • Stakeholder Buy-in: It is critical to go back to all the stakeholders and make sure that they have bought off on the proposed solution and confirm their role in the development of the solution to make it successful. Chapter 6 describes in detail how to achieve this.

  • Pilot Selection and Execution: In a complex project such as RFID deployment, a pilot provides a great way to verify the validity of the technical and business architecture as well as gather additional data for fine-tuning the solution. The pilot should be designed to check critical elements of the solution. For example, an asset-tracking pilot might reveal that certain assets are hard to track because the tag is applied directly on a metallic surface or that the assets to be tracked are not getting close enough to the reader. Such issues can be fixed more easily if found early in the RFID project as opposed to later in the production system. The pilot may also bring out hardware, software, or architecture limitations that may need to be solved for a successful deployment. For these reasons, we advise you to structure the pilot as a closed loop system (within the four walls of an enterprise only) to exhibit better control over the environment. If interaction with a third party is critical in a pilot, the pilot should preferably be implemented in phases, with latter phases involving third parties (open loop system). When Sun Microsystems was conducting an RFID pilot in its manufacturing plant, it limited the scope to its internal systems only (closed loop system). The plant had to go through several trials and errors to find the optimal tag placement on various components such as server chassis and motherboards.

  • Detailed Business Plan: The plan should document the decisions taken so far and lay out the future course of action. Specifically, it should clearly show the goal of the project, the business problem to be solved, the stakeholders, and the solution architecture. It should also highlight gaps in capabilities that need to be filled, as well as lay out marketing, deployment, and support plans.

  • Success Metrics: No solution is complete if you can't tell whether it was successful in achieving its objectives. Development of the right type of metrics is critical in ensuring that the pertinent data and a process to capture it have been developed and implemented. For example, RFID deployment in a manufacturing operation should track specific improvement in supply chain operations such as inventory turnover or frequency of stock-outs. If a company only tracks read rates for RFID tagged items, but doesn't measure if better tracking enabled by RFID has increased inventory turnover, it can't determine whether the RFID project was successful in making the business operations more efficient. In such cases, the company may not be able to decide the right course of action for future investment in this area. The business architecture should support collection of such data. It is also imperative that after the suitable metrics are defined, the pilot results meet or exceed them. Failure to do so may signify a problem and require thorough review and update of several factors, including the pilot, project architecture, and risk mitigation plan. The definition of metrics varies by application and other considerations beyond the scope of this chapter. However, in general, a supply chain project measures metrics such as the rate of inventory turnover, the frequency of stock-outs, and the improvement in operating margins.

Typical questions to ask in this phase include the following:

  • Is the technical architecture scalable and flexible enough to meet the company's business needs?

  • Do you have the right business and organization infrastructure to enable this project? For example, are the stakeholders' goals aligned? Are rules of engagement and accountability established? Have the right business processes been set up to collect data?

  • Does the cost-benefit analysis justify the project?

  • What risks should you prepare for?

  • Is the pilot structured in a way that its successful execution allows you to determine whether full-scale deployment can address key business needs of the company?

  • How will you know whether this project was successful?

  • Do you have a mechanism set up to roll out a pilot, and capture lessons learned?

  • Have the stakeholders bought off on the proposed solution?

  • Is the detailed business plan ready?


Avoid the following situations:

  • A technical architecture that doesn't address issues such as investment protection

  • Organization infrastructure considered as an afterthought

  • No or inadequate risk mitigation plan

  • No follow-through mechanism to measure the effectiveness of the pilot and act upon its results

  • Success metrics that are so subjective they are impossible to quantify, measure, or compare


The output of this stage should consist of a well-defined and executed pilot, as well as a detailed solution implementation plan, including technical architecture, business analysis, and project measurement criteria. Feedback received from the pilot deployment should be incorporated in this plan. Special attention should be given to mitigation of project risk factors uncovered during the pilot.



RFID Field Guide(c) Deploying Radio Frequency Identification Systems
RFID Field Guide: Deploying Radio Frequency Identification Systems
ISBN: 0131853554
EAN: 2147483647
Year: 2006
Pages: 112

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net