The Elsmar Cove Wiki More Free Files The Elsmar Cove Forums Discussion Thread Index Post Attachments Listing Failure Modes Services and Solutions to Problems Elsmar cove Forums Main Page Elsmar Cove Home Page
Google
  Web Elsmar.com
*Please be aware that SOME RECENT forum threads may not yet be indexed by Google.

View Full Version : Understanding IS/TS 16949 - Employee Awareness Training .ppt powerpoint presentation


Laurie Wright
10th April 2007, 12:12 PM
Does anyone have a presentation that can be used for Employees to help them understand what IS/TS 16949 is and how it affects them and their jobs?

Jennifer Kirley
10th April 2007, 12:16 PM
Welcome to The Cove Laurie!

I'm going to make this a little harder on you than you may have wanted.

First thing I will do is ask you to do a search of TS 16949 training using the Search tool in the tool bar above. I did a search of the attachments and found this page (http://elsmar.com/Forums/fileslist.php?mode=allfiles&sortby=&pageamt=2&fid=&page=54) for you.

Second thing I will do is point out that you, not we, can best know how to describe to your company's people how TS affects them and their jobs. This will vary according to the types and depths of controls you (and they) already have in place, and the company's culture because some of the TS requirements may seem confining to, shall we say, a free spirit.

You can alter one of the presentations to suit your needs.

Marc
10th April 2007, 12:43 PM
Does anyone have a presentation that can be used for Employees to help them understand what IS/TS 16949 is and how it affects them and their jobs?

If you're looking for a generic type of presentation, while I'm not sure there are any for TS 16949 here, I know there are some for ISO 9001. It would be easy to tailor an ISO 9001 presentation to TS 16949.

For all intents and purposes, TS 16949 affects employees like ISO 9001 does - Very little if you come down to it. Employees are going to be doing essentially the same jobs as before because typically ISO 9001 implementation and registration does not tell a company HOW to run their business. The standards do require certain systems (and to a lesser extent minimum documentation), but other than that the biggest effect of ISO 9001 or TS 16949 is that, if there weren't audits before, there will be now.

I do understand your position, as I did implementations for years and the first thing was to explain to employees what ISO 9001 (or TS 16949) was and how it would affect them. Employees hear about "this new program" the company is introducing and are curious. I don't think it's as common these days as it used to be, but that is in large part because, I think, ISO 9001 (more than TS 16949 admittedly) is now pretty well known. Many employment advertisements today (and have for years) cited a knowledge of, or work experience in, an ISO 9001 registered company.

I've attached a couple of old files I have, but take a few moments and visit the files attached to posts listing (http://elsmar.com/Forums/fileslist.php) as well as the free files directory (http://elsmar.com/pdf_files/) here.

Laurie Wright
10th April 2007, 12:45 PM
Thank You Mark! Perfect!:)

Icy Mountain
10th April 2007, 01:15 PM
Allow me to humbly recommend the TS16949-2002AWARENESScove.ppt that Marc posted (it must be the best because I wrote it :rolleyes: ). It's got a lot of mileage on it since I have used this since 1989, at 2 different companies. It started with ISO 9000:1994 version and has been updated to include 2000 and then 16949. There is some input required on your part. YOU must make this real to your company by going through the presentation and pointing out where and how each of these sections are going to impact the specific departments or teams in your organization.

Helmut Jilling
10th April 2007, 06:54 PM
Allow me to humbly recommend the TS16949-2002AWARENESScove.ppt that Marc posted (it must be the best because I wrote it :rolleyes: ). It's got a lot of mileage on it since I have used this since 1989, at 2 different companies. It started with ISO 9000:1994 version and has been updated to include 2000 and then 16949. There is some input required on your part. YOU must make this real to your company by going through the presentation and pointing out where and how each of these sections are going to impact the specific departments or teams in your organization.


Icy, haven't reviewed yet, but since it is vintage, I wanted to remind the readers that TS requires a process approach. This was not understood back in 1999.

Marc
10th April 2007, 07:31 PM
Icy, haven't reviewed yet, but since it is vintage, I wanted to remind the readers that TS requires a process approach. This was not understood back in 1999.

Good point, and that can be lightly discussed, but for the most part as far as those out on the floor are concerned they will be doing the same job they always were doing. How in depth one goes in an over view 'training session' for floor level, and some other departmental level, employees depends upon how many people you want to get involved in 'process approach' 'training'. The farthest I ever went with it was at Harley where we taught all the managers at York how to flow chart and made them flow chart their processes, procedures, etc.

I remember when I used to do implementations throughout the 1990's I had a standard "What does this mean to you?" aspect I went through. Most of it was how to handle auditors (such as "never lie to an auditor"), and that they had to know their job duties, they had to know what they were trained to do (as well as all training they had gone through), they had to know what paperwork (procedures, forms, etc.) was applicable to their job and stuff like that. But for most of the individuals, even had the process approach been a popular phrase (let's get real - most companies used process approach whether they recognized it or not) back then, I probably wouldn't have mentioned it.

