Go back

Ep 1 - Why Isn't Our AI Pilot Turning Into Anything Real?

from Forever Forward - Facilities Management, Asset Operations, Maintenance and Beyond!

7m 29s

Ep 1 - Why Isn't Our AI Pilot Turning Into Anything Real?

The core issue in AI pilot failures is that most are designed to prove technology rather than deliver real business value. Successful pilots are rooted in actual operational workflows and decisions, not feature demos. Operational users must be involved from day one, ensuring the solution fits real work demands. Data reliability is crucial, as inconsistent or patchy data undermines scalability. Outputs must integrate into existing, trusted systems to gain user trust and adoption. Transparency in AI reasoning is vital, as operators naturally question decisions and require explanations. Pilots need clear scope, governance, and timelines to avoid costly delays during scaling. The shift from "proof of concept" to "proof of value" better reflects the goal of demonstrating tangible business benefits. Ultimately, AI success depends on operational ownership, reliable data, and user trust—factors that are often overlooked in early-stage initiatives. The series highlights that scaling requires not just technical feasibility, but deep alignment with business realities and human processes.

Transcription

1155 Words, 6228 Characters

English
(upbeat music) - Hello everyone, welcome to the first episode of the new series, "Operations is the Alpha" from forever forward. The first question that we take from, obviously inspired by the time I spent at the Proptic Connect Europe is the question that most people who've invested in AI over the last 80 months or 24 months have on their mind that why isn't the AI pilot turning into anything real? And in bed in mind, I'm also not currently talking about the return on investments. It's just that there's this valley of bed and where all these pilots kind of go and nothing really happens from the operations point of view or the business's usual implementation point of view. Now, what's the difference between the pilot that worked and one that's about to scale? A pilot that scales was really, or should have actually been only sculpted about a real decision or a real business flow into it and not a feature demo. A pilot that usually dies has really been done to prove a technology and not the business change around it. So could be as a reason of the push that happened from top to bottom that something needed to be done AI and you ended up doing it. But fact of the matter is that there was no thought around what one real decision is it gonna change and to end? Or even alter, transform, whatever it could be. And the ones that made it to, made it like as a scale, had the people who would actually use the output involved from day one and not as an afterthought. I have been a personal like backer of the idea that unlike all the other transformations, digital transformation where your IT teams and CIO has taken the lead. I think in this case, especially when we look at operations, I think the people who actually operate need to have a very formidable seat at the table and probably be driving it as well. IT, you know, and the information technology team or the information security team, all of them are extremely important because they help us make the right technology decisions. But I think the outcome needs to be on the operations and not by the ones who are custodians of innovation. And scaling needs the underlying data and provenance to be already reliable but the data layer has not been around consistently just has just been patched for the pilot and you obviously won't survive the production volume. However, I must also say that we are also for, I'm also for belief that, you know, you can wait the eternity to get your data perfect in a perfect condition and then say, then we are going to implement because the fact the matter also is that you are operating your acid facility with whatever data you have. Now, I would have, you know, it's hard to believe that you're going to not trust that data because you're operating at those conditions, right? You could say that my confidence is not extremely high which is where we are going to work to improve the data quality. But again, data quality does happen to be one of the points where it kind of goes, goes a little, I mean, it doesn't scale. And then when you look at, you know, that you have IX that interest everyone and everyone was extremely happy is because the first time, I mean, sometimes it does happen that the credibility is fragile which means that the first time an output looks wrong to an operator which means, you know, it just takes far more effort for the team to bring them back onto the table than, you know, than it takes to impress for the first time. So I think that is where it is very important to set the right, you know, expectations from day one. And also, I think when you look at pilots, you know, on budgets for the overall goal, the time, effort, governance, all of that will have to come into play. One scopes that out, very few people scope that out for a pilot and leave it and say, okay, we'll see what to do after the pilot. And by the time when you are coming into a stage after the pilot, you're already saying, oh, this is actually going to be so much of an effort, right? And the other third point is, is, you know, the output of the pilot needs to live inside systems, people already trust, they use daily, and more often than not, unless you're changing your entire technology stack. If you're just thinking one more tool, and saying, hey, you would also need to use this, why you use five, six, seven other systems is probably not gonna work much. That's one thing, you know, for example, we've tried to stay away, we say, no, no, no replace. And there is obviously there are some use cases where you would have to have your technology stack, but the moment you are wanting to make too much of a change to the people who operate, and the tool ends up being one more tool in the armory, then I think that's gonna be a problem. And also, at times when people look at the output, the reasoning behind the AI generated output is fundamentally important and not just the answer, because people are skeptic in nature, and that they're rightfully so. So there are some sort of personas who really need to know why were certain decision made, what was the reason why that decision was made or recommended, and it's almost like us talking or working with our colleagues, we don't just take the answer in most of the cases, we want to understand the reason behind it. If it is an important decision to be made. So in my humble opinion, these are like top cohorts of reasons why the pilots fail, and as we conclude the episode one, there's one thing that I don't actually use with all our customers is that I never use the word proof of concept. I'm saying it is not a concept that we're proving, we are gonna prove the value to your business. So it's always good to say it as proof of value versus saying proof of concept. Obviously, you guys wish any people listening to the podcast, you would have your own views, suggestions, please feel free to chime in, and we are gonna be back again with the episode two, where we pick up is the pilot not being successful, and that implementation is a technology problem, or a people problem wearing a technology costume. Till then enjoy this episode, and let me know what you thought of it, and we'll be back again soon for episode two. Thank you. (upbeat music)

