Knowledge-intensive processes are typically scattered across many systems with no clear system of record. Support systems have to consider informational relations of process instances on di erent granularities, and di erent aspects of the work require di erent characteristics in regard to exibility. Today, adaptive case management is typically either tailored towards exible process models or ad-hoc activities for a lot size of 1. Pertuniti connects both approaches by implementing cases as a set primarily of groupware artifacts for complete exibility, subprocess modeling to automate aspects of the work, and exible case data management considering hierarchies of cases. This way, we can reduce routine work or guide through regulated activities, while deviations and ad-hoc activities remain traceable.
Adaptive case management systems (ACMSs) support knowledge workers in
performing emergent, unstructured work. Keith Swenson introduced the term
in Mastering the Unpredictable [
Pertuniti is a commercial ACMS that targets knowledge-intensive processes,
and initially had a clear emphasis on ad-hoc processes which we currently
extend to modeled, exible processes. It resulted from a PhD thesis [
Activity streams show all activities performed within a case regardless of whether they were manual or automated.
While capturing the whole process in a model is often desirable for traceability, automation, and continuous improvement, it is typically not sensible for a knowledge-intensive process. However, knowledge work rarely contains no frequent or repeatable characteristics. Our approach allows to import wellknown best practices of the BPM community, and to combine di erent modeling paradigms and ad-hoc activities within the same overall process1. The focus on ad-hoc activities combined with activity streams allows to transparently extend and deviate from modeled routines. This is especially useful for processes with regulated process aspects around a set of exible project management core activities, e. g. medical quality management. This nature is also present for example in automotive, aviation, insurance, or nance. 2
We introduce subprocess modeling and hierarchic case management based on the running example of a research coordinator. These activities are highly knowledgeintensive and typically not known in advance. The focus is more on knowledge than on process management. A screencast of the features outlined in this paper is available at https://www.pertuniti.com/events/bpm-2020. 2.1
Adaptive case management Pertuniti provides artifact types and features similar to popular groupware, e. g. integration with external calendar and contacts clients. Cases can capture all master data, contacts, tasks, events, documents, interactions, and relations between all case artifacts. Cases can be hierarchical, and may contain an arbitrary amount of subprocess instances. This way, we want to facilitate that all case artifacts can be captured or referenced within one system of record.
We emphasize on collaboration by adopting activity streams that are prevalent in social software. These are available on di erent levels: all visible cases, all case activities, all subprocess activities, and all artifact activities. Knowledge workers can track their own and team member actions for coordination, but activity streams can also pose as an audit trail.
All artifacts provide an EAV schema for adding attributes on demand. To facilitate discussions and capture additional information, notes can be added on artifact and case level.
For automation, we provide integration via web standards like CalDAV and CardDAV, user-de ned document templates, and subprocess models. Document templates can be created by end users in a low-code designer. They can be multilingual and apply case and contact data either from the case context or user-de ned inputs. Subprocess models allow modeling small routine aspects or full processes within the context of a case. 1 Subprocess instances happen within the context of a case, but their execution is isolated. BPMN models and DCR graphs may capture di erent aspects of the case. All modeled processes in Pertuniti are subprocesses. These have a state and their execution is loosely isolated, i. e. they could use case data to communicate, but each subprocess instance also has its local context. In the screencast, you see a subset of BPMN. Currently, we also nalize support for accepting petri nets and DCR graphs, on the client side based on diagram-js2.
This approach allows small low-code automation of routine aspects of an
overall exible process. As ad-hoc activities are always possible and subprocess
models are performed within the context and activity stream of a case, it also
allows to transparently deviate from and to extend more elaborate processes.
Moreover, it allows to combine structured or regulated processes with exible
project management. Process models may merely, and for auditors transparently,
guide through automation, while unique, knowledge-intensive work is performed
in a traceable way within the same context.
Hierarchic case structures are prevalent in BPM, e. g. subprocess activities in
BPMN, and in project management [
In process instance hierarchies, instances typically share information via message passing, e. g. on initiating and nalizing an instance. In Pertuniti, we allow a shared context, e. g. via inheriting attributes from parent cases, and gathering information like tasks from subcases in a consolidated view. Inheritance is different to modeled cases or processes: it is de ned in an ad-hoc fashion via a ag on individual attributes.
Currently, the implementation allows inheriting parent case data to subcases via ags on attributes, and aggregating subcase data in the parent case (tasks). Moreover, child subprocesses can export information to the parent case, and import information from the parent scope. Hence, we capture all directions and sources of de nition of data exchange in case hierarchies. Pertuniti is a single-page web application written in Angular and Typescript on the client side, and primarily Java on the server side. We store information in a database, and larger blobs in more scalable storage, e. g. an S3 back end3. On the server side, it has an internal message passing system to route changes immediately to client side subscribers that are noti ed via web sockets. While this approach allows that all clients typically see the same and up-to-date information, this also lead to additional implementations of BPM engines, e. g. a subset of BPMN and petri nets. In the future, we intend to provide an interface for external BPM engines to exchange context information, activity streams, and update noti cations. 3
The basic approach of Pertuniti stems from a PhD thesis [
The aspects of subprocess modeling and hierarchic data management are primarily intended to support regulated processes. As a rst domain, we focus on medical quality management of SMEs. Here, companies already need a large set of documented processes that typically are not yet automated or supported, and 3 Blobs are decoupled from individual storage providers. the most value-adding activities are creative product and service development, i. e. knowledge-intensive work with regulated aspects. We will further evolve usability and implementation details with representative customers.
The goal of Pertuniti is to introduce methods and best practices of BPM into knowledge-intensive processes without restricting them to prede ned models. We want to support processes that contain aspects with varying exibility requirements in a single system of record.
For that, we support completely ad-hoc activities and managing groupware artifacts next to subprocess modeling. Subprocess modeling is not restricted to a single notation or modeling paradigm. Subprocess instances can be used for automation or to guide through processes. Hierarchic case data management facilitates sharing and synchronizing context for di erent aspects of an overall process. Exchanging context information between di erent levels in the case hierarchy does not require prede ned models. All generated and ad-hoc artifacts are displayed within the same views. Hence, documents may be generated, and manually edited, while all changes remain traceable on the same artifact. We provide traceability via activity streams on di erent granularities.