On the other hand, when I did implementations, even back in 1991, I used flow charts to lay out procedures and systems, although I didn't convince a company to redo it's documentation in flow charts until 1994. Using flow charts, we were using a process approach. We defined the flow of each process as well as interactions between departments/processes and such. Being a biologist by education, this all made perfect sense to me and it did to my clients as well. I used to call it a 'systems' approach.

Marc
10th April 2007, 07:40 PM
Allow me to humbly recommend the TS16949-2002AWARENESScove.ppt that Marc posted (it must be the best because I wrote it :rolleyes: ).

You probably have the same file posted with a thread here somewhere already. I was in a hurry and just did a quickie search on my local machine hard drive and found these and uploaded them to feed Laurie something fast.

Credit and :thanks: to Icy.

Helmut Jilling
10th April 2007, 11:38 PM
Good point, and that can be lightly discussed, but for the most part as far as those out on the floor are concerned they will be doing the same job they always were doing. How in depth one goes in an over view 'training session' for floor level, and some other departmental level, employees depends upon how many people you want to get involved in 'process approach' 'training'. The farthest I ever went with it was at Harley where we taught all the managers at York how to flow chart and made them flow chart their processes, procedures, etc.

I remember when I used to do implementations throughout the 1990's I had a standard "What does this mean to you?" aspect I went through. Most of it was how to handle auditors (such as "never lie to an auditor"), and that they had to know their job duties, they had to know what they were trained to do (as well as all training they had gone through), they had to know what paperwork (procedures, forms, etc.) was applicable to their job and stuff like that. But for most of the individuals, even had the process approach been a popular phrase (let's get real - most companies used process approach whether they recognized it or not) back then, I probably wouldn't have mentioned it.

On the other hand, when I did implementations, even back in 1991, I used flow charts to lay out procedures and systems, although I didn't convince a company to redo it's documentation in flow charts until 1994. Using flow charts, we were using a process approach. We defined the flow of each process as well as interactions between departments/processes and such. Being a biologist by education, this all made perfect sense to me and it did to my clients as well. I used to call it a 'systems' approach.


Yes, you're right. On the floor, the "process approach is pretty transparent. That method of thinking becomes important as you move up the org chart. I do want operators to understand the concept of internal customers, and meeting those needs, some of the basic process approach concepts.

I also agree ISO did not invent the process approach. Progressive companies (and many experienced auditors and consultants) were already working in that mode. I like to say ISO recognized that and merely caught up to changing trend.

Laurie Wright
11th April 2007, 08:58 AM
Thanks for all the responses! It has been a huge help! :)

Icy Mountain
11th April 2007, 01:12 PM
You probably have the same file posted with a thread here somewhere already. I was in a hurry and just did a quickie search on my local machine hard drive and found these and uploaded them to feed Laurie something fast.

Credit and :thanks: to Icy.You are welcome, I was going to post the thread until I saw you already had the file up. The original thread is at this link (http://elsmar.com/Forums/showthread.php?p=168687) and provides some pretty good reading. BTW, I didn't post this to swell my ego. I had multiple request via PM.

@hjilling: note that this has been updated to include ISO/TS 16949:2002. Depending on the audience I might not get into the esoteric discussion of the infamous "process approach". For example, my production teams only want concrete stuff about "What does this mean to me?" Example from the slide on Section 4.1 as presented to the production teams:

Establish, document, implement, maintain, and continually improve a QMS
Icy: We are going to have a Quality Manual, and a formal system, all of the teams will be involved in the development and operation of the system.
Identify the processes needed for QMS
Icy: I'm going to meet with every team so that we can develop a process map for your team. We'll get into the detail then but each on of your teams is a process.
Determine sequence and interaction of processes
Icy: We're going to go through our chain of customers again and make sure it's up-to-date and that everyone understands it.
Determine criteria and methods to ensure operation and control of processes
Icy: Most of this is already done and represented by the metrics on your team scoreboards.
Ensure availability of information to support operation and monitoring of processes
Icy: What I said before.
Measure, monitor, analyze and implement action to achieve results and continual improvement
Icy: We already do this but we are going to start capturing our "Initiatives" in a database to make sure we don't forget anything and so we can take credit for all of the Continuous Improvements that the teams are already implementing.

Since I am relating each line to something they already know, everyone gets more comfortable with the big, scary ISO standard and starts to realize that we're just going to put some formal documentation and feedback in place to assure that things don't "fall through the cracks."

judy simidi
16th July 2008, 03:19 AM
Hi Icy,

i have to agree, your presentation is the best detailed one av seen in a while.

:thanks: