In my previous post, I argued that Critical Data Elements are not defined by importance. They are defined by process dependency. Data does not become critical because it exists or because it sounds important. It becomes critical because something in the business breaks when it is wrong, late, missing, or ambiguous.

That insight exposes a deeper theme.
If we want to understand why data matters, we must first understand the work it supports.

And that means starting, and ending, with the business process.

Too often, when organisations map processes, they draw boxes and arrows that look tidy but hide what matters most: the data.
Who creates it? Who uses it? Why does it need to be right here and now, and not just somewhere later in the chain?

Processes drawn purely as sequences of actions are comfortable because they are familiar. But they conceal the dependencies that determine whether work flows smoothly or grinds to a halt.

Start with the process, but draw it data-aware

Most process diagrams focus on activities. Someone does something, then someone else does something else. The logic of work is visible, but the logic of data is not.

That omission is not harmless. It hides where data is created, where it is trusted, and where it quietly becomes a dependency for everything that follows.

Instead, for every step in the process, we should explicitly ask:

• What data is created, read, updated, or validated here?
• Where does that data come from?
• Where does it go next?

These questions force data back into the process, where it belongs.

A simple rule helps keep this discipline.

If a step touches data, the data must be visible in the diagram.

Not as a footnote. Not as an assumption. Not buried in documentation somewhere else. It must be there, next to the activity that depends on it.

Once you do this, process diagrams stop being comforting pictures of flow and start becoming explanations of dependency. They reveal where errors originate, where quality matters most, and where Critical Data Elements naturally emerge through use, not definition.

Keep the notation simple

I also prefer to use minimum notation when drawing processes. The goal is not to create perfect models. It is to create shared understanding.

• Boxes represent activities. Something happens here.
• Data objects, such as documents, records, or datasets, are attached directly to the activities that create or use them.
• Arrows show data movement, not just control flow. They indicate where data actually travels.
• Swimlanes represent roles, systems, or domains. They make responsibility and handovers visible.

This minimal approach keeps diagrams accessible. Business experts can read them. Technologists can reason about them. Governance discussions are grounded in the same picture, instead of competing interpretations.

Add a Data Interaction Matrix

To complement the diagram, I often add a Data Interaction Matrix. This is where dependencies stop being abstract and start becoming visible.

For each step in the process, capture a simple table like this:

Process Step	Data Entity	Action	System	Owner
Capture Customer Data	Customer	Create	CRM	Sales
Validate Master Data	Customer	Validate	ERP	Master Data
Credit Vetting	Customer	Read	ERP	Finance
Sanctions Screening	Customer	Read	Screening Tool	Compliance
Activate Customer	Customer	Update	ERP	Sales

This is not documentation for its own sake. It is a thinking tool.

Patterns quickly emerge:

• The same data entity is touched in multiple steps
• The same data is owned by multiple areas
• Critical data is read far more often than it is created or updated

These patterns are dependency hotspots. They highlight where shared understanding, quality, and accountability are most important.

Flip the view: Data to Process

Once the process is mapped, flip the perspective. Instead of looking from process to data, look from data to process.

Pick a single data entity such as Customer, Material, or Vendor. Then ask:

• Where is this data created?
• Where is it enriched?
• Where is it validated?
• Where is it consumed?
• Where does it break?

This perspective makes the data the thread that ties multiple processes together. What looked like separate flows are actually connected through shared dependencies.

Surprises often appear. Data that was assumed to be owned in one place is shaped elsewhere. Validation happens after consumption. Corrections are made downstream, long after errors have already affected other processes.

Following the data instead of the arrows makes gaps visible, handovers obvious, and accountability clearer. This is usually where processes fail quietly.

Identify dependency types

Not all dependencies are equal. Mark them.

Common dependency types include:

• Temporal – one step must exist before another (for example, a customer must exist before an order is created)
• Quality – accuracy, completeness, or validity affects downstream use
• Structural – format, code lists, or hierarchies must be followed
• Ownership – who is allowed to create or change data
• System – integration or replication dependencies between systems

A simple icon, colour code, or label works wonders. It instantly shows which dependencies matter most and why.

Making dependency types explicit turns static diagrams into living tools. They show where errors are likely to propagate and who needs to be involved to prevent them.

Connect to business pain

Finally, connect dependencies to business impact. Dependencies alone are interesting. Real understanding comes when you ask what happens if they fail.

For each critical dependency, ask:

• What happens if this data is wrong or late?
• Who notices first?
• Who fixes it today?
• Where is the feedback lost?

Answering these questions naturally leads to:

• Data quality rules – protections where they matter most
• Ownership clarification – who is accountable for the data and its flow
• Feedback loops – mechanisms to learn from errors, not just fix them

This aligns perfectly with the principle that governance must start with business perception, not frameworks. Governance only works when it addresses real pain, visible in real processes, felt by the people doing the work.

When you connect the data to the process and to the business impact, governance stops being abstract. It becomes real, actionable, and directly tied to the way the organisation operates.