Intership Report Appendices Ing Chile By Hennis & Van Waalwijk

Appendices INSURANCE & PAPER An analysis towards the possibilities of digitalization and a more computerized future within the subscription process

Issued by T.A. Hennis & J. van Waalwijk, May 26, 2005

Chile –

University of Technology

26 May 2005

Table of contents Appendix 1 IDEF0 Diagram A0........................................................................................................................................4 Appendix Appendix Appendix Appendix

1.1 1.2 1.3 1.4

IDEF0 IDEF0 IDEF0 IDEF0

Diagram Diagram Diagram Diagram

A0 Level-1..........................................................................................................................................5 A3.....................................................................................................................................................6 A4.....................................................................................................................................................7 A5.....................................................................................................................................................8

Appendix Appendix Appendix Appendix Appendix

2.1 2.2 2.3 2.4 2.5

IDEF0 IDEF0 IDEF0 IDEF0 IDEF0

Diagram Diagram Diagram Diagram Diagram

B0 Level–1........................................................................................................................................10 B1....................................................................................................................................................11 B2....................................................................................................................................................12 B4....................................................................................................................................................13 B5....................................................................................................................................................14

Appendix 2 IDEF0 Diagram B0........................................................................................................................................9

Appendix Appendix Appendix Appendix Appendix Appendix

3 – Object description....................................................................................................................................15 4 – Interaction-flow diagram Part 1.................................................................................................................17 5 – Interaction-flow diagram Part 2.................................................................................................................18 6 – Demarcation and assumptions...................................................................................................................19 7 – Specifying processes...............................................................................................................................21 10 – Simulation set-up...................................................................................................................................24

Warm up period...........................................................................................................................................................................24 Number of replications.................................................................................................................................................................24

Appendix 11 – Verification............................................................................................................................................26 Appendix 12 – Validation..............................................................................................................................................28 Appendix 13 – Computerization options, process changes.................................................................................................30

Evaluation module.......................................................................................................................................................................30 Business Rules Engine..................................................................................................................................................................30 All paperwork digitalized...............................................................................................................................................................30 Agent with IPAQ..........................................................................................................................................................................31 Web based application..................................................................................................................................................................32

Appendix 14 – Demarcation and assumptions digitalization...............................................................................................34

Digitalize paperwork of sales division.............................................................................................................................................34 Agent with IPAQ..........................................................................................................................................................................35 Web-based subscription................................................................................................................................................................36

Appendix 15 – Interaction-flow diagram part 1, Evaluation Module and BRE........................................................................37 Appendix 16 – Interaction-flow diagram, digitalized sales division......................................................................................38

16.1 – part 1..............................................................................................................................................................................38

Appendix 17 – Interaction-flow diagram, all digital..........................................................................................................40

17.1 – part 1, iPAQ......................................................................................................................................................................40

2

Chile –

University of Technology

26 May 2005

17.2 – part 1, Web based application.............................................................................................................................................41 17.3 – part 2..............................................................................................................................................................................42

Appendix 18 – External variables..................................................................................................................................43 Appendix 19 – Recommendations..................................................................................................................................45 Process......................................................................................................................................................................................45 Scenario-analysis........................................................................................................................................................................45

3

Chile –

University of Technology

26 May 2005

Appendix 1 IDEF0 Diagram A0 Process controls • Availability resource • Process time

Status • Quality • Completeness • Accuracy

Location

Cooperation

Request client

Rejected request

Subscription Health Insurance contracts I Request for digitalization

Canceled request (B23)

A0

Controller

Sales agent

Client

Sales Manager

Front office employee

The first part of the subscription part deals with the request for an insurance policy by a client. The sales agent of individual sales (further on called as ‘sales agent’) obtains the necessary information and approves the request of the client. Roughly the process can be divided into four main processes. These are in the following order: Capture client information, Revise and categorize request, Evaluate request and Inform client. 4

Chile –

University of Technology

26 May 2005

Appendix 1.1 IDEF0 Diagram A0 Level-1 Process controls

Cooperation

Capture client information at front desk

Status

Request for missing info

A1

Request client

Capture information during visit

Request to controller

Revise and categorize request

A2

A3

Rejection

Evaluate request A4 Ok Supervisor Authorized request Request with nothing to declare

Inform client

To DF

A5

Front office employee

Sales agent

Sales Manager

The process starts when a client requests an insurance policy or an agent sells a policy by phone. The front desk employee will ask the client to fill out a declaration form (A1). Another possibility is when a Sales agent calls client if they are interested in a policy. If so, the sales agent will make an appointment to visit the client. (A2) After the sales agent or front office employee captures the necessary information the declaration will be sent to a sales manager of individual sales (further on called as ‘sales manager’) who will revise and sign the declarations (A31). 5

Chile –

University of Technology

26 May 2005

Appendix 1.2 IDEF0 Diagram A3 Status

Request client

Process controls

Revising and Signing A31 Categorize request

Request with nothing to declare Information missing Request ok supervisor

A32 Request to complete form

Request for missing info

A33

Send request to controller Request for analysis

Sales Manager

Request to controller

A34

Sales agent

The request will be categorized by the sales manager into four different client requests (A32). First there is an possibility of an incomplete declaration form, the sales agent will then ask the client to complete the form (A33). Complete declaration forms can be divided in three kinds of requests: 1. Request, which will be send to Medical Control for a technical analysis (A34) 2. Request, which is OK at Supervisor Level 3. Request, where the client has nothing to declare

6

Chile –

University of Technology

26 May 2005

Appendix 1.3 IDEF0 Diagram A4 Status

Cooperation

Process controls

Request for add background

Request to controller

Technical Analysis A41

not delivered by client

Get additional background information

Rejected request

A42

Reject request Received additional background

Request not ok

A43

Authorize request Request ok

A44

Print declaration Request Ok supervisor

Authorized and printed request

A45

Controller

Sales agent

Sales Manager

