Mastering Digital Transformation in Banking: Challenges and Opportunities

Digital transformation is a complex yet crucial endeavor for organizations striving to stay competitive and innovative in today's rapidly evolving business landscape. What is the optimal strategy for tackling it, and what are the key considerations right from the outset?

I’ve had an opportunity to talk to Alex Babin, a long-time expert in software development, IT management and consulting. Throughout his career, Alex has participated in and headed a wide range of projects across various industries including fintech, gaming, biometrics, retail, and blockchain.

Recently, he’s been focusing on IT consulting and facilitating transformational processes in organizations. In this insightful discussion, we delve into the intricacies of digital transformation, particularly within the banking sector.

Alex, you've been advising clients on digital transformation for many years. Can you explain it in simple terms?

Digital transformation is about transitioning a business model from traditional to digital. For clarity, let's take the financial sector as an example. Typically, a bank before digital transformation doesn't rely heavily on digital means for value creation. For instance, while they may have apps for loan or card services, digital isn't at the core of their operations, rather it's peripheral. They usually operate on a classic distribution model through bank branches.

When we say we're transforming an organization into a digital state, we mean digital becomes a key focus in the organization's activities, taking center stage in decision-making. In traditional models, launching a new product involves a lengthy preparation of a Business Requirement Document (BRD), which contractors then use to draft a proposal and agree on timelines, resembling a Waterfall approach. This process is time-consuming, and by the time it's implemented, market conditions might have changed, impacting the competitive advantage due to the production lag.

In the digital paradigm shift, digital drives decision-making. When creating a new product, there are discussions around channels and distribution from a digital standpoint from the get-go. Digital takes precedence. Unlike the traditional model where a product idea originates in someone's head, the process now begins with customer research and marketing to create customer-centric products.

How do organizations realize the need for digital transformation?

Yes, that’s a good question and everyone goes through this. Organizations aren’t isolated; they see what’s happening around. Take the banking sector for instance, all banks monitor the products released by competitors, their performance, and customer response (though direct analytics access isn’t available, market analysis on competitors’ product performance is possible).

At some point, those not prioritizing the digital sphere realize they’re lagging behind competitors. For example, losing customers or receiving complaints about service quality as competitors offer better digital experiences.

When clients come to you, say, for a lower credit rate, their expectations are set by market leaders. If your digital offerings are subpar, they might leave. Even if someone took a small loan once and found it difficult to access their account or understand the payment schedule, the inconvenience might deter them from returning, even if your offerings are better.

So, you take notice of market macro-trends, analyze them, observe what others are doing, and see your product development cycle is longer, say a year and a half compared to others' 3-4 months. This affects your competitive edge since even if competitors err, they can correct it in the next cycle or launch a new product if one fails.

Seeing this, banks understand the need to adapt, to live in this new paradigm where digital services are demanded, to have these technologies to compete. They then look for ways to execute digital transformation, like hiring a transformation officer, someone proven with experience, which can be a difficult task especially with limited budgets and timelines.

Another option is consulting experts to outline a basic approach to ensure the transformation process is successful without ruining everything. Transformation is complex, changing most processes and organizational structure, which is stressful for those accustomed to the old ways and now need to relearn.

How can organizations approach digital transformation, especially when it's known to be a complex and expensive process? And how can they ascertain the necessity of this transformation?

Checking if digital transformation is needed starts with understanding its goal, like boosting competitiveness. Initially, a small part of the organization is chosen for a test run to mimic the conditions expected during the transformation.

This test run forms a new structure, called Structure B, where a couple of teams work under the new digital setup. The main goal is to see if moving to this digital state will improve how the organization works, speed up product releases, and enhance the organization's digital position in the market.

After the test run, a detailed comparison and analysis are done to see how well the outcomes match with the set organizational goals. This review covers many areas including process efficiency and user experience enhancement. The aim is to lessen any potential problems that might come up during the bigger transformation initiative.

Surely, the test phase will reveal many challenges. Yet, it serves two purposes. It not only checks the initial idea of the transformation but also points out the current processes that may pose challenges and need tweaking to fit with the new digital setup. The learnings from this phase are very useful, even if the test projects don't hit the expected success.

These learnings are key to improving the strategies for the next stages of transformation. They help in preparing the next teams and departments with the needed knowledge and strategies to move into the new structure without facing the challenges seen during the test phase.

So, even if the tests aren't hugely successful, they still bring the organization closer to digitalization by giving a clearer view of the areas needing focus, making sure the same issues don’t come up again. Most organizations, seeing the importance of digitalization, use these learnings to make the transition smoother in the next stages, tackling and fixing the identified issues carefully.

How to pinpoint where to begin the transformation? Is there an ideal sequence?

Well, there's no one-size-fits-all answer because all banks are unique with different market positions, strengths, weaknesses, development teams, approaches, accumulated experience, infrastructure, and so on.

At the outset, it's crucial to define the goal of our transformation. For instance, the aim might be to release products more frequently, improve quality, increase market share in these products, or become competitive in certain areas. But this may not always align with a particular bank's strategy. Thus, based on this business strategy and approach, a key direction for the pilot is formed.

