CFO 4.0 - The Future of Finance

245. Financial Transformation Live: Transformation Trouble-shooters September Special

• Hannah Munro

Share episode

Send us your thoughts

In this episode of Financial Transformation Live, Hannah Munro and Neil Lynchehaun tackle real-world transformation challenges submitted by finance leaders. Together, they share practical advice, frameworks, and lessons learned from years of hands-on transformation and consulting experience.

💡 Topics covered in this session include:

  • Rethinking requirements gathering – moving away from 1,000-line requirement lists and focusing on outcomes, use cases, and best practices instead of replicating
  • System selection approaches – how to frame your needs, engage vendors effectively, and avoid box-ticking RFP traps.
  • Data migration dilemmas – when to clean data before Go Live, strategies for managing messy supplier and transactional records, and the risks of “garbage in, garbage out.”
  • Simplify before you automate – why tackling root causes and streamlining processes is often more valuable than layering automation on top of inefficiency.
  • Dealing with change fatigue – overcoming eye-rolling resistance to yet another project by contextualising benefits for teams, linking change to day-to-day roles, and building compelling outcomes.
  • Practical controls and safeguards – validation techniques, duplicate supplier detection, and post-implementation clean-up strategies.

Links mentioned:

Speaker 1:

Welcome to CFO 4.0, the future of finance. The CFO role is changing rapidly, moving from cost controller to strategic visionary, and with every change comes opportunity. We are here to help you take advantage of this transition to win at work, drive your career forwards and lead with confidence. To win at work, drive your career forwards and lead with confidence. Join Hannah Munro, managing Director of ITAS, a financial transformation consultancy, as she interviews key experts to give you real-world advice and guidance on how to transform your processes, people and data. Welcome to CFO 4.0, the future of finance.

Speaker 2:

Hello everybody and welcome to this episode of CFO 4.0 and, of course, our financial transformation live component. So today we are it's our transformation troubleshooter, and this is one of my favorite sessions because Neil and I get to talk what we would do. And I love working with Neil on these kind of things because, for those who don't know, neil is our head of delivery and transformation. So he is ex big four, ex transformation consultant and we are going to talk through I guess you know situations that I've been asked about, but to give you guys some options for how you can deal with them. So so we've got a series of snapshots and some some of them have been reworded, so to hide identities, I will just add that in and some of them were also part of longer conversations, so I've just taken a snippet with context.

Speaker 2:

So we are going to work through a series of questions and scenarios just to give you guys some advice on how we would approach implementation. And so, again, I'm going to skip over the introduction a little bit, because if you're a regular to Financial Transformation Live, I really hope that you know that I am a managing director at ITAS and that we're a financial transformation consultancy that works with Sage Technologies, but also really proud to be Sage's Customer Success Partner of the Year, and we've won a number of other awards as well. But that's enough of the bragging about ITAS, let's move on. I mentioned, obviously, neil's experience at Big Four, but he's also done some work leading global financial services and has experience not just in traditional sort of consulting roles but also around a lean transformation operational senior leadership as well, so he's always a great person to run scenarios by. We get sometimes very similar answers from you and I, neil, but sometimes a little bit different as well.

Speaker 2:

So let's move swiftly on to the first. Oh, before I do that sorry, meg has put in a slide to remind me, for those of you that missed last session planning a successful project, I took you through things to think about pre-implementation, um, and how to get the most out of your project, how to de-risk it, etc. So that is now available on demand, um, and that's here we go. Great, we can move swiftly on to the content for today's session because, um, for once, I've set myself a target that we are going to try and finish within the the agreed time frames. But we'll see how we go, because me and me and neil can talk a lot on the best of days, so we'll see how this one, this, this, plays through. So, of course, if you are listening to this live, please do ask. If you've got any questions, any commentary, um, any additional scenarios that you want to consider us to consider, either as part of this session or in future ones, and we'd love to hear it. Um, and I will keep an eye on the messaging stream, um, for those um that are joining us live, and if you have questions afterwards as part of the podcast, please don't hesitate to reach out to me on LinkedIn.

