Simpl-eBiz™
Why is it needed?
Over 25 years ago the idea was born to eliminate the use of paper documents for exchanging business data by linking computer systems together so that the data, normally on paper, could be sent from one system to the other. This concept became known as EDI, Electronic Data Interchange. The advantages are still valid today, no reentering of data and therefore fewer errors, if any. No dependency on postal services, cost savings per transaction from $75.00 to 50 cents, to mention just a few. However, looking at the statistics of who is currently utilizing EDI, one must wonder why it is not used by every business. In regard to the top 10,000 companies on the global scale (Fortune 1000 in the top 10 countries), almost every one is using EDI, 98% to be exact. However, for the rest of the world the adoption rate is less than 5%. In other words, millions of companies are still using faxes and paper documents. Why?
The answer is well known; start up cost. EDI saves a lot of money, over time. But before that happens, companies must spend resources up front to identify their data requirements in order to map their in-house data to the EDI messages. For example, the UN/EDIFACT Purchase Order (PO) contains over 1,200 data elements. A paper PO contains about 40 different data fields (assuming a single item is ordered). Why does the EDI equivalent have 30 times as much data possibilities? The reason is that the PO contains more than just data related to an order being placed. When the standard was created, and maintained over time, it was the IT departments that sent their experts to participate in the work. Their knowledge was mostly based on what was in their corporate database. Because of that, they requested (demanded) that their data requirements be fulfilled in the EDI message. There was no analysis as to whether the corporate purchasing application (or any other one) actually used or required that data. The more the number of companies using the PO (or any other EDI message) increased, then the more that additional data elements were added. Because many of the EDI messages are used across many industries, this addition of data requirements grew and grew. To help to bring the real data requirements back to a manageable level, industry groups started to create Implementation Guides designed to limit the use of data elements to what the companies in that industry agreed to. The general rule is that this would result in an 80% reduction, resulting in 240 data elements in the case of the PO, still six times as many as a paper PO.
Individual companies overcame that problem by further limiting their implementation to a subset of the industry implementation guide to eliminate another 80%, resulting in 45-50 data elements, which is almost the same number as a paper-based PO. However, if one compares the POs of any two companies in the same industry, their data requirements are not identical. Further, even if a particular company is big enough to dictate their requirements to any other company, not every partner they trade with can deliver all the data they want, therefore resulting in different implementations. The net result is, that before one can engage in EDI with a particular partner, resources are required not only to identify the requirements for data to be exchanged, but also include mapping that data to the in-house data base and testing the exchange before going live. This process is required for each new partner one wants to exchange data with, and for each EDI message with that partner. Thus, a very costly effort that only the Fortune 1000 companies in each country can afford.
In order to reduce the cost so that the implementation becomes transparent, one would have to agree to a single data requirement for a particular EDI message. This would allow software vendors to create an EDI application that would have a large enough market to reduce the cost for small and medium sized companies to be able to afford. This will never happen. So what would it take for software companies to build software that is tailored for each of the different EDI message implementations without requiring the huge startup costs to implement the variations to ensure that the different data requirements for a particular customer and their trading partners are met?
The answer is Ilumonus' Simpl-eBiz™ approach. Our Simpl-eBiz™ solution has eliminated the need for the end-user to customize their setup to meet the larger trading partners data requirements. By having worked with the Hub communities we are able to provide the exact mapping and data flow requirements in a total transparent way. All that is needed is to enter a few simple Trading partner identification parameters to start exchanging the first EDI messages. What is holding you back from trying it?