2010:100 CIV MASTER'S THESIS

2010:100 CIV

M A S T E R ' S T H E S I S

Six Sigma in Swedish bankingA case study in the applicability of Six Sigma from improvements

in the loan process

Jonas Karlsson

Luleå University of Technology

MSc Programmes in Engineering Industrial Business Administration

Department of Business Administration and Social SciencesDivision of Quality & Environmental Management

2010:100 CIV - ISSN: 1402-1617 - ISRN: LTU-EX--10/100--SE

Six Sigma in Swedish banking: A case study in the applicability of Six Sigma for improvements in the loan process. Jonas Karlsson © 2010

i

A C K N O W L E D G E M E N T S

There is only one author named on the front cover of this thesis. I would not mind adding a couple more there, as the support I have received at the bank has been incredible. I would like to thank the consultant team with whom I worked very close during the initial twelve weeks. Christian, Jan and Ylva you are the best and I would not have made it without your help and support.

I’d also like to thank my supervisor Helena for finding such an interesting and challenging project to participate in and guiding me through it. Thanks to Elisabet for the idea of doing my master’s thesis at the bank, it was a good one. To my supervisor Peder Lundqvist, thanks for your support and guid-ance, even though we didn’t see each other until the final presentation.

To the entire community, thanks for the great reception and keep up the good work.

Jonas Karlsson Stockholm, June 14, 2010

ii

A B S T R A C T

Six Sigma is proved to be an effective way of improving the quality of proc-esses and products in a wide range of industries. At the major banks in Swe-den, Six Sigma has not yet had a major impact, even though the methodology has been successfully used in banks in other parts of the world. In this thesis the applicability of Six Sigma in a Swedish bank is explored using a case study.

The subject of the case study is the loan process at a major Swedish bank. The loan process is defined as the activities taking place after the loan has been disbursed to the customer to ensure the bank’s legal right to seize the securi-ties used as collateral in the case of a default by the customer. The loan proc-ess is approached using the DMAIC cycle with the objectives of lower opera-tional risk, less rework and higher customer satisfaction.

The results of the case study show that Six Sigma can be used at Swedish banks. There are however problems with the availability of data as well as the maturity of the organization and the employees’ competences in handling large data sets. New tools to monitor the loan process and to act on deviations are developed in the thesis.

S A M M A N F A T T N I N G

Sex Sigma är ett bevisat effektivt verktyg för att förbättra processer och pro-dukter i en rad olika industrier. Hos storbankerna i Sverige har Sex Sigma dock inte fått något större genomslag trots att metodiken använts framgångs-rikt av banker i andra delar av världen. Uppsatsen använder en fallstudie för att undersöka möjligheten att använda Sex Sigma hos en svensk bank.

Fallstudien fokuserar på låneprocessen hos en av de svenska storbankerna. Låneprocessen är namnet på de aktiviteter banken utför för att säkerställa sin legala rätt att lagföra de objekt som använts som säkerhet om kunden skulle upphöra med sina lånebetalningar. DMAIC-cykeln används för att försöka förbättra låneprocessen ur perspektiven operationell risk, omarbete och kundnöjdhet.

Resultaten från fallstudien visar att Sex Sigma kan användas på svenska ban-ker. Dock finns det problem med tillgängligheten av data, organisationens mognadsgrad och kompetensen hos medarbetarna att hantera stora data-mängder. Nya verktyg för att öververka och agera på avvikelser i låneproces-sen har utvecklats under examensarbetet.

iii

L I S T O F A C R O N Y M S

BIW: Business Information Warehouse

CTQ: Critical to Quality 16

DMAIC: Define, Measure, Analyse, Improve, Control 12

FTE: Full-Time Equivalent 10

KPI: Key Performance Indicator 9

SLA: Service Level Agreement 18

iv

C O N T E N T S

1 INTRODUCTION ........................................................................................................... 1 1.1 BACKGROUND.................................................................................................................. 1 1.2 THE CASE STUDY .............................................................................................................. 2 1.3 PURPOSE, OBJECTIVE AND LIMITATIONS ........................................................................ 2 1.4 POTENTIAL SAVINGS........................................................................................................ 3

2 METHODOLOGY ........................................................................................................... 5 2.1 CASE STUDY...................................................................................................................... 5 2.2 SIX SIGMA ......................................................................................................................... 5 2.3 DATA WAREHOUSING...................................................................................................... 6

3 THEORY ............................................................................................................................ 8 3.1 CUSTOMER SATISFACTION............................................................................................... 8 3.1.1 Bank loans and the Kano model ..................................................................................... 8

4 EXECUTION ................................................................................................................... 12 4.1 DEFINE............................................................................................................................ 12 4.1.1 Define and concretize the problem............................................................................... 12 4.1.2 Identify the customers and their requirements............................................................ 12 4.1.3 Identify CTQs .............................................................................................................. 12 4.1.4 Map overall process ..................................................................................................... 13 4.2 MEASURE........................................................................................................................ 13 4.2.1 Determine the current state......................................................................................... 14 4.2.2 Current measurement tool........................................................................................... 14 4.2.3 Develop measurement tool........................................................................................... 15 4.3 ANALYZE........................................................................................................................ 18 4.3.1 Identifying different types of errors ............................................................................. 19 4.3.2 Identifying sources of errors ........................................................................................ 20 4.3.3 Conclusions from the analysis ..................................................................................... 21 4.4 IMPROVE......................................................................................................................... 21 4.4.1 Closing the feedback loop ............................................................................................. 21 4.4.2 A need for a new branch manager report..................................................................... 22 4.4.3 Developing the new branch manager report................................................................ 22 4.4.4 The process owners lack of data as decision basis ........................................................ 24 4.4.5 Monitoring tool for the process owners ....................................................................... 24 4.4.6 Further development of the measurement tool ............................................................ 25 4.5 CONTROL........................................................................................................................ 26

5 CONCLUSIONS & DISCUSSION............................................................................. 28 5.1 CONCLUSIONS................................................................................................................ 28 5.2 RESULTS & SAVINGS ...................................................................................................... 29 5.3 DISCUSSION.................................................................................................................... 30

6 REFERENCES ................................................................................................................. 33

APPENDIX ............................................................................................................... 4 PAGES

1

1 I N T R O D U C T I O N

This section presents the purpose and objective of the study and argues for why the chosen subject is relevant to research. A short description of the empirical project is delivered as well as the limitations.

1.1 BACKGROUND

Recent economic turmoil has put significant pressure on banks to cut cost and decrease operational risk while maintaining a high level of customer satisfac-tion. While events like financial crises are ultimately caused by human behav-ior, it is still an operational risk and its results need to be dealt with. Opera-tional risk is defined as “the risk of loss resulting from inadequate or failed internal processes, people or systems or from external events” (Basel Commit-tee on Banking Supervision, 2003). Williams, Bertsch, Dale, et al. (2006) argue that operational risks are best dealt with using quality management tools since the causes of operational risk lie within the organization and are there-fore in the organization’s power to eliminate.

The four major banks in Sweden are Handelsbanken, Nordea, SEB and Swed-bank. All major banks except Handelsbanken have initiated quality im-provement programs based on Lean to increase the quality of both customer facing, back office and cross-processes (Andersson & Cornéer, 2009). The methodology of the three banks share a common base, since they all took help from McKinsey & Company in developing and implementing the program (ibid). Lean is, however, not the only methodology available for quality im-provement. A case study using Six Sigma to improve an internal process at a US financial service organization by Kumar, Wolfe and Wolfe (2008), showed an improvement in process throughput time from 20 days to 15 days. Kumar et al.’s work has demonstrated a significant potential for Six Sigma in finan-cial services. The applicability of Six Sigma and possibility to co-exist with other quality improvement programs, such as the ones in three of the major Swedish banks, is not known.

Six Sigma is a well-established methodology for improving products and processes. It has been predominately used in the manufacturing industry, even though many argue, e.g. Keller and Pyzdek (2009) and Hayler and Nich-ols (2006), that it is just as well suited to be applied in the service industry. Certain sectors of the service industry, such as banking, have been more eager than others to adapt the Six Sigma methodology with most of the companies being from North America (Antony, 2006). The literature available on the up-take and use of Six Sigma in Swedish banks is non-existing and initiated sources in the business say that application is scarce at best. Hayler and Nich-ols’ (2006) list of 31 banks involved in notable Six Sigma application included only two banks (Holland and Germany) not belonging to the Anglosphere or Asia. The positive results from Kumar et al.’s case study, combined with the lack of documented application of Six Sigma in internal processes at Swedish banks, is an interesting invitation for further studies. Exploration of the appli-

S I X S I G M A I N S W E D I S H B A N K I N G

2

cability of Six Sigma alongside other quality improvement programs at a Swedish bank will be conducted in this thesis using a case study.

1.2 THE CASE STUDY

Selecting the right project to conduct using Six Sigma methodology is crucial for its success (Heckl, Moormann & Rosemann, 2010). Insufficient quantity and quality of data are named as major causes of failed projects (ibid; Antony, Antony & Kumar, 2007). Several authors, including Keller and Pyzdek (2009), have developed extensive evaluation models for Six Sigma project selection. Antony, Antony and Kumar (2007) provide a scaled down checklist for the characteristics of good six sigma projects. They are, in selection, as follows;

• The problem is recognized to be of major importance to the business in terms of cost, quality and customer satisfaction.

• The project is do-able in less than six months. • Quantitative measures of success before and after the project should be

available.

For the case study, a process fulfilling these criteria has been chosen. The case study will try to reduce the average throughput time of the loan process at a major Swedish bank. The loan process is defined as the activities taking place after the loan has been disbursed to the customer. The purpose of the loan process is to ensure the banks legal right to reclaim its money, should the bor-rower default. The bank ensures this ability by acquiring securities, such as the pledge to a house, and keeping it as collateral. In Sweden, securities for loans are not acquired before the disbursement of funds. The Swedish design exposes domestic banks to a higher operational risk and it is therefore crucial that the process of acquiring securities is operating correctly and swiftly. Fail-ures in the process of acquiring securities require additional non-value add-ing contacts with the customer, which have a significant negative impact on customer satisfaction. Quantitative data on the process is available for analy-sis in the bank’s IT systems. The case study will be conducted concurrently with an improvement project within the bank’s lean program.

1.3 PURPOSE, OBJECTIVE AND LIMITATIONS

The practice of Six Sigma as a method of improving internal processes at a Swedish bank is largely undocumented. A study documenting the application on a similar process at an US financial service organization has demonstrated great potential for the Six Sigma methodology (Kumar et al., 2008). Can the same methodology be used without modification to improve another process in another country? Is Six Sigma the preferential methodology to drive im-provements at a Swedish bank? Is it at all useful or should certain parts be ex-tracted and integrated with the current lean-based methodology? Several questions are of interest for further research in this area; however, the pur-pose of the thesis has been defined as:

Explore the possibilities of using Six Sigma methodology to improve an internal proc-ess at a major Swedish bank.

I N T R O D U C T I O N

3

The answers to these questions will be of great value both for the bank at hand as well as for other organizations in the banking industry looking for ways to improve various processes whether the goal is efficiency, cost, cus-tomer or all of them. Answers to the questions posed in the purpose will be answered by conducting a case study of the loan process at a major Swedish bank. The objectives of the case study, and likewise the thesis is to:

Achieve cost savings in the loan process by recommending and implementing im-provements to decrease the throughput time. Resulting in increased customer satisfac-tion, a reduction of operational risk and rework using the Six Sigma methodology.

The thesis will be limited to the activities taking place after the credit decision has been made, i.e., it will not involve the process of deciding which custom-ers are credit worthy and which are not. This limitation is made since it would make the scope of the thesis too large and because the credit decision is not a problem area. While the case study has support of management, the financial resources available to spend on development in IT systems are limited. Since the loan process is largely a manual process, it inheritably provides obstacles associated with measuring humans instead of machines. The ability to im-plement changes in the process is also somewhat limited because of two fac-tors. Number one; purposed changes to the design on the process need to pass through the process owners in order to be implemented. Number two; a major cause of variation is thought to originate from the advisors who sell loans to the customers at one of almost 200 branches all over Sweden. Chang-ing the behavior of such a large and geographically diverse group of people will be a challenge even with adequate resources.

1.4 POTENTIAL SAVINGS

The savings that are possible in this project are:

• Man-hours saved because of less rework. • Decreased value at risk due to less unfinished loans. • Less negative impact on customer satisfaction as a result of not having

to contact customers as often.

For each error committed, an extra 20 – 60 minutes is needed to correct the error. Very few loans default, especially for mortgages since your home would likely be among the last things you stop paying for. However, defaults do happen and when they do, the bank needs to have acquired the securities. The fewer loans circulating in the process, the less value is at risk incase of a default. With less work in progress in the process, the probability of docu-ments going missing is likely to decrease which means the bank does not have to contact customers to re-sign documents. Thereby an unnecessary contact is avoided and the customer will not become dissatisfied with the service of the bank.


4

5

2 M E T H O D O L O G Y

In this section, the methods for achieving the objective and purpose are presented as well as an argumentation for why the specific methods have been chosen.

2.1 CASE STUDY

Case studies are a frequently used research method in social sciences in di-verse disciplines as psychology, political science and business (Yin, 2003). Yin argues that a case study should be used when “how” or “why” questions are being posed. The purpose of the thesis can easily be formed as a “how” ques-tion by rephrasing it as “How can Six Sigma be used to improve…”, provid-ing argument that a case study is a suitable research methodology. Yin rec-ommends that the case study should have a multi-case design to improve chances of reaching more generalizable results. As the time and resources for this thesis are limited, only one case study will be conducted. Parallels will however be made to a previous case study in a similar setting conducted by Kumar et al. (2008). Using case study as the research method seems to match up well with the requirements, but is there not other methods that could have been used? A literature study is not possible since there is not enough written on the subject of Six Sigma in Swedish banks. There are virtually no practitio-ners to interview for a survey study (GE Money Bank being the exception, but they are rather small in Sweden) and conducting research as an experiment is not feasible. A case study is therefore deemed as the most appropriate method of research. Baxter and Jack (2008) argue that a case study is a re-search methodology that facilitates exploration of a phenomenon within its context. One could argue that the context (major Swedish bank) is more inter-esting than the phenomenon (Six Sigma as a way of improving quality) since the latter has already been thoroughly studied in other settings.

2.2 SIX SIGMA

Six Sigma is “coupled with the use of facts and data to reduce process varia-tion, thereby enabling organizations to deliver consistent, high-quality serv-ices to customers” (Hayler & Nichols, 2006). According to Keller and Pyzdek (2009), Six Sigma is “a rigorous, focused, and highly effective implementation of proven quality principles and techniques” while Sörqvist and Höglund (2007) see Six Sigma as a “concept to continuously improve an organization’s processes and products”. Even though the authors use different wordings to describe Six Sigma, they are not contradictory and are in large harmonizing with each other. There are basically two major project models in Six Sigma, DMAIC (Define-Measure-Analyze-Improve-Control) and DMADV (Define-Measure-Analyze-Design-Verify) argues Keller and Pyzdek (2009). DMAIC is used when improving an existing product or process whereas DMADV is employed when developing a new product or process. There are several dif-ferences, but also similarities between the two projects models (ibid), but also in how organizations use them. General Electric has taken the generic Six Sigma methodology and tailored it to their needs while Honeywell has devel-


6

oped their own proprietary Six Sigma approach (Kumar et al., 2008). An overview of four authors’ view on DMAIC is shown in Table 1 in Appendix.

By studying the views expressed in Table 1 in Appendix, it can be concluded that on an overall level the different authors have quite a harmonizing opin-ion of what the different phases of the DMAIC cycle mean. Six Sigma consists of a whole range of tools and techniques that are deployed in one or more of the phases of the DMAIC cycle. No standard exists as to which tool should be used in which specific phase, rather the best suited tool should be used. In Heckl et al.’s (2010) survey on which tools Six Sigma patricians in the financial industry found most useful, emphasis was put on the more basic quality tools (Pareto charts, Ishikawa diagrams) rather than on more advanced statistical tools such as calculating process capability, sigma value and design of ex-periments. The tools need to be adjusted to the problem at hand as well as the industry. The Six Sigma methodology outlined by Keller and Pyzdek (2009) will be used in this thesis since it is very comprehensive and provides discus-sions as well as examples of when and how to use a tool.

2.3 DATA WAREHOUSING

In order to explain the complexities involved in getting access to data at the bank, the concept of data warehousing is explained. Using a data warehouse is a rational way of making data accessible, because other units within the bank could potentially reuse the data. The common way to distribute data in the bank is through the use of data extracted from source systems to Microsoft Excel-files. This method of dealing with data makes analysis and automation less flexible and more manual. Data made available through data warehous-ing is stored on database servers that are readily available and not requiring any manual handling for the end user.

Most corporations generate large amounts of data through the use of IT sys-tems. For example, when a customer places, pays or signs for an order, this is usually recorded in one or several computer system. Lately corporations have identified the benefits of making data from these systems available to end us-ers within the company (Keller & Pyzdek, 2009). The practice of making transactional data readily available is called data warehousing and is illus-trated in Figure 1.

Figure 1. The principle of data warehousing adapted from Keller and Pyzdek (2009).

M E T H O D O L O G Y

7

The major components of data warehousing are (ibid):

• Source systems are where the data comes from. • Data transportation is the process of moving data from one system to

another. • Central repository is where all data is stored. • Metadata describes what information is available. • Data marts contain tables with specialized extracts of data from the cen-

tral repository. • End users are the ones who act on the data delivered and the reason

that the data warehouse exists.

Of the data available in the source systems, not everything is transported to the central repository. Only data requested by the end users are transported from the source systems to the central repository. Depending on the age of the source system, the transportation of data will occur with different frequency and with different levels of automation. A central repository, called the Busi-ness Information Warehouse (BIW) is available at the bank where the case study is conducted and is potentially a great source of information. Data from the central repository is delivered to end users in the form a database table that can be accessed from common applications such as Microsoft Excel or Access.

2.4 VALIDITY & RELIABILITY

The primary data source in this study is the quality log, where reviewers log errors committed in the loan process. Errors in the process have a large im-pact on the process time of the loan process and are as such interesting to measure. The validity can thus be considered as high. For the reliability, this is unfortunately not the case. As humans log the errors, there are several is-sues with how errors are measured. Firstly, according to Annelie (personal communication, April 12, 2010) only about 40 % of all discovered errors are logged. Secondly, what one reviewer regards as an error another might not. The errors that are logged in the quality log are most certainly generated by an actual error, but a lot of errors do not end up being logged. This uncer-tainty in reliability needs to be taken into consideration when analyzing the data in the quality log. By analyzing data over a longer time span, the affects of uncertainty from the reviewers’ logging can be reduced. If one branch month after month rank amongst the top ten committers of errors, this is more likely an affect of them making a lot of errors rather then a skewed log-ging process.


8

3 T H E O R Y

Herein, the theoretical framework underpinning the empirical parts of the study are presented.

3.1 CUSTOMER SATISFACTION

Satisfied customers are one of the most important factors in running a suc-cessful business today. There is a strong correlation between customer satis-faction and positive effects for the business (Anderson, Fornell & Lehmann, 1994). These positive effects are for example increased customer retention, customers recruiting new customers through word of mouth and increased repeat business. All of which boils down to increased profitability for the or-ganization. Johnson, Nader and Fornell (1996) argue that “the degree to which customers are satisfied with their loan experience plays a central role in their loyalty to the bank and its profitability”.

Acquiring new customers is more expensive than retaining existing ones; therefore, maintaining satisfied customers is a main objective for many orga-nizations (Ahmad & Buttle, 2001). In order to be successful organizations need to be aware of what is affecting the satisfaction of their customers and in what way. According to Johnson et al. (1996), conventional models for de-scribing customer satisfaction are not valid for explaining customer satisfac-tion when selling loans. They argue that since customers generally have lim-ited experience with the loan process, customer satisfaction cannot be de-scribed using the disconfirmation model i.e. the difference between expecta-tions and performance. Johnson et al. (1996) argue that customers’ expecta-tions are an artifact of the service production process and do not affect satis-faction. Instead perceived performance should be considered the predomi-nant determiner of customer satisfaction. However, perceived performance must co-vary with the customers’ stated expectations (ibid). Giving the cus-tomer such a pleasant experience as possible is thus a way of creating satisfied customers.

3.1.1 Bank loans and the Kano model

As stated by Johnson et al. (1996), customer satisfaction is largely dependant on perceived performance, but must also co-vary with the customer’s stated expectations. In practice, this could mean that the customer expects to be of-fered a loan with a competitive interest rate, but will not have any expecta-tions how long time the process will take.

How can banks make sure that the perceived performance is as high as possi-ble? The answer is by avoiding pitfalls and designing customer centric proc-esses. Pitfalls include not fulfilling stated expectations and failing in funda-mental areas (not disbursing the loan in time). A model for understanding how fulfillment of expectations affect customers satisfaction is the Kano model, developed in the 1980’s by Japanese Professor Noriaki Kano.

T H E O R Y

9

The Kano model, as seen in Figure 2, classifies customers’ expectations and demands into three different categories:

1. Basic factors 2. Performance factors 3. Excitement factors

Basic factors are the customer’s subconscious expectations and demands on the product or service, things that are taken for granted. If the organization fails to fulfill basic factors, the costumer satisfaction will decrease immensely. An organization cannot make a costumer satisfied by fulfilling basic factors, they can only make costumers dissatisfied by not fulfilling them. An example of a fulfilled basic factor is a car door designed not to hit the curb when opened.

Performance factors are outspoken customer demands where customer satis-faction increases linear with fulfillment of demands. A mortgage loan with an interest rate of 15% would make the customers dissatisfied and chose another bank, while 0.5% makes them very satisfied.

Excitement factors are product or service features that the customers didn’t knew existed or that they wanted. Since the customers do not expect these features, not fulfilling them will not cause the customers to become dissatis-fied. However, fulfilling excitement factors can produce very satisfied cus-tomers. In mortgage loans an excitement factor could be providing SMS noti-fications about an upcoming interest rate review meeting.

Figure 2. The Kano model adapted from Keller and Pyzdek (2009).

Customer satisfied

Customer dissatisfied

Non-fulfillment

State of fulfillment

Basic

Performance

Excitement


10

What was once an excitement factor will not remain so forever. The trend is that customers get used to a higher level of service or quality and will start taking it for granted. Something that was once an excitement factor becomes a performance factor and over time a basic factor. The ability to take a photo-graph with a mobile phone was considered an excitement factor a couple of years ago. Today, in 2010, one could make the argument that it has become a performance factor or even a basic factor.

In the case of bank loans, the customer has few expectations on the service since they are created on the fly. The expectations that do exist will be either basic factors or stated performance factors. Performance factors will need to be fulfilled in order to gain the customer, while basic factors must be fulfilled not to hurt customer satisfaction or trust.

T H E O R Y

11


12

4 E X E C U T I O N

This section presents a recollection of the actions taken in the Six Sigma project, which constitutes the empirical part of the thesis. The structure follows the phases of the DMAIC-cycle.

4.1 DEFINE

The goal of the define phase is to thoroughly define the problem at hand. By doing so the chance or realizing halfway that the problem is incorrectly stated can be reduced.

4.1.1 Define and concretize the problem

The throughput time of the loan process is too high, meaning that it takes too long from the disbursement of funds until the securities are acquired. Several factors are thought to have an affect on the throughput time, such as the qual-ity of the documents used to acquire the securities or documents not submit-ted on time. Whatever the cause of the high throughput time is, the goal is to decrease it.

4.1.2 Identify the customers and their requirements

Banks generally offer a vast range of financial services to its customers; a ma-jor portion of the revenue is however created by the basic products, for exam-ple selling loans (Shostack, 1977). Loans are sold to private and corporate cus-tomers. The mechanisms are similar for both types of customers; though cor-porate loans are usually of larger volume and with more complex securities.

Johnson et al. (1996) argue that customers hold weak expectations at best when it comes to loans. Translating this statement into one of the three types of expectations in the Kano model, classifying them as basic factors would be the most appropriate. Executing the loan process impeccably will not produce satisfied customers, however, failing to do so will hurt customer satisfaction immensely.

There have been cases where the bank, as a result of a poorly functioning loan process, has lost documents signed by the customer. The bank then has to ask the customer to visit a branch office to sign new documents. It would not be to far of a stretch to say that the common notion is that banks keep good track of their documents. Proving the customer wrong on this point will not only hurt customer satisfaction but also the customer’s trust in the bank. Heffer-nan, O'Neil, Travaglione, et al. (2008) have identified a correlation between decreased trust and lowered financial performance. If a bank fails in fulfilling basic factors, they may be punished twice through decreased customer satis-faction and trust. Both of which lead to money lost for the bank.

4.1.3 Identify CTQs

Critical to Quality (CTQ) are factors of the product or service that the cus-tomer regard as critical to his or her overall quality experience. By identifying

E X E C U T I O N

13

the CTQs, customer requirements can be separated from internal require-ments. As a customer centric organization you should prioritize improve-ments that affect the CTQ before improving strictly internal factors.

For the loan process, the CTQs have been identified in collaboration with the internal consultants working on the projects as:

• Title registered • No non-value adding contacts with the customer, from the customer’s

perspective

4.1.4 Map overall process

The process of lending money starts with the customer requesting a loan and ends with the loan documents being secured in a vault. The scope of this the-sis starts with the process step “Disburse loan” and ends with “Close errand and put documents in archive”. The comprehensiveness of the process map is needed in order to describe how different process steps link together and il-lustrate dependencies. A process map is available in Appendix.

There are four major stakeholders in the overall process of lending money. The customers who receive the loans, the divisions merchant banking and re-tail that sell the loans, loans production who produce the loan contracts and loans review who acquire the securities. The customers contact an advisor at either merchant banking or retail to get a loan. The advisor then either pro-duce a loan contract through a system called “Säljstöd” if the loan is uncom-plicated, or orders a contract from loans production. After the loan contract has been signed by the customer and required documentation to acquire the securities have been provided to the advisor, he or she sends it to loans re-view. The documents are then checked from a legal and formalities perspec-tive by loans review and if everything is correct it gets placed in a vault and the case is closed, otherwise it is returned to the advisor to be complimented.

4.2 MEASURE

This step focuses on two questions; what should we measure and how should we measure it? It also presents what data is currently available and what can be made available through development in the Business Information Ware-house (BIW).

Figure 3. Screenshot of the fronted used by loans review to record errors in loan documents in the qual-ity log.


14

4.2.1 Determine the current state

At present loans review record around 1 700 errors per month and ------ loans are older than 60 days and not yet archived. The average time from disburse-ment to archiving is not measured; it is although regarded as being too long. The post queue for incoming documents for review varies between six and twelve days depending on the day of the month and season.

4.2.2 Current measurement tool

There is already a system in place for measuring the quality of the submitted loan documents. The system is called The Quality Log and consists of a data-base stored on an SQL-server and a front-end, see Figure 3, which the review-ers use to record errors.

The quality log is used by two different functions, loans production and loans review. Loans production’s objective is to produce contracts for the customers to sign. They mainly use the quality log to record requests for contracts from branches that violate the Service Level Agreement (SLA). In the SLA it is specified that loans production have got three days to produce a contract after the branches order it. Quite often though, the branches will demand the con-tract in less time and loans productions will then record it as an “Urgent mat-ter” in the quality log.

Table 1. List of information logged in the quality log.

Field Explanation Profit center The profit center of the branch disbursing the loan. Name of advisor The name of the person responsible for the loan. Error descrip-tion level one

An explanation of what is wrong with the case on a high level. The error description is picked from a drop-down list.

Error descrip-tion level two

A more detailed explanation of what is wrong. The level two description is linked to the level one description, e.g. level one “Documents missing”, level two “Missing pledge”.

Risk level Each error description has a risk level associated with it on a scale from 1–5 with regards to the bank’s ability to sue the borrower for the money lent.

Logged by The name of the administrator in loans review or loans production that logged the error.

Department The department that the administrator belongs to. It can be either Production Stockholm/Malmö or Review Stock-holm/Malmö.

Date The date when the error was logged. Credit number Unique number used by the bank to identify individual

loans. Customer number

National identification number or corporate identity num-ber of the customer.

E X E C U T I O N

15

Loans review records a much larger variety of errors in the quality log, see Table 1 for an explanation of each of the fields. The quality log has been in use since 2004, and was intended as a feedback tool for the branch managers. Gaining knowledge on what kind of errors are the most or least common can also be useful in initiating education or clarified instructions for branches.

So far though, the quality log has failed to reach its full potential, partly due to low awareness and being hard for branch managers to interpret (C. -------, personal communication, April 8, 2010). The process owners of the loan proc-ess could benefit from the information in the quality log, but have so far failed to act upon the information because it has been to time consuming the ana-lyze (ibid).

Using the data available in the quality log enables some interesting analyzes to be made such as; which branch makes the most errors? Does error-proneness fluctuate over time? Further development will however be needed in order for the tool to be effective for one-off measures as well as continuous monitoring of the process.

4.2.3 Develop measurement tool

Given a set of data, you can usually calculate a whole range of different measures. To be successful in developing a measurement tool, you need to answer the following questions:

Why and what do we want to measure?

The problem statement is “The throughput time of the loan process is too long”, and helping to solve this is the raison d'être* for the measurement tool. Therefore, we need to measure how long time it takes to process the loan documents.

The problem can be stated mathematically as f(X1,X2,X3…Xn) = Y, where Y is the time it takes to fully process a loan. The X's are the factors having an affect * French for ”reason for being”.

Figure 4. Fishbone diagram of possible sources of deviation on process time.


16

on the process time and will also have to be measured. Figure 4 shows a fishbone diagram of the possible sources of variation on the process time. Each of the factors needs to be evaluated by asking; can it be measured? Why should it be measured? A summary of these questions with corresponding answers is shown in Table 2.

Knowing what should be measured and why, the next step is to determine how it should be measured.

What data is needed?

In Table 2, three factors are identified as measurable: Errors in review cases, Documents not submitted on time and Reviewer competences.

Table 2. Evaluation of measurability of sources of variation.

Factor Measureable? Why should we measure it? Errors in review cases Yes To understand what kind of errors are

most common and what branches have a particularly high error rate.

Documents not submitted on time

Yes To be able to identify branches having a culture of sending documents to late.

Lost documents No Lost documents mean a lot of rework and are a serious error in the process.

Mail handling No To gain knowledge on when an external supplier is not delivering adequate serv-ice and understand sources of variation beyond the banks control.

Reviewer compe-tences

Yes The speed with which the reviews can process documents is highly dependant on their skills.

Table 3. Sample table data as stored in the BIW.

Field Sample value Profit center 12345 Disbursement date 2010-02-13 Credit number 12345678 Client number 1234567891 Loan amount 10 000 First document scanned date* 2010-02-15 (or N/A if not yet occurred) Last document scanned date* 2010-03-02 (or N/A if not yet occurred) Loan finished date* 2010-03-10 (or N/A if not yet occurred)

E X E C U T I O N

17

Errors in review cases will be measured using the quality log database and the Business Information Warehouse (BIW), see section 2.3 for details on the BIW. The data in the quality log is readily available and an overview of the data is shown in Table 1 on page 14. From the BIW, the data in Table 3 will be needed. Documents not submitted on time and reviewer competences rely on investments in the BIW and are only presented as ideas for further develop-ment.

Fields marked with an asterisk are available in the source systems, but are currently not being transported to the BIW. At the time of publishing this re-port, a request for quotation has been sent to the IT department to establish the cost and time required to transport the missing data to BIW and to get ac-cess to the data already available.

What Key Performance Indicators (KPIs) should be calculated?

Using the information in the quality log and in BIW, several measures can be calculated. The ones that are deemed as most interesting and actionable are listed in Table 4. All measures can be aggregated, starting at employee level through branch, district, and region up to a global measure for the entire bank. Using patterns in Client number and credit number it is possible to dif-

Table 4. KPIs and measures for the loan process.

Measurement Data used Purpose Processing time Date case closed –

disbursement date Measure the process output.

Percentage of errors Number of errors in the quality log/Number of loans disbursed

Identify worst and best in class branches. Moni-tor and act on devia-tions from norm.

Submitting delay Scan date of first docu-ment – disbursement date

Spot branches not sub-mitting documents on time.

Number of unfinished loans

Count of loans without a case closed date

To estimate the opera-tional risk.

Review time Scan date of last docu-ment – case closed date

Measure the efficiency of loans review.

Type of errors Error descriptions level one and two

Determine which errors are the most common.

List of dangerous loans Query database for old unfinished loans with a high risk level

To help prioritize what loans in the backlog need to be dealt with first, rather than just employing the first in – first out principle.


18

ferentiate between private and corporate clients as well as mortgage and other loans. This is important since the branches are usually split organizationally on corporate and private clients.

Who are the recipients?

There are basically two different recipients of the measurement tool, the proc-ess owners and the branch managers. The level of detail and the purpose of reporting the KPIs will therefore be different.

The purpose of the measurements for the branch managers is to provide feedback on the overall performance of their branches. Making the branches and advisors more aware of errors committed will help foster a culture of “right from me”. The idea behind the right from me mantra is that advisors would commit fewer mistakes if they were more aware of how many errors they are responsible for.

If the purpose of reporting KPIs to the branches is to facilitate grass root im-provements, the purpose of reporting to the process owners is to initiate high-level global process improvements. It is the process owners’ responsibility to make sure that the process is working as smoothly as possible, and the KPIs are meant as an aid in that work. The measurement tools for process owners and branch managers were developed by the author in Visual Basic for Ap-plications and screenshots are available in Appendix.

4.3 ANALYZE

In the analyze phase, different ways to display and interpret the data from the quality log is presented.

Figure 5. Distribution of errors in the quality log.

0,0%

5,0%

10,0%

15,0%

20,0%

25,0%

30,0%

35,0%

Urgent

matter

Incomplete matter

Form is

missing

Promissory note or loan

file is missing

Incorrect

Promissory Note or Contract

Error in Land Registration

Authority matter

Possible

to handle in Säljstöd

Incorrect

Pledge

IncomingPayment

Matter handled

in sales system

Outgoing Payment

Matter

handled manually

Error in conditions

Type of error

Percentage of total errors

E X E C U T I O N

19

4.3.1 Identifying different types of errors

The time period of study is the entire year of 2009. It is chosen to provide a large quantity of measures as well as indicate any seasonal differences in the quantity and type of errors logged. The start date of the bank initiated im-provement project was set to January 2010 and in order to measure perform-ance before any improvements were made, the 2009 data is used. In 2009, a total of 21 248 errors were logged in the quality log. The distribution of the types of errors committed can be seen in Figure 5.

It can be noted that “Urgent matter” is highly overrepresented, being double the size of the second most common error. Urgent matter is an error gener-ated when advisors at the branches tries to rush the process of producing loan contracts. According to the service level agreement, advisors must order the contracts at least three days in advance. The process is however often rushed by advisors who are in a hurry to deliver the contract for the customer to sign. As such, it is not really an error, rather a measure of incorrect behavior of the advisors who do not plan their work accurately or customers who urgently need to get the deal done for one reason or another. The error Urgent matter will not be explicitly dealt with in this project since it has no affect on risk, cost and has a positive affect on customer satisfaction.

In Figure 6, the most serious errors with respect to risk, cost and customer sat-isfaction are shown. The errors are divided on what kind of loan it is and which category the customer belongs to. A loan is categorized as a regular loan or a mortgage loan, while a customer is either private or corporate. By analyzing the graph in Figure 6, the following observations can be made:

Figure 6. Serious errors by loan and customer type.

0,0%

5,0%

10,0%

15,0%

20,0%

25,0%

30,0%

35,0%

Incomplete matter

Form is missing

Promissory note or

loan file is missing

Incorrect

Promissory Note or Contract

Error in Land Registration

Authority matter

Incorrect

Pledge

Percentage of total errors

Corporate/LoanCorporate/MortgagePrivate/LoanPrivate/Mortgage

Type of error

Distribution of types of errors per loan and customer type


20

• The number of incomplete matters is larger for loans than for mort-gages (for private customers the factor is 13).

• Almost one third of errors in private mortgage loans are because of the physical file going missing.

• One in five errors in private mortgages is due to incorrect data sent to the Land Registration Authority*.

4.3.2 Identifying sources of errors

Simplifying reality, all errors in the process are human errors and either the advisors or the reviewers are responsible. The data available for study in the quality log provides a view on errors committed by the advisors, but it gives no information of possible errors made by the reviewers. This is a limitation, but argument can be made for the hypothesis that the quality of the overall process is largely due to the quality of the loan documentation provided by the advisors. Since the reviewers are specialists in the area of loans while ad-visors are not, possible errors are more likely to originate from advisors than from reviewers. The principle of the vital few within the insignificant many seems to be valid also in this case, as can be seen in Figure 7, with 35% of the errors being committed by 10% of the profit centers. A profit center is most often the same as a branch office, but it can also be special institutions within

* The Land Registration Authority (“Inskrivningsmyndigheten”) is a government body with the task of keeping track on who owns what property, also known as registering the title of the property. When a property is sold, the register must be updated with the new owner and it is the task of the bank to make sure this is carried out. Without a proper registration of title to the new owner, a mortgage deed cannot be issued and the bank has no security on the loan.

Figure 7. Pareto chart of number of errors per profit center.

0

50

100

150

200

250

300

350

400

450

500

X1 X2 X3 X4 X5 X6 X7 X8 X9 X10

X11

X12

X13

X14

X15

X16

X17

X18

X19

X20

Profit center

Num

ber of errors

0,0%

5,0%

10,0%

15,0%

20,0%

25,0%

30,0%

35,0%

40,0%

Accum

ulated percentage of total errors

Number of errors Accumulated percentage

E X E C U T I O N

21

the bank such as telephone banking or the profit center handling all employee loans. Since the number of errors is measured in absolutes, a profit center hav-ing a high number of errors do not equal less competent advisors and is more likely an affect of the number of loans handled by that profit center.

Studying Figure 7, profit center X1 stands out with its relatively large number of errors. Profit center X1 is telephone banking and handles a large amount of loans, which is an explanation of the large number of errors committed. One of the possible measures to reduce the number of errors is education for the advisors. The information gathered from Figure 7 gives an indication on where limited training resources are put to best use, should it be too expen-sive or not deemed necessary to educate the entire bank. A similar pattern of the vital few can be found when analyzing the number of errors on advisor level, but no example of this will be published in this thesis with respect to the advisors’ integrity and law.

4.3.3 Conclusions from the analysis

By analyzing the data in the quality log, we are able to identify the number and distribution of errors on advisor, profit center, district and regional level. Using this information, educations can be initiated, advisor be given extra support and abnormalities acted upon. The loan process involves all Swedish branches (totaling at almost 200) as well as the central process owners and it is in this context that the improvements will take place, and they will need to be initiated by the bank. The loan process is not as isolated as industrial proc-esses usually are, since it can start at any time, anywhere. The behavior of the advisors has a large impact on the quality of the process, and in order to im-prove the process, you would have to improve each and every advisor. Given the limitations of this thesis in time and money, improvements derived from the analysis will be of the nature of giving the bank the tools to improve itself rather than implementing change directly.

4.4 IMPROVE

One of the key issues in the loan process has been the lack of using data and facts rather than hunches and gut feeling to monitor and act on issues. The loan process is complex and geographically dispersed, making it very hard to get a feeling for the health of the process just by observing it. In this chapter, improvements that can be put in place immediately as well as improvements requiring development in IT systems are presented.

4.4.1 Closing the feedback loop

In the quality log’s database, information on the performance of individual advisors and profit centers is stored. The quality log has been used since 2005 but the information stored within has not been used in an effective way. When certain errors are committed, a letter asking for correction is sent in the post to the advisor responsible. In this way, advisors are made aware when they have made a mistake and are asked to correct or complement the matter. Not all errors generate a letter, and advisors are therefore not aware that they have made a mistake and will not have the opportunity to improve. Errors


22

not generating a letter are however logged in the quality log and this informa-tion needs to be fed back to the advisor in order to help them improve. Deliv-ering performance feedback to advisors and branch managers will be key in solving the problem of large numbers of errors in documents submitted for review.

4.4.2 A need for a new branch manager report

To solve the feedback problem, a new report to branch managers needs to be developed. There is already a report in place, but it is nothing more than a raw dump of the quality log database without any visualizations or indication of trends, since it only shows results one month at the time. Talking to advi-sors about the report from the quality log, it was clear that most did not know it existed and those who had seen it did not understand it. The new report therefore had to be both easy to use and to understand, with the purpose of assisting branch managers help advisors improve their performance.

4.4.3 Developing the new branch manager report

The quality log information is stored in an SQL database, which is accessible from all workstations within the bank for users with permission. Having the data readily available in a database is a prerequisite for developing a report which can be updated without a lot of manual work. The new branch man-ager report is developed in Microsoft Excel using PivotTables using a SQL server as the data source. The PivotTables are used to produce graphs for visualization and the tables themselves are used for drilling down the data, viewing it from different angles to give a comprehensive view on a certain branch or profit center’s performance. The new branch manager report con-sists of three different views from the same data source, they are:

• Number and type of errors over the last year as a graph • Number and type of errors over the last 31 days as a table • Number of errors over the last year per advisor

Figure 8. Number and type or errors over the last year for a single profit center.

Urgent matter

Incorrect Promissory Note or Contract

Promissory note or loan file is missing

Error in Land Registration Authority matter

Possible to handle in sales system

Incomplete matter

Incorrect Pledge

Form is missing

may jun jul aug sep oct nov dec jan feb mar apr may

2009 2010

Urgent matter



Error in Land Registration Authority matter


Incomplete matter

Incorrect Pledge

Form is missing

E X E C U T I O N

23

The graph showing “Number and type of errors over the last year” can be seen in Figure 8. The graph helps the branch manager to keep track of histori-cal performance and development of different types of errors. The branch manager can analyze the graph and note that the “Loan file is missing” error is particularly common at the time around the turn of the year. The branch manager can use this information to investigate why this has happened. Are there any special conditions at this time of year that need to be taken into con-sideration for the next year?

“Number and type of errors over the last 31 days” provides the ability to do a deeper dive into the errors committed the last 31 days. The information is presented to the branch manager as in Figure 10, with the ability to drill down the data to a more detailed level by double clicking on the error. Doing so would first reveal the error description on level two and a then the advisor, allowing the branch manager to follow up on why the error was committed.

“Number of errors over the last year per advisor”, shown in Figure 9, is simi-lar to the previous PivotTable, but instead of using the type of error as start-ing point it uses advisor. In this way, the branch manager can see if a certain advisor is responsible for a large number of errors. By being able to drill down the data on what kind of error the advisor has committed, the branch manager can help the advisor improve in that area.

In designing the new branch manager report, emphasis has been put on mak-ing it user friendly and visual. This is manifested through the use of graphs and PivotTables, which start at a high level to provide an overview instead of overwhelming the user with details. Additional features that were not present in the old version have also been added. The branch manager has the possibil-ity to filter the data on customer and loan type. For customers the options are All, Corporate or Private and for the loan type they are All, Mortgage or Loan. It is important to allocate the responsibility to the correct part within the branch since they are usually split organizationally on private and corporate clients. The filtering is set up using standard radio buttons that the users should be familiar with. The new branch manager report has gone live and replaced the old version as of June 1, 2010 and is maintained and updated by loans review.

Figure 9. Screenshot of number of errors for advisor last year.

Figure 10. Screenshot of number and type of errors over the last 31 days presented in PivotTable with drill down features.

Error description level one Error level two Advisor No. ErrorsPromissory note or loan file is missing 2

Incorrect Pledge 1

Form is missing 1

Grand Total 4


24

4.4.4 The process owners lack of data as decision basis

The loan process has got two process owners. One process owner is responsi-ble for the front office part of the process, while the other is responsible for the back office part. The two process owners have monthly meetings with improvements to the process on the agenda. The process owners are able to make significant changes to the process and they have resources to spend on education, IT development etcetera. As the top authority on the loan process, the process owners enjoy credibility from the business, which facilitates the implementation of changes at all levels of the organization. There has so far been a lack of data as decision basis in the monthly meetings, and when data have been occasionally used, quite rudimentary analyses have been made. In the following sections, the tool, which has been implemented during the the-sis, is presented alongside with a concept for further development.

4.4.5 Monitoring tool for the process owners

Just as the report to branch managers, the monitoring tool for the process owners uses the information in the quality log database to produce graphs and PivotTables. It allows for the process owners to quickly analyze the per-formance for a chosen date span and to filter the data on corporate and pri-vate clients as well as on loan and mortgages. Given these settings a screen of three graphs are displayed in what is popularly known as a dashboard. The idea behind a dashboard is to give an overview of different measures while also providing the ability to drill down the data into more detail. The meas-ures shown in the monitoring tool are:

• Top 10 profit center by number of errors • Distribution of errors • Top 10 advisors by number of errors per district • Number of errors for the last year

The first three measures are calculated for the time span chosen by the user, while the last measure always displays the number of errors from today’s date and one year back. Filtering on the type of loan and client are reflected in all measures. A screenshot of the monitoring tool is available in Appendix for reference. As shown in the analyze section 4.3, this information can be used to draw conclusions on problem areas and give the process owners something to act upon. As of mid-May 2010, the process owners have been given access to and education by the author in how the monitoring tool is used. Since being given the monitoring tools, the process owners have initiated the following measures:

• Asking branch managers of the ten profit centers with the highest number of errors to provide a plan on how they will reduce their num-ber of errors.

• Identifying the advisors who are most frequently responsible for seri-ous errors and forwarding this information to branch or district man-agers.

E X E C U T I O N

25

As the process owners get more used to working with the monitoring tool, they will hopefully find even more measures to be initiated from information presented by the monitoring tool.

4.4.6 Further development of the measurement tool

In the measure section, we identified possible sources of variation on the loan processing time, out of which, three (errors in review cases, delay in submit-ting documents and reviewer competences) were deemed as being possible to measure. To get access to these measures, further development will be re-quired by the IT department to make the necessary data available in the BIW. Please see section 2.3 on data warehousing for a detailed description on the mechanics of data handling at the bank. At the time of writing, a request for proposal for development costs and time has been sent to the IT department who are working on making an offer. The project has been deemed as techni-cally possible and the bank will need to make a cost-benefit analysis once the request for proposal is finished. If the bank chooses to invest in the develop-ment, they will be able to measure factors reflecting the sources of variation as well as other interesting indicators:

• Documents not submitted on time. • Profit centers submitting incomplete loan files. • Reviewer competences (expressed as the time required to review a

loan). • The number and amount lent of loans not yet finished, i.e. the backlog. • Percentage of errors of loans disbursed. • Time from disbursement to finished loan. • The most dangerous loans in the case of a default.

The advantages with these new measures are not only an increased under-standing of the process. They are leading instead of lagging indicators and more accurate since the data are extracted from a computer system rather than manually logged, as is the case with the quality log. A discussion about how these measures will be constructed is presented in section 4.2.3. Presenta-tion of the measures and graphs can be made using the same concept as for the branch manager report and the monitoring tool for the process owners.

With the additional data from the BIW, process owners and other stakeholders will gain more insight and knowledge on the performance of the process. The new data also lends itself to more advanced analysis techniques. The percentage of errors of loans disbursed could be analyzed using statistical process control and control charts. Using control charts with specification lim-its would allow for a passive control of the percentage of errors while allow-ing alarms to go off in case too many points are outside the limits. All in all, the BIW data would open a whole range of possibilities for process owners and others to make initiated decisions.


26

4.5 CONTROL

The number of errors logged in the quality log can be seen as an indicator of improvements in the process. As the number of errors varies with the number of loans issued by the bank, it needs to be interpreted with some caution. The improvement project initiated by the bank started in December 2009 and was finished in March 2010, while work with this thesis continued into May 2010. The number of errors per month is presented as a graph in Figure 11, please note that the data was updated on May 18, 2010. From February onward, a trend of decreasing number of errors is indicated and by using interpolation, the trend seems to continue in May as well (approximated to 1 200 errors).

A more robust method of controlling the process would be using processing time, the percentage of errors and the size of the backlog. When or if those measures are available in the future, they should be used as the primary method of controlling the loan process.

Figure 11. The number of errors per month. Data updated May 18, 2010.

E X E C U T I O N

27


28

5 C O N C L U S I O N S & D I S C U S S I O N

5.1 CONCLUSIONS

At the beginning of this thesis, the applicability of the Six Sigma DMAIC methodology on an internal process at a Swedish bank was questioned. What conclusions can be made after having conducted a case study at the loan process? With reference to the case study and the results achieved within, it is most certainly possible to apply Six Sigma in the banking industry. There are however some reservations and pitfalls which practitioners need to be aware of. The potential for applying Six Sigma at banks in Sweden is large, but there are issues regarding the maturity and competences of the studied bank that are thought to be a problem shared with competing banks. Most importantly, the availability and quality of data for analysis was a severe problem in the case study, limiting the array of applicable statistical tools that could be used. The high costs and time consumed by having to involve the IT department needs to be taken into consideration when assigning resources to the Six Sigma project. The outlook at the moment of writing is that the bank will not follow through on the BIW development due to lack of resources.

Lack of data has been identified as a common problem when using Six Sigma in the financial services industry by Heckl et al. (2010) and is not a unique problem for the bank or the specific process. Measuring performance in the loan process at the bank posed is different from measuring a more traditional industrial process. While a machine does not operate differently because its performance is being measured, this is often the case with humans. Catasús, Ersson, Gröjer and Wallentin (2007) examined if there is any truth behind the popular management adage “what gets measured gets done”. In their study, the authors suggested it be rephrased as “what gets talked about gets done, especially if there are numbers”. As opposed to an industrial process, measur-ing and talking about a problem at the bank can help reduce it, which adds a new dimension to measuring a process. The Six Sigma methodology’s strong focus on measurable bottom line effects is encouraged by the bank’s culture and would therefore work well as a compliment to the current lean based methodology. It does however require the right prerequisites such as choos-ing the right project, having the right competences and access to good quality data.

In the banking industry, changing a process will most certainly involve mak-ing changes in the IT systems. Since banks still rely to a large extent on legacy IT systems (Hayler & Nichols, 2006), changes in IT generally take a long time and cost a lot of money. For a Six Sigma project to actually implement im-provements and not just make suggestions, there needs to be an adequate budget allocated to the project. Otherwise the project will be pinioned by the lack of financial resources and confined to working with less advanced tools, thereby missing out on some of Six Sigma’s potential. As identified by Heckl et al. (2010), the less advanced tools are the ones thought to be most useful by practitioners of Six Sigma in the financial services. Whether this is due to the

C O N C L U S I O N S & D I S C U S S I O N

29

nature of the more advanced tools or because of the lack of resources in em-ploying them is not discussed by Heckl et al. and would be an interesting topic for further studies.

5.2 RESULTS & SAVINGS

Given the lack of data on the loan process, hard savings will be difficult to prove since they cannot be measured with the existing data sources. The measures that do exist, such as the number of errors per month, is influenced by a lot of factors and to establish a causality between the work in this thesis and the number of errors is problematic. The hard savings that can be proven are:

• Four hours per month saved in compiling the branch manager’s report, as it is now automated.

• Time saved for almost 200 branch managers, as they get readymade analyzes of the quality log instead of having to make them themselves.

• Time saved for the process owners by making analyzes of the quality log easier and less time consuming.

Even though the number of errors committed is not a good performance measure since it deals in absolutes instead of relative measures, it can be used as an indication of how the process in performing. In May 2010, 800 errors less were logged as compared to May 2009 which means somewhere between 260 and 800 man-hours less spent on rework. In Swedish krona, the reduction of time wasted corresponds to between 67 600 and 208 000 per month in sal-ary costs. This result should be seen as a semi-hard saving as the causalities and other affecting factors can be questioned as mentioned above.

The potentially substantial savings as a result of this thesis are of a more soft nature and will probably not been seen earlier than six months from the end of the thesis. The idea behind the end products delivered in this thesis to give the people with the power to improve the process the tools to do so. This is achieved through the monitoring tool and branch manager report that iden-tify deviations and ensures that problems are brought into the light and gets dealt with. An internal consultant who has been working with the project summarizes the results of the thesis as:

What we really appreciated with the approach taken in the thesis was the strong focus on decisions based on facts rather than common notions. While we understood that it probably was possible to do more with the data we had available – we did not have the time or the competence to pursue it. The de-liverables of the thesis have been very well received and cre-ated a pull from business areas not initially covered by the improvement project. While I can’t put a figure on how much the thesis will have saved, it made a significant difference to the project and more importantly it illustrated the possibilities of using data in a way that people can actually act upon it.


30

5.3 VALIDITY & RELIABILITY

The uncertainties of the data in the quality log has been an issue throughout the project, but as there were no other data sources available, it had to be ac-cepted. The analyses from the quality log data are therefore to be thought of as indicative rather than as absolute truths. The reliability would increase sig-nificantly if an investment in the BIW would be made, since computers with-out human interference log the information automatically.

5.4 GENERALIZABILITY

The title of this thesis is Six Sigma in Swedish banking, even though only one bank has been studied. There are however reason to believe that the result, that Six Sigma can be applied to an internal process, holds for other major Swedish banks as well since they operate in similar ways and sell the same king of producs. The methodology has been successful at banks outside of Sweden and the problems faced are similar. The greatest lesson learned that a practitioner wishing to use Six Sigma at another Swedish bank should con-sider is; make sure that you have got enough data available or an adequate budget to make it available before you start.

5.5 DISCUSSION

Being able to use a certain methodology requires a lot of prerequisites to be in place. Having a suitable process as the object of improvement is not enough if the organization has not reached maturity in its engagement in quality. As this thesis was carried out within the realms of the bank’s lean based im-provement program, the same rules and limitations on resources applied, which in general means nothing more than the consultants’ time. Such a set-ting is not adequate for a successful Six Sigma project, which has to be able to use the resources necessary given that the expected return on investment is good enough.

The high inertia associated with involving the IT department is well known within the bank and created resistance when seeking buy-in from managers. On a more personal note, dealing with the IT department sometimes felt like banging your head in a brick wall and a more visible support from senior management would probably have helped in making things happen. Never-theless, this thesis can be seen as a proof of concept in using more quantitative statistical tools to drive improvement within the bank. As the lean based im-provement program moves into its fourth year, most of the low hanging fruit will soon have been picked. Although there is no need to replace lean as the basis for the improvement program within the bank, there are probably great benefits to be reaped by investing in training for the internal consultants. Competences in statistical tools such as statistical process control as well as handling relational databases and analyzing large data sets would be very useful but are largely non-existent. The reception of the measurement tools developed in the thesis got a very positive reception by the business and has hopefully created a demand for fact instead of hunches.

C O N C L U S I O N S & D I S C U S S I O N

31

It is not without reason that the words “lack of data” have appeared several times throughout the thesis. The inflexibility of the legacy IT systems and the endurance required to get access to data severely prevents the business from getting accurate information on their problems. The ideas presented in this thesis are all very simple from a technological perspective – but with a lead time from order to answer of more than two months for a data request most people will choose to guess instead of getting facts. DMAIC’s strong focus on data has been a support throughout the thesis in requesting data from various stakeholders. Once again, the lack of data is probably hiding problems in a lot of areas within the bank. The current loan process project was not initiated because data showed that it was a big problem – it was already so problem-atic that everyone who worked in the process could feel that it was not good, data then showed just how big it was. Hopefully, a better usage of the data available will help in solve the problem for good.


