Home » Opinion » XML Capabilities for ERP Software
ERP software vendors are currently engaged in a rapid race to extend their package software capabilities to include XML message processing over the Internet. While widespread implementation of this technology is still years away, the XML messaging will have a wide impact on businesses and on ERP software capabilities.

XML Capabilities for ERP Software

ERP software vendors are currently engaged in a rapid race to extend their package software capabilities to include XML message processing over the Internet. While widespread implementation of this technology is still years away, the XML messaging will have a wide impact on businesses and on ERP software capabilities.

Every projection of Internet e-commerce growth exceeds one trillion dollars in activity within a few years. The engine driving this growth will be business-to-business trading electronic orders and shipments. This represents a shift away from the consumer driven (also called business-to-consumer or B2C) model of Internet buying and selling that we are so familiar with today.

Business-to-consumer e-commerce companies like Amazon.com and Buy.com receive most of their revenues from consumers using a web browser to access a website and purchase goods or services. This approach is inappropriate for businesses that engage in high-volume, repetitive transactions with specific customers or vendors as they acquire and sell product. Instead, what businesses require is an architecture very much like the EDI capabilities offered in the ANSI X12 standards or the International EDIFACT standards for electronic trading.

There are several drawbacks that EDI practitioners have struggled with since the inception of EDI in the late 1970s and early 1980s. The biggest drawback is the effort and cost to develop and maintain interfaces between trading partners. Because the EDI standards are so loosely interpreted and because EDI translation software exists as a stand-alone product, companies have to spend large amounts of time and resources implementing EDI with new trading partner. Nonetheless, we are assured of moderate, continued EDI growth since traditional EDI technologies and processes are deeply entrenched in large corporations. As customers, these Fortune 500 companies have become quite adept at forcing smaller suppliers to transact business using EDI.

In spite of these drawbacks, and in spite of the projected widespread acceptance of e- commerce, current projections show continued growth in EDI activity over the next several years.

Next year we will begin to see features emerge in ERP software that will augment or replace EDI capabilities. The earliest of these features will be the ability for the ERP system to receive or send XML messages that mirror or replace specific EDI transactions, such as the 850 purchase order. Initially these capabilities will require a similar level of support and set up that exist in establishing EDI sending and receiving. Later, however, we can expect to see advance features emerge in the ERP system that would automate much of the set up required. For example, we can expect a future XML message to be sent and received that actually communicates standard message processing and setup information, such as whose part numbering should be used, what units of measure will be used, what standards version applies, etc.

XML Advantages to ERP
XML messaging technology fits quite nicely into three distinct markets inside of the corporate ERP world. The first market involves using XML to interface two disparate ERP systems from different vendors. XML messages can be structured to carry information required to bridge, for example, a legacy sales and AR system to a new client/server system for inventory, purchasing and accounting. When one system updates the information that the other needs, XML messages can carry information each system needs, like customer address changes, GL journals, and inventory allocations. The future ERP system capabilities for XML processing will bring two benefits to this scenario. First, since XML messaging hooks will be prevalent in the ERP system, implementers can set up these interfaces with greatly reduced effort compared with current practices. Second, the overall solution will include the ability to store completed XML messages in an XML data base – thus providing a built in audit trail for each the interface.

The second motivation for widespread adoption to XML will come from XML's ability to support document storage and management. Large text documents that have complicated structure to them such as headers, tables, headings and sub-headings lend themselves very readily to storage as an XML data. We can expect procedure manuals and help text to be developed that use these formatting capabilities. The ERP system of the future will store this information in the data structures it uses for generalized XML storage and retrieval. Even today Microsoft uses this approach in SQL 7.0. Both data base information and help text are displayed in HTML (XML's progenitor).

The third reason for ERP packages adopting XML features — XML messages are Internet friendly. They are much easier to in supporting an e-commerce environment. For example, a vendor's catalog in an XML format is a lot easier to publish on the web than one in an EDI format.

These reasons are compelling and will drive worldwide acceptance of XML as a standard way to move information into and out of ERP systems. The ERP vendors are racing rapidly to include the earliest elements of XML messaging capabilities in their software products. Never mind that wide spread acceptance is years away. Next year's crop of ERP software releases should yield capabilities for basic XML processing, like receiving and sending purchase orders and invoices and the ability to store and translate XML messages.

Certainly there will be a long period of coexistence with EDI and XML both serving the same purpose on the same ERP system. To support this, we will see ERP system capabilities emerge that can send an XML purchase order to one vendor and an EDI message to another.

Disadvantages of XML Messaging
People cite three main disadvantages that have slowed the pace of XML development. First, because so much of the XML message text is devoted to labels and not actual data, XML has a high bandwidth requirement. In other words, compared with EDI or even flat files, more bits get sent down the line to convey the same amount of information.

Another important disadvantage that will have to be overcome is security and encryption. The EDI community has developed very sophisticated standards for encrypting messages and acknowledging transmission anreceipt of sent messages. In order for XML messaging to become an EDI-replacement technology, similar capabilities will have to emerge in the ERP modules that build and send XML messages.

The most compelling disadvantage is the current lack of standards. Even though many different industry organizations and industry trading groups have come together to begin to develop XML standards, virtually nothing has currently been promulgated. One of the earliest standards will come from Microsoft's BizTalk. Microsoft has announced that its forthcoming BizTalk server will include an Internet-accessible public repository where anyone can describe XML standards for their specific trading environment.

The wide number of standards bodies currently addressing the issue of XML standardization assures us that different XML standards will be more widespread than today's various EDI standards. (Today, many different industry groups have created separate interpretations of the same EDI transaction. Also, with the adoption of EDIFACT, EDI practioners now face two completely different “base” standards.) However, we can expect future ERP systems to be equipped with dictionary of standards that can be used to interpret and manage a variety of XML messages, each of a different standard. These ERP system features should far outweigh the disadvantages. They will help fuel a longer term trend that will make XML the most widely adopted means of business-to-business messaging for the future.

Doug Potter is a Partner with Newport Consulting Group. Mr. Potter's consulting career spans nearly two decades of management consulting including positions with Price Waterhouse and Ernst & Whinney. He specializes in helping companies select and implement packaged software. Over the last several years, his efforts have been devoted to projects that involve various ERP applications and related technologies.

Leave a Reply