# Supply Chain Integration for Sustainability Faces Sustaining ICT Problems

Hans Wortmann, Alex A. Alblas, Paul Buijs, Kristian Peters

► To cite this version:

Hans Wortmann, Alex A. Alblas, Paul Buijs, Kristian Peters. Supply Chain Integration for Sustainability Faces Sustaining ICT Problems. 20th Advances in Production Management Systems (APMS), Sep 2013, State College, PA, United States. pp.493-500, 10.1007/978-3-642-41263-9_61 hal-01449762

HAL Id: hal-01449762

https://inria.hal.science/hal-01449762

Submitted on 30 Jan 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Supply chain integration for sustainability faces
sustaining ICT problems

J.C. (“Hans”) Wortmann, A.A. Alblas, P. Buijs, K. Peters

Faculty of Economics and Business, University of Groningen,
P.O. Box 800 9700 AV Groningen
http://www.rug.nl/staff/j.c.wortmann/

**Abstract.** This paper is concerned with the role of supply chain management in sustainable operations. It argues that sustainability requires increased supply chain co-ordination using ICT for product life cycle management. Accordingly, the paper researches integration problems in supply chains due to ICT. It addresses the question, why operational decisions are hardly based on integrated information in supply chains. It argues that several current information/ communication technologies are essentially heterogeneous. Therefore, it is not easy to integrate these. The paper distinguishes (1) transactional systems (2) real-time monitoring/control systems (3) decision support systems (4) analytical systems. Integration problems should be studied by analysing the underlying characteristics of the technology.

**Keywords.** ICT, sustainability, supply chain integration

## 1 Introduction

Information systems and information technology plays a key role in sustainable supply and return of goods. When companies want to prove that materials are acquired in a socially responsible way, they need information systems. When returning products have to be refurbished, these products have to be identified by suitable information systems. When companies want to perform a Life cycle Analysis (LCA), they are dependent on correct and appropriate information systems.

Moreover, the focus on supply chains and return networks requires interoperability of supply chain partners’ information systems. Because of the fact that these partners change dynamically, the real requirement is that interoperability can be realized “on the fly” with hardly any human effort.

Current practice in supply and distribution networks is far away from this ideal. Despite of considerable investments in all kinds of ICT, the real decision makers are still deciding by rules of thumb based on flawed information, rather than by up-to-date, correct and complete information. Apparently, there are still many ICT applications which are difficult to integrate, even in a single company. This phenomenon is
the basis for the research question to be addressed in this paper: *What makes ICT
applications essentially different, creating sustaining integration problems?*

In answering this research question, the researchers first of all corroborated their assumption, that supply chain decision makers are indeed facing heterogeneous systems. For this corroboration, in-depth interviews were held nine cross-docking firms. Section 2 reports about the findings. Section 3 presents an applications typology, based on the findings of Section 2. This leads to a characterization of heterogeneity (and therefore, difficulty in integration) which is elaborated in Section 4. Section 5 concludes the paper.

2 Information used by operational decision makers in
manufacturing and freight logistics

After case studies in manufacturing (De Snoo et al., 2011) and distribution (Meyer
et al. 2010), we had to conclude that it is apparently difficult for operational planners
of goods flows to use scheduling systems. In order to understand better, what consti-
tutes the problems of these planners, it was decided to proceed with more detailed
studies.

Transportation is an essential part of supply chains and distribution networks of
physical goods. Therefore, we decided to organize detailed interviews with 9 distribu-
tion companies in The Netherlands who were engaged in cross docking operations.

The results of these interviews can be summarized as follows. While managers of
these operations considered the investments in operational ICT systems to be consid-
erable, the planners would typically not rely on the information provided by systems,
for the following reasons.

* First of all, planners could follow individual trucks via GPS systems on screens with maps, but these systems would not provide insight into causes of delays or expected problems. Accordingly the planners preferred to be called or mailed by drivers and be informed on the context, expected problems and potential solutions

* Second, the planners would not trust transactional systems (ERP systems, ware-
house management systems, distribution management systems), because these sys-
tems were not always up to date. This is also due to the fact that these systems are
not integrated with the GPS systems.

* Third, the planners would not trust their scheduling or decision support systems, because these systems are fed by the transactional systems. Moreover, these systems take a snapshot of the transactional systems, which may be bypassed by reality. Finally, constraints as perceived by the planners always differ from the constraints modeled in these systems.

