DCR Process Methodology

DCR Methodology

A major benefit of DCR graphs is the way processes are discovered and defined.

In traditional flow-graph based methods using process notations such as BPMN, you have to identify exactly where the process start and end as well as all the steps and paths in order to complete the process. Collecting such knowledge takes a long time and you cannot digitalize your process before the flow graph has been defined from start to end.

DCR Graphs are faster to work with as you can digitalize the process incrementally, based on just a few pieces of the process known. Once digitalized you can learn from experience what people do and refine the process based on actual experience. The D in DCR graphs stands for dynamic, which mean that during the digitalized process the user can even add new activities and rules meeting the need in the actual instance of the process.

Download the DCR Cheatsheet (in Danish) for details.

The methodology

The DCR methodology consists of five steps repeated again and again.

  • What: Identify activities – what work is carried out in the process
  • Who: Identify roles – who is involved
  • Why: Identify rules – assign roles to activities and describe the relations between activities, e.g. dynamic exclusions, conditions and responses, that describe why activities can only be done in a certain order and by certain roles
  • Identify and validate scenarios – use the simulator, swim lane editor and path history to identify and validate required, typical and unwanted paths in the process
  • Digitalize your work process – use a DCR enabled workflow system to digitalize your work process

The DCR Process Methodology consist of three main steps as illustrated below:

  1. First, identify roles and activties, i.e. who does the work, and what work is done
  2. Secondly, identify scenarios, i.e. typical workpaths as well as forbidden scenarios
  3. Finally, identify rules

The first three steps results in a DCR Graph, and are required before you can digitalize your work process using a DCR enabled workflow system. However, you need not identify all activities, roles and rules before you can identify scenarios and digitalize your work proces. Once you have identified the first activity of the process, you can do any of the steps in any order and as many times you need. This support for incremental process mapping makes the DCR methodology extremely agile and delivers digitalisation much faster than the traditional flow-graph based approaches.

Various tools exists to assist the users designing, validating and digitalizing the process.

  • The DCR Highlighter tool makes it easy to mark up a law text to a DCR graph.
  • The DCR Designer is used for brown paper exercises to map the above objects step by step.
  • The Swimlane editor makes it easy to create and edit scenarios and verify if they are valid or not.
  • At any point in time the users can choose to use The Simulator in order to verify the behavior of the graph.
  • The Path Analyzer can help the user finding ways through the defined DCR graphs, simular to how Google Maps helps drivings find ways.
  • Path History can assist the user analyzing either design time scenarios or run time instances in order to get insight into how users work with the graphs.
  • A future Graph Discovery will assist analyzing scenarios and suggesting relations in the graph.
  • The DCR process engine can be integrated with existing workflow, business or case management systems to digitalize work processes described as DCR graphs

An example using DCR Highlighter

Image a process description as outlined below:

In order for the employee to have a good first working day, some things must be secured before starting. HR must set up the employee in the personnel system. The employee must state previous employment so that HR can calculate the salary based on experience and previous salary. Then the HR must send the contract to the employee who must accept the contract. Finally, FM must find and assign the employee an office space and get an admission card.

Create a new DCR graph and paste this process description into the description of the graph.

New employee process

Under Apps select DCR Highlighter

Select DCR Highlighter App

Align the two windows next to each other, DCR Highlighter on the left and Designer on the right as outlined below.

New employee process

Roles

According to the methodology we may start by identifying roles. The roles are:

  • Employee
  • HR
  • FM

Using Highlighter we can mark the text for these roles.

Roles identified

Activities

Secondly we can proceed to identify activities found in the description.

The overall goal of the process is that the employee should have a good first working day.

Using Highlighter we’ve marked the activities.

Activities identified

Notice that the activities are marked in Highlighter on the left with a round A

Scenarios

As the third step we can identify possible scenarios of the process.

Using the swimlane editor new scenarios are easily created simply by dragging and dropping activities onto the swimlanes.

You can also use the simulator from the DCR Designer and step through each step shown in a task list.

Creating a scenario using swimlane editor

The newly created graph is shown on the frontpage of the portal

Scenarios for a graph

Clicking Create New Scenario will launch a menu to be filled out.

Create New Scenario

After the menu is filled out you can start creating the scenario by dragging activities into the swimlanes.

Ready to use

After dragging activities onto the board you’ll have a

Scenario created

Using the menu found under Edit you can validate the trace.

Scenario validated

Going back to the front page of the portal you can view the newly created scenario.

New Scenario on front page

Creating a scenario using simulation

From the DCR Designer you can choose to simulate a graph by clicking on the Simulate button.

New Scenario by simulation

A menu will be shown. Click on Start Simulation to start the simulation which will show a simulation screen containing several elements. The key element is the Tasks area which shows the tasks that can be executed grouped by each role.

New Scenario by simulation

Executing the tasks will create a new scenario.

New Scenario by simulation completed

Finally – click on Exit simulation and fill out the menu

Confirm to leave simulation

Ensure to select a type, fill out a type and select the Is Scenario checkbox.

New Scenario on front page

During simulation all events can be executed at the same time. The reason for this is that there are no rules defined in the graph.

Use Path History to identify diversity of scenarios

Path History can be used to analyze the diversity of a set of scenarios. These scenarios can be created on design time by users or at run time by importing the graph into a DCR complicant system which will generate a DCR XML Log that can be analysed.

View scenarios from Portal

Click the “Analyze Scenarios” button which opens up Path History.

View scenarios in Path History

Rules

Using Highlighter we can continue to mark up text as shown below.

Using Highlighter we’ve marked the activities.

Some rules identified

We’ve identified two conditions and one response.

  • First condition from state previous employment to caculate salary
  • Second condition from caculate salary to send the contract
  • First response from send the contract to accept the contract

A condition is a rule that states before you can caculate salary the employee must state previous employment.

A response is a rule that states whenever you send the contract the employee must accept the contract

Grouping

Events can be Nested or placed into sub-processes which has similar meaning. Nesting is a way to syntactically avoid many arrows as all arrows in and out of a nesting goes to each event inside. Sub-processes are different as they carry their own state. We’ll use Nesting for grouping the graph.

All events is a condition for the employee to have a good first working day. Grouping all events into a group, Group1, makes it easy to add a rule from all events to the good first working day event as shown below.

Grouping all events

Consideration – get admission card before contract is accepted

Is it allowed to get a card for an employee before the contract has been accepted by the employee? There is nothing in the process description that describe such a rule. It could be solved by saying that accept the contract is a condition for get an admission card.

Access card require accepted contract

Consideration – contract gets rejected

What happens if the employee rejects the contract? The process description does not contain any description that this can happen but what does the reality show? Do all contracts get accepted?

We’ve added a new activity reject the contract. If the contract gets rejected we’ve added a response relation to accept the contract as rejection requires the contract to be accepted at a later stage.

Final version of process

The final graph can be found here on the DCRGraphs.net portal

Sidebar



Bitnami