The Art & Science of Implementing an FP&A Solution with Expert Chris Wilson

Thank you everyone, for joining us for this session. We're super excited to have you here with us as we talk about implementing your FPA tool. That's a real challenge we all face. And so for this session, I'm going to be chatting with Chris Wilson, who's an expert in this area. He works for qbit. And so where I want to start this session is, Chris, can you just tell us a little bit about yourself and your background, what you do for work?

Sure, Paul. Thanks for having me. Chris Wilson, Director of Services Delivery with Qubit Qubit, as a company, is a consulting company, and we work with our business partners who are typically the software vendors that own these planning tools. And, and we implement planning tools with our customers, kind of tailor fitting the planning tool to their business process, their industry, that kind of thing. So my background is in implementing and architecting these planning systems for some of the biggest companies in the world. I've worked with multiple technologies across all industries and really worked with a variety of planning processes and, and methodologies.

Thanks, Chris. As I'm chatting here with Chris, please feel free to put any questions you have in the chat. Let us know any concerns you have, and we'll do our best to address some of those as we chat here today. So, you know, when I think of putting in a FP and a tool, for me, the first step starts with figuring out what you need, why you need a tool, and what you wanted to accomplish. You know, you talk to a lot of companies about that. How should people think about that? How should the company think about that process before they start looking for a tool?

Yeah, it's a good question, Paul. I think before an organization or an individual starts to look at a planning tool, they really need to take a step back and master their business process. So kind of saying that somebody taught me once that stuck with me is the planning tool should support the business process and not the business process should support the tool. So kind of take a step back and think, in a perfect world, if there was no resource constraints, what would the ideal planning process be for our organization? Would we do it top down? Would we do it bottom up? Would we keep it centralized? Maybe just finance? Or would we involve more members of the organization to kind of put their input into the forecast and budget? So I think if you can master that business process and really not let the tool dictate what the process is going to be. For example, a lot of organizations that we work with are stuck in Excel and maybe they want the sales team or the marketing team to put their inputs into the tool. But it's too much of a hassle to send out Excel templates, compile those Excel templates, and kind of have some sort of Excel mess of a budget, so they don't do it. But really that's what they should be doing to get a more accurate budget. So I think thinking about what the ideal business process will be or should be is the first step. And then once you kind of have alignment internally on what you'd like the business process to be, then you can start to go out in the market and look for different tools, their strengths and weaknesses, and see which tool is going to line up best with your business process.

I think you make a great point. I really like the one of the tool should accommodate your business process versus you have to change all your business processes for the tool. Does that mean they may. There may be some changes you have to make? Always a possibility. Because, you know, no tool has unlimited flexibility, but you shouldn't let it drive your processes. For sure. Totally agree with you on that. And I'm curious, you know, this is a very crowded market. There's a lot of tools out there today. It's one of the reasons we have this annual showcase is to help people see what's out out in the market. But any advice you'd offer or thoughts of how companies should go about kind of putting together a list or figuring out how to start that process of just looking for the right tool for them?

Yeah, Overwhelming, I think is a good way to describe the marketplace if you're looking for a tool. So there's a couple things that I would recommend an organization that's in the market for a tool. Probably the first thing is kind of surveying your internal team and see if any members of the team have experience with certain tools, whether at this organization or even maybe at a previous job where they worked with a certain tool and they liked a certain tool, or they at least had experience with a certain tool. I think that's important because all of these different tools, while they essentially accomplish the same thing, they can do it in different ways and they kind of have different terminology of how they're doing it. So, for example, some tools might call it cubes, dimensions, some might call it tables or kind of grids or different things like that. So even small things like terminology of what you're working with in the tool, if you have members of the team that are familiar with certain terminology and how certain tools work, that's going to be a big asset to you as you Implement a certain tool so that you're speaking the same language as your implementation partner from day one, a little bit nicer than say, two different brand planning tools. Additionally, you can sometimes bundle licenses kind of under the same brand and gain some licensing price reduction that way. But in general, I would say be careful of what you're looking for in kind of where you're sourcing your data and your recommendations for a planning tool. Because I think there are a lot of ulterior motives out there in terms of who's recommending what and kind of why they're recommending it. So be very careful. And if you do start to go down the path of selecting a tool or shortlisting a number of tools, I would always recommend that you essentially send your data over to whatever tool you're looking at and instead of getting some generic demonstration from them of their pre built asset, but you don't really know what's going on. It could be smoke and mirrors. Send them your data and say, hey, we have an allocation process that needs to be done A, B and C, and here's our data. We want to see the tool that you're presenting, handle our data and see, for example, can it handle the amount of data? Is it fast, is it clunky? So that's a common thing that we do at Kyubit, is we'll sign an NDA with a prospect, call it, and then we can get their data so everything's protected that way, and we'll put their data in whatever planning tool they're looking at and let them see their own data kind of going through whatever we're presenting so that they can be comfortable with what they're buying.

