Problem Collecting In-Service Data (AS9100 Clause 7.5.1.4)

S

susburke

We are a small aerospace company certified to AS9100B that installs electrical/mechanical custom-made systems in "the field" at customer sites. Currently, our field technicians report any installation issues (of all types) to their manager via emails, who logs the issues and follows through to make sure they get corrected by the appropriate departments. We have found that we need to improve this process, as some problems don't get reported and then we hear complaints about the same problems happening over and over again in the field. Also, having one person be the only point of collection is a definite drawback. If anyone uses a system for this that is working well, or has any suggestions for improving this process, I would greatly appreciate it.
Thank you.
 
D

DrM2u

Re: Problem collecting in-service data (7.5.1.4)

We are a small aerospace company certified to AS9100B that installs electrical/mechanical custom-made systems in "the field" at customer sites. Currently, our field technicians report any installation issues (of all types) to their manager via emails, who logs the issues and follows through to make sure they get corrected by the appropriate departments. We have found that we need to improve this process, as some problems don't get reported and then we hear complaints about the same problems happening over and over again in the field. Also, having one person be the only point of collection is a definite drawback. If anyone uses a system for this that is working well, or has any suggestions for improving this process, I would greatly appreciate it.
Thank you.
There are a few ways to handle this and improve your process. I will try to present some options below for your thought:

- The least expensive and requiring the least amount of change method would be to implement a weekly team review of any new and/or open field problems/reports. The team does not have to be large and, by the same token, one is not a team. I suggest involving the ones who have some responsibility and authority to address the problem, and one person to coach the team through the problem solving process. You can increase or decrease the frequency as needed. The meetings do not have to be long, just a quick review of what's new, where you stand on the open issues, and are there any resources needed. The rest of the analysis can take place in smaller groups as an option.

- A slightly more expensive method is to implement some sort of a database or problem management system that will collect and centralize the field reports. This option involves some changes in your QMS and some learning from the users. There will still be discipline required to actually do something with all the opportunities.

- The most expensive alternative is to implement a QMS integration system that will cover everything, including your corrective actions system. Such systmes work nice because many have the ability to notify users of any new problems or the status of existing ones, even escalating notifications to upper management. Such systems are great for larger organization, do not come cheap and require some more extensive learning.
 

Wes Bucey

Prophet of Profit
Re: Problem collecting in-service data (7.5.1.4)

There are a few ways to handle this and improve your process. I will try to present some options below for your thought:

- The least expensive and requiring the least amount of change method would be to implement a weekly team review of any new and/or open field problems/reports. The team does not have to be large and, by the same token, one is not a team. I suggest involving the ones who have some responsibility and authority to address the problem, and one person to coach the team through the problem solving process. You can increase or decrease the frequency as needed. The meetings do not have to be long, just a quick review of what's new, where you stand on the open issues, and are there any resources needed. The rest of the analysis can take place in smaller groups as an option.

- A slightly more expensive method is to implement some sort of a database or problem management system that will collect and centralize the field reports. This option involves some changes in your QMS and some learning from the users. There will still be discipline required to actually do something with all the opportunities.

- The most expensive alternative is to implement a QMS integration system that will cover everything, including your corrective actions system. Such systmes work nice because many have the ability to notify users of any new problems or the status of existing ones, even escalating notifications to upper management. Such systems are great for larger organization, do not come cheap and require some more extensive learning.


these are good ideas, but it seems to me the primary issue you probably face is the field techs do not have sufficient grasp of the "big picture" to understand they are the first eyes and ears on any emerging problem and they have a responsibility to make a clear declarative report.

the secondary issue is the manager (or any designee) receiving those reports has a duty to acknowledge receipt and then follow through and refer them to the equivalent of an MRB or SRB (material or service review board), which in turn has a responsibility to investigate using all resources necessary to determine whether changes need to be implemented. Regardless of the outcome, it needs to be relayed back down to the original reporter so he knows his reports are taken seriously and not dropped into a circular file. Deming championed a System of Profound Knowledge (SoPK) - the SoPK starts with clear communication up AND down the hierarchy.
 
M

Mario Alberto83

Re: Problem collecting in-service data (7.5.1.4)

Good afternoon

I would like to know what the standard means with "in-service data". In this post I see in-service data is treated as issues during installation, however in other thread I have seen it as quality/reliability data during product performance in field. What is the scope of in-service data?

I believe this requierement will only apply when customer provides post delivery requirements in the PO (such as installation, maintenance/calibration, etc.). These requirements would be considered as an extension/part of the production process. In other words, the product production process does not conclude when it is delivered, but when it is installed/maintained/calibrated, as required.

Am I correct?

Thanks in advance for your comments
 

Sidney Vianna

Post Responsibly
Leader
Admin
From the AS9100 Auditor Guide document:

In service data contains of statistical information on the use and reliability of parts and components, such as:
• Mean Time Between Failure (MTBF)
• Mean Time Between Unscheduled Removal (MTBUR)
• unexpected shut-off and similar information*.

This information is coming from the operators, and/or maintenance organizations, but also as ‘incident/accident’ information from Aviation Authorities or Safety organizations. It is recommended that analysis could include comparison of the data with the design specification on the reliability criteria for these parts and components, but also on study and tests (e.g., on failure causes linked with the design specifications)

The actions linked with these are aimed to inform the customers on possible problem. If an organization has a Design Organization Approval (DOA), this could result in service bulletins, design changes or modified technical documentation
 
Top Bottom