The Reliability of Corporate Memory

Every organisation eventually reaches a moment when somebody asks a deceptively simple question:

“Can somebody explain how this process actually works?”

The room goes quiet.

A few names are suggested. Someone mentions a spreadsheet. Somebody else recalls a workshop from five years ago. Eventually a long-serving colleague appears and begins to explain the process from memory.

Most organisations treat this as normal.

I’m beginning to think it is one of the biggest risks they face.

Twenty-five years ago, researchers Eveline van Stijn and Alan Wensley explored the relationship between organisational memory and enterprise resource planning systems. Their argument remains remarkably relevant today. They suggested that organisations do not store memory in a single place. Instead, memory exists simultaneously in multiple forms.

Some memory sits within people. Some exists within culture and shared assumptions. Some is embedded in organisational structures and governance. Some is encoded into processes, systems and technology.

The challenge is that these memories are rarely identical.

When organisations attempt to document a process, they are often documenting only one version of the truth.

The process map may describe how work is supposed to happen.

The system configuration may reflect how work happened when the software was implemented.

The governance structure may reflect decisions made years ago.

The staff carrying out the work may have developed practical workarounds that nobody has formally recorded.

All four memories coexist.

When they align, organisations perform effectively.

When they diverge, strange things begin to happen.

Teams cannot explain why decisions are made.

Projects discover conflicting interpretations of the same policy.

Different systems hold different versions of the same information.

Critical knowledge becomes dependent upon a handful of experienced individuals.

At this point organisations often respond by commissioning process mapping exercises.

Unfortunately, process mapping itself faces a fundamental problem.

Corporate memory is an unreliable narrator.

Ask ten people how a process works and you may receive ten different answers. None are necessarily wrong. Each person is describing the version of the process stored within their particular memory system.

The finance team remembers the controls.

Operations remembers the exceptions.

Technology remembers the workflow.

Leadership remembers the intention.

The process engineer is therefore not acting as a recorder. They are acting as an investigator.

Their role is not to write down what somebody says.

Their role is to triangulate evidence.

They compare stories against systems. They compare governance against outcomes. They compare documented procedures against observed behaviour. They identify where organisational memories align and where they conflict.

This distinction matters because modern organisations increasingly depend on digital platforms to preserve knowledge.

Enterprise systems, CRMs, compliance platforms and workflow tools all attempt to become repositories of organisational memory.

Yet no system can fully capture culture, informal decision making, historical context or tacit knowledge.

The value of enterprise architecture is therefore not simply that it stores process information. Its value lies in creating connections between all four forms of organisational memory.

A mature organisation does not seek a single source of truth.

It seeks consistency between its sources of truth.

Perhaps the purpose of process modelling is not to document processes at all.

Perhaps its real purpose is to test the reliability of corporate memory.

And in many organisations, that investigation reveals far more than anyone expected.