Procedure equals a process?

John Broomfield

Leader
Super Moderator
I agree that a documented procedure may be a flowchart. I too can remember when auditors were reluctant to accept that flowcharts could be effective as procedures.

When ISO agreed that procedures did not need to be documented at all must have been difficult for some to accept and perhaps that was when process and procedure became synonymous for many people.
 

RajAUSQE

Registered
I'm having a lot confusion around procedure and work instructions.
I have define interaction processes but when writing a document some said it is procedure and other said it work instructions.
Any advise?
 

John Broomfield

Leader
Super Moderator
I'm having a lot confusion around procedure and work instructions.
I have define interaction processes but when writing a document some said it is procedure and other said it work instructions.
Any advise?

Users of the management system may prefer separation of the detailed how to instructions (for tasks completed by an individual) from the higher level procedures used by the process team to manage their interactions in fullling the process objective.

So, it up to you if you want to mix the levels of detail in your documented procedures, then don’t bother with documented work instructions. In my experience most choose to separate (for ease of reference) but retain links between to two types of document.
 

Jean_B

Trusted Information Resource
Just to add to the discussion.

Activity: "doing something" (I kid you not)
Process: activities that use inputs to deliver an intended result (output|product|service).
Procedure: a specified (described) way to carry out an activity or process. Easiest comprehended by reading as a documented procedure.

But why then distinguish these at all? Because we could in the past distinguish between what we had to say about them.
These days, "document (verb)" is 'conveniently' said to encompass the requirement to also establish, implement and maintain.
So we have a process that can be established, implemented, maintained, and documented. This is in addition to them being used to define, communicate.

