Re: Comments to UBL SBS and UBP by JPLSC

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Saito-san,
We continue our discussion regarding your feedback to our group (see:
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/download.php/19178/ecom-ubp-response-july2006.zip,
or
http://www.oasis-open.org/committees/download.php/19178/ecom-ubp-response-july2006.zip).

Please see below.

>monica...1. There are example diagrams using Business Process Modeling Notation
>(BPMN) in the specification. This was chosen as BPMN is specifically
>designed to visually describe business processes. We've been working with the Object
>Management Group (OMG) to refine and expand BPMN to more fully
>accommodate choreography  and business collaboration. This work will
>likely take time and be under the auspices of BPMN and Business Process
>Definition Metamodel (BPDM).
>
>YS: I think that the specification is ebBP v2.0.3. I looked at v2.0.3 ebBP
>Directory at the ebBP page in the OASIS homepage.
>There are 10 ZIP files in this directory. I looked at some of these ZIP
>files. I could not find Business Process Modeling Notation
>(BPMN). Would you please tell me where the example diagrams using BPMN is
>described? I think that it will be much better that some business process diagrams of
>UBP would be provided in UBP specifications.
>  
>
mm1: The BPMN examples are in the actual technical specification:
http://docs.oasis-open.org/ebxml-bp/ebbp-2.0/2.0.3/
(see
http://docs.oasis-open.org/ebxml-bp/ebbp-2.0/2.0.3/ebxmlbp-v2.0.3-Spec-cs-en-pdf.zip).
The BPMN diagrams are found in Sections: 3.4.4, 3.4.5 (diagrams),
3.4.9.1 (diagram) and 3.4.9.8 (diagram).

>monica...3. We would have great interest in seeing the ECALGA collaborations that
>have been developed so they can be posted on our public web site or a
>link provided. Who is the contact for that work or could you please
>provide a public link?
>
>YS: I will ask your proposal to Secretary-general of JEITA.
>  
>
mm1: We look forward to your response.

>monica: We also understand that many legacy systems exist within the enterprise.
>We have also had many discussions about the separation between and
>relationship among enterprise or collaborative processes. We have found through our
>experiences thus far that common agreements can be used to more so
>understand the requirements on enterprise systems. Conversely, enterprise systems
>elicit requirements or constraints on collaborative processes.
>
>Has there been investigation on using collaborative processes to segment
>those requirements for enterprise operations by ECALGA in order to
>monitor collaborative processes.  This is an area of opportunity as
>several process definitions of different utility may be used (and likely
>may be required) to realize the flexibility envisioned for
>service-oriented activities.
>
>For example, the common agreement may serve as a monitoring function
>that is independent of enterprise operations, although they interact
>with one another.
>
>In the ebBP v2.0.3, you are able to establish hints that allow people to
>be involved in the manual processes that support the collaboration
>definition.  We have found thus far that the key is establish a
>framework to understand what is done in collaborative processes while
>recognizing the diversity of underlying mechanisms used to enable them.
>The v2.0.3 ebBP is substantially different and improved from previous
>v1.0x versions as well and provides greater utility for monitoring,
>runtime determination, external references, and guidance provided by the
>business transaction patterns.
>
>YS: I will inform these comments to Secretary-general of JEITA.
>  
>
mm1: We look forward to your responses and feedback.

>monica: At COXEC, was it considered the need to monitor these processes for
>adherence to mutual agreements between collaborating parties? Starting
>simple was a primary goal of the UBL SBS and the corresponding UBP.
>Therefore, some simple yet well-defined process definitions may, at a
>minimum, serve as design references regardless if the runtime systems
>only mirror (rather than implement) them.
>
>YS: I understand what you said.
>The specification regarding business process (BP) in COXEC is very simple.
>The BP specification is defined using MS Word. The contents are some
>diagrams and sentences.
>I attached BP specification of COXEC. But this specification is written in
>Japanese language. I suppose you can imagine styles or some contents about
>this BP specification.
>The main contents of BP specification is followings.
>(1) BP diagram
>This diagram specify followings.
>- There are 8 BPs (Quotation, Demand plan, Order, Delivery confirmation,
>Despatch and Receipt advice, Inspection, Receiving check, Credit account) in
>COXEC.
>- Each BP is independent each other.
>
mm1: They may be independent but have manually implemented transitions
whereby these actually comprise the collaborative agreement and process
definition. We saw this with knit wear in Italy.

>- Usually, these BPs are executed by serial operations. But, each BP is not
>essential. some BPs will be omitted (e.g. Inspection BP).
>
mm1: This is similar to the Italian requirements. To get a better idea,
please look at the public posting for knit wear in Italy on our public
web site at:
http://www.oasis-open.org/committees/download.php/18365/CristianoNovelli_ebBP_May06.zip

>- Each BP specify buyers role, suppliers role and associated business
>document.
>
mm1: These can be expressed in ebBP v2.0.3.

>saito-san: (2) Remarks
>- These BPs are for EDI operating users (e.g. Purchasing department staff,
>Selling department staff). These BPS are not for computer staff.
>- Basically, these BPs are judged and executed manually.
>- These BPs don't specify activity limited time. e.g.: Time to Acknowledge
>Receipt, Time to Perform. These will be specified by collaborating parties
>themselves.
>
mm1: These can be determined when the actual business processes occur
(i.e. at runtime). This could allow specification of timing given the
actual business circumstances.

>saito-san:- These BPs don't specify retry times.
>
mm1: Retry is optional for usage.

>saito-san: - These BPs specify how to deliver or receive Change and Cancel methods.
>I think that your idea (BPSS instances by monitor or design references of
>BP) may be valuable in some situations.
>
mm1: It is good if this information is encouraged for audit later.

>saito-san: But, COXEC BPs are specified and operated by the current document (attached
>MS Word document).
>
mm1: Could these be translated so we can review them? I expect that the
ebBP definitions could also be valuable for use in design tools (even if
developed in house). We do have a draft editor available from Dr. Asuman
Dogac METU. It is due for an update very soon and will include a user
guide. See: http://sourceforge.net/projects/freebxmlbp

>saito-san: I don't have any necessity to develop BPSS instances of COXEC BPs.
>In case we would develop BPSS instances of COXEC BPS, who will use the BPSS
>instances? EDI operators cannot read BPSS instances. Computer engineers
>don't have needs to read BPSS instances, because we don't implement BPSS
>functions to COXEC computer system.
>
>For ECOM, it would be most valuable if you would consider expressing
>some prototype business processes in ebBP to serve as design material to
>support the collaborative processes that may be implemented using
>enterprise systems.
>  
>
mm1: This would be a great stride for UBL, ebBP and ECOM if ECOM could
be involved in this opportunity above.

>YS: I will inform your comments to ECOM staff (ebXML charge).
>
>monica: This is a topic of discussion that may be best vetted on a
>teleconference call more appropriately than email. Thank you Saito-San,
>your comments are most welcome and appreciated.
>  
>
mm1: I look forward to continuing this part of the discussion. Your
inputs have been truly valuable for us. Thank you.

>>green: Saito-San
>>Many thanks for such detailed comments. These are of great interest
>>with regard to SBSC development. Of course, I hope you will consider
>>whether to submit these to UBL formally. At present I take it that these
>>are submitted for my perusal only until I hear otherwise from you.
>>
>>I will try to answer some of the questions (not official answers, just
>>my own):
>>
>>Questions
>>Scope of SBS adoption
>>    Who are users of SBS?
>>
>>I believe they will be software developers and project managers
>>developing
>>e-solutions for small businesses who trade with other small businesses
>>and
>>with larger businesses
>>
>>
>>    Which described below is a suitable scope regarding SBS adoption?
>>
>>SBS will be used by a small business which is conducted by within SMEs
>>(Small and Medium sized enterprises) only.
>>SBS will be used by a small business which is conducted by not only
>>within SMEs (Small and Medium sized enterprises), but also between
>>large enterprises and SMEs.
>>
>>Both of these are considered and the SBS package seeks to provide for
>>both
>>but the main consideration is not the larger but the smaller business
>>who need
>>to keep the costs of development to a minimum and may not be already
>>using
>>elaborate and expensive (to maintain) EDI solutions. Primarily the
>>consideration
>>is to cater for those who are moving to UBL not from EDI but from
>>paper-based
>>systems (paper invoices and orders input manually into low-end and
>>bespoke
>>business applications).
>>
>>
>>Methodologies to develop SBS from UBL
>>SBS is a subset of fullset UBL.
>>
>>    What is a methodology or algorism to develop SBS from UBL?
>>
>>Is the methodology or algorism (to have developed SBS) based on some
>>research or investigation?
>>
>>Yes, there has been much research in the area of conversion of
>>paper-based
>>procurement systems (invoice and order based) to electronic
>>equivalents. Some
>>of the work on which the SBS was based was done by PriceWaterhouse
>>Coopers
>>for the EU Commission and also considered was the similar study by APEC.
>>Particular consideration was given to feedback in UBL from members
>>(such as
>>yourself) and liaisons such as PWC and from early adopters of UBL and
>>Government Offices standardising on UBL. All these gave the same
>>message, that
>>small businesses needed the identification of a core subset and
>>special treatment
>>to ensure that the subset could be used by as many as possible and
>>with as
>>little difficulty as possible.
>>
>>
>>Remarks: Methodologies to develop Manufacturing SMS business document
>>in ECOM, Japan.
>>
>>ECOM has researched the current operational business documents (Order)
>>using by some big enterprises in Japan. The number of the big
>>enterprises is 17 companies. By evaluating and summarizing these
>>business documents, ECOM has developed Manufacturing SME business
>>document. Therefore, the scope to use this Manufacturing SME business
>>document is e-businesses not only within SMEs, but also between big
>>enterprises and SMEs.
>>
>>
>>Yes, this is an important comment and it may be that the next thing to
>>address
>>within UBL is the need to provide for larger businesses too who still
>>cannot be
>>expected to cater in their software for all of UBL. That was out of
>>scope for the
>>SBSC except that we sought to provide some of the first attempt
>>mechanisms
>>for defining subsets which might be resued for suchuse cases too.
>>
>>
>>Regarding the observation of no diagrams in the UBP, I personally
>>didn't see
>>the need for these as the processes were in most cases just a single
>>message
>>(deliberately so, to allow virtually everyone to use these same
>>processes and
>>if they needed to ellaborate then they could do so be combining the
>>atomic
>>processes and adding choreography, etc in the Collaborations, etc).
>>
>>I personally regard the BPSS 2.0.3 as a key way to identify the
>>party's desire
>>to limit trade to the subset so that they can be sure to receive only
>>messages
>>which take the their limits of catering for just the subset into
>>account. I suppose
>>that this would apply not just to the SBS but to any use of subsets,
>>unless
>>a new namespace has been created to distinguish subset use (which I
>>think is
>>less than optimal for use of available software). Maybe in time there
>>will be some
>>recognition of these things by users of ebXML in general. I do wonder
>>what is
>>being used in the meantime and how the features compare with use of BPSS.
>>
>>Thanks you very much Saito-san and JPLSC for these comments. I eagerly
>>wait to see how these matters will develope with time.
>>
>>All the best
>>Stephen Green
>>    
>>
>
>
>  
>