From Dissonance to Dialogue: A Token-Based Approach to Bridge the Gap Between Manufacturers and Customers

This article presents a novel token-based recall communication system, which integrates Enterprise Resource Planning (ERP) systems and blockchain technology to enhance recall communication and cooperation between manufacturers and customers. We employed a design science research methodology to develop a set of design principles and features that support the interoperable system. Our findings demonstrate that we can significantly improve recall coordination, traceability, and co-value creation between involved parties. By focusing on the integration potential of traditional technologies like ERP systems with blockchain and token techniques, we reveal innovative synergies for both social and technical subsystems. The study explores the implications of the proposed system for both theory and practice, offering insights into the advantages and challenges of such integration. The evaluation conducted with industry experts demonstrates high reusability of the design principles.


INTRODUCTION
Product quality control and efficient communication are critical elements manufacturers use to protect consumers' health and establish an image of accountability and social responsibility [ 7 , 56 ].Maintaining internal responsibility is critical day-to-day work within manufacturing facilities, and extending it outside organizational borders must be accomplished even after the product has been delivered to the customer [ 52 , 55 ].In the past few decades, manufacturing companies have implemented traceability procedures supported by enterprise resource planning ( ERP ) systems that ensure effective internal product traceability through upstream and downstream tracing analysis [ 71 ].However, when information-sharing traceability requests exceed enterprise system boundaries, numerous communication channels can be used to coordinate multiple organizations.Especially in extraordinary situations (e.g., product recall), information sharing is necessary, regardless of companies' relationships or competing interests [ 64 ].Data exchange is often carried out sequentially amongst direct entities such as organizations and diverse enterprise systems, posing difficulties in synchronizing the states of products, locations, and customers' health in global supply networks [ 58 ].Furthermore, when external events impact a manufacturing traceability system, various organizations and information from different enterprise systems are involved, which must be gathered to obtain a consistent picture of the recall situation [ 7 , 70 ].In general, recalls are not limited to food or pharmaceutical products but have affected several industries.For example, per the 2021 Rapid Alert System for Non-Food Products (RAPEX) report, the system received 2,142 notifications about measures adopted against hazardous non-food products.Additionally, 4,965 subsequent tasks were undertaken by the network's members in response to notifications concerning dangerous products [ 9 ].From 2012 to 2021, the Food and Drug Administration ( FDA ) counted 1,317 recalls in Class I (most severe risk), a significant 10,168 in Class II (moderate risk), and 1,302 in Class III (least severe risk), totaling 12,787 recalls over the nearly decade-long span [ 33 ].
Faced with mandatory accountability of ensuring safety of the product, recalls play an important role, as they require cooperation among several supply network actors and informationsystems ( IS ) integration [ 11 ].Currently, however, it is still challenging to create syntactic and semantic standards across company borders to establish a shared understanding and design an accepted traceability standard in supply networks [ 22 , 40 , 46 ].These challenging conditions apply to emerging technologies and concepts like representing of physical assets as tokens to extend product traceability across organizational boundaries [ 30 , 45 , 58 , 67 ].While a token-based approach in blockchains ( BC ) is a promising use case, less attention has been paid to recall procedures from a manufacturer's perspective and co-value creation processes with customers [ 2 ].
Manufacturing professionals are still confronted with managing traceability processes and providing high-quality data to ensure end-to-end traceability within their organizations' borders.To guarantee product quality and protect customers' health across several manufacturing facilities, in the future, they will also need to start with simple and practical examples to develop an interorganizational perspective to capture the complexity of multiple organizations and enterprise systems that support their trading partners' manufacturing environments [ 15 , 45 ].So far, enterprise systems and supply network BC studies are still in their infancy, making it necessary to continue research on the potential of co-value creation in customer-centric IS and the resulting impact on manufacturers and customers [ 2 , 20 ].Our motivation is therefore to explore the following research questions: -RQ1 : How can customers and manufacturers enhance their communication across different IS to establish a co-value creation approach?-RQ2 : How can an IS be utilized to improve recall communication between customers and manufacturers in a recall process?
We first introduce the research method, which offers a theoretical and practical approach to answer our research questions.Subsequently, we describe relevant steps and develop an IS Artifact.Next, we provide the current state of the research and practice on various technologies and recall communication techniques.We assess these using three design cycles and an ex-post approach with industry experts with multiple viewpoints on recall procedures, enterprise systems, and BC to develop design principles.We offer a variety of contributions for research and practise, including a structured socio-technical modeling technique that reduces coordination efforts and novel technological advancements to transform isolated IS.We conclude our work with a discussion 3:3 Fig. 1.Research methods per [ 36 ].
of limitations and future research directions that can support the adoption of co-value creation processes between manufacturers and customers.

METHOD
Artifact design and exploration are known in the IS community through Design Science Research ( DSR ) methods that propose guiding principles, phases, or processes [ 29 , 43 ].In this study, we use a method that accumulates design knowledge (see Figure 1 ) and we make it available while considering that our results should be reusable for practitioners [ 21 , 36 ].
The goal of I-Objective is to explore the synergies between customers and manufacturers for recall communication, where social and technical subsystems must be jointly optimized in advance to operate in harmony.Therefore, we do not exclusively focus on a prototype design but go beyond the socio-technical perspective describing social and technical subsystems as well as information about an IS artifact [ 6 ].
II-Research Context thus covers developing a complex supply network scenario and enterprise BC prototype.We conduct a qualitative study to ensure that the results are as reusable as practicable for practitioners and decision-makers in the future [ 21 ].
To develop design principles, [ 36 ] suggests two different research approaches, as discussed in III-Research Approaches.The supportive approach develops design principles before a prototype is developed.On the other hand, the reflective approach follows an iterative process in which the problem, an artifact, and, by abstraction, design principles are developed [ 6 , 66 ].The design science procedure offers the possibility to re-enter different stages to adjust the conceptual design and develop the results in several cycles [ 36 , 43 ].
In IV-Problem Definition, we use a supply network scenario and a state-of-the-art enterprise system implemented in supply networks that support manufacturing environments.We further show challenges regarding the organization of recall processes and the cooperation between customers and manufacturers.
In V-Design Artifact, we start with customer-focused integration possibilities and the current technological opportunities to use a token-based approach for recall communication.We show in three iterations how we designed an artifact to bridge the gap between customers and manufacturers.The IS Artifact and results enable us to VI-extract design principles and evaluate them with practitioners in VII-Evaluate.

PROBLEM DEFINITION
The design, implementation, and use of traditional IS are the backbone of a contemporary information society [ 57 , 62 ].Improving existing IS or optimizing them for a specific purpose is an ongoing motivation for researchers and practitioners that drives to organizational culture and structure changes, known in the literature as "digital transformation" [ 18 ].The use and combination with novel concepts like BC-based tokens open many possible innovative use cases in supply networks, which can lead to conflicts between humans due to different perspectives of business, technology, legislation, or a wide range of complexity drivers that exist in the real world [ 31 , 45 , 58 ].To describe the problem state holistically in the interest of research and practice, we use the Technology-Organization-Environment ( TOE ) Framework addressing the different dimensions of technology innovation decision-making [ 8 , 60 ].

The Complexity of Organizations and ERP Systems in Supply Networks
Nowadays, many organizations use a wide range of IS to manage internal operations in supply networks.One of the most popular enterprise systems is ERP, which enables supply network actors to organize and optimize internal business processes using a complex relational database [ 3 , 45 ].In practice, manufacturers can operate not just one ERP system but a more complex ERP landscape that is characterized by related systems, add-ons, and individual applications [ 15 ].In general, ERPs generate a broad spectrum of source, production, and sales event data, providing information about products and identifiers like batches and serial numbers to enable recall-traceability procedures within company borders [ 71 ].Alternatively, this data can also be described through a process perspective using the nomenclature of the Supply Chain Reference Model SCOR, such as source, make, and deliver events [ 27 , 68 ].These events are typically stored in enterprise systems' inventory movement tables, which use provider-specific (e.g., Microsoft, SAP, Weclapp) syntax that expresses semantically identical business processes (e.g., Source event: Microsoft Navision: 0 -Purchase; SAP: 101 -Goods Receipt; Weclapp: IN PURCHASE ORDER) [ 12 , 51 , 65 ].
To describe and capture the complexity of a holistic supply network, we highlight all terminology in this section in bold and connect them to Figure 2 .Our customer-focused recall communication scenario is based on the main SCOR events and represents a real-world production facility.For our purposes, however, the scenario is based on simulated data and an education enterprise system, which has sufficient complexity to present a more realistic use case for manufacturers that deliver products to more than one, two, or three customers [ 28 , 45 , 67 ].Therefore, we illustrate an entire product flow organized within a single ERP system, transform enterprise data, and employ a dynamic Sankey diagram, which has been used in manufacturing environments since the 19th century [ 48 ].
The visualization of enterprise information includes a separable end-to-end product and process flow of two vendors (v01 and vo2), nine production plants (AA-GG), each with two storage locations and one workstation.The product flow presents 19,287 raw material movements ( input ) transformed into 6,139 finished material movements ( output ) delivering products to 194 customers .All event data generated in a single ERP system are identifiable by a system ID.In the interest of standardization, we reuse the nomenclature for a unique enterprise system and define them as Unique System Identifier ( USID) (e.g., USID 1-3) [ 46 ].As mentioned previously, an organization can operate one or multiple ERP systems.
As a result, we boundary and define an intra -organizational perspective as a single organization that operates one or multiple ERP systems.Therefore, an inter -organizational perspective describes an integration of multiple ERPs and multiple organizations (e.g., from Org1+USID1 to Org2+USID2).The most crucial point is that information on traditional enterprise systems is bounded [ 3 ].They are not interconnected to one another to establish a traceability path, integrate the entire supply network, and provide synchronized recall states for products and customers between multiple organizations.
This section highlights organizational and technical challenges in designing a customer-focused recall communication system across multiple organizations and heterogenous enterprise-provider data models.Furthermore, the variety and amount of production data that could be transferred from an ERP system into a BC can lead to an increased effort for mapping organizational and technical structures and managing transparency concerns of sensitive objects between organizations [ 46 , 53 ]. ( DR1: The enterprise systems should be mapped straightforwardly, and only essential recall communication data must be stored in the BC; DR2: The system should provide an entire recall traceability path to ensure synchronized communications between multiple organizations).

Obstacles to a Variety of Terminologies and Procedures to Conduct Recalls
Creating traceability in a manufacturing system is fundamental to satisfying short-, medium-, and long-term targets.The system can interact with the internal and external environment depending on its emphasis [ 7 ].The internal environment mainly describes the short-term horizon and activities from a manufacturer's point of view, whereas the external environment describes mediumand long-term interactions with the customer.More than thirty years ago, four basic categories of communication were defined to describe extraordinary interactions between manufacturers and customers: "deny", "involuntary", "voluntary", and "super effort" [ 54 ].These are still part of BC-supported supply network research and are alternatively described as "passive" (involuntary) and "proactive" (voluntary) communication types [ 69 ].However, researchers distinguish between "reactive" and "proactive" when referring to the temporal context of decision-making [ 37 ].Proactive, in this sense, describes a prediction toward the future rather than a willingness to communicate transparently in recall situations.We identified technology-independent terminologies such as "backward" and "forward" in food and manufacturing, which trace objects and events from

Risk analysis Identification and localization of items
Recall different starting points.For example, "forward" describes the starting point of a raw material and its manufacturer, whereas "backward" describes the starting point of a finished material from the customer's perspective [ 22 , 24 ].Different contributions also adopt this terminology considering a combination of BC and recall management in supply networks using the terminology "reverse" (backward) and "forward" [ 1 , 25 , 42 ].Thus, it is difficult to come to a consistent and standardized understanding of supply network communication processes due to terminology and concept variances.However, all these terms describe different circumstances.They are hardly seen in recall approaches and steps that we analyzed in Table 1 for state-of-the-art enterprise systems, the global standardization organization GS1, and an example identified in a research paper: The comparison of research and procedures supported by enterprise system reveals an emphasis on internal tasks, such as identifying a defective product, conducting a risk analysis, and providing fewer details to external stakeholders to coordinate a recall.The GS1 recall guidelines, in contrast, focus more on external communication between involved entities to provide a potential basis for interaction between manufacturers and customers.This interaction has been conceptualized in the current research for BC-supported food-supply networks [ 28 ].It should be noted that all emphasis relies on product identification and recall notification.None of the approaches considers the state of the customer's health.( DR3: The system should allow intuitive communication of product-and customer-health states).

Related Work
Research papers that address enterprise BC are scarce, so the co-value creation between manufacturers and customers has barely been explored [ 20 ].Research remains focused on why, where, and how the application of technology could add value to supply networks [ 2 ].According to the authors, one of the significant drivers for organizations implementing BC in supply networks is the demand for traceability and transparency.Enhancing the customer experience is an additional reason to employ technology (e.g., to provide product provenance).However, there is currently little discussion over how product recalls can be handled.Product recalls are a specific but important topic for which authorities such as the FDA or Rapex support organizations with recalls and risk assessment guidelines [ 38 , 39 ].To assist product recalls, we list BC-related research articles and literature we have found in research and practice.We start by examining the technical subsystem and analyzing technical components.We extend the overview for the social subsystems to show customer integration within the manufacturer's supply network.Finally, we delineate the  2 presents a fragmented overview of recall scenarios that rarely explore the potential of combining traditional enterprise systems such as ERP and permissionless BC.The co-value creation of private customers is still in its infancy and has only been studied in two research articles.It should be noted that only two papers consider the reuse of industry standards (e.g., GS1).Different standards for consumer product recalls (e.g., ISO 10393) or any publication do not mention the ISO 307 standard that supports the development of BC use cases.The ISO 307 standard, on the other hand, does not yet list the communication or management of product recalls as a use case for supply networks [ 23 ].It is still unclear how the link between organizational and technological subsystems may be adequately and compliantly designed considering additional environmental factors (e.g., recall guidelines).( DR4: The system should allow interoperability between enterprise systems and permissionless BC; DR5: The system should allow co-value creation procedures between manufacturers and private customers).

DESIGN OF THE IS ARTIFACT
With the goal of constructing an efficient recall system, we decided on traditional and novel technologies where both manufacturers and customers are characterized by different social and technical subsystems.In the problem description, we already described a manufacturer's subsystem with traditional enterprise systems, on which private customers have no access.For establishing the link we decided on BC technology, particularly, an architecture built upon public BC.This selection was motivated by a triad of pivotal advantages which fortify the essential foundations of our system: interoperability, transparency, and decentralization.
Interoperability: Public BC are not owned or hosted by single corporations (e.g., software provider), also not hosted by consortiums, and are accessible without special knowledge or privileges.
Transparency: Everything on the public BC is known to both the customer and the manufacturer.The manufacturer can add a mapping inside their own enterprise system to augment the BC data with their own confidential data while the customer still has basic access.
Decentralization: Anyone can modify, extend, or use the system without needing to ask for permission, access, or source code.We enable easy subsystem integration by connecting manufacturers and customers to the Ethereum Virtual Machine ( EVM )-based architecture.Using the EVM architecture in the artifact aims to establish this connection without significantly modifying the existing manufacturer's system and by using an application that the customer ideally already has installed on their device (e.g., smart phone).The EVM standard has already been adopted by millions of users, including 50 million active monthly users with Brave [ 5 ] and 21 million active monthly users with Metamask [ 10 ].Multiple methods or services can facilitate interaction with customers within the EVM ecosystem.One such popular service is Ethermail [ 14 ], which allows users to send an email-like message to anyone with a known public address.Other protocols capable of wallet-to-wallet messaging include XMTP [ 16 ] and Push [ 44 ].Messaging applications like Blockscan Chat [ 4 ] and WalletChat [ 63 ] enable users to log in with Ethereum ( DF1: Customer wallet notification for recall states).

Iterations of the IS Artifact
The development of our IS Artifact followed an iterative approach, allowing us to refine and improve the design and functionality over each iteration.This process involved three iterations, each focusing on a specific aspect of the system while addressing the challenges and limitations identified in previous iterations.

Iteration 1: Integration of BC-Based Tokens into ERP Systems.
Most approaches to offering customer data are based on transferring them from ERP into a BC [ 3 , 45 , 66 ].In contrast, less attention has been paid to the possibility of transferring data from a BC into an ERP system [ 59 ].As mentioned in the previous section, providing internal end-to-end traceability is available in enterprise systems through fundamental downstream and upstream analyses, thereby mapping product traceability analysis into the BC results in almost redundant IS concepts.The function expands in case several ERP systems and data objects are integrated to represent the end-to-end traceability path of a supply network, which can lead to additional efforts managing the confidentiality of objects between multiple organizations [ 46 , 53 ].
To map more-complex products into a BC, product identifiers-objects, such as serial numbers or batches, need to be implemented, which leads to increased complexity in the programming of the smart contract to map a traceability path using organizational structures or developing logic for partially consumed amounts of batches [ 47 , 61 ].To limit the coordination effort and management of objects, we choose the highest level of abstraction that can be expressed by a traceability path of organizations we define as system .A system object represents a list of enterprise systems gathered from various organizations and the flow of a product through the supply network.System objects, therefore, must be merged in production orders inside the ERP system to prevent complex operations on the BC.However, the list of organizations is merged on the BC.Further objects necessary to achieve a coherent flow of tokens in Ethereum are the use of a Contract (e.g., 0x123 and 0x124), a TokenID (e.g., ID1, ID99), and the transfer of a token from one Owner to another (e.g., from USID n to USID n+1) ( DF2: BC ERP Integration through Objects: TokenID, Contract, FROM/TO OWNER, System).
To connect enterprise systems with EVM-compatible BC, their unique identifier, the contract address, and the TokenID combined must be recorded in a movement table of an enterprise system.In addition, the TokenID must be assigned to a serial or batch identifier, which is pulled from  output/finish material after final confirmation of a production order (see make/merge and TokenID 1).An example of Figure 3 is shown in exemplary Table 3 .
As a result, we show the technical feasibility of integrating a token's flow in a movement table of a traditional enterprise system, which, however, is limited to an intra-organizational perspective.Therefore, we extend the concept to multiple organizations and customers.

