How to compose
an Object-Oriented
Business Process Model?1
Peter K UENG,Peter K AWALEK
Informatics Process Group (IPG), Department of Computer Science, University of Manchester, UK
e-mail: {kueng | kawalek}@cs.man.ac.uk
www.cs.man.ac.uk/ipg/index.html
Peter B ICHLER
Data & Knowledge Engineering, Department of Information Systems, University of Linz, Austria
e-mail: bichler@dke.uni-linz.ac.at
IPG: Working Paper January 1996
1.A modified version of this Working Paper will be presented on the IFIP Working Conference on Method Engi-
neering and published in: Brinkkemper, S. et al. (Eds.): Method Engineering. Proceedings of the IFIP WG8.1/ WG8.2 Working Conference, Atlanta, 26-28 August 1996. Chapman & Hall (to appear).
How to compose an Object-Oriented Business Process Model?
Peter Kueng1, Peter Bichler2, Peter Kawalek3
Abstract
When modelling business processes, we have to address four key elements: On a conceptual level, we have to define Goals,Activities, and Roles. On a pre-implementation physical level we have to define Objects. In this paper, we examine step by step how business processes can be modelled, which data are needed for each step and which result would be produced during each step. Furthermore, we suggest that most object-oriented modelling methods do not pay enough attention to the process of eliciting relevant objects.
Contents
1.0Introduction (2)
2.0The state of the art (2)
3.0Key elements concerning business process modelling (4)
4.0Modelling of goals (6)
5.0Modelling of activities (7)
6.0Modelling of roles (10)
7.0Object modelling (12)
8.0Summary and future work (14)
9.0Bibliography (15)
1.kueng@cs.man.ac.uk; Informatics Process Group, Department of Computer Science, University of Manchester, UK
2.bichler@uni-linz.ac.at; Data & Knowledge Engineering, Department of Information Systems, University of Linz, Austria
3.kawalek@cs.man.ac.uk; Informatics Process Group, Department of Computer Science, University of Manchester, UK
1.0  Introduction
Today, many organizations undertake fundamental change programmes with the aim of improving their market competitiveness. Typically, the main challenges they confront are the reduction of cycle time, decreasing overall costs, and the improvement of customer satisfaction. In pursuit of such benefits the organization may seek to adapt or design processes with the aim of simplification, better control or the ready availability of information relating to the state of extant business cases. These changes are often accompanied by increased dependency on complex and heterogeneous software systems. Against this background it is not surprising that more and more enterprises establish new workflow systems for which they aim to prove coherent support of their business processes. While the demand concerning business process related software and development methodologies has reached a considerable level, the supply side is still rather patchy. Commercially available workflow
management systems are only now evolving beyond a rather overly simple, Taylorist, production-line metaphor and empirically proven methodologies for modelling and implementing business processes do not exist, cf. [Swenson/Irwin 95].
The rest of the paper is concerned with the presentation of a modelling approach. It is a contribution to the existing approaches. It focuses upon the notion of a goal. The hypothesis is that the modelling of behaviour (e.g. a business process) is best understood as purposeful, and can be described through goals. This work has been developed at the University of Linz and shall be progressed in collaboration with the University of Manchester. The paper is organized as follows: Section 2 gives an overview to today’s business process modelling approaches. Section 3 gives a short introduction to a business process, showing how a system development life cycle could look like and how our goal-based modelling process is embedded. Section 4 shows how both enterprise-wide and business process-related goals can be modelled. In Section 5, we use a case study to transfer goals into activities and explain how logical dependencies between activities can be visualised. Section 6 presents and applies the concept of roles. In section 7, our example will be transformed into an object-oriented model. Section 8 concludes with a summary and an outlook on additional issues to be addressed in our research.
The case study considers an insurance company with offices throughout Europe. The investigators spoke to commercial underwriters and administrators in the London headquarters and local office. Compared to other insurance sectors (e.g. motor policies, home insurance), the commercial sector is low volume and highly labour intensive. Underwriters receive submissions from brokers which describe major risk proposals (e.g. all the factories of a multi-national manufacturer). To process a single submission can be time-consuming. It is likely to involve many interactions with the broker and within the insurance company itself (e.g. between underwriters and administrators). The case study took place with the company in a phase of expansion.
2.0  The state of the art.
To date several methodologies have been proposed. They can be grouped into four broad categories: Activity-oriented approaches: As the name implies, activity-oriented approaches focus primarily upon activities (sometimes referred to as tasks). The flow of information, the involved organizational units, and data are either not considered or are understood in the context of the description of activities. Activity-oriented approaches are well suited to high level process description. At a lower level they are used for simulation, e.g. estimating of cycle time. There are many activity-oriented approaches, e.g. Information Control Nets [Ellis/Nutt 80], Trigger Modelling [Joosten 94], Ev
ent-driven Process Chains [Scheer 94]. Taking into account that the aforementioned methods differ from each other, criticism can be only fragmentary:
•Activity-oriented approaches generally offer good support to the process of refinement. However this may encourage too much attention to be paid to the detailed process structure and too little to the main structure of the business process.
•Activity-oriented approaches tend to define a business process as a specific ordering of activities.
This mechanistic view may fail to represent the true complexity of work, and may lead to the failure of the implementation of a new business process.
Object-oriented approaches: The principles which we associate with object orientation, for example encapsulation and specialization, may in various ways be a part of other approaches (e.g. activity-oriented approaches, role-oriented approaches). The well known object-oriented methods (e.g. [Booch 94], [Embley et al. 92]) are widely used for designing and implementing software systems. It seems obvious that the principles of object orientation be applied to business process modelling. Are the techniques, in their current form, adequate for business process modelling? Not fully, because:
•If the focus is only upon objects - describing structures and methods - the objectives of the business process may not be considered.
•Business processes are not designed by information systems specialists but primarily by process owners or their team members. [Kawalek 95] has observed, that if you ask these people how a certain business process operates, they will give a description of activities. In other words: process owners and team members describe their work through activities rather than objects.
•Most object-oriented methodologies apply object interaction diagrams. In these diagrams we can identify the concept of roles. The weakness of this approach is that the assignment of roles is done normally as a minor matter. If roles are important to us then perhaps we need to give more attention to their assignment.
Role-oriented approaches: Probably the best known role-oriented technique is the Role Activity Diagram (often called just RADs) [Ould 95]. The origin of the technique lies with the modelling of coordination by [Holt et al. 83]. The concept of ‘role’ is obviously central and yet is rather loosely defined. Ould suggests that a role “... involves a set of activities which, taken together, carry out a particular responsibility or responsibilities” [Ould 95, p. 29]. To Halé a role is “The position played in a
object toprocess by an individual, team or unit” [Halé 95, p. 237]. Given these broad definitions we can describe many things as roles, whether they be whole job descriptions (e.g. administrator), parts of work activity (e.g. make expense claim) or sub-parts of that activity (e.g. calculate expenses). It follows that roles are conceptually similar to modules. They allow a grouping of primitive activities which can then be assigned to a particular person or agent. [Kawalek 95] argues that the strengths of RADs lie with their ability to express this modularity of work through roles and the synchronisation between these roles. Essentially this means that through a role-oriented approach we are able to describe process behaviour at different levels. We can describe the co-ordination between roles and demarcate this from our concern for the co-ordination within roles. RADs are increasingly popular, especially within the UK. They seem to have many strengths but also some weaknesses, for example:
•RADs are not very suitable if it is important to express an intricate sequencing logic. For example, it can be difficult to express behaviours where two activities can be carried out alternatively. It is still more difficult a behaviour where the sequence of two or more activities is undefined except for the fact that they cannot be carried out concurrently.
Speech-act oriented approaches: Speech act theory was mainly created by Austin and his student S
earle, cf. [Winograd/Flores 86, p. 58]. Further development, under the label “Language/Action Perspective” were made by Winograd, Flores and Medina-Mora, cf. [Medina-Mora et al. 92]. The underlying concept behind Language/Action Perspective is the so called “ActionWorkflow Loop”: In each communication process (workflow) we can distinguish between a customer and a performer. The communication process itself consists of a four-phased loop: proposal, agreement, performance, and satisfaction. The speech-act approach is novel, interesting and potentially very significant. From various sources (e.g.[Agostini et al. 94]) empirical examples of its use are being assembled. What are the current limitations of speech-act oriented approaches?
•Carrying out business cases is always seen as a communication between a customer and a performer. The model doesn’t take into account several parties. Furthermore it is not always obvious which part is customer and which is performer. In different business cases they can have a different behaviour.
•It is not clear whether speech-act oriented approaches are primarily dedicated for analysing existing processes or for creating new processes. In the former case, a speech-act oriented approach could help to “... identify various types of breakdowns in the workflow” [Yu 95, p. 228]. In the case of creating new processes, this approach doesn’t provide much help: neither does it help to find adequa
te roles nor does it help to identify activities for supporting given goals.
As a broad conclusion concerning the aforementioned approaches, it seems that today’s business process modelling approaches are still immature. There could well be a viable synthesis of approaches in the future. Such a synthesis would have to address three things: First, it would have to look broadly at business processes and appreciate the relationship between the operational behaviour and managerial co-ordination, control, development and policy [Beer 79]. Secondly, it would need to describe the process of modelling. Thirdly, developing the previous point, they need to describe what kind of infor-mation has to be input to a methodology and is output from its application. In this way we would be able to select methods in an contingent way according to the circumstances of our modelling project.
3.0  Key elements concerning business process modelling
Generally speaking, a model highlights certain aspects of the real world and omits others. What does this mean with regard to the subject of business processes? According to [Davenport 93] and [Hammer/ Champy 93] a business process can be characterised by five elements: (1) a business process has customers; (2) a business process consists of activities; (3) these activities create value
for the customer; (4) activities within a business process are carried out by humans or machines; (5) business processes often involve several organizational units; that means more than one organizational units are responsible for a whole business process.
How are these aspects interrelated? As a core element of a business process model we have business cases, which are instances of a business process. Business cases have to be carried out. That means fulfilling business goals and satisfying stakeholders. Business cases are composed of activities (sometimes referred to as functions or working steps or tasks) which can be further decomposed into subactivities. Activities within an office environment need information as input. That input has to be provided by an information producer. Activities also produce an output which will be delivered to the customer, probably the most important player within a business process. Activities have to be carried out by roles.
Creating and implementing new business processes is a highly complex task. There are still few empir-ically established examples. Furthermore it is difficult to appreciate the most important requirements at the beginning of a project. It is effectively impossible to estimate if the proposed process model would lead to the desired state.
In order to reduce these problems we propose to apply a cyclic stage model. Figure 1, which includes ideas from[Floyd et al. 89] and[Hammer/Champy 93], shows that the development and implemen-tation of a business process is made up of several activities: First of all, an enterprise-wide strategy -which describes the enterprise-wide as well as the future product and service portfolio - has to be developed. After that, the business process(es) have to be modelled; an activity we describe in detail later. Subsequently the modelled business process has to be verified and validated.1 Whereas verifi-cation is usually done by formal methods, validation may efficiently be carried out by prototypes.
1.“Verification checks if the product which is under construction meets the requirements definition. (...) V alidation checks if
the product’s functions are what the customer really want” [Sommerville 92, p. 8].
Prototyping allows potential users to judge if the system is adequate or not. After several iterations the business process model has to be transformed into an executable system. For doing this we can use either a workflow management system or we can do it in a traditional way, e.g. coding a C++ appli-cation. If an executable program has been created we have to implement it in a designated env
ironment.Generally speaking, implementation means developing a plan that addresses the organization of change. On the organizational side this may include transformations concerning hierarchy of management, incentives, performance measurement, job description, job changes, skills, and training.After successful implementation the system goes into the stage operation. After a not a-priori definable duration in the Operation phase, process goals will change and this leads to a new development cycle.Furthermore customer needs, overall policies or profitability of certain activities may change - and as a result, business processes or part of them may be outsourced.
Figure 1: The system development life cycle
Figure 1 shows that the mentioned steps of a system development life cycle are surrounded by project management. It is a ongoing activity and defines some key elements which affects the success of a
Project
management

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。