Since 1999, Deutsche Bank has completely restructured its worldwide IT and operations activities in order to reduce costs dramatically, while at the same time making IT and operations more responsive to the needs of the bank’s business divisions. The steps taken to transform IT and operations included a wide range of efficiency improvements as well as the realignment of the IT organization and its governance model, and the outsourcing of a broad range of IT activities and business processes.
In 1999 the organizational structure and responsibilities of the existing IT and operations group, Global Technology & Services (GTS) were not sharply delineated. It was organized as part profit center and part cost center. On top of that, GTS was the required service provider in the bank, though the affected business divisions lacked control over the budget. Once a year, when the annual budget was to be agreed on, IT would propose a top down budget, instead of business divisions deciding on an investment focus that would support their particular strategies. Together with other cost-allocation problems, this led to a total misperception on the part of business divisions about their costs.
In the face of this, the bank made two fundamental decisions. The first was to establish the Global Transaction Bank, an organizationally distinct, profit-oriented business that would run a major part of the bank’s operations. Second, and building on this, the bank decided to dismantle the old GTS completely, to assign the pieces to the business divisions, and to establish a model of business-aligned IT and operations.
Deutsche Bank had to pry apart the existing structures and assemble new ones. It created, first, an applications-development organization, now aligned with the individual business divisions; second, a clearly dedicated infrastructure unit; and, third, named DB Services, which focuses on purchasing, credit card and point-of-sale services, payments and securities-settlement operations, and facilities management—altogether a unit of some 3,500 employees.
The next step was to build a governance structure that would in effect split the budget into two separate components with different characteristics:
• Run-the-Bank (RTB), and
• Change-the-Bank (CTB)
The Run-the-Bank budget is focused on maintaining existing operations, and the Change-the Bank budget is focused on new IT investments. The bank understood, very early on, that it had to address these two blocks of costs differently. The idea was to increase the degree of freedom for starting up new IT projects but not to continually increase the total budget. For RTB, the goal was to reduce costs by 5 percent per year. In the end, the bank not only reduced its nominal budget by 5 percent but also managed to cope with a substantial increase in transaction volumes.
With CTB, on the other hand, DB wanted to increase the budget to 25 to 30 percent of total spending. So productivity gains in RTB served as a funding source for additional CTB activities while at the same time allowing a nominal reduction of total spending. Getting to this point required two major changes. The first was restructuring the entire CTB budget into business-aligned budgets, enabling each business division to make its own investment decisions. This was sometimes difficult, of course, because IT would also have an opinion about a particular project or its implementation.
So, second, to take this into account, DB established the IT Investment Committee as a governance process for all new projects. Sitting on this committee are the business project leader and representatives of IT and of the COO area for overall cost control. Within this structure, business divisions decide on an investment, while IT serves as an informed receiver of their orders — In contrast to the original situation, where IT was often its own order giver. The basic prerequisite was complete cost transparency.
From the head count level down, you can see in DB today exactly who and what is being charged to whom. Before, the allocation process between IT, Operations, and other corporate-center functions, and the businesses was multidirectional and worked more like a no-win game: as soon as someone changed a budget, this changed the allocations to other entities. Then everybody adapted their budgets too in reaction. At the end, it was back to square one. To get rid of the smoke screen, DB introduced a cascading model, where all businesses and functions may only allocate downward, in a clearly defined waterfall fashion. These structural changes were, of course, very important for the improved professionalism of the IT and Operations function over the long term. But they surely wouldn’t have been as successful as they were if the changes hadn’t also delivered a visible cost reduction.
Between 2001 and 2003, DB reduced costs by some €1 billion. DB’s costs in 2001 were around €4 billion, and by December 2003 they were less than €3 billion. This was considerably more than DB expected to achieve. Most of the cost reductions were realized on the Run-the-Bank side. With Change-the-Bank, as planned, investments rose and now account for about 30 percent of the total. It was a combination of many levers.
Decisive in the process was starting out with a concise master plan and a clear implementation program. One key lever was an extensive spin-off of non-core functions. For example, former subsidiary e-Magine, which was bundled into an external service provider, GFT Technologies. The bank thus contracts with GFT for the management and brokerage of freelance applications development resources.
Another lever was systematically thinning out the Run-the-Bank side. Here, too, forms of outsourcing played a major role. DB focused its approach on the bank’s existing support organization. Many functions had already been bundled under the umbrella of DB Services into separate support units like DBOI. They were already quasi-outsourced to an internal service provider. This had always been a good indicator that DB could take the next step and outsource to a truly external service provider. An example is DB Payments, the operational unit for retail payments processing, which was sold to Deutsche Post. DB approached the task of outsourcing on three levels:
• Infrastructure,
• Business processes, and
• Commodity banking processes.
On the first level, basic infrastructure services activities like the data center, machine operations, and software stacks. DB’s outsourcing partner, IBM, has the task of maximizing availability time within specified cost constraints and of providing computing power in a sophisticated utility pricing model. An important argument for outsourcing the data center was the need to replace the physical infrastructure in the medium term and to revamp the Business Continuity Management (BCM) concepts in light of the 9 /11 experiences. DB also integrated all the Continental European data center operations — Belgium, Germany, Italy, Luxembourg, Poland, Portugal, Spain, and Switzerland — where in the past the bank had maintained a separate infrastructure. With outsourcing, DB had the opportunity to establish a transformational change not only on the technology and operations side but also by getting access to a much wider and deeper skill base.
The next layer was business processes where DB managed to place several complete applications areas, such as the maintenance of global PeopleSoft HR system, at outside companies. When outsourcing processes like these, companies should also outsource the applications systems that belong to them. Cost reduction was a major factor. DB did not pursue outsourcing unless there were significant cost savings to be realized. Typically, the hurdle rate was 20 percent and up. On the other hand, there must also always be qualitative improvements to be gained. This was where DB dealt with commodity-like banking processes—those that don’t provide either a competitive advantage or sufficient profit margins—retail security settlement and payments processing, for example.
The selection of processes for outsourcing will remain robust over time; it is unlikely that DB will consider reversing course. In fact, many other market participants will be doing the same, producing some rather interesting consolidation opportunities for back-office operations, called as the Industrialization of Banking.
For functions over which DB no longer has direct control, there are two possibilities:
• Competition and transparency, or
• “open book”
Competition means open bidding, so one can achieve a true market price. When it comes to infrastructure, DB was able to contract for equipment from any vendor, irrespective of IBM outsourcing. DB maintains a portfolio of several active providers for each area.
Open Book means complete transparency about costs, productivity, and performance indicators for each process. With offshoring, DB is facing a redistribution of white-collar labor, and IT applications development has certainly been one of the first areas affected. Given the fact that DB is a global bank that has vast experience with software development in India, for example, it is already sharing projects with offshore specialists.
On transaction data customer records, the main issue is the attitude of the regulatory authorities. Until told otherwise, the bank assumes that it cannot offshore this data. This is not due to concern about possible technical problems but rather about the ability, in an offshore environment, to ensure access, irrespective of any potential divergence of legal environments and political stability. If data from German banks on German customers were to be managed in China, there could be potential regulatory issues. This issue is also relevant when it comes to the expanded European Union, since regulation in Europe continues to be the domain of each member country.
For the future, DB has three key elements:
• The transition to a value contribution model,
• The separation of distribution and production, and
• A focus on customers.
With the value contribution model, the idea is to measure IT and Operations investments in terms of their true contribution to business value. DB has developed some preliminary approaches that enable how much business divisions are investing and with what effect on Return on Equity (ROE), at a product group level. The information has already produced some extremely interesting insights.
Further, the bank will continue to make the separation between distribution and production even sharper. This effort began with the separation of the bank’s private-client distribution entities from product factories such as mutual-fund management.
Finally, DB is pushing for customer orientation. This impulse will not come from new employees or from the 125th training course on cross-selling. It can only come from the technological capability to create new marketing formats, draw in new customers, or more fully serve existing ones. This will be the next “e-volution.” With its transformation efforts of the past few years, DB has built a foundation of transparency and performance orientation at the bank.
In 1999 the organizational structure and responsibilities of the existing IT and operations group, Global Technology & Services (GTS) were not sharply delineated. It was organized as part profit center and part cost center. On top of that, GTS was the required service provider in the bank, though the affected business divisions lacked control over the budget. Once a year, when the annual budget was to be agreed on, IT would propose a top down budget, instead of business divisions deciding on an investment focus that would support their particular strategies. Together with other cost-allocation problems, this led to a total misperception on the part of business divisions about their costs.
In the face of this, the bank made two fundamental decisions. The first was to establish the Global Transaction Bank, an organizationally distinct, profit-oriented business that would run a major part of the bank’s operations. Second, and building on this, the bank decided to dismantle the old GTS completely, to assign the pieces to the business divisions, and to establish a model of business-aligned IT and operations.
Deutsche Bank had to pry apart the existing structures and assemble new ones. It created, first, an applications-development organization, now aligned with the individual business divisions; second, a clearly dedicated infrastructure unit; and, third, named DB Services, which focuses on purchasing, credit card and point-of-sale services, payments and securities-settlement operations, and facilities management—altogether a unit of some 3,500 employees.
The next step was to build a governance structure that would in effect split the budget into two separate components with different characteristics:
• Run-the-Bank (RTB), and
• Change-the-Bank (CTB)
The Run-the-Bank budget is focused on maintaining existing operations, and the Change-the Bank budget is focused on new IT investments. The bank understood, very early on, that it had to address these two blocks of costs differently. The idea was to increase the degree of freedom for starting up new IT projects but not to continually increase the total budget. For RTB, the goal was to reduce costs by 5 percent per year. In the end, the bank not only reduced its nominal budget by 5 percent but also managed to cope with a substantial increase in transaction volumes.
With CTB, on the other hand, DB wanted to increase the budget to 25 to 30 percent of total spending. So productivity gains in RTB served as a funding source for additional CTB activities while at the same time allowing a nominal reduction of total spending. Getting to this point required two major changes. The first was restructuring the entire CTB budget into business-aligned budgets, enabling each business division to make its own investment decisions. This was sometimes difficult, of course, because IT would also have an opinion about a particular project or its implementation.
So, second, to take this into account, DB established the IT Investment Committee as a governance process for all new projects. Sitting on this committee are the business project leader and representatives of IT and of the COO area for overall cost control. Within this structure, business divisions decide on an investment, while IT serves as an informed receiver of their orders — In contrast to the original situation, where IT was often its own order giver. The basic prerequisite was complete cost transparency.
From the head count level down, you can see in DB today exactly who and what is being charged to whom. Before, the allocation process between IT, Operations, and other corporate-center functions, and the businesses was multidirectional and worked more like a no-win game: as soon as someone changed a budget, this changed the allocations to other entities. Then everybody adapted their budgets too in reaction. At the end, it was back to square one. To get rid of the smoke screen, DB introduced a cascading model, where all businesses and functions may only allocate downward, in a clearly defined waterfall fashion. These structural changes were, of course, very important for the improved professionalism of the IT and Operations function over the long term. But they surely wouldn’t have been as successful as they were if the changes hadn’t also delivered a visible cost reduction.
Between 2001 and 2003, DB reduced costs by some €1 billion. DB’s costs in 2001 were around €4 billion, and by December 2003 they were less than €3 billion. This was considerably more than DB expected to achieve. Most of the cost reductions were realized on the Run-the-Bank side. With Change-the-Bank, as planned, investments rose and now account for about 30 percent of the total. It was a combination of many levers.
Decisive in the process was starting out with a concise master plan and a clear implementation program. One key lever was an extensive spin-off of non-core functions. For example, former subsidiary e-Magine, which was bundled into an external service provider, GFT Technologies. The bank thus contracts with GFT for the management and brokerage of freelance applications development resources.
Another lever was systematically thinning out the Run-the-Bank side. Here, too, forms of outsourcing played a major role. DB focused its approach on the bank’s existing support organization. Many functions had already been bundled under the umbrella of DB Services into separate support units like DBOI. They were already quasi-outsourced to an internal service provider. This had always been a good indicator that DB could take the next step and outsource to a truly external service provider. An example is DB Payments, the operational unit for retail payments processing, which was sold to Deutsche Post. DB approached the task of outsourcing on three levels:
• Infrastructure,
• Business processes, and
• Commodity banking processes.
On the first level, basic infrastructure services activities like the data center, machine operations, and software stacks. DB’s outsourcing partner, IBM, has the task of maximizing availability time within specified cost constraints and of providing computing power in a sophisticated utility pricing model. An important argument for outsourcing the data center was the need to replace the physical infrastructure in the medium term and to revamp the Business Continuity Management (BCM) concepts in light of the 9 /11 experiences. DB also integrated all the Continental European data center operations — Belgium, Germany, Italy, Luxembourg, Poland, Portugal, Spain, and Switzerland — where in the past the bank had maintained a separate infrastructure. With outsourcing, DB had the opportunity to establish a transformational change not only on the technology and operations side but also by getting access to a much wider and deeper skill base.
The next layer was business processes where DB managed to place several complete applications areas, such as the maintenance of global PeopleSoft HR system, at outside companies. When outsourcing processes like these, companies should also outsource the applications systems that belong to them. Cost reduction was a major factor. DB did not pursue outsourcing unless there were significant cost savings to be realized. Typically, the hurdle rate was 20 percent and up. On the other hand, there must also always be qualitative improvements to be gained. This was where DB dealt with commodity-like banking processes—those that don’t provide either a competitive advantage or sufficient profit margins—retail security settlement and payments processing, for example.
The selection of processes for outsourcing will remain robust over time; it is unlikely that DB will consider reversing course. In fact, many other market participants will be doing the same, producing some rather interesting consolidation opportunities for back-office operations, called as the Industrialization of Banking.
For functions over which DB no longer has direct control, there are two possibilities:
• Competition and transparency, or
• “open book”
Competition means open bidding, so one can achieve a true market price. When it comes to infrastructure, DB was able to contract for equipment from any vendor, irrespective of IBM outsourcing. DB maintains a portfolio of several active providers for each area.
Open Book means complete transparency about costs, productivity, and performance indicators for each process. With offshoring, DB is facing a redistribution of white-collar labor, and IT applications development has certainly been one of the first areas affected. Given the fact that DB is a global bank that has vast experience with software development in India, for example, it is already sharing projects with offshore specialists.
On transaction data customer records, the main issue is the attitude of the regulatory authorities. Until told otherwise, the bank assumes that it cannot offshore this data. This is not due to concern about possible technical problems but rather about the ability, in an offshore environment, to ensure access, irrespective of any potential divergence of legal environments and political stability. If data from German banks on German customers were to be managed in China, there could be potential regulatory issues. This issue is also relevant when it comes to the expanded European Union, since regulation in Europe continues to be the domain of each member country.
For the future, DB has three key elements:
• The transition to a value contribution model,
• The separation of distribution and production, and
• A focus on customers.
With the value contribution model, the idea is to measure IT and Operations investments in terms of their true contribution to business value. DB has developed some preliminary approaches that enable how much business divisions are investing and with what effect on Return on Equity (ROE), at a product group level. The information has already produced some extremely interesting insights.
Further, the bank will continue to make the separation between distribution and production even sharper. This effort began with the separation of the bank’s private-client distribution entities from product factories such as mutual-fund management.
Finally, DB is pushing for customer orientation. This impulse will not come from new employees or from the 125th training course on cross-selling. It can only come from the technological capability to create new marketing formats, draw in new customers, or more fully serve existing ones. This will be the next “e-volution.” With its transformation efforts of the past few years, DB has built a foundation of transparency and performance orientation at the bank.
3 comments:
Ravi,
Do you have any insights into the processes around DB's value contribution model.
I assume they're extending the methodologies they've been using where the effects of events are projected through projects to aid in decision making?
Any insights on methodologies would be helpful.
Your post was very helpful for me. Thanks for sharing this post. Keep further posting.Origination Services and Banking Outsourcing
<a href="https://www.suntecgroup.com/banking-as-a-service/>open banking architecture</a>
Therefore, services today, including banks need to make a choice; solving functional needs by utilizing vertical expertise, or transforming to adopt a more platform-based approach which makes them customer owners, able to solve broader lifecycle needs.
Post a Comment