Business Process Support Systems Research Articles

A study on the adaptive approach to technology-driven enhancement of multi-scenario business processes

PurposeProcess-oriented organizations are compelled to be innovative and continuously implement changes to meet customer requirements and gain a competitive advantage in accordance with the business process management approach. In the digital age, organizations develop business process support systems using agile methods and introduce adaptation skills in order to support their core business. Seamlessly integrating both practices into a coherent and practically applicable solution supporting multi-scenario processes infallibly remains a challenge. The paper aims to discuss these issues.Design/methodology/approachThe workshops identifying the key issues in an international capital group that consolidates facility management companies, as well as a related research review, have fueled a two-cycled Canonical Action Research (CAR) study.FindingsThe paper extends the current understanding of IT-enabled agility, proposing an adaptively improved infrastructure with a catalog of digital options that facilitates the composition of multi-scenario business processes.Research limitations/implicationsThe CAR was limited to the members of management board and the managers constituting the focus groups. The agile business process management (ABPM) model proposed focuses on adding novel functionalities/building new processes, leaving functionality lifecycle out-of-scope. ABPM empirical validation is limited to a single business/technical case.Practical implicationsReal-life solution for supporting dynamic business processes was delivered, as rigid IT solutions do not support quick assembly of customized business processes with abundant number of scenarios. The infrastructure enables composition of customer-tailored services based on re-usable digital options directory as well as enhances business process discrepancies/software bugs detection, reducing the cost of maintaining IT infrastructure for entire customer portfolio. A number of issues resulting from building IT solutions within a series of isolated projects with no coherent overall development strategy are mitigated.Originality/valueThe ABPM acts as a reference model for focusing on developing critical functionalities and limiting resources consumed by redundant features.

Structured Shared Spaces as a Basis for Building Business Process Support Systems: A Generic Model and Analysis of Examples

Though the concept of shared spaces had been known in Groupware and Computer Supported Cooperative Work (CSCW) for quite a while, it did not become popular until the arrival of the Internet and social software. Implicitly, the concept of shared spaces has penetrated many IT-areas, including the area of Business Process Management. Though shared spaces are used in many systems and tools, like Google Drive and Projectplace, there is a lack of research investigating this usage in a generic way. The article aims to fill this gap by introducing a generic model of a Business Process Support (BPS) system based on shared space that supports the comparison, analysis and design of BPS systems. In addition, the article goes in more details on one design issue – the structuring of shared spaces. This is done by analyzing and comparing two different BPS systems that exploit the concept of shared spaces, though implicitly. These systems use different approaches to shared space structuring. The first one organizes the information by grouping similar types of items without regard to the flow of activities in a business process, while the other organizes the information around groups of activities that are usually completed as a block. Which model to choose in a particular situation depends on the characteristics of the business process and its participants. In order to facilitate this choice, the article offers a number of guidelines derived from the experience of using the two BPS systems in practice. The article also discusses in what circumstances BPS systems with shared spaces are preferable to traditional workflow BPS systems.

Selected Topics in Management and Modeling of Complex Systems: Editorial Introduction to Issue 16 of CSIMQ

The 16th issue of CSIMQ presents four articles that cover a wide range of research topics. The topics of this issue start with psychological aspects of sustainable behavior change within organizations while new technologies are introduced into a company. The range of topics ends with the discussion of specific algorithms that allow entity clustering for Big Data analysis. The goal of these algorithms is the identification of different notations of references that refer to the same real-world object. This entity resolution is also called dedublication. Additionally, an approach for modelling enterprise architecture visualizations is discussed. It is used to specify and develop an architecture cockpit for a company from the financial sector. Within the range of topics is also a paper about the concepts of shared spaces as basis for building business process support systems. In the paper, a generic model is suggested that supports the comparison, analysis, and design of business process support systems.

Towards a Business Process Modeling Technique for Agile Development of Case Management Systems