From these interviews, it may be concluded that heterogeneity (GPS, Voice, trans-
actional, decision support) and varying time properties of data is indeed an issue in
practice. NB: these findings concentrate on operational decision problems.
# 3 Conceptualization

Our conceptualization of enterprise information systems and information technology is outlined below (see Fig. 1). Note, that the increase of technologies over the last decades leads to a situation where technologies such as streaming video are nowadays covered under the header of ICT, while in the past, video streams were not considered as ICT applications.

## 3.1 Real-time monitoring and control systems

Real-time *monitoring* systems observe the value of certain variables, using sensors, cameras, microphones, GPS systems etc. Such systems generate basically streaming data. Although streaming data may be technically discrete, they can be thought of as continuous. Streaming data can be used to measure the behavior certain variables (temperatures, pressures, noise, etc.). The streams are kept in log files.

Streaming data may be in a form which is suitable for human processing (video, audio, text) or in may be in a form which is suitable for machine processing (usually numerical data). The latter may be transformed into the former.

As is well known, real-time *control* systems are automated systems able to influence certain variables via actuators with the purpose to keep other variables close to a specified set point or trajectory.

Real-time data can be used to generate discrete transactions for transactional systems (see arrow 1 in figure 1). However, generating transactions is not trivial, as will be discussed in Section 4.1. Alternatively, such transactions are posted by humans (see arrow 2 in figure 1).

## 3.2 Transactional systems

Transactional systems keep track of the relevant objects of enterprises. Such objects are e.g. freight, trucks, drivers, containers, locations, customers, orders and so on. The essence of transactional systems is that objects have a state. The state of an object changes in discrete steps (transactions). For example, a truck has either arrived or not arrived at a location. The freight either has been loaded or has not been loaded. The customer has accepted the shipment or has not accepted the shipment. And so on for all relevant objects.

Transactional systems are not built to capture full history. At each point in time, these systems contain the actual state of each object. In other words, the systems cannot recast the past (other than a few days, needed for database recovery in case of disaster). Of course, such systems keep track of the past via log files and archives, but conceptually it is not possible to delete, query or update the history.

Transactional systems are based on classical databases, whether relational or object oriented. The essence of such databases is a clear separation between the schema and the instances, corresponding to the distinction between types and instances in programming languages. The knowledge at type level defines the attributes and methods applicable for an object instance. Accordingly, transactional systems have explicit
semantics as expressed in the database schema and in the business logic which is called when transactions are posted (these semantics and logic constitute an *ontology* in knowledge engineering parlance).

Finally, transactional systems are designed to be used primarily by humans. Although sometimes automatically generated transactions are applicable (see previous section), the primary goal is to inform humans on the state of affairs of objects relevant for the organization concerned.

<figure><img src="image_2.png" /><figcaption>Figure 1. Conceptualization of enterprise information systems</figcaption></figure>

## 3.3 Decision support systems

(Operational) decision support systems are systems which support operational decisions by software models. These models relate decisions to performance measures. In cross docking, such decisions allocate trucks to doors, they schedule trips, or they allocate shipments to trips. The models compute the best choices and provide advice to the decision makers, based on the state of relevant objects (shipments, orders, location of trucks, ...).

Decision support systems (DSS) have to take a snapshot of objects' states before they can start their calculations (see arrow 3 in figure 1). After such a snapshot, the decision maker may interact with the DSS to study trade-offs between different deci-
sions. The models may vary in their mathematical sophistication or in the level of detail. The “snapshot” data are usually kept in fast computer memory (RAM) during computation.

As indicated by arrow 3, the DSS models of objects are based on transactional information. In many cases, the transformation of transactional information into DSS information is not easy. These problems are discussed in more detail in section 4.3. Reversely, decisions taken may have to be stored as objects in the transactional systems (see arrow 4). This involves peculiar problems, also discussed in section 4.3.

## 3.4 Analytical systems

Analytical systems are data warehouses where information of objects of the same type are stored. These systems typically collect information from transaction processing systems over periods of time. Accordingly, they provide insight into the dynamics of (aggregations) of objects.

