For many equipment finance organizations, modernizing technology still conjures images of massive, disruptive overhauls. But according to Campbell Clout, Managing Director, GTM, North America and APMEA at Odessa, that’s a misconception. In this conversation, Monitor Editor-in-Chief Rita Garwood talks with Clout about what modernization actually looks like when it’s done incrementally — from the shift toward vendor-led playbooks, to the real benefits of an MVP-first approach, to a case study of a client that scaled from one country to 32. They also cover the honest trade-offs of phased implementation and where AI is delivering real, immediate value today.
Watch the full podcast below or listen on Spotify.
Rita Garwood: Hi everyone, welcome to the podcast. I’m Rita Garwood, Editor-in-Chief of Monitor. Joining me today is Campbell Clout. Campbell is Managing Director, GTM, North America and APMEA at Odessa. Thanks for being on the podcast, Campbell. I’m excited to talk with you today.
Campbell Clout: Thanks, Rita, looking forward to it.
Garwood: Just to frame our discussion, I want to start broadly. In your opinion, what does modernizing without rip and replace actually mean in practice for a finance organization today?
Clout: Rita, I think it’s a common misconception that rip and replacing is about complete change and the only way to do with technology is transformation. I think transformation isn’t about changing everything, but rather taking on what you do really well today, setting the business up to leverage technology in the future and ensuring the quality of business outcomes are not compromised.
No longer can an organization wait for huge change. The systems need to be ready today to support your business and be able to be delivered in an efficient manner to support the business case and modern so that you don’t continue to inherit legacy debt, inefficiency and poor technology practices. Three things that to me are really important.
One, are we confident that the drivers are there for change? Trust the selection process you’ve undertaken. Now drive the outcome and the future adoption. Consider the vendor’s playbook. How do I orient myself to the new system? How do I ensure that I’m able to make informed decisions? The vendor walks you through so you understand it. Take the time to understand how it works and make sure that we’re aligned on how to deliver that ROI as effectively as possible. The third thing is really how do I ensure we adopt the as-is process? Can I run my business? Really, it’s about having the confidence that you chose the right solution, that it’s going to meet your needs today and then drive your future technology direction in incremental steps.
Garwood: You’ve mentioned that software vendors are increasingly expected to bring a playbook rather than just ask what do you want to a customer. Why is that shift happening now and what’s driving it?
Clout: I think whether you’re a small company, medium or an enterprise organization, you need to show success early. IT is not a one-and-done spend. It is continuous and the sooner you pay back the benefits, improve justification for ongoing spend, it’s far easier to continue to justify that spend. So there is an expectation that vendors have a sandbox or a playbook and don’t turn up with what do you want?
That mentality in terms of we can do everything, so what do you want? This doesn’t mean though that one size fits all and everyone is common, but there is an expectation that we bring a certain level of expertise to the table as we’ve done this many, many times before. This is the shift as lessors today want to adopt the product and rely on the expertise of the vendor rather than build from scratch and wait a long time for their investment payback.
Garwood: What are the real benefits of that MVP first best practices led approach for costs, for return on investment, risk and timeline?
Clout: I think firstly it’s the improved alignment up front and how the system works through that product orientation and training that’s done up front. I think then you shift to its delivery approach focused on adoption and challenging why a process needs to be done a certain way versus we’ve always done it this way. When it’s the third thing is probably when it’s clear how the system works, how you perform your business and what is required of you, it leads to greater success and better and improved outcomes.
For me these are the factors that provide for less cost for customization, less risk by not elongating the delivery and then earlier deployment into production. MVP for really providing that earlier return on your investment ensures the setup for your future investment and technology improvement is the foundation of what you’re doing and then longer-term benefits around the product and technology roadmaps with your partners.
Garwood: Let’s talk about customers for a minute. Odessa works across banks, independents and captives and equipment finance. Does the modernization conversation look different depending on which type of segment the client is in?
Clout: Yes, it’s actually a good question because I think without a doubt, even more importantly, two captives can look different depending on their size, their asset class, the customers and how they go to market. For example, those with a direct selling model don’t need originations for external parties, whereas companies with dealers, brokers and or introducers consider origination an important part of their technology ecosystem.
We find banks have a very large ecosystem to consider, so it can be complex in terms of integration, and there is actually an appetite to own enablement of a product through the configuration or what I call extensibility. Additionally, then you have captives, and captives in equipment will depend on the size and asset class. You’ve got IT captives that want integration with their asset catalogs and also have centralized systems to process things.
They are very focused on global implementations, and that’s become a bit of a common phenomenon over the last five to ten years, and they look for standardization across their decisions and platforms to really drive efficiency, a common process, and de-risk their overall technology landscape. And then I think you’ve got the third aspect, which is the independents that have a lot more autonomy. They own the decisions locally, and in some cases, especially with the smaller ones or SMBs, the requirements are far simpler. I think in short I’d probably say no two implementations are the same, although ultimately their objectives in terms of benefits, business case, and what the businesses are doing are very, very similar.
Garwood: I always feel like having examples really illustrates a point a lot better. Can you walk us through an example without naming names if that’s needed of a client who had to stand up a new capability quickly with limited risk and investment, and what did that look like end-to-end?
Clout: It’s a great question. This is actually a multinational IT captive client who’s well established in the marketplace, does traditional financing, but they wanted to introduce a new device as a service business. The buzzword of the last five years around pay-per-use or everything as a service. They wanted to introduce a device as a service business that included infrastructure as a service, managed service, and then device as a service, and they wanted to do that globally.
The key thing for them was they needed to determine really, really quickly whether the business was viable and then could be standardized globally. They chose a market that was relatively new to them, so limited impact, but they were very, very clear on the objectives and what they wanted to achieve because it was a new product operating to market. They wanted a short go live based on a MVP or a minimum viable product.
They wanted to prove the product capabilities and then they wanted to provide demonstrable software that could support business growth plans. The first phase they actually chose Australia. You can probably tell from my accent, it’s where I’m based, or was based. They wanted to introduce one product, limited integration, no originations, and really contract management capabilities to prove out the support of that business within a four month time frame. No customers, green fields, limited internal complexity. We’re able to deliver that really successfully in under four months. They were able to write their first deal within a four month time frame, which to be honest was the foundation for getting something in really quickly — that MVP approach — and then really looking at how to set the business up for success moving forward.
Garwood: That project reportedly scaled to 32 countries after starting as a standalone rollout. How did you structure it so growth could happen in phases rather than one big bang rollout?
Clout: It was really a successful program. I think the other phases were built on that initial standalone implementation. It expanded into an integration layer, which is commonly known as Kafka, which took into consideration their CRM capabilities, accounting, taxes, payment processing, more broadly across the organization. And then we also looked at how could we extend the capability or functionality across the ecosystem.
We looked at extending into originations, performing credit, helping them with the end of term, more structured details, and then additional services. Really it was the pilot country expanding to other countries, and we phased in over a two-year period, a total of 32 countries. They adopted the same workflow.
They worked with the legislative capabilities and used configuration to enable those capabilities. But ultimately it was more about aligning the business objectives with the technology that are using across the ecosystem, and then basically driving both the business and technology alignment in incremental steps. I think what really made it extremely successful was the fact that we had a single software package that could support a single instance of their configuration, which took into consideration standardized configuration globally, local processing, but more importantly that data sovereignty and data segregation, which is becoming increasingly important. With the Odessa solution we’re able to deploy a single software application across the globe, or into 32 different countries, respecting that data sovereignty, data segregation, which meant that they could have the data privacy, they met legislative requirements, but then also they could actually do real-time processing. I think it’s a combination of both technology, business drivers, aligning with those, and then really understanding what’s important from both a business point of view, technology point of view, and then driving equal benefits across the program.
Garwood: That makes sense. I’ve heard you talk about enablement as a depth of capability plus configurability. Can you unpack what that means for a client who might be evaluating a platform?
Clout: I think it’s not a new concept, and people out in the industry like a Salesforce, for example, have been doing this for a long time. Too often, our industry legacy platforms have always resulted in the path to development or vendor-led configuration customizations being the default. A product-based company should be focused on how we enable capability and configuration or extent — what I call extensibility. It shouldn’t be about consulting or development revenue. It should be about what’s the right thing for the industry and our partners.
When I talk about capability, it’s today — like when we consider today’s business drivers, and they’re going to change tomorrow, and if we’ve learned anything over the last five to ten years, they’re going to change even more rapidly. In the SaaS world, why shouldn’t we be able to introduce a new product? In this pay-per-use type product world, why shouldn’t we be able to introduce that quickly, or why shouldn’t we be able to leverage your partners remarketing module, for example. Odessa provides capability in terms of depth and breadth, which clients can leverage — what they need today but also expand into what they need tomorrow. When I talk about capability, it’s that richness, it’s the depth, it’s the broader capability beyond just what you do today.
And then when I talk about configurations, it’s in terms of enabling the user base to drive new workflows, new fields, new fees, new programs, and new products. Really, why should you be limited by what your vendor wait times are, the costs, when you can really control it yourself. We focus on the business configurability, but also what I call extensibility. Configurability is where the business user, or IT user, or the system expert can do the configuration themselves, with the required security, of course. But then expense extensibility is more comparable to where you want to take control that customization journey. We deliver a product, and then you want to be able to customize around it. It’s not for everyone, but certainly some organizations have the appetite to do that, and it is set up to be able to do that. To me, if you really have rich capability and you’re willing to work with the partners who can own the configuration and extensibility, then you not only choose a platform for your requirements today, but you’re future proofing it for your business wants to go in the future.
Garwood: How do pre-configured workflows and baseline sandbox environments give a client room to grow without re-architecting later?
Clout: This is an interesting one because it always takes continuous investment. You need to ensure that you maintain it. You need to make sure that there’s automated testing wrapped around it so it continually works. But really the systems today are designed for change. The configurability is not a set it today and forget it. But rather they’re designed to be extended, changed or added to.
This is important because historically without the configuration you’re always fixed to making heavy customization investments and you didn’t have control in your own hands. I think taking that baseline now gets you up and running really quickly. As your business changes you can then drive improvements and drive that around the growth elements that you want within your business. I think with more efficient workflows where people can be diverted to value-added functions rather than checking the work of others, you’re able to eliminate work and focus on the value-add. You then have the ability to add new products, use programs to drive data entry efficiency. Ultimately that means that you’re able to drive an improved service.
It’s driving higher levels of customer satisfaction. It’s adding or expanding these through configuration that’s going to drive your retention growth and efficiency. I think the key is really adoption gets you up and running really quickly. You can then review it where change is required or necessary. But then you can consider where it’s going to have the greatest impact on your business, and you can focus on expanding that through configuration and then those add-ons, as opposed to having to go back to the client for that customization side of things.
Garwood: That’s good. I want to shift the conversation to something that you hear a lot when anyone is talking about new technology implementations, and that’s that they usually take a lot longer than planned. What are the usual culprits? Is it scope creep, unknowns, migration complexity? What do you see that makes it take longer than expected?
Clout: It’s funny you mentioned the common ones. You mentioned scope creep, the unknown elements and migration complexity. I think they’re all really valid in their own right. Having done this for almost 30 or over 30 years now, I really think the biggest culprit is expecting important solution or project decisions prior to even knowing the platform you’re actually about to implement.
I think those decisions that you make early lead to scope increases, rework, lack of migration readiness and often delays the project. We’ve really focused on implementing a 10 to 13 week program that’s based on a sandbox that takes you through how the Odessa platform runs your business. It’s built around knowledge transfer on the business process and what to expect and then how your business will work on Odessa. It uses use cases that are focused on four to five specific areas that cover off the entire end to end user journey. It’s really the process itself is targeted on fleshing out scope early, minimising those unknowns and making sure that migration readiness is being able to be driven moving forward. I think the key is really focused on moving away from those traditional risks and longer projects, but really trying to focus on what can you do up front to mitigate that longer term exposure to those scope creep unknowns and migration complexity.
Garwood: You mentioned the 13 week program that’s built around the end to end use cases and sandbox orientation. Can you just elaborate a little bit more about how that helps clients avoid the costly rework and late stage surprises?
Clout: I think the program really orients them on how they’ll operate their business across originations, across contract funding and booking, servicing, accounting and tax, and then the end of term remarketing and termination processes. It gives you the full exposure to the end to end process.
It then trains the team on how the solution will actually work for them. It then enables them to make informed decisions, whether that be around internal change management, whether that be around solutions that they need — decisions around solutions they need to make — and actually more importantly it’s around will that process actually work for them in the business. The key other thing that it does is it ensures all parties are aligned in terms of what is the system capable of, how the business will transform, and then align on scope. It’ll help flesh out any additional gaps and then also decide in terms of does the migration make sense and when does it make sense to engage around a migration. I think having a common terminology, common baseline, and then aligned expectations will really limit the surprises in the project, and that’s why I think that 13-week program is really, really important.
Garwood: I want to shift to implementation strategy for a moment. When it comes to implementation approach, what is the trade-off between a big bang migration and a phase strategy?
Clout: I think there’s always a trade-off, for me there’s a few key points. The first one is you don’t get everything on day one, which means you may have some sort of short-term operational inefficiency, but there are strategies that you can use to mitigate these. For me, for example, the customer service team will need to determine how they access a customer record, which can normally be identified reasonably easily through a customer number or a name, but the default position means that you can have some inefficiencies because you don’t know exactly which system the data resides in, so you could potentially be searching out two different systems.
Another example could be new business for an existing client. All details may already be on that existing platform, so that could result in the same client having two different contracts, but one on your legacy tech and then the new contract on a new platform. Again, I think it’s resolvable as the new contract could actually drive a migration of that old contract data onto the new platform at the point the new contract is actually created, which would result in an incremental migration.
I do think that the benefits in terms of technology risk quite often are outweighed by these inefficiencies for a short term and support the broader investment being made. The key thing you want to see is an early return on that investment, so getting it up and running, proving it out, reducing your risk, I think is far more beneficial in terms of the trade-off against waiting for that big bang, for example, where you might not get the same results and you gotta wait a lot longer to get those results.
Garwood: What operational or staffing considerations come into play when a client is running old and new platforms in parallel?
Clout: I think it’s pretty easy for us all to look at things in the obvious terms, and that is two systems, two processes, interim additional headcount. I personally would argue that it’s the easy view, potentially short-sighted, as sticking with what you do today could be far worse in terms of keeping staff, sticking with the same poor processes and the operational risk of some of these legacy platforms.
Interestingly, we recently published an article in conjunction with Monitor called When Your Leaders Cover an Almost Ready Platform, which really focuses on the hidden costs associated with your tech stack not really being ready. The reality is, in my view, the inefficiencies already exist in terms of leaders performing workarounds not focused on value-add activities and living with your current outdated platform.
For me the question becomes will the impact of those lead to further risks or fines, staff retention issues, and hold you back in terms of technology direction. Everyone’s talking about AI, being able to add new products, really long backlogs. I think more often than not, when you weigh out the cost of the FTE on your existing platform, the short-term strategic impact is probably negated and can be negated in a very short time.
Garwood: You mentioned AI. AI comes up in almost every modernization conversation now and almost every conversation, I feel like. How does Odessa think about applying AI to real immediate use cases rather than chasing the art of the possible?
Clout: I don’t know whether it’s an interesting question anymore, because as you said everyone’s talking about it, every event we go to it certainly comes up and there’s a lot of experts around it. I think personally we think of AI as it’s really important, and it’s certainly important, but the little wins we have found to probably be the most beneficial today. For example, the use of AI to drive workflow efficiencies, using the data that you have to actually inform the users through what we call intelligent summarization or prompt on your next actions, using AI to drive simplification in terms of providing information at your fingertips to better serve your clients. Interaction with agentic AI to drive process improvement. An example of that would be prompting steps in a particular workflow or a restructure workflow rather than having to manually do every step. Eliminating the potential of making mistakes, being intelligently prompted through what are the next steps, and really taking that guesswork out of the process.
I think now we found that the big AI drivers, like developing a new application, training the models, and even things like invoicing processes, take a lot longer to implement, test, and then retrain, than looking at some of those simple process changes that provide immediate value, differentiate your business, and make your user experience much more efficient. I think it’s a great example of really focusing on those small things, doing it fast and delivering, versus overcomplicating the initiative and guessing at the results. I think it’s fail fast, or try and succeed, and then, rather than wait for those long-term investments, hoping and praying they pay off.
Garwood: That’s good advice. We are approaching the end of our time here. I’ve got one final question for you. If a finance organization is just starting to think about modernization, what is the one mindset shift that you would want them to walk away with?
Clout: I don’t know it’s a mindset shift, but I think you really need to prepare for the journey. You need to be informed, you need to be comfortable with the organization, technology, and really ensure that it’s going to be able to drive the benefits that you’re looking for. From the experience I’ve had, I think the best journeys and partnerships are those that you’re really aligned on the benefits you’re trying to achieve, the direction that you’re heading in, and what it’s going to take to be successful.
I think Odessa is now focused on providing support to drive on that your business case, reduce your implementation risk, and then longer term through the investment that we’re putting back in our platform, making sure that our partners get real roadmap benefits. It’s not because you’ve paid for something but because the partnership is coming with mutual benefits to both organizations. For me, I guess the shift would be more to making sure the partners are equally vested in that mutual improvement in terms of modernization, technology, and then share that interest in your industry and your people. It’s probably the shift in terms of how I think everyone should be thinking about technology and modernization in their organization.
Garwood: Thank you so much, Campbell, for being on the podcast today and sharing all of your knowledge with us. It’s been great talking with you.
Clout: Thanks, Rita, likewise.
