Towards Banking Agility

December 12, 2005 by SAP News

What are the key business challenges in today’s banking?

Skeels: You can word it in all different ways but it really comes down to more or less three simple things: How to grow, how to keep control of costs, and how to keep up with regulation. The European marketplace is very tough, especially with new entrants like supermarkets and car companies attacking certain market segments and international banks pressuring local banks. Add this to an arguably overcrowded marketplace and the whole picture is very competitive. To grow, in simple terms, the banks can either differentiate themselves giving themselves opportunities to grow organically or they can grow by merger and acquisition. In either case, the banks have to be clear on their strategy and be agile enough to follow it. Secondly, they need to keep costs down. That doesn’t always mean spending less in total but it does mean that any investment must improve productivity. This is all about industrialisation of the banks. Thirdly, regulation keeps growing. There is little prospect of regulation decreasing, especially for international players. And, even if not directly impacted, local or regional banks still get affected by a regulation “trickle-down” effect. So the banks need to be flexible and innovative, industrialise their operations, and keep up with the regulations. They need to be agile.

Are banks currently able to gain such agility?

Skeels: One of the key things here that banks can’t do today is to actually change what they offer very rapidly. Historically Banks automated each business unit separately and then refined the automation by business unit, or silo, to make it work very efficiently and very fast. But now, when they want to add or change a process, perhaps to launch a new product, it is very difficult and time consuming. For example, a bank may want to launch a new product that is going to be sold across multiple channels. Typically each of the channels, branch, call centre, internet are separate business units each with their own supporting systems. To launch the product and create its account opening process may involve significant changes to at least four systems, that is, a system per channel plus the account management system. Testing alone may take weeks.

What has the banking industry to do?

Skeels: Two things: One, the business needs to think not in terms of the silos of established IT landscapes but to start thinking enterprise wide and – second – then to start thinking of how they can separate the systems into reusable and recombinable elements. A key part of this is to separate the processes from the business application function so that either can be changed separately. Essentially the bank should create a shared process platform that all the business functions can use. This process platform should not just satisfy a business silo, it should satisfy the overall enterprise process wants and needs.

SAP’s answer is the Enterprise Services Architecture. What is the idea?

Skeels: The Enterprise Services Architecture goes much further than just separating business process from business function. ESA combines flexible infrastructure and flexible business function. A typical service oriented architecture (SOA) only addresses the infrastructure. ESA does more. As with SOA, ESA separates out the areas of enterprise process, information and roles. But what ESA does and SOA does not, is directly incorporates the reuse and recombination of business function. This business function can be existing, internally developed, or from third parties. This reuse and recombination provides enormous flexibility to innovate.

Which role plays IT?

Skeels: IT is a key success factor. ESA makes a “strategic weapon”, the enabler of innovation and rapid adaption. If you look at IT budgets, in the application development area up to 80 percent is spent on maintenance. This leaves a very small amount of budget spent on moving forward. Banks need to reduce the maintenance. Part of the reduction can come from banks providing less of their own software and getting more from vendors like SAP. Furthermore, as ESA is implemented, changes will be increasingly made by recombining existing business services or changing processes rather than recoding. This means accelerated change cycles and reduced complexity to maintain. All of this improves the IT budget alignment with the business direction. IT becomes an enabler rather than bottleneck. Another problem that the IT faces is demographics around supporting their existing systems. The number of skilled people to support them are diminishing. IT does not want to be dependent on a diminishing resource. So they should move to newer technologies and take advantage of growing and transferable skills. This move can be helped by migrating to more modern applications, like those from SAP, that have newer architectures and use newer technologies such as J2EE and Web services. These technologies have growing skill pools. Also, these technologies are more appealing to new recruits. So, even if there are some shortages, it is easier to get new people to learn about them.

What steps have banks to go on the move to ESA?

Skeels: Banks have to devise a roadmap for step by step migration. Banks have a complex IT landscape. And a bank really can’t throw away its legacy. Also many so-called legacy systems continue to do a very good job. Often they do not need to be very agile as they execute a large amount stable day-to-day operations. So, the bank has to identify which pieces of their systems they do need to make more agile and when.. And always step by step. To do this successfully, the bank needs to do three things: One is to have a consistent vision for the target that every project is driving to, so every change is toward the vision. The second is to ensure that co-existence with legacy is always fully accommodated. The third is to make sure that each step has a business return not just an intangible future return. As every bank has a different start point, every bank’s direction and steps will be slightly different but these three criteria are always valid, vision, step by step value, and co-existence.

In what sense is SAP supporting the process?

Skeels: We are very much supporting the creation of the roadmap and the actual migration. We work with customers to identify the best roadmap with our ESA Adoption Program. We also ensure that value comes from every step on the roadmap with our Value Engineering. We are delivering the underpinning infrastructure, the Banking Process Platform, in 2006. This is an evolution of our existing Netweaver technology. Add this to the existing capabilities of SAP NetWeaver and you can see we provide an extensive set of options for migration and co-existence, for introducing new solutions and for enhancing existing solutions as they are all moved toward the ESA vision. And, of course, ESA helps with the migration and co-existence of this new environment with the existing bank systems.

What are the experiences of SAP’s banking customers moving forward to ESA?

Skeels: Well, the news is very positive. Several of our customers are already having success as they move forward toward ESA, even though they are taking different steps. For example Postbank uses most of SAP’s banking portfolio. Recently, they have changed their internal development to exploit ESA. So, going forward, Postbank can do even faster changes to the composite application solutions. A second example is Standard Bank of South Africa. They are moving into the new architecture in small business function led steps. As I mentioned before, there are different routes forward, each route depending on where the bank is starting from and how fast they need to achieve their vision.

How will it be possible for SAP to generate incremental value during the transition?

Skeels: It is always best on a long journey – and this is a long journey – to take small steps, especially at the beginning. In order to gain credibility you always have to look for significant value on the early steps. The early steps have the most pressure on them to prove that the journey is worthwhile. So we at SAP are working very hard with our value engineering to ensure that banks can get the right business benefits out of what they are trying to achieve. To prove value it is always important to look at total cost of ownership (TCO). But you may actually improve value by cost avoidance. For example, when complying with regulations banks can avoid direct costs such from fines and loss of reputation. Similarly, when dealing with operational risk, banks could again avoid costs from loss of business and loss of reputation. So we try to bring that broader thinking to the business cases and therefore help justify each transformation step.

“Industrialized” banking services are often proposed. How does Enterprise Services Architecture support this kind of industrialization?

Skeels: Many, if not all, banks would like to improve standardization and productivity through adopting best practice. ESA supports this industrialization through open standards together with best practices in both business function and process. However this is not at the expense of flexibility. A bank can easily integrate with a third party. So, if necessary, the Bank can outsource non-critical or commodity tasks. Or the bank may offer an insourcing service. So ESA supports industrialization at all levels.

Tags: ,

Leave a Reply