The Operating System of Transformation

Over the years, one of the things I have come to believe strongly is that policies and standard operating procedures are badly underestimated in business transformation.

They are often treated as documentation—something to complete toward the end of an implementation, something needed for training, compliance, or an audit.

I think that is exactly backwards.

Policies and SOPs should be part of the transformation itself because they force an organization to answer some very basic questions:

How are we actually going to operate? Who owns what? Where are the handoffs? What happens when the normal process does not work? Who can make an exception? Who needs to participate in testing? And who ultimately has the authority to say that the business process works?

These are not documentation questions.

They are transformation questions.

Anyone who knows me knows I like analogies, so I will use one.

Think about the human body.

Finance, sales, operations, technology, supply chain, customer service, human resources, and other functions are a little like the organs. Each has a specialized role. Each can perform its individual responsibilities very well.

But the body does not work simply because every organ works independently.

It works because those organs are connected through systems that allow the whole body to function.

Business processes work the same way.

Most organizations are structured vertically by function, but the business operates horizontally through processes.

An order may move from sales to credit to inventory to the warehouse to transportation to billing and eventually to collections.

The customer does not care where one department ends and another begins.

The customer experiences one process.

And this is where transformation frequently gets into trouble.

Every individual function may believe its part of the process works.

Sales works. Finance works. The warehouse works. The applications work. The integrations work.

Yet the end-to-end business process can still be broken.

The problem is often in the connections.

Testing the business, not just the technology

I have seen transformations where enormous attention is placed on technical testing.

Did the interface work? Did the data move? Did the transaction post? Did the API respond?

Those are important questions.

But the more important question is:

Does the business work using the new technology?

If the organization has never clearly agreed on how the process is supposed to operate, that becomes surprisingly difficult to answer.

What exactly are we testing against? Which scenarios matter? What exceptions need to be tested? Who needs to participate? Who determines whether the result is correct? Who signs off?

This is why I believe a good SOP can be one of the most valuable inputs into an end-to-end testing strategy.

It defines the expected process, the handoffs, the business rules, the responsibilities, and the exceptions.

And those exceptions matter.

What happens when inventory is unavailable?

When an address cannot be validated?

When an integration fails?

When an approval is denied?

When a customer changes an order after fulfillment begins?

When someone needs to override the normal process?

Those are not simply software tests.

They are business tests.

The SOP also helps tell us who needs to be in the room.

If a process crosses six functions, those functions need to participate in validating it. Otherwise, each department may sign off on its individual piece while no one has actually validated the whole.

That is not merely a testing issue.

It is an operating-model and governance issue.

It is also common for organizations to struggle when asked to define and agree on policies and SOPs.

I do not view that as unusual.

In many cases, the organization simply has not exercised those muscles.

People become very good at operating within their own function. They rely on experience, relationships, institutional knowledge, and often years of workarounds to get things done.

Then a transformation asks everyone to sit down together and explicitly agree on how an end-to-end process should operate.

That exercises a different set of organizational muscles.

Who owns this decision?

Where does responsibility transfer?

Which source of information is authoritative?

Why do we have this exception?

Is it really a business requirement, or something we do because an old system forced us to do it?

Who has the authority to change it?

Those conversations can be difficult.

That is not a reason to avoid them.

In fact, the difficulty is telling you something important: the transformation is exposing ambiguity that already exists in the business.

If the organization cannot agree on how the business is supposed to work, it is difficult to argue that the technology supporting it has been properly designed or tested.

Without that discipline, transformation success starts to depend far too much on luck.

Don’t automate the inefficiency

Another common mistake is taking the current process and simply automating it.

That can feel like progress.

It is not always transformation.

If a process is inefficient today, automation does not necessarily fix it. Sometimes it simply makes the inefficiency happen faster.

A five-step approval process that should require two approvals does not become a better process because workflow automation moves it through all five steps more quickly.

Duplicate data entry does not become good process design because software performs it instead of a person.

And a workaround created because of a limitation in an old system should not automatically become a requirement for the new system.

Transformation should force us to ask why.

Why do we do this?

Does this step still create value?

Is this control still necessary?

Could this decision be automated?

Could we capture the information once instead of several times?

Could we eliminate a handoff?

Are we solving a real business requirement—or preserving a historical workaround?

Without that examination, organizations can spend significant amounts of money automating the very inefficiencies the transformation was supposed to remove.

That may produce automation.

It does not necessarily produce transformation.

This is also where late software changes often originate.

Anyone who has been through a large transformation has probably heard this late in the project:

“We also need the system to do this.”

Sometimes it really is a new requirement.

Often it is an existing business requirement that was never surfaced because the process was never completely understood.

Now the configuration changes. An integration changes. A control has to be added. Testing has to be repeated. Training changes. The schedule moves.

