09:00-09:15 Presentation of participants
09:15-09:50 Introductory note by Gil Regev. Why Do We Need Business Process Support? Balancing Specialization and Generalization with BPS Systems. Abstract Full text Slides
09:50-10:25 Presentation by Stewart Green. Eliciting Stakeholders' Knowledge of Goals and Processes to Derive IT Support Abstract Full text Slides
10:25-11:00 Presentation by Niko Kleiner. The Focus of Requirements Engineering in Workflow Application Development Abstract Full text Slides
11:00-11:30 Coffee break
11:30-12:05 Presentation by Peri Loucopoulos. The S3 (Strategy-Service-Support) Framework for Business Process Modelling Abstract Full text Slides
12:05-12:40 Presentation by David Wynn. Planning business processes in product development organizations Abstract Full text Slides
14:00-14:45 Discussion of questions raised by Ian Alexander. Are There Requirements for BPS? Abstract Full text Slides
14:45-15:30 Discussion of questions raised by Ilia Bider. Business Process Support - from initial analysis to introduction in the operational practice. Obstacles to overcome. Abstract Full text Slides
15:30-16:00 Coffee break
16:00-16:45 Discussion of question raised by Elke Hochmüller. Identifying Types of Extra-Functional Requirements in the Context of Business Support Systems Abstract Full text Slides
16:45-17:30 General discussion
18:30- ..:.... Social event, some kind of a dinner. When and where will be decided on the site.
Gil Regev, Alain Wegmann. Why Do We Need Business Process
Support? Balancing Specialization and Generalization with BPS Systems
Abstract: Businesses face a changing environment with an uncertain future. They need to specialize their business processes in order to become successful in the short term. This specialization, however, becomes a problem in the long term, when conditions change. A BPS system could help the business to achieve and maintain the balance between specialization and generalization.
Stuart Green. Eliciting Stakeholders' Knowledge of Goals and Processes to Derive IT Support
Abstract: Arguably the development of many organisational computer-based systems should start with an understanding of business processes and goals. Much of this knowledge needs to be elicited from business experts. Although experts can articulate some of the knowledge (explicit knowledge), unfortunately they are not able to articulate all of the knowledge that they possess (implicit knowledge). In addition there is some relevant knowledge which they probably do not possess (new knowledge). This paper presents four techniques for eliciting knowledge, two of which - an adaptation of Contextual Design and self-observation and measurement - are particularly useful for eliciting implicit and new knowledge. The cost of applying each technique and the particular utility of each are also discussed. A case study of a University Help Desk is used to illustrate the four techniques.
Niko Kleiner. The Focus of Requirements Engineering in Workflow Application DevelopmentAbstract: The paper discusses the focus of Requirements Engineering in workflow application development. It's core thesis is, that the workflow application and the new business process it supports emerge in parallel. As a conclusion, putting more effort into early development steps -- like initial business process modeling and analysis -- does not necessarily contribute to the project's overall success. Therefore, Requirements Engineering should shift its focus from specification of system requirements to its enactment in operational use. Assuming that one of the main reasons for introducing a workflow application is to help to drive business processes towards their goals,
detailed information about HOW users enact the workflow application and WHERE and WHY they deviate from the intended working style becomes more important.
To give a basis for a discussion, the paper presents a seven year project history and some recent results from organizational science. The project history solely exemplifies the findings. The results from organizational science support our project findings and serve as an initial theoretical model for further discussions and investigations. The paper also provides some arguments pro and contra the thesis.
Peri Loucopoulos. The S3 (Strategy-Service-Support) Framework for Business Process Modelling
Abstract: One of the central activities in developing requirements for business processes is that of modelling of the constituent parts of both existing and future processes. The field is dominated by approaches that focus their attention either on high-level management issues or alternatively on detailed operational aspects many of which have parallels with information systems development. This position paper examines requirements engineering issues for business processes in terms of the nature of the problem domain and of the development activities. The paper proposes a modelling framework which, in addition to the traditional treatment of modelling processes from an organisational support perspective, deals with strategic and service oriented issues.
David Wynn, Claudia Eckert, P John Clarkson. Planning business processes in product development organizations
Abstract: Business processes are difficult to plan successfully, and become more so with increases in complexity. However, certain types of business process are known to be more difficult to plan than others. One example is the process of product design, as followed during the development of physical artefacts for production. This form of process is highly complex, uncertain, and non-repeatable; effective methods for design process support must take these factors into account.
Ian Alexander. Are There Requirements for BPS?
Abstract: A huge amount of effort is consumed in modelling business processes, and then in developing and maintaining tools, documentation, and training courses to support the modelled processes. This discussion paper looks informally at the activities, costs, and benefits involved, and asks some simple and down-to-earth questions about the entire BPS enterprise. Why does it cost so much? Is it worth its salt? What does it deliver? Why do people believe in it? Is it relevant to business? Would other approaches be more effective?
Ilia Bider. Business Process Support - from initial analysis to introduction in the operational practice. Obstacles to overcome.
Abstract: There is an important difference between a traditional business application and a business process support (BPS) system. A traditional business application is aimed at supporting the old way of doing business but more effectively. A BPS system can be considered as a tool of introducing a new way of organizing work. Moreover, this way is often impossible to introduce without a support system. This difference affects all stages of system development, from initial analysis to introduction into the operational practice. For example, what are the best ways to discuss with domain expert a new way of organizing business before you have any system? In what way the user can recognize in the system the requirements created during the analysis phase? How much of the system should be initially introduced in operational practice so that the user can get a "feeling" of the new way of organizing business and accept it? A list of these, and other questions are being put forward for brainstorming.
Elke Hochmüller, Michael Dobrovnik. Identifying Types of Extra-Functional Requirements in the Context of Business Support Systems
Extra-functional requirements are known as critical success factors in traditional software engineering. While business process support systems and classical domain-specific application systems differ from the product point of view as well as from the perspectives of development and institutionalisation processes, the relevance of extra-functional requirements will even increase in case of BPS systems because of the tight relationship of such systems with the structures, responsibilities, and processes within an enterprise. This discussion paper aims at the identification of general types of extra-functional requirements which are most prominent in BPS systems.