| Identifying the business problem is a very critical step in IT deployment projects. Yet, many times it is overlooked or not addressed properly. A clear business rationale for deploying RFID technology should be established and agreed upon by key stakeholders in the enterprise. For example, line management, operations, and IT groups might be key stakeholders. The rationale should clearly identify what business problem the RFID deployment will solve and what the expected results are. Stakeholder buy-in is critical. Otherwise, one group's needs may be satisfied through the project, but the overall organization's needs may not. Such an exercise also sets the expectations correctly for various groups and defines the scope and boundary of the project, preventing project creepthat is, changing requirements or constant addition of new requirements that a project must meet.  Key factors to consider in this phase are as follows: Strategic Imperative: It is it important to determine why it is critical for the organization to solve this business problem. It could be competitive pressure (as in Wal-Mart's RFID mandate forcing other retailers to follow suit); new regulations or mandates (as in the case of suppliers of Wal-Mart or the U.S. Department of Defense (DoD)); fit with strategic direction of the organization (for example, the company decides to compete based on being the cost leader, and supply chain visibility offered by RFID is seen as a key enabler for streamlining operations to minimize cost); or response to external conditions (for example, the Smart and Secure Tradelanes (SST) initiative described in Appendix A, which was partly undertaken to mitigate the security risk that a large-scale terrorist event could shut down ports and strangle trade). Competitive Assessment: It is important to understand what the competitors are doing, and how the proposed solution will affect the organization's competitive positioning. For example, if a competitor is using RFID for a very broad set of operations and if your organization is looking at a narrow application with limited benefits, which prevents your organization from leapfrogging the competition, it may be time to rethink the scope of the project. Vendor Assessment and Selection: Finding the right vendors who can address your issues is critical. The enterprise's knowledge base about the vendor landscape and track record should be heavily leveraged. (For more information, see the "Knowledge Base" section later in this chapter as well as Chapter 8, "Vendor Considerations and Landscape.") Gaps in that knowledge base should be filled with outside consultants. Many times, these consultants can act as project managers or prime contractors, and help with the execution of subsequent phases of the deployment. Several companies specialize in this area. Special attention should be given to vendors who offer better investment protection, such as open standards-based product road maps and verifiable references. Note that the choice of vendors may need to be modified based on the results of the pilot. This can add significant cost and delays to the project, so it is critical that the vendor selection is done after careful research and evaluation of criteria mentioned in Chapter 8. Cost-Benefit Analysis (High Level): A high-level cost-benefit analysis is essential for a quick go/no-go decision and determination of the project scope and resource requirements. For example, if an organization can do item-level tagging of all its goods cost effectively only if the tag price is less than 15 cents, the current tag pricing will make it ineffective to do item-level tagging. In this case, the stakeholders need to determine if the project still makes sense (go/nogo) or if they need to re-adjust the scope of the project (for example, focus only on case- and pallet-level tagging). In case of Woolworths, Plc. (see case study described in Appendix A), it was understood that the full roll-out would yield enough benefits for the project to pay for itself in one year. The current cost of tags may not be as much of an issue for a company that makes relatively high value items such as electronics or certain prescription medicines and where introduction of item level tagging may significantly reduce shrinkage or counterfeit goods. Key factors affecting cost-benefit analysis are addressed in a separate chapter. Stakeholder Analysis: A stakeholder is any person or entity that is affected by the outcome of a business process and has interest in controlling that outcome to a desired level. A business problem can touch multiple stakeholders. Some of them may not be directly related to the business process. For example, an RFID pilot (sometimes referred to as a Proof of Concept or a PoC) in a manufacturing plant involves several stakeholders. Some of the stakeholders, such as the plant operators, its IT staff, and the supervisor, can be very close to the project. However, the senior management and the finance person are also stakeholders. If the senior management of that plant or division has not bought off on the pilot, it may not allocate the right resources to the project, or may not empower the team in the right way through proper setting of goals and metrics. If the finance department has not bought off on the pilot, the requisite purchase orders for sourcing of parts may be delayed. When the right stakeholders are found, it is important to understand their motivations for (or against) the project. Some of them may have to change the way they have operated for years. For others, it may involve loss of power, resources, or title. Others may be looking at gaining more power and resources. Stakeholders may not readily convey their motivations or may convey negative motivations. For example, the fork-lift operator in the plant may be worried about the need to learn one more process or may not be completely convinced that this is a worthwhile effort. The senior management team may have wrong expectations about the delivery timeline for the results. Unless the expectations of the stakeholders are known up front and reset (in some cases), the project may not succeed fully. The next chapter describes in detail how to mobilize various stakeholders in an organization. Existing Process Discovery: If a process exists for solving the same business problem or a variant, it should be documented and its capabilities analyzed. In some cases, modifying the existing process might be more economical or less risky than starting from scratch. For example, the existing infrastructure designed to leverage data from the barcode in a manufacturing environment might be modified to take advantage of the additional data obtained from RFID tags. In other cases, the existing process might prove to be a step in a planned transition to the new process. In the preceding example, if the existing infrastructure can't handle additional data, it can be used to process the data elements from RFID tags that correspond to barcode data. The rest of the data can be processed later when the subsequent stages of the project improve the infrastructure to handle additional data from RFID tags. During the discovery, pay special attention to processes that enable data synchronization and network enablement of applications. If you don't have a proper process to share data with your customers and/or suppliers in a timely manner, the process should be corrected as part of the architecture. Likewise, if key business applications are not network enabled (that is, they operate in their own silos without proper communication interfaces to others, or require a very cumbersome communication mechanism), the architecture must specify steps to make them network enabled. Scenarios: Also known as use cases, these can act as very powerful planning and risk mitigation tools. This is especially useful in complex, cross-divisional, or cross-enterprise projects. RFID deployments tend to fit this description well, as they can require significant behavior and process change across an enterprise, and sometimes across companies (for example, among supply chain partners). Scenarios can also act as contingency plans. For example, a hospital might create two RFID deployment scenarios: the first for aggressive implementation across the board, based on assumptions about the technology maturing fast (cheaper and more reliable) and providing very high benefits, and the second scenario for a staged roll-out, allowing technology to mature. The second scenario can also double as a back-up scenario should budget constraints force the hospital to do staged roll-out of the technology.
Typical questions to ask in this phase include the following: Is the strategic rationale for embarking on this project clear? Are all the business stakeholders identified and onboard for further exploration? Do you understand enough about the technology and the process to figure out likely outcomes? Are they acceptable? What are the drivers of cost-benefit, and what is the most likely cost-benefit scenario? How will the likely outcome affect competitive position? Can existing business processes be modified to adopt RFID, or do new ones need to be created? Have alternatives been considered?
|
Avoid the following situations: Unclear rationale for starting the project or lack of understanding about how the project will improve the competitive situation Lack of commitment from relevant stakeholders Cost-benefit analysis solely based on the most optimistic projections Insufficient focus on technical architecture leading to data synchronization or other issues that prevent fulfillment of business needs
|
The output of this stage should be a project requirements document, which captures clear project requirements. It is a good idea to make sure that the key points raised in this section are addressed in this document. |
