Using Ontology to Capture Supply Chain Code Halos

Using Ontology to Capture
Supply Chain Code Halos
Manufacturers need to create a lingua franca that extends
throughout the supply chain ecosystem, in order to
generate insights from the digital data encircling their
employees, partners, processes and customers.

2 KEEP CHALLENGING November 20142 KEEP CHALLENGING November 2014
Executive Summary
The world of high-end digital devices, with its rich hyper-connectivity,
portability and virtual intelligence, has become deeply engrained in
our professional and personal lives in ways heretofore unfathomable.
Furthermore, with the mainstreaming of technologies such as social
media and cloud, our worlds have grown both more complex and
interconnected.
While organizations are tapping into these technologies to generate
business value that extends beyond mere transactions, they are not
finding it easy to do so. Leveraging the metadata contained within these
digits offers unprecedented insight into the spirit and intent of these
transactions, beyond what is superficially apparent. However, the ability
to collect and distill insight from this data and generate exponential
value requires the ability to read what is hidden between the lines and
then structure it in ways that are understandable and useful to the
business.
Since the dawn of modern science, humans have aspired to understand
how the brain works and to replicate it through technology. This has
given rise to the discipline of artificial intelligence (AI), which today
holds the answer to how society can best capture intangible information
and structure it in a way that we can make sense of it.
This white paper explores ways to connect the dots presented by these
concepts. We provide a foundation to build capabilities specific to the
supply chain management world to produce groundbreaking insights
from the data that is generated every day.

USING ONTOLOGY TO CAPTURE SUPPLY CHAIN CODE HALOS 3USING ONTOLOGY TO CAPTURE SUPPLY CHAIN CODE HALOS 3

Data Rich, Knowledge Poor
Exabytes of digital data (1,000 petabytes)1
are generated around the world every day. Within a
supply chain, data is generated by the activities of the supply chain players, as well as at the
points of interaction among these players. This phenomenal amount of digital data encircling
individuals, companies, processes and devices is what we call a Code HaloTM
. By making meaning
from this data, supply chain constituents can generate immense value for themselves and their
partners.2
To do this, organizations must make meaning from unstructured or partly structured data,
using a comprehensive representation of what we know about the data and its interrelation-
ships. Existing models such as SCOR (Supply Chain Operations Reference) from the Supply Chain
Council have achieved a consensus view of supply chain management from a business process
perspective. These models have helped supply chain managers establish metrics, standardize
language and create common business practices. This activity has also led to academic research
to extend the SCOR model and combine it with knowledge representation through an ontology
known as SCONTO.3
Ontology is “a formal, explicit specification of a shared conceptualization,”4
or in simpler terms,
a hierarchical description of concepts in a certain domain, combined with a description of each of
these concepts.5
By applying ontology, Code Halos associated with the supply chain ecosystem
can be codified and represented by providing a formal structure to the data on the basis of our
knowledge about it.
This information can then be extended to specialized application areas within the supply chain
and captured across the various information management systems used by players in the supply
chain. This will result in an information base that is easy to integrate across supply chain partners
and is reusable by all participants.
For example, ontologies are widely used in e-commerce to represent accurate product informa-
tion, specifications and hierarchy across a wide range of products, categories, partners and Web
sites.
However, it is not always necessary to fit businesses to standard models when using ontology
to make meaning of unstructured or partly structured data. Also, businesses that have adopted
standard models like SCOR have often needed to customize the model to different degrees to
make it less ambiguous, more robust, and a better fit for their needs. Businesses that do not
follow standard academic models (which are the majority of cases) can leverage the power of
Code Halos through ontology, using the approach suggested in this paper.
Supply Chain Code Halos
The digital data surrounding entities in a supply chain can be classified in a number of categories,
largely driven by the context of the data within the broader business ecosystem. The value
generated by this data depends on the ability to identify the most effective intent of using it
rather than the pure transactional nature of the information it communicates (see Figure 1,
next page).
4 KEEP CHALLENGING November 2014
Businesses that do not follow standard academic
models can leverage the power of Code Halos through
ontology, using the approach suggested in this paper.

