1. DIGITAL FIDELITY AND HIGH VISIBILITY
xCOR: a Value Chain Framework ontology
Markus Freudenberg

2. Initiating a Purchase
• Select product and create PO
• Email PO to supplier
• …
• Activating a Supply Chain (SC)
• Select a product
• Create purchase order
• Send an email with PO

3. Purchase Order
• The supplier often just receives a PDF document
• Enter new order
• Hopefully without erroneous inputs
• Ask to clarify details
• Await an answer…

4. Further Communications
• More pain while negotiating CRM/BMS
interfaces and their particular demands
• Relaying their requirements to the customer
• Waiting for responses…
• Prolonging response time further
• …
• More pain while negotiating
CRM/ERP interfaces and their
particular demands
• Relaying their requirements to the
customer
• Waiting for responses…
• Prolonging response time further

5. Status Quo
• Brittle information flow between customer and seller
• Depending on a few agents, often reduced to a single point of failure
• Only minor number of attributes are exchanged/comparable (automated/digital)
• In reality, required data is in different data sources:
• Using different names, units, abbreviations
• Using unrelated schemata (“speaking different languages”)
• Varying accessibility
• The diversity in data increases when comparing different organizations
• Available digital interfaces are limited
• Often reduced to Excel sheets or PDF files
• Communication often based on e-mails
• Changes during a purchase are “whispered down the lane”
• Communication breakdown is a constant risk

6. Digital Approach
• SC information model as a common digital language
• For integration of different data sources
• For defining universal data interfaces
• As representation of the shared understanding of the domain
• Digital representation of all relevant, interactional data
• Defining and certifying digital objects exchanged between partners
• Expanding the available view on processes, stock and capacities of SC partners
• Automated, instantaneous matching of digital objects
• Comparing expected state against the actual shape of an object
• At any stage and process of a SC
• Minimal interaction with customer relations operatives and sales
• Not reliant on e-mail communication (or Excel / PDF)

7. A digital Supply Chain Environment
• Most of the Emerging Practices depend on a digital SC environment
• Requiring a common digital representation of SC entities
• Within an organization and between SC partners
• Assuming such a representation is available and employed by partners of a SC:
• A constant demand for comparing digital entities is evident:
• To establish the equality/similarity between two objects
(e.g. does the delivered item correspond to the product specification)
• To compare available stocking and production capacities of a supplier with demand
• To validate product quality test results with ones requirements
• Most prominent Practice based on such comparisons:
• 3/4 Way Match (SCOR BP.188)

8. Use Case: 4 Way Match
Delivery product
information
Delivery invoice
information

9. Excursion – xCOR & SCOR
© eccenca GmbH 2018

10. SCOR
• A value chain is a set of activities that an organization performs in order
to deliver a valuable product or service for the market (value enrichment).
• The Supply Chain Operations Reference model (SCOR)
• Introduced by the Supply Chain Council in 1996
• Served as a leading tool and process model for supply chain management
• SCOR consists of four basic taxonomies and their concepts interrelations
• Processes – describing the actions necessary to accomplish something
• Metrics – defining measures used to gauge the performance of Processes
• Practices – Best practices, established procedures to improve performance
• Skills – describes the necessary abilities of involved Agents, beneficial to Processes

11. What is xCOR?
• An upper level information model featuring all
jointly used concepts and relations of the value
chain domain.
• Representing an abstract view on all enterprise
domain frameworks of ASCM:
• SCOR - Supply Chain Operations Reference model
• DCOR - Design Chain
• CCOR - Customer Chain
• PLCOR – Product Lifecycle Chain
• Reused to implement each of its sub-ontologies
• Based on the W3C standardized process
reference and provenance ontology PROV-O

12. Implementing xCOR
• Model the value chain domain as described by the ASCM specifications.
• Extend the domain description derived from the official ASCM documents. In
particular regarding:
• an extended view on Metrics
• and the introduction of the Event concept
• Provide a structured foundation for any digital message exchanged between
partners in a supply chain.
• Consider the added requirements for the complex and emerging challenges of
the supply chain domain regarding its digital transition.
eccenca is developing xCOR and dependent ontologies in cooperation with ASCM

13. © eccenca GmbH 2018

14. Automated Matching
© eccenca GmbH 2018

