“EDI” Comes Before “ERP”
Please note: This post originally appeared on Extol.com (EXTOL has been acquired by Cleo).
When you’re replacing enterprise systems, remember the alphabet: “EDI” comes before “ERP”
Many organizations facing enterprise-wide systems upgrades link the EDI and ERP systems selection processes, even though this approach may end up taking more calendar time and exposing the organization to greater risk. My colleague Jim O’Leary has reminded me that some organizations value the “interface compatibility” resulting from a tandem decision, and his point is valid. However, there may be other benefits to implementing EDI first, benefits that may be much greater than that of interface compatibility (which is often an ERP system issue).
The Issue of Duplicated Work
One of the frequent pushbacks to decoupling the EDI system decision from the ERP system decision is “We don’t want to do it all over again,” meaning “We don’t want to migrate to new EDI on the old system and then do it again on the new system.”
This is a valid consideration but it misses on two points: the new system may enable much faster trading partner setup, and the only rework is the “back-end integration” (where the EDI application connects to the ERP application). The back-end work has to be done again but that’s a single well-defined task often accomplished with target-application assistance whereas migrating hundreds of trading partners will be hundreds of time-consuming tasks. Not all trading partners believe reporting the results of a test is important, and small delays of this nature can have a serious impact on the migration schedule.
Getting It Done Faster
One of the key benefits of separating the EDI and ERP software decisions is the ability to get the complete software infrastructure changes completed quicker. Evaluating and selecting software, both EDI and ERP, often happens at levels above the operational EDI team. There is merit in one team for EDI evaluation and another team for ERP evaluation—but only if both teams report to the same manager.
In many cases, the administrative side of the sales process—negotiating prices, developing an implementation plan, and running the agreements through Legal (probably multiple times!) can burn up weeks and months. Does it make sense for two decisions to be held up because one’s legal review is dragging on? Sometimes, perhaps, but usually not—those days are lost to the project and to the business.
Since the EDI decision cycle is often much shorter than the ERP cycle, moving ahead with EDI provides an important deployment benefit: staggering the EDI and ERP implementations eliminates the risk in the “big bang” (all new systems go live at once) approach. Even adrenaline-powered project managers recognize the greatly-increased risk that comes with closely-spaced deployments.
Overlapping EDI and ERP
If the EDI system is selected first, the EDI operations team can begin the partner conversion process while the ERP search continues. New trading partners can be implemented in the new EDI system quickly—a critical need in the fast-moving supply chain world— thanks to design tools that are easy to use and that enable reuse of previously-developed EDI artifacts.
It’s possible the EDI system will not have ready-to-go interfaces built for the ERP system, and it could take considerable work to build them. But the number of defined interfaces should be a key factor when evaluating the EDI system: if the top ERP candidates are Epicor, SAP, and VAI, selecting an EDI system without interfaces to any of them probably would be unwise. It’s reasonable to assume that an organization won’t be comparing SAP and QuickBooks, so the pool of EDI candidates should target the pool of ERP candidates.
At the same time, current trading partners are migrated to the new system, a task that often takes time because the people that do it—the EDI operations team—usually have daily production responsibilities too. But EDI systems with modern design tools will actually make time available by reducing the effort required to set up and manage trading partners. Changes to custom code necessary to support new trading partners end. Faster turnaround of change requests often translates into increased revenue and reduced operating costs, if there’s no requirement to maintain old and new EDI systems. But there’s a much more significant reason to implement EDI right away.
Reducing risk increases the chance of success, and few projects don’t have components of scope, schedule, resource, activity, and project risk.
Trying to install a new ERP system and a new EDI system at the same time doesn’t double risks, it squares them. The workload on the project management team is doubled and management has to make the inevitable resource tradeoffs between competing projects. Deployments, particularly the big-bang type, also increase risk considerably.
On the other hand, an ERP vendor without a proven interface to the ERP system adds multiple elements of risk: schedule, cost, scope, and quality.
Because ERP implementations seldom take the same amount of time as EDI implementations, it’s very tough scheduling them so that both applications are ready to go into production at the same time. What do you do if the new ERP system is ready and EDI is not? Do you hold off on going live with ERP, and risk crashing the EDI implementation schedule? And if the systems are ready simultaneously and go live, what happens when a trading partner identifies an error? There’s an additional layer of troubleshooting: is it the EDI or the ERP application? Trading partners are waiting!
Of course, the ERP software vendor hoping to sell his EDI module will wave off such concerns by referencing the fact that ERP and EDI are “fully integrated.” That response fails to acknowledge where the real EDI migration effort takes place—setting up trading partners and testing the interchanges.
Why is that important? Consider and EDI implementation that takes 100 units of work and an ERP implementation requiring 1,000 units. It’s easy to field 50 resources across the broad scope of an ERP implementation, so that’s 20 units of work per resource. But if there are only two resources (EDI is a technical skill), each resource has 50 units of work. So even though EDI is usually a smaller effort, there are far fewer resources, and the result is that EDI implementations benefit from an early start.
ERP systems have functional strengths and weaknesses. A good ERP application with “integrated” EDI capabilities may limit your ability to respond quickly to new standards and customer requirements. This is because an ERP vendor may prioritize work on the order management or inventory applications instead of adding a critical EDI feature. Users don’t have an option with tightly-coupled systems, their “solution” is to spend unplanned dollars writing custom code outside of the EDI component in order to achieve the desired result while shouldering the high costs of ongoing maintenance, a.k.a. “technical debt.”
The best EDI systems integrate with the ERP systems offered by leading vendors. Among these vendors are DST, Epicor, Oracle, Retalix, SAP, TMW, and VAI, and with other systems offering defined EDI interfaces. Integration of EDI and ERP is not one vendor’s responsibility: the ERP vendor must provide a clean, stable, and well-defined EDI interface for both inbound and outbound transactions and the EDI vendor must provide flexible setup and run-time environments. In every ERP evaluation, the vendor should explain how the EDI interfaces are maintained, while in every EDI evaluation, the vendor should explain the impact of changing back-end systems.
What’s the Bottom Line?
It’s smart to consider enterprise-wide requirements when starting the search for new EDI and ERP systems—those requirements will help you focus on the key capabilities of each system. In addition, the EDI and ERP candidates should be compatible from a customer size/requirements perspective. Once the base requirements are established for the enterprise, the best efficiency and lower cost will be the result from allowing each implementation to proceed at a normal pace and the total time required for both implementations be minimized.