Great, great point about sometimes demos can be smoke and mirrors, and it's always best to do that due diligence and make sure they can handle your data. And it does what it's supposed to with your, with your data, because that's kind of the proof in the pudding, so to speak. So say you've gone through that process, you've now selected your tool. How do you ensure the implementation goes well? What's the, you know, first thing you should really think about when you move into that implementation phase.

Sure. So I think in terms of concrete recommendations, at the top of my list is making sure that your data is in order. So these tools, as good as they are, they really can be garbage in, garbage out, if what you're feeding it is messy, inconsistent, that kind of thing. I mean, these tools are not a magic wand. Right. They can be powerful, but they need to be set up and implemented the right way. So making sure your data is in order is probably the the one a thing on top of my list. And then another thing that I found in doing implementations of these these types of tools is it's helpful to have really at least one owner of the system ideas in order. It's probably the one a thing on top of my list. And then another thing that I found in doing implementations of these these types of tools is it's helpful to have really at least one owner of the system. Ideally, what I've seen is it's best when you have a really what I've seen is it's best when you have a functional owns the tool from functional side and then someone from the IT side who owns the tool as well. From the technical side, data side, anything that's kind of more on the technical side. So if you have at least one individual that kind of has a sense of ownership, is involved in the selection process, and essentially let's say they got the tool that they wanted, they have kind of personal stake in the success of the tool, they're invested in it, then that makes things so much easier. Rather than a tool kind of getting thrown on a group of people. Nobody knows kind of why we chose this tool or who owns it or why we're even doing this. That's really a recipe for failure, right? Versus if you have someone who is kind of the owner, the buck stops with them. You always have kind of that person you can go to if and when there's an issue. I think that's really important to kind of label that person or persons up front.

Makes a lot of sense. Two things there, the garbage in, garbage out. I wish I had a dollar for every time I heard that phrase. I think I would have been rich just from the last week alone with AI coming. But you know, the other thing you mentioned is having that clear owner. I think those are both huge. We had a question come in and I'll go ahead and take this one and then I'll come back to you with another question. Chris, Catherine asks at what stage of company do you see the inflection point for adopting a tool? And I'll welcome your thoughts as well. Catherine. I think for me, generally when I see people really wanting a tool is when they're in what I call Excel help. They've got big enough that it becomes really difficult to share a lot of files and to have a lot of different versions and to manage integrating all the data in Excel. And that's different for every company. When that happens, that doesn't mean you can't adopt the tool at a very early stage. There are tools designed for startups, there are tools designed for fractional CFOs, but typically what I generally see is at this point, you usually have either a dedicated FPA person or person who's spending a lot of time on FPA before you start considering a tool. You have enough employees that it's difficult to manage hedge count and generally you're scaling. That's usually when I start to see people go, hey, maybe I should look at a tool. And you know, some can manage for a while in that environment and some are like, nope, I'm going now. The more legal entities you have, I think the more complexity in the process. Anything you'd add to that, Chris? So when you think kind of you hit that point where it's like, I gotta do something.

