Ep. 22: Talking AI in ERP with IFS Chief Technology Officer Kevin Miller

AI, Asset Lifecycle Management, and the Future of Manufacturing ERP with IFS (Episode 22)
The Integrate Intelligently Podcast, Episode 22 — with Jeff Bickler, Scott Bickler (CADTALK), and Kevin Miller (IFS)

Introduction to IFS and Key Roles
Jeff: Welcome back to episode 22 of The Integrate Intelligently Podcast. I'm Jeff Bickler, joined by Scott Bickler and today's guest, longtime colleague Kevin Miller. Kevin, great to have you here.

Scott: Always great to have you here.

Kevin: Hey, everybody, good to see you.

Jeff: Kevin, you and I have been working together for a few years now — you're with IFS as Chief Technology Officer, which is a bit of an unusual title compared to what that role typically covers. Can you give us a quick overview of what you actually do at IFS, and how long you've been there?

Kevin: How long do we have — just kidding. You're right, Jeff — as CTO for the North American region at IFS, I'm essentially the chief technical face of the company in front of prospective customers and existing ones. I get to talk about our technology story, but also how customers are actually adopting IFS across our six core target industries — all fairly asset-intensive businesses, whether they're designing, manufacturing, deploying, servicing, or maintaining physical assets. That's where IFS plays well. Under the CTO umbrella, I also oversee pre-sales — both functional and technical teams, plus value engineering and bid management. We're really focused on managing that early life-cycle experience with prospective customers — not just the tech stack itself, but the outcomes we want to deliver for the companies evaluating IFS.

The IFS Unleashed Event Overview
Jeff: We don't get to see each other often, but we were both recently at IFS Unleashed in Orlando. Tell us a bit about that event, its goals, and your role there.

Kevin: This is really our flagship customer event, Jeff — our worldwide user conference, essentially. It's where we get to update customers and prospects on how IFS Cloud, the product, and IFS the company are progressing, but it's also our chance to showcase partners like you — bringing extra value into the ecosystem in places IFS itself might not natively cover. We're something of a challenger brand at the moment, seeing a lot of interest largely due to our domain expertise, but it's really about how we bring the right partners into the equation to increase value for prospective customers. Much like you were at a booth shaking hands, we had a wide range of partners there too. It's our update to both the user and partner community on what's happening with the company and the product — we've made some recent acquisitions and stayed pretty active in that space. It's genuinely our premier customer event.

Jeff: I've attended a few years now, and it really is worldwide — customers from Australia, New Zealand, Europe, Asia, everywhere.

Kevin: It's a real cross-section of our global customer base. North America's obviously an important region for IFS, but we get attendees from 80-plus countries, because with IFS — or ERP software generally — you're looking at a 10, 15, maybe 20-year relationship. This isn't something companies swap out regularly; it's closer to a marriage. So it matters that customers understand where the company and the product are headed, what new capabilities are coming — and these days, everything comes back to AI, which is honestly the most overhyped topic of the century in terms of what people expect it to do.

Long-Term Relationships in ERP
Jeff: I want to pick up on that long-term relationship point — since we work in ERP and engineering software, like you said, people genuinely don't want to switch. It's not some lightweight SaaS app you use for six months and discard — their whole business runs on it. I've had plenty of conversations with customers, from CADTALK's side, asking "we like your software, but what's your relationship with IFS — will you still be here tomorrow?" I'd always walk them through our partnership and reseller relationship, and how we keep expanding that with new integrations and closer collaboration — because customers are just as concerned about the long-term viability of partners like us as they are about IFS itself.

Kevin: Those are genuinely important points. If there's one criticism we sometimes get, it's that IFS doesn't have thousands of technology partners — and that's true, because we do a fairly high level of due diligence. We want to make sure the partners we bring in actually add real value to customers. We don't want ten different partners competing in the same space, leaving customers confused about who to call for support or chasing whatever's trendy that quarter. We're after long-term, strategic relationships that are genuinely value-proven. As the world shifts toward the cloud subscription model — which has become much more common, even in manufacturing, an industry that tends to lag a bit in tech adoption — customers want proof that a solution actually works. When we bring a partner to the table, that's a partner we genuinely stand behind, in terms of the value we know they'll deliver. We don't want to be in the position of saying "well, that didn't work, let's find someone else" — we want partners with real domain experience in the industries we serve, because that just makes the whole experience better for everyone.

