Applying Distributed Ledger Concepts to a Swiss Regional Label Ecosystem

: Improving current supply chains by using distributed ledger technology (DLT) has been a highly researched topic during the last years. Currently, there are numerous articles elaborating on how such technologies can theoretically improve supply chains. However, case studies of such concepts and their economic value are scarce. In order to bridge this gap, we collaborated with a regional label company to clarify how a distributed ledger technology would beneﬁt their ecosystem. This work answers the question of how such a prototype would look and whether it adds value. By following design science research practices, we design two artifacts based on requirements gathered in 14 interviews and discuss the artifacts’ elements within an evaluation panel. Our ﬁndings show that a distributed ledger application for the regional label ecosystem should have an open and decentralized architecture giving all participants full access to the shared data while still providing security and privacy for sensitive data. Additionally, data capturing should be simple. However, such an application does not add su ﬃ cient economic value and is currently of no practical interest in the regional label ecosystem as the expenditure likely exceeds the beneﬁt. us gather better insights into their business processes as well as enabling us to the


Introduction
Knowing how food is produced and knowing the involved parties is gaining more importance for consumers. A recent report, which surveyed US-consumers, points out that they are requesting a high degree of transparency regarding the origin and production process of their food. The report states that more than 90 per cent say that it is important for "manufacturers to provide detailed information about what is in food and how it's made" [1] (p. 2). Moreover, around two-thirds of the surveyed consumers reveal that they would switch from the brand they usually buy to another one, if it provided more information on the product.
To satisfy the consumers' request, many producers inform consumers that their products are produced according to certain standards, by using a certified third-party quality label. Commonly known examples of such quality labels are vegetarian, meaning the products do not consist of animals or any animal parts [2] and fair trade, meaning the production of the product improves the livelihood of producers while respecting the human rights [3]. Generally spoken, such labels are thereby not providing more transparency to consumers but rather more 'trust' by creditably certifying a certain quality trait of a product. Nevertheless, scandals have occasionally occurred, since the quality label's certification process is not always transparent and sometimes vulnerable to fraud. Prominent examples of such events are label scandals in Italy [4], in the US [5] and in Germany [6], where regular food was sold as organic. Other examples are the recall of falsely labelled vegan food in Great Britain [7] and more recently the fraud allegations against products labelled with the Aquaculture Stewardship Council (ASC) label [8].
Meanwhile, distributed ledger technology (DLT) has become well known to provide more supply chain visibility and transparency as shown by Wang et al. [9] and Saberi et al. [10]. This technology was originally developed for the transfer of cryptographic coins, while keeping the degree of security and transparency within the system high [11]. According to Rauchs et al. [12] (p. 12) a distributed ledger can be defined as a multi-party consensus system that allows multiple distrusting parties to reach and maintain agreement on replicated, shared and synchronized data in an adversarial environment without having to rely on a central trusted party. Probably the best-known kind of a distributed ledger is the blockchain, which is why the term 'blockchain' is often used as a synonym. However, as blockchains are only one possible form of distributed ledger designs, we will use in this article the more generic term 'distributed ledger' to describe the above defined multi-party consensus system. Since its invention in the context of cryptocurrencies, the conceptual idea of distributed ledgers has been further developed and applied to many other use cases ranging from the energy sector to the pharma industry to public administration [13]. Although these use cases focus on different economic sectors, they often involve the company's supply chain as the primary subject of interest [14][15][16].
Wang et al. [17] present an overview of recent studies about using DLT for supply chains. Amongst other findings, they state that such applications are expected to add the most value by increasing product visibility and traceability along the supply chain. Nevertheless, to the best of our knowledge, there is only one study exploring the application of DLT for regional label supply chains and its potential benefits within this context [18]. The authors emphasize the potential to improve the efficiency and transparency of regional label ecosystems. However, the question of whether these theoretically stated benefits of a distributed ledger technology can be achieved in practice remains open. Therefore, based on those findings and by using a design science approach, this paper aims to further clarify whether such a value can be realized in practice, and to provide new insights and knowledge about the application of DLT in a business environment. By cooperating with different quality labels certifying regional products in Switzerland, we aim to answer the following research questions (RQ): RQ1: What would a distributed ledger application look like to provide higher efficiency and/or transparency for a Swiss regional label ecosystem? RQ2: Can such a distributed ledger application add value to a Swiss regional label ecosystem in practice by providing higher efficiency and/or transparency?
By answering these research questions, this work contributes in three ways. First, the certification process of regional labels is mapped, and current challenges are identified. Second, we present two different distributed ledger prototypes for facilitating the certification process of regional labels. Third, we elaborate on the necessary conditions for benefiting from such a distributed ledger application, which ultimately leads to new knowledge that can be used to design distributed ledger applications for solving challenges in practice.
The remainder of this paper is structured as follows: First, we conduct a literature review and give an overview of related articles. Second, we explain the design science methodology and how it applies to the research conducted in this paper. Third, we perform an environment analysis of regional labels in Switzerland and present the current process problems. Fourth, we define requirements for an artifact. In a fifth step, we develop two artifacts and apply them to our use case. Afterwards, the evaluation and discussion follow. Lastly, we state the conclusion of our work.

