People-Oriented Business Processes

Introduction

In general, the notion of process denotes a standard way to achieve a given goal. It is a result coming from experience and investigation. It can be applied to the action of a single individual or to the actions of a community; the latter case is particular relevant when business systems are addressed and, in this context, processes are referred to as business processes.

If the community involved belongs to the same organization, business processes are usually inspired to a centralized perspective: they present the viewpoint of a central authority having the power of distributing the work to the members of the organization. A business process is then a global model of work, i.e., a centralized description of the units of work (called tasks or activities) to be carried out by the various members subdivided in roles.

Tasks fall into two categories: human tasks (also called user tasks) are those performed by human participants playing suitable roles (associated with the tasks), while automated ones are implemented by services.

In the context of Process-Aware Information Systems or PAIS (Dumas, van der Aalst & ter Hofstede, 2005), tasks are meant to operate on the business entities residing in the underlying information system, and they are carried out by participants through graphical user interfaces.

From a technological point of view, tasks and process descriptions need different implementation tools: process descriptions are handled by process engines, while tasks are mapped into enterprise application software. The contact point is provided by todo lists, through which participants receive work from the process engine.

As the tasks are developed separately from the processes, current notations and languages, e.g. BPMN (OMG, 2008) and BPEL (OASIS, 2007), consider business processes essentially as orchestrators of work, which accomplish this function by means of interactions with external tasks; it makes little difference if the interaction is directed to a human task or to an automated procedure. This approach, referred to as orchestration-oriented perspective, makes the representation more homogeneous but at the expense of handling human activities as a special case of automated ones. If people are involved, they are considered as service providers. Moreover, each interaction that logically takes place between two users, say, A and B, such as A asking B for the approval of a certain request, is mediated by the process and therefore it results in two sequential actual interactions, the first between A and the process and the second between the process and B.

What is missing from the orchestration-oriented perspective is that, in most cases, human work is cooperative and therefore human activities are not performed in isolation but in structured frameworks referred to as conversations (Winograd & Flores, 1986). Conversations are the basis of the language/action perspective or LAP (Weigand, 2006), which was proposed for the design of information systems and business processes.

An example of conversation is the one governing the approval of a purchase requisition (PR). It takes place between two users, denoted as requester and approver: the former is the initiator and the latter is the follower of the conversation. The requester starts the conversation by sending a PR to the approver, who evaluates the PR and sends it back to the requester with three alternative outcomes, i.e. “accepted”, “rejected” or “to be revised”. In the first two cases, the conversation ends, in the third one the conversation continues and the requester may withdraw the PR or submit a revised version. In the latter case, the approver is expected to re-evaluate the revised version and to provide the final outcome (“accepted” or “rejected”).

If user tasks are abstracted away, a conversation consists of a number of interactions organized in a control flow specifying their sequence. Interactions are defined in terms of three major attributes: name (embodying the interaction meaning, e.g. “request”, “acceptance” or “rejection”), direction (i.e. initiator-follower or follower-initiator) and the business entity conveyed by the interaction (such as a PR). If the business entities are left unspecified, what remains is the flow that characterizes a particular kind of conversation. This flow, referred to as conversation protocol, is a template which can be specialized by providing the actual types of the business entities exchanged.