OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-jplsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: Comments to UBL SBS and UBP by JPLSC


Dear Monica J. Martin,
Thank you very much for your detailed comments.
I answered my comments in line started by "YS".
Best Regards,
Yukinori Saito

----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: "Yukinori Saito" <saito-yukinori@fujielectric.co.jp>
Cc: "Stephen Green" <stephengreenubl@gmail.com>; "Noboru Itoh"
<nitoh@attglobal.net>; <kueno@iea.att.ne.jp>; <naitoh@is.oit.ac.jp>; "Dale
Moberg" <dmoberg@cyclonecommerce.com>; "UBL JPLSC"
<ubl-jplsc@lists.oasis-open.org>
Sent: Wednesday, July 12, 2006 12:58 AM
Subject: Re: Comments to UBL SBS and UBP by JPLSC


Saito-San,
We appreciate your detailed and thoughtful responses. As Stephen, the ebbP
TC is very interested in the needs and interests of your community.

I'll attempt to answer too some of the questions related to ebBP and UBP.

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.

2. Thank you for the feedback.

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.

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.

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.
- Usually, these BPs are executed by serial operations. But, each BP is not
essential. some BPs will be omitted (e.g. Inspection BP).
- Each BP specify buyers role, suppliers role and associated business
document.
(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.
- These BPs don't specify retry times.
- 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.
But, COXEC BPs are specified and operated by the current document (attached
MS Word document).
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.

YS: I will inform your comments to ECOM staff (ebXML charge).

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.

Best regards.

> 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

=?iso-2022-jp?B?GyRCNiZETBsoQlhNTC1FREkbJEI0SjBXJSIlVyVqJTEhPCU3GyhC?==?iso-2022-jp?B?GyRCJWclcyROSTg9YCVTJTglTSU5JVclbSU7JTkbKEIuZG9j?=



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]