Challenges in Quality Label Supply Chains
Nowadays, supply chains are confronted with multiple challenges, which impede their efficiency. A thorough investigation of such challenges was conducted by Taylor [19]. The analysis concludes that there are three main challenges: First, there are issues related to the physical product flow if the links between the actors are weak. This can lead to over/undersupply, to non-value adding steps or to product waste, due to non-standardization along the chain. Secondly, the information flow is obstructed by the complexity of the supply chain, because of a multiplicity of forecasts, a lack of synchronization, and bad formats for transferring information between adjacent actors. Moreover, Özer and Zheng [20] add that companies do not want to exchange sensitive information since they fear it could be used to their disadvantage. Third, the management and control of the supply chain are difficult as there is no single entity in charge of the whole supply chain and independent decision making can prevent improvement of the supply chain. Furthermore, without a central control it is difficult to create key performance indicators, which would drive improvements [19].
An overview of the specific challenges for the supply chain of an organic label company is given by Keller and Kessler [21]. They state that the physical goods are difficult to trace, since only the financial flow is monitored. Especially during the first mile fraud can happen and non-organic food could be wrongfully labelled as organic. On top of that, there is a lack of international transparency.
Specific challenges for regional label supply chains have only been identified in a paper by Lustenberger et al. [18]. A major challenge is tracing a finished product back to its sources. This lack of transparency on a product level means that only the actors themselves are certified and not the products themselves. Moreover, the information is scattered amongst many heterogeneous actors in regional label supply chains, which makes it difficult to oversee the whole process. This also leads to a lack of coordination, which is further amplified by the fact that the actors often use separate information systems.

Distributed Ledger Applications for Supply Chain Traceability
A systematic literature review on understanding distributed ledger technology (DLT) in supply chains is given in the article [17]. They state that distributed ledgers are expected to add the most value by increasing product visibility and traceability. Another review is presented by Kamilaris et al. [22]. They offer theoretical insights into the impact of DLT on agriculture supply chains, analyze ongoing projects, and conclude that DLT has the potential to make agriculture supply chains more transparent and traceable.
This potential in the agricultural sector has led to the development of a multitude of DLT applications for food supply chains. A rather specific approach on how to improve efficiency and transparency in food supply chains is presented by [23]. The paper proposes a traceability system built on RFID and DLT for an agri-food supply chain. Through the combination of these two technologies it is possible to collect data while producing, processing, warehousing, distributing, and selling a product. At the same time, the data can be shared and validated. This has the benefit that external organizations, such as governments or quality assessors can also check the data. A concrete example is the possibility of monitoring the temperature during transportation. As soon as the temperature is out of the predefined range, a report is created and made visible on the distributed ledger for all participants.
A concrete project of using DLT for labels is called OpenSC, which is a supply chain transparency and traceability platform [24]. The technology stack can be used to certify that a product was produced according to environmental, social, safety, or other quality standards. In an example they demonstrate how in combination with Internet of Things (IoT) a distributed ledger is able to track wood and record its location, temperature, and exposure to light. During the whole process, the data is securely and tamper-proof stored on the distributed ledger.
A further example of using DLT for organic food companies is presented in the paper by Keller and Kessler [21]. They approach the identified challenges with a distributed ledger platform guaranteeing the traceability of certified products. The platform also serves as a trading platform. However, the authors conclude that such an approach makes little sense for a single label company, since the identified problems could theoretically be solved by a traditional centralized approach with the label itself as the central trusted third party.
A recently published study by Stiller et al. [25] examines the tracking of dairy products in Switzerland. They argue that if a company wants to add value to its products by using a DLT to label milk as 'Swiss made', the standards of the Swiss milk must be different from those in other countries. Such an additional standard could be represented by 'sustainability'. If such a differentiation is given, then distributed technologies such as DLT could improve and create transparency between the actors.

Design Science
Our paper follows the general design science research (DSR) approach to build and apply designed artifacts in practice with the aim to produce knowledge that can be used for solving specific practical challenges [26,27]. According to Hevner et al. [27] the DSR framework consists of three different pillars. The first pillar represents the Information System (IS) research, which is performed by conducting behavioral science and design science research. Behavioral science develops theories and justifies them, whereas design science builds an artifact and evaluates it. Such an artifact can be classified into the four broad categories of construct, model, method or instantiation. Their assessment offers better insights and leads to a new refinement, which is often shown as a future research possibility. The final goal of IS research is the application of the results in the appropriate environment and to contribute to the knowledge base.
However, IS research can only be performed if a business need is given by the environment [28]. Therefore, the second pillar of DSR is the business environment. The environment consists of the people within the organization, the organization itself, and the technology. The people need to be identified and their roles and capabilities must be stated. They affect the environment by perceiving opportunities and challenges and acting according to them. The organization itself delivers the needed context and defines the scope of the environment. The technology plays a major role, because the two previous subcategories are positioned according to current technology, infrastructure, and communication architecture.
The last pillar of DSR is the knowledge base. It is used to demonstrate the rigor of the research. It offers the researcher an artifact type to conduct IS research. Furthermore, a research methodology is drawn from the knowledge base. It defines critical points such as the data analysis technique and the data measurement.

Application of Design Science Research
Our research approach can be divided into five steps as shown in Figure 1. First, we conducted an initial literature review following the principle of Okoli and Schabram [29], while keeping in mind the recommendations by vom Brocke et al. [30]. We used a keyword search on EBSCO, ScienceDirect, and Google Scholar. Moreover, we applied forward and backward search to expand the number of articles. Through a synthesis of the literature it was then possible to capture a snapshot of the current state of research. The literature review was followed by the organization's environment analysis. In order to understand the environment, we conducted 14 semi-structured interviews [31] with different stakeholders of the regional label ecosystem in Switzerland (5 producers, 3 regional labels, 3 umbrella organizations, 2 certifiers and 1 retailer) and defined the actors and their roles. To conduct the interviews, we developed an interview guideline as shown in Appendix A. The analysis of the semi-structured interviews followed the guidelines set by Mayring [32]. In a first step we summarized the most important statements from the recorded interviews, which afterwards were categorized in a second step into process descriptions, problem-statements, and requirements for a potential application. In a third step, based on the process descriptions, we could then model the different processes by using the BPMN 2.0 standard [33]. The resulting ecosystem and process maps were reviewed by the interview partners and their suggestions for improvement were adopted. In a fourth step, we derived from the problem-statements the specific problems of the current certification process. In a fifth step, we used some of the interviews (with three producers, three regional labels, the umbrella organization, and the certifier) to derive requirements for an information system. The elicitation of requirements was conducted in accordance with the article published by Nuseibeh and Easterbrook [34]. After having defined the requirements, we searched for Swiss distributed ledger concepts for traceability in general supply chains, since no specific regional label solution existed. We found four suitable distributed ledger concepts within Switzerland and after a first short evaluation we selected two of them for further evaluation. We contacted the developers and asked them if they can adapt their concepts to our specific case. The outcome of the adaptations represents the IT artifacts for our research in the form of models according to Hevner et al. [27]. Asking the creators to build the artifacts is beneficial since it offers a high accuracy while avoiding misunderstandings. Next, each IT artifact was presented at a workshop held on 28 January 2020. An evaluation panel consisting of the two concept creators, six DLT experts, and three regional label ecosystem stakeholders as application users evaluated each artifact through a questionnaire. After analyzing the questionnaires, we assessed-based on the approach proposed by Liamputtong [35]-together with the involved stakeholders, whether the proposed IT artifacts can solve the current challenges in the certification process and add value in practice. Based on the evaluation and discussion of the two artifacts, we could then derive further insights and knowledge about the design and the application of DLT solutions within a specific environmental context.