What appears to be a late technology problem may actually have started months earlier as a process-definition problem.

Transformation should reduce debt, not refinance it

We talk a lot about technical debt.

I think transformation leaders need to think much more broadly about debt.

A company can spend millions replacing an old platform and still finish the transformation carrying significant debt.

In some cases, it simply replaces one kind of debt with another.

In worse cases, it compounds the debt it already had.

There can be process debt when inconsistent practices and workarounds are carried into the future state.

There can be knowledge debt when critical decisions and operating knowledge remain in the heads of employees or consultants.

There can be data debt when ownership, definitions, quality expectations, and authoritative sources remain unresolved.

There can be governance debt when decision rights and accountability remain unclear.

And there can be operating debt when a new platform is implemented without developing the disciplines required to operate it effectively.

The technology may be new.

The problems are not.

I sometimes think of this as refinancing the debt rather than paying it down.

The old application disappears, but the workaround survives.

A consultant solves a problem, but no one captures how it was solved.

An exception is resolved during testing, everyone agrees on the answer, and six months later no one remembers why the decision was made.

A transformation should leave the organization with less debt, not simply newer technology.

Knowledge should outlive the transformation

The knowledge created during a transformation is incredibly valuable.

Business rules. Process decisions. Architecture decisions. Testing scenarios. Exceptions. Failure modes. Controls. Vendor knowledge. Data definitions. Lessons learned. Why one option was chosen over another.

Much of this knowledge has traditionally been scattered across email, presentations, project-management tools, meeting notes, shared drives, and people’s heads.

Then the project ends.

Consultants leave. Employees change jobs. Vendors change.

And the organization slowly loses knowledge it already paid to acquire.

That makes no sense.

When policies, SOPs, architecture decisions, test scenarios, exceptions, and lessons learned reside in a maintained knowledge base, something important changes.

The information becomes available to the organization—not just the people who happened to participate in the transformation.

A new employee can benefit from a decision made years earlier.

An operations team can understand why a control exists.

A technology team can understand the business impact when an interface fails.

A future project can reuse what the previous project learned instead of starting over.

And as processes change, that knowledge can be updated and sustained.

That last point is critical.

The goal is not to create a perfect snapshot of how the organization operated on the day the transformation went live.

The knowledge has to live with the business.

Otherwise, today’s institutional knowledge becomes tomorrow’s knowledge debt.

AI makes this even more important

Organizations are rapidly moving from AI as a tool that answers questions to AI agents that can perform work.

I think there is something useful in thinking about an AI agent as a form of non-human employee.

When a human employee joins an organization, we do not simply give that person access to a powerful computer and tell them to figure everything out.

We provide context.

Here are the policies.

Here is how the process works.

Here is what you are authorized to do.

Here is what requires approval.

Here is who owns the next step.

Here is what to do when something goes wrong.

Here is when you need to escalate.

An AI agent needs organizational context for exactly the same reason.

If we expect an agent to participate in real business processes, it needs governed access to current policies, SOPs, business rules, controls, ownership, architecture, prior decisions, testing scenarios, and lessons learned.

This is where the knowledge base becomes much more than a place to store documents.

It becomes part of the operating environment for the digital workforce.

The AI model provides intelligence.

The knowledge base provides organizational context.

Policies establish boundaries.

SOPs provide operating instructions.

Governance establishes authority.

Testing tells us whether the process actually works.

And the knowledge base allows all of this to be sustained as the business changes.

That creates a continuous loop: the business operates, the organization learns, the knowledge base is updated, people and AI agents consume the updated knowledge, and the process continues to improve.

It also raises the standard for knowledge management.

An outdated SOP is no longer simply an old document that an employee may or may not find.

It could become information an AI agent uses to perform work.

Knowledge therefore needs ownership, version control, review, and retirement of obsolete information.

If AI agents are going to become part of the workforce, maintaining organizational knowledge will increasingly become part of managing that workforce.

The objective was never the document

The objective of a policy or SOP is not to produce a document.

The objective is to make the organization more capable.

To create alignment across functions.

To improve requirements.

To strengthen testing.

To clarify who participates and who signs off.

To reduce late surprises.

To avoid automating inefficiency.

To pay down technical, process, data, governance, operating, and knowledge debt.

To preserve what the organization learns.

And increasingly, to provide both people and AI agents with the context they need to operate effectively.

Coming back to the body analogy, transformation should not simply replace one organ and declare the patient healthy.

We need to understand how the whole body works together.

And we need to leave it stronger than we found it.

For me, that is one of the real tests of transformation:

Did we simply implement new technology, or did we leave the organization better able to understand how it works, operate consistently, test what matters, learn from experience, reduce its debt, and sustain that knowledge long after the transformation team is gone?

If we accomplish the latter, we have done more than modernize technology.

We have actually transformed the business.