=Paper= {{Paper |id=None |storemode=property |title=Challenges of Applying Adaptive Processes to Enable Variability in Sustainability Data Collection |pdfUrl=https://ceur-ws.org/Vol-1027/paper6.pdf |volume=Vol-1027 |dblpUrl=https://dblp.org/rec/conf/simpda/GrambowMSR13 }} ==Challenges of Applying Adaptive Processes to Enable Variability in Sustainability Data Collection== https://ceur-ws.org/Vol-1027/paper6.pdf
  Challenges of Applying Adaptive Processes to
    Enable Variability in Sustainability Data
                   Collection

  Gregor Grambow, Nicolas Mundbrod, Vivian Steller and Manfred Reichert

                Institute of Databases and Information Systems
                            Ulm University, Germany
   {gregor.grambow,nicolas.mundbrod,vivian.steller,manfred.reichert}@
                                  uni-ulm.de
                         http://www.uni-ulm.de/dbis


      Abstract. Nowadays, demanding legal regulations as well as sophis-
      ticated customer needs force companies in electronics and automotive
      industries to provide a multitude of different sustainability indicators.
      Since their products usually contain numerous components and sub-
      components, companies must deal with complex, intransparent data col-
      lection processes along their supply chains in order to finally deliver
      valuable data. A myriad of different automatic and manual tasks, po-
      tentially long-running processes, and quickly changing situations result
      in great variability that is hard to handle. In the SustainHub project,
      a dedicated information system for supporting data collection processes
      is developed. Thereby, core challenges as well as state-of-the-art were
      systematically gathered, consolidated as well as assessed. The condensed
      results are presented in this paper.

      Key words: Business Process Variability, Data Collection, Sustainabil-
      ity, Supply Chain



1 Introduction

These days, companies of the electronics and automotive industry face steadily
growing demands for sustainability compliance triggered by authorities, cus-
tomers and public opinion. As products often consist of numerous individual
components, which, in turn, also comprise sub-components, heterogeneous sus-
tainability data need to be collected along intertwined and intransparent supply
chains. Thereby, highly complex, cross-organizational data collection processes
are required, featuring a high variability, e.g., through dynamically integrat-
ing companies’ employees and information systems (ISs). Further issues include
incompleteness and varying quality of provided data, heterogeneity of data for-
mats, or changing situations and requirements. Until today, there is no dedi-
cated IS supporting companies in creating, managing and optimizing such data




                                                                                   74
collection processes. Within the SustainHub1 project, such a dedicated informa-
tion system is being developed. In this context, use cases, delivered by industry
partners from the automotive and the electronics domain, have been intensively
studied in order to consolidate core challenges and essential requirements re-
garding the IT-support of data collection processes. In relation, state-of-the-art
has also been deeply studied to assess whether existing approaches and solutions
satisfy the requirements. As a result, this paper systematically presents the con-
densed core challenges and state-of-the-art considering complex sustainability
data collection process along today’s supply chains. This domain is well suited
for eliciting such challenges because of the complexity of the supply chains on
the one hand and the requirements imposed by emerging laws and regulations
on the other. However, they can be transferred to many other domains as well.
Thus, this contribution identifies 7 core challenges for data exchange and collec-
tion in complex distributed environments and also reviews approaches in place
to solve these challenges. Thereupon, future research in the area of adaptive
business process management can be aligned to extend existing approaches for
supporting more variability and dynamics in today’s business processes.
    Therefore, the fundamentals and an illustrating example are introduced in
section 2. Subsequently, seven data collection challenges are unveiled in section
3, exposing concrete findings, identified problems and derived requirements. In
section 4, the current state-of-the-art is presented based on its origin. Finally,
section 5 rounds out this paper giving a conclusion and an outlook.


2 Sustainable Supply Chains

This section elaborates on the domain of sustainable supply chains and gives
background information.

2.1 Fundamentals

In today’s globalized industry, the development and production of many products
is based on intransparent, complex supply chains with dozens of interconnected
companies distributed around the globe. To ensure and extend competitiveness,
complex communication tasks must be managed properly for effective and effi-
cient interorganizational processes. Generally, such cross-organizational collab-
oration involves a variety of different manual and automated tasks. Involved
companies significantly differ in size and industry background, and they use var-
ious different ISs, which are not able to intercommunicate easily. Due to this
heterogeneity, neither federated data schemes, unifying tools nor other concepts
can be realistically introduced without considerable effort [1].
    As sustainability is is an emerging trend, companies even face a new challenge
in their supply chains: sustainable development and production. The incentives
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).




                                                                                         75
are given by two parties: On one hand, legal regulations, increasingly issued by
authorities, force companies to publish more and more sustainability indicators
(like greenhouse gas emissions in production or gender issues) on an obligatory
basis. On the other hand, public opinion and customers compel companies to
provide sustainability information (e.g., organic food) as an important base for
their purchase decisions.
    Examples include ISO 14000 standard for environmental factors in pro-
duction, GRI2 covering sustainability factors or regulations like REACH3 and
RoHS4 . Overall, sustainability information involve a myriad of different indica-
tors. It relates to social issues (e.g., employment conditions or gender issues),
to environmental issues (e.g., hazardous substances or greenhouse gas (GHG)
emissions), or to managerial issues (e.g., compliance issues).
    There already exist tools at market providing support for the management
and transfer of sustainability data: IMDS5 (International Material Data Sys-
tem), for instance, is used in the automotive industry and allows for material
declaration by creating and sharing bills of materials (BOM). A similar system
exists for the electronics industry (Environ BOMcheck6 ). Despite providing use-
ful support in basic data declaration and exchange tasks, these tools clearly fall
short in providing dedicated support for the sustainability data collection and
exchange along the supply chains.

2.2 Illustrating Example

To illustrate the complexity of sustainability data collection processes in a dis-
tributed supply chain, we provide an example. The latter was composed with the
problems and requirements provided by SustainHub’s partner companies for the
automotive and electronics industry by formal and informal surveys and inter-
views. Please mind that data collection in such a complex environment does not
have the characteristics of a simple query. It is rather a varying, long-running
process incorporating various activities and involving different participants.
    The example illustrated in Fig. 1, depicts the following situation: Imposed by
regulations, an automotive manufacturer (requester) has to provide sustainabil-
ity data considering its production. This data is captured by two sustainability
indicators, one dealing with the greenhouse gas emissions relating to the pro-
duction of a certain product, the other addressing the REACH regulation. The
latter concerns the whole company as companies usually declare compliance to
that regulation on a company basis.
    To provide data regarding these two indicators, the manufacturer has to
gather related information from his suppliers (answerer). Hence, it requests a
2
  Global Reporting Initiative: https://www.globalreporting.org
3
  Regulation (EC) No 1907/2006: Registration, Evaluation, Authorisation and Re-
  striction of Chemicals
4
  Directive 2002/95/EC: Restriction of (the use of certain) Hazardous Substances
5
  http://www.mdsystem.com
6
  https://www.bomcheck.net




                                                                                     76
 Process: Request 1
                                                                                Collect                                                          Provide
                   Check for          Find / Select       Submit Data                            Approve Data
                                                                               Requested                                   Sign Data            Requested
                 available Data       Right Contact        Request                                 Request
                                                                                 Data                                                             Data

 Process Parameters
  Requester                                Answerer 1          Answerer 2      Answerer 3       Indicator: GHG Reference: BoM          Indicator: Reach     Reference:
                        Available Data
  Preferences:                             Approval            Approval        Approval            Emissions    – 2 Positions             Compliant         Company X
                        Completeness
  Completeness                             Processes           Processes       Processes
                        Quality                                                                 Validity date: 1    Standard: ISO       Due date: 2       Verification:
  Quality                                  Systems             Systems         Systems
                        Validity period                                                               year             14064           months in future Legal statement
  Validity                                 Platforms           Platforms       Platforms
                                           Formats             Formats         Formats                                    Request 1                              Request 2

 Process: Request 2
                                                                      Approve Data
                                                                        Request
                                    Check for
                                                                                                     Convert Data
                                  available Data
                                                                      Approve Data
                                                                        Request
                                                                                                                                             Integrate Data



                                                                                                              Collect
                            Check for          Find / Select         Submit Data         External
                                                                                                            Rrequested
                          available Data       Right Contact          Request           Assessment
                                                                                                               Data


                                                               Start Event     End Event        AND Gate              XOR Gate             Activity            Subprocess




                               Fig. 1: Examples of Two Data Collection Processes


REACH compliance statement from one of its suppliers. To get the information,
the activities shown in the process Request 1 have to be executed. Furthermore,
the product for which the greenhouse gas emissions shall be indicated has a BoM
with two positions coming from external suppliers. Thus, the request, depicted by
the second workflow, has to be split up into two requests, one for each supplier.
    Hence, the basic scenario involves a set of activities as part of the data collec-
tion processes. Some of these are common for the requests, e.g., on the requester
side, checking available data that might satisfy the request, selecting the com-
pany and contact person, and the submitting the request. On the answerer side,
data must be collected and provided. The other process activities are specifically
selected for each case. Thereby, the selection of the right activities is strongly
driven by data (process parameters) coming from the requester, the answerer,
the requests and indicators, and possible already available data.
    For example, Request 1 implies a legally binding statement considering
REACH compliance. Therefore, a designated representative (e.g., the CEO) must
sign the data. In many cases, companies have special authorization procedures
for releasing of such data, e.g., that one or more responsible persons have to
approve the request (cf. two parallel approval activities (Approve Data Request)
at Request 2, four-eyes-principle). In some cases, data may be already avail-
able in a company and does not have to be manually gathered (cf. Request 2,
Check of available Data). However, every time the company-internal format of
the answerer does not match the requester’s one, a conversion must be applied.
Further, some indicators and requests also directly relate to a given standard
(e.g., ISO 14064 for greenhouse gases) where this can directly trigger an assess-
ment of the answerer if he cannot exhibit the fulfillment of the standard (cf.
Request 2, External Assessment).




                                                                                                                                                                             77
    Finally, another important aspect for often long-running data collection pro-
cesses is that process parameters might change over time and, hence, exceptional
situations could occur. Even in this very simple example, many variations and
deviations might occur: for example, if the CEO was not available, activity Sign
Data could be delayed. In turn, this might become a problem if there are defined
deadlines for the query answer.


3 Data Collection Challenges
Following first insights provided in Section 2, this section presents seven concrete
challenges for an information system supporting sustainability data collection
processes along a supply chain (IS-DCP). The results are based on findings from
case studies conducted with industrial partners in the SustainHub project. Three
figures serve for illustration purposes: Fig. 2 illustrates data collection challenges
(DCC) 1 and 2, Fig. 3 illustrates DCC 3 and 4, and Fig. 4 illustrates DCC 5-7.


                                                          Challenge 1: Selection




                                                           Challenge 2: Access




           Requester     Answerer   Service Provider   Human       Data Storage    Application




                       Fig. 2: Data Collection Challenges 1 and 2




3.1 DCC 1: Dynamic Selection of Involved Parties

Findings Sustainability data collection in a supply chain involves various par-
ties. A single request may depend on the timely delivery of data from different
companies. For manual tasks, this mostly has to be done by a specific person with
sustainability knowledge or authority. In big companies, it can be even difficult
to find the right contact person to answer a specific request. In relation, contact
persons may change from time to time. Furthermore, as the requested data is
often complex, has to be computed, or relates to legal requirements, external
service providers may be involved in the data collection request as well. Finally,
regarding the timely answering of a request, many requests are adjusted and
forwarded to further suppliers (cf. Fig. 2) – thus answering times can multiply.




                                                                                                 78
Problems The contemporary approach to such requests heavily relies on indi-
viduals conducting manual tasks and interacting individually. There are tools
(e.g., email) which can provide support for some of these and partly automate
them. However, much work is still coordinated manually. As a request can be
forwarded down the supply chain, it is quite difficult to predict, who exactly will
be involved in its processing. Resulting from that, answering times of requests
can be hardly estimated in a reliable manner as well.
Requirements An IS-DCP need to enable companies to centrally create and
manage data collection requests. Thereby, it must be possible to simplify the
dynamic selection process of involved parties and contact persons regarding the
request answerers as well as potentially needed service providers. This is a ba-
sic requirement for enabling efficient request answering, data management, and
monitoring.

3.2 DCC 2: Access to Requested Data

Findings In a supply chain different parties follow different approaches to data
management. Big companies mostly have implemented a higher level of automa-
tion while SMEs heavily rely on the work of individual persons. Furthermore,
sustainability reporting is a relatively new area and a unified reporting method
is not implemented along supply chains. This implies great variability when
it comes to accessing companies’ internal data. Some companies have advanced
software solutions for their data management, some manage their data in generic
databases, some store it in specific files (e.g., Excel), and some have even not
started to manage sustainability data yet.
Problems The contemporary approach to sustainability reporting is managed
manually to a large extend. This involves manual requests from one party to
another and different data collection tasks on the answerer side. This can impose
large delays in data collection processes as sustainability data must be manually
gathered from systems, databases or specific files before it can be compiled,
prepared and authorized in preparation to the delivery to the requester.
Requirements An IS-DCP must accelerate and facilitate the access to re-
quested sustainability data. On the one hand, this includes guiding users in
manual data collection as well as automizing data-related activities (e.g., data
approval, data transformation) as far as possible. On the other hand, automatic
data collection should be enabled whenever possible. This involves accessing the
systems containing the data automatically (e.g., via the provision of appropriate
interfaces) and including such activities with manual approval activities when
needed. Finally, data conversion between different formats ought to be supported
as a basis for data aggregation.

3.3 DCC 3: Meta Data Management

Findings The management and configuration of sustainability data requests
in a supply chain relies on a myriad of different data sets. As aforementioned,




                                                                                      79
this data comes from various sources. Examples of such parameters include the
preferences of the requester as well as the answerers (including approval processes
and data formats) or the properties of the sustainability indicators (e.g., relations
to standards) (cf. Fig. 3). As a result, potentially matching data might be already
available in some cases but exposing different properties as requested.
Problems As requests rely on heterogeneous data, they are difficult to man-
age. Requirements are partially presumed by the requester and often implicit.
Hence, answerers might be unaware of all requirements and deliver data not
matching them. Moreover, it is difficult to determine whether data, which has
been collected before, fits the requirements of a new request. Finally, as a supply
chain might involve a large number of requesters and answerers, this problem
multiplies as crucial request data is scattered along the entire supply chain.
Requirements To be able to consistently and effectively manage data collection
processes, an IS-DCP must centrally implement, manage and provide an under-
standable meta data schema addressing relevant request parameters. Thereby,
instanced data based on the uniform meta data schema can be effectively used
to directly derive and adjust variants of data collection processes.


                   Challenge 3: Meta Data                      Query    1                        Meta Data
                                                              Query 1
                                                            Request 1                            Available Data
               Meta Data
               Requester Data
                                                                                                 Meta Data
                                                                                                 Request Data
               Meta Data
                                        Query Variant
                                       Request Variant 11                    Query Variant
                                                                            Request Variant 22
               Answerer Data
                                                                                                 Meta Data
                                                 Challenge 4: Request                            Situational Data
                                                       Variants


                      Fig. 3: Data Collection Challenges 3 and 4




3.4 DCC 4: Request Variants

Findings As mentioned, sustainability data exchange in a supply chain in-
volves a considerable number of different manual and automated tasks aligned to
the current data request. Hence, execution differs greatly among different data
requests, highly influenced by parameters and data and distributed on many
sources (cf. DCC 3 and Fig. 3). Moreover, the reuse of provided data is problem-
atic as well as the reuse of knowledge about conducted data requests: persons
in charge, managing a data collection, might not be aware of which approach
matches the current parameter set.
Problems This makes the whole data collection procedure tedious and error
prone. Based on the gained insights, to each data request a data collection pro-
cess is manually defined initially, and evolves stepwise afterwards. Relying on
the various influencing parameters, every request has to be treated individu-
ally – there is no applicable uniform approach to a data request, instead a high




                                                                                                                    80
number of variants of data collection processes exist. So far, there is no sys-
tem or approach in place that allows structuring or even governing such varying
processes along a supply chain.
Requirements An IS-DCP needs not only to be capable of explicitly defining
the process of data collection. Due to the great variability in this domain, it must
also be capable of managing numerous variants of each data request relating
to a given parameter set. This includes the effective and efficient modeling,
management, storage and executing of data collection request processes.

3.5 DCC 5: Incompleteness and Quality

Findings Sustainability data requests are demanding and their complex data
collection processes evolve based on delivered data and forwarded requests to
other parties (i.e., suppliers of the suppliers) (cf. Fig. 4). Furthermore, they
are often tied to regulative requirements and laws as well as involve mandatory
deadlines. Therefore, situations might occur, in which not all needed data is
present, but the request answer must still be delivered due to a deadline. As
another case, needed data might be available, but on different quality levels
and/or in different formats.
Problems Contemporary sustainability data collection in supply chains is
plagued by quality problems relating to the delivered data. Not only that re-
quests are incompletely answered, the requester also has no awareness of the
completeness and quality of the data stemming from multiple answerers. More-
over, answerers have no approach to data delivery in place when being unable
to provide the requested data entirely, or their data does not match the re-
quest’s quality requirements. Missing a unified approach, definitive assertions or
statements to the quality of the data of one request can often not be made and
requests might even fail due to that fact.
Requirements An IS-DCP must be able to deal with incomplete data and
quality problems. It must be possible that a request can be answered despite
missing or low quality data. Furthermore, such a system must be able to make
assumptions about the quality of the data that answers a request.


                       Challenge 6: Monitoring                              Challenge 5: Quality
                Requester                    Feedback
                                                                Request 1          Feedback   Sub-Request 1-1
                                        Feedback


                                 Feedback               Request 2                Feedback     Sub-Request 1-2
                      Feedback

                                                                                                     Deviation 3

        Request 4                      Request 3

               Deviation 2                      Deviation 1

                                            Challenge 7: Variability


                                 Fig. 4: Data Collection Challenges 5-7




                                                                                                                   81
3.6 DCC 6: Monitoring

Findings Sustainability data collection along the supply chain involves many
parties and logically may take a long time. The requests exist in many variants
and the quality and completeness of the provided data differ greatly (cf. DCC 5).
The contemporary approach to such requests does not provide any information
about the state of the request to requesters before the latter is answered (cf.
Fig. 4). This includes missing statements about delivered data as well as the
intermediate requests along the supply chain. If request processing is delayed
at the side of one or more answerers, the initial requester cannot access such
information without huge effort.
Problems As a requester has no information about the state and potential
data delivery problems of his requests, problems only become apparent when
deadlines are approaching. However, at that time, it is mostly too late to apply
countermeasures to low quality, incomplete data, or answerers that simple deliver
no data at all.
Requirements An IS-DCP must be capable of monitoring complex requests
spanning multiple answerers as well as various different manual and automatic
activities. A requester must have the option to get actively or passively informed
about the state of the activities along the data collection process as well as the
state of the delivered data.

3.7 DCC 7: Run Time Variability

Findings Data collection requests can take a long time to answer as they dynam-
ically involve a great number of different parties. Further, they expose manual
and automatic activities, different kinds of data and data formats, and various
unforeseen influences on the data collection process. This implies that param-
eters, applied at the beginning of the request influencing data collection, may
change during the run time of a data collection process. Exceptional situation
handling occurs as a result of expiring deadlines or answerers not delivering data.
Problems The variability relating to sustainability data collection processes
constitute a great challenge for companies. Running requests might become in-
validated due to the aforementioned issues. However, there is no common sense
or standard approach to this. Instead, requesters and answerers must manually
find solutions to still get requests answered in time. This includes much addi-
tional effort and delays. Another issue are external assessments: they could not
only be delayed but also completely fail, leaving the answerer without a required
certification. The final problem touched by this example concerns mostly long-
running data collection processes: data, that was available at the beginning of
the query, could get invalid during the long-term process (e.g., if it has a defined
validity period).
Requirements An IS-DCP must cope with run-time variability occurring in
today’s sophisticated sustainability data collection processes. As soon as issues
are detected, data collection processes must be timely adapted to the changing
situation in order to keep the impact of these issues as considerable as possible.




                                                                                       82
This requests a system which is able to dynamically adapt already running data
collection processes without invalidating or breaking the existing process flow.


4 State of the art
This section gives insights on the state of the art in scientific approaches relating
to the issues shown in this paper. It starts with a broader overview and proceeds
with more closely related work including three subsections.
    Section 3 underlines that exchanging data between different companies along
a supply chain in an efficient and effective way has always been a challenge.
Nonetheless, this exchange is not only necessary—it is now a crucial success fac-
tor and a competitive advantage, these days. However, many influencing factors
hamper the realization of a data exchange being automated and homogeneous.
In particular for those companies aiming to address holistic sustainability man-
agement, the inability to implement automated and consistent data exchange is
a big obstacle. Please remind that these companies need to take into account
existing and even emerging laws as well as regulations requesting to gather and
distribute information about their produced goods. Furthermore, that requested
information need be gathered from their their suppliers as well. Hence, complex
data collection processes, involving a multitude of different companies and sys-
tems, have to be designed, conducted, and monitored to ensure compliance. So
far, we could not locate any related work that completely addresses the afore-
mentioned challenges (cf. Section 3).
    For complex data collection processes, IS support in the supply chain is de-
sirable supporting communication and enabling automated data collection. The
importance and impact of an IS for supply chain communication has already
been highlighted in literature various times. In [2], for instance, a literature re-
view is conducted showing a tremendous influence of ISs on achieving effective
SCM. The authors also propose a theoretical framework for implementing ISs
in the supply chain. Therefore, they identify the following core areas: strate-
gic planning, virtual enterprise, e-commerce, infrastructure, knowledge manage-
ment, and implementation. However, their findings also include that great flex-
ibility in the IS and the companies is necessary and that IS-enabled SCM often
requires major changes in the way companies deal with SCM. As another exam-
ple, [3] presents an empirical study to evaluate alternative technical approaches
to support collaboration in SCM. These alternatives are a centralized web plat-
form, classical electronic data interchange (EDI) approaches, and a decentralized,
web service based solution. The author assesses the suitability of the different
approaches with regard to the complexity of the processes and the exchanged
information. Concluding, the relating work in this area shows or evaluates novel
approaches to SCM management, which are, however, mostly theoretic, very
general, and not applicable to the specific topic of sustainability data collection
processes.
    As automation can be a way to deal with various issues for sustainability
data collection, various approaches addressing that topic can be found in litera-




                                                                                        83
ture. However, none of them applies to the domain and specific requirements of
sustainable supply chain communication. For example, [4] presents an approach
to semi-automatic data collection, analysis, and model generation for perfor-
mance analysis of computer networks. The approach incorporates a graphical
user interface and a data pipeline for transforming network data into organized
hash tables and spread sheets for usage in simulation tools. As it primarily deals
with a specific type of data transformation, it is not suitable in our context.
Such approaches deal with automated data collection; yet they are not related
to sustainability or SCM and the problems arising in this setting.
     There also exist approaches addressing sustainability reporting (e.g., [5],
[6],[7], and [8]). However, they do not suggest technical solutions for automatic
data collection. They rather address the topic theoretically by analyzing the
importance of corporate sustainability reporting, evaluating sustainability indi-
cators or the process of sustainability reporting as a whole, or aiming at building
a sustainability model by analyzing case studies.
     Besides approaches targeting generic sustainability, SCM and data collection
issues, there are three closer areas that are mainly related to our problem state-
ment and issues. As discussed, sustainability data collection processes involve
numerous tasks to be orchestrated. Data requests may exist in many different
variants based on a myriad of different data sources and may be subjected to dy-
namic changes during run-time (cf. DCC 7). This sub-section reviews approaches
for process configuration (Section 4.1), data- and user-driven processes (Section
4.2), and dynamic processes (Section 4.3).

4.1 Process Configuration

Behaviour-based configuration approaches enable the process modeler to specify
pre-defined adaptations to the process behaviour. One option for realizing this
is hiding and blocking as described by [9]. By blocking, this approach allows
disabling the occurrence of a single activity/event. The other option enabled by
this approach is hiding enabling a single activity to be hidden. That activity is
then executed silently but succeeding activities in that path are still accessible.
    Another way to enable process model configuration for different situations is
to incorporate configurable elements into the process models as described in [10]
or [11]. An example of this approach is a configurable activity, which may be
integrated, omitted, or optionally integrated surrounded by XOR gateways. An-
other approach enabling process model configuration is ADOM [12] that builds
on software engineering principles and allows for the specification of guidelines
and constraints with the process model. A different approach to process config-
uration is taken by structural configuration, which is based on the observation
that process variants are often created by users by simply copying a process
model and then applying situational adaptations to it. A sophisticated approach
dealing with such cases is Provop [13], which enables process variants by storing
a base process models and pre-configured adaptations to it. The later can also
be related to context variables to enable the application of changes matching to




                                                                                      84
different situations. Finally, [14] provides a comprehensive overview of existing
approaches targeting process variability.
    Process configuration approaches are a promising option to the problem pre-
sented in this paper. Nevertheless, that approaches do not completely match
the requirements for flexible data collection workflows in such a dynamic and
heterogeneous environment, as many different data sources must be considered
and request can be subjected to change even while they are running.

4.2 Data- and User-driven Processes

In contrast to classical process management approaches focusing on the sequenc-
ing of activities, the case handling paradigm [15] focuses on the objective of the
process that is called case. In relation, the product-based workflow approach
focuses on the interconnection between product specification and derived work-
flows [16]. The Business Artifacts approach [17] is a data driven methodology
that focuses on business artifacts rather than activities. These artifacts hold the
information about the current situation and thus determine how the process shall
be executed. In particular, all executed activities are tied to the life-cycle of the
business artifacts. Another data-driven process approach is provided by Core-
Pro [18]. It enables process coordination based on objects and their relations.
In particular, it provides a means for generating process structures out of the
object life cycles of connected objects and their interactions. The creation of con-
cepts, methods, and tools for object- and process-aware applications is the goal
of the PHILharmonic Flows framework [19]. Thus, flexible integration of busi-
ness data and business processes shall be achieved and the limitations known
from activity-centered Workflow Management Systems shall be overcome.
    The approaches shown in this sub-section facilitate processes that are more
user- or data-centric and aware. The creation of processes from certain objects
could be interesting for SustainHub, however in the dynamic supply chain envi-
ronment processes rather rely on context parameters than objects and are also
continuously influenced by their changes while executing.

4.3 Dynamic Processes

In current literature, there are two main options for making the automatically
supported execution of workflows dynamic: Normal, imperative workflows that
are dynamic or adaptive or constraint based declarative workflows that are less
rigid by design. This sub-section briefly reviews both kinds of approaches starting
with adaptive imperative workflows.
    Adaptive PAIS have been developed that incorporate the ability to change a
running process instance to conform to a changing situation. Examples of such
systems are ADEPT2 [20], Breeze [21], WASA [22], and SPADE [23]. All of
these only permit manual adaptation carried out by a user. An important issue
in this case is that the exceptional situations leading to the adaptation can occur
more than once. In that case, knowledge about the previous changes should be
exploited to extend effectiveness and efficiency of the current change [24][25].




                                                                                        85
    In case a human shall apply the adaptations, approaches like ProCycle [26]
or CAKE2 [27] aim at supporting him with that knowledge. In the situation
described in this paper, these approaches are not suitable since the creation
and adaptation of process instances has to incorporate various potentially new
information and has to be applied before humans are involved or incorporate
knowledge the issuer of a workflow does not possess. Automated creation and
adaptation of the data collection workflows will be favourable. In this area,
only a small number of contemporary approaches exist, like AgentWork [28]
and SmartPM [29] Unfortunately, these are limited to rule based detection of
exceptions and application of countermeasures.
    As mentioned before, another way to enables flexibility into workflows is
by specifying them in a declaring way. By such specification, a strict activity
sequencing is not rigidly prescribed. Instead of this, a number of different con-
straints can be used to specify certain facts that the workflow execution must
conform to. This could be the mutual exclusion of two activities or a sequencing
relation between two distinct activities. Based on this, all activities specified can
be executed at any time as long as no constraint is violated. Examples for such
approaches are DECLARE [30] and ALASKA [31]. However, such approaches
have specific shortcomings relating to understandability. Furthermore and even
more important in our context, if no clear activity sequencing is specified, all ac-
tivities relating to monitoring are difficult to satisfy and monitoring is a crucial
requirement for the industry in this case.


5 Conclusion
This paper motivated the topic of sustainability data exchange along supply
chains to subsequently present core challenges as well as state of the art in this
area. We have clearly identified seven core challenges for today’s data collection
processes based on intensive interaction with our SustainHub partners most of
them relating to variability issues. Especially, design time as well as run time
flexibility are clear requirements for any approach supporting companies aim-
ing at sustainable development and production. The presented challenges can
serve as starting point for applications developed to support today’s compli-
cated supply chain communication. The challenges are expressed in terms of
sustainability data collection, however they describe generic problems that may
occur in many domains. Thus the results can be easily transferred and be used
for other domains. There exists a substantial amount of related work in differ-
ent areas touching these topics. Yet, none of these approaches or tools succeeds
in providing holistic support for the process of sustainability data exchange in
a supply chain. The support of data collection requests and processes along
today’s complex supply chains is a challenge in the literal sense. Nonetheless,
SustainHub is actively working on a process-based solution to deal with, and
successfully manage the high variability occurring during design and run time.
Future work will describe the exact approach, combination of technologies, and
the architecture of the system to cope with the aforementioned challenges.




                                                                                        86
Acknowledgement
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).