Podcast Summary

Key Points:

  1. Pilots that scale are built around real business decisions and operational flows, not just technology demonstrations.
  2. Successful pilots involve operational users from the start, ensuring alignment with actual work processes and needs.
  3. Operational staff, not just IT or innovation teams, should lead and drive AI implementation for meaningful outcomes.
  4. Reliable, consistent data and provenance are essential for scaling, as patching data for pilots fails under production demands.
  5. Pilot outputs must integrate into existing, trusted systems to ensure adoption and reduce resistance.
  6. Transparency in AI decision-making—explaining the reasoning behind outputs—is critical to building trust among users.
  7. Pilots should have clear scope, budget, time, and governance defined upfront, not left to vague post-pilot assessments.
  8. The term "proof of concept" is misleading; it should be replaced with "proof of value" to emphasize business impact.

Summary:

The core issue in AI pilot failures is that most are designed to prove technology rather than deliver real business value. Successful pilots are rooted in actual operational workflows and decisions, not feature demos. Operational users must be involved from day one, ensuring the solution fits real work demands.

Data reliability is crucial, as inconsistent or patchy data undermines scalability. Outputs must integrate into existing, trusted systems to gain user trust and adoption. Transparency in AI reasoning is vital, as operators naturally question decisions and require explanations.

Pilots need clear scope, governance, and timelines to avoid costly delays during scaling. The shift from "proof of concept" to "proof of value" better reflects the goal of demonstrating tangible business benefits. Ultimately, AI success depends on operational ownership, reliable data, and user trust—factors that are often overlooked in early-stage initiatives.

The series highlights that scaling requires not just technical feasibility, but deep alignment with business realities and human processes.

FAQs

AI pilots often fail to scale because they focus on proving technology rather than driving real business decisions or operational changes. Without involving end-users from the start, these pilots lack the necessary alignment with actual business flows.

A successful pilot is built around a real decision or business process, with input from operations teams from day one. A failing pilot typically proves a technology concept without considering how it will impact actual business outcomes.

Operations teams are the ones who actually use the outputs of AI systems. Involving them ensures the solution meets real-world needs and leads to better adoption and long-term success.

Poor or inconsistent data quality undermines AI reliability. Pilots that rely on patchwork, temporary data cannot scale to production volumes, where consistent data provenance is essential.

Operators are naturally skeptical of AI decisions. Providing clear explanations builds trust and allows users to understand and validate decisions, especially in critical operations.

Introducing another tool without integrating into daily-used systems leads to user resistance. Successful pilots work within existing workflows to ensure ease of adoption and trust.

Chat with AI

Loading...

Pro features

Go deeper with this episode

Unlock creator-grade tools that turn any transcript into show notes and subtitle files.