I am having a hard time focusing lately due to being overtasked, but I need your help please!

I want a document that shows the relationship between:

processes
work instructions
procedures
etc.


That include the definition of each.

To stay focused I need a map to start from point A and go to point B while trying to impliment, analze, rework, create processes, templates, instructions, procedures, etc.

Thanks for your help! :thanx:

Hi, MarkJoel! I think it would be safe to say that most of here have been in your position of overtasked, underresourced, overstressed, underfed...in fact....I think I have a family, but I haven't seen them in quite some time so I can't be certain. :D Last night, there was a picture of me on the fridge with the caption "Have you seen this woman?" underneath it. :rolleyes:

When it comes defining processes, procedures, work instructions, etc., you will find much information if you do a search on the Cove. Unfortunately, I do not know if you find the answers you are looking for - much debate has been had on this very topic and, at the end of day, I think the only thing we all agree on is that the definitions must be specific (and useful) to your organization.

How about this, though. Rather than ask us for how we define them, what do you think they are? What do you see the relationship to be between these items?

* laughs *

hehe.. you think he will just venture out and state his thoughts, just so we can stomp on them??..

lol. just kidding.

I was trying to think of the most succinct link I might have, so I might have to go with independent speculation -- but since you put the ball back in his court, I'll wait and see.

;)

Here is what I found:

Work Instruction
Work instruction describes how a standardized task is expected to be performed (Workflow, Task process elements).


Procedure
A procedure is a series of actions or operations viewed as discrete steps.
Low level
Usually written as 2nd person


Process
A process is any series of actions or operations viewed as a whole, with a start and a finish.
A process may not even have steps but may simply be a continuum (the process of fermentation, etc.). Additionally, a process is often something one observes, whereas a procedure is something one executes.

A process document defines what the process is (Name, subject, Action)

Process contains steps that may reference a procedure.
High level
Can be written as 2nd or 3rd person


I really think a procedure and WI are the same.

Please help me think!

Our company defines as follows:

Quality Manual - describes the system, defines the policy and commitment to quality, defines responsibilities and authorities & provides description of required processes and procedures.

Procedures - defines "who, what, when"

Work instructions - defines "how"

Record - to record information and may become a quality record.

Process - inputs, activities (or steps) and outputs - process must always have some sort of measurable.

Here are the definitions I put in my document from what I have researched (too lazy to think of the right words). :lol:

Work Instructions - step by step directions on how a task should be done.

Procedures – documents outlining specific work processes.

Process- is a series of actions leading to an outcome of a product or service.

Here is what I found:

Work Instruction
Work instruction describes how a standardized task is expected to be performed (Workflow, Task process elements).


Procedure
A procedure is a series of actions or operations viewed as discrete steps.
Low level
Usually written as 2nd person


Process
A process is any series of actions or operations viewed as a whole, with a start and a finish.
A process may not even have steps but may simply be a continuum (the process of fermentation, etc.). Additionally, a process is often something one observes, whereas a procedure is something one executes.

A process document defines what the process is (Name, subject, Action)

Process contains steps that may reference a procedure.
High level
Can be written as 2nd or 3rd person


I really think a procedure and WI are the same.

Please help me think!

Using your definitions, MarkJoel, think of it in terms of examples:

Process - Getting to work on time
Inputs - Alarm clock ringing
Outputs - Happy boss. Work accomplished
Resources required - Alarm clock. Automobile. Job. Driver's licence. Qualified person to set the alarm clock. Coffee maker. Mug. Lunch dishes. Leftovers.
Process - map showing the inputs, outputs and resources ensuring you get to work on time.

Procedure - Making coffee for morning commute in
1. Fill filter basket with coffee grounds.
2. Fill water basin with required amount of water.
3. Ensure carafe is in proper placement under coffee grind basket.
4. Turn on machine.
5. Pour coffee when machine is done.
6. Add sugar and/or cream, if desired.

Work Instruction - Coffee grinds
1. Place 4 tablespoons of coffee grinds in Blender-002.
2. Operate blender until expected granular size is obtained. Use Timer-001 to verify operation time.
Large grinds - 5 seconds
Medium grinds - 10 seconds
Fine grinds - 15 seconds
3. Via visual inspection, very size of grinds. Operate Blender-002 for additional time if required.
4. Poor grinds into 500mL container.
5. Repeats Steps 1-4 until 500ml container is filled to capacity.
6. Seal 500mL container with #4 lid.
7. Write current date on #4 lid of 500 mL container.
8. Place 500mL container on lower shelf in freezer to preserve.
9. Use grinds within two weeks of grinding date.

