Electronic data interchange (EDI) provides visibility of items moving through the supply chain. Yet enabling EDI has typically been a burdensome experience for most manufacturers, requiring considerable time and financial investment. Technical professionals have long strived to improve the way they perform EDI, through standardized transactions to in-depth education. Yet amidst these difficulties, a new approach has emerged that has transformed this cumbersome data exchange into a newer model that is more aligned with today's global sourcing environment.

Doing It Yourself Only Recreates the Wheel
EDI is necessary for consumer packaged goods (CPG) manufacturers doing business with large retailers the likes of Wal-Mart and Target. However, the conventional approach to enabling EDI has been flawed. This involved creating detailed maps to reconcile data between an organization and each of its retail customers. Manufacturers invested in in-house hardware, specialized EDI software, and highly paid technical personnel to build and continually update these maps. Yet these maps are the exact same maps being built by every other manufacturer doing business with that retailer. In addition, there are lots of moving parts to watch, fix and take care of when you have a system that is transforming data into multiple formats and moving it between multiple locations and applications. To complicate matters, diagnosing and resolving problems often involves cooperatively working with your customer's EDI staff. Sometimes the problems are caused by the manufacturer. Other times, they are caused by the manufacturer's customers. Playing the 'finger pointing' game when this occurs requires a tricky balance of diplomacy and technical expertise.

All manufacturers face specific rules for how to electronically exchange business information, such as purchase orders, inventory status, shipping and packing information, sales forecasting data, and invoices with its retail partners. Since each manufacturer must conform to the same rulebook or EDI guidelines as all other manufacturers, and build out the maps exactly the same way as mandated by the retailer, many companies are essentially paying a whole lot of money to reinvent the wheel. This begs the question: Why would a manufacturer need in-house IT expertise to perform a task that is not core to their business and does not provide any competitive advantage? Moreover, whenever a map change or a communication exchange problem arises, each company's team has to learn on its own the best way of solving the problem. For example, each time Wal-Mart revises its mapping rules, there could be hundreds of manufacturers around the globe, each with its own technical team, left with the same conundrum - yet each one left to solve the problem on its own, in a vacuum.

This is called a 'single-tenant' approach, where each organization undertakes a technical project on its own. This is clearly not an efficient approach for managing technical areas that are not core competencies within a business. Moreover, EDI systems are continually in flux as new retailers, grocers, distributors and other trading partners like freight forwarders, 3PLs and sourcing companies are added or existing retailers change or expand their EDI specifications. With a single-tenant model, manufacturers are stuck muddling through these changes on their own.

Another drawback of a single-tenant model is that over time integration of trading partner data to their own systems can become a hairball. The single tenant model never forces supplier organizations to separate retailer logic from the application layer. This means that every time a manufacturer begins working with a new retailer, it must build a new application map code, too, thereby modifying the application layer, and a test of the retailer interface, and retesting all existing retailer interfaces.

Capitalize on Existing Integration
Many manufacturers today have eschewed the single-tenant model in favor of a multi-tenant solution that capitalizes on the work of many. This involves partnering with a third party service provider that leverages a pure architecture where trading partner mapping and application mapping are separated, a common infrastructure, retailer maps and labels, monitoring and administration tools, and staff across hundreds or thousands of manufacturing customers. This brings obvious economies of scale for manufacturers looking to build and update maps. More importantly, it enables each manufacturer to leverage the wealth of knowledge that the EDI service provider has gained implementing and supporting EDI for a vast number of clients.

The multi-tenant approach is akin to the payroll services model that is so prevalent in today's corporations. Years ago, most companies had their own hardware, software, and specialized staff to keep up with ever-changing payroll regulations. Today, that no longer makes sense. Not only was it way too expensive to manage payroll in-house, these financial investments in in-house payroll capabilities gave the companies no competitive advantage. Thus, payroll is now typically outsourced to firms like ADP. The task of maintaining the necessary IT infrastructure and associated payroll knowledge is left in the hands of these payroll services. With this multi-tenant solution, the cost of payroll processing is spread across many companies and the payroll company leverages the knowledge gained through countless engagements to benefit its client base.

Ideally the service provider - having made EDI and B2B integration its core business - has developed strong alliances with retailer clients that these businesses are interfacing. This goes a long way toward ensuring reliability and smoothing out potential EDI issues. And because the providers are tapped in to the leading retailers, they often are the first to know when a retailer is about to alter its EDI rules. Thus, they can adapt their EDI service proactively instead of waiting for a new mandate that could cause errors or downtime.

The Better the API, the Smoother the Transition
Getting started with an outsourced EDI provider isn't always simple. The transition may be smooth or rocky, and much of this depends on the code that the service provider relies upon. Setting this up with an EDI vendor often requires that the manufacturer provide bridge code to interface their accounting or operational systems with the vendor's application programming interface (API). Producing this bridge code can be resource-intensive and delay the solution.

To make the integration process easy for the client, the EDI provider should construct its API with a layer of abstraction that hides all the complexities associated with understanding the retail customer's rule books, EDI, or XML, or transaction sets. This allows suppliers to focus on what they know best: getting data imported, validated and exported in and out of their operational systems. This level of extraction also facilitates reuse. Instead of having to rewrite and retest code each time a new retailer is added, the service provider uses one 'uber' map that gets reused across all retail customers. To add a new retailer requires only the conversion of transactions. This dramatically reduces the time and cost involved with EDI management. Therefore, the API provided by the service provider can make the difference as to whether the transition from an in-house software application to a fully outsourced service provider can be as smooth as VAN migration or as difficult as rebuilding application from scratch.

Case in point: Western apparel manufacturer Arena Brands Inc. had outgrown its manual, in-house EDI system. Its internal EDI software required that all communications be manually entered. Further, it required IT staff to monitor it constantly for inbound EDI transactions from their retail customers. When Arena's retail customers began requiring advance ship notices and other advanced EDI requirements, the company decided to find a better alternative. They completely outsourced EDI to SPS Commerce so they could be relieved of EDI operations and focus on other IT projects.

Since SPS Commerce already had a large customer base, including many retailers that Arena worked with, the transition was easy. The EDI mappings for Arena's transactions were already created and in use. The transition just involved integrating with Arena's ERP system, Oracle Financials. Additionally, because retailer logic is separated from the application layer, it is extremely easy to add new retailers. Today, Arena has EDI connections with 21 retailers and can bring on new retailers in one to two days.

Conclusion
Investing in costly technical infrastructure and staff for managing in-house EDI systems is becoming a thing of the past. More than 50 percent of enterprises are either using or considering using on-demand applications as part of an overall supply chain management solution. In fact, in five years, 25 percent of new business software will leverage the SaaS model. Savvy manufacturers realize there are service providers who have already cultivated the expertise, infrastructure, and relationships to manage these tasks with ease. Further, those service providers with clean APIs that clearly delineate the application mapping layer from retailer logic are adding value by enabling manufacturers to adapt and grow in ways never before possible.