Every business process is made up of many workflows that dictate how business gets done. These manual processes are being replaced by Internet-based electronic systems that promise to automate, improve efficiency, and expedite results. But this new way of doing business presents a boundary problem that's a high priority for CEOs: How can you effectively extend business processes to include suppliers, partners, and customers?

You can extend the automation to reach these third parties, of course, but how do you maintain control? Moreover, how do you effectively communicate and collaborate in a way that works for all parties involved? Is true electronic collaboration a reality? How does XML enable the interaction? And what approaches are being explored to allow for electronic collaboration? This article looks at the role that XML plays in B2B collaboration.

Part 1 of this series (XML-J, Vol. 2, issue 9) focused on the CEO's need for visibility and the role of XML in making visibility a reality. However, visibility isn't the only concern of a CEO. Today's virtual corporation presents a challenge to the way business processes are implemented. The ability to extend and manage these processes with external organizations provides critical value for most companies. Organizations that have extended the reach of their business processes need to ensure that they can manage the elements accurately.

Consider the manual processes that dictate how business gets done - a string of hallway conversations, telephone calls, paperwork, and faxes. Although the manual interaction of business is cumbersome and introduces significant inefficiencies, CEOs find comfort in the checks and balances afforded by human interaction. However, as business velocity increases, it's imperative that companies automate and integrate these processes to reduce manual processes.

While those in the technical community consider this obvious and are surprised at the slow pace of adoption of Internet-based systems, CEOs know that the business impact of this replacement and the uncertainty it creates for business users is the reason for the delay.

This article discusses the correlation between XML, collaboration, and workflow and how it enables further extension of processes outside the four walls of an organization.

The Promise of Process Automation
Converting paper-based documents into an electronic format for a network exchange in a tightly coupled interrelationship challenges the current definition of these documents and puts new demands on the data elements that the business documents contain. Companies recognize that computer systems can read and interpret electronic business documents and that programs can be established to respond automatically. By creating defined interrelationships between documents, it's possible for cooperating systems to create, modify, and accept these documents directly without operator intervention. Whether the process is paper-based or electronic, errors and modifications must be resolved by people communicating by mail, telephone, or fax.

By implementing electronic business processes connected by an interrelationship, computer systems can perform the entire process of creation, modification, and acceptance of each document. For example, a company that receives a purchase order with unacceptable terms or incorrect part numbers can notify the sender about the errors and recommend modifications so the document can be corrected and re-sent without requiring human intervention.

When people interpret business documents directly, there's no need for each document to be machine readable and cross-referenced to other related documents. While partners would agree on a language and a standard for weight and measurement in paper-based systems, it's recognized that the person reading the business document can make assumptions about the context of the information. This contextual interpretation is performed by the reader and represents the agreed-upon language without explicit definition. A reader can assume that the sales order received for a thousand widgets is probably in response to the most recent purchase order for the same number of widgets. However, a computer won't make these assumptions, so the electronic version of the business document must communicate this contextual information, thus enabling the system to take the appropriate action.

With paper-based systems the sender and recipient of a business document intrinsically agree on a language the document is to be written in. Similarly, partners who intend to exchange business documents electronically need to identify clearly how the data elements of the business document will be unambiguously exchanged. This can be done on a bilateral basis, using highly structured and tightly formatted machine-readable encoding, by adhering to standards such as Electronic Data Interchange (EDI) X.12 or by adopting XML standards such as OAGI, RosettaNet, or cXML. These are all standards that define a common syntax, or grammar, widely used by companies automating their supply chain to ensure that each sent data element is properly recognized by the recipient's system.

Need to Communicate Business Semantics and Context
While the syntax assures that each data element is clearly identified and put in a format that can be read by the receiving system, the use of computers to analyze business documents has interjected a new problem: the need to manage the semantics of the data elements. A sender's internal business process will typically influence exactly what the data means within some fields of the business document.

In slower, less analyzed times in the past, minor variations in these semantics mattered little. When a buyer kept four weeks of inventory, it didn't matter if a "shipped" data element meant the order was sent to shipping or actually loaded onto the truck. The variation would account for only a day, or maybe two, of discrepancy. Today a buyer may keep no inventory and expect the supplier to ship the product as the assembly line demands it. In these highly efficient times, a day or two can mean the difference between success and failure. These semantic variations also have a serious impact on analytics that evaluate supplier performance, since suppliers may use inconsistent semantics that prevent apples-to-apples comparison.

It's also important to note that the semantics are relevant only to the context of a specific business document. A ship date data element on a sales order is semantically different from the ship date data element on a bill of lading or manifest. In many cases different departments and different systems are responsible for creating this information. The sales order reflects the semantics of the order entry department, while the bill of lading reflects the semantics of the shipping department. Each perspective of the data entered is valid, even though the data is very likely different. Each of these data elements may have a key role in supplier performance management, and the semantics may play an important role in establishing the analytic used to generate supplier performance reports. A collaborative agreement regarding how the data elements will be used in the analytic will help each participant identify the most accurate data to send for each business document.

A discussion to resolve semantic variations may appear to be easy, but in reality it's extremely difficult and time-consuming. A buyer may have several thousand suppliers. Each supplier typically sells multiple products, and often each product will have its own manufacturing and shipping facility that also has its own business process. In fact, it's not uncommon for a large supplier to have multiple manufacturing plants for the same part, all with different processes that interject some level of semantic difference. Suppliers have traditionally been able to enjoy the benefits of a new manufacturing process without being concerned with the impact that the new processes have on interrelationship with business partners. The implementation of a new business process hasn't posed a problem until recently, when buyers began to couple their business processes more tightly to the sellers'.

