<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Do You Read Me? On the Limits of Manufacturing Part Numbers for Communicating Product Variety</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Aleksander Lubarski</string-name>
          <email>aleksander.lubarski@encoway.de</email>
          <email>lubarski@uni-bremen.de</email>
          <xref ref-type="aff" rid="aff1">1</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Frank Dylla</string-name>
          <email>dylla@informatik.uni-bremen.de</email>
          <email>frank.dylla@encoway.de</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Holger Schultheis</string-name>
          <email>schulth@informatik.uni-bremen.de</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Thorsten Krebs</string-name>
          <email>krebs@encoway.de</email>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Bremen Spatial Cognition Center, University of Bremen</institution>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Industrial Services Group, University of Bremen</institution>
        </aff>
        <aff id="aff2">
          <label>2</label>
          <institution>encoway GmbH</institution>
        </aff>
      </contrib-group>
      <abstract>
        <p>Manufacturing part numbers (MPNs) are used to communicate product variety both for internal purposes and for external representation to customers. To simplify this communication, MPNs have been originally developed as humanreadable abbreviations of those characteristics that uniquely identify a product variant out of a modular system, thus acting both as an identifier and a description. However, the increasing complexity of customer requests forces component manufacturers to expand their product portfolios, thus pushing the descriptive character of a classic MPN to its limits. Ongoing digitalization drives product identification towards fully-digital possibilities. Nevertheless, in reality component manufacturers still rely on MPNs. Against this background, the purpose of this paper is to analyze the cognitive and systemic characteristics of the MPN with regard to the underlying product structure (PS). As a result, we derive evaluation criteria for the quality of mappings from PS to MPN and apply them to typical business use cases. In doing so, we provide the first systematic overview and discussion of factors that determine MPN's utility and usability as well as give practical guidelines for component manufacturers regarding the selection of appropriate MPN types.123</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>INTRODUCTION</title>
      <p>
        With the growing trend of customization and the overall direction
towards a lot size of one, manufacturers are facing new requirements
of representing their product portfolio in a clear and structured way,
as well as understanding their customers’ demands. This is a concern
particularly in the business-to-business (B2B) markets, where
complex machines (and even machine parts) consist of numerous
modular elements, thus offering almost unlimited configuration
possibilities to the customers. For example, compared to a BMW
series 7 who offer as many as 1017 possible variants [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ], Lenze AG
claims to have up to 1030 configuration possibilities just for their
gear motor, each of which resulting into a separate identifier.
However, if not structured properly, an unnecessarily high product
variety can become counter-productive, since customers can get
confused about the differentiation among product variants [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]. In
this way, while a modular product structure promises a compromise
between customer-driven customization and
manufacturermotivated standardization [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ], the structuring and the
communication of “what’s possible and at what price” is a very
important, but also a challenging task.
      </p>
      <p>
        In this context, alphanumeric strings have been used to
communicate product variety both for internal purposes and for
external representation to customers [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ]. For referring to these
strings various denominators are common practice, e.g., type code,
order code or ID, part ID or number. For reasons of simplicity, we
will use the term manufacturing part number (MPN, see Section 2.3)
throughout this paper. MPNs are codifications of product
characteristics or functions (e.g., information on its structure,
material composition, production process) and act as a distinct
identifier of a certain product combination (Figure 1). Typical use
cases for MPNs range from initial product search to reordering or
maintenance of a particular machine. Within this paper, we focus on
the appropriateness of such numbers for the purpose of
communicating product variety, i.e., visible features. In practice,
oftentimes the corresponding stakeholder is provided with relevant
supplementary documents that explain the structure and the logic of
the MPN and accelerate the process of “deciphering” its information
(e.g., tables, graphs, dictionaries). However, although originally
developed to be human-readable in order to simplify the
customersupplier communication, we ask the following questions, since
many things have changed:
• Is it still necessary and monetarily reasonable to use MPNs that
are human-readable4?
• Where are the limits of different MPN types and what should
the selection of the appropriate MPN depend on?
In particular, there exist various reasons to switch to a completely
digital MPN. First, the descriptive character within any human
interaction works only as long as a certain length and complexity of
the MPN is not exceeded [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ]. For products with a rich variety the
number of product characteristics and, consequently, configuration
possibilities, is very high. In this way, at some point, the MPN may
become too complex and confusing for involved stakeholders. In
case a customer is not able to fully understand how a specific MPN
relates to the corresponding product may result in delays or incorrect
orders, potentially damaging the customer-supplier relationship.
4 In this publication we define “human-readable” as the code feature to be
read and comprehended by the human, while “machine-readable” or
“digital” can be processed solely by a digital medium
Second, since B2B customers have to deal with dozens of such
structures a day from different suppliers, they are no longer willing
to invest their time in understanding the internal product structure of
each of their partners [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ]. This leads to the overall decline of the
technical know-how in the market, thus making human-readable
MPNs containing these technical details rather obsolete. Third,
company mergers and acquisitions may result in inconsistencies and
redundancies in the data management5 [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ]. On the one hand, both
companies could have similar nomenclatures (or even same serial
numbers for different products), thus causing confusion for the
future product handling. On the other hand, the customers of the
company would get an additional structure to deal with, thus
increasing the complexity of variant management and
communication.
      </p>
      <p>
        Nevertheless, despite all advantages mentioned above, it would
be narrow-minded to claim that a digital (i.e., only
machinereadable) MPN is a universal solution for the efficient
communication of the product variety for every manufacturer. The
most obvious argument against the abolishment of human-readable
MPNs is the complete dependency on a digital device (e.g., QR code
reader, barcode scanner) to read and understand the MPN. Examples
of situations when this could be problematic include product
manufacturing, where a person using an MPN as a guideline for
assembly would have to interrupt the production process, or general
network coverage problems leading to the inability to use a central
referral database. As for other non-functional requirements, the
transition to the digital MPN would result in additional
hardwarerelated costs as well as general efforts for restructuring. Moreover,
such an initiative could also meet the opposition of the users
themselves, who are generally reluctant to any structural changes,
since they are used to the way the things are currently handled [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ].
Finally, since a digital MPN has all the freedom regarding how much
information it can hold and thus communicate, product
manufacturers might get tempted to put too much information (if not
all of it) in one single digital ID, e.g., a QR-code, thus overwhelming
their customers, who would spend additional time for finding the
relevant information [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ].
      </p>
      <p>Overall, while digital identifiers such as RFID integrated into
ERP systems have been proposed more than a decade ago, the reality
shows that product and part manufacturers are still far away from
the best practice, which calls to find out why. Motivated by the
heterogeneity of the involved stakeholders and an overall specificity
of product configuration in the B2B markets, we believe that
different MPN structures are needed depending on respective
application scenarios. Therefore, by applying methods from
information theory and insights from cognitive science we analyze
relevant characteristics of MPN as well as define evaluation criteria
for how well the MPN can map the underlying product structure
(PS). By showing that there exist five typical business use cases and
thus no universal MPN we contribute to the theoretical discussion
on knowledge representation and pave the ground for further
research. In addition, as current pragmatic solutions of the
practitioners are rather narrow-minded without considering their
efficiency, we give practical guidelines for the selection of an
appropriate MPN.</p>
      <p>The remainder of this paper is organized as follows. After giving
a short overview of the theoretical background in Section 2, the
aspects of MPN and PS, as well as evaluation criteria of the
MPN5 Project experience of the authors shows that these kinds of problems may
arise even between units of the same company.</p>
      <p>PS mapping are explained in Section 3. The evaluation criteria are
then applied to the typical business use cases in Section 4. The paper
concludes with a summary of the results, possible limitations as well
as future research opportunities.
2
2.1</p>
    </sec>
    <sec id="sec-2">
      <title>THEORETICAL BACKGROUND</title>
    </sec>
    <sec id="sec-3">
      <title>Code Function and Code Word</title>
      <p>
        In general, a code is an agreement on sets of meaningful symbols for
the purpose of information exchange between a sender and single or
multiple recipients (e.g., [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ], [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ]). For this purpose, the sender
encodes the information, which needs to be decoded by the recipient
with the same coding schema. From a mathematical perspective, a
code is an injective mapping from a domain element ( ∈  ) to an
element of an image set ( ∈  ). Furthermore, the resulting image
must not be empty:
      </p>
      <p>:  →  +
In the context of codes  and  are considered finite alphabets, i.e.
arbitrary sets of symbols with a limited number of elements. In
general, codes can be applied for abstracting or abbreviating
information and its dependencies. In that sense, not only the Morse
code or the internet acronym LOL (“laughing out loud”) is a code,
but also traffic lights.</p>
      <p>From a communication perspective, a code is a translation from
the sender’s original information or message to some
communication means (encoding or encryption), e.g., digital
impulses, sound or flags. If the code function is known to the
recipient, the original information becomes easily decodable
(decoding). Otherwise, the recipient is not able to restore the
information at all (no decryption possible). Each code word (a
sequence of symbols), which is derivable by the code function, is
called a valid code word. Following these definitions, the transfer
from a product structure (PS), i.e., simplified a set of product
characteristics with certain values, to some part number, e.g. an
MPN. The code function is the schema which characteristics are
considered and how the corresponding values are represented in the
resulting code word, i.e., a product-specific MPN. In the remainder
of the paper, in general, we will not distinguish between the code
function and the resulting code word and use the term ‘code’
synonymously.</p>
      <p>The application of codes is closely related to efficiency, which is
achieved by reducing complexity regarding the original information,
i.e. by abstraction, abbreviation, or compression. As it takes the
effort to design a code, a code gets more efficient the more often it
is used. Additionally, some codes use a modular architecture (i.e.
decomposition of a complex system in separate functional units) for
reasons of efficiency.</p>
      <p>With this theoretical background in mind, we consider the
relation between code functions and MPN generation from a
psychological perspective in more detail in Section 3.
2.2</p>
    </sec>
    <sec id="sec-4">
      <title>Variant Management</title>
      <p>
        Due to a high level of heterogeneity and a tight customer
involvement both in the product design and manufacturing [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ],
B2B manufacturers are constantly searching for new ways of
standardization without diminishing their ability to go the last mile
for their customers [
        <xref ref-type="bibr" rid="ref13">13</xref>
        ]. In this context, the introduction of the
modular product design (i.e. building a complex system out of
exchangeable modules with a clear function and defined
connectivity interfaces) has led to a series of organization and
production changes, thus expanding configuration possibilities
almost exponentially [
        <xref ref-type="bibr" rid="ref14">14</xref>
        ]. This resulted in the introduction of such
manufacturing concepts as Mass Customization [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ] and an overall
higher interdependence of the supply chain partners.
      </p>
      <p>
        However, while a modular product structure promises a
compromise between customer-driven customization and
manufacturer-motivated standardization [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ], the variant
management throughout the whole product lifecycle becomes
increasingly challenging. A good overview of the sources of
complexity in engineering design and manufacturing is given in [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ],
where complexity is considered as a multi-faceted measurement that
is influenced both by endogenous and exogenous drivers.
      </p>
      <p>
        ElMaraghy et al. [
        <xref ref-type="bibr" rid="ref17">17</xref>
        ] define variety as “a number or collection
of different things of a particular class of the same general kind”,
with a variant being an instance of a class that exhibits (slight)
differences from the common type. The overall goal of modular
product structures is the minimization of inner variety while
maximizing outer variety. In other words – to offer customers as
many individualized products as possible with as few parts in
production as possible [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ]. Additionally, when talking about
variant management it is reasonable to differentiate between its two
levels – strategic and operative. While the strategic level
concentrates on “determining and mastering the variety of the
product portfolio in such a way that it is aligned with the competitive
and the product strategy”, the operative level implements and
secures the overall variant strategy [
        <xref ref-type="bibr" rid="ref18">18</xref>
        ]. This publication focuses on
the operative level since MPNs are used for the identification and
representation of a certain product instance or a category of product
combinations, thus supporting the actual implementation of variant
management. At this point, we assume that a modularization process
has already been conducted and a modular product structure is
already given as an input. More information on these steps can be
found in [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ].
      </p>
      <p>
        The challenge of operative variant management resulted in the
emergence of a specific market for so-called CPQ-systems [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ],
which can be integrated into existing enterprise software. CPQ
software enables product configuration (C), its respective pricing (P)
and creation of a unified quote containing all necessary information
of the offer (Q). While these quotation documents contain all the
details about the desired machine or its component, MPNs are a
more compact information representation used for internal and
external communication of the product variants and variant
identification. As of today, both the topics of CPQ-systems and
MPNs have not been devoted enough academic attention, even
though they are used in practice on an everyday basis.
2.3
      </p>
    </sec>
    <sec id="sec-5">
      <title>Product Identifiers</title>
      <p>
        Since the topic of variant management and product identification
involves different research disciplines such as engineering,
marketing, information systems or even psychology, there exist no
6 For example, the manufacturing company SEW has a 15-page document
showing the structure of their MPN.
universal definitions or terminology. The challenge lies in the
applied nature of the topic and its historical development – not only
do the terms and labels differ between companies (especially across
different domains and fields of operation), but sometimes even
within the same company, depending on the department and the use
case. For example, the term “type code” is often used for the
description of product groups, even though this term has already
established itself in the context of digital storage media, e.g., DVD
and Blue-ray [
        <xref ref-type="bibr" rid="ref20">20</xref>
        ]. Other misleading terms for the same purpose
