Operations Data, Business Intelligence and Analytical Workflow

Introduction

Operations and supply chain decisions depend on the quality, timeliness and interpretation of data. A purchasing manager deciding when to reorder, a warehouse supervisor allocating labour, a transport planner selecting a carrier, and a service manager investigating late deliveries all rely on operational information. Yet operational data are rarely created for analysis alone. They are generated by transactions, machines, employees, suppliers, customers and external institutions, often in different formats and with different definitions.

Operations and supply chain analytics therefore begins before a model is fitted. Analysts must identify relevant data sources, understand how data are produced, assess their reliability, prepare and validate datasets, recognize missingness and bias, communicate findings through visualizations and dashboards, and preserve a reproducible record of the analytical workflow. Business intelligence (BI) provides the infrastructure and reporting practices through which operational data become accessible to decision-makers; analytics adds diagnostic, predictive and prescriptive reasoning.

This chapter develops a practical framework for turning operational data into trustworthy decisions.

Learning Objectives

By the end of this chapter, you should be able to:

1. Classify internal, supplier, logistics, customer and external operations data.
2. Explain how transactional systems, data warehouses, data lakes and BI tools support analysis.
3. Prepare operational data through integration, cleaning, transformation and validation.
4. Diagnose missing data, measurement error, selection bias and data leakage.
5. Select suitable visualizations and dashboard measures for operational decisions.
6. Design a reproducible analytical workflow with appropriate governance and documentation.
7. Evaluate the ethical, managerial and technical limitations of operational analytics.

1. The Role of Data in Operations and Supply Chains

Operations data describe resources, activities, flows and outcomes. Typical entities include products, orders, suppliers, facilities, vehicles, employees, customers and shipments. A useful data record has at least four dimensions:

• What occurred: an order, receipt, production run, delivery or complaint.
• When it occurred: transaction time, event time or reporting time.
• Where it occurred: plant, warehouse, route, store or customer location.
• How much or how well it occurred: quantity, cost, duration, quality or service level.

Data become information when they are placed in context. For example, 240 late orders is only a count. The percentage of late orders by carrier, product family and customer priority is more informative. Analytics goes further by investigating causes, estimating future conditions and recommending action.

A central distinction is between event data and master data. Event data record activities such as sales orders or goods receipts. Master data define relatively stable entities such as supplier identifiers, product dimensions, warehouse codes and customer segments. Errors in master data can affect every event associated with an entity and are consequently especially damaging.

Another distinction is between granularity and aggregation. Granularity is the level at which a record is observed: one order line, one shipment, one machine reading or one day. Aggregation combines records into summaries. Analysts must not combine data at incompatible granularities without care. Joining daily inventory data to order-line data, for example, may duplicate inventory values across many lines and produce an incorrect total.

2. Sources of Operations and Supply Chain Data

Internal data sources

Internal operational systems commonly include:

• enterprise resource planning (ERP) systems for purchasing, production, inventory, finance and order processing;
• warehouse management systems (WMS) for receipts, put-away, picking, packing and dispatch;
• transportation management systems (TMS) for routes, carriers, freight costs and delivery events;
• manufacturing execution systems (MES) for production quantities, machine states, downtime and quality;
• point-of-sale and e-commerce systems for demand transactions;
• maintenance systems for asset inspections, work orders and failures;
• workforce systems for shifts, attendance, skills and labour hours; and
• Internet of Things (IoT) devices, scanners, sensors and automated equipment.

Internal data are often detailed and timely, but they may reflect local processes rather than the complete supply chain. A sales system may record an order date but not the supplier’s production delay. An ERP may show a planned delivery date that differs from the customer-promised date.

Supplier data

Supplier-provided data include quotations, capacity statements, purchase-order acknowledgements, advance shipping notices, production schedules, certificates of conformance, shipment status and invoices. Supplier data are valuable for assessing lead-time reliability, quality and capacity risk. They also require validation because suppliers may use different product codes, calendars, units of measure and definitions of “on time.”

