Digitalisation of work and business processes with the aim to provide more efficient services at a higher and consistent quality is high on the agendas in many countries. In Denmark the push for digitalisation is witnessed by the national strategy for digitalisation published every four years. Sadly, it is also witnessed by a number of expensive failed digitalisation projects. In this paper we point to two key problems in state-of-the art BPM technologies: 1) the use of rigid flow diagrams as the “source code” of process digitalisation is not suitable for managing the complexity of knowledge workflows and regulations and 2) insufficient support for continuous and agile end-user mapping and adaptation of processes. We report on research in progress on how the Dynamic Condition Response (DCR) Graph technology and collaborative process repository DCRGraphs.net could support agile and collaborative, bottom-up digitalisation of business and workflow processes.
The idea of automating office work beyond computerising individual tasks goes back
to at least the ’70s. In his PhD thesis [
By considering the specification language, the internal representation, and the
design of a prototype system using one unified model, Zisman has been able
to study the office as a system rather than simply as a collection of isolated
tasks and pieces of equipment. Although Zisman suggests the language and the
model need refinement, his basic notions will probably have great impact on
the office of the future. [
This optimism dried out during the ’80s, but re-appeared in the ’90s and ’00s,
when standards for internet web services and business process definition languages
such as BPEL [
The mapping of processes unavoidably made companies and organisations more aware of their processes. However, time and experience has also shown that many diagrams were drawn and subsequently abandoned in desk drawers or large repositories and quickly became out of date.
So why is it, that we have not seen the great positive impact of the basic notion of flow diagrams and BPM technologies on office work as envisioned in the early ’70s? We believe that flow diagrams have some inherent problems, related to how they deal with the unpredictability and the constant need for change that are key to office work.
First of all, flow diagrams do not explicitly capture why the activities are ordered
in the given sequence, which makes them very difficult to update when the underlying
reasons change. Consider implementing the rule found in the General Data Protection
Regulation (GDPR), that if personal data is collected as part of signing a contract which
is need for later but not obviously needed for offering the job, a consent from the
employee must be given before signing. In a flow diagram, the rule can be implemented
by making sure that an activity for getting consent appears on every path from the start
of the process to the activity of signing the contract, but we can not specify the actual
rule formally as part of the diagram. So, if we later update the diagram (or the rule gets
changed) we have no formal guarantee that the rule will still be correctly enforced. This
problem was experienced by the danish repository of local government workflows [
Secondly, many activities in an end-to-end business process, in particular processes
involving some elements of knowledge work, can not be automated, in particular
because the ordering of activities depends on many factors only known when the process
is carried out and best determined and evaluated by human actors. Indeed, in the recent
McKinsey report [
Consequently, state-of-the-art process mapping and automation technologies yield too rigid processes and introduce a new complex manual process of producing and maintaining the process maps, which can not be carried out in practice and thereby results in proces descriptions that do not match reality. This leads to the research question of how to manage the complexity of digitalising knowledge work processes regulated by law? Based on our work so far, we conjecture that an answer could be to support a continuous, agile and bottom-up process digitalisation that 1) provides process support that facilitates business users and knowledge workers, 2) captures both the why and the how of a process mapping, and 3) can be kept in synch with a changing reality.
Below we illustrate how the Dynamic Condition Response (DCR) Graphs
technology and collaborative process repository DCRGraphs.net [
Agile Digitalisation with DCR Graphs
Dynamic Condition Response (DCR) Graphs [
In the following we exemplify the collaborative and agile process mapping methodology supported by the tool using a prototypical example of an on-boarding process, which can be accessed at http://www.dcrgraphs.net/Tool?id=4587.
When using DCR Graphs, process mapping typically starts by placing activities as ”post-it stickers” on a virtual ”brown paper”, labelled with an activity name and roles. Fig. 1 shows an example of such an initial graph, with six activities: GDPR Consent, Sign Contract, First day at work, Need for PC, Order PC, and Receive PC. (The activities are added simply by right clicking on the canvas). Detailed textual descriptions of each activity, including links to external references, can be added, as illustrated in the figure for the GDPR Consent activity. Each activity shown in the figure has been assigned one of the roles: GDPR Consent, Employee, HR and IT. At the present point, the role assignment is the only constraint of the process. Any of the activities can be executed any number of times by an actor with the correct role.
At any time, the modeller can simulate the process by pressing simulate and invite friends or automated users to play any of the roles. Automated users may join either as an aggressive user that performs every action that is possible and not executed before, or as a lazy user that performs an action if it is possible and required.
The collaborative simulation shows a task list interface resembling a case management tool, the history of performed actions as an event log and a swimlane diagram. 4 http://www.dcrgraphs.net/
Thereby the end-users and modellers can explore and understand how the process can be performed. The screenshot in Fig. 2 shows a collaborative simulation with a friend, Morten Marquard, playing the role of Employee and an automated lazy user playing the role of the IT department. In the simulation there was a need for PC, but the PC was not ordered by the lazy IT department before the first day at work.
Simulations can be recorded as part of the documentation of the process and tagged as happy, un-happy or neutral, to indicate respectively, if the simulation is part of the desired, undesired or optional behaviour of the intended process.
The screenshot in Fig. 3 shows that we recorded the above simulation as unhappy, and named it “First day at work without PC”. We have also made an unhappy simulation without GDPR Consent before signing and a neutral simulation where consent is given and the PC is ordered (but not received) before the first day of work. Finally we made a happy path simulation, where the PC was also received before the first day. The latter example is shown in Fig. 4.
Simulations can be shared and replayed at any point, even if the process subsequently has changed. Moreover, saved simulations can be run as a test against the current version of the process, resulting in an indication by a green or red bar whether the execution trace can still be carried out. This allows a test-driven modelling approach, where users can add and remove constraints to ensure that all happy paths are possible and all un-happy paths are ruled out.
In Fig.5 we show a process map where we have added DCR constraints to the process. The yellow arrows with a bullet at the target are condition constraints and model the fact that some activity can not happen before another activity has happened. In our case, we have modelled that the GDPR Consent must be given before the contract can be signed, and the contract must be signed before a PC can be ordered and before the first day of work. The blue arrows with a bullet at the source are response relations. The response relation from Need for PC to Order PC models, as explained in the Description field in the Figure, that if HR registers a need for PC, then IT must in response eventually order the PC. The response relation from Sign Contract to First day at work models that if the contract is signed it is expected that the employee eventually has a first day at work. The red arrow with a % sign at the target is an exclusion relation. The exclusion relation from First day at work to itself models that when First day at work happens, it is excluded and can thus not happen again. The exclusion arrow from Receive PC to Order PC models that Order PC is excluded from the process when a PC is received. Dually, the green arrow with a + sign at the target from Need for PC to Order PC is an inclusion relation, which models that if Need for PC happens, then Order PC is included (if it was previously excluded). Finally, the purple relation with a diamond at the target is a milestone relation. It models that as long as Order PC is pending (required as a response) and included, then First day at work can not happen. In other words, whenever a need for PC is registered, Order PC must happen again or a PC must be received before the first day of work.
We can now re-run the simulations, as shown in Fig 6, and see that we have ruled
out the two unhappy paths and kept the happy and the neutral path. Looking back at the
simulation in Fig. 4, it was actually performed on the constrained graph and with the
computer playing the IT role as a lazy user. This time the PC was ordered by the lazy
user after the contract was signed, because the action was required as a response to the
need for PC and not enabled before the contract was signed.
The declarative specifications given by DCR Graphs capture the reasons for why
actions must be done in certain order, and leave the flexibility to do anything which has
not been ruled out. That is, a DCR graph explains the why, and relations and
activities can be added and removed when requirements change, even at run-time. It is well
known (see e.g. [
The DCRGraphs.net approach is currently being evaluated in the mapping of a real
on-boarding process of a danish municipality, involving more than 200 activities and a
great deal of flexibility. Finally, it is worth noting that the processes can not only be
simulated. Processes made in DCRGraphs.net can be accessed and executed via a
RESTful interface, or can be exported to the process engine of a case management system.
Currently, two commercial case management systems support DCR Graphs, one being
Exformatics ECM [