Let’s see…. Why would you be doing such a project? Well, you may be:

• New to EDI, and your existing company back-end system is an ERP.
• In the process of changing translators.
• Experienced with EDI, but your company is replacing their legacy back-end system with an ERP.
• A startup, buying new systems to run a new business or division.

There may be other reasons, but off the top of my head I would think these are the most common. We had extensive experience in the last two categories, and it’s interesting to look in the rear-view mirror after the fact and recognize how much work we did and how much we learned.

Our startup took place several years ago and involved a new division for our company. The division didn’t survive, but the people, processes, and learnings made it through intact. Later, our legacy system replacement, known internally as ASAP, was one of the largest SAP implementation projects undertaken worldwide and was almost certainly one of the seminal events in our 80+ year company history. Although they occurred a few years apart, we were able to leverage what my team learned in the divisional startup when we participated in the ASAP project.

Since there’s a wide variation in how different companies approach projects of this nature, rather than getting into any sort of detail I thought I’d try to communicate some of our high level learnings from our ASAP project, moving from the strategic to the more detailed. Here they are:

• Business side sponsorship/alignment. This is an absolute necessity, whether you’re part of a larger ERP project or doing a translator change with limited direct impact on the organization. The business needs to be aligned so that resources, funding, and other support needs are addressed. Our company identified the ASAP project as the top, over-riding priority for the entire organization, which cleared the way for the proper level of commitment company-wide.
• Utilize experienced help. For ASAP, the company opted to partner with an international consulting firm that had a ton of experience with ERP implementations for firms similar to ours. Although this was an expensive decision, it provided us with methodologies to short-cycle the process. As someone who wasn’t strategic but functioned as a team lead for our part of the ‘technical thread’ of the project, the benefit I realized was from the structure and approach our partner inculcated in us that accelerated our work processes. My counterpart on the consulting team, quite technical and experienced in working with teams like ours, helped us streamline our work and also acted as an intermediary with other teams and upper level project management on our behalf.
• Interface adapters.  Many companies that sell enterprise level messaging and translation systems (ie. Sterling Integrator, Seeburger) have developed ‘adapters’ to facilitate integration with ERP systems. Whether you should buy, use, and pay to maintain these adapters is something you really need to investigate. In some cases, adapters may be too costly to obtain limited functionality, but in other situations you may not have the time or the expertise to create what you need on your own. Our experience with adapters is that they are nowhere near as ‘plug & play’ as the marketing literature touts, to no one’s surprise.
• Communicate with partners. Although a key goal for us was to make changes transparent to our partners, for some there were minor changes we needed to make sure they understood. Additionally, even for the partners that should not have noticed any changes, we still wanted to ensure they knew that we were undergoing significant system changes and we needed their support.
• External partner testing. A key for partners with new interfaces to our system (not new to the company, just new to our team) was to establish and execute test processes. During both our divisional startup and our ASAP project, we took responsibility for a significant number of new processes that had previously been handled by other teams within the company, and it was crucial to us to ensure continuity for those partners.
• Internal testing. EDI is, by its nature, a part of a longer string of processes. As such, it was extremely important for us to test our development in conjunction with that of the process teams both upstream and downstream from us. In most cases, our unit testing looked great, but the real ‘proof in the pudding’ was when it was tested as a string with the adjacent processes.
• Recognize dependencies. Again, EDI has a unique role in any ERP project in that there’s no real development generated on its own. All changes are results of upstream and/or downstream development activity. Our experience was that, at times, other development teams would feel their testing was complete before the resulting development work we needed to do was fully tested. The only recommendation I can make is to be in constant communication with your peer teams, or to have a project management process established that vets project and test plans across all teams. We were fortunate to have not only good project planning in place, but also processes established with the help of our integration consulting partners that effectively ameliorated this issue.
• Define ERP and EDI development roles. This may have been specific to our situation, but I think it probably wasn’t. One variation we’ve noticed is that in some shops, EDI work is an extension of ERP development, so that the people who developed IDOC extensions and did interface work also made changes on the EDI side. We had a relatively strict line drawn between EDI and other B2B development and SAP. We worked in the Gentran environment, and the SAP teams supported everything on their end, including IDOCs, schedules, and interfaces. It worked well for us in that it allowed each team to focus more specifically on certain pieces of development. On the other hand, dependencies were really important to discover and communicate around. Any change to an IDOC made by one of the SAP  development teams had to be evaluated by us to determine if any inbound or outbound EDI or XML maps needed to be updated.
• Do some blue-sky thinking. Although most ERP-related projects have specific defined deliverables, you may have an opportunity to propose changes or new functionality you can support that would make sense to develop in the context of the project. In our case, we had one relatively large gap in our transaction offering to customers that would have been fairly straightforward to address during our ASAP project. The work and benefit were evaluated and it was accepted and placed in the development queue. As with all projects, development work is constantly evaluated with respect to resources and timelines, and it was taken out of scope near the end of the development stage. Although it didn’t go in, that was a good example of something we were able to recognize and get escalatd.
• Minimize impact to your customers. Anyone who has made changes that resulted in map modifications for partners, involving all the communication, back and forth testing, and so forth between parties, knows you want to avoid it at all costs, especially with your paying customers. Our goal on the customer side was to make all changes totally transparent to them, so that their inbound orders and payments, outbound invoices and PO Acks., and all other documents would look the same to them even though our mapping would change.  Although a lot of character comparison testing of huge streams of data was required, this effort paid off very well and, although we communicated what was going on with our project to them, it was a non-issue and no changes on their end were required.
• Map change options.  As with most everything we processed, there were multiple ways of doing the same thing. In our ASAP project, one choice we had to make was in how to move data between inbound sales orders and SAP. Prior to the project, we fed an interface program with positional data, so every map we used (I think over 500 at the time) created application data in the same format. Our choice was to go in and change every map to meet the XML based SAP interface, or to create a secondary map that would take the output of all the individual positional files and translate them into the SAP format. In order to meet the timeline, we opted to use the secondary map, going back in later after the project was implemented to make any individual map changes we felt we needed.

Although our ASAP project required the investment of two years of time by a significant part of our company, it was widely recognized as a huge success. For us, it made our interfaces more consistent, provided us with a greater level of transparency into SAP processing (and the SAP team with better visibility into our work), and increased our responsibilities in the organization for supporting additional activities. We’ve had other projects since that have been managed using the blueprint established by the ASAP project, and it has withstood the test of time. I wouldn’t call ASAP fun, but it was a once-in-a-career learning experience in which I was happy to participate.