Jeff: It makes sense — in that kind of relationship, IFS's own reputation is on the line, essentially vouching for us. It's a lot like recommending an employee — your word matters, and you want that recommendation to mean something.

Kevin: Couldn't agree more. As big as enterprise software is globally, it's still a pretty small world. Selfishly, I want customers I can point to as proof that IFS and our partner products genuinely made a difference. I've known Scott — what, going on nine years now? Maybe longer, I don't want to date myself, but probably past the ten-year mark at this point. CADTALK is one of the companies I've worked with over that entire span where I know, if you're involved, you deliver. That matters more to me sometimes than whatever's newest or trendiest — there's real trust built on the relationship and the work I've personally seen at IFS customers. It's one thing I genuinely don't have to worry about when making a recommendation.

Jeff: Good to know that's the philosophy at IFS — not every software company operates that way; some chase whatever's newest rather than investing in that long-term, trust-based relationship.

AI in ERP: Challenges and Opportunities
Jeff: I spent most of my time at the booth meeting customers and partners, but you had a big part in the event program itself — what were some of the major announcements from IFS, and how did customers respond?

Kevin: Going back to that ever-present AI conversation — our industry has, frankly, done a poor job here, in my opinion, pitching AI as this magic box you open up on the conference table that just fixes everything. One recurring theme I kept hearing from CIOs at the event was real pressure from their boards: "we need to deliver something in AI, but we're not entirely sure what that should look like." That was probably the single biggest topic at Unleashed — what's IFS's actual approach here. I think ours is a bit different from some competitors, because we've launched what we call Industrial AI — AI use cases built specifically around the industries we actually serve. Over the last 18 months to two years, we spent a huge amount of time with customers asking: where could automation genuinely help? Where could analysis help? Given that the ERP is the general repository of transactional data, how can we use that to help customers become more proactive rather than reactive?

Proactive Maintenance and AI Use Cases
Kevin: One early example came directly from a customer: if I've got machinery on the production floor feeding sensor data in, I'd love IFS to analyze that and proactively flag, "hey, we're noticing temperature ticking up about one degree an hour over the last six hours — something's probably wrong, let's dispatch a technician now," rather than waiting for an actual failure that shuts down the production line and cascades into a bunch of downstream problems. That became one of our core use cases: getting much more proactive on maintenance — not just flagging that something's off, but noting, "the last six times we saw this exact fault code, you needed a technician with this specific skill set and certification, and these five spare parts, because that's what resolved it fastest." We're trying to build a genuinely better, more complete experience for everyone involved before an outage even happens.

Advanced Planning and Scheduling in Manufacturing
Kevin: The other major thread is built around what we call our Planning, Scheduling, and Optimization engine — PSO — which came from an acquisition IFS made a few years back, originally designed to optimize very large field service teams: dispatching around traffic conditions, technician skill sets, spare parts availability, that kind of thing. We've taken those proprietary algorithms and machine learning components and applied them to manufacturing. You're both familiar with MRP, material resource planning — it honestly hasn't fundamentally changed in 30-plus years; it's essentially a big calculator weighing demand, supply, and capacity to generate recommendations. Bringing PSO into manufacturing lets us extend that calculator to weigh multiple additional criteria specific to that manufacturer — maybe you care more about prioritizing newer machines over older ones, or specific technician assignments, down to things like paint-color changeovers.

It also lets us surface things like: on this particular routing operation, Scott is 8% more efficient than Jeff. Great — how does Scott do it, can we replicate that? But then the data might also show Scott's actually running 12% higher on quality issues — faster, but maybe not necessarily better. Having that data available proactively, rather than requiring someone to manually run a feasibility study — which takes real time and organizational effort that people increasingly don't have — lets IFS surface exactly where to focus attention strategically.

The last piece of that PSO engine is genuinely advanced what-if scenario modeling. A simple example: maybe I've got a five-week maintenance backlog. If I bring in certain subcontractors, I could shrink that down to two weeks — but my outside costs go up, and it changes my spare-parts consumption forecast. There's a lot of scenario math you can throw at that engine without touching any actual production data, and just having that "what happens if I try this" capability, without committing to a real production change, is genuinely powerful.

