Why It's a Bad Idea to Let Your ERP or TMS Run Your EDI

In this article, we cover:

• The history of ERP
• Postmodern ERPs
• Postmodern ERP Features
• ERP Strategies: Administrative vs Operational
• Typical Applications for Operational ERP Functions
• TMS
• WMS
• OMS
• Digital Ecosystem Integration Landscape
• EDI
• EDI Processing
• Cons of EDI Plug-Ins and ERP/TMS Modules
• Benefits of Standalone EDI Solutions

---

 

EDI runs companies' most critical business revenue so the technology powering these transactions cannot be compromised. However, organizations often consolidate EDI with peripheral systems of record, such as an ERP or TMS. These consolidations can lead to significant shortcomings and unintended consequences. Learn about some of the major pitfalls that can hold businesses back when choosing to consolidate EDI under an adjacent technology.

 

History of ERP

To understand why it is a bad idea to let an ERP run a company’s EDI, we must first understand the background of ERPs and their traditional use cases. Conventionally, ERP (enterprise resource planning) is a software that companies use to manage daily business operations.
ERP modules are integrated with ERPs and are applications designed to address particular business functions, operations, and processes. Common ERP modules support back and front office functions, such as finance and accounting, procurement, manufacturing, and supply chain management. More functionally rich solutions may also include human resources management, eCommerce, and marketing automation.
Each module plugs into the ERP system, allowing the ERP to provide a single source of accurate data, even as the business continues to add new modules. For clarity, think of the ERP as the toolbox and the modules as the screwdriver, wrench, and hammer. Each tool (module) is part of the toolbox (ERP) to address specific needs.
 
During the 1990s and 2000s, ERP software became essential to the corporate IT infrastructure. By the mid-2000s, ERP software started garnering backlash due to the price tag of ERP systems, the relative inflexibility of an integrated suite, and the droves of ERP implementation failures.
 
It was out of this turbulent time period for ERPs that postmodern ERPs emerged.

 

 

Postmodern ERP

Postmodern ERP is a philosophy for creating a flexible IT infrastructure, in which different pieces of technology are adopted on their own merits and then integrated intelligently with one another to promote connectivity. This means that ERPs have become service-centric and very modular. A postmodern ERP has a core ERP that covers the most important business functions, but unique parts of your business are covered by specialized software applications that can handle tasks like transportation, warehouse, and order management. Standard functions of core ERP include:

●  Human Resources

●  CRM

●  Business Intelligence

●  Inventory Management

●  Financial Management

 

Features of Postmodern ERP

Postmodern ERPs are built with a core ERP that handles the most essential business functions. Other needs that are unique to a particular business are handled by specialized software applications that are utilized as needed. Some features included in a postmodern ERP are:

 

 

●  Business Agility and Flexibility – With specialist applications from the cloud, firms can leverage upgrades applied by the software vendor, let users make configuration changes, and replace applications within two to five years.

●  Reduced Complexity of the Core ERP – Implementing a hybrid set of solutions frees companies from having to customize a monolithic ERP suite to meet a differentiating business need or drive user adoption.

●  Improved Usability and User Adoption – Users’ needs for a web-based, app-like interface can be satisfied by providing specialist cloud applications.

●  Business-Appropriate Integration – Integration of functions such as order management and materials planning can be tight where needed, and loose for other functions.

●  Increased Business Outcomes – Postmodern ERP can deliver measurable improvements in business outcomes. ERP modules intended for integrated suites often lack the depth of domain-specific functionality delivered by specialist cloud applications. A postmodern ERP strategy can deliver greater business process improvements faster than the ERP suite alone.

●  Better Use of IT Resources – Postmodern ERP allows IT resources to focus on enabling innovation and differentiation instead of spending most of their time maintaining a bloated legacy system.

 
ERP Strategies: Administrative vs Operational ERP

When it comes to postmodern ERP strategies, there are two main options—administrative and operational.

 

 

Administrative ERP strategies are more likely to be used by service-centric industries. As the name implies, businesses employ administrative ERP strategies to help with more straightforward administrative aspects, such as accounting and human capital management.
 
Operational ERP strategies are more commonly used by product-focused industries like eCommerce, retail, manufacturing, and distribution. These companies have needs beyond an administrative ERP strategy. Businesses that use operational ERP strategies may want capabilities to help with supply chain and order management, in order to optimize processes and improve efficiency.
 

       Typical Applications for Operational ERP Functions

Operational ERPs have a few key functions that differentiate the platforms from other ERPs. This includes transportation, warehouse, and order management systems. We explore each management system in more depth below.

 

        TMS

