cartoon wheres waldo, beach image with waldo circled with arrows

EDI Solutions – 2 Common Pitfalls – Buyer Beware



describe the image

In our EDI sales cycle we often see two scenarios play out. One is the potential customer that wants to do things themselves, the second is the software developer that wants to control everything.

That a site wants to do things themselves is in and of itself not an issue, however when you scratch the surface two things usually come out. The first is easy to deal with the other is more insidious.

The first issue is that the potential customer does not understand the value of the specialized knowledge and figures well I am technical or I am a programmer I can do the setup, mapping and integration myself. They might be right but more often than not they are usually wrong. They may also have a fear of being held hostage by the consultant. Maybe the result of a past experience that went bad. Put the two together and you have a customer that is adamant they are going it alone. What typically happens is the site gets installed and not an awful lot gets done because the learning curve is steep, they don’t have the time or worse yet nothing works very well and the software gets blamed. Not good.

The reality is that someone who maps day in and day out can usually bang something off far faster than some one who does one map a year. The value of working with an expert is that they more than likely already know the trading partner requirements. The other aspect to this scenario is that outsourcing the technical aspects to someone who is knowledgeable is ultimately cheaper in the long run, despite the initial fears. So if you are buying ask yourself some hard questions.

The second scenario is one we come across from time to time and it is very self-serving. It is the software developer who wants to do everything themselves. Rather than focusing on core competencies they try to control all aspects of the clients IT work whether they know anything about it or not. They will often play on their client’s lack of knowledge and convince them of their approach. Usually the client suffers in this scenario and gets a less than adequate setup but it takes a while for the reality to sink in.

As it relates to EDI the way this scenario plays out is the software developer will, rather than partnering with an EDI expert, take the EDI implementation guide and code an interface specifically for that trading partner’s EDI specifications. As their client’s EDI grows so do the number of custom trading partner programs. At some point this becomes unmanageable. The software developer has locked the customer into a spaghetti mess of code that makes it very difficult to move when a trading partner changes things or wants to upgrade to a newer version of the X12 standard. At the end of the day this scenario is far more costly that putting in place a proper EDI system that interfaces with a single layout for a specific transaction type. The way to stop this scenario usually occurs when the software developer is unable to respond in a timely manner and all hell breaks lose or if the cost becomes too high and the client chokes on the price.

So building it yourself at the end of the day is not always the smartest way to go. When you talk to experts you usually derive a benefit from their expert knowledge. When you buy a proper EDI system you also derive the benefit of many inputs, the experience of many clients.

So buyers beware! It is not always better to build it yourself or rely solely on your software developer. If you are buying ask some hard questions you might find you save yourself some money.

Check out the two Integration TV episodes that discuss the build vs buy there is some useful insight.


Categories: EDI, technology