What Is AI Cross-Supply Chain Integration? A Design Approach to Breaking Down Silos and Achieving ROI

AI supply chain cross-functional integration is an architecture that centrally connects multiple AI systems spanning manufacturing, procurement, and logistics at both the data and process levels.

In a siloed approach where each department independently deploys its own AI, data fragmentation tends to reduce the accuracy of demand forecasting AI and delay decision-making, making it difficult to achieve AI ROI (return on AI investment). Cross-functional integration requires a design that handles data across departments in a unified manner while interfacing with ERP (Enterprise Resource Planning) and MLOps platforms.

This article provides a systematic explanation covering specific methods for eliminating data silos, the overall design of a cross-functional integration architecture, AI integration points for manufacturing, procurement, and logistics respectively, a phased implementation approach, and ROI measurement and maximization.

Conclusion: AI supply chain cross-functional integration is a design philosophy that centrally connects the AI systems of manufacturing, procurement, and logistics at both the data and process levels.

We will examine in turn how this differs from siloed individual AI deployments, which operational challenges it addresses, and how it relates to ERP (Enterprise Resource Planning) and MLOps.

It is tempting to assume that "deploying AI individually in each department will bring us closer to overall optimization," but in practice, siloed deployments tend to yield diminishing returns on investment. AI systems confined within individual departments make decisions without access to data from adjacent processes, making them prone to local optimization rather than global optimization.

The difference between a siloed approach and cross-functional integration is reflected in how data flows.

• Siloed approach: Manufacturing, procurement, and logistics each maintain their own data stores and models, with integration dependent on manual batch transfers.
• Cross-functional integration: Data from all processes flows through a common semantic layer, allowing each AI to perform inference within the same shared context.

This structural difference directly impacts the speed and accuracy of decision-making. For example, if a demand forecasting AI can reference procurement lead time data and logistics inventory levels in real time, the accuracy of order timing improves significantly. In a siloed approach, by contrast, the output of demand forecasting is forwarded by email to the procurement team and re-entered manually, causing the freshness and accuracy of information to degrade.

The essence of cross-functional integration lies not in "the number of AI systems" but in "the degree of coupling between data and processes." Connecting the layers of manufacturing, procurement, and logistics through a single data pipeline—while integrating with ERP (Enterprise Resource Planning) and MLOps platforms—is a prerequisite for achieving ROI.

Cross-functional integration delivers its true value in environments where chronic coordination failures between departments have become the norm. The following three operational challenges are difficult to resolve fundamentally with siloed AI deployments and can only be addressed through cross-functional integration.

① Degraded demand forecasting accuracy

When sales, inventory, and procurement data are dispersed across separate systems, demand forecasting AI receives only incomplete inputs. Cross-functional integration enables unified, real-time access to sales actuals, inventory levels, and supplier lead times, which is expected to improve forecast accuracy. Response speed to seasonal fluctuations and sudden demand spikes also tends to improve.

② Delayed anomaly detection and rising response costs

Even when an anomaly on a manufacturing line is detected, a time lag in communicating that information to the procurement and logistics departments causes the costs of emergency parts procurement and transportation arrangements to escalate. With cross-functional integration, signals detected by predictive maintenance AI on the manufacturing side can be immediately received by AI agents in procurement and logistics, automatically triggering alternative parts orders and route changes.

③ Personalization of decision-making and black-box opacity

When AI tools proliferate independently across departments, it becomes impossible to trace which AI made a decision and on what basis. By centrally managing data lineage, the rationale behind decisions can be made visible across departments, facilitating audit responses and compliance verification.

Note that the priority of these challenges varies by situation. If inventory loss and stockouts are the central management concern, it is practical to start with ①; if quality complaints and manufacturing downtime risk are significant, prioritizing ② is the more realistic course of action.

"Which should be established first—ERP or MLOps?" is a question that frequently arises on the ground during the launch phase of AI integration projects. To state the conclusion upfront: since the two serve different roles, the design question is not "which one" but "how to combine them."

ERP (Enterprise Resource Planning) is a core system that centrally manages transaction data such as orders, inventory, and accounting. MLOps, on the other hand, is an operational platform that automates model training, deployment, and monitoring, specializing in AI model lifecycle management.

