[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Comments to UBL SBS and UBP by JPLSC
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 >> >> > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]