21
Appendix: Data Models ERP and SCM systems—and in fact most busi- ness information systems—are founded on data- bases. Therefore, data structures play an important role in the design and implementation of any ERP or SCM system. A data structure defines data elements and how these elements are related with each other. On a higher level, the term also comprises the relationships between different data structures, which are then called data objects or data enti- ties. Another term for this interpretation of “data structure” is “data model.” Data models are usually created before a data- base is implemented because data modeling—on a higher, nontechnical level of abstraction—is easier than directly creating the technical speci- fications needed for a database. When a data model is available, implementation of the data- base is largely straightforward. Among the most common data models are the entity-relationship model and the relational data model. So-called object-oriented data models and object models (class models) have also been proposed, along with object-oriented pro- gramming, but they are not as common in data- intense environments such as ERP and SCM. Entity-Relationship Model The most common data model in the require- ments stage—that is, the project stage in which the company’s requirements for the new system are captured (Kurbel 2008, pp. 236–243)—is the entity-relationship model (ERM). This model goes back to P.P. Chen (1976). It is a semi- graphical model that includes semantics and uses diagrams to visualize the relationships between data. Therefore, many people use the term entity-relationship diagram (ERD) as a syn- onym for entity-relationship model. Although Chen’s basic concepts were quite powerful, many real-life modeling situations proved to be more complex than what the origi- nal model was capable of describing. This is why many model extensions have been proposed over the years. Unfortunately, they are not standar- dized. Therefore, we will briefly summarize the modeling elements that are used in this book. Basic concepts of the entity-relationship model include entities, relationships, and attri- butes. An entity can be any object of the real world that is of interest to the modeler, for example, a product, a machine, or a customer. Entities can also represent abstract things, such as a quota- tion, an order, or a transportation lane. Since a data model is usually created to describe general matters and relationships, and not specific objects and their relationships, we usually consider entity types (e.g., “supplier,” material”) rather than individual instances (“Gerber Inc.,” “turbo char- ger”). In an ER diagram, entities or entity types are represented by rectangles. A relationship connects two specific entities. On the level of entity types, the connections can also be regarded as types. In this case, we speak of a relationship type, meaning the type of rela- tionship that exists between the two entity types involved (e.g., “provides”). Relationships and relationship types are represented by diamonds. An attribute indicates a property of an entity or a relationship, for example, a name, a project number, or an address. Important attributes are K.E. Kurbel, Enterprise Resource Planning and Supply Chain Management, Progress in IS, DOI 10.1007/978-3-642-31573-2, # Springer-Verlag Berlin Heidelberg 2013 337

Appendix: Data Models978-3-642-31573-2/1.pdf · fications needed for a database. When a data model is available, implementation of the data-base is largely straightforward. Among

  • Upload
    others

  • View
    1

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Appendix: Data Models978-3-642-31573-2/1.pdf · fications needed for a database. When a data model is available, implementation of the data-base is largely straightforward. Among

Appendix: Data Models

ERP and SCM systems—and in fact most busi-

ness information systems—are founded on data-

bases. Therefore, data structures play an

important role in the design and implementation

of any ERP or SCM system.

A data structure defines data elements and

how these elements are related with each other.

On a higher level, the term also comprises the

relationships between different data structures,

which are then called data objects or data enti-

ties. Another term for this interpretation of “data

structure” is “data model.”

Data models are usually created before a data-

base is implemented because data modeling—on

a higher, nontechnical level of abstraction—is

easier than directly creating the technical speci-

fications needed for a database. When a data

model is available, implementation of the data-

base is largely straightforward.

Among the most common data models are the

entity-relationship model and the relational datamodel. So-called object-oriented data models

and object models (class models) have also

been proposed, along with object-oriented pro-

gramming, but they are not as common in data-

intense environments such as ERP and SCM.

Entity-Relationship Model

The most common data model in the require-

ments stage—that is, the project stage in which

the company’s requirements for the new system

are captured (Kurbel 2008, pp. 236–243)—is the

entity-relationship model (ERM). This model

goes back to P.P. Chen (1976). It is a semi-

graphical model that includes semantics and

uses diagrams to visualize the relationships

between data. Therefore, many people use the

term entity-relationship diagram (ERD) as a syn-onym for entity-relationship model.

Although Chen’s basic concepts were quite

powerful, many real-life modeling situations

proved to be more complex than what the origi-

nal model was capable of describing. This is why

many model extensions have been proposed over

the years. Unfortunately, they are not standar-

dized. Therefore, we will briefly summarize the

modeling elements that are used in this book.

Basic concepts of the entity-relationship

model include entities, relationships, and attri-

butes.

An entity can be any object of the real world

that is of interest to the modeler, for example, a

product, a machine, or a customer. Entities can

also represent abstract things, such as a quota-

tion, an order, or a transportation lane.

Since a data model is usually created to describe

general matters and relationships, and not specific

objects and their relationships, we usually consider

entity types (e.g., “supplier,” material”) rather than

individual instances (“Gerber Inc.,” “turbo char-

ger”). In an ER diagram, entities or entity types

are represented by rectangles.

A relationship connects two specific entities.

On the level of entity types, the connections can

also be regarded as types. In this case, we speak

of a relationship type, meaning the type of rela-

tionship that exists between the two entity types

involved (e.g., “provides”). Relationships and

relationship types are represented by diamonds.

An attribute indicates a property of an entity

or a relationship, for example, a name, a project

number, or an address. Important attributes are

K.E. Kurbel, Enterprise Resource Planning and Supply Chain Management,Progress in IS, DOI 10.1007/978-3-642-31573-2, # Springer-Verlag Berlin Heidelberg 2013

337

Page 2: Appendix: Data Models978-3-642-31573-2/1.pdf · fications needed for a database. When a data model is available, implementation of the data-base is largely straightforward. Among

usually noted down inside ovals and connected

with a rectangle or a diamond through a line.

Some attributes play a special role, as they are

used to uniquely identify an entity or a relation-

ship (e.g., “supplier-ID”). These attributes are

called key attributes (or keys). In an ER diagram,

they are usually underlined.

Figure A.1 illustrates the basic concepts of

entity-relationship modeling with the help of a

simple example. The upper part of the figure

contains an ER diagram showing entity and rela-

tionship types. The lower part provides sample

entities and how they are related. For example,

the “Gerber Inc.” entity of the “supplier” type is

connected with the “turbo charger” entity of the

“material” type through a particular relationship,

which is characterized, among other things, by a

price of 650.00 €.

Cardinalities (also called complexities) are

used to specify the relationships between two

entity types A and B more precisely. A cardinal-

ity indicates how many objects of type B an

object of type A can be related with. Basic car-

dinalities are:

• 1:1 relationship: An object of type A is

related with exactly one object of type B and

vice versa.

• m:1 relationship: An object of type A can be

related with several objects of type B, while

an object of type B can be related with only

one object of type A.

• 1:n relationship: An object of type B can be

related with several objects of type A, while

an object of type A can be related with only

one object of type B.

• m:n relationship: An object of type A can be

related with several objects of type B. An

object of type B can be related with several

objects of type A.

The relationship displayed in Fig. A.1 is an m:

n relationship. This means that a particular sup-

plier can provide several materials and a particu-

lar material can be obtained from more than one

supplier. An assumption underlying the model is

that the purchase prices have been negotiated

with the suppliers, meaning that the same mate-

rial can have different prices. For this reason, the

price is an attribute of the relationship type and

not of any of the entity types involved.

Different notations exist for representing car-

dinalities (and also, relationship types) in an ER

diagram. The notation used in Fig. A.1 can be

interpreted as follows: The number of individual

relationships an entity of type A can have with

entities of type B is noted down between the A

rectangle and the diamond. Our example thus

says that a particular supplier can be related

with n materials, while m suppliers can provide

a particular material.

If the company had the policy of purchasing

each material exclusively from one of the sup-

plier, the cardinality would have to be changed

Supplier Provides Material

Supplier-ID Companyname

Material-IDPrice Materialname

n m

... ...

Entities Relationships Entities

48159-01 Gerber Inc. Dallas, USA

48143-05 BB Motors Berlin, Germany

15230-11 Viadrina AG Frankfurt,Germany

89131-01 Miller plc London, UK

A-2233 Turbo charger 10 5

A-2457 Windshield 43 8

A-4711 Radiator 23 8

B-5221 Carburetor 77 16

D-1001 Bumper 3 5

X-9899 Wheel rim 1201 200

650.00

675.00 373.50

373.50

395.95

Fig. A.1 Entity-relationship diagram (example)

338 Appendix: Data Models

Page 3: Appendix: Data Models978-3-642-31573-2/1.pdf · fications needed for a database. When a data model is available, implementation of the data-base is largely straightforward. Among

from an m:n to an m:1 cardinality. In this case,

“price” is an attribute of “material,” because it no

longer depends on the relationship.

It is worth mentioning that in Chen’s original

work, cardinalities were noted down on the oppo-

site sides. In the example of materials provided by

one supplier only, “1” would be written between

the diamond and the “supplier” entity type and

“n” between the diamond and the “material”

entity type. This notation is known as look-across

cardinality (in contrast to look-here cardinality as

used above).

Since it is a matter of convention, readers

trying to understand ER diagrams should check

which notation the author applied. This book

uses the look-here cardinality type.

The simple cardinalities described so far are

sufficient for sketching data structures during the

initial stages of requirements engineering but are

not precise enough for implementing a database.

Min–max cardinalities provide a better way of

expressing issues that would otherwise remain

ambiguous. Consider, for example, the “provides”

relationship above. What exactly does “m” mean?

Does the relationship type allow, for example, that

suppliers do not provide any material (i.e., does it

include 0)?

In order to make things unambiguous, min–

max cardinalities specify the precise minimum

and maximum numbers of permissible relation-

ships. In most cases, the inequalities

0 � min � 1 � max ��

hold, with “*” standing for “many.” Although

min and max can be any integer numbers,

depending on the context, typical min-max car-

dinalities are (0, 1), (0, *), (1, 1), and (1, *).

Suppose we want to model the case that a

material stored in the database requires at least

one supplier assigned to it. On the other hand,

suppliers may be stored in the database even if

they do not provide any material. This can be the

case, for example, when a material has been dis-

carded but the company wants to keep the supplier

data in the database for the future. Then the cardi-

nality on the “supplier” side is (0, *), and on the

“material” side, it is (1, *), as shown in Fig. A.2.

Connectors are symbols connecting two or

more entity types with a relationship type using

logical operators (“and,” “or,” “xor”). In Fig. A.3,

which models relationships between managers

and the entities they are managing, a manager

may be heading both a department and a project.

If, however, the company wants their managers to

be responsible either for a department or a project,

but not for both, the “or” connector would have to

be replaced by an “xor” connector.

Generalization means that similar types of

entities are combined under a superordinate

type. The opposite is specialization, meaning

that a general entity type is split up into more

specialized types. The reason for doing so is

often to maintain the common attributes with

the general entity type, while the attributes in

which the subtypes differ are kept with the

specialized types.

Supplier Provides Material(0, ) (1, )

Fig. A.2 Min–max

cardinalities (example)

