Your reason codes should be pertinent to your products & processes: So, as an outsider I'd ask "What do you make" (and what do your customers consider to be the value added quality elements of those products)?
If I know that, I'd then be asking what processes (internal and vendor) are involved?, How reliable are they?, When they fail - how do they typically fail?
Do you processes lend themselves to real time SPC? (Examples:
Textile wovens
multi-axis CNC machining
welding & heat treating
finishing processes (paint, plate,anodixe, vulcanize, etc.)
Do your process & products lend themselves well to re-balanceable lean assemble to order processes? If you regularly assemble products only to have to tear them down (too often) to 'repair' something that could have been detected or prevented in step A or B with better designed and tooled steps (A or B of an A-Z process), you know what your reason codes are - Set them up in a way that drives reporting that will benefit you.
Ex: If the primary root cause is lack of good torque control drivers - Make it a reason code so the resulting stats help you justify investing in better tools (or changing to less sensitive fasteners).
People like to talk 'widgets' but GOOD QA processes are very specific to what you really make and do (and are imbedded in the company culture if codified correctly, continuous improvement efforts are rewarded and ALL (CEO to the garbage man) employees are truly given the same mission to improve things and eliminate waste.
Knowing (much) more detail about your business model & key processes would help in getting useful recommendations from the forum.
Rob Brown
If I know that, I'd then be asking what processes (internal and vendor) are involved?, How reliable are they?, When they fail - how do they typically fail?
Do you processes lend themselves to real time SPC? (Examples:
Textile wovens
multi-axis CNC machining
welding & heat treating
finishing processes (paint, plate,anodixe, vulcanize, etc.)
Do your process & products lend themselves well to re-balanceable lean assemble to order processes? If you regularly assemble products only to have to tear them down (too often) to 'repair' something that could have been detected or prevented in step A or B with better designed and tooled steps (A or B of an A-Z process), you know what your reason codes are - Set them up in a way that drives reporting that will benefit you.
Ex: If the primary root cause is lack of good torque control drivers - Make it a reason code so the resulting stats help you justify investing in better tools (or changing to less sensitive fasteners).
People like to talk 'widgets' but GOOD QA processes are very specific to what you really make and do (and are imbedded in the company culture if codified correctly, continuous improvement efforts are rewarded and ALL (CEO to the garbage man) employees are truly given the same mission to improve things and eliminate waste.
Knowing (much) more detail about your business model & key processes would help in getting useful recommendations from the forum.
Rob Brown
--- On Mon, 7/14/08, darryl_d_hall <dhall@...> wrote:
From: darryl_d_hall <dhall@...>
Subject: [Vantage] Reason Codes for Quality Assurance Module
To: vantage@yahoogroups.com
Date: Monday, July 14, 2008, 5:41 PM
We are getting ready to install the Quality Assurance module in Vantage
8.03.404A.
Is anyone in this forum currently running this module. And if so, are
you able to offer any advice regarding the establishment of reason
codes for corrective actions and DMRs? Examples would be especially
appreciated.
Thank you,
Darryl