CHAPTER 11

Putting the Pattern into Practice

This chapter illustrates how the Transaction Pattern that we have described in Parts I and II can be put to work in practice. We work through a case study step by step, progressively building the requirements specification that will lead to implementation of the transaction in systems and work practices. Through this concrete example, we hope to illustrate how the Transaction Pattern and the associated method could be used in your own business scenarios. The case study involves a realistic but fictitious transaction. Firstly, we present an overview of the design and specification steps that are necessary for this case study. Then we delve into the details of each step in the subsequent sections. The steps involved in this case study are:

• Introduce the case study scenario
• Map the value stream
• Map the customer journey
• Identify the business objects (data subjects)
• Describe the business process and organization functions involved
• Align the business process to the Transaction Pattern
• Develop a service blueprint for the process
• Hold a requirements workshop
• Specify the sequence of tasks
• Specify the data requirements for Preparation and Evaluation
• Specify validation business rules
• Specify the workflow and work queues
• Communicate the requirements
• Discuss implementation options with IT.

Our subject matter expert, Emily, takes the lead in this case study.

The case study scenario

The case study concerns an insurance company, Rebel Insurance, who market and sell insurance policies that protect the policyholder against losses caused by a wide range of unexpected incidents. Insurance policies are available from Rebel Insurance for everything from health expenses to death; from damage to buildings to damage to reputations; from unexpected events during travel to the sinking of ships. Like most insurers, Rebel Insurance has become adept at assessing and costing the risk of every sort of loss that individuals and organizations might suffer.

The insurance industry is huge and varied in many ways, yet there are remarkably consistent norms on which most insurers base their business model. All insurers produce policy documents that detail the risks that are covered and those that are excluded. All insurers need to process claims against a policy when the owner of the policy experiences a loss. All insurers must assess and settle every claim they receive. All insurers will seek to renew the policies with existing customers when expiration of a policy is imminent.

Insurance companies make a good topic for this case study because the processes and information that insurers typically use are well-described. In particular, the case study focuses on the transaction that most customers hope they will never need to engage with – making an insurance claim. Processing insurance claims forms the bulk of the work in Rebel Insurance’s office, alongside sales of policies. Insurers are always striving to process claims more efficiently, because claims processing is a significant cost that ultimately flows through to the premiums the company charges. Higher premiums make Rebel Insurance less competitive.

The value stream

Firstly, Emily looks at Rebel Insurance’s value stream – that is, the set of services by which the insurer hopes to provide value to their policyholders.

Rebel Insurance develops and markets their products, underwrites and sells policies, processes claims, and renews policies. The company’s value stream maps these services as a linear sequence (although the services may not be used by the customer in that strict order).

Emily draws a diagram of Rebel Insurance’s core value stream, shown in Figure 11-1. Note that the wording of the services is written from Rebel Insurance’s internal perspective, as opposed to the customer-centric language of the customer journey, which we will look at next.

The customer journey

Emily finds that the customer journey for Rebel Insurance is straightforward, like the value stream map but expressed from the customer perspective. Customers follow a simple lifecycle with their insurances – customers identify a need for insurance; discover insurers’ product offerings; compare products; buy a policy; renew a policy; and make claims as necessary. If Rebel Insurance seems unfair in their assessment of a claim, the customer may need to dispute a claim settlement. Figure 11-2 shows Emily’s depiction of this journey and the touchpoints with Rebel Insurance, where the customer gets information, interacts or transacts.

Looking at the touchpoints in the customer journey, Emily can see that there are three which appear to be transactions:

• Commit to buying policy
• Submit claim
• Lodge dispute.

These three touchpoints align with the transactional services that Rebel Insurance offers to its customers, as shown in the value stream map. That is, Rebel Insurance exists to enable customers to buy a suitable insurance policy, to submit a claim for an insured loss, and to dispute the company’s settlement of a claim.

Emily could augment the customer journey map in various ways, by adding channels, business functions, and business capabilities. In this way, she can start to see how the internal structures and processing infrastructure align to the customer’s point of view. Combining the value stream and the customer journey, Emily produces an initial view of the top tiers of the Rebel Insurance service blueprint, as shown in Figure 11-3.

The business objects and data

