3. The Integrated S-BPM Process Model

Subject-oriented business process management does not only include the opportunity to transfer information expressed in natural language with minimal effort into a model. It also allows a continuous change of business processes in a structured way. The S-BPM method itself is subject-oriented, with actors (subjects) at the focus. In the following, we explain the coordinated S-BPM activity bundles (predicates) that are executed by the respective actors. The object in S-BPM is the process itself. In this way, the S-BPM process model can be fully specified by its inherent elements and logic of description. This self-referentiality reflects the consistency of the approach.

First, we introduce the process understanding required for S-BPM. We then address the importance of S-BPM for organizations and introduce the various S-BPM stakeholders and activity bundles. Thereafter, the methodological framework of S-BPM is detailed. And finally, we show the multiple integrated nature of S-BPM.

The concept of processes for S-BPM is consistent with the concept commonly used to define business processes in traditional BPM (cf. Becker et al. 2008, p. 6; Schmelzer and Sesselmann 2010, p. 61ff; Fischermann 2006).

We therefore understand a business process as a set of interrelated activities (tasks), which are handled by active entities (people or systems performing work tasks) in a logical (with respect to business) and chronological sequence, and which use resources (material and information) to work on a business object for the purpose of satisfying a customer need (to thus contribute an added value), and which have a defined start and input, as well as a defined end state and result.

Business objects as such are those objects, which are economically relevant for shaping the business and which include the communication relationships in the course of task accomplishment. In S-BPM therefore, those objects are considered which are relevant during the exchange of messages between subjects, and which are also relevant for the individual activities of the subjects.

S-BPM is driven by several active roles. Governors (people caring for, taking responsibility for, or driving processes) create the conditions under which Actors operate. These Actors manage work tasks, and in doing so, cooperate with specialists (Experts) when needed. Governors are also responsible for organizational development. The respective stages of development are supported by Facilitators, who again involve Experts where needed. S-BPM does not require a hierarchical structuring of these actors and in turn does not require explicit management structures. It rather dissolves the classic distinction between business and IT people. Representatives from both areas can be found in all of the roles relevant for S-BPM.

The different activity bundles (cf. Schmidt et al. 2009, p. 52f) are the topic of main chapters following later. They are therefore just briefly described here:

The modeling of business processes is an essential part of business process management. In its basic features, it represents a traditional management process. When accomplishing its tasks, the management deals with business processes. Management activities are carried out along a feedback control cycle composed of the phases: analysis, modeling, validation, optimization, organization-specific implementation, IT implementation, operation, and monitoring. The phases follow the logic of BPM, whereby information about business processes and their design is accumulated progressively during cycle time.

The S-BPM activity bundles correspond to a great extent to these management activities of traditional BPM approaches. However, in contrast to traditional BPM approaches, as a rule they are not necessarily performed sequentially. We therefore speak of an open feedback control cycle, driven by people in the S-BPM roles that we have identified in Sect. 3.3 (see Fig. 3.1). The S-BPM activity bundles can be performed in the logic of S-BPM along a complete organizational development step as described is Sect. 3.4. However, the sequence of execution may also differ from this linear procedure. A nonlinear sequence is triggered by events in the individual activity bundles requiring such different paths, as detailed in the respective subchapters.

In BPM practice, the activities of the bundles, or even bundles out of the cycle, often cannot be clearly distinguished from each other. Quite often, organizations move back and forth between them without disruption. For instance, in case stakeholders identify ambiguities during the modeling of the process, they could switch to an upstream process step and consult the stakeholder involved in that process step for analysis. Once the issue is settled, they continue modeling their process. During the validation, the involved stakeholders can recognize obvious potential for optimization, embody it in their current model, and validate it again.

