[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Preparing for UBL
Hi David What sort of subset of UBL does Computergrid use? I ask because the SMEs who use Computergrid would need to trade with businesses which don't use it, wouldn't they. Many thanks Steve ----- Original Message ----- From: "David Lyon" <david.lyon@computergrid.net> To: <ubl-dev@lists.oasis-open.org> Sent: Friday, May 20, 2005 5:39 PM Subject: Re: [ubl-dev] Preparing for UBL > > Stephen, > > Yes they could do all that... > > alternatively, they could just spend the $300 and buy a > product like Computergrid which provides the capabilities > that they need. > > This is what we are doing in the Computer Industry in > Australia - enabling Computer shops to be up and running > with UBL in about half an hour. > > Small businesses just aren't like Government departments > or big companies - just don't have endless time or budgets > to play with. It's got to work quickly and simply.. > > As good as it may be.. if an open source UBL system requires > 300 hours to get going, the real cost is 300 * whatever the > hourly rate is. That may run into the thousands... > > Not all businesses want to waste that sort of money on > UBL... so people need to be clear about what the real costs > of "free" UBL actually are. > > Anyway... food for thought... > > Regards > > David > > > On Thu, 19 May 2005 10:02 am, Stephen Green wrote: > > Micah > > > > A few simplistic notes (all my own opinion, etc and not to be relied on > > without checking > > out for accuracy, IP, regulations, etc...): > > > > you need trading partners who: > > > > - are willing to adopt UBL (persuasion and/or pressure needed here) > > > > - have the resources to adopt UBL (this you are already helping with the > > SBS) My own main > > item on my personal task list of how to prepare for adoption is to help > > with the SBS or > > equivalent and to fill any similar gaps to make adoption easier, preferably > > working with OASIS) > > > > - have themselves other trading partners who are willing to adopt UBL - > > hence getting UBL > > into horizontal acceptance would help prepare for adoption here, as with > > the SBS but also > > (as again you are already helping to do :-) ) with getting UBL into mass > > tools support > > such as encouraging XForms support for UBL in products like OOo (which > > arguably has > > an added advantage, perhaps politically and economically, of being free > > open source) > > > > > > then with regard to gaps and addressing the BPM side a bit you need: > > > > - for there to be (either because you or others have produced it or you or > > others have persuaded > > a suitable organisation to produce it on your and yourtrading partners' > > behalf) a specification > > of a suitable workflow or set of collaborations (as in ebXML-BPSS) to which > > trading partner agreements > > (for example, but not limited to, ebCPPs and ebCPAs) can refer. This helps > > with identification and > > thence routing and reliable handling of exchanged messages. Resources or > > relevant standards to > > your business may determine how you do this or prepare to do it. You might > > decide to set up a > > ebRegistry or UDDI registry to hold the various specs. For a BPSS you might > > need a registry to be > > set up on your and your trading partners' behalf by a suitable body or > > agency. If you are not > > in a suitable industry for it to be done by an industry body which your > > trading partners also regard > > then there might be problems (this is the bit I might find most difficult) > > > > - a suitable way to create the agreements and specs and for your trading > > partners to do so too > > (maybe you can help some of them do this, or maybe an agency you have in > > common can, or maybe > > your own agency would help them as well as you) - perhaps VANs will restyle > > themselves for this > > as DaveW mentioned > > > > - if you want super systems with full automation then the above needs to be > > done 'properly' - at > > least there may be limits imposed on how it can be done (perhaps it's still > > a bit early for this and besides > > you or your potential trading partners may find it too challenging, risky > > and politically unacceptable as yet) > > > > - for the BPSS and maybe for the CPP/CPAs and for any other preparations > > for trading I can think > > of you would need to identify the exact processes you wish to engage in > > with UBL (perhaps mixing > > with other standards too). In a BPSS you'd need to break this into > > collaborations, essentially binary > > (or more comlex) but one-way messages are possible. This can be helped with > > patterns (ebBP TC just > > mentioned that an Invoice might be a one-way 'exchange' and can use the > > pattern for this called > > 'Notification'. I guess for many either just the Invoice or just the Order > > or Order/OrderResponse > > (depending perhaps on your postion in a supply chain and your influence > > among you trading partners) > > would be the first for concentrating on for return on investment. Denmark > > and Sweden have started with > > Invoice and then started looking towards the Order. I'd prefer to start > > with the Order/OrderResponse > > where these could be used with web trading sites provided by suppliers who > > might then send OrderResponse > > messages and later Invoices too. A credit note might be handy but this > > doesn't exist in UBL yet and besides > > there may be less ROI for it (fewer messages) but it may be mandatory that > > you not mix paper with > > electronic in the same process (depends on local regulations perhaps) > > > > - you may need to clear the whole thing with stakeholders, auditors (local > > and industry), tax offices, etc > > > > Maybe there needs to be better help for these things in OASIS and even in > > the UBL TC (e.g. providing > > ebBPSS documents for the UBL processes, besides the SBS and form specs, > > etc) to help those in a > > more horizontal setting (not have a major industry body to provide them for > > your supply chain). That's > > the sort of position of need of help I would be in. > > > > > > Then you (and your trading partners but perhaps with different software for > > your different roles) need software to: > > - handle messages, perhaps routing depending on a message header such as > > ebMS > > - extract data for integration with legacy systems, etc > > - produce return messages at several 'layers' (e.g. for the messaging layer > > such as for reliable messaging, etc, > > for the general business layer e.g. to signal a message receieved, > > processed successfully, etc the specific > > business message layer e.g. from your finance system e.g, to return an > > OrderResponse to an Order or an > > OrderResponseSimple) > > - perhaps to add SSL, etc > > - to send messages from the finance system or various message layers > > - provide an audit trail > > - archive messages and perhaps related artifacts with them or separately > > - involve humans where necessary (e.g. on certain errors or where there > > were message contents that couldn't be > > understood or just for every message contents before it gets into the > > finance system or perhaps to manually > > or semi-manually input messages) > > - in some cases you might need to use special software to extract > > paper-based output or input > > into UBL (as with Denmark's) or from UBL into paper-based documentation > > (e.g. with UNLayout and Ken's stylesheets) > > - some may wish to get software to automate the finding and arrabgements > > with suitable suppliers or buyers, etc > > - validation software, e.g. based on Schematron, script or the like or > > perhaps using proprietary software > > > > Then you might need to customise UBL and produce tighter schemas specific > > to your needs (and get the > > trading partners to accept them too, perhaps combining theirs and yours), > > perhaps producing schematron > > schemas to help with the validation (yours and/or theirs). This assumes > > tighter coupling of trading partners > > and maybe you can do better than that with UBL (e.g. if there were to be a > > very common implementaion > > of UBL in readily available or even free-opensource software which met most > > requirements just enough > > to justify the extar work using it to get data to and from your systems and > > likewise appealled to your > > potential trading partners and had sufficient acceptance in the legal, > > government and finance departments > > to be allowed for this purpose e.g. being sufficiently non-exclusive for > > public sector use -- e.g. OOo etc??) > > > > That's all I dare write for now. > > > > All the best > > > > Steve > > > > > > ----- Original Message ----- > > From: "Micah Dubinko" <micah@dubinko.info> > > To: <ubl-dev@lists.oasis-open.org> > > Sent: Tuesday, May 17, 2005 11:15 PM > > Subject: [ubl-dev] Preparing for UBL > > > > > I am researching for an article on UBL. What steps would you recommend > > > an organization to take in order to prepare for UBL adoption? > > > > > > I'm also interested in any links between UBL and BPM, especially as > > > real-world experiences. Can anyone elaborate? > > > > > > Thanks! > > > > > > .micah > > > > > > -- > > > Available for consulting. XForms, web forms, information overload. > > > Micah Dubinko mailto:micah@dubinko.info > > > Brain Attic, L.L.C. http://brainattic.info > > > Yahoo IM: mdubinko +1 623 298 5172 > > > Learn XForms today: http://xformsinstitute.com > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > > > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org > > -- > Computergrid : The ones with the most connections win. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]