Knowledge Capture and Retention in FEA

Editor’s Note: Tony Abbey teaches live NAFEMS FEA classes in the U.S., Europe and Asia. He also teaches NAFEMS e-learning classes globally. Contact [email protected] for details.

Many companies are concerned with retaining the knowledge and experience that analysts possess and that is inherent in both their day-to-day and long-term tasks. This is not a new phenomenon—I remember very similar worries when I joined the aircraft industry 40 years ago. The concern then was associated with the transition from traditional manual stressing techniques to the newfangled finite element analysis (FEA) methodologies.

It is sobering to reflect that those old concerns about stressing knowledge transfer are still ongoing. Many aerospace companies struggle to map conventional techniques to new FEA approaches in a physically meaningful and cost-effective way.

I was discussing knowledge and experience loss with senior managers at a major U.S. government research agency. They have many older analysts who are deeply immersed in FEA, with all its structural and physical implications. These staff members are reaching retirement and disappearing fast. Conversely, the agency has many new graduates with very little experience yet. To plug this gap and support ongoing work, the agency uses many contractors, whose average age is around 55. This exacerbates the problem of knowledge transfer between the new intake and the old guard. The contractors are often engaged for short periods, and hence will not settle in and act as mentors to the new staff. The challenge at the agency is how to capture the knowledge from the contractors.

Company Memory or Organizational Knowledge

There is a tendency to think of a company as a living, breathing entity that will naturally retain, develop and enhance its own range of knowledge and processes. This reflects the way an individual engineer matures over the years. Sadly, this analogy is flawed. Knowledge and experience can leak out of a company’s collective “soul.” I saw this firsthand some years ago when teaching an optimization class to a group of engineers. Two of the attendees were from a company I worked for in the 1970s. One was the current expert in that area. The company had been one of the leaders in structural optimization development, with several noted pioneers. It quickly became clear that the knowledge and aspirations from 20 years previously had become diluted.

As design engineers with a wealth of experience retire, they often take that knowledge with them.
Illustration by Steve Abbey.

There is wide literature on this topic: Company knowledge is often described as organizational and is assumed to stem from the combined knowledge of different groups or communities within that company. In the world of FEA, knowledge was often held by specific individuals who may not have considered themselves part of the community. In today’s connected and interacting ethos, individual knowledge is a natural contribution to the sum total of company knowledge.

The analogy of the company as a living entity has another interesting aspect. Individuals develop most skills through failure. Negative results matter significantly in human development. I was startled to learn that bone development is basically a battle between a continual purging and building process. The process reacts to external stimuli such as gravity, biomechanical loading actions and other environmental inputs. Corporate culture tends to reject failure and disguise or ignore it. There is a danger that, with any knowledge retention approach, emphasis will be placed on successful results. The skeletons in the cupboard are actually very important. Equally, a safe and trusted knowledge base may inhibit exploration of new methodologies.

The Full Story

The emphasis so far has been on retaining knowledge in a company. However, the full knowledge management process involves learning, capture, retention and dissemination of that knowledge. This is the path for an individual and hence by extension to communities and the organization. Last-minute capturing is an unfortunate consequence of not anticipating a drastic skill shortage. It also means that there are probably unrealistic demands on solutions to retain and disseminate the knowledge captured from leavers. The knowledge is not inherent in the organization any more; it is an abstraction to be reabsorbed. So perhaps consider the full story when planning knowledge capture and retention. Learning processes, either formal external courses, or informal on the job, could form part of the knowledge management.

Knowledge Transfer Inhibitors

Knowledge transfer from contractors has always been a thorny issue. A positive desire to pass on experience to the younger generation is far from the norm. Sharing this knowledge with others is viewed as undermining value to the organization. I have seen contractors putting barely sufficient information into reports to specifically avoid providing knowledge of methodologies.

This can also occur when using external consultants, who may avoid describing methodologies in the FEA report. I have seen initial public offering claimed on the basis that the methodology is a trade secret. It is difficult to reconcile this. A consulting house may have taken many years to develop special methodologies and be reluctant to share. However, it is difficult to see how deep-level verification can be done without full disclosure of the methods used.

A good company lawyer will write a contract to require a consultant to release sufficient information to have a proper and full verification. A reasonable nondisclosure agreement should help to offset concerns. If the consultant decides that too much intellectual property is at risk, then that contract can be declined.

A few years ago, I saw a great example of how a prime contractor can take a positive attitude toward knowledge transfer using consultants. I gave a three-day in-house dynamics course at SpaceX. There was some methodology inherent in the training, but it was primarily aimed at effective use of the software. After two days, the young engineers had fully explored the process and interface. The last day became a technology transfer session as we sat down to expand on the methodologies and see how they could be implemented at SpaceX. This was in the very early days for the company. Instead of being able to use a NASA specification for a random loading environment, with a standard PSD (power spectral density) spectrum, they had to develop their own. As questions arose, we went straight to the guys responsible for live launch data to see how it was obtained and processed. I brainstormed a methodology to synthesize a PSD spectrum that formed the basis for their process.

It was a very heady experience, and the key was that the young engineers, empowered by their CEO, saw it as their role to explore and develop these new methodologies. I met two ex-colleagues at SpaceX. It turned out that they were not there for the duration; their mandate was to transfer the knowledge to the younger engineers around them over a 12- to 18-month period.

It was a refreshing approach, as the experienced guys understood their dual role. They were there to carry out the groundwork, develop methodologies and pass everything on to the next generation. I assume that these older engineers were well paid for their work.

Formal Knowledge Management

What formal ways can be used to achieve knowledge management?

Knowledge management processes within a company can be defined and documented. On an ongoing basis, experienced engineers describe directly or through an interrogatory interview, what their processes and best practices are. This could be a broad overview of the FEA process. Or it could be specific methodologies, such as simulating bolting connections, modeling of equivalent small-scale damage and initial imperfections on buckling, and so on. This forms the basis of a company methodology and experience database. There are many other forms of knowledge capture, including surveys, brainstorming sessions, etc.

It is important to start this type of activity now and not wait for a critical exodus to trigger it. The process can be subtly blended into the full-knowledge learning and retention practices. I am a believer in peer reviews of FE analyses. An informal review at the start of an FE project, where the analyst describes objectives and methodologies to members of the team is useful. Experienced and inexperienced members can sit in. Processes discussed during the review are captured and documented to form part of the knowledge database. At the end of the analysis, prior to formal reporting, a more in-depth peer review can take place. Lessons learned and mistakes made en route to a successful conclusion can all be documented as a formal corporate knowledge, but the inexperienced engineers also have absorbed this directly. The social interaction involved in peer reviews is typical of the modern understanding of the importance of community. All the social networking tools that are underpinning our society can be used in some form or another.

If hemorrhaging of experienced staff has gone too far, then companies could use the SpaceX approach of using external consultants with dual tasking to move projects forward and at the same time build experience levels in full-time staff. On a smaller scale, a company could include expert consultants in internal peer reviews of FEA. The consultant is briefed to provide a full and open discussion on the various aspects of methodology occurring during the review of the FEA project. It is then the responsibility of the team members to make sure that that the dialogue is captured and documented.

Implementing the Knowledge Base

Building the captured documentation into a company knowledge base will vary from informal approaches to sophisticated IT solutions. The key to any implementation will be acceptance by all, which means a minimally invasive and demonstrably productive solution.

An IT solution will tend to focus on tangible assets. There is a danger that it will become just a document collection. It should form part of the ongoing analysis management process and be able to incorporate the informal and human aspects. Easier said than done, it will be a major challenge in any successful knowledge management implementation.

Many years ago, I attempted to develop an automated FEA debugging process within my analysis group. It was a strictly logic-based approach that assumed any problem would have a mechanistic solution. It was not a great success because it failed totally to capture any real experience or rationale. You have probably had similar experiences with call centers that operate from scripts.

Templating Knowledge Transfer and Retention

A popular way of defining best practices is to establish a template using specific CAD or analysis software. An experienced analyst will define the steps required to set up and run an FEA model. The steps are parameterized in a template form. This means less experienced engineers do not have to set the problem up from scratch, but instead are guided through a focused subset or analogy of the original software steps.

I recently saw an example in the automotive industry where the analysis of a range of connector rods in a suspension system could be carried out parametrically. A high-level menu overrode the usual detailed menus. The high-level menu drove a series of scripts or macros that carried out detailed work. Engineering judgment on loading and boundary conditions was enforced by limits on values and location. Warnings for inappropriate selections were built in. This tool was aimed at designers producing variants of the connector rods. It enabled them to focus on the design and carry out precautionary analysis with confidence.

There is a danger with this approach. If the understanding of the methodology behind the templating is lost, the process is at risk. The process becomes a black box. Nobody knows what it does in detail, but it forms a core part of the analysis process and cannot be changed. It can become very expensive to re-engineer and re-architect the process.

One of the requirements of templating or a macro should be a user-friendly interface, which avoids opaque programming languages that rapidly become obsolete. Instead, it should be possible to reverse engineer a transparent process. Perhaps more importantly, the physics or engineering behind the process should be fully documented and understood.

The auto industry example also highlighted another limitation. It was time-consuming to define the template and it was limited in the range of configurations it could deal with. If designers continuously want to push the envelope and explore significantly different solutions, the template creators are unable to provide the tools in time.

The Future

I imagine at some point there will be a migration toward a pure machine learning environment for learning, capture, retention and dissemination. Some form of artificial intelligence will be embodied in FEA solvers that will allow the capture of the objectives, setup, methodology and results of many thousands of analyses within a company. Engineers can then carry out variations within these analyses and be confidently guided through the process. A much bigger challenge is to develop a system that could advise on new forms of analyses outside of the scope of the learning provided. That is a scary thought.