Defining the ERP Transformation Strategy for CFOs

Megan - 00:49: Welcome back to CFO Weekly. Today, I'm chatting with Evan J. Schwartz, Chief Innovation Officer at AMCS Group and a seasoned technology and operations leader with more than three decades of experience driving large scale digital transformation. Evan has held roles spanning Chief Innovation Officer, CTO, and Chief Enterprise Architect, leading ERP modernization, SaaS adoption, and AI driven platforms across complex resource intensive industries. He's also the author of the Amazon best selling book, People, Places, and Things, a practical framework for achieving ERP success without costly overruns or failed deployments. Today, we'll explore why so many ERP initiatives fail to deliver ROI, what CFOs can do differently to ensure adoption and value creation, and how finance and technology leaders can work together to turn digital transformation into a true competitive advantage. Welcome to the show. Today, we're diving into one of the most expensive and most misunderstood investments finance leaders make, ERP transformation. While the technology promises efficiency, insight, and scalability, the reality is that many ERP programs fail to deliver meaningful ROI. Our guest today has spent his career at the intersection of finance innovation and large scale ERP modernization. He's seen firsthand what works, what breaks, and most importantly, what CFOs must personally own if they want transformation to stick. Evan, we're thrilled to have you on the show today. Thank you for joining me.

Evan - 02:23: Hey, Megan. This is exciting. I'm glad to be here.

Megan - 02:26: So before you were leading global innovation and ERP transformations, as you think back throughout your career, was there an early moment when a technology decision either went spectacularly right or painfully wrong and shaped how you think about adoption and ROI today?

Evan - 02:46: There were actually two moments that were in high contrast that kind of led to the philosophy at which I run technology today, and I'll just briefly go over both of them. I would say most of the early enterprise rollouts for large scale companies at the mid size, it wasn't nearly as bad. But for the large scale companies, was generally an awful experience. It was difficult. There was not a lot of coordination at the enterprise level. There were huge numbers of stakeholders in the rollout of a new ERP that often either never had representation during the rollout or came so late in the process that it was very disruptive to then try to accommodate the needs of those departments. That was early on. And you got to understand, in the early days, companies were largely required or needed to build their own systems. And in that transition to offloading that responsibility for ERP systems to third party, large scale delivery systems, that was the transition phase, where you were expecting a vendor that was servicing your vertical industry to come into your business, know your business, and be able to deploy it well. And it was several decades of learning. Then on the other side, where it did seem to go well, but almost by accident, which was also still a learning exercise, were the efficiency gains that were acquired by accident after the program went into operation and the boots on the ground, the people that worked with it day in and day out, started to innovate process around the capabilities of the system, started to engineer efficiencies. If I look back in those early days, those gains in efficiencies were almost never a part of the original project at all. There was always some systemic or external pressure to take on this new system with very weak metrics that define success with almost a hope, more a cult like belief system, that it was going to provide a better outcome for the company. So it took a little while for companies to transition away from owning their entire technical fate to buying off the shelf systems and adapting to them before projects and implementation standards started to catch up. And it was in that if we would have planned for this in the beginning and worked towards that outcome, we probably would have seen it faster, cheaper, and it would have been a more declarative outcome. We could have measured the success earlier. So there was a learning period, but it wasn't just a precipice. It wasn't a I get it now moment. It was sort of death by a thousand paper cuts. Some were good, some were bad. And it took a lot of reflection to kind of look back on how should we begin to think about implementing these large scale systems, particularly where there was change management in the way that people operated day to day.

Megan - 06:03: And before we go any further, let's just take a step back. Can you talk me through your background, your experience, and where you are today, and I guess how you got there?