Manufacturers and Partners
Manufacturers generate massive amounts of data, both from transactional sources and through
interactions among multiple systems and individuals. Chief among this data are the metrics and
statistical data generated by manufacturing processes. This data originates from multiple sources
within the core manufacturing environment, for example, the control system components of a
process-based manufacturing execution system. With the adoption of mobility and close integra-
tion with enterprise resource planning (ERP) systems, the volume, velocity and variety of data has
also increased substantially.
Moreover, data on best practices and standards is spawned from collaboration platforms used to
share expertise, experiences and perspectives (e.g., Yammer, Chatter, etc.). This can be further
enhanced by sourcing data from external forums to obtain a more holistic view of best practices
and standards of manufacturing processes.
USING ONTOLOGY TO CAPTURE SUPPLY CHAIN CODE HALOS 5
Figure 1
Code Halos in the Supply Chain
Products and Services
Data generated from PLM systems, product
reviews, customer feedback, collaborative
platforms, network-aware devices, field
services, bill of materials, etc.
End Customer
Data generated by social networks, search
engines, e-commerce systems, online forums,
transaction history, surveys, customer
service, payment systems, etc.
Transportation
and Logistics
Data generated from live
traffic and weather updates;
GPS and satellite-based
systems; government entities;
order fulfillment, real-time
inventory and returns
authorization systems, etc.
Manufacturers and Partners
Data generated from manufacturing processes; best
practices information from collaboration platforms and
online forums; competitive information from the Web
and paid sources, etc.

Collaboration platforms with suppliers, distributors, vendors and other third parties can prove
to be another source of useful business data. For example, supplier portals to interchange ASNs,
EDI channels, etc. can provide useful insights on the efficiency of the partner operations and
other inputs beyond the purely transactional.
Moreover, another source is derived from access to competitor information and intelligence
from open channels on the Web. Subscriptions to various paid channels of competitor informa-
tion (e.g., Hoovers) can potentially be added to this.
Products and Services
Products and services — which are supply chain outputs — are a significant source of useful
business data. This covers both data generated by the products themselves through the product
lifecycle management systems, as well as the data about products generated from external
sources, such as product reviews and feedback from e-commerce Web sites or feedback forms.
Collaborative product design and development provides a host of useful business data from
various partners that can offer fresh perspectives. Hence, collaborative product development
platforms — part of modern-day product lifecycle management systems — are also a rich source
of this kind of product data.
Network-aware devices and products that make up the Internet of Things (IOT) are generating
exponential amounts of data that can provide useful insights about both usage and performance.
For example, smart meters attached to electric grids yield insights on a customer’s power usage
patterns and preferences beyond the basic information of the grid’s operational state.
The above can be combined with more traditional product data, such as bill of materials and
component sourcing information, to provide a holistic view of products. The downstream supply
chain data from field services, such as servicing requirements, servicing frequency and usage
patterns, can also add more traditional but very useful sources of product data.
Transportation and Logistics
Data sources for logistics operators have vastly increased. Whether it’s live traffic updates
and weather information, or vehicle positioning and tracking using GPS and other satellite-
based systems, a huge amount of data is generated by various commercial and public systems.
Businesses that can tap into these sources using telematics-based technologies can make
effective logistics decisions in real-time involving route planning, fleet management, safety,
accident prevention, etc. Moreover, government data sources are in abundance, such as facilities
to verify drivers’ licenses by departments of motor vehicles throughout the U.S. and UK.
Collaborative product design and development
provides a host of useful business data from various
partners that can offer fresh perspectives. Hence,
collaborative product development platforms — part of
modern-day product lifecycle management systems —
are also a rich source of this kind of product data.

