Application of the Design Thinking Approach to Process Redesign at an Insurance Company in Brazil

Appendices

Appendix 1

1.1 Workshops Conducted and Tools Applied During the Empathize Stage

1.1.1 Workshops Conducted During the Empathize Stage

Kick-off Workshop

During the kick-off workshop, a facilitator from ADDTECH clarified all aspects of the planned Sessions to the members of all four groups involved. The facilitator presented and discussed the work proposal, reached a consensus about the activities to be performed, and emphasized that participation and engagement in the Sessions was vital for their success. All participants then collaboratively defined the procedures and rules during the Sessions, and the facilitator answered the participants’ questions.

Some participants (mostly supervisors and managers) tried to divert the workshop focus to activities with which they were more familiar. As a result, the facilitator had to stop the workshop occasionally to explain again the stages of work and improve cooperation among the participants.

Immersion Workshop

The purpose of the immersion workshop was to clarify the problem and its characteristics from the client perspective. Resulting customer requirements could then guide the development of the services to be offered by the information system. During this workshop, it became clear that the WGs had no common understanding of ANR materials, as the participants disagreed on what should and should not be considered ANR materials and how such materials could be registered in the information system. ADDTECH also saw that the existing information system had been developed without a comprehensive understanding of the processes it was intended to support, so it was necessary to review the planned Sessions and work steps to address both the definition and the procurement process for ANR materials.

1.1.2 Tools Applied During the Empathize Stage

Process Design Canvas

The goal of the Process Design Canvas (Fig. 7) was to compare the existing information system’s features with those the users (clients) wanted. In order to understand the existing process (the as-is process), representatives of each WG described (a) the course of the process, (b) results of the process, (c) resources required to perform the process, and (d) existing obstacles to performing the process. Figure 4 depicts the resulting as-is process model.

Fig. 7

Process design canvas (designed by José Ricardo Cereja)

Value Proposition Canvas

The goal of the Value Proposition Canvas (Fig. 8) was to set the path from the as-is process to the to-be process by following the concept that each product or service must deliver value to the customer/user. Members of all WGs participated in the canvas development. First, each participant described (a) current “pains” (difficulties) related to the use of the procurement system and (b) the “gains” they would obtain (or expect to obtain) if the system works optimally. Then the participants described (a) what products or services correspond to customer/user activities specified, (b) what “pain relievers” could address the existing difficulties, and (c) what “gain creators” could support achieving the potential gains specified.

Fig. 8

Value proposition canvas (Osterwalder and Pigneur 2010)

In the next step, the participants used the same procedure to select, cluster, and synthesize the information from all Value Proposition Canvasses. These syntheses were then compared, generating 133 requirements for the desired information system that reflected the users’ needs and expectations (called “value propositions”). Information about these value propositions formed part of the Business Model Canvas built in the next stage.

As a result of the previous step, the participants learned the as-is process, agreed on its authenticity, and recognized the need to review the activities and tasks. They also tried to analyze the process’s system use, but no one could explain why the system was built as it was and why it had the identified gaps. The use of Value Proposition Canvas revealed (a) the global quality issues that should be addressed by the system, such as agility, accuracy, and reliability, and (b) the features necessary to implement improvements.

The participants faced problems in understanding how to apply this tool. The Value Proposition Canvas should be filled in the following order: (1) user activities, “pains,” and “gains” and (2) what products and services can meet the users’ activities, what solutions address the “pains,” and what generates the “gains.” It was difficult for the participants to distinguish these aspects of the issue, so their responses were analyzed and revised in an iterative way. The confusing responses were clarified and rewritten, and similar responses were grouped.

1.2 Workshops Conducted and Tools Applied During the Define Stage

1.2.1 Workshops Conducted During the Define Stage

Material Definition Workshop

The Material Definition workshop involving WG representatives was not planned initially but was added once ADDTECH realized that there was no shared understanding of ANR materials. These materials had been ordered by email or phone with no prior analysis, authorization or registration in the information system. The aim of the workshop was to reach a consensus among the WGs on the definition of ANR materials.

Process Design Workshop

The goal of the Process Design Workshop involving WG representatives was to design the to-be process, where the information system would be employed to manage the procurement process of all company materials (including ANR materials). Prior to designing the to-be process, participants had reached a common definition of ANR materials and a common understanding of how the procurement process (particularly purchasing of ANR materials) had been performed. The participants could then define the target purchasing process and the features the new information system should have.

Business Model Workshop

The subsequent Business Model workshop involving PT members determined the value that the updated information system was to bring its users, future users, and the company as a whole. Based on this knowledge, the PT could then determine how this value could be delivered in the most efficient way and the associated costs.

1.2.2 Tools Applied During the Define Stage

Definition Canvas

The goal of the Definition Canvas (Fig. 9) was to support finding a common definition of ANR materials. For that, WG representatives specified, why ANR materials need to be there. Participants used sticky notes to express their ideas, and then each participant went through and considered all the points made by the whole group and proposed a list of features that might define an ANR material. Finally, WG representatives agreed on a common definition of an ANR material (presented in the Sect. 4).

Fig. 9

Definition canvas (designed by the ADDTECH Team)

This work was first attempted through an open discussion in an effort to include individual perspectives, but it was soon apparent that brainswarming was required. The applied Product Definition Canvas gave the participants the opportunity to present their perceptions and understanding about what ANRs are and what they should be.

Process Design Canvas

The goal of the Process Design Canvas (Fig. 7) at this stage was to support the design of the desired material-purchasing process (“to-be process”), with the procurement of ANR materials as one of its sub-processes. Application of the Process Design Canvas followed the same steps as were followed during the empathize stage for the as-is process model design. The resulting to-be process and the ANR sub-process are presented in Figs. 5 and 6, respectively.

Business Model Canvas

The goal of the Business Model Canvas (Fig. 10) was to formalize (a) the requirements of the information system, derived from the resulting Value Proposition Canvas developed during the Immersion sessions, (b) the customers who receive direct benefits from using the information system, (c) how user support should be organized, (d) the information system’s key activities and the key features required, and (e) partners who would be key to ensuring the system worked properly.

Fig. 10

Business model canvas (Osterwalder and Pigneur 2010)

1.3 Workshops Conducted and Tools Applied During the Ideate Stage

1.3.1 Workshops Conducted During the Ideate Stage

Stories and Requirements Workshop

During this workshop, the participants of all three WGs gathered to describe as stories each of 133 requirements that they generated through the Value Proposition Canvas during the empathize stage. Each story focused on describing a service that fulfilled a client need or desire. As a result, duplicate or similar requirements were identified and merged, and the requirements were reviewed and rearranged, resulting in 43 requirements that were fundamental to improving the information system.

Prioritization Workshop

During the subsequent Prioritization workshop, the participants of all three WGs met to analyze the 43 final requirements that had been extracted, grouped, and ranked during the Stories and Requirements workshop. The goal was to identify the most important features that should be prototyped and implemented.

1.3.2 Tools Applied During the Ideate Stage

Story Cards

The goal of the Story Cards tool (Fig. 11) was to translate the clients’ requirements to the features to be implemented in the information system. Each of the three WGs received about a third of the 133 value propositions identified during the empathize stage. The task was to describe the service behind each requirement. The interdisciplinary nature of each WG and the opportunity to communicate with the members of the other WGs facilitated the discussion of the nature of each requirement and ensured consideration of diverse opinions. The check for duplicate or similar value propositions reduced their number from 133 to 80. The stories written for the remaining 80 value propositions contained customer identification (department, position), the requirement’s level of importance to the customer, and the perceived benefit from incorporating this requirement in the information system. In the next step, the PT analyzed and classified the 80 Story Cards and concluded that, in many cases, one solution could address more than one requirement. As a result, the PT defined 43 features that addressed all 80 requirements.

Fig. 11

Story card (designed by the ADDTECH Team)

Participants could describe easily who would benefit from implementation of a certain feature but often faced difficulties in formalizing the motivation for implementing this functionality. Although the initial plan was to write individual stories by each participant, in the course of the workshop the participants organized themselves into groups that interacted with each other. This collaborative process accelerated the stories’ construction, which were beneficial in understanding the required system features.

Prioritization of Requirements Canvas

The goal of the Prioritization of Requirements Canvas (Fig. 12) was to support ranking of the features to be implemented in the information system, based on three criteria:

• Added value: the extent to which the functionality a requirement generated improved the overall service the information system delivered.

• Technical competence: the level of expertise required from the development team to implement a requirement.

• Development easiness: the level of effort (time) required of the development team to implement a requirement.

Fig. 12

Prioritization of requirements canvas (designed by the ADDTECH Team)

1.4 Workshops Conducted and Tools Applied During the Prototype Stage

1.4.1 Workshops Conducted During the Prototype Stage

Functionality Requirement Workshop and Development Planning Workshop

Based on the input from the Prioritization Workshop, during the Functionality Refinement workshop WG representatives and the PT jointly categorized each feature’s importance as large, average, or small. All participants then discussed and elaborated on the plan for implementing the feature during the Development Planning Workshop.

1.4.2 Tools Applied During the Prototype Stage

Flip Chart

The goal of the Flip Chart was to encourage the participants to express their thoughts on detailing, adjusting, and ratifying the features to be developed and implemented.

Project Model Canvas

The goal of the Project Model Canvas (Fig. 13) was to assist the participants in elaborating on the project plan for implementing the improved information system. The participants placed on the canvas the important attributes to be considered when managing any project, including the work to be done, the timeline, and the effort required. The plan was designed following the agile software-development methodology, where the tasks are accomplished in iterations (sprints).

Fig. 13

Project model canvas (Finocchio 2013)

Appendix 2