Stakeholders
The primary subject of interest for this study is the regional label ecosystem. Its structure is depicted in Figure 2. The umbrella organization is at the highest level of the hierarchy. It has fifteen regional labels as its members. Each member operates within a different geographic part of Switzerland. Their main business process consists of certifying products of producers (e.g., farmers) as regional, which is defined as at least 80% of the ingredients and at least two-thirds of the generated value of any certified product coming from the declared geographic region. Any certification will be assessed and regularly reassessed by an independent certification body. The certification is used to increase the value of the product by communicating to the consumer that it is produced regionally and complies with certain additional predefined rules and standards (e.g., higher animal breeding standards). The umbrella organization's as well as the regional labels' source of income is the producers, who pay a certain amount to be certified. Additionally, they also receive governmental funds for regional development. After having defined the requirements, we searched for Swiss distributed ledger concepts for traceability in general supply chains, since no specific regional label solution existed. We found four suitable distributed ledger concepts within Switzerland and after a first short evaluation we selected two of them for further evaluation. We contacted the developers and asked them if they can adapt their concepts to our specific case. The outcome of the adaptations represents the IT artifacts for our research in the form of models according to Hevner et al. [27]. Asking the creators to build the artifacts is beneficial since it offers a high accuracy while avoiding misunderstandings. Next, each IT artifact was presented at a workshop held on 28 January 2020. An evaluation panel consisting of the two concept creators, six DLT experts, and three regional label ecosystem stakeholders as application users evaluated each artifact through a questionnaire. After analyzing the questionnaires, we assessed-based on the approach proposed by Liamputtong [35]-together with the involved stakeholders, whether the proposed IT artifacts can solve the current challenges in the certification process and add value in practice. Based on the evaluation and discussion of the two artifacts, we could then derive further insights and knowledge about the design and the application of DLT solutions within a specific environmental context.

Stakeholders
The primary subject of interest for this study is the regional label ecosystem. Its structure is depicted in Figure 2. The umbrella organization is at the highest level of the hierarchy. It has fifteen regional labels as its members. Each member operates within a different geographic part of Switzerland. Their main business process consists of certifying products of producers (e.g., farmers) as regional, which is defined as at least 80% of the ingredients and at least two-thirds of the generated value of any certified product coming from the declared geographic region. Any certification will be assessed and regularly reassessed by an independent certification body. The certification is used to increase the value of the product by communicating to the consumer that it is produced regionally and complies with certain additional predefined rules and standards (e.g., higher animal breeding standards). The umbrella organization's as well as the regional labels' source of income is the producers, who pay a certain amount to be certified. Additionally, they also receive governmental funds for regional development.
Logistics 2020, 4, x FOR PEER REVIEW 6 of 18 Figure 2. The regional label ecosystem consists of an umbrella organization, regional labels, producers, and a certification body.

Certification Process
A simplified certification process is shown in Figure 3. The process starts with the regional labels acquiring a producer as a new customer. Then the producer has to fill out up to eight registration documents and save them in his database. Since a signature and additional information of the producer's suppliers are needed, the producer has to transmit the documents (often via e-mail) to them. Transferring and signing documents are normally done physically; therefore, documents are often saved physically, then signed, and scanned again.
After signing the documents, the suppliers save a copy and send the original document back to the producer. The producer saves the new documents. Later, the documents are sent to the corresponding regional label for checking. If something is faulty, the documents are either sent back to the producer, and amendments are demanded, or they try to clarify the issues with the umbrella organization. If the documents are valid, the regional label signs them and scans the documents to store them in its database. The documents are delivered by mail or e-mail to the umbrella organization. There, the documents are signed and saved to the respective database. After completion, they are sent back to the corresponding regional label so it can be controlled for completeness. Afterwards they include an updated version of the documents in their own database. Then they transmit the latest version to the external certifier responsible for the audit to check whether the requirements are met by the producer. However, before the certifier can initiate the audit process, he checks all documents and saves them in his local database. Only then, if all these steps are performed correctly, does the certifier undertake the audit on the producer site and sends the final audit report together with the signed documents to all the other participants. Consequently, everybody updates their local database one more time.
For the on-site audit, the certifier arranges an appointment with the producer. The certifier checks the invoices and delivery notes of the producer's suppliers in order to assure that all ingredients are regional. Besides that, the production processes are checked to verify that a mix-up with non-compliant raw materials can be excluded.
In the whole process, standard Microsoft Office tools are used by all parties. The umbrella organization emphasized that they rely on Excel for calculations, as well as for defining recipes for complex goods. For data sharing, Dropbox and WeTransfer are often being mentioned. However, Figure 2. The regional label ecosystem consists of an umbrella organization, regional labels, producers, and a certification body.

Certification Process
A simplified certification process is shown in Figure 3. The process starts with the regional labels acquiring a producer as a new customer. Then the producer has to fill out up to eight registration documents and save them in his database. Since a signature and additional information of the producer's suppliers are needed, the producer has to transmit the documents (often via e-mail) to them. Transferring and signing documents are normally done physically; therefore, documents are often saved physically, then signed, and scanned again.
Logistics 2020, 4, x FOR PEER REVIEW 7 of 18 these tools are normally used for intra-company communication. Additionally, the umbrella organization stated that they use AdobePro to edit documents.