A transportation management system (TMS) is a logistics platform that uses technology to help businesses plan, execute, and optimize the physical movement of goods—both incoming and outgoing. Additionally, TMS ensures the shipment is compliant and proper documentation is available. Functions of a TMS include:

·     Planning and optimizing terrestrial transport rounds
·     Inbound and outbound transportation mode and transportation provider selection
·     Management of motor carrier, rail, air, and maritime transport
·     Real-time transportation tracking
·     Vehicle load and route optimization
·     Transport costs and scheme simulation
·     Shipment batching of orders
·     Freight negotiation
·     Freight audit
·     Cost control, KPI (Key performance indicators) reporting, and statistics
·     Service quality control in the form of KPIs
·     Typical KPIs include but are not limited to:

o Percent of On Time Pick Up or Delivery Performance relative to request
o Cost Per Metric – mile; km; weight; cube; pallet
o Productivity in monetary terms, e.g., cost per unit weight or shipping unit
o Productivity in operational terms, e.g., shipping units/order or weight/load

Access White Paper on How to Maximize Your TMS Investment

        WMS

A warehouse management system (WMS) is an application that helps control and manage the day-to-day operations in a warehouse. WMS software guides inventory, optimizes order shipment, and advises on inventory replenishment. The benefits of a comprehensive WMS include:

·     Reduced fulfillment time
·     Increased inventory accuracy
·     Improved customer service
·     Greater space utilization
·     Increased warehouse productivity
·     Reduced labor cost

        OMS

Receiving, tracking, and fulfilling orders across two or more channels can be challenging for retailers, as customers expect more flexibility than ever. Some may want to pick up in-store, and others might prefer the order shipped to their home. Managing these requests from different sources — such as websites, apps, in-store, etc. — can be a logistical headache if using different systems for each channel. Instead, an order management system (OMS) can aggregate those channels and provide a single portal for all orders.
 

 

Digital Ecosystem Integration Landscape

ERPs can be integrated into a digital ecosystem. A digital ecosystem is composed of suppliers, customers, third-party data service providers, logistics providers, and all their respective technologies.

To create a digital ecosystem, companies need B2B integration. B2B integration ties together all business processes and systems at play. This enables companies to swiftly respond to supply chain disturbances, whether it is caused by a pandemic, hurricane, or geopolitical event. Furthermore, B2B integration helps companies through positive scenarios as well, such as increased eCommerce purchases and fulfillment.
 

  EDI

ERPs are a great way to improve supply chain management, along with EDI. EDI is a methodology encompassing many sets of standards and transmission protocols that help companies electronically interchange business information. Since EDI is set up as an automated process, errors/issues are reduced, and efficiency increases because humans are removed from the equation.
 
When thinking about EDI implementation and strategy, companies that underestimate or do not account for their supply chain will likely run into issues along the way.  An EDI strategy needs to align with the requirements of the business implementing it, and all the businesses within their supply chain.  
 
Globalization has resulted in larger and more complex supply chains, magnifying both the challenges and benefits of EDI implementation. A rigid EDI system will not be able to connect all stakeholders and can leave companies struggling with manual inputs and ad-hoc procedures that will undermine the entire point of the investment. ERPs that provide EDI services tend to be more rigid since the ERP’s priority is not EDI. ERPs tend to add EDI as an extra feature that provides basic functionalities, not as a forever replacement for standalone EDI software.
 

  EDI Processing

EDI processing requires a lot of complex technologies and processes. Oftentimes, EDI processing requires more capabilities than an ERP’s EDI module was created to handle. This is largely due to trading partners requiring a wide assortment of protocols and standards. There are four main aspects of EDI processing which we cover below.

        1) Communication, Transformation, and Standards

Communication Between ERP and Trading Partners
EDI processing facilitates communication between a company’s ERP system and its trading partners. Different trading partners have different standards and protocols for communicating. An effective EDI solution should be able to use the right communication method that each trading partner requires.
 
Translating EDI Formats
When it comes to EDI standards and protocols (esp. X12, EDIFACT, and Tradacoms), they are not easy to use for importing and exporting information. It is usually better to use a simpler format like flat format/fixed records or CSV. There are often libraries in an EDI system or programming language for these formats. For example, libraries and facilities exist for XML and JSON.
 
Handling Different Versions of EDI Standards
EDI standards are often actively maintained and undergo updates. Companies end up using different versions of the same EDI standards depending on their trading partners’ requirements. Unfortunately for companies, the latest EDI version rarely offers added functionality or advantages.
 
Handling Different Interpretations of EDI Standards
Since trading partners use different versions of the same EDI standard, companies have to be able to interpret the various versions of EDI standards.

        2) Workflow and Integrations