Iteration 2: Managing the Complexity of Network Objects.
In this iteration, we zoom out of a single ERP system and develop an inter-organizational perspective, as defined in the previous section.A USID shows a possible technical object as the highest level of abstraction to identify an ERP system [ 46 ].In our concept, we adapt the idea of defining a traditional enterprise system as a token owner to connect multiple enterprise systems, which can be transferred to a customer at the end of the product flow.Therefore, Figure 4 describes the possibility of this token flow without the need to map and create standards for organizational structures (e.g., workstations, plants) of heterogenous ERP data models.The challenge in this approach is to identify the enterprise systems and organizations that will participate in the supply network system and connect them to smart contracts that allow them to mint tokens.We have also considered more-complex IT landscapes, where an organization can operate multiple ERP systems (see USID 2 and 3 of Organization 2 ).In the following case, even a subcontractor can participate in the system, depending on the product flow, if they are assigned to a smart contract (see SC 0x124 ).For systems to be merged correctly, organization 2 needs to maintain the S0 of the subcontractor in USID 3.
Ethereum allows developers to develop and implement smart contracts on the Ethereum BC, a distributed computing platform.The defining features of Ethereum include the ability to generate and trade tokens, which are virtual assets representing a unit of value employed for various purposes, including transactions, administration, and utility functions within decentralized  applications.The Ethereum protocol has introduced several token standards since its launch, defined by Ethereum Improvement Proposals ( EIPs ).Table 4 summarizes the EIPs for token standards on the Ethereum BC.These standards offer a range of features and functionalities, such as standard interfaces for tokens, non-fungible tokens for unique assets, multi-token standards for managing multiple tokens in a single, smart contract, payable tokens that enable more complex interactions, and a smart contract-based account structure.These standards have different statuses; some are being widely adopted and finalized, while others are still being drafted or are stagnant.
None of the existing token standards listed in Table 4 fully meet the requirements for our new recall communication token.While some standards, such as ERC721, allow users to create unique tokens, they do not provide the necessary functionality to trace previous manufacturers and notify all previous holders simultaneously.While ERC1363 and ERC777 offer more complex interactions between tokens and smart contracts, they do not address the specific needs of recall communication, such as product and recall states and a list of organizations that manufactured the product.Therefore, creating a new token standard is necessary to achieve the goal of our new token, which is to provide a comprehensive recall communication solution.
From Dissonance to Dialogue 3:11 While the ERC1155 does not provide us with everything we require, it is an excellent starting point for a few reasons.The first reason is interoperability, as the standard allows for multiple token standards within one smart contract.This also allows for extensibility, such as adding fungible tokens to this system in the future.Second are batch operations that allow us to mint and send multiple tokens at once, making the system more efficient in production.We acknowledge that taking the ERC721 standard as a basis would have been a good option, too short of the beforementioned convenience features.The token must be stored on a system that is available to all manufacturers and customers ( DF4: Interorganizational BC-based data storage).Second, the token must implement a standard interface to transfer it from organization to organization, organization to customer, and customer to customer ( DF3: Recall tracing and product state extension of the token).Third, all manufacturers must be known to create a history of previous manufacturers that is then used for the recall process ( DF6: Smart Contract Token Ownership Tracing History).

