Conceptual Commercial Bank: A case study on Internet product delivery process improvement
Executive Summary:
Conceptual Commercial Bank (CCB) is a fictitious large commercial bank based upon information gathered from several large corporate banks. Given the confidentiality and proprietary nature of such information none of the financial information or the process flows discussed in this case study directly correlates to any one specific bank, rather it is an amalgam of public and private information from all the banks.
CCB’s eBusiness Unit is facing challenges on how to quickly deliver new Internet based commercial bank products to its current customer set as well as expanding its customer base. Customers do not feel they are getting as much Internet product as they would like, and the business units feel that the deployment process takes too long and is too expensive.
The purpose of this case study is to analyze the current Internet product delivery process being implemented at CCB and how things could be improved to provide more Internet product for customers quickly while generating more revenues for CCB.
History:
CCB’s eBusiness Unit is responsible for developing and implementing CCB’s Internet financial services products and e-commerce solutions. This group works with the individual lines of business (LOBs) to develop and deliver Internet based solutions to meet the LOBs’ needs.
Due to the immaturity of the Internet space, there are high costs involved with deploying Internet solutions to customers. There are high costs for Internet technologies that are needed to deliver Internet solutions and the high cost of skilled resources has increased operating expenses significantly year over year.
Revenues from Internet products are increasing, although not as quickly as operating expenses. This is due to the slow adoption rate of current customers to new Internet products. It requires them to implement changes within their current business process, which takes time. Overall, customer feedback has been positive regarding their desire for Internet products, but how many products and what kinds are not clear.
Reported losses before restructuring-related items of $179 million in 2004, compared to $141 million in 2003 and $78 million in 2002. Net losses of $143 million in 2003 and $94 million in 2002 included restructuring-related items of $2 million ($3 million pretax) and $16 million ($28 million pretax), respectively. See Table 1.
Strategic Objective
The strategic objective of the eBusiness unit is to Internet enable as many products as possible to form a competitive advantage in selling commercial banking products.
Each line of business (LOB) is responsible for working with their customers to solicit new trends and needs within the market. Given that many of the products currently available to their customers are non-Internet based, the LOBs’ need to think through the consequences of cannibalizing current revenue streams in exchange for new Internet based product solutions.
Internet Product Delivery Processes
The challenge is that the uptake on new Internet product varies greatly based upon customer type. Large corporate customers tend to need specific products for specific needs. They have large treasury departments that have specific individuals to handle specific transactions: Foreign Exchange, Cash Management, etc. In middle-market and smaller organizations these functions tend to roll up under a small group of people. They prefer to have suites of products available to them to manage their complete relationship with the bank.
In order to address both needs, CCB formed the CCB Internet portal to serve their customers. This way both large corporate and middle-market customers can see their applications all in one location. This provides a consistent user interface for their end customers, and a consistent security and deployment mechanism for rolling out applications.
The end customer interacts with the portal in the following way:
1. They access CCB’s Internet portal;
2. Depending on what application they are accessing they are validated using different security measures;
3. The user is asked to authenticate depending on the security mechanism required;
4. The portal builds the customers information from LDAP (an internal database) and displays the look and feel depending on the type of customer;
5. The user interacts with the portal to get access to the applications it needs off of the shared application servers.
New Customer Idea
During this phase, customers may provide feedback on products and services that they would like to utilize from the bank. This input is generally routed to LOB’s customer sales representatives. New idea generation rate averages 5 recommendations per month.
Business Group Review
Capacity: 20 projects; depending on size and complexity
Given that there are multiple business areas, each area looks at new product development within their own budget constraints and determines what products would give them the greatest competitive advantage or what do they need to do in order to retain key customers.
Many projects are not implemented right away due to the fact that it may not be possible to begin work in the current budget cycle. Other projects are already funded and to start new work would mean sacrificing of other projects already underway. These projects are sometimes brought back into the queue in the next budget planning process.
Proof of Concept
Capacity: 5 projects; depending on size and complexity
If the business feels that there is enough potential in moving forward, it engages the system IT areas to start to build out a proof of concept. This proof of concept can be done internally or sometimes in conjunction with external vendors.
This is often done very quickly to test out the idea before the senior management review meeting. It also allows the IT and business teams to better size the amount of time and effort required to deliver this product.
Things get rejected at this point when IT identifies a showstopper from a systems end that will impede the ability for the product to get to market.
Senior Management Review
Capacity: 5 projects
Senior management meets and reviews new proposed business cases for additional projects. This process typically happens during budget planning cycles, but can occur off-cycle if there is enough business justification.
Most projects get rejected at this point due to the following reasons:
1. Not enough data to determine if the projects will generate real return;
2. Competing internal and system needs that cannot afford to free up resources;
3. Other business cases are more compelling and require the same resources.
Gather Detailed Requirements
Capacity: 2 projects
Given the size and complexity of the projects, the number of resources required to implement this phase can greatly vary. Compounding this challenge is that there is an internal strategy group that works as a liaison between the Systems and Business areas. This strategy group tries to marshal the requirements back and forth between the areas which slows the process down. Elimination or reduction of the utilization of this group would greatly enhance the ability for the system’s areas to handle more projects.
Build Internet Product
Capacity: 10 projects; dependent on complexity
This is where the development process begins to build to the business requirements. This takes a lot of coordination amongst resources and across groups. The more complicated the project the more complicated the communication flows. This can lead to miscommunications, turf battles, and stalling of the project. If the cost and time overruns are too extreme, management may choose to stop the project.
QA/Product Release
Capacity: 4 projects; dependent on complexity
CCB is moving to an automated form of QA testing, but currently relies extensively on resources from both the business and IT areas to help do the final QA testing.
During this time a select group of customers are invited to test the product and provide feedback… Too much negative feedback or instability in the application can cause the project to be stopped.
Deliver product to Customers
At this point the product becomes generally available to customers, and it is a factor of the salespeople to sell their customers on it.
If the process has worked successfully the products that are coming out will meet the consumers needs. However with the long lag times, and the rapidly changing Internet landscape those products may not be what the customers want today, which causes the process to be kicked off yet again.
Process Improvement
In order to determine the optimum process improvements, the overall process was entered into the Process Model software, and statistics were collected for the operation.
Table 2 shows the baseline statistics for the process. The inputs to the system are assumed to be 5 new ideas per month fed into the system over a 4 year time period.
Improve Quality
From looking at Figure 2 we see that some projects get stopped in the build or QA phase of the project. The primary reasons are that the projects selected had high variability in customer acceptance, or tended to be trendy in what the market wanted for the short-term, but by the time the product would be delivered it was no longer required by the customers.
By implementing more stringent criteria early in the project selection process, it will help increase the quality of the product ideas and reduce the rejection rate of the project once the project has begun. This is very important do to the fact that any rejection after the bottleneck “Gather detailed requirements” is very expensive.
Table 3, shows the improvements in the quality process. The rejection rate for the “Build internet product” and the “QA pilot release” activities were decreased to 0%. This leads to 4 more products being released - an additional project per year.
Improve Capacity
From Table 2 we observe that the biggest buildup is before the “Gather detailed requirements” activity. The “Gather detailed requirements” activity actually encompasses many sub-activities and three resources. In order to improve the process we need to be able to increase the capacity of the bottleneck. The reason that there is such a small capacity is that in order to solicit requirements, the system group needs to work through the strategy group to communicate with the business. This only leads to indirect and inefficient communications between the business and the systems groups.
By cutting out the strategy group and redeploying those resources into the systems groups, the business can directly work with the system areas, which will increase the communication flows and increase the capacity of handling more projects.
The capacity of the bottleneck was increased from 2 to 6 projects per month. Table 4 shows the improvements. The number of finished Internet products dramatically increased by 200%, releasing 18 projects over a 4-year period. Time to market decreased from 24 months to 15.6 months. Also note that the % utilization of the last two activities increased, because the bottleneck is now releasing more projects each month.
Improve Flow time
Areas in which we could improve flow times are in the “Gather detailed requirements” and “Build Internet product” activities. These two activities take 72% of the 14.5 months of theoretical flow time. But breaking the overall project into smaller phases (one could visualize this as breaking down the batch sizes) we would be able to increase the flow time through both the requirements and the building phase.
Requirements would be less per phase, which would take shorter time to gather and ultimately would speed up the building process.
Table 5 shows the improvements when the flow times are reduced to 3 months for the “Gather detailed requirements” and “Build Internet product” activities. The number of Internet products dramatically increased by over 200%, releasing 22 projects over a 4-year period. In addition the time to market decreased from 24 months to 14 and the theoretical flow time is now 10 months.
Total Improvement (All three improvements implemented)
By improving quality control, decreasing the theoretical flow time and increasing the capacity at bottlenecks, CCB will be able to increase product releases to 30 products over 4 years, or about 7.5 products per year. (Table 6) Just as important, average cycle time is as close to average value-add time as possible. This greatly streamlines the operation and keeps products from being obsolete by the time they reach the market.
Table 7 compares and contrasts the impact of the changes individually as well as implementing all of them together.
Conclusion
The biggest challenge in implementing some of these improvements is that it requires major organizational changes to be effective. While some things such as better quality controls can be implemented without any pushback, removal of the strategy group and closer linkages with the business and system areas will disrupt the political status quo. In order to make changes along these lines support of senior management will be necessary.
But by implementing these improvements CCB will greatly increase its speed in which it delivers new Internet product to market. Infrastructure components (fixed costs) represent 80% of operating expense where project development (variable costs) represents only 20%. By speeding up the process of delivering Internet product CCB will be able to reduce operating expenses and improves the bottom line contribution of the eBusiness unit on a per product basis. This will greatly increase CCB’s competitive advantage in this market by being able to respond to their customer needs quickly, which will allow them to generate revenues to better fund other Internet product ideas.
Conceptual Commercial Bank (CCB) is a fictitious large commercial bank based upon information gathered from several large corporate banks. Given the confidentiality and proprietary nature of such information none of the financial information or the process flows discussed in this case study directly correlates to any one specific bank, rather it is an amalgam of public and private information from all the banks.
CCB’s eBusiness Unit is facing challenges on how to quickly deliver new Internet based commercial bank products to its current customer set as well as expanding its customer base. Customers do not feel they are getting as much Internet product as they would like, and the business units feel that the deployment process takes too long and is too expensive.
The purpose of this case study is to analyze the current Internet product delivery process being implemented at CCB and how things could be improved to provide more Internet product for customers quickly while generating more revenues for CCB.
History:
CCB’s eBusiness Unit is responsible for developing and implementing CCB’s Internet financial services products and e-commerce solutions. This group works with the individual lines of business (LOBs) to develop and deliver Internet based solutions to meet the LOBs’ needs.
Due to the immaturity of the Internet space, there are high costs involved with deploying Internet solutions to customers. There are high costs for Internet technologies that are needed to deliver Internet solutions and the high cost of skilled resources has increased operating expenses significantly year over year.
Revenues from Internet products are increasing, although not as quickly as operating expenses. This is due to the slow adoption rate of current customers to new Internet products. It requires them to implement changes within their current business process, which takes time. Overall, customer feedback has been positive regarding their desire for Internet products, but how many products and what kinds are not clear.
Reported losses before restructuring-related items of $179 million in 2004, compared to $141 million in 2003 and $78 million in 2002. Net losses of $143 million in 2003 and $94 million in 2002 included restructuring-related items of $2 million ($3 million pretax) and $16 million ($28 million pretax), respectively. See Table 1.
Strategic Objective
The strategic objective of the eBusiness unit is to Internet enable as many products as possible to form a competitive advantage in selling commercial banking products.
Each line of business (LOB) is responsible for working with their customers to solicit new trends and needs within the market. Given that many of the products currently available to their customers are non-Internet based, the LOBs’ need to think through the consequences of cannibalizing current revenue streams in exchange for new Internet based product solutions.
Internet Product Delivery Processes
The challenge is that the uptake on new Internet product varies greatly based upon customer type. Large corporate customers tend to need specific products for specific needs. They have large treasury departments that have specific individuals to handle specific transactions: Foreign Exchange, Cash Management, etc. In middle-market and smaller organizations these functions tend to roll up under a small group of people. They prefer to have suites of products available to them to manage their complete relationship with the bank.
In order to address both needs, CCB formed the CCB Internet portal to serve their customers. This way both large corporate and middle-market customers can see their applications all in one location. This provides a consistent user interface for their end customers, and a consistent security and deployment mechanism for rolling out applications.
The end customer interacts with the portal in the following way:
1. They access CCB’s Internet portal;
2. Depending on what application they are accessing they are validated using different security measures;
3. The user is asked to authenticate depending on the security mechanism required;
4. The portal builds the customers information from LDAP (an internal database) and displays the look and feel depending on the type of customer;
5. The user interacts with the portal to get access to the applications it needs off of the shared application servers.
New Customer Idea
During this phase, customers may provide feedback on products and services that they would like to utilize from the bank. This input is generally routed to LOB’s customer sales representatives. New idea generation rate averages 5 recommendations per month.
Business Group Review
Capacity: 20 projects; depending on size and complexity
Given that there are multiple business areas, each area looks at new product development within their own budget constraints and determines what products would give them the greatest competitive advantage or what do they need to do in order to retain key customers.
Many projects are not implemented right away due to the fact that it may not be possible to begin work in the current budget cycle. Other projects are already funded and to start new work would mean sacrificing of other projects already underway. These projects are sometimes brought back into the queue in the next budget planning process.
Proof of Concept
Capacity: 5 projects; depending on size and complexity
If the business feels that there is enough potential in moving forward, it engages the system IT areas to start to build out a proof of concept. This proof of concept can be done internally or sometimes in conjunction with external vendors.
This is often done very quickly to test out the idea before the senior management review meeting. It also allows the IT and business teams to better size the amount of time and effort required to deliver this product.
Things get rejected at this point when IT identifies a showstopper from a systems end that will impede the ability for the product to get to market.
Senior Management Review
Capacity: 5 projects
Senior management meets and reviews new proposed business cases for additional projects. This process typically happens during budget planning cycles, but can occur off-cycle if there is enough business justification.
Most projects get rejected at this point due to the following reasons:
1. Not enough data to determine if the projects will generate real return;
2. Competing internal and system needs that cannot afford to free up resources;
3. Other business cases are more compelling and require the same resources.
Gather Detailed Requirements
Capacity: 2 projects
Given the size and complexity of the projects, the number of resources required to implement this phase can greatly vary. Compounding this challenge is that there is an internal strategy group that works as a liaison between the Systems and Business areas. This strategy group tries to marshal the requirements back and forth between the areas which slows the process down. Elimination or reduction of the utilization of this group would greatly enhance the ability for the system’s areas to handle more projects.
Build Internet Product
Capacity: 10 projects; dependent on complexity
This is where the development process begins to build to the business requirements. This takes a lot of coordination amongst resources and across groups. The more complicated the project the more complicated the communication flows. This can lead to miscommunications, turf battles, and stalling of the project. If the cost and time overruns are too extreme, management may choose to stop the project.
QA/Product Release
Capacity: 4 projects; dependent on complexity
CCB is moving to an automated form of QA testing, but currently relies extensively on resources from both the business and IT areas to help do the final QA testing.
During this time a select group of customers are invited to test the product and provide feedback… Too much negative feedback or instability in the application can cause the project to be stopped.
Deliver product to Customers
At this point the product becomes generally available to customers, and it is a factor of the salespeople to sell their customers on it.
If the process has worked successfully the products that are coming out will meet the consumers needs. However with the long lag times, and the rapidly changing Internet landscape those products may not be what the customers want today, which causes the process to be kicked off yet again.
Process Improvement
In order to determine the optimum process improvements, the overall process was entered into the Process Model software, and statistics were collected for the operation.
Table 2 shows the baseline statistics for the process. The inputs to the system are assumed to be 5 new ideas per month fed into the system over a 4 year time period.
Improve Quality
From looking at Figure 2 we see that some projects get stopped in the build or QA phase of the project. The primary reasons are that the projects selected had high variability in customer acceptance, or tended to be trendy in what the market wanted for the short-term, but by the time the product would be delivered it was no longer required by the customers.
By implementing more stringent criteria early in the project selection process, it will help increase the quality of the product ideas and reduce the rejection rate of the project once the project has begun. This is very important do to the fact that any rejection after the bottleneck “Gather detailed requirements” is very expensive.
Table 3, shows the improvements in the quality process. The rejection rate for the “Build internet product” and the “QA pilot release” activities were decreased to 0%. This leads to 4 more products being released - an additional project per year.
Improve Capacity
From Table 2 we observe that the biggest buildup is before the “Gather detailed requirements” activity. The “Gather detailed requirements” activity actually encompasses many sub-activities and three resources. In order to improve the process we need to be able to increase the capacity of the bottleneck. The reason that there is such a small capacity is that in order to solicit requirements, the system group needs to work through the strategy group to communicate with the business. This only leads to indirect and inefficient communications between the business and the systems groups.
By cutting out the strategy group and redeploying those resources into the systems groups, the business can directly work with the system areas, which will increase the communication flows and increase the capacity of handling more projects.
The capacity of the bottleneck was increased from 2 to 6 projects per month. Table 4 shows the improvements. The number of finished Internet products dramatically increased by 200%, releasing 18 projects over a 4-year period. Time to market decreased from 24 months to 15.6 months. Also note that the % utilization of the last two activities increased, because the bottleneck is now releasing more projects each month.
Improve Flow time
Areas in which we could improve flow times are in the “Gather detailed requirements” and “Build Internet product” activities. These two activities take 72% of the 14.5 months of theoretical flow time. But breaking the overall project into smaller phases (one could visualize this as breaking down the batch sizes) we would be able to increase the flow time through both the requirements and the building phase.
Requirements would be less per phase, which would take shorter time to gather and ultimately would speed up the building process.
Table 5 shows the improvements when the flow times are reduced to 3 months for the “Gather detailed requirements” and “Build Internet product” activities. The number of Internet products dramatically increased by over 200%, releasing 22 projects over a 4-year period. In addition the time to market decreased from 24 months to 14 and the theoretical flow time is now 10 months.
Total Improvement (All three improvements implemented)
By improving quality control, decreasing the theoretical flow time and increasing the capacity at bottlenecks, CCB will be able to increase product releases to 30 products over 4 years, or about 7.5 products per year. (Table 6) Just as important, average cycle time is as close to average value-add time as possible. This greatly streamlines the operation and keeps products from being obsolete by the time they reach the market.
Table 7 compares and contrasts the impact of the changes individually as well as implementing all of them together.
Conclusion
The biggest challenge in implementing some of these improvements is that it requires major organizational changes to be effective. While some things such as better quality controls can be implemented without any pushback, removal of the strategy group and closer linkages with the business and system areas will disrupt the political status quo. In order to make changes along these lines support of senior management will be necessary.
But by implementing these improvements CCB will greatly increase its speed in which it delivers new Internet product to market. Infrastructure components (fixed costs) represent 80% of operating expense where project development (variable costs) represents only 20%. By speeding up the process of delivering Internet product CCB will be able to reduce operating expenses and improves the bottom line contribution of the eBusiness unit on a per product basis. This will greatly increase CCB’s competitive advantage in this market by being able to respond to their customer needs quickly, which will allow them to generate revenues to better fund other Internet product ideas.
posted by Soren Burkhart at 11:30 PM
0 Comments:
Post a Comment
<< Home