Request 1 (previous page) will be analyzed by a controller, for a medical control (A41) and results into three different outcomes: a. Request, which needs additional background information, which goes to the sales agent who tries to retrieve the additional background (A42). When the client’s additional background is received, the request will be send back to the Technical analysis (A41), if not, the request will be rejected and the client will be notified (A41). b. Rejected request, rejection will later be sent to client (A43). c. Authorized request, is just as Request 2b (Authorized and Ok supervisor level requests) are printed out (A45) and made ready for sending. 7

Chile –

University of Technology

26 May 2005

Appendix 1.4 IDEF0 Diagram A5 Status

Authorized and printed request

Rejection to client

Cooperation

Process controls

Send information to client A51 Sign restrictions Restrictions not accepted

A52

Rejection

Mark declarations

Request with nothing to declare

A53

Restrictions accepted Canceled request (B23)

Fill out documents A54

Sign documents (by client)

Request for digitalization

A55

Sales agent

Sales Manager

The declarations will be sent back to the client (A51). The client then has to accept the declaration with restrictions. When the client accepts (or not) the restrictions in the declaration and signs the document (A52) it will be sent back to a Sales manager, who marks the declaration form (A53). The accepted requests will be sent by the manager to the sales agent at the end of the day. The agent will fill out the request documents so the client can sign these (A54 and A55). 8

Chile –

University of Technology

26 May 2005

Appendix 2 IDEF0 Diagram B0 Process controls  Availability resource  Process time

Status  Quality  Completeness  Accuracy

Location

Cooperation

Date

Rejection, canceled RQ RQ - for digitalization

Subscription Health Insurance contracts II

RQ - complete

RQ - for completion RQ - mail

B0

Chief sales

Employer

Service assistant

Sales agent

This part of the subscription process deals with the digitalization, approval and completion of requests. Also an interaction takes place between the sales and the employer. This is just a short overview of the different processes and their sequence, the SADTdiagrams provide a more elaborate view, including their sub-processes, their interactions and the resources. 9

Chile –

University of Technology

26 May 2005

Appendix 2.1 IDEF0 Diagram B0 Level–1 Location (employer/client)

Date

Cooperation

Process controls Status

RQ for notification

Digitalize RQ

RQ for digitalization

B1

Rejection Canceled RQ FUN with error

Process notified RQ B2

RQ with errors

Notified RQ

Sign RQ B3 Approve RQ

Notified RQ

Approved RQ

B4

RQ - complete

Complete RQ

RQ - for completion

RQ - mail

B5

RQ - control

Service assistant

Employer

Sales agent

Chief sales

Laying off When a request, or FUN (name of the form, part of the request) 1, enters this part of the process, a distinction is made between those that arrive before and after a certain date. The ones that are late go immediately to the completion process (B5), after which all processes will be dealt with manually at ‘Control Production’. The other flow goes into the digitalization process (B1). 1

See demarcation in Appendix 6

10

Chile –

University of Technology

26 May 2005

Appendix 2.2 IDEF0 Diagram B1 Date

Form with error

RQ - for digitalization

Process controls

Location (employer)

Digitalize RQ B11

Send RQ other city

RQ for notification

B12

Notify employer

Notified RQ

B13

Sales agent

Service assistant

The orders that have to be digitalized go to three processes of digitalizing, which are modeled as one (B1), because they are all subsequently done by the same resource. After this process one flow of requests goes to the employer of the person with the request, who has to decide upon acceptation of this request. The other flow goes, after signing (B3) and checking on errors, to approval. 11

Chile –

University of Technology

26 May 2005

Appendix 2.3 IDEF0 Diagram B2 Status

RQ - for notification

Location client

Cooperation

Process controls

Accepted RQ (SF)

Receive notification Rejection, no employee

B21

Copies not delivered

RQ (SF)

Inform client and get copies

Canceled RQ

B22

Cancel RQ and take care of errors

Canceled RQ (S)

B23 Rejection, special case

Employer

Sales agent

Chief sales

The employer decides upon acceptation after receiving the notification. A request can be accepted or rejected, and the latter can have two causes. One of them is because the person of the request is no employee or there is an error in the notification. The average time an employer needs is a week. The rejections have different follow-up processes. The first regards another interaction with the client, where the right documents are being tried to be recovered (B22). If this process is successful, the request will be canceled, otherwise the request will go back to the signing part of the digitalization process (B3). The second possible rejection, because it is a special case, starts a process of canceling the request and taking care of the error2 (B23). This results in another flow, back into part 1 of the subscription process. 2

This can be a mistake in the application, e.g. wrong address. The process will start over again.

12

Chile –

University of Technology

26 May 2005

Appendix 2.4 IDEF0 Diagram B4

RQ for approval

Cooperation

Process controls

Status

Approve RQ B41

Approved

Approved RQ

Prepare submitted documents Authorized RQ

B42

Copies not delivered

Authorization VP

Denied

Inform client and get copies B43

Chief sales

B44 Canceled RQ

Sales agent

There are two possibilities for approval, which are of course positive and negative. If a request has been approved it flows from prepare deliveries to completion (B5). The negative approval, i.e. denial, starts another interaction with the client, again to recover the client’s copies and retrieve the legal documents (B43). When the client does not hand over the documents, the request has to be passed on to the VP Sales for authorization (B44). After authorization it flows as well to prepare deliveries and completion. 13

Chile –

University of Technology

26 May 2005

Appendix 2.5 IDEF0 Diagram B5 Process controls Status

Authorized/ accepted RQ RQ - for completion

Prepare submitted documents B51

RQ - mail

Complete request

RQ - complete

B52 RQ - control

Receive, digitalize, prepare B53

Checked RQ

Chief sales