Evan - 06:13: So very early on, I was attracted to become a chemist. I was very science oriented. And technology, computers, programming, all that seemed to come very easy to me. So as you can imagine, I didn't value it as a skill. And as a summer project, I started a company that wrote help bulletin board system games. And I'm old enough to tell you that the old school dial up BBS, which was the internet before the internet is the best way to describe that if you're not familiar with it, where you would dial one computer and it was just you and that computer talking for a short period, then you hung up and no one else could talk to that computer slash website until you hung up. It was all text screens. People were using characters and special characters to make pictures. And I just knew there had to be a better way. So I wanted to bring graphics to the online BBS world so people could play games online. And we did that. And that was exciting. And it made a lot more money than I had thought, a lot more money than my father even thought was possible with this fad thing with computers. And I rode that probably for ten years, building connected systems, online gaming, connecting people, getting value out of it. And then the internet came and it up leveled. So what was sort of a hobby, I was no longer in a position to compete with commercialized gaming coming into the online world. Internet had came. There was a variety of market pressures that killed the bulletin board system and hobbyists from doing this. And that wedged me into the business world. When I got to the business world and I saw how horrible the computer systems were, there was no thought around user experience. You would get to a screen, Megan, and the tab order was out of place. The human interface had zero to no thought process. You would go to a screen, you'd have to know esoteric codes to unlock the screen or even get to it. There was no instructions on how to load the data appropriately. There were no validation fields you made. You just had to try it, and they would bark at you with some error message. It was just a very terrible experience. And I knew there needed to be a change in the way business solutions ran. And that in the natural gas world, when I had taken the role at Infinite Energy out in Gainesville, Florida, is where I reapplied the rigor of making a game from a user experience and efficiency and a latency concern and applied it to business products. And it, as you can imagine, if you've played within the old software and you hit a button, it would whirly gig for a minute, two minutes, three minutes, to suddenly it being very reactive to you and interactive. And you could do something and then go do something else while that one thing is still working so it didn't block you. Those things were well received in the business world. And I was able to thrive up from that position. That was my first interaction to what I consider wealth industries, vertical industries that produced revenue from either the extraction of materials, the transformation of materials, making something real. It wasn't just an information or services based industry. And from there, I got to see and rebuild the entire customer service module from consumer based customers to large industrial customers that were burning hundreds of thousands of dekatherms a month. So it was the entire gambit of customer experiences, billing systems, processing systems, specialty type of billing engines, all of that across what you would see in these large scale industries, whether it's waste, harvesting, mining, materials, construction, any kind of manufacturing system. I got to see parts and pieces of it, even transportation, logistics of moving gas across eight pipelines with transportation costs. I was able to cut my teeth across all of the common problems in industry, that one ERP system. And I built it from the ground up with no real prior experience other than a demand excellence on the user experience, efficiency, efficient use of data. It was just a different perspective. And it unlocked that little company, which was a receivership for the Enron fiasco. They'd gone from 8,000 customers to 80,000 customers overnight as the government had stepped in and break up Enron when natural gas was deregulated and opened the doors for them to go and look at deregulated water, deregulated electricity. And I saw firsthand something that I had designed and built open a company's market cap up to such a broad market. That was the moment for me that while gaming is actually fun and it allowed me to cut my teeth in an area with just incredible rigor and demand by its customer base. The real passion on seeing how software can affect the real world was in these ERP systems. It revolutionized that company. It changed it overnight, literally. Within less than two years, they had gone from a small $50 million a year to a half billion dollar a year company, and then went IPO. That software solution was it. From there, it led into other wealth industries like the forestry industry, paper business was in that for a couple of decades, migrated from the paper business into secondary fiber, which led me into recycling, which led me into waste and recycling, which led me into scrap metal and net zero and harvesting materials and manufacturing. And then seeing the connected tissue. A lot of people don't know this, but in the pulp and paper from the pine trees, the terpenes that are extracted during the paper manufacturing process goes into the flavorings industry or the fuel additive industry, which led me back to natural gas and led me back to big gas and oil. And all of these industries, I found that there was always a segment of one industry's waste or byproduct was another industry's feedstock. And I've been chasing that kind of connectivity for the last three decades. How can you build a system that would work across a wide variety of industries, but then also connect in all of these ancillary industries to make sure that we're making the most efficient use of resources. And from that path is how I landed at AMCS Group Global, working to build a resource intensive platform that covers all of these facets across so many resource intensive industries, giving them connected intelligence and systems. That's where I am today, really driving. We'll never get to a perfectly closed loop system, but there is so much opportunity in the connective tissue between the processing steps today. And I believe AI is going to give us that capability to look at the data. I mean, if you think about it, it was not even eight years ago, we were in data overload, right? Too much data. We can't do anything with it. To now we're running out of data. There's nothing called data. It's a remarkable transformation. And it's just accelerating and accelerating and accelerating. But that's where we're taking those ideal models of efficiency that these companies are looking for to improve their margins. And then we're taking it to the next order of magnitude. That's my origin story.

