Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

In Chap. 2, we argue that supply chain configuration is one of the principal supply chain management decisions and that it has a profound impact on other subsequent managerial decisions. As described therein, the supply chain configuration problem is a complex problem, which is composed of several sub-problems. It is also emphasized that the solutions to these problems require design, modeling, and problem-solving techniques based on knowledge from various fields such as systems science, systems engineering, operations research, industrial engineering, decision sciences, management science, statistics, information sciences, computer science, and artificial intelligence. Some of the prominent techniques utilized from these fields are information modeling, process modeling, simulation modeling, data mining, and optimization. We build on this proposition by adopting a key problem of information integration in the supply chain, which has an embedded structure representing various sub-problems, and how its management relates many of the concepts espoused in this book about supply chain configuration. Also, this problem serves as a prime example of how crosscutting approaches drawn from various disciplines highlighted above may be adopted in devising solutions for the complex supply chain configuration problem. Before we proceed further, let us first develop a clear understanding of the information integration problem in the supply chain.

The Supply Chain and the Information Integration Problem. One way to look at a supply chain is as an alignment of firms that bring products or services to the market (Lambert et al. 1998). This alignment is in the form of an extended enterprise, where firms collectively organize the supply, production, and distribution of products and services.

The management of such a complex organization can be brought to the integration of its business processes. Process-oriented management vs. function-oriented management is an important feature that makes the supply chain a distinct enterprise system class. Another facet of supply chain system complexity is its organizational dynamics and operational specifics. Organizational dynamics assumes frequent changes in organizational structures such as control hierarchy, goal structure, members’ network, and so on. Operational specifics are mainly related to the uncertainty in which a supply chain organization operates. Integration of supply chain processes assumes additional complexity when the decision-making mode (i.e., centralized vs. decentralized) is considered in the mix.

One of the key issues in managing a supply chain process is information integration among its constituents. To facilitate this integration, supply chain information resources ought to be effectively organized and shared. Information integration provides channels that convey information from one supply chain constituent to another. One form of this problem involves the integration of existing implementations that have been built in heterogeneous infrastructures, such as different hardware platforms, operating systems, and database management systems. Presenting the data on which applications perform in a uniform, self-consistent way ensures that they share the same view of the supply chain. Another form of integration is concerned with working collectively on common problems by sharing an understanding of the problems’ reasoning logic and applying best practices. This provides a common architecture in information sharing so that supply chain members’ collaborative activities provide performance improvement to each member and to the entire supply chain.

The problem of process integration, and its surrogate information integration described above, needs an appropriate solution. In this context, we advocate the necessity of applying system principles and knowledge management methodologies based on the following reasons: (1) the extent of knowledge becomes intractably large, (2) business units are geographically decentralized but more closely networked, (3) collaboration among individual workers is important, and (4) challenges are faced in eliciting requirements when user partners are large, decentralized, and unknown.

In this chapter, we propose a framework and implementation mechanisms for designing a knowledge management system capable of supporting organizational dynamics and operational uncertainty, as well as facilitating process integration in a supply chain. Taxonomies and ontologies are viewed as a means for conceptualizing the knowledge to share and utilize in decision-modeling applications. They bring formalism into the knowledge management system, thus offering standards for communication, which is necessary for collaborative problem solving.

