Content uploaded by Reinhard Schütte
Author content
All content in this area was uploaded by Reinhard Schütte on Nov 14, 2017
Content may be subject to copyright.
BUSINESS-TO-BUSINESS-PROCESS INTEGRATION:
FUNCTIONS AND METHODS
Jörg Becker, Michael Rosemann, Reinhard Schütte
Department of Information Systems,
University of Muenster, Germany
Abstract
We have developed a framework for intercorporate information models.
Information models build the basis for information systems as well as for the
design of organisational process in enterprises. Because of several business
partners being involved it is difficult to assure the consistency of the information
models in terms of syntactical and semantical correctness. In this paper, we
present "Guidelines of Modeling (GoM)" that contain conventions to improve
the correctness, consistency, and comparability of information models. We focus
on the integration of processes between producers and retailers. The integration
of information systems between producers and retailers requires frameworks of
the information systems on each side. Out of these, we present the H-model as
an architecture for retail information systems and show some of the integration
potential between the retail information system and the IS of the producer.
1 INTRODUCTION
This paper presents a framework for business-to-business-process
integration, focusing on the improvement of the value chain between industrial
companies and retailing corporations. We suggest to describe the connection
between suppliers and retailers by information models. Therefore having the
opportunity to integrate information systems and not just implement specific
structures of an electronic data interchange format. The information models
form the design specification for information systems that tie together industrial
and retailing corporations.
After a glimpse at an architecture for retail information systems and the
necessary connections to the supplier’s information system, we present
methodical aspects to build information models that are the basis for
information systems used by retailers and producers. Thus, the analysis goes
beyond the specification of electronic data interchange formats as given by the
EDIFACT (electronic data interchange for administration, commerce, and
transport) standard.
The use of high quality information models increases the consistency of the
information systems applied by the producer and the retailer. This can
significantly improve the performance of the activities in the value chain
between producers and retailers. For example, setting up an invoice by the
producer and checking the same invoice by the retailer is just doubling a task. If
there is an integration between the information systems of the two business
partners - and not only a data interchange - one of the identical tasks can be
eliminated. Apart from a pure exchange of data, our approach encompasses the
development of a consistent nomenclature and handling of business processes.
2 PROCESS DESIGN BETWEEN RETAIL AND INDUSTRIAL
CORPORATIONS
The implementation of enterprise-wide approaches, such as the realization of
a higher process orientation, demands the integration of information systems. In
contrast to the traditional perspective that focuses on processes within the
enterprise, business-to-business considerations in general and processes between
retailing and industrial enterprises in detail become increasingly important.
Even though the necessity to design the value chain of the enterprise is well
known, two factors prevail the current discussion about this topic:
• State of the art and current developments of information and communication
systems
Due to the opportunities of modern information technology, transaction costs
between industry and retail enterprises can be reduced [ClRe93]. Electronic
commerce and related topics will have a major impact on the value chain of an
enterprise. The use of electronic data interchange (EDI) [Pfei92], as a
prerequisite for inter-organisational systems, or the use of electronic markets
(market-like structures and processes which are displayed in an electronic way
[Bako91]) are examples of topics related to electronic commerce.
• The commitment to vertical cooperation
The need for a process design that spans across corporations leads to an
increased commitment to vertical cooperation. However, when looking at inter-
organisational concepts, common values have to be made clear, that is, a
perspective is necessary that focuses on a network of several companies, not
only on one single co-operating enterprise [Klei96].
In this study, we define a process as a self-contained, temporal and logical
sequence of those functions which are necessary to handle a business relevant
object. These process objects can be information objects, such as the order, the
delivery note, and the invoice, as well as material objects, such as the
merchandise or the recyclable packaging material.
Business processes have a special position within the design of inter-
company processes. The business processes (as a specific type of processes)
usually reflect the different types of an enterprises businesses, thus resulting
from the company’s objectives, and have interfaces to external business
partners. Typical business processes for retail corporations are the "classical"
retailing (procurement, warehousing, distribution), third-party orders,
settlements, sales promotion, and customer service [BeSc96, 15ff.]. In the
classical retailing process, the retailing company fulfils planning tasks, the
logistics, and the "money-related" (invoice, payment) tasks between producer
and customer. In third-party orders, the logistics is performed directly between
supplier and customer without involving the retailing company. In the
settlement process, the retailing company acts in a similar way as a bank, only
being involved in the "money-related" tasks (invoice, payment, eventually
delcredere).
In all cases, the retailing corporation acts as an intermediary between
supplier and customer; processes can be streamlined by harmonising the
business data and integrating the functions. Here, we will focus on the
integration between suppliers and the retailing company.
The integrated view of the business processes of retail and industrial
enterprises requires appropriate information systems. On the part of industrial
enterprises, the logistics is handled by manufacturing resource planning systems
(MRP II-systems). MRP II-systems consist of the planning of the production
program, the materials management and the time and capacity management
[Sche94].
The counterpart to MRP II-systems on the producer side are merchandise
information systems on the retailer side. While some definitions of a
merchandise information system are more purpose-oriented, others focus on its
basic components, such as ZENTES, where "the functions of a merchandise
information system cover disposition, order management, coverage of incoming
merchandise (goods receipt), cash register handling and inventory as well as
merchandise-related evaluations and reports" [Zent91, 69; MaME94, 109]. A
focus that is more process oriented leads us to the following definition:
A merchandise information system controls the merchandise-oriented
planning, logistical and money related processes performed within the business
processes of a retail company [BeSc96, 13]. Within the procurement process, a
merchandise information system covers the tasks contracting, order
management, goods receipt, invoice auditing and the accounts payable. Within
the distribution process, the merchandise information system handles the
functions of marketing, selling, goods issue, billing and accounts receivable.
The task of warehousing, also part of the merchandise information system, is to
form a bridge between these two processes.
Because of the graphical arrangement of the tasks to be fulfilled in retail
business, the framework is referred to as "H-model" (BeSc 1996, see fig. 1, right
hand side).
The merchandise information system itself is part of the retail information
system. The retail information system also encompasses the business
administration systems with the components general accounting and asset
management, cost accounting and human resources. The controlling, the
executive informations, and the strategic planning system (EIS) (the "roof" of
the "H") support the management functions. They are built on aggregated data
derived from the atomistic data of the merchandise information system and the
business administration systems.
Especially between the procurement process of retail companies, as it is
shown in the left branch of the Handels-H-Model, and the planning of the
production program within the process of the industrial corporation, various
information exchanges take place. These exchanges can be improved by process
integration (see fig. 1, left hand side).
The procurement of retail companies is heavily controlled by sales data, i.e.
the data generated at the POS can be used to automatically generate an order (a
change from push- to pull-principle). Other examples for interdependencies are:
• Market surveys available to retail corporations are needed by industrial
corporations for the creation of appropriate marketing strategies. The supply
with retail data for industrial corporations supports the improvement of
production and quantity planning, thus resulting in a smooth flow of material
from industrial companies via retail enterprises to the customer.
• A high degree of interdependency can be found within the sales planning of
industrial corporations and the assortment planning of retail companies. The
exchange of related informations can help to speed up the processing time
and to reduce the degree of uncertainty.
• Within operational processes industrial and retail functions are like two sides
of a mirror and, therefore, offer some starting points for process integration
(the outgoing order of the retailing company is identical to the incoming
Figure 1. An architecture for retail information systems [BeSc96, 14] and
exemplary information exchange between industrial and retailing
corporations
order of the industrial company, goods issued of the vendor correspond to
goods received of the retailer, an invoice of the industrial corporation
corresponds to a rated delivery note of the retail corporation etc.). The
identity of the processes and their contents allows the elimination of one of
the two corresponding activities. The supply of information to be processed
by one system has to be generated by the other system (see section 3).
3 COST REDUCTION POTENTIAL THROUGH THE INTEGRATION OF
PROCESSES BETWEEN RETAIL AND INDUSTRIAL CORPORATIONS
Theory and practice see the specific value of the process orientation in
overcoming functional boundaries. The view of a process does not end at the
borders of an institution (even though nowadays processes within one company
are the focus of attention). The design of processes between retail and industrial
corporations offers considerable economical potentials. The cost of the
distribution of one merchandise makes up approximately 10% of the turnover at
retail prices [Zent94]. A process design across different levels of the value chain
has been proposed within the concepts of Efficient Consumer Response
[Ritt95], Quick Response [Hens91], Supply Chain Management [Houl92;
OlWe92; Holl95] and mainly focuses on the fields of product development,
order management control, data exchange and administration. With the help of
these concepts, the aforementioned cost of distribution could be reduced to
7.5 % [Zent94] or even to 6.6 %[CoRe94] of the turnover at retail prices, thus
allowing a cost reduction of 25 % resp. 34 %. Even if the figures are not exact,
considerable savings of the costs occuring between vendors and retailing
companies are possible.
4 CATEGORIES AND AIMS OF PROCESS INTEGRATION
On an abstract level, we will have a look at integration from two viewpoints:
the category of integration, which is unification or connection, and the aim of
integration, which is elimination of functions or realisation of degression
effects.
Integration by unification, generally spoken, combines two existing elements
in one new element and therefore reduces the number of elements and relations
within the system as a whole (here: consisting of retail and industrial
corporations).
Integration by connecting creates a system of elements and/or subsystems,
that were not (or not sufficiently) connected so far, but show logical
correspondences.
Furthermore, two different objectives can be pursued by process integration.
The objective of the ideal case is the elimination of functions in order to reduce
the processing time through the reduction of process elements and interfaces.
An elimination of functions is possible, if similar functions are identified within
the process and one of those functions can be eliminated without reducing the
overall efficiency of the process. In contrast to this, the objective of realising
economies of scale is much more expenditure oriented. Economies of scale can
be utilised through the centralisation of previously separated tasks. Thereby, the
number of process objects concurrently passing through the process increases
and the overall number of process instantiations is reduced.
Integration by connecting with the aim of utilising economies of scale can be
achieved, e.g., if the merchandise data is set up once by the industrial
corporation and then supplied to all retailers. In this case, the effort to maintain
the merchandise data is reduced to the input of company-specific attributes for
single articles.
An example for the type of process integration by unification is a delivery
that is billed by the industrial corporation, while the retail company gives up the
valuation of the incoming merchandise. The IT-realization of this concept
involves the transmission of the data that led to the billing by the industrial
corporation. The valuation of the delivery note and invoice auditing are no
longer necessary, thus leading to the elimination of redundant functions within
the whole business process. In this case, it is necessary to identify the analogy of
the partial processes valuation of the supplier’s delivery note (within the retail
company) and valuation of the customer’s delivery note (within the industrial
corporation).
A field closely related to process integration is process structure integration,
where processes with structural analogies are unified [Rose96]. This kind of
integration can also be differentiated in connection and unification.
Process structure integration by unification leads, e.g., to a utilisation of
economies of scale if the central department of the retail company takes over the
procurement for all branches. In this case, the same function (order management
of merchandise for decentralised customers) is no longer carried out
decentralised by every branch but centralised by the headquarter. A connecting
process structure integration supports the elimination of functions. This is
possible if the industry takes over the procurement according to the sales data
provided by the retail company. In this case the decentral order management of
the branches and the central procurement department of the headquarter are
removed.
Interdependencies between retail and industrial corporations can be
considered in different ways. In addition to the coupling of systems, an interface
system can provide a connection between systems. A technical realisation of
such a system - regardless of how it is disposed - has the integration on the
foundation of information models as a precondition. The integration of process
models has the advantage of taking into account all different aspects of
integration. Therefore, this kind of integration is likely to be more persistent
than the more technically focused approaches.
5 METHODICAL PROBLEMS OF PROCESS MODEL INTEGRATION
Process models are immaterial (mostly semi-formal) images of the logical
and temporal order of functions performed on a process object. They are the
foundation for the operationalisation of process-oriented approaches (e. g.
Business Process Reengineering, Process Innovation, Workflow-Management,
Activity Based Costing). The conceptual foundation of process integration
across company borders requires an integration of the underlying process
models (process structure integration). Even though the integration of data
models (view integration [BaLN86]) has been a field of research for more than a
decade and first approaches for the modelling of data transfer across company
borders do exist, only a few papers were presented on the inter- and intra-
company integration of process models, respectively. The approach of PRIEMER
[Prie95] integrates process models and aims at evaluating the applicability of
standard software on the foundation of semi-formal models. Based upon an
object-oriented approach, EMBLEY ET AL. [EMKW92] discuss the integration of
process models without giving a theoretical foundation. In the following, the
main areas of conflict regarding the integration of process models shall be
pointed out. As an exemplary method the event-driven process chains [Sche94]
are used to put the results in concrete terms. The procedure is based upon
approaches for data model integration.
Fundamental precondition for avoiding naming, type and structural conflicts
discussed in the next chapter is the agreement on common conventions by the
participating companies. This shows the necessity for design recommendations
for information modeling that go beyond basic syntactical rules. A framework
for a system of more systematic recommendations has been introduced with the
"Guidelines of Modeling (GoM)" [BeRS95, BeSc96, Rose96]. The guidelines of
modeling form a framework that goes beyond the rules given through specific
modeling techniques (e.g. entity relationship modeling for data, event-driven
process chain modeling for processes). They help to improve the quality of
models and to combine models that are built for the same function (e.g. invoice
auditing) from two different views (e.g. data view and process view). The six
guidelines are: guideline of correctness, of relevance, of economic efficiency, of
clarity, of comperability and of systematic design (BeSc96, p. 82). The
following remarks line out the principle of comparability, which is one of the
important guidelines considering the integration between vendors and retailers.
5.1 Naming conflicts
Already in a single company, the meaning of specific terms is understood
differently by several persons. Expressions like cost efficiency, gross margin,
net price, space efficiency lead to different associations among different people.
The difficulty arises especially, when several business partners are involved.
Therefore, prior to the integration of models, it has to be made sure that the
designation of an information object uniquely reflects its meaning as well as its
associations. In the following, the most common defects of language are
discussed: synonyms and homonyms.
A synonym can be found if two or more linguistic expressions share the
same meaning. Compared to process model integration within one company, the
dual perspective on the processes during the course of process model integration
between different companies (retail company and industrial company) offers an
additional source for synonyms. For example the process object "outgoing
order" is called "incoming order" by the receiving business partner. The
existence of synonyms involves the danger of not recognising equivalent objects
(unintended redundancies).
A homonym results from the ambiguity of a linguistic element. In its context,
the meaning of a homonym is unique, but not because of its notion alone. For
example the basic term "disposition" is used differently in retail and industrial
enterprises. While in industrial corporations, the term disposition is used for
material requirements planning (MRP), in retail corporations disposition
includes especially the order management.
The determination of synonyms asks for an analysis of different terms with
identical meaning and associations. A recommended process in linguistics is the
so-called component analysis, where the meaning of a term is described by its
semantic characteristics (attributes). In order to apply the component analysis to
event-driven process chains, events and functions have to be classified. This
classification provides additional information for the analysis of linguistic
defects, and, therefore, enables a more detailed analysis than it would be
possible with the use of the notion of the linguistic element alone. Further hints
about potential synonyms can be found by tracing similar structures embedding
information objects with different names (concept likeness) [BaLe84]. The
elimination of identified synonyms is performed by subsuming the synonyms
under a new term that may be one of the synonym terms or a completely new
term (e.g. customer for the terms market and branch).
Identified, but not yet resolved homonyms contradict the guideline of clarity,
because the notion of the term can be determined depending on the user and the
context, but not in general. A potential indicator for the identification of
homonyms in process models are information objects with the same term that
are embedded in different structures (concept unlikeness). They are resolved
through the selection of new, context-independent terms. Homonyms are easier
to avoid than synonyms, because the difference is in the term itself, not in its
meaning or associations (e.g. department as a logical summary of a product
category or as an organisational unit).
In the following, we propose conventions for naming information objects.
For the unique designation of a process object, a data model may be referenced
if applicable, thus utilising its harmonising effect. Synonyms and homonyms
among the process objects should already be identified before modelling the
process. In the following, the determined process object terms are set
recommendations for the process models to be created. However, the
determination of the general naming of the functions is more difficult. When
using integrated standard software in an enterprise-wide environment, the
vocabulary of the software should be used. Table 1 shows dedicated naming
conventions for the most common function types. Terms in italics are variables,
terms in brackets are optional. The active imperative for the naming of functions
is recommended because it emphasises the normative character of a process
model as a medium for the design of organisations (e. g. ‘move transport
packing’ instead of ‘transport packing is moved’).
Table 1. Dedicated naming conventions for selected function types
Naming
convention
Example/explanation
Check, whether
process object meets
condition
"Check, whether the supplier already exists in the
information systems"
Attention should be paid to unique conditions, i.e. that
the above phrase is to be preferred to the phrase
"check, whether sender of delivery is known". In
contradiction to a comparison only one process object
is changed here. Especially, if the adjacent events
show no dichotomy, phrases like "check, who..." and
"check, how..." should be used.
Also: examine, control, re-examine, re-count, re-
calculate, review, inspect
Compare process
object 1 with process
object 2
"Compare delivery note with outgoing order"
Two active process objects are compared. Eventually
changes to both objects are necessary.
Also: equalise, adjust, match
Correct process object
[facts]
"Correct invoice by discount"
The declaration of the facts is necessary only if there
are alternative changes.
Also: change, rectify, revise
Create process object
"Create order"
Also: set up, install, generate
Transport process
object [by medium]
[from source] to
destination
„Transport delivery note by messenger from goods
receipt to invoice auditing“
The specification of the medium (e-mail, pneumatic
post, messenger etc.) is only to be made in case of
alternatives. The source should be specified if the
process object is to be fetched, i.e. the source is not
responsible for the transfer.
Also: move, pass on, forward, send, carry, deliver
For the naming of events, triggering and providing events have to be
distinguished. Especially in pure sequences, the naming of the respective
function should be an orientation for the naming of the event (e.g. "Enter return
of empties" -> "Return of empties is entered"). The naming of the event should
be consistent and complete compared to the naming of the functions. Providing
events indicate the end of a function and should be described as "process object
+ be + past participle" (e.g. "invoice is corrected"). Trigger events are named as
"process object + be + to-infinitive" (e.g. "merchandise has to be returned",
"invoice has to be corrected"). In contrast to functions, events carry designations
in the passive voice to reflect their character as representatives of an information
object’s state.
5.2 Type conflicts
A type conflict can be located if the same fact is represented by two models
through different methodical concepts. These conflicts are resolved by a
syntactic restructuring that is based on normative recommendations for a
preferred type. In the following, an alternative use of operators is given as an
example.
The demand for minimality is particularly important if a certain style of
modeling is preferred. In this case minimality is interpreted as the reduction of
the number of used operators. The "classical" connectors of the event-driven
process chain (AND, exclusive OR (XOR) and inclusive OR (IOR)) have been
chosen, because they depict the most common kinds of connections, and their
incoming and outgoing connectors need no marking. In figure 2, three
alternative models are shown. They show two parallel branches of which one is
optional and one mandatory. Alternatives 1 and 2 illustrate this case with the use
of four connectors. In alternative 3 the IOR-connector is enhanced with a mark
(1=100%) for the mandatory branch. In this case it is called IOR1-connector.
This example shows that even basic cases can be modelled in different ways,
therefore, the need for a convention concerning this problem arises. The
decision, whether alternative 3 is the preferred alternative depends on the
subjective preference for a complex model (number of information objects) over
a complicated model (number of different information objects) and vice versa.
5.3 Structural conflicts
Structural conflicts arise if the process models to be integrated depict the
same facts using different semantics. This is a violation of the guideline of
(semantic) correctness.
Structural conflicts can be resolved in three ways that are not equivalent:
• The most appropriate solution is resolving the conflict through a competent
co-worker of the participating companies. He judges the models according to
the level of semantic correctness and only the correct part - if applicable - is
integrated into the final model. This alternative demands the availability of
an appropriate person during the process of integration. Due to a lack of
competence, however, not all of the conflicts may immediately be resolved.
• In the course of the disjunctive composition, the conflicts are integrated into
the final model and connected via an XOR-operator. This part of the model
has to be marked as to be revised and the process of integration can be
continued. The conflict has "to be resolved" through the participation of a
person before the final model is used for explanatory or design purposes.
Figure 2. The IOR1-connector and modeling alternatives
• The third alternative is the resolution through abstraction. Compared to the
models in conflict, generalised information objects are integrated into the
final model. If one model proposes the function "forward sales data via disk"
whereas the other model proposes the function "forward sales data via e-
mail", the final model contains the function "forward sales data via
electronic media". Similar to the disjunctive composition, this conflict has to
be resolved before the final model is used for the first time.
An important element in avoiding type and structural conflicts is the use of
predefined model components that can be divided into structural components
and reference components. Structural components are well defined structures
without content, e.g., the iteration, while reference components offer a
predefined content, e.g., the six-eyes-principle. With the help of these
components, a company’s headquarter could give its branches predefined
processes for the storage of merchandise or for the accounting of cost and
maintain these processes through a central process owner.
After the resolution of the described conflicts the process models can be
integrated by connecting as well as by unifying.
6 SUMMARY AND OUTLOOK
A consistent process-oriented design of the value chain has to have an
optimisation perspective across the borders of companies, if the intention is the
rationalisation of the whole system. The reference models for retail companies
designed in the project MEGAHANDEL form the background for the problems
that are described in this paper. In this connection, two aspects have to be
pointed out. From a methodical point of view, the Guidelines of Modeling have
to be applied and extended in order to replace the ex-post resolution of conflicts
with an ex-ante integration. This has to be seen especially against the
background of the need of a process integration based on information models.
The rising number of co-operations on time (virtual enterprises) emphasises this
demand. From a functional point of view not only the economical benefits of
process integration, but the social and strategic consequences of integration (e.g.
loss of core competencies) have to be analysed as well in future research.
LITERATURE
[Bako91] Bakos, J. Yannis: A Strategic Analysis of Electronic Marketplaces.
In: MIS Quarterly, 15 (1991) 3, pp. 295-310.
[BaLe84] Batini, Carlo; Lenzerini, Maurizio: A Methodology for Data
Schema Integration in the Entity Relationship Model. In: IEEE
Transactions on Software Engineering, 10 (1984) 6, pp. 650-664.
[BaLN86] Batini, Carlo; Lenzerini, Maurizio; Navathe, Shamkant B.: A
Comparative Analysis of Methodologies for Database Schema
Integration. In: ACM Computing Surveys, 18 (1986) 4, pp. 323-
364.
[BeRS95] Becker, Jörg; Rosemann, Michael; Schütte, Reinhard: Grundsätze
ordnungsmäßiger Modellierung (GoM). In: Wirtschaftsinformatik,
37 (1995) 5, pp. 435-445.
[BeSc96] Becker, Jörg; Schütte, Reinhard: Handelsinformationssysteme.
Landsberg/Lech 1996.
[ClRe93] Clemons, E.K.; Reddi, S.P.: Some Propositions Regarding the Role
of Information Technology in the Organization of Economic
Activity. In: Nunamaker, J.F., Sprague, R.H. (Eds.): Proceedings
HICSS. Los Alamitos 1993.
[CoRe94] Supplier-retailer collaboration in supply chain management. The
Coca Cola Retail Research Group-Europe by GEA Consulenti
Associata di gestione aziendale. 1994.
[EmKW92] Embley, D. W.; Kurtz, B. D.; Woodfield, S. N.: Object-Oriented
Systems Analysis. A Model-Driven Approach. Englewood Cliffs
1992.
[Hens91] Hensche, H. H.: Zeitwettbewerb in der Textilindustrie: Das Quick
Response Konzept. In: Zentes, Joachim (Ed.): Moderne
Distributionskonzepte in der Konsumgüterindustrie. Stuttgart 1991,
pp. 275-309.
[Holl95] Holland, C. P.: Cooperative supply chain management: the impact
of interorganizational information systems. In: Journal of Strategic
Information Systems, 4 (1995) 2, pp. 117-133.
[Houl92] Houlihan, J. B.: International Supply Chain Management. In:
Christopher, M. (Ed.): Logistics - The Strategic Issues. London
1992, pp. 87-100.
[MaME94] Mason, J. Barry; Mayer, Morris L.; Ezell, Hazel F.: Retailing.
5th ed., Burr Ridge-Boston-New York 1994.
[OlWe92] Oliver, R.K.; Webber, M. D.: Suppy Chain Management: Logistics
Catches Up with Strategy. In Christopher, M. (Ed.): Logistics - The
Strategic Issues. London 1992, pp. 63-75.
[Pfei92] Pfeiffer, H. C.: The diffusion of Electronic Data Interchange.
Heidelberg 1992.
[Prie95] Priemer, Jürgen: Entscheidungen über die Einsetzbarkeit von
Software anhand formaler Modelle. Sinzheim 1995.
[Ritt95] Ritter, S.: Coorganisation - gesehen als ECR-Infrastruktur. In:
Coorganisation, (1995) 1, pp. 26-30.
[Rose96] Rosemann, M.: Komplexitätsmanagement in Prozeßmodellen.
Wiesbaden 1996.
[Sche94] Scheer, August-Wilhelm: Business Process Reengineering.
Reference Models for Industrial Enterprises. 2nd ed. Berlin et al.
1994.
[Zent91] Zentes, Joachim: „CIM“ und „global sourcing“. Dynamik im
Handel, 35 (1991) 7, pp. 69-74.
[Zent94] Zentes, Joachim: Supply Chain Management: Erfolgspotentiale
kooperativer Logistik. Dacos Anwenderforum Handel ’94.
Saarbrücken 1994.