Megan - 13:47: Yeah. That's really interesting. I mean, just gaming and how important it is for the user experience to be great and tying that into an ERP where usually the user experience is not so great. Right. So from a CFO's vantage point, where do ERP transformations most often break down? Is it strategy, governance, adoption, or measurement? And why do so many initiatives miss ROI even when the technology itself is sound?

Evan - 14:16: So that's a great question. There are a couple of areas that you can look at, but they all stem from how the project launch. So let's start with what I think is the leading cause is most companies don't really know what they have. They know the name of the system that they use, but what they don't recognize is that most of the users across the departments and across enterprise, and this is why it impacts the larger your company is, the more likely this factor would impact the rollout of your next generation system is, we could argue about how techie or smart or edgy the average employee is. But what is really unarguable is that they're all diabolical. They're very good at becoming efficient at their job. They'll find a way to figure out how to do their job efficiently. It's just human nature. And in a lot of ways, that ends up in the creation of a rogue system, whether that's a oh so special Excel spreadsheet that's being managed offline, some Access database in the corner that is producing a mission critical report or a compliance output. There's processes that evolve around the current system because of the way the current system was deployed. Either it was very rigid, it was difficult to change, management was kind of maybe not necessarily tuned in to the boots on the ground foot soldier. So they had to build these workarounds. So now having ten years of that diabolical evolution within your enterprise, you at the C level, or even the senior leadership level might have a perception of the way things work, outcomes, metrics, that we have a compliance requirement, but you probably don't know exactly how we satisfy that requirement. And so you're now considering on swapping out ERP system because there's some specific things you want to go and do, and you don't have a good picture of your current architecture. That is guaranteed to be a break from the beginning because the way that you strategize around your new ERP, what you classify is going to be ROI is going to be off because unfortunately, if you haven't done that rigor upfront, if you don't know what your as is architecture is, and then designing the to be, which usually occurs somewhere in the discovery phase of the project, you don't have a good roadmap. You're designing to be from an idealistic as is. And then when you discover things, that starts to create leakage, that starts to create unexpected change requests, you start having to put in more change. So not having a strong in-depth detail of what your as is, a really big indicator of failure. The second one, and to me in a lot of ways this is the easiest one to do, so it surprises me that it doesn't happen, is the vision statement for the new system. A lot of people will run out a new ERP system because their old system's old. It's not easy to change. We need a new one. That's not nearly good enough of a vision to put your entire company through pain. So you have to build a vision around the project. If you're a strong leader, you're about to put, maybe not everyone, some people will benefit from it, but there's going to be departments in your business that are going to suffer because it's not going to do the thing they were able to do with the older system. And now they're going to be put through pain and they're not going to understand why. Because you didn't announce the why. You don't have a vision around the why are we doing this? People can put up with a lot of pain if they get why you're asking them to take on this pain. And if you can paint some picture of when does this pain go away? Vision statements do a good job of that. So that helps morale. It gets through the grit. And if anyone thinks rolling out a large enterprise scale ERP is easy, they're lying to you. It's not. Change management is going to be difficult because it's got people in it and people are messy and that's just, it's going to be a problem. The other part of the vision statement is confining what the outcome is going to be. There needs to be three maximum four non negotiables as to what you need the ERP system to do and why you need it to do it. That's tied to some kind of ROI growing your market. Like the Infinite Energy story I told where they were wanting to have a more flexible billing system to go into other deregulated markets, there needs to be those whys. You don't need to get super specific, but you need to have a non negotiable that the system needs to do this. Why? Because when you get through the implementation, there's going to be little things like, oh, well, I have to do four clicks to get to this report. And it used to be one. And without a strong vision that says these are the non negotiables. Everything else is negotiable. Can be put on roadmap, can put to a later date. You end up building a project team that chases every paper cut as it goes. And it's never going to be accepted because this department's going to feel like this is a step back. And we didn't frame the project in a way of going, you are going to feel like it's a step back, but the reason you're going to feel that is because it does not do this. But what we do get is we get an increase in bottom line margin EBITDA up revenue of X million. So I'm asking you to take on this pain and the vendor, I'm going to work with the vendor to get this feature you need on roadmap, but it might not come for fourteen months. So we're tabling it in the project. We're not going to chase it because the most important things to chase are these three to four non negotiables. If you don't have that, you're guaranteed overruns, you're guaranteed delays, and you're guaranteed that you're going to have a dissatisfaction because you as the customer never defined what satisfaction is. And if your definition of satisfaction is to have everything I had before plus, you're already guaranteed to be in that 70% bucket of fail. I'm sorry to say. So those two things I would ask businesses, make sure you know what you have, and then as you're going and chasing this new ERP system, have a strong vision with which you can hold up project based decisions and go, do I need to address this right now in the project or can I delay it? The third critical feature is most businesses go after an ERP system and think they're buying a piece of software. This one's harder to swallow. Not a lot of people agree with me, so I'm going to put that hazard cone out there. But if you think about the speed at which the market and technology is evolving today, even if you had a very fast paced, successful ERP rollout across your global enterprise, and it was going to be eighteen to thirty six months, there is no way what you think you need today is what you're going to need in eighteen to thirty six months. No way. The world is changing so fast. Your needs are going to evolve with it. The most important thing you're buying when you're buying a ERP system today is the vendor. Get as much of that software in place as you can to run your business, but build and invest in that relationship with your vendor so that you can help manage roadmap. You can make sure that it's an extensible system. So maybe if you need to get other partners to evolve your system, to wrench it into place, to do what you do. Even if this is a vertical industry specific vendor, I can tell you, because I've been in the vendor seat for a long time, our systems at Baywood handled the top 10 pulp and paper companies in the world. And not one of them did business the same way, but every single one of them made paper, and they did it through forestry and harvesting trees, but none of them did it the same way. So invest in your vendor over your software. Make sure your software meets the minimum requirements and meets the vision of the project. But you need to invest in your vendor because that's how you're going to get this software to feel like that nice worn in pair of jeans that you're walking away from. And it still have that new fresh pair of jeans feel when you're done. Because if you're looking for a perfect piece of software, you're chasing a rainbow or looking for a unicorn you'll never get. And by the time you've given up on that rainbow chase, you would have spent three to four X, your original budgeted project money.

