Scenario Summary The goal is to define and implement an MVP path through the workflow as a first scenario, which

can then be iterated and built out to further scenarios. Here is the workflow depicted as a BPMN

Collaboration involving BAW Case and BPM aspects with the path through it for MVP highlighted :-

The scenario high level steps are :-

1. Email or phone call received from Customer to report a claim (a car accident damage but no

personal injuries or other property damage) and it quotes either the Policy Number or

sufficient customer details (e.g. First and last name) to be able to search and find the policy.

Customer Intake Services identify the relevant Policy and create a New Claim against it

(which is an Activity that can be launched from an existing Auto Policy Case).

2. Case instance starts based on the Policy data extracted from the existing Auto Policy, Claim

Intake Services role gets a work item to Gather Accident Information, the end result of which

they update the Case with the necessary FNOL data properties.

3. On completion of Gather Accident Information this is when the long-running BPM process is

initiated, the first step of which is to handover to a Decision Task to assess the claim type

(simple or complex) – for MVP path the accident information will be such that this decision

results in a complex claim type.

4. BPM process then hands control to a Case Activity to Create Adjuster Report which the Claim

Adjuster then does. As part of this task the Adjuster will also request and upload a Police

Report of the accident (a discretionary activity in Case terminology). The adjusters report

will include pictures of the damage to the vehicles and will reference the Police Report

where some parts of the vehicle were in prior poor condition (this is important for later

settlement were only partial reimbursement of the repair costs is agreed).

5. Case returns control to the long-running BPM process where it calls the ODM decision to

Assess Potential Fraud – for MVP the data will be such that no potential fraud is the result.

6. BPM process then passes to the Claim Analyst to Estimate Damage. This logical single activity

is in fact a collaboration between the Claim Analyst and business partner Repair shops – the

analyst selects from the list of preferred suppliers for each vehicle in the region and solicits

estimates from them (at least 2 per vehicle), the repairers then provide their estimates

online, and finally the analyst reviews the estimates and selects one for each vehicle. This

then triggers a recalculation of the total damage estimate (which is needed by the following

ODM service).

7. After estimating damage a further ODM step checks for whether the Claim has escalation

conditions that would require a Claims Manager to review the estimate. For the MVP the

data inputs to ODM will be such that this results in no escalation being needed.

8. BPM process then passes to the Claim Adjuster for them to Create Settlement Offer and in

this they use data gathered from the preferred estimates along with police report and

adjuster report data to provide a cash settlement offer that is not the full repair amount.

9. BPM process then completes and hands control to a Case Activity for the Claim Adjuster to

Create Closing Report (which completes the Case instance).

Note that there are many more steps in a realistic Auto Insurance Claims processing scenario, our

goal here is to provide sufficient illustrative steps to demonstrate the main components of IBM

Cloud Pak for Automation and not to attempt to replicate a true-to-life Auto Insurance Claim.

Therefore here are some considerations to keep in mind :-

- In our scenario we do not deal with identifying fault and counter-claiming against the other

party insurance carrier, the premise is that we accept liability and the workflow is to

establish the amount to settle (provided it is not a fraudulent claim)

- Our scenario will only focus on simple vehicle damage and not any personal injuries as that

would require many more steps to perform medical investigations to verify personal injury

claims

- Similarly no property damage is considered in the scenario

- In a real-life scenario the arrangements for physical repair of the vehicle(s), once agreed

would be performed as part of the claim processing, also, if appropriate, arrangements for

the insured to hire a temporary replacement vehicle would be made

Scenario Walkthrough (BAW solution version used: v0.6.1)

We start in the role of Claim Intake Services – they have received a phone call or email from the

policy holder to report they have been in an accident and wish to make a claim. The caller does not

have their policy number to hand, the case worker will instead use their details to search :-

The customer last name and first name are provided to search on :-

The search finds the policy numbered “POL0001” :-