My company uses these definitions.


The QA Policy is a “DIRECTIVE” from the President of the company.

The QAM (quality assurance manual) documents “WHAT WE DO” .

The Procedures document “HOW WE DO IT” .

Detailed Work Instructions are “STEP BY STEP” procedures.

Forms are documents used for “COLLECTING” data.

Records are “COMPLETED” FORMS.

:2cents:

Great information! :applause:

So let me regurgitate.

Process or work flow = inputs (tasks) + outputs
Task = sequence of and interdependencies between the procedures that comprise the task

Procedures describes the physical activities that the customer performs

So therefore creating a process is the last step?

My company uses these definitions.


The QA Policy is a “DIRECTIVE” from the President of the company.

The QAM (quality assurance manual) documents “WHAT WE DO” .

The Procedures document “HOW WE DO IT” .

Detailed Work Instructions are “STEP BY STEP” procedures.

Forms are documents used for “COLLECTING” data.

Records are “COMPLETED” FORMS.

:2cents:


So what are Checklists used for?

So what are Checklists used for?
Either a form or procedure, depending on whether you record the information on it or use it for reference. If you record data, then it becomes a record after completing it.

I want a document that shows the relationship between:

processes
work instructions
procedures
etc.

That include the definition of each.


My view:
"Processes" have always existed because that is how day-to-day business operates. What has changed is the focus on the flow of work through and amongst departments rather than on what happens within a department. Nothing is achieved within an organisation which is not part of a process. Processes can exist without being "defined" - they can just happen, because the people involved know what to do, or they react spontaneously etc.

My definition of a business process is “a sequence of related tasks that is triggered by an event and which is intended to achieve an objective. It uses resources and is subject to influences”. [I have a problem with the "input - transformation - output" definition, especially when it is applied to admin functions and to the service sector.]

A "procedure" is merely a recorded description of how something (a task / an activity or a process) is done. So a process definition (in narrative, diagram or flowchart format) is just one type of procedure.

For completeness, I would define a “task” as “an activity within a process which is the responsibility of one person, performed at one time and in one place”. So a process definition can refer to other procedures for individual tasks.

A “work instruction” is most definitely a procedure. In my experience, a work instruction is typically “a detailed description of a (relatively complex) task, usually carried out by one person”.

Dear MarkJoel...
See attachment for yet another perspective (or two) on the topic of Operating System Documentation. In the attachment, the samples show one system with 4 levels of documentation, and the other with 5 - You can have as many levels as you think is necessary to provide clarity and navigation through the system documenation. How you define and distinguish the levels is what is important.

I'd appreciate your feedback.
Thanks and good luck.
Patricia

Sometimes a picture is worth a thousand words

Dear MarkJoel...
See attachment for yet another perspective (or two) on the topic of Operating System Documentation. In the attachment, the samples show one system with 4 levels of documentation, and the other with 5 - You can have as many levels as you think is necessary to provide clarity and navigation through the system documenation. How you define and distinguish the levels is what is important.

I'd appreciate your feedback.
Thanks and good luck.
Patricia

Patricia,
Beautiful graphics!
They are clear, concise, and to the point.
I am now starting to see the light!
Many thanks for your attachment.

:applause:

I wholeheartedly agree with the gentleman from Texas. Very nice looking and easy to grasp.:agree1:

/Claes

My view:
"Processes" have always existed because that is how day-to-day business operates. What has changed is the focus on the flow of work through and amongst departments rather than on what happens within a department. Nothing is achieved within an organisation which is not part of a process. Processes can exist without being "defined" - they can just happen, because the people involved know what to do, or they react spontaneously etc.

My definition of a business process is “a sequence of related tasks that is triggered by an event and which is intended to achieve an objective. It uses resources and is subject to influences”. [I have a problem with the "input - transformation - output" definition, especially when it is applied to admin functions and to the service sector.]

A "procedure" is merely a recorded description of how something (a task / an activity or a process) is done. So a process definition (in narrative, diagram or flowchart format) is just one type of procedure.

For completeness, I would define a “task” as “an activity within a process which is the responsibility of one person, performed at one time and in one place”. So a process definition can refer to other procedures for individual tasks.

A “work instruction” is most definitely a procedure. In my experience, a work instruction is typically “a detailed description of a (relatively complex) task, usually carried out by one person”.

Peter Fraser,