Megan - 22:46: And once things start to wobble, I'm sure the challenge becomes recognizing trouble early enough to change course. Yeah. Yeah. You've led ERP modernization across multiple roles and industries as you mentioned. So what early signals tell you that an ERP program is drifting towards Gartner's failure zone, and what corrective actions actually work?

Evan - 23:08: That is a great question. So there are plenty of project management tools. To me, this isn't specific to the ERP world. If you've run any project that has a budget, you have earned value over, I guess, burnt budget. So if your budget is burning faster than your earned value and you've got a gap, you're already in trouble. So standard project management reporting is going to tell you you're off the track. So the challenge is what to do to fix it. Good project managers, especially ones that have experience doing digital transformations will have mitigations already thought through at least a handful. You don't want to go down that rabbit hole so far because it's an infinite use case. But you want to have some strong, what are my risks? Do I already have some plans in place? Do I have reserve budget? All of the what I consider the normal things. But to be very successful is build a project culture. Sit down with your customer and the project team and decide what is our project culture so that we can start to establish trust. Because if you don't establish trust from the day one of the project and encourage people to report problems, you're going to get Hail Mary mentality. I've seen managers many times go, nope, we're not moving that date. We committed to that date. That's the date no matter what. You're forcing the team to lie to you. You've given them no out. If they're trying to tell you that something has cracked up and we're not going to hit the date and you've not created an environment of trust for them to say that, then they're going to go, yep, you're right. Let's fight for this. We're going to see if we can come up with a better way. And then they go away. They know there's no better way. But then what happens is the project team comes to the stakeholder table or the steer co meeting the day of having missed the delivery and the next delivery date is probably two months away. That erodes trust even further. And so now you've begun to spiral because you've waited to the last minute to raise the flag. There are no other options except to add more time and money to the project now. You've removed any other ability to use management best practices to try to get it back on track. And getting it back on track, if you have that vision statement, you already know what the non negotiables are. So is this thing that's causing a delay in the non negotiables? If it isn't, can I remove it from scope? Can I de scope the project and come at it later? Is there a workaround for now to keep the project on track and on budget? So those are all what I would consider the meat and potatoes of project management. The goal is if you've done your work and you have your vision upfront and you have your as is, and you've built a strong to be, and you've got that journey, you understand your decommissions, you understand what you're adding, you've built your plan around it. There's going to be unexpected. Your crystal ball works about as good as mine, which is to say it doesn't work. So we're using our experience to predict the future, and then we're tracking it on the earned value versus budget burn to see, make sure that we're on track against it. And we're looking at it a variety of different ways, money over earned value. We're looking at it on time over the project scale, delivered tasks. Is there ways that we can pull a more pressure in, work weekends? All those things pan out. But you have to have a project team with grit, experienced enough, that has trust to be able to go, we're not going to be able to deliver everything on time. So either we're moving the goalpost, which immediately puts us into that Gartner risk. We're starting to sort of have scope creep into the system. Or if I can do without, let's take it out, let's keep us on task, and then we run it then as a separate body of work to meet that requirement. But it has to have a workaround. If you've pre thought through that exercise of something's going to happen and I have to take something out of scope, what are the minimum requirements for me to be able to do that? Then the team can bring to the steer co not only the challenge, but potential solutions based on the framework you built the protocol or the rules of engagement at the beginning of the project. It is so much easier to negotiate those rules of engagement during the forming and storming phase than when the problem hits and you're trying to figure out what's good and what's not good. So I would say that there's no magic. It's measure often, keep not only the steer co, but the project team, all the stakeholders involved as you go, and make sure you've got a change management framework pre built in. You don't want to be stingy with that either. I've seen it go the other way where it's not the customer being unruly on what they need. It's the vendor nickeling and diming you for every little bump in the road. There's going to have to be that trust relationship built along the project. And you know probably within the first four milestone deliveries as to whether or not you've got a strong and good project team. Do not be afraid to rework the project plan. Don't be so allegiant to your plan that it becomes rigid, and you just keep going and hoping. Hope is not a plan.

Megan - 28:21: And how should finance leaders think about ERP investments not as IT projects, but as enterprise operating model changes? And what decisions do CFOs personally need to own to ensure success?

Evan - 28:36: That's a great question too. So what are the outcomes? What is it you're trying to achieve from an outcome standpoint? Don't get mired in the how it does it. Let the project team and the smart people you hire do that. But what is the outcome? What are you trying to get? Are you trying to get efficiency saving on reporting? Are you trying to reduce your month end? Is your month end on the order of taking you two weeks to close the books and you need to get it done sooner? Have your metrics well established upfront of what the goals are that you want this new ERP system to achieve. And then make sure that you're targeting the highest value of those. And it's very clear what the priorities are. Clarity and prioritization around goals from a CFO standpoint. Why are you going after the new system? I can tell you if you were pushed into a corner, if this would be my advice to a CFO is you've got an age system. It's running end of life end of support. While that may be the catalyst, the spark that's causing the change, ignore that piece. We're now going on a change, but I need to have a measurable, quantifiable success metric with which I'm tracking to on a new system. Have to. Because that's going to be what's driving the hard decisions going forward. Don't get wrapped up in the tech. Because AI is a very big concept now. A lot of people are talking about AI. And AI most certainly could be a tool that accelerates month end close, could reduce the time to reporting, especially doing ad hoc reporting. Hell, you may not even need, right now, you have a room full of 12 analysts pouring over spreadsheets. And with this new system and its AI, you played with it. I can shrink that down to maybe three to four. Great. Then quantify what those success metrics are and say the system needs to do this. You're not telling how the system does that. These are the success metrics. This project succeeds or fails by achieving those. And I'm expecting this new ERP system to do it. If the spark or the impetus for the new system was because it's old and needs to be replaced, fine, we're replacing it. But then treat it just like you would any business decision. And when you start treating your heartbeat, your technical heartbeat of your system, like roof repair, I'm just replacing the roof because it's fifteen years old and I need to do it. You're going to find yourself in the Gartner 70% territory. You have to have a vision around why you're doing it, but it doesn't necessarily have to be a technical vision. You don't have to be technically savvy. You just need the ERP system to achieve these outcomes. So speaking outcomes and less about tech jargon, I think I find depending on which side of the aisle you're on, I found highly technical CFOs who get wrapped up in the tech. And what you really should be is really focused on the outcome. A great COO that used to work at AMCS said this, and I love this. He said, stop selling the drill. No one's really buying the drill. What they're buying is the hole. They want to be able to put a hole in the wall. So talk about the hole. Let's make sure the hole is the right size, the right depth, and how easy is it to use. Talk about the hole. And then once the hole has been achieved, we can now look at the drill and go, is it doing it efficiently? Are the RPMs? Or now we can start talking about and making efficiencies to the drill only after it's achieved the outcome. Otherwise, what's the point?

Megan - 32:16: And it's often adoption that's cited as the silent killer of ERP ROI. So what specific behaviors, incentives, or leadership actions most influence whether teams actually are going to change how they work?

Evan - 32:31: OCM or organizational change management is absolutely the biggest threat. As you're going through and you're doing that exercise I talked about in the beginning of as is and to be, there's a process map on top of the architecture map. What process changes am I expecting my business to take on? How am I going to get those processes adopted? Am I making departments less efficient? Am I adding process weight to some departments? That's where the why of the vision becomes very important. And that would be technical debt. When do I buy that out for that department and get them back to the efficiencies that they solved before this? But I still have a net gain because I got efficiencies in this other area, or because I have more accurate accounting at the end of the month, because I can close the month out faster so we can make faster business decisions. So know the why of you're doing this, and it can't be something like the system's old and we need to replace it. There's not enough passion in that why to handle the pain you're about to put your whole business through. And there is no change without pain. There just isn't, but people can manage the pain if they understand with clarity, what's being asked of them, how long they're going to have to deal with it. So the sooner you can get ahead of rolling the system out and start evangelizing, no pun intended, the new system as it goes across to your organization, making people aware of what's coming at them so that you've already gotten over the shock and now they understand, are they in the martyrdom group? They're taking on a little pain for the organization and everyone appreciates it and wraps their arms around them. And it's very respective if things slow down in that department. Those are the kinds of things you need to get in front of. If you go forward with this and you're just focused on the end result, you haven't thought about the change management to the people within the process and how those processes are going to get adopted and trained during the rollout, you're going to get a rejection by most people. It's going to slow things down. It's going to create unrealistic expectations back into the project team. It's going to be hard to learn because it's going to be different and they weren't expecting it. So there are whole, you could write a whole book onto itself on just change management and how to drive adult learners. But the most important thing I learned along the way is adult learners don't learn like children learn. Children are okay with not knowing. Adult learners, you almost have to tell them what you're going to tell them, tell it to them, and then tell them what you just told them. You need to give them that entire journey from end to end, what they're about to experience, then walk them through the journey so they can sense it and feel it and get their questions answered, and then summarize that journey. And if there's an uplift, congratulations, you're a benefactor of the new system. If there's a downgrade where you're going to feel pain, tell me how long I have to live like this so that I can understand the sacrifices I'm making for the betterment of the company. That's it. It's not really much harder than that.

Megan - 35:45: And speaking of pain free, you've written about people, places, and things as a framework for pain free ERP implementation. So how does this lens help finance leaders derisk large scale digitalization efforts?

