EDI mapping is a very simple concept. The objective is to connect two companies to automate supply chain communication. If you’re sending EDI transactions, you need to map data from your system of record to an EDI file. If you’re receiving EDI transactions, you need to map data from the EDI file to your system of record.
The complexities lie in the fact that every company has a different system. Even if you’re running the same ERP as your trading partner, it’s guaranteed that the systems have custom requirements.
Mapping exercises require both functional and technical expertise. Within an organization this is typically two different people.
From a functional standpoint, you have to understand what the data is and how it will be used by the systems. You then have to provide a mapping structure that a technical person will use to build the actual integration.
This part of the process usually happens in a spreadsheet. It’s a bunch of “Field A in the source relates to Field C in the target,” along with descriptions of the data and enumerated values. It’s not very exciting, but it’s essential to an accurate EDI integration.
From a technical standpoint, a member of the IT team will take the functional mapping document and write code that turns it into software. However, the person who writes the functional requirements is rarely the same person who does the technical work so there is a risk that in communicating the requirements for a piece of code, something may get miscommunicated, lost in translation, or left out entirely.
Unless the communication between the functional mapper and technical person is precise and collaborative, the functional mapper won’t know how to express requirements in a way that leads to the most efficient, bug-free code. And when the technical person tests the integration and realizes something is broken, they won’t necessarily know how to fix it in a way that reflects how business users will actually be using the data.
In an ideal situation, your functional and technical people communicate and work collaboratively to solve these problems. Each communication — and each iteration of code — can take time and cause delays in getting your integration up and running, and each delay in going live with your trading partner will cost you revenue.
One approach to streamlining the mapping process and improving the communication of turning function into code would be to invest in training. You could teach your functional people how programming languages work so that they would have enough background to provide your technical team with specific instructions. You could also train your technical people in business workflows so that they could start writing code that reflects the actual flow of information between trading partners. This approach requires an investment in both time and resources.
There is another, better approach. Tap into a cloud EDI solution that makes EDI mapping a one-person job for your company. This approach requires less of your time and resources.
With Orderful EDI, you can take advantage of pre-built integration relationships to hundreds of trading partners. In other words, the technical part of the job is already done. Your functional person logs onto our platform, builds rules for each integration by pointing and clicking, and then validates the integration against the trading partner’s requirements.
And if the integration didn’t work? Your functional person gets real-time feedback and can fix the problem with more pointing and clicking. No phone calls. No miscommunications. No delays.
Your EDI mapping should be this simple of a process. Talk to an expert. about how a cloud EDI platform can actually make it easy.< Back to EDI Blog
© Orderful 2019.