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

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.

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!

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.

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?

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).

M Greenaway said:

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).


OK. I got that. So an input must be altered by the process.

To help me further understand (I'm sure everybody else already knows this but I'm still in holiday mode with a high Corsican wine content in the old blood), tell me this:

1 can a document ever be an input?

2 if a document, as part of running the process, is altered (notes are added, it's signed off and and and .........) can it then be an input?

3 if a document MAY be altered by the process, but in some cases is not, is it an input only in those cases where it's altered?

3 is it true that stuff that is changed (sheet metal that is bent for example) is input while stuff that is not changed (a screw, for example) cannot be input and therefore must be resource?

4 if, in warshe's case, there is nothing that qualifies as an input, does that mean that his Purchasing 'process' can't be a process at all, since a process exists to transform inputs but there are none?

5 in your case, what forms do your 'purchasing requirement' inputs take, and how are they transformed so that they qualify as inputs?

6 are any of these questions answered in the IDEF0 documentation?

A million thanks for your patience.

Let's give it a shot here Tom, no not hair of the dog!

1) Yes - I'm thinking of standards, changes, etc.

2) Yes - Procedure approval process comes to mind.

3) No - Same as above without the procedure being edited.

4) Purchasing process has inputs; description of requirements, customer requirements, etc. If a process does nothing to the inputs and is just a "pass through" why bother with it? It would be like driving your car through the car wash with no equipment working. The car is a dirty coming out as it was going in! Why bother?

5) Purchasing takes the requirements (i.e. quantity, rate and flow, etc.) and transforms them into a contract with the supplier. I may order some amount of bar stock steel (ex. 45 feet of 1/2 inch round), purchasing identifies the best supplier, cost effective length for delivery, date to be delivered, etc.

6) I'm not sure about direct answers, but it will show you how to identify inputs and outputs.

Randy Stewart said:

Let's give it a shot here Tom, no not hair of the dog!


And a fine shot it is, too, sir! It all makes sense to me!

It seems you and I agree that when we are told that a process transforms inputs into outputs, that does NOT mean that the inputs are NECESSARILY altered by the process.

For example, the purchasing process input examples that you give (description of requirements, customer requirements, etc.) are not altered by the process.

Martin, I think, will tell us that (if we follow IDEF0 conventions) your examples are NOT inputs because they are not altered by the process.

Let's see what he has to say??

For example, the purchasing process input examples that you give (description of requirements, customer requirements, etc.) are not altered by the process.

Oh, but they are Tom. I'm not saying that purchasing will disregard requirements, but the request (submitted by the requesting department) becomes DA, DA, DAAAA, the SUPPLIER CONTRACT!!!! I'm just passing customer and my requirements onto puchasing. Purchasing then make my request into a usable document by identifying; supplier, cost, etc. If all I do is say "I need this and want that" I'll probably end up like a child going through the toy store at Christmas. I give a lot of ideas but usually walk out empty handed!!! It's not until that toy (inventory) is transformed into a purchased product (income) that it becomes usable to me!!!
It's not as easily seen in documentation as it is in say raw material becoming a saleable product. But the transformation is there. Look at the supplier side. They take a PO and transform it into useable product without really changing the input! They take the documented descriptions and requirments and make them into raw material. It may not be that the inputs are physically changed by the process, but translated and reorganized.
Did that help or make it more confusing??

Perhaps to clarify, and for some perhaps to confuse, I would liken the documented "inputs" to the way a simple transistor (or even for the older folk as simple triode vacuum tube) works.

With either of these electrical devices I have a major signal flow running from the collector to the emitter (cathode to anode for tubes), this signal is modified by a small varying signal applied to the base (grid for tubes), this variation affects the larger signal flow such that the resulting signal as it appears at the emitter (anode) seems to have "amplified" the change. The actual signal seen at the gate (grid) has not been affected, but has significantly impacted the output of this simplified electronic circuit.

Similarly, although documents that form the "inputs" to our processes may NOT be altered, they can (and many times do) have significant impacts on the output.

I hope that I added some clarification and not obfuscation.:)

When I was going through electronics training it was taught as "Transistor Theory"! Boy you've made me feel old!!!:biglaugh:

Randy Stewart said:

It may not be that the inputs are physically changed by the process, but translated and reorganized.


ddhartma said:

..... although documents that form the "inputs" to our processes may NOT be altered, they can (and many times do) have significant impacts on the output.


So it seems we three are in agreement that inputs may or may not be changed or altered in the process of 'transforming' them into outputs.

And we reached agreement with neither obfuscation nor befuddlement!

But does it mean that we transgress {shock! horror!) IDEF0 rules? And if so, do we give a flying fig?

Tom,
You may want to get a screen dump or the printable version of this page quick! The agreement going on here doesn't happen very often and you may want a reminder!
Just wait till Jim or Energy read this thread!!!!:smokin: :biglaugh:

Hi, all

If I may, I would like to offer my take on the purchasing scenario. To me, one important input is money, who's ownership is transformed. The ownership of the goods or results of a service also represent a transformation.

Therefore, as long as purchasing is buying something, it has to be a process.

If you buy all of this, the interesting aspect is, if we get invoiced and the goods arrive before we pay the invoice, Purchasing is one of the few processes where the output preceeds the input!!!

Great thread!!

Craig

Tom

Yes a document can be an input if, as you correctly say, it is transformed by the process - the production of records by filling out forms is a classic example. Another might be a drawing change through the engineering change process.

Processes may well be clerical or office based processes where the process is the transformation of data.

Also as you point out raw material, such as sheet metal, that is bent (for example) by a manufacturing process is clearly an input. A screw would also be an input if it goes through an assembly process for example (along with other stuff) to become transformed into a product of some kind.

IDEF0 does give us clear rules:-

2.17 Control Arrow: The class of arrows that express IDEF0 Control, i.e., conditions required to produce correct output. Data or objects modeled as controls may be transformed by the
function, creating output. Control arrows are associated with the top side of an IDEF0 box.

2.29 Input Arrow: The class of arrows that express IDEF0 Input, i.e., the data or objects that are transformed by the function into output. Input arrows are associated with the left side of an
IDEF0 box.

2.33 Mechanism Arrow: The class of arrows that express IDEF0 Mechanism, i.e., the means used to perform a function; includes the special case of Call Arrow. Mechanism arrows are
associated with the bottom side of an IDEF0 box.

2.40 Output Arrow: The class of arrows that express IDEF0 Output, i.e., the data or objectsproduced by a function. Output arrows are associated with the right side of an IDEF0 box.

Do we give a sh!t if we conform to IDEF0 - not at all, do we give a sh!t if we create understandable, clear and coherent diagrams to our company, sure do ! Will IDEF0 help clear up the confusion, well it works for me.

M. Greenaway said: Yes a document can be an input if, as you correctly say, it is transformed by the process - the production of records by filling out forms is a classic example. Another might be a drawing change through the engineering change process.

I'm trying to understand IDEF0 and think that it would help if you could help me through a simple illustration. My procurement process begins with the completion/issuance of a Purchase Requisition, which physically does not get "changed" in any fashion, but drives the purchasing process. Is the Purchase Req. to be considered as an "input", a "control" or a "mechanism"?

Identifying which, should help me to understand IDEF0 - since you have already provided the definitions of each. Right now I'm confused at best.:frust: :)

Edited to corrected Mr. Greenaway's name.

Yes, I believe "Transformed" or "Translated" works.
I haven't seen the publication referenced before, I'll have to look it up.

The link really helped, I've started to look at the ProSim 7 software too. It seems to be something we have been searching for. We have been trying to tie/integrate our Value Stream Maps (present and future states), Capacity Planning/Forcasting and MS Project (program input and timeline) together. Haven't been able to get real deep with it, but so far so good.

It was close to making my day Jim. Thanks.

Gone fishin', puttin' the bass boat in the water today!!!! So I'm looking at a POETS (P1ss On Everything Tomorrow's Saturday) day. Besides Surveillance #10 / 9K2K certification audit starts on Tuesday. Time to kill some brain cells.

I'll leave with these 2 points:
Never give yourself a haircut after 3 Margaritas and
Everyone seems normal, until you get to know them.

Have a great weekend folks. I'm outta here.
:thedeal: :smokin: :ko: