Abstract not found

Contemporary business process systems are built to automate routine procedures. Automation demands well-understood domains, repetitive processes, clear organisational roles, an established terminology, and predefined plans. Knowledge work is not like that. Plans for knowledge intensive processes are elaborated and reinterpreted as the work progresses. Interactive process models are created and updated by the project participants to reflect evolving plans. The execution of such models is controlled by users and only partially automated. An interactive process system should - Enable modelling by end users, - Integrate support for ad-hoc and routine work, - Dynamically customise functionality and interfaces, and - Integrate learning and knowledge management in everyday work.

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.

Whatever their role, office workers are involved in two types of activities: either they are doing some task on a predefined routine, or they are inter-acting with each-other (communicating) to deal with an exceptional situation, i.e., they have to solve a problem they or their colleagues have encountered.

Large software systems have a large number of components and are developed over a long time period frequently by a large number of people. We describe a framework approach to evolving such systems based on an integration of product and process modelling. The evolving system is represented as a Product Tower, a hierarchy of components which provides views of the product at multiple levels of refinement. The evolution process is component based with the cooperation between components being mediated by the Product Tower. This ensures that the evolution process is scaleable and that it maintains, and evolves, the design model. We illustrate our approach with an example, outlining an evolution both of the product and of the process. The reflexive facilities of the process are shown to be key in ensuring the framework's ability to evolve. Keywords: product evolution, process evolution, process modelling, design hierarchy 1 Introduction Modern large software systems are systems which: ffl ...

The Petri net formalism, due to its graphical modeling support and profound mathematical background, has been successfully used in the analysis of systems that obey concurrency, synchronization, mutual exclusion and nondeterminism. Computerized tools supporting the model development process and automating the analysis are available today. In this work we propose the tool supported analysis of business workflows represented by Petri net models with stochastic transition timing. Qualitative analysis by applying well developed techniques allows to answer questions related to behavioral properties of the workflow system. Performance characteristics obtained from quantitative analysis can be used for workflow performance tuning, business process reorganization and throughput optimization. 1 Introduction Analysis and modeling of information systems in business organizations has traditionally focused on data objects, data flows and the transformation of data. With this approach however, only...

: The focus of Business Process Reengineering (BPR) on the process concept puts forth the need for consistent methods and techniques for the capture, representation and performance assessment of business processes. In addition, Information Process Reengineering (IPR), i.e., the analysis of how to use legacy and new information systems to automate and support the reengineered business processes, requires the development of information process models, that are consistent, transparent and coherent with the business process models. Although the object-oriented approach seems to be the most suitable for a common process modelling scheme, it lacks significant attributes that would model the specificities of the business domain. In order to tackle this problem, the present paper develops a coupled modelling framework, that integrates an object-oriented method (Object Modelling Technique, OMT) and a business workflow analysis method (Action Workflow Analysis, AWA). The application of the framework to a banking case-study proves its usefulness and practicality. KEYWORDS: Business process reengineering, information process reengineering, workflow analysis, objectoriented software development

This paper discusses links that may be made between process models and UML software specification techniques, working from an argument that the whole complexity of organisational activity cannot be captured by UML alone. The approach taken is to develop a set of use cases which would be capable of providing information support to a pre-defined organisational process. The nature of the thinking which is necessary to derive the use cases is outlined, using the pre-defined process as a case study. The grouping of transactions and state changes into Use Cases is shown to require design choices which may vary between particular organisational contexts. Conclusions are drawn about the direction of further investigation of links between process modelling and UML. Keywords: Process Modelling; UML; Use Cases; Business Modelling. 1.

. This paper documents some of the work involved in describing the ISPW-6 process example in terms of graphical models and in terms of a modelling and enactment language PML. It further describes experiences in instantiating this model in ICL's Processwise Integrator support system, and outlines the lessons learnt and directions for future work. 1 Introduction There are numerous technologies, in various states of development, which attempt to support the software process. It is not an easy matter to make comparisons between technologies; not only because of the variety of approaches but also lack of a familiar and comprehensive model on which to base comparisons. In order to remedy this state of affairs, the ISPW-6 [7] example process was formulated. This was developed at the 6th International Software Process Workshop, and hereinafter will be referred to as the ISPW-6 Example, or simply as the example process. After a very brief introduction to the enactment technology, the work of m...

. Coordination theory is an interdisciplinary approach to studying the management of dependencies among activities. By its very nature software process technology deals with coordination. However it often expresses coordination in terms of low level details. An effective coordination theory would give us a better set of coordination abstractions. We illustrate the close relationship between these fields and propose areas where they could learn from each other. 1 Introduction Coordination theory is the term used by Malone [9] to refer to the interdisciplinary study of coordination. It draws on a variety of different disciplines including computer science, organisation theory, management science, and economics. In these disciplines there are a variety of coordination problems and a range of solutions have been evolved to cope with them. One aim of coordination theory is to provide a language which can describe coordination problems and solutions in a way which allows them to be compared...