Cross-Company Data Sharing Using Distributed Analytics

Abstract

Decision making in modern supply chain management relies heavily on data-driven decision support. Companies show a growing interest in building insights not only on data from within the company’s own boundaries, but also from collaborators and other actors in the market. While the topic of data and information sharing has been the focus of previous works, there has been a lack of studies focusing on practical implementations in the supply chain domain. Our aim is to conduct a technical feasibility study of data sharing in supply chain management. We analyze the requirements for cross-company data sharing in supply chains, and discuss existing technologies that enable such collaboration. We apply a distributed analytics framework that has already been implemented in the healthcare domain to a simulated use case of key performance indicator (KPI) exchange between supply chain actors. We find that the application is able to compute and exchange KPIs from the simulated companies’ datasets without requiring centralization of the databases. Furthermore, we find that the framework supports integration of data quality assessment and privacy preservation mechanisms. The application thus yields promising results with regard to technical feasibility. Factors that may facilitate scalability are discussed as directions for future research.

1. Introduction

Data-driven decision making is highly relevant in modern supply chain management, particularly for addressing challenges such as disruptions as seen during the COVID-19 pandemic [1,2]. As the need for robust and sustainable decisions grows, companies’ interests emerge to build insights based not only on internal data, but also on data from external sources [3]. This development emphasizes the growing role of data sharing, the process of making data available to third parties, which can include companies, individuals, or public institutions [4].

Data sharing in the sense of cross-organizational collaboration has the potential to benefit organizations, as multiple parties can use the same data resource for various applications. McKinsey [5] highlighted the importance of collaboration and coordination throughout the supply chain as crucial strategies to address current and future challenges. The benefits of such data sharing in supply chain management are substantial [3,6,7]: it enables superior knowledge throughout the network, leading to faster and better-informed decision making. Companies may achieve reduced latencies and time-to-market while improving product quality. Beyond operational improvements, data sharing may foster novel types of collaborations within supply chains and enable new value-added services.

However, despite these recognized benefits, the implementation of data sharing systems remains challenging. Many organizations maintain data silos due to [8]:

• Lack of mutual trust, understanding, and interaction;
• Fear of losing control over sensitive data;
• IT infrastructure limitations for external data exchange.

To address these challenges, implementing cross-company data sharing requires several key components [9]. First, legal frameworks need to be analyzed and governance structures developed to regulate data access and usage. Second, technologies need to ensure efficient and secure data transfer while maintaining data quality and transparency. Third, infrastructure and platforms must be established that facilitate data exchange.

While data sharing frameworks exist in various domains, supply chains present unique challenges that require specific solutions. These become evident when comparing different types of confidentiality across domains. For example, in healthcare, data sharing primarily concerns personal privacy rights of patients, whereas supply chain data involves business-sensitive information that directly affects competitive advantages and market positions [10,11]. While patient data privacy mandates the strict anonymization of individual patients, corporate privacy standards for sharing business-sensitive information are more flexible, varying according to the sensitivity of the specific information. Thus, a granular, controllable design of the data sharing privacy mechanisms for contextual adaptability is required. Different domains also operate under distinct incentive structures. In academic research, for instance, data sharing is driven by citation metrics and scientific recognition. In contrast, businesses require clear operational or financial benefits to justify sharing their proprietary information [11]. These fundamental differences create a more complex environment for establishing trust and governance mechanisms in supply chains, as the shared data directly impact business relationships and market dynamics.

To structure these complex data sharing environments, the concept of data ecosystems has evolved [12,13]. These frameworks help model and analyze data sharing scenarios by defining key entities and their interactions. Data ecosystems specify different types of actors (such as organizations or individuals), their roles in the ecosystem, the resources they handle (such as datasets or services), and their attributes. In addition, they define the relationships between these components, helping to understand data flows, access rights, and dependencies within the system.

Building on these concepts, initiatives such as the International Data Spaces (IDS) and Gaia-X provide comprehensive frameworks for data sharing [14,15]. They combine governance models with technical solutions— for instance, IDS defines both specific roles (data providers, consumers, brokers, and clearing houses) and technical components like the IDS connector for standardized data exchange [14]. These frameworks offer solid foundations for secure and standardized data sharing. However, while their application in specific domains is being explored1, there remains a gap between these general frameworks and practical implementations. The supply chain sector in particular requires detailed exploration of realistic application scenarios and the technical feasibility of data sharing in those use cases.