Iteration 3: State Definition and Execution for Customer-Manufacturer Recall Procedures.
We conceptualize established procedures that are recognized and performed in manufacturing facilities to provide simple solutions that humans can process visually and intuitively.For this purpose, we rely on the visual management concept known as ANDON [ 49 ].It is characterized as the most typical sort of light used in visual control applications and consists of three distinct colors-red, yellow, and green-which each express a distinct meaning [ 41 ].
To reflect the current state of the product and the recall process, we have implemented three products and three recall states (see Figure 5 ).The product state "OK" is used by default, and "On Hold" is set once a customer announces a product is defective ( backward recall ).This also sets the recall state for this product for all manufacturers to "Check Requested."Every manufacturer can set the recall state to "Checked OK" or "Checked NOT OK."If one manufacturer sets the recall state of a specific TokenID to "Checked NOT OK", the product state changes to "NOT OK."If every manufacturer sets the recall state to "Checked OK", the product state changes to "OK" again.Figure 5 shows the product and recall states with the example of one product and its manufacturer recall states by manufacturers' object systems.The product state is "NOT OK" as manufacturers 2 and S0 have set the recall state to "Checked NOT OK" ( DF7: Manufacturer recall state management; DF5: Customer product defect announcement).All manufacturers can also directly set the product to "Checked NOT OK", initiating a forward recall that notifies all customers with this token of the defective product ( DF6: Manufacturer product defect announcement).Lastly, the customer can also provide voluntary information about his health state by using the recall states where "Checked NOT OK" means the customer's health is impacted.The majority of product safety risk assessments focus on human bodily injury or health [ 40 ].As a result, this data is compliant with the necessity to identify the severity and number of impacted humans (e.g., private customers) in the context of risk assessments [ 41 ].The BC technology offers futhermore a supporting wallet-to-wallet communication to provide customers with additional and individual information from manufacturers about how to proceed with "NOT OK" products.
We provide our prototype on the Polygon Testnet Mumbai, and the interface specification and the reference implementation are in permanent decentralized storage.We also want to emphasize that the files are always available on other IPFS gateways with the same Content Identifiers ( CIDs ).

Mapping Design Features to Design Principles
Design principles are abstractions that describe prescriptive knowledge and should be written so that their recipients can quickly grasp them to ensure their utility.For this purpose, we use a mapping diagram to connect the design features to the design principles [ 36 ].Finally, the design principles are also subsequently linked to the design requirements.Figure 6 describes the aim, context, and mechanism according to the recommendations for formulating design principles [ 17 ].
The authors further divide into different roles, which we have illustrated through different colors and titles, highlighting possible features with which the respective role will have points of contact in the ReCoBridger IS.DP1 integrates any ERP system by extending existing data models of required BC objects (DF2) and recall tracing (DF3), promoting seamless communication between ERP and BC systems.DP2 captures multiple enterprise systems and analyzes historical owners (DF7) using BC-ERP integration (DF2) and recall tracing (DF3), fostering cross-organizational collaboration in recall processes.DP3 enables traceability functions with customer wallet notifications (DF1) and backward and forward ownership tracing (DF8) to ensure synchronized communication for all related owners.DP4 provides interoperability between EVM-supported software applications using recall tracing From Dissonance to Dialogue 3:13 (DF3), customer wallet notifications (DF1), inter-organizational BC-based data storage (DF4), customer product-defect announcements (DF5), manufacturer product-defect announcements (DF6), and manufacturer-recall-state management (DF7).DP5 implements mechanisms that allow customers to receive recall information (DF1) and announce product defects (DF5), promoting active customer participation.Lastly, DP6 fosters co-value creation procedures between manufacturers and customers using inter-organizational data storage (DF4), customer and manufacturer product defect announcements (DF5, DF6), manufacturer-recall-state management (DF7), and backward and forward ownership tracing (DF8).

Reusability of Design Principles
We conducted a qualitative evaluation to check whether experts found the abstracted design principles reusable.We have acquired 10 participants who are experienced in the tracing of securityrelevant products.As a prerequisite, this interviewee should be familiar with cross-location product traceability, as well as the necessary product grading in the context of customers.We interviewed four senior developers with extensive experience in BC-based systems on the technical side.Table 5 contains a description of all 14 interviewed partners.The interviews lasted around one hour each.We followed the propositions for evaluating DSR-based design principles [ 21 ].The authors propose for the evaluation to use criteria accessibility, importance, novelty and insightfulness, agency and guidance, and effectiveness.We asked participants to rate the constructs through several questions on a 5-point Likert scale (1 = strongly disagree, 5 = strongly agree).We conducted the evaluation in combination with an expert interview and an online survey.Figure 7 illustrates the corresponding results.The questionnaire was designed according to the [ 21 ] questionnaire template.
The results show positive feedback from the experts that we show in Figure 7 , and have not resulted in any changes to the formulations.Therefore, we consider the design principles presented in Figure 6 to be ready to use.

