Re: [ubl-dev] Preparing for UBL

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

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
>