With the introduction of ISO TS focus on process it is necessary to create a map process , describe each macro process (Tortle map) and micro processes.

My question is if we have to create a new kind of Document on the top of the pyramide named process.

Process

Manual

Procedure

Work instruction

Registers

Threfore a new identification will be required?

i.e

Process1-rev or something like that.

Or Do we include the process map into the manual and some microproccess into procedures?

Thanks

Although process maps or turtle maps are not required, it is required to show your processes and process interactions. This can be done by using text only, but a lot of TS and ISO companies prefer to use process flow maps, turtle maps, etc to show customer oriented processes, suppoet processes, and management processes and how they interact. This is usually is easier to understand by your people and easier for the certification auditor too.

To add to Ralph's response, the standard (4.2.2) calls for the quality manual to include "...a description of the interaction between the processes of the quality management system." Other process diagrams might be useful at the procedure or work instruction stage, but to answer your question, no, it's not cecessary to create a new level in the pyramid.

Thanks.

I have just revised the norm and I noticed that process is just one more document like:

procedures.
Bussines plan.
customer requirements.

Therefor need to be trated as Document.

any structure of documentation your management would like.

Javier, you can stop using the 'pyramid shown in QS-9000 if you'd like - many folks have. You can structure your qms as a top level process map with sub-processes and procedures for the 7 requirements of TS and use WI's for other controls. Just about any combination is applicable. But please be careful what you choose. Just like a building, choose your 'architecture' carefully, because you have to 'build' and 'maintain' it;)

Andy

In the last ISO TS 16949:2000 the pyramid was still active but in the version of 2002 dissappeared.

In this norm, Only two kind of papers, the pyramid now is flatter:

1) Documents and its procedure.

Manual, Procedure, WI, even map process and more documents

2) Register and its procedure

Dear Mr Javier Rubio Barragán.

In my understanding , Most organizations prefers to have the structure like this.

1) Quality Manual

2) Process Maps

3) Work instructions/ Standard operating instructions

4) Formats & Records.

Organizations point of view , this is easier to understand and practice.

Thanks
Raghuramesh

Dear Mr Javier Rubio Barragán.

In my understanding , Most organizations prefers to have the structure like this.

1) Quality Manual

2) Process Maps

3) Work instructions/ Standard operating instructions

4) Formats & Records.

Organizations point of view , this is easier to understand and practice.

Thanks
Raghuramesh
Certainly this is true in my case. We use this same structure. It is very useful especially where our 'transition' to process orientation is not yet complete to be able the describe the functional interactions and responsibilities in the instructions.
Definately easier to understand for the process practitioners.

Ian

I concur with earlier replies. Here's my "vision" of the Operating System Documentation.

Patricia

Patricia.
I like the visual a lot but
I think that standards and customer requirements are above the Quality Manual.
If as you say they are inputs, I agree, then they must be at the top

Hi Howard,

I appreciate your response. From my perspective, the document structure in my schematic represents the architecture of the Operating System Documentation, and has nothing to do with "superior/inferior, high-level or low-level" documents.

If that were the case, a record like the customer's Purchase Order might also be considered a "high-level" document, when in reality, it is a record, albeit an important one...Similarly, the ISO/TS 16949, ISO 14001, Sarbanes-Oxley, Legal and Regulatory, Health and Safety requirements, etc., while indisputably important, are viewed as reference documents which impact in varying degrees on the architecture of the Operating System. Their assigned level is not a reflection of their stature.

Patricia

Hi Howard,

I appreciate your response. From my perspective, the document structure in my schematic represents the architecture of the Operating System Documentation, and has nothing to do with "superior/inferior, high-level or low-level" documents.

If that were the case, a record like the customer's Purchase Order might also be considered a "high-level" document, when in reality, it is a record, albeit an important one...Similarly, the ISO/TS 16949, ISO 14001, Sarbanes-Oxley, Legal and Regulatory, Health and Safety requirements, etc., while indisputably important, are viewed as reference documents which impact in varying degrees on the architecture of the Operating System. Their assigned level is not a reflection of their stature.

Patricia

Did Canada adopt Sarbanes-Oxely for public companies?
Our company is public, but not in the USA, so compliance is not applicable.