A supplier’s reported on-time delivery rate should therefore be accompanied by its denominator and date rule. For example, on-time delivery may mean delivery on or before the requested date, the confirmed date or the appointment date. These are different measures.

Logistics and carrier data

Logistics data include tracking scans, GPS positions, planned and actual departure and arrival times, route distance, dwell time, fuel use, freight charges, damage records and proof of delivery. Such data support carrier comparison, route analysis, estimated-time-of-arrival monitoring and investigation of bottlenecks.

Event timestamps require particular care. “Shipment created,” “picked up,” “arrived at terminal,” “out for delivery” and “delivered” are distinct events. Treating the first available timestamp as the delivery time creates measurement error.

Customer data

Customer sources include orders, returns, service contacts, complaints, ratings, cancellations, delivery preferences, clickstream records and loyalty activity. They help estimate demand, identify service failures and segment customer requirements. Customer data may contain privacy-sensitive information and should be collected and used according to applicable law, organizational policy and the principle of data minimization.

External data

External sources can enrich internal analysis. Examples include weather, traffic, port congestion, fuel prices, exchange rates, holidays, labour-market conditions, economic indicators, regulatory changes and publicly available supplier-risk information. External data may improve forecasting and risk assessment, but analysts must verify licensing, coverage, update frequency, geographic fit and methodological consistency.

3. From Operational Systems to Business Intelligence

A typical BI architecture separates operational processing from analytical processing. Transaction-processing systems are optimized for recording current events. Analytical systems are optimized for querying historical data across multiple sources.

A simplified flow is:

Figure: A simplified flow from operational data sources to BI-supported decisions and feedback.

An ETL process extracts data, transforms them and loads them into a target repository. In ELT, raw data are loaded first and transformations occur within the analytical platform. A data warehouse generally contains curated, structured data with defined schemas. A data lake can hold structured, semi-structured and unstructured data, though without governance it can become a poorly documented “data swamp.”

BI commonly includes standardized metrics, interactive dashboards, scheduled reports, alerts and self-service exploration. A semantic layer defines shared business meanings, such as the official definition of an order, fill rate or late shipment. Without common definitions, different departments may produce contradictory performance reports.

4. Preparing and Validating Operational Data

Data preparation is not merely cosmetic. It determines whether an analysis represents the underlying process.

A practical preparation sequence

1. Define the decision and unit of analysis. Specify the question, population, time window and record grain.
2. Inventory the sources. Document owners, update frequency, fields, identifiers, units, access rights and known limitations.
3. Profile the data. Inspect data types, ranges, unique values, duplicates, missingness and distributions.
4. Standardize representations. Align dates, time zones, currencies, units, product codes and categorical labels.
5. Integrate sources. Match entities using reliable keys or carefully governed cross-reference tables.
6. Validate business rules. Check logical relationships and reconcile totals with trusted reports.
7. Create an analysis-ready dataset. Preserve raw data separately and record every transformation.
8. Test and approve. Obtain subject-matter review before operational use.

Validation checks

Common checks include:

• Completeness: Are required fields populated? Are all expected dates, facilities and products represented?
• Validity: Do values conform to allowed formats and ranges? For example, quantity should not be negative unless returns are explicitly coded.
• Uniqueness: Is an order identifier unique where it should be? Duplicate records can inflate demand.
• Consistency: Do related fields agree? A delivery cannot occur before dispatch unless the timestamps use different time zones or definitions.
• Accuracy: Can values be compared with source documents, calibrated instruments or audited totals?
• Timeliness: Were records available at the time the decision would have been made?

A useful reconciliation is:

Here all terms must use the same product, location, unit and accounting period. The identity is a control check, not proof that every record is correct; equal totals can still conceal offsetting errors.

Units and time

Unit inconsistency is a frequent operational error. Cases, pieces, kilograms and pallets are not interchangeable without documented conversion factors. Similarly, UTC, local time and daylight-saving changes can alter lead-time calculations. A timestamp should ideally include its time zone and event definition.

For a shipment with dispatch time t_d and delivery time t_a, elapsed transit time is:

where T is elapsed time in the chosen time unit. This calculation assumes both timestamps refer to comparable events and a common time standard.

5. Missing Data, Error and Bias

Missing data occur for many reasons: a scanner failed, a supplier did not report, a field was optional, a transaction was cancelled, or a process changed. Missingness is not automatically random.

Three conventional mechanisms are useful:

• MCAR (missing completely at random): missingness is unrelated to observed and unobserved values.
• MAR (missing at random conditional on observed variables): missingness depends on observed information, such as facility or shift.
• MNAR (missing not at random): missingness depends on the unobserved value or an unmeasured cause, such as poor performers being less likely to report delays.

The labels describe assumptions, not facts that can be proven from a dataset alone. Analysts should investigate process causes and compare missingness across sites, products, suppliers and time periods.

Possible responses include correcting the collection process, retaining a missing category, using a justified imputation method, analyzing complete and incomplete cases separately, or reporting a sensitivity range. Replacing missing values with zero is appropriate only when zero is the documented meaning of non-occurrence. A missing delivery time is not the same as a zero-minute delivery.

Measurement error occurs when recorded values differ from the intended construct. Examples include planned rather than actual lead time, rounded quantities, inaccurate cycle counts and inconsistent definitions of “available inventory.” Selection bias arises when the observed records do not represent the population relevant to the decision. A carrier study using only peak-season routes cannot automatically generalize to the full year.

Survivorship bias occurs when failed, cancelled or discontinued cases disappear from the dataset. Confirmation bias occurs when analysts select measures or periods that support a preferred explanation. Data leakage occurs when information unavailable at the time of prediction is used to build a model. For example, using the final delivery status to predict whether a shipment will be delivered late invalidates the prediction.

A defensible analysis records assumptions, tests alternative definitions and communicates uncertainty rather than presenting a single number as unquestionable fact.

6. Descriptive Measures and Operational Metrics

Metrics should connect clearly to decisions. Common measures include:

• On-time delivery rate: the proportion of deliveries meeting a defined promise or appointment criterion.
• Fill rate: the proportion of demand supplied immediately, with the numerator and denominator explicitly defined.
• Order cycle time: elapsed time between specified order and fulfillment events.
• Inventory turnover: cost of goods sold divided by average inventory value over a stated period.
• Forecast error: the difference between actual and forecast demand.
• Capacity utilization: used capacity divided by available capacity, where the capacity definition is explicit.

For observations y_i and forecasts F_i, the mean absolute error (MAE) is:

Here n is the number of observations, y_i is actual demand and F_i is forecast demand. MAE has the same units as demand and treats positive and negative errors equally in magnitude. It is appropriate when absolute operational deviation is more interpretable than squared deviation. It should not be calculated across incomparable units without normalization.

A metric is not automatically a good key performance indicator (KPI). A warehouse may improve pick rate by rushing work and increasing errors. Local optimization can damage total supply-chain performance. Balanced measurement therefore combines service, cost, quality, speed, resilience and safety, with clear ownership and review frequency.

7. Visualization and Dashboard Design

Visualization reduces cognitive effort when it exposes patterns relevant to a decision. The choice should follow the analytical question:

Effective dashboards usually contain a small number of prioritized measures, visible definitions, current-versus-target comparisons, trend context, filters that do not create confusion, and clear escalation rules. A dashboard should answer “what requires attention?” rather than merely display everything available.

Visual integrity matters. Truncated axes can exaggerate differences; dual axes can imply false relationships; excessive colours obscure priorities; averages can conceal variation; and maps can overemphasize large geographic areas. Units, dates, denominators and refresh times should be visible. Users should be able to move from an aggregate KPI to the underlying records through governed drill-down.

A dashboard is a decision instrument, not a substitute for process understanding. A red indicator may identify a symptom, but investigation is needed before intervention.

8. Reproducible Analytical Workflows

A reproducible workflow allows another analyst to understand and, where permitted, recreate the result using the same data version, code, definitions and assumptions. Reproducibility improves quality assurance, auditability and organizational learning.

A robust workflow contains:

1. a written decision question and data dictionary;
2. version-controlled extraction or query logic;
3. an immutable raw-data layer;
4. scripted or documented transformations;
5. automated tests for schema, ranges, duplicates and reconciliations;
6. versioned analysis and visualization code;
7. controlled parameters, such as reporting dates and thresholds;
8. provenance records showing source, owner and refresh time;
9. peer review and sign-off; and
10. an archived output linked to the exact input and method versions.

The principle is often summarized as “data, code, environment and documentation.” A spreadsheet can be reproducible if formulas, inputs, definitions and change history are controlled; a sophisticated platform can be irreproducible if transformations are hidden.

Reproducibility differs from repeatability. Repeatability concerns obtaining consistent results under the same conditions. Reproducibility more broadly concerns recreating findings using documented materials, possibly by another analyst or system. Operational decisions also require traceability: the ability to follow a reported KPI back to source events and business rules.

9. Applied Case: Improving Distribution-Centre Service

The following is an illustrative case.

Background

A regional retailer operates three distribution centres and uses an internal dashboard showing a 96% on-time shipment rate. Store managers, however, report frequent late arrivals. Senior management asks an analytics team to investigate.

Problem definition

The team defines the unit of analysis as one store shipment and defines “on time” as arrival at the store no later than the confirmed appointment date. This differs from the existing dashboard, which uses the requested date and counts shipments created during the reporting period.

Analysis

The team inventories WMS, TMS and store-receiving data. It discovers that the WMS records dispatch, the TMS records carrier pickup and the store system records unloading. Product codes are standardized through a master-data table. Duplicate shipment IDs are removed after investigation. All times are converted to local facility time, while the original timestamps are retained.

Validation reveals that 8% of shipments lack a receiving timestamp. Missingness is concentrated among two stores whose scanning equipment was unreliable. Treating these shipments as on time would bias the rate upward; treating all as late would bias it downward. The team reports the observed rate separately and performs a sensitivity analysis under documented assumptions.

The revised dashboard separates three measures: dispatch punctuality, carrier transit performance and store receiving delay. A process view shows that dispatch performance is strong, but carrier dwell time at a cross-dock and receiving congestion at several stores explain most late arrivals. The original 96% figure had combined records from different grains and used a date definition that did not match the customer promise.

Approach and solution

Management changes the KPI definition, adds scan-completeness monitoring, introduces alerts for cross-dock dwell time and schedules receiving appointments based on store capacity. Carriers receive a common event dictionary and are required to report pickup and arrival events using standardized codes.

Outcome

The organization does not merely replace one percentage with another. It establishes a traceable measure, identifies where delay occurs and assigns corrective actions to the responsible process owners. Subsequent reviews compare service, cost and scan completeness so that improvement in one measure does not conceal deterioration in another.

Learning points

1. KPI disputes often result from definitions rather than arithmetic.
2. Data integration requires attention to grain, keys, time and event meaning.
3. Missing data can be operationally patterned and therefore bias conclusions.
4. A dashboard is effective when it supports ownership and action.
5. Reproducible logic protects the organization when definitions or systems change.

10. Governance, Ethics and Contemporary Developments

Operational analytics involves responsibilities beyond technical accuracy. Organizations should apply access controls, least-privilege permissions, encryption where appropriate, retention limits and audit logs. Personally identifiable information should not be copied into analytical datasets without a legitimate purpose and appropriate safeguards. Data-sharing agreements should define permitted use, security requirements, ownership and deletion procedures.

Fairness is relevant when analytics affects workers, suppliers or customers. A productivity dashboard may penalize employees assigned difficult tasks; a supplier-risk score may reproduce historical purchasing bias; a delivery model may disadvantage regions with sparse data. Analysts should examine subgroup performance, explain important decisions and provide escalation or correction mechanisms.

AI and machine learning can support demand forecasting, anomaly detection, estimated arrival times and document extraction. They do not remove the need for sound data governance. Models can drift when routes, suppliers, policies or customer behaviour change. Human review is especially important when recommendations affect safety, employment, access to service or contractual decisions. Generative AI may assist with query drafting or documentation, but generated code and interpretations require testing against controlled data.

Contemporary data platforms increasingly support streaming event data, digital twins, process mining and real-time control towers. These technologies can improve responsiveness, but more data and faster refresh do not guarantee better decisions. The organization must still define the decision, establish reliable event semantics and ensure that action can occur quickly enough to benefit from the information.

Best-Practice Checklist

Before publishing an operational analysis, ask:

• Is the decision, population, period and grain explicit?
• Are metric definitions and denominators documented?
• Are source owners, refresh times and access permissions known?
• Have units, time zones, duplicates, missingness and outliers been checked?
• Have totals been reconciled with an authoritative source?
• Could selection, survivorship, measurement or confirmation bias affect the result?
• Does the visualization show context, uncertainty and relevant comparisons?
• Can another analyst trace the result through data, code and assumptions?
• Are privacy, security, fairness and regulatory requirements satisfied?
• Is there a named owner responsible for acting on the insight?

Chapter Summary

Operations and supply chain analytics depends on data from internal systems, suppliers, logistics providers, customers and external environments. These sources differ in purpose, granularity, timeliness, ownership and reliability. Business intelligence integrates governed data into reports, dashboards and decision processes, while analytics adds explanation, prediction and recommendation.

Sound analysis begins with a clearly defined decision and unit of analysis. Data must be profiled, standardized, integrated and validated through checks for completeness, validity, uniqueness, consistency, accuracy and timeliness. Missingness, measurement error, selection bias, survivorship bias and data leakage can materially distort conclusions. Metrics require explicit definitions and should balance service, cost, quality, capacity, resilience and safety.

Visualizations and dashboards should direct attention toward decisions rather than display data indiscriminately. Reproducible workflows preserve raw data, documented transformations, versioned code, tests, provenance and review. Finally, privacy, fairness, security, explainability and human accountability are essential parts of professional operational analytics.

Key Terms

Analytics: Systematic use of data, methods and reasoning to support decisions.

Business intelligence: Technologies and practices for organizing, analyzing and communicating business information.

Data grain: The level of detail represented by one record.

Master data: Relatively stable definitions of entities such as products, suppliers and locations.

Event data: Records of activities occurring at particular times.

ETL: Extract, transform and load; a process for moving and preparing data.

Data warehouse: A governed repository of structured, integrated historical data.

Data lake: A repository capable of storing diverse raw and processed data.

Semantic layer: Shared definitions and logic for business measures.

Data profiling: Examination of structure, completeness, values and distributions.

Data validation: Testing whether data satisfy technical and business requirements.

Missing data: Required or expected values that are absent.

Measurement error: Difference between a recorded value and the intended quantity.

Selection bias: Systematic difference between observed records and the relevant population.

Data leakage: Use of information unavailable at decision time in analysis or prediction.

Key performance indicator: A defined measure used to monitor important performance.

Dashboard: An interactive or scheduled display of selected measures and context.

Reproducibility: Ability to recreate an analytical result from documented materials.

Data provenance: Record of a data element’s origin, transformations and ownership.

Data governance: Policies, roles and controls that manage data quality, access, use and accountability.

Review Questions