32

33

6 R E F E R E N C E S

Ahmed, B., Buttle, F. (2001). Customer retention: a potentially potent market-ing management strategy. Journal of Strategic Marketing 9(1), 29-45.

Antony, J. (2006). Six sigma for service processes. Business Process Management Journal, 12(2), 234-248. Retrieved April 26, 2010, from the Emerald da-tabase.

Antony, J., Antony, F. J., Kumar, M., & Cho, B. R. (2007). Six Sigma in service organisations. International Journal of Quality & Reliability Management, 24(3), 294-311. Retrieved April 26, 2010, from the Emerald database.

Arvidsson, N., & Cornéer, L. (2009). Lean inom tjänsteföretag. Linköping: Linköpings universitet.

Basel Committee on Banking Supervision. (2003). Advanced measurement ap-proaches for operational risk: supervisory expectations. Basel: Basel Com-mittee on Banking Supervision.

Baxter, P., & Jack, S. (2008). Qualitative case study methodology: Study design and implementation for novice researchers. The Qualitative Report, 13(4), 544-559. Retrieved May 2, 2010, from http://www.nova.edu/ssss/QR/QR13-4/baxter.pdf

Gummesson, E. (1991). Truths and Myths in Service Quality. Journal of Service Management, 2(3), 7-16.

Hayler, R., & Nichols, M. (2006). Six Sigma for Financial Services: How Leading Companies Are Driving Results Using Lean, Six Sigma, and Process Man-agement (1 ed.). New York: McGraw-Hill.

Heckl, D., Moormann, J., & Rosemann, M. (2010). Uptake and Success Factors of Six Sigma in the Financial Services Industry. Business Process Man-agement Journal, 16(3). Retrieved April 26, 2010, from the Emerald da-tabase.

This is a pre-print of a paper and is subject to change before publica-tion.

Johnson, M. D., Nader, G., & Fornell, C. (1996). Expectations, perceived per-formance, and customer satisfaction for a complex service: The case of bank loans. Journal of Economic Psychology, 17, 163-182.

Keller, P., & Pyzdek, T. (2009). The Six Sigma Handbook (3 ed.). New York: McGraw-Hill Professional.

Kumar, S., Wolfe, A. D., & Wolfe, K. A. (2008). Using Six Sigma DMAIC to improve credit initiation process in a financial services operations. In-ternational Journal of Productivity and Performance Management, 57(8), 659-676. Retrieved April 26, 2010, from the Emerald database.


34

Nilsson, L., Johnson, M. D., & Gustafsson, A. (2001). The impact of quality practices on customer satisfaction and business results: product versus service organizations. Journal of Quality Management, 6(1), 5-27. Re-trieved April 28, 2010, from the ScienceDirect database.

Shostack, G. (1977, Winter). Banks sell services - Not things. The Banker's Magazine, 32, 40-45.

Sörqvist, L., & Höglund, F. (2007). Sex Sigma. Resultatorienterat förbättringsar-bete som ger ökad lönsamhet och nöjdare kunder vid produktion av varor och tjänster. Lund: Studentlitteratur.

Williams, R., Bertsch, B., Dale, B., van der Wiele, T., van Iwaarden, J., Smith, M., et al. (2006). Quality and risk management: what are the key is-sues?. The TQM Magazine, 18(1), 67-86. Retrieved April 28, 2010, from the Emerald database.

Yin, R. K. (2003). Case Study Research: Design and Methods (3rd ed.). Thousand Oaks, CA: Sage.

1

A P P E N D I X

Figure 1. Process map of the loan process.

The loan process

CustomerFront Office FunctionsLoans

production

Loans review

Loan request

Credit control

Loan offer

Close case

Passed

Produce loan

contract

Application

possible to

handle in

sales system?

Register web

assignment

No

Loan contract

Yes

Control and verify

loan contract

Sign contract

Disburse loan

Document

formalia and

information

correct

Post loan

documents for

review

Post queue

6-12 days

Review

documets

Decision to buy

Close errand and put

documents in archive

Yes

Retrive

complementary

information/signa

ures/documents

No

Registered in

The quality log

System 1

Work flow

management

system

Denied

Assignment

within SLA

Yes

No

No

Register loan

in system

System 2

System 3

Foreign currency

Bank financing

Mortgage

Mortgage?

Yes

No

2

Resultatställe

X1

Historisk utveckling

Typ av fel senaste 31 dagarna

Antal fel per handläggare senaste 12 månaderna

Felbeskrivning

Felorsak

Handläggare

Antal fel

Handläggare

Felbeskrivning

Felorsak

Antal fel

Handling saknas/Form is missing

323

Brådisärende - jämför m

ed ankomsttid i prodkön/Urgent m

atter

317

Fel i pantsättning/Incorrect Pledge

314

Fel i skuldebrev/Kontrakt/Incorrect Promissory Note or Contract

213

Matter handled in sales system

112

Fel i inskrivningsärende

112

Kredit- / Låneakt saknas/Promissory note or loan file is missing

111

Ofullständigt uppdrag/Incomplete matter

110

Grand Total

1510 10 9 8 7 7 7 6 6 6 6 5 5 5

The quality log april-maj 2010 Historisk kvalitetsnivå

0102030405060

maj

jun

jul

aug

sep

okt

nov

dec

jan

feb

mar

apr

2009

2010

Brådisärende - jämför med ankomsttid i prodkön/Urgent matter


Fel i pantsättning/Incorrect Pledge

Fel i skuldebrev/Kontrakt/Incorrect Promissory Note or Contract


Handling saknas/Form is missing

Kredit- / Låneakt saknas/Promissory note or loan file is missing

Ofullständigt uppdrag/Incomplete matter


Endast för verktygsförvaltare

Resultatställe: X1

Uppda t er a t : 2010- 05- 05

Lånetyp

Endast bolån

Endast andra lån

Alla lånetyper

Kundtyp

Endast privat

Endast företag

Alla kunder

Figure 2. Branch manager report.

3

Figure 3. Monitoring tool for process owners.

FrånTill

Read more

Read more

Da t a upda t ed 2010- 05- 06

2010- 05- 012010- 05- 05

AllaPrivatFöretag

Top 10 Profit centers by number of errors

0

2

4

6

8

10

X1 X2 X3 X4 X5 X6 X7 X8 X9 X10 X11 X12 X13 X14

Profit center

Distribution of errorsUrgent matter

Form is missing



Incorrect Pledge

Incomplete matter




Bolån

Kundtyp

Lån

LånetypDatum

Alla

Total number of errors last 12 months

0

500

1000

1500

2000

2500

maj-09 jun-09 jul-09 aug-09 sep-09 okt-09 nov-09 dec-09 jan-10 feb-10 mar-10 apr-10 maj-10

Egentillverkad kredit/Matter handled manually

4

Table 1. The DMAIC cycle described by four different authors.

Author Define Measure Analyze Improve Control Kumar et al. (2008)

Identify process in need of improve-ment.

Data relat-ing to the process is gathered.

The data are ana-lyzed to determine causes of defect or problems

Eliminate identified causes of variation.

Maintain the improvement set in place.

Antony (2006)

Define the problem.

Measure the prob-lem (i.e. defects which are responsi-ble for the problem)

Analyze the data to discover the root causes.

Improve-ment of the process to remove root causes.

Monitor the process to prevent the problem from recur-ring.

Sörqvist and Höglund (2007)

Thor-oughly de-fine the problem with the intent to describe what hap-pened.

Gather facts about the prob-lem through data collec-tion and measure-ment

Analyze the data to identify root causes.

Implement suitable improve-ments.

Establish continuous control to se-cure long time effec-tiveness of the im-provements.

Keller and Pyzdek (2009)

Define the goals of the im-provement activity.

Measure the exist-ing sys-tem. Estab-lish met-rics to monitor progress towards the goal.

Analyze the system to elimi-nate the gap be-tween cur-rent per-formance and goal.

Improve the system. Be creative in finding ways to do things bet-ter, cheaper and faster.

Control the new system. Institutional-ize the im-proved sys-tem.