From an execution point of view, data pertaining to real-time order fulfillment statistics and proof
of delivery tracking, combined with real-time inventory information from back-end systems, can
provide a live view of fulfillment and useful insights on performance and potential problems. Fur-
thermore, businesses can track returns data through return material authorizations, combined
with order and fulfilment data to potentially perform root-cause analysis of the causes for
returns, thus reducing returns frequency.
End Customer
New sources of customer data are providing groundbreaking insights into customer behavior,
explicit and implicit expectations, usage patterns, etc. The vast amount of data generated in social
networks, search engines, e-commerce systems, online forums, etc. through devices of different
form factors — from computers to phones, watches and fitness gear — has immense potential to
provide insights into the needs, wants and desires of existing and potential customers.
Insights on potential customers can be generated by sources such as search patterns, buying
histories, social network updates (including “likes”), page visits and even buying patterns of
related products or services. Insights into existing customers can come from satisfaction surveys,
service history, reviews, feedback, discussion forums, payment systems, etc. For example, a
global vehicle manufacturer created an early warning system by tapping into automotive Web
sites and forums using Web “crawlers” to gather insights on what customers were talking about
regarding newly launched product lines. Based on these insights, this company was able to more
quickly address and manage possible issues before they became widespread.
Ontology to Make Meaning from Code Halos
Once businesses understand how many forms and sources of data are available to continuously
enrich supply chain Code Halos, they realize that they need a way to structure and represent
these massive amounts of data to derive meaningful insights. Ontology can be an excellent way
to provide a method to this madness and meaningfully represent what would otherwise look like
chaotic data.
Ontology involves various concepts of classes, subclasses, inheritance, relations, properties,
instances, etc. Practitioners who are familiar with object-oriented design concepts will find
many of these concepts familiar. The most significant concept, however, is that of classes, their
hierarchy and how they can be interwoven to represent related real-world entities. Once these
concepts are clear, decision-makers use ontology to represent businesses, organizations and
entities in a structured and streamlined manner.
Once businesses understand how many forms and
sources of data are available to continuously enrich
supply chain Code Halos, they realize that they need
a way to structure and represent these massive
amounts of data to derive meaningful insights.

Computer
Desktop*
Laptop
Handheld*
Upper Ontology
Phone*
Model XXX Model YYY
Specifications*
Subclass of
Subclassof
Subclass of
Instance of
Uses
Contains
Bill of
Materials*
Ultraportable
Laptops*
Desktop
Replacements*
Gaming
Laptops*
Multimedia
laptops
Two main types of ontology are useful in the context of supply chain information:
• Domain ontology represents knowledge in a particular domain.
• Process/task ontology represents knowledge of any process to achieve a goal or solve a
problem.
Other forms of ontology, such as meta-ontology (which helps codify domain and task ontology)
and knowledge representation ontology (which captures representations in knowledge represen-
tation languages) can be useful to further enhance the above.
When it comes to ontologies, a picture tells a thousand words.
Figure 2 illustrates a domain ontology that represents a part of an electronic goods manufactur-
ing supply chain ontology. If we consider computers to be a superset, laptops can be a subset,
and multimedia laptops can be a further level of classification. These are represented by classes
and subclasses in ontology.
It is important to note that computers may not be the starting point for the ontology as depicted,
since they may be part of an upper ontology structure. Properties of classes will be inherited by
subclasses when they can add further specialized properties. For example, the bill of materials of
computers may contain some generic parts, whereas they are further specialized for laptops and
then for multimedia laptops. The actual models of the laptop manufactured will be an instance
Domain Ontology
Figure 2
* Further specialization possible.

Process
RFI/RFQ*
Plan*
Source*
Make*
Deliver
Return*
Invoice*
Metric
Measures Supports
Subclass of
Subclass of
SubclassofSubclassof
Subclass of
Subclass of
Definition
Make Cycle
Time
Instance of
Derives
Instanceof
Instance
of
Instance of
Derives
Derives
Best
Practice*
Process
Payment*
Deliver
Stocked
Receive
Order*
Deliver
Made-to-
Order*
Calculation
Deliver
Engineered-
to-Order*
Return on
Working Capital*
Deliver
Cycle Time
Source Cycle
Time
Fulfillment
Cycle Time
Upper Ontology
Process-Task Ontology
Figure 3
of the most specialized class. Properties such as bill of materials and product specifications may
be further specialized by other subclasses.
Figure 3 illustrates a process/task ontology.6
This approach explores a part of the ontology of
processes and subprocesses based on the SCOR model. The process to deliver goods is repre-
sented as a class and broken down into subclasses based on the type of production approach.
The delivery of stocked goods is further broken down into subclasses of the different process
steps involved. The processes have metrics and follow best practices, which are represented as
properties.
Metrics will have their own definitions and calculations. ”Fulfilment cycle time” and ”return on
working capital” are instances of the metric class. The different subcategories of cycle times are
also instances of the metric class, since they are related to the metric for overall fulfilment cycle
time through a common relation. This relation will be useful to derive and calculate the master
metric.
It is important to note that the above types of ontology may not necessarily sit independently
of each other. The examples can potentially be part of a single master ontology definition that
are interrelated with each other at some higher ontology common to both. Such a higher level
of ontology can potentially be shared by multiple players of a supply chain to interconnect their
systems and processes with a common depiction of information that is meaningful to them. This
can lead to an amplification of their individual potential for creating higher levels of synergy.
* Further specialization possible.