Speaker 2:

A lot of the material I get for these sessions is based on asks that I get, and it's a really good way for me to not only get inspiration but hopefully help a few people along the journey as well. So our first scenario, neil, for us to talk about. Hi, hannah, we've just started looking at new systems, and conversation has already gone down the path of documenting thousands of requirements. Honestly, it just feels like busy work. Is there a simpler way to get to the right choice without writing a novel? Oh so, um, very cognizant of the fact, obviously you come from that judicial consulting background, so I'm going to go to you first, neil. What's your thoughts on this one?

Speaker 4:

Oh, wow, thanks, Hannah. Hi everybody, I'm glad you went to this one first. I was having a good look at this. I think there's a few things that we can do and it is the most difficult thing on the planet to kind of just write down a list of the things that you want a solution to do and be exhaustive and be complete. That is a really challenging thing to do and I understand the frustration.

Speaker 4:

A couple of things I can think of in terms of if there's particular parts or processes of your business functional areas, teams, whatever it is that you're looking to improve, whatever it is that you're looking to improve, solutions almost all bring their own best practice that is in line with widely accepted best practice and there's probably a huge time-saving element to go out and find how would a particular solution address this particular functionality in the business and do a gap fit assessments.

Speaker 4:

So, whether that be kind of a demo that kind of sparks a few ideas, or a deeper dive session into how does this fit with our organization, I think there's a very pragmatic sorry I can't speak there pragmatic way of addressing, kind of understanding what you could get out of a system and how it can enhance your business and make life easier. If you're in a place where, let's say, things are frustrating, you're having a few firefights or there's things that are not so great, document the pain points. Just capture particular pain points that are affecting your business. Maybe try to have a go at the root cause. If you can't get to the root cause, at least capture the symptoms and have that as part of a brief going into the same kind of kind of gap fit analysis. I think um I know that certainly um is a very fast way to to move forward, from my experience. So what do you think, hannah?

Speaker 2:

So my challenge and I have a real problem, and in the nicest way possible, with how everyone seems to approach requirement gathering in when, when, when it comes outside of a consultancy not that I don't agree with the fact that people are spending time thinking about it, but in some instances they just tend to spend more time thinking about the requirements than they do actually implementing. And when you've got that imbalance, you've got to genuinely ask your question why and I think a lot of it comes down to fear of getting the decision wrong. Right, and and I genuinely believe that requirements like a list of massive requirements that you send off as part of an RFP is brilliant If you know exactly what you want and you want to replicate what you've already got. I guess my challenge to everybody out there is it's very rare in this day and age that people are looking to replicate what they're normally looking to do is to change and transform. That people are looking to replicate what they're normally looking to do is to change and transform, and so and as you said earlier, a lot of each software will do something similar, but maybe in a different way.

Speaker 2:

So I think if I was, if I was engaged as a independent software independent consultant right now. I would actually approach it in a slightly different way. I would document and think about the areas of capability that I need at a top level, ie consolidation, etc. Um, and then almost document each of the elements that impact those areas. So use cases like do you need to?

Speaker 2:

If you say like we need tax compliance as an area, it needs to suit these these, uh, I need to be able to support these tax specific taxation, um taxation requirements, ie sort of use case based versus literally I you know I want to be able to log in and see this, because I think some of the requirements are so specific it's really hard for any one software to meet them all.

Speaker 2:

And then you're not making good choices around solution elements and certainly and it might just be the ones that I've received or, but I've seen some that I've seen maybe one or two that were really good and top level and summary based that encouraged us to work with that company as consultants to help them rethink their process and gain the automation improvements. And I think that's what you should be looking for as a partner. Going into these kind of projects is almost getting them to rethink, like saying this is I need an ap process. What does best practice look like? Rather than it must have this, this and this in the process and it must look exactly like this. Does that make sense now?

Speaker 4:

I think it does. I totally and totally agree, If you're kind of shaping, what are the outcomes that we've got to achieve what's important to our business? It gives you a yardstick by which to assess how you should be working in the future.

Speaker 2:

Yeah, and I think, like you know, if you just say, maybe have the top level requirements, we need to do this, and then had a briefing paper that you gave to your you know, your top, your three or five, because you shouldn't really have really be engaged with more than three or four partners at this kind of stage, because it's a lot of time wasted for everybody, let's be honest.

Speaker 2:

So if you had a detailed briefing paper where they could understand the, the business structure you know they, they should be able to come back and say these, this is what I would expect you to think about in terms of modules and capabilities for a business of your size and your industry, and then you can, you know, do a consultation with each of the companies, record and transcribe it, share it with the other companies, and then you've got like everybody's on the other companies, and then you've got like everybody's on the same page and then can demonstrate a solution according to that.

Speaker 2:

And for me, that's a lot better than going down a sort of a predefined matrix of you know ticking boxes, because we've I I found this really interesting when we've had them before we've been overly honest, according to one consultant, is that if we don't perfectly tick a box. We've said. We've said why and where the gaps are, whereas a lot of people gloss over the requirements that they put forwards as well. So it there is. There is a little bit about. You need to make sure that your partners are on the same page and aligned with you as much as anything else, and and it's so easy to misinterpret a requirement have you seen any good instances where it's worked really well?

Speaker 4:

um, I, you know, I think, uh, I have actually, let's, almost almost the reverse situation. Um, I'll explain that momentarily. Where I've seen businesses that have challenged me to demonstrate that there's a better way of working and they've been planning to systemize a process, they've gone through describing exactly how they want it to function, the features it must have, how they want it to function, the features it must have, and then they were surprised when, after they'd done all that documentation and reviewed it with them, I hadn't done the documentation. I was reviewing the process that they went through. What I pointed out to them was that they had exactly the same functionality 48 hours earlier in their business processes. And had they focused on. What are we trying to achieve? What's the outcome that we're trying to achieve? It would have been recognized earlier as an outcome. They avoided spending a seven-figure number on systems, but they took a lot of time defining system functionality, specification, flow authorities and missed the point about what we're trying to achieve. Is this business outcome?

Speaker 2:

and they would have recognized that they could already do that elsewhere in their business so if we could rethink, right, and we can maybe ignore the way that everyone's always done it, because that you and I, if that's our favorite way to work let's be honest, neil um, we like to challenge um and, as consultants, we we hate hearing the phrase well, that's the way we've always done it. So if we go back and think through where that requirements process come, a lot of time it's come out of the traditional big erp style implementations where somebody's putting SAP in across five continents and it's just been scaled down to a small business scale. Right, that's the reality. So I think what we're saying here is that if you're maybe a more agile business right, and you want, you know you need a new technology and you don't necessarily want to spell 12 months putting together a requirements document and going through an assessment process maybe the thing you need to think about is what are the functional areas in your business that you need this system to cover? What are the outcomes that you want to achieve in those functional areas?

Speaker 2:

Yeah, and then putting that out with enough detail around your business and how you currently operate in order for um, a couple of consultancies and or solution providers to come back and say this is how we would suggest you approach this, because I I think there's a danger in that you're relying on whoever's putting that document together to understand the best way to do that process, and that, for me, is a really dangerous place. And actually the advance what you should be leveraging is the experience of the various vendors to say this is how customers use this product, if you know if, when, when the most successful. This is how customers use this product when they're most successful. This is what we see, and then it's up to you then to decide whether that is a good fit for you as an organization, which I think is a much, I guess, a much better way, because you're not then being trapped into just replicating. You're not just getting what you think you need. You're getting the best possible answer to the outcome that you're trying to achieve.

Speaker 2:

Be interested to get feedback on this, guys. So, whether you're listening to this live or on the podcast, I'd really welcome some input, and I might. I've already decided that I'm going to flesh this out into a new framework and suggested approach as well. So watch this space, guys. We are going to cover this in more detail in a future session.

