Re: [ubl-dev] Preparing for UBL

["Stephen Green" <stephen_green@seventhproject.co.uk>]

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
>