Process inputs and outputs - Purchasing and Preservation

[warshe]

During PURCHASING PROCESS development I have tackled with such question- which inputs and outputs are in PURCHASING PROCESS ? My first thoughts about inputs and outputs are in PURCHASING PROCESS were:
-inputs are received customer orders and/or purchasing plans for stock renewal and/or replenishment;
-outputs are delivered products.

As inputs of a process are considered to be things that are transformed by process into outputs, inputs has to change in some way. This implies that requirements, orders, plans or any documents are not inputs because they are not transformed. They are the same at the end of the process as they were when they entered it.

Please tell me- what are on your view inputs and outputs of PURCHASING PROCESS ?

The same I would like to ask about PRESERVATION of to be delivered ready-made products PROCESS (in my case, this process includes handling, identification, storage operations).

Please tell me- what are on your view inputs and outputs of PRESERVATION PROCESS ?


Warshe

[db]

As inputs of a process are considered to be things that are transformed by process into outputs, inputs has to change in some way. This implies that requirements, orders, plans or any documents are not inputs because they are not transformed. They are the same at the end of the process as they were when they entered it.

Warshe, I think you are closer than you think. What if the input was the "missing" item that needed to be purchased? I have an order that requires three parts, but I only have two. The input is the missing third item, or "hole" in my inventory. When I purchase the item, the "hole" is changed to an actual part.

[Randy Stewart]

Warshe,
With purchasing what I've seen work best is the submission of a PO Request. The actual PO is written by the Purchasing Department not by the requesting individual/department. In this case the inputs to the PO would be description of material or product, quantity, inspection requirements, date desired, etc. This information is then used to negotiate and establish dates, price, rate and flow, etc. The output would be the Supplier Contract and agreement to meet the requirements of the PO.

I would think that inputs to the Preservation Process would be parts, delivery schedule, environmental (humidity, temp, etc.) monitoring, packaging requirments, FIFO, ect. If storage is the support or input to "transport to customer" then the output can be as simple as the part conforming to customer requirements.

Hope this helps.

Hello team! Here's an opinion....

I think there's too much credence given to this transformation malarkey. It's all taken too unnecessarily literally to the point where it all sounds like alchemy.

**********
I really do admire the thinking that came up with the 'hole as an input' approach, db. But ----- gimme a break!

**********

Warshe - sounds to me you've got it right. Your customer orders and/or purchasing plans are valid inputs. They represent the eventual purchased product. The process transforms that representation into actual product. It is not necessary for the inputs literally to be changed (although that happens in many cases)

As I say - it's just an opinion! Here's another: as for the 'preservation' process, maybe what you really have there is bunch of procedures. In which case, forget all about the input/output stuff!

[M Greenaway]

Warshe

Take a look at the IDEF0 approach to process mapping at http://www.idef.com/idef0.html

It differentiates between inputs, outputs, controls and mechanisms which you may find useful in creating a clearer picture of your process.

I could not comment on whether or not the examples you quote are true inputs, they may be, but if as you suggest they are not transformed by the process then they are probably more like Controls.

My purchasing process map starts with the input of 'purchasing requirement', a very generic term I know, but this requirement gets transformed into a purchase order through the processes of supplier evaluation, supplier selection, purchase requisition, and raising a purchase order. The whole process is completed by verification of purchase product process, which takes the delivered un-verified product as an input, uses the purchase order (amongst other things) as a Control, and generates a verified purchased product as an output.

Note how the output of raising a purchase order provides a control to the verification of purchased product.

Note also that the input to the whole thing at the start of 'purchasing requirement' may come out of the process of reviewing stock re-order levels, or vendor schedules, or production schedules, or your purchase plans.

Hope this helps.

PS db's 'hole' analogy is actually quite good.

[RosieA]

Warshe,
Here's an other take on it:

In my environment, the beginning of the purchasing input comes from the output of the engineering new design process, which defines the components to be used on the design. Often the engineering staff has worked with a specfic vendor and approved parts for the design.

My environment is one in which new design input may come from market needs and inputs, but not usually from a specific customer requirement. Therefore the beginning of the purchasing process is in engineering, not with the customer.

Consider a process that builds prototype products.

Imagine it as a black box into which I stick a document (a spec or drawing) - along with other stuff including resources - and a prototype product pops out the other end.

Doesn't the process, without changing the spec/drawing, still transform it into a prototype?

[M Greenaway]

No Tom.

The drawing has not been transformed into the prototype, raw material has. The drawing has just defined what the output of the process, the prototype, should look like - it is a Control (if we choose to use IDEF0 methodology).