Emily remembers that business objects are the ‘things’ that Rebel Insurance deals with; business objects (sometimes called ‘entities’ or ‘data subjects’) comprise data that describe those ‘things’. Emily can now begin to discern, from the service blueprint, the business objects that are likely to be created or updated by Rebel Insurance’s services. She needs to be aware of what these business objects are because this will help her to be clear about the purpose of each transact or interact touchpoint in the service journey. The transact touchpoints will create or update at least one type of business object that is part of the company’s master data. For example, Submit claim will create a new Claim object.

Emily realizes that it is worth spending some time thinking about the business objects that are ‘in the frame’ for her business context, and about the relationships between the objects. She knows how important it is to carefully define each of these business objects, so that there is less confusion and ambiguity about what the terms mean. These steps will enable her to be clear about which master data each transaction might be creating or updating. Emily finds some obvious candidates for Rebel Insurance’s business objects in the nouns used in the phrases that appear in Figure 11-3. These include:

• Policyholder
• Sales agent
• Policy
• Claim
• Payment
• Dispute.

She can also see from the service blueprint in Figure 11-3 that these business objects probably have relationships with each other – these relationships are expressed as a connecting verb. For example:

• Policyholder owns Policy
• Sales Agent sells Policy
• Payment settles Claim.

A diagram of the business objects and their relationships is somewhat easier to grasp than a list of relationships. So, Emily sketches out her thoughts about Rebel Insurance’s data in the simple diagram shown in Figure 11-4.

This kind of diagram is called a business data model. Emily also compiles all of her definitions of the business objects in a Business Glossary.

Rebel Insurance probably has many more data objects that those shown here, but this level of detail is sufficient for the purpose of working through the design and specification of a transaction. If more details come to light later that are relevant to our objective, they can be added then. The diagrams shown in Figure 11-1 to Figure 11-4 can – and should – evolve as more discovery and design work is completed.

Narrowing the focus to one transaction

So far, Emily has pieced together a fairly comprehensive idea of the business context of Rebel Insurance, the customer experience, and the kinds of data that Rebel Insurance works with. Now she will zoom in on one of the transaction touchpoints shown in the service blueprint – Submit claim.

Processing claims is the core operational process for Rebel Insurance – it consumes the bulk of the firm’s work effort and involves a range of personnel with different skills. Insurers take care to assess each claim to ensure that the claim arises from a loss that is explicitly covered by the policy. In other words, claiming for losses against insurance policies generates a lot of transactions. Emily’s goal in this case study is to redesign the Submit claim transaction, using the Transaction Pattern as the framework. She hopes to make the Submit claim transaction more efficient for the teams that process claims, and more effective for the customer, who wants their claim to be settled as quickly as possible.

The business objects involved in the submit claim transaction

Because she is now focusing only on the Submit claim transaction, Emily can start to narrow her focus to the customer experience, business objects, and business functions that are involved specifically in this transaction.

She easily filters out the business objects that are not relevant to Submit claim by looking for the business object Claim in Figure 11-4 and finding the objects that are joined to it. These objects have a relationship to the Claim object which could be used or updated during the Submit claim transaction, so she needs to give them all some attention. By limiting her view in this way, she ends up with a smaller model showing only the business objects that she needs to consider when discussing Submit claim transactions, as shown in Figure 11-5.

Emily revisits the service blueprint for Rebel Insurance (Figure 11-3) and notes that there is a transaction touchpoint after Submit claim called Lodge dispute. She realizes that these two transactions are separate because only a small proportion of all claims will be subject to a dispute; that is, they are made when the policyholder thinks that Rebel Insurance’s assessment of their claim is unfair or mistaken. Therefore, she can remove the Dispute business object from Figure 11-5, because it will not be created or updated by a Submit claim transaction. Emily’s resulting map of the relevant business objects is shown in Figure 11-6.

The removal of Dispute from the scope of the business data model indicates that there is a clean finish to all Submit claim transactions, as they will be completed when a payment (or a rejection of the claim) is sent to the policyholder. If the policyholder is unhappy with the rejection or with the payment amount, they can commence a different – but related – transaction called Lodge dispute, and that is where the Dispute data is created.

This raises a vital point concerning how to distinguish different transactional services. It is relatively easy to get confused about the scope of your work and where your attention should be focused. We must be clear whether the scope of the project includes disputed claim settlements or not. If included in the scope, then Emily needs to ensure that the two transactions are kept separate in her design and (especially) in the requirements documentation. Emily becomes keenly aware that there are two transactions going on here. Allowing the two transactions to be jumbled together will complicate everything, not least the implementation of the transaction in systems.

Remember the request-and-response nature of the Transaction Pattern. The key question to ask is: “Is the customer making another request, and is there a separate decision that we make in response?” In the case of a disputed claim settlement, the answer to both questions is clearly “Yes”. Also, consider whether the information that needs to be submitted by the customer is the same or different when lodging a dispute – a dispute must relate to a previously submitted claim, but the details of the claim do not need to be submitted again. Also, the policyholder may need to provide additional information to support their dispute. Therefore, Submit claim and Lodge dispute are separate transactions.

The insurance claim business process

Emily knows that processing an insurance claim at Rebel Insurance not only involves several types of operators and assessors, but also some claims need the attention of senior claims assessors because of their complexity and/or high value. Simple or low-value claims may be processed and approved by junior staff, while complex or high-value claims will be investigated more thoroughly by a senior assessor and possibly approved by yet another person. In larger insurance companies, big claims teams deal with a large volume of claims for a wide range of policy types.

Emily sketches an outline of the processing steps. At Rebel Insurance, an insurance claim transaction is submitted online and processed through the following steps. Each step is carried out either by the insured person (or their representative) or by the insurer’s front office and back office staff.

1. The policyholder or a person representing the insured party (the ‘insured’) goes to Rebel Insurance’s website, navigates to the place to make a claim, and identifies themselves and the insurance policy;
2. They then enter the information required by the insurer, and may attach supporting evidence such as a photo of a damaged item, the original receipt for the item’s purchase, or a document that proves that an incident occurred (a police report or a death certificate, for example);
3. Rebel Insurance’s website will validate that all the required information has been completed, and the website will invite the insured to review and submit the claim;
4. Inside the Rebel Insurance office, the attachments are checked for authenticity and relevance to the claim. A check will be made that the claim is valid under the policy.
5. If these checks pass, the claim is accepted for assessment and a letter is sent to the policyholder acknowledging receipt of the claim;
6. The claim is classified according to its policy type, complexity and potential value. The claim’s classification is used to determine which teams will be involved in assessing it;
7. The Rebel Insurance assessor that is assigned to the claim conducts their assessment. This may be a straightforward process, or it may require further information from the insured, including a visit to view the extent of the loss incurred by the insured;
8. The assessor makes a decision to pay the claim or recommends such a decision to the claims manager. In the latter case, the claims manager reviews the case and the assessor’s recommendation and makes the decision. If the decision is to reject the claim, the next step is skipped.
9. The amount of the payment is calculated, and the payment is made to the insured;
10. A record of the decision and the payment amount is made and linked to the data about the customer’s policy, for future reference;
11. A letter is printed and sent to the insured to notify them of the decision and the payment amount (if any). The claim is now settled.

Align the process to the Transaction Pattern

Emily notices that the basic pattern at play in the above sequence of activities conforms to the request-and-response Transaction Pattern. The submitter (the insured) submits a request (a claim). Rebel Insurance validates and assesses the claim, and either rejects the claim or agrees to pay an amount. The submitter is notified of Rebel Insurance’s decision and, if applicable, receives the payment. Emily draws a diagram showing this alignment of the process steps with the Transaction Pattern, illustrated in Figure 11-7.

Eliminate unnecessary business tasks

By comparing Figure 11-7 to the complete Transaction Pattern, Emily notices that some tasks described by the pattern are missing. The missing tasks are:

• Profiling
• Commencement Notification
• Acknowledgement
• Future Activity Scheduling.

Emily investigates each one of these tasks and makes sure that they are not required in the Submit claim transaction. For example, the Profiling task may be used if Rebel Insurance gives priority to claims received from high-value customers, or may flag the transaction as risky if the claimant is a known nuisance. The Acknowledgement task may be used, as an alternative to using the Acceptance task in the Validate phase, if Rebel Insurance wants to give immediate acknowledgement to the customer that the claim has been received.

In this example, a Classification task is required because Rebel Insurance’s assessors are divided into junior and senior teams. The Senior Assessor team deals with complex and high-value claims. This means that each claim’s Evaluation task must be classified as simple or complex, and low-value or high-value, so that it can be workflowed to a junior or a senior team of assessors. To further complicate matters, Rebel Insurance has a team of assessors for each policy type – life, vehicle, fire and general, etc. These factors mean that a received claim must be routed to a different team for assessment according to several business rules – complexity, potential value, and policy type. These rules may be implemented in a system, enabling automated routing of the Evaluation task to the work queue for the correct team. Rebel Insurance does not have this automation capability yet but would like to implement it soon. Currently, the complexity and value of each claim are classified by a human and they will manually assign the Evaluation task for the claim to the correct work queue.

Furthermore, high-value claims, once assessed, must be passed to a claims manager for approval. This facilitates separation of the duties between the senior assessor and the manager, enabling a check on the quality of the assessment and the recommended pay-out.

The separation of duties requires the Approval task to be workflowed to a task queue that is separate from the assessor queue. After performing the Evaluation task, the senior assessor may perform the Recommendation task to recommend a decision based on their assessment of the claim. When they mark the Recommendation task as ‘done’, the workflow will place a new task – Approval – on the claims manager’s task queue. Since the senior assessor is not a member of the claims manager’s queue, this mechanism prevents the senior assessor themselves from picking the Approval task.

Rebel Insurance has a policy that low-value claims can be approved by the same assessor that conducted the assessment of the claim; that is, they can approve their own work. This suggests that, in this case, the Evaluation task includes the Approval step. However, a well-designed workflow system will not combine the Approval task with the Evaluation task. This would ‘hardwire’ a rule that Rebel Insurance may want to alter in the future. For instance, keeping the Evaluation, Recommendation, and Approval tasks separated allows a second assessor to approve the conclusion of the first assessor, perhaps after checking by a third assessor. Rebel Insurance might do this for quality and training purposes, or to introduce a separation of duties into the business process when on-boarding new staff (as above for high-value claims). They would not be able to do this – at least, not without making changes to the IT system – if the Evaluation, Recommendation, and Approval tasks were combined into one task for low-value claims.

Furthermore, since they want to be able to route approvals of high-value claims to a claims manager, the system must support separate Evaluation and Approval tasks. There is no additional cost to using the same mechanism for low-value claims.

In this example, we also see the Payment task in the Complete phase of the transaction. Recall that the tasks within the Complete phase cannot be stopped once the Approval task is finished. In the case of an insurance claim at Rebel Insurance, after the decision is made to pay the claim, the exact payment amount must be calculated, and an instruction sent to the accounts payable team to make the payment. This is the job of the Payment task.

Also, during the Complete phase, a letter is printed and sent to the insured party to notify them of Rebel Insurance’s decision. This is the Notification task. There are standard payment letter and rejection letter templates. The details of the claim and the payment amount are inserted into the template and the letter is generated.

Holding a requirements workshop

Having sorted through how the work of the Claims Processing Department fits with the Transaction Pattern, Emily now wants to convene a workshop to discuss future requirements with her peers. She finds a date when the most experienced people are available for the whole day, then she chats with each of them individually to ensure they understand why it is important for them to attend. Emily also identifies three new hires in the department who seem to have fresh ideas and are open to doing their work differently.

Not feeling confident that she could facilitate the meeting as well as make good notes of the discussion, she invites an expert in the Transaction Pattern, Frank, to be the facilitator as well as an impartial observer.

Opening the workshop, Frank presents an overview of the Transaction Pattern and how it will help the team to design a better process. Then he leads the group through each phase of the Transaction Pattern, asking open questions at each step that stimulate the participants to share their knowledge and make observations about flaws in the current processes and systems.

Working through each task of the standard Transaction Pattern in turn, Frank writes notes on sheets of paper pinned to the wall of the room. From time to time, usually when the discussion revolves on a complex topic, Frank hands out colored sticky notepaper and invites the participants to write down data needs, business rules, the names of forms and letters, and the current issues that bother them, and to place them on the big sheets. Then Frank reads through all the sticky notes, aggregates similar notes, and moves them to where he thinks is the best place for them in the flow of the Transaction Pattern. Emily notices how this is a very efficient technique for extracting knowledge from people and stimulating group discussion about anything controversial.

The day progresses in this way until they reach the end of the Complete phase of the Transaction Pattern. Frank and Emily thank everyone for their active participation and they explain what will happen next. Emily takes photographs of all the sticky notes and wall sheets to distribute to the participants to encourage them to keep thinking about the issues. She gathers up all the sheets of paper to use as memory joggers when she sits down to compile the Transaction Requirements Document, which is the next step.

Creating the transaction requirements document

Emily now has the task of transforming the output from the requirements workshop and any other discussions into a formal document which details the business requirements for the Submit claim transaction. Emily is best placed to write the document, as she is now thoroughly familiar with the Transaction Pattern and how her peers would like to see things change. Another person could do this job – like another subject matter expert, a business architect, or a business analyst – as long as they were closely involved in the requirements workshop.

Recalling the structure for the transaction requirements document that we proposed in Chapter 9, Emily organizes her document into four major parts. These four parts, and a few points about what Emily includes in each, are outlined below. These points are not exhaustive but are intended to illustrate the kind of content that the author should include and how the content should be expressed.

Part 1: Introduction

• In addition to the normal introductory comments that describe the purpose of, and the audience for, the document, Emily realizes that she needs to be clear about the scope of the document – i.e. what’s in the document and what is not. Emily’s scope statement states that the Submit claim transaction includes the creation, validation, submission, assessment, approval and payment of claims for all policy types. The scope does not include disputed claim settlements, which are the subject of the Lodge dispute transaction.

Part 2: Transaction Overview

• To create her overview of the transaction, Emily assembles the various diagrams and descriptions outlined earlier in this chapter. These include: the customer journey map, the service blueprint, and the business data model. Also, Emily emphasizes the importance of the Submit claim transaction, since it is one of only two foundational pillars of Rebel Insurance, the other being selling insurance policies. The efficiency with which Rebel Insurance processes claims has a huge effect on the company’s profitability.
• Emily also provides a brief section that states the things that must be true before a Submit claim transaction can commence (its pre-conditions) and the conditions that will exist when the transaction is finished (its post-conditions). These help readers of the document to be clear what triggers the transaction and what the result is.

Part 3: Transaction Requirements

• This part of the document specifies the detailed business requirements for each of the tasks throughout the Request and Response stages of the transaction. Each task is addressed in the order of the real-world sequence of operations. The contents of some key tasks are highlighted below.
• The Preparation task includes a list of the data that the claim submitter must complete. A sample from Emily’s list follows:

• The Post-submission Validation task specifies the rules that need to be checked before allowing the claim to be accepted for assessment. These include:
  • o “Check the claimed loss is covered by the identified policy.”
  • o “Check the contents of attachments are relevant to the claimed loss.”
• The Classification task assigns the claim to the most appropriate work queue, so that it is handled by the correct team. It does this by assigning the Evaluation, Recommendation, and Approval tasks to the best queue, according to the business rules that we outlined earlier – i.e. the complexity of the claim, its potential value, and the policy type. Emily lists these task distribution rules in a table.
• The Evaluation task section lists the criteria that the claim assessor must consider, such as “Does the supplied evidence support the claim?” and “What portion of the loss is Rebel Insurance liable for?”
• The Record Creation task specifies the data that must be stored in master data, including the Claim data and its attachments, data about the Decision made by the Approver, and data about any settlement Payment that was made.

Part 4: Operational Requirements

• The final part includes the system performance requirements, such as “Availability – 99% during specified Hours of Operation.” This part also includes any levers and switches that the business unit wants to be able to adjust without needing IT system changes, for example: “Add and remove queues and queue allocation rules in the Classification task.”

Improving the transaction requirements document

With the first draft of the requirements document completed, Emily circulates her draft to the participants of the requirements workshop. She asks them to check that she has recorded the workshop discussion accurately. Then she asks them if they have had any other thoughts about things that were missed during the workshop or any new ideas.

Emily takes all this new input and edits her first draft, producing a second draft that is ready for broader distribution and review. After she has dealt with all the feedback from the broader group of stakeholders, Emily feels that the requirements document reflects a sound and much-improved way to process claims. The document is ready to be shown to the managers of her department. She proceeds by giving them a brief outline of how the proposed set of requirements based on the Transaction Pattern is structured and how it will change the way work is handled, making significant improvements in the department’s efficiency and effectiveness. Emily then seeks endorsement from the team leads and, finally, formal approval of the document by the Claims Executive.

Communicating the transaction requirements document

Emily has kept the key players of the IT and user experience teams and (especially) her business architect, abreast of the emerging requirements and has explained to them how the Transaction Pattern gives the requirements a logical structure. With approval of the Transaction Requirements Document behind her, Emily can now turn her full attention to communicating the revised requirements more fully to those teams – she can say to them authoritatively now: “this is what we want you to build.”

Three key points from this chapter

• The case study illustrates how to use the Transaction Pattern in Emily’s situation.
• After understanding the business context of her transaction, Emily aligns the business process with the Transaction Pattern.
• Emily’s requirements workshop gets all the key players aligned with the Transaction Pattern and allows Emily to rapidly discover more business requirements.