Electronic Data Interchange (EDI) - what my job entails.
I sometimes write about what I'm doing outside of work and never really talk about what I do as my day job. I'm responsible for the Electronic Data Interchange (EDI) systems at the company that I work for, across EMEA and APAC regions. I've been in the EDI world for about 20+ years now, and I usually have a blast in what I get up to on a daily basis.
Even though EDI has been around for checks notes 40 years or something, it's still relatively unheard of - even amongst the tech community. It's drowned out by the shouting of all the new tech like Containers, Microservices, AI LLMs, and everything else. EDI is generally there, quietly working away in the background.
If you're unsure what EDI is, then it's quite simple. Companies like Amazon don't order TVs from, say, Sony via phone, fax, or email. You might think, "Ha! I bet they use XML to place their orders." Nope, they generally - and get this - they generally prefer to use EDI to do it. EDI is a series of structured business documents. Typically, companies use EDI Orders, Order Responses, Shipping Notifications, and Invoices. There's a whole bunch of other EDI messages covering Port Authorities, Shipping, Transportation, Warehouse, Medical, Banking, and Insurance related messages, and then there's still a whole bunch more.
Both suppliers and sellers prefer EDI because it is governed by a set of internationally defined standards. Those standards are different depending upon where they're implemented. So in EMEA, they're governed by the United Nations (yes, really); in the US, they're governed by the American National Standards Institute (ANSI). These are big names, and they are responsible for coming up with new message types, and they review/revise the standards over time. The UN publishes 2 new updates a year; the version is usually denoted by the year and then either A or B, such as D96A or D98B. So let me spell this out to you, if you've not already twigged: EDI messages are structured so that if you implement, say, EDI Orders D96A with one customer, then you're already 90% of the way there with implementing it with the next customer. Because the messages are governed and maintained by respected organizations, even Amazon conforms. I'll let that sink in with you for a minute.
The same concepts apply to Order Acknowledgements, Shipping Notifications, and Invoices. All the standards are published and free for any organization to use. There's really no charge at all. You can find the latest UN EDIFACT standards here: https://service.unece.org/trade/untdid/d24a/trmd/trmdi1.htm
Now, I know that that's the latest version, but don't fret - you don't need to keep updating your EDI system every 6 months to keep up with the latest version. I'll let you into a secret - just about everyone (in UK/EMEA) uses EDIFACT D96A for just about everything - Orders, Order Responses, and the rest of the messages. Occasionally, you might stumble across a D98A or a D98B, but really they're pretty rare.
So now the next concept is that EDI links organizations together. They could link, say, a wholesaler to a customer, or to a supplier, or to a 3PL, or preferably all 3! This is where the job gets interesting. In my experience, EDI people fall into one of two camps. Camp 1: they see EDI as a technology that needs to be supported, or as an IT system that simply implements EDI with other companies. In my opinion, that's a very narrow technology-focussed view. Camp 2: These people - and I count myself amongst this group - see EDI as a way to bring about business change. This to me is where the fun is.
I work quite closely with Sales Teams, Customer On-boarding Teams, Customer Services Teams, Warehouse Teams, and also various Finance teams. In short, I work across pretty much every department in our organization. Sometimes, I interact with a team because I need to know what the business priorities are, or because sometimes invoices are not sent, and I need to ensure that they are. My EDI role is about 20% technical and 80% business focused. I need to learn and talk the same language as the different teams, and to explain technical 'stuff' to them in non-technical ways.
I also get to work with customers, 3PLs, various IT suppliers including their support teams. I also have to manage EDI Suppliers, and their relationships with us, ensuring that they fulfil their contractual obligations.
I also work a lot with my IT colleagues. The EDI data has to go somewhere, right? This is usually into an ERP system, and in the past I've worked with SAP R/3, Microsoft NAV, and now D365 in my current role. I have to be able to understand how I can integrate my EDI data into these systems, which is usually through XML in the case of D365. The EDI Suppliers usually have an set of XML Schemas that they use to extract/import the data into the backend D365 system, that we simply bolt onto.
There's no such thing as a typical week for me. The last couple of weeks then I've been doing the following:
- Writing a technical design specification for an EDI data archive with a web front-end for different internal teams to access historical data.
- Updating customer facing documentation relating to new processes that we're implementing in D365. To help them navigate the new changes.
- Meetings with our EU 3PL to resolve technical issues relating to message delivery.
- Meeting the warehouse manager to discuss new opportunities for EDI within the company.
- Trying to get UAT testing sign-off, for some D365 system changes from different internal business units.
- Liasing with MS support to resolve technical bugs on their D365 inbound Shipment XML schema, and get an overview of preferred/best practise interfaces for our new 3PL integration.
- Supporting an internal Sales Team with an EU customer that is rejecting some shipping notifications.
- Helping Credit Management resolve invoice queries for a particular customer.
- Meeting with external EDI team, to get help and resolve point 8 above. Creating test orders for them, so we can generate test invoices for certain customers.
- Meeting external EDI Account management team to get some customer stats.
- Liasing with my US counterpart to keep him informed of what we're doing in EMEA.
- Prepping for the onboarding of new APAC customers, with the customer on-boarding team.
- The usual IT team, and meeting with IT managers for the usual advice, support, and guidance.
So that's my day job! I enjoy the large scope that I'm afforded by my role; working with the different business teams and trying to understand their wants and needs and to translate that into business-focussed technical solutions, is what makes me happy.