Clicking on this Policy allows for inspecting the policy data including confirming that it is valid for the

claim the policy holder wants to now make, the case worker can start a new claim with Add Activity

button :-

The only available activity type is selected (you could optionally provide a custom meaningful name)

to which you click OK on :-

And then click Add :-

Back in the Cases view they can refresh the search predicate to search for Auto Insurance Claims for

the POL001 Policy Number :-

… and see the newly created claim case type has started (the generated number comes from the

policy number) :-

The Claim Intake Services role now gets a work item to perform the activity Gather Accident

Information which is the first necessary step in the workflow :-

To put this in context this is where we are in the overall workflow :-

A police accident report may optionally be provided for the Case. To do this the Case admin can

select the Auto Claim case instance and Add Activity :-

They choose from the available activities – in this case just the File Police Accident Report option :-

Again click Add on the resulting activity :-

The Claim Intake Services representative now has an additional work item to file the police report :-

When they open this work item they choose the appropriate Case folder (Police Accident Report)

and click File Police Report :-

They browse and select the document to upload, choose the appropriate document class (Police

Accident Report) and the case correlating information is prepopulated :-

They then provide a police report number and add the document :-

You then see the added document in the folder :-

The case worker also fills in some example data regarding the police findings :-

… and then clicks Complete :-

The case worker then opens their original work item (Gather Accident Information) and are

presented with a UI showing relevant data fields either already gathered from the policy or to be

input here as part of this activity :-

The case worker completes accident data they have obtained (here is an example – note of

particular importance is the “On Private Property” setting to ensure the ODM Decision qualifies this

as a complex Claim scenario”) :-

And some more (note there are selection lists of items that drive the level of interactivity later in this

scenario so it is important to choose certain vehicles – for example the Auto Policy insured vehicle is

already set to this one) :-

And for other vehicle we choose this set of data :-

(Note of the above the context-sensitive items that drive later behaviour are Make, Model, Plate,

VIN and ZIP). Note any other data is not relevant to the MVP scenario so it does not matter what

values, if any, are provided for those sections. It is a good idea to Save the work after providing all

these inputs :-

The case worker can also inspect and upload any relevant case documents, in this situation the case

worker wants to file a picture of the crash scene they have received in the relevant case folder :-

The user then selects the Add Document Set Property custom menu option :-

The dialogue launches and they can select from the available document classes (in this case Claim

Supporting Document), there are document metadata properties defined for the class and in this

one the Claim Number and Policy Number are pre-populated from the case instance :-

Browse and select the relevant file and then Add :-

After adding the crash scene picture you see it in the folder :-

And clicking on it launches the Daeja One viewer to display it :-

We are also going to upload a number of vehicle damage documents which will be used later on

inside the Estimate Damages BPM activity (so that we can see Coach technology interacting with

content). This time we choose the Vehicle Damage class and we set the vehicle registration plate

(which later we use to correlate on against the various vehicles involved in the claim) :-

We also add a sample stock MP4 video and associate it with the same vehicle plate :-

We also add another image for a different plate (we make sure we match it to the plate chosen for

the other vehicle involved in the claim) :-

After this we have these documents uploaded :-

Before completing we want to demonstrate a sample custom validation added to this case activity.

To do that we deliberately set a Date Reported time in the future and then click Validate and

Complete :-

We get a popup warning and the Complete does not transition from this page :-

We correct the date (ensuring it is not a future date) and retry and this time Complete finishes as

expected :-

Behind the scenes there is communication going on now from Case – BPM in order to pass control

and BPM has to gather the properties and build up more complex data structures that are needed by

next steps in the workflow that are performed in ODM. Logging uses correlation data (the Claim

Number and Policy Number) as in IBM Cloud Pak for Automation there will be a need to configure

Elasticsearch and Kibana and view a thread of execution across all the component pillars :-

This is where we are now in the workflow (and the path the ODM result will take) :-

