What EDI Integration Method is Right for Your ERP?

Welcome to this week’s Think Tank with Frank Kenney

With decades of analyst and integration industry experience, Frank Kenney is a fountain of knowledge on all things tech. Now, he aims to share that awareness with you. Come back every other Thursday for your biweekly dose of thought leadership in this blog from one of technology’s most insightful thinkers and gain perspective on a variety of topics ranging from what’s happening in integration today to what’s on the horizon, poised to disrupt the integration space going forward.

***

Recently, I was chatting with a colleague and we found ourselves in conversation around the critical differences in approaching EDI integration between going with an ERP provider and selecting Cleo’s ecosystem enablement capabilities. Increasingly, organizations find themselves in similar discussions around how to make a strategic technology choice that’s rooted in operationalizing key business objectives – accelerate growth, gain a distinct competitive advantage, drive revenue, maintain compliance, and so on – that will best enable the business to thrive in today’s quickly shifting and dynamic supply chain landscape.

While modern ERP platforms – typically cloud-based – continue to be designed primarily for the strategic planning and forecasting of resources, increasingly those resources are elements involved in managing orders, as well as the shipping and transportation of any number of manufactured products.

In this context, today’s market forces consistently show that manufacturers who

1. reduce their overall transportation and logistics cost and time, and
2. have end-to-end visibility of the entire process, which includes manufacturing, 3PL and payment/invoice reconciliation,

are the companies better positioned to gain opportunities to continually digitally reinvent their business processes. This is key to successfully leveraging new sales channels as well as for entering new and peripheral markets, opening new lines of revenue, and rapidly driving growth.

In short, the more your business is able to facilitate the integration of your “core” applications with those of your partners and providers, the lower your cost and the greater your profitability – a straightforward, commonsense formula for success.  

To ERP, or not to ERP, that is the EDI question

The fit-for-purpose post-modern ERP, like many of the heavier traditional brethren, have embraced models based on this approach to enabling integration. As such, more and more ERP solution vendors are attempting to increase the stickiness of their offerings by working with integration specialist partners and service providers and not uncommonly coupling their offerings with that of specialized integration technology providers. The goal is to pre-integrate minimal integration capabilities into their respective ERP platforms. The assumed advantage – but one that is not necessarily a given – is that fewer ERP customers will travel outside of the direct ERP ecosystem, giving the ERP vendor greater control over the options (and the fate) of their customer base.

However, this approach is not challenge-free. The problem with the ERP-centric EDI method is that it introduces layers of complexity when it comes to initial implementation, continual support, and governance, as well as managing upgrades and new functionalities. Additional issues around how much technology you’re going to get with any ERP-based EDI capability is also an issue. As stated in the previous paragraph, put the emphasis on minimal.

To illustrate this point, take for example what goes into performing a basic EDI transformation. Typically, it is pretty simple, and some vendors will leverage generic XML-based libraries to do the transformation. The problem with this route is that the underlying engines are often based on XLST-stylesheet-type technologies, which are much better suited for only simplistic translations, such as HTML or plain text.

Once you start to elevate into the higher complexities of EDI, with its recursive objects added on to multiple EDI messages in a transaction, then a non-dedicated EDI engine starts to bottleneck, leading to performance degradation. To get around the performance hits, you end up having to buy more power whether in the form of virtual machines or more “instances” in a cloud solution, leading to greater cost and more investment in time and resources.

To push this scenario out a little further, there may be a tendency to think about EDI as just a transformation. This is a risky reduction of a critical component in intelligent integration. Instead, your business should be thinking about EDI as a set of complex processes that necessarily expand to include the requisite governance along with controlled, secure communications.

The need to think beyond data transformation

Once you stop thinking of EDI as just a transformation, you can broaden the view to include the required data movement protocols and transaction standards. For instance, is the business process contingent on moving files via AS2 or AS3, or does it only use FTPS? In either case, the process context still needs an inherent understanding of the expectations of the various business partners and their specific connection and integration requirements.

Further, where does the business store that information? Where do we assign or embed information regarding partners’ expectations, more commonly referred to as service-level agreements (SLAs)? And how do we ensure that these are enforced? The new breed of lightweight ERP vendors will say that it’s your ERP on one end and you simply have to configure the other side.

But that’s where things get lost. The devil, as they say, is in the detail. Let’s extend this line of thinking beyond EDI. Let’s talk about the other mechanism for business-to-business/ecosystem integration that is becoming ubiquitous in multi-enterprise business process environments – APIs.

Perhaps your partners want to call one of your internal APIs. In this scenario, you can just skip the middleman and the integration altogether, right? The answer is not really. Because those transactions still need to be governed, secured and controlled, you still need to bring about the capability to mediate between the ERP’s API and your partner’s choice of technology – ERP, CRM, WMS, TMS, etc. You will again need to introduce some level of integration.

What’s the verdict?

I can sum this up in a nutshell. When pushing for operational efficiency with your internal manufacturing process, inventory, and visibility, doing so from an ERP can seem to make all the sense in the world. But the reality is that your business is reliant on trading partners, suppliers, customers, and more frequently e-commerce marketplaces and platforms at the edge of your ecosystem to drive revenue. Simply put, that reliance means it’s necessary to consider the end-to-end business process holistically. Look at the entire process instead of focusing only on the ERP – the internal piece of the story.

That’s what we do at Cleo. We allow you to see the entire story in a way that gives you interoperability, standardization, and a unique set of governance technologies that layer across all protocols and integration mechanisms – B2B and APIs – for communication and control.

I’d love to have this conversation live with a virtual whiteboard so that we can talk specifically about your use cases and ultimate ecosystem/B2B needs and challenges.