I love a good waffle/rant, and those who’ve worked with me will know this. Famed for essay length emails, laced with detail and facts – my defence being that if you include all the details, there’s no confusion, and everythings immediately out on the table. It’s perhaps why returning to blogging has helped with my wordy out pourings. This particular article however, feels quite controversial, and maybe it is… nothing like a bit of controversy.

This post is a bit off-piste, for Device Management, but I guess it’s all somewhat relevant as we’re all being AI’d to death, one way or another. It actually takes me back maybe five or six years ago, the term “Automation” was everywhere. Infrastructure as Code (IaC), PowerShell, Robotic Process Automation (RPA), DevOps and workflow automation were going to revolutionise how businesses operated. The promises were compelling. Fewer manual processes, improved efficiency, reduced operational costs and less time spent performing repetitive, mundane tasks. It’s all starting to sound a little familiar…

Fast-forward to today, and Artificial Intelligence (AI) has taken centre stage. Every technology vendor has an AI story. Every conference has an AI keynote. Every organisation seems/claims/wants to have an AI strategy, or at least feels it should have one.

We’re being told that AI will transform productivity, automate business processes, reduce operational overheads and fundamentally change how people work. And perhaps it will. But I can’t help feeling that we’ve been here before.

The Automation Revolution That Never Quite Happened

Having spent years working with enterprises on technology transformation, I’ve seen first-hand how difficult it can be to automate even relatively straightforward activities. Not necessarily because the automation technology wasn’t capable. Quite the opposite. We had scripting languages, APIs, configuration management platforms, orchestration tools and increasingly sophisticated ways of connecting systems together. The tools were often perfectly capable of doing what we wanted.

The problem was everything surrounding them.

Legacy applications with limited integration capabilities. Poorly documented processes, or processes that predate dinousaurs. Inconsistent configurations. Data scattered across multiple systems. Manual approval chains that nobody understood. Business-critical workflows built around individual employees and their accumulated knowledge.

In many cases, what initially appeared to be an automation opportunity quickly became an exercise in understanding why the existing process was so complicated in the first place. And that’s before considering security, governance, organisational resistance and the inevitable statement: “We’ve always done it this way.”

The uncomfortable reality was that many organisations weren’t ready for automation. Not because their infrastructure was too old, but because their operational processes and technology foundations were fundamentally unsuitable. You cannot reliably automate something you don’t properly understand and automating a broken process doesn’t fix it. It simply allows that broken process to operate faster.

Step forward AI

Today, we’re seeing remarkably similar conversations. It feels like we’ve done a find-and-replace, and updated the bullshit bingo cards, replacing Automation with the term AI – only this time, we’ve gone nuclear, and deployed earth destroying datacentres and made lots of people very rich. Hypocritical comments and politics aside, Organisations want AI. They want Copilot-esque helpers (if not Copilot specifically), AI-powered service desks, autonomous agents, intelligent workflows and automated decision-making. But ask what problem they’re trying to solve, and the answer isn’t always particularly clear.

Often though, the ambition seems to be adopting AI itself (or be seen to be adopting AI) rather than achieving a specific business outcome. I’ve lost count of how many times I’ve heard “Can we just AI this?”, “AI can probably fix that” and more worryingly, in the past I’ve personally been asked to “just throw AI into the solution” as if little old me can personally can enhance something that the product vendors haven’t thought about yet — it just doesn’t work like that. You can’t or shouldn’t AI for AI’s sake.

Of course, all that said, AI is technically different from automation. Automation largely relied on predictable inputs, defined rules and repeatable actions. AI introduces the ability to interpret natural language, analyse unstructured information, recognise patterns and assist with decisions that previously required human involvement. So when it comes to comparing AI and Automation, the closest it gets, really, is the fact that AI is the hot topic in town (much like Automation was many years ago).

But here’s the real problem.

AI might be better at understanding what needs to happen. That doesn’t mean your enterprise is any better equipped to make it happen.