To recognize the relationship between a purchase order and a sales order, a computer needs a key or a common data element that unambiguously links the two documents. While a person can simply assume this relationship, a computer needs the relationship to be made unambiguous.

An oversimplified example involves a purchase order and a sales order. As two companies increase the coordination of business processes, a flood of orders, order modifications, and status information begins to flow. The volume of transactions is so large that people would be unable to keep up. In order to delegate the creation and exchange of these documents to computer systems, appropriate keys must be in place. Properly keyed, the interrelationship across business documents can be recognized by a computer, which significantly reduces the effort and lowers costs. This efficiency is possible because the keys link multiple internal processes so that computer systems can manage interactions across the buying, selling, building, shipping, and paying processes. This substantially lowers the need for human interaction, reduces human error, and increases the precision of product delivery - critical if inventory levels are to be reduced.

XML as an Enabler for Communicating Process
While the need for process integration is evident, the ability to achieve it has been elusive. The emergence of XML has provided a means for allowing this to occur. Because XML separates data and metadata, computer programs can accurately separate the syntax of a transaction from the data. Disparate systems now have the means of providing a communications vehicle for application-to-application data.

The value of this simple innovation contributes to the role of XML in the Enterprise Application Integration (EAI) space. In addition, the self-describing nature of XML enables data structures to evolve over time. As the use of XML matures, companies will extend the capabilities by communicating semantics and context through standardized definitions for business transactions, messaging, and process. The evolution for extending the process outside the four walls has had three distinct phases, as discussed below.

Phase 1: JUMP
(Just Use My Process) You've heard the expression "When I say jump, you say, 'How high?'" This is the approach most channel masters used to extend business processes beyond their four walls. In fact, most companies cited as examples for the dramatic ROI potential that process optimization can achieve are in this category. They represented enough of a business opportunity that they were willing to JUMP at the opportunity to integrate with the channel master.

While this did produce dramatic results, the solution wasn't scalable and could be implemented only with partners who were willing and able to absorb the cost of changing to the channel master's business processes. As a result, organizations that wanted to maintain relationships with several large companies incurred the expense of maintaining partner-specific processes for each channel master. This limits the application of the JUMP approach to the few key accounts that require it. It became evident that a more collaborative standards-based approach would facilitate broader participation due to reduced costs.

Phase 2: Choreographed Process Definition
Organizations like RosettaNet and OAGI have, at various levels of flexibility, defined a choreographed flow for transacting business. Whether it's for the communication of sales orders or purchase orders, these approaches allow for integration of the transaction data into the processes of the enterprise application.

Although striving for the adoption of a single, common, domain-specific standard for content and transactions is useful, it's often difficult to achieve. This is particularly true in the case of cross-industry initiatives, where companies both cooperate and compete with one another. As a practical matter, the variations in business processes can't be resolved for a variety of technical, practical, and organizational reasons. Even if these issues could be resolved for a particular industry and instance, "in-time changes" and "evolution-to-market" conditions demand a more adaptive approach.

Phase 3: Defining a Language for Communicating Process
It's clear that while XML provides a language for communicating business transactions, it doesn't make any assumptions about the context definitions required for communicating business process. A modeling language that builds a means of communicating this contextual information on the syntactical framework of XML would provide the ideal language for communicating business process.

One example of such a language is Business Process Modeling Language (BPML). Defined as a medium for the convergence of existing applications toward process-oriented enterprise computing, BPML offers explicit support for synchronous and asynchronous distributed transactions. Thus it can be used as an execution model for embedding existing applications within e-business processes as process components.

Built in XML, the BPML specification provides a means of defining processes and workflow in an application-independent language. Figure 1 represents the levels of communication that such a language can facilitate.

Conclusion
While XML has opened the door for enabling automated communication between organizations and applications by providing a means for communicating the syntax, the ability to extend this capability to accurately define and execute a business process is still evolving. Efforts to create standardized process definitions provide a meaningful level of semantic communications. Although it's possible to communicate semantics through these standards-based definitions of business transactions, the need exists for a richer language for creating and evolving business transactions - a language that enables the expression of specific knowledge without the need to create or define specific terminology.

The capability of systems to communicate information across the virtual corporation will be a prerequisite of most businesses in the future. The main barrier to achieving this goal centers on the need for applications to communicate business processes including contextual and semantic variations at the level of human interaction. Unfortunately, this problem grows exponentially as the number of participants in a virtual corporation increase.

In Part 3, I'll cover the semantic issues for people, products, and processes that B2B collaboration presents. Different companies have different processes, personalities, nomenclatures, and so on. These differences present a challenge for companies that choose to collaborate electronically, particularly through XML. I'll focus on the role of semantics in managing the complexity of describing distinctive elements of corporations. If you'd like to discuss some particular aspect of this or any other topic, send me a note.

References

1. www.rosettanet.org
2. www.bpmi.org

Definitions

• Syntax: Symbolic description of a language that describes how elements may be combined independent of their meaning
• Semantics: Meaning of a data element from a specific point of view; the explicit meaning as intended by the writer/owner
• Context: Circumstances in which an event occurs; a setting that indicates the state of a process
• Process: Series of operations performed in the making or treatment of a product, or business transaction