What's wrong with trading partner portals
Wednesday, September 8, 2010 at 4:49PM Retail trading partner portals have been creating somewhat of a buzz lately. We happened to read an article in the current issue of the Journal of Trading Partner Practices titled, "Using Portals to Improve Collaboration." Not surprisingly, we have been receiving a lot of questions from vendors regarding the challenges they face in managing trading partner portals.
Just in the past two weeks, vendors have called to asked questions about trading partner portals for Wal-Mart, Target, JC Penney, Goody's, Lowes, Home Depot and Walgreens.
The stated objective of retail trading partner portals is to create a more open and collaborative relationship between the retailer and their vendors by sharing POS activity and other important documents. The expectation is that open communication will improve sell-thru and in-stock. But unfortunately, the proprietary nature of the portals is greatly limiting their effectiveness.
One of our vendor customers has more than two dozen retail customers. Among those retail customers, about two-thirds have a trading partner portal, so this vendor must log-on to more than a dozen different websites each day to analyze POS and conduct other critical business. This is very time consuming and inefficient. For this vendor, and many more like them, these portals have quickly become a huge drain on their staff time and efficiency.
What are some of the issues with trading partner portals? Each portal is different, so vendors must learn the in's and out's of each. Data format and availability is different for each portal. The data available in the portal is often different than the data available in EDI 852. e.g. some retailers only report dollars sold within a portal. Many retailers do not permit 3rd parties supporting the vendors to have access to the portal. This discourages a vendor from seeking out category management and data analysis assistance they may not have in-house. The data available within the portal is often very different than the data sent via EDI 852. We have seen large variations in units on-hand reported for an item.
What's wrong with EDI 852? EDI was created many years ago to standardize the format and transmission of data between trading partners. In other words, it was designed to eliminate the proprietary ways of doing things (think trading partner portal) and get everyone within the supply chain onto one single framework. EDI has limitations, but at least it provides a consistent and universally acceptable means of transmitting data.
Trading partner portals are not inherently a bad idea. Like many technologies, they have just been over extended in ways that don't necessarily make sense for end users. In our conversations with vendors and our review of various trading partner portals, we have found they do have some good uses. First, they are very good for communicating vendor compliance information. In the retail world, compliance information changes daily. Trading partner portals provide a very effective path to communicate shipping requirements, labeling requirements, vendor score cards and other related information. Portals are also very effective for communicating store information and standard document formats like EDI document guides. Unfortunately, many of these portals have been turned into an analysis tool, and for the reasons we outlined in part I of our series, this is not a good application. If POS data is going to be provided through the portal, it should be provide as a simple tab delimited text file, so vendors can simply download the data into their analysis tool.
Vendor portals are also very effective for establishing vendor support communities. Many vendors that support retailers are fairly small organizations. They benefit greatly from the ability to connect with other non-competitive vendors to share ideas and tips. When the vendors improve their capabilities, the retailer benefits too. Some of the best portals we have reviewed provide user groups by geographic region and product category. Some even go so far as to provide user group meeting information, agendas and contacts. This is a very good use of the portal.
One technology we would like to see more retailers incorporate into their trading partner portals is RSS. Really simply syndication (RSS) is a push oriented technology that notifies a vendor when news or other information has been updated. This greatly increases the efficiency of communication because a user does not need to constantly visit the portal and check for updates.
This is the third part of our series on trading partner portals. If you missed part I or part II read that before continuing.
In the first two parts of our series on trading partner portals, we discussed the limitations as well as some positive aspects. In this third and final part, we want to discuss how your organization can dramatically improve the efficiency of your POS and EDI 852 data analysis.
The most efficient way to handle multiple trading partner portals is to first understand they serve two distinct purposes: (1) communication of vendor compliance information and (2) providing POS or 852 data. There are numerous services available which monitor trading partner portals and supply vendors with automated announcement of compliance changes. These services are valuable and worth investigating. You might consider Trading Partners Collaboration as one good resource or Vendor Compliance as another resource.
Many vendors we talk to have not fully considered tools to automate the analysis of POS data. They are working in each of their customers portals or manipulating data in a spreadsheet. This is time consuming and inefficient. Improve your processes and consider a service like Accelerated Analytics, which can provide item and store level analysis without manually gathering data from the trading partner portals or manipulating data.