Plugging People into B2B Infrastructure

1. A Brief History of Automation

We human beings are extraordinary in the range of tasks that we are capable of performing, from mining coal to pondering philosophy. The history of technology has been an ongoing attempt to take advantage of this fact, by building tools to take increasingly complex tasks off our hands. Mundane, repetitive tasks have been the first ones targeted, both because they are the simplest to automate, and because they are least appealing to perform. The earliest innovations, such as the wheel and the lever, didn't really automate anything, but simply amplified the power that can be deployed by a human in performing a task. This in itself is already of great value, as any bicycle rider will attest. Later the train and the automobile removed the peddling from machine-aided mobility, and in recent years automatic transmissions, cruise control and antilock braking systems have made it possible for any Sunday driver to feel like a Formula One racer.

This example holds an important lesson for the automation of business processes. Automotive engineers haven't attempted to revolutionize their discipline in one fell swoop. Instead, they have worked with the evolving technology, allowing it to take over more and more sophisticated activities, but leaving humans, with our amazing versatility, to take up the slack. True, information technology has made it possible for computers to move quite high up the food chain, performing intellectual-seeming tasks, but we are still far from the day when they will have covered the full spectrum of human abilities, leaving us to a well-deserved retirement on the beach.

The promise of modern e-business is to extend the benefits of existing systems such as Electronic Data Interchange (EDI), making them cheaper to implement, accessible to a wider range of companies and applicable to a broader variety of tasks. This paper is not directly about the different approaches that are being applied to this problem. It is about providing tools and technologies that enable human beings to interact with the new e-business systems being put into place. As the above discussion has set out to demonstrate, this interaction will be a vital part of automating business for the foreseeable future, and by letting people apply their remarkable abilities to areas where automation is not feasible for one reason or another, we are continuing on the logical path that has been traced by the evolution of technology.

2. A User Guide for Humans

So let's turn the key question of business automation on its head. Instead of asking what the role of technology is in e-business, we now ask ourselves what is the role of humans. In a way, this is just an alternative path to the same goal, like sculpting a statue using subtraction (e.g. chipping away from a block of stone) rather than addition (e.g. building it up with clay). But it also provides insights into the correct way to build e-business systems that are designed around the obvious need for connectivity with humans. This is a vital point, since far too little attention is currently paid to the problem of enabling humans to work in the framework of new-generation e-business architectures.

Obviously, humans will continue to have a vital role in determining high-level company strategy. Sophisticated management information systems may make it easier for senior executives to plot the course of a corporation, but the final decision of whether to continue to invest in a failing subsidiary, sell it or float it on the stock market lies squarely in the hands of the executives themselves. The same pattern can be seen when moving down the hierarchy, wherever technology cannot yet duplicate the intellectual capabilities of humans. A purchasing manager may be able to use an Enterprise Resource Planning (ERP)system to anticipate future inventory needs, but the final decision of what to buy remains her own. A secretary can use a mail-merge program to create hundreds of identical letters, but he still has to correct his boss's English. Line workers may be eliminated entirely from certain highly automated manufacturing processes, but human engineers still design the robots that put the products together on the assembly line.

In many cases, the decision not to automate is driven by financial, not technological factors. An antilock braking system that wouldn't increase the price of a $30,000 car perceptibly might have an unacceptable effect on the total cost of a $10,000 car, even though the technology is equally usable in the second case. Nor does it make sense to build a $2.5 billion chip fabrication plant unless the resulting chips will be sufficiently powerful to justify their necessarily high price. And online grocers who raced to build super-modern automated warehousing and storage facilities are now finding that it would have been cheaper to use more traditional methods involving manual procedures.

The last example points to a final area where human intervention remains superior to automation. This is when circumstances arise that could not have been anticipated in advance. This is very often the case when something new is being tried, as in the case of the online grocer. Some events are so rare and catastrophic that it would not be feasible to protect against them. If an earthquake throws an assembly line off kilter, it is up to maintenance staff to set it right again. There are also cases when a normal response is acceptable, but an unexpected and superior alternative is also available. If my automated navigation system is guiding me the long way around the block, I might decide to ignore it and do an illegal U-turn as long as I can't see any cops around.

All of these scenarios can be seen in the world of e-business. Obviously there are plenty of tasks that cannot be automated using existing technology. General Motors may dream about automating its entire supply chain across multiple tiers of suppliers, from nuts and bolts to the final vehicle assembly, but no one is contemplating giving machines the choice of which cars to build in the first place. The same is true for vehicle design; although supported by sophisticated computer-aided design tools, it will be the responsibility of human engineers for a long time to come. These examples are, however, of little interest to us, since we are focusing on situations where human interaction must take place alongside automated processes.

This is often the case when automation is rejected for financial reasons. This decision is often temporary, and may be linked to the newness of the technology being used. For instance, a company contemplating use of an e-marketplace might hesitate to embark straight away on a full-scale integration project that links the company's internal ERP systems straight through to the marketplace. Although the advantages of this integration (in terms of improved supplier sourcing, access to new markets, improved customer relationships, reduced costs, etc.) are clear, the sector is very new, and it is unclear at present which technologies and even specific marketplaces will emerge as the leaders. It can therefore make more sense to choose less expensive integration that includes a component of human intervention.

The final example, when unforeseen circumstances arise that require human input, is perhaps the most important for this discussion. So-called "exception processing" is an important part of supply-chain management. Although this can be automated to a certain extent using rule-based systems that analyze circumstances and take action accordingly, nothing can replace tools that enable humans to monitor processes and reject the automatic response when a superior alternative presents itself. If a human operator notices, for instance, that a regular supplier has not made an automated bid for a large order, she might contact the supplier directly to find out why. It might turn out the supplier didn't have sufficient stock to fill the entire shipment by the date requested, but that if the buyer waits a short time for the last few items, a much lower price can be achieved.

In general, the two most significant cases where human operators must work alongside automated systems are covered by the last two examples given. In the first instance, full automation is costly and involves a certain amount of uncertainty as to the potential return-on-investment. For this reason, less expensive human intervention with an incremental upgrade path towards full integration is preferred. In the second, human monitoring and intervention is necessary in order to make sure that unanticipated circumstances are handled in the most efficient manner possible.

3. Sockets for Human Plugs

Obviously existing e-business applications take these facts into account, providing aUser Interface (UI) for humans to work inside the framework of an automated architecture. These are generally web browser-hosted UIs that use reports to display data and forms to enable interaction with applications and databases. The problem with current generation e-business UIs is that they do not take into account the characteristics of modern XML-based e-business systems. Instead, they require that an application developer perform significant manual work in order to produce the appropriate UI for a given task.

There are three instances where current practices do not meet the requirements of human-machine communication in e-business architectures:

The first is when systems are evolving rapidly. This is especially common at present, as e-business vendors intent on providing end-to-end solutions are busy extending their systems with additional capabilities that require the development of new UIs. Often this UI development can significantly delay the release of new functionality.

The second case is when e-business applications must be heavily customized in order to be used by real-world customers. This requirement is more and more frequent as companies strive to automate increasingly critical tasks that require specific adaptation to their business practices. For example, an aerospace manufacturer and an electronics company involved in a trading relationship might have very different requirements for common business documents such as shipping notices and invoices. In this case, the need for customization might lead to the complete redevelopment of all application UIs.

Finally, the latest e-business standards hint at future architectures where document formats will be negotiated automatically by trading partner systems. The most obvious example of this is ebXML, a joint UN/CEFACT and OASIS standard, which includes procedures for trading partners to generate mutually compatible document formats automatically. In this case, UIs cannot be developed ahead of time, presenting a dilemma in cases where human intervention is necessary.

The solution to this problem is to create UIs automatically using the same infrastructure that is being used to build automated e-business architectures. Almost universally, this infrastructure is based on XML, which has proven to be a highly robust and flexible means of transmitting business data between heterogeneous systems. Crucial to the successful use of XML is the existence of XML schemas that describe XML document formats and as such represent the foundation of modern e-business applications. By using schemas to model data structures, rather than hard-coding them into applications, the latter can be adapted by modifying schemas rather than recoding, with significant savings in development time. Schemas furthermore serve as a convenient medium for a company to communicate the document formats it uses to its trading partners.

While it is not a trivial task to generate a usable e-business UI from an XML schema, examples such as Schemantix's XMLForms show how this can be achieved through deep understanding of UI requirements and schema technology. Particularly important is the ability to personalize UIs quickly and easily after they have been generated so that they conform to the expectations of system users. This approach can be applied with good effect to each of the usage cases mentioned earlier in this section:

When new functionality is developed, it is modeled using XML schemas. For example, an e-business vendor might create a new module for invoice processing based on schemas for invoices, payment orders and other documents. By using an XML-schema-driven UI, the company does not have to expend additional effort to enable human operators to interact with this new business service.

Now consider the case where the users of this new module need to adapt the XML schemas to reflect their precise business requirements. If traditional UI technologies are used, the customer might have to redevelop large parts of the UI from scratch. Besides the expense of this time-consuming and error-prone process, problems with updates are inevitable since the customer's version is no longer synchronized with that of the software vendor. But if UIs are generated automatically, the customer need only make the necessary changes to the module's schemas and continue to use these modified schemas when future versions are received.

In the case of schemas generated dynamically at trading time, schema-driven UIs are the only game in town. Hard-coded UIs can never take into account the unique requirements of two trading partners in the context of a specific trading interaction.

User interfaces based on XML schemas are thus a vital component in future e-business architectures. Despite the theoretical appeal of e-business systems that eschew human intervention completely, the history of technology has shown us that the remarkable computing machinery of the human brain has always been needed to fill in the gaps where automation has been impossible or impractical, and is likely to remain so for the foreseeable future. By providing a socket for humans to plug into, schema-based UIs remove the need for implausible end-to-end automation. All types of XML-based e-business applications become immediately feasible, the only question being the degree of human intervention required to make them run. And systems can be migrated from heavy use of human operations to complete automation in an incremental manner, dramatically reducing time-to-market and removing much of the risk from investment in e-business development when the technologies being used are new and still maturing.

Design and Development by deepX Ltd.