To bridge the gap between theoretical framework and implementation, our approach focuses on creating a concrete supply chain data sharing scenario while building on foundations of existing frameworks. Our implementation builds on distributed analytics, a method we selected for its focus on generating insights from distributed data sources, allowing us to start with practical use case development while progressively evaluating broader requirements for collaborative data analysis in the supply chain domain. One framework developed for the healthcare domain is the Platform for Analytics and Distributed Machine Learning for Enterprises (PADME)2, which builds on the Personal Health Train (PHT)3 concept [16,17]. PADME has found adoption in the healthcare domain, where it has already been applied to successfully demonstrate the derivation of insights from multiple data sources without centralizing the underlying data.

Our goal is to assess whether it is technically feasible for PADME to be applied to data sharing use cases in supply chains, to explore the applicability and adaptation needs of the approach to the specific requirements of the supply chain domain, and to derive insights on and develop functions for facilitating data sharing in supply chains in general. Our method combines a literature review for supply-chain-specific requirements for data sharing, the identification of a use case for data sharing in the supply chain domain, and a prototyping approach focused on implementing a proof-of-concept deployment of PADME to address the identified use case.

The remainder of this paper is structured as follows. In Section 2, we examine collaborative supply chain data sharing and introduce supplier ratings as a specific use case. Furthermore, we compile a requirements overview for cross-company data sharing and discuss the current state-of-the-art of technical solutions addressing those requirements, and identify a lack of existing practical implementation examples. In Section 3, we simulate a use case for a cross-company KPI exchange by synthesizing sample datasets to which we apply the PADME distributed analytics framework, detailing our technical implementation and extensions. Section 4 discusses our results regarding their performance and limitations, and proposes approaches to address these improvement potentials alongside further areas for future work.

2. Literature Review and Requirement Analysis

The following section first examines general tasks and issues in supply chain data analysis. Subsequently, the section reviews supply chain collaboration with a focus on data-driven decision support across company boundaries. We introduce the use case of exchanging supplier performance metrics to support supplier selection decisions. We further analyze the requirements for such systems and evaluate how current frameworks and technologies address these needs.

2.1. Data Analysis in Supply Chains

Supply chain data analytics span a wide range of tasks, including forecasting demand, optimizing production schedules, identifying bottlenecks, and monitoring operational performance [18]. Measuring figures such as supplier delivery reliability, production throughput, or inventory turnover plays a critical role in providing structured, quantitative insights into process performance. Internally, companies typically compute such metrics based on structured data extracted from operational databases such as enterprise resource planning systems or warehouse management systems. Transactional records, such as purchase orders, shipment confirmations, and production reports, often serve as the basis for these calculations. Even in internal systems, analytics efforts are often complicated by fragmented data sources, heterogeneous database schemas, inconsistent event recording practices, and variations in data granularity across departments [19]. As data analytics tasks are extended to an inter-organizational scale, additional complexities are introduced, which are discussed in the following.

2.2. Supply Chain Collaboration

Collaboration in supply chains occurs when two or more independent companies decide to work together to plan and execute supply chain operations more successfully than they could on their own [20]. This collaboration can typically have two primary forms [21], illustrated in Figure 1:

Vertical collaboration is established between entities at different levels of the supply chain, such as suppliers, manufacturers, distributors, and retailers. These partnerships aim to streamline processes, reduce delays, and optimize the product flow from production to customer delivery.

Horizontal collaboration is formed between organizations at the same supply chain level, including potential competitors or businesses within the same industry. Such collaboration typically focuses on expanding market reach through shared resources and capabilities, building reputation systems [22], and benchmarking [23].

Collaboration in supply chains can involve data sharing across organizational boundaries. When organizations exchange data, they can achieve goals such as improved services, enhanced operational efficiencies, and innovation in products or processes. Such data sharing activities can be driven by incentives including monetary compensation, reciprocal data sharing, or service benefits [24,25,26].