The general trend in process integration is to develop information models that system users can share, thereby sharing the same view of the world (CIMOSA (Kosanke 1995), TOVE (Gruninger et al. 2000), Supply chain ontology (Grubic et al. 2011). The gap seen in these and other research efforts is the absence of a system reference model that can identify information model components and define mechanisms for their design and implementation. This reference model formally represents the source system, such as supply chain, its informational needs, and constructs that need to be built to support system processes. The ultimate target and value of the proposed approach, and hence the reference model is taxonomy and ontology development as a platform for integrated supply chain knowledge management. That is particularly important in the era of web-based supply chain collaboration and cloud computing, where the reference models and integration standards provide the basis of knowledge sharing and supply chain integration (Huang and Lin 2010).

Further, the proposed reference model enables fulfilling the purpose of this chapter in laying the ground work for integrated solutions proposed in Chaps. 7–9. The importance of this chapter is to highlight that solutions to supply chain configuration problems must integrate complex modeling and analysis techniques drawn from a host of disciplines.

The chapter is organized as follows. Section 6.2 describes the motivation, focus, and significance of crosscutting approaches. Section 6.3 discusses the notion of taxonomy and ontology and how it contributes to system integration. Section 6.4 introduces the knowledge management system development framework, which starts from the source system, goes through system component decomposition, and presents knowledge-modules design for these components. Section 6.5 formally presents the knowledge management system reference model, relating elements in the proposed framework and describing their meaning. Section 6.6 presents four stages of the knowledge management system development life cycle, as well as describes how the reference model can be implemented for each stage.

2 Crosscutting Approaches: Motivation, Focus, and Significance

Supply chain configuration draws from an array of fields as far as framework, models, and methodologies are concerned. This is primarily owing to the impact of any configuration effected on a supply chain, on its strategic, tactical, and operational decision-making environments. In this section, we discuss the motivation behind developing an integrated supply chain configuration framework and a reference model for designing knowledge and its management, with the aim of improving supply chain management.

2.1 Motivation and Focus

The motivation and focus of the research methodology proposed in this chapter is to integrate various problem-solving approaches from a host of fields in the design of proposed supply chain configuration problem-solving methodologies. It is characterized by two main purposes: general and specific.

The general purpose is to develop a common body of interdisciplinary knowledge to understand issues and problems related to reconfigurable systems.

The specific purpose is to (a) develop methodology and tools for supply chain reconfiguration, (b) elaborate framework for knowledge-based problem analysis and model building, and (c) quantify factors influencing supply chain reconfiguration.

The general problems in reconfigurable systems can be classified as related to the system’s environment, availability of appropriate modeling tools, interconnectedness of decisions at various levels of supply chain, and availability of common knowledge throughout the system. These can be listed as follows:

  • Increasing competitive pressures and consumer focus requires innovative supply chain modeling and management tools.

  • Supply chain modeling tools must capture complex interactions within the supply chain.

  • Supply chain configuration decisions have significant impact on other decisions at all levels.

  • Knowledge assumes a critical role in a firm’s success, and, therefore must be captured, organized and utilized effectively.

Problem-solving strategies applied to reconfigurable manufacturing systems entail developing (a) domain independent solution(s) templates at the macro level, (b) capability models for application specific domain dependent problems at the micro level, and (c) coordination models to integrate models developed in (a) and (b).

2.2 Problem Solving for Configurable Systems

To provide an integrated overview of interconnectedness of crosscutting research areas for configurable systems, three problem-solving approaches are proposed: systemic, reductionist, and analytic. These are defined as follows:

  • Systemic Approach This incorporates the abstract level. This level of inquiry deals with issues of scalability of system, meta-modeling of systems, and defining the dynamic knowledge problem domain model.

  • Reductionist Approach. This incorporates the activity level. This level of inquiry consists of dynamic knowledge problem domain model, internal state, and goals and objectives of the enterprise units, (producer, plant, department, supplier, vendor, etc.), and strategic management models.

  • Analytic Approach. This incorporates the implementation level. This level of inquiry consists of internal state, goals and objectives of the enterprise units, strategic management models, and shared goals and objectives of the enterprise.

We discuss below related research in direct comparison to these three problem-solving approaches.

At the systemic level, a supply chain is a general class of system that exhibits a cooperative behavior within its business and market environment (Klir 1991). The foundation of this system is built on a network architecture that has various demand and supply nodes as it provides, as well as receives goods and services to and from its customers and suppliers, respectively (Chandra 1997; Lee and Billington 1993; Swaminathan et al. 1998; Bellamy and Basole 2013). Supply chain system frameworks describe general foundational elements of integration between its marketing and production functions. These are in the form of general theories, hypotheses, standards, procedures, and models that are based on well-founded principles in these disciplines (Cohen and Lee 1989; Deleersnyder et al. 1992; Drew 1975; Graves 1982; Hackman and Leachman 1989; Lee 1993; NIST 1999; Tzafestas and Kapsiotis 1994; Younis and Mahmoud 1986). Systems modeling deals with general modeling issues of this class of systems, such as how to represent, quantify, and measure cooperation, coordination, synchronization, and integration (Little 1992; Morris 1967; Pritsker 1997). Systems engineering describes methodologies for structuring systems as these are implemented in various application domains (Blanchard and Fabrycky 1990). System integration deals with achieving common interface within and between different components at various levels of hierarchy in an enterprise (Shaw et al. 1992), as well as different architectures and methodologies (ISO TC 184/SC 5/WG 1 1997; IMTR 1999; Hirsch 1995), using distributed artificial intelligence and intelligent agents (Gruber 1995; Stumptner 1997; Wooldridge and Jennings 1995).

At the reductionist level, a supply chain configuration must be based on its local, as well as global, environmental constraints. These constraints are partly imposed as the supply chain negotiates and compromises to adapt to its cooperative behavior (Jennings 1994). Enterprise modeling as a technique has been used effectively in decomposing complex enterprises, such as a supply chain. Ontologies are defined to describe unique system descriptions of supply chains that are relevant to specific application domains (Gruninger 1997). The classic problem for a supply chain is an inventory management problem requiring coordination of product and information flows through a multi-echelon supply chain. This class of problem has been solved by integration of the front and back ends of the supply chain with costs and lead times as key measures of its performance (Clark 1972; Clark and Scarf 1960; Diks et al. 1996; Diks and De Kok 1998; Hariharan and Zipkin 1995; Pyke and Cohen 1990).

The analytic approach for the general class of supply chains has its origins in economic models of supply and demand coordination. Game Theory principles for payoffs among market competitors have been used effectively to design competitive strategies for supply chains (Gupta and Loulou 1998; Masahiko 1984). Coordination and cooperation—dealing with interfaces between strategies, objectives, and policies for various functions of an enterprise, has received much attention in optimizing the performance of a supply chain (Malone and Crowston 1994; Thomas and Griffin 1996; Whang 1995). Various aspects of cooperation have been prescribed for effective management of supply chains (Sousa et al. 1999).

Starting from the evaluation of existing enterprise integration architectures (CIMOSA, GRAI/GIM, and PERA), the IFAC/IFIP Task Force on Architectures for Enterprise Integration has developed an overall definition of a generalized architecture framework called GERAM or Generalized Enterprise Reference Architecture and Methodology (ISO TC 184/SC 5/WG 1 1997).

2.3 Significance of This Approach

Supply chain management strategies have the potential of enabling smart manufacturing and services

  • Adaptable, and integrated equipment, processes, and systems that can be readily reconfigured.

  • Manufacturing processes that minimize waste.

  • System synthesis, modeling, and simulation for all manufacturing operations.

  • Technologies to convert information into knowledge for effective decision-making.

  • Software for intelligent collaboration systems.

  • New educational and training methods that enable the rapid assimilation of knowledge.

The common thread in the deployment of these technologies is achieving (a) reconfigurability, (b) efficiency, and (c) complex modeling and analysis in decision-making related to managing advanced manufacturing systems.

This emphasis on developing enhanced manufacturing capabilities and technologies to support infrastructure mandates research in following crosscutting areas

  • Adaptable and reconfigurable manufacturing systems.

  • Information and communication technologies.

  • Processes for capturing and using knowledge for manufacturing.

  • Adopting and incorporating IT into collaboration systems and models focused on improving methods for people to make decisions, individually and as a group.

  • Enterprise modeling and simulation.

  • Analytical tools for modeling and assessment.

  • Managing and using information to make intelligent decisions among a vast array of alternatives.

  • Adapting and reconfiguring manufacturing enterprises to enable formation of complex alliances with other organizations.

The objective of the research presented in this chapter is to formalize the capture and management of supply chain management knowledge accumulated in various domains of science, engineering, and technology, and using various problem-solving techniques.

3 Taxonomy, Ontology, and System Integration

To see linkages between problems and decision-making models utilized in a complex enterprise such as a supply chain, it is imperative that these components be formally represented. Taxonomy and ontology provide the means to classify the supply chain problems and represent formal knowledge, which is used in decision-making. We take up discussion on this topic next.

3.1 Taxonomy

According to the American Heritage® Dictionary of the English Language, Fourth Ed. (2000), taxonomy is the classification of organisms in an ordered system that indicates natural relationships. It is the science, laws, or principles of classification. Further, it is an arrangement by which systems may be divided into ordered groups or categories according to common characteristics.

System taxonomy reflects information about relationships both inside the system, and with its surrounding environment. Supply chain system taxonomy aims to provide a multidisciplinary representation of supply chain activities and characteristics. The review of research in the field of supply chain taxonomy development reveals that most of them are based on single case studies, providing taxonomy for a subset of information. System taxonomy is organized for the entire system. Organizing information representation for a part of a system or for one problem jeopardizes decision-making because it may miss some key aspects. The supply chain is an organization whose components are interrelated to each other. This cohesion makes the system unmanageable if it is considered as one unbreakable unit. Based on biological classification, system taxonomy provides mechanisms for dividing a supply chain system into relatively independent units, providing as minimal a coupling between units as possible by collecting characteristics in groupings by their similarity. Further, iterative decomposition of groupings and creating new groupings can build a robust hierarchy of describing system characteristics.

System taxonomy serves two purposes: (1) standardization of terms and definition, and (2) unification of information representation. This brings out reusability of developed information models, as well as organization and structure, to knowledge management. Scalability and traceability are the most important features that system taxonomy provides, and thus, new features can be added and existing ones easily found.

3.2 Ontology

In the Artificial Intelligence (AI) literature, ontology is defined as the study of the kinds of things that exist (Sowa 2000). In AI, programs and logic deal with various kinds of objects, and we study what these kinds are and their basic properties (McCarthy 2003). Over the years, ontology has become more than an abstract representation of objects and their properties and is becoming a part of the software application domain with application to other branches of AI, such as heuristics and epistemology. The latter is a study of the kinds of knowledge that are required for solving problems in the world, and the former is a way of trying to discover something, or an idea embedded in a program. Along with shaping its pragmatic purpose, ontology has found its application in many fields, such as knowledge representation, system integration, enterprise modeling, conceptual modeling, and Semantic Web.

The above definition of ontology by Sowa (2000), as a study of the kinds of things that exist, is very generic. However, during the last two decades, several features of ontology have evolved that define its broader and more diverse scope and purpose in designing information support for decision-making. A review of the pertinent literature offers the following contrasting definitions and interpretations of ontology to validate our above assertions:

  • Ontology is an explicit specification of conceptualization (Gruber 1993), meaning that ontology defines kinds of things, their possible relationships, and plausible implementation.

  • Ontology is a catalog of types of things that are assumed to exist in a domain of interest, D, from the perspective of a person who uses a language, L, for the purpose of talking about D (Sowa 2000). This feature of ontology assumes the existence of a language with enough expressiveness for representing the domain of interest.

  • Ontology refers to an engineering artifact, constituted by a specific vocabulary that is used to describe a certain reality and by a set of explicit assumptions regarding the intended meaning of words in the vocabulary (Guarino 1995). This definition of ontology adds a new feature requiring that it must have mechanisms and terminology for describing the meaning of words and vocabulary as well as their interpretations.

Ontology as a tool for information modeling has been adopted for a large body of research initiatives. As part of the research described in this chapter, a number of ontology tools, languages, and research projects have been studied to understand the role of ontology in information support systems, particularly for information integration. Some of them, such as Ontolingua (Farquhar et al. 1997) and OntoBroker (Fensel et al. 2001), investigate ontology narrowly as a standalone discipline. Other projects, such as TOVE (Fox and Gruninger 1999; Fox et al. 2000) and DOGMA (Meersman 2001), combine knowledge organization with specific domains, investigating agents for which knowledge is organized. Others look at the problem more widely, including development of ontologies in enterprise modeling systems, such as Enterprise (Stader 1996) and Process Handbook (Malone et al. 1999), aiming to support organizations effectively in change management. What is common in all of these projects, however, is that ontology explicitly defines the vocabulary presented with a language in which queries and assertions are exchanged among users (Grubic and Fan 2010). The next section describes the knowledge management system development stages in a framework.

4 Knowledge Management System Development: A Proposed Framework

The framework for knowledge management system conceptualization is depicted in Fig. 6.1. Based on the theoretical background developed in Sect. 6.3, a technique is proposed for conceptualizing supply chain organization and problem knowledge. The proposed advances offer integration of knowledge components with decision support systems and their consumption by software applications or agents. Knowledge components encompass ontology models and the infrastructure supporting their creation, storage, and use.

Fig. 6.1
figure 1

The conceptual framework of a knowledge management system

Full size image

To serve the needs of a knowledge management system in formalizing and delivering knowledge to decision-modeling applications, several requirements are imposed on ontology conceptualization, such as (1) systematic principles for knowledge conceptualization, (2) the problem-specific nature of ontology constructs, (3) the modularity and object nature of formed knowledge, (4) reusability of created knowledge, (5) integration of distributed data, and (6) machine-readable format of delivered knowledge.

The genesis of the proposed framework is taxonomy and its amplifications to problems and problem-solving techniques, particularly when applied to supply chain management.

4.1 Taxonomy Development

Taxonomy is a systematic representation of a system’s existence (McKelvey 1982). Accordingly, taxonomy is built based on principles of system theory. It is a mechanism for structuring the knowledge about a certain system domain. The process of taxonomy development consists of information collection, systematic analysis, and classification of system attributes.

Problem taxonomy provides the overall framework under which problem-oriented information system components can be designed and implemented.

Supply chain problem taxonomy comprises: (a) classification of supply chain problems, (b) classification of problem solving methodologies for supply chain management, and (c) hierarchical classification of variables or factors necessary for dealing with such problems. We explain this concept with the help of one of the fundamental problems in the supply chain management literature—the bullwhip effect .

The Bullwhip Effect

The most downstream supply chain unit observes an external demand, transmitted up on a supply chain as inventory replenishment orders move from one unit to another. It has been observed that substantial information distortion may occur during this transmission. This information distortion, known as the bullwhip effect, appears as an order variance increase as one moves up the supply chain.

Classification of the Bullwhip Effect Problem

The bullwhip effect is a prime example of problems encountered in a complex system, such as the supply chain. In these systems, problems are multifaceted with a primary problem and many related sub-problems. For instance, the bullwhip effect, one of the fundamental problems in supply chain management literature (Lee et al. 1997a), has several secondary problems, such as order management, demand forecasting management, inventory management, and shipment consolidation. Further, Lee et al. (1997a) formally identify the main causes of the bullwhip effect, while Lee et al. (1997b) discuss their managerial implications. They state that if the following conditions hold—(1) demand is mean stationary and no signal processing is used, (2) lead time is zero, (3) fixed ordering cost is zero, and (4) no price variation occurs—then the order variance increase does not occur. However, if some of these conditions are relaxed, the bullwhip effect may be observed.

Classification of Techniques

We need to discuss some of the published techniques utilized in managing the bullwhip effect to highlight their classification. Chen et al. (2000a) use the simple moving average forecasting technique to obtain forecasts and investigate the bullwhip effect according to lead time and information sharing. Chen et al. (2000b) and Xu et al. (2001) use the exponential smoothing technique in forecasting. Chen et al. (2000b) also show that, if a smoothing parameter in exponential smoothing is set to have equal forecasting accuracy for both exponential smoothing and moving average methods, then exponential smoothing gives larger order variance. Graves (1999) demonstrates the presence of the bullwhip effect, if external demand, which is the first-order integrated moving average process, is forecasted using exponential smoothing with an optimally set smoothing parameter. Metters (1997) measures the impact of the bullwhip effect by comparing results obtained for highly variable and seasonal demand against the case with low demand variability and weak seasonality. Cachon (1999) proposes methods to reduce the bullwhip effect using balanced ordering.

Problem model taxonomy is a projection of system taxonomy, and thus inherits system structure and vocabulary. A problem domain is presented at two levels—generic problem domain and specific problem domain. Generic problem domain taxonomy is a class of problems that can occur in a supply chain, such as coordination of production activities. It is a highly generic problem that comprises several tasks, such as scheduling of production or inventory replenishment, which are problems describing more specific issues. Usually, specific problem domain taxonomy is represented by domain-dependent (or specialized) model(s). Splitting problem representation modeling into the above defined two parts provides the means for developing generic and specific problem models.

The process of problem model taxonomy development starts with problem domain space identification. This involves analysis and design of functional requirements for the problem and proposing a structured representation of relevant information. For example, for a scheduling of production problem, the model comprises its input and output variables, underlying sub-tasks or activities, tools and mechanisms for solving the problem, problem-oriented goals, roles and agents involved in performing them in accomplishing tasks to achieve identified goals, and external environmental issues. The purpose of problem taxonomy (PT) is the systematic representation of supply chain domain constituents, such as problems and their content.

Different problem models have the same representation format and characteristics vocabulary, thus providing standardization of information representation in the supply chain domain. Problem model taxonomy serves as a meta-model for knowledge model generation and ontology engineering. Ontology inherits concepts, subsumption relationships, and characteristics from the problem model, thus providing consistency in representing various problems. Ontology development components enrich the problem model with constructs, thus turning it from an abstract problem representation into a knowledge model by formulating rules and regulations related to the problem domain. These constructs are: (1) axioms, defining rules specific to the problem domain; (2) algorithms, providing step-by-step procedures for approaching the problem and solving it; and (3) commitments, linking characteristics to data and assigning variables with values. The first two components are modeled through a comprehensive analysis of the problem. System analysis and design techniques, such as process modeling and object-oriented design, are applied for this purpose. The identification of the first two components is the most important part of ontology development. Ontology by itself is a vocabulary with rules on its use. Real world applications require data to operate. Ontological commitments provide these data.

Object model generation is a software engineering practice. If parallels are drawn with software engineering, ontologies can be considered as classes, while object models are their instances encapsulated into software entities. Object models are tangible software constructs, where problem-specific data are represented in a common programming language, encapsulated in a formal model, and accompanied with descriptions of what to do with the data and how to do it.

The next section formalizes the proposed framework with the help of a knowledge management system reference model.

5 Knowledge Management System Reference Model

The knowledge management system reference model is proposed as a theoretical foundation for building knowledge-based information systems. It follows various stages in the above-described framework and formally represents its component types, their meaning, and functions. The reference model is divided into three parts: source system representation (system taxonomy), supply chain functional requirements representation (problem taxonomy), and formal knowledge representation (ontology). First, notation to represent the reference model is presented. Next, the reference model is formally enumerated in the form of a set of equations.

Notations related to general problem representation

S

System

T

Thing symbolizing the elements of a system

R

Relationships among things of a system defined on T

GP

Generic problem model

at i

Attribute (the index i here and afterwards signifies the ith attribute in the set of attributes)

At i

Set of instances of at i attribute

vv i

Variable that can be assigned to attribute at i for generic problems

VV i

Set of possible values that variable vv i may possess

ww i

System generic state for vv i , respectively

WW i

Set of possible states of ww i

Notations related to specific problem representation

Ob

Object model

b i

Observation channel

B i

Set of possible b i states

SP

Specific problem model

v i

Variable that can be assigned to attribute at i for specific problems

V i

Set of possible values that variable v i may possess

w i

System specific state

W i

Set of possible states w i

o i

Observation channel for attributes at i

Õ

Relationship between object system and problem system

W

Class instances of S for supply chain domain (general representation of W i )

Notations common for specific and general problem representations

Ê

Relationship between specific and generic systems

e i

Relationship between V i , VV i

k j

Relationship between W j , WW j (the index j signifies the jth relationship between general WW j and specific W j system states as well as between B j and W j )

S w

Specific system for supply chain domain (an instance of S )

T w

Things specific to supply chain domain (an instance of T )

R w

Set of relationships held on T W

Notations for ontology

M

Data model for a supply chain domain

I

Ontological commitments

V

Set of variables (General representation of V i )

B w

Observation channels for defining variables

B C

Observation channels for defining constraints

B H

Observation channels for defining algorithms

J

Set of Interpretation functions I

M w

Data model for a supply chain problem

C

Constraints on data

O

Ontology model

A

Set of axioms

H

Algorithm or heuristics

G

Set of equations

The system consists of interrelated elements. Ackoff (1971) identifies system characteristics, such as an abstract and a concrete system, system state, its changes, and so on. These characteristics guided us during the development of the reference model. System taxonomy is an abstract system whose elements are concepts. Problem taxonomy has two system representation forms—abstract system representation, where problem-relevant elements are presented as concepts: and concrete system representation, where these elements are presented as objects. Ontology presents the states of the system from both static and dynamic perspectives. Ontology also presents system behavior such as response or reaction.

The approach for source abstract system representation is adopted from Klir (1984) and can be formulated as follows:

$$ S=\left(T,R\right) $$
(6.1)

Formally, a supply chain system can be represented as a collection of all possible instances of a generic system applied to a supply chain, with corresponding relationships

$$ S=\left(T,W,R\right) $$
(6.2)

Equation (6.1) is a highly generic and domain-independent system representation. Equation (6.2) is still generic, but is a domain-dependent representation. Only those things and their relationships are considered to exist in system instances W. Equation (6.2) is the system taxonomy formalism, where W is the supply chain domain. A detailed description of the taxonomy of a system in general can be found in Chandra et al. (2007). For each possible system instance w ∈ W, the intended structure of w according to S is the structure (problem classification in problem taxonomy)

$$ {S}_w=\left({T}_w,{R}_w\right) $$
(6.3)

R w is the set of extensions (relative to w) of elements of T w

$$ R=\left\{{R}_w\Big|w\in W\right\},\;T=\left\{{T}_w\Big|w\in W\right\}\Big| $$
(6.4)

We denote with S the set of all the intended system instance structures of the system

$$ S=\left\{{S}_w\Big|w\in W\right\} $$
(6.5)

Equations (6.4) and (6.5) reveal that for each system instance w, there is only one system structure S w with one set of things T w and one set of relationships R w . Each S w is a description of a problem (model) defined as a part of problem taxonomy for which a solution is to be found. S w contains the names of parameters identified in the problem description, with corresponding relationships organized in a structured hierarchy. Problem model development based on this formalism offers two sublevels of the problem-modeling layer: problem object model and problem formal model.

Problem Object Model and Problem Formal Model

The notion of thing is abstract. To investigate a single thing, we separate it from the outside world, and examine it as an object.

$$ Ob=\left(\left\{\left(a{t}_i,A{t}_i\right)\Big|i\in {N}_n\right\},\left\{\left({b}_j,{B}_j\right)\Big|j\in {N}_m\right\}\right) $$
(6.6)

where N n  = {1,2,…,n} is the number of attributes that the object Ob possesses; and N m  = {1,2,…,m} is the number of observation channels where attributes are examined and collected. N n and N m are the rows and columns, respectively, of a two-dimensional matrix with n rows and m columns. Observation channels are situations, circumstances, processes, narrative descriptions, or any other sources where the problem can be investigated. The set of possible observation channels is denoted by B j . Different observations where attributes are examined are called backdrops. When investigating a more specific system, backdrops can be considered as situations, where we examine the same attribute. These situations can be subdomains or problems. (at i , At i ) denotes an attribute and a set of its appearances (possible values that the attribute can possess), respectively. (b j , B j ) denotes an observation channel and a set of its states, respectively.

Ob is the object (an instance of a thing). Variables are used for an operational representation of an attribute. Each attribute has a name, which is taken from the set of possible values (At i ).

Attributes define two types of variables general and specific for use in general and specific models, respectively. General and specific variables are components of three primitive systems: object system, specific problem system, and general problem system. The last two primitive system representations connect observed domain attributes to real world variables, which this book classifies as ontological commitments. Separation of generic and specific objects is comparative. In some situations, only one problem model is required, while in other cases two or more problem models are necessary to alleviate the complexity by separating problem domains into information models with various levels of abstractions. Two levels of abstraction are discussed: generic Eq. (6.8) and specific Eq. (6.7).

$$ SP=\left(\left\{\left({v}_i,{V}_i\right)\Big|i\in {N}_n\right\},\left\{\left({w}_j,{W}_j\right)\Big|j\in {N}_m\right\}\right) $$
(6.7)
$$ GP=\left(\left\{\left(v{v}_i,V{V}_i\right)\Big|i\in {N}_n\right\},\left\{\left(w{w}_j,W{W}_j\right)\Big|j\in {N}_m\right\}\right) $$
(6.8)

SP contains variables v i related to a specific problem, and GP contains variables related to a general problem vv i . Both specific and general variables may have sets of states (values vv i ; VV i ) and participate in a set of system states (situations ww j ; WW j ). A specific problem model contains variables related to a set of abstractions (one for each variable), expressing the relationships between specific and general problem systems. It can be called an abstraction channel, which formally can be represented in Eq. (6.9) as

$$ \widehat{E}=\left(\left\{\left(V{V}_i,{V}_i,{e}_i\right)\Big|i\in {N}_n\right\},\left\{\left(W{W}_j,{W}_j,{k}_j\right)\Big|j\in {N}_m\right\}\right) $$
(6.9)

The relationship between the object system and the problem system Eq. (6.10) is expressed by an observation channel consisting of individual observation channels for each attribute in the examined system.

$$ \tilde{\mathrm{O}}=\left(\left\{\left(A{t}_i,{V}_i,{o}_i\right)\Big|i\in {N}_n\right\},\left\{\left({B}_j,{W}_j,{w}_j\right)\Big|j\in {N}_m\right\}\right) $$
(6.10)

The notion of thing about a particular problem can be formulated as

$$ {T}_w=\left(Ob,GP,SP\right) $$
(6.11)

Relationships among things can be formulated as

$$ {R}_w\cup \tilde{\mathrm{O}}\cup \widehat{\mathrm{E}} $$
(6.12)

Equation (6.12) comprises all possible relationships that may exist in system instance w. To keep the model simple, we will refer to the problem model Eq. (6.3) as the object model and to the set of relationships as R w . A problem model S w is an abstract representation of a problem domain—a meta-model. Ontological commitments are for developing a data model out of this meta-model. These commitments are interfaces between abstract problem representation and real world data storage. Rearranging the standard definition, we can define a model M as a structure (S, I), where S = (T, R) is a global structure (standard system definition) and I is an interpretation function assigning elements of T to constant symbols (variables) of V.

$$ M=\left(S,I\right) $$
(6.13)
$$ I=\left(V\to {T}_w\cup {B}_w\right) $$
(6.14)

I in Eqs. (6.13) and (6.14) is a function that through observation channel B assigns attributes of T to variables of V. This intentional interpretation can be classified as the first ontological commitment. Observation channels are situations where the system state is captured to observe variables V. These can be process models, where required variables participate. Studying the documented process model may reveal the meaning of variables and where they can be taken from. Another example of an observation channel can be database schema, precisely describing how variables can be queried and stored. The model representation can be used for more general cases:

$$ M=\left(T,W,\ R,\ J\right) $$
(6.15)

These are data models for a system in general, including all of its instances and possible interpretations. Equation (6.15) is not practical, because it will never be implemented for presenting actual system data models. Rather, data model presentations for specific system instances are more practical. If we assume S w  ∈ S, for each instance w ∈ W

$$ {M}_w=\left({T}_w,{R}_{\mathrm{w}},I\right) $$
(6.16)

M w is a projection of M, but we refer to it as a model, not a model instance, because model M in reality will never be implemented. A model can describe a situation common to many states. The second ontological commitment is the application of logical axioms designed to account for the intended meaning of vocabulary, and assigning constraints to system variables. Ontology can be represented as a continuation of problem representation by adding new features to it.

$$ O=\left(M,A,\ H\right) $$
(6.17)

A is a set of axioms for assigning constraint C to variables through the B C observation channel.

$$ A=\left(C\to V\cup {\mathrm{B}}_C\right) $$
(6.18)

H is a set of algorithms for assigning mechanisms (G) to data model processing through the B H observation channel.

$$ H=\left(G\to M\cup {\mathrm{B}}_H\right) $$
(6.19)

6 Development of Components of Knowledge Management System

Ontology development is the implementation of the reference model described in the previous section in capturing its elements, assembling them using a computational language, and storing them in an environment that would facilitate dissemination and usage. Particularly, software tools and techniques will use the developed ontology as part of supply chain decision modeling, the other significant part of supply chain configuration, which is taken up for discussion in Chaps. 7–11 of this book. Various stages of ontology development are described next.

6.1 Capture

This stage involves the following activities: (1) identification of key concepts and relationships in the domain of interest, (2) production of unambiguous text definitions for such concepts and relationships, and (3) identification of terms to refer to such concepts and relationships (Uschold and Gruninger 1996). Development of a system taxonomy aims to achieve the first two activities for the supply chain domain in general. Identification of concepts for a specific purpose and scope (i.e., the third activity), is the task for the ontology capture activity. The difference between ontology development from scratch and using system taxonomy is that the latter uses search and navigation in the taxonomy hierarchy to find relevant concepts. Once concepts are chosen, an instance of system taxonomy is created that captures only selected concepts, which is T w and specified by Eq. (6.11). As was mentioned earlier, for the sake of simplicity, thing T w will be regarded as the object model Eq. (6.6). Relationships R w are captured automatically in the form of a taxonomy structure that defines how concepts relate to each other.

The knowledge management system conceptualization framework, in addition to the data model (M) identified in the previous section, defines two other components—axioms (A in Eq. (6.18)) and algorithms (H in Eq. (6.19)). Axioms and algorithms capture a process for a search of rules held in the domain of interest for which an ontology is to be built. The theory for axiom representation is based on situation calculus and predicate calculus for representing a dynamically changing supply chain environment. Situation theory (Lesperance et al. 1995) views a domain as having a state (or situation). When the state is changed, there is a necessity for an action. Predicate theory defines conditions on which specific actions can be taken. Based on these two theories, ontology calculus for a supply chain is planned to be built. It will be based on extending both predicate and situation calculus with new terminology specific to the supply chain domain. The term do(x, s) represents the state after an agent performs an action x in state s. A more supply chain-specific example can be the statement that each product should have demand. This can be formulated as Exist (demand, Product). Another example of an axiom is the inventory constraint: Maximum Inventory ≥ Current Inventory Level, which can be formulated as Less(MaxInventory, CurrInventory).

An example of a portion of an algorithm is the formula according to which order size is calculated as s = L × AVG + z × STD; IF IL < s THEN Order = s-IL, where s is the reorder level, L is lead time; AVG, STD are forecasted demand means and standard deviation, respectively, and z is a customer service indicator. If the inventory level (IL) is less than the calculated reorder level, an order is placed (Order), which is equal to the difference of reorder and inventory levels. This axiom can be formulated through situation calculus as Poss(do((L × AVG + z × STD) = s) > Il) = MakeOrder(s − Il).

6.2 Assembly

Assembly is an explicit representation in some formal language of the conceptualization captured in the preceding stage. This involves (1) committing to the basic terms that will be used to specify the ontology, (2) choosing a representation language, and (3) writing the code. It simply has to do with writing down, in some language or communicative medium, descriptions or pictures that correspond in some salient way to the world, or a state of the world, of structured data.

For ontology representation, different programming languages and standards have been utilized. Ontolingua (Farquhar et al. 1997) adds primitives to defined classes, functions, and instances. Ontolingua is not a representation system, but rather a mechanism for translating from standard syntax to multiple representation systems. OIL (Ontology Interchange Language) (Fensel et al. 2002) fuses two paradigms—frame-based modeling with semantics based on description logic, and syntax based on web standards, such as extensible markup language (XML) schema and resource description framework (RDF) schema. Both Ontolingua and OIL are frame-based languages that do not provide formalism for first-order logic. With the latter, we intend to represent process logic the same way as frame logic.

XML has become a standard for communication between heterogeneous systems and is widely used on the Internet (Staab et al. 2001). This presents new opportunities for knowledge representation and acquisition and has two aspects. First, XML documents can easily be translated into knowledge representation format and parsed by problem-solving environments or domains. Second, XML can directly connect with data storage repositories (RDBMS or ERP systems), thus enabling database queries to be more expressive, accurate, and powerful. The two objectives can be achieved by enhancing the semantic expressiveness of XML, especially XML data schemas (XSD). We propose a new language, Supply Chain Markup Language (SCML ), for presenting knowledge about supply chains. The specification of SCML is formulated as a XSD data schema, depicted in Fig. 6.2. It reflects system representation formalism presented in system taxonomy. At the top level there are seven groupings: input, output, functions, environment, processes, and mechanisms. Each grouping is a container, which consists of subclasses.

Fig. 6.2
figure 2

Data schema for supply chain markup language

Full size image

A representative sample of SCML is depicted in Fig. 6.3. It defines the entity Axioms, any elements it may have, and entities it may contain. An Axioms entity class may have one or many Rules (unbounded) entities, which may have Attributes entities (0 or many). An Argument entity may have two attributes: Name and Description. The entity Rule may have one and only one Body entity and two attributes.

Fig. 6.3
figure 3

Supply chain markup language example axioms

Full size image

The SCML XSD specification defines the format of knowledge representation and can be used for developing ontology models and verifying their correctness.

The assembly process, as viewed in this chapter, is the representation of captured knowledge with XML formalism. Three components of an ontology model can be represented. Data assembly is concerned with developing software programs for connecting to data storage facilities and building XML data files based on schema described earlier. A data model example is represented in Fig. 6.4. Demand for a part (Number 295) produced for Customer Number 21 is demonstrated with four attributes. The Demand Net attribute can be used if the demand is stationary. In case it is dynamic, the DemandMeans and DemandDeviation pair of attributes can be used to present the demand distribution function (it is assumed that demand has a normal distribution). The numberofRegression attribute presents the number of observations when calculating its mean and deviation.

Fig. 6.4
figure 4

Data model XML fragment

Full size image

Axiom assembly is a manual process consisting of manually entering rules captured with ontology calculus into an XML data file based on SCML schema. An axiom model XML example is represented in Fig. 6.5. The rule demonstrated here is about the relationship between inventory and demand, in case the service level is 100 %. Ontology calculus for this rule looks like:

Fig. 6.5
figure 5

Axiom model XML fragment

Full size image
$$ Poss\left( ServiceLevel=100\%\right)= Less\left( CurrInventory, Demand\right) $$

Ontology calculus formalism is transformed into XML formalism as follows. The entity type Rule defines the condition Service level is 100 %. It contains two arguments, inventory and demand. The entity Body defines the relationship between these two arguments according to the condition identified in the parent Rule entity’s Name property.

6.3 Storage

The purpose of building an ontology server is to enable technology that will facilitate the large-scale reuse of ontologies through Web interfaces for decision-making purposes throughout the complex, extended supply chain enterprise. Figure 6.6 depicts the ontology server architecture. Data are stored in data storage facilities, which are mainly relational database systems or other carriers of information, such as ERP repositories (as a complex system for maintaining data) or files (as a simpler class of data storage facilities).

Fig. 6.6
figure 6

Ontology Server architecture

Full size image

The main component of the ontology server is the ontology library, which must have an index indicating how each individual item can be found. A problem classification hierarchy, Eq. (6.4), defines this index. Each node in this library corresponds to a problem and is the ontology specifying description of that problem.

6.4 Usage

Ontology can be utilized in a variety of ways. It can serve as an explicit medium where knowledge workers share their expertise and skills, it can be used as specifications for software engineers in developing complex software applications, and it can be used by decision makers for understanding the problem and making decisions. But the greatest advantage of having explicit ontologies is in implementing the vision of supply chain management as formulated by Fox et al. (2000). According to Fox, a supply chain is viewed as being managed by a set of intelligent agents, each responsible for one or more tasks in the supply chain, and each interacting with other agents in the planning and execution of their responsibilities.

An ontology server deployed on the Web makes the library available to supply chain members, who share the same perception of problems that they communicate to each other. In the case of agent-based SCM, ontologies provide the members with communication and interoperation. Ontologies inform the system user of the vocabulary for representing domain or problem knowledge.

Marra et al. (2012) identify that outsourcing, new product development, decision support, and risk management all are relevant to supply chain configuration. The knowledge management framework is particularly well-suited for addressing decision-making challenges in a distributed environment. Liu et al. (2014) argue that increasingly supply chain knowledge management systems should incorporate global contextual information and knowledge.

7 Summary

In this chapter, we explore the complexity of the supply chain configuration problem and argue that the best way to solve it is through devising a crosscutting approach that adopts concepts drawn from various disciplines in designing, developing, and implementing efficient and effective solutions. We take the representative information integration problem in the supply chain and argue that any methodology developed for supply chain configuration must explicitly take into account the systemic, reductionist, and analytic approaches available either in the published literature, or designed specifically. These approaches incorporate supply chain configuration problem details at the abstract, activity, and implementation levels, respectively. We make a case for knowledge design, development, and dissemination using taxonomy and ontology principles to incorporate system integration concepts. We propose a theoretical knowledge management system development framework, which acts as a reference model. It is based on problem solving at the above three levels. We also describe a brief implementation scenario of this framework. The utility of this framework rests on the fact that it provides a high level approach to managing the generated supply chain problem-solving knowledge, using various techniques described in Chaps. 7–9.