We all know that it is good to sound practical or to have common sense, but personally, I believe that it's only when we start talking with accuracy and seriousness, that we start building unvaluable knowledge (maybe I've sounded too pedagogic, but I believe that). So Peter, I like very much your definition of "process" and I have these 3 questions.
1) When you say that a process has to be triggered by an event, what kind of events are you referring to? An input of supplies? An order from a boss? A request from an internal or external client?
2) Don't you think that the definition "inputs-transformation-output" would always apply?
3) When listing the tasks within a business process, are they supposed to have always a sequential order?

I hope you'll be interested in answering my questions. By the way, I liked that part of the process's definition that says "subject to influences".

Happy new year,

Raphael

Peter Fraser,

We all know that it is good to sound practical or to have common sense, but personally, I believe that it's only when we start talking with accuracy and seriousness, that we start building unvaluable knowledge (maybe I've sounded too pedagogic, but I believe that). So Peter, I like very much your definition of "process" and I have these 3 questions.
1) When you say that a process has to be triggered by an event, what kind of events are you referring to? An input of supplies? An order from a boss? A request from an internal or external client?
2) Don't you think that the definition "inputs-transformation-output" would always apply?
3) When listing the tasks within a business process, are they supposed to have always a sequential order?

I hope you'll be interested in answering my questions. By the way, I liked that part of the process's definition that says "subject to influences".

Happy new year,

Raphael

Raphael

First of all, thank you for your questions - in a way I am disappointed that more people haven't responded, since I believe that the traditional "input - transformation - output" definition is too often accepted without thinking about what it is really saying.

1) Yes, you are on the right lines here. A "trigger" can be an event (eg a customer phones with an order), a thought (eg you decide to carry out a management review) or even a date in a diary (eg the accountant sees that it is the end of the month and he needs to do the month-end accounts and reports).

And the same logic applies to a task within a process (eg a form from another department appears in your in-tray). [This may mean that there is no clear differentiation between a "process" and a "task", although I would suggest that in many cases a task is carried out by one person, and a process is more likely to have a number of people involved]

2) Definitely not! It obviously applies to a "continuous production line" type of process, where you have raw materials ("ingredients") being "transformed" into (eg) a TV set or a cake. Once they have gone through the process they no longer exist in their original state. But take as an example something I found on the website of a flowcharting software company:

Input = Requirements Specification
Process/Task = Functional Design
Output= Functional Specification.

(i) the Requirements Specification has not been transformed - it still exists (and in fact will need to remain in existence, since you may need to refer to it later)
(ii) the "process" or task is the design and development of a Functional Specification
(iii) the trigger to start the design is the completion of the Requirements Specification
(iv) I see no benefit in defining the activity and the output in separate boxes on a flowchart (as they do), especially when this is repeated for every task in a process. The flowchart becomes twice as big as it needs to be, and is therefore less likely to be used.

Or take Procurement: someone recognises that you are short of stock (that is the trigger), so they raise a requisition. The objective of the process is to get more stock into the bin. It is non-intuitive and pointless to say that the requisition is "transformed" by someone issuing a purchase order - the requisition must still exist so that you can check the order details against it.

I accept that a process can have a number of "inputs" - but I see these as (a) the "trigger" which starts it off, (b) the resources it needs to function (people, methodologies, drawings, transport etc, none of which you want to be "transformed", since you need them the next time) and (c) the factors which can influence how well it works (company culture, lack of staff, risks, need to comply with external standards).

Non-manufacturing type processes are discontinuous and selective. By this I mean that you do not press a button and the whole process is followed without interruption - the people responsible for steps in the process are often also responsible for steps in other processes, and they select what to do next. So a process stops and starts. The "traditional" definition does not help a manager to manage a process - it doesn't mention an objective (which should be one of the key benefits of the "process approach"), it doesn't consider influences (which can cause many of the practical problems in an organisation) and it sets managers off on a wild goose chase to find "transformations".

Most folk don't go to work to "do" transformations - they try to meet objectives, and there are many issues which can affect how well they achieve them.

3) The sequence of tasks in a business process should be whatever is going to achieve the objective most efficiently. You can often have some activities which must be completed before you move on to the next stage in a process, but which do not have to be completed in any set order. But you can get round this in different ways: eg (i) define a single task called "Complete the paperwork" rather than separate tasks such as "fill in a form" / "update the register" / "sign the request" - these can be listed as "how" you complete the task; (ii) employ / train staff who know that the sequence is flexible; (iii) if the worst comes to the worst, actually say that "these three tasks can be completed in any order but all must be completed before you move on".

One last point: "Inputs" and "outputs" suggest that someone (or the process itself) is "putting" in or "putting" out. One of the most important points about management is that the things that "come out" of processes (harm to the environment, learning for staff etc) need to be anticipated and managed. Minimising / maximising them should be part of the corporate objectives.

Hope this helps.