Jeff: That's really interesting — I hadn't thought about CIOs essentially coming to IFS and saying "help us help ourselves," because AI is new and nobody quite knows how to apply it yet. Bringing concrete use cases to that conversation is a smart approach — AI gets a ton of fanfare, similar to how the early internet was mostly "you can share recipes online" before the real use cases matured. Is IFS just leveraging data you already had, or are you also expanding what data gets collected specifically to feed these algorithms?

Kevin: Both, honestly — and we're also leaning on partners in this space.

Leveraging Generative AI for Business Efficiency
Kevin: Our proprietary algorithms and machine learning inside PSO are core to that effort, but we're also leveraging things like Microsoft's investment in OpenAI on the generative side. Boardrooms are hearing constant chatter about ChatGPT, Claude, all these generative engines, and asking "how do we use this to become more efficient and stay current?" I think it's a two-pronged approach. We released our first Copilot in May of this year, and a follow-up just last week alongside our 24 R2 release — things like integrated help, walking users step by step through "how do I do X in IFS."

But it'll keep evolving — eventually you'll be able to say "generate an integration using this RESTful API between these two systems, here are the mappings I want," rather than hand-coding it or even using a low-code/no-code tool. I genuinely expect traditional static reporting to finally die — we've been trying to kill paper reports for years. I've been on implementations where customers insisted on dozens of specific reports, and half the time nobody could remember the last time anyone actually opened them. IFS as a product has already shifted toward dynamic, real-time grid displays customers can sort, filter, and one-click chart — but it'll go further, to the point where you can just ask the Copilot, "give me a recap of this week's sales, which product lines were up or down, who was my highest-margin customer" — and get that insight immediately.

We're also leaning on partners like Crosser — because if you look at where Industry 4.0 is heading, there's an obvious need for tighter integration with plant-floor machines. One of the biggest adoption barriers there is that machine data speaks different languages depending on the PLC — Rockwell, Allen-Bradley, Bosch, and so on — so we built tooling to make that machine-level connection easier. That data is also very noisy: a machine might spit out a hundred different metrics, but a customer really only cares about three. We built filtering for exactly that, paired with our business process automation tool, so customers can say "here are the three metrics I care about, here's my normal tolerance range" — and when something falls outside that range, automatically kick off a defined workflow.

Integrating Augmented Reality in Service
Kevin: We're genuinely interested in partners who bring that kind of innovation mindset to the platform. Take CADTALK as an example — we originally worked together around manufacturing BOMs, which I still view as high-value, coordinating that transformation. But let's extend that further: model data for physical assets, not just how something was originally designed. Often, by the time a complex asset actually gets installed, there have been manufacturing changes, or field-site installation changes — "we couldn't use that part, we had to substitute this one instead." Field technicians servicing those assets later genuinely need visibility into all of those different states: how it was designed, how it was manufactured, how it was actually installed, and how it's currently being serviced. Being able to see through each of those phases is where I view CADTALK as strategically valuable — helping extend that model data through the entire life cycle, not just keeping it contained within manufacturing.

Jeff: That's interesting — we've talked a lot about assets, which isn't the most traditional space for us, but it makes a lot of sense given it's fundamentally the same data structure and need. We've worked with customers — even in agriculture, for example — who design and manufacture components, ship them to a site, assemble a full unit there, and then have to maintain that asset over time, which may require design changes that need to stay backward compatible and then get installed or retrofitted directly on-site.

Kevin: And another partner we work with focuses on augmented reality for field service technicians — imagine a newer technician out in the field who knows someone back in the office has deep experience. Today that's basically a FaceTime call. But what if you could overlay the actual CAD model on top of the physical asset, select specific parts visually, and automatically generate a purchase requisition or customer order right from that interaction? That interactive ability to explore the model, identify exactly what's failed, and one-click order the right spare part — or even check a map to see if a nearby supply chain partner has that part in stock just a few miles away — completely changes what we can offer from a service standpoint.