Well, I'd also like a dollar for every time I heard the word Excel. Hell, in this line of work. But I think you hit the nail on the head. Another way of thinking about it is when your financial analysts are spending their day being kind of data manipulators, data organizers, then that's kind of a sign that, hey, my analysts don't have any time to analyze and kind of really model the data. They're just spending their time organizing Excel workbooks. I think that's kind of a telltale sign as well that, that, hey, I think we need to gain some efficiency here, let our analysts analyze and kind of stop having them spend so much time just dealing with Excel Health.

Yeah. So you mean if I'm, if I'm spending my full day just dealing with data and then trying to do my day job in the evening, that's a bad recipe.

Nobody ever does that, right?

No, never. We have a few more questions coming through, but we'll hold those for a minute. I have another question I want to ask you here. So you've selected the tool, you started that implementation process. If you're going to use a third party for implementation. I know some of the tools do it internally, some do both. Use a partner and internally. Any advice? You know, to make sure you get a good partner, things you should do similar. Like you mentioned, the tool, you want to make sure you test it. What are things you should do to make sure you're partner is going to be a partner and not just dump it on you as soon as they can? We've all seen that happen, right?

So, I mean, I Think that the easy cop out answer here is ask for references. But to be candid, if you ask a potential partner for a reference, they have a handful of people that are on speed dial that are going to be obviously good references for them. So really I wouldn't expect anything different from reference. So what I would recommend is talk to the software vendor themselves that you purchase the software from and say, hey, who are your top partners that you work with that you give your most complicated projects to that have been able to really solve some of your toughest problems? Because most of these software vendors, they care about selling the software and collecting kind of the support money and the license fees year over year after the sale of the software, they are mostly done with you and they are kind of handing the rest of the process off to a partner. So it's kind of out of their hands at that point. So they are incentivized to make sure that you as the purchaser are continuing to have a good experience with this software. And so they, at that point, like I said, they're kind of done in the process and they're handing you off to a partner. So they really want to get you their best partner. So if you ask them, hey, who are your best partners? Typically they have a short list and that they'll recommend to you right away. So that's what I would say beyond just kind of the generic reference call. Because let's be honest, if you're going to get it on reference call, it's going to be a glowing review 99% of the time.

It's kind of like, right, checking references. When you apply for a job, if that person you call gives you a bad reference, that's a sign you probably should run because in theory, we all select our best references.

Exactly.

You got to take it with a grain of salt. It's not a bad thing to do. But I agree with you, you got to go beyond that. So I want to ask one question that we had from an audience here and just kind of get your thoughts. So Julio asked, what is the average time you have been seeing for an implementation? Among what they said among the best solutions and what is the milestone to measure when that implementation phase is done? So the first one, what's kind of the average time you're seeing for implementations? I know that's going to vary a lot depending on complexity and size.

Yeah, again, cop out. Answer is it depends. But I will say it depends on the size of your organization and the size of your planning process, if that makes sense. How Many, basically how, how many people you're involving in your planning process, how many legal entities you're involving in your planning process, and really the sheer amount of data. So for points of reference, I would say at Qubit, we work a lot with Fortune 500 companies. If you're doing an enterprise wide planning implementation at a Fortune 500 company, so when I say enterprise wide, that's the, the full PL budget, bottoms up, you're typically looking at six to 12 months or more implementation time. Just because there's so many factors to consider, so many stakeholders that essentially need certain things within the tool, so many requirements to account for. If you're maybe more of a mid market company, small market company, you can stand these planning tools up fairly quickly in a matter of, I would say months. So anywhere from one to four months, depending again on what your requirements are, what your business process is, and of course what tool you pick, because there are certain tools that can implement faster than others. So hopefully that gives you some insight. Julio, in terms of implementation times.

Thank you. And that, that sounds about right to me. When you mentioned kind of the Fortune 500, your six months plus mid market, some maybe as quick as a month to a few months, if you go with something very basic, you might get something right away, but you're not getting any customization. You're just kind of taking your data and giving you a standard template, so to speak. So the way I like to think of it is more customization, the more you're going to extend that implementation time.

Yeah, and again, I mean, the whole idea of a planning tool is going back to one of the mantras I said earlier, which is your tool should support your business process. Right. So you don't. I mean, I wouldn't say you should buy a tool and then just take everything the tool has out of the box, because it is very unlikely that a tool is going to read your mind and have your business process perfectly nailed right out of the box. So if you kind of buy a tool and you say, yeah, we'll take everything out of the box, in a lot of ways you're kind of in the same place that you were before, where you're kind of altering your business process to whatever the tool can do.

Great point. I really like how you said that. So you mean it's not going to. I thought the AI overlords were going to read our mind soon.

I know, right? I'm still waiting for that too.

So. So next question I have for you is as you kick off that implementation process, who are the key people you need to make sure you involve in that process? Who should be in the room to make sure you have a smooth implementation?

So I mentioned earlier, kind of designating at least one owner of the solution is important. So beyond that you really want to, I would say when you're kicking off a project like this, have what's called a core team, and in the core team have your business process perfectly nailed right out of the box. So if you kind of buy a tool and you say, yeah, we'll take everything out of the box, in a lot of ways you're kind of in the same place that you were before, where you're kind of altering your business process to whatever the tool can do. Maybe you have one representative from each area of stakeholder, so maybe someone from the business team or the end users that can represent that. Maybe someone from it, maybe someone from finance. Right. So all the stakeholders having what's called the core team and usually it's like a half dozen people, if not maybe a few more. And then you have the broader team, which is really every end user of the system. So core team involved in the implementation throughout, very helpful in terms of requirements, initial testing, that kind of thing. And then the broader team, which is really the full end user base, not so involved in the day to day, but are going to become pretty important towards the end of the process when we get to the testing cycle.

Great point. I really like how you said that. So you mean it's not going to. I thought the AI overlords were going to read our mind soon.

I know, right where we're going to want as many of those people as we can. I'm still waiting for that too.

So next question I have for you is you kick off that implementation process, who are the key people you need to make sure you involve in that process? Who should be in the room to.

Test the tool, kind of shake it out, make sure that it's meeting not only the core team's requirements, but the broader team's requirements as well. And then kind of another nifty thing that I've picked up over the years is when you get to that, make.

Sure you have a smooth implementation.

So I mentioned earlier, kind of designating at least one owner of the solution is important. So beyond that, you really want to, I would say when you kicking off a project like this testing period, you can kind of try to kill two birds with one stone doing a training and testing phase. So typically when you roll out a new tool, you need to train People on it. Right. Just like Excel, we all have to learn Excel at some point. So when you roll out a new tool, have what's called a core team. And in the core team you have one representative from each area of stakeholders. So maybe someone from the business team or the end users that can represent that. Maybe someone from it, maybe someone from finance. Right. So it's not that it's going to be difficult, but it is something new to learn. Right. So there will be some aspect of training no matter what tool you select. But what I found, well is you can essentially give some basic training on the tool and then when the broader group is in there testing, they're all the stakeholders having what's called the core team. And usually it's like a half dozen people, if not maybe a few more. And then you have the broader team, which is really every functionality, but they're also getting used to the tool, they're training themselves, they're picking up tips and tricks. So that's kind of one of the techniques that I like. End user of the system. So core team involved in the implementation throughout. Very helpful to use my implementations that generally gain some efficiency.

I like that. Thank you for sharing that. So next, next question I want to ask you here is do you have a framework you like to use to help manage and guide the implementation process? Like is there a standard framework that you share with your customers or that you go through with this process?

Sure. So we follow what's called sdlc, which is a typical software, it's called software development in terms of requirements, initial testing, that kind of thing. And then the broader team, which is really the full end user base, not so involved in the day to day, but are going to become pretty important towards the end of the process when we get to the testing cycle where we're going to want as many of those people as we can to life cycle. So if anyone's implemented any kind of really tool doesn't have to be planning tool. The SDLC is the main pillars are your design phase and then once you kind of nail down your design, you get into the build phase and then after build you test the tool, kind of shake it out, make sure that it's meeting not only the core team's requirements, but the broader team's requirements as well. And then kind of another is the testing phase and then the deploy phases. Nifty thing that I've picked up over the years is when you get to that testing period, you can kind of try to kill two birds essentially when you go Live with, wear tools. So of those four phases, I would say the design phase is definitely the most important. So think of the design phase as where you're going over all the requirements and you're coming up with a blueprint of what you want the end solution to be. So kind of just like building a house, right? The design, the blueprint is the most important part. Once you emerge with one stone, doing a training and testing phase. So typically when you roll out a new tool, you need to train people on it, right? Just like Excel. We all have to learn Excel at some point. So when you roll out a new tool, it's not that it's going to be difficult, but it is something new to learn, right? Agree on what it should look like, then you can kind of have your worker bees go off and build it. Another thing that we do at kyubit, if anyone has really been involved in any kind of project or implementation, doesn't have to be planning. There's a couple different project management philosophies out there that are popular. So there will be some aspect of training no matter what tool you select. But what I found, well, is you can essentially give some, some basic training on the tool and then when the broader there's agile, there's waterfall. Agile is really more of a. It's done in really two week or so increments where your group is in there testing they're functionality, but they're also getting used to the tool, they're training themselves, they're picking up tips or kind of coming up with a list of a few things that you're going to accomplish in a few weeks. And then after that's done, you're going to kind of come back to the drawing board, see where you are, come up with another list of things. So it's designed to be flexible. If things take longer or shorter, then you can be flexible, add things, that kind of thing versus waterfall is kind of more, less flexible, I guess you could say, where you're kind of coming up with an end date and you're kind of from the start saying words and tricks. So that's kind of one of the techniques that I like to use my implementations that generally gain some efficiency.

I like that. Thank you for sharing that. Next question I want to ask you here is do you have a framework you like to use to help manage and guide the implementation we're going to.

Do this day, this day, this day, all the way throughout. There's not a ton of room for flexibility in there. What we do at Qubit is we have termed something like a hybrid of agile in waterfall we call it agifol where we take the best of both project process.

Like is there a standard framework that you share with your customers or that you go through with this process?

Sure. So we follow what's called sdlc which is a typical software. It's called software development life cycle. So if anyone's implemented any kind of management kind of methodologies where a lot of times when we do these projects our customers will have an end date that they're trying to hit. Right. So for example, we're implementing a project right now with a customer. They may say we need this tool to go live September 1st because that's when we start our budgeting cycle for the next year. Really tool doesn't have to be a planning tool. The SDLC is the main pillars are your design phase and then once you kind of nail down your design you get into the build phase and then after build is the testing phase and then the deploy phases. That's common in most of our implementations where we do have a target date that we're working towards. But we also like the contents of the Agile philosophy where we can be flexible with what we're building each and every week. We don't need to from the start. Say during the week of July 12th we are going to do X, Y and Z. Right. That's kind of hard to predict out in the future. So we, we do kind of keep the flexibility of agile where we know where we want to get to but how we're going to get there. We're going to be flexible essentially when you go live with wear tool. So of those four phases, I would say the design phases definitely the most one how we do it.

Got it. And I really like one thing you said is most important is design. I say that again and again when it comes to building a function.

So think of the design phase as where you're going over all the requirements and you're coming up with a blueprint of what you want the end solution to be.

So kind of financial model. And it's true with just about anything. The other thing you mentioned last question is testing and tell kind of a funny story. I worked on a software project and somebody submitted a bug after doing testing and the software vendor came back and told us that is not a bug, that is undesirable functionality because they didn't want it classified as a bug because it would hurt their performance ratings for the payout. I just had a laugh. I'm like okay, I guess undesirable functionality. Either way, it's not what I want.

But yeah, who do I speak to for that?

Yeah, exactly.

Just like building a house, right? The design, the blueprint is the most important part and once you agree on what it should look like, then you can kind of have your worker bees go off and build it. Another thing that we do at Qubit, if anyone has really been involved in any kind of project or implementation, doesn't have to be planning. There is.

It was pretty funny. But we got a few more questions coming in. Before we do that, I'm going to ask you one more question, then we'll go through a few questions and I'll give you just a minute to kind of wrap up and share any last thoughts. So the question I want to ask is what are the biggest mistakes you see companies make when implementing tools and any advice on how to avoid them?