The role of each within a cross-functional integration architecture can be summarized as follows:

• ERP: Functions as the Single Source of Truth for master data (items, business partners, inventory).
• MLOps: Handles the pipeline that trains models using data extracted and transformed from ERP, and feeds inference results back into ERP business processes.
• Cross-functional integration layer: Positioned between the two, it guarantees data quality and freshness through mechanisms such as a medallion architecture and a feature store.

A practical consideration is that the update frequency of ERP data and the inference cycle of AI models tend to fall out of sync. For example, if the inventory master is updated via daily batch processing, a real-time demand forecasting AI risks referencing stale data. To bridge this gap, an effective design approach is to introduce event-driven data integration between the ERP and the MLOps pipeline.

Conclusion: Data silos block the cross-functional data required for AI model training and inference, locking organizations into a state where only partial optimization is possible.

In a structure where manufacturing, procurement, and logistics departments each operate their own systems, data formats and update frequencies are inconsistent, preventing AI from making decisions that optimize the whole. The H3 sections below explore the specific mechanisms and impacts of this problem.

As each department accumulates operations within its own system, serious discrepancies emerge in data format and freshness.

In the manufacturing department, equipment sensors output logs every second, while aggregation is performed in daily batches. In the procurement department, purchase order data is managed in Excel or CSV files, with updates to the ERP (Enterprise Resource Planning) system occurring on a weekly basis. In the logistics department, transportation status arrives via EDI in proprietary formats, with timestamp reference times varying by location. The reality is that these incompatibilities coexist without issue across the same supply chain.

It is tempting to think that "connecting each department's data via APIs will solve the problem," but in practice, failing to first standardize format conversion and data freshness will contaminate the input data fed to AI models and significantly degrade their accuracy. Moreover, it is important to note that discrepancies in data freshness tend to be more serious than inconsistencies in format. When outdated inventory data and the latest demand signals are mixed together, the AI's inference results can themselves become an obstacle to decision-making.

The following three approaches are effective in addressing this problem.

Demand forecasting AI is the area most susceptible to the effects of data silos, as accuracy is directly tied to the quality of training data.

When sales performance data is siloed within the sales system, inventory data within the warehouse management system, and production planning data within the ERP (Enterprise Resource Planning) system, the demand forecasting AI can only reference fragmented information. Models trained on incomplete context tend to show significantly reduced accuracy in responding to sudden demand shifts and seasonal fluctuations.

The main impacts of silos on accuracy are the following three points:

• Insufficient features: When procurement lead times and logistics delay information are not included in the training data, the model tends to underestimate the risk of stockouts.
• Data freshness discrepancies: When update frequencies differ by department, outdated inventory data and the latest order data become mixed together, causing the reference point for forecasts to drift.
• Label inconsistencies: Using figures with different definitions across departments—such as "shipped quantity," "ordered quantity," and "allocated quantity"—without consolidation causes the model to learn incorrect demand signals.

This is where the decision criteria diverge. For items with relatively stable demand fluctuations, a certain level of accuracy can be maintained with data from a single department. However, for items affected by seasonality, promotions, or external procurement factors, the risk of increased forecast error grows significantly unless data from multiple departments is cross-functionally integrated.

Eliminating data silos and integrating features can be considered the highest-priority prerequisite for improving the accuracy of demand forecasting AI.

"Who has authority over this data?"—If no one on the supply chain floor can answer this question immediately, it is a sign that data governance is not functioning.

When cross-functional AI integration is pursued without established data governance, the following risks tend to materialize:

• Absence of data ownership: Because inventory data is independently managed and updated by each of the procurement, manufacturing, and logistics departments, it becomes unclear which data is the "authoritative" source.
• Broken data lineage: It becomes impossible to trace which data an AI model used to generate a forecast, making it impossible to explain the basis for prediction results.
• Compliance risks: The EU AI Act (Regulation (EU) 2024/1689) requires high-risk AI systems to ensure data quality management and traceability. The absence of governance makes it difficult to comply with such regulatory requirements.

