Expand +



How Strong Is Your Auto-ID Strategy?

by Taylor Erickson

August 11, 2009

SAPAuto-ID Infrastructure (SAP AII) provides the foundation on which you build your RFID applications. With RFID technology changing and your future needs uncertain, it's important to have an SAP AII strategy that can adapt to unexpected change.

Some of your most important data is also the most difficult to get into your ERP system: inventory counts, asset status, location of goods in transit, or glitches that occur on the shop floor. The faster you acquire and report on this information, the better you can use it to improve business performance. Unfortunately, such data is often collected and entered manually - usually a slow process.

These six recommendations are intended to help those challenged with the task of bringing Auto-ID into their organizations.

If you've been exploring RFID to automate data collection tasks, you've probably heard the term "Automatic Identification," or "Auto-ID," which is a collection of industry-driven standards for connecting computers to a host of technologies including bar codes, voice or image recognition, and RFID tags that help devices automatically recognize and enter data.

SAP supports RFID standards throughout its RFID technology stack. This stack consists of SAP Auto-ID Infrastructure (SAP AII), SAP Exchange Infrastructure (SAP XI), preconfigured BI, and Event Manager for tracking and tracing. SAP AII is supported by the SAP NetWeaver platform and consists of an ABAP application running on SAP J2EE Web Application Server (Web AS) 6.40.

SAP AII receives raw data from the devices and converts it into business process information. This can be done in either a standalone deployment or by making key associations with the back-end information and functionality in your R/3 or mySAP ERP system.

For example, a warehouse picker confirms picking in SAP after pulling 20 items off the shelf and grouping the items on the packing floor. The picking confirmation status in SAP triggers a business process in the form of an Interactive Document (IDoc) that passes this information to SAP AII, and by extension, the packer's handheld RF device. The packer triggers the RFID tags on the items, loads them on a pallet, and associates the items with a single handling unit (HU) by scanning an RFID tag located on the pallet.

This process triggers an IDoc from SAP AII back to SAP updating the packing status in the ERP system. The packing confirmation in SAP triggers a new IDoc to SAP AII that prepares the handling unit for loading. As the pallet of goods is physically moved under the loading dock archway (and loaded onto the truck), an overhead RF reader triggers the RFID tag on the pallet and sends an IDoc to SAP, updating the load status in the delivery and triggering the post goods issue and advance shipping notification.

With each new data-capture technology you bring into the fold comes a host of decisions. Without a cohesive strategy to cover them all, integrating data-capture technologies with ERP systems can lead to time and cost overruns and become a support and maintenance nightmare. Developing a comprehensive Auto-ID strategy - one that supports multiple technologies in a single framework - can save you time and money while also providing enterprise flexibility.

Bottom line: Your SAP AII strategy is only as strong as its weakest link. Creating an enterprise foundation that can grow with your business and adapt to new and changing technologies is the primary challenge. Working with industry experts in data capture technologies and software - including numerous RFID vendors, middleware companies, SAP, and various SAP customers - has helped me to hone an approach that is crucial to meeting the task. The following six recommendations are intended to help those challenged with the task of bringing Auto-ID into their organizations.

Recommendation #1: Embrace the Electronic Product Code (EPC)

The EPCglobal Network, a joint venture between EAN International and the Uniform Code Council (UCC), drives the Electronic Product Code (EPC) as the global "license plate" standard that uniquely identifies products in the supply chain. As more companies explore RFID, I'm hearing the following questions asked with increasing frequency: "Should I worry about EPC if we are doing a small, closed-loop (within the four walls) RFID pilot?" or "Should I worry about EPC if we don't have writeable tags?"

In response, I recommend contemplating the question: "Are the benefits of not considering EPC worth risking the possible costs associated with retrofitting EPC later on?" One of the key goals of performing a pilot is to gain practical knowledge. For some companies, a pilot may be the ideal time to cross the EPC learning chasm and if your supply chain strategy involves sharing product information with partners, industry participants may hasten the adoption of EPC standards.