In this way, activity bundles are iterated and the process is enriched successively with information, until the process specification is complete and sufficiently detailed to meet the project target. Stepping back to a previous activity always leads to an analysis state, and, depending on the results of this analysis, back to another downstream activity bundle. This applies in particular to the feedback from monitoring activities. When modifications of the model follow, each downstream activity bundle after modeling has to be completely performed subsequently. Otherwise, it is possible to skip steps. For instance, when process owners recognize during monitoring a negative deviation from a target value, they initiate a causal chain analysis. In case this analysis results in recognizing a lack of work force handling the particular case, this deficiency can be removed through another organizational implementation of the process (simply by providing additional work force), without having to change the process model itself. There are no further steps required. If the process owner concludes from the analysis that extensive throughput times are caused by lacking possible parallel execution of process steps, the model needs to be modified and revalidated. In this case, the implementation of the process into the organization and the IT infrastructure (organization-specific implementation) needs to be reviewed according to the modified model, and adapted where required.

Which bundles of activities are executed iteratively depends on the purpose of each project. In case only the process documentation is concerned, e.g., for certification within quality management, modeling and description of the current processes are sufficient.

Before detailing the various S-BPM bundles of activities in distinct chapters, let us clarify the conditions under which the activities are performed, and also how these activities are affected by those conditions.

Business process management based on the described bundles of activities is not independent of its environment in an organization. It is embedded in organizational frameworks that are designed primarily by Governors. Figure 3.2 provides an overview of various framework conditions, the Governors typically responsible for these conditions, and the affected activity bundles (see Fig. 3.2). Then, we detail the main framework conditions of S-BPM.

S-BPM is a methodology that enables integration in multiple ways in an organization. In order to demonstrate this capability, we first consider the business and technical aspect of S-BPM—two dimensions which traditionally allow the term Business Process Management to be grasped (BPM) (cf. Bucher and Winter 2009, p. 6; Becker et al. 2009, p. 3; Schmelzer and Sesselmann 2010, p. 5). The original exclusive economic point of view refers to an integrated management approach for documentation, design, optimization, implementation, control, and further development of management, core, and support processes in organizations. It is intended to meet the needs of stakeholders, especially to satisfy customers and to achieve business objectives.

Moreover, the term BPM in science and industry is also often associated with its technical dimension of IT support of business processes. This ranges from tools for documenting and modeling of processes, to workflow engines for the execution of process instances while using functionalities of application software (such as services of an ERP system), to business intelligence applications to evaluate the performance of processes. Solutions with a high degree of coverage of these aspects are referred to as Business Process Management Systems (BPMS) or, preferably by software vendors as business process management suites. An example of such is the Metasonic Suite, which already covers the modeling and validation of process specifications based on executable models.

S-BPM integrates the business and technical point of view by focusing on business processes from the perspective of all stakeholders. It provides them with a tool, which enables them to express their respective views of these processes effectively and efficiently. S-BPM is a role-centric and communication-centric tool for the development of organizations. Unlike other BPM approaches, it does not put the development of functional processes in the foreground, but rather the parties involved, i.e., the subjects and their interactions. Thus, development is equally enabled on both the organizational and personal level.

The organizational aspect of work does not only come to bear from the technological operational perspective, but rather already when dealing with the respective work profiles, in the context of which stakeholders in the operational business ultimately need to be supported by information technology. In S-BPM, subjects determine the roles of Actors that are relevant to the achievement of organizational objectives. Subsequently, their respective behavior is defined, and synchronized through the exchange of messages when performing tasks.

Unlike many BPM approaches, a model developed with S-BPM is directly executable. This means that in each step of development, models can be processed without further transformation. Thus, for the first time, a coherent development process based on subject-oriented modeling can be established (seamless round-trip engineering). With this approach, modeling and implementation can be directly interconnected.

In addition, the S-BPM process model comprises a procedure that allows the dynamic integration of activity bundles with each other. Going beyond classical life cycle approaches, parallel and branched activities can be triggered—depending on what is currently required according to the business process. Feedback between the activity bundles can occur, which leads to successive transitions, not only forward and backward between business logic states, but also skipping intermediate states.

Finally, S-BPM itself can be described in a subject-oriented way using the available tools. The item to be represented in a model, i.e., the process, can be grasped by using subject–predicate–object descriptors (i.e., modeling), just as the process of developing a process model itself can be described by using subject–predicate–object sequences (see Fig. 3.1). The core is the modeling process, which is embedded in an organization-specific development process based on modeling.