Current Problems
The certification and audit process offer insight into various challenges. The certification involves cumbersome multi-step communication. The communication paths lead from point to point through the entire process chain. This renders high throughput times of the entire process and After signing the documents, the suppliers save a copy and send the original document back to the producer. The producer saves the new documents. Later, the documents are sent to the corresponding regional label for checking. If something is faulty, the documents are either sent back to the producer, and amendments are demanded, or they try to clarify the issues with the umbrella organization. If the documents are valid, the regional label signs them and scans the documents to store them in its database. The documents are delivered by mail or e-mail to the umbrella organization. There, the documents are signed and saved to the respective database. After completion, they are sent back to the corresponding regional label so it can be controlled for completeness. Afterwards they include an updated version of the documents in their own database. Then they transmit the latest version to the external certifier responsible for the audit to check whether the requirements are met by the producer. However, before the certifier can initiate the audit process, he checks all documents and saves them in his local database. Only then, if all these steps are performed correctly, does the certifier undertake the audit on the producer site and sends the final audit report together with the signed documents to all the other participants. Consequently, everybody updates their local database one more time.
For the on-site audit, the certifier arranges an appointment with the producer. The certifier checks the invoices and delivery notes of the producer's suppliers in order to assure that all ingredients are regional. Besides that, the production processes are checked to verify that a mix-up with non-compliant raw materials can be excluded.
In the whole process, standard Microsoft Office tools are used by all parties. The umbrella organization emphasized that they rely on Excel for calculations, as well as for defining recipes for complex goods. For data sharing, Dropbox and WeTransfer are often being mentioned. However, these tools are normally used for intra-company communication. Additionally, the umbrella organization stated that they use AdobePro to edit documents.

Current Problems
The certification and audit process offer insight into various challenges. The certification involves cumbersome multi-step communication. The communication paths lead from point to point through the entire process chain. This renders high throughput times of the entire process and producers need to wait for a long time until being awarded the label. Moreover, this communication process is quite static and does not quickly adapt to changes. If the state of a document changes, it has to be communicated to all participants.
Furthermore, the lack of transparency and traceability of the products and the certification process influence the consumers as well as the participants in the supply chain. On one hand, the consumers are not able to understand easily how the label on a product translates to quality standards. They would first have to read all the guidelines on the internet to understand the process. On the other hand, they are not able to trace the product on their own and have to rely on the promise of the regional label and the diligence of the involved actors. The producers are affected by the lack of transparency as well. It has become apparent that the effort for a small business to check the origin of the raw materials is high. The producers do not influence the suppliers' suppliers and need therefore to trust in the declaration of their direct suppliers.
In addition, however, the data and information saving practices by the actors are challenging. The process model explicitly shows that the certifier, the umbrella organization, the regional labels, the producers and all the suppliers maintain their separate databases and save the documents differently (e.g., digitally or physically). With these practices it takes more time to find documents than usual. The on-site audit process becomes especially inefficient, because the producers gather all the documents, print them, put them into a folder and the certifier goes then through each document. The transparency and traceability suffer from these information silos since no overarching framework is available. What is more, these redundant storages pose a high threat of creating inconsistencies within the ecosystem.
Lastly, there are no standards for the files. This aspect is two-fold. On one hand, there is no standard on how to store the files. Currently, they are either being printed out or saved electronically (or a combination of both). On the other hand, the standard on how to structure the documents can be improved as well. Although there is a form for the certification and the audit process, there is still a lack of standardization for documents. These variations can lead to confusion and increase the process complexity.

Requirements Engineering
Based on the work by Myers [31] and Nuseibeh [34] we extract requirements from the conducted interviews with the producers, regional labels, the umbrella organization, and the certifier. In the interviews, we asked the stakeholder the following question: "What must a digital certification application be able to do?". For the umbrella organization it is important that the introduction of the new application is accompanied by the application providers since new IT-systems can be overwhelming for the producers. Moreover, it became clear that the application should be simple and unify all the processes.
The regional labels desire an application that can reduce redundancies. Currently, many steps such as signing and sending papers during the certification process are done multiple times. Furthermore, it was mentioned that it is difficult to trace the product along the supply chain. While offering traceability, the application should also integrate all the involved actors. The regional labels emphasized the need for a simple application, meaning that the user interface (UI) should be customer-friendly, and it should provide an efficient method of data input. Additionally, one regional label mentioned that there should be a certain degree of privacy since they do not want to offer insights on critical business processes. Security is also one of the regional labels' demands since they do not want any sensitive data to be leaked.
The producers pointed out that a new application must make the current audit process more economical. They think that it is sufficient that only one certifier does the audit (instead of two) and that the recertification process could happen fewer times. They also indicated that the application should offer the ability to trace the products since this would reduce their workload during the certification process. Moreover, they raised concerns about a too complicated application and therefore simplicity was yet again named. Lastly, the producers stated that they want a high degree of privacy and security as well. The certifier stated that they require a guaranteed and credible traceability.
In conclusion, as shown in Figure 4, we could derive eight requirements from the evaluation of the interviews. The four requirements 'redundancy reduction' (R1), 'traceability of products' (R2), 'unification of all parties' (R3) and 'reduction of costs' (R4) can be directly related to the identified problems within the certification process. Whereas the four requirements 'simplicity' (R5), 'easy data capturing' (R6), 'privacy' (R7) and 'security' (R8) are more general requirements for a new IT solution not directly related to the current issues, but still mentioned in the interviews. These requirements serve as a basis for evaluating the artifacts presented in the next section. be improved as well. Although there is a form for the certification and the audit process, there is still a lack of standardization for documents. These variations can lead to confusion and increase the process complexity.

Requirements Engineering
Based on the work by Myers [31] and Nuseibeh [34] we extract requirements from the conducted interviews with the producers, regional labels, the umbrella organization, and the certifier. In the interviews, we asked the stakeholder the following question: "What must a digital certification application be able to do?". For the umbrella organization it is important that the introduction of the new application is accompanied by the application providers since new IT-systems can be overwhelming for the producers. Moreover, it became clear that the application should be simple and unify all the processes.
The regional labels desire an application that can reduce redundancies. Currently, many steps such as signing and sending papers during the certification process are done multiple times. Furthermore, it was mentioned that it is difficult to trace the product along the supply chain. While offering traceability, the application should also integrate all the involved actors. The regional labels emphasized the need for a simple application, meaning that the user interface (UI) should be customer-friendly, and it should provide an efficient method of data input. Additionally, one regional label mentioned that there should be a certain degree of privacy since they do not want to offer insights on critical business processes. Security is also one of the regional labels' demands since they do not want any sensitive data to be leaked.
The producers pointed out that a new application must make the current audit process more economical. They think that it is sufficient that only one certifier does the audit (instead of two) and that the recertification process could happen fewer times. They also indicated that the application should offer the ability to trace the products since this would reduce their workload during the certification process. Moreover, they raised concerns about a too complicated application and therefore simplicity was yet again named. Lastly, the producers stated that they want a high degree of privacy and security as well. The certifier stated that they require a guaranteed and credible traceability.
In conclusion, as shown in Figure 4, we could derive eight requirements from the evaluation of the interviews. The four requirements 'redundancy reduction' (R1), 'traceability of products' (R2), 'unification of all parties' (R3) and 'reduction of costs' (R4) can be directly related to the identified problems within the certification process. Whereas the four requirements 'simplicity' (R5), 'easy data capturing' (R6), 'privacy' (R7) and 'security' (R8) are more general requirements for a new IT solution not directly related to the current issues, but still mentioned in the interviews. These requirements serve as a basis for evaluating the artifacts presented in the next section.

Ethereum-Based Artifact
The first artifact is based on a client-server architecture, as shown in Figure 5. A database (in this case NEO4J), a graph index manager, and the synchronization service together form a node. The nodes have direct access to the Ethereum distributed ledger [36] and the InterPlanetary File System

Ethereum-Based Artifact
The first artifact is based on a client-server architecture, as shown in Figure 5. A database (in this case NEO4J), a graph index manager, and the synchronization service together form a node. The nodes have direct access to the Ethereum distributed ledger [36] and the InterPlanetary File System (IPFS) [37]. A node is able to create acyclic graphs and to save them on the distributed ledger. Web clients can access the Ethereum distributed ledger by using the remote interface. Based on that basic architecture, a specific application for our use case would have the goal of offering a faster and traceable (R2) process. The focus would also be on redundancy reduction (R1) and the unification of all the stakeholders (R3). The realization of those goals happens by replacing the physical signatures currently used through digital ones and by exchanging documents over IPFS.
Logistics 2020, 4, x FOR PEER REVIEW 9 of 18 (IPFS) [37]. A node is able to create acyclic graphs and to save them on the distributed ledger. Web clients can access the Ethereum distributed ledger by using the remote interface. Based on that basic architecture, a specific application for our use case would have the goal of offering a faster and traceable (R2) process. The focus would also be on redundancy reduction (R1) and the unification of all the stakeholders (R3). The realization of those goals happens by replacing the physical signatures currently used through digital ones and by exchanging documents over IPFS. The proposed architecture could be applied to our use case as follows: Full clients (e.g., some regional labels, certifier, umbrella organization) can be compared as full nodes in a distributed ledger network. They participate in the validation process, communicate to the peers and store all the validated transactions. On the other hand, simple clients (producers, consumers) access the network over full clients. Thereby, they do not have to have a lot of computational power, but still benefit from the DLT solution. On the network side we have two public networks. The Ethereum distributed ledger is used for verification purposes. The other network is a distributed database system (i.e., IPFS) in order to store the documents. Lastly, documents will be stored in the form of acyclic graphs on the distributed ledger and IPFS.
The workflow, depicted in Figure 6, begins with the producer registering for the labeling process (1). The registration form would be represented through a step by step guide. As soon as the producer uploads all the needed documents, a smart contract is created for the suppliers (2). Then, the suppliers have to upload their documents and sign everything (3). This then goes back to the registration form (4), which creates another smart contract for the agreement (5). The regional label and the umbrella organization check whether all the documents fulfill the requirements and if so, they sign the documents as well (6). By signing the documents, the producer has the proof of fulfilling the requirements and has the right to call the certifier for the audit. The proposed architecture could be applied to our use case as follows: Full clients (e.g., some regional labels, certifier, umbrella organization) can be compared as full nodes in a distributed ledger network. They participate in the validation process, communicate to the peers and store all the validated transactions. On the other hand, simple clients (producers, consumers) access the network over full clients. Thereby, they do not have to have a lot of computational power, but still benefit from the DLT solution. On the network side we have two public networks. The Ethereum distributed ledger is used for verification purposes. The other network is a distributed database system (i.e., IPFS) in order to store the documents. Lastly, documents will be stored in the form of acyclic graphs on the distributed ledger and IPFS.
The workflow, depicted in Figure 6, begins with the producer registering for the labeling process (1). The registration form would be represented through a step by step guide. As soon as the producer uploads all the needed documents, a smart contract is created for the suppliers (2). Then, the suppliers have to upload their documents and sign everything (3). This then goes back to the registration form (4), which creates another smart contract for the agreement (5). The regional label and the umbrella organization check whether all the documents fulfill the requirements and if so, they sign the documents as well (6). By signing the documents, the producer has the proof of fulfilling the requirements and has the right to call the certifier for the audit.

SupplyTree Artifact
The work of Guenther and Woerner [38] introduces the concept of SupplyTrees. The authors propose to use a federated system, instead of using a fully distributed system to keep track of the data within a supply chain. They point out that the characteristics of a distributed ledger such as auditability and immutability can still be achieved, while providing a better scaling behavior. In Figure 7 we demonstrate how such SupplyTrees work. Companies are represented through node objects N on a certain tier X. The data objects D flow from tier to tier, until the finished product reaches the root node RN. To guarantee the confidentiality and integrity of data objects, they are being hashed h(D). Later, the hash h(D) is added to the node object N in the current tier. Then a hash of the node object h(N) is created and sent to the next tier. This process is done until the final hash reaches the root node.
If the root node RN wants to trace a product's supply chain, it requests the node object content from the previous tier X-1. Afterwards, it hashes the content and compares the hashes. If there is a match, the node object content of the tier X-2 is requested and the process continues. Based on that architecture, a specific adoption to our case would have the main goal of guarantying traceability (R2) within the certification process. This would additionally require that

SupplyTree Artifact
The work of Guenther and Woerner [38] introduces the concept of SupplyTrees. The authors propose to use a federated system, instead of using a fully distributed system to keep track of the data within a supply chain. They point out that the characteristics of a distributed ledger such as auditability and immutability can still be achieved, while providing a better scaling behavior. In Figure 7 we demonstrate how such SupplyTrees work. Companies are represented through node objects N on a certain tier X. The data objects D flow from tier to tier, until the finished product reaches the root node RN. To guarantee the confidentiality and integrity of data objects, they are being hashed h(D). Later, the hash h(D) is added to the node object N in the current tier. Then a hash of the node object h(N) is created and sent to the next tier. This process is done until the final hash reaches the root node.
Logistics 2020, 4, x FOR PEER REVIEW 10 of 18 Figure 6. The workflow of the certification process in the Ethereum-based artifact.

SupplyTree Artifact
The work of Guenther and Woerner [38] introduces the concept of SupplyTrees. The authors propose to use a federated system, instead of using a fully distributed system to keep track of the data within a supply chain. They point out that the characteristics of a distributed ledger such as auditability and immutability can still be achieved, while providing a better scaling behavior. In Figure 7 we demonstrate how such SupplyTrees work. Companies are represented through node objects N on a certain tier X. The data objects D flow from tier to tier, until the finished product reaches the root node RN. To guarantee the confidentiality and integrity of data objects, they are being hashed h(D). Later, the hash h(D) is added to the node object N in the current tier. Then a hash of the node object h(N) is created and sent to the next tier. This process is done until the final hash reaches the root node.
If the root node RN wants to trace a product's supply chain, it requests the node object content from the previous tier X-1. Afterwards, it hashes the content and compares the hashes. If there is a match, the node object content of the tier X-2 is requested and the process continues. Based on that architecture, a specific adoption to our case would have the main goal of guarantying traceability (R2) within the certification process. This would additionally require that If the root node RN wants to trace a product's supply chain, it requests the node object content from the previous tier X-1. Afterwards, it hashes the content and compares the hashes. If there is a match, the node object content of the tier X-2 is requested and the process continues.
Based on that architecture, a specific adoption to our case would have the main goal of guarantying traceability (R2) within the certification process. This would additionally require that self-sovereign identities are established and that the nodes are capable of creating digital signatures. In contrary to the previous artifact, traceability would only be obtained if one entity requests it. Without a request of an entity and the permissions of the previous tier, traceability is not possible. Thereby, a high degree of privacy (R7) is achieved. Moreover, this artifact focuses on reducing process costs due to a lightweight implementation (R4). Figure 8 shows the adaption of SupplyTree to the regional label ecosystem.
self-sovereign identities are established and that the nodes are capable of creating digital signatures. In contrary to the previous artifact, traceability would only be obtained if one entity requests it. Without a request of an entity and the permissions of the previous tier, traceability is not possible. Thereby, a high degree of privacy (R7) is achieved. Moreover, this artifact focuses on reducing process costs due to a lightweight implementation (R4). Figure 8 shows the adaption of SupplyTree to the regional label ecosystem. Our exemplary use case focuses on the production of cheese, where multiple actors are involved. Prerequisites are that each of those actors in the supply chain must own a web server and a database. Moreover, each participant creates a self-sovereign identity and defines publicly and privately available data. Each participant hashes the data and the node object and sends it to the cheese producer. Additionally, the hash is saved on the web server. Digital signatures are used to establish authenticity.
Later, the producer includes each hash in his node, adds additional data, hashes everything and puts it on his web server. The activity of hosting the servers could be done by the regional label. The final product receives a QR-code, which creates a link to the corresponding web server. If customers want to trace the product, they can ask the producer to hand over the data in the node object. Next, they can hash and compare the hash output to the initial value.

Evaluation
During a workshop, the two concept creators, six DLT experts, and three regional label ecosystem stakeholders (two representatives from two different regional labels and one representative from the umbrella company) evaluated with a questionnaire if the two designed artifacts satisfy the requirements. Each artifact was presented by the respective creator and afterwards the participants directly wrote down whether the artifact fulfills the stated requirements. We asked specifically for each requirement, except for privacy (R7) and security (R8), since those are given by the nature of a distributed ledger. The results of the questionnaire are shown in the second Data Flow of Objects D Hash pointer Our exemplary use case focuses on the production of cheese, where multiple actors are involved. Prerequisites are that each of those actors in the supply chain must own a web server and a database. Moreover, each participant creates a self-sovereign identity and defines publicly and privately available data. Each participant hashes the data and the node object and sends it to the cheese producer. Additionally, the hash is saved on the web server. Digital signatures are used to establish authenticity.
Later, the producer includes each hash in his node, adds additional data, hashes everything and puts it on his web server. The activity of hosting the servers could be done by the regional label. The final product receives a QR-code, which creates a link to the corresponding web server. If customers want to trace the product, they can ask the producer to hand over the data in the node object. Next, they can hash and compare the hash output to the initial value.

