These days, companies in the automotive and electronics sector are forced by legal regulations and customer needs to collect a myriad of di erent indicators regarding sustainability of their products. However, in today's supply chains, these products are often the result of the collaboration of a large number of companies. Thus, these companies have to apply complex, cross-organizational, and potentially long-running data collection processes to gather their sustainability data. Comprising a great number of manual and automated tasks for di erent partners, these processes imply great variability. To support such complex data collection, we have designed a lightweight, automated approach for contextual process con guration.
In todays' industry many products are the result of the collaboration of various companies working together in complex supply chains. Cross-organizational communication in such areas can be quite challenging due to the fact that di erent companies have di erent information systems, data formats, and approaches to such communication. These days, state authorities, customers and the public opinion demand sustainability compliance from companies, especially in the electronics and automotive sector. Therefore, companies have to report certain sustainability indicators as, e.g., their greenhouse gas (GHG) emissions or the amount of lead contained in their products. Such reports usually also involve data from suppliers of the reporting company. Therefore, companies launch a sustainability data collection process along their supply chain. This often involves also the suppliers of the suppliers and so on.
As sustainability data collection is a relatively new and complicated issue, service providers (e.g., for data validation or lab tests) are also involved in such data collection. A property that makes these data collection processes even more complex and problematic is the heterogeneity in the supply chain: companies use di erent information systems, data formats, and overall approaches to sustainability data collection. Many of them even do not have any information system or approach in place for this and answer with low quality data or not at all. Therefore, no federated system or database could be applied to cope with such problems and each request involves an often long-running, manual, and errorprone data collection process. The following simpli ed scenario illustrates issues with the data collection process in a small scale.
Scenario: Sustainability Data Collection An automotive company wants to collect sustainability data relating to the quantity of lead contained in a speci c part. This concerns two of the companies suppliers. One of them has an IHS in place, the other has no system and no dedicated responsible for sustainability. For the smaller company, a service provider is needed to validate the manually collected data to ensure that it complies with legal regulations. The IHS of the other company has its own data format that has to be explicitly converted to be useable. This simple scenario already shows how much complexity can be involved even in simple requests and gives an outlook on how this can look like in bigger scenarios involving hundreds or thousands of companies with di erent systems and properties.
In the SustainHub1 project, we develop a centralized information exchange
platform that supports sustainability data collection along the whole supply
chain. We have already thoroughly investigated the properties of such data
collection in the automotive and electronics sectors and published a paper about
challenges and state-of-the-art regarding this topic [
To guarantee the utility of our approach as well as its general applicability, we have started with collecting problems and requirements directly from the industry. This involved telephone interviews with representatives of 15 European companies from the automotive and electronics sectors, a survey with 124 valid responses from companies of these sectors, and continuous communication with a smaller focus group to gather more precise information. Among the most valuable information gathered there was a set of core challenges for such a system: as most coordination for sustainability data exchange between companies is done manually, it can be problematic to nd the right companies, departments, and persons to get data from and also to determine, in which cases service providers must be involved (DCC1). Moreover, this is aggravated by the di erent systems and approaches di erent companies apply. Even if the right entity or person has been selected, it might still be di cult to access the data and to get it in a usable format (DCC2). Furthermore, the data requests rely on a myriad of contextual factors that are only manage implicitly (DCC3). Thus, a request is 1 SustainHub (Project No.283130) is a collaborative project within the 7th Framework Programme of the European Commission (Topic ENV.2011.3.1.9-1, Eco-innovation). not reusable because an arbitrary number of variants can exist for it (DCC4). A system aiming at supporting such data collection must explicitly manage and store the requests, their variants, all related context data, and also data about the di erent companies and support manual and automated data collection.
The remainder of this paper is organized as follows: Section 2 shows our general approach for data collection with processes. Section 3 extends this with additional features regarding context and variability. This is followed by a brief discussion of related work in Section 4 and the conclusion.
The basic idea behind our approach for supporting data collection in complex environments is governing the whole procedure by explicitly speci ed processes. Furthermore, these processes are also automatically enacted by a PAIS (ProcessAware Information System) that is integrated into the SustainHub platform. That way, the process of data collection for a speci c issue as a sustainability indicator can be explicitly speci ed by a process type while process instances derived from that type govern concrete data collections regarding that issue. Activities in such a process represent the manual and automatic tasks to be executed as part of the data collection by di erent companies. This approach already covers a number of the elicited requirements. It enables a centralized and consistent request handling (cf. DCC1) and also supports manual as well as automated data collection (cf. DCC2). One big advantage lies in the modularity of the realization as process. If a new external system shall be integrated, a new activity component can be developed while the overall data collection process does not need to be adapted. Finally, it also enables the explicit speci cation of the data collection process (cf. DCC4). By visual modeling the creation and maintenance of such processes is facilitated. However, the realization via processes can only be the basis for comprehensive and consistent data collection support. To be able to satisfy the requirements regarding contextual in uences, various types of important data, and data request variants, we propose an extended process-based approach for data collection illustrated in Figure 1.
Influences l e d oCustomer taM Product a D Customer Relationship
Mapping ssce sep rPo yT s n o i t a r u g if n o
C
Process Configuration
Configured Process Instance
To generate an awareness of contextual in uences (e.g. the concrete approach to data collection in a company, cf. DCC3) and make them usable for the data collection process, we have de ned an explicit context mapping approach (discussed in Section 3.1). This data is necessary for the central step of our approach, the automatic and context-aware process con guration (discussed in Section 3.2), where pre-de ned process types and con guration options are used to automatically generate a process instance containing all necessary activities to match the properties of the current requests situation (cf. DCC4). As basis for this step, we have elaborated a data model where contextual in uences are stored (cf. DCC3) alongside di erent kinds of content-related data. This data model integrates process-related data with customer-related data as well as contextual information. We will now brie y introduce the di erent kinds of incorporated data by di erent sections of our data model. At rst, such a system must manage data about its customers. Therefore, a customer data section comprises data about the companies, like organizational units or products. Another basic component of industrial production that is important for many topics as sustainability are substances and (sustainability) indicators. As these are not speci c for one company, they are integrated as part of a master data section. In addition, the data concretely exchanged between the companies is represented within a separate section (exchange data). To support this data exchange, the system must manage certain data relating to the exchange itself (cf. DCC1): For whom is the data accessible? What are the properties of the requests and responses? Such data is captured in a runtime data section in the data model. Finally, to be able to consistently manage the data request process, concepts for the process and its variants as well as for the contextual meta data in uencing the process have been integrated with the other data. More detailed descriptions of these concepts and their utilization will follow in the succeeding sections.
This section deals with the necessary areas for automated process con guration: The mapping of contextual in uences into the system to be used for con guration and the modeling of the latter.
As stated in the introduction, a request regarding the same topic (in this case, a sustainability indicator) can have multiple variants that are in uenced by a myriad of possible contextual factors (e.g. the number of involved parties or the data formats they use). Hence, if one seeks to implement any kind of automated variant management, a consistent manageable way of dealing with these factors becomes crucial. However, the decisions on how to apply process conguration and variant management often cannot be mapped directly to certain facts existing in the environment of a system. Moreover, situations can occur, in which di erent contextual factors will lead to the same decision(s) according to variant management. For example, a company could integrate a special foureyes-principle approval process for the release of data due to di erent reasons like if the data is for a speci c customer group or if the data relates to a speci c law or regulation. Nevertheless, it would be cumbersome to enable automatic variant management by creating a huge number of rules for each and every possible contextual factor. Therefore, in the following, we propose a more generic way of mapping for making contextual factors useable for decisions regarding the data collection process.
In our approach, contextual factors are abstracted by introducing two separate concepts in a lightweight and easily con gurable way: The Context Factor captures all di erent possible contextual facts existing in the systems' environment. Opposed to this, the Process Parameter is used to model a stable set of parameters directly relevant to the process of data collection. Both concepts are connected by simple logical rules as illustrated on the left side of Figure 2. In this example, a simple mapping is shown. If a contact person is con gured for a company (CF1), the parameter 'Manual Data Collection' will be derived. If the company is connected via a tool connector (CF2), automatic data collection will be applied (P3). If the company misses a certain certi cation (CF3), an additional validation is needed (P2).
Context Factors CF 3 CF 1 CF 2
Context Rules
CF3 P2 CF1 P1 CF2 P3
Process Parameters
P2
CF1: Contact Person X P1: Manual Data Collection CF2: Tool Connector Y P2: Validation needed
CF3: Certification missing P3: Automatic Data Collection
Implication Contradiction 1 Contradiction 2 PP31 EMxculutsuiaoln PP21 P3 CCFF 21 CCFF21 PP31 P1 P3
P2
When exchanging data between companies, various situations might occur, in which di erent decisions regarding the process might have implications on each other. For example, it would make no sense to collect data both automatically and manually for the same indicator at the same time. To express that we have also included the two simple constraints 'implication' and 'mutual exclusion' for the parameters. For an example, we refer to Figure 2, where, for example, manual and automatic data collection are mutually exclusive.
Although we have put emphasis on keeping the applied rules and constraints simple and maintainable, there can still exist situations, in which these lead to contradictions. One case (Contradiction 1 in Figure 2) involves a contradiction only created by the constraints, where one activity requires and permits the occurrence of another activity at the same time. A second case (Contradiction 2 in Figure 2) occurs when combining certain rules with certain constraints, in which a contradicting set of parameters is produced. To avoid such situations, we have integrated a set of simple correctness checks for constraints and rules.
In this section, we will introduce our approach for process con guration. Therefore, we not only considered the aformentioned challenges, we also wanted to keep the approach as easy and lightweight as possible to enable users of SustainHub to con gure and manage the approach. Furthermore, our ndings included data about the actual activities of data collection and their relation to contextual data. Data collection often contains a set of basic activities that are part of each data collection process. Other activities appear mutually exclusive, e.g. manual or automatic data collection, and no standard activity can be determined here. In most cases, one or more context factors impose the application of a set of additional coherent activities rather than one single activity.
In the light of these facts, we have opted for the following approach for
automatic process con guration: For one case (e.g. a sustainability indicator) a
process family is created. The latter contains a Base Process with all basic
activities for that case. Additional activities that are added to this Base Process
are encapsulated in Process Fragments. These are automatically added to the
process on account of the parameters of the current situation that is represented
in the system by the already introduced Process Parameters and Context
Factors. Thus, we only rely on one single change pattern to the processes, an insert
operation. This operation has already been described in literature, for its formal
semantics, see [
To keep the approach lightweight and simple, we decided to model both the Base Process and the fragments in a PAIS (Process-Aware Information System) that will be integrated into our approach. Thus, we can rely on the abilities of the PAIS for modeling and enacting the processes and also for checking their correctness.
Process Fragment 1
Collect Data Automatically
ID: PF1 Type: a Insert: Inline Exec: single
Process Fragment 2
I(nRfeosrmpoPnesirbsloen) CoMllaencutaDllayta
ID: EP1, Start: EP1.start, End: EP1.end, Type: a, Order: 1
EP1.start Extension Point 1 EP1.end Configure Data
Collection
Inform Person (Responsible)
Collect Data
Manually Collect Data Automatically
Aggregate
Data
ID: PF2 Type: a Insert: Inline Exec: single
Process Fragment 3 ID: PF3
ARpepicreoivpet ITEnxysepecer::ts:xiInnglilnee
ID: EP2, Start: EP2.start, End: EP2.end, Type: x, y, Order: 2 EP2.start Extension Point 2 EP2.end
Deliver
Data Approve Reiceipt
Inform
Requester
To enable the system to automatically extend the base process at the right
points with the chosen fragments, we have added the concept of the Extension
Point (EP). Both the latter and the fragments have parameters, the system can
match to nd the right EP for a fragment (see Figure 3 for two example EPs
and three fragments with matching parameters). Regarding the connection of
the EPs to the Base Processes, we have also evaluated multiple options as, e.g.,
connecting them directly to activities. Most of such options introduce limitations
to the approach or impose a fair amount of additional complexity (cf. [
By relying on the capabilities of the PAIS we have kept the number of
additional correctness checks small. However, the connection points are not checked
by the PAIS and could impose erroneous con gurations. To keep correctness
checks on them simple we rely on two things: The relation of two connection
points of one EP and block-structured processes [
Regarding the topic of process con guration, various approaches exist. Most of
them focus on the modeling of process con guration. One example is C-EPC [
In this paper, we have shown a lightweight approach to automatic and contextual process con guration required in complex domains. We have investigated concrete issues in an example domain relating to sustainability data collection in supply chains. With our approach, we have centralized the data and process management uniting many di erent factors in one data model and supporting the whole data collection procedure by processes executed in a PAIS. Moreover, we have enabled this approach to apply automated process con gurations conforming to di erent situations by applying a simple model allowing for mapping contextual factors to parameters for the con guration. In future work, we plan to evaluate our work with our industrial partners and to extend our approach to cover further aspects regarding runtime variability, automated monitoring, and automated data quality management.
The project SustainHub (Project No.283130) is sponsored by the EU in the 7th Framework Programme of the European Commission (Topic ENV.2011.3.1.9-1, Eco-innovation).