Analytical systems use databases which are based on Online Analytical Processing (OLAP) technology. OLAP databases are often represented as cubes, which can be seen as tables with an additional time dimension. The tables are in themselves organized at different levels of aggregation. These systems can be queried for all kinds of analysis, but unlike transactional databases it is not possible to navigate between related object types.

Analytical systems are nowadays in use as the basis for many management reports, especially for strategic and tactical decisions. For operational decisions, they are only incidentally used. Our investigation in practice did not reveal high usage at operational level. It has been included here for the sake of completeness.

Analytical systems retrieve their information from transactional systems either within the company (see arrow 6 in figure 1) or from external sources. Section 4.2 describes some difficulties in this transformation. There is usually no information flowing back from analytical systems to transactional systems, with the exception of e.g. forecasts. The problems encountered here are similar to those related to DSS.

The above systems and their distinguishing features are summarized in Table 1.

<table><caption>Table 1. Summary of information system features</caption><thead><tr><td>Type of system</td><td>Structured or un-structured?</td><td>Snapshot or time-varying?</td><td>Continuous or discrete data?</td><td>Main way of data storage</td></tr></thead><tbody><tr><td>Analytical systems</td><td>Structured</td><td>Past until now (aggregated)</td><td>Discrete (often in periods)</td><td>OLAP databases</td></tr><tr><td>Decision support systems</td><td>Structured</td><td>Snapshot and future</td><td>discrete</td><td>In-RAM storage</td></tr><tr><td>Transactional systems</td><td>Structured</td><td>snapshot</td><td>discrete</td><td>Relational or object-oriented</td></tr><tr><td>Real-time systems</td><td>Can be both</td><td>Past until now (detailed)</td><td>Continuous</td><td>Files</td></tr></tbody></table>
# 4 Integration problems between different types of systems

## 4.1 Integrating real-time systems and transactional systems

When data streams follow a structured format (e.g. by measuring known physical temperature, pressure, etc.), it is in principle possible to generate transactions for transactional systems, as depicted in figure 1 by arrow 1. Although this is possible, it is not trivial, for several reasons.

First of all, transactional systems are not designed to capture these streaming data, because these data are usually not meaningful as changing states of objects. Nobody is interested in the square meter where a truck resides at every other second. Rather, it is interesting to know if the truck arrives in time at its destiny, and whether it is able to load or unload; it is interesting to learn that the unloaded cargo is accepted by the next party; etc. This information is mostly still subject to human interpretation and therefore it still requires human data entry (arrow 2). The same holds for sensor data on equipment condition used in refurbishment decisions: it requires an explicit human decision to assess when to act.

Second, the usual differences in technical and syntactical standards between different IT applications will emerge. Although increasingly technology becomes available to generate interfaces, there is a long way to go before “plug-and-play” is reached.

Last but not least, there are always differences in semantics. One of the major sustainability challenges in the food industry is to decrease waste. Food may have a status “fresh” and a status “perished”, but also some intermediate states. The nature of the states and conditions under which a product proceeds through these states may differ between applications (e.g. fish differs from fruit). Therefore, sensor data are unlikely to match the semantic categories applicable in specific cases without dedicated programming effort.

Therefore, the conditions of streaming data leading to a transaction may be programmed (e.g. by software on a truck), but such software posting transactions is customer-specific and expensive to build and maintain. With current state of the art, it cannot be configured or installed “on the fly” in e.g. third-party trucks which happen to transport the cargo concerned. Similarly, in the context of refurbishment and sustainability, a product being maintained or disassembled will not be automatically reported to the OEM or upstream in the supply chain. Rather this requires a separate (manual) transaction, for which many things have to be arranged organizationally.

Accordingly, the first sustaining problem encountered in ICT integration resides between streaming data and transactional systems (see arrow 1 in figure 1).

NB. The above arguments apply à forteriori to non-structured data. It is clear that e.g. video streaming data cannot easily be integrated with other ICT applications such as transactional systems. Basically, humans have to look at video data or listen to audio data and capture meaning. Attempts to create automatic alerts from audio data (e.g. with voice recognition) are encouraging, but this does not mean that *in general* transactions can be posted in transactional systems without human intervention.
## 4.2 From transactional information to analytical information

Many decision makers will currently employ data warehouses for analysis of historical data or other time series. These data warehouses contain data of similar objects (e.g. sales data, quality control data or purchasing data) aggregated over certain dimensions such as time periods, geographies of market segments. The power of a data warehouse is that it enables quick drill down into data and/or slicing and dicing.

Analytical data are structured data, often based on transactional data from transactional systems; quite often, analytical data are generated for the archives of transactional systems. Because analytical data are derived from transactional data, they should both based on the same semantics (or ontology).

However, these semantics may yield problems. An obvious problem emerges when the semantics of a transactional system changes over time. In the context of supply chain management, the semantics of systems of different parties involved may also be different. For example, the notion of “sales figures” may be interpreted as “booked sales”, “invoiced sales” or “earned sales” by different systems.

In the context of sustainability, different interpretations of sustainability measures is a major problem. This is elaborated in Ingwersen and Stevenson (2012) where the term *product category rules* is used to denote standard values for environmental load calculated in LCA. The disadvantage of such standard is, that actual effort to reduce environmental load by companies is not acknowledged. Accordingly, there will be an ongoing debate on “numbers” related to sustainability issues in data warehouses.

We conclude that this *semantic heterogeneity* will be a sustaining problem in supply chains engaged in sustainability (see arrow labeled “6” in figure 1).

NB: some early work has been done to overcome semantic heterogeneity by automated semantic negotiations “on the fly”, see Van Blommestein (2007).

## 4.3 From transactional to decision support systems

In contrast to data warehouses, which contain aggregated data related to one type of objects in past or future periods of time, decision support models perform calculations to support specific decisions. In sustainable product development, LCA calculations typically represent decision support. In manufacturing, DSS often simulate the future across multiple objects. In Logistics, these systems support planning or scheduling of logistical operations.

In contrast to analytical data, the data for these decision support models is based on a *snapshot* of transactional data at a particular point in time (“now”). Obviously, the semantic heterogeneity problem also plays in the context of creating data for decision support models from transactional data. However, there is an additional issue for *operational* decision making problems. This is due to the fact that the time proceeds while decisions are being taken. At the same time when the snapshot is taken, new transactional information becomes available which may change the picture to some extent. Accordingly, the decision maker is forced to keep an eye on actual developments while using the DSS model and while to taking the first decisions in real time. No wonder that it is difficult to use such models (see arrow “3”).
A DSS calculating LCAs suffers from similar problems in timing and semantics. An LCA is based on a snapshot of product data. This DSS is full of assumptions on coefficients for sustainability performance (from handbooks or LCI databases). Genuine improvements in sustainability will affect these coefficients, but in the DSS software, it is very cumbersome to adjust such coefficients. Moreover, maintaining correct engineering data is a challenge in itself. Ideally, such DSS for LCA should be interactive and integrated with PLM and ERP systems.

# 5 Conclusion

In this paper, several sustaining problems in supply chain integration have been identified. These problems are inspired by future requirements to information systems from expected sustainability developments. These problems are:

* Creating automated transactions from streaming data (preferably "on the fly")

* Automated solution of heterogeneous semantics or ontologies between transactional systems and/or data warehouses and decision support systems

* Automated solution of the problem of changing snapshots for operational decision support systems

* Automated analysis of text and feedback of the results in enterprise systems.

# Acknowledgement

This work was sponsored by the IOP ICPR (NL Min. of Economic Affairs)

# References

F. van Blommestein: "Decentralized Metadata Development for Open B2B Electronic Business". In: *Interoperability for Enterprise Software and Applications* (eds. Morel, Müller), Springer, Berlin, 2007

W.W. Ingwersen and M. J. Stevenson: "Can we compare the environmental performance of this product with that one? An update on the performance of product category rules and future challenges towards alignment", *Journal of Cleaner Production* 24 (2012) pp. 102-108

G.G. Meyer, G.B. Roest and N.B. Szirbik: "Intelligent products for robust monitoring and control of road-based logistics", *Proc. 2010 IEEE Int. Conf. on Management and Service Science*, Wuhan, China, ICMSS 2010.5577852.

S. Seuring and M. Müller: "From a literature review to a conceptual framework for sustainable supply chain management", *Journal of Cleaner Production* 16 (2008) pp. 1699-1710

C. de Snoo, W. van Wezel, J.C. Wortmann and G.J.C. Gaalman: "Coordination activities of human planners during rescheduling: case analysis and event handling procedure", *International Journal of Production Research* 49, no.7 (2011), pp. 2101-2122