The Vicious Cycle - Part 2 - The Cloud
Cloud and the opportunity to change
This is a bit of a shorter one, but I hope it will be useful.
On the previous blog we talked about the plus and minuses of the single vendor strategy. The management of different technologies and software within a banking organization can indeed require significant resources. Each new piece of software may require its own specialized expertise and teams for implementation, operation, troubleshooting, and upgrading. This need for a diverse skill set can increase the complexity of the IT department and the overall operation. Basically, having an additional piece of software - if that needs to be maintained in house - means a lot more people:
Software Maintenance: Each piece of software or technology might require dedicated personnel who understand the specific product. This usually leads to the need for more hires, contributing to increased operational costs.
Training Costs: New software often requires training existing staff to use and maintain it. This not only leads to direct training costs but also indirect costs due to the time employees spend away from their regular work for training.
Interoperability Issues: Different pieces of software may not be inherently designed to work together, leading to potential compatibility issues. They might need to have their own hardware and their own operational system. This can create additional workload for the IT team who need to ensure that it all works.
Version Control and Upgrades: Different software will likely have different upgrade cycles and methods, meaning the IT department needs to manage multiple timelines and processes for keeping software up to date.
Risk Management: Each new piece of software represents a potential point of vulnerability for cybersecurity threats. Managing these risks across different technologies can be challenging and requires continuous attention.
The diversity of software can also lead to what's called a "technology stack" problem, where the number of different, layered technologies becomes unwieldy and difficult to manage efficiently. All these factors contribute to the preference of many banks to streamline their operations with a single vendor, reducing the need for extensive specialization, facilitating integration, and simplifying vendor management.
If you add a new significant piece of software to the ecosystem of a bank, what is the impact in the bank staff? Let's assume a bank with 500 IT staff, and one with 50, and guess some numbers:
Implementation and Upgrades Team: You would likely need a dedicated team to handle the transition, upgrades and deployment of patches and fixes. This team could include project managers, business analysts, data migration specialists, and software engineers. For a smaller bank with a 50-person IT team, this might be an additional 5 people. For a larger bank with a 500-person IT team, this might be an additional 10 people.
Training Personnel: If the new system has significantly different features or interfaces compared to the legacy system, you might need personnel to train the end-users. The size of the training team would depend on the number of end-users and the complexity of the software. This might be an additional 1-2 people for the smaller bank, and 3-5 people for the larger bank.
Ongoing Support and Maintenance: After the transition, you'll need staff to handle ongoing maintenance, troubleshooting, and user support for the new system. For the smaller bank, this might mean an additional 2-4 people. For the larger bank, this might mean an additional 10 people.
Vendor Management: If the new system comes from a different vendor than the legacy system, you might need additional staff to manage the vendor relationship. This might be an additional 1-2 people for the smaller bank, and maybe the same for a larger bank.
Security and Compliance: You may also need additional resources to ensure the new system meets all necessary security and compliance standards. This might be an additional 1-2 people for the smaller bank, and 3-5 people for the larger bank.
The extent of the increase will depend on many factors, and in some cases, banks may be able to minimize the need for additional staff by choosing software that's compatible with their existing systems, taking advantage of vendor-provided training and support, or using cloud-based solutions that reduce the need for in-house maintenance and support. But if we use these numbers, the larger IT team will need to add about 30 people (6% increase) , and the small bank about 12 people (24% increase). It is important to note that to keep the system up and running, the large bank is using about 25 people, and the small bank, 10 people (implementation, upgrades, training and ongoing support and maintenance).
Given these numbers, it is not a surprise that banks had a strong preference for a single vendor. And that small banks did not have a chance to automate a lot of its processes as the cost increase would not justify the investment - keep doing it using Excel, even if that means greater operational risk.
As the internet evolved and virtual machines and storage became the backbone of what we call "the Cloud", Software-as-a-Service (SaaS) comes to life (Salesforce vs Siebel Systems an interesting use case). The equation changes significantly when it comes to staffing needs.
The primary advantages of SaaS include the fact that much of the heavy lifting associated with maintaining and upgrading the software is handled by the vendor, not the customer. This shifts the staffing needs from more technical roles to roles focused on configuration, user training, and managing the vendor relationship. Not to mention that virtual machines can be upgraded much easier than the hardware you have on your premises.
It is important to note the difference between SaaS and Managed Services as it comes down to what is being managed. With SaaS, the software itself is managed by the SaaS provider, allowing users to access and use the software without worrying about the technical details. With managed services, the banks subcontracts someone to manage the company's IT environment, potentially including servers, networks, and other systems, in addition to specific software applications.
One simple way to look at the difference is that SaaS you are mutualizing an specific functionality - example using Microsoft Word on your web browser. If we are talking about Managed Services you are asking someone to run all aspects of your Microsoft Word license, while this license is deployed somewhere. Asking someone to run your software for you, even if that is on the Cloud can be great but it is NOT SaaS.
While it's challenging to provide a specific figure without detailed knowledge of a specific implementation, industry trends and anecdotal evidence suggest that moving from an on-premises solution like Siebel to a SaaS platform like Salesforce could potentially reduce the staffing requirements by around 40%-60%. Here's a rough breakdown:
Implementation: SaaS solutions generally require fewer staff for the initial implementation as they are less hardware-intensive and often come with more out-of-the-box functionality that can be configured rather than custom-built. A significant part of the implementation is also typically handled by the vendor's professional services team or a third-party consulting firm.
Ongoing Maintenance: SaaS platforms handle most of the system maintenance and upgrades, significantly reducing the need for system administrators, database administrators, and other technical roles that are often needed for on-premises software.
Security and Compliance: While security and compliance are still crucial, many of the responsibilities lie with the SaaS provider, reducing the need for in-house staff in these areas.
Custom Development: SaaS platforms often require less custom development, as they typically offer extensive configuration options and a wide array of plugins and add-ons that can provide additional functionality.
However, some roles may see an increase or remain the same:
User Support and Training: Regardless of the platform, users still need training and support, and this role may not see a significant reduction.
Configuration and Customization: While less custom development is required, there's often more emphasis on configuration and customization of the platform to meet the organization's needs. Therefore, the roles that handle these tasks might increase.
Vendor Management: Managing the vendor relationship and coordinating upgrades and changes to the platform can become more complex in a SaaS model, which might increase the need for roles that handle these tasks.
So while it's difficult to provide a precise figure, it's reasonable to estimate that moving from an on-premises solution to a SaaS platform could potentially reduce the related staffing needs by a significant margin. It's crucial, however, to remember that this is a rough estimate and the actual figure could vary depending on the specifics of the organization and the implementation.
So the case can be made today that adding a new vendor in your ecosystem is a much more viable alternative today.
So let's move everything at the bank to software as a service? Probably not doable in one go. Detroit took decades to implement some of the changes needed to up their game. But now Ford and Toyota are not that far out in key indicators like quality, and in some cases, the Americans now are beating the Japanese.
Banks have started the journey though. Are they doing it with the speed they could? I don't think so. And some of the reasons might be clear once we go into what is the legacy of the single vendor policies. But as a teaser, one of the reasons banks tend to say they can not have apps or functionality delivered to them from Fintechs that operate on the cloud is that because the software is not on their premises, they do not have control. But at the same time some of the biggest complaints they have is that the code is usually a black box, vendors usually do not disclose APIs, documentation is not clear, the data schema is not clear, etc. Mind you, a lot of the FIntechs out there operate with an amazing level of transparency and openness. Are you really giving up control if you use them?
Of course, feel free to leave comments. When people agree with you is great, but when they don't it is even better, that is when you learn. A great guy once told me that interesting is when people disagree.