Full episode transcript: AI & PE: The Future of Value Creation

Guest: Ash Pembroke, Managing Director, AI Strategy and Value Creation, Accordion | Host: Kyle Roemer

Ash Pembroke: What is the forecast — the ML forecast orchestration skill for finance? Someone has to own that. That’s a technical artifact, and that’s a place where the technology teams have to step up and learn about the business, versus the business teams leaning more into the tech.

Kyle Roemer: Welcome back to AI & PE: The Future of Value Creation. I’m excited to welcome back Ash Pembroke from Accordion’s AI Strategy and Value Creation team. Ash works closely with sponsors and portfolio companies on value creation initiatives using AI, data, and technology to move from experimentation into real operational impact. Today, we’re diving into Accordion’s latest AI at Scale survey report, which benchmarks how private equity firms and portfolio company finance functions are adopting AI today. The report shows a market in transition. Most firms have moved beyond pilots, but far fewer have the data foundations, operating playbooks, CFO ownership, and governance models required to make AI scale across the portfolio. Welcome back, Ash.

Ash Pembroke: Thank you for having me.

Kyle Roemer: All right, Ash, let’s get into it. One of the main takeaways from the report is that fewer than 30% of companies are working from a formal AI playbook, or even have an AI CoE. What does a real AI playbook or CoE — whatever vernacular you want to use — look like in practice?

Ash Pembroke: That’s a question where I think the answer changes depending on the size of the company and the scale of the portfolio. Candidly, I think larger organizations need to manage their change differently than smaller groups. What I think is interesting about that statistic, though, is that the asks from our customers have changed. I’ll give you a couple of examples. Last year, there were a lot of use-case-shaping engagements — lots of identification of value. This year, there are more formal, and I’d say larger, requests for transformative programs. Yes, deliver AI use cases — but how are you going to train my team? So, change management, adoption. I’d say the playbook is getting created as we experience a bit of a lack of value from some of these AI engagements. And that’s necessitating a playbook that includes the transformation of functions, documentation of business processes, and user enablement — using real use cases, real training, and documentation on stuff that’s actually real, not just abstract AI courses.

And I think the elephant in the room is cost and value. How do you federate — or at least make transparent — what teams are consuming, and figure out whether that’s actually driving the value you expected? Because in many instances, it’s a highly variable cost.

Kyle Roemer: It’s interesting that so many of these conversations have evolved. But I keep asking myself — is it really that different from what it used to be with technology CoEs, data CoEs, playbooks you might have created for a variety of other functions, technologies, topics?

Ash Pembroke: I’d say it’s similar in that we’re using all the same language. What’s different is the amount of pressure this puts on end business users to upskill through the transformation. What’s happening right now, at least in my impression, is that the way we’re delivering AI is pushing every single person in the organization to be a little more technical and cross-functional. It’s changing the role of their job. There are a lot of different expectations being pushed down. In the past, cloud transformation happened in the office of the CIO. Marketing technology happened in the customer experience function. AI is happening everywhere. It’s the scale of it being rolled out across every function — whether you’re talking about bespoke use cases, SaaS implementations, conversational analytics, whatever it is.

That, I think, is different. It’s putting a lot of strain on the organization to try a lot of things very quickly and find value. Any transformational AI program has to navigate finding that value through a lot of delivered use cases — not just business cases on a page, because a lot of those assumptions can change. So I think the programs are slightly more complex in their breadth than some of the prior ones I’ve been a part of as a consultant, or as an SI.

Kyle Roemer: I always find this dynamic interesting — when you have such prolific, compelling technologies that anyone can leverage, it gets to a point where you have to ask about governance. How do you actually govern these things well, without limiting too much of the innovation that might happen in a team, a functional area, an engineer, or an analyst? Where are you finding, right now, with your clients, that people are introducing governance well — and where might it be falling apart?

Ash Pembroke: It has to happen at two levels. One is the kind of boilerplate governance that should come with any technology you roll out — are we adhering to our enterprise security standards, do we have monitoring on these tools? That’s the technology part, where you put in safety guardrails that have to be firing. And then there’s this responsible-use, cost-federation piece — does the leader of Function A know what tokens their team is consuming? That’s more of an ongoing governance and management structure, where you should be able to evaluate individual AI use, workflow AI use, agentic AI use — all these different layers. Without strong governance, teams end up surprised by where things go a little awry.

That has to happen at all of those levels at the same time. I know that probably sounds complicated, but in practice it’s not — a lot of those decisions can be made once and pushed out into any implementation of an AI tool. You just have to go through the process of making those decisions.

Kyle Roemer: The last thing you want is to be surprised by your Anthropic or OpenAI bill at the end of the month, or the end of the quarter — which is happening quite a bit right now. Our survey findings highlighted a clear ownership gap with CFOs — only 17% of portfolio company CFOs have formally claimed AI transformation as a strategic mandate. I’m curious, with CFOs in particular — PE-backed CFOs — why does that matter?

Ash Pembroke: There are a couple of layers to that onion. Part of the lack of taking charge is the nature of the finance function itself — if your charter is to be the responsible brakes on an organization, always evaluating cost-benefit, you’re probably going to hold yourself to a very high standard, even in experimentation. So part of it is cultural. But even in interviews over the last month, the Anaplan CEO said something like, “Forward-deployed is a myth — it looks good on a slide, but it’s not really how enterprise-grade workflows in finance should be built.” I don’t think he’s necessarily wrong, when it comes to improper deployment of these tools.

So much of finance is about repeatable outcomes, and generative AI, by definition, has some wildness to it — that’s what we want, some non-deterministic thinking. When you’re designing and delivering workflows in finance that are partially deterministic — I have to use the same template each time, the same data each time — that’s test-driven design, and you can bake in a lot of repeatability and quality assurance. It’s the redesigning of the workflow, where you’ve got that plus a human in the loop, plus a tool that can come up with things like summaries for quarterly reports on its own — how do you do that in a way that’s traceable and auditable? That requires more work than simply turning on enterprise ChatGPT or Claude.

So there’s a cautious approach to figuring out the right workflow to redesign. Do I have the right governance and infrastructure on my financial data to do this safely? For a lot of companies, that’s still a big barrier — the data and governance work, the unsexy work. A significant amount of the work I do in AI use-case delivery involves a data engineer fixing things alongside the AI engineers doing some of the sexier work. That’s simply because we have to do both at the same time to get the quality and output you’d expect as a CFO.

Kyle Roemer: You’re hitting on something we’re seeing so often today, which is finance functions saying, “My data isn’t good enough, I don’t have enough quality,” or “the engineer doesn’t understand my workflow, they don’t have the domain expertise.” I think — and you’re leading the charge on this — the way we deploy teams today to solve this is quite different. Going back to the Anaplan CEO saying forward-deployed is a myth — I don’t necessarily agree with that, but what I do agree with is you can’t just deploy engineers at a problem. You need more than that to solve for these things, and to get some of these use cases to stick and be leveraged in production.

Maybe explain a bit about how we think about — and how you think about — our forward-deployed model of delivering AI use cases.

Ash Pembroke: I disagree with Charlie on FDE being just a leaner technology delivery model — at the end of the day, that’s all it is to him. But I also agree that you shouldn’t have somebody who’s never been a supply chain leader redesigning supply chain forecasting workflows. The way we’ve seen success with our teams is a three-legged stool. You have an expert — for your run-of-the-mill business use case, where you’re redesigning a bit of business process, doing a lot of orchestration and connection, with a lot of end-user enablement and training — so that’s the product owner of the process and solution. You have the architect, whose job is to ensure everything designed is built in a sustainable way, with the security and safety you’d expect — that’s about future-proofing the solution. And then you have the engineer — could be one, could be several.

Kyle Roemer: Sounds a lot like a scrum team.

Ash Pembroke: It kind of still is. I don’t think that model is surprising, but I do think in the very early days of forward-deployed work, there was this idea of the “wunderkind” — that you could drop a savant engineer into the middle of a complex business environment, full of legacy issues, undocumented processes, and bad data, and they’d magic their way into ROI. I don’t think anyone’s surprised that wasn’t the model that won out.

Kyle Roemer: By the way, I wish that were the case — that would be incredible.

Ash Pembroke: Yeah, it would be.

Kyle Roemer: Switching gears a bit — we talk a lot about the state of AI in the finance function. As part of the survey, we asked operating partners what’s blocking AI adoption. Unsurprisingly, 71% cite data readiness as the biggest blocker. Let’s start with the underlying point — why is data readiness so important for the transformations that need to happen right now?

