Dan Curran is the executive general manager for core banking modernization at Commonwealth Bank of Australia, the country's largest bank with $620 billion in assets. Now partway through the core conversion that kicked off in the spring of 2008, Curran spoke with Bank Technology News about why the bank embarked on the project, why it choose SAP and what it takes to succeed.
What's the strategic rationale behind your core upgrade?
We have a very clear strategic imperative; we want to go to No. 1 in customer service in our market [by] genuinely putting the customer at the top of what we do and then use that [new core] as a growth platform.
Many banks would say they are already customer centric.
As banks, we've been talking about being customer centric for years but in reality our legacy world is still product stovepipes. While we put [the customer] at the center of what we do, our systems don't, and in the digital world a bank lives on its data. If it's not built around the customer then you're not genuinely customer centric.
So how does the core upgrade facilitate growth?
Two ways: Organic growth, that by becoming more agile you can respond to market conditions; and inorganic growth, a platform for acquisitions and other types of third-party relationships.
How did you choose SAP as your core platform provider?
Rather than an RFP we did a lot of scenario testing with different vendors. In the case of SAP they said we can't do this scenario out of the box, we'd need to do some development and our guys sat down with their guys and they realized that because it was architected well you could take pieces of existing functionality, put them together and actually solve the problem. That was a real "a-ha" moment for us. If you actually architect this right you can actually take your different components and put them together. In banking we're used to having everything you need in term deposits living in the term-deposit stovepipe, everything you need for a saving account lives in its stovepipe. But the interest module is the same; the statement module is the same. If we industrialize our back area, you can take pieces we originally built for something else and use them for what you need; in the end that's the reason we went with SAP.
So how are you actually making the switch?
We're doing a series of launches and migrations. The last thing we wanted to do was to build the new bank looking like the old bank, so we're launching the new capability, prove it works and then migrate the old to that, and that way we're building the new bank and taking the old one to it. Now we're very much focused on the deposit and transaction space and we'll move to lending after that.
Any advice for others considering such a project?
Be careful because it's bloody hard. If you just want to get efficiency and deal with [operational] risk there are a whole lot of ways to deal with the problem that are less expensive and give you quicker short-term reward. For us it's stopped being a technology program and started being a business transformation program, which has really excited us. Every day you realize it's not about the technology, it's about the transformation of an organization and genuinely creating the customer centricity in the business orientations.
