A Review of the 2018 ASQ CRE Body of Knowledge
I just noticed the new 2018 ASQ CRE Body of Knowledge had been posted on the ASQ site. The new BoK will be in effect for CRE exams as of January 2018. Thus, we have six months to adjust to the new body of knowledge.
This is part 1 of a multipart review of the new BoK. Here we’ll look at the parts that those preparing for the exam will not have to master or review. There are 10+ topics dropped completely or in part from the BoK.
In future articles, we’ll review what has been added, what has been changed (a review), and how to best prepare for exams based on the new BoK. Plus, we can look over past BoK’s to understand where reliability engineering practice is today.
In part, the logic is these sets of tools (topics) that are not widely used by working reliability engineers. In some cases, I agree, and in others, I don’t. Let’s look at the eight topics not found in the upcoming CRE BoK.
I. A. 6. Warranty management
It appears the general topic of warranty management is gone, which is fine. There is a growing industry around warranty management, including policies, reverse logistics, and extended and 3rd party warranties. A portion of the topic remains as warranty data often contains a wealth of information about past product performance, failure criteria, and use conditions. Thus you may still want to connect to the warranty information in your organization.
I. A. 7. Customer needs assessment
Since this has been interpreted as the cumbersome quality functional deployment (house of quality) tool, removing QFD is fine. Yet, as reliability engineers, we need to understand reliability-related customer needs. Often the voice of the customer work is done by marketing or other groups and not by reliability engineers. Yet, we should work with our teams to fully gather and understand our customer reliability needs.
Areas of this topic related to design prototyping have been kept under other areas on the BoK, yet it seems the idea that we need to gather and understand the voice of the customer is missing. That is not good, IMHO.
II. A. 4. Poisson process models
Since these tools tended to focus on the use of MTBF, good riddance. We can and should do better than rely on tools that use such a poor measure.
II. A. 5. Non-parametric statistical methods
This one has me puzzled. The tools of mean cumulative plotting (MCF) and Kaplan-Meier life data analysis are classic and very useful non-parametric methods. The tools here also permit comparing rank data, non-normal data, etc. The topic is now under III. A. 1. Basic statistics, which is unlikely to receive the same attention as under its listed topic.
III. A. 6. Tolerance and worst-case analyses
What? Really? This is a set of tools that bring together the design implementation for reliability as related to the process capability of the manufacturing processes. Variability and lack of robustness kill products. This should have remained a part of the BoK.
If you are a serious reliability professional, you know the importance of working to create a robust, reliable design solution. Well, this is largely accomplished by establishing tolerances for items critical to the reliability performance of the product that balance functionality with manufacturability. I’ll keep talking about tolerance analysis and highly recommend you understand and work with your team to implement tolerances that improve product reliability performance.
III. A. 12. Reliability apportionment (allocation) techniques
While I disagreed with the allocation techniques commonly cited, the ability to break down the system reliability goal into subsystems and major components is a vital function of reliability engineering. Again, I’m afraid I have to disagree with the removal of apportionment techniques and urge you to keep practicing allocation of reliability goals.
III. B. 3. Parts obsolescence management
For products that enjoy a long functional life and sales period, the need to maintain functionality while maintaining or improving reliability is adversely impacted by parts obsolescence. It happens, and it happens even for relatively short live products. By not including the topic, we are avoiding the necessary discussion around the skills to select parts and manage obsolescence while protecting product reliability. This should have stayed a part of the body of knowledge.
IV. A. 5. Dynamic reliability
This always struck me as a workaround to deal with changing failure rates when one is using MTBF. Good riddance.
V. B. 2. Discovery testing
Guess discovery as a term didn’t catch on as a replacement and apt name for HALT. We are trying to discover weaknesses and not pass a test. Oh well. HALT is mentioned under testing, so that concept is not gone.
V. C. 2. Product reliability acceptance testing
It seems that we’re not doing acceptance or demonstration testing anymore. In some industries, this remains a critical activity. The actual test planning and techniques may have different names, but the concept here is useful to understand. I’m ok with the drop, yet not with the loss of the concept, at least at a definition understanding level.
V. C. 3. Ongoing reliability testing
Seems the CRE BoK is moving further away from involvement with manufacturing variability (tolerance analysis being dropped, for example). ORT is one way to monitor variability and the impact on reliability performance. In some situations, there are no upstream means to detect adverse changes to reliability performance. ORT requires a different approach to sampling and testing than used during development, thus, should remain in the BoK.
V. C. 5. Attribute testing
The entire testing topic has been gutted, it seems. This area remains a key element of most reliability professionals I know and work with. Sure, when possible, we should test and collect variables data, yet at times we are limited to attributes and should know when and how to apply these tools.
VI. A. 1. Planning
This referee to maintenance planning. It is an essential role to prepare for preventative maintenance activities. While reliability engineers rarely are planners, understanding reliability (working with reliability engineers) is an essential factor for successful maintenance planning.
VI. B. 3. Non-destructive evaluation
I enjoy destructive testing, yet I have always started with non-destructive testing. A valuable skill when exploring new material, assessing new component suppliers, or conducting failure analysis, is the ability to use the appropriate evaluation tools to learn as much as possible before implementing a solution. NDE and destructive testing methods should remain featured in the body of knowledge. We must understand the range of tools available as we peer about and into our products.
VII. A. 3. Data Management
Maybe the concepts in this topic are just too common. Not specific to reliability engineering. We all have to deal with data, often too much data. The topic has been removed and subsumed in the new topics under III. B. Data Management, which does not call out managing data specifically.
I.A. 4. Reliability in product and process development now does not include the concepts of concurrent engineering, corporate improvement, and lean. The emphasis is not on six sigma methodologies. This is unfortunate as lean and concurrent engineering are excellent ways to influence designs and processes to improve reliability performance.
I. A. 5. Failure consequence and liability management now does not include liability management and are partially included in the new BoK under I. B. 2. Drivers of reliability requirements and targets and II. C. Mitigation. Depending on your industry, this may be a big deal or not. This, along with the deemphasis on the voice of the customer, is unfortunate.
III. A. 5. Fault tree analysis (FTA) and success tree analysis (STA) now does not include success tree analysis. I’m ok with this one.
III. B. 2. Derating methods and principles have limited the derating concept to only selecting materials and components. Derating impacts reliability performance. Derating is not taught in school for election engineers. This should have remained a major topic and expanded. It is an essential role that we often have to teach and monitor as our reliability engineers work to implement derating.
IV. A. 4. Simulation techniques now is mostly covered in IV> C. 5. Reliability prediction methods and do not include Markov models. Markov models, probabilistic risk assessment, and Petri Nets are specialty tools for high-available critical systems. Organizations that need those models typically hire someone full-time to build and manage the models. We should be aware the models exist along with a basic understanding of when and why they are useful, though. Not just drop them.
I know the CRE BoK review process involves a lot of people across many industries. I participated during the update for the 2007 CRE BoK, so I understand the process is comprehensive and difficult.
In future articles, I’ll talk about the additions, new organization of topics, and the changes in Bloom’s Taxonomy Levels for various topics. The changes are around the edges, and the overall trends will be the subject of yet another review article.
I agree with a few removals and do not with a few. You may have a different opinion on what a reliability engineer should be expected to understand and do, which is fine. Let me know your thoughts in the comments section. What is your take on the topics removed?
Anup Hegde says
I noticed that Hypothesis testing (II.B.5 -CRE BOK 2009) is left out in CRE 2018. You didnt mention that in here.
Or am I missing something?
Fred Schenkelberg says
if you mean II.B.3. Hypothesis testing, it is now part of III.A.1. Basic Statistic and the comment in the map from BOK 2009 to 2018 reads, “The 2018 BOK includes this topic in area III.A.1 by stating ‘and compute and interpret their values’.”
While hypothesis testing in not called out by name it is still part of the body of knowledge we are expected to master and use.
Anup Hegde says
Thank You very much for the reply Fred.
I recently ordered the CRE Primer 2018 from Qimpro, but the Hypothesis testing (compute and interpret their values) is missing in it except for a definition. Have asked Qimpro the same.