References
 1. Fawcett, S.E., Osterhaus, P., Magnan, G.M., Brau, J.C., McCarter, M.W.: Infor-
    mation sharing and supply chain performance: the role of connectivity and willing-
    ness. Supply Chain Management: An International Journal 12(5) (2007) 358–368
 2. Gunasekaran, A., Ngai, E.W.T.: Information systems in supply chain integration
    and management. European Journal of Operational Research 159(2) (2004) 269–
    295
 3. Pramatari, K.: Collaborative supply chain practices and evolving technological
    approaches. Supply Chain Management: An International Journal 12(3) (2007)
    210–220
 4. Barnett, P.T., Braddock, D.M., Clarke, A.D., DuPré, D.L., Gimarc, R., Lehr, T.F.,
    Palmer, A., Ramachandran, R., Renyolds, J., Spellman, A.C.: Method of semi-
    automatic data collection, data analysis, and model generation for the performance
    analysis of enterprise applications (2007)
 5. Singh, R.K., Murty, H.R., Gupta, S.K., Dikshit, A.K.: An overview of sustainability
    assessment methodologies. Ecological indicators 9(2) (2009) 189–212
 6. Ballou, B., Heitger, D.L., Landes, C.E.: The Future of Corporate Sustainability
    Reporting: A Rapidly Growing Assurance Opportunity. Journal of Accountancy
    202(6) (2006) 65–74
 7. Adams, C.A., McNicholas, P.: Making a difference: Sustainability reporting, ac-
    countability and organisational change. Accounting, Auditing & Accountability
    Journal 20(3) (2007) 382–402
 8. Pagell, M., Wu, Z.: Building a more complete theory of sustainable supply chain
    management using case studies of 10 exemplars. Journal of Supply Chain Man-
    agement 45(2) (2009) 37–56
 9. Gottschalk, F., van der Aalst, W.M.P., Jansen-Vullers, M.H., La Rosa, M.: Con-
    figurable workflow models. Int. J. Cooperative Inf. Syst. 17(2) (2008) 177–221
10. Rosemann, M., van der Aalst, W.M.P.: A configurable reference modelling lan-
    guage. Information Systems 32(1) (2005) 1–23
11. La Rosa, M., van der Aalst, W.M.P., Dumas, M., ter Hofstede, A.H.M.:
    Questionnaire-based variability modeling for system configuration. Software and
    System Modeling 8(2) (2009) 251–274
12. Reinhartz-Berger, I., Soffer, P., Sturm, A.: Extending the adaptability of reference
    models. IEEE Transactions on Systems, Man, and Cybernetics, Part A 40(5)
    (2010) 1045–1056
13. Hallerbach, A., Bauer, T., Reichert, M.: Configuration and management of process
    variants. In: Int’l Handbook on Business Process Management I. Springer (2010)
    237–255
14. Torres, V., Zugal, S., Weber, B., Reichert, M., Ayora, C., Pelechano, V.: A qual-
    itative comparison of approaches supporting business process variability. In: 3rd
    Int’l Workshop on Reuse in Business Process Management (rBPM 2012). BPM’12
    Workshops. LNBIP, Springer (September 2012)




                                                                                           87
15. van der Aalst, W.M.P., Weske, M., Grünbauer, D.: Case handling: A new paradigm
    for business process support. Data & Knowledge Engineering 53(2) (2004) 129–162