Evaluation
During a workshop, the two concept creators, six DLT experts, and three regional label ecosystem stakeholders (two representatives from two different regional labels and one representative from the umbrella company) evaluated with a questionnaire if the two designed artifacts satisfy the requirements. Each artifact was presented by the respective creator and afterwards the participants directly wrote down whether the artifact fulfills the stated requirements. We asked specifically for each requirement, except for privacy (R7) and security (R8), since those are given by the nature of a distributed ledger. The results of the questionnaire are shown in the second and third column of Table 1. The evaluation showed that all participants agree that the Ethereum-based artifact would reduce redundancies (R1) and would integrate all involved actors (R3), whereas the SupplyTree artifact profited from the fact that a UI was already developed and presented. This allowed the less IT-affine participants to see what a prototype version would look like. Therefore, in comparison to the other results, the results regarding the perception of the simplicity of the application (R5) and data capturing (R6) were perceived better compared to the Ethereum-based artifact. Nevertheless, the questionnaire clearly demonstrated that most participants were not able to accurately evaluate whether the proposed artifacts fulfill the requirement of traceability (R2) and reduction in costs (R4) based upon the presentations. Therefore, the requirements were further assessed during a discussion within the evaluation panel following the presentations. The aim of the open discussion was to understand better how the designed and presented DLT solutions fulfill the specified requirements. To visualize the outcome of this discussion, we show the elements of each artifact corresponding to the respective requirement in the same Table 1.
In the discussion about the Ethereum-based artifact it became again visible that for most participants the advantage of this artifact is the elimination of redundancies (R1) since the Ethereum distributed ledger allows the implementation of smart contracts and the IPFS data system provides a single point of truth. Additionally, it allows the unification of all parties (R3) as all stakeholders are either full or simple clients in the distributed network. However, when it comes to traceability (R2), reduction of costs (R4), simplicity (R5) and easy data capturing (R6) many of the regional label ecosystem stakeholders could not provide a clear statement. Due to the high complexity of the distributed systems, it became obvious that for them it was difficult to understand how traceability (R2) is achieved, how costs are reduced (R4), how simplicity (R5) would be guaranteed and how data is captured (R6). That is why they abstained the vote on those four points. The concept creators and the DLT experts within the evaluation panel agreed that traceability (R2) was achieved because Ethereum offers a fully distributed ledger providing transparency and immutability. However, they were split over the simplicity (R5) of the application, since a UI for the web client could be developed later. Consequently, whether easy data capturing (R6) could be achieved depends strongly on the realization of the UI. The requirement regarding the reduction in costs (R4) received mixed feedback as well. Even though the majority of the entire evaluation panel agreed on the improved speed of the processes, many are concerned about the costs of developing and operating such an Ethereum-based application. The last two requirements of privacy (R7) and security (R8) were assessed only by the concept creators and the DLT experts. The regional label ecosystem stakeholders were purposefully excluded, since they already stated at the beginning of the workshop that they cannot make accurate estimations. The concept creators and DLT experts concluded that privacy (R7) can be achieved, since encryption algorithms are used and since there is an individual NEO4J database for each node. This would be sufficient to, e.g., guarantee the secrecy of critical business processes. Regarding the last requirement concerning the security (R8) the creators and the experts concluded that this is given as well, due to the nature of distributed ledgers.
The discussion regarding the designed SupplyTree artifact was mainly focused on the already existing UI and the inability of creating traceability (R2) within the ecosystem. The UI showed everybody how simple such an application could be (R5) and that the capturing of data happens easily (R6). In contrast to the Ethereum-based artifact, the DLT experts and concept creators agreed that traceability (R2) cannot be achieved to the same extent due to the artifact's architecture. Since it is a linked list, the data is only visible to the consumers if it is explicitly demanded by them. Otherwise, the data remains with the nodes. Therefore, the proposed artifact is dependent on the cooperation of all nodes. If that is not the case, then tracing is not possible. The evaluation panel further stated that the SupplyTree reduces redundancies (R1) due to the shared infrastructure and the standardized processes. This shared infrastructure also unifies the involved parties (R3). However, in contrast to the Ethereum-based artifact the unification happens to a smaller degree, since the actors can by default not see the entire supply chain, but only adjacent actors. Furthermore, it was agreed that the SupplyTree artifact can reduce the costs (R4), because the process gets optimized and there are no transaction costs involved. Lastly, the DLT experts and concept creators agreed that privacy (R7) is achieved due to the fact that there are no shared databases and data are stored individually. Moreover, security (R8) is also given since the architecture relies on the utilization of hash pointers.
The participants concluded that if the evaluation is corrected for the UI-factor, the outcome is in favor of the designed Ethereum-based artifact. The main reason for correcting the evaluation is the fact that the UI can be developed at a later point in time. Additionally, the discussion brought to light the fact that the fully distributed and completely decentralized system of the Ethereum-based artifact fulfills the requirement traceability (R2) and unification (R3) better. The better results of the SupplyTree artifact regarding the requirements simplicity (R5) and easy data capturing (R6) were caused by the presented UI.
During the open discussion, the value of a distributed ledger application for the regional label ecosystem was generally questioned. The group discussion raised the following four concerns: First, all parties involved in the certification process already have a high trust in each other, which implies that a much simpler file sharing application provided by any centralized third party could be a more efficient and effective solution. Second, a short benchmark with two other regional label ecosystems from other regions in Switzerland revealed that they only need two parties to check and sign all required documents for the same certification process, which makes their process by design much more efficient. Third, while conducting our interviews with the stakeholders as well as during the workshop discussion, we could not find any evidence that consumers would be willing to pay more or to buy more of a labeled product just because its origin and production steps are traceable. This consideration goes along with the findings of [25], where the authors conclude that the consumers do not see a benefit of using a QR code to receive more information about the Swiss milk supply chain. Fourth, in the current certification process neither the producers nor the regional labels are required to provide an extensive track and trace of all their raw materials and production steps. A short statement signed by all involved parties, covered by the correct delivery notes and invoices is currently enough to pass the audit process and to establish transparency into the supply chain.

