What is operating intelligence?

Operating intelligence is a connected, current understanding of how a business is operating.

It answers practical questions: What is happening now? What changed? Which source supports that view? Where do systems disagree? Who owns the next decision? What action is appropriate, and what still needs human judgment?

This is different from adding another dashboard or copying every record into a new database. The work begins with a business outcome, then makes the data, relationships, decisions, and operating habits around that outcome clear enough for people and software to use responsibly.

Start with the business outcome

An organisation can connect large amounts of data and still create little value.

The useful starting point is a defined operating outcome: reduce manual coordination around orders, improve fulfilment accuracy, shorten supplier review, control project change, improve service continuity, or reduce the time required to prepare a management decision.

That outcome determines scope.

If the goal is more reliable order updates, the relevant data may include customer orders, product revisions, production events, quality holds, shipment state, and promised dates. If the goal is faster supplier qualification, the boundary may include requirements, quotations, certifications, samples, payment history, logistics events, and approval ownership.

The system does not need every record in the company. It needs the evidence and relationships that explain the outcome, including the cases where the evidence is incomplete or contradictory.

This also makes value measurable. Time spent reconstructing status, repeated data entry, avoidable exceptions, delayed approvals, correction rates, or missed commitments can be baselined before implementation. The technology then has to improve an observable part of the operation rather than create abstract AI activity.

Audit, clean, and reconcile before automating

The first technical task is not automation. It is understanding the source data.

Approved systems and records need to be audited for:

• identity: whether two records refer to the same customer, product, supplier, asset, order, or project;
• authority: which system or role owns a particular fact;
• freshness: when a record last changed and whether that timing is sufficient for the decision;
• completeness: which fields, events, or relationships are missing;
• consistency: where terms, units, states, and definitions differ;
• permissions: who may access the source and for which purpose;
• provenance: where a value came from and how it was transformed.

Cleaning does not mean forcing every source to contain the same value. Two systems can disagree for a legitimate reason. A CRM may hold a customer promise while an ERP holds a planned production date. A quality system may block material that an inventory system still counts physically. Reconciliation should expose the relationship and the conflict rather than silently select the most convenient answer.

Existing systems remain authoritative for the records they own. The connected view records source identifiers, timestamps, permissions, mapping rules, and provenance so a reviewer can understand why the current state appears as it does.

W3C's PROV framework describes provenance as information about the entities, activities, and people involved in producing data or a thing. That is useful here because a connected operational fact needs a traceable history, not only a value ^{2W3C PROV Overview}.

Four technical layers support the operating model

The implementation can be understood through four technical layers. They explain how the system is assembled without replacing the outcome-led sequence above.

• Ingestion: approved signals enter from documents, messages, meetings, forms, calendars, operational systems, databases, and user updates with source, time, ownership, and permission attached.
• Processing: raw material is cleaned, deduplicated, normalised, permissioned, linked, and reconciled into the concepts the organisation actually uses.
• Durable state: the resulting records and relationships live in databases, indexes, document stores, knowledge graphs, workflow logs, and audit records that can be queried and corrected.
• Controlled interfaces: people and agents search, review, edit, route, approve, and write back through tools whose actions and authority are explicit.

Retrieval without controlled tools leaves the system as an adviser. Tools without governed state let action outrun understanding. Operating intelligence requires both: a durable account of the work and bounded ways to use it.

The ontology creates a shared operating language

Once the relevant data is understood, a business ontology provides the connected map.

An ontology describes the entities, relationships, states, and terminology that matter to the operating area. It can connect customer order to order line, product revision, work order, quality state, shipment, promise, and owner. In property work, it may connect project, document, revision, change, approval, instruction, acknowledgement, and downstream commitment.

The W3C Web Ontology Language was designed to represent classes, properties, relationships, and meaning in a machine-readable form ^{1W3C OWL 2 Web Ontology Language Overview}. A business ontology applies the same underlying idea to the organisation's own operating language.

This is the practical meaning of a connected source of truth. It is not a claim that one database has replaced every system of record. It means the organisation has a shared, source-linked explanation of how current records relate, which definition applies, and where uncertainty remains.

An ontology earns its place when simpler approaches stop being enough.

If a team only needs better naming or document control, improve that first. If two stable systems need a few well-defined fields, a targeted integration may solve the problem. If approved records are difficult to find, search and indexing may be sufficient.

The ontology becomes valuable when several systems describe the same operation differently, when the relevant state depends on relationships across those systems, or when repeated exceptions reveal that a single fixed schema cannot explain the work.

Interfaces should match the user's operating world

The connected model is not the interface.

Different roles see the operation through different responsibilities. A sales user needs a dependable customer-facing status and a concise explanation. A planner needs constraints and sequence. A quality specialist needs evidence and release authority. A manager needs exceptions, ownership, and business impact.

Showing all of them the same record does not create alignment. It transfers the work of interpretation back to the user.

An operating interface should therefore reflect:

• the business outcome the user is trying to influence;
• the entities and language familiar to that role;
• the evidence required for the decision;
• the actions available in that operating context;
• the approval and escalation boundaries;
• the exceptions that deserve attention.

This is why automation and interface design come after the data and ontology work. Workflow automation is useful when steps are defined and observable. IBM describes it as using software to execute part or all of a process ^{5IBM, What is workflow automation?}. Operating intelligence provides the context needed to decide which process state is actually present and whether the next step is appropriate.

Some work can be automated. Some can be prepared for review. Some should be escalated. Some remains human because the consequence depends on professional, commercial, technical, or relationship judgment.

Training is part of the operating system

A technically correct system can still fail if people do not understand or trust it.

New interfaces and automations change how staff interpret information, correct errors, hand over work, and make decisions. Adoption therefore requires communication, practice, and feedback, much like onboarding a new colleague.

Teams need to learn:

• what each connected state means;
• which source remains authoritative;
• how uncertainty and conflicts are shown;
• how to correct a wrong identity or relationship;
• which actions require approval;
• how feedback changes later results.

Training should use real work, including edge cases. Standard cases prove that the path works. Exceptions reveal whether the ontology, source timing, interface, and authority model fit the operation.

Repeated corrections are not simply user error. They may show that source capture is late, the ontology is incomplete, a definition has changed, or the workflow no longer matches how the business operates. Refinement turns those corrections into better mappings, controls, interfaces, and training.

NIST's AI Risk Management Framework treats risk management as a continuing cycle of governance, mapping, measurement, and management. That lifecycle perspective is important because operating intelligence is not finished when the first interface launches ^{3NIST AI Risk Management Framework}.

How this differs from business intelligence

Business intelligence and operating intelligence overlap, but they answer different questions.

IBM describes business intelligence as processes for collecting, managing, and analysing organisational data to inform strategy and operations ^{4IBM, What is business intelligence?}. BI is often strongest at reporting what happened, comparing performance, and showing trends.

Operating intelligence focuses on the connected current state needed to move work:

The categories can work together. A management view may use BI metrics, authoritative records, workflow events, and a business ontology to explain both performance and the live exceptions behind it.

Boundaries matter most with sensitive information

A connected view does not imply unrestricted access.

Purpose, permissions, and audience determine what can move between sources and interfaces. In occupational therapy, for example, private practitioner working notes and organisational summaries serve different purposes. Private notes do not automatically enter a wider connected view. Any transfer into an organisational summary requires a defined purpose, an access boundary, and review by the responsible practitioner.

The same principle applies elsewhere. A factory supervisor does not need every commercial detail. A maintenance team does not need a guest's loyalty history. A supplier reviewer may need qualification evidence without access to unrelated financial records.

The single connected view is permissioned and role-specific. Connection makes relevant relationships legible. It does not erase confidentiality, source ownership, or professional responsibility.

The argument for operating intelligence

Operating intelligence is useful when the cost of fragmented context becomes material.

The sequence is straightforward:

1. Define the business outcome and how value will be measured. 2. Audit, clean, and reconcile the approved data needed to understand it. 3. Build an ontology that connects the relevant entities, relationships, states, and terms while preserving authoritative sources. 4. Shape interfaces and automation around the workflow, user, authority, and operating environment. 5. Train with real work, learn from corrections, and refine the system as the operation changes.

The result is not a perfect model of the entire company. It is a more understandable operating area: one connected enough that people can see what is current, software can prepare useful work, and accountable decisions can move with less manual reconstruction.

Sources

1. W3C OWL 2 Web Ontology Language Overview
2. W3C PROV Overview
3. NIST AI Risk Management Framework
4. IBM, What is business intelligence?
5. IBM, What is workflow automation?