Bank Branches need Process Improvement

I am generally a happy client with my personal bank here in Australia. Their online services are good, they have excellent phone service, always reply to my enquiries with a smile, and service fees are kept at a minimum. However, two weeks ago I had an experience I thought belonged to the pre-Gorbachev era. My wife and I went to the bank in order to integrate consolidate our bank accounts and personal finances. Also, we wanted to migrate a single credit card into both our names as shared card holders. With many couples consolidating their banking business every day, this really shouldn't be a complex process, even though it turned out to be a dull three hour experience. Forget about going to the bank in your lunch break to finally get those accounts sorted out: you will need at least an afternoon to get things right.

Let's investigate the processes involved in this relatively client request: 

1. Verify client identity
2. Open x new client bank accounts
3. Transfer funds from existing bank accounts to new bank accounts
4. Close y old client bank accounts
5. Update client and card holder details for MasterCard credit card
6. Verify details and finalise client request

For a bank (and the branch officer), these processes should be relatively trivial and simple. Following Porter and Harmon (Harmon, 2007), these are core bank service processes. I had expected 30-45 minutes including a couple of signatures, a few mouse clicks, and maybe an internal phone call to a service desk. How could that result in three hours? These were the main process flaws:

1. The poor customer service officer spent more time looking for the correct paper forms and subsequently printing these out for further processing. The bank has a comprehensive Intranet site providing access to all client request forms with an enormous tree folder structure, and she even tipped over the screen so I could have a look for the right place to find the form. All relevant forms for a account closure and account opening were located in completely different folders, completely detached from the actual client task. Furthermore, all forms were given long, cryptic names, which made the whole operation even more painful (who would have guessed that HD30 is the code for an account transfer request?).
2. Lack of task and process orientation: the user interface on the service officer's screen was data-driven and not process-focused. For each step in the processes, she had to navigate through a hierarchy of different Intranet pages to find the right forms and data entry screens. Some of these screens (or web based wizards) were task oriented, but only at the most local level. One client request thus consisted of invoking six different wizards dispersed over three different application systems each with its own user interface, constraints, and terminology. I would recommend looking in to consolidating end-to-end business processes inside the same process engine operating on the same account data.
3. Basic process tasks were delayed and not properly formalised. It is crucial for a bank to verify the identity of its clients to prevent fraud, also for people walking in from the street. Verifying the client's identity should this be a basic condition for proceeding with any further steps in the above processes. But only after 30 minutes spent on printing out five-six different request forms and allocating all of our bank accounts did the service officer actually ask for our driver's licenses in order to confirm that I was actually me. Now, what if I had forgotten my driver's license and I had to come by another day? That could have saved both her and I for 60 wasted minutes, although I fortunately had remembered my license. It is probably the most basic conditional task (or in BPMN terms: decision gateway) for all basic client processes. All requests demand confirming the correct identity. Move all conditional, security and identity related decision points to the earliest possible point in your banking process. It might sound like common sense, but with multiple entry points for invoking a client request (online, in person, phone call), it is crucial to use integrate all authentication in a uniform fashion across all business processes.
4. No visual graphic of process path and progress---neither for the service officer or client. A visual progress overview generally makes people more patient and clarifies the tasks at hand (imagine having a non-technical EPC or BPMN model of all of the above processes for the customer service officer to follow).
5. No process Key Performance Indicators or client feedback integrated into the workflow. The friendly, but frustrated customer service officer could have ended the (albeit very lengthy) transfer process by asking me: how would you rate this transaction? Is there anything we can do better? Process improvement demands learning and systems feedback being fed back into the next process cycles. Only from incremental improvement cycles can significant process improvements be won (Seddon & Caulkin, 2007). This demands a balance between quantitative (e.g. processing time, number of mouse clicks, processing/systems exceptions) and qualitative process indicators (client satisfaction, that friendly smile on the face, welcoming clients in the branch, offering them a glass of water whilst the banking transaction is cooking) (Zokaei et al., 2010).

These recommendations and conclusions are by no means revolutionary or unique. The important difference is that ideas emerged from a---at least in the blueprints---simple visit to my local bank; a visit that in the end brought a lot of frustrations and ultimately improvement ideas on the table. With the billions of dollars each year spent on IT portfolio management and business analysis in the financial sector and a GFC finally returning to the historical wastelands of our capitalist society, one would assume that significant improvements---and (systems) learning---have been discovered. Paradoxically enough, the budgets are apparently still spent on building cluttered unintuitive user interfaces and manually integrating disparate data sources at the cost of redundancy, whilst ignoring the fundamental structure of systems learning and feedback.

References

Harmon, P. (2007), Busines Process Change, 2nd edn, Morgan Kaufmann Publishers.

Seddon, J. & Caulkin, S. (2007), `Systems thinking, lean production and action learning', Action Learning: Research and Practice 4(1), 9-24.

Zokaei, K., Elias, S., O'Donovan, B., Samuel, D., Evans, B. & Goodfellow, J. (2010), Lean and Systems Thinking in the Public Sector in Wales (Report for the Wales Audit Office), Technical report, Lean Enterprise Research Centre, Cardi Business School, Cardi , Wales, UK