eBIZ courseware -Module 05 - use profile and adoption (CW513-021)

eBIZ adoption mini course

January 2017

Adoption path, Use Profile, mapping

Piero De Sabbata, [email protected] Brutti, [email protected]

Summary

1. Terminology2. eBIZ3. eBIZ applicative domain4. Focus on…5. The adoption path6. Resources and documentation7. Validation and control

Plug-and-play Interoperability?

plug-and-play:adding a new partner (or new kind of transaction) in a network and immediately launch the collaboration

DEGREES of FREEDOM prevent plug-&-play data exchanges:

- Optional elements (allowed but not mandatory), to be managed and, when they are a lot, not any implementation supports them in order to limit costs

i.e. in UBL there are millions of possible XPATH in an ‘order’ document, but only some tens are used (differently from the case of eBIZ/Moda-ML)

- Many positions of an information are allowedi.e. refDoc in header or at item level

- Free coding: i.e. free texts instead of look-table (sometimes both are allowed)i.e. ‘payTerm’ (enumeration) and ‘payTermText’ (free text) or ‘note’ element

- Ambiguity: Different interpretation of the same statement

Degrees of freedom in specifications

Note: Often free coding is preferred by the programmers even if not necessary

A possible answer: the Use Profile

− Implementing the specifications only on the really used domain (a sub set of the specifications)

− Reducing ambiguities and interpretation uncertainty

− Coherence of organisational and contractual aspects with the chosen mode l

To lower implementation costs

To improveinteroperability

Some ‘drivers’ when implementing standard eBusiness specifications:

USE PROFILE is a way to express HOW the specification is implemented in a specific context and domain (a supply chain, a community, …)

Use Profile content

- Use Profile is a conformant restriction of the specification (thus is conformant still) that is ruling a subdomain, a community, the suppliers of the same supply chain, …

- regarding Documents UP rules

- List of Transactions to be implemented- Mandatory presence and Cardinality of optional elements of the data structure- Codings, units of measure, ranges and enumerations of allowed values- Context constraints and rules on data (deriving from role, other data, current

position in the workflow)

- UP might rule also transmission and security protocols, contractual and procedural issues (i.e. goods return management, invoicing,..)

TREND: automatic UP creation, comparison, deployment…

In short, how to use

A necessary LANGUAGESelect the electronic DOCUMENT models and the information to exchange for each transaction (order, piece quality report, sales report, offer request,…)

eBIZ is a referenceChoose the PROCESS and related activities (fabric supplying, vendor

managed inventory, weaving subcontracting, …), select the subset to implement (single transactions)

APPLICATIONS to be adapted or developedUsually the basic internal functionalities are already implemented (order management, stock management…)Adapt: sw modules are added to import/export data towards external systemsDevelop: new and more sophisticated internal procedures and services

Approaches for eBIZ adoption

• Scenario driven approach(incremental and partial, transition from paper to XML, largely adopted)

• ERP’s Entity driven approach(global big-bang, designed «a tavolino», not frequently adopted)

v

«Scenario driven» approach

− Step 1. Boundaries identification of Domain and Process of application (and involved industrial partners)

− Step 2. Transactions Analysis: how we implement the process (Use Profile, first part)− Which transactions to implement actually− Which granularity: what I need to identify and how (articles, serials –i.e.pieces or lots-;

advancement statuses, locations)− Which information are useful for each transaction and which document type

− Step 3. Document Analysis & Mapping for each transaction (Use Profile, second part)− Information mapping into the standard document template for each transaction

− Step 4. Choice of transmission protocols− Step 5. Check of the agreement of the partners− Step 6. Implementation

− import/export tools (conformance and functional tests included)− transmission protocols (conformance and functional tests included)

− Step 7. TRIALS with partners− Roll out, trials and interoperability testing

How to build a Use Profilea real case, step 1

Domain and process: average quality fabric supplying

Participants: Fabric Producer and Fabric buyer

Objective: to support order sending and logistic

Others requirements:- I do not care about serial number of pieces but simply lots- I do not allow Order Responses changing dates or quantities- I want a third party quality check- I do not want a separate quality report beyond Despatch Advice

Case requirements:

Real case, next steps

− Step 2. Transactions Analysis: how we implement the process (Use Profile, first part)

− Which transactions to implement actually− Which granularity: what I need to identify and how (articles, serials –

i.e.pieces or lots-; advancement statuses, locations)− Which information are useful for each transaction and which document type

− Step 3. Document Analysis & Mapping for each transaction (Use Profile, second part)

− Information mapping into the standard document template for each transaction− i.e. cardinality changes− Subsets of enumeration, business and operations instructions…