A modern organization needs to adapt its behavior to changes in the business environment by changing its Business Processes (BP) and corresponding Business Process Support (BPS) systems. One way of achieving such adaptability is via separation of the system code from the process description/model by applying the concept of executable process models. Furthermore, to ease introduction of changes, such process model should separate different perspectives, for example, control-flow, human resources, and data perspectives, from each other. In addition, for developing a completely new process, it should be possible to start with a reduced process model to get a BPS system quickly running, and then continue to develop it in an agile manner. This article consists of two parts, the first sets requirements on modeling techniques that could be used in the tools that supports agile development of BPs and BPS systems. The second part suggests a business process modeling technique that allows to start modeling with the data/information perspective which would be appropriate for processes supported by Case or Adaptive Case Management (CM/ACM) systems. In a model produced by this technique, called data-centric business process model, a process instance/case is defined as sequence of states in a specially designed instance database, while the process model is defined as a set of rules that set restrictions on allowed states and transitions between them. The article details the background for the project of developing the data-centric process modeling technique, presents the outline of the structure of the model, and gives formal definitions for a substantial part of the model.

Enabling flexible location-aware business process modeling and execution

Business process management (BPM) has emerged as one of the abiding systematic management approaches in order to design, execute and govern organizational business processes. Traditionally, most attention within the BPM community has been given to studying control-flow aspects, without taking other contextual aspects into account. This paper contributes to the existing body of work by focusing on the particular context of geospatial information. We argue that explicitly taking this context into consideration in the modeling and execution of business processes can contribute to improve their effectiveness and efficiency. As such, the goal of this paper is to make the modeling and execution aspects of BPM location-aware, i.e. to govern and constrain control-flow and process behavior based on location-based constraints. We do so by proposing a Petri net modeling extension which is formalized by means of a mapping to colored Petri nets (CPNs). Our approach has been implemented using CPN Tools and a simulation extension was developed to support the execution of location-aware process models. We also illustrate the feasibility of coupling business process support systems with geographic information systems by means of an experimental case.

Design science in action: developing a modeling technique for eliciting requirements on business process management (BPM) tools

Selecting a suitable business process management (BPM) tool to build a business process support system for a particular business process is difficult. There are a number of BPM tools on the market that are available as systems to install locally and as services in the cloud. These tools are based on different BPM paradigms (e.g., workflow or case management) and provide different capabilities (e.g., enforcement of the control flow, shared spaces, or a collaborative environment). This makes it difficult for an organization to select a tool that would fit the business processes at hand. The paper suggests a solution for this problem. The core of the solution is a modeling technique for business processes for eliciting their requirements for a suitable BPM tool. It produces a high-level, business process model, called a "step-relationship" model that depicts the essential characteristics of a process in a paradigm-independent way. The solution presented in this paper has been developed based on the paradigm of design science research, and the paper discusses the research project from the design science perspective. The solution has been applied in two case studies in order to demonstrate its feasibility.

Controlling business process instance flexibility via rules of planning

The way of imposing a given level of flexibility in business processes depends on the means employed for controlling business processes. When a Business Process Support (BPS) system is used, the flexibility limits can be incorporated in it. Achieving flexibility when workflow management systems are used for support of business processes is widely discussed in the literature. The ways of achieving flexibility for other types of business process support is a much less studied topic. This paper discusses how a given level of flexibility can be imposed by a Business Process Support (BPS) system built based on the state-flow view on business processes. The flexibility is achieved by combining different kinds of rules of planning: obligations, prohibitions, recommendations and negative recommendations. The discussion is illustrated with the help of a simplified example already implemented in a BPS system called ProBis.

Business process flexibility through the exploration of stimuli

For organisations to survive and flourish in a changing environment, their business processes need to be flexible. Ashby's law of requisite variety applied to business processes postulates that a robust process needs to exhibit as much as variety in its responses as there are stimuli in its environment. An essential aspect of the design of a business process is to know to what stimuli it needs to respond to. In this paper, stimuli to the requirements of Business Process Flexibility (BPF) are examined. A classification framework is proposed to characterise the environmental stimuli. Using this framework, business process designers can visualise variations of the stimuli affecting the process. They can then consider if the Business Process Support (BPS) system would adequately manage the variations in the stimuli. The use of the framework is illustrated with the example of a university train ticket purchasing process.

On the architecture and form of flexible process support

AbstractThe ability of businesses to develop is frequently hampered by difficulties in changing underlying software systems. An example is the need to change when business partnerships are formed, or dissolved. This article is concerned with the architecture of business process support systems in the context of change, and particularly with the need for such systems to facilitate software change. The viable system model (VSM) is a cybernetic model of organisations that change. It provides an inclusive architecture in which both operational and development components are described within an organisation. This article illustrates, through a business supply chain example, the use of the VSM as an architecture for flexible process support systems. This architecture is systemic and inclusive: it incorporates the ongoing development of both the business and its underlying software. Copyright © 2006 John Wiley & Sons, Ltd.

