Upskill

"What does that role look like in the future, what are the key skills that we think we need them to have? We need them to be fairly analytical, we need them to understand at a high level how technology works. That does not mean we expect them to code, but we need them to be able to understand that: this is what a data set looks like, these are the different types of manipulations they can go through..."

Jibran Ahmed - Executive Director, Capco

Listen to the episode below to find out more

Episode Transcript

[Sally Yates, CMO, Xceptor] Welcome to this episode of Unleash Your Data, I'm your host, Sally Yates. This season on Unleash Your Data we have had the shadow across the globe of the black swan event that is the pandemic. We will talk about impact so far, learning so far, as well as what hindsight can teach us as we talk regulation, Intelligent Automation, and digital transformation. We've heard from other guests about some of the unintended consequences and their hopes of how it can shape our future workplace and industry. How else has the global pandemic shifted perspectives? Our guests are well placed to tell the stories of how a wide variety of firms are handling challenges of the highly demanding industry that is financial services. Today's guest is Jibran Ahmed from Capco. Jibs leads the research and development team and Innovation Lab at Capco, which focuses on the use of the latest technologies such as AI and machine learning and how they can help build the future of the banking industry. As a consultant, Jibs focuses on pushing the boundaries of financial services by making the art of the possible a reality for large financial institutions, not only through implementing technology changes, but also through pushing for changes in the way organisations work, collaborate, and approach problems. Welcome Jibs.

[Jibran Ahmed, Capco] Thank you for having me.

[SY] Thank you for joining us for a chat today on Unleash Your Data. From Jibs’ bio, it is clear that he has a passion for people, technology and change and today's podcast is going to focus on just that with a wrapper of successful organisational change. Obviously, people are central to transformational change and we understand that, but all too often that focus, you know, the focus sits on the process and how to automate that. Take us through some examples of where you have seen the impact of banks taking a people centric approach.

[JA] Yeah, I think you are absolutely right that the focus is often too much on the process and how to automate processes. More broadly, I think, not just financial services, when we think about change, we think too much about technology: we get really excited about the latest tools and gadgets and gizmos and so on, and we don't actually think enough about the people.
The reality actually, in my opinion, is that technology does not actually determine the future of our industry or the future of any industry, it is the humans that do. If humans don't adopt the technology or don't gel well with the technology, then that technology is bound for failure, regardless of how good it might be. So, the human aspect of technology adoption is incredibly important and what leads to technology change sticking is changing human behaviours effectively and allowing human behaviours and skills to adapt in tandem with new technologies coming along. And too often we see in large organisations, not just banking, where you throw millions of dollars at a new system, or new technology, and try and hammer it in there because you think this is the new fancy thing that's going to reduce my cost or increase my sales or whatever, but we don't think about the human effect that it has, you're not necessarily going to have the people with the right skills, you're not going to have people who are motivated to adapt and change, and you might have employees who are afraid that they're going to lose their jobs because of this new technology change, or afraid that they're not going to be able to operate the new systems or whatever it might be and they might choose to leave or just may not perform at the highest level that they're capable of performing at. And so, thinking about all of those things is incredibly important when diving into any kind of technology change, and even more so right now because the type of technology change that we are seeing happen in financial services, and that Xceptor and the other firms in the automation space are a big part of, is a fundamental change in how we work. We're not just swapping out system A and putting in system B, and just you know it's not like moving from Excel to Google spreadsheets for example, we’re fundamentally changing how we operate: humans in back office operations environments are going to be doing a different type of job in 5 to 10 years’ time because tools like Xceptor will take away a lot of the manual grunt work, they will even take away some of the lower level intelligence work that is currently carried out and so we need to be cognizant about that. And so, with some of the banks that that we are working with at the moment, and I have worked with over the past couple of years, we are looking more holistically at change. Yes, we have to focus on the technology and the process to some extent because we have to fix certain burning issues, we have to automate certain processes to improve efficiency, reduce costs, etc. But we are trying to do that with a longer-term view on where are we going as an organisation in terms of the architecture, the roadmap to that target state, and what it means for the people, the skill sets the roles and how we operate as a set of teams and as an organisation.
So as an example, I can't, apologies I can't mentioned client names, but I'll try to describe as best as I can without revealing confidential information. But one of the large banks we are helping run a large transformation programme in operations where, yes, there is a big focus on taking out in efficiencies and improving cost by using various automation technologies, by digitising processes where we can, and there are some short term wins that we go after just by saying, well here's a great tool do X, Y, Z; but in tandem with all of that, we've spent and this client has spent quite a lot of time on a global level, looking at what are the likely roles that we need to exist in the future of our organisation, because they will change, if tools like Xceptor and other automation tools are taking away a lot of the manual grunt work: what is it that a human spends their time doing, where can they add value and what skills will they need in order to be able to do that job and which skills will become redundant. And so, with that in mind that they have looked at what are the new types of roles that might exist and one of the roles we are looking at is someone in operations who understands both the domain content of the area that they're in, so they understand the particular financial services product set, and how it operates, and what are all the things that you need to do in order for that product to be able to execute front to back. But then they also understand how to operate some self-service technologies, those are tools like Xceptor, where you do not have to write code or you do not have to write much code, but they allow you to carry out tasks that five years ago we would have said you definitely needed a developer for that. And I like to think of them as Excel on steroids. Because historically in banking, we've had so much Excel work that goes on. I've seen some phenomenally complicated things happen in Excel, and it's great because that has allowed us to move away from manual number crunching to automating an enormous variety of things, but Excel isn't a performance scalable, secure manageable solution, whereas some of the new automation tools we're seeing are. And so, what we are seeing, at this organisation, is a look at what does that role look like in the future, what are the key skills that we think we need them to have. We need them to be fairly analytical, we need them to understand at a high level how technology works. That doesn't mean we expect them to code, but we need them to be able to understand that this is what a data set looks like, these are the different types of manipulations they can go through, this is roughly what an API looks like, you don't have to be able to build one but you have to know that this is what an API call looks like, and you know these the key types of errors that might occur if you try to integrate from product A and product B and it throws up a 404 exception, what does that mean. And that means these people can be skilled to then take a product like Xceptor and build an automation solution for something that might save them, you know, 50, 60, 80% of their time without having to put in a request to IT and say, I need you to automate this process, wait six months for funding, and go through that cycle of change which can take anywhere from, you know, nine months to a year. And then what we're also doing is looking at, you know, if we're going to have individuals with that skill set in the future: how do we train them? What are the qualifications they might need? Which vendors do we partner with to acquire those qualifications? Where do we recruit them from? There is an element of “you will need to transform your existing workforce” but big banks constantly have this pipeline of graduates coming in every year and they more likely will have some of that skill set, but if you sort of hone that search now, it means in a few years you will have the right people, or if you make sure that at graduate level they are going through the right training, such that when they are sort of two, three years into their career, they do have the right skill set to be able to carry out that type of work.
So that's the training element and then the other element to it is: how do you operate as an organisation because automation tooling is, if you really want to maximise the value from it, the classic waterfall approach to change in large institutions that we historically had, doesn't allow you to really extract maximum value. Because if you're still waiting a year to automate a smallish process, then you've missed out on a year's worth of change, and by the time you've automated that process, it's likely something else around has changed again. And so, we’re reorganising how the organisation works, in terms of how do you go from, I have a problem or have an idea, to I'm now ready to build this setting up a chord that can then go off and execute, and actually run with that with that change. And the general process, and every bank will say we do this is you know, adopt agile methodologies, adopt specialised pods that are multidisciplinary, and skill set and give them the freedom to kind of say: okay this is your thing for the next two months, you are going to automate this particular process. In reality, it is very hard to do because from the top-down, everything in the financial services industry certainly for big banks, is driven by annual budgets, annual change programmes, convoluted change request processes etc. And whilst in principle, everyone says yeah we do agile, the reality is you don't do agile front to back, the ability to execute change quickly is very hard. And so, we are working with a few organisations at the moment, around, how do you try to incorporate that rapid development mentality, almost sort of like an innovation lab but within your actual business where you take new problems or new ideas and try to at least execute a proof of concept very quickly to show that this will work, or it will not work. And if it will work then, as quickly as possible deploy a pod to execute. So, we are in the early stages of what I think is a large change over the next five years, but we are starting to see a shift away from, let's just implement the next shiny tool that comes our way too. Let's think about how our workforce is going to change in the next 5 to 10 years, what it means for our organisation in terms of how we work, how we manage and motivate people, and how we retain our ability to attract talents, to attract customers, and adapt to the world as it changes around us, so I'm quite excited that we are seeing a focus on people. I think there's a lot more to be done and it's definitely only happening in pockets, but I think the events of the last year have sort of accelerated that thought process, because one facet of the change is the fact that realistically we are not going back to five days a week in the office, and that alone is a significant change in how you manage teams, how you manage people, and how you execute change. But coupling that with a change in workforce, change in technology, increasingly rapid changing customer expectations, means that it's now time for banks and other big institutions to really think about putting people at the core of how to deal with change.

