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

["Schuldt, Ron L" <ron.l.schuldt@lmco.com>]

Rachel,

I agree completely that it not an either/or situation and also agree that if
we confine the discussion on this list to the relatively simple commodity
MRO procurement, we will make great progress. However, each industry must
deal with those topics that are truly unique to their industry and that
require extensions to the commodity MRO procurement processes. 

The basic processes/data you scoped out provide a good start for identifying
the basic core components required by nearly everyone.

Thanks! I trust that others on this list agree.

Ron Schuldt
Lockheed Martin Enterprise Information Systems




-----Original Message-----
From: Rachel Foerster [mailto:rachelf@ix.netcom.com]
Sent: Wednesday, June 06, 2001 11:01 AM
To: ebxml-dev@lists.ebxml.org
Subject: RE: [Fwd: Example Scenarios Used Within the Aerospace Industry]


Ron,

Excellent example and good points. My personal opinion is that for most
industry supply chains the processes and messages required to support the
processes are best determined and defined by the subject matter experts
within that domain, e.g., healthcare, electronic components, automotive,
aerospace, etc.

On the other hand, I also think there is value for a small suite of
"generic" light versions of processes and messages for the other scenario
you describe....purchasing/replenishing commodity MRO type items.

I certainly don't see this as an "either/or" situation. What's wrong, for
example, with developing something extremely basic and fundamental for the
small guys to use to buy something, receive something, and pay for it. My
experience over the last couple of decades leads me to believe that this
could be done by any one of us (or a handful of us) over a few drinks in a
bar. These simple buy/receive/pay this for commodity/MRO items are just not
that complicated.

For example, in a simple PO what would the seller need to know? Well...

1. Who's buying
2. Where do I ship and when (immediate or some date in the future)
3. How I am going to get paid (credit card, open account, COD)
4. What's being purchased and at what price (and most often, the buyer in
this case doesn't set the price, the seller does upon receipt and acceptance
of the PO)
5. How many of what unit

I bet this set of data could be used for the vast majority of routine,
commodity/MRO type buys.

Rachel Foerster
Principal
Rachel Foerster & Associates, Ltd.
Strategies for Electronic Commerce
39432 North Avenue
Beach Park, IL 60099
Phone: 847-872-8070
Fax: 847-872-6860
http://www.rfa-edi.com



-----Original Message-----
From: Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com]
Sent: Wednesday, June 06, 2001 9:42 AM
To: 'David Lyon'; ebxml-dev@lists.ebxml.org
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