Getting an EDI integration project up and running is not easy. If you’re looking to be successful, there are certain questions you need to ask project stakeholders before you begin. It would be a huge display of idiocy not to ask them.
I know, because I’ve forgotten to ask these questions before. Don’t be dumb like me. Here are the 5 questions you must ask so that your solution architects can supercharge their EDI integration strategy using a reimagined solution that doesn’t turn into an IT project from hell.
Say you’re onboarding a new trading partner into your B2B Trading Partner Management solution, and you assume that the trading partner will send EDI messages with the specific standard, version 4010. Based on this assumption, the processing of the EDI messages, validation and mapping of the EDI data into target systems, and the sending of acknowledgments and notification of errors is all based on version 4010.
A few months go by and the trading partner suddenly changes its EDI file to a new standard, 5010. Now, your developers have to go through the process of recreating maps to deploy the updated content and validation rules into production. If your business rules are too specific to version 4010, then a complete review and migration of the mapping rules must be implemented, costing time and money.
Related White Paper: I Just Bought EDI Software, Why Am I Still Up A Creek?
Solution architects need to establish a plan to handle scenarios outside of their control. There are things we can examine - like templates, workflows, and communications — to prepare for these contingencies.
One question I always ask myself is, “How are these maps organized and managed when we deal with hundreds of trading partners?” Companies should rely more on standardized mapping templates for different message types rather than individual maps for each trading partner. The reason we have individual maps is because some trading partners have custom fields, segments or rules.
Individual mapping eliminates a company’s ability to scale. It’s no longer realistic to have individual maps for hundreds to thousands of trading partners. In addition, the amount of upkeep needed for these connections is just about insurmountable. Businesses should look to standardize their processes as much as possible.
Some trading partners still choose to send their EDI files through Managed File Transfer (MFT), requiring both parties to have a similar configuration. However, there could be cases where using a MFT product is no longer cost-effective for one of the trading partners. They may opt for a secure web service API to send or receive EDI messages.
Therefore, you should provide a variety of protocols on how to send or receive EDI messages. One option is secure cloud-based file sharing applications, which are becoming popular in exchanging files. Lastly, your EDI solution should be able to publish a web service as REST API. This helps meet the demands of trading partners who are moving away from MFT models.
Having an accurate list of error codes and descriptions is helpful for end-users to make corrections to data because it may not always be available. Be sure there are functions in place to automatically route data correction tasks to the right individuals, as this helps improve data quality and accuracy.
You should also have a list of rules that define what EDI errors mean to your company. Custom errors are fine if you are dealing with one or two trading partners, but as your network grows it’s important to standardize all business rules validations. Having a rules engine helps provide full operational details on how to handle the processing of EDI messages. Your team can add more rules or remove older ones; these rules can have an expiry date so they are not applied after a set time.
Because EDI validation is a vague term, most trading partners might not send you fully compliant files. It’s important to note a file may be incomplete but not invalid. Applying full semantics or compliance rules on these files might not be a good idea, since you end up rejecting all of the files. You have to judge based on the totality of errors and whether these files are valid.
A packaged solution will do the trick for a little while, but won’t cut it in the long run. Since mapping and configurations are all coded in proprietary code, it may aggravate an already difficult situation. It’s impossible to migrate maps to another tool since the code is exclusive, and you need well-versed engineers to manage this.
Instead opt for a flexible SOA based framework to implement EDI solutions. If the platform generates code in standards like XML, then it is easy to maintain.
Knowing what to ask before implementing an EDI integration solution can play a crucial role in whether you succeed or fail. As I have experienced, many scenarios are out of your control, but if you are prepared, you can set realistic expectations and tackle each situation accordingly.