15. Purchase Order example (some data)
Name From To Actual
PO Number 7654321 7654321 7654321
Customer Id 12345670 12345670 12345670
Currency EUR EUR EUR
Terms of Payment [complex] - -
PO Item* [complex] - -
-> Product Number 135790 135790 135790
-> Product Description* [complex] - -
-> Price per Unit 41200 41200 41200
-> Quantity 500 500 500
-> Quantity Unit lb_us lb_us lb_in
-> Customer Requested Date 03/04/2019 05/04/2019 04/04/2019

16. Matching PO
• Comparing an invoice
against the agreed PO
• Containing simple values
and complex objects
(such as PO Items or
Terms of Payment)
• The expected shape
(orange)
• Vs. the actual invoiced
shape

17. Matching PO Item 2
• Zooming in on PO Item 2
• Demonstrating a shape
with ranged value specs.
(Customer Requested Date)
• apparently QuantityUnit
has an unexpected value

18. The showcase – PO data
Name From To Actual
PO Number 7654321 7654321 7654321
Customer Id 12345670 12345670 12345670
Currency EUR EUR EUR
Terms of Payment [complex] - -
PO Item* [complex] - -
-> Product Number 135790 135790 135790
-> Product Description* [complex] - -
-> Price per Unit 41200 41200 41200
-> Quantity 500 500 500
-> Quantity Unit lb_us lb_us lb_in
-> Customer Requested Date 03/04/2019 05/04/2019 04/04/2019

19. Digital Fidelity
© eccenca GmbH 2018

20. Digital Fidelity
• Requires digital object matching based on a common vocabulary
• Validating the fidelity to the common vocabulary or defined data interfaces
• Has to be capable to ingest and validate additional, complex conditions
• Support for complex matching operations and queries
• Must accurately compare values in different units of any dimension
• Physical dimensions, currencies, standardized taxonomies, etc.
• Capable to deal with a certain amount of fuzziness

21. W3C Shapes Constraint Language
• W3C Recommendation as of 20 July 2017
• For validating graph-based data against a set of conditions
• Conditions are
• Inferred directly (automatically) from an ontology
• Or defined explicitly (in addition, satisfying the demand for complex constraints)
• Multiple conditions an object has to satisfy are summarized as a “shape”
• Various SHACL validation engines are available
• Can be included into any automatic data workflow
• (For example to trigger automatic responses to violations)

22. High Visibility
© eccenca GmbH 2018

23. Proliferation and High Visibility
• Extending the reach and depth of the currently visible view of a SC officer
• Exposing Product, Process, Plan and Inventory information to SC partners:
• Forward real information about every item at any stage of the SC
• SC planning does not have to revolve around gathering messages to account and
plan around delays
• “This approach provides real information about those parts that are truly at risk of
negatively impacting the planned availability of inventory”[1].
• Based on the same shape comparison as in 4-way-matching:
• Differences between the expected and actual shape of an object can be evaluated
• Allows for a high degree of automation in SC planning
• => fewer planners can make better decisions more quickly
[1] Ptak, Carol and Smith, Chad (2011). Orlicky's MRP 3rd edition, McGraw Hill, New York

24. Proliferation and High Visibility

25. Demand Driven MRP
• Fulfils the technical requirements for Demand Driven MRP (BP.179)
• Crucial for the 4th component the DDMRP stack [1]: Demand-driven planning
• planning based on observations of “highly visible” partners
• Basis for the 5th component: Highly visible and collaborative execution
• Extends insights during the execution horizon
© eccenca GmbH 2018
[1] Ptak, Carol and Smith, Chad (2011). Orlicky's MRP 3rd edition, McGraw Hill, New York

26. Proliferation and High Visibility

27. Summary
• The Value Chain domain is in an digital transition
• A common, unified information model is needed to support most tasks
related to this effort:
• Data integration
• Creating transactional data between partners
• Creating high visibility between supply chain partners
• To gather, unify, and communicate data from different sources,
departments, and organizations, without loss of content, meaning or
functionality, requires a universal and flexible language, understood by all
participants, humans and machines alike.
• Fulfilling the origin vision of SCOR
© eccenca GmbH 2018

28. © eccenca GmbH 2018
Markus Freudenberg
Data & Knowledge Engineer
markus.freudenberg@eccenca.com