This process starts with the completion of the submitted documents (B51-2), which is followed by a black box process of checking all the requests by ‘Control Production’ (B53). This is a separate and demarcated department. Within this process there are three different outputs:  RQ with error  Approved RQ  Rejected RQ The RQ with error and the Approved RQ are both checked whether they are notified, because when they were laid off at the start of this second part (they were too late), they could be unnotified. If so, the process of notification, which is done by an external company, and all other possible follow-up processes are done within the responsibility of Control Production. The requests, which contains reviewed errors, and the direct approvals than go to mail. 14

Chile –

University of Technology

26 May 2005

Appendix 3 – Object description Beneath are the different object types listed, with their primary attributes and actions. This information is in accordance with the IDEF0 diagrams. The table is useful in communicating and looking up the different aspects of the most important objects in the system. A more elaborate description of the actions of the different resources will be handled elsewhere, see appendix 7 Specifying processes. Object type Resource Client

Attributes

Actions

Location Status (at home) Level of cooperation (deliver copies)

Sales manager

Location Responsibility Speed Working hours Utilization

Sales agent

Location Responsibility Speed Working hours Utilization Location Responsibility Speed Working hours Utilization Location Responsibility Speed

Fill out forms Receive information Receive agent Deliver forms Sign restrictions Sign documents Digitalize declaration Signing papers Authorize Accept/reject Revise forms Fill out forms Prepare forms Handling papers Visit client Call client Fill out forms Recover forms Prepare forms Serve client with filling out declaration and enclose background Digitalize declarations

Front office employee

Service Assistant

Notify employer Send documents 15

Chile –

Employer Controller (Technical Analysis)

Controller (Control Department)

Documents Request

Client’s documents Other Process

Decision

University of Technology

26 May 2005

Working hours Utilization Location Fill out forms Accessibility Accept/reject notification Speed of handling Send forms Location Perform Technical analysis Responsibility Speed Working hours Utilization Location Control production Responsibility Speed Working hours Utilization Attributes Status (checked, signed, accepted, rejected etc.) Time in process Completeness Physical attribute (digital/physical) State (delivered) Physical attribute (digital/physical) Kind of process Time, distribution Average queue Quality (reprocess needed?) Dependence (previous processes, resource) Probability/distribution Location in process

Table 1 - Object description

16

Chile –

University of Technology

26 May 2005

Appendix 4 – Interaction-flow diagram Part 1 Client Client enter FrontDesk

Sales

Medical

Call client for an appointment Digitalize declaration Visit client

Revision & signing Fill out declaration form and enclose background

Categorize

Incomplete

Request to complete form

OK Nothing to declare

OK Level Supervisor

TA

OK Level Controller

MS

Send request to controller

Technical Analysis

Decision

Print declaration

ACCEPT

NO

Authorize request

Send information to client

Send rejection to client

Mark declarations Not specified

End

Reject

Ask background

YES End Sign restrictions Mark signed declaration

S

Sign document by client

MS

Fill out documents

L

NO

Deliver background

Get background

End YES

Receive and send background

TA

17

Chile –

University of Technology

26 May 2005

Appendix 5 – Interaction-flow diagram Part 2 Client

Sales

Control Production

Employer

Mail

L

Laid off Production

YES

Prepare submitted documents 1

C

NO RQ Notified

YES

RDE

Send RQ other city

NO

Digitalize RQ

E1

Notify employer

YES

One week between send and receive notification, done by external company

Digitalization Errors Sign RQ

SF

NO

RC

E

Delay at employer

M Contact and inform clients

Deliver copies

NO

Recover client copies

YES

Cancel RQ, DS not specified

Request Authorization VP.Sales

NO

Approve RQ

YES

Prepare submitted documents 2

Prepare submitted RQ for signing

Mail process

Outcome

C

End1

End

Complete submitted electronic and physical documents

Control product ion

Approval

No employee

Error

Outcome control Review errors

Check submitted documents with errors

Error

Prepare submitted documents 3

Appr.

Rej.

SF

RC

End3 RQ Notified

YES

NO

S

M

E2

Cancel RQ and take care of errors

18

Chile –

University of Technology

26 May 2005

Appendix 6 – Demarcation and assumptions 1. There is only one kind of entity flowing through the system, this entity represents the request of a client, even when it (for example) changes in a notification to employer, declaration or another kind of document. 2. The monthly average number of requests is 7500, assumed is that clients request policies 12 months per year. A year has 52 weeks, a week 5 days and a day 10 hours. Therefore we assume that the average number of clients per hour is around 35 clients and around 346 per day. 3. The distribution between clients that enter the underwriting process via the front desk and via sales agents who call them and visit them afterwards is assumed at 5% - 95%. 4. The process of calling a client and make an appointment will only be modeled with clients who accept the offer. The time of calling clients who are not interested is calculated in this time. The duration per call without result is assumed at 11 minutes and with result at 21 minutes. Furthermore is the distribution of calls with-without result assumed by colleagues at 90%10%. Hence, 9x11min + 21min = 120 minutes for every call with eventually a result. 5. After calling the client for a first appointment it is modeled that the sales agent then directly will visit the client. In reality the sales agent will make an appointment for a few days later, but in the model it is assumed that when a sales agent has sufficient free time to visit the client, that he will do so. 6. The working hours are between 9am and 7pm every day of the week except Saturday and Sunday. Every employee has a lunch break of 1.5 hours. 7. Friday, except for the front desk employees, the sales agents and sales managers often leave the office 2 hours earlier (4.7% more scheduled utilization). This is not included in the simulation. Hence, this has to be taken into consideration when drawing conclusions about the utilization of the resources. 8. Only working days, including lunch breaks, are simulated. This has been taken into account with routing times and results of several days. For example asking additional background from client, which takes 8 days in total in the simulation. This will take in reality about 10 days. 9. In reality, a client will always be served by the same agent. This will not be simulated because simulating this is too complex and useless, because it doesn’t have any influence on the outcomes. 19

Chile –

University of Technology

26 May 2005

10.The decision taken after the technical analysis takes 10 minutes. That is excluding the process times for sending the documents. 11.We assume that there is always an equal amount of front desk employees present at every moment of the day, except during lunchtime, from 14.00 until 15.00. They help the clients that are waiting before going to lunch. 12.Reprocesses have a higher priority than the other processes and are done instantly. 13.Front office employees serve clients at the front office with the following processes: Fill out declaration form, enclose background and digitalize declaration. 14.The 3 processes of reviewing errors after ‘Control Production’ are taken together into one, because they are subsequently done by the same resource. 15.The Technical analysis will be seen as a black-box model in this analysis. Every day, incoming declarations will be processed and the (different) resources will not stop working after they finished every incoming declaration of that day. Therefore all the incoming requests are handled within a day. 16.Every request that enters the Technical Analysis process will be finished at the end of the day, even if that means working late. ING is interested in the utilization of the controllers who perform the technical analysis, and because they sometimes work overtime, we created an extra resource, representing the Controllers working overtime. 17.After the Technical Analysis decisions have to be made about the request. In 40% of the cases there is a need for asking backgrounds occurs. Assumed is that the expectation that this decision will be made for the second time (after obtaining the background from a client the first time) is around 3%. 18.The agent has to visit clients, which takes time. The time for visiting clients is simulated as a process visiting client. The corresponding time encapsulates the time going back to the office (or home) as well, hence they signify the average travel time per visit. These times are very hard to validate, and are subject to alteration to approximate the utilization of agents better.

20

Chile –

University of Technology

26 May 2005

Appendix 7 – Specifying processes The following tables show all the different tasks of the resources that have been previous identified. The right column shows the average time each process takes, between brackets are the reprocess times. Sales manager Part 1 Minutes Part 2 Minutes Revising and signing 9 (9) Sign Request (2 processes) 7 (7) Judge request (incomplete) 2 Prepare submitted documents 1 5 Judge request (Ok nothing to declare) 1 Prepare submitted documents 2 2 Judge request (Ok Level supervisor) 5 Prepare submitted documents 3 5 Judge request (Ok Level controller) 1 Prepare submitted Request for signing 5 Print declaration 4 Cancel Request and take care of errors 2 Mark declaration not specified 2 Request Authorization VP Sales 3 Mark signed declaration 1 Complete submitted electronic and physical documents 5 Check submitted documents with errors 1 Review errors 5 Sales agent Part 1 Minutes Part 2 Minutes Average calling time per agent per request 120 Recover not notified copies of Request 2 Request to complete form 5 Cancel Request, DS not specified (twice) 3 Send to controller 0.5 Authorize request 10 Other: Front office employee Reject request 10 Part 1 Minutes Ask background 10 Fill out declaration form and enclose background 17 (17) Send information to client 5 Computerize declaration 23 Send rejection to client 6 Sign restriction 5 Get background 7 Other: Service assistant and Control Department Receive and send background 11 Part 2 Minutes Fill out documents 20 Send Request other city (service ass.) 5 Sign documents 5 Notify employer (service ass.) 10 Digitalize FUN (3 processes) 24 (11) Control Production (CP) 7 Recover client copies 3 Contact and inform clients (twice) 10 Table 2 - Process description

21

Chile –

University of Technology

26 May 2005

Appendix 8 – Decisions Part 1 Name Reprocess fill out declaration YES NO Reprocess revising and signing YES NO Request incomplete YES NO Categorize requests Ok nothing to declare Ok Level supervisor Ok Level controller Decide after Technical Analysis Authorize request Reject Ask background Accept restrictions YES NO Deliver background YES NO

1% 99%

Part 2 Name Laid off production (too late) YES NO

1% 99%

RQ notified (2x) YES NO

81% 19%

2% 98%

Digitalization Errors YES NO

30% 70%

Approve RQ YES NO

95% 5%

Deliver copies (2x) YES NO

97% 3%

Outcome control Approved RQ Error Rejected RQ

80% 10% 10%

Outcome (employer) Approval Error No employee

90% 8% 2%

Distribution

20% 35% 45%

55% 5% 40%

95% 5%

80% 20%

Distribution 5% 95%

Table 3 – Distributions

22

Chile –

University of Technology

26 May 2005

Appendix 9 – Routing times In the following table are the routing times listed. Also are there not routings present, but only delays in sending information. These are as well listed in the table. Information document exchange Action Part 1 Visit client Send request for analysis Send authorization Send rejection Ask background Get background from client Send background to Technical Analysis Send restrictions to client Send documents for signing Visit client to complete form Part 2 Send request to employer Delay and receive request from employer Contact and inform client1 Control production

From

To

Travel time (min)

Delay

Sales agent Sales agent Controller Controller Controller Sales agent Sales agent Sales manager Sales agent Sales agent

Client Controller Sales agent Sales agent Sales agent Client Controller Client Client Client

TRIA(80,100,120) 0 0 0 0 TRIA(80,100,120) 0 TRIA(80,100,120) TRIA(80,100,120) TRIA(80,100,120)

<1 1 1 1 6 1 3 5

Min Day Day Day Days Day Days Days

Service ass. Employer Sales agent Sales manager

Employer Service ass. Client Control dept.

0 0 TRIA(80,100,120) 1 Batch per Day

1 5

Day Days

Table 4 – Routing times

23

Chile –

University of Technology

26 May 2005

Appendix 10 – Simulation set-up Warm up period There are different possibilities to deal with the warm up period. A very long run can be simulated in order to diminish the effect of the initial conditions. This is not very desirable, because it takes too much time. Other solutions are to start with higher initial values for certain variables or to include a warm up period in the simulation. Certain important variables are monitored graphically in order to identify the time when they stabilize. Several graphs can be found below that show important variables in the model. These are used to define the warm-up period. The variables that have been chosen to do this are the following: Average waiting time at Control Process, the Scheduled Utilization of the Control department and the Average time that it takes for a (successful) request to get through the system. Control production is a process very late in the subscriptions process. All of the requests flow through it and affect these variables. The average subscription time is one of the most important variables in the system and clearly shows the stabilization point. The runtime is set on 2000 hours.