While supply chain collaboration can offer benefits, its implementation requires addressing complex challenges. Especially in horizontal collaboration, organizations must actively develop and maintain the balance of coopetition, a hybrid of cooperation and competition, where competing companies choose to collaborate for mutual benefits [27]. This requires careful consideration of data sharing mechanisms that protect individual interests while enabling collective advancement.

Given the multiple parameters and design choices in data sharing ecosystems, a use-case-driven approach enables focused analysis of requirements and challenges while allowing evaluation of transferability.

2.3. Use Case: Supplier Ratings

Selecting the right supplier is a difficult decision for many companies and organizations, with a possible significant impact on the ongoing performance of the organization [28].

In fact, supplier selection can be seen as one of the most crucial aspects of supply chain management. While academic literature on this topic is extensive, many industries still face challenges in implementing effective selection processes [29]. The evaluation typically considers multiple criteria, including price, flexibility, quality, delivery, and service. More recently, external factors such as political or environmental considerations have also gained importance [30]. Selecting appropriate suppliers ensures that goods and services are delivered in the right quantities, at the right price, and at the right time. The selection criteria are described by several key performance indicators (KPIs).

One KPI that could be computed using cross-company data sharing is the on-time delivery score of suppliers. This metric plays a significant role in supplier selection, as a supplier’s performance with regard to delivering on-time directly impacts a company’s operational efficiency [31]. For companies with limited or no experience with a particular supplier, evaluating performance metrics becomes particularly challenging. The ability to build this KPI from other companies’ experiences could provide valuable decision support, thus presenting a relevant use case.

2.4. Requirement Analysis and Current Technologies

To enable such collaborative scenarios, we examine the technical approaches and solutions proposed in the literature. While business and organizational aspects play an important role, we focus particularly on the technical feasibility and implementation of data sharing solutions. These range from fundamental privacy and security mechanisms to governance frameworks and concrete analytics solutions, each addressing distinct requirements of collaborative data sharing.

Privacy and security form the foundation for cross-organizational data sharing solutions [32]. At the most basic level, privacy is ensured through data anonymization techniques, while differential privacy provides formal guarantees for protecting records of individuals [33]. For security, solutions range from basic encryption to advanced approaches like secure multi-party computation, which offers mathematical guarantees for secure distributed computations. In industrial settings, trusted sensors and execution environments (TEEs) enable end-to-end security for distributed data processing [34]. These fundamental mechanisms establish the essential trust required for organizations to share sensitive data.

Building on these fundamentals, organizations need to establish trust and governance structures to enable sustainable data sharing partnerships and ensure mutual value creation. Blockchain technology can help build trust between organizations by providing transparent and verifiable records of all data transactions [35]. Governance frameworks define the rules and policies for data sharing—in federated models like Gaia-X, organizations collectively establish shared policies, data standards, and compliance rules [15].

For data sovereignty and control, organizations may employ smart contracts to automate access and usage policy enforcement [36]. Initiatives such as the International Data Spaces implement this through a decentralized architecture where data providers maintain control over the access to their data [37].

Interoperability standards enable consistent interpretation and seamless technical exchange of data across organizations [38]. Various domains have established specific standards—for instance, SNOMED4 in healthcare or ISO standards in manufacturing ensure that data maintain their meaning across organizational boundaries [39]. However, manufacturing supply chains lack comprehensive standards that cover all production parts and processes, especially for composite parts and complex assemblies. Initiatives like the Digital Product Passport have the potential to address these standardization challenges in supply chains [40]. There is a need to not only standardize the terminology, but also the exchange process. Data exchange protocols need to be established. For example, IDS implements a standardized protocol through specifically developed software components (“Connectors”) that provide API-based data exchange while integrating usage policies and access control at the technical interface level [14].

Data quality assessment is particularly challenging in supply chains, as quality requirements are heavily use-case dependent and differ across organizations—what constitutes high-quality data for one partner’s analytics might be insufficient for another’s process control. While generic data quality frameworks define metrics such as completeness, consistency, and timeliness, their concrete interpretation needs to be negotiated for each cross-company data sharing scenario [41].

