- Get your internal business units and IT department to understand and define the data they need from the trading partner. If you use SAP, what IDoc can be used and does it need to be customized?
- Find the appropriate EDI standard and transaction set for this purpose (Not always as easy as it sounds). Where do you start? Someone needs an education and mentoring through this process.
- Customize the transaction set to match your requirements (this means buy the EDI Standards Guides and a specification editor), read it, understand it, customize it and publish your EDI specifications in the form of a EDI Guideline. Send this to your trading partner. The trading partner will often ask you to review their existing EDI Guidelines to see if it is already acceptable (more time investment…)
- Get all the contact names from your trading partner that will be involved in the EDI implementation process. Often this list will include: Database Administrators, Project managers, IT security experts, EDI specialists, Systems Analysts, Business Analysts, EDI Managers, etc. Here is one problem, many of these folks report to different managers in different departments with different priorities. Someone needs to talk with all of these managers, get permission to use their people and get them on your schedule. This is not easy.
- You need some kind of database application or CRM to keep track of all these contacts names, titles, roles, phone numbers and email addresses. You need to know which of these contacts needs to approve the various parts of the implementation process. You need a complete Project Plan.
- If there are large numbers of trading partners, their implementations need to be prioritized. The business unit should do this. Get this task on their schedules.
- Once you have an internal list that is prioritized, you must get the implementation process on the calendars of your trading partners. They most often have different projects and priorities than you. Align your schedules.
- Your EDI partner needs to agree to do business with you via an electronic data interchange. This most often requires a signature on a legal document called a Trading Partner Agreement. This requires getting the trading partner reviewed by all legal departments.
- Once the trading partner agreement makes it through the legal departments and has been signed each partner must configure their own EDI translators to enable the data exchange. This configuration task is hard on the eyes and is boring. A person must read the EDI guideline line-by-line and systematically configure the EDI translator to match the specification. This is hard on the eyes and very boring. It is hard to get the best and brightest in your IT department to enjoy this task and get motivated at the thought of supporting this for the next 20 years.
- Once both parties have configured their EDI translators they need to be tested. How does one test this system? This again, is a painful process. Somehow test data, that matches the requirements of your EDI specification, must be generated. When you ask for volunteers – no one raises their hand for this process.
- Testing, testing and re-testing. You can’t afford to have high volume and valuable business information screwed up in the EDI system. Make sure your test data is good. Oh by the way – which party should make the test data. No one wants this job and everyone hopes the other trading partner will create it.
- Testing the EDI data is just one part of the test. The EDI data needs to be integrated into your ERP system. Who develops and tests that part? Which manager needs to give up resources to work on this?
- Oh no! The security guy and the DBA says they won’t allow direct integration with their database. OK, someone needs to develop an API layer. Who do I need to ask about this? What developers do I need? Who will give up their resources when they are already behind schedule on other mission critical IT projects?
- Everything works now…except my trading partner needs to wait for IT development resources to integrate their side of the EDI process. This will delay the project for 5 weeks.
- It would all be manageable with one trading partner, painful but manageable. The problem is the business wants me to implement 486 suppliers and customers. They want them all on B2B/EDI NOW!!!!!
- Should I just request more IT resources – the problem is the business has been cutting costs by outsourcing IT, they are not interested in adding more headcount. OK, can some of this work be contracted to a managed service provider for EDI/B2B?
Today, up to 70% of a mature EDI department’s time is dedicated to simply maintaining existing B2B connections, rather than expanding the business network and adding value and efficiencies. How can you expand, take on new on-boarding projects, and maintain your existing EDI connections all at the same time? It isn’t easy.
Today there are different options available to EDI deparments. They can outsource the maintenance and operations of their EDI so they can focus on adding more trading partners to their business network, or they can choose to outsource new implementation projects. There are managed services providers that work closely with SAP and provide these services now days. This is a relatively new development.
When electricity first came to the manufacturing industry companies purchased and maintained their own expensive electrical power plants on premise. This made sense only until the power grid was available as a service on the street in front of their building. Economies of scale were then available and the grid meant many companies could share in the development and maintenance of the system (See the very interesting book, The Big Switch). We have reached a point where companies can now subscribe to EDI/B2B business networks as a monthly service as well.