Manager Heads

Project

Department

or

Fig. A.3 A logical

connector (example)

Appendix: Data Models 339

Page 4: Appendix: Data Models978-3-642-31573-2/1.pdf · fications needed for a database. When a data model is available, implementation of the data-base is largely straightforward. Among

A common way of representing generalization

and specialization is to use a particular relation-

ship type called an “is a” relation. The meaning

of this term is obviously that an object of any of

the specialized types is also an object of the

general type.

Figure A.4 illustrates generalization and spe-

cialization with the help of an example. The

general type here is “business partner,” while

the specializations include “customer,” “sup-

plier,” and “bank.” Since all business partners

have a name and an address, these common attri-

butes are assigned to the “business partner”

entity type. However, describing customers also

requires different attributes than describing sup-

pliers or banks. For example, outstanding debts

and credit rating are meaningful attributes for a

customer but not for a supplier or a bank. Regard-

ing a supplier, the allowed payment period would

be more useful, and regarding a bank, it would be

the credit line.

In order to make the ERM in Fig. A.4 more

accurate, logical connectors can be included.

One possible ambiguity is that the model does

not specify whether an entity can be both a cus-

tomer and a supplier or whether a bank can also

be a customer. With the help of logical connec-

tors, these matters can be precisely defined. The

extended example modeled in Fig. A.5 shows a

case where a business partner can be a customer

and also either a supplier or a bank at the same

time. Note that the “is a” type of relationship has

been written on the connecting line to avoid

multiple triangles with different semantics.

It is worth mentioning that there are more

ERM concepts than the ones described above.

Among these are important concepts such as

weak, strong, and dependent entity types and

aggregation. Since these concepts have not been

used in the ER diagrams of this book, they are not

explained here.

Relational Data Model

The entity-relationship model is useful when

nontechnical people are involved, because it pro-

vides a good overview and is easy to understand.

ER modeling is common, for example, in

requirements engineering when the relevant

data structures have to be identified.

However, an ERM is not a model that can be

directly implemented in a database management

system (DBMS). The reason for this is that

DBMSs organize their data structures according

to different data models. The most common of

these models is the relational data model (alsoknown as relational model). Therefore, an entity-

relationship model has to be mapped onto a rela-

tional model before it can be implemented.

The most fundamental notion of the relational

data model is “relation.” This is a mathematical

Business partner

is a

Companyname

Address

SupplierCustomer Bank

Outstandingdebts

Creditrating

Paymentperiod

Creditline

Fig. A.4 “Is a”

relationship (example)

340 Appendix: Data Models

Page 5: Appendix: Data Models978-3-642-31573-2/1.pdf · fications needed for a database. When a data model is available, implementation of the data-base is largely straightforward. Among

term and not to be confused with the term “rela-

tionship” in the ER model.

To briefly explain the mathematical concept

of a relation, consider an object that can be

described by n different attributes Aj:

Aj ¼ aijji ¼ 1; . . . ; mj

� � 8 j ¼ 1; . . . ; n

mj is the number of values attribute Aj can

have. Attributes are the same as in the ER model

(e.g., material-ID, material name, on stock, safety

stock). Thus, the object can be represented as an

n-tuple composed of entries aij, each one repre-

senting a value of one of the attributes Aj:

ai1; ai2; . . . ; ainð Þ:

Each attribute Aj has a domain D, which is theset of all possible values the attribute can take on:

D Aj

� � ¼ faijg:

The Cartesian product over the domains of

the attributes contains all possible combinations

of attribute values, that is, all possible n-tuples:

DðA1Þ � DðA2Þ � . . .� DðAnÞTranslating this into real-life language, using

the sample attributes mentioned above, the

Cartesian product contains all combinations of

supplier-IDs, company names, addresses, con-

tacts, etc. However, a real supplier with a partic-

ular supplier-ID has only one address and only

one contact (and not all possible ones).

Therefore, in a database we are not interested in

all n-tuples but only in some, that is, in a subset R:

RðA1; . . . ;AnÞ � DðA1Þ � DðA2Þ � . . .� DðAnÞ

The mathematical term for this subset is “rela-

tion.” It is defined as follows:

An n-place relation (n-ary relation) over the

domains D(A1),. . ., D(An) is a subset of the Car-tesian product D(A1) � D(A2) � . . . � D(An).

Since the elements of a relation are tuples and

a relation is a set, two properties immediately

follow: Tuples are pairwise different (i.e., there

are no duplicates), and there is no defined order

of the tuples.

A common notation for relations is to write

the relation’s name, sometimes preceded by “R.”

(to indicate that it is a relation), followed by the

attribute names. Key attributes are underlined, as

in the entity-relationship model. For example,

supplier and material relations might be defined

as follows:

R.Supplier (supplier-ID, company name,

address, contact,. . .)R.Material (material-ID, material name, on

stock, safety stock, . . .)

Business partner

or

SupplierCustomer Bank

Companyname

Address

Outstandingdebts

Creditrating

Paymentperiod

Creditline

xor

is a

Fig. A.5 Generalization

and specialization using

connectors

Appendix: Data Models 341

Page 6: Appendix: Data Models978-3-642-31573-2/1.pdf · fications needed for a database. When a data model is available, implementation of the data-base is largely straightforward. Among

In practice, most people speak of “tables”

instead of “relations” because the values of a

relation are usually arranged and displayed in

rows and columns. When the data items (i.e.,

the attribute values) of the entities in question

are displayed and printed, the format is usually

rectangular as illustrated in Fig. A.6.

Each column of the table contains specific

values of one attribute. The name of this attribute

is displayed as the column heading. Attributes

are usually called fields or columns.Each row represents one tuple, that is, one

data object (entity). For example, the first row

describes the material A-2233 (turbo charger)

and the second row describes the material

A-2457 (windshield). Practitioners usually

speak of rows or records instead of tuples. All

rows together make up the set of materials repre-

sented as a database table.

Mapping an ERM to a Relational Model

As mentioned above, the modeling effort usually

starts with creating an entity relationship model

of the problem domain. Later, this model has to

be converted into a relational data model before

it can be implemented in a database management

system. Based on a number of mapping rules, the

conversion is fairly straightforward.

1. Mapping Entity Types

The general rule for mapping entity types is

simple: Each entity type is mapped to one

relation of the relational data model. The attri-

butes of the entity type are adopted as attri-

butes of the relation.

2. Mapping Relationship Types

• An m:n relationship between two entity

types A and B is mapped with the help of

a connecting relation. This relation speci-

fies through pairs “primary key of A—pri-

mary key of B” which tuple of A is

connected with which tuple of B.

• A 1:n relationship (m:1 relationship)

between two entity types A and B is mapped

with the help of a foreign key attribute in A

(B) that references a tuple in B (A). How-

ever, if the relationship type has been mod-

eled to include attributes, the mapping has

to be done in the same way as if it were an

m:n relationship (see previous paragraph).

• A 1:1 relationship is mapped in such a way

that foreign key attributes are included in

the two entity types involved. This means

that each tuple of A points to a tuple of B

via a foreign key and vice versa.

3. Mapping Generalization/SpecializationThe general entity type and each specializa-

tion are mapped to separate relations. The

relations representing the specialized entity

types will use the same primary keys as the

relation representing the general entity type.

Example

In order to illustrate the different mapping

rules, we will refer to the example in

Fig. A.1. This entity relationship model con-

sists of two entity types and one relationship

type. Since the relationship type is an m:n

relationship, the resulting relational data

model contains three relations:

R.Supplier (supplier-ID, company name,

address, contact, . . .)R.Material (material-ID, material name, on

stock, safety stock, . . .)

R.Provides (supplier-ID,material-ID, price,. . .)Figure A.7 shows these relations filled with

sample data. The “provides” relation has five

tuples because there are five specific connections

Material

Material-ID Material Name On Stock Safety Stock

A-2233 Turbo charger 10 5A-2457 Windshield 43 8A-4711 Radiator 23 8B-5221 Carburetor 77 16D-1001 Bumper 3 5X-9899 Wheel rim 1201 200

Fig. A.6 “Material” table

(relation)

342 Appendix: Data Models

Page 7: Appendix: Data Models978-3-642-31573-2/1.pdf · fications needed for a database. When a data model is available, implementation of the data-base is largely straightforward. Among

between the four suppliers and the six materials,

as already shown in Fig. A.1. For example, sup-

plier 48159–01 (Gerber Inc.) provides material

A-2233 (turbo charger) for 650.00 €. The same

material is also provided by supplier 15230–11

(Viadrina AG) for 675.00 €.

Supplier

Supplier-ID Company Name Address

48159-01 Gerber Inc. Dallas, USA48143-05 BB Motors Berlin, Germany15230-11 Viadrina AG Frankfurt, Germany89131-01 Miller plc London, UK

Material

Material-ID Material Name On Stock Safety Stock

A-2233 Turbo charger 10 5A-2457 Windshield 43 8A-4711 Radiator 23 8B-5221 Carburetor 77 16D-1001 Bumper 3 5X-9899 Wheel rim 1201 200

Provides

Supplier-ID Material-ID Price

48159-01 A-2233 650.0048159-01 D-1001 373.5015230-11 A-2233 675.0015230-11 D-1001 395.9589131-01 D-1001 373.50

Fig. A.7 Supplier,

material, and provides

relations

Appendix: Data Models 343

Page 8: Appendix: Data Models978-3-642-31573-2/1.pdf · fications needed for a database. When a data model is available, implementation of the data-base is largely straightforward. Among

References

Aarts EHL, Korst JHM (1989) Simulated annealing and

Boltzmann machines—A stochastic approach to com-

binatorial optimization and neural computing. Wiley,

Chichester, New York

Active Sensing (2009) Product lifecycle management

(PLM); http://www.product-lifecycle-management.

com/plm-glossary-N.htm (accessed Jan 23, 2013)

Adelsberger HH, Kanet JJ (1991) The Leitstand—a new

tool for computer-integrated manufacturing. Produc-

tion and Inventory Management J 32(1):43–48

Alavudeen A, Venkateshwaran N (2010) Computer

integrated manufacturing. Prentice Hall, New Delhi

Ambler SW (2009) UML 2 Activity diagrams. http://

www.agilemodeling.com/artifacts/activityDiagram.

htm (accessed Mar 23, 2012)

Armbrust M, Fox A, Griffith R, et al. (2009) Above the

clouds: A Berkeley view of cloud computing; EECS

Department, University of California, Berkeley, Tech-

nical Report No. UCB/EECS-2009-28, February 10,

2009

Auto-ID Center, XPLANE.com (2002) How the EPC

network will automate the supply chain. http://www.

quintessenz.at/rfid-docs/www.autoidcenter.org/media/

xplane/large/XPLANE-TheEPCNetwork-A.pdf (ac-

cessed Mar 23, 2012)

Auto-ID Center, XPLANE.com (2003) How efficient is

your supply chain? http://www.rfidfactory.com/pdfs/

XPLANE-TheEPCNetwork-B.pdf (accessed Mar 23,

2012)

Baily P, Farmer D, Crocker B, Jessup D, Jones D (2008)

Procurement principles and management, 10th edn.

