Re: Process Flow Chart is a Work Procedure?
That sound you can hear in the background is my grandmother sucking eggs.
Hardly there's any harm in calling both the documents as procedures but at some point we need to differentiate the two. 'Procedures' are normally defined at the 'Process or 'activity level' (largely at the functional/ department level) but certainly the work instructions come into way at the 'task level’. The task level is at the level of the individual. A process is not a ‘work’ (task) but a set of activities or tasks and hence the two cannot be considered as one and the same thing.
I'm aware of the distinction but was merely making the point that whatever the document is called it is still a documented procedure. You can call it Ethel (not my Grandma's name

) but, if it is a
specified way to carry out an activity or a process ( )
then it is, (in ISO terms) a procedure.
Procedures are infact documents (let's assume we are discussing in terms of written down documents) ... <snip>
Let's be clear (again). You can have procedures and you can have documented procedures. Not all procedures have to be documented. Full stop, period, point.
<snip>...with detailed process descriptions which may have:
- Process objectives
- Process inputs and outputs
- Process standards
- Operating conditions and methods
- How this process interact with other processes
- Reference to required Records, specifications, guidelines, work instructions etc.
- Resources required
- KPIs
- Methods of measuring the process performance
- Troubleshooting guidelines etc. etc.
No argument with what you think might go into a documented procedure.
We can differentiate the two by looking at the big picture of the organization:
Hold on a second while I give granny a few more eggs.
1. The organization is a system which comprises of business processes that mainly create and fulfill customer demands. Key documents required at this level are mission statements and policies (organizational or unit level).
2. In order to fulfill the ‘demands’ an organization sets up some work processes which ISO 9001 defines as ‘Product Realization process’ (planning to post delivery activities/ processes). At this level, the organization defines its processes and ‘process descriptions’ which among other elements as mentioned above, do have standards (acceptance levels/ process specifications), plans, process/ deptt. level policies and Operating Procedures (process or activity level documents).
3. Finally we arrive at the TASK level where an individual needs ‘instructions’ on how to work /do (operate, use, handle, control, manipulate, run: (Oxford meaning)) a specific task in a specified way in order to achieve consistent results and the documents that describe ‘step-by-step’ instructions for carrying out a task, are normally known as ‘Work Instructions’.
If that is your way of distinguishing between different types of Ethels, sorry procedures, then fine.
Since 'purchasing' fits well into the definition of a 'process', I know it as a 'process' but in the big picture (Product Realization), it can also be termed as a 'sub-process' (undefined). There's no fine line where we stop calling an 'activity' a 'process'. If you further go up, Product Realization Process may look like a sub-process of the 'Demand Fulfillment Process' which again is a subset of the higher level Business processes. It all depends on the way one looks at the things.
I have already explained that I feel purchasing is part of a bigger process but am not going to reopen that argument here. I do have a problem with your
'Demand Fulfillment Process' which again is a subset of the higher level Business processes
comment. Any process that captures customer requirements and fulfils them is, IMHO, at the highest level.
Now I appreciate you haven't had a chance to react to my request to be careful with quoting my posts so will simply discuss this as I see it:
Now I recognize that I am probably alone in this but feel that purchasing is not a process on its own but is an activity that supports a lot of the 'product realization' processes. A flow chart can also describe a process. As soon as it prescribes the way of doing things then it becomes a procedure.
I've put your added highlights back in here because your next point takes it up.
By your own reasoning, it can also be tagged as a Work Instruction (the way of doing things). 'things' is a confusing word - if you replace it with 'process or activity', then it's a procedure but if you replace it with 'work' or 'task', then it should logically be a WI.
A couple of things:
- Whenever I talk about a process I only ever mean at the high level and any process flow chart would therefore be at a documented procedure level (using your distinction above)
- I accept in ISO definition terms an activity is also a process and therefore could require a work instruction but you won't hear me using the terms process and work instruction in the same sentence.
- The point in my original post that you missed or ignored is that a procedure (whether documented or not) is a prescribed way of carrying out a process or activity (see ISO definition above). So if the MD tells people that all customer orders have to be handed to the sales department and they must then be tied in pink ribbon then that is the procedure that must be followed. S / he may then decide that it is so important this procedure is followed that the procedure must be documented, people trained in its use and signed off by the HR department as competent to tie the ribbons.
(It is a silly example but I think it makes my point.
