"I believe the adoption of DevOps principles and methodology can alleviate these Technology and Operational constraints to support the Treasury team in fulfilling Business Objectives." 

 

​

Francois: OK, so can you briefly explain what DevOps is and how it can be leveraged? 

 

Darryl: Sure. DevOps is a methodology to rapidly develop and deploy software and infrastructure. You can think of it as a faster and more reliable way of rolling out new features. To shift the perspective away from Technology and towards Treasury, you could consider it as rapid way of responding to market and stakeholder demands. For example, a demand for a new capability like an additional currency, Bank Account, or a new type of Loan.  

  

Francois:  Responsiveness to demands and more rapid delivery sounds a lot like Agile. 

 

Darryl: Good point. And the discussion today could have been "How can Agile influence Treasury Operations", but that would not have been far-reaching enough.  

Agile and DevOps are similar, as they both consider collaboration across different areas, Technology and the Business, or with our Treasury lens we could reframe to Technology, Front, Middle and Back Office. But DevOps extends the Agile development methodology to include the deployment as well. 

 

Francois: So, what are the benefits of adopting DevOps? 

 

Darryl: I think one of the best ways to answer that, is to imagine a Treasury department that desperately needs automation and new features and functions. 

Imagine a Treasury department running with many manual processes and an inability to automate or cope with new demands from the Business. Safely, rolling in new capabilities may take many months or even years. This leads to the operations team working with an ever-increasing amount of "temporary" manual workarounds. The technology team is constantly supporting/fixing an unstable solution that repeatedly has issues whenever fixes are applied. A situation with constant fire-fighting and unhappy end-users.  

This environment breeds a vicious circle of spiralling inefficiency as the various teams blame each other, degrading communication and collaboration in requirements gathering and testing. 

With frequent outages, misconfiguration, and error-prone manual workarounds, all the resources are overwhelmed and overloaded, unable to accommodate new requests from the Business. Scaling up is only possible by hiring more people, but they are ineffective as no one has time to train them properly. The overall feeling of hopelessness leads to high staff turnover that exasperates the situation.  

OK, so that is an extreme example, but we have all encountered parts that will sound familiar. Stressed-out Treasury and Finance teams that dread the month-end and end-of-quarter cycles that are then overwhelmed with change requests to stand up a new Entity Group in a different country. 

 

Francois: Yes, I have seen those situations where the Treasury team struggles to meet new business demands. 

I am convinced that there are still too many manual processes in treasury departments. One of the most striking examples are the FX management where the pre-trade part is manual and not at all interfaced and integrated, with the risks that this implies. Similarly, the management of hedging relationships or other IFRS reports remain semi-manual through export from the TMS reworked at the cost of heavy efforts of the teams. Still at the FX level, too often the systems in place cannot handle certain financial instruments or their banks cannot hedge certain more exotic currencies. The solution is then to do nothing or to refuse to trade in these countries, to the detriment of the business. We can also mention cash-flow forecasting, which remains problematic for any company to the point that they wonder about the usefulness of dedicated solutions. Therefore, they continue pilling up solutions and make the whole IT architecture extremely complex. Here again, the processes are so manual and in Excel that the production time is enormous and the reliability low, without being able to simulate or stress test future cash-flows. And even when a company uses a TMS, it is often never fully implemented and therefore under-utilized. When reviewing a customer's treasury internal controls, one is often surprised by the lack of effective, documented and tested controls. Digitization requires automation and the treasurer always thinks he is more automated than he is. Finally, the teams get used to manual procedures and, unfortunately, live with them. Too bad when you know it could be optimized, isn’t it? 

 

Darryl: Exactly. 

 

Francois: So, how does DevOps help? 

 

Darryl: I think there are two stages, the first being a review of the current situation, a primer for Change regardless of methodology. 

Here the relevant stakeholders should revisit the Treasury Operating Model and its relationship with Finance and IT. This should be followed by a vision on "What Does Good Look Like?" “What is our purpose?” “What are we trying to achieve?” “Can Data be Loaded rather than Manually Entered?” “From a Lean perspective, within the current Treasury Operating Model, what can be optimised, removed, enhanced and how can the various teams work more efficiently together?“ Are there any tactical quick wins we can get to simplify reduce manual work, for example using Power Automate to load data from Word Documents into systems rather than manually keying it in. 

Then by referring to DevOps, there is the implementation of an enhanced collaborative Change capability. With a focus on Continuous Development and Continuous Integration, there should be a move away from long implementation cycles by automating as much as possible. “How can a cross-functional team speed up the change process from requirements, design, testing and deployment?” “What can be streamlined?” Again “What Does Good Look Like?” “What manual processes can be removed?” “What sign-off and quality assurance is required?” “Can the deployment of test environments be automated?” “How can we simplify the onboarding processes, maximise reusability and the reduce the number of errors?” “How can we free up and prioritise the resources to work together in a transparent progressive way?” “How can we build in continuous improvement and learn from each deployment?” Can we aspire to implementing minor changes to applications within one business day? 

 

Francois: I like this. I can see how this approach would have helped me in the past, but I would think that this is not easy. What are some challenges that organisations might face? 

 

Darryl: Agreed. It’s not easy, but it is a long journey that will realise benefits along the way, not a quick trip. You don’t have to aim for perfection. The main challenge is getting everyone to adopt the right mindset - the cultural Change. DevOps requires a greater level of collaboration and communication, which can be challenging to achieve in organisations with a lack of trust and respect, and siloed teams with rigid hierarchies. Unfortunately, companies that exhibit these characteristics probably need it most. A bespoke reward and recognition framework can help incentivise the right actions, but Cultural Change is a Pandora's box we don’t have time to cover now. 

Then there is the skill and capability gap, another topic that came up on the ATEL Tech Day. Treasury, Finance, and IT teams may need to develop or acquire resources with the required skill sets around automation, testing, migration and infrastructure management.  Of course, related to this, the company may also need to invest in new tools and technologies that facilitate automated testing, deployment, and collaboration. 

As a final point, unfortunately, in some cases, the current Technology may be too immature to properly leverage DevOps methodology. Rolling out DevOps in an Excel/Highly Manual environment could stabilise the current environment but offer little long-term value. In this case, one would have to consider outsourcing areas and investing in a new Treasury Solution as part of the leap to a better Operating model. 

 

Francois: Thank you for your time and insights.  

​

Darryl: My pleasure, thanks for having me.