Super Designer Improving the Design Process

Two years ago, D.H. Brown Associates, Inc. (DHBA) published a detailed study on the findings from a survey of 105 respondents and over half a dozen in-depth discussions with our collaborative research partners on design and CAE trends. All the participants uniformly agreed that designers could not use the then current generation of CAE tools directly; nearly all agreed we had to give the designers a new set of tools. Specifically, we recommended the development and use of templates and wizards directly concentrating on a specific task or problem facing a designer. In short, we needed the CAE tools to target designer's needs in their specific domain; and we needed support from the analysts to mentor designers. We also needed new metrics for performance assessment. In a recent conference call organized and hosted by Don Brown, Greg Roth from Eaton, and James Crosheck from Deere share their lessons learned.

Greg Roth: Over the last few years, the industry has been pushing to get products out quicker to the market to meet the needs of customers before they change, and ahead of the competition. In the automotive industry, the platform development cycle has fallen from about 48 months in the 1980's, to around 24 months, and even less. That's a huge compression.

The methodology for achieving this has focused on using CAE up front in the design process. This basically gets rid of the traditional build and break cycle where components are designed, and then their prototypes are built, tested, failed, redesigned, and the cycle goes on.

In the process that I've piloted and implemented at Eaton, we have imbedded CAE for up front design early in the process. This is important because typically within the first 5 percent of a project, 85 percent of the time and costs are committed by the design decisions and selections made. That can become an expensive proposition if you select a design that does not perform as expected. In our process, we have built in safety checks, with everything flow charted and structured to be well understood and easy to follow. We also have the traditional CAE team and support that follows later in the cycle, but their job focuses on higher-levels of CAE analysis.

One of the key issues in implementing any process in industry right now is the "process du jour" problem. The industry sees so many new processes coming down, all with new buzz words, that people become skeptical as to the real benefits that may be achieved. So, any new process invites the comment, "Yeah, but what can it really do? Prove it."

Now we have results. Our approach reduced time and cost 30 to 50 percent in the design phase of the development process. The big improvement comes from the reduction in whole iterations. The focus now concentrates on achieving first pass success. If you reduce the number of design iterations from six to two, these metrics are quite achievable.

In terms of other measures, the return-on-investment (ROI) for such process improvements depend on the product development intensity. Developing a paper clip, for example, does not involve much intensity in the development process. Each iteration may not take much in resources, time and cost. A clutch housing, or a transmission, or a vehicle involves a lot of system dependencies and interrelationships. The preliminary numbers show over a five-year period, 12 to 24 percent ROI should be realized. But, the key is that the ROI depends on a reduction in the number of iterations encountered.

The major surprise in terms of metrics is related to the number of designs that can be evaluated. It may take four to five days in a traditional CAE environment for a particular product, say a clutch housing, for evaluation and analysis. We saw that cycle fall to about a quarter of a day. We are now able to see many more concepts in design feasibility studies in the same amount of time.

Don Brown: Are these changes easy for designers to accept?

Greg Roth: One of the major issues determining success in this whole process relates to the culture. We are suggesting a major change in how things are done, and cultural barriers can stop all progress. You can show all the metrics of success, but if people don't like to use it, they are not going to use it.

For example, in the past, designers worked with CAD and the CAE analysts did all the simulations, and engineers handled the engineering detail. In the new process, we are smearing those boundaries. Engineers now work with up-front CAD to develop concepts, and even do some analysis. Designers access analysis tools. Analysts no longer do the lower level simulations. Roles and job definitions change, a challenge in and of itself that impacts each individual's behavior.

But one of the biggest changes impacting culture relates to the "responsibility breakout." That is, designers may feel that the engineers are taking away some of their responsibility. CAE analysts may feel they've lost their charter. But, it turns out that the designers in fact gain more responsibility with these first order studies. Their responsibilities increase. Further, the analyst teams may now focus more on high-tech studies - contact, non-linearities, and product optimizations. Typically in the past, by comparison, they always focused on the first order stress effects or temperature effects of a particular design. The change frees their time and increases their overall responsibilities and value-added contribution.

Another issue that comes up in the culture is what I call "transparent benefits." Typically, a designer or engineer may take four or five iterations to develop a product. The new process won't require those iterations. You might do one, two or three and you basically saved the time and costs that would be associated with all those extra re-design and build cycles. But, when you're doing the process, you don't see that.

That benefit relates to the next item, which is the apparent efficiency loss. It may have taken a designer or engineer eight weeks to get a first drawing release out for prototype. But now they complete a virtual prove out of the concept up front, early. The new process takes a little longer to do the evaluation up front. To get the part out for a release, let's say it takes 12 weeks. The design manager in fact sees a decline in efficiency. He'll say, "Hey, typically people would be freed up within eight weeks, and now they take 12 to 14."

But, the transparent benefit kicks in. The designers typically worked on the same product through three or four iterations, but now only work it one or two times. Over the full development cycle, rather than considering each individual iteration, they're freed up much earlier to do other work. Ultimately, throughput increases and more product goes out. Whereas before it took a lot longer to get one product out, now development completes more products in the same amount of time. That helps increase market penetration in terms of getting more offerings out more quickly.

Don Brown: What are the keys to success?

Greg Roth: I found the keys to success for this type of process to be:

