Back

Increasing sales, revenues, profits, customer satisfaction, robustness, and security – and a decreasing number of recalls. This is still a dream for many automakers, but for Toyota it's already reality. At the heart of Toyota's success is a culture of respect and responsibility that pervades all of the company's processes, but there is also a method called DRBFM.

A look at the Western quality scene reveals a certain helplessness with respect to the current difficulties in automotive manufacture. Sure, everyone thinks he knows how to solve the problems, what the right methods are, and who should be held responsible for the problems. But few are willing to really address the problems and make them their own. Western managers have long since recognized Toyota's strengths. The somewhat odd result is that a sign that reads "Be Toyota" in big letters now hangs in the design engineers' offices at one of the biggest Western automakers. But integration into the organization from above, strictly governed by the rhythms of the processes, time pressures, competition, managers, employees, production, and the enormous pressure to innovate is hardly likely to bring about the adoption of Eastern development philosophies. Toyota, on the other hand, is coping with the very same conditions just fine.

European developers usually want to take full responsibility for their work, too. But first they would have to receive – or give themselves – permission to identify. Therefore, the question is how to encourage such identification while bearing in mind that integration is necessary. Certainly not by simply creating new symbols, slogans, and doctrines, which are, ultimately, just more organizational fiction. Paradoxically, the decisive factor for identifying with one's own work and, thus, for actively taking responsibility, is inextricably linked with the way in which the individual is integrated into the group – with whether he or she feels like a wheel that's being turned or a wheel that's turning itself.

Three is a charm
The philosophy behind the DRBFM method is called GD3 (Figure l), which stands for Good Design, Good Discussion, and Good Dissection. Good Design, or robust design, is paramount within the philosophy. Good Design is achieved by following two rules:

• Use as many proven, robust components as possible.
• Actively seek out hidden "buds" of problems.

The first thing that is needed is a central system of variant management or knowledge about how variants are available. By using this knowledge productively, one can determine where responsibility for variants lies and what a variant in the target design can do. Thus, the developer can decide whether or not a variant is able to take on a specific role within his design. Second, attention must be focused specifically on those points where problems like to put forth buds. The following formula can help developers:

• Create a complete requirement analysis.
• Derive the design from the requirements step by step.
• Have interdisciplinary teams work on finding the solution.
• Establish particular attention to the interfaces.
• Ensure that as many robust components as possible are reused.

Robust Design through variant management
Best Practice for Good Design, particularly with respect to the first four points above, has been described in the technical literature [1]. The last point can be achieved with active, global, knowledge-based variant management using the SCIO support software from Plato. Good Discussion is based largely on the Design Review Based on Failure Modes (DRBFM) method. Good Dissection is based largely on the Design Review Based on Test Results (DRBTR) method.
DRBFM is a creativity method that accompanies the development process. It is also a philosophy of discourse-oriented design development and design evaluation. The method ensures that products maintain their high level of quality after changes are made. DRBFM evolved from the realization that changes entail the highest failure potential, regardless of whether the changes are due to cost considerations, innovation pressures, or new requirements placed on products, systems, or processes. Finally, DRBFM complements and enhances Failure Mode and Effects Analysis (FMEA).
DRBFM is an integral part of Plato's comprehensive quality philosophy, Total Quality Engineering, and deeply rooted in the development process. DRBFM was largely derived from FMEA. Failure modes and information from existing FMEAs can be used in DRBFM.

Good Integration
Part of a developer's distress is that organizational constraints require him to distribute, procure, and create information – mostly for others and not themselves. And the tools that they use have not become any less complex along the way. On the contrary, the complexity of the tools continues to grow as the variety of the developer's tasks increases.
In order to escape this vicious cycle, software architectures have increasingly been converted to "services and database technology" in the past few years. This sounds nice and helpful, but underlying it is a simple formula: instead of providing a new tool for everything and everyone, standardized server components that handle special information-related tasks quietly in the background are offered for existing tools.

The software provider Plato has chosen to depict DRBFM in Excel with a strong connection to its DRBFM service and SCIO database (Figure 2). This is because Excel has become so widely used that it is not even thought of as software anymore. Excel is as much a part of the developer's work area as a pencil, a piece of graph paper, a Web browser, or a mail system.

Good Discussion
The connection to the central SCIO database helps ensure the continuity that the DRBFM method demands. Whether information comes from the areas of law, requirements analysis, function analysis, product structure, or process definition is unimportant. The integration into the central information hub SCIO ensures that all engineering aspects are taken into account. This gives the developer a tool that actively supplies him with information and with which he can work creatively. The DRBFM service takes care of everything else in the background, storing the information in the database, versioning the document and tracking its history, sending the document to the review team, and monitoring action deadlines. In this way, the developer's work is integrated into the organization; the developer is not subjected to additional obligations and can use DRBFM to coordinate his work with colleagues and stake-holders in a productive, meaningful way.

The central variant management system in SCIO supports the developer's efforts to equip robust design with robust components. The soft­ware monitors the use and creation of variants. Once the decision for a specific design has been made, the software starts a review process when changes occur and uses Excel to guide the developer securely through all stages of communication.
Of course, quality does not depend on method alone. It also depends on implementation within the organization. DRBFM is the method that integrates the quality process into the development process.

What is DRBFM?

Methods Design Review Based on Failure Modes is aimed at:

Guiding the design engineer securely, systematically, and creatively through all stages of a change process.
Achieving a robust design for a robust process in early design stages.
Involving production, purchasing, suppliers, and customers in decisions regarding the change process, in addition to the design engineers.
Actively integrating the design engineer in the quality process and, thus, lifting the separation between the quality process and the development process.

The method ensures that

• The focus is on changes.
• The focus of the development work only goes into the critical aspects of the product.
• The division of work between the design engineer and a review team leads to the effective implementation of changes, with verification and release of the results.

• Changes are not viewed in isolation but rather the links within the system or product are taken into account completely and systematically.
• The project leader is given an overview of the status of all changes in the project, which quickly shows him whether they were resolved, critical, or discarded and why.

Back