An AI agent might be capable of interpreting a support request, identifying a potential issue and recommending a resolution. But what happens when the underlying asset inventory is inaccurate? What happens when the knowledge base contains contradictory documentation? What happens when the business process depends on a legacy application with no usable API? What happens when access permissions are inconsistent, or nobody can explain who owns the process?

AI hasn’t solved any of those problems. In some circumstances, it may actually make them worse.

SISO 💩

There’s an old principle that feels particularly relevant here. Shit in, shit out. Give a system poor-quality information and you shouldn’t be surprised when it produces poor-quality results. AI hasn’t made that principle obsolete. It’s has however made it more important.

Consider an organisation deploying an AI assistant across its internal documentation. On paper, it’s a fantastic idea. Employees could ask questions about company policies, technical procedures, operational processes and business information without spending hours searching through SharePoint sites and file servers. But what if those repositories contain years of outdated documents, duplicated procedures, conflicting policies and information that nobody has maintained?

The assistant may retrieve that information and present it in a coherent, confident and entirely convincing response. Unfortunately, being convincing isn’t the same as being correct. Of all the training I’ve done on AI, “Human in the loop”, “Hallucinations” and “being factual” are all highlighted as risks and concerns, heck they’re not only highlighted but called out as AI principles.

On top of this, there’s another dimension to this problem. Security.

If an organisation has spent years allowing excessive access to internal information, introducing an AI assistant that makes that information easier to discover could expose problems that previously went unnoticed. AI doesn’t necessarily create the underlying issue. It can simply make an existing issue much more visible and much easier to exploit. This is why data quality, information governance, access management and process ownership matter so much.

AI is only as dependable as the information, systems and controls it relies upon.

Are We Automating Problems?

One of my biggest concerns is that organisations will treat AI as another technology implementation exercise. Purchase the licences. Deploy the platform. Run some training sessions. Measure adoption. Declare success, regardless.

This isn’t new, we see if all the time with enterprise technology. And while the implementation activities listed above have their place and are actually necessary, they don’t necessarily tell us whether anything meaningful has improved. An employee using Copilot to summarise a meeting might save themselves fifteen minutes. That’s useful. But has the organisation considered why that meeting was necessary in the first place? Could the meeting have been replaced by a better process? Could the information have been captured automatically without requiring people to attend?

This is an important distinction. There is a difference between making an inefficient activity easier and eliminating the inefficiency altogether. And I suspect a significant proportion of the value attributed to AI will come from doing the former, when organisations should perhaps be concentrating more on the latter.

Before asking how AI can improve a process, shouldn’t we first be asking whether that process needs to exist at all???

A Familiar Example From IT Operations

Let’s consider something closer to my own area of expertise: enterprise endpoint management. Imagine an organisation managing 15,000 Windows devices. It has an established service desk, Microsoft Intune, perhaps some remaining Configuration Manager infrastructure, and a mixture of modern and legacy applications. There are thousands of incidents relating to device compliance, application failures, configuration problems and operating system updates. The organisation decides it wants AI to improve IT support.

The vision sounds fantastic. An AI agent capable of investigating incidents, examining device health, identifying likely causes and potentially performing remediation without engineer intervention. Technically, much of this is achievable. But what if the organisation hasn’t standardised its device configurations? What if compliance policies have accumulated over years without proper rationalisation? What if application deployments are inconsistent? What if device naming conventions are meaningless, ownership information is inaccurate and the service desk knowledge base hasn’t been maintained? What if incidents are regularly resolved through undocumented workarounds?

You could introduce an incredibly sophisticated AI solution into that environment. But you’re asking it to operate on top of an estate that is already difficult for experienced engineers to understand. Wouldn’t it make more sense to address those issues first? Standardise configurations. Rationalise policies. Improve monitoring. Establish reliable data sources. Document repeatable remediation procedures. Then introduce AI to help analyse, interpret and act upon that information. (Hint! The answer is yes!)

The fact is, many of the improvements required to make AI effective would deliver operational benefits even if AI were never deployed. And perhaps that’s the point.