Prentice Hall, Harlow, UK

Balla J, Layer F (2007) Production planning with SAP

APO-PP/DS. Galileo, Bonn, Boston

Bareiss R (1989) Exemplar-based knowledge acquisition:

a unified approach to concept representation, classifi-

cation, and learning. Academic, San Diego

Behrenbeck K, Großpietsch J, Kupper J, Thonemann U

(2003) Wie Hersteller und Handel kooperieren; Har-

vard Business Manager, September, pp. 39–47

Benz J, Hoflinger M (2008) Logistikprozesse mit SAP,

2. Aufl. Vieweg+Teubner, Wiesbaden

BOC AG (2009) Supply Chain Management with ADO-

log. BOC, Vienna. Available at http://www.boc-

group.com/products/adolog/ (accessed Mar 23, 2012)

BOC AG (2012) Business Process Management with

ADONIS; http://www.boc-group.com/adonis/ (accessed

Mar 23, 2012)

Brehm N, Marx Gomez J (2007) Service-oriented devel-

opment of federated ERP systems. In: Proceedings of

the workshop on software engineering methods for

service oriented architectures 2007 (on CD), Hann-

over, Germany

Brehm N, Marx Gomez J (2008) Federated ERP-systems

on the basis of Web Services and P2P networks;

Special Issue on “Service-Oriented Architecture and

Firm Performance” of the International Journal of

Information Technology and Management (IJITM)

2:28–42

Buyyaa R, Yeo CS, Venugopala S, Broberg J, Brandic I

(2009) Cloud computing and emerging IT platforms:

vision, hype, and reality for delivering computing as

the 5th utility. Fut Gener Comput Syst 25:599–616

Chen PP (1976) The entity-relationship model – toward

a unified view of data. ACM Trans Database Syst

1(1):9–36

Cheng F, Ettl M, Lin GY, Tonner M, Yao DD (2011)

Designing flexible supply chain contracts with

options. In: Kempf KG et al (eds) Planning production

and inventories in the extended enterprise – a state of

the art handbook, vol 2. Springer, New York, pp

207–229

Corsten H, Gossinger R (2008) Einfuhrung in das Supply

Chain Management, 2. Aufl. Oldenbourg, Munich,

Vienna

Crnkovic I, Stafford J, Szyperski C (2011) Software com-

ponents beyond programming – from routines to ser-

vices. IEEE Software 28(3):22–26

Davenport TH (1993) Process innovation – reengineering

work through information technology. Harvard Busi-

ness School Press, Boston

DeMatteis JJ (1968) An economic lot sizing technique I –

The part-period algorithm. IBM Syst J 7:30–38

Dickersbach JT (2009) Supply chain management with

SAP APO – structures, modelling approaches and

implementation of SAP SCM 2008, 3rd edn. Springer,

Heidelberg

Dittrich J, Mertens P, Hau M, Hufgard A (2009a) Dis-

positions parameter von SAP R/3-PP, 5. Aufl. Vieweg

+Teubner, Wiesbaden

K.E. Kurbel, Enterprise Resource Planning and Supply Chain Management,Progress in IS, DOI 10.1007/978-3-642-31573-2, # Springer-Verlag Berlin Heidelberg 2013

345

Page 9: Appendix: Data Models978-3-642-31573-2/1.pdf · fications needed for a database. When a data model is available, implementation of the data-base is largely straightforward. Among

Dittrich Y, Vaucouleur S, Giff S (2009b) ERP customiza-

tion as software engineering: knowledge sharing and

cooperation. IEEE Software 26(4):41–47

Economist (2011) D.T.: LG’s new smart-fridge – One

step closer to the home of the future. The Economist,

April 22nd, 2011; http://www.economist.com/blogs/

schumpeter/2011/04/lgs_new_smart-fridge (accessed

Mar 23, 2012)

Euro-NF (2011) The Governance Dimension of the Internet

of Things – EURO-NF & GOVPIMINT Workshop;

Leipzig, Germany: March 24–25, 2011; http://www.

medienstadt-leipzig.org/euronf/ (accessedMar 23, 2012)

Factory Solutions GmbH (2012) AHP-Leitstand, Version

7.0, Product description. Available at http://www.fac-

tory-solutions.com/cms/upload/pdf/Product_AHP.pdf

(accessed Mar 23, 2012)

FaisstW (2011a) Die nachste Generation der Unternehmens-

Software am Beispiel von SAP Business ByDesign.

Wirtschaftsinformatik und Management 4:24–30

Faisst W (2011b) SaaS, PaaS, cloud computing: the next

generation of enterprise application software. Chapter

3: On-demand Solutions. Lecture at the University of

Bamberg, Summer Term 2011, Powerpoint Presenta-

tion; Bamberg, Germany

Faisst W (2011c) SAP Commercial platform, Whitepaper

Version 2.0; SAP AG, Walldorf, Germany

Fauser AG (2012) The JobDISPO Suite: Software for

small and medium-sized enterprises; http://www.job-

dispo.de/media/files/prospekte/en/JobDISPO_Suite_

brochure_english.pdf (accessed Mar 23, 2012)

Ferdows K, Lewis MA, Machucha JAD (2004) Rapid-fire

fulfillment. Harv Bus Rev 82(11):104–110

Finnegan D, Willcocks LP (2007) Implementing CRM:

from technology to knowledge. Wiley, New York

Fitzgerald B (2006) The transformation of open source

software. MIS Quarterly 30(3):587–598

Fleisch E (2010) What is the Internet of things? An

Economic Perspective; Auto-ID Labs White Paper

WP-BIZAPP-053; http://www.autoidlabs.org/uploads/

media/AUTOIDLABS-WP-BIZAPP-53.pdf (accessed

Mar 23, 2012)

Fleischmann B, Meyr H, Wagner M (2010) Advanced

planning. In: [Stadtler 2010], pp 81–106

Forrester JW (1958) Industrial dynamics – a major

break-through for decision makers. Harv Bus Rev

July–August: 37–66

Forrester JW (1961) Industrial dynamics. MIT, Cam-

bridge, MA

Gaddam B (2009) Capable to match (CTM) with SAP

APO. Galileo Press, Bonn, Boston

Goldberg DE (1989) Genetic algorithms in search, opti-

mization, and machine learning. Addison-Wesley,

Reading, MA

Goo J, Kishore R, Rao HR, Nam K (2009) The role of

service level agreements in relational management of

information technology outsourcing: an empirical

study. MIS Quarterly 33(1):119–145

Graupe D (2007) Principles of artificial neural networks,

2nd edn. World Scientific, Singapore

Gronau N (2009) Enterprise systems knowledge: a new way

to detect changes in the ERP market in Central Europe.

In: AMCIS 2009 Proceedings, Paper 203, http://aisel.

aisnet.org/amcis2009/203 (accessed Mar 23, 2012)

Guillemin P, Friess P et al (2009) Internet of things –

strategic research roadmap. European Commission,

Brussels, http://ec.europa.eu/information_society/

policy/rfid/documents/in_cerp.pdf (accessed Mar

23, 2012)

Hamady M, Leitz A (2009) Supplier collaboration with

SAP SNC. Galileo Press, Boston

Hammer M (1990) Reengineering work: don’t automate,

obliterate. Harv Bus Rev 68:104–112

Hammer M, Champy J (1993) Reengineering the corpo-

ration – a manifesto for business revolution. Nicholas

Brealey, London

Holloway S (2006) RFID: an introduction. http://msdn.

microsoft.com/en-us/library/aa479355.aspx (accessed

Mar 23, 2012)

Homer Computer Services (2007) Advanced plan-

ning system software selection guide; http://www.

homercomputer.com.au/pdf/wapssamples.pdf (ac-

cessed Aug 16, 2007)

Hoppe M (2007) Sales and inventory planning with SAP

APO. Galileo Press, Boston

Howson C (2008) Successful business intelligence –

secrets to making BI a killer application. McGraw-

Hill, New York

Hufgard A, Kruger S (2012) SAP business ByDesign.

Galileo Press, Bonn

Hullenkremer M (2003) Erfolgreiche Unternehmen arbei-

ten mit Produktkonfiguratoren. Industrie Management

19:37–40

Ilie-Zudor E, Kemeny Z (2009) Potential of RFID Appli-

cations over a Product’s life-cycle and relevance in an

IOT context. In: Macchi M, Pinto R (eds) 11th Inter-

national conference on the modern information tech-

nology in the innovation processes of the industrial

enterprises. MITIP, Bergamo, Italy, pp 209–218

Inmon DW (2009) SAP NetWeaver and DW 2.0 – Com-

paring SAP’s architecture evolution to the latest gen-

eration of data warehousing; Inmon Consulting

Services 6/2009. Available at http://www.sap.com/

platform/netweaver/components/businesswarehouse/

index.epx (accessed Mar 23, 2012)

Joseph J (2009) Patterns for high availability, scalability,

and computing power with windows Azure; MSDN

magazine (2009) May; online available at http://

msdn.microsoft.com/de-de/magazine/dd727504.aspx

(accessed Mar 23, 2012)

Juels A (2006) RFID: A general overview; RSA Security

Inc.; http://www.cs.umass.edu/~kevinfu/talks/rfid-

tutorial/usenix-RFID-introduction.pdf (accessed Mar 23,

2012)

Kagermann H (2009) Von der Idee zur Innovation –

Presentation at the Annual General Meeting of

Shareholders, May 19, 2009; http://www.sap.com/

corporate-en/investors/governance/meetings/index.epx

(accessed Mar 23, 2012)

346 References

Page 10: Appendix: Data Models978-3-642-31573-2/1.pdf · fications needed for a database. When a data model is available, implementation of the data-base is largely straightforward. Among

Kagermann H, Osterle H (2006) Geschaftsmodelle 2010 –

Wie CEOs Unternehmen transformieren. Frankfurter

Allgemeine Buch, Frankfurt

Kallrath J, Maindl TI (2006) Real optimization with SAP

APO. Springer, Berlin

Kandray DE (2010) Programmable automation. Industrial

Press, New York

Kernler H (2000) PPS der 3. Generation – Grundlagen,

Methoden, Anregungen, 3rd edn. Huthig, Heidelberg

Khan A (2002) Implementing SAP with an ASAP meth-

odology focus. iUniverse, Lincoln, NE

Khan KM, Malluhi Q (2010) Establishing trust in cloud

computing. IT Professional 12(5):20–27

Kirkpatrick S, Gellat SD, Vecchi MP (1983) Optimization

by simulated annealing. Science 220(5):671–680

Kletti J (2010) Manufacturing execution system – MES.

Springer, Berlin

Knolmayer G (1985) Ein Vergleich von 30 “praxisnahen”

Lagerhaltungsheuristiken. In: Ohse D et al (eds)

Operations research proceedings 1984. Springer, Ber-

lin, pp 223–230

Knolmayer G, Mertens P, Zeier A (2000) Supply Chain

Management auf der Basis von SAP-Systemen.

Springer, Berlin

Knolmayer G, Mertens P, Zeier A, Dickersbach JT (2009)

Supply chain management based on SAP systems –

architecture and planning processes. Springer,

Berlin

Kuhn A, Hellingrath B (2002) Supply Chain Management –

Optimierte Zusammenarbeit in derWertschopfungskette.

Springer, Berlin

Kurbel K (1993) Production scheduling in a Leitstand

system using a neural-net approach. In: Balagurusamy

E, Sushila B (Eds.) Artificial intelligence technology –

applications and management, Proceedings of the 4th

international computing congress, Hyderabad, India,

1993, pp 297–305

Kurbel K (1998) A computational study of the effects of

parameters on the performance of intelligent algo-

rithms. In: Cantu FJ et al (eds) Application of

advanced information technologies – Fourth World

Congress on expert systems, Mexico City 1998, vol

1. Cognizant Communication, New York, pp 407–414

Kurbel K (2008) The making of information systems –

software engineering and management in a globalized

world. Springer, Berlin

Kurbel K, Meynert J (1989) Engpassorientierte Auftrags-

terminierung und Kapazitatsdisposition. In: Kurbel K

et al (eds) Interaktive betriebswirtschaftliche Informa-

tions- und Steuerungssysteme. De Gruyter, Berlin,

pp 69–87

Kurbel K, Ruppel A (1996) Integrating intelligent job-

scheduling into a real-world production-scheduling

system. J Intelligent Manufactur 7:373–377

Kurbel K, Dabkowski A, Jankowska AM (2003) A multi-

tier architecture for mobile enterprise resource

planning. In: Uhr W et al (eds) Wirtschaftsinformatik

2003/Band I – Medien, Markte, Mobilitat. Physica,

Heidelberg, pp 75–93

Kurbel K, Schreber D, Ulrich B (2006) A Web services

Facade for an open source ERP system. In: Proceed-

ings of the 12th Americas conference on information

systems, Acapulco, Mexico, August 4–6, 2006; ISBN

970-31-0621-8, pp 2547–2554

Kurbel K, et al. (Eds.)(2011): Enzyklopadie der Wirtschaft-

sinformatik, 6th edn. Oldenbourg, Munchen. http://

www.enzyklopaedie-der-wirtschaftsinformatik.de

(accessed Oct 23, 2012)

Land AH, Doig AG (1960) An automatic method of

solving discrete programming problems. Econome-

trica 28(3):497–520

Lawton G (2008) Developing software online with plat-

form-as-a-service technology. Computer 41(6):13–15

Lee HL, Padmanabhan V, Whang S (1997a) The Bull-

whip effect in supply chains. Sloan Manage Rev

Spring: 93–102

Lee HL, Padmanabhan V, Whang S (1997b) Information

distorsion in a supply chain – The Bullwhip effect.

Manage Sci 43:546–557

Lewis S (2004) A basic introduction to RFID technology

and its use in the supply chain, White Paper, 2004.

http://www.idii.com/wp/LaranRFID.pdf (accessed

Mar 23, 2012)

Loos P (2011) Kanban. In: [Kurbel 2012] (accessed Nov

30, 2012)

Magal SR, Word J (2009) Essentials of business processes

and information systems. Wiley, Hoboken, NJ

Magal SR, Word J (2012) Integrated business processes

with ERP systems. Wiley, Hoboken, NJMartin J (1989) Information engineering, Book I: Intro-

duction. Prentice Hall, Englewood Cliffs, NJ

Matsui Y, Sato O (2002) An international comparison

study on benefits of production information systems.

Int J Operat Quantitat Manage 8(3):191–214

Mattern F, Florkemeier C (2010) Vom Internet der Com-

puter zum Internet der Dinge. Informatik Spektrum 33

(2):107–121

McCormack K, Wilkerson T, Marrow D, Davey M, Shah

M, Yee D (2008) Managing risk in your organization

with the SCOR methodology. Working Paper, June

2008. Available at http://supply-chain.org/f/Supply

Chain Risk Project Report.pdf (accessed Mar 23,

2012)

McDermott J (1981) R1 – The formative years. AI Maga-

zine 2(2):21–29

Mendling J (2007) Detection and prediction of errors in

EPC business process models; Ph.D. Dissertation,

Vienna University of Economics and Business

Administration (WU Wien)

Mertens P (1995) Wirtschaftsinformatik – Von den

Moden zum Trend. In: Konig W (ed) Wirtschaftsin-

formatik ‘95 – Wettbewerbsfahigkeit, Innovation.

Wirtschaftlichkeit, Physica, Heidelberg, pp 25–64

Mertens P (2009) Integrierte Informationsverarbeitung 1 –

Operative Systeme in der Industrie, 17. Aufl. Gabler,

Wiesbaden

Meyr H, Wagner M, Rohde J (2010) Structure of advanced

planning systems. In: [Stadtler 2010], pp 109–115

References 347

Page 11: Appendix: Data Models978-3-642-31573-2/1.pdf · fications needed for a database. When a data model is available, implementation of the data-base is largely straightforward. Among

MPDV Mikrolab GmbH (2009) HYDRA – Machine data

collection;Mosbach,Germany.Available at http://www.

mpdv-usa.com/PDF-Files/HYDRA-MDE-Brochure_

English.pdf (accessed Mar 23, 2012)

MPDV Mikrolab GmbH (2010) The quality management

system HYDRA-CAQ; http://www2.mpdv.de/en/pro-

ducts/hydra_caq/default.htm (accessed Mar 23, 2012)

Murray M (2009) Discover logistics with SAP ERP. Gali-

leo Press, Boston

Nahmias S (2008) Production and operations analysis, 6th

edn. McGraw Hill, New York

National Intelligence Council (NIC) (2008) Disruptive

civil technologies – Six technologies with potential

impacts on US interests out to 2025. Conference

Report CR 2008–07, April 2008; http://www.dni.

gov/nic/confreports_disruptive_tech.html (accessed

Mar 23, 2012)

Nayak S, Gangadhar G, Puttamadappa C (2011) Intelli-

gent refrigerator with monitoring capability through

Internet. Int J Comput Appl 2:65–68, Special Issue on

“Wireless Information Networks & Business Informa-

tion System”

Object Management Group (OMG) (2011a) Business Pro-

cess Model and Notation (BPMN), Version 2.0; OMG

Document Number: formal/2011-01-03, January

2011; http://www.omg.org/spec/BPMN/2.0 (accessed

Mar 23, 2012)

Object Management Group (2011b) CORBA Basics;

http://www.omg.org/gettingstarted/corbafaq.htm (ac-

cessed Mar 23, 2012)

Ohno T, Bodek N (1988) Toyota production system –

Beyond large-scale production. Productivity, Portland

Presser M (Ed.) (2011) Inspiring the Internet of things;

Alexandra Institute. Available at www.alexandra.dk/uk/

services/ Publications/Documents/IoT_Comic_Book.

pdf (accessed Mar 23, 2012)

Raymond ES (2000) The cathedral and the bazaar, Ver-

sion 3.0, September 2000; http://www.catb.org/~esr/

writings/cathedral-bazaar/cathedral-bazaar/cathedral-

bazaar.ps (accessed Mar 23, 2012)

Riesbeck CK, Schank RC (1989) Inside case-based

reasoning. Erlbaum, Hillsdale, NJ

Russell N, ter Hofstede AHM (2009) Surmounting BPM

challenges: the YAWL Story. Comput Sci Res

Develop 23(2):67–79

SAP Deutschland KG (2001) Supply chain event manage-

ment mit mySAP Supply Chain Management. SAP

AG, Walldorf

SAP Deutschland AG & Co. KG (2003) Plattform-

Interoperabilitat von SAP NetWeaver mit IBM Web-

Sphere und Microsoft .NET, SAP White Paper. SAP

AG, Walldorf

SAP AG (2006) SAP NetWeaver and enterprise services

architecture – SAP solution in detail, SAP NetWeaver.

SAP AG, Walldorf

SAP AG (2010) SAP event management: power and

sophistication to manage your extended supply chain –

SAP Solution in detail, SAP Supply ChainManagement.

SAP AG, Walldorf. Online available at http://www.sap.

com/solutions/business-suite/scm/brochures/ (accessed

Mar 11, 2012)

SAP AG (2012a) ERP software from SAP – a foundation

to execute your business strategy. http://www.sap.

com/solutions/business-suite/erp/ (accessed Mar 10,

2012)

SAP AG (2012b) SAP Documentation – SAP Library.

http://help.sap.com/saphelp_ewm70/helpdata/en/,

http://help.sap.com/saphelp_scm70/helpdata/en/,

http://help.sap.com/saphelp_em70/helpdata/en/

(accessed Mar 12, 2012)

SAP AG (2012c) SAP NetWeaver – adaptive technology

for the networked enterprise. http://www.sap.com/

platform/netweaver/ (accessed Mar 12, 2012)

SAP AG (2012d) SAP supply chain management – Solu-

tionMap. http://www.sap.com/solutions/business-suite/

scm/ (accessed Mar 15, 2012)

SAP Deutschland AG & Co. KG (2012e) SAP ERP Solu-

tion Map. http://www.sap.com/germany/solutions/

business-suite/erp/businessmaps/ (accessed Mar 11,

2012)

SAP University Alliances (2011) SCM-IDES-Fallstudien

v70—CPG3: SNP Planning (training material). SAP

University Alliances EMEA, Walldorf, Germany

Schatz A, Egri P, Sauer M (2011) Open source

ERP – Reasonable tools for manufacturing SMEs?

Fraunhofer Institute for Manufacturing Engineering

and Automation IPA 2011, Stuttgart, Germany. Online

available at http://www.ipa.fraunhofer.de/fileadmin/

www.ipa.fhg.de/pdf/Studien/OpenSource-ERP_Study_

2011.pdf (accessed Mar 23, 2012)

Scheer A-W (1976) Produktionsplanung auf der Grund-

lage einer Datenbank des Fertigungsbereichs. Olden-

bourg, Munchen, Wien

Scheer A-W (1985) Computer: a challenge for business

administration. Springer, Berlin

Scheer A-W (1994) CIM – Computer integrated

manufacturing – towards the factory of the future,

3rd edn. Springer, Berlin

Scheer A-W (2000) ARIS: business process modeling,

3rd edn. Springer, Berlin

Silver B (2009) SAP Netweaver BPM White Paper; Bruce

Silver Associates. Available at http://www.sap.com/

platform/netweaver/brochures/index.epx (accessed Mar

23, 2012)

Singh K (1997) New trends in cell placement techniques as

part of IC layout design methodologies. Ph.D. Thesis,

Devi Ahilya University Indore, India, January 1997

Software AG (2012) ARIS Business Architect & Designer.

http://www.softwareag.com/us/products/aris_platform/

aris_design/business_architect/overview/default.asp

(accessed Mar 23, 2012)

Stadtler H, Kilger C (eds) (2010) Supply chain manage-

ment and advanced planning – concepts, models, soft-

ware and case studies, 4th edn. Springer, Berlin

Stankov IE, Datsenka R, Kurbel K (2012) Service level

agreement as an instrument to enhance trust in cloud

348 References

Page 12: Appendix: Data Models978-3-642-31573-2/1.pdf · fications needed for a database. When a data model is available, implementation of the data-base is largely straightforward. Among

