So, you just purchased a shiny new ERP, and are looking to roll out EDI. You want to get started right away on your EDI project, right? We should be able to set up data and test all transactions out of the box, right? WRONG!
EDI Project Best Practices
EDI is a customized, systemic process, that much like your data, rolls through the quote to cash cycle in a coordinated sequence. Each EDI document requires data from an upstream process, and you must always complete, and validate, the upstream processes first. A common mistake we see on many EDI projects is an expectation that EDI is plug and play, and that we can implement all documents simultaneously. EDI is not plugged and play, for the same reason that ERP implementations are not plugged and play.
EDI trading partners are notorious for sending through erroneous or uniquely specific data. Our customers all have different shipping and packaging scenarios. Many customers have different expectations on how EDI data is to be handled. The answer to a successful EDI implementation is to work on each document until it is correct, until moving to the next one, and ensure that the ERP system has been configured and validated for packaging and shipping processes before starting to work on outbound transactions. EDI implementations always lag the ERP implementation by some weeks, and always last the duration of the design and validation stage of the implementation project.
Below are some typical EDI transactions, that must be managed, and processed sequentially.
Inbound Purchase Orders (850i), Demand Forecasts (830i), etc.
Many times, Trading Partners will send data that does not have a native home in ERP. Our EDI team must carefully inspect all the inbound PO documents from all your trading partners, and understand each file, which will be unique, whether there is a native home in Epicor, and if not, we create one for it and make it visible in the ERP through customization. This can take time, and for some trading partners, extensive customer part cross references must be built, so that Epicor ERP can understand what it is in fact that this customer is ordering.
Outbound Sales Acknowledgement (855o)
It is common to need to include custom trading partner data in an 855 outbound. Until all of the inbound maps have been translated, and the data housed in Epicor, we can not start testing 855o. This is normally not a difficult transaction, but until we have every inbound document defined and a custom schema in place to accommodate your trading partners, we can not design the outbound format for this document for testing.
Outbound Packing Slip (856o)
Most customers expect us to be able to start this right away. Some customers have even demanded that we start this right away. The trouble is that everyone ships differently, and some people have multiple levels of packaging, at various points in their production process, which change how we build the dataset for the 850o. Another common mistake our customers make is asking for the packing labels before the ASN is designed.
The shipping and packaging process must ALWAYS be designed first, and approved, before we start building 856o data and labels. Typically the label would be the last thing we build, as we process through all the 850i for all trading partners, demonstrate all packaging scenarios for each, and then finally, armed with model data, we can construct the outbound ASN dataset and labels. This is especially important when you have multiple versions of labels for different trading partners, or if you have Master Pallets, Mixed Pallets, etc. All EDI projects I have seen go over budget, or that have been frustrated, have been those where the company insists on having working outbound ASNs before the shipping process is validated.
Outbound Invoices (810)
Typically the easiest of all, but these can not be started until a validated ASN document has been produced. As such, we save these until the end of the project, to ensure all the data necessary on the invoice, whether from custom inbound data from the 850o, or custom packaging data from the 856o, are available. Shipments in the system are required to invoice, so there needs to be a solid, unchanging process to generate multiple shipments for the inbound orders, such that they can be invoiced. This data is typically not available until the last quarter of the implementation.
Listening to your expert EDI implementation consultant, and understanding that EDI will slightly lag the work being done in ERP and that the work will stretch the duration of the project, are key to a successful EDI implementation. Following our process and methodology and will minimize frustrations if expectations were that EDI would be ready on day one, and reduce or eliminate rework for any EDI transactions forced through before the system is validated.
If you are having a difficult implementation and would like to talk to Encompass about how to put things back on track, we would be happy to conduct a mid-ERP implementation review. If you are about to start an EDI implementation, understanding the above before starting, and ensuring that the project manager and steering committee understand the timeline, will be critical to meeting expectations, and ultimately having a successful, error-free cutover.
About Encompass Solutions
Encompass Solutions is a business and software consulting firm that specializes in ERP systems, EDI, and Managed Services support for Manufacturers. Serving small and medium-sized businesses since 2001, Encompass modernizes operations and automates processes for hundreds of customers across the globe. Whether undertaking full-scale implementation, integration, or renovation of existing systems, Encompass provides a specialized approach to every client’s needs. By identifying customer requirements and addressing them with the right solutions, we ensure our clients are equipped to match the pace of the Industry.
