One of the underlying factors contributing to the existing database being largely ignored was the portal itself.
Problem: Our client’s quality personnel speculated that it might be too complicated to use easily, and because the design engineers were rushed for time (being behind the industry average put considerable pressure on them to work faster and better), many of the design engineers simply skipped this step entirely when starting a new design. The quality personnel investigated whether a more streamlined and simplified system could be used. The difficulty with this proposed solution was the age of the databases accessed by the portal; some of them were too old to be transferred to a new, fully integrated database. Incompatibility of the data formats was also an issue.
Action: A request was submitted to the IT department to research the cost and resources needed to redesign the database. They determined that three of the six databases accessed by the portal wouldn’t be able to migrate to a new database, so these data would be lost if this project was implemented.
Recommendation: Develop a new database or portal access, and input data to the new system as information becomes available; migrate data manually as new designs and revisions are developed. For the short term, because we didn’t want to lose momentum or support for this project, we suggested that a simple Microsoft Office Access database be used that would have searchable tags. This would provide the engineers with an interim database that could then migrate to the new solution. Each entry could be given multiple tags as necessary to identify the design characteristics. This allowed users to enter search queries based on key criteria. The example in figure 1 below has four tags, although more would be attached in working models. The figure also shows how this table can be used in different industries.
This database could then be expanded to capture additional action information, such as the action proposed and taken, the person responsible for the action, due dates, milestones, and closure results.
Until a new system could be developed, populated, and implemented, the current system had to be used.
Problem: We needed to encourage design engineers to use the database by developing examples of searches and search strings that would make the database search easier, faster, and more focused. This would also encourage standardization of tags to use when searching; these could also be used when creating the entries, as illustrated in figure 1.
Action: Write simple scripts for portal searches, including the most frequent search strings, anticipated and unanticipated results, and how to refine the search to eliminate the latter. Provide training and reference materials to design engineers and managers. Develop standardized search tags and make these available in a drop-down menu format to standardize and facilitate lessons learned data entry.
Recommendation: Solicit design engineers and managers for suggestions to include as lessons learned tags. At key checkpoints, provide feedback to managers and engineers about how they can use the lessons learned database to eliminate rework. This would highlight early improvements to garner buy-in throughout the organization.
We needed to train personnel to use the database during the design phase.
Problem: In the past, the same errors showed up in redesigns despite being documented in the lessons learned database.
Action: We emphasized with engineers that reviewing the lessons learned database wasn’t time-consuming busywork but rather a valuable tool to prevent redesign. We emphasized that the earlier a design flaw or error was identified, the less money and time it took to correct. This could improve both their turnaround time and final design costs. This approach appears to be working well because we’re seeing better database entries. To keep them informed and motivated to participate, we translated this into language appealing to management: project schedule compression, improved customer satisfaction, and lower design costs.
Recommendation: The lead engineer in each particular subsystem should review the lessons learned database for entry completeness prior to final acceptance. Because these gurus would understand not only the major points but also the more subtle implications of design flaws or errors, we thought they could then tag the data appropriately to ensure that a keyword search would give the expected result.
In addition, we asked managers to require a lessons learned database review as part of the formal design review. We also suggested that they require a review of lessons learned database entries as part of the project closure.
The long-term results of this case study are yet to be determined, but the short-term results show that acceptance and use of the lessons learned database are growing. As data become more complete and useful, we expect this usage to grow until it becomes a standard operating procedure for all new designs.
Like all processes, CAPAs must be reviewed for efficiency and effectiveness. In this case, the lessons learned database wasn’t being used effectively, which led to efficiency losses. By focusing your organization on continual improvement, you can identify nonvalue-added work, and either streamline it to make it more effective and efficient, or eliminate it.
If you have trouble identifying where a problem lies, take the time to look at your CAPA process as well as the process itself. You may be surprised at what you find.