16. Reijers., H.A., Liman, S., van der Aalst, W.M.P.: Product-based workflow design.
    Management Information Systems 20(1) (2003) 229–262
17. Bhattacharya, K., Hull, R., Su, J.: A data-centric design methodology for business
    processes. In: Handbook of Research on Business Process Management. IGI (2009)
    503–531
18. Müller, D., Reichert, M., Herbst, J.: A new paradigm for the enactment and
    dynamic adaptation of data-driven process structures. In: CAiSE’08. Volume 5074
    of LNCS., Springer (2008) 48–63
19. Künzle, V., Reichert, M.: PHILharmonicFlows: towards a framework for object-
    aware process management. Journal of Software Maintenance and Evolution: Re-
    search and Practice 23(4) (June 2011) 205–244
20. Dadam, P., Reichert, M.: The ADEPT project: A decade of research and de-
    velopment for robust and flexible process support - challenges and achievements.
    Computer Science - Research and Development 23(2) (2009) 81–97
21. Sadiq, S., Marjanovic, O., Orlowska, M.: Managing change and time in dynamic
    workflow processes. Int. J Cooperative Information Systems 9(1&2) (2000) 93–116
22. Weske, M.: Formal foundation and conceptual design of dynamic adaptations in
    a workflow management system. In: Proc. Hawaii Int’l Conf on System Sciences
    (HICSS-34). (2001)
