The Human TouchThe Human Touch

Large-scale business processes — even those now automated to a great extent — still call for human involvement at pivotal points. Frequently, activities streamlined by business process automation (BPA) will not be completely automated; they will be coordinated. Coordinating the entire business process will not eliminate human involvement. However, it will increase overall process efficiency by enabling activities to be routed, escalated, and monitored.

This article discusses how to utilize semistructured communication to augment a business process. It briefly describes three major trends: more extensible and flexible business process technology, programmable communications servers, and the ability to categorize and analyze data more efficiently. We contend that together, these three trends will enable greater business process coordination (BPC).

Relevant Processes

Most large-scale business processes presuppose human involvement of some kind in various phases along the way. Decision points, for example, often call for human assistance. Two primary initiators of manual intervention are critical decisions that involve large sums of money and exceptions that necessitate that transactions be overridden and processed in a nonstandard way. In this article, we will discuss a returns process, which offers a good demonstration of human interaction at different phases of a business process.

Seamless interaction between human and computer resources participating in a business process requires consideration of the differences between human communication and communication as computer systems perform it. The main difference, of course, is that the messages exchanged between computer resources must follow strict, predefined semantics for the computer resources to understand each other. Humans can communicate in a more informal manner and often make sense of each other even if the message contents are partially formed at best.

The inevitable interaction between human and computer resources should be designed so that these fundamental differences have as little effect on the interaction as possible. The best solutions presuppose behavior modifications by both the human users and the computer systems. Human participants have to allocate an extra few seconds every time they interact with the system in order to categorize their messages. And computer systems have to become intelligent enough to understand the semistructured messages created by humans.

New Modes of Messaging

Emailing, instant messaging (IM), chatting, and short message systems (SMSs) are examples of newer computer-aided communication methods that have proved extremely popular, partly due to their easy-to-use interfaces. People can use them to access their companies' legacy systems with multiple devices and through various interfaces.

Messaging performed with these media affect the interaction details. Individual email messages, for example, often contain more than one topic. SMSs sent from mobile phones are limited to a few hundred symbols, forcing people to restrict themselves to fewer topics than with an email client. Moreover, unlike email, chatting and IM are examples of synchronous communication. Synchronicity here means, for example, that people typically try to answer questions in IM messages as soon as possible. These different means of communication and the reasoning based on them should be taken into account when designing BPC.

Human-to-human interaction has been the original intent of all of these styles of communication; computer systems have acted merely as the transportation medium. To allow machines to process the content of email messages, the free-form messages written by humans would somehow have to be translated into formal pieces of code. This would entail burdening humans with heavy interfaces through which they would declare formal semantics for their messages; or creating intelligent and heuristic natural language processing (NLP) systems for extracting semantics out of free-form messages. The first of these options is far easier to implement, but not likely to receive a warm welcome from users. The latter, on the other hand, encounters NLP difficulties that engineers have struggled with for decades.

If we are to consider an easier to implement approach, working environments and communities are ideal candidates. There are at least two reasons for this. First, people in working communities often perform repetitive tasks. People in communities write documents and send messages that are similar and repeated at certain designated project stages. That is why members of working communities might easily see the advantages of taking a few extra moments to categorize their messages according to some ontology, and thereby make it possible for machines to process and reuse their communication. Secondly, business processes concern, by default, working communities. Effective, wide-ranging BPC presupposes that, as much as possible, the information exchange among members of the working community is retraceable and intelligently retrievable.

A Process Example

To demonstrate, let's consider the inner workings of a returns process. We choose this because it contains automated system processes that are frequently augmented by intra- and inter-departmental collaboration.

In a typical returns process, a customer requests permission from her sales representative to return an order. The sales representative authorizes the return and issues a Return Merchandise Authorization (RMA). Upon receipt of the returned package, the returns associate inputs the RMA number to initiate the returns process. As is frequently the case, the actual returned items do not match the contents of the original order.

The returns associate inputs a reason code to classify the problem. The system checks the customer, order amount, product details, message type, and other factors to determine what routing and escalation characteristics to use. These details will control who should be sent emails or instant messages and of what type, how long the recipients have to reply, to whom they route escalations, and what the override requirements are.

In this case, an email is sent to the sales representative in charge of the account; she is given two days to accept or decline the rejection of this return. The sales representative feels the returns should be accepted and declines to accept the rejection, which triggers the sending of an escalation email to the sales manager. The sales manager overrides the rejection of the return and selects "huge potential sales" from the list of reason codes. The override is sent to accounting because it is more than $5,000. The accounting manager is out that day, so an exception is triggered and the email is sent to a coworker, who requests further clarification. This launches an IM session between the accounting manager and the sales manager. An IM session is spawned here as opposed to an email because this item generally requires a set of questions and responses that should be taken care of as quickly as possible. The sales manager accepts the override. Notification is sent to the Returns department, and the return is processed.

Without the automated system, returns and sales would fill in their own calendars and spreadsheets to keep up with the process. The sales representative would spend time and energy ensuring that none of the parties involved dropped the ball, and that the sales and returns departments agreed on the specific rules and policies of this return. This would require sales and returns personnel to spend considerable time manually communicating with each other. With the process coordinated, reminders, escalations, and routings are processed according to requisite business rules. This processing is handled by the system when possible and escalated to humans when necessary.

Collaboration

When sending a request for something — such as a request to return an order, which occurs at the beginning of this example — the recipient of that message understands from that message type, also called the "speech act," the anticipated actions to take. Request(return order) would translate as a request for returning an order, whereas inform(return order) would indicate a factual statement that the order has been returned.

Moreover, we can group messages as ordered sets, also called "interaction protocols." Interaction protocols define what message types are expected and allowed as replies to certain messages; they also provide details to identify which participant is the sender of some message. For example, request(return order) could identify the customer as a sender and "agree," "refuse," "failure," or "inform" as possible reply message types. As was the case with message contents, comprehending message types and interaction protocols is also typically easier for humans than for computer programs. In human-to-human communication, explicit message labeling to indicate the message type or expected reply is often unnecessary. However, it is essential to mention these things if a computer program is potentially the recipient, or if the communication is to be automatically categorized and stored. The burden to provide such information naturally falls to the interfaces, which much offer excellent usability, especially for SMSs and similar communication that involves small devices offering slow and limited input modes.

Because the system coordinates the basic collaborative process, the activities are now stored. Potentially, an organization could retrieve and view the entire communication thread and return transaction via a Web page. Many participants play roles in a process; because the transaction and its associated collaborative activities would now be accessible, the sales manager and the Accounting department are able to make decisions about the process without requiring updates from the participants involved throughout the process.

Lastly, the structure added to the collaborative portion of the business process allows you to save these previously uncategorized portions of business transactions in business intelligence and transaction systems for retrieval and analytical purposes. In addition to being generally useful, an organization could use this newly actionable data to streamline the business processes themselves. For example, accounting may always approve returns of less than $10,000. The newly recorded information would provide options: For example, an organization could further automate the process by changing the rule to request the accounting department validation only for orders larger than $10,000, or to inform Accounting that it needs to follow the rule and check on all orders larger than $5,000.

"Error! Reference source not found" summarizes the returns transaction. Figure 1 shows a returns process: (1.) The customer sends a request message to the sales representative. (2.) If the sales representative does not refuse the request right away, she queries the sales manager to see whether her decision is acceptable. (3.) In this case, since the amount of money is more than $5,000, the sales manager contacts the accounting department. (4.) Since the accounting manager is out of the office, an accounting assistant sets up an IM session between the sales and accounting managers. (The IM session can include multiple messages sent between the participants, but those are excluded from Figure 1.) (5.) The sales manager informs the sales representative that the order should be returned. (6.) The sales representative is therefore capable of telling the customer that the return is approved.

Figure 1 An example of a returns process.

Process Improvements

This article has focused on business efficiencies to be gained by augmenting the traditionally automated portion of business processes with their manual counterparts. Given current trends enabling BPC, people now have the means to participate in processes otherwise carried out mainly by computer systems — and these means will mature in the years to come. Process descriptions for Web services will come to include conversation patterns that support more natural interaction between humans and computer programs. On the other hand, IM and chat clients will become more common in mobile devices, thereby enabling better real-time interaction with process flows anytime, anywhere.

With BPC improvements, the array of details contained in the automated section of the process becomes visible to the process participants — and much easier to act upon. This improvement is especially helpful in a large, one-off process, such as a loan process that contains a set of deadlines, regulations, and forms, and consists of process participants with varying skill levels and understanding of the underlying process.

BPC improvements will also prove critical to conforming to government regulations and standards, such as those presented by the Sarbanes-Oxley Act and HIPAA. These recent regulations demand that businesses align forms and unstructured data with their associated automated processes so that information may be routed and analyzed in timely and efficient manner.

As this article has described, BPC enables processes and tasks within processes to be routed and escalated according to business rules that lie within the process. With the additional data captured and made available for reuse by those drilling into processes for analytic purposes, greater efficiency and effectiveness will be within reach of both human and computer applications.

Robert Eisenberg [[email protected]] principal of RE Associates, consults, speaks, and writes on business process management and service-oriented architecture. He has owned two software companies, sold one, and held a senior IT position at a public corporation.

Santtu Toivonen [[email protected]] is a research scientist at VTT Information Technology. He specializes in software agent communication, ontologies, and the semantic Web.