How do I implement?
The EFM Documents tab of this website contains a number of resources that can help you implement EFM. The EFM Package documents located there describe the technical details of EFM and how it can be implemented. While the EFM package documentation and software can be downloaded for free, there are additional implementation costs as well as ongoing maintenance costs both to the supply chain owner (primary adopter) and their supply chain partners. The flow chart shows the general steps that a company would need to follow in defining the scope of the use of EFM on a supply chain, in designing and developing the data and software needed to exchange data, and in implementing and testing EFM.
EFM Scope Definition
Define the supply chain network
Define the supply chain network and work with all of the partners along the supply chain to coordinate data exchange processes and testing, implementation and operating parameters. In CEFM, The Limited Brands chose several China-Hong Kong-Columbus air freight supply chains.
If your supply chain involves multiple partners, multiple modes of transportation, and international borders, EFM’s unique shipment identifier, the Unique Consignment Reference (UCR), provides a common reference for all partners as various waybill, bill of lading and container numbers are assigned to the shipment and used by partners for internal tracking. The CEFM test successfully demonstrated the creation and use of the UCR.
Of course, the ability to track an order and shipment, as well as the integrity of the data and events reported, rely solely on the capabilities of the supply chain partners. The quality of the solution and the ability to realize benefits can often rely on the lowest common denominator. Therefore, it is critically important to work with all the chosen supply chain partners to obtain their commitment and continue to coordinate with them until EFM is tested and implemented. The EFM Adopter’s Questionnaire is useful in articulating needed information about supply chain partners.
Partner classification
There are three types of EFM partners: data providers, data consumers, and both.
- A data provider is expected to provide information related to a shipment but is not expected to receive information from other partners for their use. In CEFM, the manufacturers were data providers and, in fact, the only partners that actually entered data manually into CEFM.
- A data consumer receives supply chain information from providers, and uses this information in accordance with their internal business processes. The primary consumer is the supply chain owner, possibly the receiver of the freight. In CEFM, the receiver consumed the data, but another division of the owner originated the purchase orders that initiated CEFM shipments. No other partner in CEFM was strictly a data consumer.
- The third type combines the other two, both using and providing supply chain data. Most supply chain partners would perform both roles, usually by providing automated status information from their logistics systems and receiving or viewing status data from other partners in the supply chain. An example in CEFM included the freight forwarders, who provided data about shipment departure, managed overseas containerization and transportation, and then consumed status information and electronic advance shipment notices (ASNs) nearer to the U.S. destination.
Determine partner authorization
The primary adopter (in many cases, the supply chain owner) control what data they provide to EFM partners and which of their partners can access or receive the data. Only authorized parties may access certain shipment records. Who may access the data, and what they may access is determined by the shipment owner. In CEFM, a partner was not privy to information that they did not have a need to know or that was business sensitive or might be used against a competitor.
Data to be exchanged
Each supply chain partner participating in EFM will need to map data from existing logistic systems, as well as hard copy or other manual documents, into standardized formats in order to exchange information within EFM. The EFM Package contains database schemas and other information about data formats and EFM documents. Manual documents can be converted to XML documents using the Web services provided in the EFM Package. Users should define their output data and reporting requirements. If they have existing logistics system outputs, users will need to determine the EFM data required to update the output reports. If users do not have existing automated outputs, they should assess the outputs available from EFM and assure that the required data is present.
EFM Implementation Models
There are three functional models with varying degrees of data integration, sophistication, and cost. EFM participants need to decide whether to implement the Web Portal model, Hybrid model, or Fully Integrated model. The fully integrated model provides the most benefits with less data entry, yet is the most complex to implement. The Web Portal requires only an Internet browser to view supply chain data and make any required inputs, but requires manual inputs and is more limited in potential benefits. The Hybrid model is a combination of the Fully Integrated and Web Portal models. Each model is described in more detail below.
Fully Integrated Model
A fully integrated implementation includes seamless electronic transfer of key data into a company’s own logistics system, eliminating the need to re-key or manually transfer updated data from EFM to the logistics system. The data within a company’s internal logistics system can be automatically populated and updated using EFM’s Web services, so that the user can take advantage of existing familiar screens or output reports. The fully integrated EFM model requires a server, either a “virtual” server consisting of dedicated space (approximately 10 GB) on an existing server, or a separate hardware server. In CEFM, the fully integrated user achieved more benefits as a result of the automated data. Although the data was integrated, the CEFM user also found that having access to an EFM Web user interface made it possible to view transportation status messages and update screens as non-integrated partners saw them. With the fully integrated model of EFM, a requirements generation process should be undertaken to define data inputs and outputs, mapping, and partner collaboration. The process should include IT and operations organizations within the company.
Hybrid Model
In a hybrid approach, the implementing company’s existing logistics system remains intact and isolated from EFM. The hybrid model of EFM requires a server, either a “virtual” server consisting of dedicated space (approximately 10 GB) on an existing server, or a separate hardware server. The Web services and SOA are implemented on that separate server and simply link to the organization’s existing system. In a hybrid implementation, the existing logistics system acts as the data source while EFM acts as a value-added network that routes consignment information in a secure environment with XML messaging and Web services transmitting messages. In CEFM, a database was developed for each partner to hold data from the existing system and isolate the existing system from the Internet.
The hybrid approach is often appealing to supply chain partners who are not ready for full integration with an existing logistics system, or who prefer a staged transition to EFM. The hybrid approach is not considered to be ideal for the long-term as only full integration provides automated access to all EFM data. Without full integration, data received from EFM supply chain partners must be rekeyed or manually transferred from the EFM hybrid server database into the company’s existing system. A requirements generation process should be undertaken to define data inputs and outputs, mapping, and partner collaboration for the hybrid model. The process should include IT and operations organizations and should address how the existing data is transferred into EFM and then how EFM data from other partners is displayed and potentially transferred to the existing system. The implementation costs of the hybrid model generally fall in between Fully Integrated and the Web Portal implementation costs.
EFM Web Portal
Partners with manual processes or who do not want to be a provider or consumer of data can use the Web Portal model of EFM to achieve automation of supply chain data exchange. With the EFM Web portal implementation model, users access the database and Web services via the Web and do not require additional software on the user’s system, beyond an Internet browser. In this model, EFM acts as a third party host for the participating partners’ functions and data. Use of the Web portal means that other partners’ data and EFM transportation status messages can be viewed without further data entry, although providing data or responding to other partners would require manual inputs. Web portal users with existing logistics systems would have to rekey data to take full advantage of EFM’s automated supply chain data. This is the least expensive implementation model, but cannot achieve all of the benefits because of the data rekeying that is required.
Development: Using the EFM Package
Once an adopter has decided to implement EFM and has selected one of the implementation models, the details of the design need to be worked out by the IT and operations staff in close coordination with the supply chain partners who will be participating. The EFM Package and other documents on this website provide guidelines, checklists, templates, and components that should make EFM implementation easier.
The EFM Package. This package consists of two major functional areas. The first is the underlying infrastructure, which is the basic platform on which the EFM web services operate, and includes the security and network operations that transfer data via the Internet to and from authorized EFM partners. The second functional area is the specific application software which implements the end-user configurable, JAVA-based web services (the EFM Package contains the 20 Web services tested in CEFM), as well as the necessary database schemas needed to support each partner SQL database.
Use Cases, Web Services, and Interfaces
Working with the adopter who has defined the data flows and partners, the developer will need to create the use cases for each of the data exchanges with each partner and determine which of the 20 EFM Web services can be used as-is, which need revision or identify any new Web services. Template use cases are available as part of this website.
If the Web Portal model has been selected for implementation, the developer will need to create the appropriate web pages and modify EFM outputs in conjunction with the prospective users. If the Hybrid or Fully Integrated models are to be used, the developer will need to build the appropriate software interfaces to obtain the needed data from existing systems that will be shared with other partners – and if appropriate, to provide EFM data to automatically update existing systems.
Technical architecture
For the two more sophisticated models, the developer will need to establish a server environment to host the architecture components such as the EFM Registry and network coordination as well as the web space and interfaces needed to share data with partners. They will also need to define the UBL message schemas that will be used in their deployment.
These activities are described in more detail in the documents on this website, including the EFM Deployment Guide.
EFM Implementation
Once the EFM capability has been designed and developed, it needs to be implemented both within the user’s local IT environment and within the network concept designed for sharing data with supply chain partners. An important aspect of the implementation is to thoroughly test the network and assure that all interfaces, network connections, and partner interactions are working. Related to system testing is user training, which should be done for both the company’s users and for each trading partner. Even if basic supply chain processes do not change, there will be Internet and partner interactions and use of EFM’s outputs that must be understood before they can be used operationally. Software will need to be moved from a development environment to operational systems. Implementation details are contained in the documents on this website and questions can be raised to points of contact identified on the website.