RE: [ubl-dev] Mapping business model fields to UBL 2.0

["Stephen Green" <stephen.green@bristol.gov.uk>]

OK Fulton, this I do agree with. It kind of becomes obvious as you
implement electronic systems to replace paper ones that the way
you do the business side of things changes a bit in this kind of way.
I'm not sure the software needs to take that into account though,
apart from with three-way-matching. It will surface, I think, as a 
business requirement on the way people work rather than anything
that needs to be formally agreed necessarily between trading parties.
I guess I regard it as an evolutionary rather than revolutionary
aspect of moving from paper to electronic. Most changes in fact are,
in my limited experience: Most changes need not impact to a great
extent on the design of the software if the software is actually
converted from paper ordering/invoicing to electronic - at least not
when using something like UBL. That, I suppose, is the point of the
main design goal of UBL - to keep such changes deliberately to a
minimum wherever possible (and most minimisations of change are
it seems in fact possible). Three-way-matching aside: That requires
a potentially significant amount of redesign of both software and
business process human activity but one has to weigh up whether
the changes are compensated sufficiently by the benefits and also
of course whether there is funding up front to invest in making such
changes if they are desired.

Best regards and apologies for not understanding too well the original
points

Steve 

>>> Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com> 23/07/09 17:01 >>>
Stephen,

 

By "atomic" transaction, what I mean is a naturally joined set of line
items, order together. An order for a laptop might be a multi-line item
transaction that includes a separate power supply, carrying case, etc. which
may be distinct line items The subsequent transactions such as shipping
advices or invoices would align with the "atomic" order.

 

The "bad" non-atomic transactions originate in various efforts to optimize
essentially manual processes. For example, in the purchasing sphere or
invoice processing sphere, almost universally the people who run those
functions have been told (correctly) that the overhead cost per transaction
is some high number (e.g., commonly an organization might estimate its
administrative cost per purchase transaction to be 50 USD each), so make the
number of transactions go down. People are rewarded for aggregating multiple
requisitions into one purchase order, switching to one invoice for
everything bought from a given vendor during the month, etc. They often are
rewarded for adding information requirements that should be handled by their
BI processes (e.g., incorporate year-to-date consumption information onto a
given transaction). Even in the manual world, these transaction-reducing
aggregations often add rather than reduce complexity, and the world if full
of people trying to get authorization for paying an invoice even though a
dozen or more people have to approve their particular subset of the complex
invoice.

 

End-to-end mechanized processes have entirely different cost
characteristics. A trading relationship may be somewhat costly to set up
(one hopes not), but once set up and tested the per transaction cost goes
down into pennies as long as the various transactions can be handled without
human intervention. Doing a three way match (order to receiving to invoice
match) if they are what I described as "atomic" and "atomic" in the same way
(e.g., in my example, the laptop and associated widgets is ordered, received
and invoiced at the same level of granularity).

 

My point was not that there be some bureaucratic mandate in favor of
atomicity, but that people understand that electronically implemented
trading relationships need to be optimized differently from manual
processes. 

 

 

 
Fulton Wilcox

 
Colts Neck Solutions LLC

 

______________________________________________________________________
'Do it online' with our growing range of online services - http://www.bristol.gov.uk/services 

Sign-up for our email bulletin giving news, have-your-say and event information at: http://www.bristol.gov.uk/newsdirect 

View webcasts of Council meetings at http://www.bristol.gov.uk/webcast