What we are doing at C2P2.

Where do we come from?

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.

What are we doing?

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.


Research in fields of agile business processes.


Development of powerful tool suites for managing and supporting agile processes.


Consulting for business process management.

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

  • 1
    Language Design
  • 2
    Process Modelling
  • 3
    Process Enactment
  • 4
    Process Analysis

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.

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.

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.

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.