Speaker 4:

Maybe if I could sorry just on that, Hannah build on what you were saying there and maybe help people to frame their thinking. If you're really struggling to kind of define what systems do we need, what do we need them to do, maybe if you kind of take a step back and look at your business and say, okay, what aspects of our business do our customers pay us for? Where do we create value for them? What do they pay us to do? Better, faster, quicker I said faster and quicker, easier with richer features. What would they part with more money to do, more volume or to do in a different way? And that's a set of requirements about making what we do to achieve this easier, better, faster, reliable. Then there's a set of things that you do in order to just operate your business your payroll, paying your taxes, doing your reporting. Those things need to be done efficiently at lowest unit cost. Do them exactly the number of times that you want to do them, Error-proof them. Make them of times that you want to do them, error-proof them. Make them easier to do, faster to do If you base decisions off the back of them, bring the timeline forward. That's the requirements around making those more efficient, faster, less cost.

Speaker 4:

And then there's a whole load of things that you do in your business and you'll be aghast at how much you do of this that nobody wants. You don't want it and your customer doesn't want it. It's the rework, the waste, the error handling, the queries about things that should have been avoided. All of those things look to how you can eliminate those. What is it that's causing those that, if you improve the processes and the systems around them, would take those things away and eliminate them, and that might be a way of compartmentalizing what it is that you're looking for a partner to help you with yeah, and and I, and I think again, like you might want to consider, you know, how the approach might differ when it's a finance only simple, you know, implementation, versus a business-wide implementation.

Speaker 2:

Because, like you say, I think the challenge with finance is very often they get lumbered with the outputs from other areas of the business. We talk the downstream challenges right, and so there is a genuine question about you know, those downstream challenges. Are they critical? Because we like and we have this conversation with customers a lot that there'll be things happening elsewhere in the business that are creating problems for finance, and part of transformation and change is actually challenging that and going is that genuinely necessary for the business to be successful and people understanding the cost of, I don't know, changing contract terms or putting in a new payment method or plan or whatever. And I do think that's really important as well is making sure you're simplifying, you know, rather than just automating, because it's you know you can spend a lot of time automating things when actually what you need to do is simplify before you automate. So that's yeah, sorry, slight tangent, but kind of you inspired me there, neil, to sort of expand on that.

Speaker 2:

Glad to help, brilliant Right. Any other thoughts on this, neil, before we move on?

Speaker 4:

No, I promise that's it. We said we wouldn't overrun. We're already ahead. That way, I think we're going to do it anyway.

Speaker 2:

So I'm going to aim for three of the five questions for us to get through, but we'll see how we go.

Speaker 5:

Now for the £1 million question what is the best finance software for your business? Is it A Sage 50? Is it B Sage 200 Standard, c Sage 200 Professional or D Sage Intact? An impossible question to answer without a lifeline. But we have the perfect lifeline for you. Our free quiz which Sage Product is Right for you will tell you which product is the best fit for your business in just five minutes. All you need to do is head to wwwitassolutionscouk and answer a few simple questions um, so this one was interesting.

Speaker 2:

So, um, and it does come up a lot, um, new systems nearly ready, but our old data is a mess. The team is arguing about whether to stop until it's fixed or just push ahead. What would you do? Oh, okay, um, it depends. I'm to be a consultant here, right? I guess, my, my, I guess I'm just getting my head, my, my sort of my initial reaction out of the way now, and then I'll come to you. But my initial reaction is try not to put anything into a new, pretty clean system that you're not wanting in there permanently would be my first reaction. And and you need to decide what is actually essential for your new system, because I do find people try to pull a lot of ancient history, shall we say, that doesn't add value into their old system. So if it's not correct, then why would you spend the time pulling it in in the first place, I guess? So that's my initial reaction, neil, what was, what's yours?

Speaker 4:

oh, I, I'm desperately trying to shake off the the old database management systems background. I, I wholeheartedly agree. I think we all know the phrase size. So, um, I won't expand on that. I think we all know what that is. Um, well, I'd be good to define it, because a lot of people may not.

Speaker 2:

Now, please don't you know. We. I think we all know the phrase SISO. I won't expand on that. I think we all know what that is. Well, I'd be good to define it, because a lot of people may not. Neil, please don't you know. We have to shout our acronym yeah.

Speaker 4:

So if we put bad information into a system, it's going to give us bad results, basically, and in finance. You know there's some areas of exposure where, for example, duplicate supplier records could end up with duplicate invoice processing, can duplicate payments going out the door. Um, you know there's there are risks that the business encounters as a result of of having data in not a clean shape. I think, alongside housekeeping and user conventions around data naming, we always do need a sense of trapping where those exposures exist. So we could say, oh yeah, let the data go in with the duplicates it has and what we'll do is we'll try to trap it at invoice posting or we'll try to trap it when we're doing a payment run. I think we should be doing those things anyway, but let's not give ourselves an avoidable volume to trap.

Speaker 4:

My every instinct is to try to clean up the data as much as possible in advance of moving to your new system. Are such that you're almost forced to accept the current situation and take some of that poor data in. Then you know, please, please, do have a cleanup immediately, as soon as possible, to get that data into good shape, and think about what would be the gatekeeper processes that we could have in place in terms of controls to detect the risks associated with that poor data. That's probably a good exercise. Regardless of which approach you you take, it will be a good um. Detective control um. There are some fault tolerance approaches to how data can be handled to take into account that we, you know, ultimately we're reliant upon a human um, but my advice is to to kind of go for the the clean data approach as soon as possible yeah.

Speaker 2:

So I think fundamentally, if we think about it, we have three options right we pause the project, we go ahead with a partial but semi-clean data set, or um. We crack on with the the bad data. My answer is cracking on with bad data is just a recipe of disaster unless you've got a lot of resource to clean it up. So personally, I don't think I think you need to rationalize your data set that you're pulling across and then assess how easy it is to clean that up. You also might want to consider things like suppliers, right. What's the damage in entering them at point of entering the invoice and getting it clean that way? Because then I would hope that your new system has some kind of validation procedures around that side of things. I know it's going to make the go live process longer and more painful, but then that's something that you need to weigh up versus the delay and whether you have the capacity.

Speaker 2:

Um and I also think I do think the partial data set is probably better can you get 70% of your suppliers in clean? Do some basic excel validation based on multiple variables, for instance? So, for instance, the suppliers dedupe based on back codes, post codes and things like that um, and then, um, you know, like various different pieces, that you can try and catch them and then at that point you can. You know, because not being funny if a supplier's got a different postcode and a different bat number and a different name, then they're probably a different supplier.

Speaker 2:

In most instances you'd have to be um, pretty bad and then, like, have a validation, a way of validating that data, say, like that 30 and 30 days post where you can run a list of all supplies that haven't been used and then validate those potentially. So I feel like there's always a way around it. It just may not be the answer that somebody's looking for and if you're doing a massive historical data migration, in my personal opinion you need to rethink that anyway, because that should have its own project plan, because it has a number of challenges with that as an approach. So further thoughts, neil.

Speaker 4:

I think everything you said, I think is absolutely spot on, hannah. What I would add to that is that you might get a pleasant surprise in if you put some resource into cleaning the data. You might find that you regain that resource consumption in using the system. So if we've got unclear data conventions, somebody trying to find a particular supplier and finding multiple records and then asking about which one should I be using might take up more time than cleaning up the data collectively in your business. So there might be a little bit of a false economy about we'll leave the cleaning up till later.

Speaker 4:

You know the economy might come straight away by getting clean data that is clear on how it can be used in the business. And you know there's the old exercises in shape, short, sort, shine, you know kind of. You can more readily find the thing you're looking for if everything's organized in a particular standard way, and that's true of data records. If they're following conventions, it will get your system will become more usable for the users. So I think you'll find that you get back the investment very quickly.

Speaker 2:

So I think you'll find that you get back the investment very quickly. Absolutely, and you know there is a lot around how we think through the process of entering data and there's a lot to be done around validation there. So I'm going to quickly move us on to our last and final question. We've had so many projects over the last few years that people have stopped paying attention. Every time we announce something new, the reaction is basically eye-rolling. How do we get people to take this seriously and join in? Over to you, neil? I'd love to hear your thoughts on this one.

Speaker 4:

So you know I love referring to John Cotter when it comes to transformation projects. I think the key thing here is we're facing, obviously, a situation where there's change fatigue. Every business hits that at some point and, you know, maybe we have some thoughts about what. Is it about the changes that causes eye rolling? I'd say that a first piece around it that we need to think about is is there a compelling reason for the change, is there a meaningful outcome that people can align behind, and is it contextualized into their day-to-day jobs? So if there's a sort of we're going to change our finance system and we're going to do it within four months and it's going to be great, is the message I can imagine that would cause eye rolling.

Speaker 4:

If it's, we're going to change our finance system and the benefit to our team is that there are fewer steps in this piece. We're taking away the manual effort in reconciliations over here. Statement processing from the bank is going to be automated, we'll have more time to get involved in producing reports that help the leadership take good decisions and we'll have the right tagging against all of our costs so that we can run really good cost center budgets and we can start acting as business partners rather than accountants just in the back room. That's a far more compelling picture for people to see themselves being part of the story and I really think contextualizing whether it be a change program or whether it be just the day--to-day um direction of business takes contextualizing what you're trying to achieve to the to the day-to-day jobs of individuals is a real part of bringing them on board absolutely um, and and I think there's a lot to be said.

Speaker 2:

So I'm actually going to save this question around because I'm very aware we have now completely run out of time and we are trying to stick to our timing budget for this session. But thank you, guys all, for listening into this episode of Transformation Troubleshooter. We have a number of questions to cover on our next session, but if you have a question you'd like us to answer, please send it to the email address on the screen Hannah Monroe at itassolutionscouk and we do have a session upcoming called Stop Shopping, start Transforming all about helping you streamline that software selection process. So I do hope you can join us that future one. So a massive thank you to Neil for joining me today and, as always, lovely to have your advice.

Speaker 2:

If you're looking for a new solution, perhaps a new partner, then please do look to explore our website, wwwisasolutionscouk. We've got a which Sage Product is Right for you quiz that you can take part in. On that We've got Planning a Successful Project and how to Avoid Some of the Mistakes and Challenges that we've talked about before, and, of course, you can explore and learn more about Sage's products. So thank you again, neil, for joining us. Thank you to our listeners for getting involved and inspiring this podcast, and we'll see you next time on Financial Transformation Live.

Speaker 4:

Thanks, Anna, Goodbye everybody.

Speaker 2:

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.

Speaker 3:

So rather than me tell you how awesome we are, let me introduce one of our customers I'd recommend itas as a stage partner, not only because of their knowledge that they have on the product itself and intact, but also their friendly and professional approach to the whole project. They've been incredibly flexible throughout the process, but also challenging us as a customer to really think about what it is that we're after and ensuring that Intact was actually the correct solution for us to meet our needs, which was really refreshing rather than feeling we've just been sold a product that they offer. We've got on really well with the whole team. They've been hugely approachable, helpful throughout the whole process, really putting hugely approachable, helpful throughout the whole process, really putting it as an ease, if that you know anything we kind of felt we were struggling with or difficult, and really helped us to understand some of the complexities with the new system that's different to other finance systems, things that we've just never come across before, like the new dimensions and understanding how that actually works.

People on this episode

Head Shot

Hannah Munro

Host

Podcasts we love

Check out these other fine podcasts recommended by us, not an algorithm.

CFO Bookshelf Artwork

CFO Bookshelf

Mark Gandy
FP&A Tomorrow Artwork

FP&A Tomorrow

Paul Barnhurst