Druckansicht der Internetadresse:

Faculty of Mathematics, Physics & Computer Science

Chair for Databases and Information Systems – Prof. Dr.-Ing. Stefan Jablonski

Print page

Process Science

Selected projectsContact person
Process Mining: Analysis of massive SAP process event log dataDr. Schönig
Process Modeling: Modeling of administration processes in healthcare serviceProf. Dr.-Ing. Jablonski
Process Modeling: Modeling and system support of university administration processesProf. Dr.-Ing. Jablonski

Research in Process Science

We are particularly interested in issues that prevent process management systems from being enacted broadly. Therefore, we concentrate our research on agile process management what deals with processes that show a high amount of variability.

Furthermore, with the BPM Round Table Bayreuth we provide a platform for knowledge transfer from academia to industry. The BPM Round Table is organized regularly where local companies are invited to participate.


C2P2 - Competence Center for Practical Process Management

The Competence Center for Practical Process Management translates latest research results in business process management into practical solutions for your enterprise. C2P2 was funded by Bayerisches Staatsministerium für Wissenschaft, Forschung und Kunst in the context of the EFRE program.

The C2P2 has developed out of the KpPQ (Kompetenzzentrum für praktisches Prozess- und Qualitätsmanagement), which was funded between 2012 and 2015 as an EFRE project by the Bayerisches Staatsministerium für Wissenschaft, Forschung und Kunst.

The major goal of C2P2 is to continue the successfull scientific and practical work of KpPQ. Fully in the tradition of the KpPQ our aim is to translate newest scientific results into practical solutions. Sustainable knowledge transfer from research to industry is our major vision. The focus of our work lies on modern approaches to process management that foster the application of this promising technology also in application domains that are characterized by flexible, i.e. agil processes. Modelling, analyzing and executing such agile processes is one of our focal points of interest.

Further information is available at www.kppq.de.


   

Process Science for flexible and agile processHide

On the following web pages we show how we approach the issue of agile process management with declarative process management technology.

Why agility? Because our work life is agile. Swenson states that "[...] only 20-40% of current processes are routine processes […]" – here, routine processes are meant to be the complement to agile processes. Our observations made over the last two decades in a variety of industrial projects support this statement. However, there is room for both: agile and routine (strict) processes. This is why our framework is capable of supporting both types of processes. This is what practical process management distinguishes.

Process LifecycleHide

We apply latest research in all the different phases of the process lifecycle. The process lifecycle comprises the following phases.

Language Design

In cases where the expressivity of standard notations like BPMN or CMMN does not suffice, the modelling language needs to be customized in an intuitive way. The modelling notation may be extended by domain-specific elements directly within a diagram.

Process Modelling

Business Process Modelling techniques are concerned with mapping to enable understanding, analysis and positive change. Describing the process in diagrams or or textual models are a central feature of the methodology. Following the terminology of programming languages, there are two paradigms of describing business process models: the imperative and the declarative style. The imperative way corresponds to imperative or procedural programming. Every possible path must be foreseen at design time and encoded explicitly. If a path is missing then it is considered not allowed. In declarative modeling, on the other hand, only the undesired paths and constellations are excluded so that all remaining paths are potentially allowed and do not have to be foreseen individually. As the so-called agile type of business processes incorporates many often unforeseen paths, the declarative approach is best suited for it.

Process Enactment

If business process execution involves humans then it should be seen as a decision support system instead of a means of automation. As a consequence, an according system should propose actions and support them but it should never enforce them. This requirement goes along with the call for process management systems “to provide directions and guidance ra-ther than enforcing a particular route” whereas they are com-pared to navigation systems. An important characteristic of decision support is explanation and so-called meta-knowledge. Proposals made by the system need to be justified and explained so that sound choices can be made. For process execution, this means that certain proposed actions must be marked as recommended and that discouraged actions can be traced back to and explained by the according parts of the business process model. A declarative and therefore less rigid form of business processes leads to a greater amount of possible paths. So, especially in the declarative area, the capability of explanation comes into value.

Process Analysis

For purposes of compliance and process improvement, organisations are interested in the way their processes are actually executed. Process mining aims at discovering processes by extracting knowledge from event logs, e.g., by generating a process model reflecting the behaviour recorded in the logs.

​Agile vs. Routine ProcessesHide

Process support for routine (strict) processes has well developed over the last years. BPMN 2.0 is a good example for a framework that copes with strict processes. There is a bunch of tools out there that supports modeling and execution of strict processes. However, support for agile processes – although predominant in real life applications – is rare. This is why our research has focused agile process management. Modeling and executing agile processes implicates the following issues:

Declarative Process Modelling

Following the terminology of programming languages, there are two paradigms of describing business process models: the impera-tive and the declarative style. The imperative way corresponds to imperative or procedural programming where every possible path must be foreseen at design time and encoded explicitly. If a path is missing then it is considered not allowed. Classic approaches like the BPEL or BPMN follow the imperative style and are therefore limited to the automation type of processes. In contrast to imperative modelling, declarative models concentrate on describing what has to be done and the exact step-by-step execution order is not directly prescribed. Here, only the undesired paths and constellations are excluded so that all remaining paths are potentially allowed and do not have to be foreseen individually. As knowledge- and decision-intensive business processes often incorporate many unforeseen paths, the declarative approach is best suited for it.

Cross-Perspective Modelling

Declarative modelling is based on constraints that relate events of the process and exclude or discourage from certain correlations. Both constraints and events must be able to involve all the perspectives of a business pro-cess like, e.g., incorporated data, agents performing the work and utilized tools. On this way it becomes possible to express realistic correlations like, e.g., the actual performing agent of a step affecting the type of data used in another step.

Different Modalities and Explanation

A business process usually consists of several “facets” like, e.g., a legal framework (mandatory, “must”) and best practice (recommended but facultative, “should”). Classic approaches like the BPMN only allow for describing one of these facets per model. Combining both of them in one model greatly enhances its documentary character and allows for a BPM system to act more flexibly. An action that, e.g., is contrary to best practice but conforms to the legal framework is offered but marked as discouraged. The BPM system may even explain why the action is not recommended by tracing it back to the process model.


Webmaster: Dr. Stefan Schönig

Facebook Twitter Youtube-Kanal Instagram Blog Contact