Cited By
View all- Harkonen JGuerrero Rodriguez JMustonen E(2024)The Role of Productization in End-To-End TraceabilityEng10.3390/eng50401535:4(2943-2965)Online publication date: 12-Nov-2024
From Dissonance to Dialogue: A Token-Based Approach to Bridge the Gap Between Manufacturers and Customers
Article No.: 3, Pages 1 - 20
Abstract
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.
1 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].COMP: Please remove the repeated author address section.
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 information-systems (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 inter-organizational 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 of limitations and future research directions that can support the adoption of co-value creation processes between manufacturers and customers.
2 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].
Fig. 1.
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.
3 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].
3.1 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].
Fig. 2.
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).
3.2 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 medium- and 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 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:
Table 1.
| Step1 | Step2 | Step 3 | Step 4 | Step 5 | Step 6 | |
|---|---|---|---|---|---|---|
| Gs1 [19] | Issue Product Recall Notification | Receive Product Recall Notification | Issue Product Removal Confirmation and remove a product | Issue Product Recall Closeout Notification | Receive Product Recall Closeout Notification | Execute Closeout Record internally |
| Enterprise Provider [68] | Problem with a product starting from raw material or customer | Find all the applicable batches | Isolate the bad batch at the lowest level | List all batches together with the locations | Send out a notice of recall, withdrawal, or hold | - |
| Research [11] | Confirmation of defect | Root causes analysis | Risk analysis | Identification and localization of items | Recall | - |
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).
3.3 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 research of this study by introducing the Recall Communication Bridger (ReCoBridger) IS, which we describe in the next section.
Table 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).
Table 2.
| Technical Subsystem | Social Subsystem | |||||
|---|---|---|---|---|---|---|
| Source | Blockchain Type | Technologies used | Enterprise System Integration | Domain | Customer Type and Co-Value Creation | Recall Concepts and Standards |
| [25] | Not discussed | BC, IOT | No | Healthcare | No | Backward and Forward (B/F) |
| [42] | Ethereum Permissionless | SC | No | Automotive | No | B/F |
| [69] | Generic Permissioned | BC, QR, IOT | OOT, OOS, SCM, LMS, ERP | Pharma | Generic Customer | No |
| [1] | Generic Permissioned | SC | No | Pharma | No | B/F |
| [26] | Ethereum Permissionless | IoT, SC, ERC 721 | No | Food | Private Customer | GS1 (GLN) |
| [28] | Ethereum Permissionless | SC | No | Retail | Private Customer | EPCIS, GS1 Recall Standard, B/F |
| [32, 50] | Generic Permissioned | SC | ERP | Generic | Industrial Customer | SCOR Events and Status ‘on hold’ or ‘recalled’ |
| ReCoBridger | EVM Permissionless | SC and ERC 1155 | ERP | Generic | Private Customer | B/F and visual control |
4 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).
4.1 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.
4.1.1 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.
Table 3.
| SCOR Event | ProductID | Identifier | TokenID (M) | Contract (M) | System (M) | Owner=System From/To (M) |
|---|---|---|---|---|---|---|
| Source | Raw-B | 1 | 1 | 0x123 | 1, 2 | USID 2 |
| Raw-D | 2 | |||||
| Raw-C | 3 | 99 | 0x124 | S0 | USID S0 | |
| Make (Merge) | Finish-E | 4 | 1 | 0x123 | 1, 2, S0 | USID 3 |
| Raw-B | 1 | 1 | 0x123 | 1, 2 | USID 3 | |
| Raw-D | 2 | USID 3 | ||||
| Raw-C | 3 | 99 | 0x124 | S0 | USID 3 | |
| Deliver | Finish-E | 4 | 1 | 0x123 | 1, 2, S0, 3 | USID 4 |
Fig. 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.
4.1.2 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.
Fig. 4.
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.
Table 4.
| Standard | Status | Title | Purpose |
|---|---|---|---|
| ERC20 | Final | (Fungible) Token Standard | A standard interface for tokens |
| ERC777 | Final | (Fungible Payment) Token Standard | Defines standard interfaces and behaviors for token contracts |
| ERC721 | Final | Non-Fungible Token Standard | Standard for non-fungible tokens |
| ERC1155 | Final | Multi Token Standard | Multiple tokens in a single contract |
| ERC1363 | Final | Payable Token | Executes code after a transfer or approval |
| ERC725 | Draft | General data/key-value store and execution | Provides an interface for a smart contract-based account with attachable data key/value store |
| ERC884 | Stagnant | DGCL Token | A token that is Delaware General Corporation Law (DGCL)–compliant |
| ERC1337 | Stagnant | Subscriptions on the Blockchain | Monthly subscriptions for decentralized applications |
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.
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 before-mentioned 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).
4.1.3 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.
Fig. 5.
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).
4.2 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.
Fig. 6.
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 (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).
4.3 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 security-relevant 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 detailed description of all 14 interviewed partners. The interviews lasted around one hour each.
Table 5.
| Id | Background and Job Title | Domain |
|---|---|---|
| 1 | Business - Supply Chain and Quality Control | Manufacturing |
| 2 | Business - Quality Control | Manufacturing |
| 3 | Business - Supply Chain | Manufacturing |
| 4 | Business/Technical - Supply Chain and Quality Control | Manufacturing |
| 5 | Business - Supply Chain and Quality Control | Food |
| 6 | Business - ERP Consultant | Food |
| 7 | Technical - Senior ERP Consultant | Food |
| 8 | Business - Supply Chain | Manufacturing |
| 9 | Business – Senior Quality Control | Manufacturing |
| 10 | Business - Quality Control | Manufacturing |
| 11 | Chief Technology Officer | Technology |
| 12 | Senior Software Engineer | Technology |
| 13 | Senior Software Engineer | Technology |
| 14 | Software Engineer | Technology |
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.
Fig. 7.
5 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.
5.1 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?
5.2 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?
5.3 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?
6 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.
7 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 real-time, allowing outsiders to gain business intelligence. Third, the system as is does not offer real-world 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 on-chain 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.
8 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.
References
[1]
Divyansh Agrawal, Sachin Minocha, Suyel Namasudra, and Amir H. Gandomi. 2021. A robust drug recall supply chain management system using hyperledger blockchain ecosystem. Computers in Biology and Medicine 140, C (2021), 105100. DOI:
[2]
Wafaa A. H. Ahmed, Bart L. MacCarthy, and Horst Treiblmaier. 2022. Why, where and how are organizations using blockchain in their supply chains? Motivations, application areas and contingency factors. International Journal of Operations & Production Management 42, 12 (2022), 1995–2028. DOI:
[3]
Arnab Banerjee. 2018. Blockchain technology: Supply chain insights from ERP. In Blockchain Technology: Platforms, Tools and Use Cases, Pethuru Raj and Ganesh Chandra Deka (Eds.). Advances in Computers, Vol. 111. Elsevier, 69–98. DOI:
[4]
Blockscan. 2023. Blockscan Chat: Wallet to Wallet Messaging for Web3. Retrieved from https://web.archive.org/web/20230408220308/https://chat.blockscan.com/start. Accessed 09.04.2023.
[5]
Brave. 2022. Brave Passes 50 Million Monthly Active Users, Growing 2x for the Fifth Year in a Row. Retrieved from https://brave.com/2021-recap/. Accessed 09.04.2023.
[6]
Sutirtha Chatterjee, Suprateek Sarker, Michael J. Lee, Xiao Xiao, and Amany Elbanna. 2021. A possible conceptualization of the information systems (IS) artifact: A general systems theory perspective 1. Information Systems Journal 31, 4 (2021), 550–578. DOI:
[7]
M. J. Cheng and J. E. L. Simmons. 1994. Traceability in manufacturing systems. International Journal of Operations & Production Management 14, 10 (1994), 4–16. DOI:
[8]
Venkataiah Chittipaka, Satish Kumar, Uthayasankar Sivarajah, Jana Lay-Hwa Bowden, and Manish Mohan Baral. 2023. Blockchain technology for supply chains operating in emerging markets: An empirical examination of technology-organization-environment (TOE) framework. Annals of Operations Research 327, 1 (2023), 465–492. DOI:
[9]
European Commission, Directorate-General for Justice, and Consumers. 2022. Safety Gate 2021 Results: Modelling Cooperation for Health and Safety of Consumers in the European Union. Publications Office of the European Union. DOI:
[10]
ConsenSys. 2021. MetaMask Surpasses 21 Million MAUs. Retrieved from https://web.archive.org/web/20230409174426/https://consensys.net/blog/press-release/metamask-surpasses-21-million-maus-as-consensys-raises-200-million-to-make-web3-universally-easy-to-use-access-and-build-on/. Accessed 09.04.2023.
[11]
T. M. L. Diallo, S. Henry, and Y. Ouzrout. 2016. Effective use of food traceability in product recall. In Advances in Food Traceability Techniques and Technologies, Montserrat Espiñeira and Francisco J. Santaclara (Eds.). Elsevier, 263–273. DOI:
[12]
DynamicDocs. 2023. DYNAMICS NAV TABLE RELATIONSHIP DIAGRAMS: Business Central E/R Diagrams for Customized Database/Extensions. Retrieved from https://web.archive.org/web/20230409172618/https://dynamicsdocs.com/. Accessed 09.04.2023.
[13]
Ethereum Foundation. 2023. Ethereum Improvement Proposals. Retrieved from https://eips.ethereum.org/. Accessed 09.04.2023.
[14]
ETHERMAIL. 2023. Reimagining Email for Web3. Retrieved from https://web.archive.org/web/20230409174527/https://ethermail.io/. Accessed 09.04.2023.
[15]
Christian Fleig, Dominik Augenstein, and Alexander Maedche. 2018. Process mining for business process standardization in ERP implementation projects—An SAP S/4 HANA case study from manufacturing. In Proceedings of the International Conference on Business Process Management. 149–155.
[16]
Matt Galligan. 2023. Secure web3 Messaging for Wallet Apps with XMTP. Retrieved from https://web.archive.org/web/20230409174539/https://xmtp.org/blog/secure-web3-wallet-messaging. Accessed 09.04.2023.
[17]
Shirley Gregor, Leona Kruse, and Stefan Seidel. 2020. Research perspectives: The anatomy of a design principle. Journal of the Association for Information Systems 21, 6 (2020), 1622–1652. DOI:
[18]
Gregory Vial. 2021. Understanding digital transformation: A review and a research agenda. In Managing Digital Transformation, Andreas Hinterhuber, Tiziano Vescovi, and Francesca Checchinato (Eds.). Routledge, 13–66. DOI:
[19]
Gs1. 2014. Product Recall. Retrieved from https://web.archive.org/web/20230409173407/https://www.gs1.org/standards/edi-xml-recall/xml-product-recall/3-2. Accessed 09.04.2023.
[20]
Moutaz Haddara, Julie Norveel, and Marius Langseth. 2021. Enterprise systems and blockchain technology: The dormant potentials. Procedia Computer Science 181 (2021), 562–571. DOI:
[21]
Juhani Iivari, Magnus Rotvit Perlt Hansen, and Amir Haj-Bolouri. 2021. A proposal for minimum reusability evaluation of design principles. European Journal of Information Systems 30, 3 (2021), 286–303. DOI:
[22]
Samantha Islam and Jonathan M. Cullen. 2021. Food traceability: A generic theoretical framework. Food Control 123 (2021), 107848. DOI:
[23]
ISO. 2022. ISO/TR 3242:2022: Blockchain and Distributed Ledger Technologies – Use Cases. Retrieved from https://web.archive.org/web/20230409173825/https://www.iso.org/standard/79543.html?browse=tc. Accessed 09.04.2023.
[24]
M. H. Jansen-Vullers, C. A. van Dorp, and A. J. M. Beulens. 2003. Managing traceability information in manufacture. International Journal of Information Management 23, 5 (2003), 395–413. DOI:
[25]
Raja Jayaraman, Fatima AlHammadi, and Mecit Can Emre Simsekler. 2018. Managing product recalls in healthcare supply chain. In Proceedings of the 2018 IEEE International Conference on Industrial Engineering and Engineering Management (IEEM’18). IEEE, 293–297. DOI:
[26]
Mark Kim, Brian Hilton, Zach Burks, and Jordan Reyes. 2018. Integrating blockchain, smart contract-tokens, and IoT to design a food traceability solution. In Proceedings of the 2018 IEEE 9th Annual Information Technology, Electronics and Mobile Communication Conference (IEMCON’18). IEEE, 335–340. DOI:
[27]
Iurii Konovalenko and André Ludwig. 2019. Event processing in supply chain management – The status quo and research outlook. Computers in Industry 105 (2019), 229–249. DOI:
[28]
Satit Kravenkit and Chakchai So-In. 2022. Blockchain-based traceability system for product recall. IEEE Access 10 (2022), 95132–95150. DOI:
[29]
Bill Kuechler and Vijay Vaishnavi. 2008. On theory development in design science research: Anatomy of a research project. European Journal of Information Systems 17, 5 (2008), 489–504. DOI:
[30]
Marlene Kuhn, Felix Funk, Guanlai Zhang, and Jörg Franke. 2021. Blockchain-based application for the traceability of complex assembly structures. Journal of Manufacturing Systems 59 (2021), 617–630. DOI:
[31]
Philipp Lesche, Philipp Sandner, and Horst Treiblmaier. 2022. Implications of the token economy: A taxonomy and research agenda. In Blockchains and the Token Economy. Mary C. Lacity and Horst Treiblmaier (Eds.), Springer International Publishing, Cham, 1–30. DOI:
[32]
Christophe Leske, Andreas Göbel, and Steffen Joswig. 2020. Blockchain Mit SAP (1. auflage ed.). Rheinwerk Verlag, Bonn.
[33]
Lightfoot Law. 2022. FDA Drug Recall Statistics. Retrieved from https://www.lightfootlawdc.com/blogs/fda-drug-recall-statistics/. Accessed 09.04.2023.
[34]
Jeffrey K. Liker. 2021. The Toyota Way: 14 Principles from the World’s Greatest Manufacturer (2nd ed.). McGraw Hill, New York, NY. Retrieved from https://www.accessengineeringlibrary.com/content/book/9781260468519
[35]
Rafael Lorenz, Paul Buess, Julian Macuvele, Thomas Friedli, and Torbjørn H. Netland. 2019. Lean and digitalization—contradictions or complements? Springer, Cham, 77–84. DOI:
[36]
Frederik Möller, Tobias Moritz Guggenberger, and Boris Otto. 2020. Towards a method for design principle development in information systems. In Designing for Digital Transformation. Co-Creating Services with Citizens and Industry. Sara Hofmann, Oliver Müller, and Matti Rossi (Eds.), Lecture Notes in Computer Science, Vol. 12388. Springer International Publishing, Cham, 208–220. DOI:
[37]
Ujjal Kumar Mukherjee and Kingshuk K. Sinha. 2018. Product recall decisions in medical device supply chains: A big data analytic approach to evaluating judgment bias. Production and Operations Management 27, 10 (2018), 1816–1833. DOI:
[38]
Office for Product Safety and Standards. 2022. Product safety risk assessment methodology (PRISM): A guide for GB market surveillance authorities and enforcing authorities responsible for regulating consumer product safety. Retrieved from https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/1128532/prism-guidance-v01A.pdf. Accessed 09.04.2023.
[39]
Official Journal of the European Union. 2004. GUIDELINES for the management of the Community Rapid Information System (RAPEX) and for Notifications Presented Pursuant to Article 11 of Directive 2001/95/EC. Retrieved from https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32004D0418R(01). Accessed 09.04.2023.
[40]
Petter Olsen and Melania Borit. 2018. The components of a food traceability system. Trends in Food Science & Technology 77 (2018), 143–149. DOI:
[41]
Chris A. Ortiz and Murry Park. 2011. Visual Controls: Applying Visual Management to the Factory. CRC Press.
[42]
Pratyush Kumar Patro, Raja Wasim Ahmad, Ibrar Yaqoob, Khaled Salah, and Raja Jayaraman. 2021. Blockchain-based solution for product recall management in the automotive supply chain. IEEE Access 9 (2021), 167756–167775. DOI:
[43]
Ken Peffers, Tuure Tuunanen, Marcus A. Rothenberger, and Samir Chatterjee. 2007. A design science research methodology for information systems research. Journal of Management Information Systems 24, 3 (2007), 45–77. DOI:
[44]
Push. 2023. The Communication Protocol of Web3: Push Protocol. Retrieved from https://web.archive.org/web/20230409174424/https://docs.push.org/developers. Accessed 09.04.2023.
[45]
Norman Pytel, Adrian Hofmann, and Axel Winkelmann. 2020. Tracing back the value stream with colored coins. International Conference on Information Systems (ICIS) 2020 Proceedings, 10. Retrieved from https://aisel.aisnet.org/icis2020/blockchain_fintech/blockchain_fintech/10
[46]
Norman Pytel, Benedikt Putz, Fabian Böhm, and Axel Winkelmann. 2022. Digging for quality management in production systems: A solution space for blockchain collaborations. International Conference on Information Systems (ICIS) 2022 Proceedings, 15. Retrieved from https://aisel.aisnet.org/icis2022/blockchain/blockchain/15/
[47]
Norman Pytel, Christian Zeiß, and Axel Winkelmann. 2023. Enabling UTXO-based backwards and forwards traceabilty. European Conference on Information Systems (ECIS) 2023 Research Papers, 319. Retrieved from https://aisel.aisnet.org/ecis2023_rp/319
[48]
P. Riehmann, M. Hanfler, and B. Froehlich. 2005. Interactive Sankey diagrams. In Proceedings of the IEEE Symposium on Information Visualization, 2005. INFOVIS 2005. IEEE, 233–240. DOI:
[49]
Javier Santos, Richard A. Wysk, and Jose M. Torres. 2014. Improving Production with Lean Thinking. John Wiley & Sons.
[50]
SAP. 2023. Administration Guide for Material Traceability. Retrieved from https://help.sap.com/docs/SAP_LBN_MT_OPTION/d42cfa0f03cf400f8952fff0da9635d2/2b0c3ae006b947f185e0b818bc7e8903.html. Accessed 09.04.2023.
[51]
SAP. 2023. Goods Movement. Retrieved from https://help.sap.com/docs/SAP_CUSTOMER_RELATIONSHIP_MANAGEMENT/29079fe0f6214efa9c974a54e714f418/8e325729f69a47809a1b1d50880b860f.html?version=7.0.4.16&locale=en-US. Accessed 09.04.2023.
[52]
Reuben Schuitemaker and Xun Xu. 2020. Product traceability in manufacturing: A technical review. Procedia CIRP 93 (2020), 700–705. DOI:
[53]
Johannes Sedlmeir, Jonathan Lautenschlager, Gilbert Fridgen, and Nils Urbach. 2022. The transparency challenge of blockchain in organizations. Electronic Markets 32, 3 (2022), 1779–1794. DOI:
[54]
George Siomkos. 1989. Managing product-harm crises. Industrial Crisis Quarterly 3, 1 (1989), 41–60. DOI:
[55]
George J. Siomkos and Gary Kurzbard. 1994. The hidden crisis in product–harm crisis management. European Journal of Marketing 28, 2 (1994), 30–41. DOI:
[56]
Nizar Souiden and Frank Pons. 2009. Product recall crisis management: The impact on manufacturer’s image, consumer loyalty and purchase intention. Journal of Product & Brand Management 18, 2 (2009), 106–114. DOI:
[57]
Yi-fen Su and Chyan Yang. 2010. Why are enterprise resource planning systems indispensable to supply chain management?European Journal of Operational Research 203, 1 (2010), 81–94. DOI:
[58]
Ali Sunyaev, Niclas Kannengießer, Roman Beck, Horst Treiblmaier, Mary Lacity, Johann Kranz, Gilbert Fridgen, Ulli Spankowski, and André Luckow. 2021. Token economy. Business & Information Systems Engineering 63, 4 (2021), 457–478. DOI:
[59]
Stefan Tönnissen and Frank Teuteberg. 2018. Using blockchain technology for business processes in purchasing \(-\) concept and case study-based evidence. In Business Information Systems. Witold Abramowicz and Adrian Paschke (Eds.), Lecture Notes in Business Information Processing, Vol. 320. Springer International Publishing, Cham, 253–264. DOI:
[60]
Louis G. Tornatzky, Mitchell Fleischer, and Alok K. Chakrabarti. 1990. The Processes of Technological Innovation, Lexington Books. Retrieved from https://cir.nii.ac.jp/crid/1130000796720150784
[61]
C. A. van Dorp. 2003. A traceability application based on Gozinto graphs. In Proceedings of the EFITA 2003 Conference. 280–285.
[62]
Jan vom Brocke, Wolfgang Maaß, Peter Buxmann, Alexander Maedche, Jan Marco Leimeister, and Günter Pecht. 2018. Future work and enterprise systems. Business & Information Systems Engineering 60, 4 (2018), 357–366. DOI:
[63]
WalletChat. 2023. Turn Any Dapp Social. Chat Wallet-to-wallet. Retrieved from https://web.archive.org/web/20230409175416/https://www.walletchat.fun/. Accessed 09.04.2023.
[64]
Christian Wankmüller and Gerald Reiner. 2020. Coordination, cooperation and collaboration in relief supply chain management. Journal of Business Economics 90, 2 (2020), 239–276. DOI:
[65]
weclapp GmbH. 2023. weclapp API. Retrieved from https://web.archive.org/web/20230409172901/https://www.weclapp.com/api/. Accessed 09.04.2023.
[66]
Jörg Weking, Michael Mandalenakis, Andreas Hein, Sebastian Hermes, Markus Böhm, and Helmut Krcmar. 2020. The impact of blockchain technology on business models – a taxonomy and archetypal patterns. Electronic Markets 30, 2 (2020), 285–305. DOI:
[67]
Martin Westerkamp, Friedhelm Victor, and Axel Küpper. 2020. Tracing manufacturing processes using blockchain-based token compositions. Digital Communications and Networks 6, 2 (2020), 167–176. DOI:
[68]
Kevin Wilson. 2014. Understanding what SAP Global Batch Traceability Brings to the Table\(\ldots\). Retrieved from https://web.archive.org/web/20230409172415/https://blogs.sap.com/2014/02/18/understanding-what-sap-global-batch-traceability-brings-to-the-table/. Accessed 09.04.2023.
[69]
Xuanping Wu and Yanjun Lin. 2019. Blockchain recall management in pharmaceutical industry. Procedia CIRP 83 (2019), 590–595. DOI:
[70]
M. T. Wynn, C. Ouyang, A. H. M. ter Hofstede, and C. J. Fidge. 2011. Data and process requirements for product recall coordination. Computers in Industry 62, 7 (2011), 776–786. DOI:
[71]
M. Yuan, H. Yeh, and G. Lu. 2011. The development of products traceability for enterprise resource planning system. In Proceedings of the 2011 IEEE 18th International Conference on Industrial Engineering and Engineering Management. IEEE, 475–479. DOI:
Index Terms
- From Dissonance to Dialogue: A Token-Based Approach to Bridge the Gap Between Manufacturers and Customers
Recommendations
Do Promotions Benefit Manufacturers, Retailers, or Both?
Do price promotions generate additional revenue and for whom? Which brand, category, and market conditions influence promotional benefits and their allocation across manufacturers and retailers? To answer these questions, we conduct a large-scale ...
Traveling the token world: A graph analysis of Ethereum ERC20 token ecosystem
WWW '20: Proceedings of The Web Conference 2020The birth of Bitcoin ushered in the era of cryptocurrency, which has now become a financial market attracted extensive attention worldwide. The phenomenon of startups launching Initial Coin Offerings (ICOs) to raise capital led to thousands of tokens ...
Comments
Information & Contributors
Information
Published In
Copyright © 2024 Copyright held by the owner/author(s).
This work is licensed under a Creative Commons Attribution-Share Alike International 4.0 License
Publisher
Association for Computing Machinery
New York, NY, United States
Publication History
Published: 12 March 2024
Online AM: 04 January 2024
Accepted: 08 December 2023
Received: 01 September 2023
Published in TMIS Volume 15, Issue 1
Check for updates
Author Tags
Qualifiers
- Research-article
Contributors
Other Metrics
Bibliometrics & Citations
Bibliometrics
Article Metrics
- View Citations1Total Citations
- 859Total Downloads
- Downloads (Last 12 months)859
- Downloads (Last 6 weeks)124
Reflects downloads up to 12 Nov 2024
Other Metrics
Citations
Cited By
View all- Harkonen JGuerrero Rodriguez JMustonen E(2024)The Role of Productization in End-To-End TraceabilityEng10.3390/eng50401535:4(2943-2965)Online publication date: 12-Nov-2024
View Options
Get Access
Login options
Check if you have access through your login credentials or your institution to get full access on this article.
Sign in