This becomes particularly problematic during AI model retraining. When the origin and transformation history of data are not recorded, identifying the cause of model accuracy degradation requires enormous effort. There are also reported cases where errors in data received from suppliers go undetected, leading to incorrect ordering decisions.

An effective countermeasure is to establish data catalog and data lineage mechanisms in advance. The "shift-left" approach—building a governance foundation before AI deployment—significantly reduces rework in downstream processes.

When attempting to map the systems of manufacturing, procurement, and logistics onto a single architecture diagram, the first challenge encountered is the question: "Where do we collect data, where do we make decisions, and where do we take action?" If these three concerns are left intermingled as design proceeds, accountability boundaries become ambiguous later on, and isolating the cause of failures becomes difficult.

This is precisely why the starting point is to organize responsibilities into three distinct layers: the data layer, the AI processing layer, and the agent layer. In the sections that follow, we will examine the specific approach to design from three perspectives: data layer design principles, multi-agent coordination models, and the division of processing between edge and cloud.

The first common pitfall in supply chain data integration is the assumption that "if we just gather all the data in one place, we can use AI." In practice, however, when data of varying quality is fed into AI models without being sorted out, there are reported cases where prediction accuracy actually decreases rather than improves. The Medallion Architecture addresses this problem structurally through a layered design.

The Medallion Architecture manages data across three tiers: Bronze, Silver, and Gold.

• Bronze layer: The "landing zone" where raw data from each department is ingested as-is — including sensor logs from manufacturing lines, purchase order data from procurement systems, and shipping records from logistics WMS
• Silver layer: Cleansed data that has undergone deduplication, missing value imputation, and format standardization. Cross-departmental join keys are standardized at this layer.
• Gold layer: Aggregated and processed datasets organized by use case, directly referenced by AI models and BI dashboards

In the supply chain context, "standardizing cross-departmental join keys" at the Silver layer is particularly critical. It is common for manufacturing part codes and procurement part numbers to be managed under different numbering systems, and building a Gold layer without aligning these will prevent the Demand Forecasting AI from functioning correctly.

A Multi-Agent System (hereafter MAS) is an architecture in which AI agents specialized for each process — manufacturing, procurement, and logistics — are deployed and made to collaborate autonomously via an agent-to-agent communication protocol (A2A). Each agent makes independent decisions within its own domain, while a higher-level agent orchestrator manages overall consistency.

Autonomous inter-process coordination is especially effective in the following scenarios:

• Procurement → Manufacturing coordination: When the demand forecasting AI detects a stock shortage, the procurement agent automatically generates order candidates, and the manufacturing agent readjusts the production schedule.
• Manufacturing → Logistics coordination: When the predictive maintenance agent detects a risk of equipment downtime, the logistics agent immediately recalculates shipping lead times and automatically generates customer notifications.
• Cross-process: When the anomaly detection agent identifies signs of a supply chain attack, it propagates alerts to agents across all processes and incorporates human approval via a HITL (Human-in-the-Loop) flow.

As a guiding principle for agent design, when inter-process dependencies are loosely coupled, agents are generally run in parallel to prioritize processing speed; when there are strong sequential dependencies, a task graph is used to explicitly define a serial execution order.

One important consideration when implementing MAS is that establishing a semantic layer to unify message formats between agents is essential. Without consistent formats, there is a risk of cascading failures similar to hallucinations, where agents make decisions based on incorrect assumptions.

The question of "where should AI be placed — at the edge or in the cloud?" almost invariably arises during the design phase of cross-functional integration.

The principle governing the division of roles is determined by the trade-off between latency and context volume.

Processing that should be handled by Edge AI

• Anomaly detection and predictive maintenance on manufacturing lines: Decisions are required on the order of milliseconds, making a round trip to the cloud impractical.
• Cargo appearance and damage inspection at logistics hubs: When performing real-time inference on camera footage, edge processing is also preferable from a bandwidth cost perspective.
• Continued operation during network outages: Communication can become unstable in factories and warehouses, and Edge AI completes inference locally.

Processing that should be handled by the cloud

• Supply-and-demand optimization across the entire supply chain by the demand forecasting AI: This requires large-scale computing resources, as it spans data from multiple sites and multiple time periods.
• Continuous model retraining and version management via MLOps
• Inter-process decision-making coordination through agent orchestration

The key to integration: aggregating data from edge to cloud

Logs and inference results generated at the edge are aggregated into the Bronze layer of the Medallion Architecture, then promoted to the Silver and Gold layers on the cloud side. This approach enables both the high-speed capabilities of the edge and the contextual processing power of the cloud.

As a design consideration, edge device models are assumed to be lightweight by default, leveraging techniques such as quantization and the use of SLMs.

The three domains of manufacturing, procurement, and logistics each have different critical points for "where AI should be connected." Optimizing only one area cuts the impact in half if an adjacent domain becomes a bottleneck. Before designing cross-functional integration, it is necessary to understand the connection points specific to each domain.

In the manufacturing domain, predictive maintenance in smart factories tends to serve as the starting point. A mechanism that collects equipment operating data in real time and detects early signs of anomalies has value on its own, but by feeding that information to the procurement side, it becomes possible to place advance orders for parts and adjust inventory. This chain reaction cannot emerge as long as manufacturing AI remains siloed.

In the procurement domain, the integration of demand forecasting AI with dynamic pricing is central. What determines the depth of integration is not just the ability to forecast demand fluctuations, but whether those results can be automatically reflected in supplier price negotiations and order timing.

In the logistics domain, the use of AI digital twins is key to the design. The process of repeatedly running simulations on virtual models of warehouses and transportation networks and translating the results into actual operations only gains accuracy when it receives variable data from manufacturing and procurement. Whether each domain's AI is designed with the other domains' data as a prerequisite makes a significant difference in its effectiveness.

When considering AI adoption in the context of a Smart Factory, the initial tendency is to think that "attaching the optimal AI sensor to each piece of equipment is sufficient." In practice, however, as long as data from each piece of equipment remains siloed, predictive maintenance accuracy will plateau and will not translate into optimization of the entire supply chain. Cross-functional integration is the key to raising AI ROI (AI return on investment) in the manufacturing domain.

The main points for cross-functionally integrating smart factories and predictive maintenance are the following three.

• Linking sensor data with production planning: By connecting edge data such as equipment vibration, temperature, and current values to the production schedule in the ERP (Enterprise Resource Planning) system, AI becomes capable of autonomously proposing "when and which equipment to take offline for maintenance."
• Linking predictive maintenance with procurement: By automatically feeding predicted part replacement timing to the procurement system, excess spare parts inventory and emergency orders can be reduced. This linkage only functions once the silo between manufacturing and procurement is eliminated.
• Quality data feedback loop: By feeding defective product data from the manufacturing line back to the Demand Forecasting AI in real time, the accuracy of forecasts for shippable quantities improves.

In procurement departments, demand forecasting AI and dynamic pricing are often operated independently. However, by linking the two in real time, it is possible to simultaneously optimize order timing and purchase prices.

How the Integration Works

• The demand forecasting AI integrates sales data, seasonal indices, and external economic indicators to calculate future demand for each item
• Calculation results are immediately fed back to the dynamic pricing engine, which automatically updates order quantities and negotiation conditions for supplier pricing
• An approval flow via HITL (Human-in-the-Loop) is triggered only when price fluctuations exceed a defined threshold

Decision Criteria for Conditional Branching

When demand fluctuations are minor (i.e., forecast error falls within the acceptable range), the engine autonomously updates order conditions. When demand changes abruptly and forecast error exceeds the threshold, the design that proves effective in practice is one that escalates to the procurement officer and delegates the final decision to them.

Benefits of Cross-Functional Integration

• Reduced risk of excess inventory and stockouts
• Ability to support supplier price negotiations with demand-based data
• Shorter procurement lead times (through automation of order decisions)

As a prerequisite for integration, it is essential that the purchasing module of the ERP (Enterprise Resource Planning) system and the demand forecasting AI reference the same data pipeline. If data remains siloed, a time lag arises between forecast results and order processing, which tends to halve the effectiveness of dynamic pricing. By leveraging a feature store to centrally manage feature variables, data freshness can be synchronized between both systems.