computing – An analysis of infrastructure-as-a-service

providers. proceedings of AMCIS 2012 – 18th Amer-

icas conference on information systems, Seattle, WA,

Aug 9–11, 2012

Suh S-H, Kang S-K, Chung D-H, Stroud I (2010) Theory

and design of CNC systems. Springer, London

Supply-Chain Council (2008) The SCOR Project Road-

map. In: Supply-Chain Council: executive overview,

2006, p 34; http://www.supply-chain.org/node/3946

(accessed Mar 23, 2012)

Supply-Chain Council (2010) Supply chain operations

reference (SCOR) model – SCOR overview – Version

10.0. Supply Chain Council, Cypress, TX

Supply-Chain Council (2011) SCOR 10.0 overview, Exec-

utive presentation; http://supply-chain.org/f/15-%

20SCOR%20Overview.pdf (accessed Mar 23, 2012)

Sweeney R (2010) Achieving service-oriented architec-

ture: applying an enterprise architecture approach.

Wiley, Hoboken, NJ

Takeda H (2006) The synchronized production system –

going beyond just-in-time through Kaizen. Kogan

Page, London, 2006

Theuer H, Klaukien M, Lass S (2010) Marktrecherche

product lifecycle management system. Productivity

Manage 15(2):33–36

Thonemann U (2010) Operations Management: Kon-

zepte, Methoden und Anwendungen, 2. Aufl. Pearson,

Munchen

Trovarit AG (2012a) ERP-Matchmaker. http://www.

erp-matchmaker.com/alle-softwareloesungen.html

(accessed Mar 23, 2012)

Trovarit AG (2012b) IT-Matchmaker. http://www.trovarit.

com/software-suchen/lastenheftvorlagen-erp.html

(accessed Mar 23, 2012)

Vajna S, Weber C, Bley H, Zeman K (2009) CAx fur

Ingenieure – Eine praxisbezogene Einfuhrung, 2. Aufl.

Springer, Berlin

Verein Deutscher Ingenieure (2007) VDI-Richtlinien –

Fertigungsmanagementsysteme – Manufacturing

Execution Systems (MES), VDI 5600, ICS 35.240.50;

Dusseldorf: Verein Deutscher Ingenieure e.V. 2007.

Online available at http://www.vdi.de/uploads/tx_

vdirili/pdf/1381197.pdf (accessed Mar 23, 2012)

Voluntary Interindustry Commerce Standards (VICS)

Association (2004) Collaborative planning, forecast-

ing and replenishment (CPFR) – An overview, 18

May 2004; http://www.vics.org/docs/committees/cpfr/

CPFR_Overview_US-A4.pdf (accessed Mar 23, 2012)

vom Brocke J (2008) Total-Cost-of-Ownership von

Anwendungssystemen. In: [Kurbel 2012] (accessed

Nov 15, 2012)

Wiendahl H-P (1995) Load-oriented manufacturing con-

trol. Springer, Berlin

Wight OW (1984) Manufacturing resource planning:

MRP II – unlocking America’s productivity potential,

Revised Edition. Wiley, New York

Winkler S (2006) An introduction to RFID. SearchSAP.

com, Newton, MA; http://searchsap.techtarget.com/

feature/An-Introduction-to-RFID (accessed Mar 23,

2012)

Wood DC (2007) SAP SCM – Applications and modeling

for supply chain management (with BW Primer).

Hoboken, NJ, Wiley

Wooldridge MJ (2009) An introduction to MultiAgent

systems, 2nd edn. Wiley, Chichester, UK

World Wide Web Consortium (W3C) (2004) Web ser-

vices glossary. http://www.w3.org/TR/2004/NOTE-

ws-gloss-20040211/ (accessed April 11, 2012)

World Wide Web Consortium (W3C) (2006) Naming and

addressing: URIs, URLs, . . ., 27 Feb, 2006 http://

www.w3.org/Addressing/ (accessed Mar 23, 2012)

Wu H, Cao L (2009) Community collaboration for ERP

implementation. IEEE Software 26(4):48–55

Zangemeister C (1976) Nutzwertanalyse in der System-

technik, 4. Aufl. Wittemannsche Buchhandlung,

Munchen

Zimmermann G (1989) Neue Ansatze zur Strukturierung

von PPS-Systemen. FB/IE 38(2):72–77

References 349

Page 13: Appendix: Data Models978-3-642-31573-2/1.pdf · fications needed for a database. When a data model is available, implementation of the data-base is largely straightforward. Among

Index

AABAP. See Advanced Business Application

Programming (ABAP)

ABAP workbench, 183

ABC analysis, 43–44

Accelerated SAP (ASAP), 160–165, 167, 170

Active model, 254, 255

Active version, 255

Activities, 9–10, 105–108, 139–158

Adjustment planning, 210

ADOlog, 240, 241

ADONIS, 10, 119, 236

Advanced Business Application Programming

(ABAP), 180, 183

Advanced planning and scheduling (APS), 3, 16, 121,

122, 243, 259–261, 274

Aftermarket sales and service, 132

Aggregation, 278–279, 340

AGVs. See Automated guided vehicles (AGVs)

AHP leitstand, 193, 198

Alarm generators, 204–205

Alert monitor, 276, 297

Alternative operations, 62, 79

Alternative routings, 62

American Production and Inventory Control

Society (APICS), 191

Analytical CRM, 5

Analytics, 5, 97, 128, 133–135, 187, 191, 315

ANN. See Artificial neural networks (ANN)APICS. See American Production and Inventory

Control Society (APICS)

APIs. See Application programming interfaces (APIs)

Application layer, 182

Application programming interfaces (APIs),

168–170, 183

Application server, 187

Application system, 1, 3, 4, 6, 8, 10, 19–21, 127, 128, 160,

163, 164, 168, 184, 187, 192, 193, 200, 294

APS. See Advanced planning and scheduling (APS)

ARIS platform, 10, 119

Article, 20, 35, 227, 278, 303, 327, 328

Artificial neural networks (ANN), 88, 196

ASAP roadmap, 161–164, 170

Assemble-to-order, 39

Asset management, 113, 136, 239

ATD. See Available-to-deploy (ATD)

ATP. See Available-to-promise (ATP)

Attribute, 20–23, 31–33, 63, 89, 96, 107, 223, 228,

239–241, 247, 249, 250, 256, 280, 324, 332,

337–342

Auto-ID Center, 327

Automated guided vehicles (AGVs), 7, 213

Automatic inventory systems, 213

Availability checks, 57–58, 82–84, 107, 108, 110,

111, 115, 132, 175, 176, 178, 179, 243, 260,

276, 294, 295, 301

Available-to-deploy (ATD), 289

Available-to-promise (ATP), 243, 260, 275, 294–297

BBackward scheduling, 69–72

BAPIs. See Business application programming

interfaces (BAPIs)

Barcode(s), 49, 84, 111, 130, 204, 306, 327

Barcode readers, 204, 306

Bill of materials (BOM), 25–28, 49

Bill of materials explosion, 49, 294, 295

Bill of materials processors (BOM processors), 49

Binary tree, 22, 23, 25

Biometric data, 201, 204

BOM. See Bill of materials (BOM)

BPM. See Business process management (BPM)

BPMN. See Business process model and

notation (BPMN)

BPR. See Business process reengineering (BPR)

Branch-and-bound technique, 262

Bridge programs, 163, 164

Bridging the “last mile”, 325

BRM. See Business rules management (BRM)

Bulk reading, 327

Bullwhip effect, 227–229, 264

Business application programming interfaces

(BAPIs), 183

Business blueprint, 161–163, 165, 171

Business components, 183

Business framework, 183

Business functions, 2, 8, 10, 95–97, 103, 105, 127,

174, 222, 309

Business map, 127

Business objects, 20, 183, 246

Business process, 1–3, 8–10, 105–119, 139–157

Business process management (BPM), 118, 184, 186

K.E. Kurbel, Enterprise Resource Planning and Supply Chain Management,Progress in IS, DOI 10.1007/978-3-642-31573-2, # Springer-Verlag Berlin Heidelberg 2013

351

Page 14: Appendix: Data Models978-3-642-31573-2/1.pdf · fications needed for a database. When a data model is available, implementation of the data-base is largely straightforward. Among

Business process model and notation (BPMN), 9–11,

117–119, 186, 232, 236

Business process reengineering (BPR), 8, 15, 219,

232, 233

Business rules management (BRM), 186

Business scope diagram, 236–238

Business software, 1–3, 16, 125, 307

Business warehouse (BW), 184, 186

ByD Studio, 316, 317

CCAE. See Computer-aided engineering (CAE)

CAID. See Computer-aided industrial design (CAID)

CAM. See Computer-aided manufacturing (CAM)

CAP. See Computer-aided planning (CAP)

Capable-to-match (CTM), 282, 286–289

Capable-to-promise (CTP), 243, 296–297

Capacity, 3, 37, 63, 110, 131, 179, 191, 227, 250, 280, 299

Capacity availability check, 111

Capacity demand, 53, 68, 78, 79

Capacity leveling, 286

Capacity load leveling, 68, 76–82, 191, 199, 202, 211

Capacity load profiles, 77, 78

Capacity planning, 12, 40, 41, 61, 80–81, 131, 197–199,

206, 211, 213

Capacity profile, 76–80, 193, 197, 198, 202

Capacity requirements, 2, 12, 15, 52, 62, 63, 66, 68,

76–82, 84, 85, 108, 111, 154, 155, 193, 194,

202, 206, 229

Capacity requirements planning (CRP), 2, 12, 15, 62, 63,

66, 68, 78–80, 82, 85, 193, 194, 206

Capacity scheduling, 52, 85, 191, 193–200

Capacity supply, 68, 78

CAQ. See Computer-aided quality assurance (CAQ)

Cardinalities, 22, 79, 338, 339

Carrier selection, 297

Cartesian product, 341

Case-based reasoning (CBR), 93, 169

CAx implementation, 215–216

CAx systems, 6, 189, 201, 202, 206–219

CE. See Composition environment (CE)

Change management, 132, 161, 216, 218, 252

Checking control, 176, 179, 181

Checking group, 176, 178, 179

Checking rule, 176, 178, 179, 295

Checking scope, 178–180

Chip cards, 204

CIM. See Computer-integrated manufacturing (CIM)

Classification numbers, 35, 36

Client-independent customizing, 170

Client-specific customizing, 170

Closed loop MRP, 2, 66–68

Cloud, 312, 313, 317–319

Cloud computing, 312–313, 317

CLP. See Collaborative demand planning (CLP)

CNC machines, 213

COGM. See Cost of goods manufactured (COGM)

COGS. See Cost of goods sold (COGS)

Collaborative demand planning (CLP), 279, 280

Collaborative planning, forecasting and replenishment

(CPFR), 167, 230–231, 259, 260, 279

Collaborative product commerce (CPC), 216

Collaborative product definition management

(CPDM), 216

Communication Oriented Production Information

and Control System (COPICS), 19

Company code, 98–103, 138, 143, 170, 172–174, 177

Company IMG, 171

Completion confirmation ticket, 84

Complexities, 160, 170, 217, 338

