A Business Process Reference Model for the Development of a Wine Traceability System

Abstract

Traceability is among the most significant challenges in supply chains, where multiple stakeholders and activities are involved in the production and distribution of products. No supply chain can become sustainable without effectively addressing the problem of traceability by recognizing, monitoring, and implementing all necessary activities of the processes. This research provides a reference model for effective wine supply chain traceability and is part of a research project for the development of a blockchain-enabled traceability system. The reference model not only depicts processes but also covers all views that are necessary for achieving the whole picture of an effective traceability system. These views include the value chain, organizational resources, functions, processes, systems, data, and risks that are related to wine production and distribution. The reference model has a strong contribution to practice and research as it pertains to bridging the barrier between developers and users while also offering significant research outcomes. The research output is the reference model that includes standard wine traceability processes and all necessary data for effective wine supply chain traceability. The results of this research will be used for creating the traceability system’s specifications and ensuring that it will be effectively designed and implemented. The reference model can also be used for the implementation and adaptation of the traceability system to the stakeholders of the wine supply chain.

1. Introduction

One of the most important challenges faced by product manufacturing and distribution companies today is the effective traceability of products along the supply chain [1]. This particular challenge creates a complex problem in which multiple criteria and limitations must be simultaneously taken into account, as well as the particular requirements of each product [2]. Today, where the demand for products and the challenges faced by companies involved in product supply chains are clearly more intense, the use of advanced systems for effective product traceability becomes a necessity [3].

In an effort to address this problem, a blockchain-based system for the efficient traceability of wine along the supply chain is being developed as part of a research project. In this context, in this article, a reference model is developed, which will be built using renowned architectural modeling methods and frameworks. This model will be used in the near future to define the requirements and specifications of the system. Software requirement analysis is a practice of thorough preparation, elaboration, and examination of objectives, before, during, and after the implementation of any information technology (IT) project. The thorough analysis of the requirements during the design and development of a system is particularly important, as this contributes decisively to the correct completion of the system, without delays and deviations from the forecasts.

The contribution of this research is not limited to just creating the reference model but may also be used in the future by the research community as a guide for a more sustainable wine supply chain. A supply chain that is properly tracked is both financially and in terms of health and safety sustainable for all participants. In addition, it is environmentally sustainable as an accurate recording and measurement of the impact on the environment can be achieved. Moreover, through effective traceability, the supply chain becomes socially responsible as best practices and compliances are ensured. In fact, it is not only the traceability system that will be developed but also the standard processes that are synthesized as part of the reference model that will ensure the supply chain sustainability. This is due to the fact that the supply chain cannot become sustainable and traceable without recording, monitoring, and implementing the related processes as recent research studies show [4,5,6,7,8,9,10]. Therefore, by not only focusing on the traceability system but also emphasizing processes as a key factor, the research effort has a strong direction towards sustainability.

Process modeling, the approach needed for successfully recording and monitoring processes, contributes to the understanding of the structure and operation of businesses, while it is a particularly useful tool for analyzing the requirements of a system, which is called upon to support their needs [11]. A company’s choice to implement an information system is greatly influenced by the requirement to address certain operational issues. These issues may affect specific company operations or a combination thereof. The success of an information system is directly proportional to the degree to which its deployment has assisted the organization in achieving essential goals, such as enhancing its services, lowering its expenses, and decreasing its downtime [12].

The development of an information system is not an easy task as many stages are necessary and multiple parties are involved. The specific system will be developed following a methodology based on the waterfall model [13]. In this model, in the first phase, the problems that the system is called to face are investigated following systematic research, including interviews and a study of best practices. The more accurately and in detail this phase is performed, the more successfully can the system be designed and implemented. In the second phase, it is determined how long it will take to develop the system, how much it will cost, how businesses will benefit from using the system, whether the necessary infrastructure and expertise exist, how the adaptation of the system will be accomplished, and how key factors such as profitability will be impacted. Moreover, at this phase, the needs are identified and, afterwards, analyzed. The outcomes of this stage will then be used in the system design phase to provide technical specifications and design details. In the programming phase, the requirements will then be translated into an executable code, and in the testing phase, the system will be placed into testing using suitable control scenarios. After the completion of all testing, the system will finally be placed into operation.