If we aim to develop a product and be competitive in launching new products, testing new hypotheses, attracting new customers, and adapting flexibly to requirements, then we can affirm that this is our goal. We understand this goal, and within the pilot, we want to verify that this goal is achievable. How can this be done?

Key indicators like OKR or KPI are formulated to determine the success of the pilot once concluded. These indicators encompass a broad range of metrics from a business standpoint as well as technical approach and the overall process. Ideally, these metrics can provide a deep understanding of how the transformation will affect other processes, how much retraining of employees will be needed, or whether hiring new staff is necessary.

Next, having clarified our direction and the metrics we will obtain, it's essential to correctly choose the pilot area. Banks have a vast range of products and many people developing them. Something that brings little or no benefit to the business could be chosen as a pilot. For instance, if a bank lacks a digital channel for attracting savings accounts, this could be an excellent candidate for a pilot.

How is this done? We analyze the bank's current activities, products, and everything else. By comparing it with the competitors, we devise a matrix where we can see strengths and weaknesses. Another focus is feasibility. Considering the current organization, processes, and legacy infrastructure, we need to understand whether transforming this product within these timelines is realistic—a sort of feasibility check is needed.

Finally, we compile this matrix, i.e., the benefit for the business and other indicators, and its feasibility. Accordingly, we choose what is the most important for the business and the most feasible. This is how we determine the goal and scope for the pilots.

How can one approach team formation and scaling changes after conducting a pilot?

Suppose, after the pilot, we realize that transformation makes sense for us and we have a functional Structure B in place. And we have this picture where everyone works this way. To build a bridge from this picture to the entire organization, which may have tens or hundreds of thousands of employees, is not always simple.

Next, we identify a set of technologies. Ideally, we should update what we have, see where we can reuse something, and where we need something entirely new. This leads to an understanding of the future technological landscape, the tech stack we'll use and the infrastructure: whether it's in-house, cloud-based, or a hybrid solution.

With this figured out, we can start detailed planning. Suppose we have some marketing insights and understand our audience—accordingly, we start forming the scope of work for this product. Given three to four months, what can we achieve? What's crucial from a functionality standpoint? We break down the product into features, slice the scopes in some way, and turn it into a certain backlog.

For implementing this backlog, we estimate what kind of team is needed—whether it’s five or seven people, or two teams perhaps. Then we start working on the backlog together with the teams. Here, as in the classic Agile approach, you have a team, a certain deadline, and a backlog. This turns into classic project management. And if you realize at some point you're falling behind, what can you do? You can cut the scope, add people, or move the project deadlines.

It's also crucial to document all issues during retrospectives. There are two levels of documentation. The first level is local, as the team will face problems during development. Secondly, they will also face global problems, as they work in a new paradigm, while the rest of the organization doesn't.

In Agile methodology, sprints are the norm but traditional departments like legal and risk may not align with this pace, creating a bottleneck. Transformation leaders preemptively identify individuals from these departments to assist in implementation, albeit partially, to ensure necessary support during the pilot phase. Despite this, the partial involvement, for instance spending 20% of their time, might cause disruptions as urgent requests from Agile teams can lead to multitasking and delays.

To mitigate this, a leadership-supporting project team is formed to handle arising issues efficiently. For example, if legal approvals stall or procurement delays threaten the timeline, this team intervenes to accelerate the process or find alternative solutions, ensuring the Agile process scales smoothly within the organization while navigating through these institutional hurdles.

What common challenges do organizations face during transformation?

I would divide these challenges into two types: procedural and human, or in other words, structural and cultural. When we start transforming a company, the usual hierarchy changes. People used to work in specific departments under managers. Now, they’re in an agile setup without managers. They aren’t told what to do but are made aware that they’re accountable for their own tasks.

For instance, I’d prepare a report, send it to my supervisor for review, and if there was an issue, it wasn’t my job to fix it. This setup didn’t encourage employees to take the initiative. But now, if you spot a problem, you’re expected to mention it, try to solve it, and generally work on it. This is a big change because earlier, intervening in others’ tasks was frowned upon. There was always a specific person to handle specific issues.

Adjusting to this new culture isn’t a one-day affair. It requires a ton of effort. During transformation, not only is the structural aspect changing, which is manageable, but the culture is transforming too. The culture change can be significant, requiring training for everyone transitioning through this change. It's not a matter of attending a lecture one day and implementing new methods the next day. It’s about living through the change, going through cycles to fully grasp and adapt to the new ways of working.

Not everyone will fit into this new culture, and that's important to understand. People are different. Some value a structured, secure environment where their tasks are clearly defined. In the new setup, the absence of clear rules and the increased self-accountability can be challenging. Some people might thrive in this environment, while others might not. It's a significant point to consider when going through a transformation.

The structure, culture, and processes are all changing. By conducting pilots, we build a knowledge base to adapt to future changes. It's better to transition to new processes in phases, learning from each phase to aid the next. And leadership is crucial in driving this transformation. Leaders should have the authority and resources to push the transformation and actively participate in it.

But often, individuals tasked with driving transformation lack the influence to bring real change on the ground. People, in general, resist change, making the process challenging and at times painful. This resistance can lead to sabotage, not out of malice, but because individuals are focused on their current tasks tied to their performance evaluations.

This, in essence, encapsulates the major considerations during a digital transformation.