Component model, 163, 169

Componentware, 169

Composite applications, 186, 187, 309, 310

Composition environment (CE), 184, 186

Compound numbers, 35, 36

Computer-aided design (CAD), 6, 21, 25, 96, 191,

206–211, 214–219

Computer-aided engineering (CAE), 6, 206, 207,

212, 214

Computer-aided industrial design (CAID), 207

Computer-aided manufacturing (CAM), 202, 207,

210–214

Computer-aided planning (CAP), 6, 202, 206, 210–211

Computer-aided quality assurance (CAQ), 205, 207, 214

Computer-integrated manufacturing (CIM), 192,

205–207, 214

Computerized numeric control (CNC), 7, 212, 213

Connectors, 10, 116, 119, 339–341

“Consists of” relationships, 27

Constraint propagation, 261, 293

Consumption-driven planning, 44–49, 105

Consumption rate, 44

Continuous change, 164–165

Continuous manufacturing, 25

Control(s), 1, 19, 64, 95, 133, 171, 189, 221, 273, 325

Controlling, 2, 95–99, 132–133

Control post, 193

COPICS. See Communication Oriented Production

Information and Control System ( COPICS )

Core interface (CIF), 249, 250, 254, 273, 297–299

Corporate governance, 132, 133

Corporate social responsibility (CSR), 136

Costing, 11, 21, 89–93, 96, 108, 113, 130, 202, 229

Cost of goods manufactured (COGM), 89, 133, 210

Cost of goods sold (COGS), 89–92, 133, 150

CPC. See Collaborative product commerce (CPC)

CPDM. See Collaborative product definitionmanagement (CPDM)

CPFR. See Collaborative planning, forecasting and

replenishment (CPFR)

Critical ratio (CR), 265, 267

CRM. See Customer relationship management (CRM)

CRM system, 3–6

CRP. See Capacity requirements planning (CRP)

CSR. See Corporate social responsibility (CSR)

Customer data, 4, 5, 33, 95, 96, 145, 183, 185

Customer exits, 168

Customer inquiry, 10, 40, 80, 81, 106, 108, 119, 137,

145, 147, 297

Customer-order-oriented planning level, 56, 57

Customer relationship management (CRM), 3–6, 127,

161, 183, 187, 191, 311

352 Index

Page 15: Appendix: Data Models978-3-642-31573-2/1.pdf · fications needed for a database. When a data model is available, implementation of the data-base is largely straightforward. Among

Customer satisfaction, 15, 40, 166, 167, 222

Customization, 97, 110, 121, 123, 154, 163, 164, 167,

169–171, 218, 301, 311, 318–320

Customizing, 123, 124, 163, 167–181, 218, 291

Cutover, 164, 215

DDatabase layer, 182

Database management systems (DBMS), 3, 7, 8, 16,

186, 340, 342

Database table, 21, 24, 29, 30, 342

Data models, 7, 33, 62, 64, 80, 96, 163, 168, 183,

217, 337–343

Data structure, 1, 20, 32–34, 61, 63, 65, 79–80, 89, 167,

168, 218, 219, 249–271, 280, 282, 337, 339, 340

DBMS. See Database management systems (DBMS)

Decision-relevant costs, 264, 265

Decomposition, 25, 186, 234–236, 282

Delivery, 10, 21, 75, 96, 130, 166, 192, 221, 254, 282, 309

Demand fulfillment, 270, 287, 288

Demand planning (DP), 243, 259, 260, 274, 276–281,

284, 301, 302

Dependent requirements planning, 49–52

Deployment, 134, 276, 280, 282, 285, 286, 289, 290

Deployment optimization, 289

Detailed scheduling (DS), 81, 85–88, 191, 243, 274–276,

279, 281, 286, 289–294, 296

Developer studio, 186

Development system, 162, 163

Direct costs, 89, 165–167, 201, 266

Disaggregation, 259, 278–279

Discrete manufacturing, 25

Dispatching rules, 85, 86

Distributed numeric control (DNC), 203, 213

Distribution planning, 3, 243, 260, 274

DNC. See Distributed numeric control (DNC)

DNC machines, 203, 213

Documents, 84, 105, 137

Double scheduling, 71–72

2D systems, 208

2½D systems, 208

3D systems, 208

Dynamic availability check, 82, 178

Dynamic pegging, 257

Dynamic replenishment, 300–301

Dynamic variants, 29, 31, 32

Dynpro, 183

EEconomic lot size, 15, 45–47

Economic order quantity, 15, 45–48, 228

Economic principle, 13, 174

Electronic leitstand, 189, 192, 193, 214

Electronic planning board, 194, 197, 198

Electronic product catalogs, 42, 125, 132, 219

Electronic product code (EPC), 9, 10, 105, 106,

115, 117–119, 139, 145, 157, 327–329

EM. See Event management (EM)

Employee data, 64, 112, 134

End-user service delivery, 135

Engineering application systems, 6

Engineering data management (EDM), 216, 220

Engineering information systems, 189, 206–220

Engineering management (EM), 216

Enterprise portal, 125, 168, 184

Enterprise service(s), 186, 309–310

Enterprise service bus, 309

Enterprise structure, 103–104, 172, 173, 175

Entity, 8, 22, 29, 101, 228, 337–340, 342

Entity-relationship diagram (ERD), 20, 34, 59, 62, 64,

169, 337, 338

Entity-relationship model (ERM), 5, 33, 80, 337–341

Entity types, 22, 33, 59, 63, 90, 163, 249, 337–340, 342

Environment, health and safety compliance

management, 135, 136

EPCglobal, 327

EPC network, 328

EPCs. See Event-driven process chains (EPCs)

ERD. See Entity-relationship diagram (ERD)

ERM. See Entity-relationship model (ERM)

ERP on demand, 313–314

ERP systems, 3, 19, 67, 97, 119–124, 127, 159–189, 192,

243, 249, 291, 310

Event, 9, 10, 12, 105, 106, 115–119, 139, 144, 152,

186, 189, 204, 244–246, 279, 290, 298, 303,

304, 330, 336

Event-driven process chains (EPCs), 8–10, 105, 115, 118,

119, 156–157, 163, 232, 327, 329

Event management (EM), 244–247, 273, 299, 304

Event monitor, 246

Event-oriented planning, 12

Event processor, 246

Expectation-oriented planning level, 56, 57

Exponential smoothing, 37, 38, 44, 277

Extended warehouse management (EWM), 273,

299, 304–306

External procurement relationships, 249, 253–254

FFacade pattern, 322Factory calendar, 61, 63, 64

Fair share rule, 289, 290

Feature-based modeling, 209

Federated ERP (FERP), 307, 320–323

Final preparation phase, 164

Financial(s), 1–3, 95, 97–99, 103, 111, 113, 127–129,

132–135, 155, 159, 180, 315

Financial accounting, 3, 98, 99, 113, 132, 155

Financial analytics, 135

Financial supply chain management (FSCM), 132, 133

Finite capacity scheduling, 191, 193–200

Finite scheduling, 80, 293

First-order exponential smoothing, 277

Fixed pegging, 258, 259

Fixed period requirements, 45

Flexible manufacturing system (FMS), 7, 212, 213

Forecasting and replenishment (F&R), 167, 230–232,

260, 273, 279, 299, 303–304

Index 353

Page 16: Appendix: Data Models978-3-642-31573-2/1.pdf · fications needed for a database. When a data model is available, implementation of the data-base is largely straightforward. Among

Forecasting methods, 5, 36–39, 59, 97, 133, 135, 167,

230–232, 243, 260, 273, 277–279, 299, 301–304

Formulation, 25, 262, 264, 268, 320, 335

Forrester, J.W., 224, 225, 227, 228

Forward scheduling, 69–72, 76

Forward shift, 50–52, 55, 131

F&R. See Forecasting and replenishment (F&R)

FSCM. See Financial supply chain management (FSCM)

Function, 8–10, 105–119, 127–128, 139–157

Funnel model, 83

GGateway to the Internet, 326

Generalization, 339–342

Genetic algorithms, 87, 88, 196, 259, 260, 293

Geographic map, 233, 237, 239

Global ATP, 275, 294–297

Global Bike International (GBI), 138–139, 143

Global settings, 163, 170, 171

Global sourcing, 14

Global trade services (GTS), 136, 137

“Goes into” relationship, 21, 22, 28

Go live & support, 161, 164–165

Goods issue, 109, 130, 138, 178, 204, 245, 250, 306

Goods receipt, 106, 116, 130, 137, 139, 142, 143, 178,

245, 250, 255, 300, 306

Gozinto graph, 21, 22, 30

Graphical leitstand, 193

Gross requirements planning, 49, 50, 54

HHCM. See Human capital management (HCM)

Heuristic, 3, 85–89, 196, 259, 260, 274, 276, 281–286,

288, 289, 291–293, 297

Heuristic Search, 87–88

Home automation, 330

HR. See Human resources (HR)

Human capital management (HCM), 103, 127, 128,

133–134

Human resources (HR), 2, 10, 16, 64, 90, 95, 97, 98,

103–105, 111, 133, 134, 201, 315

IIaaS. See Infrastructure-as-a-service (IaaS)Identification numbers, 35, 335

Identity management, 187

ILM. See Information lifecycle management (ILM)

Implementation guide (IMG), 163, 171, 172, 176

Implementation methodology, 160

Implementing an ERP system, 98, 120, 121, 159,

165, 166, 215

Inactive models, 255

Inbound logistics, 130

Indirect costs, 165–167, 266

Individual make-to-order, 34, 39

Individual make-to-order production, 34

Individual one-time production, 34, 39

Individual-purchase-and-make-to-order, 39

Industrial dynamics, 224–227, 264

Industrial robots (IRs), 189, 210, 213

Information engineering, 169

Information lifecycle management (ILM), 184, 185, 280

Information management, 184–186, 191

Information model, 169

Information objects, 106, 119, 139–141, 144–146, 149,

151, 152, 156, 163, 239

Information system (IS), 1–17, 20, 67, 95–97, 119, 134,

167–169, 174, 186, 187, 189, 191, 193, 206–220,

229, 231, 309, 337

Infrastructure-as-a-service (IaaS), 312, 313

Inquiry, 10, 40, 57, 58, 80, 81, 84, 96, 105–108, 119, 132,

137, 145, 147, 193, 211, 294, 297

Inspection plans, 6, 205, 215

Integration models, 298

Intelligent refrigerator, 331

Intelligent shopping, 330

Interaction model, 163

Internal variant, 29

Internet Governance Forum, 336

Internet of Things (IoT), 322–336

Interoperability, 187, 308, 324

Inventory and warehouse management, 113,

128–131, 135

Inventory management, 8, 19, 42, 56, 97, 100, 130, 230,

328, 331

Invoice, 6, 10, 35, 36, 96, 98, 105, 106, 108, 113, 129,

135, 137, 139, 141, 143–145, 149–151, 183, 213,

229, 234, 298, 301, 309, 311, 315, 318

IoT. See Internet of Things (IoT)IoT governance, 336

IRs. See Industrial robots (IRs)IS. See Information system (IS)

“Is a” relation, 340

