This blog post is the fourth part of a series highlighting the best practices for EDI-as-a-Service in planning and evaluation.
As you go about the implementation of an EDI-as-a-Service solution, knowing partner setups and determining an internal contact with your provider at the start of the implementation can save you a lot of time effort and frustration in the long-run.
Understanding partner setups, changes and how long they take
When onboarding new partners and implementing new transactions, a common complaint is that the process takes too long. Sometimes changes that should take minutes, take days or weeks. How can the expectation be set that a change sometimes isn’t instantaneous, but may take longer? Continue reading
The benefits of automating the exchange of business transaction documents between B2B trading partners (customers, suppliers, and service providers), including time and clerical cost savings, as well as increased accuracy, are well known. This automation is typically accomplished utilizing some type of standardized data formatting, such as traditional EDI or, in some cases, industry specific XML documents. Initial implementations frequently involve trading partners with high transaction volumes, and/or those of significant strategic importance.
The next stage of partner integration involves implementing those trading partners with lower transaction volumes, but who also have the capability to exchange transaction data utilizing standardized data formatting. After this, automating transactions with your remaining trading partners involves a greater challenge, since they are frequently smaller businesses who cannot justify the required investment in softwareand/or do not have the level of IT sophistication required to implement and integrate B2B data exchange with their internal applications.
There are a number of alternatives which a larger organization can utilize with their smaller and less IT capable trading partners that will provide many of the benefits of automated B2B transactions to both parties. These include:
- Implementing web-based software that trading partners can use to send or receive transactions. For example, this software could present purchase orders to a small vendor from the same system used to send orders to EDI capable vendors. The small vendor would log into the website to receive the orders, which could be printed or downloaded in a spreadsheet. When the order is ready to be shipped, the small vendor could log back into the website and add the shipping and billing information to the original order. The larger organization would receive all the benefits of automated transactions, and the small vendor would also receive the same benefits except for the clerical cost savings.
- The same scenario described above could be providedas a service by an EDI VAN (traditional EDI VANs are now considered ‘in the cloud’), or some other third party service provider.
- Documents could be exchanged as spreadsheets attached to emails sent between trading partners. There is B2B integration software available that can create and process spreadsheet data in addition to standardized data exchange formats.
- Software (both on-premise and available as a service) is available that can reformat data in standardized data exchange formats to an easily readable document and fax it to a smaller vendor. Some systems also have the capability of receiving faxed documents and transforming the information into standardized formats, although the accuracy achieved with this method is not always acceptable.
With the technology available today, automating the integration of business documents with small B2B partners is practical and affordable.
You’ve probably heard some version of the “golden rule” of business (not the one we grew up with) – “S/he who owns the gold makes the rules.” In the world of business-to-business (B2B) integration, it’s easy to see the golden rule at work. In general, it’s the payer – the customer in a B2B relationship – that sets the rules for partner interactions, including implementation details like document types, versions, and syntaxes, document size and content constraints, communication and security protocols, and quality of service requirements.
The term “channel master” has long been used to describe the role of a dominant company in a value chain, exemplified by mega-retailers like Wal-Mart, Target, or Sears. Companies that supply products and services to such channel masters understand that compliance with their integration requirements is a price of doing business. Continue reading
Traditional EDI integration, in its’ simplest form, involves an exchange of core business transactions between two trading partner entities. The Shipping Notice or “ASN” (the “A” being for “Advanced”, although that’s not always the case) is a type of electronic document that is sent (for example) from a supplier (manufacturer) to a buyer, and precedes the shipment (and arrival) of products at the buyer’s location. The products on the shipment would represent one or more purchase orders made by the buyer of the supplier, often combined into a single shipment. The ASN notifies the buyer of the contents of the shipment; the buyer reconciles the received products against original purchase orders by using the ASN. Primary advantages include the improvement of the ordering cycle and improved efficiencies in managing stock.
The Electronic Data Interchange (EDI) X12 document associated with the ASN is the 856. This transaction is structured using Hierarchical Levels (HL) where each level represents shipping and packaging levels. For example, a shipment might consist of one or more orders; each order might have one or more cartons; each carton might have one or more items; and so on. The ASN will detail contents of a shipment goods and contains information specific to the order, product descriptions and attributes, physical characteristics, type of packaging, markings, carrier information, configuration of goods within the equipment, and/or many other specifics to the shipment and representing purchase orders.
This information is generally sent electronically at (or about) the time the physical shipment departs, as it must arrive prior to the actual shipment. This makes it possible for the trading partner to review all ASN data before the physical shipment actually arrives, allowing them to schedule the receipt at the distribution center and identify any possible shortages from the shipment. Technology also exists making it possible to scan the incoming shipments, which would then update inventory and reconcile the purchase order(s) saving manual time and effort, and ultimately saving money. Automation and integration of these various processes provides advantages with business logistics. As one might expect, for all of this to function as intended the ASN must contain accurate data. Just as accurate data and synchronized ASN processes will provide efficiencies in the movement of products, inaccurate data and/or untimely processes can result in lost revenue and potential customers.
While the ASN is not a mandatory transaction for trading partners, it can be a very useful tool in shipping and receiving systems. If implemented properly and completely, it can reduce supply chain and administrative costs by utilizing automated integration to all systems within an organization.
After having supported many customers for the past several years, I look back at some of the more critical issues and quickly recognize that most of these could have been resolved (or certainly avoided downtime) had the customer employed reasonable and simple testing.
The one recurring theme is the amount of implementation work that is performed without equal efforts applied to testing that work. One would expect that any configuration with impact on company reputation and revenue would be tested to its’ fullest potential before it is ever promoted to a production status. Schedules and deadlines do not always allow for intense sessions of testing and debugging, however, there are many important yet unrecognized advantages to the testing process. Continue reading