In my previous article, I defined the concept of efficiency and digitalization in the financial industry and presented the benefits it brings, with a focus on interoperability and business transformation agility. I am now using my first-hand experience at leading efforts in this area to come up with ten basic rules to avoid the main pitfalls and apply best practice.
Rule #1: Change has to come from the top
There are a number of reasons why the transformation of business processes in a financial institution needs to be strongly anchored in the top management.
Firstly, it should be clearly aligned to the strategic priorities and the vision to be achieved. Where does the firm aim to be in three to five years from now? How does the transformation fit into the current overall strategy? For instance, if the focus is on short term cost cutting, I would advise on a low-tech streamlining of individual workflows and the introduction of robots to replace more expensive humans wherever possible. If on the contrary the institution is aiming at a leading role in the future financial ecosystems where interoperability will be a prerequisite, the project should start with a review of the overall technological architecture and be driven on a company basis.
The other reason is that change does not happen by itself, especially in incumbent financial institutions where the staff is used to doing things in a certain way and where Standard Operating Procedures (SOP) are too often missing. In addition, individual units are primarily focused on their KPIs (Key Performance Indicators) which are usually short term goals in a “business as usual” mindset. It is therefore the role of upper management to take the balcony view, set longer term goals, allocate the resources and follow-up on the achievements.
In any case, it is also only upper management which can break the mental barriers to change. People tend to love the status quo and the hurdle to change how things have always been done is really high. Yes, initiatives will be regularly started from the ground by enthusiastic employees, but unless they get support which goes beyond moral encouragement, they will tire and return to their business-as-usual mindset.
Rule #2: Someone needs to take a driving role for any given end-to-end process
End-to-end processes involve, by definition, a number of units, including the front line sales team, the product units as well as the support units (compliance, middle and back office, etc.). Each one can try to improve its own way of doing, i.e. its contribution to the full workflow, but if no one takes the responsibility of the whole value chain, little will happen.
Hence the need for a driver with a clear mandate from management.
In many cases, the customer fronting unit is the one best place to take ownership of the whole value chain since they are the first one to suffer from inefficient processes. For instance when admin tasks take too much of their time, errors are regularly made and customers complain about long delays in answering their requests. Ultimately, they are responsible for what is delivered to their customers, they get allocated all the costs involved and they are the only unit with the total view on the end-to-end value chain.
Rule #3: Start from the core processes
It is tempting to address a specific process inefficiency with a local solution. It is in fact the way to go if solving this pain point can be done by redesigning it (how information is flowing, who is involved, etc.) and questioning rules (for instance internal procedures to comply with a given regulation can be unnecessarily strict). But if the effort involves the use of technology at scale, it makes sense to start with the core processes.
Core processes attract more attention and are more likely to get funding and resources. A cascading effect can then be initiated by demanding the digitalization of connected processes and is a good opportunity to insist on having clear internal SLAs (Service Level Agreements) and full auditability and visibility of those supporting processes.
Rule #4: Use common sense before calling-in a robot or an AI
Transforming end-to-end processes in a profound way requires the widespread use of technology (Digital platforms, robots, workflow tools, iBPMs, AI, etc.) but also to apply common sense. My experience is that some of the initiatives require substantial development resources and IT budget, but many of them are more about clarifying roles and responsibilities, and challenging the internal guidelines which in many cases have become outdated.
A method used by my former employer really made a difference. We created ChangeLabs which gathered around a facilitator all the participants in a specific value chain for a time-boxed “sprint” lasting a few weeks. This brought a structure as well as a proven framework for analysing the pain points, prioritising the issues and looking for concrete, and primarily short term, solutions.
Rule #5: Optimising current processes is not the end game
A trap I have noticed too many times is the urge to improve current processes without reflecting on the possibility to completely reinvent them. The risk is to focus on doing better what has always been done, to improve bits and pieces or even to make them more digital or automated. Instead, end-to-end processes should be rethought totally and redesigned in the best possible way, using technology where it makes sense.
Digitalization efforts should also be seen as a unique opportunity to question the status-quo, anticipate what is coming in the financial industry sector and prepare for it. For instance, what if the existing business model or large chunks of it start to be obsolete in 5 or 10 years time? It is generally difficult to grasp the industry trends and conclude on how they will affect the current business, but one thing can be done: to keep options open. In this respect and since ecosystems are becoming prevalent, building a high level of interoperability for the key business processes is a decision which has little downside.
Rule #6: Aim at modularisation
Such interoperability is reached when processes and sub-processes can plug-and-play into each other and with the external world. This means that, when processes are redesigned, the goal should be to move towards modularisation: each process should be chopped into a series of modules (or micro-services) built as APIs. This brings flexibility and the ability to easily change or upgrade a given micro-service.
For instance, a modular corporate lending process is made up of micro-services that are integrated together to deliver, i.a., the credit rating of the customer, the list of all the bank’s exposures to a given customer, or the industry sector analysis. When this is achieved, data can flow between systems in real time, eliminating rekeying, manual imports and inconsistent formatting. In such a set-up, a good governance model is really important, with in particular each microservice having an owner, i.e. someone responsible for its performance and improvement.
Rule #7: Measure what you can, before and after
As Peter Drucker coined it, “you can’t manage what you can’t measure”. This is all the more valid in a business efficiency project where the development budget needed will be weighted against the benefits it will bring. To be credible, the business case needs to include easily measurable and credible parameters like cost to process (primarily employee time needed), speed (time from initiation of the process to the delivery of its output) and reliability (down-time, number of errors and related costs).
Other benefits, for example increased sales thanks to more efficient processes, better auditability of those processes or the production of extra data are more difficult to measure. And when it comes to technology infrastructure transformation, for instance to reach a high level of interoperability, it is more about a strategic bet on the future than an excel calculation (although in many cases those will be produced).
Rule #8: Communicate relentlessly
Like for any change initiative, it pays off to involve at an early stage all those who will be affected, for instance by interviewing as many of them as possible on the current processes and asking for improvement suggestions. During the development phase, progress reports should be circulated very regularly (or better, presented in person) not only to management but equally importantly to those who will be affected by the change. And during the implementation of new processes, especially when technology is used and affects the way people cooperate with each other (for instance an iBPMS platform), you should not take for granted that those affected will immediately change their way of doing and you should instead continue to evangelise the benefits generated.
In fact, it is smart to groom early adopters to be advocates of the new processes, by involving them all along and using them as a reference board. They will be very instrumental to spread the good word, especially if they are considered as influencers.
Rule #9: Be ready for setbacks
Changing the way things are currently done faces resistance from many directions, so be prepared for a roller coaster of achievements and setbacks. I have for instance met the following obstacles:
- Multiple stakeholders in the value chain, making the anchoring, decision making, prioritisation and funding process cumbersome;
- Scarce resources within stakeholder teams, especially in support units which have experienced staff reduction and near or off-shoring, leaving experienced employees with very little time for development initiatives;
- IT organisation (development and architecture) more concerned about keeping the shop running and avoiding risks;
- Kafkaesque process for evaluating and onboarding external technology providers or partners.
Rule #10: Keep a positive spirit
Be patient with the naysayers, they are often just worried about their job. And resist those who argue that “we need to fix the basics first to get a good foundation in place before we can truly innovate and transform”. I agree that it is difficult to innovate when there is a weak platform, processes are manual and data access and quality are poor. But if you listen to them, there will always be something to be fixed first.
As I like to say, attitude is everything …
In my next article, after taking a harsh look at the role of traditional business consultants, I will try to define a novel way to combine external contributions with internal competence build-up.