The back-end integration component of SAP AII supports EPC serial numbering with IDoc creation. The EPC serial number ranges are housed in SAP in a cross-client table. The process of defining the EPC number ranges is accessible through the Implementation Guide (IMG).

The request for the next EPC is generally communicated through the use of IDocs, either from SAP AII or an application transaction in the back-end SAP supply chain system.

Recommendation #2: Know Your Core SAP Systems

SAP AII works lockstep with the back-end SAP system. It is important to know how the following processes and technical areas in your SAP system work with SAP AII to get a head start on your development effort.

  • Logistics processes: Become familiar with the inbound logistics processes in SAP, including the configuration and steps involved with unloading and unpacking. Also, explore outbound logistics processes, including the SAP configuration and steps associated with packing, handling unit management, and loading.

  • PID and HUM: Packing instruction determination (PID) is used within handling unit management (HUM) to create packing proposals for documents. Become familiar with configuring PID settings and working with HUM. Make sure you can create packing instructions and packing proposals.

  • IDocs: IDocs are the primary communication mechanism used in SAP AII. Become familiar with IDoc creation and customizing, and explore how IDocs can be triggered with output determination. Also, investigate using Business Add-Ins (BAdIs) to enhance IDoc processing. BAdIs allow you to modify information, such as expiration or due dates, in the IDocs after mapping. They can also assist you with triggering a notification email or database update after the mapping or posting of IDocs.

  • Scheduling jobs: In some cases, you may choose to have IDocs sent with a scheduled job instead of immediately. Become familiar with scheduling jobs and understand how to create a variant for program RSEOUTØØ (Process all selected IDocs) for each message type.

Recommendation #3: Form an Auto-ID Strategy Team

The broad scope and potential applications of SAP AII can inadvertently lead an unfocused company down many solution paths. For example, a team working on wireless connectivity may pursue a technology framework that is inconsistent with the direction outlined in an RFID pilot. Bar code and personal data terminal (PDT) efforts may further complicate the situation by requiring software rewrites to the handheld PDT unit. An SAP AII strategy team focuses on the broader context of applying a host of technologies to help machines identify objects. SAP AII provides a unifying framework to help guide the efforts of the team. SAP AII crosses many disciplines, so team members need to have an intimate understanding of business processes, familiarity with SAP AII technology enablers, and a vision for applying technology to improve business. A prototypical Auto-ID team should include supply chain subject matter experts (SMEs), SAP functional members (typically sales and distribution, materials management, and production planning), ABAP and integration developers, and business process experts. Executive support and a clearly defined strategy are essential to the team's success.

Recommendation #4: Meet the FAS Imperative

The key challenge for the SAP AII strategy team is building a solution that meets three criteria: flexibility, adaptability, and scalability, or FAS.

  • Flexibility: From a technology perspective, one of the primary objectives of the SAP AII strategy team is to avoid painting itself in a corner. For example, an enterprise decision to adopt passive tagging should not rule out the option of using active tags in the future. A closed-loop RFID pilot should not be at the expense of pursuing open-loop strategies. Flexibility is required to ensure the impact of retrofit implications are kept to a minimum.

  • Adaptability: The pace of change in Auto-ID technologies is almost overwhelming. A key challenge of the SAP AII strategy team is to build a technology infrastructure that can support multiple Auto-ID technologies. In the late 1990s, a progressive Fortune 500 company was starting an Auto-ID team when it decided to incorporate bar-coding into its SAP system. The company realized that whatever interface it designed needed to support future initiatives targeting around wireless connectivity and PDT interfaces.

    The Auto-ID team leveraged SAPConsole and incorporated design standards that forced technology adaptability. Now, as it pursues RFID, the team has confidence that its existing interface framework can support the demands of an RFID pilot. This confidence allows the team to focus on the unique challenges of RFID (tag placement, duplicate reads, testing environment, RF interference, and so on) instead of crossing the familiar threshold of designing new interfaces to SAP. However, the team is also identifying the limitations of its existing framework and exploring the advantages of adopting SAP Exchange Infrastructure and SAP AII. What remains unchanged, however, are its broad Auto-ID strategy and the goal of maintaining adaptability.

  • Scalability: Some RFID early adopters are discovering that the methodologies and operations used during test pilots cannot support a large-scale initiative. For example, a localized middleware solution may have worked for the pilot, but when rolled out globally, with hundreds of users and thousands of products, the pilot solution needs a large infusion of capital and resources to handle the increased transaction processing and database requirements. One of the key issues facing the SAP AII strategy team is to design processes and technologies that work not only in pilot scenarios but are also scalable.