A couple different project management philosophies out there that are popular. So there's agile, there's waterfall. Agile is really more of a, it's done in really two week or so increments where you're kind of coming up with a list of a few things that you're going to accomplish. Sure, I mentioned, I mentioned this before, but the biggest thing 1A for me is data. So a lot of times companies will want a planning tool but their data isn't in order and kind of. Here you go, here's a dollar, Paul. Garbage in, garbage out, right in a few weeks and then after that's done, you're going to kind of come back to the drawing board, see where you are, come up with another list of things. So before you bring or it's designed to be flexible, if things take longer or shorter, then you can be flexible, add things, that kind of thing versus waterfall is kind of more, less flexible, I guess you could say, where you're kind of coming up with an end date and you're kind of from the start saying we're purchase a planning tool or bring an implementation partner in. Make sure that your data is in order. When I say data is in order, I mean things like utilizing a data warehouse where possible so that you can kind of have a centralized location of where all of your input data that's going to be going into model comes from keeping consistency in how the data is formatted. I'm going to do this this day, this, this day, this, this day, all the way throughout. And there's not a ton of room for flexibility in there. So what we do at Qubit is we kind of have termed something how things like blanks and zeros and nulls are treated between different tables and that kind of thing, consistency in the columns of data so that every time you get a file or load from a certain data source, it's the same consistent setup. So when I say kind of clean up your data, make sure your data is not messy, those are kind of some concrete examples of what I mean by that. The second thing I would recommend in terms of like a hybrid of Agile and waterfall, we call it agifol, where we take the best of both project management kind of methodologies, where a lot of times when we do these projects our customers will have an end date that they're trying to hit. Things to watch out for when implementing a tool is making sure that your core, I'll call it core team. We talked earlier about our core team and the broader team making sure that the right. So for example, for implementing a project right now, core team is adequately or has adequate time to put into this project because if you think of it, the implementation partner, which is usually someone like me and my team from Qubit, this is our full time job, right? We work usually one project at a time and with a customer they may say we need this tool to go live September 1st, because that's when we start our budgeting cycle for the next year. So that's common in most of our implementations where we do have a target date that we're working towards. But we also like the contents of the Agile philosophy where we can be flexible. This is all we're working on. And from the client side, from the customer side, people usually have their, their day job, right? And then they're doing kind of this implementation on the side. They still have their deliverables that they need to do and everything else that goes along with their day job. And I would say probably eight or nine times out of ten where we're with what we're building each and every week. We don't need to kind of from the start, say during the week of July 12, we are going to do X, Y and Z, right? That's kind of hard to predict out in the future. So we, we do kind of keep the flexibility of agile where we know where we want to get to, but how we're going to get there, we're going to be flexible, burning budget, or maybe not being as efficient as we can is because the client can't keep up with the pace that we're developing, requiring testing, requiring feedback, that kind of thing. So if you want to kind of get the most bang for your buck, get the most efficiency out of your consultants. Make sure that the people that are working with your consultants day in and day out can kind of keep up with them and provide them what they need so that they can keep moving forward.

I'm not surprised to hear you say that. I mean, I heard someone say in the implementation process, maybe 30% of the time is consultant working and 70% is something with the customer either waiting for data to be cleaned up or getting an answer or other things like that. I've heard how we do it.

Got it.

And I really like one thing you said is most important is design. I say that again and again when it comes to building a financial model, and it's true with just about anything. The other thing you mentioned, last question is testing and tell kind of a funny story. I worked on a software project, and somebody submitted a bug after doing testing, and a few people say, so it's definitely a challenge. So the more you can dedicate a resource, the better. We all are busy, and so it's a balancing act, but I imagine it goes smoother when they really give you the attention you need versus you having to figure some things out from time to time because you're not getting responses, of course. Yep. Yep. All right, so a couple more questions here, and then I'll just kind of give you. A software vendor came back and told us that is not a bug. That is undesirable functionality because they didn't want it classified as a bug because it would hurt their performance ratings for the. The payout. I just had a laugh. I'm like, okay, I guess undesirable functionality. Either way, it's the last word. As we just have a few minutes left. We'll skip the beard question that somebody asked about me braiding my beard. We'll. We'll bring that up later. Thanks, Nate. I appreciate you bringing some humor to the session. So I'll. I'll take this question from Scott, as I know you mostly kind of deal with larger tools, but I had a question. How should we differentiate FP&A tools intended for fractional CFOs who serve clients of various sizes and what I want.

But, yeah, can I. Who do I speak to for that?

Yeah, exactly. It was pretty funny. But we got a few more questions coming in. Before we do that, I'm going to ask you one more question, then we'll go through a few questions, and I'll give you just a minute to kind of wrap up and share any last thoughts? So the question I want to ask is what are the biggest mistakes you see companies make when implementing tools is different business sector versus a single enterprise solution. Scott It's a great question. I'd say most tools are initially designed to be an enterprise solution or mid market or whatever but a single company, if you look at their website they're usually going to talk about fractional CFO if that's a core and any advice on how to avoid them?

Sure. I mentioned I mentioned this before but the biggest thing 1A for me is data. So a lot of times companies will want a planning tool but their data isn't in order and kind of here.

You go area they support. That doesn't mean they may not be able to support it but generally those are going to be your smaller market tools, maybe a few in the mid market that support that. Really none of your enterprise tools are going to advertise fractional because they're just so different. It's a different purpose. I recently shared on LinkedIn a market landscape and one of the categories I shared were some some of the tools that support fractional by no means is a complete I'm also happy if any of you want to message me to talk a little bit more about this. I'm hoping to have something out here in the next month or so that will provide more information around that. But I will say there are definitely more and more tools that are exploring that even some of them we have.

On the Here's a dollar Paul Garbage in, garbage out, right? So before you bring or call very.

Much supporting fractional or looking into it, you know some in the market guide, some that attended last year so they're.

Purchase a planning tool or bring an implementation partner in, make sure that your data is in order. When I say data is in order I mean things like utilizing a data warehouse where possible so that you can kind of have a centralized there are.

Tools out there and the biggest thing I'd look for is something that says look, we provide fractional. We have a way where you can load multiple different data log into different accounts because that's something that has to be done in the design to really be a fractional tool. Otherwise it becomes a challenge. And then another question we had location.

Of where all of your input data that's going to be going into model comes from keeping consistency in how the data is formatted and I love to.

Get your thoughts on this one Chris. I think it's an interesting question given where we're at right now so Is.

FPA software vendor how things like blanks and zeros and nulls are treated between different tables and that kind of thing, consistency in the columns of data so that every time you get a file.

Or implement new, you know, gen AI ML capabilities into their offerings. How should we prepare a finance team member? Do you think there's something different we need to do to prepare them to leverage these capabilities?

Load from a certain data source. It's the same consistent setup. So when I say kind of clean up your data, make sure your data's.

Not abilities like does training need to change any thoughts as we're, you know, going into the kind of this whole new AI world, so to speak.

That's a great question. It's definitely the messi. Those are kind of some concrete examples of what I mean by that. The second thing I would recommend in terms of things to watch out for when when implementing a tool is the buzzword of the industry right now, I would say what we're seeing where making sure that your core, I'll call it core team. We talked earlier about our core team and the broader team. Making sure that the AI and machine learning is within the Office of Finance I'll call it where it's going to be utilized best is still very much an open question. We do kind of all kinds of planning, so not just financial planning, we do a lot of operational planning as well, SOP that kind of thing. Core team is adequately or has adequate time to put into this project because if you think of it the implementation partner, which is usually someone like me, I would say the AI machine learning is a bit more defined on that side where it can kind of help you with specific operational things like demand, quantity, fulfillment, that kind of thing. But in terms of the finance side, the Office of Finance side, I don't think there is any clear in my team from qubit. This is our full time job, right? We work usually one project at a time and their guidance or kind of best practices. Yet in terms of how to use AI machine learning still very much kind of in its early stages. So if you're an early adopter type of organization where you like to pull in AI machine learning, I think you really I would recommend just this is all we're working on and from the client side, from the customer side, people usually have their day job, right? And then they're doing kind of this implementation on the side. They still have their deliverables that they need to do and everything else that goes along with their day job. And I would say probably Eight or nine times out of ten where we're try different things, there really isn't a playbook to follow yet in terms of AI machine learning. So not a great answer there, but I would say try different things. Try using some of the tools, for example, have generative AI where there's like a chatbot in your dashboard, you can burning budget or maybe not being as efficient as we can is because the client can't keep up with the pace that we're developing, requiring testing, requiring feedback, that kind of thing. So if you want to kind of get the most bang for your buck, get the most efficiency out of your consultants, make sure that the people that are working with your consultants, they basically say what's my revenue growth for fiscal year 2025? And the chatbot AI will kind of go look in your system, pull out the information you need and kind of return that for you. So I think that's one use case that we've seen where maybe 4 higher level in day out can kind of keep up with them and provide them what they need so that they executive users of the system that don't have time to kind of go into the details or dig through the tool and they want to just get certain high level points using like essentially the equivalent of ChatGPT in their planning tool to say hey, how did we do in terms of keep moving forward.