Discussion
The development and evaluation of the two distributed ledger artifacts produced some insights, which we would like to discuss further. Based on our designed artifacts, it seems safe to say that a distributed ledger application can mainly generate practical value if it is truly distributed and decentralized, as otherwise the traditional governance and therefore trust problems of centralized applications will arise again. To create a transparent and unified regional label ecosystem, our designed artifacts have also shown how important it is that all parties involved have direct access to the data of the distributed ledger as full or light client. In order to simplify this access and to enable easy data entry, a corresponding user interface in the way of a well-designed web client is required. Once a shared infrastructure and automated workflows in the form of smart contracts are established, it is safe to assume that current process redundancies and therefore costs could be reduced. Security and data privacy concerns can thereby be ensured by appropriate encryption mechanisms and by storing sensitive data in an individual database.
However, even though a distributed ledger system can create a common platform for exchanging, signing and storing all needed documents in a secure and transparent manner and therefore reduce process redundancies and costs, such an application is currently not a good fit for the regional label ecosystem. This is mainly because we could see that the perceived high costs and complexity of DLT applications cause at least smaller organizations to be reluctant to invest in this new technology. In the light of the efficient processes of other regional labels, we would therefore suggest that the umbrella organization needs first to eliminate all unnecessary and inefficient steps in their certification process as identified in Section 4.3. Only in a later step, the digitalization of the process should be taken on to achieve further optimizations, and the implementation of a DLT application can be again considered.
Moreover, the often-stated request of consumers for more transparency and product traceability [1] does not necessarily hold true in every context and environment. At least for regional labels in Switzerland it seems implausible to assume that a distributed ledger system can add value by increasing the transparency for consumers in regional supply chains and thereby increasing the buying intentions for a specific certified product. Based on the evaluation panel's opinion, consumers in Switzerland already trust the statements of regional labels and do not explicitly demand more transparency. For short and regional supply chains, where the involved parties are well known (and to some degree trusted), it might be therefore questionable whether DLT can provide enough benefits in comparison to its-at least currently-high development and implementation costs.
Furthermore, the regional labels in Switzerland can create the required transparency with relatively simple documentation and audit processes. Currently, producers can prove their compliance with basic (physical) documents like delivery notes, invoices or signed statements as well as simple process adaption to avoid the mix-up in their supply chain. The current process satisfies the trust-demands of the consumers and the regional label regulations in Switzerland. Any comprehensive end-to-end track and trace application would inevitably create additional efforts and costs along the entire supply chain without creating (enough) value for the regional label ecosystem. It seems therefore, that for low regulated markets, distributed ledger applications are currently a too complicated and costly solution. To put it the other way: DLT applications seem to be particularly valuable in environments where a high level of transparency is mandatory (e.g., by regulations) but difficult to achieve due to the lack of a shared trusted solution.

Conclusions
In this study, we performed multiple steps for answering our research questions with the aim to produce new knowledge that can be used to design distributed ledger applications for solving current challenges in practice. Our findings offer insights into current challenges of the regional label ecosystem. Those challenges are embodied in a lack of traceability, inefficient and static communication paths, data and information silos, no standardization for files or file storage, a cumbersome audit process, and high search costs for document provision. As a consequence, an application should satisfy the elicited requirements. In particular it should make the certification and audit process simple, unify all parties, reduce redundancies, increase data security and privacy, improve the traceability of products, offer easy data capturing and lower certification costs. Intending to fulfil those requirements, we designed two distributed ledger artifacts, which should overcome the current challenges and add value to the regional label ecosystem.
To answer the first research question-what a distributed ledger application could look like to provide higher efficiency and transparency for a Swiss regional label ecosystem-we point to the designed and discussed artifact elements. To be a good match for the Swiss regional label ecosystem, such a distributed ledger application should have (a) an open and decentralized architecture, (b) give all participants full access to the shared data via full or light clients, (c) provide security and privacy by encryption and individual storage for sensitive data, and (d) offer simplicity and easy data capturing by a well-designed web client.
However, we answer our second research question-if the concept can add value-negatively. The challenges of the regional label can be better solved by conventional process optimization. A distributed ledger application seems in the current situation an over-engineered approach for a Swiss regional label ecosystem.
Lastly, we would also like to point out that our conducted research has certain limitations. On one hand, we would like to emphasize that our results may only apply to Switzerland. In other countries the initial situation could be different, and the consumers could have a different perception of labels. On the other hand, our evaluation was based on the opinion of experts and the artifacts were not implemented and tested. Therefore, we were not able to evaluate possible positive effects such as marketing opportunities, synergies, or first-mover advantage or possible negative effects such as transaction cost, implementation difficulties or governance issues. However, as the perceived value was low by all relevant Swiss regional label ecosystem stakeholders, it is also not surprising that they stopped further adoption and development efforts.
We therefore propose for future research to look deeper into conditions under which a DLT approach could add value for a regional label environment and to elaborate on possible designs for DLT application for small-scale label applications. The insights from our research regarding the spatial extension and complexity of a supply chain and the regulatory requirements of a specific market environment could thereby provide a good starting point.  Acknowledgments: We would like to thank all the people, especially Dominik Woerner and Markus Knecht, involved in the development of the artifacts. Lastly, we would like to thank the umbrella organization and regional label participating in this study and helping us to gather better insights into their business processes as well as enabling us to evaluate the artifacts.

Conflicts of Interest:
The authors declare no conflict of interest.

Appendix A
Interview Guideline (translated-Original is in German) Topic 1: Getting an overview of the (re-)certification process-questions: Final objective: We should be able to describe and map the current (re-)certification process in detail and understand the current issues/problems/barriers/challenges.
Topic 2: Understanding the requirements for a 'digital platform' ('App')-questions: -Which IT tools to support the certification process do you know or currently use? -Where do you see the biggest problems/difficulties in the certification process today? Final objective: We should be able to record and describe the digital 'desired certification process' including the requirements for a 'digital platform (app)'.