OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: AW: POs considered harmful for dependent demands


     Hello.
      
     Here I am, late in the discussion.  There's one point I haven't seen  
     anybody make.  Or I've missed it by reading the thread too fast, so  
     pardon me if the point has been made ... the appeal to the bottom-line  
     ...
      
     I'm frequently asked by my internal customers (the ones who place the  
     orders to our suppliers) why they should bother with implementing  
     processes that eliminate PO's.  "Because they are electronic, what  
     difference does it make?"  I don't know about other companies'  
     systems, but from the HP buyer's perspective, you're just pushing  
     'Release Requirements' button, and it generates an electronic signal.   
     It's the same amount of effort for the buyer whether pushing that  
     button generates a stand-alone (discrete) PO or a call-off against a  
     delivery schedule (a/k/a release against the blanket order or  
     scheduling agreement).  We call this latter process "Material  
     Release".
      
     After banging my head against the wall, I try to calmly explain that  
     it's not the same for the seller or for the accounting folks.  The  
     overhead associated with processing releases is significantly less  
     than the overhead associated with a new purchase order.   When a  
     supplier receives a new purchase order, it has to be reviewed.  Is the  
     pricing agreeable?  Has this material been forecasted?  Has material  
     been allocated to this buyer?  Is the contract current and valid?  Do  
     I have this buyer's address in my system? And so on. All the overhead  
     associated with discrete POs occurs early in the process when the BPO  
     is negotiated, and the releases in the Material Release need minimal  
     validation and can flow straight through to the supplier's shipping  
     system.
      
     And then I try to explain to the buyer that even though they push the  
     same amount of buttons for a release as they do for a PO, the  
     reduction in administrative and tactical time is significant.
      
     By the way, a semantic point ... we never really "eliminate" purchase  
     orders.  We may call things by different names, but there is still,  
     somehow, some way, always "Written authorization for a supplier to  
     ship products at a specified price, which becomes a legally binding  
     contract once the supplier accepts it," which is a legal definition of  
     "purchase order".
      
     Kind regards,
 __________________________________________________________________
                                                                 
              | HEWLETT-PACKARD SUPPLY CHAIN INFORMATION SOLUTIONS   
    /_  _     | SUPPLY CHAIN ELECTRONIC BUSINESS TEAM              
   / / /_/    | Stephenie Cooper, M/S 4L-5                         
      /       | eBusiness Development Engineer         
              | 1501 Page Mill Rd. Palo Alto, CA 94304 US          
              | Tel. 1/650.857-6970,  Fax. 1/650.857.5544  
              | Internet: stephenie_cooper@hp.com
              | Websites:  www.hp.com, www.hpebiz.com
              |
              | Member, Board of Directors
              | Electronics Industry Data Exchange Association
              | www.eidx.org
 __________________________________________________________________

      
      
     ______________________________ Reply Separator  
     _________________________________
Subject: AW: POs considered harmful for dependent demands
Author:  Non-HP-Hartmut.Hermes (Hartmut.Hermes@mch11.siemens.de) at  
HP-PaloAlto,mimegw9
Date:    2/18/2000 5:19 AM


Bob,

EDIFACT has some more specific message types which replace the use of purchase o
rders in many processes: DELFOR, DELJIT, HANMOV etc. Indeed I am not sure which  
different process you name "dependent demands". It would be helpful to have a pr
ocess model identifying the parties and their activities.


Kind regards / Mit freundlichen Gruessen Hartmut Hermes      
     Siemens AG EL LP           D-80286 Muenchen Tel: +49 89 9221 4564      
Fax: +49 89 9221 3753  
Tel: +49 8233 600 222     Cellular phone: +49170  
22 97 606   


> -----Urspr> üngliche Nachricht-----
> Von:  Andrew Macpherson [SMTP:andmac@idx.com.au] > Gesendet am:  Dienstag, 15.
Februar 2000 12:21
> An:   Bob Haugen; ebxml-bp@lists.oasis-open.org;  
ebxml-core@lists.oasis-open.o rg
> Betreff:      Re: POs considered harmful for dependent demands >  
> Bob
>  
> I'm not sure if there is a real difference. Whether it is a PO  
or a
> dependent demand, one is satisfying a need with a service or a good.  No >  
matter what you call it it is a request for item, quantity and price
> (information) coupled with a linked payment stream.  A distinction can  
be > drawn between push and pull mechanism but ultimately it is the user  
with > the need who initiates the process.
>  
> Andrew Macpherson
>  
> ----------
> > From: Bob Haugen <linkage@interaccess.com>
> > To: ebxml-bp@lists.oasis-open.org; ebxml-core@lists.oasis-open.org > >  
Subject: POs considered harmful for dependent demands
> > Date: Tuesday, 15 February 2000 3:51 > >  
> > Maybe everybody already knows this, so this is the short version.  
> > I have included this point in a different message, but wanted to  
> > make sure it was as clear as I could make it.
> >  
> > I still see documents going to this list that seem to assume > >  
that purchase orders are the way all B2B ecommerce is done. > >  
> > PO's are not a good mechanism for dependent demands,
> > and if they are set in stone in ebXML in such a way that
> > it is difficult to do business without using them, it will > > need to be  
redone for Internet-mediated commerce.
> >  
> > Dependent demands are demands that are dependent on some >  
> other demand, usually called the independent demand.
> > This concept comes from MRP, the predecessor (and still  
> > included in) ERP software.
> >  
> > Dependent demands include the components of  
manufactured > > products, retail replenishments, shipping  
for almost any > > purchased item, etc.
> >  
> > Purchase orders are a carryover from paper systems.
> > They are usually composed of a collection of line items,  
> > often aggregating quantities over time periods.  They
> > have no knowledge of how the purchases items  
> > will be used, nor what processes and components > > are  
required to fulfill the order.
> >  
> > Dependent demands, by contrast, are totally  
dependent > > on whatever independent demand  
stimulated them in the > > first place.   
> >  
> > All dependent demands should be linked to their
> > relative independent demand so if there are changes >  
> anywhere in the network of activities, they can be > > rippled out to the  
affected relatives.
> >  
> > For example, if a customer order for a finished  
good > > changes in quantity or timing or is cancelled  
- the > > dependent demands should be changed  
correspondingly. > >  
> > The PO is too heavy a mechanism for managing > >  
dependent demands - something more like an
> > electronic Kanban or manufacturing schedule  
> > or point-of-sale event notification would be  
> > better.
> >  
> > The same goes for invoices, which are  
unnecessary > > for dependent demands.
> >  
> > Comments? Violent disagreement or agreement? > >  
> > -Bob Haugen
> >  



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC