233. Finance Transformation Live - Future Proofing your Finance Software Architecture

Introduction and Objectives 

Hello everybody, and welcome to this episode of financial transformation live. So today, we're going to talk about some things that you can do to build a future proof finance architecture. So, I'm very aware that at the moment, with all of the changes in technology, it can be incredibly hard to decide where to go. You're worried about making sure that whatever you're doing is not just going to last you 12 months, it's going to last you a few years, and that you're setting your organisation up for success in the future. So I'm going to talk about things that you can think about with your existing systems, how to think about the layers within your finance architecture, but also what sort of things should you be looking for in the products, the modules that you're buying, the different technologies that you're buying, in order to make sure that They are have the very best chance of being okay for you, and not just now in the next four months, but also a few years ahead as well. So, what are we going to cover? So, we are going to cover the components of strong financial systems, architecture, common mistakes and risks that you need to consider. Doesn't mean you can't do them. You just need to think about them, the different layers you might want to think about in your longer-term strategy. And of course, any questions that you may have as we go through this. So for those of you who don't know me, I am Managing Director and Head of transformation itas, and I've been working within the technology space for probably longer than I want to admit over 15 years, but I'm very much focused on not just the technology, but I genuinely, you know, all of the things that go around making a technology implementation successful. So, we're known as well. We were awarded Customer Success Partner of the Year from Sage. So, we've got a reputation and evidence base of making sure that people helping people make good transformation decisions.  

Components of Strong Financial Systems Architecture 

So last session that we did was all about record to report. So, what does that maturity model look like? And that was with Neil, who looks after our delivery team, and he took you through some of the things to think about there. And so, we are going to start with the components of strong financial system architecture. So, I think about it in four areas. So well, you got to think about your data architecture. So, when you're looking at finance systems, and when I say about finance systems, I'm thinking about all of the components that make up your system, you've got to, you got to think about your data architecture and how that supports it. You do need to think about API integration, and there's lots of reasons for that which I'll get into. Expandability, how can this system flex and help you become an agile finance team, and what's the maintenance component of the system that you're looking at? So therefore, things that you need to think about when you're thinking about your finance system.  

Data Architecture 

So, let's dig into the first one, which is data architecture. So, the reason this is important, there's two reasons, right? One is obviously one of the key reasons that people need a good finance system is for reporting. If your data architecture isn't strong enough, then you're going to have challenges getting out the report, and you need, you know, let's just take away the formats and how they look, but fundamentally being able to report on that information. The second piece is that as new tools develop, particularly in the AI space, they need access to data to be able to support you with things like forecasts and modelling and things so making sure that you have a really strong data architecture is the foundation of be building a future proofed financial architecture. So, I'm my key tenant is that it's got to be multi-dimensional. So, what that means is that when you're working with your ledgers, so you need to be able to analyse not just by just by customer. In the sales size you need to be analysed by product and those items you need more. You need layers, both within you within your ledgers, but also within your nominal so that's my that's my key sort of baseline, if I'm thinking about a future proof dark. Architecture. The second thing you need to consider is based once you've built what you know, once you so you might have those that ability to have a multi-dimensional architecture, but how easy is it to create different groupings based on that? So thinking about, you know, the sorts of things that you think about is, can I add fields to each of the objects that sit within it, and then I can expand it, or am I limited to the pre-built fields within that? So having a flexible, multi-dimensional financial data architecture is really important as you go forwards. And it's not just about your core finance platform. It's also about the modules that sit around it. So, you may have an AP tool, an AR tool, you may have payroll tool. How you know how shared is that data architecture across platforms, and how consistent is it? How well defined is it? So do you have data dictionaries within your team. So, you'll notice some of these things are not technology, but also but about things that you can do as a team to make your systems more robust, so you could establish data dictionaries. So, what's the definition of a customer? What's an invoice, etc? What does a particular field mean, maybe you're What does a department mean across different systems? What does a project mean, etc, and what you need to make sure is that that data that you're putting into your financial systems is going into established fields versus free text. So rather than going into comment lines or free text fields, you know, where you're doing some weird and wonderful coding. You know, I've seen all sorts over the years. I've seen people, you know, have the description fields and they type in manually, the invoice number, then put a colon, etc. But all of that leaves you very open to data entry errors and consistency errors. So, you want to be working with established fields. So, you're what you're looking to make sure is you're making use of the ability to add custom fields within your different systems, and not just relying on that free text entry and try to work within the system's intended structure. 

Avoiding Overcomplication and Foresight in System Design 

This fudging it right? So, I've seen a lot of and it kind of ties into next point. I've seen a lot of very complex Chart of Accounts, setups, reporting setups, where people have really tried to push the boundaries of the systems, data architecture and that is fine if you're filling a short-term gap. So, you know you're moving systems in the next 12 months or in the next 18 months, right? And you just need to fill the gap to deliver reporting for the business that is not a future proofed data strategy, because there is there, you're going to hit challenges later on. So, this is what this conversation is all about. It's about thinking about, how do I make good decisions now, so that I don't have to make another decision and go through a world of data migration and pain in two years’ time? So do not it, unless you it is you are all agreed it's a short-term strategy. Do not build overly complex structures. So, a really classic example of this I've seen is people using their chart of accounts nominal structure, like the departments in it for projects. And the challenge with that is the projects in most businesses maybe last a year, year or two, Max. And so you then end up building out this really big chart of accounts that at some point in the future is going to become unwieldy because you're putting so many projects through, and then it makes it harder to find you run out of coding all those kind of maintenance and, you know, scalability challenges. So, so again, it's a short-term gap. You, you, you, if you're going to do that, you do it in the knowledge that you might have to undo it, and you're going to have more data mapping when you migrate to a new system. So, if you can get ahead of that, it's really good to do so, and that's the key thing you want to think about. If the business grows or changes are our system in a position to grow with it. If you are hitting the limits of your system now and you're looking to grow, you need to act fast, because you don't want to be in a position where you're behind the curve with finance systems, because it's a lot harder. You need to get ahead of the transition. And when you're thinking about your data architecture, some things you need to think about is, you know, can I get access to dashboards and reports to assess things like completeness and accuracy? Because, again, as you're going into this AI era, it's all going to be about data so and so that data needs to be clearly defined. It needs to be consistently populated. If you've got loads of gaps where you know, for instance, maybe people are putting. Postcode into the address three line and things like, you know, small things at this point, but then when you want to use that data for some analysis, it's not there. So really, thinking about the quality of your data as well as, you know, as well as the breadth of your data and how well integrated it is so important. And do think about data lifetime and volumes again. So, assess each system to say, if we doubled in size and we put double the amounts of data in every month, would this system be able to cope easily? And, you know, after a few years, would it start to hit some slowness issues and things like that? So, thinking about those and don't hard code permissions and validations. And you'll see this a lot I talk about not you don't want to do anything. You don't want to make design decisions around permissions, around workflows, around data architecture that at some point you can't undo. So when you're looking at systems, you're not just looking for like, if it will, it suit my exact requirements right now, what you want to say is, well, if those requirements change, how easy is it for me to change that structure and do things differently? Again, these are all the things if we want a future proof system we need to think about and a lot of people focus on the here and now and what they want now, and they make decisions based on what they have in front of them. And the reality is, is that we're living in a world where technology is changing, business is changing, and almost agility is probably it was sometimes more important than anything when it comes to choosing technology systems. How well can the system grow, adapt, scale up, scale down, to suit my requirements?  

Importance of APIs 

Okay, so that's a little bit about thinking about data, architecture of the systems and the landscape that you're looking at. Now let's move on to API. So why is API so important? So APIs, again, I'm sorry for those of you that know what an API is, but it's basically, think of it like a translation box that sits outside of your finance system and allows you to pass data through into that system and it should be upgrade proof. So, when you because it's using, because it's going through that translation box, when they do new features and functionality, it's using standard objects that the developers have exposed. So, it should, it should be strong. So, when you're looking at systems, the first question you've got is, does it have an API? If it doesn't have an API, being very transparent and honest, you need to seriously consider whether that's a good investment. So, your question around APIs, it should be the first question you ask when it comes to systems, because you never know what you need to integrate and you're you might need tools not just to push data in. You might need tools to push data out. So, the second question is, how robust are those APIs? And this is a really difficult question to get a good answer to, but some of the ways that you can spot a good API is, can it handle volume? So, what's the highest volume of a particular object that customers are pushing through data into, you know, can, can the API handle volume? Are there any limits to the volumes that it can handle? Um, there might be a chargeable limit, which is good to know, and you should ask that question. But there might also be a technical limit in that it can only handle up to, I don't know, 2000 transactions a month, or something like that. So, because you need to know that whatever you're looking at can scale, and you need to make sure that the breadth of the API, so what you need to ask them is things like, Well, what objects don't exist in the API? So, when I put my finance data into system. When I put my fixed assets, I put my customers. Are there any objects that I can't get out? How can I see what objects are available to connect to? Objects are like your data. So normally, a customer record is an object, an invoice, sales invoices are an object. An AP invoice is an object, for instance, and they will have lines underneath that. So, you know, and I you need to get comfortable understanding data architecture and finance. I think, you know, we understand the outputs, we understand the debits and credits, but we need to really understand data architecture and how data connects together. Because, you know, reporting is a key part of our role. So thinking about the robustness, so the volumes, it can handle the objects that are available, obviously security, where it's become big, bigger and bigger over the last few, I'd say, few months, actually, with all the things that have been happening, but making sure that you've made. You've made sure that they're following good security principles. They've got things like, you know, the standard sort of ISO accreditations from a, you know, net from an API perspective, or software perspective, is really important. And really important is good documentation. So, if you know, you should be able to go in and see that there's a decent amount of documentation and not just about the current API, but what happens when there's upgrade? Is there a developer notes or something to show you what's changed when, when the system's been upgraded and things like that. And another really good sign of a good API is that there's an ecosystem and a marketplace around it. So, you do wherever possible, you need to minimise risk. And part of minimising that risk is not having a single vendor. And that goes against lots of the I would say that the sort of the historical thinking, the traditional way of thinking, certainly sort of 10 years ago, was that you wanted an ERP. You wanted one vendor that does everything. The challenge with that is that what that does is that leaves you tied to that vendor, their roadmap and their development and their technology, and so you know that you don't have the opportunity to maybe swap different parts of the system in and out, and we'll talk about this in a minute, but having an ecosystem of non-vendor apps and integrations is a really good sign that one, that products well established, but two, it can connect easily to others, right? And so, talking to the vendors that you already work with and see, you know, and saying, you know, if you wanted to connect this, how easy would it be? You know, could you do this? Would you be willing to is a really good sign of whether something's well established and, and I think, you know, a lot of people say, well, we've got integration. And I think one of the key challenges that you should have for any bench you work with is making sure that they have API based integration.  

API Integrity and Ecosystem Considerations 

What I've seen recently is a few people try, and I won't say hide, but kind of talk about their integration as being, you know, API based when one side of the integration is API, so they're just pulling data out, putting it in, like an FTP file and falling into another one. So it's part of what we do is we work with multiple partners and vendors, and you know, we have to go and assess how those integrations work as part of the recommendations that we make, and that's one of the things I'm always really cautious on. So making sure you've got an API to API integration, and you understand how they integrate, what data objects for all of the systems that you're working with is really important and that kind of gives you, it's not going to completely de risk, but it's going to de risk a lot of your future, future projects, because maybe there's a great new piece of technology that comes out that you want to take advantage of, because it works really well for your industry. Your industry. If it has an API, and if your current systems have APIs, then you have an ability to connect fairly simply and easily, right? I won't say, you know, it's, you know, sometimes there can be some development costs involved, or there might be a bit of middleware, if you are depending on your approach to integration, but fundamentally, it's doable. If you don't have APIs, you are limit. You're very limited in what you can do, and also, you're limited. You're it's high risk to integration if you're going into directly things like databases, yep. So, API is kind of de risk integration, because they make sure all of the data that's passed through is complete and follows that software's protocols and validation rules. Yeah, so you want to avoid direct database to database integrations where you know at all costs, and you need to be very careful when building and maintaining those so API integration is a key element and component of a successful finance architecture. One of the hardest things, I think, is actually putting into words what it means to work with myself and the team here at itas, because not only are we a financial transformation consultancy, but we do it using sage technology. So rather than me tell you how awesome we are, let me introduce one of our customers. 

Expandability and Modularity in Financial Systems 

Expandability. Now, I kind of dabbled in this a little bit earlier, so I'm kind of kind of from a different perspective. So, what we want in finance is systems that can grow with the business. So, as we maybe we purchase a new company, and those guys have a different kind of business model to us. How good, how well can the systems that we currently use expand to suit different workflows, different business models, etc. So, I look expandability in a couple of different ways, so I'm going to talk you through that now. So, expandability and you know, the kind of the bit that everyone thinks about is, will it cope with volumes and scale? Can I add 100 users, and the system will still function right? Maybe not 100 users in finance, because I'm hoping we're a little bit more automated than that. But can we add, you know, a significant number of different types of users, and will that impact the speed and or robustness of my system? The second question is, modular. Modular. So, does the systems that I'm using have the ability to turn on I don't maybe project accounting or inventory, or are there additional reporting capabilities? You know, can I sort of turn on different elements depending on what the needs of my business are? You do want a base level of capability within your finance system, but especially if you've got a good underlying data architecture and you've got API integrations, it allows you to make choices about what system to use. So, you might go off and use a separate CRM because you need your B to B versus B to C, and you need a different type of operation model. It might be that you decide to start a subscription, change your business model to subscription, and you need a contracts module. We need, you know, some you know, so just it's how easy it is to turn on different components. And a lot of people say, well, don't you just want one system that has everything and that, you know, very often, you know, there's a cost impact to this, this way of thinking. But my general rule, and the way I think about it, is, I don't want to pay for stuff I'm not using. So, if I'm paying for a system to have everything, then the reality is, I'm probably paying for things I'm not using. And if you know, and then you have to ask the question is, well, what if I need some functionality that isn't in my existing system? Does that mean I have to change out my entire system to meet a particular requirement? So, this is where I really focus on non-primary vendor integrations and the marketplace. So, for example, when I say primary vendor, so you should, you know, obviously got your core ERP, but can I swap out my AP solution or my credit control capabilities? Can I add that on? I might want to add a layer on of, you know, I'm going to IPO, and I want to add in some compliance layers and things like that to really build the robustness of my and speed of my reporting. So really thinking about, how can my business scale, you know, as in, how can my system scale with me? And am I reliant on that primary vendor, my core ERP, doing all of the work and having the same view on what their system does, as I have of what they should do. And that's where I think APIs really come into play, because they support you going out and choosing different layers to your architecture, and they allow you to maybe swap out your AP solution. So maybe you start with something that's quite cheap, just because you don't, you don't have a lot of complexity, and then when you hit a certain level of business, or there's maybe, or there's a new there's a particular solution that has an AI capability that you want to take advantage of, you can just swap that part out.  

Tailorability and Future Readiness 

So again, this is where flexibility, agility and expandability, all the ilities, come into play, and things like tailor ability. So, what do I mean by that? So, I I'll talk about this in a little bit, but I don't believe in having a heavy development burden to maintain and manage. Right? So, what's this? What a good core system does is allow you to tweak your work. Those and put in various checks and balances but be able to change them. Yeah, so you should have a system that, if you want, again, if you want a future proofed system that's going to last for, you know, five years rather than 12 months. You need to have a system that can, can be tweaked to suit the changes in your environment, as in your internal environment, also your external and I think we're, we're about to go into period of big change, um, you know, both, I think, in terms of the business landscape and how we operate, but also the technology landscape. So, making sure you're geared up to take advantage of that is going to set your business up for success, and, you know, and could potentially ensure that you have a more robust business moving forwards. 

Maintenance Considerations 

And maintenance. Okay? So, a lot of people focus on the, you know, how do I get live? They don't think enough about what happens after I go live. So, sorts of things you need to think about is Okay, so what's the release cycle for my all of the apps that I work with? Is it quarterly? Is it annually? Is it two yearly? And a really good way to assess the quality of investment into a product is to look at the last couple of release cycles. What content was in there? What did they release? What you know, what do they deliver? And that will give you a good idea of what it is. You know, how invested that that part you know, that developer is to their software, the ease of upgrade process. So, is it a system down to get upgrades? Does it just automatically roll? What does that look like? Is there a sandbox environment and you need to heavily challenge custom depth, right? So, when you're in a you know, and again, this is less about Yes. So, this both with existing suppliers and with, you know, potential new solutions you're looking at, if they say you give them something to come back and say, yes, we can, but that would be custom. You need to understand if that is fully bespoke codes and screens, or is that a tweak to a setting, or, you know, a little bit of script that goes into an existing screen. Because custom development at different levels adds a think of it like a weight, like a challenge, for every upgrade. Because not only do you mind you do you need to, may need to maintain that custom dev but you will need to maintain it for each new upgrade. So, if it slows down your ability to upgrade, or it adds more of a challenge, or it means that you can't take advantage of new features. It's going to make you less agile, and it's going to cost you more. So be really careful about what dev that you go for, like things like report, you know, custom reports, and, you know, putting in, like a validation, well, that that should be pretty standard. What I'm talking about is, like, big bits of custom development, you know, fundamentally, like new screens that are completely rewritten, or, you know, entire I've had some people have decided they, you know, come to us and they've got, you know, entire programmes. And I'm like, the problem with that is, you're tied into the developer that's built that for you, as well as diversion that they built it on. So, thinking through and understanding the upgrade path, if you do those kinds of things, is really important. You know, do they have existing AI capabilities right at this stage? They should at least have something that they can show you. They should have some kind of AI capability that is in play, given, you know, if they're not, they're probably behind the curve. So, you know, looking at your existing providers and modules and going, you know is, is there just some element of AI, and what are the use cases of AI that you are building to? And asking that question, both of your existing providers and also new ones. Ask, you know, what's the security policies? How easy is it to change permissions? Because, as a small, small business, when you're in the finance team, maybe you're, you know, there's only two of you in a finance team at the moment, but if you have a business is looking to grow, there might be five or six, so, you know, and you might want to give access to data to different individuals, so how easy it is to change what people can see and what they can do within the system, and what are things like backups? What's the protocols around things like that as well? And I class this under maintenance, but there's two things I think are really important, regardless of what platforms you're on is to build the knowledge of your data architecture and your systems into your team. You know, you should be, you know, should be making sure your team are setting aside time to explore your systems. Because I, you know, and I because that's how you get value from them. You can obviously have a really great part. Partner, as you know, as a sage partner, you know, we look at what we do, and we make sure we try to educate our existing customers, and we make sure we can obviously come back and answer questions, but fundamentally building the knowledge within your team about your systems, your architecture, your data allows you to take advantage of the capabilities of that system. You're more likely to be using the systems more fully then. Then if you, you know, rely completely on your partner, yeah, and you know, there are some instances where, if you need things like high turnover, I completely understand that in that case, you will have to rely heavily, but obviously you need to address that underlying issue, and then look at how you can build education and something and making sure that when you're costing out a system, whether it's an existing system or, you know, you're looking to use improvements, make sure you put some budget aside for training and development of your staff in that system's capabilities. You know, have you well established processes and procedures documented on how it works when a new release comes out? Do you, does your team sit down and review how they can take advantage of that? I've, I've seen that a lot. It's like, you know, they've been, you know, people have been through, they've had a couple of upgrades, and they haven't really, they don't really, haven't paid attention to what's coming out in these upgrades and how they can take advantage of it. 

Layers of a Financial Systems Architecture 

So making sure you've got an established, ongoing system improvement process and team so people that are responsible for looking at the new releases, you know, embedding the change, and building that culture of continuous improvement will help you get more out of your existing systems. But it should be a question that you're asking with your if you're going in for new systems, right? So, this, all of this, should apply to both existing and new systems. So, you should be thinking about these things when building out your architecture. And I talk about architecture. So, some of the things that I think people tend to think, they just think that an ERP is an ERP, right? I like to think in ERPs and finite systems in layers. So, give you some examples. I just thought I'd give you some examples of layers that you might want to consider. So, your core is always first, right? I've seen a lot of people jump to stick a really great FP and a and planning tool on top of something small, like zero or sage 50, and you will go so far, but you will, you will hit problems at some point because the underlying data architecture. So, it doesn't matter how good that the top that layer is, if the base isn't strong, you can't do anything with it. So, getting your core right is your first point. Then you can layer on things like FP and a and planning tools, you know. And I put some examples in, you know, we work with some of these. We don't work with all of them, but they give you an example. And if, obviously, if obviously, if you've got any questions about specific ones, reach out, but you've got your FBA, your planning tool to do, budgeting, forecasting, modelling, your integration layers, so it that might be pulling data out into a data warehouse, it could be doing integration with different systems I talked about, yeah, should all be via API, but you can do it with different layers, and some examples of that. So, what you're what you're making sure, is that the data, all this data in all of your systems, is, you know, robust and being passed in real time. You might have analytics or Bi-level Tableau Power BI are pretty common ones. There are some others like and some of the tools on this do double up, like profits, for instance, like they all, they are double up. And some, some products will do multiple, multiple layers automation and RPA again, some of your integration tools can act as that AI and predictive insight this. This is a new sort of category it's developing. I like I put some names in there at this stage. I think this, this area is pretty, I would say is very much bleeding edge, not cutting edge. So be careful in this space. I always suggest that people get, you know, most people don't have the core in place yet, but focusing on, you know, sort of the AI features in your existing tools right now, before you put on an AR layer, is really important making sure that you've got the right ones there. Governance and controls. So very often, as companies scale up and they get bigger, they need another layer of month end, you know, controls and governance and risk management, audit readiness, etc. There's a couple of examples in there. We worked a couple of those. And then workflow, collaboration. So, all of these things, these layers, some systems will have them, right? So, you might have a system that goes. Across a couple of these layers, or does like part of these layers? Or you can pick purpose-built solutions to put on top of your core ERP or finance system, and that is what I mean by agility and adaptability. So having something that can act as a base and give you a basic level of capabilities, but also knowing that there's an integration that you could just tap on to take advantage of some FPA, because you're, you know, you've suddenly got funding from PE company, and they've got an M A strategy that you need to take advantage of. So, think of your system in layers and build. Get your building blocks at the base really strong. Get your data secure, make sure you've got good API and integration capabilities and build from there. 

Common Mistakes and Pitfalls 

So, common mistakes, things that I have seen, and this is just based on what I've seen. So, and it sounds obvious, right? Waiting till you're you need a system, a different system, or a different capability, before you actually make a decision, you need to start looking ahead. You know, we talked about, we talked generally about reporting and stop looking back and start looking for the same with technology and systems. Technology and systems now are an essential part of finance remit. Now, if you don't have the data and the systems that you need, you cannot perform well as a finance function, and you need to get ahead of it if you are implementing things at the point where you need them, you're probably you are behind the curve in reality, because it's going to, in most instances, it's going to take you three months to implement minimum, right? And that's assuming that you're not massively, you know, under capacity already. So, get ahead of what you're going to need, and always be three to six months ahead in terms of systems, as to what you want to be if you want to be a high performing finance team. Right? I completely understand that budgets are challenging and putting business cases together and getting the sign off, etc. But you, your, when, when the business comes to you says, I need this reporting. I need this analysis. We're about, you know, we're going into audit. We need we're going we're hitting our audit threshold. We need to do this if you are responding at the point that you have to deliver on those asks, and only then looking at systems, you are behind the curve. So, a lot of people. Other common things I've seen is when people try to get one system that does everything. And, you know, we work with systems. We work with sage, right? And, and, and I don't tend to say that sage has is EV is the right system for every single person, right? But what makes it able to adapt to the majority of organisations is because it's modular. We can turn certain things on. We have a, you know, a marketplace of partners that we can pull in depending on the size and scale of the business, and that, you know, not relying on a single vendor is really important right now, with the with the way that the market, the technology landscape is changing, so making sure that you have systems that play nicely with others is really important. High custom debt burden. We've actually had customers come to us and said, can you pick up our systems? And we've looked at them and gone, we can't, because you have so much custom depth, you know, because you've built yourself something that's so bespoke that to upgrade is going to take months, let alone, you know, to edit what you know, that's just to, you know, replicate what you've already got. So be very careful. And if you have, if you have a high custom dev setup, you need to start thinking about how you work your way out of that, and changing pieces at a time, and complex data architectures. We've talked about that before. We talked at the beginning, make sure you are not trying to fudge your data architecture. You're not trying to put, you know, do weird and wonderful things as a long-term solution with free text sales, etc, because you will end up, at some point coming unstuck. You know, you might need to edit something and it's not editable somebody. You know, there's a data keying error, and that could mean the difference between making a profit and your P and L or not. So being very careful about your data architecture, making sure you've got robust field level validations around what goes into fields and how it's formatted, etc, so that when you want to take advantage of good reporting tools you want to use AI, that your data structure is robust enough to support it dead end design path so making choices around how you configure your systems in a way that if you want to change things or take advantage of new features and capabilities later on, you can't so I call them dead end design paths, so making processes that you have no option but to work that way and you can't change it. And again, that normally ties into some custom dev Yeah. Um, people ignore data quality, right? So, they, they have, you know, have these systems, but they don't even think about, well, how well populated is our data? You know? How? You know, how well are we put data in the right fields when we're migrating systems and rushing data migration. So, yeah, think about data quality. Um, not digging deep enough on integration dependencies. So really making sure that your vendors that you're working with tell you how things integrate, what objects, what method are using API, if we've got pre built connectors, etc, getting into that is really important and underestimating change management and training needs for both new implementations and existing right? You should have regular contact with your current vendors. You should be speaking to them. I, I would, think, on at least a six-month basis, and talking about new features and capabilities in your plans if your team aren't doing that, or if they haven't had training on your system for a few years. You need to make sure that you are you've got budget for that, and you're investing in do they know what features we and capabilities this system has? Because you might end up paying for a new system when actually your existing system could deliver what you need because, but you just didn't know it could, because you've not stayed on top of its capabilities, right? We get into an argument about whose responsibility that is, right? And for me, it's a partnership between you and your software partners to make sure that you are being proactive, and they are being proactive to support you. So, making sure that you've got that you've given your team the best chance of success is really important.  

