Der Beitrag The Real Cost of EDI: Considerations When Selecting a Solution erschien zuerst auf ecosio.
]]>With limited experience of EDI and faced with a choice between multiple different solutions, it is understandable that many people use the price of the solution as a key selection criterion. However, as we shall explore in this article, when it comes to EDI solutions, focusing principally on price is unwise. In fact, opting for a cheaper package that is less well suited to your current and future needs will almost always end up costing your business more than implementing a more comprehensive solution.
Implemented correctly, EDI solutions can bring substantial long term cost savings and hugely reduce internal effort and associated complications. By opting for a substandard solution, however, many of the key benefits of efficient EDI (and attendant savings) are negated.
To see exactly where savings are lost, let’s look at some of the common areas where EDI solution buyers typically experience problems.
As mapping and routing is the bread and butter of EDI providers and something that everyone considering EDI requires, EDI users understandably do not expect to be charged extortionate amounts to test connections, to send/receive a new document type or to exchange messages via a new communication channel.
Unfortunately, however, this is exactly the situation many businesses face once tied into a contract. By failing to check exactly how much work their contract obliges their provider to do or what functionality their package contains, customers run the risk of encountering large license fees or activation charges. Despite the fact that activation of new functionalities (e.g. exchanging via AS2) often requires no effort on the part of the EDI software vendor, something as simple as gaining an license key to activate a new function can cost thousands of pounds! Obviously this quickly eradicates whatever savings a business intended to achieve by selecting the cheaper solution.
A common example of such a situation can be found below:
Like mapping and routing, partner onboarding is an essential part of EDI for growing businesses. Predictably, therefore, it is another key area where solution buyers become frustrated with substandard service from EDI software vendors.
As anyone who has had to onboard partners themselves will recognise, onboarding requires a huge amount of effort. In addition to sorting the technical details (e.g. setting up test connections etc.), liaising with partners to get the necessary connection information can be a very time-consuming process.
With a fully comprehensive EDI software vendor this process is handled by the solution provider. Ideally, a dedicated project manager will be assigned to oversee the connection process. This involves chasing partners for relevant details, validating information and overseeing document implementation. In addition to removing all internal effort, this drastically improves the speed of connections.
By contrast, some EDI software vendors offer remarkably little help when it comes to partner connections. Whilst they may claim to provide assistance with onboarding, the contract may only specify that they are obliged to send a single email requesting relevant requirements from your prospective partner, for example. Solution buyers therefore experience neither fast, nor hassle-free connections and are left having to chase both their partners and their EDI software vendor to achieve results. Obviously, as with extortionate costs for unlocking new mapping/routing capabilities, this can quickly erase whatever savings were made by selecting a cheaper solution.
As EDI is constantly evolving, it is necessary to implement regular updates to keep a system functioning at optimum level. Updates can relate to many different things, such as document standards, EDI protocols or e-invoicing regulations.
For example…
Therefore an experienced integration partner that knows about the business level as well as the technological implications should be selected.
The larger a business’s partner network, the more updates have to be implemented, the more work is required to do so, and the higher the risk of failing to make the changes.
With the best fully managed EDI solutions such updates are implemented as required with zero effort needed from the customer. Cheaper and less comprehensive packages, on the other hand, will not include updates. Customers then face a choice between attempting to fix issues in-house (and running the risk of making costly mistakes while doing so), or paying for their service provider or an external consultant to update their system.
Further, by selecting a substandard solution which does not offer ongoing maintenance and automatic implementation of updates businesses may not even be aware of new and potentially crucial updates. Over time this can cause a significant reduction in process efficiency and security. Businesses in this situation also run the risk of experiencing sudden errors across a large proportion of their supply chain, which can be extremely expensive to rectify.
As costly as issues relating to mapping, routing, partner onboarding and maintenance can be, arguably the area where EDI solution buyers experience the most frustration with non-comprehensive EDI software vendors is error fixing.
Although many solutions claim to offer support, the quality of this support differs hugely from one provider to the next. Whilst a fully comprehensive EDI provider may offer 24/7 support, cheaper providers’ support will be limited. Often ‘support’ is limited to a single phone number or email address, via which it is typically extremely difficult and time-consuming simply to get through to anybody, let alone the right person.
Unfortunately, many businesses neglect to investigate the quality of their chosen provider’s support prior to signing a contract. When errors then occur, valuable time is lost trying to fix the issue. Further, the longer it takes to resolve the issue, the more likely it is to escalate or for similar issues to appear elsewhere in your supply chain, a scenario that can easily result in spiralling costs.
Possibly the single most useful step you can take before starting the process of selecting your EDI supplier is to conduct a thorough requirement analysis. Though this takes some time, it is well worth the effort and will ensure you don’t get stuck in the wrong contract. Some key questions to ask during this stage might be:
Although fully automated EDI hugely reduces the amount of manual effort required to exchange business documents, there are still many processes even after setup, such as error handling and message monitoring, that require management by someone to keep your system running smoothly.
A common error made by those selecting an EDI software vendor is to focus on the capabilities of the software, without considering who will be in charge of making sure things function correctly. Ultimately, even if you purchase the most incredible software, if you don’t know how to use it effectively or don’t have sufficient internal resources, you won’t see any benefit. Businesses in this situation are therefore forced to hire the required resources, change their EDI solution altogether or enlist the help of another third party supplier in the form of an EDI consultant (and in so doing commit to another contract).
With a comprehensive EDI solution these problems do not arise. Whilst operating an EDI solution in-house makes sense for those businesses with sufficient internal resources/knowledge and for whom EDI is a central part of the business, this is not the case for others. By far the most sensible option for businesses new to EDI or without EDI experience in-house is to opt for a fully managed solution. As opposed to the hands-off approach of other providers, a fully managed EDI solution provider will handle everything from the initial setup to ongoing operation, virtually eliminating the need for internal involvement. In addition to offering much better value, this approach ensures optimal system performance and frees up time for internal teams, allowing businesses to focus on what they do best.
A detailed breakdown of the differences between different EDI provider solutions can be found in our infographic on this topic.
Choosing a flexible solution is one of the best ways to ensure you achieve value over the course of your EDI contract. From a change in the amount of monthly messages you send, to needing the ability to send information in different formats and via different communication protocols, your EDI needs can easily shift over time. It is essential, therefore, that you select a solution that is able to help your business as you grow and requirements change. Sadly too few businesses consider this and are forced to pay through the nose to achieve simple functionality as their needs evolve.
Don’t let that be your business! By considering future needs and choosing a flexible, comprehensive EDI solution you can ensure that your business avoids surprise fees and continues to benefit from efficient, hassle-free EDI for the duration of your contract.
Though it sounds obvious, clarifying exactly what your package includes can save you a huge amount in the long run. If a provider seems to be offering the same service for considerably less, this is very unlikely to be the case! By failing to identify the difference between the two before making your decision you are likely to pay for it later.
A concise list of five things to consider when selecting a vendor can be found in our article “5 Key Components to Consider When Selecting an EDI Vendor”.
For more information on ecosio’s unique, fully managed EDI solution and to find out how we could help your business to benefit from efficient B2B document exchange with minimal internal effort, contact us today.
Der Beitrag The Real Cost of EDI: Considerations When Selecting a Solution erschien zuerst auf ecosio.
]]>Der Beitrag The Four Most Common EDI Protocols Explained erschien zuerst auf ecosio.
]]>In this article we will look specifically at the four most commonly used EDI protocols: AS2, OFTP2, HTTP and REST APIs.
An EDI protocol describes and defines the exchange of data between computers and is used by the communication software/application. In essence each protocol is like a separate language, as unless the trading partners are using a VAN, the computers of both parties must use the same protocol in order to communicate.
The chosen protocol also determines the level of message encryption, what software and hardware will be required and the ease with which transmissions can be received (i.e. whether both sides’ machines have to be online at the same time for message exchange to occur or not).
Although EDI can theoretically be conducted between two partners via any electronic method capable of transmitting the relevant information, the vast majority of EDI today is conducted over the internet. With the emergence of new technology came the need for standardised protocols. Naturally, over the past few decades the number of these protocols has increased. Thankfully, however, most supply chain organisations today use one of the following exchange channels:
First established in 1991, HTTP, or Hypertext Transfer Protocol, is a well-known and popular file transfer protocol. Since its inception four subsequent updates have been released, with the fifth and latest (confusingly called version 3.0) having come out in 2018.
As it only requires a web browser and no additional installation, HTTP constitutes a simple method of completing person to server and person to person file transfers. As anyone who uses the internet is likely to recognise, HTTP resources can be easily located on the network through URLs (or Uniform Resource Identifiers).
The downside of HTTP’s simplicity is the lack of security it offers, however. Although not as prone to firewall issues as File Transfer Protocol (FTP), HTTP is unable to secure data or meet regulatory measures. Due to the security disadvantage plain HTTP is therefore not recommended and at least the use of HTTPS with TLS (transport layer security) should be considered. Similarly, as HTTP doesn’t offer users the ability to receive receipts automatically, it is lacking when it comes to message traceability.
AS2 (or Applicability Statement 2) rose in popularity drastically after the turn of the millennium following the move by Walmart to require its suppliers to use it. Many other large retailers followed suit, meaning AS2 quickly became the most popular EDI protocol across many industries for point-to-point connections.
Unlike many other protocols, AS2 was developed specifically for B2B document exchange. As a result it offers several advantages over HTTP, including better security and the ability for acknowledgements and transactions to happen in real time.
AS2 uses the HTTP(S) protocol to send EDI messages through an encrypted tunnel. In a standard AS2 message files are transmitted as ‘attachments’. All file formats can also be handled and messages can be signed to provide authentication if required. As virtually no ERP system offers inbuilt AS2 capability, however, this must be integrated separately. To do this requires detailed knowledge and can lead to long troubleshooting if the administrator is not well versed with AS2 and its functionalities.
In order to improve traceability AS2 requires receipts, or Message Disposition Notifications (MDNs) to confirm message delivery/receipt. In contrast to AS1 and AS3 protocols, AS2 offers multiple MDN return options, including the ability to return synchronous or asynchronous MDN..
Thanks to its compliance with the Health Insurance Portability and Accountability Act of 1996 (HIPAA), AS2 is particularly popular in the healthcare industry today.
Like AS2, OFTP, or ODETTE File Transfer Protocol, was specifically designed for B2B document exchange by the Organisation for Data Exchange by Tele Transmission in Europe (ODETTE) in the mid 1980s.
In 2007, the OFTP2 protocol was developed specifically to be used over the internet. This update included important improvements over OFTP such as improved data security (via exchange of digital certificates) and the capacity for high compression.
In addition to allowing for very secure exchange of high volumes of data via dedicated servers, OFTP2 is remarkably simple to use compared to other protocols, with only 14 commands.
Crucially, unlike with AS2, with OFTP it is possible to push and pull information (rather than just pushing). It also gives the user the ability to request signed receipts, further improving data security.
For temporary issues, OFTP2 offers transmission restarts. This is preferable to the alternative method of causing an error and aborting the session, which in turn requires the message to be resent in a following session.
OFTP2 is widely used in the automotive industry in Europe, though is also popular across retail, manufacturing, banking and government industries among others.
An API, or Application Programme Interface, is a combination of rules and mechanisms which dictates how two endpoints are able to interact and share information.
In theory data exchange via APIs offers a great advantage to businesses as it allows for free access to important B2B data without the need for participation of the partner or availability in the moment of transmission. Once an API has been set up, data can be accessed instantly and whenever convenient. Companies are also able to ensure a high level of security by the ability to restrict access as required.
As there is little standardisation or restriction surrounding how APIs should be created and used, however, using APIs for B2B data exchange can become difficult the more partners your business has as you effectively have to reinvent the wheel for each connection. Unlike with AS2 or OFTP2, which adhere to predetermined standards, APIs can be used in different ways. For example, one trading partner could request to pull the files, one only accepts pushing files onto his server and yet another a mix of both approaches. Similarly, the semantics of the data being exchanged is also not standardised with data exchange via APIs. Whereas traditional EDI protocols rely on universally accepted document standards (e.g. EDIFACT), this is not the case with APIs, meaning each connection requires additional work. APIs can be very useful for EDI, however, as we explore in more detail in the article “Conducting EDI via API – What are the benefits?”.
REST, which stands for Representational State Transfer, is not a protocol itself, but rather a common method of writing API. APIs themselves lack a uniform structure. Instead structure is created through messaging formats such as JSON. Like AS2, REST relies on HTTP(S).
For small and medium-sized suppliers, by far the easiest solution for trading EDI messages is to use an EDI service provider – or VAN (Value Added Network).
Unfortunately, setting up point-to-point EDI connections is a complicated process and requires a lot of technical expertise. Plus, although certain protocols are favoured by particular industries, as your supply chain grows you will undoubtedly encounter requests to conduct EDI over different exchange channels.
By selecting a fully managed EDI solution all connection issues are taken care of by your provider. With just a single connection to ecosio’s cloud-based EDI solution (our Integration Hub), your business will be able to send automated messages to your entire partner ecosystem… and any future partners. In addition to allowing you to experience the cost benefits of fully automated EDI, this approach completely removes the responsibility for establishing, monitoring and troubleshooting your B2B message exchange processes, leaving your staff free to focus on more value-adding activities.
For more information on EDI protocols and how to get started with B2B data exchange automation, contact us today.
Der Beitrag The Four Most Common EDI Protocols Explained erschien zuerst auf ecosio.
]]>