• No results found

Chapter 4. Bringing it all together: The AIC decision discovery project

4.4 Step 3: Identify and prioritize decisions for further discovery

4.4.5 Preparing for in-depth decision discovery

Once Sue has documented the high-level characteristics of each of the five top-level decisions, she associates them with the decision points in the process that had been

identified in the earlier on in the project. This way the team will be able to navigate directly to a decision from the decision point in the process diagram. This will be helpful during the workshop that they are having the next day where they will walk through each of these decision points to decide which ones they will proceed to document in more detail. She creates these associations by clicking each decision task in the process diagram, going to the Decision tab and selecting the appropriate decision, as shown in Figure 4-26 on page 69.

Figure 4-26 Associating the Validate Driver decision task with the Validate Driver decision

Once selected, the decision appears on the Decision tab where it can be clicked to navigate directly to the decision diagram, as shown in Figure 4-27.

Figure 4-27 The Validate Driver decision task associated with the Validate Driver decision

Selecting decisions for further discovery

In Chapter 3, “Getting started with decision discovery” on page 21 we discussed a set of criteria to help identify and prioritize decisions for further discovery. You may want to quickly review this before continuing on. Detailed decision discovery is a lot of work, so you do not necessarily want to go ahead and do it for each of the decision points that you uncover. But it is necessary to capture some high-level information up front about these decision points in order to make that evaluation.

The AIC decision discovery team has gotten together to review their five decision points and identify which ones they want to tackle. Sue has Blueworks Live open and projected onto a screen so everybody can see. She is presenting, walking the team through what she has captured for each decision point and making recommendations.

“Throwing out” cars and customers that we do not insure is really a fairly easy decision. We have a list of the cars that we do not insure, and we only update that every year. Right now the only customers that we “throw out” at this point are those who are under 18. While I could imagine wanting to decide on cars based on something better than just a list, I really do not think that we are ready for this….so I would say that this one should be a low priority for us right now.”

“Deciding whether the driver and car qualify is a really complex decision, based on looking at all the factors on the application, on the driver's record, and at some of the qualities of the car.

Now we usually only make changes twice a year, but when the state insurance board makes a change, we usually only have a short time until it becomes effective. It is so difficult to go back and review all the auto insurance policies that have been issued between the changes becoming effective and the new code being implemented. Some of this decision is made by the computer now, but most of it is done manually by the underwriters and the policy adjusters, and they really understand these decisions well. In fact, sometimes when the system is wrong they catch it. This one looks like a good choice to me.”

“Now the pricing decision actually involves three related decisions. We have to figure out a base price for the car, adjust the price based on many factors, and then perform the actual pricing calculation. Figuring out the base price for the car just comes from a table. That usually changes every year, in January. We have this in a database, and it just gets pulled out.

I would say this one is low priority.”

“Adjusting the price requires consideration of many different pieces of information about the customer and their driving record to determine what the price should be. Sometimes some factors override other factors. Sometimes we back things out. I do not completely trust that the system is doing it right now, but the worksheets to figure the adjustments out are so long, I hate to keep checking the system answers. And when customers call to ask about their rate, it would be really nice to know exactly how it is calculated. This looks like a good choice, too.”

“The calculation is easy once we come up with the base price and applied the adjustments. It is just math. I think it might be nice to be able to see how it is done, but I am not sure that this is a great choice.”

The team discusses this for a while, and ends up agreeing that the best candidate decisions for further discovery are “Validate Driver”, “Validate Vehicle”, and “Adjust Price”. However, because they are not sure that the knowledge for adjusting the price is correct in their organization, they decide to go ahead and get started with “Validate Driver” and “Validate Vehicle” first. They will come back to “Adjust Price” after they have gotten more experience and have had some initial success with their decision discovery efforts.

The decision discovery roadmap

Sue documents the team’s recommendation, puts together a high-level project plan, and packages this up with a PDF of the process diagram and a Word document containing the decision point details. She sends this Decision Discovery Roadmap out to the management team for their review, and schedules a meeting convening the stakeholders to review and approve the project going forward. This will ensure that they have buy-in and visibility across the organization, as well as the commitment for the team members to continue to invest their time in this decision discovery initiative.

4.4.6 Summary

In this section, we learned how to capture the high-level characteristics of our decision points in Blueworks Live, and how to evaluate those decision points to identify decisions that might be worth additional discovery.