Opinion: Should the AIAG Be in the FMEA Software Business?

AIAG move could spell damage to auto industry and AIAG members

Published: Thursday, January 10, 2019 - 12:03

On Oct. 13, 2018, the Automotive Industry Action Group (AIAG) sponsored a webinar on the status of the AIAG Core Tools Software (AIAG CTS). John Cachat, AIAG project manager for the AIAG CTS project, was the presenter for the webinar. The presentation provided information on why the AIAG was developing the AIAG CTS as well as the current status of the software’s development. After attending the webinar, I found myself asking the question, “Should the AIAG be in the FMEA software business?”

The purpose of this column is to explain why I ask the question and then to answer it. Up front, let me be clear that I have a vested interest in this topic as someone who has devoted their life to the improvement of the use of FMEAs as effective risk management tools, the owner of a company who sells software that will compete with the AIAG CTS, and as a member of the AIAG. This column will examine several key issues, including why I believe the AIAG-VDA FMEA Handbook European committee members’ allegiance to existing VDA FMEA software and the AIAG decision to become a seller of VDA FMEA-based software has led to the creation of an FMEA handbook that, if implemented, will severely increase implementation time while seriously degrading the effectiveness of FMEAs in the North American automotive industry. The article will also investigate the impact of the combination of the AIAG’s auto industry influence and the announced intent to drive AIAG CTS pricing far below existing market levels on the Core-Tools software market. Finally, the AIAG-Microsoft Automotive partnership will be examined for the impact it will likely have on existing AIAG members.

AIAG’s reason for developing the AIAG CTS

The first 10 minutes of the webinar were used to provide the AIAG’s reason for developing the AIAG CTS. Topics covered were who the AIAG CTS was created for and issues when using Excel to implement the Core Tools (e.g., DFMEA, PFMEA, control plans).

When explaining the reason behind the AIAG CTS, Cachat stated that the “AIAG is developing a new Core-Tools forms solution to replace the 15-year-old Core Tools CD, and the goal is to help small suppliers with a strong, multi-platform SAS or cloud tool to manage these activities in a global automotive project environment. The AIAG CTS tool is a very specific tool solution. It is focused on taking the old spreadsheet on the CD ROM, doing that same functionality just a little bit better.”

The number of automotive suppliers currently using Excel for Core Tools implementation is considerable. According to the March 17, 2017, AIAG CTS announcement, “as much as 75 percent of automotive suppliers use Excel-based approaches to complete and manage their Core Tools-related document authoring and release.” Given the volume of automotive suppliers using Excel, it is obvious that small suppliers are not the only target users of the AIAG CTS, which will be discussed later.

When explaining why the AIAG CTS was being developed, Cachat added, “They [AIAG] started the assessment when the AIAG and VDA started to look at the new Core Tools manual, and with an understanding that all the Core Tool books will be updated within the next few years.”

Issues using Excel to implement Core Tools

Section 1.5—“FMEAs for products and processes” of the proposed AIAG-VDA FMEA Handbook contains the following statement in bolded print: “When products and processes are complex, it is recommended that specialized software be used to apply the FMEA method.”

Very few automotive suppliers will meet the requirement of having products and processes that are simple enough to implement the proposed handbook FMEA methodology using Excel. Cachat spoke of a “transition period” to allow companies to move from the AIAG’s fourth-edition FMEA methodology to what’s recommended in the AIAG-VDA FMEA Handbook. Once the transition period is up, the vast majority of the 75 percent of automotive suppliers currently using Excel will, essentially, be forced to purchase the “specialized software” the handbook talks about and that AIAG is about to begin selling.

Cachat pointed out several issues when using Excel to implement the Core Tools. When it comes to implementing the proposed handbook FMEA methodology using Excel, the showstopper is “big data.” When performing a design failure mode effects analysis (DFMEA), the existing VDA FMEA software that drives the FMEA methodology contained within the handbook requires that a DFMEA be constructed for the complete product as well as every subassembly and component of the product covered by the scope of the DFMEA.