include “Product Key” or “Type Designation Key”, which are used
either when installing software programs or when describing
specifications and configurations of computer drives [
        <xref ref-type="bibr" rid="ref21">21</xref>
        ]. The fact
that there exists no standard (international) specification or central
point of reference makes it even more confusing for the
communication with partners and customers.
      </p>
      <p>
        Irrespective of the use case, each product or service needs a
certain description for the purpose of identification and explanation,
containing compressed information in the form of characteristics.
Oxford Dictionary defines Identifier (ID) as a sequence of characters
used to identify or refer to an element, such as a variable set of data.
Such an ID can refer either to a unique class of objects with a certain
level of abstraction (i.e. products that are grouped based on a certain
set of characteristics while, possibly, ignoring further details), or be
used for an identification of a specific physical object. A typical
example of the object identification is a serial code or Serial Number
(SN), which is usually comprised of numerals even though other
typographical symbols are also possible. In most cases, the SN is
built with no particular logic or predefined structure, as it is assigned
incrementally or sequentially to an item in the production [
        <xref ref-type="bibr" rid="ref22">22</xref>
        ] and
thus cannot be read or interpreted by any of the stakeholders. On the
contrary, Manufacturer’s Model Number (MMN) is a solely
marketing-driven succinct and catchy description with the purpose
of evoking certain associations and interpretations when being
communicated to the customers. However, the inevitable problem
with the MMN is its necessary level of abstraction – driven by either
customer’s cognitive capacity (e.g., the ability to remember a certain
string) or system limitations (e.g., input fields of ERP systems are
often limited in length), the MMN has to concentrate only on the
most important product characteristics (e.g., iPhone SE 64 GB
black) thus neglecting other valuable product information [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ].
      </p>
      <p>
        Against this background, a compromise between
productiondriven machine readability and marketing-driven human-readability
can be reached by using the term Manufacturer’s Part Number
(MPN) [
        <xref ref-type="bibr" rid="ref23">23</xref>
        ], which is the focus of our publication (Figure 2). While
also being an identifier for a unique class of objects just like MMN,
the MPN contains much more information and is historically built
upon a certain predefined structure, which is often sent directly to
the customer.6 Here, an SN is a particular instantiation of an MPN
acting as an identifier within a certain context. Therefore, an SN
alone cannot be used as a unique identifier (UID), i.e., guaranteed to
be unique among all identifiers used for those objects and for a
specific purpose, as companies may have identical serial number
systems for different products within their product portfolio. Instead,
a UID can be created by combining both the MPN and its particular
instantiation SN, e.g., “Model X” and “Serial Number 238912”.
From a mathematical point of view, an MPN is a code word, which
is derived by a code function from the product structure taking a
subset of characteristics into account (cf. Section 2.1).
3
3.1
      </p>
    </sec>
    <sec id="sec-6">
      <title>MPN-PS MAPPING EVALUATION</title>
    </sec>
    <sec id="sec-7">
      <title>Methodology</title>
      <p>
        For the purpose or transparency and traceability of our results, we
first give an overview of the methodology used in this paper (Figure
3). It consists of the metaphases Orientation and Application of the
MPN, each containing two consecutive steps along with the applied
technique (textual description) and preliminary results (rectangles).
Due to the applied nature of our research, first, we contacted the
practitioners in order to identify current problems in variant
management and product configuration (Step 1). For this, we
cooperated with one German consulting company, which specializes
in CPQ-Software for complexity reduction and simplification of the
quotation process. By conducting semi-structured expert interviews
[
        <xref ref-type="bibr" rid="ref24">24</xref>
        ] with eight of its previous customers, we were able to gather first
insights on the challenges concerning MPN and confirm that
different use cases require different types of MPN (Result A).
      </p>
      <p>As a second part of the orientation phase, we then conducted a
systematic literature review (Step 2). Sadly, despite its practical
importance, the topic of MPN structure and its deployment has not
received enough academic attention yet. Therefore, in order to place
our research within an ongoing theoretical discussion, we also
looked at the adjacent topics of variant management, complexity in
manufacturing, and production identifiers. In this way, we were able
to identify various MPN aspects, which are relevant for the
communication of the product variants (Result B).</p>
      <p>The second phase dealt with the application of the MPN in the
real-life context. For instance, based on the results from the
orientation phase we were able to derive systemic and cognitive
evaluation criteria for the MPN-PS mapping in Step 3 (Result C).
Since this publication is meant to open a discussion on the topic, we
did not provide any specific metrics but remained merely on a
conceptual level. Finally, with the help of the conducted expert
interviews and based on our own experience from previous projects
in Step 4 we defined five business use cases for the MPN
deployment, including stakeholder description and requirements for
the MPN. In this way, it was possible to show that there exists no
universal MPN, but rather that its selection depends on certain
industrial, company, and customer characteristics (Result D).
3.2</p>
    </sec>
    <sec id="sec-8">
      <title>Formal definition</title>
      <p>While it may seem that an MPN is just a string of characters, it has
numerous systemic and cognitive aspects, which influence its
communication and variant management in general. In this context,
MPN generation can be seen as a specific mapping ℳ that is used
to represent a given (fixed) product structure in an understandable
way (cf. Section 2.1), aiming to be both complete and easy to use
(Figure 4). With different product structures and company’s
specificities, there are many ways to approach such a mapping,
ranging from a mere enumeration of all possibilities up to the
complex nested configurable structure, meaning that the quality of
the mapping can be evaluated for a specific context. We define such
an evaluation function ℰ of mapping ℳ with respect to a specific
need or application of the generated MPN, defined by a set of
evaluation criteria  = [ 1, … ,   ] and corresponding outcomes  =
[ 1, … ,   ]:
ℰ(ℳ,  ) =  
ℎ   ∈ [0. .1]
Based on the insights from the expert interviews (Figure 3, Step 1)
and literature review (Figure 3, Step 2), in this publication, we
concentrate on the general mapping ℳ and the definition of the
corresponding evaluation criteria as well as their testing for different
use cases. The subsequent optimization problem, i.e. finding an
optimal MPN with respect to a given set of criteria, is beyond the
scope of the publication and is left for the future research.
3.3</p>
    </sec>
    <sec id="sec-9">
      <title>Product and MPN structure</title>
      <p>When talking about the evaluation of the MPN it is important to
differentiate between two different types of structure (Figure 4).</p>
      <p>The Product Structure is a rigid arrangement of elements that is
