Charting Your EDI Modernization Strategy
Please note: This post originally appeared on Extol.com (EXTOL has been acquired by Cleo).
EDI today is very different from what it was 10 or 15 years ago, when many companies made their last EDI technology investments. Today’s businesses face a broader range of EDI requirements, including the ability to support proprietary document interchanges, near real-time transaction response, and web services.
When we talk with prospective customers about how they cope with new EDI integration requirements, the answers boil down to these five approaches:
- Do nothing, and deal with the consequences. When the consequences of inaction are minor, like having to manually process a few transactions per day, doing nothing can make sense, especially in small businesses. But over time, the overhead, latency, and higher error rates inherent in manual processing can inflict real business harm. The impacts of high processing costs, chargebacks, process bottlenecks, key-person dependencies, supplier scorecard demerits, lost business opportunities, and other consequences of manual processing can add up, over time.
- Write code to address gaps in primary EDI software or services. The broad availability and affordability of point tools (see next point) has made coding a less common remedy for missing EDI capabilities than it used to be. But a combination of IT department pride and diverse open source assets have kept this option alive, particularly in larger companies. There are circumstances in which coding can be a valid choice: when the cost of implementation is predictable and low, the number of coded exceptions is small, and the rate of change in requirements is low. But as more exceptions and changes surface, this approach becomes too costly for most businesses to sustain.
- Acquire point tools to address gaps in primary EDI software or services. This option, like the previous one, is a hybrid approach. In this case, gaps in the capabilities of the primary EDI integration solution are addressed by acquiring complementary point tools, like process automation tools, web services toolkits, data transformation tools, and spreadsheet integrators. Again, when the exceptions are few and contained, this approach can make sense. But when requirements span tool boundaries – like invoking a web service as part of validating an EDI document – or the number of exceptions rises, the costs of acquiring, training, integrating, and maintaining multiple tool technologies can mount quickly.
- Engage a third-party service to replace or augment your existing EDI solution. The main advantage of third-party service solutions is that they reduce dependencies on internal IT staff skills and availability, and can sometimes produce results faster, by eliminating learning curves. But third-party services can be slow to respond to needed changes, may cost more over time than internal solutions, and unless last-mile integration is part of the service solution, don’t completely eliminate the need for internal IT. Still, a service-based approach can be the right option for companies with limited IT staff availability, even if temporarily.
- Migrate to a modern EDI integration solution. If your legacy EDI solution provider can’t offer the “modern EDI” capabilities called for by your trading partners and internal business needs, migrating to a broader, more capable integration solution may be the most efficient and cost-effective option, in the long term. The ability to address multiple kinds of EDI integration requirements with one solution can accelerate results and reduce both software and IT staff costs, by eliminating coding and internal integration requirements, reducing software licensing and skill set maintenance costs, and supporting simpler, more consistent methods.
What makes EDI modernization such a difficult topic is that there is no best way to modernize. Under the right circumstances, each of the approaches above can make sense. Where problems arise is when companies apply strategies that don’t fit the circumstances they are facing, usually for cost or expediency reasons.
And both companies and their circumstances change over time, of course. So that solution that made sense a few years ago might become the next problem to solve.
In the end, every business is limited by budgets, circumstances, and its ability to predict change. So the ability to add modern capabilities and move between service- to self-implementation as needed, without sacrificing EDI integration investments, may be the most important decision factor in EDI modernization.