DISCUSSION
Traditional enterprise systems continue to be the backbone of the information society and the foundation for developing internal traceability for manufacturers.However, due to their history, traditional enterprise systems like ERP are more suited to vertical than horizontal integration [ 58 ].Another challenge in designing an IS is the creation of accepted standards across enterprise systems and various software providers [ 46 ].A tradeoff can avoid conflicts between different TOE dimensions while combining already implemented and novel technologies.This tradeoff can prevent conflicts and competition between different human perspectives while enabling structured technological innovation decision-making.Following [ 6 , 59 , 60 ], we will discuss the organizational, technical, and environmental dimensions of the ReCoBridger IS below.In each dimension, we pose a research question that can be answered specifically and in collaboration with researchers and practitioners in the future.

Technical Dimension (T)
Data Privacy.Information required for the recall process is persistently stored on the BC and accessible to all actors.Such transparency might enable malicious entities to infer data about recalls associated with specific manufacturers, potentially harming their reputation.It's noteworthy, however, that the BC doesn't retain details about the products (e.g., productID, identifiers); such details are stored solely in the individual manufacturer's enterprise systems.Still, by examining the associated wallets, manufacturers might gain insights about their product users.
Scalability.Performance testing has yet to be conducted, and we haven't delved into the scalability nuances of various BC.Given that our system is tailored for any EVM-enabled BC, its performance and scalability will vary significantly based on the chosen BC for deployment.For instance, deploying on the Ethereum mainnet might lead to anticipated challenges such as elevated transaction fees or extended confirmation durations, rendering scalability on this network financially unviable.However, on a Layer 2 BC or an application-specific BC, scalability is likely to be cost-effective.
RQ: Which features would be required by the IS to reach mass adoption?

Organizational Dimension (O)
Culture and Structure.The provision of concepts and prototypes serves, first and foremost, the open culture of an innovative and cooperative manufacturing company.The ability to test components and reflect ideas firsthand before putting them into productive use provides the opportunity to identify a value for one's own employees (humans) and strategic supply network participants [ 34 ].It offers the chance to get in touch with new technologies that reduce obstacles (e.g., resistance to change) and allow an open dialogue to a redesign of a traditional enterprise system like ERP.Furthermore, because IS are not just technologies but also the outcomes of their designers and users, human integration is essential as it will always be a part of value creation [ 46 ].Our design approach is based on the internal communication procedures of a lean management manufacturing philosophy, whose objective is to identify and provide customer value while establishing simple procedures [ 35 ].We therefore relied on the visual management of internal communication processes which supports decision-making for small, medium, and large businesses.Finally, our findings for conceptualization provide a simpler and less expensive entry point for businesses with limited IT resources, reducing the effort and, thus, the costs of conceptualization and implementation.
RQ: Can communication systems like ReCoBridger change the culture and openness to collaborate?

Environmental Dimension (E)
Industry Characteristics.Standards for monitoring and regulating industries for the usage of permissionless BC-supported IS have not been identified in our study.Our research examined authority guidelines, industry standards, and enterprise provider procedures for conducting recalls.Typical product identifiers like batch or serial numbers serve for the identification of physical assets in many industries and are recommended by authorities for recall processes [ 38 , 39 ].A simple and in the network unique TokenID is not widely used yet.However, it can be linked to the informal communications structure and the products of the manufacturers enterprise systems.This likelihood informal linking structure, not owned by a single authority and implemented in a decentralized manner, addresses transparency concerns of organizations and can increase acceptance of an IS from a manufacturers perspective.
Trading Partners.In the discussion of technological innovation decision-making, the study of [ 8 ] links rivalry and trading partner pressure as relevant latent variables.They are described through items that impress that new technologies are the solution for business processes but hardly show any relation to enterprise systems or BC data.As we demonstrated, traditional enterprise systems already provide basic functionality regarding internal traceability analysis.However, bounded ERP systems do not support a customer-centric co-value creation approach with private customers.As a result, we regard the ReCoBridger IS as an instrument for enabling novel recall processes, such as improved recall communication between trading partners, rather than as a solution.Innovative decision-making, therefore, is not pushed by environmental external pressures.It's rather intended to change currently isolated subsystems into a modern dialogue of co-value creation path between manufacturers and customers.
RQ: How can customers be incentivized to join the co-value creation with the manufacturers?