• Ease of use: relates to the software, the process itself, and everything that supports this effort.
  
  
• The time and training philosophy involves teaching people as necessary for what they need to know. We never offered a huge monolithic training regimen at the very beginning, because engineers and designers will typically forget everything that they've learned in a huge glob. We're giving them what they need to know as they need to know it.
  
  
• Web-based training programs, supported by Net meeting tools, enable designers and engineers to call in, and get mentoring from the CAE group as needed. The analysts can take control of their software and show them where the issues are a problem.
  
  
• The process itself has to become the way you do business. With a milestone or a management review, people have to ask, "Did you do your CAE studies, did you follow the process?"
  
  
• Flexibility improves when the process defines the way you do business. Designers and engineers don't have to do CAE on every single product. They do have to complete a risk assessment, and they have to get buy in from the CAE and the technical specialist. Everybody buys into that approach.
  
  
• Design filtering represents another focal point in the process. We don't expect the designers and the engineers, or the analysts for that matter, to actually get accurate results up front, early in the design. We simply want them to filter out poorly performing designs early and we don't expect 5 percent accuracy.
  
  
• Accountability becomes important in defining success for designs. In the past, designers and engineers felt that once a drawing of a part was released for prototyping, they were done. Now, we're requiring and expecting that the part passes the test and validation. The engineers and designers are responsible for the performance of the part.

By using these tools, engineers and designers increase their competency, and their contribution to product performance. Their morale rises because they understand the products much better.

As a final, quick point, implementation has got to be a "push pull." That is, you do have to have a mandate from management. But, everyone's got to look at the program and conclude, "This makes sense, this is really the way to do business." The grassroots approach, the ease of use, the training, all those steps I've just outlined make it much easier to implement. Making sure that everyone offers that simple conclusion represents the right way to do it.

Don Brown: Thank you Greg. The results are impressive. James Crosheck, you have had considerable success with templates for wheel designs at Deere and Company.

James Crosheck: We face the same issues that Greg just discussed. That is, we must squeeze down our design cycle time, just like everybody else.

We would like to take the lessons that we've learned, and the technology that we're using, and reuse both on a regular basis. Many of the designs that have been done once - and maybe twice - become relatively routine. We'd like to make it fully routine, with a much faster pace. Some form of template captures that process.

As an example, we set up templates analyzing wheel rims. Part of the problem relates to finding common design tasks across the various product lines. In this case, most of the pieces of equipment that we manufacture do in fact have wheels, tires, and wheel rims. The design task represents a wide enough range of design activity that the development effort to establish a template makes sense.

We had a process that was obviously scriptable. So, the idea was to create a template with an MSC scripting program that sits above the commercial software actually doing the work. The process pulls information out of Pro/E files, taking that into Patran, creating shell models, and then moving the models into Nastran to actually do the analysis.

The template solution now involves a half-hour to an hour of the designer's or analyst's time, as opposed to days or weeks before. That's a major improvement, so there's considerable attraction to extending the approach.

The difficulty remains that after all of the associated development expenses are totaled, we're looking at $100,000 to $250,000. It's not trivial to pull something like this together. We really have to have enough volume to be able to justify the effort. Moreover, once a template is created, maintenance issues come along every time one of the software vendors come out with a new release. Something usually breaks that requires maintenance.

We're really trying to pass that challenge and opportunity on to the vendors to make the whole effort of producing templates a lot easier and a lot faster. If I had my preference right now, I'd also like to see scripting tools that could be supported by us directly, as opposed to farming it out to a specialist. It should not require programmers who are specialists in the software involved, or specialists in writing C or C++. I'd like support of a higher level language. I'd like to target, let's say, two to four weeks of development time, which probably translates into $10,000 to $20,000 dollars, or even less.

Don Brown: How would the templates serve the needs of individual designers facing a specific problem?

James Crosheck: Obviously, we also want these templates to speak in the language or jargon that the designers use. We really don't want it to require a lot of extra input above and beyond the actual need to define the files from the CAD system, or the specific information that's relative to the particular problem under consideration.

The challenge on our side today relates to finding those common design tasks where we can define the process very cleanly. The first pass in a design obviously does not come up with a clean definition. The second time gets closer. But by the third pass, regardless of whether a designer or an analyst is involved, they start to get bored, and the task becomes pretty routine. Those kinds of tasks, after completion a number of times, or maybe a few more, are candidates. A template then eliminates some of the potential for errors, standardizes the process, and cuts the development time required.

The approach certainly opens up an opportunity to support a design-optimization process. It gets closer to a true synthesis, as distinct from the design analysis mode in a long term. That design mode is really trial and error, which is not a particularly effective way of developing new products.

Don Brown: Thank you, Greg and James, for sharing your experiences. These critical issues in simulation, as well as others across the whole spectrum of design and engineering, will be addressed at our annual conference, November 13-14 in Dearborn. Both Greg and James will be joining us, as well as several other major users that will share their experiences. While these teleconference calls are quite helpful, there is no substitute for the one-on-one discussion where we converse eyeball to eyeball. Please join us at the conference to network and share mutual experiences in wrestling with technology to work effectively for your organization. The symposium, which forms an integral part of our collaborative research programs, complements the research we have delivered throughout the year. We look forward to getting together November 13th and 14th. Thank you all.

Please see DHBA Events for details or visit our Web site at www.dhbrown.com.
Don Brown, dhbrown@dhbrown.com.