The Importance of Asset Lifecycle Management
Jeff: One thing we've always emphasized is integration starting from engineering all the way through — out the door, through labor tracking, raw material consumption, shipping. This is just the next logical extension of that same philosophy, all the way out to the field.

Kevin: Quite candidly, that's been one of IFS's biggest differentiators over the last few years — manufacturing, traditional ERP, supply chain, field service, and asset maintenance all live in a single codebase on our platform. Where I've seen us add the most value is with companies that come looking purely for ERP and manufacturing software, initially assuming service management would need a totally separate RFP because they figured no single platform could handle both. And the answer is — actually, yes, it can. That's where we've made a real difference, because customers start to see the complete picture, even if they don't have every piece of it solved yet. It's a mindset shift: understanding that the work engineers do flows all the way through to the service team — and just as important, feedback flows back the other direction. If I'm a field technician, I might understand exactly why something failed based on how it was installed or the environment it's operating in — something engineering might never have considered. Having a channel to funnel that insight back to design, potentially triggering a revision change, is how the whole system continuously improves. Looking at our competitors, some cover pieces of that story, but very few are market-leading across the entire chain the way IFS is.

Future of Manufacturing and Technology Integration
Jeff: That reminds me of when I was in manufacturing myself, building packaging machinery — we had these massive parts books, hundreds of pages of drawings, and servicing something like a chain meant flipping through a 500-page manual just to identify the right part. We actually looked into solid-model-based disassembly for service purposes maybe 20 years ago, and it was genuinely mind-bending at the time, because the technology just wasn't there yet. Worst-case scenario, funny side story: on some really old machines with no drawings at all, technicians would literally pull a gear off the machine, trace its outline onto paper, and mail that stencil back to the machine shop so they could reproduce the part. That's about as old-school as it gets — but it shows how much faster you can move with the right technology tying everything together.

Kevin: And if you extend that further — handheld 3D scanning has been around for a while, but now we're also seeing additive manufacturing, 3D printing parts on demand, across manufacturing, aerospace, you name it — the ability to essentially turnkey-produce a part as needed. I've also seen plenty of cases where communication breaks down: engineering bumps a revision, but manufacturing never gets the memo and keeps building the old version — sometimes hundreds or thousands of units before anyone catches it, and then it's a scramble to figure out what has to be scrapped. That's exactly where I see CADTALK sitting, right at the earliest stage of this whole chain — whether it's a prototype or a design element inside engineering, engineering shouldn't have to worry about whether what they're designing is correctly making its way into the ERP as a real product. Thankfully, the days of hand-keying that data, or Excel import/export round-trips, are basically over — you just don't have to think about it. And as service becomes more central to uptime, availability, and speed to value, having accurate information at every one of those checkpoints along the way is genuinely critical.

The Importance of Speed in Prototyping
Jeff: I recently worked with a customer in the racing industry, where prototyping speed is everything — one of the big conversations was around "dwell time": how long from the moment something's released out of engineering until it's actually live and usable downstream. They wanted to measure that precisely so they could keep shrinking it — release to live, start to finish. Since the integration connects both systems, we can actually calculate that dwell time directly: CADTALK knows exactly when something was released in engineering and exactly when it was created in IFS, so we can report on that gap directly.

Quality Control and Automation in Production
Kevin: With the rise of trainable visual models — showing a system examples of what's good and what's bad — even quality control becomes a bottleneck worth automating. You might be producing everything correctly, but you still need sampling or certification to prove a product's within spec to your customers. I've seen this adopted quite a bit over the past year — I have a customer in food production, measuring cookies or dog biscuits on the line, and if something's out of spec, an arm literally sweeps it off the line before it reaches packaging, based on a camera model trained on what "good" and "bad" actually look like.

Enhancing Speed to Value in Manufacturing
Kevin: That dwell-time concept you mentioned is really about moving things through faster — especially if you're prototyping new parts, or trying to get ahead of competitors. You constantly have to find opportunities for better speed to value, without sacrificing the quality customers still expect.

Jeff: That's exactly what we talk about with lead time in CADTALK conversations — how fast can you move from ideation and design all the way through to the customer realizing that value, and how do you compress that timeline without degrading quality. All these systems matter for exactly that reason — there's really no way to hit that kind of speed manually.