Hi Ralph,
I believe Sarbanes-Oxley (SOX) remains a mandatory requirement of publicly owned U.S. corporations only. I added it as a reference in my earlier post because I work in both Canada and the U.S., and many of the companies that I work for have divisions in both countries, and while not obligatory, these companies strive to consistently apply the SOX requirements throughout their organizations on both sides of the border. I create a singular integrated Management Operating Systems that captures the requirements of all the standards to which they subscribe (ISO/TS 16949, ISO 9000, ISO 14001, SOX, Customer-specific requirements, Health and Safety, Legal and Regulatory...and so on.)

Post script (I found this quick summary after my initial post)...

The Sarbanes-Oxley Act was signed into law on 30th July 2002, and introduced highly significant legislative changes to financial practice and corporate governance regulation. It introduced stringent new rules with the stated objective: "to protect investors by improving the accuracy and reliability of corporate disclosures made pursuant to the securities laws".
It also introduced a number of deadlines, the prime ones being:
- Most public companies must meet the financial reporting and certification mandates for any end of year financial statements filed after November 15th 2004 (amended from June 15th).
- smaller companies and foreign companies must meet these mandates for any statements filed after 15th July 2005 (amended from April 15th).

The act is actually named after its main architects, Senator Paul Sarbanes and Representative Michael Oxley, and of course followed a series of very high profile scandals, such as Enron. It is also intended to "deter and punish corporate and accounting fraud and corruption, ensure justice for wrongdoers, and protect the interests of workers and shareholders" (Quote: President Bush).

But things are always changing...someone else might know something that I'm not aware of...

Patricia

Patricia,
You are to be commended to combine all the required systems into one management system. I think we should combine TS16949 and ISO14001, but the president wants them separate because the ISO14001 coordinator also handles all the safety, and legal requirements. I handle TS6949 plus now 3 Customer Specific Requirements, and document control for the entire facility.

You have been foreward planning to anticipate the current and future requirements. Good work:agree1:

Thanks Ralph,

Now that I've integrated all the requirements into one system, I can't imagine managing them any other way. The requirements of ISO 9000, ISO 14001 and other ISO standards, customer specifics, etc., are all intertwined, and managing separate systems is very redundant and labor-intensive - PLUS, there's a huge disconnect between the systems. It's also easier to update documents when they're all in one system. You can still have individual Management Reps who are the watch-dogs for their particular areas...

Good luck in convincing management to change their stand.

Patricia

Hi Howard,

I appreciate your response. From my perspective, the document structure in my schematic represents the architecture of the Operating System Documentation, and has nothing to do with "superior/inferior, high-level or low-level" documents.
Patricia

I understand your thinking but I think that this is maybe misleading to the normal staff at a facility.
In "normal" life their is a hierarchy of requirements from National , state, municipal laws and every one is aware of this.
It is the same in the quality field, your organisation could cause misthinking by those who are not aware of the subtlety of the "architecture of control". For example those who think that in an internal audit the requirements of the standard are not audited rather the actions according to the companies procedure.
Whilst in your mind position does not show importance can this not in fact cause implementation problems?

PS
Where do you position drawings and specifications, are they level 3 WI or Level 5 Records and references?

Howard wrote:
I understand your thinking but I think that this is maybe misleading to the normal staff at a facility.
In "normal" life their is a hierarchy of requirements from National , state, municipal laws and every one is aware of this.
It is the same in the quality field, your organisation could cause misthinking by those who are not aware of the subtlety of the "architecture of control". For example those who think that in an internal audit the requirements of the standard are not audited rather the actions according to the companies procedure.
Whilst in your mind position does not show importance can this not in fact cause implementation problems?
PS
Where do you position drawings and specifications, are they level 3 WI or Level 5 Records and references?
__________________
Reply:
Question 1: It hasn't caused problems so far...probably because most people don't have a vision of the document architecture, so what I introduce is the only frame of reference they have.

Question 2: Drawings and Specifications are Records. Records are classified as internally or externally generated, and controlled or uncontrolled. Drawings and specifications are "Controlled" records, i.e., they are subject to possible review and revision.

Patricia