Defining business process flexibility with the help of invariants

AbstractEnterprise survival is about maintaining an identity that is separate from other enterprises. We define flexibility as the ability to change without losing identity. The identity of an enterprise can be analyzed as a set of norms and beliefs about these norms held by its stakeholders, such as customers, employees, suppliers, and investors. Business processes and their support systems maintain invariants that are the result of compromises between the often conflicting norms and beliefs of these stakeholders. We formalize these invariants as values in a state space. Identifying a minimum set of invariants provides a basis for defining flexible processes and support systems. We illustrate the use of this framework with production business process support (BPS) systems. Copyright © 2006 John Wiley & Sons, Ltd.

Aligning people to business processes experience report

AbstractBusiness process orientation requires some kind of a business processes support system. However, building a proper system is not enough for introducing process orientation, the organization should ensure that the system is routinely used by all people involved in the processes. The latter task may be more complicated than the one of building the system. This article summarizes an experience of building business process support systems and introducing them into operational practice acquired over some period of time. The article describes and explains difficulties related to the marketing of such systems and introducing them into operational practice, and gives examples that show how these difficulties could be overcome. In conclusion, it suggests an approach to introducing business process orientation, called a ‘reverse’ evolutionary approach, which could be suitable for some business contexts. Copyright © 2005 John Wiley & Sons, Ltd.

Scope analysis: identifying the impact of changes in business process models

AbstractOrganizations often change their business processes in reaction to changes in the environment or as a result of improvement efforts. These changes lead to adjustments in the Business Process Support (BPS) system. The impact of a change in a business process may extend beyond the specific point that has been changed, affecting preconditions required for other activities, outputs to be created, or requiring new inputs. This article introduces a concept of a scope of a change, whose identification facilitates focused efforts when adjusting the BPS system to changes in business processes. The article presents a taxonomy of modifications that can be made to a process model and characterizes different modification types in terms of possible scopes of the changes made. Copyright © 2005 John Wiley & Sons, Ltd.

Capturing design rationale with functional decomposition of roles in business processes modeling

AbstractEnterprises need to create and maintain the fit between their business processes and their business process support (BPS) systems. This frequently requires re‐engineering of business processes. If the business processes' design rationales are made explicit, the re‐engineering of the existing business processes is easier. Making the design rationales explicit is useful to understand why things exist as they are, and to understand if and how they can be changed.The most common way to capture design rationales is to list the design decisions underlying the business process. In the method proposed in this publication, we capture design rationales through role modeling. We document the design rationales for each role in the analyzed business process. The roles are described as the compositions of ‘base functionalities’. A base functionality is the specification of a role (or of a part of a role) from the viewpoint of one of the specific specialists who designs the business process. These base functionalities are composed together to describe the roles of the participants to the business process. As a result, a business process modeler can understand who is responsible for what in the business processes. In collaboration with the specialists, the business modeler can then ensure that no important part of the business process is missing or is unnecessary. Owing to this work, the business process can be verified before being automated with the BPS system. Copyright © 2005 John Wiley & Sons, Ltd.

Coordinated development of business processes and their support systems

