The bulk of B2B interaction taking place, the transfer of routine transaction data such as delivery schedules, invoices and payments, is done in a batch mode. Here, the predominant need is to simply transmit repetitive information without any attendant sophistication. Let us examine the available tools to handle this job.

The basic tool available in the country, as on date, is conventional Electronic Data Interchange or EDI, offered by Service Providers (SPs) using private networks. Though robust in use, it suffers from some serious defects. Firstly SPs have not been able to demonstrate the ability to interconnect among themselves. The implication is that each user may eventually have to subscribe to all the SPs if they have to extend their business boundaries, to interact with other communities. Secondly, only the SP can service the front-end software. This poses a hassle, in case there is a change in the document format or a change in government legislation. This will require immediate updating. SPs do not have the wherewithal to make this change simultaneously at all the customer's locations. Thirdly, the tariff for carrying the traffic is a contentious issue. Who will pay for this, the sender or the receiver? In all probabilities, the weaker partner will be coerced into picking up the tab, regardless of who benefits by thetransaction.

Web-based EDI, as offered by Indian SPs suffers from the baggage of conventional EDI. This is because, connectivity issue among SPs still remains. A further drawback is that the economy of Net-based transmission is neutralised by a transaction fee levied by the SP for mailbox services.Individual companies have organised Net-based communities through their private initiatives. But these are ideal for operational only if suppliers are dedicated to that customer, as otherwise, the supplier ends up being a part of various communities, with different modes of operation for different customers. Incidentally, some of the private initiatives suffer from some lacunae.

One such site conveys the monthly order schedule to its supplier, but this is not valid as the buyer conveys orally the schedule on a day to day basis. Clearly the organisation is unable to update the schedules on a daily basis and instead, relies on physical interaction. Another shortcoming is that in some sites, the displayed information for the benefit of partners can only be printed and not processed. Such systems do not benefit the recipient to the desired extent hence are sub-optimal.

And finally, many such sites charge the community for the service and hence commercialism based on clout is at work.Several Web mall or portal-based solutions are available for B2B commerce from private vendors. Unfortunately, these are based on integrated transactions from tendering to payment, with all the bells and whistles built in. All these are not required for the run-of-the-mill transaction running in batch mode. The segment that portals and Web malls are good at, is more suited for one-off type of transactions. It may take some time before these tools can handle routine batch type transactions. Exhortations by vendors that users must be "creative", "adventurous" and "figure out methods, failing which they would be left behind", must be reckoned as part of their shrill sales pitch.

In addition, connectivity between marketplaces is currently not possible unless the sites are from the same vendor. There is a potential for integration software, which can bridge these individual sites.The ideal process to be adopted for the bulk of the transactions is to send information economically through the Internet. For this the user community must provide the foundation by standardising their documents. This should ideally be a subset of the UNEDIFACT standard so that integration with the outside world is facilitated. An appropriate body of users must be responsible to update the format from time to time and host it at a site where this is accessible to the members.

All the members must provide a uniform basic platform, on which the software can function, which can be just a Windows-based PC. An ideal software tool must approach the task along the lines given below.The software must extract user data from the database, convert into the standard format, compress the data, encrypt it and give a reference number to identify the batch. It must then send the data out through the Internet through either a leased line or a dial-up line. In the case of a dial-up line, it must give the option to the user to schedule the transmissions. In the event of an interruption in transmission, there must a method to alert the user and retransmit the information. Partial transmissions should not be permitted.

An acknowledgement is required from the receiving end to confirm safe receipt of the data. A log must be maintained at the sender's end to show the various transmissions done and the status of the acknowledgments. XML support must be available from long term viewpoint. It must have an option for using conventional EDI also. At the receiving end, the software must ensure version check and enforce control.

It must then perform all the reverse actions as applicable, till the data enters the receiver's database. Keeping in mind that many small parties in remote corners of the country are not fully conversant with IR, the software must be simple and user friendly. The user must be able to install, configure and make the first diagnosis in case of any difficulty. It is the author's belief that the availability of such a simple tool will bring large volume transactions into the electronic fold.

The author is the deputy general manager, Business Strategy & Systems, Sundaram Fastener Limited