Ontology Benefits
■ High
■ Medium
■ Low
Dataheterogeneity
Level of collaboration
Structured Data,
Limited Players
Ex: Digital thermostat
Unstructured Data,
Limited Players
Ex: Home entertainment
system, product catalog
representation in
e-commerce
Unstructured Data,
Multiple Players
Ex: Smart home
Structured Data,
Multiple Players
Ex: Smart grid
Applications in the High-Tech Domain
In the high-tech industry, numerous applications exist for taking an ontological approach to
classify use cases by data heterogeneity and level of collaboration. Such an analysis can be
performed using the 2x2 matrix proposed in Figure 4. The applications in the first, second and
fourth quadrants are suitable for an ontology framework. However, maximum benefits can
only be realized for applications in the first and second quadrants. Ontologies naturally lend
themselves best to scenarios in which organizations must collaborate across multiple parties
with unstructured data.
Example 1: Manufacturer Partnering
Leading high-tech OEMs are increasingly leveraging their suppliers’ expertise in product design
to improve quality and reduce costs. These collaborations – formalized through manufacturer
partnership programs — are fast becoming hotbeds of innovation. However, they suffer from a
flaw: Suppliers have no access to real-time product usage information and, by extension, insights
into customer preferences and needs. Additional challenges include:
• Most product usage data, if recorded, lies unused with the OEM.
• There are security concerns and classification issues with sharing raw, unstructured data with
suppliers.
• The amount of data is voluminous, and post-processing is extremely complex and time-con-
suming.
• If post-processing takes too long, the date is often rendered meaningless as product lifecycles
are getting shorter.
One possible solution is to automate the process of usage data collection and standardize relevant
data available to both OEMs and suppliers. This can be done by incorporating an observation
module in the product itself.7
The observation module needs to be complemented with a pre-
defined observation specification to ensure that recorded data is relevant, accurate and formatted
appropriately. It is critical to involve the supplier in defining the observation specification.
Framing Ontological Benefits
Figure 4

End User
Observation
Product
Manufacturer
OEM
Supplier
Usage
Data
Usage
Supported
byProfile
Location
Has locationHas profile
Has
preference
Preference
Has usage
End User
Usage
metrics
Usage
Is measured by
Product Usage
Observation
Observation
Specifications
Records data
Observation
module
Observation
data analysis
Features
Identifier
Product
Sub-modules/
components
Specifications Part
Manufacturer
Build parts
Supplier
Procure
parts
Publish part
hierarchy
Has a
Has a
Has a
Is an input
Input to
Has a
Part
hierarchy
Issue
replacements
Build subcomponents/
modules
Process & analyze
usage data
Publish
usage data
Build
productOEM
Collect
usage data
Sell product/
service
Support
Center
Support
product/service
Is an input
Furthermore, businesses should also be able to update the observation logic on-the-fly as more
clarity is gained on the process. Once implemented, the pre-processed data can be shared with
corresponding suppliers, who in turn, can use it to understand user preferences and incorporate
them into the design.
The ontology depicted in Figure 5 provides the framework for doing just that.
Thus, the ontology can be used to “tag” data in real-time. As a result, the logged data is pre-
processed and structured using high-level concepts, such as source, classification, usage, format
and privacy level. Consequently, there is no need for extensive and time-consuming post-pro-
cessing of raw data. Instead, relevant data can be shared with suppliers in a secure fashion, and
analyzed directly and in a more efficient manner.
Example 2: Smart Homes
Smart homes are a model case study for the use of ontologies in understanding Code Halos.
With the advent of sensors, which are small, easily pluggable and energy-efficient, it is now
possible to deploy smart-home technologies in real-world settings. Furthermore, machine-learn-
ing techniques can be applied to recognize user activities from sensor-generated data. However,
An Ontology for Understanding Product Usage Data
Figure 5

Role
Mood
Has role
Has mood
Has profile
Has location
Profile
Location Point
Building
GarageStoreyRoomGardenBuilding
Non-Controllable Architecture
Furniture
SensorControl
Measured by
LightingActuatorMeterPower delivery
CO2 Humidity Luminance Noise Pressure Temp Volume
Environmental
parameter
HVAC System Security
System
Electrical
System
SystemsHome GatewayAppliances
Controllable
Has functionality
Functionality
Control
Functionality
Query
Functionality
Has command
CommandNotification
Has notification
Notification
Functionality
Has screen
Has memory
Device
Screen
Memory
Devices Users
Location
Building
Environment
User
there are challenges in the wide deployment of these techniques in ordinary homes, including
the following:8
• Data heterogeneity: This can be caused by the diversity of sensors and the lack of a uniform
markup language, which hinders seamless exchange, integration and reuse of data.
• Knowledge heterogeneity: This can be caused by a lack of data uniformity and formality,
which prevents the sharing of defined or learned domain knowledge across different systems.
• Application heterogeneity: This can be caused by the tendency of application developers to
deploy smart-home applications without leveraging the requirements for joint execution of
tasks.9
Each application, meant for recognizing different human activities, works with a differ-
ent architecture and operating system, which renders interoperability difficult.
These challenges can be addressed by adopting a formal, uniform ontology structure
proposed by Marco Grassi (as depicted in Figure 6).10
A Formal Ontological Structure
Figure 6

Notification Command
Has command
Notification
Functionality
Query
Functionality
Control
Functionality
Consumer
Supplier
FunctionalityState value
Has value
State Has
state
Controllable
Has functionality
Energy
demand
Estimated by
Estimated
Cost Appliances Home
Gateway Systems
HVAC
System
Security
System
Electrical
System
SensorControlLightingActuatorMeterPower delivery
Renewable Nonrenewable Electric sources
Primary source Secondary source
Energy source
Has source
Produced
by
Energy
Supply
Energy
Supplier
Has projection Has tariff
Input
to
Energy tariff
Peak tariff Regular tariff
Monetary value
Estimated
production
Created by
Input to
Calculated by
Has notification
Using such a framework will help energy suppliers aggregate the heterogeneous information of
a smart home in a semantic knowledge base. Such information can then be effectively retrieved
and used in algorithms to implement intelligent control logics and task scheduling to enable, for
example, efficient energy administration.
The ontology depicted in Figure 7 provides the framework for doing just that, by linking the
energy supplier and the smart home consumer in a common ontology structure.11
The consumer portion of the ontology (on the right) is an extract from the smart home ontology
illustrated in Figure 7. As the smart home can now access both the electricity consumption
patterns and related tariffs, it can run real-time algorithms to predict and optimize energy con-
sumption and costs. On the supply side, the energy producer gains visibility into the overall
consumption pattern and can optimize its production and tariffs accordingly.
An Ontology for Enabling Efficient Energy Administration for Smart Homes
Figure 7