[SY] Interesting isn't it, to see whether that really happens, as you say there's many things to consider there: you've got to not just automate the process, you've got to rewire it, you want those self-service sort of like no code technologies so you're not reliant on those change requests and IT, but you've got to bring your people along with you. It's got to be an evolution, you know, bring the existing people along, bring the right people in, and get them to understand that actually this is you know rescaling, upskilling, it is part of future proofing, you know your skill set, your workforce and everything. And then it is, you know, and can we do it with a longer-term vision than 12 months, or the next cost cutting exercise, or it has to be as you say that transformational change, that long term vision.
Obviously, we are talking a bit about around organisational change Jibs, and it has been around for a while, and you talked a bit there about a project you have been working on there and how that client very much understands the need to focus on people. But by enlarge, what progress has the industry made, and have we seen any sort of tangible impact?

[JA] So I think that is a tricky question to answer because I think there is not a steady state that we can compare to and say this is what it was like and this is where we are now because organisations are in a constant state of flux. And I do not think there is a perfect model that any business can use, or certainly not for a long period of time, there may be a perfect model for a particular moment in time, but the world is constantly changing around us, and I think that the art in running an effective organisation is around how do you enable the organisation to adapt and change as the world around it changes. And I think that is what the real skill is: rather than coming up with one amazing operating model and saying this is it now, we are set for the next 10 years, and that just does not happen. And the things that change around an organisation can be technology, it could be competition, the market might change, human behaviour might change, a pandemic might come along… These things happen and it is more about how do you set up your organisation to be able to deal with those changes effectively? And I think that is where we see challenges with large organisations compared to smaller ones. But I think we all saw in the pandemic over the last year the smaller banks, and the smaller organisations generally, were able to adapt much more quickly. They were able to digitise processes that historically would have required someone to physically come into a bank or physically sign a piece of paper or something, and as your organisation gets larger, your ability to adapt becomes harder because there are more people, there are more processes, there is more bureaucracy, there is typically more regulation if you become a larger bank and more products etc. It all just adds up and it becomes very hard to adapt. If you couple that with what I said earlier about how large organisations typically work in a top-down manner with annual shareholder meetings targeted around how do we pay out a dividend, working all the way down to, you know, target growth, annual budgets per region department, and then working down to change budgets and so on, you end up with this massively complex set of layers in an organisation that mean it is actually very difficult to manoeuvre the ship in an event where you have to change quickly. And I think that is what leads to large organisations not being able to adapt as quickly as small organisations. And the events of last year, I think showed large organisations that those processes are not fit for major events or events that come along very quickly or unexpectedly, but it did also show that change is possible. We did see the large banks start to implement new digitised processes. They shifted from, you know, people coming into branches or signing physical documents to digitise signatures, trying to service as many customers as possible via online channels, etc. Did they find it harder than the smaller banks? Yes, absolutely. Did they managed to get it done? Yes. Have they learned some lessons that mean that in the future they will adapt more quickly and implement new technologies more quickly? I would like to think so… I think in reality, once the pandemic is over, I think our short-term memories will kick in again, and people will go back to leaning on the old ways to get which is a bit of a shame because I think we have learnt quite a lot from the pandemic. And the results are remarkable if you think about how quickly some of the big banks went and implemented new technologies and digitised what were core processes. You know, things like onboarding customers, or approving a mortgage, are things that, historically, you would have said no we have got to spend a year on this because we need to do it right, but they have done it in a month in some cases, which is remarkable. But you know those were exceptional circumstances and I think a lot of things would have been approved or pushed through the door as exceptional items rather than this is the norm for how we do change. And I really hope that some banks do change some of those higher level processes or the bureaucracy that exists that sometimes hampers changed. And I am not saying that those processes and bureaucracy are not needed, they are needed, because we are talking about critical processes, we are talking about people's finances, it is very important. But I hope they go through a process of reviewing them and trying to understand how can we make these more efficient, and how can we allow new technologies to be adopted more quickly because I think we are moving to a world where you need to be able to change quickly and if you cannot, then you are going to be left behind to some extent. So, I do think that there is going to be a reversion back to the old ways, and then probably a steady shift away to be, to be able to adapt more quickly and I wish it would happen faster. I'm slightly pessimistic in how quickly banks can change. The fundamental challenge for me is the fact that everything is done top-down, annual budgets, annual incentives, annual change programmes and that mentality has to change, if we do not change that mentality, we are not going to get to a position where we can implement something in six weeks or eight weeks. And so, for that reason I think, I am a little bit pessimistic about how far we have actually come post pandemic.

[SY] It is as you say, you know, being adaptive, speed, you know, a lot of the changes that we have seen are ones that we were expecting to come but over a much longer period. And as you say, it is great that just happened, we have seen the sort of the culture shift in the workforce as you say we will not go back to the five days in the office. And can the organisations, really, you know, challenge themselves to take the opportunity and move forward. And we have seen as well, being big does not mean also that you are safe, you know, it does not mean you will survive. And so, if they don't change, there can be some you know some very severe consequences
We talked a bit a bit earlier around the sort of the self-service technologies, the sort of like no-code platforms and you know they are very much gaining momentum and putting the power in the hands of the business. I have heard you talk a bit previously around, you know how no-code is the future. Talk to us a bit more about that and how people can drive that adoption internally?

[JA] Yeah, I think I use the term Excel on steroids earlier. If I think about automation. We've since the dawn of computing, we have tried to automate as much as we can. And what we are seeing at the moment is just another wave in that sort of constant progression of trying to make things more efficient and use technology to make things as efficient as possible and Excel for the banking world was a godsend, because it allowed us to automate so much of what we do. And if you couple VBA with that, it really opened the doors to allowing the average employee let's say, to go off and automate things that were mundane or repetitive. Now, the challenge with Excel was they still require you to understand either how Excel operated quite deeply, so you need to have a really strong understanding of the formula and functions available, or you needed to be able to code and write VBA. And some amazing things were done with Excel, I've seen, you know I said earlier, some absolutely phenomenal solutions built with Excel, but it's also a dangerous tool in some ways, allowing an individual who may not be a trained software developer to write code that affects numbers or values that ultimately go into financial reports or might impact a customer in terms of the products or services you offer. It can be dangerous. And I think, naturally the evolution from uncontrollable proliferation of Excel files was to have as a mechanism of automating these types of tasks with more control, with more security, with the ability to scale up the performance, and with assurance that things are not going to go wrong. And I think that is where, it is one of the reasons that led to the plethora of automation tools that are out there at the moment. I think the brilliant thing about Excel is that you did not necessarily need to be a coder to be able to do pivot tables and to automate some of the calculations that you did. If you were able to code, you were then able to go that extra mile.
I think what we are seeing now with the automation tools is we are making it even simpler for people to automate those parts of their jobs that are a bit laborious, are a bit mundane, are not particularly complicated, but do save them quite a lot of time. And I think what the various tools have tried to do is pick off certain types of activities that we think are safe enough to automate and easy enough to automate at scale, such that you can then allow the human to focus on the other things, and so a lot of early automation tools were about clicking buttons on screens, we are now getting automation tools that manipulate data and produce reports, and getting increasingly more complicated extract data from other documents, help make decisions, and so on. And there is still an element of coding involved this, but there is still an element of low-code or no-code solutions and I think now that we have tested that robotic process automation or Intelligent Automation as you call it, does work and it can be successful, and it can save you a lot of time, money, and effort. It's time to start putting that into the hands of people who sit in the offices, not necessarily in IT, but in operations or finance or the back-office functions, to allow them to really exploit what these tools are capable of doing. And a lot of the tools out there are building with self-service in mind, which is really important. You know, they are building them such that you do not need to understand the nitty gritty details of how the code works behind the scenes, you need to understand what are my inputs, what do I need to do to them and what are my outputs? You know, it's almost like putting together a diagram in Visio in many cases. And I think one of the things I like about Xceptor is that you can build some very complex automations without really understanding the technicalities of what is going on behind the scenes, you can integrate with dozens if not hundreds of other applications and extract data from them, and you can build reusable components almost like Lego blocks that you can take and reuse without having to go back to the drawing board every single time. And that unlocks an enormous amount of power for the user on the end of that automation. And I think for an organisation to be able to really leverage these technologies they need to give users that ability to utilise these tools and automate a lot of the mundane tasks or the repetitive tasks or the inefficient tasks that they carry out on a day to day basis. And I think that will happen, we are already starting to see it happen in some cases, I think there is still a bit of nervousness around allowing users to go off and automate whatever they want and rightfully so because, in financial services particularly, we are dealing with sensitive data, we know that the margin for error is very small, if any at all. So, the nervousness is understandable, we will need adequate training, we will need adequate policies, we will need adequate control etc, and those things will come along in time. But I think if we stick to the historical model of only IT are allowed to build technology solutions, banks are not going to be able to evolve quick enough. A task that saves an individual, half an hour a day or an hour a day is never going to make it to the top of the backlog, or a big IT function. And so, we have to put that power in the hands of the users. And you know some of these things change so frequently as well that having to go back to IT every month and say, “now I need to change this process a little bit”, it is just going to delay things and so you need to be able to put power in the hands of the user. The big challenge is, where do you draw that line: what do you allow the user to do versus what requires IT to step in and say, actually, you're dealing with, you know, very sensitive data here so we need to make sure that there's controls around the data, or, you know this data that you're working with is going to be pushed into our general ledger at some point and therefore we need to make sure there's checks and balances in place to ensure that it's correct, that it's not being manipulated, etc, etc. And so, there is a lot of complexity around in the financial services world, and whilst I think some of the tooling, you could drop it into the hands of users now and it would work and they would be able to do great things with it, we're not going to be able to do that immediately simply because we need to figure out, in the financial services world, what is that model, where is the balance between what the user is allowed to do and what IT have to do. And in reality, where is that overlap, like how do we get them to work together so that the user can build some fairly complex things and engage IT at the right time to balance it, you know, have I do not it right, is there anything I have missed, is it secure, etc... But it is all part of the learning experience and we are getting there eventually; it is just you know in financial services we have to be a little bit sensitive to these things and allow change to happen with the right controls in place.

[SY] Yeah absolutely, as you say it is that balance, isn't it as to who owns what, but also getting IT and the business to work as partners, and to sort of drop those sort of like fiefdoms for having that sort of wraparound of security and audit but also having that ability to do the human-in-the-loop piece, so where you need the four eyes and the six eyes that's actually baked into the process. So, you know, not a simple ask, but a reasonable ask in our industry. We touched a bit there, a bit more on the data aspect, Jibs, and as we know, you know, the value sits with the data and the flow of that data. Again, how well understood and acted upon really is that?

[JA] I think at the moment the view on the value of data and how we can automate the flow of data across an organisation largely sits within the CDO function of a bank. And I think, on the business end, you know the part of the business that owns a particular product or service, I think they see problems with the data, and they understand that the data causes issues, but they do not think about how do we fix the data issues down at the architecture level. They often think about how do I automate a particular process, and how do I get my customer on boarded as fast as possible, or how do I produce these reports as fast as possible. And for that type of problem statement, a lot of the automation tools that currently exist are great and they can help solve that problem. But often what they do is neglect that there is a fundamental problem somewhere with the data architecture which is leading to that problem, or what they do is they allow you to solve that problem in isolation. So, you can build an automation process to automate the creation of one particular report for one particular department, but then there is another department somewhere else creating another report that is 80% the same but doing it in a different way or using a different tool or not automating it at all. And those are the types of challenges that are very frustrating for a CDO function because they would like to have a data architecture that allows any department to generate whatever reports they need or to gather, aggregate, consolidate whatever data they need. I think data functions, CDO functions, are now waking up to the fact that they do need tools that allow them to automate key parts of the data flow, but I think they are realising that they need to move to tools that are more adaptable that can change more easily, etc. And I think they are also realising slowly that it comes to data, the use of data, the manipulation of data, and the generation of reports, you cannot hog it all as a CDO function, it is too big, it is too complicated. So, there is a line at some point where you have to say: okay, I have got the core data architecture in place and I can deal with all the critical things that my data architect needs to do, but when it comes to the user reporting and the use of that data, there has to be a point where I provide autonomy to the various business areas. And I think that’s where the value of being able to automate data processes becomes incredibly powerful. Because if you have a tool like Xceptor, which is used to automate a particular part of the data flow, you know, let's say we are automating the process of gathering data from five different sources, compiling it all, carrying out some manipulation and churning out reports. You can then take that data automation, and I'm going to call it data automation not Process Automation, you can take that data automation and use it elsewhere, you can use it 10, 20, 30 times, and just make that 5-10 percent tweak that you need to make to customise it for a particular business function or a particular product, and I think there is a huge amount of value in that, because in my experience of having worked in many, many banks over the last nearly 15 years, the amount of repetition in processing the same data, again and again is insane. And not only is there an inefficient set of processes there because you have got multiple humans doing the same thing with the same set of data. There is an added layer of inefficiency because inevitably if you put four or five people in a position where they are having to do the same task, they are going to do it slightly differently, or mistakes are going to be made. And so, you then end up with situations where you have to then try and reconcile, why are these two sets of numbers different or why does this data not look like the data coming out of department B. And I think all of that is incredibly inefficient, I mean, in my view, reconciliations should not exist. You should not need reconciliations if you do data properly, you just should not need reconciliations at all. And I think that should be an ambition for banks and apologies for anyone who works in reconciliations. I find it mind boggling that in this day and age, we still have to have humans there comparing to two sets of data and trying to understand why they are different, and I think that is where, you know, we need to really think about data automation as well as process automation. The process automation is important because you do need to automate the clicking of screens, the making of decisions and so on, but we should think about it in the context of what am I doing with that data, am I doing it in a consistent way am I doing it in a way that is reusable, scalable, etc. And am I leaving something behind that can be used again, I think is an important thing to think about, because if I'm automating the process and I only ever use that automation once, I am not being particularly efficient in my use of technology or use my time; but if I automate a process and then I can take 20% of what I've done, and save 20% of effort on the next time, then I'm being incredibly efficient. And the beauty of tools like Xceptor is that more things you automate with it, the more you build up this library of little components that the next person can just come along and say oh you have already done that extraction from the system. Cool, I'll take that. Now I just need to build my extra 20% on top of it.

[SY] That's it, isn’t? Getting people to see data truly is the lifeblood of the organisation and looking at you know who touches it, you know, when, what, what do they do with it. You know who else would use that and, you know, it is that partnering together, and you know that bigger vision probably will take a bit more than 12 months though Jibs, so probably put that on the wish list, think about that one for a while. It has been really interesting Jibs, is there anything else you would like to add that you think you know our listeners should hear from you.

[JA] Yeah, I think when we talk about change, I really like to take a longer-term view and work back from there. It is really easy for us, particularly in a fast-paced environment like banking where critical requests come at you repeatedly and there is often a focus on of we have to get this done by X date because there is a regulatory deadline or, you know, there is a customer pain point, or, you know, we have suddenly had to switch to everyone working from home. And we tend to take a narrow short-term view on change. And I always encourage people to just step back and think about where is this heading in five years, and work back from there so that when we do implement change, even if it is a short term, tactical fix, we are keeping an eye on what, what the longer term journey is, and trying to ensure that whatever we put in place today we are doing something that moves us incrementally, a step closer to where we want to be in five years’ time. And I think if we all do that, gradually we start moving towards the ideal state in terms of the technology we use, the processes we use, how we operate as teams, how we upskill the humans in our workforce… And that is all it takes, it is those marginal gains every single time so I would encourage everyone really to never take your eye off the longer-term plan, or the longer-term vision, even if you are doing something that is, you know, a quick one-month super urgent piece of work. Just take, you know, even if it is just an hour to brainstorm with your team on where is this going in five years, absolutely do it.