«Scenario driven» approach

Real case, Step 2

− Step 2. Transactions Analysis: how we implement the process (Use Profile, first part)− Which transactions to implement actually− Which granularity: what I need to identify and how (articles, serials, i.e.pieces, dyes,

lots; advancement statuses, locations)− Which information are useful for each transaction and which document type

Standard:

Process 1 – Fabric supply

− Fabric choice− Fabric purchase

− Fabric purchase order− Fabric order response− Fabric order change− Fabric status

− a - Fabric despatch with third party quality check

− b - Fabric despatch with groupage− c - Fabric despatch with third party

quality check− Textile invoice

Use profile:

Process 1 – Fabric supply

− Fabric choice− Fabric purchase

− Fabric purchase order− Fabric order response− Fabric order change− Fabric status

− a - Fabric despatch with third party quality check

− b - Fabric despatch with groupage− c - Fabric despatch with third party

quality check− Textile invoice

It might happen a new process is ‘COMPOSED’with existing documents

Step 3: specific cases

fabMnfrOperation, manufacturing phases to be performed. When it is a ‘printing’ order there might be up to 3 different ones

texJob, 1-1: Type of fabric manufacturing phase (table T202) allowed values: ”53” : print, ”54” : finish, ”81” : check

texJobTech 0-1: Type of Technology for the fabric manufacturing phase (table T262) allowed values :If texJob=”53” then allowed values 73: transfer printing, 80: cylinder printing, 81: inkjetif texJob=”54” or “81” then empty value

1. Context constraints from crossing values of different elements

Piece 0-n, serian numbers of the pieces, in Despatch Advice used in different transaction (for example «despatched for purchase» or «retuned from quality check»).

If «despatched for purchase» then piece serial numbers might be not interesting, If «retuned from quality check» then piece serial numbers are mandatory for tracing

2. Constraints deriving from using the same document type in different transactions

Step 3: specific cases/2

Note 0-19, free text

@noteLabel [Optional]: this label gives to the note element a meaning agreed between the parties

@codeList [Optional]: pointer to the list of allowed values (i.e. URL to download values list)

@numberingOrg [Optional]: organization that gives the meaning of the label

Pairs attribute/value to manage unforeseen information

Usage of structured «Note» elements:

Example:

Structured note about piece faults:the bodies of these note fields tell us, for each piece the type of faults (as attribute, «Hole»), their number, the piece reference («PZXXX») and informs us that the coding has been decided by the customer («CL») …

<note numberingOrg="CL" noteLabel=«Hole">2/PZ003</note><note numberingOrg="CL" noteLabel=«Hole">4/PZ004</note><note numberingOrg="CL" noteLabel=«Spot">11/PZ003</note>

CAUTION:- We are syntactically

conformant but outside the semantics of the specification

- Thus people can understand the meaning only by reading the agreed Use Profile

Some qualitative guidelines

Avoid implicit assertions, for example -never declare “when not explicited you should assume this value=‘XX’”, -always explicitate units of measure, never say “when um is empty assume CM”

Never give a meaning to the position, i.e. “first code is from customer, second one of the supplier” (always declare at least @numberingOrg)

Restrict the usage of free texts, especially when enumeration values are available (for example avoid to write “FREE CARRIER” in incoTermText and prefer incoTerm with value “FCA”)

Restrict the usage of structured note (that is better than free text)

When free text is unavoidable, try to limit the use to few values and cases (remember it is not processable by machines and might depend on the mother tongue of the operator that reads it)

Errors and common imprecisions

Syntax errors (found out thanks to XML Schema validation)• Wrong reference to XML Schema in the head of an XML document• Wrong elements sequences or wrong tags ….• Type of data or dates in a wrong format, use of comma for decimals …

Semantic errors• Values out of the range of allowed ones in the fields with predefined values• Incoherence between a tag and its content• Incoherence among different elements • Duplication/overlapping of the same information between coded elements

(based on enumerations) and freetext elements• Wrong reference to another document

End of eBIZ adoption

We have talked about Assessment criteria of standard-based solutions effectiveness‘Scenario driven’ approach divided in phases:

domain/process/profiletransactions/single documents logic mapping/data model

of the profile it follows agreement between

parties/implementation/transport protocols‘Entity driven’ approach: an open topicThe creation of the process profileThe creation of the document model profile

A sample of profile and related XML documentSome qualitative guidelines: optional fields, use of structured notes and free texts, others..Question and Doubts?

eBIZ courseware -Module 05 - use profile and adoption (CW513-021)

Internet

Transcript of eBIZ courseware -Module 05 - use profile and adoption (CW513-021)