Identify
knowledge
Define
concepts and
relationships
Detail
concepts
Build
ontology
Integrate
and grow
Approach and Business Outcomes
To successfully use ontology in supply chains, organizations must take a methodical approach
that involves tight collaboration among different players inside and outside the supply chain,
from end-to end. We suggest an iterative approach because at every phase, new concepts or
relationships may be uncovered that must be integrated into an earlier phase (see Figure 8).
The approach is bottom-up, which enables holistic coverage at the lowest levels of businesses
that are collaborating across the supply chain. Developing the ontology can start as an individual
activity within different business units that contribute to the overall value chain. These can then
be integrated iteratively as the ontology builds across the entire organization and then finally
proceeds toward a shared ontology across multiple partner organizations in a supply chain.
• Identify knowledge framework: The first phase of developing a supply chain ontology is to
identify the gamut of knowledge in the functional area under focus. This typically involves
identifying the boundary of all domain and process knowledge areas and the high-level con-
cepts contained therein. The identification process must involve internal business experts, as
well as domain specialists whenever necessary. It can also be beneficial to perform additional
analysis of existing domain literature for more holistic coverage. The output of this phase is a
high-level scope of the ontology.
• Define domain concepts: With the overall framework in place, the next step involves defin-
ing the concepts. The concepts usually range from products, processes, services, metrics and
best practices, to more specific concepts that are unique to the business. At this phase, new
concepts may emerge, which usually involves re-visiting the output of the previous phase in
an iterative manner. At the end of this phase, a definitive view of the concepts, which will be a
part of the ontology, should be available.
• Define relationships: The third phase involves defining the relationships between concepts,
which is now achievable because the domain concepts have already been defined in sufficient
detail in the previous phase. These relationships will link the identified concepts using logi-
cal relations, resulting in a grouping of similar concepts. This will help create hierarchies and
other relations in future stages of ontology building. At the end of this phase, a definitive view
of all concepts and their relationships should be available.
• Detail domain concepts: This stage covers a deep-dive analysis of the concepts and relation-
ships identified in the previous phases. Here is where the output from the previous two stages
is defined in detail by subject matter experts. Along with breaking down and defining indi-
vidual concepts in detail, the relationships between the concepts are established at a lower
level. The output of this stage will be a logical definition of the ontology in business terms.
Building a Supply Chain Ontology: Five Integrated Phases
Figure 8

• Build ontology: The build phase involves using specific ontology-building tools and technol-
ogy to create the ontology. Requirements of this phase include ontology definition expertise
using the output of the previous phase as input, along with understanding of Web Ontology
Language (OWL). Different tools, including open source, are available to build an ontology
(e.g., Protégé). It is vital to choose the appropriate tool based on the intended application and
the existing technology landscape with which integration may be necessary. The build output
will be a completely defined ontology in the standard format, which can potentially be inte-
grated with multiple systems on an as-needed basis.
• Integrate and grow: The integration and growth phase can potentially be a continuous pro-
cess. Once the ontology is built, it can be shared with all supply chain partners and potentially
integrated with their systems when feasible and necessary. This introduces the possibility of
growing the ontology in collaboration with partners. For example, if a manufacturer has devel-
oped its ontology and shares it with suppliers and distributors, the latter parties can, in turn,
follow the same approach detailed above to embrace and extend the ontology. With a recur-
sive approach, the entire supply chain can be covered in a common and well-defined ontology
that is maintained and owned by all interested collaboration partners.
Business Outcomes
When a common ontology is in place within and across supply chain players, it can then be
enhanced and amplified through significant synergies among the players. A common ontology
will provide a shareable framework for data capture, analysis, information dissemination and
communication within the business and outside of it, across interlinked and inter-dependent
businesses. This is akin to the emergence of a common language of communication among
supply chain partners. The framework can be enhanced to align information systems and remove
barriers of data exchange between applications owned and maintained by different parties,
which typically run on various platforms.
The ontology that is established will be the foundation for implementing Code Halo solutions.
The ontology will provide a lens to meaningfully view the multitude of data generated at various
supply chain stages from Code Halo amplifiers (different devices, systems and other sources
generating usable data). With all concepts and relationships already defined, it becomes much
easier to develop a comprehensive set of algorithms and run analytics on this data to generate
meaningful information. The ontology can further be leveraged to relate concepts that would
have never been linked in a silo-based view, resulting in analytical insights that potentially
amplify business value.
Looking Forward
Achieving a strategic fit among individual players has always been considered the Holy Grail of
supply chain. A huge step toward achieving this goal is the emergence of a common language to
classify data and interpret the information. With modern digital technology, the amount of data
generated is enormous. If businesses fail to make sense of the Code Halos surrounding their
supply chains — as well as their employees, their partners’ employees and the interconnected
processes and smart devices that span the supply chain — they are likely to quickly fall behind
the competition and ultimately be rendered irrelevant.
By using ontology effectively, businesses can create a lingua franca to take Code Halo thinking
from high concept to supply chain reality.
The ontology that is established will be the foundation
for implementing Code Halo solutions.

Footnotes
1 Matthew Wall, “Big Data: Are You Ready for Blast-Off?” BBC News, March 4, 2014,
http://www.bbc.com/news/business-26383058.
2 For more on Code Halos, see our book, Code Halos: How the Digital Lives of People, Things, and Organi-
zations are Changing the Rules of Business, by Malcolm Frank, Paul Roehrig and Ben Pring, John Wiley
& Sons, 2014, or our white paper, “Code Rules: A Playbook for Managing at the Crossroads,” Cognizant
Technology Solutions, June 2013, http://www.cognizant.com/Futureofwork/Documents/code-rules.pdf.
3 Alicia C. Böhm, Horacio P. Leone and Gabriela P. Henning, “SCONTO: A Supply Chain Ontology that
Extends and Formalizes the SCOR Model,” American Insitute of Chemical Engineers, 2011,
http://www3.aiche.org/proceedings/Abstract.aspx?PaperID=237484.
4 T.R. Gruber, “A Translation Approach to Portable Ontology Specifications,” Knowledge Acquisition, Vol. 5,
Issue 2, June 1993, pp. 199-220, http://dl.acm.org/citation.cfm?id=173747.
5 Ali Ahmad Mansooreh Mollaghasemi and Luis Rabelo, “Ontologies for Supply Chain Management,”
Industrial Engineering and Management Systems, presented at the 13th annual Industrial Engineer-
ing Research Conference, Houston, May 2004, http://www2.isye.gatech.edu/people/faculty/Leon_
McGinnis/8851/Sources/Ontology/Ontologies.pdf.
6 Joerg Leukel and Stefan Kirn, “A Supply Chain Management Approach to Logistics Ontologies in Informa-
tion Systems,” University of Hohenheim, Stuttgart, Germany, 2008, http://link.springer.com/chapter/10.10
07%2F978-3-540-79396-0_9.
7 Mathias Funk, Anne Rozinat, Ana Karla Alves de Medeiros, Piet van der Putten, Henk Corporaal
and Wil van der Aalst; “Improving Product Usage Monitoring and Analysis with Semantic Concepts,”
presented at the Third International United Information Systems Conference (UNISCON), April 2009,
http://wwwis.win.tue.nl/~wvdaalst/publications/p532.pdf.
8 Juan Ye, Graeme Stevenson and Simon Dobson, “A Top-Level Ontology for Smart Environments,”
Journal of Pervasive and Mobile Computing, Vol. 7, Issue 3, June 2011, http://www.sciencedirect.com/
science/article/pii/S1574119211000277.
9 Thinagaran Perumal, Abdul Rahman Ramli, Chui Yew Leong, Shattri Mansor and Khairulmizam Samsudin,
“Interoperability for Smart Home Environment Using Web Services,” International Journal of Smart
Home, Vol. 2, No. 4, October 2008, http://www.sersc.org/journals/IJSH/vol2_no4_2008/1.pdf.
10 Marco Grassi, “An Ontology Framework for Smart Homes,” IEEE Workshop on Modeling and Simulation of
Cyber-Physical Energy Systems, May 2013, http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=59843
27&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5984327.
11 Ibid

