If you are a SAP user, you certainly know that most of the difficult tasks part of your project are to get the EDI partner's system to the configuration needed for the job.

This is especially true for those users of large EDI partners whose systems are rather inflexible and sometimes have hardcoded business rules. This can make even minor changes a time-consuming and painful process. After all - so much hassle just to change a few characters or add a couple of new lines of product code.

If above statement rings a bell or describes a situation you have encountered or are currently experiencing, then you are in the same situation than some of our customers, so the lines below will certainly be of interest.

For the one not familiar with EDI and interested to know more, I put some reference and explanation at the end of this post.

We had never considered looking at the EDI market because there are a lot of players there, and we never got too many complaints on the topic.

For the past six months we have heard more and more customers complaining about delay on their project due to integration issues with their partner via EDI platform. Some of them even asked us to develop the integration while their legacy EDI partner was trying to make it happen.

Moving forward half year, we are now in the process of migrating legacy EDI partners to our solution for four of our customers.

We have compiled the concerns / issues that our customers mentioned during the last six months:

• My EDI provider can integrate big partner with standard processes but struggles to onboard small partner.
• For some processes, I can generate two standard IDocs to be sent in one shot to my partner, some work being needed to merge the IDocs data. An alternative could be that I develop a custom IDoc and maintain it, so my EDI provider has nothing to do. But I do not want to have the complexity on my ERP side, I want the EDI provider to deal with it so that I can stay as close as possible to the standard output.
• The freight forwarder did something wrong and sent thousands of messages over the weekend, all of them failed as they were generated un-properly, but my EDI provider wants to charge me an extra 3 000 EUR for the over-numbered messages received. No gate keeper, no information, no monitoring on their side, I have just been informed when I received the bill…
• The EDI provider does not understand SAP logic (even if they claim being specialised in SAP integration), for each process I need to spend a lot of time explaining their team what and how to do.
• Each time we need a change, it takes weeks to get it delivered.

Now let us be honest, in some cases the issue is not only due to the EDI provider, but there is also a shared responsibility between all parties involved. However, we are here to help our customers, so we try to guide them on a way to improve and to easily integrate their partners.

Having analysed the different pain points, we started our journey in the EDI world.

Our first decision was to apply the same philosophy than with our robots, meaning:

• fix price for the development (same three tiers),
• monthly maintenance based on the complexity (same three tiers),
• and reusable building blocks.

Nothing more. Therefore, for the cost aspect, it is easy to compare what we do with your current solution.

This approach is tackling the different comments about pricing regarding legacy EDI provider.

Now, speed to execute. As you might have understood, for this topic, customers requiring our support are all using SAP, which makes it easier to build a solution. The flow we need to manage is simple (Outbound and Inbound):