23. Bandinelli, S., Fugetta, A., Ghezzi, C.: Software process model evolution in the
    SPADE environment. IEEE Transactions on Software Engineering 19(12) (De-
    cember 1993) 1128–1144
24. Lenz, R., Reichert, M.: IT support for healthcare processes - premises, challenges,
    perspectives. Data and Knowledge Engineering 61(1) (2007) 39–58
25. Minor, M., Tartakovski, A., Bergmann, R.: Representation and structure-based
    similarity assessment for agile workflows. In: Proc. ICCBR’07. (2007) 224–238
26. Weber, B., Reichert, M., Wild, W., Rinderle-Ma, S.: Providing integrated life
    cycle support in process-aware information systems. Int’l Journal of Cooperative
    Information Systems 18(1) (2009) 115–165
27. Minor, M., Tartakovski, A., Schmalen, D., Bergmann, R.: Agile workflow tech-
    nology and case-based change reuse for long-term processes. Int’l J. of Intelligent
    Information Technologies 4(1) (2008) 80–98
28. Müller, R., Greiner, U., Rahm, E.: AgentWork: A workflow system supporting
    rule–based workflow adaptation. Data & Knowledge Engineering 51(2) (2004)
    223–256
29. Lerner, B.S., Christov, S., Osterweil, L.J., Bendraou, R., Kannengiesser, U., Wise,
    A.E.: Exception handling patterns for process modeling. IEEE Trans. Software
    Eng. 36(2) (2010) 162–183
30. Pesic, M., Schonenberg, H., van der Aalst, W.M.: Declare: Full support for loosely-
    structured processes. In: Enterprise Distributed Object Computing Conference,
    2007. EDOC 2007. 11th IEEE International, IEEE (2007) 287–287
31. Weber, B., Pinggera, J., Zugal, S., Wild, W.: Alaska simulator toolset for conduct-
    ing controlled experiments on process flexibility. In: Information Systems Evolu-
    tion. Springer (2011) 205–221




                                                                                          88