Short Answer Questions

1. Distinguish event data from master data and give one example of each.
2. Why can joining datasets with different grains produce incorrect results?
3. What is the difference between ETL and ELT?
4. Name four dimensions of operational data quality.
5. Why should a dashboard display metric definitions and refresh times?

Long Answer Questions

1. Explain the main internal, supplier, logistics, customer and external data sources used in supply chain analytics.
2. Describe a complete workflow for preparing and validating an operational dataset.
3. Explain MCAR, MAR and MNAR missingness and discuss appropriate managerial responses.
4. Discuss how visualization and dashboard design can improve or impair operational decisions.
5. Explain the components of a reproducible analytical workflow and their value to governance.

Analytical / Application Questions

1. A warehouse reports rising productivity after introducing a new scanning system, but error rates and customer complaints also rise. Design an analysis that tests whether the productivity improvement is genuine.
2. A carrier’s reported on-time rate is 94%, but the organization’s customer-service rate is 87%. Identify possible definition, grain, timestamp and missing-data explanations, and propose reconciliation tests.
3. Design a dashboard for monitoring distribution-centre service. Specify five measures, their definitions, suitable visualizations, refresh frequency and safeguards against misleading interpretation.

Multiple Choice Questions with Answers

Question 1

Which source is most directly associated with put-away, picking and packing events?

A. Warehouse management system

B. Customer relationship management system

C. External economic database

D. Supplier quotation file

Correct Answer: A. Warehouse management system

Question 2

What is the principal risk of joining daily inventory data to order-line data without addressing grain?

A. The data will automatically become more current

B. Inventory values may be duplicated across order lines

C. All missing values will be removed

D. Time zones will be standardized

Correct Answer: B. Inventory values may be duplicated across order lines

Question 3

Which condition is an example of data leakage?

A. Using shipment weight recorded at dispatch

B. Using a final delivery status to predict whether delivery will be late

C. Using historical traffic data available before dispatch

D. Using a supplier identifier in a risk model

Correct Answer: B. Using a final delivery status to predict whether delivery will be late

Question 4

Which measure has the same units as the forecasted quantity?

A. Mean absolute error

B. Correlation coefficient

C. Percentage of missing values

D. Number of dashboard filters

Correct Answer: A. Mean absolute error

Question 5

A missing delivery timestamp is coded as zero minutes of transit. What is the main problem?

A. Zero is always a valid substitute for missingness

B. The code may falsely represent an observed event

C. The dataset will contain too many time zones

D. The shipment identifier will become unique

Correct Answer: B. The code may falsely represent an observed event

Question 6

Which visualization is generally most suitable for showing performance over time?

A. Line chart

B. Pie chart with dozens of categories

C. Unsorted word list

D. Single-number card without a time reference

Correct Answer: A. Line chart

Question 7

What is the purpose of a semantic layer in BI?

A. To delete all raw operational data

B. To define shared business meanings and metric logic

C. To prevent users from viewing historical data

D. To replace data validation with visualization

Correct Answer: B. To define shared business meanings and metric logic

Question 8

Which practice most directly supports reproducibility?

A. Changing formulas manually without recording changes

B. Keeping only the final dashboard image

C. Versioning transformation logic and documenting data inputs

D. Removing all raw data after publication

Correct Answer: C. Versioning transformation logic and documenting data inputs

Question 9

A supplier reports delivery on time when it meets the confirmed date, while the buyer uses the requested date. This primarily illustrates a difference in:

A. Metric definition

B. Encryption method

C. Database storage capacity

D. Visualization colour

Correct Answer: A. Metric definition

Question 10

Which is an appropriate governance control for customer data?

A. Copying all personal data into every analytical file

B. Using least-privilege access and collecting only necessary data

C. Allowing unrestricted dashboard downloads

D. Ignoring retention requirements

Correct Answer: B. Using least-privilege access and collecting only necessary data