To identify the eBIZ business processes, the transaction sequences and the exchanged information, that the new solution would be able to support in order to adopt the Business Scenario(s) identified in the previous Phase.
OUTPUT:
Collection of the Implementation scenario features and requirements in a document providing:
the analysis of the scenario where the new solution will be used, highlighting requirements and criticalities;
the list of eBIZ domain(s) and business process(es) able to support the analysed scenario;
for each selected process, the modelling of the sequences of the relevant business transactions and related abstract data models.
AVAILABLE RESOURCES:
eBIZ Technical documentation: eBIZ Business Processes and Transactions definition
Template TP513-006 : a Template that can be used to realize the document expected as output of this Phase.
Phase 2
STEP 1:
Business Scenarios - Implementation Scenario mapping
The output of the previous Phase is a set of (one or more) selected Business Scenarios that have to be implemented in order to improve some company's KPIs. This step aims to depict the Implementation scenario, meant as the set of real company's business processes and transactions that have to be arranged or reorganized in order to adopt the selected Business Scenarios. For each identified real business process, it is needed to define:
the involved roles/actors (who exchanges business information);
the conditions affecting the process execution;
the business transactions (e.g. purchase order, dispatch advice, etc.), the information sent and their granularity (e.g. what is identified and how: articles, serials – i.e. pieces or lots, advancement statuses, locations, etc.);
the transaction sequences and the conditions affecting their execution;
requirements and criticalities at both process and transaction levels.
If the Business Scenario requires RFId, following additional actions are requested:
identification of the phases of the supply chain and production process where it is expected to use the RFId;
identification of the events to be monitored using RFId;
selection of the RFId information sent and their granularity.
Expected Outputs:
textual description of the Implementation scenario (see Chapter 2 of the Template TP513-006 ).
STEP 2:
Business domains and processes analysis
eBIZ Reference Architecture (RA) defines business processes for three different domains:
Textile/Clothing (Upstream)
Footwear (Upstream)
Production to Retail (Downstream)
but, in most cases, a subset of them is enough to implement the selected Business Scenarios. The objective of this step is to identify the section of the eBIZ RA able to cover the Implementation scenario. This should be made performing the following actions:
selection of the relevant eBIZ domain;
mapping of the company's business processes (coming from Step 1) in the eBIZ ones, verifying that the collected requirements and criticalities can be supported/managed.
Expected Outputs:
the list of the relevant eBIZ domains and business processes for the Implementation scenario (see Chapter 3 of the Template TP513-006 ).
STEP 3:
Business transactions modeling
The goal of this step is to model all business transaction sequences, customizing (if needed) the eBIZ RA reference business processes identified by the Step 2. It should be achieved through the following actions:
analysis of the transactions belonging to the eBIZ processes coming from Step 2, and of the eBIZ document types implementing each one;
selection of the eBIZ transactions able to implement the company's business transactions (coming from Step 1). Take care to verify that the collected requirements and criticalities can be supported/managed;
definition and modeling of the transaction sequences through UML sequence diagrams, taking as reference the eBIZ ones.
Expected Outputs:
a set of UML sequence diagrams representing the sequence of business transactions that the new solution should implement;
the list of eBIZ document types that should be used (see Chapter 4 of the Template TP513-006 ).
STEP 4:
Abstract data models modeling
This step has the objective to provide the abstract data models related to the transactions identified by Step 3. Each model should represent the information potentially exchanged when the transaction is executed (e.g. the admitted and expected content for the related business document). Models are syntax independent, so for the implementation of real cases it is necessary choosing a syntactic notation and defining a Use Profile describing the mapping (see the next Phase). An abstract data model has to be defined for each transaction in the list coming from Step 3; each one defines:
the list of information exchanged in the transaction and what is mandatory;
code lists (for example for currency codes, country codes, etc.), if used;
where the information is located, at header or at line level or at both levels (e.g. a delivery date can be specified both in the header and in each line);
mechanisms used for information coding, like articles, location, packages, etc.
Expected Outputs:
the set of abstract data models representing the information that the new solution should be able to exchange (see Chapter 5 of the Template TP513-006 ).
If the Business Scenario requires RFId, following additional actions are requested:
the definition of the data to be stored into the RFId tag and related coding (standards).
