Perspective Is Operational Data

One of the most useful questions I ask when I am trying to understand a problem is also one of the simplest:

“From your understanding of how this works, tell me what you think happened.”

I am not asking because I expect the person to diagnose the system for me.

I am asking because I want their version of reality.

What did they see? What did they expect? What happened instead? What do they believe came before the failure? What happened afterward? Which part of the process feels normal to them, and which part feels wrong?

Their answer gives me something no system log can provide on its own.

Perspective.

The truth of a process is often scattered across the people who touch it.

Nobody sees the whole system from where they stand.

That does not make any one perspective wrong. It means each perspective is incomplete.

Operational Intelligence requires us to recognize the difference.

Where You Stand Changes What You Can See

I often ask people what they do for the company before I start digging into the problem.

That question may sound conversational, but it is diagnostic.

A person’s role tells me which part of the operation they can see clearly.

Someone working on an assembly line may understand exactly what happened at the moment production stopped. They may know the machine state, the item, the quantity, the timing, the physical material in front of them, and what they were trying to accomplish.

They may not know what happened when the demand was created.

They may not know how planning interpreted it, how the warehouse handled it, how the order was entered, or what happened upstream before the work ever reached them.

That does not make their knowledge less valuable.

It tells me where their visibility begins and ends.

So I may have to trace the lifecycle backward.

What was being produced?

Why was it being produced?

Where did the demand originate?

How was it planned?

What material was expected?

What was available?

What was picked?

What was consumed?

What was posted?

What happened before the person standing at the line ever touched the process?

Sometimes I walk through that lifecycle conceptually. Sometimes, when possible, I want to understand it physically too.

Show me where the material starts.

Show me who touches it next.

Show me what gets scanned.

Show me what gets written down.

Show me what happens when something goes wrong.

The system does not begin at the login screen.

That is one of the most important things to understand about supporting operational technology.

Software is embedded in work.

The work may begin with a customer placing an order, a technician repairing equipment, a truck arriving at a dock, an ingredient being received, a salesperson making a promise, a planner anticipating demand, or an employee noticing that something does not look right.

By the time the problem appears on a computer screen, half the story may already have happened.

Why “Show Me What You Did” Can Sound Like an Accusation

There is a question that technical people ask constantly:

“Can you walk me through the steps?”

It sounds harmless.

It is not always heard that way.

A customer who has been doing the same job for ten years may hear, “You must have done something wrong.”

Someone under pressure may hear, “Prove that this is really broken.”

Someone who has already explained the problem several times may hear, “Nobody listened to you the first three times.”

And sometimes people simply think, reasonably enough, “Why do you need me to show you? You are supposed to know how this system works.”

I understand that frustration.

But reproducing the steps is not about testing someone’s competence.

It is about discovering their operating reality.

Organizations do not all use the same software in the same way.

Configuration matters.

Customization matters.

Industry matters.

Staffing matters.

Approval structures matter.

Physical workflows matter.

Local habits matter.

Sometimes a standard process has been intentionally adapted. Sometimes it has evolved over time. Sometimes the system technically allows several ways to accomplish the same result, but one organization has built years of downstream processes around a specific sequence.

If I assume that the customer’s process is identical to the one I already know, I can miss the problem completely.

This is why “show me what you did” needs to be accompanied by curiosity rather than suspicion.

I am not asking because I assume you made a mistake.

I am asking because I do not yet know what you know.

There is a difference.

Expertise Is Knowing Where Your Knowledge Ends

I have spent a significant portion of my career working with Microsoft Dynamics NAV and Business Central.

It is an enormous system.

Finance, sales, purchasing, inventory, warehousing, manufacturing, service, projects, planning, costing, fixed assets, reporting, integrations, extensions, permissions, workflows, and industry-specific functionality can all exist within the same environment.

Then organizations configure it differently.

Partners customize it.

Third-party applications extend it.

Microsoft changes it.

Business processes evolve around it.

A person can spend decades working with the platform and still encounter areas they have rarely touched.

That is not a failure of expertise.

That is the nature of expertise in a complex system.

Expertise is not pretending to see everything.

It is understanding an area deeply enough to recognize when another perspective is required.

That may mean asking someone in manufacturing what the production process is supposed to accomplish.

It may mean involving a finance expert because the operational symptom ultimately traces back to costing.

It may mean asking a warehouse employee what actually happens at the dock rather than assuming the documented flow matches reality.

It may mean admitting that someone else knows this part better than I do.

That should not threaten expertise.