We can also inspect the long-running BPM process and especially confirm that critical data

properties have been accessed from Case using the JS API and populated into ODM service

interfaces – here we see the Process Inspector letting us see the instance that is running :-

And we can drill into the variables data to see the data set from data already provided (combination

of Policy data passed on claim start plus the data entered in File Police Report and Gather Accident

Information) :-

And we can see visually where we are inside this particular long-running process that is an

implementation of a Case Activity (we are paused awaiting an inbound message event from the Case

when the next activity is completed) :-

The BPM process integrates to an ODM Decision and the provided data in the case ensures that we

follow the complex case type path and sets the necessary Case property in order to hand control

back to a Case Activity this time for the Claim Adjuster role :-

The case worker can review data of interest to them from that provided already in the Case :-

In order to move the workflow on we just Complete here to represent the finish of the Activity and

control passing back to the long-running BPM process (normally the adjuster would file some report

document detailing their findings in the Documents section) :-

The BPM part of the workflow now calls another ODM service to assess if any Fraud (in our MVP

scenario the result is that none is detected) and eventually moves on to the Loss Assessment section

in the workflow :-

This is in turn a sub-process with the first step to Estimate Damage :-

In order to Estimate Damage the logic requires a collaboration between the Claims Analyst and

business partner repair shops. What happens is that the Claims Analyst identifies candidate repairers

per vehicle involved and solicits estimates from them, they then each provide an estimate, and

finally the Claims Analyst reviews and selects from the estimates which then builds up the total

damage estimate (which the adjuster will later take as input to the settlement offer). This is

represented in simplified form by this BPMN Collaboration :-

For the next set of activities we can either switch context to the Work Dashboard plugin (normally

we would also log in as different user but for expediency of demo we have a power user that is a

member of all roles in the scenario) or login directly to the Process Portal. Here is the Work

Dashboard link :-

You then see the awaiting work item :-

The work item details show claim summary info and the list of vehicles that have damages to be

estimated :-

The Work Dashboard has a subset of Process Portal functionality. If we view the same work item in

Process Portal we also have a set of generic actions available (such as viewing the instance) as well

as collaboration features :-

Back to this specific work item, Save is available at any time to save partial work, while Complete

however has had validation built-in – here it is disabled as the necessary selection of repairers for

each vehicle has not been done yet :-

When the user selects a Vehicle from the list they get a popup menu of options :-

Each one of these will present a separate sub-dialog. First the view on Map – what is meant to

happen here is that the ZIP of the vehicle is used to go out and find geo coordinates and then show

on a map (for MVP we use a set list if mappings but this could be extended to make a REST call out

to a geo finder service) :-

And when you select a different vehicle and again chose the Map menu option you get a different

location :-

Next if we select the Show Damage menu option you get this dialog showing the list of damage

documents associated with the selected vehicle (which maps back to the earlier step where the Case

worker uploaded docs and specified the corresponding registration plates) :-

The ECM documents for the case are retrieved and displayed in a modal list :-

When you select from the list the document loads :-

And when you choose a different document the viewer changes (in this case a sample video of a

cartoon over-sized rabbit in a cave to demonstrate the control can play videos inline – I really

wanted to find a suitable video here of a damaged vehicle being surveyed but could not find a free

stock one ) :-

If you switch to the other vehicle and again select that menu option you see a different list of

documents :-

And again selecting the document renders it dynamically :-

Next for each vehicle we want to choose repairers to request estimates from. So again we select the

first vehicle and the menu option Search Repairers :-

… and we get a context-sensitive set of repairers in proximity to the vehicle location (note validation

has been built-in to this dialogue, the buttons are not enabled until the correct selections are made)

:-

If we were to choose the other vehicle the list of candidate repairers is different (it is based on the

ZIP that we have for each vehicle) :-

Back to the insured vehicle (Mercedes), you can select one or more candidates and notice that the