AI Maturity and Customer Feedback
Kevin: I think we'll keep seeing this evolve at a breakneck pace, but we're finally reaching a real level of AI maturity. At Unleashed, we launched about 32 use cases that were genuinely vetted by our customer base through what we call customer advisory boards — highly engaged customers across our target markets who give us direct feedback on what will actually move the needle versus what's just noise. That feedback has been crucial for developing these use cases and packaging our domain expertise in a way that's genuinely useful from day one. As a publisher, we also have a responsibility to package AI in a way that's easily consumable — we can't make it so confusing, or so prone to hallucination, that it becomes more trouble than it's worth.

Data Privacy and Governance in AI
Kevin: The other major concern is data privacy. If a customer's using a generative Copilot, is that model learning from their proprietary data? Nobody wants a scenario where a competitor could ask a public model how a company makes their product, or what their quality statistics look like. At IFS, that AI component is fully contained within each customer's own instance — we don't even have access to that customer content ourselves, outside of a shared screen during a support case, and we take that boundary very seriously. That matters enormously to customers who are putting a lot of sensitive information into these systems and don't want it leaving their own walls. You need real data governance in place, and the data itself has to be good. That circles back to our earlier point, Jeff — if you start clean at the design phase, and that flows correctly all the way downstream, with revisions kept current and active, you avoid the classic "bad data in, bad analysis out" problem. A lot of customers come to us with years of accumulated data and ask us to fold it into demand-planning algorithms — but that data has to be good, and it has to be governed.

Scott: In the world of AI, the data really is the asset — that's what gives the model context to make good decisions. I think what's happening is that more and more companies are effectively becoming data companies, and their real competitive advantage is their accumulated experience — once that experience is captured in a machine-readable form, AI becomes more leverageable by the day.

Transforming Services with Data-Driven Insights
Kevin: I've got an interesting customer story — won't name them, but it's a fairly large pest control and rodent-management company, which admittedly isn't the sexiest example on paper. They came to us three or four years ago wanting to fundamentally rethink how they deliver service. Traditionally, this kind of business runs on what you'd call a "milk run" — every Monday you hit this route, Tuesday that route, repeat indefinitely. They wanted to install small sensors in bait boxes and traps, which let them shift to a subscription model — only dispatching a technician when something actually needs attention: bait's gone, it got wet, a trap physically tripped. Now they're adding real value on every visit instead of just showing up because it's Monday.

The most interesting part of that project, to Scott's earlier point, is the data itself: they could tell a customer, "we know you've got four buildings on this property, and based on data from mid-September through mid-October last year, we saw a consistent influx of field mice specifically at these two back doors of building three — we're going to preemptively place extra traps there," because the data models show that pattern peaks reliably at that time of year. They can offer enhanced service levels purely based on the data flowing through. The sensors themselves are cool, sure — but the real story is the sheer amount of insight that data gives them into managing that service far more intelligently.

Scott: And that data itself gives that customer a genuine competitive advantage over anyone without it — the data essentially becomes the product. They can offer more granular, fine-tuned service, which is really a different product entirely at that point.

Kevin: Exactly right, Scott — and you can apply that same pattern elsewhere. Say you've got a food and beverage customer storing ingredients in silos or tractor trailers, where environmental factors like excess heat can cause premature spoilage before the material even reaches the production line. You could add sensors, automatic fans for circulation or cooling, and so on. CIOs especially are under real board-level pressure to show a concrete return before greenlighting projects like this — and that's on us, as vendors, to help prove that story out with real value modeling, which is genuinely exciting given the tools available now.

Leveraging Data for Competitive Advantage
Jeff: Everyone tends to think first about cost savings as the "easy" AI use case — but the truly exciting ones are where the technology fundamentally improves the actual business and the products you sell. That pest control example is a perfect illustration — they're not just saving the customer money, they're genuinely enhancing the service itself using the technology and the data. That's where you start seeing exponential growth, because demand for that kind of differentiated service goes way up, and it lets a company completely rethink how they deliver value to their end customer. We're seeing the same pattern with assets deployed out in the field — the ability to capture that feedback loop, done securely and scoped appropriately, and carry it all the way back into the business.