Ash Pembroke: LLMs are really good at finding things that seem similar across a lot of different types of data. If you throw an unstructured-data tool — an LLM — on top of all the SharePoint data, even in our own company, it starts intuiting associations: snippets of text, documents created around the same date or in the same folder. It’s able to make natural associations, and you want it to do that. What you don’t want is for it to make up associations that aren’t authoritative.

I think we’re seeing the enterprise technology stack for AI clump together in ways that make sense. So, unpacking that CFO comment a bit — you’ve got your traditional data-warehouse problem, where maybe you don’t trust the data, or don’t really know what’s in there. Navigating and documenting what’s in a data warehouse — structured data output from source systems — has never been faster with LLMs. We can scan very large data sets and find things like how many numbers, how many times something’s misspelled — that’s the kind of work you do in cleaning up data, and it’s never been faster.

But then there’s the other part — all that data goes into, say, in a CFO’s world, a whole bunch of Excel templates. Maybe your real estate company is evaluating deals for multifamily — that’s a real use case I’ve dealt with. Which version of that spreadsheet do you use? You’ve got 17 of them. They started with one person, and now they’ve proliferated across SharePoint. How do you do version control when you’re having, say, Claude create a spreadsheet? Do you have a naming convention for these things?

When we say data is an issue, it’s also the processes that generate the data that are the issue. Going back through a lot of legacy iterations is sometimes daunting for finance teams, and that’s part of the data-readiness answer too.

Kyle Roemer: The number of financial models that are “F_final_final” — which one do you actually use?

Ash Pembroke: It changes over time, too — there’s not really a right or wrong answer. But I think for leaders, the technology team is no longer the issue. It used to be that you could blame IT and say, “It’s going to take them a year to fix this.” I think we’re figuring out it’s not IT that’s the blocker now — so we’re pushing a lot of decisions back to the business, at a speed they’re not quite used to. Sometimes the natural reaction is to blame the data — and yes, the data is an issue — but you’ve got to make a decision about what the right answer is. Once you tell me that, I can make sure the processes are repeated. It’s more on the business to make decisions and redesign the process. That’s sometimes more daunting than anything else.

Kyle Roemer: Looking at finance broadly — this comes up a lot right now — are companies actually redesigning their workflows, or mostly accelerating and becoming more efficient at existing ones? What are you seeing?

Ash Pembroke: I think both. But the value you get out of one versus the other is very different. Take something like a mortgage underwriting flow, where you’re extracting a lot of intelligence out of documents provided by loan applicants. Machine learning has been doing that work for a long time — you swap in an LLM, and you might get more information extracted, without additional engineering cost, but the traditional ML workflow’s engineering cost has gone down. So the analogy is: the engine’s being swapped out, but the vehicle remains the car. From a driver-experience or business-ownership perspective, there’s not a lot changing. There’s a lot of that work going on — choosing different engines. It’s meaningful work, and from a technology perspective, IT teams see a lot of value in using AI to do the work we’ve been doing for a long time, better, faster, cheaper.

Now, in the finance function specifically, I’m seeing teams — it’s easier to do with leaner teams, more complicated with large teams, say a planning exercise done across multiple BUs — but they’re redesigning their workflow to put AI in the loop with them. That’s a far more sensitive, thoughtful, change-management-oriented task. We end up doing a lot of those — they look like process-redesign engagements, and we design human-in-the-loop checkpoints. I’ll use the word “acceptance criteria” — what answers should you have gotten?

So there’s test-driven design built into all of that — new concepts for a lot of our friends in finance. That redesign pushes the finance function to be slightly more technical, slightly more data-oriented. It’s a bit uncomfortable at first, but I’m seeing champions emerge in finance teams — maybe they were the data scientist of years past, or the IT business partner — but they’re stepping forward to own things like: what is the ML forecast orchestration skill for finance? Someone has to own that. That’s a technical artifact. There are going to be teams that don’t want to take ownership of that within the business, and that’s where the technology teams have to step up and learn about the business, versus the business teams leaning more into the tech.

