When AI Finds the Business Process Nobody Documented

Your AI found the process.

That’s great.

Nobody else knew it existed.

That’s less good.

There wasn’t a process document.

There wasn’t a diagram.

There wasn’t a runbook.

There wasn’t even a particularly useful comment in the code.

There was just:

A spreadsheet.

Three emails.

A scheduled job.

A stored procedure.

A shared folder.

And one person who knew that on the third business day of every month, you had to do something manually or Finance’s numbers would be “off”.

Your AI didn’t create a new business process.

It discovered the one you forgot you had.

Welcome back to Production.

The Process Isn’t Always Where You Think It Is

Ask an organization where its business processes are documented and you’ll probably hear about:

SharePoint.

Confluence.

Process diagrams.

Standard operating procedures.

Runbooks.

Technical documentation.

Maybe even a data catalog.

Those are certainly places where processes can live.

But that’s not necessarily where the real process lives.

Sometimes the real process is:

“When this email arrives, Jeannine downloads the attachment, fixes two columns, saves it to the shared drive, and then Bob’s job picks it up at 6:00.”

Is that documented?

Absolutely not.

Everybody knows it.

Until they don’t.

The Official Process and the Actual Process

Organizations often have two versions of a process.

There’s the process we designed.

And there’s the process that actually happens.

The official version might say:

Source System → Integration → Data Warehouse → Reporting

Beautiful.

Four boxes.

Three arrows.

Probably presented in PowerPoint.

The actual version is much closer to:

Source System
↓
Integration
↓
First Failure Notice
↓
Email notification
↓
Jeannine downloads CSV
↓
Fixes bad records in Excel
↓
Renames file EXACTLY
↓
Copies to shared folder
↓
Scheduled job at 6:00 PM
↓
Stored procedure written in 2014
↓
Data Warehouse
↓
Reporting

That diagram doesn’t fit as nicely on the architecture slide.

But it’s the one running your company.

AI Has an Annoying Habit of Connecting Things

This is where AI becomes interesting.

Traditional systems tend to expose pieces.

The scheduler knows the job runs.

SQL Server knows the procedure executes.

The file share knows a CSV appeared.

Email knows someone sent an attachment.

Power BI knows the data eventually arrived.

Jeannine knows what she did.

Each system knows its piece.

AI may be the first thing we deploy that starts pulling those pieces together.

Someone asks: “Why is the revenue report wrong every few months?”

And suddenly we’re looking at:

A recurring email.

A spreadsheet.

A file timestamp.

A scheduled process.

A database load.

And a report refresh.

Individually, none of them explains the process.

Together?

Oh.

The Sherpa’s Notebook

I’ve encountered versions of this throughout my career.

One of my favorites involved a spreadsheet.

Not just any spreadsheet.

A Master Spreadsheet™.

That spreadsheet received its data from an Access database.

The Access database received its data from an internal website.

Why the website?

Because IT wouldn’t give the people doing the work direct access to the database.

The Master Spreadsheet then generated multiple other spreadsheets—one for each store.

Those spreadsheets became part of the operational process.

So let’s draw that architecture:

Database → Internal Website → Access Database→ Master Spreadsheet → More Spreadsheets → Business

Nobody sat in an architecture meeting and said:

“You know what this enterprise needs? More Excel.”

The process evolved.

Each step solved a problem.

Eventually, the workaround became the architecture.

Now imagine connecting AI to that environment.

Someone asks: “Where do the store spreadsheets come from?”

The answer isn’t in one system.

The answer is the history of how the organization learned to get work done.

Workarounds Have a Life Cycle

Most workarounds begin innocently.

The real process is broken.

Someone needs the numbers today.

So they create a spreadsheet.

Or a script.

Or a manual step.

Or a scheduled task.

Or an Access database.

Or a temporary table.

Or a stored procedure.

The intention is “We’ll fix this properly later.”

Later arrives.

The workaround is still there.

Then someone builds another process that depends on it.

Now you can’t remove the workaround because it’s a dependency.

Then the person who created it leaves.

Congratulations.

Your temporary solution has achieved tenure.

AI Didn’t Create the Technical Debt

This distinction matters.

When AI exposes one of these processes, the temptation will be:

“AI is giving inconsistent answers.”

Maybe.

But sometimes AI has stumbled into an inconsistency the organization has lived with for years.

Maybe the documentation says one thing.

The code does another.

The business does a third.

And the report compensates for all three.

AI didn’t create that mess.

AI removed our ability to ignore it.

That’s going to happen a lot.

“Why Does This Number Change on Tuesday?”

Imagine Jeannine asks, “Why does this number change every Tuesday morning?”

That’s a fantastic question.

The official documentation says the data refreshes nightly.

The pipeline says it completes successfully every night.

The database is healthy.

Power BI refreshes successfully.

Everything is green.

Then somebody discovers:

Every Monday afternoon, someone receives a file from a vendor.

They manually correct several records.

They place the corrected file into a folder.

A Tuesday morning job loads it.

That’s why the number changes.

There was nothing wrong with the AI.

There was nothing wrong with the pipeline.

There was nothing wrong with Power BI.

The missing piece was: the business process.

Successful Jobs Can Still Hide Manual Dependencies