Kevin: IFS takes that as something of an obligation — to provide that path where we can, and to bring in the right partners where we're not the best fit ourselves, and help customers think through opportunities they might not have considered on their own for an AI project.

Innovations in Utility Management
Jeff: Something you said about pest control made me think of landscaping — the classic "same guy shows up every week to water your lawn" model, whether or not it's actually needed. You see this at scale somewhere like Disney World, where they're managing millions of gallons of water. The same sensor and AI approach could tell you the actual fertilizer content or soil moisture, and exactly how often watering is genuinely needed.

Kevin: IFS is quite active in utilities, partly through our recent acquisition of Copperleaf, but also more broadly through our strategic asset management portfolio. One of the folks on my team has deep utility industry background, and he's walked me through scenarios where utilities are increasingly deploying drones for what's called vegetation control — historically done with helicopters and saws clearing brush off power lines. That has the potential to save utilities millions of dollars. With IFS now able to look ten days out at weather forecasts, we can help model potential service interruptions, better position crews, put mutual aid on standby, or pre-position spare parts — and utilities are using drones to go do very targeted vegetation control based on that modeling.

The other utility use case: after a major weather event, or worse, a wildfire, utilities often have to power down lines entirely to prevent contributing to a catastrophic event — and those lines then require full visual inspection before they can be safely re-energized, which takes real time. If a drone can be deployed based on precisely where the weather event tracked, and it's equipped with cameras for visual inspection, that dramatically speeds up getting service back — again, that same theme of speed of service and speed of value.

Jeff: That's incredible — thinking about other use cases for critical infrastructure and service industries generally: vegetation management sounds simple conceptually, but it's not an easy problem operationally, given the sheer geographic area involved. Locally, we have Duke Energy driving through neighborhoods trimming trees preemptively — but with drones and that kind of technology, you could map the actual risk areas systematically.

Kevin: Some utilities are even deploying cameras directly on utility poles now, so if severe weather comes through, the camera can automatically flag "this line is down" or "service interruption detected here" — versus the old model where a customer calls in, reports an outage, and gets a wide, imprecise window for restoration. With sensors, and — back to Scott's point — data as the real asset, software providers have to be genuinely willing to work well with other platforms. We have to be a system that's ready to ingest that data, analyze it, and then either run what-if scenarios or trigger real dispatch capability to actually get things fixed. That's just as applicable to a utility as it is to a manufacturer running a 24/7 operation across multiple production lines, where a single broken machine or component can't be allowed to cause an outage that snowballs into a four-week production backlog.

Navigating ERP Modernization in Manufacturing
Jeff: Let's bring this back to manufacturing to wrap up. I've talked to a lot of manufacturers over the last ten years at CADTALK, and you've seen plenty through IFS as well — you mentioned yourself that manufacturing tends to be slower to adopt new technology, more conservative about the cloud, more conservative about ERP change generally, even when it's genuinely needed. In my experience, a lot of manufacturing companies we see are still running on old legacy systems, sometimes literal green-screen mainframes — hard to believe, but true. What's your advice for manufacturers who are considering an ERP change, or reconsidering their current system, given how much more cautious that industry tends to be?

Kevin: These projects can genuinely be scary. People like us encounter dozens of implementations at any given time, so we understand the stress involved — and anyone at a company going through one of these will come out the other side with essentially a mini-MBA on their own organization. You often hear from a steering committee or executives, "this is how we do it," and then you find someone actually on the floor who says "no, that's not remotely how we do it" — and reconciling that gap is part of the process. But there's genuinely more maturity available now than there used to be, and real experience out there to draw on.