Turning data into actionable insights requires data processing and applied analytics solutions. Solutions such as Apache Spark5 and Apache Flink6 address data processing on distributed systems and can handle large data transfers. In the area of applied analytics, traditional centralized approaches where data are pooled for analysis in a single location offer straightforward implementation and direct control over the analytics process. However, when data sovereignty or privacy concerns prevent centralization, distributed methods such as federated learning enable collaborative model training across organizations without raw data sharing, particularly for applications like image classification and prediction tasks [42]. Domain-specific implementations such as the Personal Health Train in the healthcare domain enable distributed analysis of medical datasets across multiple hospitals. The PHT follows a ‘train-to-data’ principle where analytics algorithms travel between participating hospitals, allowing them to collectively analyze patient data and derive medical insights while maintaining local data storage [17]. This approach uniquely ensures that no raw data are transferred; instead, it is the algorithm that is sent to the data, and only the results of the local computations are returned to the requester.

Table 1. Requirements for cross-company data sharing and current technologies to address them.

Requirement	Technologies
Data privacy	Data anonymization
	Differential privacy
Security	Encryption
	Multi-party computation
	Trusted execution environments
Trust and governance	Blockchain
	Federated governance models
Data sovereignty and control	Smart contracts
	Decentralized access control
Interoperability	Vocabularies and ontologies
	Standardized data exchange protocols
Data quality	Collaborative data quality management
Actionable insights	Centralized analytics
	Distributed analytics

summarizes the requirements and existing technologies.

The frameworks and approaches discussed above highlight the current landscape in enabling data sharing and analytics across organizational boundaries. Rather than attempting to develop a comprehensive theoretical framework that addresses all these aspects, we adopt a use case-driven approach where we apply a framework to the concrete scenario of collaborative supplier ratings in supply chains.

Among the analyzed approaches, distributed analytics—particularly the ‘train-to-data’ principle demonstrated by the PHT—offers a promising foundation for our use case-driven development. To evaluate this approach in practice, we build upon PADME, a framework that has already proven successful in healthcare settings. We have chosen this framework over other comparable solutions such as Vantage67, FAIR Data Train8, DataSHIELD9, and PySyft10 for its easy deployability. In

Table 2. Comparison of the requirements in the healthcare and supply chain domain.

Dimension	Healthcare Domain	Supply Chain Domain
Data privacy	Mandatory due to regulation (e.g., GDPR)	Critical due to business confidentiality and competition
Security	High sensitivity (e.g., patient data, GDPR-regulated)	High sensitivity (e.g., trade secrets, supplier performance data)
Trust and governance	Strong legal regulations	Emerging governance frameworks (e.g., IDS, Gaia-X)
Data sovereignty and control	Distributed data across hospitals, individual ownership of patients	Distributed data and ownership across independent companies in the supply chain
Interoperability	Different systems, medical terminologies (e.g., SNOMED)	Heterogeneous systems, varying KPIs and taxonomies
Data quality	Varies across institutions; supported by standards like HL7/FHI	Inconsistent across firms; lacks standardized KPIs and formats
Actionable insights	Research collaboration, improving public health outcomes	Operational optimization and benchmarking

, we compare the similarities and differences of the healthcare and supply chain domains, and find that the privacy and data protection requirements, the emphasis on stakeholder sovereignty, and the decentralized nature of data support the case for the transferability and alignment with the requirements of the supply chain domain of PADME.

To position our proposed approach within the broader landscape of distributed analytics methods, we compare PADME against federated learning and multi-party computation frameworks. The comparison analyzes the focus of each approach, its deployability, and its scope of analytics tasks, as summarized in

Table 3. Comparison of distributed analytics frameworks.

Framework	Focus	Deployability	Scope of Analytics Tasks
PADME	Data sovereignty and decentralized analytics	High (Dockerized, moderate setup effort)	High (suited for a high variety of computation tasks)
Federated learning	Collaborative machine learning model training	Medium (requires ML frameworks, model synchronization, substantial setup)	Medium (suited specifically for predictive modeling tasks)
Multi-party computation	Strong cryptographic security for joint computation	Low (computationally intensive, complex integration)	Low (strict requirements for defining functions)

.

PADME, federated learning, and multi-party computation represent fundamentally different approaches to distributed analytics.

PADME prioritizes data sovereignty by executing analytic tasks directly at data sources, allowing organizations to retain full control over their sensitive information. Its architecture, based on lightweight Dockerized deployments and flexible analytics scripts, offers high deployability with moderate technical effort. Given its design for decentralized data sources and its adaptability to various computation tasks, PADME aligns closely with the needs of supply chain collaboration.