It should strengthen it.

There is a professional maturity in being able to say, “I understand this part very well, but I need another perspective before I can responsibly tell you what happened.”

Complex systems punish certainty that has not been earned.

Curiosity Is Part of the Job

Technical knowledge matters.

I need to understand what the software can do, how the data moves, where records are created, what configuration controls behavior, and what should happen under expected conditions.

But that is only half the problem.

To support technology well, I also have to be interested in what the customer actually does.

What do they make?

What do they sell?

What do they repair?

What do they move?

What do they record?

What do they promise?

How do they get paid?

What creates risk for them?

What does a mistake cost?

What happens physically when the system says something happened digitally?

Technical knowledge tells us what the system can do.

Industry knowledge tells us what the system is intended to accomplish.

The two are not interchangeable.

You can understand a production order perfectly from a software perspective and still misunderstand what matters on a factory floor.

You can understand inventory transactions perfectly and still miss why one warehouse movement is operationally unacceptable.

You can understand a service record perfectly and still miss what it means when a technician cannot get the part they need while standing in front of a customer’s broken equipment.

This is why intellectual curiosity is not a personality bonus in technical work.

It is a professional discipline.

You do not have to become an expert in every industry.

You do have to care enough to understand the work you are trying to support.

When someone explains how their business operates, they are giving you operational data.

Listen to it.

The Person Closest to the Failure Is Usually Under the Most Pressure

There is another reason perspective matters.

The software does not get blamed.

The system does not worry about losing its job.

The database does not have to explain to a manager why the shipment did not leave.

The person standing nearest the failure does.

That changes the conversation.

A warehouse employee who cannot post a transaction may not be thinking about data consistency or system architecture. They may be thinking about the truck waiting outside.

A planner dealing with an incorrect quantity may not care which table contains the value. They may be thinking about whether production will stop tomorrow.

A customer service representative may not care why an integration failed. They may be thinking about the angry customer they have to call back.

Pressure narrows perspective.

That is human.

This is where the technical expert and the operational expert can become far more valuable together than either one is alone.

I may understand what the system is doing.

They may understand what the work requires.

Between those two perspectives, we can often find something neither of us could have understood independently.

This is one of the principles I try to carry into every interaction:

Always try to bring people to your level. If they do not understand, help them understand. If they know more than you, listen and learn.

That is not just a communication philosophy.

It is a diagnostic method.

If I understand something the other person does not, hoarding that knowledge does nothing to strengthen the operation.

If they understand something I do not, pretending otherwise makes me less useful.

Operational Intelligence grows when knowledge moves in both directions.

Perspective Is Evidence

We tend to think of operational data as something structured.

Numbers.

Transactions.

Timestamps.

Logs.

Reports.

Dashboards.

Those are data.

So are repeated observations.

So are the explanations people give when asked why a process works the way it does.

So are the differences between what one department believes happens and what another department actually experiences.

Perspective is not always objective, but that does not make it useless.

A person may misunderstand why something happened.

That misunderstanding is still information.

It tells us what the system communicated to them.

It tells us what training they received.

It tells us what assumptions the process allows.

It may reveal why people make certain decisions.

If five people describe the same process five different ways, the correct response is not necessarily to decide which person is wrong.

The more interesting question is why the organization has five different versions of the truth.

That is operational data.

Sometimes the disagreement is the finding.

Reconstructing the Whole from Partial Views

Nobody sees the whole system from where they stand.

The person creating demand sees one part.

The planner sees another.

The warehouse sees another.

Production sees another.

Finance sees another.

The customer sees another.

The technical system records portions of all of it, but even the system only records what it was designed and configured to capture.

Operational Intelligence comes from connecting these views.

It means asking enough questions to reconstruct the lifecycle.

It means recognizing where knowledge changes hands.

It means understanding where assumptions enter the process.

It means noticing when the software’s version of reality and the human version of reality begin to diverge.

And it means resisting the temptation to assume that the person with the most technical knowledge automatically has the clearest view.

Sometimes they do.

Sometimes the most important piece of information comes from the person who has never opened the configuration page in their life but knows exactly what happens when the conveyor stops.

Perspective does not replace technical evidence.

It gives technical evidence meaning.

That distinction becomes especially important when we start measuring operational performance.

Because once we decide that a number represents reality, it becomes very easy to stop asking how that number was produced.

And that is where the next problem begins.

Before we measure the work, we need to understand whose work we are measuring, how it actually happens, and what the people inside the process can see that the metric cannot.

I Am Here for YOU.