I believe they can be but I have not seen any examples of this.
I have only seen them done in written form.
I am starting on revamping the nonconforming material procedure right now, when in the middle I am thinking "Hey this could be a lot shorter and a lot more clear for the employees if it was in flow form". Then taking a look at the rest, there are a lot of procedures that could be dealt with this way.

I guess my dumb questions are, where do you fit the purpose, application, scope, and definitions into these?
On the LONG format it's easy, you just list them out.
But does that really NEED to be on there? Or can you generate your flows without listing all that out as in the old format.

Anyone have any examples of QP's in flow form that have satisfied ISO-9000-2k?
It would help to see some.

Thanks

G.

I don't have any examples, but I did once audit a supplier that used flowcharts as procedures & work instructions. I thought it was very effective. This supplier was not ISO registered & had no plans for becoming so.

When I was a QA/QDC manager at a construction company, I used embedded flow charts in procedures & work instructions to clarify &/or reduce the amount of verbiage I would have otherwise needed. I don't have those files with me, but I'll check to see if I can find one & clean up the company name information so I can post it.

My current employer uses process maps embedded in our procedures & work instructions. Unfortunately, I am not at liberty to share them. We are ISO 9000:2000 registered & are working on AS9100 registration.

I guess my dumb questions are, where do you fit the purpose, application, scope, and definitions into these?
On the LONG format it's easy, you just list them out.
But does that really NEED to be on there? Or can you generate your flows without listing all that out as in the old format.


Where does it say you have to have all of that stuff. I don't have any examples handy, but I know companies that have added enough detail to the flowchart, so the user knows what's going on and what's expected. Just remember, the procedures are written for the process owners, and operators, not the auditors.

If you can squeeze enough information into a flowchart that everyone in your company can follow and understand go for it!
We have not gotten that far. We have very few embedded flowcharts in a few of our procedures. We don't have the most user friendly flowchart software, and not everyone is comfortable making/using them. Some are still stuck on "written" details.
Here is an example of a Non-Conforming flow that is embedded. The written parts just further explain the flow chart.
Sorry for the low quality but I wanted to post it as an image.

Gman,

Do whatever works best for your company to convey the necessary info. If that is text, flowcharts, pictures, drawings, movies, or whatever, so be it. Do what works. If you want you can always use "hybrids" combining any or all of the above.

If you can squeeze enough information into a flowchart that everyone in your company can follow and understand go for it!


If not everyone in the company, at least those who are using it.

A number of our procedures are combinations of text and flowcharts, and in some cases the text is actually just there to clarify the flowcharts. You mentioned that you were working on your nonconforming material procedure. Here is ours. As you will see, it is mostly comprised of flowcharts to indicate the process flow and then text to add more detail and clarity.

At our company I have made it a requirement that all Level 2 procedures that are either being created or revised, and have a "process" within them, that processes have to be documented in the form of a flow chart. This change went over surprisingly easy. We use MS Visio to create the flow charts and cut and paste them into a MS Word document (We have such things as Scope, Purpose, References, Responsibilities, etc. in the procedure in addition to the process). The primary advantages of using flowcharts are to clearly show the hand-off of information or material between two entities and showing decision points in the process. The decision points are there to depict different scenarios (ex. product A and product B have slightly different processes) and to accommodate the two or more directions the process can take after something is reviewed or tested. These decision points are very difficult to incorporate and logical follow within a standard outline of a Word doc.

We found the time to ramp up one's understanding of how to use Visio was minimal; few if any went to any formalized training. I pretty much spent an hour or so with a user creating their first flowchart.

A secondary advantage for using flowcharts is for your internal auditors in understanding the process that they are about to audit.

One final comment. I have found that not all Level 2 procedures we created have a "process" associated with them. For example, our Control of Records procedure merely states where records are kept. In this particular case, I have the detail about when to collect a record and how long the records must be kept embedded into the procedure that actually creates the records. The point being is that if you are like us, you may have procedures that list requirements only and may not have an actual process where something is being transformed.

I hope this helps.

Tom

I guess my dumb questions are, where do you fit the purpose, application, scope, and definitions into these?


I gotta ditto Dave on this one....these items are not required in written or flowcharted procedures.

CarolX

I gotta ditto Dave on this one....these items are not required in written or flowcharted procedures.

CarolX

But that also doesn't mean its wrong to have them. If it works for you, you can put them into a header, or footer to the chart, or even a callout.

But that also doesn't mean its wrong to have them. If it works for you, you can put them into a header, or footer to the chart, or even a callout.Dave,

Agree, bottom line is what works best for each individual company.

Carol

This is some great feedback, I will post my old and new procedure on here once it is finished for more feedback (it may take a while though).

Something else, when you reference a FORM in your procedure, for example, a hold tag or a scrap tag, do you have ot list it's (in our case QSF) number along with it like in: "...will place a Material Hold Tag (QSF 1.2.4.5.03) on the material.
Or will Material Hold tag be enough?
The was hey are written now it has every reference ot every form and procedure listed with their Assigned Number. Seems like overkill to me.




G.

Just as there is no requirement to have the purpose, scope, etc... there is no requirement for how to handle references. The key thing to remember is that it is your procedure and you can develop it however you see fit. If having the number referenced each time is not necessary, then get rid of it. If you make the procedures usable, then people might actually read them :)

Just as there is no requirement to have the purpose, scope, etc... there is no requirement for how to handle references. The key thing to remember is that it is your procedure and you can develop it however you see fit. If having the number referenced each time is not necessary, then get rid of it. If you make the procedures usable, then people might actually read them :)

I'll Green Dot that! :agree:

Okay now I just noticed that there is a controlled "Work Instruction for the development of procedures in written format"!

I clearly lays out the requirements for writing a procedure, along with the scope, purpose, and requiring that all forms and procedures are listed along with their Numbers listed at the start of the procedure and when they are listed thruout! ****! I have neer seen a work instruction for writing procedures.

Someone tell me I am not crazy.

G.

Okay now I just noticed that there is a controlled "Work Instruction for the development of procedures in written format"!

I clearly lays out the requirements for writing a procedure, along with the scope, purpose, and requiring that all forms and procedures are listed along with their Numbers listed at the start of the procedure and when they are listed thruout! ****! I have neer seen a work instruction for writing procedures.

Someone tell me I am not crazy.

G.

I can't answer the crazy part (I'm too biased to make judgement :ko: ). However, if there is a work instruction, it is one of your local docuements. If it doesn't make sense, or if it doesn't work for you, then get rid of it or re-write it so it does work.

Okay now I just noticed that there is a controlled "Work Instruction for the development of procedures in written format"!

I clearly lays out the requirements for writing a procedure, along with the scope, purpose, and requiring that all forms and procedures are listed along with their Numbers listed at the start of the procedure and when they are listed thruout! ****! I have neer seen a work instruction for writing procedures.

Someone tell me I am not crazy.

G.
As long as you are updating and changing procedures you might as well start with that one :vfunny:

Looks like Dave and I are stumbling over each other to help out :biglaugh:

At least we aren't contradicting each other :D

Okay now I just noticed that there is a controlled "Work Instruction for the development of procedures in written format"!

I clearly lays out the requirements for writing a procedure, along with the scope, purpose, and requiring that all forms and procedures are listed along with their Numbers listed at the start of the procedure and when they are listed thruout! ****! I have neer seen a work instruction for writing procedures.

Someone tell me I am not crazy.

G.
Gman2

You're not crazy. We have a similar procedure or work instruction. The value in such a document is that it provides a template for those document attributes that your organization deems as being valuable or important, and hopefully insures consistency in format of documents. Its primary use is for document creators/owners who are not familar with the requirements to follow when they are modifying or creating procedures. Once someone knows what the "proper" format is for a procedure, its value drops to 0.

Tom

Okay now I just noticed that there is a controlled "Work Instruction for the development of procedures in written format"!

I clearly lays out the requirements for writing a procedure, along with the scope, purpose, and requiring that all forms and procedures are listed along with their Numbers listed at the start of the procedure and when they are listed thruout! ****! I have neer seen a work instruction for writing procedures.

Someone tell me I am not crazy.

G.

No, you are not crazy; in fact, we made a "procedure to make procedures" to get ISO9002:1994 ; two years ago, now, because we just began to implement a QMS here in Mexico, here, the things runs different as in other countries; we need to tell exactly what to do if not everybody will pointing at you if they missing something;

Now, the culture "grows up" a little bit and due to we are changing to TS, this is one of the procedures we will take off...

I don't have any examples, but I did once audit a supplier that used flowcharts as procedures & work instructions. I thought it was very effective. This supplier was not ISO registered & had no plans for becoming so.

When I was a QA/QDC manager at a construction company, I used embedded flow charts in procedures & work instructions to clarify &/or reduce the amount of verbiage I would have otherwise needed.

How about turning it around, so that you define your processes in flowchart format, and refer to supporting documents (procedures, work instructions, forms etc) at the relevant point in the process? If you need a sub-process at a particular popint in a process, just link to another flowchart (after all, a process definition is just one type of procedure).

We have now assisted a number of organisations achieve the new standard using a simple system structure based on processes, along the following lines:

Almost all organisations do the following:
- Plan and organise
- Get and do work
- Manage resources (including people)
- Review and improve.

Typical processes within this structure might be:

Planning and Organising
- Prepare a business plan
- Define policies and objectives and how you will implement them
- Define and manage operational processes
- Allocate top level responsibilities for key functions

Getting and Doing Work
- Develop a marketing strategy
- Design and develop new products
- Promote the business
- Find potential customers
- Tender / sell
- Initiate / manage / complete a project.

Managing Resources
- Equipment / premises / finance / information / documents and records.

Managing People and Relationships
- Staff, suppliers, agents etc

Reviewing and Improving
- Review processes
- Fix problems and make improvements
- Review operations
- Review the business.

We do not use the standard as a template. We do not have a "Quality Manual" as a separate document - the system IS the process definitions (in flowchart format), with reference to supporting documents where required. People use it because they can find their way around it, and it matches what the organisation does. And assessment bodies like it.

A number of our procedures are combinations of text and flowcharts, and in some cases the text is actually just there to clarify the flowcharts. You mentioned that you were working on your nonconforming material procedure. Here is ours. As you will see, it is mostly comprised of flowcharts to indicate the process flow and then text to add more detail and clarity.

This is an example of a QMS procedure used , here. :bigwave:

Hi, all:

Does anybody set procedures on ordering materials?


thanks,

Lucy

I guess my dumb questions are, where do you fit the purpose, application, scope, and definitions into these?
Iso/Tr 10013:2001 doesn't prohibits of write Procedures using Flowcharts , so is written in p. 4.5 , but in 4.4.2 the norm suggest to define the purpose, scope and registration. (http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=26978) By

[QUOTE=Gman2]I guess my dumb questions are, where do you fit the purpose, application, scope, and definitions into these?
QUOTE] Iso/Tr 10013:2001 doesn't prohibits of write Procedures using Flowcharts , so is written in p. 4.5 , but in 4.4.2 the norm suggest to define the purpose, scope and registration. (http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=26978) By

There is NOWHERE that states that you must place purpose, application, scope, and definitions in a quality document. This is a bit of a myth started by the ancients when they wrote the original Procedures and Work Instructions they simply followed the layout of the Standard (mainly ex Military types like myself). If you have a Flow chart as a procedure or a Video etc it must carry a title and or registration details (some form of recognition to distinguish it from other documents). It does not require all of the other GUFF. Rememebr that the documents you werite are for YOUR business not the auditor.

There is NOWHERE that states that you must place purpose, application, scope, and definitions in a quality document. I'm Agree there is only suggestions in the standard iso/Tr 10013:2001. Rememebr that the documents you write are for YOUR business I'm agree.not the auditor.
I disagree with you (. I'm going to write my opinion. Would somebody else kindly to give an opinion about that in the meantime?. By

Just wanna share my experience and opinion on the topic.

Yes, procedures can be documented using flowcharts.

I love flowcharts!

At a glance the user could see all the branches and sub-branches of a process. For complicated processes, i usually put a superscript over the text inside the flowchart shape and it is referenced to the rear page of the flowchart - the Notes portion.

Ive seen some organizations create redundant documented procedures - in narrative and in graphical (flowchart) formats. This would be difficult in revising said documents cuz the author/process owner would have to change both.

I use Microsoft (TM) Visio in making my flowcharts and I really enjoy making them.

Warm greetings to everyone!!!

With regards to other information beside the "meat" of the procedure, I only indicate the scope.

Why?

Defining the scope provides the reader an idea of the content of procedure/flowchart, the start and end points, without going through the whole document only to find out they got the wrong procedure. This IMHO, saves a lot of time and its only a couple of sentences long at the most.

Terms and definitions are defined in the quality manual appendix - the Organization's Lexicon.

Mabuhay!!!

Yes, procedures can be documented using flowcharts.
The point is not this. If the prescriptions contained in the procedures are recorded subsequently they can be visualized in every way. In the way corrected to the occasion! :bigwave:

IMHO Flowcharts present an alternative (or maybe even better) way to view/visualize complex processes.

Some processes are not as simple as "pass go and collect $200".

Some processes have multiple nested "if-then-else" statements making it difficult to follow in a narrative documented procedure.

Cheers!!!