Which EDI software should I buy?

Ladies and Gentlemen, that is a loaded question, one that does not have a simple and straight forward answer or response.

There are a lot of variables not being taken into consideration when you ask someone this question. Variables like ‘what is the core knowledge of the EDI department at the company’, what is the network capability, the main operating system, how is internet connectivity handled and at what speed, and lastly… what is the total and recurring cost of purchasing, using, and maintaining the EDI software?. 

I have had companies ask me what I think they should buy, and I refuse to tell them what they need to get. You see, a lot of years ago I did just that, told a potential trading partner I like our software so they bought it stating it is what I recommended. It did not work with their OS version, they could not figure it out, they never really made it work properly and in the final days, there were no refunds. 

So, they decided to sue my company (not me thank goodness). During the hearing (which I did not need to attend as I signed a statement), the emails and information came out that I expressed happiness and joy that it works for our systems, but they never researched any aspect of the software or its requirements and in their short-sighted knee jerk purchase, they spent money they could not recoup. The bottom line was the case was dropped and I will never “recommend” a software product to anyone, ever. I will give them a list of EDI Software packages I know are available and they can choose which they want after researching the software, the company, and the requirements themselves.

Yes, believe it or not, EDI software runs from affordable up through gourmet...I mean priced out of reach. I am not putting any numbers here because every one of these products has a smorgasbord of add-ons, and is scalable to meet the needs of the most demanding system. A few hundred PO’s a day to maybe 250,000 a day but that is the tip of the Iceberg. I know of companies that process more than a million transactions a day through their EDI translator, that would be the inbound and outbound totals.

Think about it, let's take 5 Purchase Orders in a day, that is not just 5 EDI 850 documents. That can be 5 EDI 850’s, followed by 5 or more 855’s, 5 or more 856’s, and at least 5 810 documents. Not to mention the 940’s, 945’s, 943’s, 944’s if you are using a 3PL (3rd Party Logistics), and all the related 997 acknowledgments that go with those initial 5 simple purchase orders. The more the software costs, and the better the code in the software, the more powerful the EDI Translator. Pay as you go… maybe, but more expensive does not always mean better. The most expensive software out there used to be affordable, but recently they priced themselves out of reach for most companies.

Prices depend on the product you go to, communications protocols, some software charges you more if you are using a more powerful computer – I find that ridiculous. I tend to be from the school if they ask how many cores, or how many processors will your computers have it may not be worth it to pursue that relationship. 

There is one software package I love. It has everything I mentioned above and below this paragraph and it is very fast to learn. I learned the application in less than a few weeks and learned the mapper, and the specific and somewhat unique syntax, in less time. I hate playing favorites here, but if you are looking for a new or replacement or a possible EDI application for your organization, give Seeburger a call. They are friendly and helpful, and their goal is for you to succeed.

Yes, for nearly any software out there with an exception or two you can add capabilities as they are needed and most of the time the software vendor will provide a resource to install and configure the new service. That is a plus and you need to know if this is normal before you sign the initial check.

So what exactly is in a base system? It has communications, EDI Translation, connectivity to the backend, a user interface for the EDI Team, and “other” users in the company for reporting capability. 

COMMUNICATIONS: In this world, most major organizations are getting away from the VAN (Value Added Network) because there is an added charge. If your VAN charges by the kilo-character, you may want to explore a VAN that charges a monthly flat-rate. The cost could be less than 10% of what you are currently paying. But needless to say, several communications protocols need to be included out of the box, or at least a low enough cost to justify an add on for one trading partner. Protocols such as AS2, SFTP, FTP, API, and an email interface. AS2 direct connection to your trading partner is the way to go for FREE EDI (after you pay for the software) it is a PUSH-PUSH system therefore it can be considered a near-real-time connection. You have documents for them, you send them when they are ready to go; they have documents for you, they transmit them to you when they are ready to go also. FTP is old-school. There is NO encryption in its use, but you can add a PGP encryption step before transmitting it. It is slow, a 2k file for example can be transmitted every couple seconds. SFTP is a better choice than FTP, it has built-in encryption when it transmits but the speed is just as slow as FTP. API is a direct connection from one system/network to another, encrypted and secure. Speed is a lot better than SFTP but still leaves a lot to be desired. Whatever communications protocol you decide on, you need to ensure your trading partner can use it also, so they need to be your first stop. The bottom line, make certain the communications you need are available in the software or easily addable, or activated, at a later date. Remember to ensure you can pick up or drop off files

EDI TRANSLATION:    EDI Translation is the act of transforming one data format to another. It can include X12 to SQL, or even Oracle to CSV. It makes no difference and does not NEED to include an EDI standard (X12, EDIFACT, etc). It only needs to change the data so on an outbound, you send it to your trading partner in a format they can use, and visa versa. It needs to include certain features out of the box. Features like a programming interface, a syntax language that makes it useful, and it needs to use standard programming methods to accomplish the transformation. It does not need to include bells, whistles, or glitter like some software companies add to charge more for the application. Also, certain vendors seem to charge 3 or 5 times more these days, giving you the impression that they improved the software. Where in reality, they were bought by another company that raised the cost to increase their profit. A trade-off. Costs too much, no one wants to pay, lower the price and more people will consider it. The bottom line, when you are looking for EDI Translation Software do your research. Find out the purchase cost and remember to find out the annual (maintenance) cost.

CONNECTIVITY:          Being able to talk to your ERP system is maybe more important than the ability to talk to a trading partner, after all, if you cannot USE the data, it makes no sense to have an EDI Translator. Whatever your ERP uses, specifically ask for the spec needed to connect. Like, does it need to be the newest version of SQL? Can it use an older version and still be stable? The bottom line, Whatever you use to hold your data, make sure the software can connect to it.

What else needs to be considered when purchasing EDI software?

Primarily, the core knowledge of the EDI Team. If they cannot figure it out or they are not programmers from the start, training and education are very important. Having the team learn the software is one thing, teaching an EDI User or Application specialist to be an EDI Developer is a different animal.

EDI Development is programming, not Visual Basic or C or C+ or any other but a combination of all of them. Having experience in any of the programming languages makes it a simple paradigm shift to program in another or a new language.

Is there a way to teach programming? Yes, but it is not a fast process and you need to be very patient with those who are in the learning phase as an EDI Developer. The idea of IF – THEN – ELSE is natural for some and foreign to others. As the basis for EDI Programming, this concept must be ingrained into the new programmer at a base or core level of understanding. Once they can grasp this root concept, regardless of how the software product uses or processes this reality, they can learn to use this to accomplish what they need to accomplish to move data in and out of the translator.

The last thing to consider is one of the first things I mentioned. The cost!

$2500 sounds like a lot but it is the low-end EDI product for use by the Mom and Pop business. Low throughput, low number of translations, low-end servers internally – possibly even using a PC to perform the translation.

How high does the cost go? That is up to the design you need. 

1. Is there a need for all of the communications protocols?
2. Will you be using a VAN (Value Added Network) or direct to your Trading Partner?
3. Is there a need for X12, EDIFACT, Tradacoms, VICS, HIPAA, Odette, SWIFT, or any of the rest?
4. How much support will the vendor provide?
5. Is support pay as you go, or is there a limit to the number of requests, or is support included in the annual maintenance plan?
6. Is outsourcing a viable option? 
7. Is in-house translation services a better, less expensive plan in the long run?
8. What about the nay-sayers who state EDI is an old and dead technology, do you believe this is true? 

I want you to know, here and now, that EDI is not dead. Look at the number of companies beginning or expanding their EDI processing. True, there are other options like XML, but they still utilize a base EDI Translator. You can transfer CSV files with your trading partner unless they are a big-box, then you MUST use traditional EDI formats.

The bottom line is you need to do your research. But how?

Begin with what you know. Number of processes per day, number of trading partners, back-end connectivity. These are all easy to find and understand. Then you can expand by thinking for the future, where do you want to be in 3 years? For example, you have a dozen data specialists inputting PO’s into your system that arrives by fax, USPS mail, or email. In three years you want that to be 2 EDI Specialist monitoring the automated systems.

This is a leadership and a department decision. How much is the company willing to spend to get to that point in time? 

I feel this is the initial conversation, have your leadership understand it is not instant and will require funding, and patients. As a consultant, I spent a great deal of my time trying to educate the 3-letters about how EDI works, how it is implemented, and the education and capabilities the EDI system in place currently possesses and what would be needed to get to where they want to be in a few years. Most of the time the CEO and CIO were on-board fast and the rest follow suit but there were times they wanted a million dollars of development for a thousand bucks. It was a difficult reality for them to swallow and once they did, and stood behind the process, the company thrived and excelled in the realm of EDI.

So, have that conversation internally. Then do your research. But most importantly remember these words…..

EDI IS FUN ! ! !

. . . . .

Chris Cancilla is an EDI Developer with more than 25 years of experience in more than 7 unique EDI translators. He has worked for EDI Software companies, manufacturers, 3PL's and distributors in a creative and/or support function; he has been a consultant and a contractor assisting companies in implementing EDI or improving their current capabilities. He has a line of EDI Education books for the new EDI Analyst and enjoys teaching and training people in how EDI can be used within its and the companies limitations.

For more information, review the available EDI Education books at https://AuthorCancilla.com

#EDI #EDUCATION #TRAINING #SOFTWARE #PROGRAMMING #ELECTRONIC #DATA #INTERCHANGE