Recommendation #5: Separate Development and Testing

SAP AII projects are complex because they comprise a critical chain of interdependent activities. Teams are faced not only with SAP configuration and interface challenges but also new sets of master data, device controllers, roles and authorizations, message dispatching, action handling, and a host of other activities.

I recommend separating the Auto-ID technology and processes into discrete units for development and testing. SAP AII provides a good framework. The infrastructure is based on two main services: core and integration.

Core services have four main components that you can test individually:

  • Action and process management
  • Configuration and administration management
  • Object data management
  • Lean master data management

Integration services enable integration with three different entities:

  • Human, including the SAP AII cockpit
  • Back-end system
  • Device

SAP provides a powerful tool, the SAP AII Traffic Generator, to help you start testing the core services without first having to cross the integration challenge. The SAP AII Traffic Generator is a Java-based Web application that allows you to test SAP AII functionality without using real RFID devices or even a back-end SAP system. You can also perform stress testing by simulating large data loads and heavy traffic. The SAP AII Traffic Generator will help ensure your core services around RFID are solid before you take that unfamiliar step into new RFID hardware and interfaces.

Recommendation #6:
Prepare for Decision Making Under Uncertainty

The technology, processes, and standards underlying Auto-ID are continually evolving. A lack of data or agreed-upon best practices is the norm, and this magnifies the risks and rewards of decision-making. Don't let the lack of comprehensive information or accepted industry standards paralyze you from pursuing a technology that is consistent with your SAP AII strategy.

Strategic factors like improving supply chain transparency and collaboration, or strengthening manufacturing processes and business intelligence, need to be considered in addition to ROI. Also, recognize the strategic value of flexibility.

One company's per-unit ROI looked great if it ordered five times the number of RFID tags required for its initial pilot, due to the scale efficiencies offered by the vendor. The Auto-ID team feared the long-term implications of such a purchase. They reasoned it would be difficult to pursue alternative RFID strategies if they possessed excess inventory of their pilot tag. The option of paying a higher per unit price, and maintaining strategic flexibility, was a better value than the alternative of achieving a higher per-unit ROI and compromising agility.

Remember, Auto-ID is a broader framework than just RFID, supporting a wide range of data-capture technologies. By developing your Auto-ID strategy, you are laying a foundation that can accommodate change and support your business for the long term.

Visit to learn more about EPC and how your company can gain access to the EPCglobal Network. You can also download Version 1.0 of the EPCglobal Network, which contains a series of technical specifications for every component in the EPCglobal Network. In addition to the EPC, explore other global Auto-ID concepts, such as the Global Trade Item Number (GTIN), Serialized Shipping Container Code (SSCC), European Article Number (EAN), and the Universal Product Code (UPC) - all of which work with SAP AII.

Taylor Erickson has more than 12 years' experience with ERP systems. He has worked with SAP for eight years, specializing in SD and SCM, reporting, and compliance. Taylor is a member of the Institute of Internal Auditors and has facilitated global SAP system implementations and trained numerous SAP customers. He is currently a manager at Deloitte Consulting. Before that, he was a consultant for SAP America, Inc., and later, practice director of corporate compliance and security for Virtuoso, LLC. Taylor is working on a team that is exploring strategies to add value to the supply chain by integrating RFID with SAP. You may reach Taylor by email at

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!