Kyle Roemer: Agreed. And that naturally leads to certain use cases resulting in P&L impact — revenue, costs, et cetera — and those are the things you should really be prioritizing. Many won’t hit the P&L directly; they’ll be efficiency plays, like some of what you alluded to. But I think a lot of PE-backed companies ultimately want to know: are we going to get credit for this when we exit, and what are the implications at exit? As part of the survey, 86% of operating partners expect buyers to pay a premium for AI-enabled finance capability within the next couple of years. What do you think is actually driving that expectation across the market?

Ash Pembroke: We’ve been talking about transformation this whole conversation, using different words — efficiency, headcount reduction, data cleanup. What you’re actually doing is an incredible tune-up of the finance organization, because a lot of what I’m describing — like establishing your last-and-final model for evaluating a transaction — forces a finance team to make decisions, consolidate decision rights, and work more efficiently overall. It also creates better data, better forecasting quality, more transparency. You could see a world where, in an acquisition, instead of just asking for access to the data room, you might start asking for access to their enterprise cloud environment on top of their data warehouse. Some of this isn’t just about efficiency — it’s about enabling growth, capability expansion, and better results, better telemetry on the business, faster, that helps you make decisions.

That, I think, is very valuable — even if it’s done in the name of AI, the underlying work is what’s actually transforming the function and making it operate better.

Kyle Roemer: It’s so interesting now, as an investor or operating team, what you can actually underwrite to get done in your first year. You might be inheriting a bit of a messy finance and technology situation, and you might have paid less for that at the transaction level. Even the portfolio companies that haven’t fully adopted this yet — as an investor, you can now underwrite, “We’re going to get to a much better place within six months,” when that might have taken two and a half years previously. Could be a legacy code base, could be a full team rebuild — the speed at which you do this now is totally different.

Ash, we have a number of operating partners and investors listening to this episode. What are a few pieces of guidance you’d give them, that they can pass on to their portfolio companies, on moving from pilots to real programs and impact?

Ash Pembroke: Because this transformation impacts so many different parts of the business, and it’s broad in scope, I’d say: pick the right person to be accountable for the transformation, and let them pick their people within each function. There’s a real risk of death-by-committee in these programs — somebody has to actually own it. Within the finance function, if we’re deciding what model we’re going to use for a given view of the business — okay, I own that. If it needs to change, I’m responsible, as the owner of that model, for updating the things that affect how it’s consumed, by AI tools and by other people using those tools. That radical-ownership, small-teams idea.

The other thing I’d say: don’t train and redesign your organization in an ivory tower. There was a bias toward “we’ll just turn on all the SaaS stuff and maybe get our data right, and then my team will go through a cloud-based training that HR puts on, and they’ll become AI engineers, or be able to navigate all these tools.” What we’ve seen actually make the difference is real, delivered use cases. The team delivers alongside the consultants or the technology team doing the hands-on work. The business gets trained through that delivery — they develop a deep understanding of why things work the way they do, what data’s being pulled from, and they’re in a position to own it and have an AI-enabled workflow going forward. You train teams using the use case itself — don’t rely on third-party trainings and certifications alone to transform your workforce. That’s part of why a lot of our AI TMOs spend far more time on evangelism and training than people expect.

And my last point: get something in front of the business as quickly as you can, and expect it not to be all the way there yet. Have a bias toward action, and treat it like a four-to-six-month roadmap, where you’re adding functionality that people are specifically asking for — and they’re enabled enough to ask for the right things. Not simple things they should already know how to prompt their way into, but consolidated capabilities that can live on beyond their own function. That’s what you want them asking for. So: get something in market with the business, and use that to gather more requirements — versus these super-lengthy strategy engagements where you document every use case in the world, build a beautiful PowerPoint deck, and then a new release comes out and all those assumptions change.

It’s hard to get moving if you stay academic for too long.

Kyle Roemer: That’s great advice — really practical things PE firms and portfolio companies can be doing and prioritizing right now. Ash, thanks for being here — this was awesome. I think we covered a lot of ground: where adoption is happening and where it isn’t within the finance function, what’s holding it back, like data readiness, and the fact that it’s not just engineers but domain experts and architects that make these things stick. But fundamentally, you’ve got to start trying things, put things in front of the business, and understand it’s not going to be perfect. This was a really interesting conversation — I appreciate you spending the time.

Ash Pembroke: Thank you.