AIAG recently announced the creation of a Core Tools Forms Software project. The second Voice of the Customer Survey was sent out, and the results show a strong international interest in a cloud-based application to complete several very technical forms related to product and process development (FMEA, Control Plan), measurement system capability evaluation (MSA), and product release (PPAP) that are part of the Advanced Product Quality Planning (APQP) process.
The intended customer base for this project is T2 and smaller organizations that do not need, and/or cannot afford, the larger PLM or QMS applications. These T2 and smaller companies may have only one or two people working on the documentation versus large, multi-site teams. Several common themes emerged, including: flexibility, customizable, project task tracker, linkages between forms, and robust security of proprietary data on a web app.
The second VOC Survey, titled “It Would Be Great if...,” asked for input to each key section of the AIAG Core Tools: APQP/Control Plan, PPAP, FMEA, and MSA (SPC is out of scope). Thank you to all the respondents for their input.
Here are some of the thoughts on making the new AIAG Core Tool Software app the best. NOTE: Not all the ideas from the survey will be incorporated into the Minimum Viable Product (MVP) or the first release of the app.
Q: In a Core Tools software package that encompasses APQP, PPAP, Process Flow, FMEA, Control Plan, MSA, and a project (or product launch) tracker, what would be the top 3 items that would make it extremely useful to you?
Several responses focused on standardization across the automotive supply chain, including OEMs and T1 forms, which is of course a great goal, but outside the scope of this project. The alternative, making the application flexible enough to support the myriad of OEM and T1 Customer Specific Requirements, is in scope. The results also indicated that the variation across T1 documents is significant and costing the automotive supply chain money.
Others repeated the need for linkage across all the forms, yet maintaining flexibility. This is one of the most difficult criteria as the team tries to design “an Excel-like front end with a database backend,” including helping, but not forcing, on the linkages. The mantra is “Make it easy and do not force me to do things.”
The project team has created the following linkage diagram to help guide this effort.
Q: Specifically, in an APQP module, what would you find useful?
The most common input was the addition of a checklist or a simple project management/task management process with flexibility to customize the task list. The need for a simple timeline with assignments and due dates was common across multiple respondents. Similar thoughts about industry standardization were mentioned, or at least the ability to work with customer specific forms/formats without it just becoming an extra step in the process.
Another idea was for the development phase; it would be nice to have tracking for open items that need to be completed. Many times in a development phase, several prints and models are constantly changing. Controls would be needed to ensure that everyone working on the project is referencing the correct and current models/prints. These controls would continue to be useful after the project has launched to track engineering changes and tool replacements. The ability to include risk management in the process was discussed.
Q: Specifically, in a PPAP module, what would you find useful?
Like APQP, PPAP input also included the addition of a checklist or a simple project management/task management process with flexibility to customize. In addition, PPAP needs a robust submission, review, and approval process that several companies are trying to manage in email. The ability to modify document requirements based on customer specifics was repeated, e.g., “If the system is too restrictive to allow case-by-case customization, it becomes more of a burden than a help.”
Q: Specifically, in a Process Flow module, what would you find useful?
The idea of shared or common/reusable process flow across multiple products was mentioned. The ability to have a library of symbols to allow users to match the symbol to the customer requirement was repeated several times.
The ability to import process flows from other apps such as Visio was also mentioned, but the technical issues and effectiveness of importing is questionable. It seemed that an app that starts with a Process Flow and uses the information to drive other forms is important to all. However, the consistent flow steps with PFMEA and Control Plan are being reviewed as to when a process may change due to adding/removing a step, as well as whether the change is automatic and forced or if a human is asked to decide what to update.
Some people suggested it would be nice to be able to identify waste in the process and track process improvements from eliminating waste to support Value Stream Mapping.
Q: Specifically, in a FMEA module, what would you find useful?
A high priority is incorporating the new AIAG VDA FMEA manual that is under development, including the ability to sort by all methods of evaluating level of risk (RPN, SO, SOD, SD, or other).
T2 and smaller companies may or may not have design authority, and therefore may or may not have access to DFMEA information. The ability to share DFMEA information across the supply chain was mentioned.
The ability for creation of “generic” or PFMEA templates that contain reusable, or shared, process information across multiple parts was repeated several times. The ability to have changes made to PFMEAs automatically update across part numbers so each one does not have to be updated individually is under review, trying to make it easier, but not force updates. The challenge is determining what the computer does automatically and what decisions should be made by a human.
The ability to use the “right side” of the FMEA forms with action-item tracking and a lessons-learned database was suggested. Others stressed the need for a robust reporting capability to allow companies to look at and analyze several FMEAs for Top 10 RPN, etc.
Finally, a reusable list of information to assure consistent data entry is being defined, including: Potential Failure Modes Text, Potential Effects of Failure Modes Text, Potential Cause of Failure Text, Current Process Controls Prevention, Current Process Controls Detection, Control Methods, Tools/Gage Types, Sample Size, and Frequency.
Q: Specifically, in a Control Plan module, what would you find useful?
One person suggested the ability to allow for three “flavors” of Control Plan to be created: Prototype, Pre-Launch, and Production. The population of one document should “read-across” to the other two flavors. Special controls that are put in place for Prototype and Pre-Launch can be manually added to their respective documents.
Several respondents identified a concern about how control plans and operator instructions are created and maintained. This included concerns about what is “auditable by the customer” versus internal, non-auditable information needed by manufacturing.
The application of Dynamic Control Plan (DCP), or the blend of the Process Failure Modes Effects Analysis (PFMEA) and Control Plan (CP), was suggested.
Q: Specifically, in a MSA module, what would you find useful?
The management of MSA by a device type, versus for every specific device, was stated. In addition, it was recommended that the application should be able to decide which type of MSA study should be used versus making the user decide which approach is applicable to the MSA study being performed.
A few people requested the ability to automatically send data from measurement devices into the study, or perhaps the ability to import from Excel. At a minimum, printable data collection sheets are needed.
NOTE: A full calibration system is out of scope.
Q: Specifically, in a project (or product launch) tracking module, what would you find useful?
Previous research has indicated that APQP and PPAP checklists are being used across the automotive supply chain, yet this is not part of the former AIAG Core Tools Form Disc. This question specifically asked for input for a “simple, low cost, project management” functionality. T2s and smaller companies are not looking for MS Project-like capability, as MS Project is very involved, made for those who relish the finer details, and expensive.
Other suggestions include: a calendar view, task due-date reporting with email reminders, and again an approval process, as the task is not “done” until the approval is received.
Q: If I could get reports like this, my job would be much easier.
This question was asked because reporting is not part of the former AIAG Core Tools Form Disc. All respondents stated reporting is very important, especially the type of reports that cannot be done across multiple stand-alone spreadsheets.
Some of the suggested reports suggested include:
- Project Status Report Summary (internal and customer views)
- Due and Past-Due Action Items
- My To-Do List (automatically email daily real time reports)
- Exception Reporting
- Part Number List
- Part Number Detail (including product and process requirements)
- Change Requests Status
- Create PPAP Submission Packet
A common theme was “Don't put in defined reports or formats. Allow ad-hoc reporting based on needs. The industry does not stay fixed long enough to utilize a fixed report. The requirements will change before you get it coded.”
Q: Do you have any other suggestions, thoughts, or ideas you would like to share regarding the next generation AIAG Core Tools software project?
Several times, across multiple questions, the need for better training on all the AIAG core tools was mentioned. The creation and use of small video snippets was mentioned quite often. There were some thoughts to expand the scope into LPA, CAR/PAR forms, 8D, 5WHY, etc., but as of now, these are out of scope.
Supporting multi-languages was also mentioned as well as the ability to run on a variety of devices (phone, tablets, PCs) and across multiple browsers (IE, Edge, Chrome, Firefox).
“Stay focused on T2 and below market – It seems that tools are often designed with the OEM in mind, which makes multiple tools needed for suppliers. Try creating one tool for suppliers that generates what the OEMs / T1s want without the extra hassle/cost/time.”
“I cannot stress the importance of flexibility too much. All tier 1 and tier 2 companies deal with an infinite number of different processes and submission requirements. These documents are not only for submission to customers and the OEMs; these are mainly used as process control mechanisms within each organization.”
If you have any thoughts or ideas on this project, please contact John Cachat at firstname.lastname@example.org.