Federated learning focuses on collaborative model training across decentralized datasets, aiming to produce a shared predictive model without moving raw data. Although it preserves a degree of privacy, it requires substantial technical setup, including compatible machine learning frameworks and ongoing synchronization of model updates. Its relevance to supply chain contexts is limited to specific use cases of predictive modeling tasks.

Multi-party computation emphasizes maximum privacy and security through cryptographic protocols, allowing joint computation without revealing private inputs. While offering strong theoretical privacy guarantees, multi-party computation imposes significant computational and communication overhead, reducing its deployability. Its rigid requirements for parties to jointly define functions and operators make it less suited for conducting a variety of analytics tasks.

In the following section, we detail how we employed PADME’s distributed analytics framework to enable collaborative supplier performance analysis across multiple organizations. This practical implementation allows us to evaluate both the technical feasibility and practical implications of the approach while continuously evaluating the implementation against the broader requirements for collaborative data analysis in supply chains.

3. Applying a Distributed Analytics Framework to a Supply Chain Use Case

For our practical implementation, we employed PADME [16] as a central component of our approach. PADME is designed to enable secure, decentralized analytics across multiple parties. Built on the Personal Health Train concept, it allows for the execution of complex analytics across distributed data sources without requiring the centralization of sensitive data.

PADME has been deployed in both the medical and social sciences domains [43,44]. In the medical field, the system has been implemented to allow researchers to access and analyze sensitive health data without compromising patient privacy and sovereignty, as demonstrated by its use in a study on federated learning for medical data analytics. In social sciences, PADME has been utilized to analyze sensitive, decentralized datasets for a sentiment analysis. These applications demonstrate PADME’s adaptability in cases where the generation of insights from multiple parties is needed while the sharing of data itself is restricted.

Building upon the framework’s capacity for decentralized analytics across distributed data sources, we apply PADME to a use case within the supply chain domain.

3.1. Use Case Setup

We selected the on-time delivery as our test case for information sharing through PADME. The on-time delivery is a KPI defined per supplier as [45]:

$$\mathrm{On}\text{-}\mathrm{time}\mathrm{delivery}=\frac{\mathrm{Number}\mathrm{of}\mathrm{on}\text{-}\mathrm{time}\mathrm{goods}\mathrm{receipt}\mathrm{positions}}{\mathrm{Number}\mathrm{of}\mathrm{goods}\mathrm{receipt}\mathrm{positions}}\times 100\mathrm{in}\%$$

Thus, for this score to be of value, it is required that the KPI is computed based on transactional delivery data.

The required data are sourced from the following relations in ERP systems [45]:

$$OrderProcessing(OrderID,OrderLine,ItemID,ConfirmedDate,ItemType)$$

$$GoodsReceiptEntry(GoodsReceiptID,OrderID,OrderLine,ItemID,EntryDate,ItemType)$$

Figure 2 and Figure 3 present examples of these datasets.

Using these data, the on-time delivery score is computed as follows. For the supplier in question, four orders were placed: two delivered on time and two delayed. Applying the formula, the score is calculated as:

$$\mathrm{On}\text{-}\mathrm{time}\mathrm{delivery}=\frac{2}{4}=50\%.$$

For our use case of on-time delivery exchange between companies, we chose a simulation-based approach to flexibly explore a simple setup and practically execute the entire pipeline with low implementation barriers, while still considering all potential challenges that may arise. We set up sample databases in PostgreSQL on two separate machines to represent two distinct manufacturing companies interested in sharing information on the on-time delivery rate of suppliers. Each database contained 200 entries with randomized delivery data and supplier identifiers, simulating synthetic yet realistic datasets. The aim was to calculate averaged on-time delivery scores of suppliers across participating companies, such that an aggregated score could be retrieved without centrally collecting individual scores. While the use case would benefit from, and the PADME framework theoretically supports, a large number of participating companies, we limited our setup to two entities to focus on establishing a proof of concept. This approach allows us to validate the core functionalities of the framework.

With the simulation setup established, in the following, we delve into the technical details of how the PADME framework operates, and how we integrate the databases of the simulated companies.