used to depict product compositions and configuration possibilities.
Unlike the MPN structure, the actual product structure (i.e. what
elements a complex machine consists of, what possible
combinations are there, etc.) states the core of the value proposition
and thus cannot be changed. In this regard, the Number of Product
Characteristics shows which parts of a complex product can be
substituted or exchanged if desired. Similarly, such a modular
product composition and interface specifications determine the
Configurable Variety, thus enabling satisfaction of customer
heterogeneous requirements. However, as mentioned earlier, a
higher configurable variety does not necessarily mean a better
portfolio, since an excessively high variety can even be
counterproductive, as customers can get confused about the differentiation
among product variants. Finally, the actual Composition of the MPN
along with the sequential arrangement of the characteristics within
is influenced by the product structure. In other words, the
stakeholder is able to read and understand the information encoded
in the MPN only as long as he/she knows what symbol is responsible
for what characteristics.</p>
      <p>
        The MPN structure, on the other hand, is flexible and can be
adjusted according to the company’s preferences. A cleverly picked
MPN can enhance human understanding and thus its overall
manageability and understandability, whereas a bad MPN may
confuse both the company employees as well as their customers.
This includes the Length of the MPN, which may sometimes be
challenging, since many ERP systems (e.g., SAP) have an integrated
limit on the string length, thus indirectly forcing product
manufacturers to use shorter codes [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ]. Another important MPN
characteristic is an average Characteristics Richness showing how
many variants are encoded inside single characteristics. This aspect
is especially important if the MPN is human-readable and a person
operating it has to remember all the variants of every characteristic
by heart. Finally, the amount of configurable feasible solutions is
limited by the applicable logical rules (e.g., IF, XOR, AND), which
can be summarized by the aspect Dependency Density. Although
acting as a limitation to the possible solution space, dependency
density increases the complexity of the MPN and thus its
applicability by a human stakeholder. Looking at the long-term
lifecycle of products, another central aspect is the Extensibility of the
MPN. This is particularly important for products, which are still in
the development and it is foreseeable that new characteristics may
be added according to customer’s preferences or market’s
development, e.g., by adding functionality by software updates. The
level of extensibility can hereby range from practically impossible
(e.g., rules defining the MPN structure prohibit any further
extension) or cost-inefficient (e.g., requiring database connectivity)
to complete freedom (e.g., no limitations within a digital MPN).
Finally, the choice of MPN Representation type predefines how it
will be used between the involved actors. Three possible types of
MPN representation can be differentiated, each with its advantage
and limitation: (i) human understandable MPN that can be read and
assessed without any additional help, meaning that human operator
needs to know the MPN structure and characteristic meaning by
heart; (ii) human readable MPN that can be read and assessed using
a certain (analog or digital) code translator or additive requiring a
certain level of know-how of the user; (iii) machine-readable MPN
that can contain almost unlimited amount of coded information
within product characteristics, without any know-how requirements
for the user, but with a high dependency on a digital scanner.
3.4
      </p>
    </sec>
    <sec id="sec-10">
      <title>Mapping evaluation criteria</title>
      <p>Once an appropriate MPN and a clear mapping of the product
structure to the MPN is created, the question arises how well a
human can employ it, with or without any auxiliary means, i.e. how
complex the code function is w.r.t. human processing (cf. Section
2.1). If we abstract from specific company restrictions or personal
7 Due to its direct connection to the fuel type Diesel it is also considered as
“Turbocharged Diesel Injection”.
preferences, the human user should be able to map the MPN to a
corresponding product 1) quickly, 2) with acceptable accuracy, and
3) without extensive learning. A prerequisite for achieving this is
that the MPN and the mapping realized by it are conducive to the
way in which humans process information. For example, consider
the acronym "TDI" to characterize a property of car motors. If
confronted with this acronym in the context of cars, people may
already "know" that the car being under consideration has a diesel
motor with "Turbocharged Direct Injection".7 At this point, the
question arises: how or why do people know this? If observed
separately, these three letters "TDI" could also stand for something
else, e.g., "Total Dream Interior", thus describing some arbitrary
aspect of the car. The only source for this knowledge is the memory
of the person having to deal with the acronym. In other words – the
working and usability of MPNs for human users relies critically on
the memory capacity of the human user.</p>
      <p>
        The human cognitive system is commonly conceived as
consisting of several different types of memory stores [
        <xref ref-type="bibr" rid="ref25">25</xref>
        ]. For
reasons explained in the following, the two types of stores most
relevant for our considerations with regard to MPNs are working
memory (WM) and long-term memory (LTM). Information recently
having or currently being processed resides in WM. As such, WM is
assumed to be limited in capacity as well as in the duration that
content will remain accessible. Although exact estimations vary it
seems clear that no more than 10 items of information can be
maintained simultaneously [
        <xref ref-type="bibr" rid="ref26 ref27">26, 27</xref>
        ]. If the information in WM is not
used, it will be lost within a few seconds [
        <xref ref-type="bibr" rid="ref28">28</xref>
        ]. Human LTM, on the
other hand, can store vast amounts of information (see [
        <xref ref-type="bibr" rid="ref29">29</xref>
        ] for
estimates) over very long time spans (just think of old people telling
stories from their childhood). In fact, depending on the usage
frequency, information from LTM can be retrieved into WM and
information residing in WM may be transferred to LTM for more
permanent storage. Going back to the "TDI" example, it seems most
likely that knowing that "TDI" signifies "Turbocharged Direct
Injection" is retrieved from LTM. If it was not the case, it would
have had to be maintained in WM since first learning what "TDI"
means. This may be the case when someone first tells you what
"TDI" means in the domain of car motors, but on later encounters, it
seems unlikely that the meaning of the acronym has been constantly
maintained in working memory for the whole time. Given that LTM
plays a central role in the human use of MPNs, it is instrumental to
consider some of the properties of how information is represented
and organized in LTM. Two properties seem particularly
noteworthy.
      </p>
      <p>
        First, human LTM is associative [
        <xref ref-type="bibr" rid="ref30">30</xref>
        ]. Certain concepts/pieces
of information are associated with each other such as, for example,
the concept of "fire" is associated with the concept of "heat". In
particular, these associations are a major means of retrieving
information from LTM. If a current item in WM is sufficiently
strongly associated with some other piece of information in the
LTM, retrieval of this other information is greatly facilitated. If, for
instance, "TDI" is sufficiently strongly associated with
"Turbocharged Direct Injection" in the context of cars, seeing the
acronym will allow retrieving the desired information.
      </p>
      <p>
        Second, knowledge organization in human LTM is hierarchical
