The Battle of Standards
Purchase order software is a fantastic mechanism for managing and monitoring all of a company’s buying activity and in most cases its receiving activity as well. This type of purchase order system works great when it is entirely self contained. The problem that these purchasing and supply chain management suites inevitably run into though is when they need to integrate with outside trading partners and their respective systems.
Take the example of a retailer that is trying to purchase from one of their suppliers. They may have an excellent purchase order system that can import their supplier’s catalogs, that is linked with their internal point of sale (POS), yet when they send out the purchase order it goes to the supplier in a format that is foreign to whatever sales order management system the supplier may be using. This typically requires the supplier, or one of that supplier’s sales representatives, to manually enter the purchase order into their sales order management system which can be the beginning of a growing cesspool of data entry errors that result in miss-ships and lost sales for the retailer.
In the case of a big box retailer, they can force their suppliers to support their file formats or they simply won’t stock that supplier’s products. These big box retailers have the weight to jam their format, which is typically some form of EDI, down the throats of their suppliers and leave the supplier scrambling to implement a receiving mechanism if they want to receive those big ticket sales.
In the case of mid-tier or specialty retailers, this is simply not an option. So, where to turn?
The good news is that there are tons of standards out there that define trading transactions generically. For example, they define a purchase order via a schema, which is essentially an outline for how a generic purchase order should be built. They define all the fields that the PO should have, like order number, shipping address, ship date, order date, etc… It is then up to each trading partner to implement that schema so that both sides of the trading transaction can utilize the same data from system to system.
The bad news is that there are tons of standards out there. The two most popular after EDI are RosettaNet and OASIS, but there are many more to be found with a little searching on the web. This means that even if you decide to implement a standard for all of your major trading documents, your trading partners may have chosen to implement a different one. Unfortunately, the problems don’t end there. Even if you and your trading partners end up implementing the same standards, there is a good chance that you implement them differently and consequently your data will still not jive from your system to your trading partner’s. This is the primary failing of EDI, it is sooo broad and there are so many different ways to implement it that one 850 document (PO) from one trading partner ends up looking totally different than the 850 implementation of the trading partner on the other end.
So are standards a waste of time? Absolutely not. They at least give you a framework to start with, so you are not dealing with apples and oranges instead something closer to clementines and tangerines. This makes the mapping required to manage different formats from one system to the next manageable.
The best way to deal with standards is by trying to get your industry involved. This is a much smaller, more manageable group that will share many of the same attributes that make up their trading documents. A perfect, successful example of this is the outdoor industry with their OIA B2B initiative. This is a group of like minded professionals who got together and just built a standard to increase the efficiency of all of their businesses. If you do go down this route with your industry, rather than reinventing the wheel, start with one of the commercial standards out there and then adapt it to best meet your industry’s business practices. You’ll be happy you did.