xCOR - a Value Chain Framework Ontology
1 like438 views
The document discusses the need for a common digital framework to improve supply chain visibility and data sharing. It proposes xCOR, an ontology based on SCOR, to serve as a shared information model and digital language. This would allow automated matching of supply chain data to validate fidelity and enable high visibility of processes, inventory, and plans between partners. A shape constraint language could be used to validate complex data matches. Together this could support practices like demand-driven planning and collaborative execution across the supply chain.
![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](https://image.slidesharecdn.com/lswt2019-markusfreudenberg-xcor-talk-190626081054/85/xCOR-a-Value-Chain-Framework-Ontology-15-320.jpg)
![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](https://image.slidesharecdn.com/lswt2019-markusfreudenberg-xcor-talk-190626081054/85/xCOR-a-Value-Chain-Framework-Ontology-18-320.jpg)
![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](https://image.slidesharecdn.com/lswt2019-markusfreudenberg-xcor-talk-190626081054/85/xCOR-a-Value-Chain-Framework-Ontology-23-320.jpg)
![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](https://image.slidesharecdn.com/lswt2019-markusfreudenberg-xcor-talk-190626081054/85/xCOR-a-Value-Chain-Framework-Ontology-25-320.jpg)
xCOR - a Value Chain Framework Ontology
- 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