Add Selected becomes enabled :-

Once added if at least 2 are in the selected list then Confirm Selections also becomes enabled (plus

Add Selected is disabled again until further selections are made) :-

If you remove one of the selected repairers the Confirm Selections again becomes disabled :-

If you choose to add the same item twice it will recognise this and not add it again :-

Now you can Confirm Selections and these items are saved for the chosen vehicle.

At this point Complete is still not enabled as you have not assigned candidate repairers to the other

vehicle :-

So that is done next for the other Vehicle (Cadillac) :-

Now the Complete button becomes enabled and the user Completes the work item :-

(Note: If the user relaunches the dialogue for vehicle repairers for a specific vehicle at any point it

remembers their previous selections and they can change them if needed prior to completing.)

What happens now is that these chosen repairers are each sent a request to provide an estimate for

the respective vehicles, logically this part of the workflow :-

We are going to show that they are a business partner that also has access to BAW (though typically

they would be using different credentials) and we will “skin” the UI pages differently to show they

are an outside party. Each repairer (there were 4 chosen) would log in individually and see only their

work item. For demo expedience it is easier to not have to switch users so our “power” user can see

and interact with all of the items that now show up in Process Portal (note the subjects match to the

selected cars / garages in the previous activity) :-

We have to complete each of the 4 work item tasks before the process returns to the Claim Analyst.

Let’s walkthrough one of them first. The Coach shows the Vehicle summary along with a Repair

Estimate section and various buttons (in common with the previous Coach we have validation to

prevent Complete being enabled – this time the logic is that there must be at least one part specified

plus the labor cost and tax should be valid values) :-

Starting with the contextual buttons under Vehicle, the View Damage reuses functionality already

seen to let the repairer see the level of damage done :-

Next Check History uses the VIN to simulate going out to some vehicle records service (normally a

government department) as the repairer wants to check any previous accident history etc for the

vehicle as that will effect the likely complexity of their repair work :-

This particular vehicle comes back with a clean bill of (previous) health :-

If we switch to the other work items for the other vehicle with a different VIN this time it comes

back that the vehicle history has found some previous incidents of relevance :-

(Note the implementation here for demo purposes use a static image stored and matched to the

Vehicle VIN).

So next moving on to the repair estimate, we can imagine that the repairer needs to familiarise

themselves with the particular vehicle make, model, and variation so View Diagram might present

them with a contextual parts breakdown (again for the demo implementation this is using a static

image and in this scenario it is not specific to the vehicle) :-

So now on to the main data entry for this item (as we shall see the data entry is minimal as we use

dynamic lookups). So staying with the Mercedes vehicle let’s launch the dialogue to search for parts

:-

We are presented with a popup dialogue :-

If the user were to attempt to Add Part without completing the fields they get validation errors :-

The parts dialogue is contextual to the vehicle (in this case Mercedes) – so you start typing the SKU

code “merc…” and it presents a picklist :-

And when you select from the picklist it prefills in the fields based on that part’s catalog entry :-

The repairer can also search on description if they don’t know the SKU :-

There is also validation on Add Part that the part’s quantity matches the catalog stipulations :-

After fixing issues and adding the parts list is updated and the running total calculated (but note that

Complete is not yet enabled as labor cost and tax need non-zero values) :-

The Edit and Delete buttons on the row allow for deleting or editing the part. Here is an example of

the Edit dialogue (Cancel Edit will not commit any changes while Save Changes will update the part

item in the Parts list) :-

If the repairer provides a labor cost and or tax the total is again dynamically re-calculated :-

After adding some more same parts the finished estimate for this repairer looks like this (and

Complete is enabled) :-

User Completes the work item and the Process Portal refreshes to show the 3 remaining work items

:-

The other estimates are provided in a similar way, the only other difference to note is that the parts

catalog matches the Cadillac vehicle :-

We action the other work items in a similar way, the below screenshots show the final settings