"We have inventory — so why can't we predict delivery times?" Many professionals on the logistics floor have faced this question. The factors that influence lead times — transportation routes, warehouse operational capacity, customs clearance delays, and more — span multiple departments, making it structurally difficult to see the full picture through monitoring individual systems alone.

AI digital twins address this challenge by reproducing the entire logistics network in a virtual space and continuously running simulations in combination with real-time data. Specifically, the following elements are integrated:

• Integration of transportation data: Vehicle location, temperature, and load status obtained from GPS and IoT sensors are ingested in real time
• Visualization of warehouse capacity: Inbound/outbound scan data is combined with staff shift information to predict processing bottlenecks
• Incorporation of external variables: Weather information, port congestion indices, and customs clearance status are connected to the data pipeline to score delay risks

Simulation results are also linked with the Demand Forecasting AI, enabling advance detection of future conflicts such as "transportation capacity will be insufficient during a week when a demand surge is forecast." This is expected to not only shorten lead times but also suppress excessive safety stock accumulation.

However, the accuracy of a digital twin is directly tied to the freshness and comprehensiveness of its data.

Attempting to roll out cross-functional integration across all processes at once often leads to failure due to a combination of operational disruption and cost overruns. The realistic approach is to proceed through three stages in order: data infrastructure development, knowledge integration, and autonomization.

In the first stage, the goal is to build a foundation from which data scattered across departments can be accessed in a unified manner. Attempting higher-level integration while skipping this step will not yield accuracy, as input data quality remains inconsistent. In the second stage, knowledge integration, individual models such as demand forecasting and inventory optimization are connected, and the decision-making logic across departments is aligned. Only in the third stage can the autonomization of decision-making — including exception handling — be pursued.

At the end of each phase, a PoC (Proof of Concept) is conducted to verify effectiveness and determine whether to proceed to the next phase. By establishing these verification gates, investment returns can be accumulated incrementally while keeping risk under control.

The first stumbling block when introducing cross-functional integration is rushing to "build an AI model first." In practice, prioritizing the development of a data catalog and an AI readiness assessment significantly reduces rework in later stages.

What to Do When Building a Data Catalog

• Inventory the data assets held by systems across manufacturing, procurement, and logistics (ERP (Enterprise Resource Planning), WMS, MES, etc.)
• Record data owners, update frequency, formats (CSV, JSON, EDI, etc.), and freshness as metadata
• Visualize data lineage (the flow from data origin through processing to use) to identify at which stage data is being altered

Through the cataloging process, many cases have been reported where issues surface such as "data we thought was usable turned out to have a high missing-value rate" or "the same item codes were being managed under different classification systems across departments."

Perspectives for AI Readiness Assessment

Once the data catalog is in place, evaluate each data asset across the following four dimensions:

• Completeness: Are there any missing values in required fields?
• Consistency: Is the same definition used consistently across departments?
• Freshness: Does the data meet the real-time requirements of the AI model?
• Accessibility: Can the data be automatically retrieved via API or data pipeline?

Assets with low evaluation scores should be prioritized for remediation before proceeding to RAG (Retrieval-Augmented Generation) and vector database integration in Phase 2 and beyond.

Once the data catalog and AI readiness assessment from Phase 1 are in place, the next stage involves integrating scattered operational knowledge into a searchable form. The combination of RAG (Retrieval-Augmented Generation) and a vector database plays a central role here.

RAG is a technique that combines external knowledge retrieval results with LLM response generation. In the supply chain domain, its effectiveness has been reported in the following use cases:

• Procurement: Search past order histories and supplier evaluation reports to instantly suggest alternative sourcing options
• Manufacturing: Vectorize equipment manuals and defect records to automatically generate explanations supporting predictive maintenance
• Logistics: Index shipping contracts and customs regulations to support decision-making in handling irregular situations

The choice of vector database depends on data scale and update frequency. For inventory and transportation data requiring real-time performance, a low-latency in-memory type is appropriate; for regulations and specification documents with low update frequency, a cost-efficient disk-persistent type is more suitable.

The following three points are important implementation considerations:

1. Chunk size design: Over-segmenting documents causes loss of context, while segments that are too large increase noise. Use approximately 500–800 tokens as a baseline and adjust per domain
2. Adoption of hybrid search: Combining semantic search (vector similarity) with BM25 (keyword matching) tends to improve accuracy for business documents containing specialized terminology