Not Everything Needs AI

Honest.

So, Where Should Enterprises Actually Start?

I’m not opposed to AI, nor do I think the solution is to scale back investment in it. Quite the opposite. AI has enormous potential. However, that potential grows exponentially when it’s paired with clean, well-governed, and trusted data. What I would suggest, or challenge, is that organisations change the starting point.

Rather than asking: “How can we introduce AI into our business?”

Start by asking: “What are the biggest inefficiencies in our business, and what’s preventing us from addressing them?”

That changes the conversation entirely. It moves the focus away from technology procurement and towards business outcomes. My preferred approach would be relatively straightforward.

1. Understand the problem

Donning my SRE hat, and thinking about TOIL. Identify the processes consuming disproportionate amounts of time, generating repeated incidents or requiring unnecessary manual intervention. Understand why those processes exist and what makes them inefficient.

2. Assess the foundations

Look at the systems, data, integrations, security controls and operational procedures supporting those processes. Are they reliable? Are they documented? Are they consistent? Is there clear ownership?

3. Rationalise before automating

Challenge the process itself. Remove unnecessary steps, standardise where possible and address the underlying causes of inefficiency. Don’t simply reproduce a broken manual workflow using more sophisticated technology.

4. Choose the appropriate technology

Some problems require process redesign. Others require better integrations or improved data management. Some will genuinely benefit from AI. And many of the best solutions will combine all of these.

5. Demonstrate measurable value

Start with a clearly defined use case. Establish a baseline and measure whether the solution genuinely reduces effort, improves reliability, lowers costs or delivers a better experience. Not how many people have opened an AI application. Not how many prompts have been submitted. Actual operational improvement.

6. Scale what works

Once there’s evidence of value, expand. Build governance, operational ownership and continuous improvement into the solution from the beginning. A successful proof of concept is only the beginning of delivering a sustainable enterprise service.

AI Readiness Is Really Enterprise Readiness

The more I think about it, the more I wonder whether we’re approaching enterprise AI transformation from the wrong direction. We’re talking about AI readiness as though it’s a completely new discipline. But many of the fundamental requirements should already be familiar.

Reliable operational practices.

These are the same foundations we’ve been encouraging organisations to establish for years. They were important for cloud adoption. They were important for infrastructure automation. They were important for digital transformation and they’re just as important for AI.

The difference is that AI has brought renewed attention, investment and executive interest to problems that many IT teams have been trying to address for a very long time. Perhaps that’s actually the opportunity. If enthusiasm for AI encourages organisations to finally address years of accumulated technical debt, fragmented processes and poor information governance, it could deliver enormous value. Not necessarily because AI itself performs every task. But because organisations finally improve the underlying systems and processes that have held them back, and this, is the key point, fixing the underlying systems and processes – you cannot build foundations on unstable ground.

Final Thoughts

Despite “the rant”, I’m genuinely excited about the potential of AI it’s already helped me immensely – my PowerShell capabilities have increased from hello world, to being sufficiently dangerous. The ability to analyse information, understand context, coordinate activities and drive meaningful efficiency improvements across enterprise systems represents a significant step forward (and drives home the continuous improvement cycle I’ve been an advocate of for time!). But I’m also sceptical of annoyed by the suggestion that simply introducing throwing AI into an organisation will somehow transform it. We’ve all seen technology initiatives struggle because the underlying problems were never addressed. There’s no reason why AI should be immune to those same challenges. It is more capable than many of the tools that came before it. However, it is not magic.

AI can’t fix your broken processes, poor-quality data or fragmented enterprise architecture just because you’ve connected a language model to them.

Successful AI adoption requires much the same disciplines as successful technology transformation: discovery, rationalisation, architecture, governance, implementation and continuous improvement. So perhaps the most important question an organisation can ask isn’t: “How do we become an AI-first business?” but actually, “Are we actually a well-run, well-integrated and well-governed business that AI can meaningfully improve?”

Because if the answer is no, I’d argue that’s where the transformation should begin…