Re: [Fwd: Example Scenarios Used Within the Aerospace Industry]

[Abid Farooqui <farooqui@tampabay.rr.com>]

Ah I can see how for example this packaging method for a purchase will cause
all kinds of problems in traditional EDI. It is simply because it is not
tagged. You are depending on the some delimeter or something to determine
what is what. In tagged data fortunately you would simply look for some
element called <packagingRequired> and see what value is assigned to it.
A lot of data description problems go away with tagged elements describing
what the adta is. Attributes and MetaData make it even more easier. I
actually do not personally like attributes because it makes XML a little
more complex. Sub-elements could have achieved the same thing but oh well.

----- Original Message -----
From: "Abid Farooqui" <farooqui@tampabay.rr.com>
To: <ebxml-dev@lists.ebxml.org>
Sent: Thursday, June 07, 2001 10:12 PM
Subject: Re: [Fwd: Example Scenarios Used Within the Aerospace Industry]


> Isn't there packaging method already in every PO. I would think it would
be
> a required item for any B2B purchase. If packaging is to be left to the
> supplier, one can simply fill this field with something like
> <packagingRequired>SuppliersDiscretion</packagingRequired> !-- Required
> element
>     <specialPackagingInstructions>blah blah
> blah</specialPackagingInstructions> !--This item may be made optional
> That does not sound like just limited to manufacturing or any other
> industry.
>
> Anyway, even if we go with the approach you suggest, let me ask this.
> How are you planning to automate business processes across vastly
different
> verticals without the kind of pain that is involved in doing so today.
> Because if we still have to go through all that kind of stuff, we can just
> put ebXML and all other SME solutions on the shelf and just stick with how
> things are today.
>
>
> ----- Original Message -----
> From: "Schuldt, Ron L" <ron.l.schuldt@lmco.com>
> To: "'Abid Farooqui'" <farooqui@tampabay.rr.com>;
> <ebxml-dev@lists.ebxml.org>
> Sent: Thursday, June 07, 2001 11:06 AM
> Subject: RE: [Fwd: Example Scenarios Used Within the Aerospace Industry]
>
>
> > Mr. Farooqui,
> >
> > The "generic business document" you suggested already exists - called
> > inspection procedures. These inspection procedures are developed within
> each
> > business similar to ours to insure that the part received does not
contain
> a
> > flaw - either in its manufacture or in its material composition - for
> > critical parts. These procedures are used to limit the risk and
liability
> of
> > the integrator. For certain parts, the inspection involves testing to
the
> > point of failure. For other parts, the inspection involves
non-destructive
> > testing/inspection.
> >
> > In other examples in the manufacturing industry, the material received
> > requires special handling and special equipment at the receiving site.
> > Material sent by a supplier can be packaged in many different ways. The
> > necessary packaging is a requirement of the purchase order so that the
> > receiving site can handle the material with the equipment available at
the
> > site. For many parts, you cannot leave this to the discretion of the
> > supplier.
> >
> > Regardless of how you try to simplify things, certain data are
absolutely
> > necessary and uniquely required for the types of items that the
> > manufacturing industry (aerospace being one example) procures. Again, I
> make
> > my case that this list should focus on the MRO commodity type items and
> > define core components that broadly apply across multiple industries
> > (including aerospace) for all procurement/settlement transactions.
> However,
> > each industry needs to be able to extend (note the "X" in XML means
> > eXtensible) the data that applies uniquely to its industry.
> >
> > The ebXML architecture is based on a building block approach. The core
> > components that apply across multiple industries are key building blocks
> and
> > I wish that this list would accept this basic principle and move
forward.
> >
> > Ron Schuldt
> > Lockheed Martin Enterprise Information Systems
> >
> >
> > -----Original Message-----
> > From: Abid Farooqui [mailto:farooqui@tampabay.rr.com]
> > Sent: Wednesday, June 06, 2001 5:31 PM
> > To: ebxml-dev@lists.ebxml.org
> > Subject: Re: [Fwd: Example Scenarios Used Within the Aerospace Industry]
> >
> >
> > Dear Mr. Schuldt,
> > I appreciate your points and from one point of view they are quite
right.
> > I have some points or comments however.
> > As I had mentioned earlier that I believe that vertical standards are
> > probably passing information in say a PO that is probably not completely
> > necessory for a PO. It may be necessory but not in a PO unit of work.
> > I agree that delivery schedule is a requirement for a PO. But it is not
> just
> > a requirement for an airplane part but a requirement most likely in any
PO
> > even a light bulb order. Delivery schedule may be much more relaxed in a
> > light bulb order and very timely and close in an airline order. But lets
> > look at some other things you mentioned.
> > "The inspection criteria (per some ASME standard) are likely to be a
> > requirement of the PO. "
> > My answer is a simple no. The inspection criteria is a requirement but
it
> > can be detached from the purchase order and put in another document
> (invent
> > a generic business document regarding inspecting criteria and use it).
In
> > the PO you can easily define a list of other documents that are related
to
> > that PO and if the inspection document is one of them you can list it in
> the
> > PO. This makes the PO an independent unit of work.
> >
> > I believe unless otherwise proven that this kind of business processing
> has
> > not been divided enough to be at the most efficient level that it can be
> and
> > unless I am not understanding your example it seems to me more and more
> that
> > I may be right.
> > This is the same kind of difference when you use C as apposed to C++ or
> > Java. One uses OO principles and one does not. Seems to be like the EDI
> > documents like a PO do not use any such data guiding principle as OO.
You
> > have to decouple these dependencies and look at the PO model to be sort
of
> > an object on its own. Has any one tried using some modelling tools to
come
> > up with business document specification. I guess OO EDI was doing that
but
> > it was not very condusive to XML but to other technologies like CORBA
> which
> > are much more complex.
> >
> > Sincerely,
> > Abid Farooqui
> >
> >
> > ----- Original Message -----
> > From: "Schuldt, Ron L" <ron.l.schuldt@lmco.com>
> > To: "'David Lyon'" <djlyon@one.net.au>; <ebxml-dev@lists.ebxml.org>
> > Sent: Wednesday, June 06, 2001 10:41 AM
> > Subject: RE: [Fwd: Example Scenarios Used Within the Aerospace Industry]
> >
> >
> > > List,
> > >
> > > The is a major difference between buying non-inspectable commodity
items
> > > such as light bulbs used in a facility versus inspectable items such
as
> > > landing gear struts that go into a passenger plane. The processes that
> > > generate the requirement and the processes that verify order
fulfillment
> > are
> > > completely different. For the light bulb example, a building custodian
> > might
> > > use a credit card to order a case of light bulbs and keep an inventory
> in
> > a
> > > storeroom. For the passenger plane landing gear strut example, the
buyer
> > > might evaluate several candidate bids from several
> > engineering/manufacturing
> > > firms that have the expertise to jointly design and build the landing
> gear
> > > strut. The passenger plane integrator (prime contractor) must ensure
> that
> > > the landing gear strut properly interfaces to many other parts of the
> > > aircraft and specify critical interfaces. Delivery schedule is
probably
> > > critical since the integrator (prime contractor) can't maintain an
> > inventory
> > > of the thousands of parts that go into each aircraft - rather delivery
> > > schedule is a key requirement of the PO. In addition, many of the
parts
> > must
> > > be inspected for defects (I'm certain you could relate to this safety
> > > precaution on a part as critical as a landing gear strut). The
> inspection
> > > criteria (per some ASME standard) are likely to be a requirement of
the
> > PO.
> > >
> > > Bottom line - the requirements in a landing gear strut purchase order
> are
> > > vastly different from those in a simple light bulb procurement. As a
> > result,
> > > should the PO for a light bulb pay the penalty of having to address
the
> > > multitude of topics (extra overhead) that are required for the landing
> > gear
> > > strut? My strong suspicion is --- no.
> > >
> > > Having stated my point - it is my hope that common (core component)
data
> > > elements applicable across multiple industries and used within
multiple
> > > transactions will be addressed by this ebXML list. Examples include -
> > > address, currency, organization, etc.
> > >
> > > Ron Schuldt
> > > Lockheed Martin Enterprise Information Systems
> > >
> > >
> > > -----Original Message-----
> > > From: David Lyon [mailto:djlyon@one.net.au]
> > > Sent: Tuesday, June 05, 2001 9:49 PM
> > > To: ebxml-dev@lists.ebxml.org
> > > Subject: Re: [Fwd: Example Scenarios Used Within the Aerospace
Industry]
> > >
> > >
> > > Abid,
> > >
> > > I tend to agree with you Abid. There are too many technical people
that
> > say
> > > that a Purchase Order for an Electronics company is entirely different
> and
> > > non interchangable for those say, for Insurance. It's ridiculous.
> > >
> > > The fact is that every day, Electronics companies get Insurance, and
> > > Insurance companies buy light bulbs. That's the way it was last time I
> > knew
> > > of anyway.
> > >
> > > So for anybody to say that an Electronics Industry PO can't be
> understood
> > by
> > > Insurance, is either off the planet or an EDI consultant.
> > >
> > > Invoicing between Electronics and Insurance, and account payments have
> > also
> > > happened for the last one hundred years as far as I am aware.
> > >
> > > Of course, there are going to be certain elements that may need to be
> > added
> > > into documents between particular trading partners. It was only
because
> > EDI
> > > elements weren't tagged that this was so difficult with EDI. With XML,
> the
> > > problem has gone away and trading partners can add elements without
> having
> > > to redefine and register completely new documents.
> > >
> > > POs aren't super complicated documents, nor invoices, nor statements.
> > >
> > > ebXML needs to be forward looking, not looking to solve all the
answers
> > for
> > > all industries, but just provide a basic framework of XML documents
that
> > can
> > > then be "extended" to suit per trading partner requirements.
> > >
> > > Once again, it was only a technology limitation that prevented EDI
from
> > > being able to do this in the first place.
> > >
> > > David
> > >
> > >
> > > ----- Original Message -----
> > > From: Abid Farooqui <farooqui@tampabay.rr.com>
> > > To: <ebxml-dev@lists.ebxml.org>
> > > Sent: Wednesday, June 06, 2001 1:07 PM
> > > Subject: Re: [Fwd: Example Scenarios Used Within the Aerospace
Industry]
> > >
> > >
> > > > Looks like I hit a nerve there Mike.
> > > > I actually do have a line of work and it is certainly not directly
in
> > EDI
> > > or
> > > > similar. I am an engineer and a computer Scientist and busines
> problems
> > > are
> > > > just one thing a computer scientist can work on in conjunction with
> > > business
> > > > people. I was simply pointing out what I have seen around.
> > > > Just consider it a fresh outsider perspective or similar. Standing
> > > outside,
> > > > I simply cannot come up with a good reason why a PO for an
electronics
> > > > company would have to have completely different fields and options
> than
> > a
> > > PO
> > > > for companies in lets say insurance industry. Now before you go and
> > state
> > > > the obvious that the business processes for both these industries
are
> > > > completely different, think about it from outside the box and
outside
> of
> > > > that world. What we are trying to achieve is automation of the
> business
> > > > process. You can divide a business process or any other process for
> that
> > > > matter into unit of works completely independent of each other. If
you
> > > can't
> > > > your approach isn't quite hitting the nail. When this unit of work
is
> > > > completely independent of any other UOW in the process then this UOW
> is
> > > > serving the exact same purpose for the insurance industry as it is
for
> > the
> > > > electronics industry. Perhaps what is happening is that we are
> carrying
> > > > information around in the POs that is really not relevent directly
> there
> > > but
> > > > is relevent further along after immediately processing the PO. In
that
> > > case
> > > > we have not really defined PO as a completely independent unit of
work
> > and
> > > > more work is needed and my point was that this is the domain of a
> > > standards
> > > > body. In the end something like this will make business processing
> > easier.
> > > I
> > > > hope you see my point.
> > > > Thanks for the link to the tutorial. I am familiar with X12 to the
> point
> > > of
> > > > understanding some basics but I will make sure to check it out.
> > > > Thanks
> > > > Sincerely,
> > > > Abid Farooqui
> > > >
> > > > ----- Original Message -----
> > > > From: "Mike Rawlins" <mike@rawlinsecconsulting.com>
> > > > To: <ebxml-dev@lists.ebxml.org>
> > > > Sent: Tuesday, June 05, 2001 10:35 PM
> > > > Subject: Re: [Fwd: Example Scenarios Used Within the Aerospace
> Industry]
> > > >
> > > >
> > > > > In response to Abid Farooqui's comments about EDI not being
> standard,
> > > > concerns
> > > > > about ebXML going the same way, and his proposed solution, I can
> only
> > > say
> > > > this:
> > > > >
> > > > > Yes, it is a pain (if you want a little more detail about why it's
a
> > > pain
> > > > in
> > > > > EDI, I invite you to check out the article of the same name under
> the
> > > X12
> > > > > Technical tutorial at my web site:  www.rawlinsecconsulting.com).
> > But,
> > > > you have
> > > > > to remember a few basic truths.  Even though it would be ideal if
> > > business
> > > > folks
> > > > > were a bit more aware of some of the IT costs involved in doing
what
> > > they
> > > > want
> > > > > to do, it is ultimately business needs that drive things and not
IT
> > > needs
> > > > or
> > > > > wants.  We can't put the cart before the horse.  EDI POs and ebXML
> > > > compliant POs
> > > > > will be different for different companies and industries because
the
> > > > business
> > > > > processes in which they are used are different.  It is as simple
as
> > > that.
> > > > If
> > > > > you want the POs to be the same, then the business processes need
to
> > be
> > > > changed
> > > > > - something that probably will not happen in any of our lifetimes.
> If
> > > you
> > > > have
> > > > > problems accepting any of this, you probably need to find a
> different
> > > line
> > > > of
> > > > > work.  There has been at least one other suggestion that a "least
> > common
> > > > > denominator" approach such as the one you suggest would work, but
it
> > > will
> > > > almost
> > > > > certainly not work because the data requirements of the business
> > > processes
> > > > will
> > > > > not be met.
> > > > >
> > > > > The context dependent core component work should help ease or at
> least
> > > > make it
> > > > > easier to identify the differences in POs, but it won't eliminate
> > them.
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Mike
> > > > >
> > > > >
> > > > >
> > > > > ------------------------------------------------------------------
> > > > > To unsubscribe from this elist send a message with the single word
> > > > > "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org
> > > >
> > > >
> > > > ------------------------------------------------------------------
> > > > To unsubscribe from this elist send a message with the single word
> > > > "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org
> > > >
> > >
> > >
> > > ------------------------------------------------------------------
> > > To unsubscribe from this elist send a message with the single word
> > > "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org
> > >
> > > ------------------------------------------------------------------
> > > To unsubscribe from this elist send a message with the single word
> > > "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org
> >
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org