What are all the possible building blocks or inputs for a process?

[MarkJoel]

What are all the possibile building blocks or inputs for a process?

I want to create a document that defines how to create process documents.

Is there one out there?
If so please post!

Please use plain english since I am a novice!

 

[Craig H.]

Mark:

You are asking a lot here, and I'll tell you why.

When you are creating process documents, it is best to remember what the document is to be used for, and who is using it. That gives a perspective from which to start.

For instance, take a basic process of, say, washing a car. The guy with the sponge may need to be told "..turn on the water to the hose. The valve is under the cover in the floor near the back roll up door. Turn the valve counter-clockwise until the desired presure is reached." The folks in the office, on the other hand, may be able to do their work with "...spray the car with water...".

In your case, I would try to standardize which flowcharting shapes mean what (start of process, decision diamond, etc.). Going much further than that will be problematic, IMO.

Good luck, and hope this helps.

 

[Mike S.]

Craig makes good points. Perhaps it would help you to see some examples. I know there are many process flow charts posted here -- try a search using "process flow" and I'll bet you see big threads with lotsa examples.

 

[MarkJoel]

Thanks for the info!

 

[M Greenaway]

Try reading up on a recognised process mapping approach, such as IDEF0.

 

[Greg B]

What are all the possibile building blocks or inputs for a process?

I want to create a document that defines how to create process documents.

Is there one out there?
If so please post!

Please use plain english since I am a novice!

Hi Mark,

Here is a small training package I put together some time ago and put it up on the cove in May 2003. (You may use it but please remember where you got it from)
http://elsmar.com/Forums/attachment.php?attachmentid=810

And here is the thread it is from

http://elsmar.com/Forums/showthread.php?t=6059

remember that a search will turn up a lot of information. I hope this helps in some way.

 

[Diana Cadwalader]

Process Training Package - Nice

Hi Mark,

Here is a small training package I put together some time ago and put it up on the cove in May 2003. (You may use it but please remember where you got it from)
http://elsmar.com/Forums/attachment.php?attachmentid=810

And here is the thread it is from

http://elsmar.com/Forums/showthread.php?t=6059

remember that a search will turn up a lot of information. I hope this helps in some way.

Greg: Nice presentation. Simplistic.

 

[Peter Fraser]

What are all the possibile building blocks or inputs for a process?
I want to create a document that defines how to create process documents.
Is there one out there?
If so please post!
Please use plain english since I am a novice!

Mark

Picking up on the "plain English" theme ...

1 the "building blocks" for a process are: the steps (activities) involved creating the output from the process / the resources it needs to function / the event that triggers it to start. [Remember that a process can exist and function without being documented at all]

2 the "inputs" to a process are not the same. Using the "traditional" definition of a process (which I believe is the cause of much confusion unless you limit it to a production line), they are the resources required (in my opinion, whether they are "transformed" or not).

3 as Craig H says, a description of a process can be an outline flowchart at one extreme or a detailed work instruction at the other. It all depends on why you are defining the process and for whom. (eg IDEF0 may not work too well for someone on the shop floor).
As an aside, I have noticed recently that folk talk about a "process map" in two totally different ways - one is "a picture of our business showing how the key processes fit together", and the other is (typically) "a flowchart of the steps in a specific process". Confusing?!

4 Anyway, my advice would be:
4.1 first, clarify the purpose of the intended process description and how it will be used
4.2 clarify the objective of the process (ie why are you doing it, and what is the end result you want?)
4.3 describe the steps you follow to achieve the result (and don't get to hung up on the "what-ifs" at this stage - describe it as it normally happens)
4.4 if necessary, add a bit more detail on how a step is performed (and identify documents, registers, forms, work instructions etc, whether you create, refer to, update or file them)
4.5 say who is responsible for each step, and who else is involved (consulted, informed etc - have you come across RACI?)

Then show it to someone who will use the description, and get their feedback on whether it helps them to understand the process.

 

[MarkJoel]

Thanks to all you have been very generous and patient!