Stefan’s Insurance Story

When an insurance company decided to acquire a new software system for customer relationship management (CRM), they asked me to help them with the selection process. One important constraint was that the new CRM system had to be off-the-shelf software. Company guidelines required at least three comparable offers from suitable vendors. To achieve that, the company followed a multistage process:

1. Research the market to identify about ten possible vendors.

2. Give those vendors equal access to a requirements document and ask them for offers.

3. Compare the offers using a weighted decision matrix.

4. Invite the top three vendors to give a demo to sales representatives (the future users of the system) and other stakeholders.

5. Evaluate the demos and factor the results in the decision matrix to make the final decision.

I had worked with the insurance company before to analyze their IT landscape. We had modeled many AS-IS, DIGITALIZED domain stories then, including those relevant to a CRM system. For selecting the new CRM system, we used domain stories for steps 2 and 5 of the selection process.

The requirements document was largely comprised of functional requirements (of course, it also described technical constraints and quality requirements, but those are not relevant to this story). We used several sources to come up with functional requirements: features that the old CRM had, features we discovered during market research, and features the sales representatives considered useful. However, we did not provide only a list of functional requirements. We also provided domain stories that we had modeled with sales representatives and other stakeholders. The stories showed how they wanted to use the system and how it would integrate with existing software systems.

The scope of the domain stories was TO-BE and rather FINE-GRAINED (about sea level). We chose to tell DIGITALIZED stories (with software systems). That allowed us to express our expectations, for example:

• That the document management system should notify the CRM if customers send or receive letters

• That changes to contracts in the host system need to be reflected in the CRM

• That interactions between the customers and the telephone customer support need to be documented in the CRM

When we asked vendors for their offers, we made clear that the domain stories were suggestions. We asked them to clarify if the processes we had described could be realized with their software or if they had suggestions that would improve the processes. The answers that the vendors gave us were useful for determining how much customization would be necessary for a system. For every process, we could ask ourselves: Do we pay to customize the CRM so it fits the intended process? Or should we instead change the intended process to fit the CRM?

To help the vendors understand the domain stories, we did not provide just the pictures; we provided a textual description, similar to a use case (see Chapter 7, “Relationships to Other Modeling Methods”). After all, we could not talk to vendors directly until step 4 of the process, the demo.

In the fourth step, the domain stories played another role: We asked the vendors to prepare a demo that reenacted the most important domain stories. This made it easier for the stakeholders to compare the demos because all three vendors followed the same “screenplay.” The survey after the demos resulted in a clear ranking of vendors. Ultimately, the vendor that won the demo round also had the highest overall score and won the contract.

Back to the Leasing Example

In Chapter 10, “Finding Boundaries,” we found the bounded contexts for Alphorn. For the context “offering,” the IT department is working on implementing their own solution (see Chapter 11 and Chapter 12). Now, for the “payment” context, Harold, the head of IT, considers purchasing an off-the shelf product. (See Figure 14.1.)

Figure 14.1 Context map for Alphorn, focus on “payment”

Harold wants to compare the different solutions that are offered in the market: the two competitors Paynator and GreatPay. He asks us for support.

As a first step, we meet with Amin, the domain expert from the accounting department to model FINE-GRAINED, PURE domain stories for the “payment” context. The stories will help to define what requirements a solution has to fulfill. Two cases are looked at—a successful payment (the standard case; see Figure 14.2) and a missing payment (see Figure 14.3).

Figure 14.2 Alphorn 8: Payment, standard case—PURE

Figure 14.3 Alphorn 9: Payment, missing payment—PURE

Now that the team understands the PURE process, they look at how the process would change with the different offered systems. Like in Chapter 13, “Supporting Organizational Change,” we use color to mark what is new in a process: green in the e-book, dark gray in print.

The team evaluates the Paynator system first (see Figure 14.4).

Figure 14.4 Alphorn 8a: Payment, standard case—DIGITALIZED—with system Paynator

As you can see, the accountant would have less work, because they wouldn’t have to manually search for the payment of the monthly installment into the bank account anymore.

The team moves on to review GreatPay. The process with this system looks a bit different (see Figure 14.5).

Figure 14.5 Alphorn 8b: Payment, standard case—DIGITALIZED—with system GreatPay

With GreatPay, the work of the accountant is fully automated and is done entirely by the system.

From this first evaluation, GreatPay looks like the winner. But how about the other case? Again, the change is modeled as domain stories. Let’s first look at Paynator in Figure 14.6.

Figure 14.6 Alphorn 9a: Payment, missing payment—DIGITALIZED—with system Paynator

In this story, the system does everything the accountant had to do before.

Compare it with GreatPay (see Figure 14.7).

Figure 14.7 Alphorn 9b: Payment, missing payment—DIGITALIZED—with system GreatPay

Here, the dunning ²has to be done by the accountant. In this scenario, Paynator looks like the better-fitting tool.

² “Dunning” is a domain term that describes the process of reminding customers who owe an installment.

Based on this evaluation, Alphorn can compare the two tools. Since dunning had caused a lot of errors in the past when it was done manually, the management decides to buy Paynator instead of GreatPay.