NATIONS / E
/ Economic and Social
Council / Distr.
RESTRICTED
TRADE/WP.4/R.1212
19 January 1996
ENGLISH ONLY
ECONOMIC COMMISSION FOR EUROPE
COMMITTEE ON THE DEVELOPMENT OF TRADE
Working Party on Facilitation of
International Trade Procedures
(Item 9 of the provisional agenda of
the Meetings of Experts on Data Elements
and Automatic Data Interchange (GE.1)
Fifty-third session, 18-19 March 1996)
DRAFT BUSINESS AND INFORMATION MODELLING
FRAMEWORK FOR UN/EDIFACT
* * *
Submitted by the Pan American EDICAT Rapporteur *
This document contains the draft of a document created by the JRT BIM Group.
The Group of Experts is expected to:
-note this document as being for information and comments.
* The present document is reproduced in the form in which it was received by the secretariat.
GE.96-
UN/EDIFACT
Document Ref.: BIM2
Version Date : September 14, 1995
Issued by : T5 BIM Group
Status : Draft for Comment
Editors :Colin Clark, WEEB Dave Files , PAEB
Tel : +44 1625 529130 Tel : +1 716 722 1836
CompuServe: 100325,3106 CompuServe: 72614,732
The Business and Information Modelling
Framework for UN/EDIFACT
Table of Contents
Section Page
1.0 Introduction 4
1.1 Document Purpose
1.2 Underlying Principles
1.3 Status of Document
2.0 Why Business and Information Modelling in UN/EDIFACT?4
2.1 What is Business and Information Modelling? 5
2.2 The BIM Framework for UN/EDIFACT 6
2.3 Examples of BIM deliverables7
3.0 BIM Framework Deliverables 10
3.1 Specification of Business Analysis Deliverables11
3.2 Specification of EDI Requirements Deliverables 11
3.3 UN/EDIFACT Design Deliverables12
4.0 Implementation Considerations 12
4.1 Case Tools and Message Design Tools 12
4.2 BIM Warehouse 13
4.3 Organisation for BIM 13
5.0 Relations to the work of other groups14
5.1 ISO Standardisation Activities14
5.1.1 Open-edi
5.1.2 Naming Standards
5.1.3 Basic Semantic Repository
5.1.4 EXPRESS
5.1.5 Data Modelling Standards
5.2 Other groups 15
Appendix
1. Definitions 16
2. List of Reference Documents 17
3. List of Tools 18
NOTE In the conversion from A4 to 8X11 paper the number of pages increased from 17 to 20. In the document id BIMox811, the 811 stands for 8X11 paper format. Otherwise the document content is unchanged.
The Business and Information Modelling
Framework for UN/EDIFACT
1.0 Introduction
1.1 Document Purpose
This document presents a new approach to the development and documentation of
EDI messages. It outlines a framework for the application of structured modelling techniques which UN/EDIFACT message development groups can use as the basis for the creation of messages and implementation guides. These techniques deliver formal specifications of Business requirements and their related EDI requirements and the framework links these to the message design through the application of UN/EDIFACT Message Design Guidelines. Through the use of computer tools these processes can be carried out speedily and effectively. Although specifically directed to UN/EDIFACT, the framework described is applicable to other EDI standards and facilitates a move towards "Open-edi".
1.2 Underlying Principles
The BIM Framework for UN/EDIFACT seeks to ensure that data is uniquely defined
once and that all models and data constructs developed in one area may be re-used in other related areas. (This leads to the requirement for a central “warehouse” to support the storage and re-use of the data models)
As far as possible BIM allows for the use of any existing modelling technique that is
capable of providing the deliverables defined for each phase of the Framework. For example NIAM, CHEN, IDEF, IE, SADT, Yourden.
The BIM Framework is designed to be a modelling method, technique and tool
independent. A central warehouse will require that the deliverables be provided in a standard format. A primary principle is the use of existing standards to develop standards.
1.3 Status of Document
The document has been produced by the UN/EDIFACT Joint Rapporteurs' Business and Information Modelling Group, for the Joint Message Development Groups, the Message Design Guidelines Group, UN/EDIFACT Steering Group, Ad-hoc Group 1 and the JRT to consider for incorporation as part of the standard procedures for the future operation of the UN/EDIFACT process.
2.0 Why Business and Information Modelling in UN/EDIFACT?
The growth of EDI and the expanding range of areas of application has resulted in a rapid expansion in the number of groups involved in designing messages and in the number of UN/EDIFACT messages under development. Much of the early work re-produced in electronic form, the data and function(s) already handled by the paper based processes, and UN/EDIFACT message Design Guidelines provided the groups with the necessary rules for structuring the messages.
The interchange of UN/EDIFACT messages occurs in the context of some business process and, up to now, no guidance has been given to Message Design Groups on the way the business requirements should be specified prior to starting on message design. Standard messages have become large with many options so that the diversity of business processes can be handled. With the growth of EDI messages, message maintenance and reconciliation of requirements from different areas have become very time consuming and expensive. As businesses seek to re-engineer their methods of operation, making greater use of new technology, their business requirements change and opportunities exist for re-design of trade procedures and for simpler messages. The developments of interactive EDI and the concept of Open-edi require more formal definition of business processes and improved message design. Business and Information Modelling makes the major contribution of formal models of the business activities and data on which to base decisions in message design, message maintenance, Interactive EDI, Open-edi and re-engineering.
The methods outlined are already being used in some UN/EDIFACT groups (e.g. Finance, Construction and Health Care) to help with message design and by user groups (e.g. CEFIC, ODETTE and EDIFICE) to help guide implementation of existing messages.
2.1 What is Business and Information Modelling?
Business and Information Modelling is the application of structured activity and data analysis methods. These methods provide business people, as well as developers of EDI standards and computer applications, with a consistent and rigorous means of describing business activities and of defining and structuring the data needed to support those activities. They are described in the form of models that can be presented in both textual and graphical forms. BIM also provides a means to maximise the re-use of data across business areas.
BIM answers the questions: WHY do we need to provide the information? and WHAT information is needed for a specific business process to operate? It does so by representing, in the form of models, business functions and processes on the one hand and the information and data on the other.
For EDI purposes we are only concerned with those aspects of the business (or trade processes) which interface with trading partners and not all the processes internal to an organisation. It is recognised that by having consistent inter trading partner data there is the opportunity for an individual trading partner to align its internal data with the external standards to minimise its own data and interfacing maintenance. The BIM Framework is concerned with standardising the deliverables of activity and data modelling that are needed to develop UN/EDIFACT Message Standards so that any activity and data modelling method can be used.
2.2 The BIM Framework for UN/EDIFACT
The BIM Framework is based on a top down iterative process for modelling which converts business world perspectives into formal structured representations of activities and data. The models can be used to design consistent UN/EDIFACT messages.
The framework consists of three phases:
I. Business Analysis Phase
II. EDI Requirements Phase
III. UN/EDIFACT Message Design Phase
Phase I.
The Business Analysis Phase, involves the definition of the Business Requirements of the business area of interest e. g. Banking, Materials Handling, Purchasing. In this phase the business world perspective is captured as formal models of activities (Functions and Information Flows) and information (Objects /Entities and Entity relationships or roles). These are referred to as Conceptual Models. This process may be carried out initially in broad (high level terms) for a large area of business, or even the whole international trade process, and then refined in greater detail in specific areas appropriate to the business need. Together the Conceptual Activity and Data Models specify the Business Requirements.
Phase II.
In the EDI Requirements Phase the models from Phase I are further developed and refined for those activities that are to be supported by EDI Message Standards. The EDI Supported Activities model specifies the activities that generate and use the data exchanged via the messages, the order in which the data is generated and used, and the rules governing the exchange of the data (The Scenario). The EDI Message Data model defines the data and data relationships to be included in the EDI messages. The data model shall be fully attributed and normalised.
Phase III.
In the UN/EDIFACT Message Design Phase the UN/EDIFACT Message Design Guidelines are applied to translate the EDI Data Requirements Model from Phase II into existing or new segments, composites, data elements and code values in the UN/EDIFACT directories and create the message structures (UN Standard Message (UNSM)). The EDI Supported Activities Model is used to state the purpose and scope of the UNSM which is the specification of the functionality which computer applications must provide to have consistent implementation of the UNSM.
At each phase the activity and data models are verified against each other whenever there is a change needed, and changes made at one phase are checked against other phases. Throughout the work the results are verified with the business world to ensure the models truely represent the business requirements.
Figure 1 shows the BIM framework and the deliverables in terms of the activity models and data models from each of the three phases.
Figure 1. The BIM Framework
PHASE Information Activity
I. Business Analysis
II. EDI Requirements
III. UN/EDIFACT Message Design
2.3 Examples of Deliverables
Deliverables from the Business Analysis Phase.
Figures 2 illustrates a Business Function Model. Figure 3 illustrates a Data Model of some of the data needed to carry out those functions. The models are taken to a level of detail which allows identification of where EDI can be applied and the major blocks of data which need to be exchanged.
Figure 2. Activity Model
(Business Functions, Data Flow Diagrams)
Operate Company
Buy Manufacture Sell Manage
Materials Product Product Other Activities
Manage Ordering Manage Payment Manage Order Manage Invoicing
Activities Procedures Processing
Prepare Order Receive Invoice Receive Order Prepare Invoice
Receive Order Receive Credit Note Receive Order Prepare Credit
Response Changes Note
Arrange Payment
Cancel OrderPerform InternalPerform Internal
Perform InternalFunctionsFunctions
Perform InternalFunction
Functions
Figure 2 describes a manufacturing company as having four key functions. The functions concerned with Buying and Selling are further dissected to describe the component activities involved. While it is the communication between the buying and selling functions in a trading partner relationship that is of relevance for EDI standardisation , this model shows the functions within a single company.
Figure 3 is an example of an Information Model that illustrates a way of constructing a model of some of the Entities involved in the buying and selling companies. Further expansion of the model is needed to arrive at the fully attributed and normalised data model needed to carry out the business functions in Figure 2.
Figure 3. Information Model
(Entities and relationships )
Generates Placed with
1 Receives
1
Receives Results in Supplies
1 1
Is billed via
1
1
Consists of Be included in
This model can be represented in words as follows:
Each CUSTOMER may generate one or many ORDERS
Each ORDER can be placed with only one SUPPLIER
Each SUPPLIER may receive zero, one or many ORDERS
Each SUPPLIER may supply one or many PRODUCTS
Each PRODUCT is supplied by one or more SUPPLIERS
Each ORDER results in one or more INVOICES
Each CONSIGNMENT is billed via one or more INVOICES
Each CONSIGNMENT consists of one or more PRODUCTS
Each CUSTOMER may receive one or many CONSIGNMENTS
Each PRODUCT may be included in zero, one or many CONSIGNMENTS
Deliverables from the EDI Requirements Phase
Figures 4 and 5 illustrate the deliverables from the EDI Requirements Phase. The types of messages are defined in the EDI Supported Activities (Figure 4) and the data to be included in the messages is delivered in a tabular model form (Figure 5).
Figure 4. EDI Supported Activities
(Message sequence component of a Scenario)
Figure 5: Tabular representation of EDI Message Data for Purchase Order
(including mandatory and optional requirements)
Item NameCardinality Mandatory/ Optional or Conditional
Purchase Order number1..1M
Contract Reference0..1 O
Buyers ID 1..1 C
Buyers Name 1..1M
Buyers Address1..1M
Line Item Group 1..9999M
Product Code 0..1M
Product Description0..1O
Order Quantity1..1M
Unit of Measure 1..1 M
Price/Unit 0..1 O
Currency 0..1 O
Delivery Date1..1M
Place of Delivery 1..1M
Delivery terms 1..1 M
UN/EDIFACT Message Design.
The deliverables from Boxes 5 and 6 are the UN/EDIFACT message structures and their purpose and scope for implementation by business users.
Figure 6 illustrates the activity of converting the EDI requirements into UN/EDIFACT Messages.
The EDI requirements are mapped to the existing UN/EDIFACT segments and data elements held in the directory, new elements and segments are created as needed and the message structured according to the message design guidelines and UN/EDIFACT procedures.
Figure 6. UN/EDIFACT Message Design (Inputs, Outputs, Controls, Resources )
Message UN/EDIFACT
Design Procedures
Guidelines
BIM Deliverables New UN/EDIFACT Message
UN/EDIFACT Directories Modified UN/EDIFACT Directory
EDIFACT Message Message
Design Tool Design Group
3.0 BIM Framework deliverables
The deliverables from each phase of the BIM Framework are specified in this section. The deliverables consist of both diagramatic and textual representations. Because different methodologies can be used for the BIM modelling, and these different methodologies use slightly different types of wording and depiction, the description of the data is only described in a conceptual way. Reference should be made to the respective methodology manuals and the BIM3 documents for a more detailed description of what is required at each BIM phase.
Each set of deliverables must have the following identification data needed for effective management of the deliverables:
0) Business Area (Name and Scope)
Owner (Name and contact information)
00) For each Diagrammatic representation
Name of Diagram
Owner of Diagram and contact information
Name of Modelling Technique
Name of Modelling Tool and Version
Reference to diagram files.
3.1 Specification of Business Analysis Deliverables
Box 1 Business Functions and Data Flows
i) Diagrammatic representation
ii) Business Functions and Processes (Name, Definition, Purpose)
Inputs (Name, Definition, Originating Functions)
Outputs (Name, Definition, Destination Functions)
Controls (Name, Definition, Originating Functions)
Resources (Name, Definition)
Component of (Name of Function of which this Function is a component)
Box 2 BusinessObject Classes/ Entity Types
iii) Diagrammatic representation
iv) Entity Type/Object Class (Name and definition)
Supertype (Name)
Attributes (Name and Definition)
Relationships to other Entity Types/Object Classes
Related Entity Type/Object Class (Name)
Cardinality to Entity Type/Object Class (zero, 1 or many or min./max.)
Cardinality from Entity Type/ Object Class (zero, 1 or many or min./max.)
Verb phrase describing to related Entity Type/Object Class
Verb phrase describing from related Entity Type/Object Class
3.2 Specification of EDI Requirements Deliverable
Box 3. EDI Supported Activities (Scenarios)
v) Scenario (Name, Purpose and Scope)
Names of EDI Messages
Trigger Mechanism
Required Data for Input, Output and Control
vi) Diagrammatic representation
vii) Activities (Name, Definition, Purpose)
Input (Name, Definition, Originating Activity)
Output (Name, Definition, Destination Activity)
Control (Name, Definition, Originating Activity)
State Transition Table
Resources (Name and Definition)
Component of (Name of function/activity of which this is a component)
Box 4 Message Data Requirements
viii) Diagrammatic representation of message data requirements (fully attributed and normalised.)
ix) Entity Type/ Object Class (Name and definition, Data type, Data length)
Supertype (Name)
Attributes (Name and Definition, Data type, Data length, Key type, Source of
values for instantiation)
Relationships to other Entity Types/Objects Classes
Related Entity Type/Object Class (Name)
Cardinality to Entity Type/Object Class (zero, 1 or many ormin./max.)
Cardinality from Entity Type/Object Class (zero, 1 or many or min./max.)
Verb phrase describing to related Entity Type/Object Class
Verb phrase describing from related Entity Type/Object Class
3.3 UN/EDIFACT Design Deliverables
UN/EDIFACT Messages (UNSMs), segments, composites, data elements, codes and message design and user documentation.
4.0 Implementation considerations
4.1 Case Tools and Message Design Tools
Application of the principles of BIM is enforced and facilitated by software tools. The management of the information models, the maintenance of generic information objects and their syntactical representations are all activities that can be computer assisted and automated in some aspects.
The use of computer based tools saves time and effort by facilitating
i) enforcement of the rules
ii) the recording of requirements
iii) the re-usability of elements
iv) the automation of maintenance
v) the production and consistency in message design and documentation and user guides.
A small list of Case tools and Message Design Tools which BIM members have used are given in the appendix for information only. No endorsement is intended or implied.
4.2 BIM Warehouse
A fundamental requirement of the BIM Framework is the sharing of information (in the form of the BIM deliverables) between different Message Design Groups and their use of the models and definitions. Although this process can start with the sharing of written documents, the effective speeding up of the message design depends on the use of computer based tools which enable the models to be stored in a data base, browsed, queried and presented for re use. This data base is called the "BIM Warehouse".