Peeling The EDI Onion: Part 2
[Read "Peeling The EDI Onion: Part 1"]
Transport
The Internet has enabled anyone to throw up an FTP or HTTP website to move information. But most of these types of solutions require people touching the data, driving up the cost of the solution. In its origins in the 1970’s, EDI introduced mechanisms such as the Value-Added-Networks [VAN] and inner/outer envelopes that enabled parties to automate the transport of their transactions. Computers could now reliably send transactions to other computers without people being involved.
The Internet in the 1990’s took EDI practices into new domains. The first step was to replace the middle-men VAN’s. Solutions like the North American Energy Standards Board’s [NAESB] (formerly Gas Industry Standards Board’s [GISB]) Internet Transport, and the Internet Engineering Task Force’s [IETF] AS2 provide transport of transactions across the Internet that assure privacy, authentication, integrity, and Non-repudiation in sending transactions.
The second step still in progress is the adoption of ‘Service-oriented architectures’ [SOA], including use of WSDL and SOAP. SOA enables real-time exchange of information, speeding up the batch-oriented world of EDI. You no longer need to wait a day to find out the disposition of your transaction. Wholesale and smart-meter energy marketplace demands make real-time exchange of information critical.
Best practices
One of the most common statements we hear is ‘the cost of EDI is too high’. The reason costs of EDI are high is classic ‘pay me now or pay me later’: you pay higher EDI upfront costs by fully automating a process, eliminating people touching transactions and eliminating errors (which cause people to touch transactions). Making computers speak to other computers can be expensive; the downstream savings is usually worth it.
The transactions of an energy marketplace translate into real money. The enrollment transaction turns on a meter for an energy retailer. The usage transaction converts into actual dollars that a customer will pay. These transactions are extremely valuable to a retailer, and are tracked that way. Like inventory at a warehouse, they need to be able to pull a transaction, to remove a transaction, and to view the lifecycle of each transaction.
One best practice that EDI people live by is the transaction ID. Each EDI transaction has a unique number attached to it, enabling a company to track this information as it comes in to or leaves their organization, and the downstream actions taken on that transaction (e.g. ‘was that usage billed’). Many non-EDI markets do not include this convention, making it difficult for energy retailers to track and maintain ‘usage’ and other inventories.
Another best practice learned from EDI world is the ‘acknowledgement’, the ‘997’ in X12 EDI world. Non-repudiation concepts include the receiver not being able to claim they did not receive it, the proverbial ‘return receipt’ in snail mail worlds. People with low-budget hosted FTP or HTTP sites don’t normally provide receipts/acknowledgements, opening the door to claims that trading partners never received the transactions.
These practices often mean the difference between a computer taking action or a person taking action. They represent true cost-saving measures in an organization.
Conclusion
The real costs of ‘EDI’, no matter X12 EDI or XML EDI, is not that you have to pay someone who knows what ‘REF*12’ means. The real cost is that you need to pay attention to the gory details that enable you to eliminate errors and people touching transactions. There is no magic bullet or magic WSDL or magic FTP site or magic HTTP site to do this.
Fortunately if you are an energy retailer, there is ESG.