|
|
|
|
|
|
|
Understanding
The Barriers To Electronic Business-To-Business Relationships By:
Norman Katz, Katzscan Inc. The ability for two companies, such as a provider of goods or services and the customer purchasing them, to transact business electronically is a relationship that can be very difficult to attain but one that offers great satisfaction and efficiencies once it is achieved. Many software vendors like to tout the capabilities of their product to perform these relationships, but while the technology is very much present, the operational barriers that exist at both ends can hinder to the point of preventing an electronic business-to-business (e-B2B) relationship from ever coming to realization. Electronic Data Interchange (EDI) is probably one of the most well known and widely used methods of e-B2B. Since 1992 I have been helping my employers and clients setup and integrate their EDI systems as part of vendor compliance, as well as talking to other companies about doing so and offering advice when I can. I seem to consistently encounter the same basic barriers (and mistakes) when it comes to the approach to e-B2B data processing. These mistakes have less to do with the e-B2B methodology and more to do with systems & data architecture and shortcomings. Barrier
# 1 – Data Unification Companies sending data to vendors, such as purchase orders, do so from a single source computer system. While their may be a few different types of purchase orders, (i.e. replenishment versus blanket), all purchase orders of the same type look the same. This approach should be used when vendors receive electronic transactions: all transactions of the same type, such as purchase orders, should be processed (received and translated) to a single data file structure before being passed to the sales order processing system. Customer A might send a data field that Customer B does not. So, for Customer B, this data field will be blank in the output file that is the result of all inbound purchase orders. Customer A might require this data field to be returned on the invoice, which is not a requirement of Customer B. Or, Customer A may be simply sending this additional data field but does not require it to be returned to them on any other electronic document. For vendors, outbound data should be treated the same way. From the accounting or shipping systems, invoices or electronic shipping documents (advance ship notice, bill of lading) should be exported to a single data file structure against which data translation will occur on a customer-by-customer basis. Data unification makes data auditing, the next barrier, a much more efficient process. Barrier
# 2 – Data Audits A direct benefit of data unification will be that auditing the data becomes a much easier process to perform programmatically. Data audits are necessary when the host business application is not capable of checking the correctness of electronically received data. Typical data audits for purchase orders could include the following:
In the event the host business application cannot audit the data sufficiently, an external application will have to be developed to perform this function. However, with the data in a unified file format, the auditing process becomes much more straightforward. For example, regardless of whether a customer sends a purchase order with their item code, your item code, or the UPC (if applicable), a data audit program would simply check each of these three unique data fields in the unified file and, upon finding the non-blank field, would check to ensure it was a valid value. (I would also suggest cross-checking non-blank item fields, as I have encountered incorrect UPC’s assigned to item numbers in purchase orders.) The entire invalid purchase order would be held out from processing, and good purchase orders would be sent through for import into the host business application. Auditing the data outside the host business application also isolates a company’s business system from erroneous but structurally correct data. For example, if a product is sold in case quantities of four, than a purchase order for this product must have a quantity represented as a multiple of four, the minimum sale quantity for the product. This purchase order should not be accepted by the business system until the product quantity is corrected. Thus, this erroneous data did not engage a manufacturing or inventory commitment, and reduced the amount of manual intervention to “back out” the erroneous data. Barrier
# 3 – Data Additions Inbound electronic documents may contain data fields the customer requires returned to them. Additionally, the customer may require data values on electronic documents you send to them (i.e. invoices, ship notices, bills of lading) but did not exist in any inbound electronic document (i.e. purchase orders). This data is most likely some cross-reference information, such as the name of a customer store (when only the store number is sent in the inbound document). If these additional data fields cannot be stored in the host business application because there are no data fields available, then this information must be stored in an external application that is referenced whenever outbound documents are created. Once again, having a unified data file helps to resolve this dilemma. Once the data is extracted from the host business application and formatted to the unified file, another application can simply pass over this file and “fill in the blanks” with the appropriate cross-reference information, or add the missing data to an expanded unified file format. With the unified file now complete, data mapping (translation) and communication to your customer can occur. A unified file format
also simplifies the task of outbound data mapping.
Granted, each trading partner (customer) will have their own
unique mapping requirements, but across all customers, the mapping
requirements for the same document (i.e. advance ship notice) should be
mostly similar. Thus, when
creating the mapping logic for Customer B, you should be able to start
by copying the mapping logic for Customer A and making only minor
modifications. Barrier
# 4 – Open Communications It is important to note that both parties must be willing to meet at the bargaining table when forming an e-B2B relationship, but this is rarely the case from a vendor compliance standpoint. However, those enforcing EDI or some other means of e-B2B would do well to understand the complexities faced by their suppliers and be willing to make changes to requirements and updates to their own computer systems. I hear often that vendor compliance directives are not enforced, or their deadline extended, because so many vendors have complained or simply cannot comply by the deadline date. Likewise, I have had to complicate my clients’ systems and procedures to compensate for the data processing shortcomings of a trading partner. For example, a pallet record should not be required in an EDI Advance Ship Notice when shipping via small parcel carrier (i.e. FedEx, UPS). Instead of the trading partner making the corrections to their computer system, they forced all their thousands of vendors to modify their computer systems to comply with this requirement. Companies are quick to identify compliance requirements but not the solutions, leaving up to the vendors to source out the technology and professionals required, and take a chance on selecting the right technology or quality consultant. An open communication forum before vendor compliance requirements are established would help greatly to avoid missed deadlines and vendor complaints. Recommendations for local help to vendors are blocked due legalities and a fear of retribution by the vendor should a solutions provider fail to provide the right compliance solution. There is validity in this concern, but large companies would do their vendors a great service by providing some type of solutions directory with a disclaimer in regards to the selection of the solutions provider. (I see similar disclaimers in the print and television advertisements from lawyers.) Additionally, large trading partners with the technical resources should develop and make available (for a nominal price) to vendors simple solutions for compliance, such as off-the-shelf barcode label software and pre-designed compliance labels and a barcode printer. In
Summary Traditional EDI as a language has morphed over the years to become a “non-standard standard” – there is so much flexibility that the same concept, such as a replenishment purchase order, can be represented multiple ways. Each variation requires custom translation (mapping) on the part of the vendor receiving this electronic document. Utilizing the data unification, data audit, and data additions methods described here, it is possible for a vendor to make their internal data processing more efficient and effective, reducing the costs of developing external applications for reviewing inbound and outbound data. It is unfair, though commonplace, to blame EDI – a language – for the difficulties in communicating through the supply chain. The sins blamed today on EDI can easily be replicated in XML or any other new e-B2B language that comes along. And software vendors would do well to understand the barriers to e-B2B and at least provide their clients with the ability to easily store and use additional data fields and to audit inbound data based on built-in flexible and intelligent rules. Companies enforcing vendor compliance requirements without offering solutions are simply dictating orders to their vendors, imposing difficulties and excessive costs on both external suppliers and their own internal buyers and compliance (operations and technical) personnel. This is counter-productive to the collaboration the supply chain is supposed to bring about.
Copyright (c) 2003 - Katzscan Inc. |