Manage EDI Data Flow and Integration to Backend Applications
EDI software lets companies build and monitor the communication and processing flows to and from your applications. This is similar to EAI software (Enterprise Application Integration), but EDI software is focused on external integration.
 
Users should be able to see:

●    What comes into the EDI software and what goes out
●    How an EDI file is translated
●    Error notifications (ex. by email) and easy-to-understand error reports
 

        3) EDI Functions

Conversion of EDI Data and Codes
EDI standards have thousands of code lists they adhere to. EDI standards are based on agreements between a company and each of its trading partners, whether they are suppliers, manufacturers, shippers, carriers, or customers. If the EDI data does not adhere to those agreed-upon standards, an error will occur, and the supply chain will be disrupted.
 

        4) Visibility, Tracking, and SLA Management

Business Process Visibility
Visibility into processes such as document flows is a critical aspect of EDI processing. An example of a document flow is an O2C process (850 inbound -> 855 outbound -> 856 outbound -> 810 Invoice outbound). Users should be able to search for a single attribute like a purchase order number or load number, then drill into the complete processes.
 
With supply chain disruptions caused by the pandemic, trading partners are mandating companies to adhere to stricter SLAs. For example, acknowledging and responding to a purchase order within four hours instead of six hours, or providing a load tender response within 20 minutes. If a company does not respond within the timeframe outlined in the SLA, trading partners may penalize the company with a fee.
 

  Cons of EDI Plug-Ins and ERP/TMS Modules

There are essentially two options when looking to incorporate EDI into a business; build the EDI inside the ERP or use a standalone EDI processing application. Companies often run into challenges when building EDI inside an ERP via plug-ins and modules. We cover the common issues below.
 

        1.  EDI Tied to ERP

The first challenge of EDI inside an ERP, TMS, or WMS is that it will be tightly tied to the ERP. When an enterprise grows and is looking to implement a new ERP or TMS, the switch will impact EDI with its trading partners. The average company that performs EDI has anywhere from 100-200 partners, and 400-500 maps—all of which will be impacted by the switch. This is a huge challenge and workload to tackle for any company.

        2.  Constricted EDI Capabilities

EDI is a complex process. If performing EDI inside an ERP, it usually requires other solutions around the ERP to help complete the EDI processing. This is because ERP, TMS, and WMS tend to have very lightweight EDI processing. For example, a company may have a different communication software to support various protocols— scripts to complete EDI processing, scripts for database table lookups, or integration between different databases to pick up certain attributes and values.
 
Another limitation is that ERPs may not support warehouse or O2C transactions, so businesses must perform EDI in multiple places or applications.

        3.  Limited Visibility Tracking

EDI requires business visibility into O2C, P2P, and L2I processes and transactions. As an example, ERP, TMS, and WMS do not have any visibility into linked transactions. Thus, forcing the daily operations and business teams to spend time searching for connected transactions.
 
Companies spend a lot of time debugging an issue with their suppliers. They often hop into communication portals and ERP logs to determine what happened to the transaction. If it failed, why? Did the transaction fail in communication or translation? These issues affect customer scorecards with trading parents, which negatively impacts rebates and negotiating better terms. They can also result in penalties such as fines.

        4.  Integration Challenges

As we mentioned earlier, companies employing EDI inside an ERP may end up with multiple applications to complete EDI processing. Also, data in an organization needs to move into different applications from various ecosystem players. For example, an order may go to the core ERP, stock transfers may go to the WMS, and shipping information may go to the TMS. If EDI is bundled inside core ERP, businesses may not be able to seamlessly process EDI for WMS or TMS, such as 940s, 204s, or 214s. This is because ERPs may not have fields or modules applicable to leverage or store the data.

        5.  No Innovation

Lastly, the EDI software market is large but a lot of players are not innovative; especially integrated EDI solutions inside ERPs, TMSs, and WMSs. For ERP, TMS, and WMS providers, it would not be a worthwhile investment to innovate their EDI modules as it is not their main service, capability, or function.
 
Additionally, without innovation, new EDI use cases like API integration and management of SLAs for different document flows will not be supported. Enterprises are then forced to build workarounds using other applications and scripts, or do manual processing to support these particular requirements.
 

 

  Benefits of Standalone EDI Solutions

The better option for EDI implementation is standalone solutions, not plug-ins and modules. We cover the benefits of standalone EDI solutions below.

 

        1) Comprehensive B2B Solution

Standalone EDI engines are complete B2B solutions. Standalone EDI has EDI processing, communications, transformation, standards, visibility, code lists, look-ups, and orchestration. Additionally, standalone EDI solutions can integrate with other ecosystems and numerous internal applications.

 

        2) Flexibility-Communication Protocols and Data Types

As explained earlier, in B2B there are 10s of communications protocols and various file formats. Standalone EDI solutions provide enterprises with flexibility by accommodating their ecosystem needs. Standalone EDI solutions also allow for more business opportunities since companies can communicate with more trading partners.
 
On the other hand, EDI plug-ins and modules are rigid and force users to adhere to a much smaller pool of protocols and standards, thus limiting business opportunities.

 

        3) Enhanced Business Process Visibility and SLA Management

Standalone EDI engines are designed to provide business process visibility and SLA management. For example, companies can incur a huge fee if an ASN is incorrect or is not delivered on time. Standalone EDI software with the correct capabilities can mitigate that risk. Furthermore, customers and suppliers frequently maintain partner scorecards. A solid EDI system helps partners adhere to their customers’ standards and manage turnaround times for documents. This creates a positive scorecard with those customers which results in favorable business relationships.
 
Meanwhile, ERPs have complex reporting engines. Reporting engines have to be customized to generate reports pertaining to EDI communication or EDI data that has been received. Even with customization, reporting engines do not understand business flows for EDI documents.

 

        4) Innovation

Standalone EDI and B2B software companies like Cleo continue innovating based on new market needs and demands. Conversely, ERP providers treat EDI modules as non-revenue or minimal-revenue items. As such, ERP providers allot minimal focus on EDI development and enhancements, which is why EDI plug-ins and modules experience limited functionalities.

 

        5) Business Critical-Availability, Reliability, Scalability

Standalone EDI systems are critical business applications, yet most organizations treat them as tier 1 applications. The reason is that more than half of their business or revenue goes through this particular platform. Companies want their customers, suppliers, and carriers to see that they have 100% uptime, even when performing upgrades to their ERP or TMS systems.
 
For example, on Black Friday companies may experience the highest number of B2B interactions for the year. A solid SaaS standalone EDI system is reliable and can scale appropriately, keeping the system up and running throughout the sudden, large increase in activity.

 

        6) Superior Onboarding and Operational Support

Since EDI is their specialty, EDI software companies have superior support for operational issues. They also have knowledgeable teams to foster faster onboarding surrounding communications, translation maps, and workflows. These features are also cost-efficient.
 
Contrarily, EDI through ERP companies results in higher costs, fewer functionalities, longer resolution and onboarding times, and less expertise on EDI flows—creating a higher total cost of ownership.

 

        7) ERP Migration

Separation of ERP is key as companies can avoid customizing their ERPs to handle EDI, which is costly and complex. Standalone EDI engines are also helpful when enterprises grow and have to switch to a new ERP. This is because until the migration is complete, a standalone EDI solution can flow data based on the partner product migration to either the new or old ERP, until the migration is complete. Access our ungated checklist on everything you need for a successful ERP migration:

 

    The Solution: Cleo Integration Cloud-A Standalone EDI Platform

 There are three core functions of the Cleo Integration Cloud (CIC) standalone EDI engine. They are the ability to:

1. Support and integrate with any type of data format, whether it is JSON, cXML, flat file, spreadsheet, etc.
2. Enable a multitude of communication protocols like AS2, STFP, REST, VAN, and portals
3. Implement automation, orchestration, integration, and transformation
 

 

These three capabilities allow companies to communicate with their various applications, as well as their ecosystems which may include customers, suppliers, carriers, or retailers. There are additional features included in CIC, such as:

●   Operational Visibility - The ability to look into processes, supply chain, and data

●   Message Comparison -The ability to look at what messages came in and what went out

●   Exception Management - Determining what needs to happen if something fails

●   Activity Monitoring, Reporting, and Alerts - Helps companies adhere to SLAs

●   End-To-End Business Process Views - Ability to understand the process flows for O2C, L2I, and P2P

Lastly, CIC users have the option to control their EDI themselves, use our managed services, or enlist our hybrid services. If handling EDI themselves, companies can handle and design their own workflows, map development, version control, change management, profile configuration, testing, and operational maintenance. As a bonus, CIC is a SaaS environment so users do not have to worry about hardware or application maintenance because CIC will automatically scale depending on volume.

Key Takeaways

---

• Enterprises that rely on EDI for their business need a capable, standalone platform
  • Standalone EDI platforms are more robust, less complex, and more cost-effective than ERP plug-ins and modules
• Future proof your enterprise with a standalone EDI engine
  • ERPs built into an EDI may cause consequences down the road, such as EDI downtime during an ERP outage or ERP migration

 

Want more information? Learn about some of the major pitfalls that can hold businesses back when choosing to consolidate EDI under an adjacent technology.

Watch the Webinar

If you have questions pertaining to your business or want to learn more about CIC, explore our site for more resources or contact us today at sales@cleo.com to speak with an EDI Integration Expert.