[
        <xref ref-type="bibr" rid="ref31 ref32">31, 32</xref>
        ]. This means that human LTM has a tendency to be
organized into categories, subcategories, and concrete instances. If
asked to enumerate properties/instances in a certain domain, people
will often enumerate aspects (sub)category after (sub)category. Vice
versa, if people are asked to memorize a (large) list of properties, the
ability to memorize the given information increases considerably, if
the material can be (and is) organized hierarchically. Having
expounded the crucial characteristics of human memory, we now
relate them to the readability, learnability, and processing speed of
MPNs.
3.4.1
      </p>
      <sec id="sec-10-1">
        <title>Readability / Learnability</title>
        <p>In the context of this publication, we consider an MPN readable, if
a human user can map each MPN to the corresponding product (a)
virtually without error and (b) without any supporting material (e.g.,
tables, software). Thus, the following requirements have to be met:
• The MPN has to be short enough to be held in WM completely
or it has to consist of several meaningfully separable parts, each
of which is short enough to be held completely in WM.
• The MPN or its meaningful parts have to be sufficiently
strongly associated in LTM with the product aspects they
represent.</p>
        <p>
          The first requirement seems comparatively easy to achieve. A
tenarity code using letters and ciphers is able to represent about 3510
different product variants. The second requirement is tightly related
to the learnability of the MPN, that is, to the feasibility of acquiring
all necessary associations and the speed with which they can be
acquired. As a result, the second requirement is much harder to
satisfy as soon as we are dealing with large-scale variant spaces.
There seems to be an upper limit of only around 5000 arbitrary
associations that human LTM can store, while learning a good 3000
arbitrary associations took a whole year (incremental training with
three sessions each day) [
          <xref ref-type="bibr" rid="ref33">33</xref>
          ]. If the human user is supposed to go
beyond such limitations, the code either needs to build on and reuse
existing associations or the code has to be organized hierarchically
or both. The simplest form of reuse is to employ non-arbitrary
mappings. For example, in the case of "TDI" the acronym is much
easier to memorize than arbitrary acronyms (e.g., "XYZ"), because
the letters in the acronym are the starting letters of the crucial words
in the product description and, thus, the letters are already associated
with the target words. More elaborate forms of reuse may involve
exploiting more domain-specific knowledge of the human users. A
hierarchical organization of the code would allow reducing the
number of associations that need to be stored at each level of the
hierarchy, while still allowing to cover a large variant space with the
MPN. For example, the first digit of the MPN may signify whether
the product is a car or a motorbike with the remainder of the key then
being specific to the type of vehicle (car or motorbike). The upper
limit of possible associations that can be stored when drawing on
existing knowledge and hierarchical organization is hard to predict
and will probably also depend on the individual user. Nevertheless,
it is clear that the readability/learnability of the MPN increases:
•
•
•
•
        </p>
        <p>The more easily (parts of) the MPN can be maintained in
working memory,
The fewer associations have to be memorized,
The more previous knowledge can be drawn on, and</p>
        <p>The clearer it can be structured hierarchically.
3.4.2</p>
      </sec>
      <sec id="sec-10-2">
        <title>Processing speed</title>
        <p>Processing speed can be assumed to be directly related to the length
and the complexity of the MPN: The shorter the MPN and the less
complex (i.e., the fewer associations) the faster the human user will
be able to map the MPN to the product. Direct mappings can be
assumed to be faster than hierarchical mappings, because each level
in the hierarchy requires a separate mapping, while a direct mapping
– once sufficiently learned – involves only a single mapping process.
If a hierarchical MPN is employed, the order in which MPN parts
signifying different (sub)categories appear in the MPN will have an
influence in processing speed. At least in western culture languages,
representing highest to lowest (sub)categories by MPN parts ordered
from left to right (the predominant reading direction) will likely lead
to faster MPN processing than other orderings. Consequently, the
processing speed of MPN increases
• The shorter the MPN,
• The fewer associations are involved,
• The fewer hierarchical levels are involved, and
• The more the ordering of the hierarchy levels in the MPN
corresponds to the reading direction.
4</p>
      </sec>
    </sec>
    <sec id="sec-11">
      <title>USE CASES</title>
      <p>
        Motivated by the diversity of the customer requirements and
specificity of product configuration in the B2B markets, we propose
five different application scenarios also referred to as “use cases” in
the context of business modeling [
        <xref ref-type="bibr" rid="ref34">34</xref>
        ]. The use cases are based on
the expert interviews and insights from the previous projects (Figure
3). To ensure comparability, we describe each of the use cases using
following characteristics: (i) role of the involved actor, (ii) his/her
aim and objective, (iii) current know-how level in the field, as well
as (iv) what is expected from the desired solution. Consequently,
with the help of the previously introduced evaluation criteria, we
derive individual MPN requirements for each of the use cases (Table
1). For simplicity reasons, the costs relating to the implementation
and maintenance of a specific type of MPN (e.g., establishing the
new MPN structure, employee training, structure maintenance) is
beyond the scope of this paper but should be considered in future
research.
      </p>
      <p>Starting with the customer side, one particular type of users is a
Rare Guest, who is characterized by a low frequency of MPN use
and the need for a specific (one-time) solution. These customers
have little to none expert knowledge on the topic, either because of
the involvement in various supply chains or due to the overall
unwillingness to deal in detail with the product structure of the
particular manufacturer. Their expectation towards the
communication of product variety is a mere satisfaction of their
request with as little effort as possible. In this way, the rare guest
would not appreciate the efficiency of the MPN (e.g., through the
digitalization), but would be disappointed if standard functionalities
are not functioning properly. At the other end of the spectrum, there
is a Power User. Unlike the rare guest, the power user deals with the
respective MPN on a regular basis. Due to the high level of
knowhow both regarding the operating industry and the MPN structure,
the power user is interested in a fast interaction and comparability of
different variants within this particular manufacturer, in order to
attain the optimal solution for a specific situation. Typically, power
users are established via long-term cooperation between companies
and would be interested in a high learnability of the MPN. Moreover,
they personally would even get averse to switch to a purely
machinereadable MPN, since this would make their own know-how obsolete.</p>
      <p>The last external stakeholder of the MPN we consider is the
Purchasing department, who already has a particular product
configuration in mind. Similar to the rare guest, the purchasing
department has little interest in the product itself (or its
configuration), but mostly focuses on getting the best price and most
suitable delivery time. In addition, due to the overall desire for
comparability across different manufacturers, the purchasing
department seeks understandability and simplicity of the MPN and,
if possible, the establishment of an industry-wide standard.</p>
      <p>Apart from the customer-driven requirements towards the MPN,