When the data infrastructure and knowledge integration established in Phase 2 are in place, the question "how far can we automate next?" will inevitably arise from the field. In Phase 3, we introduce agent orchestration that coordinates multiple AI agents, autonomously chaining decision-making across manufacturing, procurement, and logistics processes.

The core of agent orchestration is the definition of dependencies through task graphs. Each process handled by an agent (demand forecasting, order approval, delivery route optimization) is defined as a node, with the structure explicitly showing how upstream outputs trigger downstream processes. This allows the accumulation of individual decisions to function as decision-making across the entire supply chain.

There are three key points to keep in mind during implementation:

• HITL (Human-in-the-Loop) design: Insert human approval steps for decisions that exceed monetary or inventory thresholds, preventing errors caused by excessive agent authority
• A2A (Agent-to-Agent Protocol) standardization: Unify message formats between agents to ensure scalability that allows modules from different vendors to interoperate
• AI Observability integration: Collect and visualize decision logs from each agent, establishing a framework for early detection of hallucinations and abnormal reasoning paths

Incremental expansion is also important. Starting with the automation of a single process (e.g., automatic ordering for inventory replenishment) and gradually increasing the number of coordinating agents as results are validated is a realistic path to accumulating ROI while keeping risk in check.

Conclusion: The ROI of cross-functional integration can be maximized through the dual approach of designing quantitative metrics and driving continuous improvement via AI Observability.

To make the return on investment visible, it is essential to design measurement metrics and establish a continuous improvement cycle. The following H3 sections explain, in order, the quantitative metrics for measuring impact and how to leverage AI Observability.

When measuring the ROI of cross-functional integration, there is a tendency to focus solely on "cost reduction," but in practice, combining operational metrics such as lead time reduction rate and inventory turnover rate provides a more accurate picture of the overall investment impact.

The quantitative benefits generated by cross-functional integration can be broadly organized into the following three categories:

① Inventory and Procurement Cost Metrics

• Reduction rate in safety stock levels (linked to improvements in demand forecasting AI accuracy)
• Reduction rate in emergency procurement orders
• Number of days reduced in procurement lead time

② Manufacturing and Quality Metrics

• Reduction rate in unplanned downtime due to predictive maintenance
• Changes in defect rate and rework man-hours
• Improvement in Overall Equipment Effectiveness (OEE) after smart factory implementation

③ Logistics and Customer Service Metrics

• Changes in on-time delivery rate (On-Time In-Full: OTIF)
• Transportation cost reduction rate through route optimization using AI digital twins
• Trends in the number of customer complaints

Rather than aggregating these metrics individually by department, it is important to visualize them as unified metrics via a semantic layer. Without integrated data across departments, it is impossible to determine whether improvements on the manufacturing side are having an impact on procurement costs.

For the measurement cycle, a two-stage approach is recommended: confirming metric trends in monthly reviews, while revisiting the cross-functional integration design itself on a quarterly basis.

ROI measurement should not be treated as a one-time evaluation; it is important to design it as a continuous improvement cycle incorporating AI Observability.

AI Observability refers to a mechanism that visualizes model inference logs, input/output data, latency, and accuracy metrics in real time, enabling early detection of degradation and anomalies. In a cross-functional integration environment where multiple agents operate in coordination, an observability infrastructure capable of identifying which process experienced drift becomes indispensable.

The basic steps of the improvement cycle are as follows:

• Observe: Aggregate the demand forecasting AI's prediction error rate, inventory discrepancies, and delivery delay rate into a dashboard on a daily basis
• Diagnose: Trace the Data Lineage to determine whether the cause of accuracy degradation lies in data quality or in feature drift within the model
• Intervene: Address minor drift by updating the Feature Store, and implement fine-tuning or retraining for significant degradation
• Evaluate: Quantitatively record KPI changes following the intervention and update the baseline values for the next cycle

As a decision-making framework, clearly defining the division of responsibilities—where anomalies originating upstream in the data pipeline are addressed first on the Data Governance side, and where issues with the model's own generalization performance prompt the MLOps team to initiate a retraining process—will improve response speed.