EDI Integration in simple terms is the ability to take EDI (Electronic Data Interchange) data from any source system, validate, translate, and then map that data into another application. Data that gets mapped into an application is contextual, meaningful and is often converted into a format that the target application would be able to understand and interpret.
Some of the common examples in EDI integration are
- Integrating EDI 850 Purchase Orders with an Order Management system.
- Integrating EDI 834 Benefit Enrollment plans with an Insurance carrier’s Policy management system.
- Integrating EDI 204 Motor Carrier Shipment information with Shipping and billing systems.
- Integrating EDI 820 Payment Orders with an ERP’s Account Receivables.
- Integrating EDI 856 ASN with SAP (mapping it to IDoc DELVRY03 or DESADV)
- Integrating EDI 837 Claims with an Insurance carrier’s Underwriting and Claim Management system.
- Integrating EDI 810 Invoices with Quickbooks.
- Integrating EDI messages with Cloud applications such as NetSuite, Shopify, Intacct, Freshbooks, Bigcommerce, Salesforce etc.
Why is EDI Integration needed?
EDI integration is needed to automate business processes. Application landscape in any organization consists of disparate systems that store specific business data related to a given business process. For example, Order to Cash process would consist of multiple entities such as an eCommerce portal or a trading partner that would send the order to a back-end ERP system which would execute that order and send an invoice to the customer. As part of this process, the order is received as an EDI 850 and mapped into the ERP system. EDI is not an end in itself but a means to provide meaningful and timely data to applications that can take business decisions.
In some cases, the EDI data would require review and approval by a business user before it gets routed to target applications. Human interaction in the form of assigning workflow tasks or alerts for end-users to view and make decisions is important for achieving business success and especially in cases where data is incomplete or erroneous. Integrating EDI with workflow engines is another important example of why EDI integration is needed in automating business processes.
How to achieve EDI Integration?
EDI Integration is an important undertaking that requires an implementation framework which takes into account your company’s resources and skill-sets, application landscape and an acceptance to the fact that your business exists in a rapidly changing environment. Having the right skill set to understand EDI, having the right software to translate and integrate EDI with other applications and having the ability to make adjustments quickly to your solutions as your business environment changes are keys to a successful implementation of EDI strategy.
First, let’s talk about the team and the skill-sets needed for implementing EDI solutions. Key here is the organizational team needed that can plan, design and implement the solution. Based on my experience the key players in the team are:
- EDI specialist – provides full EDI knowledge in terms of data fields/loops and documents mapping rules.
- Project Coordinator/Manager – puts timelines around the overall project with tasks and deliverables.
- Business Users – provides visibility on which EDI integrations are crucial for their business success.
- Solution Architect – comes up with enterprise architecture for integrating EDI messages.
- Development team – implements the EDI solutions.
Project Coordinator has an important role in terms of communicating the goals to the rest of the organization. Defining clear goals and providing visibility to the executive team on the importance of EDI integration is one of the key tasks of the Project Coordinator.
EDI specialist have the role of sharing knowledge with the rest of the team on how to interpret EDI messages from trading partners, deriving meaningful information from the EDI messages and how the data can be mapped to the target systems. They help in documenting the mapping rules, documenting business specific validations on what data is required and how to handle errors.
Solution Architect’s job is to avoid coming up with one-off’s and point-to-point designs and instead provide a common framework that is adopted throughout the enterprise. Important part of this role is to design a common framework that incorporates handling of all EDI messages, a common framework for using or reusing mappings, a common framework for handling errors, a common framework for making changes and promoting those changes into production. Enterprise framework that is based on meta-driven, SOA architecture would allow for quick adjustments to the solution as your business need changes and is best suited to scale as your trading partners or data volume grow over time. If we use the ESB approach then we need to make sure we have the ability to map EDI to cloud applications through REST/JSON framework and be able to create an abstract layer of mapping and validation rules that can be used both on on-premise legacy systems and cloud applications.
Let’s talk about the role of the business user. We have seen that ignoring business users in implementing any EDI strategy is not a good idea. IT off-course can come up with their own unique design of handling EDI messages but not having the buy-in from the business users would prove disastrous in the end. Business users are the first responders to any change in the business environment, they are the ones who onboard new clients, they understand the speed of responding to their customer needs. An EDI solution that is slow to respond, moves at a glacial speed in adjusting to changing business environment is at the end of the day a failure and should be declared as such. Business users would need access to EDI logs and reports. They would track inbound or outbound EDI messages and drill-down into the transactions and be able to report out of that information. Having a rich reporting interface connected to your EDI solutions is necessary to allow end-users perform their business activities with their trading partners.
I have written more about some of the common questions that need to be asked when designing your EDI solutions.
I can summarize some of the key solution design questions here:
- 1.How are your trading partners managed
- 2.How is EDI data delivered and what if the delivery method changes?
- 3.How are all the EDI mappings managed And what happens if you don’t standardize on your EDI maps?
- 4.How do we handle errors and what happens if we don’t follow a standard way of handling those errors?
- 5.What if the EDI vendor you have chosen to implement your solution generates proprietary code and is not flexible enough to make constant adjustments as your business needs change over time?
Now let’s talk about choosing the right software to implement the EDI integrations. Companies thinking of purchasing an EDI solution should go through a proper due diligence in evaluating an EDI vendor. I have come up with some of the key questions that must be answered and have listed them here:
How quickly can your team learn to use this product?
As a growing company you would need your team to access and use the EDI solution quickly without having to go through an extensive training session with your software vendor. Ease of use is important when you want your business users to onboard new trading partners and don’t have the patience to wait for the slow-moving IT to respond to those needs. Product should be browser based so that it provides easy access to the application and it should have an intuitive navigation and configuration interface that allows any user to start using the solution quickly.
What is the process for adding a new Trading Partner?
This is one of the most important factors in judging how the EDI solution offered by a vendor is going to handle the on-boarding of new partners into your B2b network. As part of this function one has to also understand how your trading partners would send or receive EDI files, the SLAs around missing transactions and the notification process in case of errors.
What is the process of making a map change such as creating a new map, editing an existing map or migrating a map to another version (example: 5010 to 6020)?
I have seen that companies that purchase an EDI solution often ignore the long-term cost of having onsite consultants involved in implementing EDI maps and quite often they are the only ones in your company who understand how to use that product. Mapping shouldn’t require programmers; it should be doable by your business team with their existing skill-sets.
Does it have the flexibility to handle integrations beyond EDI?
Some of the key points to look into are:
- Companies nowadays connect not only using EDI but also with APIs, XML, Web Services, Cloud apps etc. and you want the EDI integration solution to support these features.
- Most real-life, mission-critical situations require complex features such as error handling, human workflow to make decisions etc.
- Handle both file-based batch mode type of integrations but also real-time REST/JSON transactional integrations in same product.
- What are the report generation and management capabilities around creating adhoc reports and dashboards and how are they managed?
For example, your team would need an ability to track the number of EDI transactions sent by a particular trading partner, or would want to know the total amount of Claims sent by a healthcare provider. Having an ability to let your team be able to create these reports and have an ability to manage them is critical for a long-term successful relationship with your business partners.
There are additional factors involved that shouldn’t be overlooked such as making sure that the solution architecture supports high-availability and disaster recovery. It should also support various data formats such as flat files and connections to cloud-based SaaS applications and on-premise databases.
5 important factors that enable successful EDI implementation
Now let’s talk about the important factors needed to implement EDI successfully in your company. In the above sections I have discussed the resources and the right EDI translator needed for implementing EDI, but having all the resources along with a process of how to go about implementing the solution is also important. So let’s list what those steps are here.
1. Functional Requirements and project scoping
Analyze what your EDI requirements are and how they would change in the future. Understand what type of data is required by the target applications. Document the types of EDI messages and acknowledgments that would be sent to the trading partners. What are your ISA envelops for outbound, what happens if you get duplicate transaction control numbers in EDI files, what type of mappings are needed to translate the EDI into other data formats. Have a good understanding of what is required, what is optional and how are validations going to support custom EDI messages from your trading partners. Items such as data volume, the type of protocols used in transmitting EDI messages; the amount of customizations needed in mappings; network access, security and data encryption; all of these items should be discussed as you dig deeper into the requirements. These are just few of the thought starters as your team starts to analyze the requirements and documents them.
2. Organizational structure of the project team
Come up with a unified team that would be leading the EDI implementation. Team can consist of an EDI specialist, Project Manager, Solution Architect and developers. You would also need access to the business users to get their input on a solution design that your team comes up with. Team with right reporting and communication channels would be able to share progress and problems quickly and keep everyone in the same page when it comes to project status and next steps or requesting for additional budget.
3. Project plan with timelines and specific deliverables
Key to project success is when it is delivered on time and on budget. In order to consider what those timelines should be as part of your project plan, completed technical and functional requirements are needed.
4. Enterprise solution design
As discussed earlier, a solution that provides a standard framework for addressing all your EDI needs is important.
5. Promoting changes to production
A meta-driven approach in implementing EDI solution would help in quickly making adjustments to the solution as your business requirements change. A custom-coded solution would not give the flexibility needed to make modifications to the EDI solution and would require lengthy test and promotion cycle.