Traditional RE for business applications mainly concerns creating requirements for a software system based on business needs. For the past ten years, requirements on functionality of business applications have been slowly changing. The shift consists of moving from the command-based applications to the applications of workflow and groupware type. The difference between the traditional applications and the new generation is that while the former supports the execution of certain activities, e.g., to write a letter, to print an invoice, to complete a transaction, the latter supports the whole business process (BP). A business process support (BPS) system provides the possibility to run a business in a new, process-oriented way, a way which is more effective and efficient but which is not possible to introduce without a BPS system. This, in turn, demands to consider not only the requirements the business imposes on the system, but also the requirements the system imposes on the business. In the broader context, the focus of the development project should be shifted from the software development to coordinated development of business processes and BPS systems. The goal of a co-development project can be formulated as creating and maintaining the fit between business processes and support systems. This implies a parallel evolution of the business and its BPS system as a reaction to changes in the business environment as well as to ‘‘revolutions’’ in the information technology. While the need for alignment of business processes and their support systems has been emphasized and discussed, there is a great need for systematic approaches and tools for achieving it. The aim of this special issue is to fill the gap between the practical needs of co-development and the state of the theory and methodology of systems development, in general, and requirements engineering, in particular. This issue is a follow-up of the discussions at the Fifth International Workshop on Business Process Modeling Development and Support (BPMDS’04, Riga, Latvia), co-organized by the guest editors of this special issue; see http://www.ibissoft.se/events/bpmds04/bpmds04.htm for details. The five papers presented in this special issue were carefully selected from 13 papers initially submitted to it. The selected papers went through a number of revisions based on the reviews and guest editors’ comments. We hope that the resulting set represents a step forward in the direction of filling the above-mentioned gap. Below, we shortly overview the papers presented in the special issue. In order to properly discuss relationships between business processes and BPS systems we need to understand more clearly what a BPS system is, how it could be differentiated from, and how it is connected to all the other systems in the jungle of software that exists or might exist in an organization. The proper way of getting such understanding is by matching an organization as a whole (in all its richness) to a set of supporting tools and systems. This is what Jan L.G. Dietz and Antonia Albani describe in their paper. The analysis is done based on the W -theory that differentiates three interrelated levels within organizations. These organizational levels require different kinds of computer support that should be integrated. Based on the suggested theory, the paper gives some recommendations for an overall strategy of support systems’ design. Maintaining the fit between business processes and support systems presumes that we can measure the level of fit (or misfit) between the two. Otherwise, how would we know when it is time to begin a redesign iteration to adjust the system to the processes or the processes to the system? Is it possible to measure the fit in a quantitative way, or can it be expressed in a qualitative way only? A significant portion of the submissions to this special issue addresses the topic of evaluating and assessing the fit G. Regev (&) Ecole Polytechnique Federale de Lausanne (EPFL), School of Computer and Communication Sciences, 1015 Lausanne, Switzerland E-mail: gil.regev@epfl.ch

Basic notions regarding business processes and supporting information systems

In order to achieve and maintain an optimal fit between business processes (BPs) and business process support systems (BPSs), both need to be understood thoroughly and coherently. Moreover, to benefit fully from the potentials of modern information and communication technology (ICT), the deep structure that lies behind the surface structure of BPs should be understood. The Ψ-theory, which is only summarized in this paper, provides the basis for such an understanding of BPs and BPSs as well as for some other basic notions. In particular, the notions of design and engineering and of architecture and ontology will be addressed. The conclusion is that these notions can consistently and coherently be related to each other, on the said theoretical basis, such that the concurrent (re)design and (re)engineering of BPs and BPSs can be performed more effectively.

The Process Interchange Format and Framework

This document provides the specification of the Process Interchange Format (PIF) version 1.2. The goal of this work is to develop an interchange format to help automatically exchange process descriptions among a wide variety of business process modelling and support systems such as workflow software, flow charting tools, planners, process simulation systems and process repositories. Instead of having to write ad hoc translators for each pair of such systems each system will only need to have a single translator for converting process descriptions in that system into and out of the common PIF format. Then any system will be able to automatically exchange basic process descriptions with any other system. This document describes the PIF-CORE 1.2, i.e. the core set of object types (such as activities, agents and prerequisite relations) that can be used to describe the basic elements of any process. The document also describes a framework for extending the core set of object types to include additional information needed in specific applications. These extended descriptions are exchanged in such a way that the common elements are interpretable by any PIF translator, and the additional elements are interpretable by any translator that knows about the extensions. The PIF format was developed by a working group including representatives from several universities and companies, and has been used for experimental automatic translations among systems developed independently at three of these sites. This document is being distributed in the hopes that other groups will comment upon the interchange format proposed here, and that this format (or future versions of it) may be useful to other groups as well. The PIF Document 1.0 was released in December 1994, and the current document reports the revised PIF that incorporate the feedback received since then.

Linking Information Services to Business Strategies

Cet article presente une methode pour reinventer les services d'information en creant des liens entre la gestion des services d'information et les strategies d'entreprise, et ceci a tous les niveaux : le marketing, le distribution, la production, l'administration et le financement. Les role professionnel du professionnel de l'information dans cette reorgnisation est souligne