To understand this process example, it’s helpful to start with the process goal, typically an end result phrased in terms of something a customer values. Modeling and executing the process is merely a means to that goal. In this case, we can summarize the process and its goal as: Process an insurance claim in order to make a payment to a customer. This is a high-level goal that doesn’t include alternative possibilities, such as rejecting the claim, or things that could go wrong. A high-level view of the process is shown in this model:
In summary, the process is to assess a claim and make a payment, or reject the claim for some reason. For this example, we’ll simplify the final step into merely calculating the payment amount and suppose that a follow-on process will actually make the payment to the customer or send a rejection letter. Instead, we’ll focus how we assess the claim in order to calculate the payment amount. In particular, we want to be able to model for a large team is handling a high volume of claims.
To handle a large volume of claims, we need a way to work with a large team, in order to do lots of work in parallel. However, a small volume of claims require special processing. Perhaps the claim is very large, which means that an assessor must visit the customer and investigate the claim, or perhaps it is a complex claim that is difficult to assess.
If this special processing needs a senior assessor to assess the claim, then this will make it difficult to assign the Assess claim tasks to team members without first knowing more about the claim. To solve this, we can split the task to assess the claim into a process that allows us to use a different flow for claims requiring special processing. We can add checks that a junior assessor can perform to see if special processing is required, and process the claim themselves if not. When special processing is required, specific assessment tasks can be assigned to a senior assessor.
In this version of the process we have separated the four easier tasks (along the top row) from the two harder tasks (on the bottom row). The path along the top row includes two exclusive gateways – decisions to check whether special processing is required. Now it’s easier to scale our team.
Most claims can be handled completely by junior assessors. Junior assessors also perform the checks to discover whether a claim requires special processing by a senior assessor. Senior assessors can be left with a smaller workload, as they only need to investigate high-value claims and process complex claims.
We’ve identified two different roles to optimize handling a large number of cases: Junior Assessor and Senior Assessor. Part of our process definition is that each task will always be assigned to one of the two roles.
These two roles are only defined within this process, so they are not organizational roles. Within a small insurance company, employees with the job title (organizational role) Junior Clerk might be candidates for the Junior Assessor process role, while any Manager or Senior Partner might be a candidate for the Senior Assessor process role. A larger company might have more specialist positions in the company that correspond more closely to the process roles. As far is process modeling goes, this is separate to the process definition.