This research focuses on the first phase that was previously described as it concerns the development of the reference model. There is a gap in the literature concerning practical implementations of reference models as most studies remain at a theoretical level without including real-life implementations. The model of this study will be used in on-going research to enable the accurate requirement analysis that is critical for the system’s development. In most cases, in addition to the team that undertakes the software development, many business executives who will use it in practice are involved, such as managers, shareholders, and consultants, who will work with the software development team. This cooperation becomes necessary for understanding the needs of businesses and the processes that the system is called upon to support. Difficulties in communication between users and software developers often lead to errors, as shown by practical experience. As a result of an inability to comprehend the demands that the system is tasked with supporting, the designed system may provide insufficient coverage of business operations [14]. If neither the demands nor the functioning of the system is understood by all parties, the system requirements will not be accurately established, and the system’s implementation is deemed to fail [15,16,17].

The reference model of this study has a strong contribution to practice as it pertains to bridging the communicative and comprehending barrier among the team of developers, which will implement the wine traceability system, and the various stakeholders along the supply chain, who are the potential users of the system. In order to effectively design the reference model, a series of visits to and interviews with different companies in the wine industry and to distribution companies were preceded, aiming to record how they carry out their operations and how they trace their products but also to identify as many problems as possible. In addition, the internationally recognized GS1 EPCIS traceability standard was studied in depth and adopted. In particular, it was made sure that the elements of the data view of the reference model conform to the GS1 EPCIS traceability standard.

The reference model also has a strong contribution to traceability research as it depicts standard wine traceability processes, related to both production and distribution, indicating how the traceability system needs to be implemented in order to fully serve the needs for effective wine traceability. The model represents different modeling views (perspectives), not being limited to just a process overview but also depicting related data, functions, systems, risks, value stream, and organizational structures. The aim of developing the reference model was to create a guide or “benchmark” for understanding the functionality of the wine traceability system, its interaction with the stakeholders in the supply chain, and its contribution to wine product tracking and tracing. That is why the reference model can be used at the driver for implementing the designed traceability system at every party of the wine supply chain. To the best of our knowledge, no other research has been published covering all the aforementioned views as part of a reference model for traceability.

More specifically, this reference model will be used in the next phase of our research for the development of the blockchain-enabled traceability system by providing the data that need to be collected by the system from each wine supply chain stakeholder. The data collection and management play the most important role when designing a traceability system, and therefore, care was taken to make sure that all necessary data were effectively collected. Blockchain technology will play a key role for the successful implementation of the traceability system as the collected data will be transmitted to a secure and decentralized blockchain network in order to ensure that they will not be altered or manipulated in any step of the supply chain. Blockchain technology will enable secure and robust data sharing among all supply chain stakeholders. Therefore, it becomes clear that the reference model of the present research, and especially its data view, plays a critical role for the future implementation of the traceability system. The role of blockchain technology and its adoption for traceability in various industries has gained extreme popularity in recent years, and high-quality research has been published [18,19,20,21,22,23,24]. Additionally, the authors of this paper, as part of their research project for the development of a blockchain-enabled traceability system, have performed a strong literature review on blockchain and other technological implementations for traceability in various sectors [25].

After this introduction to the current research, the structure of the paper is as follows: The Section 2 presents a review of the business process modeling concept that serves as a guidance for the implementation of the reference model. Section 3 presents ARIS (ARchitecture of integrated Information Systems) that is used as a base for developing the reference model’s custom architecture. Section 4 analyzes the development of the reference model and all the views and models that were included. Finally, Section 5 includes a discussion of the main findings of this research as well as future research goals.

2. Review of the Business Process Modeling Concept

Moving towards the implementation of the reference model, it was considered appropriate to analyze the business modeling concept that enables the design and implementation of the reference model. In particular, the concepts related to business modeling are interpreted in this section, and their correlations are explained. This investigation is carried out with the aim of extracting useful data that will then be used for the construction of the reference model.

2.1. Enterprise Modeling

The term “enterprise modeling” refers to the depiction of some or all the systems and processes of an enterprise, including its resources and the various stages of its life cycle [26]. The modeling of business processes is part of the more general topic of business modeling alongside the modeling of systems, which may be either informational or noninformational, and is the most significant dimension of this kind of modeling [27]. The transfer of ideas and expertise into a systematic way of representation is the foundation upon which business process modeling is formed, and according to Panayiotou et al. [28], it includes the five typical stages illustrated in Figure 1. Business process modeling starts with a partial knowledge about a problem that is under investigation. The researchers then try to display the knowledge in a structured way with the use of modeling tools and software. Afterwards, they continue to investigate the problem to gain knowledge and understand the elements of the immediate environment. Next, the gained knowledge is defined, segmented, visualized, and imported to the developed models. Finally, after forming all required models to address the problem, they are verified and validated, and necessary improvements are made.

