10 lessons learnt when DBS came out of the Stone Age

4 April 2017

By PAUL COBBANChief Data and Transformation Officer, DBS Bank

Photo: Kelvin Chow, 2009

Lessons we learnt when innovating as a team

I still remember my first day at DBS. When I told the Singapore taxi “uncle” where I was going he said, “DBS – Damn, Bloody, Slow.”

There’s no doubt that in 2009 DBS had a well-earned reputation for being a bureaucratic, unimaginative and unresponsive bank.

We also had a new Chief Executive, Piyush Gupta determined to turn that perception around. We knew we had to do things differently but where to start?

Our inspiration came by looking outside the banking sector to the automotive industry and in particular the concept of Kaizen. Developed by Japanese management guru Masaaki Imai, Kaizen is a process of continuous improvement, initially across car production lines. It is the foundation of the Lean methodologies you read about today.

Having had the privilege of meeting Masaaki Imai personally during a tour of Japanese factories I could see the power of this process in modern day manufacturing. But could it work in a bank? We gave it a go anyway.

We started with a project we called the RED programme and created a type of workshop which became known as Process Improvement Events or PIEs (the PIE or Pan Island Expressway is the longest expressway in Singapore).

We had learnt from Imai that to improve processes we needed to take out waste defined as anything that doesn’t add value to the customer. One Monday morning, my colleague and I walked into a room armed with nothing but butchers paper and post-it notes and led a small, slightly bewildered cross-functional team through a five-day process that dramatically reduced the time and effort it took to handle one specific problem – retail account opening by mail.

Day 1: Walk and map the current state.

First we needed to know what we were up against. We forced the team to physically walk the entire DBS process step by step, taking notes, interviewing staff and recording times. We then created a large "current state map" on the wall indicating each step with timings and issues. We marked the steps that added value with green dots and those that didn’t with red dots. We calculated effort and time for the entire process. It wasn’t pretty.

Day 2: Map the future state.

We asked the teams to create a new version of the process for opening this account. This time, tried to eliminate as much waste as possible. We estimated the resultant levels of effort and end-to-end times. Much better but so far a theoretical exercise on paper.

Day 3: Decision-making session.

We asked the seniors responsible for the process along with risk executives to review the current and future states. Then we asked them to go through the list of changes required and give a decision on each as to whether the team could proceed.

Day 4: Refine the solution.

Based on the direction of the seniors the solution was refined and an implementation plan developed. We wanted to action as many of the changes as possible, and we wanted to do it immediately.

Day 5: Outbrief.

The team presented the solution to the senior team, and we went ahead.

By refining that one process we reduced the turnaround time for opening a new account by post from 21 days to five.

We initially ran a pilot of five PIEs across various parts of the business to test and refine the approach. We soon stepped that up to 50 PIEs and then over 200.

At the end of the RED programme, we estimated we reduced customer waiting time by 250 million customer hours. If you go back in time 250 million hours, you end up in the Stone Age!

10 lessons we learnt

Results aside, there were learnings along the way when we implemented Kaizen and these were valuable lessons, on top of the implementation itself.

The admittedly low-tech approach of intensively challenging a customer process over five days with teams from across the bank changed the game for us. We learnt a massive amount during PIEs that has stood us in good stead as we’ve continued on our transformation journey:

1. We had gargantuan amounts of waste in our processes. We estimated that an eye-watering 95% of our processes were the waste. Previous efforts had focused on improving the 5%. It was far easier and more impactful to focus on slashing the waste that doesn’t help the customer.

2. Not once in any of the 200 plus PIEs did we come across a single person who understood the end-to-end flow of that process. We needed to assemble a team from across the bank simply to map the current state. Many times people were oblivious to the chaos they were causing with one additional step to the downstream process.

3. You need to experience the process for yourself. Documents and process charts do not show you the problems. By walking the process, we found mind-boggling issues. In one example a process diagram showed a cut and pasted step – we assumed this was at the click of a mouse – but we found out that it was, in fact, someone using scissors and glue! Many showed handoffs to other departments – but failed to show that department was in a different location.

4. Most of the waste is caused by organisational silos. The handoff between departments always creates an overhead. We made most of the improvements by eliminating handoffs.

5. Saying no is very easy on email. Before the PIE programme, process experts had often proposed changes based on email. They typically were either ignored or rejected as too hard. We supported our PIEs by creating a three-day decision-making process. It became much more difficult to say no or to sit on changes when you come out of a meeting with an enthusiastic team that has worked for 48 hours to propose an improvement for the customer.

6. Visualisation of the process and its waste is critical. We had hundreds of "light bulb moments" when participants saw the sheer volume of unnecessary waste in our work. This always happened once we had mapped the current state and put a handful of green dots and an entire sea of red dots.

7. Experimentation breaks through resistance. The vast majority of the time we had nothing but support from the executives. However once in a while, we had people who were reluctant to change from the status quo. We found the best way through this was to seek permission to run an experiment. "Just let us try one time and see what happens" we would say. More often than not this removed the blocker and became a technique that would underpin future programmes.

8. It takes five days. It’s a big ask to take a team of people out of their day job for five full days. We were often asked to cut this back, and we relinquished a number of times but the outcomes were always sub-standard.

9. Picking the right measure is key. Before the PIE programme our measurement was inconsistent. We were typically measuring how much effort each process was taking but not the end process time.

By insisting on measuring end-to-end from the customer point of view (i.e. in calendar days, not business days and from when a customer makes a request to getting it fulfilled), we gave a clear signal that the purpose of the programme was to improve customer experience and not drive productivity.

10. Act quickly: don't wait for the system change. We insisted that the teams only find solutions that don’t involve changing any IT system which can take months. We wanted fast improvements. Despite this, more often than not the team insisted on system change. So we ended up allowing a two-phase approach – first the quick wins and then moving on to the system changes.

According to Malcolm Gladwell in his book Blink, to become an expert you need 10,000 hours of experience. The Beatles notched this amount up when they were playing the bars of Hamburg in the early 1960s.

The PIE programme was our Hamburg moment. We learnt an incredible amount about how to drive change, we learnt how the bank operated and most importantly we started to understand the culture of the organisation.