We’ve talked before about how dangerous the word Success can be.

A pipeline can succeed.

A SQL Agent job can succeed.

A Fabric refresh can succeed.

An API call can return HTTP 200.

None of those tells you whether a human performed the undocumented step required before the automation ran.

That’s a different kind of dependency.

Your monitoring system sees: Job succeeded ✓

The business process may actually be: Jeannine remembered ✓

That’s not the same thing.

AI Can Discover Shadow Architecture

We talk about Shadow IT.

But I think there’s another useful term here: Shadow Architecture.

Systems and processes that became critical without ever becoming part of the official architecture.

The Access database.

The Excel workbook.

The shared folder.

The Cron job.

The SQL Agent job.

The PowerShell script.

The personal OneDrive file.

The API somebody built three years ago.

The stored procedure with no documentation.

The report everyone uses even though another report is supposedly the official one.

Individually, these may look insignificant.

Collectively, they may describe how the business actually operates.

And AI is going to encounter all of them.

This Can Be Extremely Valuable

I don’t want this article to sound like another reason to fear AI.

This is actually one of the things that excites me most.

Imagine someone asking, “How does customer onboarding actually work?”

And instead of returning the process document, AI helps identify:

• The documented workflow.
• The systems involved.
• The data movement.
• The scheduled processes.
• The manual interventions.
• The exception handling.
• The spreadsheets people actually use.
• The emails people rely on.
• The undocumented dependencies.

That could be extraordinarily valuable.

AI may help us build a more accurate picture of our organizations than our documentation ever did.

But there’s a catch.

Discovery Isn’t Understanding

Finding all the pieces doesn’t automatically explain why they exist.

Maybe AI finds:

A stored procedure.

A spreadsheet.

A recurring email.

A scheduled job.

It can identify relationships.

It can suggest that they might be connected.

But remember our rule: No Magic AI.

AI cannot automatically know that Jeannine changes Column H because a vendor has been sending an invalid code since 2019 and the downstream ERP rejects it.

Unless that knowledge exists somewhere AI can access…

someone still has to explain it.

This is where humans remain incredibly important.

AI can help uncover the architecture.

The people doing the work explain why the architecture looks like that.

Don’t Immediately Kill the Weird Thing

This is important for architects.

You discover an Access database sitting in the middle of a critical process.

Your first reaction may be to kill it.

Understandable.

But first let’s ask a few questions:

• What is it doing there?
• What problem did it solve?
• What business rule lives inside it?
• What does it compensate for?
• Who depends on it?
• What happens if it disappears?

That ugly workaround may contain ten years of institutional knowledge.

Modernizing the technology without understanding the behavior can remove something the business quietly depended on.

Sometimes technical debt is also business knowledge encoded badly.

Extract the knowledge before you eliminate the debt.

Document the Process You Actually Have

Once AI helps expose the real workflow, don’t just patch whatever immediate problem sent you looking for it.

Capture what you learned.

• Who owns the process?
• What starts it?
• Which systems participate?
• Where are the manual steps?
• What business rules are being applied?
• What exceptions occur?
• What happens when something fails?
• Which pieces are temporary?
• Which pieces are now critical dependencies?
• And perhaps the most important question, Is this actually the process we want?

Because documenting a terrible process doesn’t magically make it a good one.

But at least now we can see it.

And once we can see it, we can decide what to do about it.

The Architecture Diagram Should Make You Slightly Uncomfortable

If your architecture diagram is beautiful, that’s wonderful.

But if the actual production process includes:

Three spreadsheets.

A shared folder.

Two scheduled jobs.

A manual approval.

A legacy database.

And a callout to Jeannine…

put them on the diagram.

Architecture isn’t supposed to make us feel good.

It’s supposed to describe reality.

A messy accurate diagram is far more useful than a beautiful fictional one.

Your AI Will Find Organizational Archaeology

People are going to ask questions nobody used to ask.

And AI is going to follow connections nobody used to follow.

That means we’re going to discover:

• Old business rules.
• Forgotten integrations.
• Conflicting processes.
• Hidden dependencies.
• Shadow systems.
• Manual workarounds.
• Things everyone thought were retired.
• And things everyone assumed somebody else owned.

Some discoveries will be embarrassing.

Some will be terrifying.

Some will finally explain problems people have been fighting for years.

That’s not AI failure.

That’s visibility.

The Sherpa’s Lesson

AI doesn’t just consume your architecture.

It can expose it.

And what it exposes may look very different from the diagram hanging on the wall.

Your real architecture includes the systems you officially deployed.

But it also includes:

• The workaround.
• The spreadsheet.
• The scheduled task.
• The manual correction.
• The undocumented business rule.
• The person everybody calls when something looks wrong.

Those things were always there.

AI didn’t create them.

It just started asking enough questions to find them.

So when AI discovers some bizarre process involving Excel, an old stored procedure, a shared folder, and a scheduled job nobody remembers creating…

don’t immediately ask, “How do we stop the AI from using that?”

First ask, “Why is our company still using that?”

And then document what you discover.

Because once you’ve finally figured out how the business actually works, you have another problem.

How do you keep that documentation from becoming wrong again?

Because the moment you document the process…

…the clock starts ticking.

Next time: Your Documentation Was Correct Six Months Ago.