Figure 1 – Wait time CP

Figure 2 - Utilization CP

Figure 3 - Subscription time

From the first graph a clear change in the curve can be noticed, at nearly 200 hours, but a slight rise occurs a bit later, until 1000 hours. The second graph shows a slight less distinct change, but after 200 hours as well the curve begins to slow down its rise. After 1000 hours the curve is nearly a flat line. The third graph below shows the average time in the system for successful and unsuccessful requests. This is one of the most important factors in the system. This graph as well shows a stabilization after 1000 hours, one hundred days.

Number of replications There are rules to calculate the number of replications. After a number of replications (n) the results are used in order to define the ultimate number of replications at a certain level of accuracy. This can be done using the following formulas and the StudentT distribution: 24

Chile –

h = t n-1,1-α/2 s( x )

University of Technology

2

s (x) 2 s ( x )= n

  h 2  n′ = n     h'  

26 May 2005

h n s (x) h’ n’

= =

= half-width number of replications standard deviation = desired half-value = ultimate number of replications

The results of 5 replications can be seen below. The value represents the average total time an approved request is in the system (hours). 1 2 3 4 5

Value 118.5 118.9 119.0 119.2 118.4 118.8

∆2 0.09 0.01 0.04 0.16 0.16

Using these outcomes the following calculations can be made. s2(x) = 0.115 2 0.023 x s() = t0.975 = 2.78 h = 0.42

Table 5 - Results replications

This indicates that with a certainty of 95% the average total time in the system for approved requests is between 118.4 and 119.2. Now we use the last formula to calculate the number of replications with certain reliability:  h 2 n′ = n   h'   With a 95% certainty that the average total time of approved requests is between 116.4 and 120.4 (h’ = 2), the number of replications has to be 1.

25

Chile –

University of Technology

26 May 2005

Appendix 11 – Verification In this verification a check is done on the calculation of different variables throughout the system. A comparison is made between different output variables and related variables in the model. For each of the chosen output variable a formula is created with different variables that are related to this output variable. Then the output variable is calculated using these variables and subsequently checked with the ‘real’ (output) value. A big difference between the calculated and the computed value could signify a fault in the model. The symbols in the tables correspond with those in the interaction-flow diagram (see appendices 4 and 5). Variable (#) (Categorize) (PrintD) (RecBG) (FO)

Equal to (#) 0.997*Input + Incomplete AUTH(0.55*MD) + OKSUPER (0.35*Input) 0.8*(GetBG(0.4*(OKCONT(0.45*Input)))+3% FBL) NoDECLARE (0.2*Input) + MSD 0.95*PrintD)

Value1 59404 44048 8602 53453

Value2 60710 42482 8413 52090

% 2.2 3.6 2.3 <1

Table 6 - Variables part 1

Legend table 3 PrintD: Print declaration AUTH: Authorize request MD: Make decision OKSUPER: Request categorized at OK level supervisor RecBG: Receive background from client TA: Technical Analysis GetBG: Get background from client after the technical analysis OKCONT: Request categorized at OK level controller FBL: Feedback loop, when backgrounds are received from the clients, they are sent back to the technical analysis. MSD: Mark signed declaration Variable (#) (SignRQ) (E2) (M) (RQ Auth. VP Sales) Σ(Contact&Inform1,2)

Equal to (#) (L)-(C)-(RC)+(RDE) (5/95)*0.86*(E1) (L)-Σ(End1,2,3) 0.03*0.05*((SignRQ)-(RDE)) 0.05(L-C) + 0.95*RC

Value 1 63801 497 41640 61 2714

Value 2 64362 557 42722 73 2736

% <1 12 2.6 20 <1

Table 7 - Variables part 2

26

Chile –

University of Technology

26 May 2005

Legend table 4 L: Signed documents coming from part 1 C: Laid off documents for completion RC: Recover copies (No employee) RDE: Request with digitalization errors E1&2: Notification to employer out of town M: (Approved) request to be sent by mail There are differences in the outcomes, and for two variables these look pretty significant. At closer look we notice that the values of these variables are the smallest of them all. A small difference in outcome means a bigger difference in terms of percentage. The difference can be explained from this point of view, that the influence of distributions has a more fluctuating impact on the smaller amounts.

27

Chile –

University of Technology

26 May 2005

Appendix 12 – Validation Different outputs, such as the total subscription period, number of entities and different process times are used to consult experts. Table 10 shows the variables, their computed and their expected value, usually per month. In the second column of values the results are shown when the requests are delayed by the agents in the beginning of the process. Variable Average subscription time accepted requests (days) Average subscription time rejected requests (days) Average waiting time at Control Production (hours) Number of successful requests Number of requests with errors after Control Production Number of clients that don’t accept restrictions Number of requests for background Number of clients that don’t deliver background Number of rejections after Technical Analysis Number of requests through process Sign RQ (incl. RDE) Number of requests through process Control Production Scheduled utilization manager Scheduled utilization front desk employee Scheduled utilization agent Scheduled utilization control production Scheduled utilization technical analysis

C-Value 11.8 9.0 3.4 5800 615 280 1350 266 262 8231 6555 0.18 0.03 0.59 0.81 0.66

Delay 14.1 11.5 4.4 5808 660 290 1270 250 258 8334 6660 0.18 0.03 0.58 0.83 0.69

X-Value3 12 7 4 5500 630 40 1250 300 280 8500 6500 0.20 0.10 0.75 0.85 0.75

Table 8 – Validation

From this table can be derived that the model represents the expected reality (by experts) relatively well. First of all it is important to recognize the possible influence of the delay caused by the agents in order to let every other agent make its minimum. Because the information about this strange procedure was provided very late and was also very uncertain, it cannot be taken into account with our further analysis, but it will be taken into consideration at the recommendations. This does not make the analysis useless, because the focus will be on the changes certain alternatives will bring within possible future scenarios. It does not has to show the true values, but a comparison will be made between these benchmark values and the results that the alternatives will bring.

3

X-Value is the value expected by experts.

28

Chile –

University of Technology

26 May 2005

As can be seen in the table, the utilization of the resources is lower than expected, which can partly be explained from the fact that they work 2 hours less on Friday. This change in utilization of 4,7% is not taken into account in the simulation. For the agent still leaves a gap between the outcome and the expected value of 11%. Probably there are some inaccuracies in the model or some processes missing that are normally done by agents.

29

Chile –

University of Technology

26 May 2005

Appendix 13 – Computerization options, process changes The following processes will change for each option. Assumed is that for every option, the earlier changes in processes stay. The possibilities are handled in this specific order as well, in order of digital advancement.

Evaluation module Revision and signing and Categorize It will partially take over the Sales manager task to revise and sign the request and to decide how to categorize the incoming requests (See appendix 4 Process: Categorize). The evaluation module will take over the decision making in this specific process (categorize requests). The evaluation module has only three different outputs: a. Ok nothing to declare b. Send to BRE (Technical analysis) c. Ok level supervisor Send request to controller This process is still done manually, but is considered redundant after implementing the Evaluation module.

Business Rules Engine Technical analysis, Decision, Authorize-, Reject request and Ask background After implementing the BRE the request that has been judged by the sales manager (or the Evaluation module) as ´Ok level supervisor´ will be digital send to the BRE, which will execute the technical analysis. Also the decision about the request after the Technical Analysis will be made by the BRE. An overview of the implementation of above two options can be clearly seen in the new interaction-flow diagram in appendix 15.

All paperwork digitalized Part 1 Fill out form and enclose background When a client requests a police at the front desk, the following is applicable. In case of an agent who visits a client to cell a policy this is not applicable. Instead of filling in the declaration form on paper, the client and the agent fill out the necessary information into a computer. Agent digitalizes declaration This process is not necessary anymore because the form is already digital. However the agent has to do something else. Instead of digitalizing the declaration form, the agent now has to scan the background papers. Request to complete form Neither this process is necessary, because after filling out the form, the software will automatically alert the client that the form is incomplete and will directly notify the client which information is still missing. 30

Chile –

University of Technology

26 May 2005

Fill out documents This process will also be done digitally. The agent will fill out all the documents in a computer, because all the information is still in the computer, and will send the information afterwards to the client. Part 2 Digitalize request Obviously this process will not be part in this new digital environment, because nothing has to be digitalized. Sign request This process consists of two small processes, which are comparing the paperwork with the imported data and validate this data. Of these processes the first will drop out in this new situation. Prepare and complete documents These two processes as well can be demarcated when everything is digitalized. There are no documents to prepare and everything is, with the right software, well arranged. Control production This process, which currently deals with checking paperwork, will be fully digital. Requests, if not rejected, go directly to mail, making the processes that deal with errors superfluous. The time per request will be zero, because it all happens automatically. Not only processes will change, also some of the decisions and flows are subject to change. There is no production laid off, because requests flow through the system much and much faster than in the old situation. Neither are there requests with digitalization errors, not after signing nor after control. Especially the second part has undergone a big change, so a new interaction-flow diagram is made in Appendix 16.

Agent with IPAQ Part 1 Fill out declaration and enclose background, Agent digitalizes declaration This process will be done digitally, using an IPAQ to import the client’s data (including the background). If the request cannot be processed automatically and a sales manager or controller has to process it manually, there will be send a message to the IPAQ with the approximate delay of the information. The agent can then decide together with the client what to do next (wait, make a new appointment).4 Print declaration The request is digital, so there is no need for a printed form to sign the restrictions. Possibly a receipt, without legal value, can be given to the client. The receipt is without legal value, because then, in case of a non-approval later on, the request does not have to be retrieved at the client. Send rejection to client 4

This however is not taken into account in the simulation. See for more information the assumptions in Appendix 14.

31

Chile –

University of Technology

26 May 2005

After the request has been analyzed the request can be rejected. This information will be directly sent to the IPAQ of the agent. The agent who is still with the client can inform the client directly about the rejection. Send information to client, Mark declarations not specified, Sign restrictions, Mark signed declarations, Fill out documents, Sign document by client The following processes will be totally different. If the request is simple and can be analyzed directly using the Evaluation Module and/or the Business Rule Engine, the client will be able to directly sign the restrictions and the documents. If the request is complex, thus it needs a more specific analysis for categorization or technical analysis, the agent will visit the client a second time for acceptation and signing. The marking of declarations is done by the sales agent instead of the sales manager in the new situation, using the IPAQ. Part 2 Recover client copies, Contact and Inform clients These processes will be turned into one process of informing the client, because there are no documents to be retrieved. Cancel request, Request authorization etc. The flow stops after the client is informed, hence there will be no flow after the above mentioned process.

Web based application Part 1 Fill out form and enclose background This process will be done by the client, wherever he feels like. There is no need for an agent to assist, because the website is clear and should be understandable for everyone. The background information however still might have to be handed in, which is possible via normal mail. Agent digitalizes declaration This process becomes partially redundant. The declaration is already digital but the incoming backgrounds have to be scanned and attached to the digital requests. Request to complete form This process will also be incorporated in the website and will automatically send a notification when there is information missing in the declaration form. Hence the process will also be redundant. Print declaration, Send information to client, Send rejection to client These processes become also redundant. The information will be send to the client automatically via email. When the agent receives the enclosed background papers and has scanned them, the automated process starts. Eventually after these processes of categorizing and evaluating certain information has to be send to the client. In case of acceptance of restrictions, an email notification will be send to the client telling to sign the restrictions at the website. Mark declarations, Mark signed declarations not specified 32

Chile –

University of Technology

26 May 2005

These processes will be abundant when using the website to apply for a policy. The software behind the website will be sufficient for detecting errors or anomalies in the declaration form. Sign restrictions, Fill out documents The signing of the restriction will also be done digitally through the website. When the restrictions are signed the information is send to a sales agent who will fill out the documents and visits the client to sign the contract. Part 2 Recover client copies, Contact and Inform clients These processes will be turned into one process of informing the client (by email), because there are no documents to be retrieved.

33

Chile –

University of Technology

26 May 2005

Appendix 14 – Demarcation and assumptions digitalization The following assumptions have been made according to Future Underwriting: 1. The Evaluation module can process between fifty and seventy percent of all incoming requests. There is no need for a sales manager to interfere with these requests. However the other thirty to fifty percent contain too much specific information or anomalies that they still have to be processed manually. 2. Estimated is that around eighty percent of the incoming requests can be processed by the BRE. The other twenty percent will then be processed in the same way as they do now. 3. Restrictions can be accepted digitally, which does not always involve an agent or legal documents. 4. When all paperwork has been changed into digital format, the production that will be laid of is nil. 5. There are no digitalization errors in the second part of the subscription process. 6. Legal documents that are handed to the client are valid from the moment that they get their confirmation by mail (last process), hence, early contracts are restricted. 7. There are simple and complex requests. Simple requests can be handled electronically by the Evaluation Module or by the Business Rule Engine, complex requests cannot. 8. In case of a sales agent that has to leave a client, because for example the process has to be done manually, the sales manager will mark the declaration as in the current situation. Only when a sales agent is capable of perform the whole process with the client at once, he is authorized to mark the declarations instead of the sales manager 9. In case of computerization of parts or entire processes, the process will be assumed not significant and simulated as 0 minutes for processing (just a few calculations within a computer program).

Digitalize paperwork of sales division 10.The processes Fill out declaration and enclose background and Digitalize declaration, are now done in one process. Filling out the declaration form takes around 15 minutes and enclose the background 2 more. Digitalizing takes another 23 minutes. Assuming that the front desk employee is experienced with entering information in the form, so this will be a lot faster than a client who has to fill out the declaration for the first time. Assumed that will have an efficiency gain of 70%, so the fill out process will be around 0.70*15 = 11 minutes. Enclosing background will be the same, adding 5 minutes 34

Chile –

University of Technology

26 May 2005

extra for asking the client the necessary information during the process will make a final process time of around 11+2+5 = 18 minutes. 11.The process Fill out documents will be done in the computer and assume that there is an efficiency gain (no problems with handwriting, clear form in computer etcetera) of around 80 percent. The process takes now around 20 minutes; 0.80*20 = 16 minutes digitally 12.When digitalizing processes, it will be possible to extend the tasks of a front desk employee. Processes that follow after the automated EM and BRE will be done by the front desk employee (mark declaration, sign restrictions and fill-out documents). In this case it is possible for a client to leave the front desk after the first visit with a signed contract. This however is still in the case when there is no need for manually processing of the above mentioned processes.

Agent with IPAQ 13.When the agent will process the different actions with his iPAQ i.e. Mark declarations, fill out documents and sign documents by client. Assumed is that the time to perform these processes will be the same as is, in the current case. 14.When a request cannot be processed immediately through the EM and BRE, the result will be delayed. The agent gets a notification of the approximate time of delay and can then decide if he stays and wait, or make another appointment. Because at this point it is not clear to what extent this is possible and secondly there is no information about how long a client will wait for it. Therefore it is assumed that sales agents always leaves the client’s residence and comes back another time when: a. The categorization process has to be processed manually. b. The technical analysis process has to be processed manually. c. Additional background papers are asked after the technical analysis. 15.Digitally signing is an accepted and legal agreement and can be done with the IPAQ. 16.No legal document will be transferred to the client, so the agent does not need to recover any, if rejected later in the process. 17.When a request is rejected later in the process, the agent still visits the client to inform and possibly make another deal (this won’t be taken into account). 18.The additional background will probably not be in digital format, but this will be digitalized by the agent back at the office, either by scanning or by importing into a computer program. 35

Chile –

University of Technology

26 May 2005

19.There is software supporting the subscription through IPAQ, taking over all paperwork at the client. 20. Only in the first scenario the agent has to bring paper contracts with him, when visiting the client. This because there is no possibility of legal digital agreements yet.

Web-based subscription 21.In the initial process, fill out declaration and enclose background, the client has to enclose background such as medical forms etcetera. The client will fill in the necessary information from these background documents through the website. Because of authenticity of the documents, the client still has to send these to ING. But this will not be modeled as a delay, only will be marked as a request which needs additional background later on in the process. 22.The delay for fill out the declaration form by the client will be assumed as about the same as when a sales agent performs this process. However 5 minutes is added, because there is no sales agent present to help in cases of unclear things. 23.The client has to send the background by mail where a sales agent has to scan the background and send the digital information to the Evaluation module. This delay will be around 1 day. 24.However possible without, the agent will visit the client to let them sign the contract. This for speeding up the process (do not have to wait for a client to send the contract) and building-up a more personal relation with the client. 25.If a request is complex, this is notified to either the agent’s IPAQ or the front desk employee, so that these resources can make another appointment with the client. If the client does a request over the internet this will be notified as well. 26.Clients cannot only apply through the internet, but can also have legal agreements using the internet, no agent is needed for this  a (restricted) policy can be sold without interference of any resource (part 1 of the subscription process). a. In scenario 1 this is not possible. In this scenario there are still legal problems and the agent still have to visit the client to let him sign the documents. 27. Assumed is that the website can detect errors or missing info in that manner, that there is no need for marking the declaration form by a sales manager or sales agent. These processes will thus be excluded.

36

Chile –

University of Technology

26 May 2005

Appendix 15 – Interaction-flow diagram part 1, Evaluation Module and BRE Client Client enter FrontDesk

Sales

Medical

Agent Calls to make an appointment

Agent visits client

Fill out declaration form and enclose background

Digitalize declaration

Evaluation Module TA

Request to complete form

MS

BRE

Print declaration

ACCEPT

NO

Send information to client

Send rejection to client

Mark declarations Not specified

End

YES End Sign restrictions Mark signed declaration

S

Sign document by client

MS

Fill out documents

L Get background

Deliver background NO

End

YES

Receive and send background

TA

The implementation of the Evaluation Module (EM) and the Business Rules Engine (BRE) only affect changes in the first part of the underwriting process. The second part will still be the same as the current process. This diagram presents the case where EM and BRE take over all the manual activities. In reality there are still some cases where manual processing is needed and this will be done like in the current situation, see appendix 4. This however applies for all the other revised interaction-flow diagrams in the following appendices. 37

Chile –

University of Technology

26 May 2005

Appendix 16 – Interaction-flow diagram, digitalized sales division 16.1 – part 1 Client

Sales

Medical

Call client for an appointment

Client enter FrontDesk

Visit client

Revision & signing Fill out declaration form and enclose background

Categorize

OK Nothing to declare

OK Level Supervisor

MS

TA

OK Level Controller

Send request to controller

Technical Analysis

Decision

Print declaration

ACCEPT

NO

Authorize request

Send information to client

Send rejection to client

Mark declarations Not specified

End

Reject

Ask background

YES End Sign restrictions Mark signed declaration

S

Sign document by client

MS

Fill out documents

L

NO

Deliver background

Get background

End YES

Receive and send background

TA

38

Chile –

University of Technology

26 May 2005

16.2 – part 2 Client

Sales

Control Production

Employer

Mail

L

RQ Notified

YES

NO

Send RQ other city

E1

Notify employer

One week between send and receive notification, done by external company

SF Validate data

RC Contact and inform clients1

NO

E

Delay at employer

Approve RQ

M YES Mail process

Outcome

Deliver copies

YES

NO

Cancel RQ

Request Authorization VP.Sales

End1

End Control production

These requests will be rejected at control production

Approval

No empl oyee

Error

Outcome control

S

Appr.

Rej.

M

End3

SF

RC

Cancel RQ and take care of errors

39

Chile –

University of Technology

26 May 2005

Appendix 17 – Interaction-flow diagram, all digital 17.1 – part 1, iPAQ Client

Sales agent

ING Server

Agent Calls to make an appointment

Agent visits client

FD

Fill out declaration form and enclose background

Evaluation Module

FO

AC

Request to complete form

TA

FD BRE

AC

ACCEPT

NO

YES

Send rejection to client

Mark declarations Not specified

End

End

Sign restrictions Mark signed declaration

S Sign document by client

Fill out documents

FO

L Deliver background

Get background

NO

End

YES

Receive and send background

TA

40

Chile –

University of Technology

26 May 2005

17.2 – part 1, Web based application Client

Sales agent

ING Server

Client enter Website

FD Fill out declaration form and enclose background

Evaluation Module

Request to complete form

FO

AC TA

FD BRE

AC

NO End

Send rejection to client

ACCEPT YES

End

Sign restrictions

S Sign document by client

Fill out documents

FO

L Deliver background

Get background

NO

End

YES

Receive and send background

TA

41

Chile –

University of Technology

26 May 2005

17.3 – part 2 Client

Sales

Control Production

Employer

Mail

L

RQ Notified

YES

NO

Send RQ other city

E1

Notify employer

One week between send and receive notification, done by external company

SF Validate data

RC Contact and inform clients

NO

E

Delay at employer

Approve RQ

M

YES

Control production

Mail process

Outcome

End

Outcome control

Appr.

End

Rej. Approval

M

Error

End

SF

S

No employee

RC

Cancel RQ and take care of errors

42

Chile –

University of Technology

26 May 2005

Appendix 18 – External variables First, when searching for external variables it is useful to list the different processes of interaction with other parties in the process. Processes within ING are not interesting within this context, because they can be revised by ING whenever they want to. Behavior of other parties on the other hand is more difficult and almost impossible to influence. Therefore the processes, which involve different parties, are listed and questions about possible external variables that have an influence on their behavior postulated below. The processes (per party) listed below are the same in the interaction flow diagram (see appendix 15-17). Client Client enter front desk • Why do they prefer to go to the Front desk? o Do they favor personal contact when they first apply for a policy? o Do they like to go out for applying? Sales • • • •

agent calls client for an appointment Do clients like to be called by agents selling policies? Do they favor a sales agent visiting them at home? Do they prefer to stay at home instead of going to an office? Does the personal contact (agent visits a client at home) plays a significant role in agreeing to make an appointment?

Fill out declaration form and enclose background • Agent’s influence on the client’s behavior is not taken into consideration. Accept and sign restrictions or documents • Will clients accept signing via websites in the future? • Will clients accept digital signing via iPAQ? • Is their a significant influence of a sales agent upon the decision to accept or deny restrictions or documents? Deliver background or copies • Is there a significant influence of a sales agent upon the decision to Deliver the background or copies?

43

Chile –

University of Technology

26 May 2005

Employer Notification employer • What are the incentives for an employer to send the notification back quickly? • Will the employer accept digital notification or notification via a website? Government • Does the government allow digital archiving? • Does the government allow digital signing or legal agreements via internet? A short recapitulation brings us to the following main external variables that can be listed after taking all the questions above into consideration: 1. Importance of personal contact for the client with ING 2. Use of internet 3. Acceptance of digital agreements (government policy)

44

Chile –

University of Technology

26 May 2005

Appendix 19 – Recommendations Process Agents Number of clients per day Travel time per day Real process times Number and length of breaks Time-intensive processes, distributions Input Number of calls per day Percentage successful Call time successful/unsuccessful Number of clients who go to front desk Process logic Missing processes Sequences

Scenario-analysis Technology Internet coverage (trend) Technological possibilities Digital signing Software for new data storage Interface possibilities for website and iPAQ Clients Needs and opinions Agent’s help/assistance Subscription over internet Government Rules and laws Data storage Client’s documents Digital agreements Possible changes 45