About the Authors
Shreejit Mitra is a Consultant with Cognizant Business Consulting and is a member
of its Manufacturing and Logistics Practice. His areas of expertise are in the appli-
cation of digital technologies in supply chain functions. He is currently involved
in advising clients on ways to leverage disruptive technologies, such as social,
mobility and analytics in their supply chain functions. Shreejit has an M.B.A. from
XIM, Bhubaneswar, and a B-Tech in computer science and engineering. He can be
reached at Shreejit.Mitra@cognizant.com.
Raghu Ramamurthy is a Director within Cognizant’s High-Technology Consulting
Practice. He has 14-plus years of experience in various areas of supply chain
management and has worked on business transformation initiatives for clients
across the U.S., Europe and APAC. His key areas of expertise include supply chain
planning optimization, business process harmonization and IT roadmap devel-
opment. He holds a master’s degree in management from the Indian Institute of
Management Lucknow. Raghu can be reached at Raghu.Ramamurthy@cognizant.
com | Linkedin: http://www.linkedin.com/in/RaghuRamamurthy.
Ganesh Iyer is a Manager within Cognizant Business Consulting’s Manufactur-
ing and Logistics Consulting Practice. His primary areas of expertise include
supply chain management and business process harmonization. He has extensive
experience advising companies with supply chain planning and execution issues
across manufacturing industries. Ganesh has an M.B.A. from NITIE, Mumbai. He can
be reached at Ganesh.Iyer@cognizant.com | Linkedin: http://www.linkedin.com/in/
ganeshiyer4 | Google+: iyerganesh@gmail.com.
Stephen Pradeep Edward has over 15-plus years of experience and has worked
extensively in executing various supply chain consulting projects and programs for
numerous high-technology companies, ranging from OEMs to equipment manu-
facturers. His experience spans package implementation and developing custom
service offerings for the high-tech segment. He can be reached at Stephenpradeep.
Edward@cognizant.com.
Aditya Dixit is a Senior Consultant at Cognizant and a member of the Cognizant
Business Consulting Team in the technology practice. He has worked across
diverse consulting engagements with leading high-tech and semiconductor firms.
His key areas of expertise include supply chain management, trade compliance,
business strategy and program management. He can be contacted at Aditya.Dixit@
cognizant.com.
Ramji Mani is an AVP and Consulting Partner with Cognizant’s Manufacturing and
Logistics Practice. He has over 25 years of marketing, operations and supply chain
experience and is part of the consulting leadership team responsible for setting
strategic direction for solutions that address client challenges and help customers
align and enhance their supply chains. He can be reached at Ramji.Mani@cognizant.
com

World Headquarters
500 Frank W. Burr Blvd.
Teaneck, NJ 07666 USA
Phone: +1 201 801 0233
Fax: +1 201 801 0243
Toll Free: +1 888 937 3277
inquiry@cognizant.com
European Headquarters
1 Kingdom Street
Paddington Central
London W2 6BD
Phone: +44 (0) 207 297 7600
Fax: +44 (0) 207 121 0102
infouk@cognizant.com
India Operations Headquarters
#5/535, Old Mahabalipuram Road
Okkiyam Pettai, Thoraipakkam
Chennai, 600 096 India
Phone: +91 (0) 44 4209 6000
Fax: +91 (0) 44 4209 6060
inquiryindia@cognizant.com
© Copyright 2014, Cognizant. All rights reserved. No part of this document may be reproduced, stored in a retrieval system, transmitted in any form or by any means,
electronic, mechanical, photocopying, recording, or otherwise, without the express written permission from Cognizant. The information contained herein is subject to
change without notice. All other trademarks mentioned herein are the property of their respective owners.
About Cognizant
Cognizant (NASDAQ: CTSH) is a leading provider of
information technology, consulting, and business
process outsourcing services, dedicated to helping the
world’s leading companies build stronger businesses.
Headquartered in Teaneck, New Jersey (U.S.), Cognizant
combines a passion for client satisfaction, technology
innovation, deep industry and business process expertise,
and a global, collaborative workforce that embodies the
future of work. With over 75 development and delivery
centers worldwide and approximately 199,700 employees
as of September 30, 2014, Cognizant is a member of the
NASDAQ-100, the S&P 500, the Forbes Global 2000, and
the Fortune 500 and is ranked among the top performing
and fastest growing companies in the world. Visit us
online at www.cognizant.com or follow us on Twitter:
Cognizant.

Using Ontology to Capture Supply Chain Code Halos

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Using Ontology to Capture Supply Chain Code Halos

Similaire à Using Ontology to Capture Supply Chain Code Halos (20)

Plus de Cognizant

Plus de Cognizant (20)

Using Ontology to Capture Supply Chain Code Halos