I had a tough conversation recently with a prospective customer who was chasing the holy grail of a fully optimized production schedule right out of the gate — and having been in this industry over 20 years, we know that's really the end point of a long journey, not the starting point. You need a huge number of things to be correct and stable first. I told them candidly: I think you're trying to bite off scheduling and a foundational ERP implementation simultaneously, and that's too much — get the foundation solid first. These projects tend to suffer from real scope creep, because customers start seeing every possible efficiency gain on the table and get pulled toward shiny objects. You have to stay disciplined and focused on the specific outcome for phase one, because getting over that initial hump — and it is genuinely a lot of work, I won't pretend otherwise — sets you up well. There are also peer groups out there for almost any kind of project like this — people who've already been through it and can give you an unbiased read. In the US specifically, there's a whole industry of ERP selection consultants who document best practices and help narrow down software providers. Generative AI can even help you figure out what ERP a competitor is likely running, which can be a useful reference point. Learning what peers in your industry have actually done, what worked and what didn't — even through a medium like this podcast — genuinely helps. My honest take: these projects are challenging, but if you can stay focused on that initial core outcome — get the ERP installed, get good foundational data flowing — everything you want to add later comes at a much gentler curve, because you've already internalized how the system fundamentally works.

Continuous Improvement in ERP Implementation
Kevin: There's a real counterargument to that too, though — sometimes teams do phase one, and phase two just never happens. Part of the answer is continuously seeking genuine improvement: how do we get better now that this foundation exists? Getting that initial foundation right — with the software provider or a trusted partner helping guide you through phase one — matters enormously. I currently sit on about eight steering committees for recent IFS wins, and it's important to me to understand exactly what hiccups each one runs into, because every single one is a learning exercise — where did we fail to communicate clearly, where were the gaps we should have caught sooner, so I can jump in and address something quickly before it festers. In these kinds of projects, communication and expectations are really the two biggest levers for success.

Jeff: That hits on two things we talk about internally as core values: first, that implementation isn't a one-time event, it's an ongoing process — just like lifting weights, you don't get stronger from one three-hour session, it's the consistent process that builds the muscle over time. We try to instill that mindset from the start of every CADTALK project — yes, we can do a lot, but let's actually deliver core value first, and build a genuine culture of continuous improvement from there.

Kevin: It really is a mindset shift, and a culture change, because historically our industry treated go-live as the finish line — "we went live, thank you very much, we're done." With the shift to SaaS and subscription models, publishers like IFS have to do better than that — we need a higher level of ongoing intimacy with customers, because, like we said earlier, no company wants to go through one of these projects any more often than they absolutely have to. Some people are genuinely lucky to go through this even once in their career; a rare few might go through two or three. These are big, disruptive projects, and companies rightly want to minimize how often they have to endure that disruption. So that culture shift toward staying engaged well beyond go-live is hugely valuable — even now, part of our service offering is about staying close to customers long after go-live, understanding their long-term strategic goals so our roadmap actually aligns with where they're headed. The last thing you want is a customer calling two years later and the response is essentially "wait, remind us who you are and how you're using the software" — that's a bad experience for everyone. Serving on these steering committees, even if it's just a half hour here or there across eight different accounts in a week, is worth it if it means resolving issues faster and genuinely reaching go-live and beyond in good shape.

Closing Thoughts
Jeff: Couldn't have said it better myself, Kevin. We're coming up on an hour — amazing conversation. Where can people who might be listening, especially manufacturing companies interested in IFS, learn more, or get in touch with you directly?

Kevin: I'm pretty active and open on LinkedIn — I share everything from company and product updates to just interesting things I come across in the field, customer products, that kind of thing, which honestly is always the most interesting part to me. Like you two, if I get a one-hour plant tour, I learn more from that than from six meetings. We also have a YouTube presence with product content, and a video library covering not just IFS itself but partner products too — CADTALK's included in that library, for customers who want to see how it actually works. LinkedIn's probably the fastest way to reach me, and I respond to pretty much every inquiry I get.

Jeff: Kevin, this has been a great conversation — really appreciate you giving us the hour. I suppose the next time we're together will probably be at an IFS event in the UK.

Kevin: That's usually when we cross paths — and that's actually less than a month away at this point.

Jeff: That sounds about right. Anything else before we let you go?

Kevin: No, just — I really appreciate the partnership. There's been a tremendous amount of value built through this relationship, and we want to keep that going. I appreciate the support you provide to IFS customers as well — my pleasure being here today.

Jeff: Thank you, Kevin. Thanks, everybody, for listening — please subscribe, leave a comment, and feel free to reach out to Kevin on LinkedIn. We'll see you next time.

Scott: Thanks, Kevin.

Kevin: Thanks, guys.