3.2. The PADME Architecture

Figure 4 illustrates the PADME architecture.

PADME is built on the PHT concept which enables distributed data analysis by allowing data to remain at the source, while analytic tasks are executed at the distributed sources, only transferring results.

PADME’s architecture is composed of three main components: Stations, Trains, and Central Services (CS) [43,46].

The Stations are independent, self-contained units that manage both data storage and the execution of analytic tasks. Each Station either stores data locally or provides access points for it, running containerized analytic models via Docker. After completing an analysis, the results are returned to the CS or the relevant repositories, ensuring that only results, and not the underlying data, are transferred during the process.

The Trains are computational workflows that travel between these Stations to perform analytics. These Trains carry predefined algorithms to be run by the Stations on the data, such as computations, transformations, or statistical analysis. They are defined and stored in Train Depot repositories and are orchestrated by the CS. Once the analysis is completed, the results can be written back to the Train which returns them to the requester, keeping the raw data within its originating Station.

The Central Services manage the coordination of tasks by defining the sequence of Stations and Trains involved in each analysis. They also manage the Train Depot repositories that store and allow access to the analytic models. Additionally, the CS includes monitoring tools that ensure transparency and accountability throughout the execution of tasks. For the Stations to function within the PADME framework, they must first register with the CS. This registration process enables the CS to manage and coordinate the tasks assigned to each Station.

In our simulation, the components of PADME’s architecture correspond to the following entities:

• Stations: The two machines in our setup represent the Stations in the PADME framework. Each machine simulates a separate company, with its own local PostgreSQL database storing supplier delivery data. The two simulated companies (Stations) must be properly registered and recognized by the CS before they can execute the analytic tasks.
• Train: The analytic task in our case is implemented as a Python script (3.10) that is containerized using Docker. This script, representing the Train, is transmitted to the respective Stations. Upon reaching a Station, the script can be inspected and executed. The Train’s primary function is to request access to the local database, perform the calculation of the on-time delivery score as defined earlier, and store the result to return it to the requester.
• Central Services: The CS are an existing application implemented by the PADME developers and can be compared to a train operation service. These services coordinate the transmission of the containerized Python script (Train) between the Stations.

Requests to CS for a Train to roll can be initiated by any authorized user. While this flexibility is essential for operational efficiency, it also necessitates strict user access control and activity monitoring. Ensuring that only authorized users can submit requests helps maintain the integrity of the system and prevents unauthorized interference with the analytic processes or data exchanges. In our use case, the idea is for companies registering as participants to be both potential data providers as well as authorized data requesters.

To address this, PADME’s system integrates identity and access management mechanisms, such as Keycloak11, to control access to the platform, ensuring that only authorized users can interact with it.

3.3. Use Case Execution

Figure 5 marks the execution steps of PADME along its architecture. The process of on-time delivery score calculation is visualized as a flowchart in Figure 6.

At Step 1, a company initiates a request for an on-time delivery score calculation through CS. The process is illustrated in Figure 7. Upon receiving the request, the CS triggers the creation of a Train ride, stored within a Docker container, and pushes it to the next company on the line.

At Step 2, the company pulls the Docker image, where it can inspect the contents of the container before deciding whether to allow its execution, an example snippet of which can be seen in Figure 8. Should the company choose to reject the execution, the Docker image appends no results, and only appends any rejection reasons, if provided by the company. The train is pushed to the next Station.

If a company decides to allow the Train to execute its script, it is required to provide the necessary database connection details to the Docker container to enable the Train’s access to its local database. The Train then calculates the on-time delivery score based on the data available in the company’s database. Upon successful calculation, the resulting score is appended to a predefined results list, stored within the Docker container along with the script. The updated container is pushed back to CS.

At Step 3, once the ride is complete, the requester can pull the updated container, which now contains the appended on-time delivery scores, allowing the requester to access the results of the analysis performed on other companies’ data without transferring the underlying data itself. A sample results view is illustrated in Figure 9.

