Most Companies Aren't Ready for AI
Most companies don't need AI, at least not yet. They need systems and processes to stand on, and writing down step-by-step guides won't solve the chaos.
"We want to add AI." I hear a version of it almost every week. The business has seen what these tools can do, they can feel their industry shifting underneath them, and they want AI working inside their company before they get left behind. The instinct is sound. The readiness usually isn't. Most companies that ask for AI aren't ready for it, and not for lack of budget or talent. They're missing the one thing AI actually depends on: clean data and processes that make sense. Without that, there's nothing for AI to attach to. A recent engagement made the point about as plainly as it gets.
A physician group I was working with brought me in to implement AI into their operation. Multi-site, 80-plus providers, growing. The request was straightforward: they wanted to scale without hiring more overhead. They figured AI was the way to do it. A very reasonable assumption. It's also where most of these conversations start.
So I did what I always do before writing a line of code: I mapped how the work actually moved. It didn't take long to find the real problem. It wasn't a missing model or the wrong tool. There was no system underneath any of it. And their plan to fix that was to write everything down.
What the operation actually looked like
Start with HR. It ran on ten to fifteen different Excel spreadsheets. Each admin kept their own stack. Everyone organized their information the way that worked for them: their own files, their own naming conventions, their own logic for where things lived. Whatever worked for each individual became that person's system.
And locally, it sort of worked, until the cracks showed. Each person could find what they needed in their own files. That's exactly what made it so easy to mistake for organization. But there was no shared source of truth. No agreement on what a field meant or where the real record lived. Everyone doing the same job a different way, with no way to reconcile them.
It wasn't only HR. Company files lived the same way: each person keeping documents on their own OneDrive, with no central repository anywhere. Their previous "fix" told the whole story: they had designated the OneDrive of an employee who'd already left as the de facto company drive. The shared source of truth was an account nobody owned, attached to a person who was gone. That one decision set off its own cascade of problems, but the root was the same one running through everything: no plan, and no system underneath it.
Then there were the SOPs. The owners wanted control, and their instinct was that every procedure should be approved by them, nothing official without a sign-off at the top. So I looked at the gap between the work that actually happened every day and the work that had been written down. It wasn't even close. Most of the tasks the business ran on had no SOP at all. The approval process gave the owners oversight of a sliver and felt like oversight of the whole. The ritual produced confidence. It did not produce coverage.
Writing it down is not the same as having a system
Their plan was reasonable on its face. No standard processes, so write standard operating procedures. Document every task, assemble the binder, and the operation becomes organized.
But writing a process down and having a process are two different things.
An SOP is a description. It records how a task is done today. What it does not do is ask whether the task makes sense, whether the steps are in the right order, or whether the output of one process is the input the next one needs. Documentation captures the current state. It doesn't improve it. When the underlying work is incoherent, writing it down doesn't fix the incoherence. It freezes it. Document that sprawl of spreadsheets and you don't get a process. You get a dozen procedures for the same job, each describing a personal workaround, none of them talking to each other. You'd codify the fragmentation and call it structure. The wild west, with a manual.
Why AI had nothing to run on
This is why the AI request was premature. Not because AI would have broken something, but because it had nothing to operate on. AI runs on structured, consistent data and defined processes. That's the raw material it needs. Point a model at a dozen-plus spreadsheets that don't agree, with no source of truth and no shared definition of what a field even means, and there's nothing coherent for it to use. No canonical record to read from. No reliable pattern to learn. No defined workflow to automate. You can't point intelligent tooling at a question the business hasn't answered for itself: which version is right?
So it isn't that the technology would have hurt them. It's that it would have had nothing to do. AI needs something to stand on: a defined workflow, a clear owner for each step, data that lives in one place and means one thing. None of that existed yet. The technology wasn't the missing piece. The foundation was.
What to do instead
So I didn't start with AI. I started with the operating layer.
I mapped the current state and designed the future state, not just documenting what people did, but redesigning the work so the steps made sense and the processes fit together at the handoffs. Then I built the system to hold it: a single admin portal to replace the spreadsheet stacks, one source of truth where the HR function finally lived in one place instead of fifteen. Around it went the things that make a system trustworthy in healthcare: role-based access, audit logging, and retention and data-integrity controls.
Only then did AI and automation have a place. Not AI bolted onto chaos. AI as a layer on top of a system that could finally support it.
The order matters. Foundations first, then automation, then intelligence. Get it backwards and there's nothing for the technology to build on.
Are you ready, or just chasing the hype?
You don't need a consultant to get an honest read on this. Ask a few plain questions about your own operation:
- Does your data live in one place, or many? If the same information sits in five files kept by five people, you don't have data. You have copies that disagree.
- Could two people doing the same job describe it the same way? If not, there's no process yet, just personal habits.
- Does work move along a defined path, or through whoever remembers to push it forward? Memory is not a workflow.
- If you wrote down what you do today, would it be a coherent process, or a transcript of the current chaos? Documenting the second one doesn't fix it.
- Are you reaching for AI to do the work, or to avoid fixing it? That's the question that separates the two camps.
Here's the tell. A company that's ready can name the exact workflow AI would slot into and what it would own. A company chasing the hype wants AI first and hopes the process sorts itself out afterward. The first is buying a tool. The second is buying a feeling.
The group I worked with wanted to scale without adding overhead. That was the right goal. AI just wasn't the first step toward it. A real operating system was. Build that, and AI becomes the on-ramp they were after. Skip it, and the most advanced model on the market will simply run your broken process faster.
Most companies that want AI don't need AI yet. They need a system worth automating.
If your operation has the same shape
That's the kind of work we do.
Build, Buy, or Rent: The Software Math Just Changed
The old reflex was rent, never build, because software needed engineers. AI coding changed the math: when to build, buy, or rent, plus the stack we run on.
ReadHow to Safely Get Started with AI Coding
Building your own software is finally realistic for non-coders. A safe, step-by-step guide to build your first app and replace the spreadsheet you outgrew.
ReadThe Need to Know: AI Vibe Coding
AI coding agents are making software faster and cheaper to build, but they do not replace the judgment needed to design, secure, and operate business systems.
Read