Closing Remarks and Call for Questions. 

Okay, so I hope that's been useful. Guys, a bit of a download based on some conversations I've had recently, and I've had some interesting asks for the podcast. So, we're going to try something different on the next FTL session. We're going to do an Ask me anything. Think of it like acne. Aren't for trans financial transformation, right? So, give me a challenge. You know, you can make it as broad or as specific as you like. Send it to me. Podcast, IT solutions, dot credit, UK or PM. Send me a message on LinkedIn with your ask, um, ask me anything. So what I'm going to do is pull out, you know, the questions and queries I get asked, and I'm going to walk it through, potentially going to try and grab one of my transformation guys in and we're going to and we're going to talk this through it together and give you answers to those queries. So, I don't mind if it's a people challenge, a process challenge, a technology challenge. It could be up the chain. It could be a challenge. You're trying to get your CFO on board. It could the wider business, whatever it is, send me your questions and your transformation challenges, and we're going to have a kind of a Q and A slash agony arm style FTL next time. So, I hope you've enjoyed this session, and you've got some value from it. As always, I like to give you guys some resources. So, we've got building out your finance data strategy. So, I've talked a lot about data, but there's way more in depth on that, on our bill, our previous FTL. Have a look at that sage database guide. I have one for sage, 200 and I've got a whole I've got one developing for some of the other sage products. So, if you're interested in that, send me a quick message. And for those that are using sage itself, so sage intact, and you're thinking, oh, how do I get more out of that? We've got a session on reporting tools and sage Intacct. So, you can take advantage of that as well. Awesome. Okay, well, thank you so much. My email is there, so whether that's podcast, or whether you PM, you send me an email directly with your questions for that next. FTL, would love to hear from you. I hope you've enjoyed that this session. If you have, please do leave me a review. You know, it helps me know that the content that we're producing is valuable. If you have any suggestions for improvements, perhaps the session wasn't as valuable. Some other ones tell me why. Like, I'm very much in a review and design of my next six months of content at the moment, so I'd love to hear from you, our listeners and get some feedback. So, there we go. So that's the answer this week. So, either leave a review or give me some feedback. I'd love to directly. I'd love to get some thoughts from you. Thanks again for listening, and we'll see you next time on financial transformation live.