CONTRIBUTIONS
Our research makes several contributions to the literature.First, we present a conceptualization of a new token standard to the Ethereum request for comment ( ERC ) standard for recall communication, which can potentially improve the efficiency and effectiveness of the recall process.Second, we introduce a new IS that can be used for recall communication, incorporating the proposed token standard and other relevant features.Third, we comprehensively discuss different token standards for recall communication, highlighting their strengths, weaknesses, and extensibility.Fourth, we provide design principles that are highly reusable for practitioners.Fifth, we offer an IS-centered modeling technique to improve coordination efforts.It offers technical and social aspects to holistically capture the complexity of multiple organizations and their IS in supply networks.Sixth, we contribute to the discussion of subsystems and information related to IS artifacts.Finally, we map the requirements of enterprise goods to public ledger software, specifically EVM, to demonstrate the feasibility and practicality of the proposed system.We also add a network design, including organizational and technical aspects, which can be used to implement the proposed system.
Our article makes several contributions to practice.We propose implementing a new token standard that can improve the efficiency of recall communication for enterprise goods.Second, we explore how BC technology can be used to connect enterprises with customers to directly inform and involve them in the recall process, thereby improving communication and collaboration.Customers can thus receive faster and more personalized case-related information (e.g., measures before and after the use or consumption of a product) from multiple manufacturers.Third, we investigate how BC identifiers can be integrated minimally and non-invasively into existing enterprise systems to enable better tracing and monitoring of recalled products.Finally, we reuse the terminology of backward and forward traceability, which involves propagating important recall information from the product user back to the manufacturer.

LIMITATIONS AND OUTLOOK
This research has limitations in five important areas: decentralized management, data privacy, incentives for using the system, special cases, and middleware.First, with the current setup, there is a need for a single orchestrator that helps all involved parties to update their software and set up the smart contracts.Second, data put into the system is publicly available for everyone in realtime, allowing outsiders to gain business intelligence.Third, the system as is does not offer realworld incentives to customers for using the system; More research is needed to design an incentive system.We have not designed the artifact to handle cases like products that have no identification number (e.g., serial number).Software that connects customers wallets with the obtained products is not designed in our artifact.
Future research should extend the scope of the system using a Decentralized Autonomous Organization ( DAO ) that consists of all smart contracts used to issue recall tokens and a registry of all available contracts that manage these tokens.This DAO would allow creators of ecosystem software to better support the recall tokens.Additionally, research should expand the data privacy of the proposed system by investigating the incorporation of Zero-Knowledge proofs and onchain encryption.These approaches would allow for the secure and private sharing of sensitive information between parties.To encourage customer participation, incentives such as token-based rewards or discounts could be investigated.Moreover, our research does not consider cases like joint production and recursive processes, and the middleware and connection of multiple ERP systems are out of this article's scope.We focus on communication between the manufacturer and the customer rather than on the manufacturer's recall management.We acknowledge that customers are responsible for securing their wallets with ReCoBridger.

CONCLUSION
In this study, we investigated innovative approaches to augment existing recall communication processes between manufacturers and end customers by examining the integration potential of traditional technologies, such as ERP systems, with BC and token techniques.We formulated two research questions and utilized an IS Artifact to address these queries.
In the first research question, we investigated strategies to involve customers with manufacturers effectively.We determined that providing customers with access to a wallet enabled them to participate in backward and forward active recalls via interaction with the product and recall states, thus making valuable contributions and supporting manufacturers during recall situations.
In the second research question, we explored the design principles that can facilitate efficient recall communication between customers and manufacturers, supported by an interoperable, integrated ERP-BC-based IS Artifact.Our methodical research approach enabled the development of several design principles, which practitioners have confirmed possess high reusability.
Additionally, we examined how a token-based approach, leveraging our proposed ReCoBridger IS, could enhance recall procedures and foster co-value creation between manufacturers and customers.Through a thorough analysis and extension of existing ERP data models and ERC standards, we demonstrated the feasibility of designing and integrating a token-based approach across multiple organizations, capturing the complexity of inter-organizational perspectives.

Fig. 2 .
Fig. 2. Organizations and enterprise system boundaries in supply networks.

Fig. 6 .
Fig.6.Mapping of design requirements, design principles, and design features.

Table 1 .
Examples and Comparison of Recall Steps

Table 2 .
Existing BC-Based Approaches Supporting Recalls research of this study by introducing the Recall Communication Bridger (ReCoBridger) IS, which we describe in the next section.Table

Table 3 .
Modified (M) Movement Table of a Single ERP System

Table 5 .
Overview of Interviewees