Many enterprise data initiatives begin with a reasonable request: consolidate information so management can see the business in one place. Yet even after dashboards and data warehouses are in place, leaders often discover that visibility is not the same as operational understanding. They may know revenue, cost, inventory and progress, but still struggle to answer where work is stuck, what has just changed, why it changed, who owns the issue and what should happen next.

The reason is structural. Enterprise management cannot rely on one homogeneous category called “data.” Master records, ERP transactions, execution events, sensor signals, project documents, business rules and analytical indicators describe different dimensions of the same operating reality. A useful data foundation must therefore connect multiple layers rather than merely centralize more records.

This article goes one level beneath ERP to examine the data architecture required for management and operations. It explains five layers—master, transactional, execution, analytical and contextual data—and how their integration creates the foundation for real-time management, forecasting and enterprise AI.

1. There is no single enterprise data layer

A material master record and a warehouse issue transaction are both data, but they play different roles. The master record identifies a relatively stable business object. The issue transaction records an event. A status such as “awaiting inspection” describes execution. An on-time delivery KPI is an analytical result calculated from many events and states.

Each layer answers a different management question. Master data establishes what object the enterprise is talking about. Transaction data records what has formally happened. Execution data reveals how work is progressing. Analytical data exposes patterns and performance. Contextual data explains rules, relationships, documents and conditions that give numbers their business meaning.

Missing one layer can leave the enterprise numerically correct but operationally blind. A purchase order in ERP proves that an order was issued; it does not prove that materials will arrive when the project needs them. Risk assessment also requires supplier confirmation, committed delivery dates, shipment status, site demand and the downstream impact of delay.

Figure 1. Five data layers work together to create a complete management picture.

2. Master data: creating a common business language

Master data describes the core entities repeatedly referenced across transactions and systems: customers, suppliers, materials, products, assets, employees, projects, organizational units, accounts and cost structures. Its value is not the number of attributes stored. Its value is consistent identity and meaning.

An enterprise can run ERP, CRM, project management and warehouse systems and still lack a single view of a customer if each platform uses different identifiers or classifications. The same problem appears when one material has multiple codes or units of measure. Individual systems may remain internally consistent while enterprise-wide inventory, procurement and profitability analysis becomes unreliable.

Effective master data management therefore addresses identity, definitions, relationships and ownership. It determines which entity is unique, how attributes are defined, how objects relate to one another, and who can create, modify or approve critical records.

This becomes even more important with AI. Models can process inconsistency at extraordinary speed, but speed does not correct meaning. Forecasting cannot be trusted when the same material is fragmented across codes, and an AI agent should not autonomously select suppliers when supplier identity, relationships, history and approval status are unreliable.

Figure 3. Master data creates a common language across systems and functions.

3. Transaction data: the formal record of business activity

Transaction data is created when a business event is formally recorded: quotations, sales orders, purchase requisitions, purchase orders, receipts, issues, production orders, acceptance records, invoices, payments and accounting postings. Traditional ERP systems are particularly strong at this layer because transactions are governed by workflow, authority and integrity controls.

Transaction data provides both auditability and economic linkage. It shows what was done, by whom, when and at what value. It also connects operations to finance: a material issue can affect not only inventory but also project cost, production cost or a cost center.

Its limitation is equally important. Transactions usually represent discrete checkpoints. The period between two checkpoints may contain substantial operational change. If a purchase order is issued on day one and the goods receipt appears on day fifteen, a transaction-only view leaves a fourteen-day blind spot. Execution data is required to understand what is happening in between.

4. Execution data: seeing work while it is happening

Execution data describes the states, events and actual progress between plan and completed transaction. In manufacturing it includes work-order status, shift output, downtime, work in progress and quality results. In construction it includes site diaries, completed quantities, inspection status, labor and equipment deployment. In administrative workflows it includes queue status, approval waiting time, rework and exception reasons.

This layer is essential to real-time management because leaders cannot wait for the final transaction to learn that a process is already failing. A month-end report may confirm that a schedule slipped; execution data should expose the early signals—excess waiting time, unavailable resources, abnormal equipment stoppage or an approval bottleneck—while intervention can still change the outcome.

Execution data is also harder to govern. It is distributed across MES, field applications, task systems, IoT platforms, spreadsheets, diaries and informal communication. The goal is therefore not to collect everything. The enterprise should define the states and events that have management significance and capture them where work actually occurs.

A practical test is whether the data helps answer three questions: What is the current state? What just changed? Does that change require action? Data that cannot support a decision or control may cost more to collect than the value it creates.

Figure 2. Operations require status, events, causes and actions—not transactions alone.

5. Analytical data: turning history into management signals

Analytical data is usually derived from master, transactional and execution layers through aggregation, calculation and modeling. KPIs, revenue trends, inventory turns, on-time delivery, equipment performance, budget variance and cash-flow forecasts all belong here.

The difference between reporting and analytics is the question being answered. Reporting describes what happened. Strong analytics progresses toward why it happened, where the trend is heading and what may happen without intervention. KPIs should therefore not exist as isolated numbers. Each should connect to a management objective, a clear data lineage, an appropriate refresh frequency and an action mechanism when thresholds are breached.

Latency should also reflect the decision. Not every dataset needs millisecond updates. Formal financial reporting can remain periodic, while equipment stoppage, material shortages and at-risk orders may require very low latency. Real-time management means information arrives before the decision loses its ability to change the result.

6. Contextual data: the layer analytics often misses and AI increasingly needs

Numbers rarely explain themselves. Five hundred units of inventory can be high or low depending on demand, lead time, safety stock, seasonality and production plans. A ten-day project delay may be critical or manageable depending on the critical path, contractual terms, recovery options and downstream dependencies. These meaning-making elements are business context.

Context can reside in policies, contracts, drawings, technical instructions, meeting records, email, project documents, object relationships and metadata that describes definitions and provenance. Much of it is semi-structured or unstructured, which is why traditional reporting environments often left it outside the analytical model.

AI changes the economics of using contextual information. Language models can process documents, but the ability to read text is not the same as understanding the enterprise correctly. To explain contract risk or prioritize a purchase order, AI must connect transactions to policies, documents, relationships and history. Enterprise AI therefore needs business context, not data alone.

Metadata, catalogs and lineage become control mechanisms in this environment. Users and AI systems need to know where data came from, how it was transformed, who owns it and under what conditions it can be used. Without provenance, a plausible answer can still create a governance risk.

7. Management data architecture: connect layers instead of building another silo

A common mistake is to define the target architecture as a project to move all data into one repository. Centralization can support analytics, but a modern architecture must simultaneously handle operational, historical, real-time and document data together with a semantic and governance layer. Some decisions need years of history; others depend on an event from seconds ago; an AI agent may need both plus policy and authorization context.

Source systems include ERP, CRM, MES, BIM, IoT and industry applications. Integration moves information through APIs, event streams and ETL/ELT pipelines at appropriate latency. Data platforms organize historical and operational information. Metadata, catalogs, lineage, business definitions, quality controls and access policies provide governance and semantics. BI, forecasting models and AI agents then consume these layers for insight and action.

The architecture should preserve system responsibilities. ERP remains the control point for transactions; MES remains responsible for production execution; BIM retains model context. A data platform should not become a second ERP. Its purpose is to enable cross-system use while preserving sources of truth, ownership and traceability.

Figure 4. A management and AI data architecture connects source systems, integration, data, semantics and consumption.

8. Build the data foundation from management decisions, not data accumulation

Data programs often fail when they begin by asking what data the company has and then attempt to collect all of it. A more practical approach starts with decisions that need improvement. Does the enterprise need to reduce material shortages, forecast schedule delay, control cash flow or shorten approval time? Each decision implies a different data set, latency requirement and quality threshold.

From the target decision, teams identify required sources and gaps. They then standardize identifiers, definitions, ownership and quality rules; design integration flows; and measure whether the resulting data actually changes decisions. This turns data governance from a technical program into a management capability.

Data quality should also be prioritized by decision impact. A missing field with no operational consequence may matter less than an incorrect delivery date that causes a shortage forecast to fail. Linking quality to use cases helps organizations invest where errors have real business cost instead of pursuing an unattainable state of perfect data.

Finally, the data foundation must be operated as a living product. Systems change, processes change, definitions change and AI creates new patterns of consumption. Enterprises need continuous ownership, quality monitoring, change management, lineage and adoption measurement if data is to become part of the management operating system rather than an asset sitting in storage.

Figure 5. A data-foundation roadmap should begin with the decision that needs to improve.

Conclusion

An enterprise does not become data-driven simply by accumulating more data. The capability emerges when master data gives functions a common language, transactions provide an official record, execution data reveals what is happening now, analytics converts history into signals, and contextual data allows both people and AI to interpret those signals correctly.

When these layers are connected through governed architecture, the enterprise can shorten the distance from event to awareness, awareness to decision and decision to action. That is also the foundation on which BI, predictive models and AI agents can create operational value rather than add another technology layer.

The critical question is therefore not how much data the enterprise owns, but whether it has the right data, with the right context, at the right time and with enough trust to support action.

References

• IBM (2026), The 2026 Guide to Data Management.
• IBM (2026), What it takes to build an AI-ready data foundation: Insights from Think 2026.
• Microsoft Learn, Master Data Management reference architectures with Microsoft Purview.
• Microsoft Learn (2026), Data and AI governance architecture guidance.
• NIST (2026), Data Governance and Management Profile working materials; AI Risk Management Framework resources.