To me establish (contrasting ISO's vague define/make) means tagging it with an identifier, and by implicit matters listing its inputs, outputs, the needed relations and the intended result after that process has been executed, undergone etc.
Implement means to "put into effect or practice". Maintain means to "enable to continue".

I don't quite like the interaction, which implies implement is the kick-off, and maintain is simply keep going. In most of my mentoring interactions, implement means easing it into the (quality) system, activating those established relations. Maintain means reviewing, adjusting it, keeping it up-to-date both with other parts of the system and with best practices outside of the system (e.g. updated standard, best practices or feedback from the market). The actual obligation to execute as needed is inherent in the presence within the system, and it can be either continuous, contiguous (periodical), or circumstancial (event-based, i.e. in case of fire do this, or when the order comes in execute); I feel that the word implement doesn't quite catch that feeling.

Competent people can know what is the needed input, output, what to achieve (establish), when to do so (implement), and assign responsibility to keep it aligned with the rest of the system and developments in the profession (maintain).
We all perform many processes daily which we don't have a written procedure for. We're competent, or if not we ask help, or a check on what we did.

The requirement to document one then becomes one of commitment, verifiability, support to explain (possibly, but not necessarily to train), ability to align other processes, ability to exchange personnel at a certain level, additional controls when the task is of such criticality you cannot leave it to memory and competence (the pilot's take-off checklist).

Instructions are best seen as used to teach, not execute. Remember that in the highly succesful Training Within Industry practice, the most detailed notes were only for the instructor (how words can line up). They were used to develop the instruction provided to the trainee, who had only a checklist of the most critical steps to check on (checklist).

What do most people like best when executing a task? A checklist, often in the form of a brief sheet or even a form to be checked off or filled in, and even checked again by someone else.

What do people prefer to see when being trained? All the textual detail: no. They want to see the chunks and the relations that allow them to make sense of it, give it a place in their mind to be able to recall it.

Who is able to give a comprehensive training without ever having thoroughly worked out what is they want to say. What would you use to train other instructors|trainers? I cannot give someone less than everything they need to teach, and probably need to give them more to be able to explain all the cases, evaluate exceptions etc.

Example:
Instructions for use are mostly (expected to be) read before the first use (interaction).
Manual is something more comprehensive, taken to be at hand when you run into problems, but not necessarily used in every immediate execution. Often it stands in for instructions, but still doesn't show everything, only the critical steps.

We look at what the standard and its terminology has become, but forget both where it came from longer ago, and how the form dictates how it will be used in the here-and-now because of human nature no matter what you call(ed) it.
At times I'd argue that work instructions were instructions to execute work. A list (Bill of Materials, Production Order), that instructed/told you how to configure or what to make. The how was in the competence, and only that instruction was new. If you're making the same every time it would just be orders to execute something you already knew how to.

Hierarchy (assigned status through title) has less to do with it than affordance (design/usability). The form/content of a document is more telling of how people (will) use it or ignore it than the artificially assigned priority, unless your organization is utterly disciplined or controlled. People will peruse only section headings, skip to images, prefer flowcharts that take up more space, scan bulletpoints more when they're pressed for time or believe they're competent and just need that little bit of confirmation. They'll not believe a short document can hold the answer if their problem is huge or has been haunting them for a long time (though once accepted, you'll get the a-ha of disbelief). They like people telling them what to do (minutes long YouTube videos) while a 30-second read could provide the same information. They prefer seeing it, just jotting the core sketch with that crucial action they were missing, and then going out to the car and fixing it (after likely first just having tried it with what they already knew). It's the same reason why, as competent auditors, we don't readily accept written procedures as proof that now everything is fixed, as its not that document that holds someone accountable to actually doing it, or doing it in that way.

I believe human nature informs us on how things should be to elicit or prevent certain responses from people. Thus establishing processes informs competent people, procedures provide additional confidence where people have accepted that the knowledge in their head is not fully reliable, and instructions are useful for increasing the competence of people, checklists are that extra bit of confirmation, forms are when you need resulting records to be interpretable for a long time or en-masse.
 

L.Bishop

Registered
My experience with differentiating these:
  • A process is more high-level. It's a 20,000 foot view of "what" is being done.
  • A procedure is more detailed than a process. It describes "how" something is being done.
  • A work instruction is even more detailed than a process or procedure. It is an exhaustive step-by-step.
All three could be for the same thing, the difference is in the level of detail.
 

Jim Wynne

Leader
Admin
I think the simple answer to this is that definitions of "process" and "procedure" may differ according to context and local usage, notwithstanding "official" ISO definitions. In some contexts the two might be synonymous, or very nearly so. For example, it might be said that in order to attain the required results, the proper process must be used. Saying that the proper procedure must be used is a distinction without a difference. On the other hand, if we're referring to the processes of the QMS, the ISO definition should rule. Likewise, we might refer to a document as a procedure, which is common usage.
 

Weeder

Involved In Discussions
My question is why are we forced to write procedures for everything? For example. MEDDEV 2.7/1 is a guide on Clinical Evaluation. You can simply follow this guide and prepare a clinical evaluation of your device that is in full compliance with the regulations. However, we are also required to have a Clinical Evaluation procedure in place. Basically, you are going to copy what ever is in the guide and create a procedure. You may throw in a couple of things here and there to show it is applicable to your device.

Same thing goes for the device vigilance guidance 2.12-1. This guidance is so comprehensive and detailed that you don't really need to have a separate procedure. But again, we are required to have a procedure that basically repeats what is in the guidance. I know some will say that you need to tailor the guidance to your own device etc. but essentially 90% of the procedure is already there.

What exactly is the purpose of a procedure in such cases?
 

John Broomfield

Leader
Super Moderator
Forced to write procedures for everything?

Where is this specified as a requirement?

These days our standards and auditors of systems and processes recognize the usefulness of undocumented procedures arising from training, competence and shared organizational beliefs and knowledge.

The old rule of document the system to the extent necessary for effective planning and control did lead to a lot of over documentation but much of that is disappearing as users find that the upkeep of many documents added cost but no value. Long may that continue.

These days system developers start with the process and the people doing the work. Respecting them as experts in what they do instead of acting as representatives of the “we know best department”. Consequently, the employees feel they own the system and are more enthusiastic about improving it as and where necessary.

But I am intrigued by your claim that you feel forced to write procedures for everything.

Kindly explain.
 

Big Jim

Admin
The word procedure no longer exists in the standard and for just the reason depicted here.

Processes and procedures were never intended to be the same although that is how many in the earlier days chose to create a quality management system. Old thinking tends to die hard.

For the OP, I see the biggest issue here that you don't consistently use the same set of processes. The set you mentioned first is a reasonable set. The standard requires that you determine what your processes are and how they interact with each other. This is shown with a chart depicting your core processes and how they interact. Also referred to as the IOP.

In answering your questionnaire stay with the same set as show on your IOP, which is likely the same set that you first described.

ISO somewhat led you into this trap because they failed to provide a sufficiently developed definition for the word process. What most leaders in the field today say is that the processes talked about in element 4.4 (where it says you need to determine them and haw they interact) refers to your BUSINESS PROCESSES.

Make sure your IOP is properly developed, that you can explain it, and CONSISTANTLY USE THE SAME SET OF PROCESSES when answering questions. When you don't use the same set it makes it look like you don't really know what they are.

PM me if you need further help.
 
Top Bottom