JJob ticket, 84

Just-in-time delivery, 14

Just-in-time manufacturing, 70

Just-in-time production, 14

KKanban, 14, 48, 49, 131, 301

Kanban principle, 48–49

Key attributes, 32, 338, 341, 342

Knowledge-based modeling, 209

LLead-time offset, 52, 131

Lead-time reduction, 15, 62, 72–75, 86, 98

Lead-time scheduling, 15, 40, 62, 68–81, 86, 96, 111,

131, 152, 155, 193, 195, 198, 202, 211, 216, 291

Leitstand, 189, 191–202, 214, 293

Life-cycle data management, 114, 131–132

Like profile, 278

Linear programming (LP), 37, 271

Linear regression, 277

Load-oriented order release, 82–84

Location and product substitution, 295

354 Index

Page 17: Appendix: Data Models978-3-642-31573-2/1.pdf · fications needed for a database. When a data model is available, implementation of the data-base is largely straightforward. Among

Location product(s), 254, 257, 291

Location product hierarchy, 254, 255

Logistics, 3, 14, 16, 98, 127–131, 137, 173, 193, 212,

222, 229, 240, 244, 245, 279, 301, 302, 328

Look-across cardinality, 339

Look-here cardinality, 339

Lorenz curve, 43

Lot size, 11, 15, 21, 45–47, 49–53, 55, 71, 110, 250,

252, 254, 269, 271, 283, 289, 291

Lot-size planning, 11, 50, 52–53, 55

Low-level codes, 53–56, 69–71, 291

LP. See Linear programming (LP)

LP model, 37

Lying times, 69–71, 73, 84

MMachine cost rate, 63, 90

Machine data, 6, 84, 191, 201–204, 214, 215

Machine data acquisition (MDA), 6, 84, 191, 200–205,

214, 215

Machine utilization planning, 85, 193

Maintenance, repair and operations (MRO), 219

Make-to-order production, 34, 36, 39–41, 53, 56–59,

75–76, 80–81, 84–85, 108, 109, 131, 295, 296

Make-to-stock production, 36, 39, 40, 56, 75, 84,

109, 131, 296

Management accounting, 8, 132–133

Management processes, 132, 234

Management science, 15–16, 36

Mandatory variant, 29

Manufacturing automation and control, 6–7

Manufacturing cost, 15, 89–91

Manufacturing execution, 131, 206, 214

Manufacturing execution systems (MES), 6, 79–81,

131, 189–206, 211, 214–216, 244, 293

Manufacturing leitstand, 191, 193–200

Manufacturing levels, 14, 19, 32, 46, 52–57, 69, 70

Manufacturing orders, 40, 42, 45, 57, 59, 62, 68, 69,

75–82, 84, 88, 110, 111, 114, 193–199, 202,

203, 210, 211, 217, 256, 281, 298

Manufacturing resource planning (MRP II), 2, 61–93

Mapping an ERM to a relational model, 342–343

Master data, 16–17, 20–33, 61–66, 249–255

Master data management (MDM), 20, 184, 185, 211, 217

Master production plan(ing), 11, 12, 36–42, 189, 259

Master production scheduling, 66, 68

Material, 1, 19–61, 95, 128, 164, 189, 221, 250, 279,

320, 337

Material availability check, 175, 179

Material cost, 89–91, 216

Material master data, 21, 141, 142, 145, 149, 176, 250

Material requirements planning (MRP), 2, 19–60, 66

Material slips, 84

Material withdrawal, 111, 145, 149

MES. See Manufacturing execution systems (MES)

MESA International, 190–191

Metrics, 135, 136, 161, 164, 201, 204, 208, 209, 216,

233, 239–242, 247, 276

Min-max cardinalities, 339

Mixed-integer linear programming (MILP), 271

Mixed-integer optimization model, 262

Model-based generation, 168–169

Moving averages, 37, 38, 44, 277

Moving reorder quantity (MRQ) method, 45–48

MRO. See Maintenance, repair and operations (MRO)

MRP. See Material requirements planning (MRP)

MRP II. See Manufacturing resource planning (MRP II)

MRQ. See Moving reorder quantity (MRQ) method

Multilevel ATP check, 294–295

Multilevel bills of materials, 25, 26, 259

Multiple linear regression, 277

Multi-tenant architecture, 311

NNC machines, 212–213

NC programs, 210, 211, 213, 214

Net requirements planning, 49–52, 54, 55, 206, 213

Neural networks, 87–89, 259

Newsvendor model, 264–265

Nonconformance management, 205

Normal distribution, 265, 266

n-place relation, 341

Numbers, 2, 20, 35–36, 61, 105, 131, 160, 190, 225, 255,

276, 308, 337

Numeric control (NC), 212, 213

OObject naming service (ONS), 327, 329

OCR, 204

Open item, 144, 145, 150, 151

Open-source ERP, 307, 319–321

Open-source software (OSS), 319, 320

Operating facility(ies), 63–64, 76–84, 90

Operating facility data, 52, 63, 90, 201

Operation(s), 1, 20, 61, 95, 127, 161, 189, 228, 250,

291, 311

Operational CRM, 5

Operation completion slips, 203

Operations analytics, 135

Optical markings, 204

Optimal lot size, 15, 45, 46

Optimal order quantity, 45–47, 59, 265–267

Optimization, 3, 12, 15, 16, 36, 37, 48, 53, 85–88, 121,

196, 213, 243, 244, 252, 259–262, 264–266, 271,

274, 276, 281–283, 286, 289, 293, 297

Optional variant, 29

Order, 2, 20, 61, 95, 129, 159, 189, 221, 249, 277,

308, 337

Order batching, 228

Order calculation, 40, 76

Order completion confirmation, 154

Order costing, 93, 111, 202

Order data, 42, 201, 216

Order fulfillment, 10, 11, 41, 85, 93, 103, 106–109,

114, 115, 119, 123, 137, 144–152, 175, 211,

231, 240, 244, 260, 311

Order quantity, 11, 15, 42, 44–48, 59, 79, 143, 152,

154, 228, 265–267, 283

Order release, 81–85, 179, 199, 245

Order scheduling, 40, 80, 81, 86, 132, 211, 260

Order sequencing, 85, 194–196, 259

Index 355

Page 18: Appendix: Data Models978-3-642-31573-2/1.pdf · fications needed for a database. When a data model is available, implementation of the data-base is largely straightforward. Among

Organizational structure, 97–105, 134, 138, 159, 163,

169, 172–174, 195, 218

Organizational units, 98–101, 103, 104, 106, 133, 135,

156, 157, 163, 170, 193, 219, 236, 239

Organization model, 163

Outbound delivery, 109, 145, 148–150

Outbound logistics, 129, 130

Outsourced manufacturing, 300, 302–303

Overage cost, 265

Overhead cost(ing), 89–91, 135

Overlapping of operations, 73–75

PParallel numbers, 35–36

Parameter(s), 167–168, 170–172

Parameterization, 167–169, 175, 179

Parametric modeling, 209

Part, 2, 20–61, 98, 127, 159, 189, 221, 251, 309, 338

Part classification, 218

Part master data, 20, 21, 23, 25, 32, 34, 45, 90, 206

Partner adapters, 87

Part-period algorithm, 45, 47–48

Payment, 20, 33, 106, 108, 111, 113, 126, 130,

132–135, 139, 143–145, 150, 151, 165, 235,

245, 301, 315, 318, 330, 335, 340

Payroll, 3, 10, 84, 97, 103, 104, 111, 134, 135, 201,

202, 315, 316

PDA/MDA. See Production and machine data acquisition

(PDA/MDA)

PDA server, 205

PDA system, 200

PDM. See Product data management (PDM)

Pegging, 256–259, 276, 288, 293

Performance attributes, 240–241, 247

Performance of the supply chain, 239, 240

Periodic review policy, 44

Phase-in profile, 278

Phase-out profile, 278

Picking list, 111, 146

PICS. See Production information and control system

(PICS)

Planned event, 245, 304

Planned orders, 59, 60, 69, 109, 110, 131, 152, 193,

200, 250, 255, 257, 281, 282, 286, 287, 293,

296, 300

Planning board, 193–198, 202, 214, 295, 297

Planning book, 284–286

Planning for service levels, 286–287

Planning principles, 12–13

Plant, 99–101

Plant data, 200

Plant data acquisition, 191, 197, 200

Plant order, 84

Plant scheduling, 85

Platform-as-a-service (PaaS), 313–314, 317

PLM. See Product life cycle management (PLM)

Pool of operations, 194–197

Posting documents, 111, 115–117, 149, 150, 155, 156

PP/DS, 279, 281, 286, 289–294, 296

PPM plan, 250–252

Presentation layer, 181, 182

Price fluctuation, 228

Primary requirements, 2, 39, 40, 42–44, 49, 50, 59, 60, 81,

211, 215, 279

Primary resources, 82, 251

Priority rules, 85, 86, 211

Privacy, 313, 336

Process data, 202, 205, 217, 303

Process model, 9, 10, 65, 105, 118, 119, 160–165, 186,

215, 233

Process parameters, 202

Process reference model, 233

Process steps, 9, 50, 98, 105, 108, 110–112, 127, 137, 139,

141, 144, 145, 151, 152, 155, 186, 219, 309

Procurement, 105–106

Procurement and logistics execution, 128–131

Procurement orders, 10, 16, 59

Procurement process, 6, 9–11, 105, 106, 114–116, 118,

137, 139, 140, 144, 156, 296

Product, 2, 19–32, 62, 96, 127, 185, 189, 201, 249,

276, 309, 337

Product availability check, 294

Product configurator, 5, 32, 41, 42, 219, 243

Product cost(ing), 89–93, 96, 108, 113, 202

Product-cost calculation, 210

Product data and process management (PDPM), 216

Product data management (PDM), 6, 191, 214, 216–220

Product decomposition, 282

Product development and manufacturing, 128, 131–132

Production and machine data acquisition

(PDA/MDA), 6, 191, 201–203, 214, 215

Production control, 10–16, 136

Production data, 192, 200–205, 250

Production data acquisition (PDA), 2, 15, 111,

200–205, 216

Production data structures (PDS), 249–252

Production-distribution system, 225–227

Production information and control system (PICS), 19

Production Kanban, 14, 48, 49

Production lots, 11, 45, 50, 57, 59, 70, 110, 270

Production orders, 2, 9, 11, 14–16, 20, 42, 44, 52, 57,

59, 73–74, 79, 82, 84, 85, 108, 131, 138, 152–155,

179, 191, 193, 201, 214, 255–257, 291, 293, 302

Production planning (PP), 10–16, 36–42, 128, 131

Production planning and control, 10–16, 20, 48, 192,

206, 221

Production planning and scheduling, 212, 260

Production planning/detailed scheduling (PP/DS), 279,

281–282, 286, 289–294, 296

Production planning goals, 13–14, 86

Production process models (PPM), 65, 249–253,

280, 295–596

Production program, 1, 2, 12, 19, 34, 37, 39, 40, 49,

53, 68, 92

Production resources and tools (PRT), 179, 201

Productive system, 162, 164

Product life cycle, 6, 136, 207, 208, 216, 217, 278,

332–334

356 Index

Page 19: Appendix: Data Models978-3-642-31573-2/1.pdf · fications needed for a database. When a data model is available, implementation of the data-base is largely straightforward. Among

Product life cycle management (PLM), 6, 127, 161,

217, 220

Product master data, 6, 35, 250

Product overview, 291, 293

Product planning, 131, 205, 217, 260, 291, 293

Product planning table, 293

Product specification, 39, 41–42, 84, 211, 252

Product structure(s), 16, 19–32, 34, 35, 49, 50, 52–56,

62, 65, 69, 70, 72, 75, 76, 90, 131, 152, 154, 210,

211, 217–219, 256, 270, 271, 283, 291, 294

Product structure tree, 21–23, 25, 28, 30, 50, 52, 53,

55, 70, 72, 90

Product variants, 28–32, 39, 41, 218, 219

Product view, 291–293

Professional-service delivery, 132

Profitability, 5, 13, 93, 99, 113, 133, 135

Program exits, 168

Project and portfolio management, 134, 136

Project charter, 161, 162, 233

Project IMG. See Project-oriented implementation

guide (Project IMG)

Project kickoff, 162

Project-oriented implementation guide (Project IMG), 171

Project preparation, 161–162

Promotion planning, 279

Purchase orders, 10, 11, 40, 42, 44, 45, 50, 57, 59, 60,

84, 98, 105, 129, 131, 142–144, 156, 228, 230,

234, 256, 300, 302, 304, 336

Purchase requisition, 105, 129, 137, 139, 141, 142, 213,

236, 255, 291, 300, 316

QQuality management (QM), 135–137, 161, 191, 192,

202, 205–206, 214

Quantitative adjustment, 79

Quantity goals, 13

Quantity variant, 29

Quota arrangements, 249, 253–254

Quotation, 6, 10, 39, 41, 42, 57, 80, 84, 93, 105, 107,

108, 121, 126, 132, 145, 211, 229, 307, 308, 337

RR/3, 127–129, 131, 134, 161, 168, 181, 183, 273

Radio frequency identification (RFID), 84, 121, 130,

201, 306, 324, 326–336

Rationing, 228

RDBMS. See Relational database management

systems (RDBMS)

Real estate management, 136

Realization phase, 162, 163, 170

Recurrent costs, 165

Reference IMG, 171, 172

Reference model, 161, 163, 171, 231–233, 235

Relation, 340–342

Relational database management systems

(RDBMS), 7, 186

Relational data model, 337, 340–343

Relationship, 337–340

Relationship type, 337–340

Reorder point, 44

Reorder point/order-quantity policy ((R,Q) policy), 44

Repetitive planning, 210

Replenishment planning, 289, 300, 301

Replenishment time, 20, 44, 230

Repository, 6, 134, 169, 170, 183, 185, 186

Requirements-driven planning, 44, 49–56, 105

Resource decomposition, 282

Resource lists, 65–66, 250

Return on capital employed, 13

RFID reader, 111, 201, 204, 326, 329, 334

RFID system, 326

RFID tags, 49, 204, 326, 327, 329, 331, 336

Risks, 14, 44, 48, 58, 70, 82, 85, 88, 109, 121, 133, 135,

160, 161, 167, 224, 227, 229, 230, 233, 239–241,

263, 264, 266, 283, 299, 332

Robotics, 213, 322

Rolling planning, 12

Root formula, 45, 46

Rough-cut planning, 40, 41

Routing, 16, 20, 35, 40, 41, 52, 57, 61–65, 68, 69, 73, 76,

79, 87, 90, 93, 110, 113, 121, 131, 138, 152, 154,

193, 205, 206, 210, 211, 213, 214, 216, 217, 250,

252, 259, 296

(R, Q) policy. See Reorder point/order-quantity policy

((R,Q) policy)

Rule-based ATP, 295–296

Rule processor, 246

SSafety stock, 42, 44, 50, 178, 227, 228, 243, 256, 282,

289, 301, 341, 342

Sales order, 107, 109, 110, 119, 132, 138, 145, 255

Sales order management, 132

SAP APO (advanced planner and optimizer), 273

SAP Business ByDesign, 313–319

SAP business suite, 127, 184, 187, 217, 246

SAP commercial platform, 317, 319

SAP ERP, 20, 98, 127–157, 159, 244, 250, 273, 314

SAP ERP solution map, 128, 181

SAP NetWeaver, 125, 128, 172, 184–188, 246

SAP R/3, 127, 128, 129, 168, 181, 273

Savant, 327–329

Scalability, 123, 184, 187, 311, 319

SCE. See Supply chain execution (SCE)

Schedule, 4, 40, 41, 68, 71, 76, 81, 83, 84, 110,

192, 195–197, 233, 235, 236, 255, 256, 286,

290, 291, 293, 297

Schedule changes, 196–197

Scheduling, 2, 39, 61, 96, 131, 191, 221, 250, 273, 315

SCM systems, 3, 6, 241–247, 249, 256, 259, 261, 273,

298, 307, 328, 337

SCOR model. See Supply chain operations reference

(SCOR) model

Search strategy, 287, 288

Secondary requirements, 2, 11, 42–44, 49, 50, 57, 59–61,

66, 68, 70, 76, 105, 202, 228, 279

Secondary requirements planning, 11, 42, 43, 202,

228, 279

Index 357

Page 20: Appendix: Data Models978-3-642-31573-2/1.pdf · fications needed for a database. When a data model is available, implementation of the data-base is largely straightforward. Among

Secondary resources, 251

Second-order exponential smoothing, 38

Sequence dependent setup effort, 86, 87, 290

Sequencing, 15, 16, 85, 87, 88, 193–196, 259

Service consumer, 308, 309

Service-level agreements (SLAs), 123, 313

Service-oriented architecture (SOA), 186, 307–311

Service provider, 250, 297, 308, 309, 312, 323

Shift model, 61, 63, 64

Shop floor control (SFC), 6, 12, 36, 64, 67, 68, 78, 81, 82,

85–89, 171, 176, 190, 191, 197, 221, 291

Shortage gaming, 228

Simple object access protocol (SOAP), 187, 308

Simulated annealing, 87, 88, 196, 259, 261

Simulation, 42, 82, 83, 86, 135, 197, 210, 225–227, 242,

255, 259, 280, 293, 294, 296

Simultaneous planning, 16, 81

Single-level bills of materials, 25, 26

Smart orchard, 330

Smart urban waste management, 330–331

SNP heuristic, 282–286

SOAP. See Simple object access protocol (SOAP)

Software-as-a-service (SaaS), 311, 312

Software components, 129, 138, 169, 186, 308

Solution manager, 187

Solution map, 127, 128, 130, 132–135, 181, 273, 274,

300, 302

Specialization, 33, 339–343

Splitting production orders, 73–74

SRM. See Supplier relationship management (SRM)

(s, S) policy, 44

Standard for the exchange of product (STEP)

model data, 215

Standard order, 145, 147, 150, 152, 296

Standard software, 3, 97, 121, 159, 163, 167, 170, 311

Static availability check, 82

Static variants, 29, 30

Statistical process control (SPC), 205

STEP. See Standard for the exchange of product

(STEP) model data

Stock-keeping level, 56

Stock overview list, 145, 148

Strategic network planning, 259, 260, 275–276

Structure variant, 29

Subassemble-to-order, 39

Subcontracting, 14, 78, 202, 256, 257, 274, 302

Subcontractor requirement, 256

Subscription, 311, 318

Summarized bills of materials, 25, 27

Supplier collaboration, 300–301

Supplier data, 33, 339

Supplier invoice, 10, 139, 141, 143, 144, 234, 301

Supplier managed inventory (SMI), 300, 301

Supplier relationship management (SRM), 6, 127,

161, 315

Supply chain, 1, 49, 65, 127, 183, 221–247, 273, 307

Supply chain cockpit (SCC), 276–277, 297

Supply Chain Council (SCC), 224, 233, 236, 241

Supply chain engineer (SCE), 275, 276, 280

Supply chain event management (SCEM), 244–247

Supply chain execution (SCE), 244

Supply chain operations reference (SCOR) model,

232–241, 247

Supply chain performance management (SCPM),

246–247

Supply chain planning matrix, 259, 260, 276

Supply network, 3, 223, 224, 244, 259, 261, 267, 268,

276, 324

Supply network collaboration (SNC), 273, 299–303

Supply network planning (SNP), 123, 243, 267, 268,

271, 274, 279–290, 297, 300

Swimming lane, 239

System landscape, 161–163, 219

TTalent management, 134, 135

Technical information systems, 206

Temporal adjustment, 79

Test programs, 205

Test system, 162

Thread diagram, 233, 237, 239

Time & attendance, 134, 191, 201, 203

Time buffers, 70–73, 79, 85, 251

Time data acquisition (TDA) system, 201

Time decomposition, 282

Time goals, 13

Timekeeping system, 201

Time ticket, 155, 203

Tools and attachments, 64–65

Total cost of ownership (TCO), 165–166

Tracking, 5, 6, 113, 133, 134, 191, 195, 202, 213,

244–245, 302, 327, 331, 332

Tracking and tracing systems (T&T systems),

244, 245, 328

Transaction data, 20, 79, 139, 144, 149, 152, 254–256,

273, 299, 315

Transition time, 62, 73, 75

Transition-time reduction, 73, 75

Transponder, 326, 328, 331, 336

Transportation lane, 249, 252–254, 337

Transportation management, 129–131, 244

Transportation planning, 130, 214, 243, 260, 275,

279, 297

Transportation planning/vehicle scheduling (TP/VS),

275, 297

Transport Kanban, 48

Transport load builder (TLB), 276, 280, 282,

289–290, 297

Travel management, 135, 136

Treasury, 132, 133

Trust, 133, 229–232, 313, 314, 317

UUnderage cost, 265

Univariate forecast methods, 277

Unplanned events, 304

User exits, 168–170, 180–183

VValue drivers of the Internet of Things, 334–335

Variant(s), 14, 20, 24, 29–32, 39, 41, 68, 76, 93, 108, 131,

138, 170, 210, 212–214, 255, 257, 279, 300

358 Index

Page 21: Appendix: Data Models978-3-642-31573-2/1.pdf · fications needed for a database. When a data model is available, implementation of the data-base is largely straightforward. Among

Variant family, 30, 31

Variant planning, 210, 255

Vendor managed inventory (VMI), 167, 230–232, 259,

274, 283, 300

VICS Voluntary Interindustry Commerce Standards

Association

Visual composer, 186

Voluntary Interindustry Commerce Standards (VICS)

Association, 231, 232

WWage slips, 84, 155, 203

Warehousing data, 33

Web services, 169, 186, 187, 308–309, 322

Web services description language (WSDL),

187, 308–309

What-if simulation, 242, 255, 259

Where-used lists (part-usage lists), 25, 27–28, 35, 218

Withdrawal rate, 44–46, 56

Workflow model, 169, 237–240

Workforce analytics, 134, 135

Workforce deployment, 134

Workforce process management, 134

WSDL. See Web services description language (WSDL)

YY-model, 207

Index 359