PADME is connected to a user interface through an Application Programming Interface (API) integration that enables interaction between the two systems. This integration allows users to trigger the execution of a Train through the interface. By using the API, the user interface can send requests directly to PADME’s CS. The interface abstracts the complexity of the underlying process, allowing users to specify the data, select the appropriate analysis, and initiate the execution with minimal technical knowledge. Upon a user’s action, the API sends the necessary parameters to CS, which deploys the corresponding Train to the designated Stations. The results are then retrieved and displayed back to the user, completing the workflow.

3.4. Data Privacy

Aside from the calculation and transmission of the KPI, we have explored how to extend the application with privacy-preserving functionalities. We focused on integrating mechanisms based on k-anonymity and l-diversity to ensure that the shared data are protected against re-identification and unauthorized inference. Firstly, k-anonymity is a privacy model that ensures that each record in a dataset is indistinguishable from at least k-1 other records with respect to certain identifying attributes [47]. This means that any individual data point cannot be uniquely identified based on the combination of its quasi-identifiers. Secondly, l-diversity is a further enhancement to k-anonymity, where the sensitive attributes in each group of k records must have at least l “well-represented” values, ensuring that the data do not expose sensitive information through homogeneity or skewness in sensitive values [48].

In the context of our use case, k-anonymity and l-diversity can be applied to the supplier data used to calculate the on-time delivery score. For example, consider a dataset containing supplier names, delivery times, and delivery statuses. If this dataset were shared between companies, it could potentially expose sensitive details such as the identity of the data provider, e.g., if it is known that the company had a partnership with the supplier in question at the given times. To apply k-anonymity, we could generalize or suppress certain quasi-identifiers (e.g., supplier names or delivery dates) such that each record is indistinguishable from at least k-1 other records. For instance, if the threshold for k-anonymity is set to 3, any given supplier’s record must be grouped with at least two other suppliers with the same or similar delivery characteristics, thereby preventing any data provider from being uniquely identified. From a technical perspective, this could involve aggregating supplier delivery data into broader categories, such as grouping suppliers by industry or geographical region, or binning delivery times into ranges (e.g., 0–5 days, 6–10 days) to reduce the granularity of identifiable data.

To ensure l-diversity, we would need to ensure that for each group of k records, the values for sensitive attributes like delivery status or delay reasons are sufficiently diverse. For example, if all records in a group of k suppliers have the same delivery delay reason, the group would not meet the l-diversity requirement unless there are multiple delay reasons present.

3.5. Data Quality Assessment

In parallel to our primary work with the PADME framework, we explored additional functionalities that could be integrated with such a system in future implementations.

One aspect of this exploration focused on developing a simple user interface for data management and quality assurance, which could play a key role in ensuring that data shared across companies is both accurate and reliable. We designed a prototype interface which includes a feature called Register Data Mode. In this mode, users can upload and review data before they are shared for collaborative analysis. The interface provides a series of checks to assess the quality of the data, which we call the data quality assistant. Figure 10 presents a simplified view of the interface.

The assistant performs several key functions:

• First, it checks for data completeness, ensuring that all necessary attributes are present;
• Second, it verifies the plausibility of the data, filtering out unrealistic or inconsistent entries;
• Finally, it applies validity thresholds to ensure that only high-quality data are used for analysis.

This functionality demonstrates how data quality checks could complement the collaborative analysis process. Future work may focus on integrating such a quality assurance tool to create a more robust and reliable environment for data-driven decision making across organizations, and on enhancing the assistant to not only facilitate assessing standard data quality metrics, but also metrics that are of use-case-specific importance. This would require a more in-depth analysis of which data quality metrics are relevant for a use case.

4. Discussion

In this section, we provide a structured discussion of our research findings. We begin with a summary and discussion of the key contributions, followed by an analysis of the limitations of the current study, and conclude with directions for future research.

4.1. Key Contributions

Our work demonstrates the technical feasibility and practical potential of distributed analytics for cross-company data sharing in the supply chain domain. The following key contributions were achieved:

• Domain-specific requirements: We identified and structured key technical and organizational requirements for supply chain data sharing.
• Adapting PADME to supply chain scenarios: We compared the requirements of the supply chain domain to the healthcare domain, and transferred a suitable framework from the healthcare domain to a use case of calculating on-time delivery metrics across companies.
• Enabling sovereignty-conscious KPI exchange: The system enables KPI computation without requiring centralization of sensitive data, preserving data sovereignty.
• Integrating privacy and quality functions: We have explored the integration of privacy-preserving techniques (k-anonymity, l-diversity) and the implementation of a data quality assistant to support trust and data integrity.