manufacturer’s internal departments have their own, often
contradictory expectations. For example, the Sales department uses
MPN for selling, searching, and configuring product variants in a
simple and quick manner. Similar to the purchasing department of
the customer, the internal sales department seeks a practical and
catchy MPN structure, which can be used for the external
representation of a large quantity of (homogeneous) products. With
the level of know-how varying according to the position and the
seniority of the sales employees, the efficiency of the sales
department is dependent either on the learnability of the
humanreadable MPN or on the increase of the processing speed due to its
digitalization.</p>
      <p>Finally, the employees working in the internal Production
department of the company are looking for an MPN, which would
both contain information on the internal structure of the product and
have a high level of learnability. Their daily usage of the MPN
involves the identification of the required parts and their assembling
sequence. With a highly specific background knowledge and fast
production processes, production employees would appreciate a
digital MPN only if it can assure a low error rate and not obstruct or
slow them down in their daily activities.
5</p>
    </sec>
    <sec id="sec-12">
      <title>CONCLUSION AND OUTLOOK</title>
      <p>With the increasing customer demands for individualization and an
overall growing complexity of B2B products, part manufacturers are
facing new problems of communicating their product variety in a
transparent and efficient way. In this context, MPNs are used as
codifications of those characteristics that uniquely identify a product
variant out of a modular system, thus acting both as an identifier and
a description. While academia has not yet devoted enough attention
to the topic of MPN, we believe that a correct deployment of the
MPN is a key step to efficient variant management. Therefore, in
this publication, we analyzed the main systemic and cognitive
aspects of the MPN and derived evaluation criteria (i.e. readability,
learnability, and processing speed) for its mapping on the underlying
product structure. We then mapped these evaluation criteria on
various use cases of the internal and external stakeholders, thus
showing that there exists no ideal MPN, but instead it should be
created depending on the respective application scenario.</p>
      <p>This publication also highlights important topics for future
research endeavors. First, despite a detailed analysis of the existing
literature on manufacturing complexity combined with personal
project experience of the authors, we believe that there exist
additional aspects of the MPN and the product structure. Similarly,
future work should differentiate between industries or
companyspecific characteristics.</p>
      <p>
        Altogether, our publication has no claims to completeness but is
intended to serve as a starting point of an academic discussion on the
MPN and the communication of the product variety in general.
Future research should focus more on the differentiation between
different layers of the company, in particular, the production and the
sales layer, which may even lead to different MPNs. Another
research direction is the operationalization of the above-mentioned
mapping by introducing a maturity model [
        <xref ref-type="bibr" rid="ref35">35</xref>
        ] or some other
