1 Introduction
This document sets out the methodology to be used in developing harmonised and streamlined semantic model of a business process.
The methodology is aimed to work as a basis for the GSMP EDI Standards Maintenance Group (EDI SMG) in developing specific semantic models.
Using a methodology ensures that all business processes are described in the same way, which also ensures consistency and facilitates harmonization between different semantic models used in business processes.
2 Background and scope
Many market participants within different sectors suffer from the lack of standardisation of business processes. They have realised that cooperation between business partners is necessary in areas such as product identification and barcoding, master data synchronisation, ordering, delivering and invoicing processes as well as transport and logistics processes.
In many sectors such as the retail sector, all market participants are experiencing increasing pressure to control costs and improve efficiency, making the need for optimisation even more urgent. There is also increased pressure from politics, but also from consumers about improving consumer safety.
GS1 EDI strategy 2018-2020 approved in May 2018 describes a new approach to GS1 EDI standardisation “GS1 will decouple business content from technical considerations so that business processes and data can be harmonized and standardised”.
The strategy is a response to the EDI user community to the reported question of the difficulty of implementing GS1 EDI standards with a higher frequency.
The overall aim of the methodology described in this document is to bring even more value to the existing GS1 EDI standards.
The problem is not a lack of standards but the difficulties in implementing in a harmonised way due to ambiguities in the names and definitions of business terms and ambiguities in how business terms are used or not used in a specific business process. EDI standards, that are lacking additional non-technical descriptions, are also grounds for misunderstandings between technical and business people in implementing a phase in a user company.
The methodology includes the use of new writing rules which improve consistency and clarity of business data terms by using business language for business data terms and their definitions. The writing rules are developed and published as an annex.
The methodology also includes the possibility to add clarifications, usage rules and descriptions needed for clarification reasons in a specific context to separate semantic business documents, and include business data terms and business data term groups
3 Developing semantic business processes
By using established, harmonised and streamlined semantic models for different business processes in the supply chain including logistics processes, implementation in IT systems is facilitated, and development costs are reduced.
The latest trends indicate several directly positive results with the implementation of an agreed and standardised semantic business process.
The implementation of a standardised semantic business process into the internal IT systems and operations of a company, has proven to be possible in a relatively short time.
The subsequent phase of integrating business partners is also implemented more efficiently, in addition to avoiding different solutions in different business relationships.
Buyers, sellers and other participants save time and money when the semantic business process such as order to cash, from contract to invoice, is carried out electronically and according to agreed rules described in the semantic business process. In addition, the consumer safety and patient safety is improved by more efficient alignment of traceability information across the entire supply chain between trading partners.
A global harmonised and streamlined semantic business process is essential to avoid inconsistencies between different semantic business processes for the same user needs (business requirements). A global harmonised and streamlined semantic business process also ensures consistency across syntax standards.
4 GS1 Semantic Model Methodology for EDI Standard
The GS1 Semantic Model Methodology for EDI Standard is based on UN/CEFACT Modelling Methodology (UMM) and Common Business Process Catalogue (CBPC). See Annex A.
4.1 Overview of the GS1 Semantic Model Methodology for EDI Standard
The GS1 Semantic Model Methodology for EDI Standard includes descriptions of the various steps in the development of a semantic model.
Principles and preconditions - section 4.1.1 explains the methodology for describing the basic preconditions which prevails for the specific semantic business process to be developed.
Business process – section 4.1.2 explains the methodology for describing a semantic business process seen from the top level, for example, order to cash.
Collaboration process – section 4.1.3 explains the methodology for describing how the parties interact and gives an overview of the exchange of information in a particular collaboration process area, for example, place order.
Exchange of business document – section 4.1.4 explains the methodology for describing how the parties exchange a business document and including business data terms and business data term groups.
Business document – section 4.1.5 explains the methodology for describing what information should be included in the electronic business documents exchanged by the parties using a specific business process.
Binding a business document specification to syntaxes – section 4.1.9 explains the methodology for describing how to bind each business data term of a business document specification to a syntax.
Publication – section 4.1.10 explains which documents are required to be developed and published.
Communication – section 4.1.11 describes how the work team produces deliverables that can form the basis for marketing communications.
Maintenance – section 4.1.12 describes where maintenance of a semantic model take place.
4.1.1 Principles and preconditions
The section should include descriptions of the principles to be followed for the business process to be described as a semantic model. An example of a principle can be that GLN, GTIN and SSCC is notified as required to use in the actual business process to be described.
Important principles of general nature must be described. An example is that a business partner is always considered to be responsible for the business documents received or transmitted and processed as described in the semantic model. This principle applies even when there is a contract with a third party such as a VAN operator providing EDI services.
A description of the preconditions to be fulfilled must also be described such as having synchronized master data for products, parties, roles and delivery places. Preconditions related to agreements in contract must also be described to be used as basis for agreements to be set with business parties when using the business process.
The reasons for the principles and preconditions must be well explained.
The document Part I Framework is part of the GS1 Model for Supply Chain Processes in Healthcare and is an example of describing principles and preconditions.
4.1.2 Business process
The GS1 EDI Semantic Models are to be designed to work together with other GS1 standards for the identification of products, services, parties, locations, logistics units and labelling of goods. This means that the information and the flow of goods can be linked together to form a whole that provides traceability, visibility and safety in the business of each participant in the supply chain.
The semantic model for a business process should be documented in a separate document. The description of the business process should include the descriptions of the collaborating processes (see section Collaboration processes) and give an overview of the used business documents (see section Business document). Each business document describes the information which should be included in the electronic business documents (transactional information) which are exchanged between business systems. A description must be provided which describes how the parties exchange a business document (see section Exchange of business document).
This means that the description of a business process is consistent and coherent and that similar business requirements are described in the same manner in different semantic models of business processes. This way of describing prevents from unharmonized implementations.
The document Part II EDI Guideline is part of the GS1 HealthCare EDI model and is an example of describing business processes.
During the time a business process is developed, it must be ensured that the business process (including the collaboration processes) provide business benefits for all parties (stakeholders) who are supposed to implement the business process.
The description of a business process must be business oriented and the language must be non-technical. At the same time each description of a business process must be as general as possible to be easy to understand and implement by user companies who are stakeholders of the specific business process. However, the description should avoid generalisation to avoid non-harmonisation during implementation.
If any part in the description of a business process needs to have specific descriptions regarding a business need for a specific sector, a clear description of the need must be provided.
The GS1 EDI Semantic Models are to be designed to work together with other GS1 standards for the identification of products, services, parties, locations, logistics units and labelling of goods. This means that the information and the flow of goods can be linked together to form a whole that provides traceability, visibility and safety in the business of each participant in the supply chain.
Sectors are collaborating by using different business processes, such as, retail and transport and logistics sectors. Sometimes business processes are closely linked to each other such as the order to cash process and the transport management process (part of GS1 Logistics Interoperability Model, LIM). In such cases, it is suggested to mention in the business process where this kind of link appears.
An overview of the business process should also be made and be included in the documentation of the semantic model of a business process (see figure below). The overview should show the collaboration processes that are included.
Figure 4‑1 Overview of a business process as described in the GS1 Model for Supply Chain Processes in Healthcare, Part II - EDI Guideline.
A more detailed overview of a business process points out each collaboration process by showing the included business transactions (see figure below).
Figure 4‑2 Detailed overview of a business process pointing out the collaboration processes and the included business transactions as described in the GS1 Model for Supply Chain Processes in Healthcare, Part II - EDI Guideline.
The semantic models for a business process are developed and described together with experts of the specific business process.
The audience for the document describing the semantic model for a business process are:
■ Experts from business operations where the EDI solutions are implemented, who can use the descriptions to identify changes to be made to those operations.
■ IT system developers who will modify business IT systems, applications and other software.
4.1.3 Collaboration processes
Each collaboration process included in a business process should be described. The collaboration process describes how business documents interact at a specific step in a specific business process such as order to cash. The description must explain how the parties interact and exchange business information in a particular area such as the “Place order” collaboration process.
Figure 4‑3 Place order. Example of a collaboration process.
If a collaboration process includes various scenarios of exchanging and use information, each scenario must be explained and described.
Examples of alternative scenarios of exchanging business documents for the Place order collaboration process showed in the Figure above:
Scenario 1 - Order
Scenario 2 - Order and Order receipt acknowledgement
Scenario 3 - Order and Order confirmation
Scenario 4 - Order, Order receipt acknowledgement and Order confirmation
4.1.4 Exchange of business document
This section describes how the business systems at each business party need to handle and process the transactional data. The business partner who buys services from a third party are responsible that the data received in business documents are processed as it is described in the business document specification.
The business partner who buys services from a third party are responsible that the data sent in a business document are processed as it is described in the business document specification.
A collaboration process includes one or more document exchanges. A description of a document exchange describes how the parties exchange a business document and how the business systems at each business party need to handle and process the transactional data. The IT systems for sender and receiver must be set so that data is perceived in the same way.
A document exchange describes step by step what the sender and recipient should do before a business document is sent and received. This may include how a business document should be approved by an authorised person before it is sent and what checks the recipient of the document should carry out. A document exchange puts the business document in context.
Each scenario must include an overview description of activities to perform when exchanging a business document.
A more detailed description shows all the steps that parties should take before a business document is sent by the sending party and after it has been received by the receiving party.
For each description of a document exchange, the initial and the termination conditions to be fulfilled must be described. The description should also include how validation of the business document content should be performed for example in the step of receiving an Order.
An overview of the steps and activities to perform can be showed in diagrams.
Figure 4‑4 The diagram shows an example of an overview of exchanging the business document Order including the steps to be performed by each involved party in a specific activity.
The diagrams can show different views such as focusing on the activities to be performed by a specific party involved in the business process.
Figure 4‑5 The diagram shows an example of the supplier’s steps in the activity of checking stock levels.
4.1.5 Business document
A semantic business document model describes the business data information of a business document.
A semantic business document model is a description of what information should be included in the electronic business documents exchanged by the parties. By designing a semantic business document model such as an order, the parties can be sure that their systems interpret the sent and received information in the same way.
When developing a semantic business document, account must be taken of the principles and preconditions described in Principles and preconditions (see section 4.1.1).
4.1.6 Developing a semantic business document model
When developing a semantic business document model, the included business data terms should be retrieved from the semantic data dictionary (see section 4.1.7 Semantic data dictionary, SDD).
General groups of business data terms that are stored in the semantic data dictionary are to be used in different semantic business documents. Comments that clarify the use of a specific business data term in a specific context can be added. Also comments that clarify the use of a specific data term group of business data terms in a specific context can be added to the semantic business document model. One or more synonyms and example data can be added for each specific business data term in a specific context. Relevant business rules are also to be documented in a semantic business document model.
Each semantic business document model can be presented in the formats HTML and PDF.
Figure 4‑6 The semantic business document model Order presented in HTML.
Figure 4‑7 The semantic business document model Order presented as a PDF document.
4.1.6.1 Cardinalities
The business document specification provides information about the cardinalities of the business terms included in the message only.
The cardinality is based on the business message only and not on a specific syntax
The development of a valid mapping requires that terms, that are mandatory at least on one of the sides, source and target, should be available in both source and target. In the case of a term missing on one side, a work request should be submitted in order to extend the supported data set
4.1.7 Semantic data dictionary, SDD
A centralised, syntax-neutral semantic data dictionary, SDD, is the cornerstone of interoperability and an important tool to maintain the highest degree of consistency within a semantic model (business process) and between different semantic models.
When modelling a business process and the documents, used in the collaboration process, a common SDD must be used.
The content of the SDD, the business data terms and groups of business data terms, must be available in the developing phase as well as in the future maintenance phase of a semantic model.
For each business data term and business data term group, the name and definition should be stored in the SSD. Business data term groups which can be determined as general should also be stored in the SDD.
Each business data term and business data term group included in a business document model can be further clarified by adding specific context description.
4.1.8 Writing rules
A set of writing rules are developed to facilitate coherent naming and definitions of business data terms and business data term groups.
The writing rules also improve consistency and clarity of business data terms and business data term groups by using business language.
GS1 Semantic Model Methodology Writing Rules Standard
4.1.9 Mapping a business document specification to syntaxes and external data models
In order to support the implementation of real data exchanges, the business document specification must be connected to a syntax.
A syntax is a technical representation of the document, allowing the exchange of the message between the partners and the import / export into the ERP system.
The connection between a business document specification and a syntax is identified as mapping.
A mapping can be developed not only to connect to a syntax but also to another data model available in the market, for instance UN/CEFACT SCRDM or CEN invoice data model.
Figure 4‑8 Invoice mapping to EANCOM syntax.
4.1.9.1 Mapping to implicit structures
While the construction of semantic data dictionaries privileges the creation of specific terms for each business object, the syntaxes diffused in the market often leverage code lists to qualify the type of information contained in a data element.
This means that the mapping won’t be a one-to-one but a many-to-one mapping and, in addition to the mapping between the business data term and the target data element, also the indication of the corresponding qualifier must be provided.
4.1.10 Publication
A set of documents are to be developed describing a semantic model of a business process.
The following documents are to be developed and published:
■ The principles and preconditions that describes the basic settings for a specific semantic model
■ A document describing the semantic model of a business process
■ A document describing the semantic business document model including the business data terms and business data term groups used
□ One document per each semantic business document model included in the semantic model of a business process
■ A document describing the syntax binding for each semantic business document model included in the semantic model of a business process
□ One document per each syntax that a semantic business document model is bounded to
4.1.11 Communication
Marketing efforts must be done when a finalised semantic model of a business process is to be published. The information about a new developed semantic model is to be communicated within the GS1 organisation as well as to GS1 customers and GS1 users. A commercial communications message and marketing materials should also be produced and published externally.
As one of the final work items to do in the Mission-specific Work Group (MSWG) responsible for the development of a semantic model for a business process is to describe the model at a high level, including a description of the benefits which comes with an implementation by a user company. The description can be designed as an executive summary which can be used by the GS1 Marketing Department when developing marketing communication.
4.1.12 Maintenance
Maintenance of a semantic model including all the documentation is to be performed according to the GSMP process.
5 Working procedure
The diagrams below illustrate the working procedures for developing and maintaining a semantic business process.
Figure 5‑1 The diagram illustrates the steps when developing a new business process.
Figure 5‑2 The diagram illustrates the steps to perform when maintaining an existing business process.
6 Glossary
The following glossary was updated for this publication of this document. Please refer to the GS1 Glossary for the latest version.
A Annex: UN/CEFACT Modelling Methodology (UMM) and Common Business Process Catalogue (CBPC)
CBPC identifies and describes business processes at a general level. According to CBPC a business process consists of phases:
Figure A‑1 The phases of a business process.
According to CBPC, a business process starts with a Planning phase when a company or organisation is planning their operations. Thereafter, the process proceeds to the Identification phase, where the company or organisation identifies which parties are suitable to establish a business relationship with, for business to be conducted.
The business process then proceeds to the Negotiation phase, when two parties who want to establish a business relationship sign a framework or contract. The contract provides, among other things, agreements for goods or services to be supplied, prices, delivery and payment terms. In the Implementation phase the parties carry out the obligations they assumed under the framework or contract.
The Implementation phase is divided into sub-phases:
Figure A‑2 Sub-phases of the “Implementation” phase.
In the Identify basic information phase, a buyer and seller exchange additional information about such things as parties, delivery points, price information and trade item information.
In the Order/Call-off phase, the buyer makes a purchase order or a call-off in accordance with what has been agreed in the framework or contract. The supplier undertakes to deliver in accordance with the terms of the contract. The buyer agrees to reimburse the supplier for goods delivered or services performed.
In the Deliver phase, delivery is made of what the parties agreed in the phase Order/Call-off.
In the Pay phase, payment is made for goods delivered or services rendered according to what the parties agreed in the phase Order/Call-off.
The Post-processing phase includes all activities and events occurring after the agreed goods or services have been, or should have been, delivered. This can include handling deposits and returns or various warranty obligations.
All the standardised semantic models (business processes) GS1 has developed together with users are part of the phase Implementation and go through the sub-phases which this phase contains.
A business process is composed of collaboration processes.
According to UMM, a business process is composed of collaboration processes, which run through the sub-phases of Implementation.
Figure A‑3 Illustration of a business process.
The figure shows an example of a business process that is composed of a set of collaboration processes. The business process runs through the sub-phases of the Implementation phase.
A collaboration process describes how the parties interact.
A collaboration process describes how the parties interact and exchange information in a particular area, for example to order goods. The information exchanged is primarily in the form of electronic business documents.
Figure A‑4 Illustration of a collaboration process.
A document exchange describes how the parties exchange a business document.
A collaboration process includes one or more document exchanges. A document exchange describes step by step what the sender and recipient should do before a business document is sent and received. This may include how a business document should be approved by an authorised person before it is sent and what checks the recipient of the document should carry out. A document exchange puts the business document in context.
Figure A‑5 Illustration of an exchange of a business document.
A business document specification describes the content of a business document.
A business document specification is a description of what information should be included in the electronic business documents exchanged by the parties. By designing an electronic business document such as an order following the business document specification for an order, the parties can be sure that their systems interpret the sent and received information in the same way.
Contributors & change log
Contributors
Log of Changes
Useful links:
* PDF version of the GS1 Semantic Model Methodology for EDI Standard