These contributions collectively demonstrate that privacy-preserving, cross-company data analytics is technically feasible and practically relevant in supply chain contexts. By grounding the design in domain-specific requirements, the work moves beyond abstract architecture to address concrete challenges faced by companies, such as maintaining sovereignty over sensitive operational data while still participating in shared performance evaluation.

The successful adaptation of a framework from healthcare to supply chain analytics not only confirms the architectural flexibility of PADME, but also shows that common concerns around decentralization and trust span multiple domains. This cross-domain transfer strengthens the generalizability of algorithm-to-data approaches and suggests a broader applicability of existing technologies in industrial collaboration.

The use case of on-time delivery illustrates how KPI exchange across firms can improve supplier evaluation and benchmarking. This is particularly valuable for companies with limited transactional history with a supplier, as performance insights can be aggregated from peer organizations in a privacy-preserving manner. The modularity of the PADME framework further allows the definition and execution of custom analytics, enabling adaptation to other KPIs or operational contexts. Examples of such variations could be the calculation of KPIs like defect rate or lead time.

Our work offers a concrete proof-of-concept that connects technologies to practical supply chain needs, making a case for distributed analytics as a viable strategy for supply chain collaboration.

4.2. Limitations

While our implementation demonstrates the feasibility of distributed analytics in supply chain settings, several limitations remain that warrant further investigation:

• Limited scale of evaluation: Our prototype setup involved only two simulated companies with synthetic data. While PADME theoretically supports larger networks, the evaluation of scalability in real-world, multi-actor supply chains was beyond the scope of this study.
• Manual approval workflow: The current data sovereignty model requires each company to manually accept or reject each analytic request. While this supports strict data control, it introduces administrative overhead and may hinder responsiveness in time-sensitive scenarios.
• Central Services as a single point of coordination: The need for participating Stations to register with the CS introduces a potential point of vulnerability. If compromised, the CS could expose metadata or enable unauthorized train requests, underlining the need for robust access and monitoring mechanisms.
• Dependence on schema consistency: The analytic script assumes a predefined schema for database access. If a company uses alternative column names or data structures, the train will be unable to perform the intended computation.
• Privacy–utility trade-off: While privacy-enhancing techniques such as k-anonymity and l-diversity reduce re-identification risks, they may limit the granularity or interpretability of results. Future research should explore whether meaningful analysis of performance trends remains possible under stricter privacy constraints.

4.3. Future Research Directions

Building on the current proof-of-concept implementation, several directions emerge for future research. A key priority lies in evaluating the scalability of the framework in real-world, large-scale supply chain networks. This includes addressing performance considerations such as processing efficiency on large datasets and reducing bottlenecks caused by centralized orchestration. One promising approach may involve restructuring the architecture into distributed subclusters that coordinate analysis locally and report to a higher-level control service [49].

In parallel, further development of the data sovereignty model is needed to reduce administrative overhead without compromising control. Automating access decisions based on predefined consent protocols, metadata, or train characteristics could streamline participation, especially in dynamic or high-frequency analytic scenarios. Integrating artificial intelligence into consent decision making may also enhance flexibility and user trust.

Another area for exploration would be schema interoperability. As the analytic scripts currently rely on predefined data formats, future work should consider onboarding support or vocabulary mapping services that align heterogeneous schemas across companies [13]. This could significantly improve the generalizability and ease of adoption across diverse supply chain contexts.

From a privacy perspective, future implementations may benefit from expanding the range of supported techniques, such as incorporating differential privacy or adaptive aggregation strategies. This could offer more flexible trade-offs between data protection and analytic utility, especially when evaluating more complex KPIs or time series data.

Finally, enabling real-world adoption at scale will require integrating technical solutions with business model and governance frameworks. This includes establishing legal agreements for data usage, providing compensation models for data contributions, and ensuring transparency in ecosystem participation [50]. Initiatives like IDS that combine technical connectors with contractual enforcement mechanisms represent a promising foundation in this regard [14].

Taken together, these research directions may help mature the proposed system into a scalable and widely applicable solution for cross-company data collaboration in supply chains.