An Excel worksheet is required for each DFMEA. The multiple product, subassembly, and component DFMEA worksheets must also be linked. The single DFMEA required by the AIAG’s fourth-edition FMEA methodology, which could be created using a single Excel worksheet, is replaced by multiple, linked DFMEAs requiring multiple, linked Excel worksheets whose quantity is determined by the number of sub-assemblies and components. A single product like a gearbox can require well over 100 linked DFMEA Excel worksheets due to the number of subassemblies and components the gearbox contains

Cachat also presented IATF 16949 audit result data in an attempt to show how the use of Excel was leading to improper construction of control plans: “To put this in context, if you look at the IATF 16949 major and minor audit result findings, control plans—which have been around forever with these Core Tools and manuals—are still on the list, with more than 400 major findings and 6,000 minor findings with respect to control plans,” he said. “Mostly those errors came from keeping, and attempting to keep, the process flow from the PFMEA and the control plan all synchronized, where sometimes in Excel, I can change something, but it does not always update everything.”

However, during the past 28 years of helping companies implement PFMEAs and process control plans, I have found that the most common and damaging mistake made when constructing control plans is the improper definition of process controls, and not the mismatch between the PFMEA process flow and control plan process flow that Cachat described.

Process controls, also known as “prevention controls” are used to prevent the causes of defects. The primary cause of improper process control definition is the entry of non-root causes in the “Failure Cause” column of the PFMEA. The bad news about the PFMEA methodology found in the proposed AIAG-VDA FMEA Handbook is that it leads to the entry of non-root causes in the Failure Cause column of the PFMEA a large portion of the time. The example “Machine stops before reaching final position (to less force)” provided as an example of a failure cause on page 84 of the proposed handbook is a perfect example of this problem. If one assumes the AIAG CTS will be programmed to be compliant with the new handbook, there could be a significant decline in the quality of control plans in the automotive industry, assuming the AIAG CTS becomes widely used among companies currently using Excel. Companies will find themselves being guided by the AIAG CTS to enter non-root causes in the PFMEA Failure Cause column. thus making it very difficult to properly identify the process controls necessary for strong process control plans, and more important, to prevent defects.

Microsoft and AIAG partnership

During the webinar, Cachat announced a partnership between AIAG and Microsoft Automotive: “We are also very happy to announce at the Quality Summit, partnership with Microsoft Automotive,” he said. “The Microsoft Automotive team has been very helpful with our developers in coming up with solutions to some of the performance issues and some of the design issues we were having. The expanded collaboration between AIAG and Microsoft will bring to the AIAG CTS project technical expertise, marketing support, and experience with deploying and supporting a global, multilingual cloud application across multiple Azure hosting centers. The idea was we don’t want a global solution only to be hosted in Michigan or in the United States when we have, again on this event, over 50 countries logging in. We would like to have local hosting centers and local response time.”

Clearly, the AIAG vision for the AIAG CTS is much larger than “taking the old spreadsheet on the CD ROM, doing that same functionality just a little bit better,” and its target market is not just small suppliers.

AIAG CTS pricing

Cachat made the following comments during the webinar that provide insight into the planned AIAG CTS pricing strategy:

“Pricing has not been announced yet,” he said. “I will tell you this. The directions I got from the AIAG executive team was to drive it as low as possible. This is an AIAG global improvement effort. We are not concerned about profit. I can share with you this. Right now we think it will be $30 per concurrent user per month. We are trying to get it lower. For those used to ‘named user’ pricing, depending on what ratio you use, if it were ‘named user’ that would be $3 to $10 per user.”

If implemented, this pricing strategy will severely impact existing pricing throughout the world automotive Core-Tools software industry. It should significantly increase AIAG’s ability to gain market share rapidly while making it difficult for existing FMEA software providers to compete.

It is interesting that the AIAG presents the cost savings due to the extremely low AIAG CTS pricing structure as a tremendous benefit to the automotive supplier. Once the “transition period” discussed earlier is over and the automotive suppliers are required to use the AIAG-VDA FMEA Handbook methodology, it’s my belief that they will experience increases in required time and subsequent labor costs due to inefficiencies and the complexity of the new FMEA methodology. Small to medium-size companies will most likely consume the yearly savings from the low AIAG CTS cost in one or two FMEAs. The product and process failure related cost impact due to the creation of the less effective DFMEAs and PFMEAs produced by the new FMEA methodology is impossible to quantify.

AIAG quality standards and CTS design requirements relationship

Although it was not part of the AIAG CTS webinar, it is important to consider the relationship between AIAG publications such as the proposed FMEA handbook and their impact on FMEA software design requirements when attempting to answer the question, “Should the AIAG be in the FMEA software business?”

Despite disclaimers such as, “The manual does not define requirements” found in the foreword of AIAG’s fourth-edition FMEA manual, the automotive supplier perception of AIAG publications is considerably different. On the AIAG Wikipedia page we find the following:

“The AIAG publishes automotive industry standards and offers educational conferences and training to its members, including the advanced product quality planning (APQP) and production part approval process (PPAP) quality standards. These documents have become a de facto quality standard in North America that must be complied with by all Tier I suppliers.[4] Increasingly, these suppliers are now requiring complete compliance from their suppliers,[5] so that many Tier II and III automotive suppliers now also comply.”

AIAG Core-Tool publication content determines automotive industry Core-Tool software design requirements. The close to 75 percent of all automotive suppliers currently using Excel that will be looking for “specialized software” if the current AIAG-VDA FMEA Handbook FMEA methodology is adopted is proof of this power.

Negative impact of software on proposed AIAG-VDA FMEA Handbook quality

The implementation of FMEAs has a tremendous financial impact on every automotive supplier that uses them. Properly implementing FMEAs is the cornerstone of automotive suppliers being able to successfully implement the “risk-based thinking” required by IATF 16949:2016 as well as reaping the benefits this methodology provides. Due to time and resources, the cost of FMEA implementation can be significant. If implemented and used correctly, the benefits of FMEAs will dwarf the implementation costs.

When the AIAG and VDA develop a handbook to capture FMEA implementation best practices, they must never forget the important role FMEAs play. The two trade groups must ensure that the needs of the automotive supplier community they service are put above those of the VDA, AIAG, and members of the committee who are creating the handbook. This can be difficult to accomplish given the considerable previous investments the committee members’ companies have previously made to implement the FMEA methodology they are currently using. The entry of the AIAG as an FMEA software supplier raises additional issues when protecting the needs of the automotive supplier community over the creators of the FMEA handbook.

In response to “The Case Against the AIAG-VDA DFMEA,” an article detailing the weaknesses of the proposed AIAG-VDA FMEA Handbook DFMEA methodology that I wrote last year for Quality Digest, Mike Bucala from Daimler Trucks North America and a member of the AIAG-VDA FMEA Handbook committee wrote:

“Your article concludes that the team should have started with (Excel-based) AIAG fourth-edition methods, and (by inference) expected the Europeans to modify their software-based methods to conform to it. This in an unrealistic expectation.”

Clearly, the VDA members of the AIAG-VDA FMEA Handbook committee refuse to give up the investment they have in their VDA FMEA software.

Historically, the AIAG was not affected by the contents of the FMEA manual it created. A new FMEA manual would lead to short-term increases in FMEA manual and FMEA training sales for the AIAG, regardless of the content. But AIAG’s decision to sell FMEA software changes everything. Given that the handbook in the form put out for public comment would force up to 75 percent of the automotive industries suppliers to purchase “specialized” FMEA software—and the AIAG would most likely be the first place for them to go for the software due to the AIAG and VDA owning the handbook—the AIAG is positioned to rapidly become the top-selling FMEA software in the world.

The influence of software on the contents of the proposed AIAG-VDA FMEA Handbook is undeniable. Given all of the weaknesses of the proposed FMEA methodology contained within the handbook due to limitations placed on it by requiring compliance with the functionality of existing VDA FMEA software, there should be no illusion that the handbook contains “best in class” FMEA practices. With the strong influence of software on its content, perhaps a more appropriate name for the document at this time would the “AIAG-VDA VDA FMEA Software Handbook.” The purpose of the handbook would be to explain how software packages function that implement the VDA FMEA methodology.

Should AIAG sell products that compete with members’ products?

There is a moral question that must also be considered when evaluating whether the AIAG should be selling FMEA software: Is it appropriate for a trade organization to develop products that compete with member products and then offer them at cost when its members currently selling similar products need to sell at a profit to survive?”

Suppose the AIAG announced that, after talking to members about their needs, it had developed a new bearing design that would significantly reduce bearing development costs. Also suppose the announcement stated the AIAG had arranged for manufacturing of the bearings throughout the world and would begin selling the new bearings at cost because the AIAG is nonprofit. It would obviously benefit the members who would be buying the bearings. But what impact would the new bearings, sold at cost, have on the businesses of members who are selling bearings? What would the automotive industry response be?

During the webinar, Cachat stated that the AIAG and Microsoft Automotive “share the common vision of providing the global automotive supply chain with better, faster, lower-cost solutions to support the rapid development of new products in the automotive supply chain.” This is definitely beyond the AIAG’s traditional role of offering publications, training, and certifications designed to advance continuous improvement in business practices, encourage collaboration, and provide global resolutions to industry issues.

Given the breadth of AIAG member types and the products and services they provide, it is easy to see how some members will likely be exposed to financial harm when new products are introduced by the AIAG-Microsoft Automotive partnership for the benefit of other members. One must wonder how the AIAG is going to determine which AIAG members are to be preferred over other members when selecting new products for development and sale? Will membership in the project teams to create the new products be internally selected and their identities kept private, as is the case with the AIAG CTS project, or will project participation for new product development be open to all members of the AIAG and their identification publicly known, as is the case with the six active projects currently on the AIAG listed website? The “new AIAG” and its Microsoft Automotive partnership creates many questions.

Conclusion

Due to the fact that any meaningful change to the proposed AIAG-VDA handbook contents would require significant software changes to existing VDA software and the AIAG CTS, it is unlikely that these changes are going to happen. Consequently, I expect that the AIAG and VDA are not going to ask for public comment on the revisions they made to the handbook as the result of the 3,500 comments they received on the first draft. Given the impact the handbook will have on the profitability of automotive suppliers, I believe they have the right to see and comment on the revised handbook before it is adopted. If you are an automotive supplier, I would encourage you to contact the AIAG and make known your desire to review the document before adoption.

I hope you now understand why, after attending the AIAG CTS webinar and hearing the AIAG CTS project plans, I found myself asking the question “Should the AIAG be in the FMEA software business?” I believe the answer is no.

Full disclosure

As I said at the beginning, I have a vested interest in this topic. I am president of Harpco Systems. Although our Quality Plus Risk Based PLM software supports the rapid and effective implementation of the Core Tools, it does not use the VDA software-driven FMEA methodology documented in the current 2012 VDA FMEA manual and the proposed handbook because of the weaknesses that have been noted above. Since we have automotive industry customers that will have to comply with the handbook if adopted, we are currently working on adding features to our software that will allow our customers to meet the handbook output format requirements. It will do this while generating the content for the output using our software’s more powerful and efficient FMEA methodology.

None of that invalidates the arguments outlined above. I believe that AIAG’s decision to sell FMEA software is bad for automakers and suppliers and, yes, unfair to the many software producers that sell into this industry.

About The Author

Richard Harpster

Richard Harpster is president of Harpco Systems, which he founded in 1987. Harpco Systems specializes in providing software, training, and consulting for risked-based product lifecycle management (RBPLM). During the past 30 years, Harpster has helped hundreds of companies implement improved risk-based design and manufacturing systems in a wide variety of industries. He is a recognized expert in the application of FMEAs and has invented several new concepts, including the linking of design FMEAs to process FMEAs in 1990, which became an automotive industry standard 18 years later. His latest inventions in the field of RBPLM include Requirements Risk Assessment (RRA), Usage Risk Assessment (URA), Multiple Integrated Cause Analysis (MICA), and Rapid Integrated Problem Solving (RIPS). He has published several papers on the topic of RBPLM.