People-Oriented Enterprise Information Systems

Introduction

Enterprise Information Systems (EISs) were first conceived as systems providing a repository for business entities and enabling users (subdivided into appropriate roles) to handle such entities. Then the process-oriented approach (Dumas, van der Aalst, & ter Hofstede, 2005) has pointed out that business purposes are achieved through coordinated work to be carried out by means of two kinds of activities: user tasks and automatic procedures. User tasks are units of work that users carry out with the help of a graphical interface in order to achieve a particular purpose. Placing a purchase requisition or filling in the review form for a conference paper are examples of user tasks. Automatic procedures, instead, accomplish their function without requiring any human intervention.

However, as the activities are developed separately from the processes, current notations and languages, such as BPMN (Object Management Group, 2008), XPDL (Workflow Management Coalition, 2007), and BPEL (OASIS, 2007), consider business processes essentially as orchestrators of work, which accomplish this function by means of interactions with external services; it makes little difference if the interaction is directed to a user task or an automatic 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 automatic procedures. 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 (Weigand, 2006), or LAP, which was proposed for the design of information systems and business processes. According to LAP, EISs are mainly tools for coordination.

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, that is, “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, for example “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 that can be specialized by providing the actual types of the business entities exchanged.

Several modeling approaches based on LAP have been proposed (a short survey is given in the next section); however, they mainly focus on the nature of the underlying interactions and do not provide an adequate solution to the integration of conversations and business processes. This integration is a major purpose of this chapter, which proposes a notation called POBPN (People-Oriented Business Process Notation) and a perspective referred to as conversation-oriented perspective.