before complete in each case :-

Once they are all done the process representing the gathering of business partner repair estimates

hands control back as depicted here :-

A work item appears to Review and Select Estimate :-

The work item Coach shows summary data and sections for the Vehicles (Complete is disabled until

a preferred estimate is selected from the repairers estimates for each vehicle) :-

The user opens up the Insured Vehicle and sees the estimates breakdown :-

When they select one as the preferred estimate the running total of damages is calculated (but

Complete is not yet enabled) :-

They repeat for the other vehicle, first viewing the estimates :-

Then selecting the preferred one :-

.. and the total damage is set (plus Complete option is now enabled) :-

They now can Complete the review with these preferred repairers set and the workflow proceeds, in

MVP the ODM service does not determine than any escalation is necessary so it can proceed to

settlement. We are now here in the workflow (within the Loss Assessment sub-process) :-

The Process Portal displays a new work item for Create Settlement Offer :-

Opening the item we see that it shows the damage estimate information provided in previous

activity (Complete is not enabled until required fields have non-default values) :-

The Adjuster considers the information (in reality they would also access case documents here to

review the report, polict report, etc) and in this case they decide to reduce the payout for the

insured vehicle due to issues with the existing condition it was in at the time of the accident. When

they change the Adjustment Factor percentage the Adjusted Amount and Claim Settlement Amount

fields are automatically recalculated :-

Note there is also built-in validation in these fields, here is an example of what happens when you

try to provide an invalid percentage :-

The Adjuster then completes the Claim Settlement section which in turn then enables the Complete

button so they can click that to finish :-

BPM long-running process now completes and hands control back to a final Case Activity for the

Claim Adjuster to Create Closing Report :-

We are now here in the overall workflow :-

We can see the data for the Case so far (including key data updates provided as a summary of all the

previous steps in BPM) :-

Also if you look at the documents you will see that a generated file has been added to the Case, this

represents the complex data structures that were processed in all of the previous steps but are not

stored on the Case itself due to restrictions in the data model of Case :-

Here we show this file opened and formatted with a Sublime Text JSON plugin :-

By storing this file we now have core BPM process data stored with the Case and can be available

long after the instance has completed according to whatever retention policies have been

configured in ECM.

Back in the work item data entry tab, provide a Claim Outcome and then just Complete to emulate

that work getting done (in reality there might be some PDF report that the Adjuster provides and

uploads to the case documents) :-

Now back in the Case Search view you get confirmation the Case instance has completed :-

And we can launch the Case Management view and examine the Case properties that were updated

during the lifecycle :-

And we can see documents :-

And we can see the Activities :-

.. and History :-

That’s all for the MVP scenario walkthrough.

Appendix - Scenario Paths The MVP scenario has a happy path that best shows off all the features and to achieve that requires

choosing specific data items. First in the Auto Policy for the insured make sure there are settings for

each of these :-

For the insured vehicle use these settings (the highlighted items are the context-sensitive ones that

are needed in the logic) :-

Now when you are in Gather Accident Information activity in the Auto Claim, ensure you set at least

the below items in the Accident section (checking On Private Property is vital to trigger the correct

ODM path) :-

In the Insured Vehicle provide additional values as shown (you can choose any values here just don’t

leave them blank) :-

Finally for the other vehicle you should complete all fields but the ones shown below are the

sensitive ones and you should match the screenshot choices below exactly :-

If you do not choose these Vehicle options you just get default behaviour in sections of the solution

as follows …

So let’s say we choose a different vehicle choice and location for the other vehicle :-

When you reach the work item to Tender for Estimates the car location map just picks up a default

place (the HQ of Levi Straus given their association with denim) :-

The available repairers to choose from also defaults rather than being location-sensitive :-

Then when you go into the work item to Provide Repair Estimate the only part option you have is

this one :-

So you can still navigate a successful E2E scenario you just don’t get the full richness of features.