The most recent theories of business process management draw heavily on the total quality and business process reengineering movements, identifying as its main goal the improvement of products and services provided to customers. This is achieved through a structured approach that emphasizes performance improvement and focuses on the systematic planning and management of the organization’s entire business [29]. Business processes are highly complex involving numerous resources and need to be carefully studied from different perspectives. In order for the management of business processes to be carried out effectively, it is necessary to clearly record the sequence between business activities and to be connected to the organizational units responsible for their execution, with information systems, documents, and all other data and the limitations that characterize them.

As it becomes clear, analyzing, improving, and effectively applying business processes to practice can only become possible when all information related to the processes has been successfully recorded. In any other case, missing information will surely lead to suboptimal process analysis, and the expected goals will not be met [30]. The effective recording and analysis of business processes in a formal and systematic way is achieved by modeling them using appropriate modeling methods [31]. Numerous practical applications of modeling in the context of business process management can be found in the literature [27,32,33,34,35]. The most typical uses are summarized in the following:

• Analysis of systems and processes to identify malfunctions and areas for improvement;
• Analysis and design of systems and procedures before their implementation;
• Aidance to reduce complexity and increase understanding;
• Communicating a common understanding regarding a system or process;
• Achieving organizational changes;
• Gaining the support of stakeholders and building the necessary consensus on the implemented changes;
• Automation of business processes;
• Usage as a means of documentation, such as in a quality assurance system, a total quality system, or a reorganization project.

2.2. Correlation of Architectures, Frameworks, Modeling Methods, and Tools

For the construction of business models, which by nature are particularly complex, modeling methods are used, which may cover one or more views (aspects) of a system. The modeling method is the formal way of recording, analyzing, and visualizing a system based on specific rules and symbols. This formal method of recording is often diagrammatic; nevertheless, it is not prohibited to use some other notation for developing models and systems [36]. Methods can refer to either techniques or modeling languages, with the former being primarily modeling methods from the perspective of business processes and the latter being primarily modeling methods from the perspective of information systems [32]. Modeling tools make it easier to use modeling methods in order to develop models in a methodical fashion that adheres to the rules and requirements of each modeling approach [37]. This makes the application of modeling methods one of the most important aspects of modeling. Modeling tools are often developed in accordance with certain modeling frameworks and architectures [31], and may be based on one or more modeling methods.

As can be seen in Figure 2, which graphically represents the relationships of the concepts presented in this section, models are constructed using modeling methods, describing different dimensions of enterprises and systems. The correlation of these different dimensions through the connection and construction of the different models is carried out by the application of the enterprise modeling frameworks, which shape the architecture of a system or even the entire enterprise. The concepts of architecture and modeling framework, often also of modeling methodology, do not have commonly accepted and clear definitions in the literature. Due to lack of clarity and often understanding, these terms may at times have been mistakenly used interchangeably. For this reason, in the following paragraphs, an attempt is made to define these concepts in combination with the aforementioned concepts of the method and modeling tools.

Enterprise architecture is the approach to design enterprise operations and systems in a systematic and methodical manner and in accordance with the rules and principles of the modeling framework on the basis of which they were developed, seeking the most efficient possible achievement of their purpose [38,39]. Through this, the analysis of systems is approached for different visual and individual phases of their life cycle so that their overall picture can be understood. The application of enterprise architecture achieves the analysis of complex systems and their representation in a formal way through the creation of models that specify various aspects of the enterprise, such as processes, data, risks, and software applications [40,41]. The importance of the creation of models for the design and implementation of enterprise systems, and also for the integration of the individual components of the organization, led to the development of the various enterprise modeling architectures by the scientific community and their adoption by the enterprises, making the terms enterprise architecture and modeling architecture synonymous [28].

An enterprise modeling architecture handles business models in a unified and integrated way. To achieve this when applied to a specific case, it should be modeled following the associated modeling framework or architectural framework (both terms are found in the literature) [42]. Therefore, in order to be able to organize and classify the business models that comprise an architecture, a modeling framework is used [43], which helps in building and defining the architecture and modeling and organizing the models. The framework can be characterized as a broader concept in relation to architecture, constituting a set of principles and rules that govern it.

Modeling frameworks achieve the linking of models for different dimensions (views) within the enterprise [26]. Thus, modeling frameworks include the life cycle dimension whereby different models of an architecture cover the entire spectrum of an operational system’s life cycle. Additionally, they include the different aspects of modeling, giving the possibility to focus on specific perspectives of a business depending on the purpose of modeling [44]. In order to meet the modeling requirements for the different modeling dimensions, modeling frameworks usually propose a set of modeling methods. For the formation of an architecture, the use of specific methods can be prescribed or simply suggest the use of those considered more appropriate, depending on the purpose of the modeling [28]. The practical application of modeling methods and architectural methodologies is made possible by the use of modeling tools [45].

The most widespread architecture frameworks do not always have a common way of organization and a uniform structure in terms of the components that make them up, while they are not always inspired by the same logic in terms of the use of methodologies and modeling methods. This fact has mainly to do with the purpose for which each framework was created. Additionally, it is a fact that both architectures and architecture frameworks for enterprises have been the subject of extensive scientific research by researchers around the world. From 1990 to the beginning of the 2000s, the most important architecture frameworks were formed, including CIMOSA (Computer Integrated Manufacturing Open System Architecture), Zachman-ISA (Information Systems Architecture), GERAM (Generalized Enterprise Reference Architecture and Methodology), and ARIS (ARchitecture of integrated Information Systems) [28].

For the implementation of an architecture framework, a methodology is often used that supports with instructions and official rules the use of the components of the framework [46]. A methodology can provide the rules for the consistent description of the business using the models for the different aspects of modeling but also for the implementation of specific projects, such as business process re-engineering or information systems implementation [28].

For the implementation of any reference model, an architecture needs to be formed that combines different dimensions (views) of the processes that will be supported. The different modeling dimensions determine the combination of methods and tools to be used each time to achieve the modeling [47]. The views that are usually modeled are those of the functions (functional view), the information or data (data view), the organization (organizational view), the products/services (product view), and the processes (process view). All these views represent different elements, while the last one (process view) combines elements from the other views. These dimensions are all included in the most important architectures [28].

Summarizing the above, regarding the relationship between architecture, framework, and methodology, it can be said that architecture has the role of assembling and structuring models to formally define a system and describe its structure graphically. The models that make up the architecture are used to define the system through different perspectives that it is perceived and for different phases of its life cycle. Modeling methods are used to create the models, which in some cases have been developed specifically for a modeling framework. In addition, a framework may be accompanied by a specific methodology, which provides the rules for its implementation. Finally, a set of principles and rules for modeling and organizing models according to a modeling framework is used to form an architecture. Figure 2 illustrates the concepts of architecture, modeling framework, methodology, method, model, modeling dimensions, and modeling tools, graphically representing the previously discussed relations.

3. ARIS Architecture as a Basis for the Reference Model

ARIS (ARchitecture of integrated Information Systems) was developed in the early 1990s as a reference architecture for the purpose of systems analysis and design. It is considered to be a process-oriented approach to business management. ARIS architecture’s framework is developed using two dimensions: the views and the life cycle levels. ARIS is oriented to processes and their behavior in response to events (event driven), while using the different views to reduce the complexity of the models. It emphasizes maintaining the relationships between modeling aspects in a clearer and more granular way [48].

The content of the separate views proposed by ARIS is described by methods that are appropriate for each specific view. In the first phase, models are developed using selected methods, without placing too much emphasis on the numerous relationships of the elements and the interrelationships with the other aspects. Afterwards, the relationships between the aspects are integrated into the model and united in an overall analysis of the process chains. Views are defined in such a way that the relationships between the elements of each view are strong, while the relationships with the other views are weak. In this way, the aim is to divide the project into smaller ones that are undertaken by groups of people who can work at the same time [28].

Regarding the view dimension, ARIS architecture’s framework models the business system with the following five descriptive views [28]:

• Data and systems view: It includes the organization’s data and systems and is used to describe the events and conditions prevailing in its environment.
• Function view: It describes all the internal functions and subfunctions of the business, their hierarchical structure, and the relationships that govern them.
• Organization view: It describes the organizational structure of the business and the relationship between users and organizational units.
• Process view or control view: It describes the relationships between the first three views. It is perhaps the essence of architecture as it examines the business, taking into account the elements of all other views.
• Product/services view: It represents the most important results, outputs of the organization or its individual functions.

The second dimension of the ARIS framework involves the use of descriptive layers based on the principles of a life cycle model. Thus, each aspect is described using three levels, which essentially constitute the phases of the life cycle of a system and especially an information system [28]. The layers include:

• Definition of requirements;
• Definition of design specifications;
• Implementation description.

The different dimensions of the ARIS framework [49] have been connected by its creator in a single framework called ARIS House. As shown in Figure 3, the framework contains multiple modeling views with each of them being connected to three life cycle phases of system development. The ARIS architecture’s framework suggests several modeling methods for the different aspects and for each phase of the framework’s life cycle.

The ARIS framework and the modeling tools that follow it have a wide range of modeling methods for each different perspective, not limited to the ones mentioned above. From these offered methods, the most appropriate ones are selected each time, depending on the purpose of the modeling. An important feature of the ARIS framework is that the models are interconnected, and this helps to identify the interaction of different business objects (e.g., organizational units and process steps, information systems and processes) and in the configuration of reports with these interactions. This is enhanced by the capabilities of the software tool, which manages the objects of the models in a database (repository) [49].

4. Development of the Reference Model of Wine Traceability Processes

In this section, the development of the reference model for wine traceability standard processes in the supply chain is carried out. The reference model development methodology is summarized in Figure 4.

The first step in developing the reference model is to define the modeling strategy. This step includes the selection of the modeling perspectives and the methods that will be used in each perspective, ultimately shaping the architecture of the reference model. After the design of the architecture follows the recording of the needs of the companies, which includes conducting interviews with a large number of wine production and distribution companies, as well as a detailed recording of the processes they apply, which could be supported by the traceability system. At the same time, using the data from the interviews, the recordings, and the in-depth study for compliance with the internationally recognized GS1 EPCIS standard, problem areas that lead to malfunctions and reduced traceability are identified. Then, by studying the problem areas, the possibilities of supporting the companies by the system are determined, as well as specific processes that the system will be able to support. In conclusion, leveraging the ARIS v.10.0 software tool [50], the reference model is finally developed, including a set of different perspectives and modeling methods that will accurately capture the functionality of the traceability system and its value to the companies in which it will be used.

4.1. Reference Model’s Architecture

The modeling architecture for the implementation of the reference model, as depicted in Figure 5, essentially includes the framework for organizing the models and, specifically, the different modeling perspectives and the selected modeling methods per perspective. For the construction of the architectural modeling of the project, elements of ARIS were used, that is, different views of modeling, specific methods, and the modeling software tool ARIS v.10.0. This tool is one of the most widespread and powerful process modeling tools, with a large number of worldwide applications in both the public and private sectors [51]. The modeling architecture of the reference model has been configured in such a way that it can support in the formation of the system’s specifications. The chosen modeling tool can also ensure the future use of other methods that, in addition to the already-developed static ones, can support the dynamic modeling and simulation of the processes.

4.2. Value Chain View

The value chain view concerns recording the main processes that are directly involved in the creation of added value of an organization using a value-added chain diagram (VACD). They are also called in the literature as end-to-end processes or main group of processes [48]. This method has been developed to perform and design a “map” of the organization’s processes, taking into account the higher conceptual levels of the process architecture to describe the main business functions. It is one of the most general and comprehensive methods provided by ARIS and is based on the creation of a chain of interconnected processes. Typically, each of these interconnected processes represents a family of individual processes, which are broken down in greater detail using other methods, such as function trees. The value chain is presented in Figure 6 using a VACD and is essentially the mapping of the processes that are further broken down into subprocesses. The figure is split into two rows in order to be visible to the readers, but the flow continues from the wine production management to the wine orders management.

As shown in Figure 6, the recognized processes in the wine supply chain range from the collection of the grapes in the vineyard (harvest) to the distribution of the final products to the customers. More specifically, for each process, its description is provided, the possible risks are recognized, and the necessary resources that enable the process are recorded. The main processes identified during the interview phase are presented using business process modeling notation (BPMN) diagrams and illustrate the main operational tasks performed during the wine production and distribution. Each one of the four main groups of processes that are presented in Figure 6 is analyzed in Appendix A at the end of the paper. The four main groups of processes that were recognized are:

• The “wine raw materials management” process, which includes all those subprocesses that are related to the management of the winery’s raw materials. The subprocesses are the collection of the grapes (harvest) in the vineyard, the cooling of the grapes, the ordering, and the receipt of the wine products.
• The “wine production management” process includes all those subprocesses that are relevant to the production of the wine within the winery, from the receipt of the grapes at the winery and the production of the must to bottling and packaging.
• The “wine order management process” includes all those subprocesses that are relevant to order management at the winery, such as the preparation of finished products and the execution of orders.
• The “wine distribution” process includes two main subprocesses. The first subprocess concerns the management of expected order receipts from a winery to a distribution operator. The second subprocess concerns preparing and sending orders from the distributor to the recipients (wholesalers or retailers). In more detail, the “receipt of orders” subprocess includes all the processes from receiving the request for receipt of an order from the winery, to storing it, awaiting shipment, or sending it directly to the recipient (cross-docking). The “shipping of orders” process includes all those subprocesses that are relevant to preparing and sending orders to their recipients.

4.3. Organization View

The organization view analyzes the organizational structure of the business from top to bottom, as well as all the roles of the organizational units involved in the modeled processes. To support the modeling of the organizational view, the organizational chart method was chosen, which is essentially the standard diagram of organizational structures, and is the most popular method of the organizational view. The organizational chart allows the use of a wide range of organizational structure objects, and a business can be organizationally modeled, taking into account departments, groups, teams, roles, positions, people, boards, committees, and partners. These diagrams also allow the creation of hierarchical relationships between organizational units and employees in an organization.

The diagram, as depicted in Figure 7, in this case, was not constructed as a standard organizational chart as the study concerns processes with universal application in many businesses. Therefore, instead of an organizational chart, a custom diagram was constructed in which the organizational units are grouped according to the processes in which they participate. For demonstration purposes and to present a clear overview, the diagram includes only a high-level representation of the participants. All depicted roles have been connected to the processes they are involved in through the use of relevant lanes in BPMN diagrams.

4.4. Function View

The functions view includes the hierarchical structure of processes (in the form of trees), breaking them down from the high level of operations down to individual processes and subprocesses, which are then broken down into process diagrams. The function tree illustrates the division of a complex process into subprocesses. It belongs to the perspective of operations and gives us a high-level view of processes and subprocesses. Those processes that cannot be further analyzed are called elementary processes, and for them, a process diagram is always created. To group the subprocesses in a function tree, we can apply three different grouping criteria:

• To process the same object (object oriented);
• To include the same activities (operation oriented);
• To belong to the same main process (process oriented).

In this particular model, as illustrated in Figure 8, the function tree is a process-oriented function tree, which means that it depicts the breakdown of main processes into subprocesses.

4.5. Process View

The process view analyzes all the modeled processes. Complex and larger processes are deconstructed so that they can be described autonomously without complexity. For each process, its analytical flow is described, including the performed tasks and the events that occur. In the process view, information is combined from the other views, which act as information libraries by providing to this view the information systems, the involved organizational units, files, data, and risks that are used during the execution of a process.

The modeling method chosen to better depict wine supply chain processes is the business process modeling notation (BPMN), and especially the BPMN 2.0 method [52]. BPMN business process diagrams aim at the most accurate and complete representation of the flow of processes in order to analyze and improve them. A BPMN business process diagram represents a graphical sequence of all the actions that make it up. The main objects of BPMN processes are the activities (tasks) and the events. Tasks refer to processes that cannot be analyzed at a more detailed level. Events may arise as a result of some tasks or can be conditions for another event or task. The process flow may be split into two or more flows using rules (logical operators).

Pools and lanes are the two ways that BPMN organizes tasks in a process model. As a key component of BPMN, pools describe the parameters of a business process and often serve as organizational representations. There can only ever be one business process in each pool. The tasks in a process are organized and classified using lanes, which are smaller compartments within a pool. An organizational position (actor), duties, and organizational hierarchies are often also represented by a lane. An activity can only belong to one lane, and a process can only belong to one pool.

Another type of diagram that was included in the process view was the function allocation diagram (FAD). These diagrams allow a detailed visualization of specific tasks while allowing the process diagram to be kept simple and easy to read. Specifically, for each task in a process diagram, there is a separate FAD that exclusively models the relationships of the specific tasks with other objects of the architecture, such as data, roles, systems, and risks. An indicative process concerning the quality control is presented in Figure 9, accompanied by a FAD for one of the related tasks.

4.6. Systems View

The diagram chosen to depict the system is application system type diagram as this is described in the ARIS framework. The use of this diagram is suggested as an optimal solution for modeling information systems, and also applications or subapplications. At the simplest level, an application system type diagram identifies a library of systems used by the organization. At a more detailed level, it models the structure of systems and their subsystems or provides a hierarchical categorization of system types. The model, as shown in Figure 10, allows the representation of the external systems, used by the wine supply chain stakeholders, that will need to communicate with the blockchain traceability system that will be developed.

4.7. Data View

All data identified during the analysis were collected in separate information carrier diagrams. These diagrams allow the representation of information elements or business objects, usually in the form of clusters, as well as the physical media that act as information carriers and carry or store said information or business objects. An example of such a model is shown in Figure 11, depicting data related to the wine orders.

Additionally, based on the analysis of the wine supply chain processes, various attributes were selected that will be incorporated as the system’s traceability data. The attributes were modeled using the eERM attribute allocation diagram, and an indicative diagram concerning the necessary data for the transportation of the wines from the bottler to the wholesaler or retailer is presented in Figure 12.

4.8. Risks View

The risks view represents all risks identified during the analysis. Risks were grouped in separate risk diagrams according to the processes they were discovered in. A risk represents the possibility that a specified process objective will not be achieved or, in many cases, an indication that tampering actions may occur. Risk diagrams were used as they allow the prioritization and aggregated visualization of the risks identified in the process diagrams. Risk objects and risk categories are combined in risk diagrams depicting the risks hierarchy structure. An indicative risk diagram and risk hierarchy structure is presented in Figure 13 depicting risks related to wine transportation.

Risk identification, risk connection with activities of business processes, and risk categorization and hierarchical representation are of main importance for the developed reference model, as risks represent the points that data are important to be traced in order to avoid wine fraud and conform with traceability standards and sustainable practices.

5. Discussion

The main purpose of this research is to present a reference model of standard wine traceability processes. The development of an effective traceability system requires the study and analysis of the supply chain in order to identify the actors, the elementary processes, the resources involved in it, and the critical data for traceability. This analysis is of fundamental importance as it is one of the main activities that must be carried out in order to reveal how products move along the supply chain. After all, only through the proper recording, monitoring, and implementation of appropriate business processes can the traceability system function effectively and lead to an environmentally, socially and financially sustainable supply chain.

The reference model that was developed supports the implementation of a traceability system along the wine supply chain, including the production, storage, and distribution activities. More specifically, the reference model includes, in a structured way, different views of the operation of the companies involved in the supply chain. The model aims to provide a guide for effective wine supply chain traceability so that the traceability system can be effectively implemented and adapted to the processes of supply chain stakeholders. The diagrams that were designed depicted the flow of the processes and their connection with all the objects, illustrating beyond the processes also the functions, risks, value chain, data, systems, and organizational resources.

The modeled processes highlight the critical points in the wine supply chain, that is, those points that need effective traceability to avoid fraud and products’ counterfeit. For the wine production process, the points were mostly related to additions or mixtures with other wines and/or wine products. These points present a high risk of adulteration and, therefore, need systematic monitoring. Correspondingly, the storage and the preparation of the shipment, during the phase of the distribution of the wine products, were found to be points where alterations and label fraud are most likely to occur. Through the analysis of the wine supply chain and in combination with the discovered critical points, it was identified what data should be collected for effective wine traceability. The data basically concern who performs a specific action, what exactly this action includes, when and where it takes place, and of course, why it is performed. The data are in full compliance with the internationally recognized GS1 EPCIS traceability standard, which will be adopted during the development of the traceability system.

The constructed reference model will be utilized in light of upcoming research to specify the operational requirements and technical specifications for the deployment of the traceability system. In essence, the reference model will serve to bridge the communication and comprehension gap between the traceability system’s developers and wine supply chain stakeholders, which will be the main users of the system. This will be accomplished by providing a common language for both parties to work off with. Subsequently, based on the requirements and specifications, the development and testing of the traceability system will be carried out in order to validate its effectiveness.

As a next step, and after the development of the traceability system, the presented reference model can be further used as a guide for business process transformation in conformance with the operation of the traceability system. In this phase, the reference model can be used by every stakeholder involved in the wine supply chain that uses the new traceability system. Finally, as research advances and traceability solutions based on the blockchain technology become more affordable for mass usage, the reference model will be improved to offer an end-to-end guide on wine supply chain traceability. Thus, the reference model will be expanded beyond the currently covered processes.