Evan - 35:59: The book is labeled People, Places, and Things because that is almost the order in which you should think about your ERP implementation. You should think about your people first and what's the impact on them, the places within your organizations, your locations, and how the impact on them, and then any things. If you're selling or buying something, everything in this world is you're either buying or selling something that has to be transported from one place to the next and it's a transaction between people. And all the book does is it accepts the fact that there is a strong body of work for project management best practices. But digitalization is a slightly different beast. There is a point where there's a very circular iterative process, particularly around testing, around process improvement. There is an area of morale you have to be cognizant on within your team. There's a variety of things because it's so complex. It's such a broad area. It's impossible for any one person to know everything that's going on for an ERP implementation. So you have to really drive these processes, maintain the morale, make sure that you're avoiding toxicity within your project or your teams or the folks that are trained. So people and places and things, the book goes through my thirty five years of narrative that kind of explains the back stories for all the principles and the customer journey framework. The customer journey framework is a separate it's a 750 page. Here's a full framework. I'm not even going to try to advocate. There's a one size fits all. So there's a lot of latitude left to right. You can go through it. Top down. There's 10 phases on the customer journey from before you buy all the way to support maintenance. If you're in the middle of a project that's gone off rails, great. Find out where you were on that roadmap and work your way backwards and find out what you missed. And the customer journey will let you know, and then you can fill those gaps, go back forward to get caught up, get that train back on rails and get your project done. If you're smart enough to realize that you need help from the get go, if you're taking maybe a floor manager and going poof, you're now the project manager on our side for an ERP rollout, you've never rolled one out before, and you see that they need help, get the customer journey ahead of that. It'll walk them through how to leverage AI during the rollout, how to train AI across your organization, how to implement an ERP system, the things that you need that are different or unique to a digitalization transformation project. So it sits over top of what I consider standard project management best practices, but there's a reason why these fail 70% of the time. They're just very specific things that in addition to your best practices of project management that you need to do around preparing expectations for your people, getting your vision statement in place, understanding how to prioritize technology, making sure that you have good expectations. It's a rules for engagement between your vendor and you. So when things go off rail, because you should also put this in front of your vendor and go, this is the way I would like to implement this project. And if they agree to it, the rules are engagement. So there's no finger pointing at any point along this. It's very clear of those things that are customer responsibilities versus those things that are vendor responsibilities. And it makes it very clear in there. So that way, when you have a problem, there's no doubt who's responsible or accountable for getting that problem resolved. So it just gets you through all the things that you wouldn't ordinarily consider a challenge, like the rogue systems, how to get them out of your environment so that or at least exposed so that you can account for them. You may find out that your new ERP system also does not do this rogue system. So now I need to integrate this rogue system. How do I make it more robust rather than it being this thing that only this department knows about on this giant 16 gigabyte Excel spreadsheet that's being passed around an email. Right? How can my IT department get their arms around that and put governance to make sure it's backed up and give my company some resilience? So it covers all of those things. That's really the nature of the book is just, why are you listening to me? It's all of my stories. And then the customer journey is the how to framework that you can mold and apply to your business and your project to make sure that you're not in that 70% Gartner fail.

Megan - 40:30: And how do you recommend CFOs define and track ROI for ERP initiatives beyond just cost savings, especially in areas like sustainability, customer experience, scalability, and decision velocity?

Evan - 40:45: So that gets back to if I'm able to call into my ERP and get data out of it very quickly, I can make rapid decisions. If it takes me currently today, I have to pull out a bunch of raw data, grind it through a series of Excel sheets. Maybe I'm having to survey data in it. And it takes me three to four days to get this special Excel spreadsheet, whatever it is, whether it's your margin report, whatever it is that's driving decisions in your business. You're not making very fast decisions. You need things that are near real time. So the speed at which you're able to deliver that report that took X amount of time before you can get it, you want to increase to what now? And then what's the lift of that? Does that allow you to capture a greater market? Does that allow you to win more sales? Does that increase revenue? There's always going to be some sort of a financial metric on the outside of that balanced scorecard, but work from a balanced scorecard. If you just say, I want to see 20% revenue and you don't hit it, how do you fix it? What you're really looking at is I need to be able to generate reports faster than I do today. That's great. How long does it take today? So if you don't know your current metrics, how do you know whether you're winning or losing? So I would say is whatever you are targeting as your winning metrics, know what they are today. Go into the ERP shopping experience already knowing where you are and make sure your new system is going to achieve better. Then have at least a prediction of if I can increase my report generation or I can reduce my month close by 50% from six days to three day closing period. What's going to be the net impact to the business. Ask that question, have the rest of your senior leadership, your C suite get involved in that and ask operations, ask sales, What would it be worth if I could get a month end close done in half the time? Would that allow us to make investment decisions faster? Would that allow us to do deal making with new customers faster? What's the net impact? And then agree to that metric. This is what I'm expecting to hit. I'm going to measure the scorecard and then I'm gonna measure, do I get the financial outcome I was expecting to get from it? Now, as long as I'm within your plus or minus 15% variance, I'm gonna call it a win. Right? Because my crystal ball's as good as yours. So there's a little bit of guesswork here in a new system, and I'll dial it in and see where else can I get lists? But every one of your metrics should be tied to two to three balance scorecard actions. What is the real activity I'm looking for? I wanna reduce the number of analysts I have to have doing analyst work on my financials. So I know because I got a headcount and I've got a salary cost, what that should give me. Can I reduce it to that amount? Here's my expected efficiencies and cost reduction that I expect to see. If I can accelerate my monthly close, what's that worth and why do I think that's worth that? And then you just track those. That's what you're measuring to. You're not going to get that day one. It's going to take time for your organization to assimilate. It's one of those things. I've given you the tools as a vendor for you to go chase that $3,000,000 a year savings, but I can't cash the check for you now, mister customer or missus customer. You now need to implement those things because the tools are now here for you to get it. So as long as you're incrementing it within the first six months, you might even experience a slight dip as you've got a new system coming into the room less efficient because your people are getting used to it. But by month seven, eight, nine, I should start to see that hockey stick work its way up. Have expectations around your metrics. Measure them at whatever frequency makes sense to measure them. Some of those might be quarterly metrics. Some might be monthly, depending on what you're choosing. Measure them and have what my target metric is, my plus or minus conformance, and my absolute outer limits. If I'm in my absolute outer limits, I need to bring the vendor back in and go, guys, we talked about this at the beginning. This is what I was expecting from this activity. The most important thing you could do is not hide that from your vendor because they can't configure the system or make recommendations to you if they don't understand the objectives and the metrics with which you're measuring success by. And if you don't know what your metric is today, how are you gonna know that you're plus any percent or minus any percent? So work with a vendor that you can trust, define what your metrics from a balanced scorecard perspective, then tie that out to your, whether it's an EBITDA lift, ARR, whatever your metrics that drive financially your business at the end of the year, tie your scorecard to those items because the system can achieve the scorecard. And then by achieving the scorecard outcomes, you're expecting to get those end year financial metrics lifted. Hopefully, that makes sense.

Megan - 45:41: Yeah. Thank you. So to wrap things up, looking ahead, what defines the future ready CFO and what should the future ready CFO be looking for in their ERP?

Evan - 45:53: I would say interoperability is a big one. As AI hits the field, artificial intelligence is offering technologies like model context protocol, MCP, interconnected systems, the ability to move data between your CRM, your operation system, your ERP financial system, your sales system, all of that in near real time. And then AI is able to look at that in between them. We call it connected intelligence, the ability to look between it. We've spent decades, if you look at a process diagram and you have triangles and boxes, we've looked at the boxes and gone as deep as we can, but we're now able with AI to look at the triangle, to look at the handoff to the next step of the process and the receiver of that process in a more rapid, like IOT sensor type of way. And you should be able to look at your processes today from how connected is my ERP, how available is my data? Could not necessarily do I need a two hundred to two hundred and twenty thousand dollars a year financial analyst on staff, or do I need someone that is close to comptroller that understands the nature of the business, maybe managerial accounting, as well as gap financial style accounting, and can ask questions into the AI and get those results back. That person's probably going to be more useful. How quickly does that person learn new skills? The ability to interact with systems that are less about user experience and more about interactive activity with agents. Agents, we're heading into the agentic flow here in 2026. I'm not going to say that Europe has to have all of those things, but they need to be prepared for it today. You have to have the ability to interconnect into your system, feed data into it, get data out of it. You need to have AI quality analytics and agents that can inspect that data, have observability so you know what the agents are doing. You can validate correctness and confidence levels, allowing you to move much, much more rapidly than you do today. The way that you look at those folks that you hire in your department are going to change. You're not looking for the domain knowledge, deep, masterful skill set like you were in the last few decades, where you're hiring a very specific surgeon level skill set. You're looking for generalists that understand how to collaborate and coordinate across multiple agents, get a data, be able to surface the right data so the business decisions can be made quickly so that you could be a true finance partner to the business side of your company. So they can make risk based business decisions. And you wanna be able to do that quicker because speed and velocity is gonna own the day over the next two to four years.

Megan - 48:51: Evan, thank you for sharing such practical experience-driven insights.

Evan - 48:56: You're absolutely welcome, Megan. Thank you for the opportunity.

Megan - 48:59: This has been an incredibly valuable conversation for finance leaders navigating ERP decisions that will shape their organizations for years to come. To all of our listeners, please tune in next week, and until then, take care.