decision-support framework. This may also include the task on how
to find optimal MPN for a specific set of criteria. A good opportunity
for creating such a model would be by following an action research,
where the transformation of the company’s MPN structure (e.g.,
towards a digital one) is supervised and documented. Finally, the
monetary aspects and the area of cost efficiency in general (e.g.,
calculation of the possible cost savings, if a certain MPN is
introduced), which were not considered in this publication, would
make a major contribution, especially for the practitioners.
      </p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <given-names>S. J.</given-names>
            <surname>Hu</surname>
          </string-name>
          ,
          <string-name>
            <given-names>X.</given-names>
            <surname>Zhu</surname>
          </string-name>
          ,
          <string-name>
            <given-names>H.</given-names>
            <surname>Wang</surname>
          </string-name>
          , and
          <string-name>
            <given-names>Y.</given-names>
            <surname>Koren</surname>
          </string-name>
          , „
          <article-title>Product variety and manufacturing complexity in assembly systems and supply chains“</article-title>
          ,
          <source>CIRP Ann</source>
          .-Manuf. Technol.,
          <source>Bd</source>
          .
          <volume>57</volume>
          ,
          <string-name>
            <surname>Nr</surname>
            . 1,
            <given-names>S.</given-names>
          </string-name>
          45-
          <fpage>48</fpage>
          ,
          <year>2008</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [2]
          <string-name>
            <given-names>C.</given-names>
            <surname>Huffman</surname>
          </string-name>
          and
          <string-name>
            <given-names>B. E.</given-names>
            <surname>Kahn</surname>
          </string-name>
          , „
          <article-title>Variety for sale: Mass customization or mass confusion?“</article-title>
          ,
          <string-name>
            <surname>J. Retail.</surname>
          </string-name>
          ,
          <source>Bd</source>
          .
          <volume>74</volume>
          ,
          <string-name>
            <surname>Nr</surname>
            . 4,
            <given-names>S.</given-names>
          </string-name>
          491-
          <fpage>513</fpage>
          ,
          <year>1998</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3]
          <string-name>
            <given-names>C. Y.</given-names>
            <surname>Baldwin and K. B. Clark</surname>
          </string-name>
          , Design Rules:
          <article-title>The Power of Modularity Volume 1</article-title>
          . Cambridge, MA, USA: MIT Press,
          <year>1999</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [4]
          <string-name>
            <given-names>T.</given-names>
            <surname>Blecker</surname>
          </string-name>
          ,
          <string-name>
            <given-names>N.</given-names>
            <surname>Abdelkafi</surname>
          </string-name>
          ,
          <string-name>
            <given-names>B.</given-names>
            <surname>Kaluza</surname>
          </string-name>
          , G. Kreutler, „
          <article-title>Mass customization vs. complexity: a Gordian knot?"</article-title>
          ,
          <source>Munich Personal RePEc Archive</source>
          ,
          <fpage>890</fpage>
          -
          <lpage>903</lpage>
          ,
          <year>2004</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [5]
          <string-name>
            <given-names>W.</given-names>
            <surname>ElMaraghy</surname>
          </string-name>
          , H. ElMaraghy, T. Tomiyama, and L. Monostori, „
          <article-title>Complexity in engineering design and manufacturing“</article-title>
          , CIRP Ann.,
          <source>Bd</source>
          .
          <volume>61</volume>
          ,
          <string-name>
            <surname>Nr</surname>
            . 2,
            <given-names>S.</given-names>
          </string-name>
          793-
          <fpage>814</fpage>
          ,
          <year>2012</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [6]
          <string-name>
            <given-names>C.</given-names>
            <surname>Forza</surname>
          </string-name>
          and
          <string-name>
            <given-names>F.</given-names>
            <surname>Salvador</surname>
          </string-name>
          , „
          <article-title>Managing for variety in the order acquisition and fulfilment process: The contribution of product configuration systems“,</article-title>
          <string-name>
            <given-names>Int. J.</given-names>
            <surname>Prod</surname>
          </string-name>
          . Econ.,
          <source>Bd</source>
          .
          <volume>76</volume>
          ,
          <string-name>
            <surname>Nr</surname>
            . 1,
            <given-names>S.</given-names>
          </string-name>
          87-
          <fpage>98</fpage>
          ,
          <year>März 2002</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [7]
          <string-name>
            <given-names>P.</given-names>
            <surname>Mishra</surname>
          </string-name>
          and
          <string-name>
            <given-names>T.</given-names>
            <surname>Chandra</surname>
          </string-name>
          , „Mergers,
          <article-title>Acquisitions and Firms Performance: Experience of Indian Pharmaceutical Industry“</article-title>
          ,
          <string-name>
            <surname>Eurasian</surname>
            <given-names>J. Bus. Econ.</given-names>
          </string-name>
          ,
          <source>Bd</source>
          . 3,
          <issue>Nr</issue>
          . 5,
          <string-name>
            <surname>S.</surname>
          </string-name>
          111-
          <fpage>126</fpage>
          ,
          <year>2010</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          [8]
          <string-name>
            <given-names>V.</given-names>
            <surname>Venkatesh</surname>
          </string-name>
          and
          <string-name>
            <given-names>F. D.</given-names>
            <surname>Davis</surname>
          </string-name>
          , „
          <article-title>A theoretical extension of the technology acceptance model: Four longitudinal field studies“, Manag</article-title>
          . Sci.,
          <source>Bd</source>
          .
          <volume>46</volume>
          ,
          <string-name>
            <surname>Nr</surname>
            . 2,
            <given-names>S.</given-names>
          </string-name>
          186-
          <fpage>204</fpage>
          ,
          <year>2000</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          [9]
          <string-name>
            <given-names>F.</given-names>
            <surname>Piller</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Koch</surname>
          </string-name>
          ,
          <string-name>
            <given-names>K.</given-names>
            <surname>Moeslein</surname>
          </string-name>
          , and
          <string-name>
            <given-names>P.</given-names>
            <surname>Schubert</surname>
          </string-name>
          , „
          <article-title>Managing high variety: how to overcome the mass confusion phenomenon of customer co-design“</article-title>
          ,
          <source>in Proceedings of the Proc. 3rd Annual Conf. of the European Academy of Management (EURAM</source>
          <year>2003</year>
          ), Milan, Italy,
          <year>2003</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          [10]
          <string-name>
            <given-names>D. W.</given-names>
            <surname>Hoffmann</surname>
          </string-name>
          , Einführung in die Informations-und Codierungstheorie. Springer,
          <year>2014</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          [11]
          <string-name>
            <given-names>W. Heise und P.</given-names>
            <surname>Quattrocchi</surname>
          </string-name>
          ,
          <article-title>Informations-und Codierungstheorie: mathematische Grundlagen der Daten-Kompression und-Sicherung in diskreten Kommunikationssystemen</article-title>
          . Springer-Verlag,
          <year>2013</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          [12]
          <string-name>
            <given-names>F.</given-names>
            <surname>Piller</surname>
          </string-name>
          and
          <string-name>
            <given-names>C.</given-names>
            <surname>Berger</surname>
          </string-name>
          , „
          <article-title>Customers as co-designers“, Manuf</article-title>
          . Eng.,
          <source>Bd</source>
          .
          <volume>82</volume>
          ,
          <string-name>
            <surname>Nr</surname>
            . 4,
            <given-names>S.</given-names>
          </string-name>
          42-
          <fpage>45</fpage>
          , Aug.
          <year>2003</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          [13]
          <string-name>
            <given-names>A.</given-names>
            <surname>Bask</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Lipponen</surname>
          </string-name>
          , M. Rajahonka, und M. Tinnilä, „
          <article-title>The concept of modularity: diffusion from manufacturing to service production“</article-title>
          ,
          <string-name>
            <surname>J. Manuf. Technol. Manag.</surname>
          </string-name>
          ,
          <source>Bd</source>
          .
          <volume>21</volume>
          ,
          <string-name>
            <surname>Nr</surname>
            . 3,
            <given-names>S.</given-names>
          </string-name>
          355-
          <fpage>375</fpage>
          ,
          <year>2010</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          [14]
          <string-name>
            <given-names>C. Y.</given-names>
            <surname>Baldwin and K. B. Clark</surname>
          </string-name>
          ,
          <article-title>Design rules: The power of modularity</article-title>
          ,
          <source>Bd. 1</source>
          . MIT press,
          <year>2000</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          [15]
          <string-name>
            <given-names>B. J.</given-names>
            <surname>Pine</surname>
          </string-name>
          ,
          <article-title>Mass customization: the new frontier in business competition</article-title>
          . Harvard Business Press,
          <year>1999</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          [16]
          <string-name>
            <given-names>A.</given-names>
            <surname>Lubarski und J. Poeppelbuss</surname>
          </string-name>
          , „
          <article-title>Methods for Service Modularization-A Systematization Framework“</article-title>
          ,
          <source>in Proceedings of the Pacific Asia conference on information systems (PACIS)</source>
          , Chiayi, Taiwan,
          <year>2016</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          [17]
          <string-name>
            <surname>H.</surname>
          </string-name>
          <article-title>ElMaraghy u. a., „Product variety management“</article-title>
          , CIRP Ann.,
          <source>Bd</source>
          .
          <volume>62</volume>
          ,
          <string-name>
            <surname>Nr</surname>
            . 2,
            <given-names>S.</given-names>
          </string-name>
          629-
          <fpage>652</fpage>
          ,
          <year>2013</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          [18]
          <string-name>
            <given-names>B.</given-names>
            <surname>Avak</surname>
          </string-name>
          , „
          <article-title>Variant management of modular product families in the market phase“</article-title>
          ,
          <source>ETH Zurich</source>
          ,
          <year>2006</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          [19]
          <string-name>
            <surname>Gartner</surname>
            <given-names>IT Glossary</given-names>
          </string-name>
          , „Configure, Price,
          <string-name>
            <surname>Quote (CPQ) Application</surname>
            <given-names>Suites</given-names>
          </string-name>
          “.
          <fpage>16</fpage>
          -Apr-
          <year>2018</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref20">
        <mixed-citation>
          [20]
          <string-name>
            <given-names>S.</given-names>
            <surname>Tsukatani</surname>
          </string-name>
          ,
          <string-name>
            <given-names>T.</given-names>
            <surname>Inokuchi</surname>
          </string-name>
          , and
          <string-name>
            <given-names>H.</given-names>
            <surname>Ito</surname>
          </string-name>
          ,
          <article-title>„Multi-session disc-shaped for recording audio and computer data having disc type code area located in each session for recording common and particular disc type code“</article-title>
          , Juli-
          <year>1998</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref21">
        <mixed-citation>
          [21]
          <string-name>
            <given-names>D. E.</given-names>
            <surname>Denning</surname>
          </string-name>
          and
          <string-name>
            <given-names>D. K.</given-names>
            <surname>Branstad</surname>
          </string-name>
          , „
          <article-title>A taxonomy for key escrow encryption systems“, Commun</article-title>
          . ACM, Bd.
          <volume>39</volume>
          ,
          <string-name>
            <surname>Nr</surname>
            . 3,
            <given-names>S.</given-names>
          </string-name>
          34-
          <fpage>40</fpage>
          ,
          <year>1996</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref22">
        <mixed-citation>
          [22]
          <string-name>
            <given-names>R.</given-names>
            <surname>Elz</surname>
          </string-name>
          , „Serial number arithmetic“,
          <year>1996</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref23">
        <mixed-citation>
          [23]
          <string-name>
            <given-names>J.</given-names>
            <surname>Schickler</surname>
          </string-name>
          , „
          <article-title>Parts search system“</article-title>
          , Aug-
          <year>2004</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref24">
        <mixed-citation>
          [24]
          <string-name>
            <given-names>R. K.</given-names>
            <surname>Yin</surname>
          </string-name>
          ,
          <article-title>Case study research and applications: Design and methods</article-title>
          .
          <source>Sage publications</source>
          ,
          <year>2017</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref25">
        <mixed-citation>
          [25]
          <string-name>
            <given-names>B. J.</given-names>
            <surname>Baars</surname>
          </string-name>
          and
          <string-name>
            <given-names>N. M.</given-names>
            <surname>Gage</surname>
          </string-name>
          ,
          <article-title>Fundamentals of cognitive neuroscience: a beginner's guide</article-title>
          . Academic Press,
          <year>2013</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref26">
        <mixed-citation>
          [26]
          <string-name>
            <given-names>N.</given-names>
            <surname>Cowan</surname>
          </string-name>
          , „
          <article-title>The magical number 4 in short-term memory: A reconsideration of mental storage capacity“, Behav</article-title>
          . Brain Sci.,
          <source>Bd</source>
          .
          <volume>24</volume>
          ,
          <string-name>
            <surname>Nr</surname>
            . 1,
            <given-names>S.</given-names>
          </string-name>
          87-
          <fpage>114</fpage>
          , Feb.
          <year>2001</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref27">
        <mixed-citation>
          [27]
          <string-name>
            <given-names>G. A.</given-names>
            <surname>Miller</surname>
          </string-name>
          , „
          <article-title>The magical number seven, plus or minus two: Some limits on our capacity for processing information</article-title>
          .“,
          <string-name>
            <surname>Psychol. Rev.</surname>
          </string-name>
          ,
          <source>Bd</source>
          .
          <volume>63</volume>
          ,
          <string-name>
            <surname>Nr</surname>
            . 2,
            <given-names>S.</given-names>
          </string-name>
          <year>81</year>
          ,
          <year>1956</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref28">
        <mixed-citation>
          [28]
          <string-name>
            <given-names>A.</given-names>
            <surname>Baddeley</surname>
          </string-name>
          , „
          <article-title>Working memory: theories, models</article-title>
          , and controversies“,
          <source>Annu. Rev. Psychol</source>
          .,
          <source>Bd</source>
          . 63, S.
          <fpage>1</fpage>
          -
          <lpage>29</lpage>
          ,
          <year>2012</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref29">
        <mixed-citation>
          [29]
          <string-name>
            <given-names>Y.</given-names>
            <surname>Dudai</surname>
          </string-name>
          , „
          <article-title>How big is human memory, or on being just useful enough</article-title>
          .“, Learn. Mem.,
          <source>Bd</source>
          . 3,
          <issue>Nr</issue>
          . 5,
          <string-name>
            <surname>S.</surname>
          </string-name>
          341-
          <fpage>365</fpage>
          ,
          <year>1997</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref30">
        <mixed-citation>
          [30]
          <string-name>
            <surname>J. R. Anderson</surname>
          </string-name>
          ,
          <article-title>Cognitive psychology and its implications</article-title>
          .
          <source>Macmillan</source>
          ,
          <year>2005</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref31">
        <mixed-citation>
          [31]
          <string-name>
            <given-names>T. P.</given-names>
            <surname>McNamara</surname>
          </string-name>
          , „
          <article-title>Mental representations of spatial relations“, Cognit</article-title>
          . Psychol.,
          <source>Bd</source>
          .
          <volume>18</volume>
          ,
          <string-name>
            <surname>Nr</surname>
            . 1,
            <given-names>S.</given-names>
          </string-name>
          87-
          <fpage>121</fpage>
          ,
          <year>1986</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref32">
        <mixed-citation>
          [32]
          <string-name>
            <given-names>A. M.</given-names>
            <surname>Collins</surname>
          </string-name>
          and
          <string-name>
            <given-names>M. R.</given-names>
            <surname>Quillian</surname>
          </string-name>
          , „
          <article-title>Retrieval time from semantic memory“</article-title>
          ,
          <source>J. Verbal Learn. Verbal Behav</source>
          .,
          <source>Bd</source>
          . 8,
          <issue>Nr</issue>
          . 2,
          <string-name>
            <surname>S.</surname>
          </string-name>
          240-
          <fpage>247</fpage>
          ,
          <year>1969</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref33">
        <mixed-citation>
          [33]
          <string-name>
            <given-names>J. L.</given-names>
            <surname>Voss</surname>
          </string-name>
          <article-title>, „Long-term associative memory capacity in man“</article-title>
          ,
          <source>Psychon. Bull. Rev., Bd</source>
          .
          <volume>16</volume>
          ,
          <string-name>
            <surname>Nr</surname>
            . 6,
            <given-names>S.</given-names>
          </string-name>
          1076-
          <fpage>1081</fpage>
          ,
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref34">
        <mixed-citation>
          [34]
          <string-name>
            <given-names>H.-E.</given-names>
            <surname>Eriksson</surname>
          </string-name>
          and
          <string-name>
            <given-names>M.</given-names>
            <surname>Penker</surname>
          </string-name>
          , „
          <article-title>Business modeling with UML“</article-title>
          , N. Y.,
          <source>S. 1-12</source>
          ,
          <year>2000</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref35">
        <mixed-citation>
          [35]
          <string-name>
            <surname>M. C.</surname>
          </string-name>
          <article-title>Paulk, The capability maturity model: Guidelines for improving the software process</article-title>
          .
          <source>Addison-Wesley Professional</source>
          ,
          <year>1995</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>