I'm not surprised to hear you say that. I mean I heard someone say in the implementation process, maybe 30% of the time is consultant working and 70% is something with the customer either waiting for.

Data of actuals versus forecast in Q2.

And having to be cleaned up or getting an answer or other things like that.

I've heard us the tool pull that back. So that's what I would say. What we've seen so far, great.

And I appreciate that. And we're just a minute over, so I'm just going to add one thing to that and then we'll thank our guest here and wrap up. But what I would say on the AI is there's a lot of great people to follow. I've done a few podcast episodes of some of these early adopters of how a few people say so it's definitely a challenge. So the more you can dedicate a resource, the better. We all, we all are busy and so it's a balancing app. They're thinking about gen AI and trying to use it. At this point the biggest advice I give is start using it, get familiar with it. Because in a couple years every company will be using it. I don't know that you need to completely change the way your staff is working. I think think there's but I imagine it goes smoother when they really give you the attention you need versus you having to figure some things out from time to time because you're not getting responses.

Of course. Yep.

Some areas where you might need to be a little more technical, especially if you're going to start using code. Yep. All right, so a couple more questions here and then I'll just kind of give you a last word as we just have a few minutes left. We'll skip the beer interpreter and some of the python to make sure you're getting right results which could save you a lot of time. And I think there'll be more strategic needs. But the biggest advice I'd have is follow some of those people who are leading the way out there, look at some of the trainings and spend time edging question that somebody asked about me braiding my beard. We'll, we'll bring that up later. Thanks Nate. I appreciate you bringing some humor to the session. So I'll, I'll take this question from Scott as I know you mostly kind of dictating yourself because, because it is going to save us time in many different ways and we need to be prepared. But I don't know that there's a clear pill with larger tools. But I had a question. How should we differentiate FP&A tools intended for fractional CFOs who serve clients of various sizes and a playbook for any of us yet we're still kind of all figuring it out and learning and it's a pretty amazing time on that front. So with that, any last thoughts or words you'd like to ask before we close? There's a different business sector versus a single enterprise solution. Scott, It's a great question. I'd say most tools are initially designed to be an enterprise solution or mid market or whatever. Chris.

Nothing for me. I just want to thank you Paul for having me. It's been a lot of fun being.

On here but a single company, if you look at their website they're usually going to talk about from fractional CFO.

If that's a core talking shop with you and if anybody has any questions for me, please feel free to reach out. Chris Wilson, Cuban Consulting feel free to connect with me on LinkedIn.

Happy to area they support. That doesn't mean they may not be able to support it, but generally those are going to be your smaller market tools. Maybe a few in the mid market that support that really none of your enterprise tools are going to advertise.

Answer any questions and talk some more.

Thank you so much Chris and thank you for joining this session. The next session will have another demo here starting in about eight minutes at the at 30 pass. So we'll look forward to seeing all of you. We have four great vendors still to go today and then we'll have a wrap up session. So thank you so much for joining us. Is fractional because it's they're just so different. It's a different purpose. I recently shared on LinkedIn a market landscape and one of the.