Regular

posted 25 May 2007 in Volume 10 Issue 8

Case report: General Motors

Changing gear

General Motors combines BP, LO, KM, DFSS. With all those acronyms, what’s not to like?

By Jerry Ash

There’s lots of knowledge work going on at General Motors (GM) these days, but you’ll not find a generic, company-wide initiative based on any of a growing number of knowledge management (KM) formulas for facilitating tacit knowledge sharing across the enterprise. Instead, you will find it in multiple functional areas, applied in targeted and innovative ways to improve already accepted business practices – some of them believed by KM thought leaders to be contrary to, incompatible with, or only one part of the practice of KM.

IK readers have seen this rub in our previous reports about KM and the learning organisation and, more recently, Six Sigma. Now we find GM’s product engineers subtly mixing KM with best practices (BP), a technique for capturing tacit knowledge. This has been largely ignored by the KM community as a ‘failed strategy’ for achieving some of the mutual goals sought by both BP and KM:

Knowledge sharing;
Converting tacit knowledge to explicit;
Back to tacit again; and,
Putting knowledge to work.

The case against best practices

This has not been as much a philosophical issue as it has been practical. Critics of BP complain that trying to codify tacit knowledge results in a limited database driven by the answers, not the questions – supply, not demand.

Answers usually come from the results of completed team projects. They are retrospective and often written hastily by a single author who was unlucky enough to be stuck with the add-on reporting duty at the end of a project. Critics argue that the reports are generally cursory, tainted by the point of view of the single author, or biased towards successes, not failures – they present the good, only sometimes the bad, but rarely the ugly. The goal of the BP writer has generally been to make the team look good.

Among KMers, the argument goes that documented knowledge (information) is static, of limited value and has a short shelf life. Best-practice databases, it is said, gather dust because users find plenty of ‘stuff’ but rarely relevant answers to specific needs or problems.

KM proposes an alternative by facilitating a more dynamic human-to-human flow of always-up-to-date tacit knowledge. The facilitators are communities of practice, networks, expert locaters, yellow pages and so on – connecting people to people. In this case, explicit knowledge is the by-product. GM sees its situation differently.

While working on a new business model starting in early 2000, GM research uncovered six systemic issues. The lack of a comprehensive set of documented product engineering solutions was identified as part of one of the six. GM had plenty of tacit knowledge but not enough explicit. And because of the lack of an organised knowledge transfer process (tacit to explicit), engineers worldwide were lacking access to hidden knowledge of common interest across the company’s product engineers. After all, GM is a company with 327,000 employees that manufactures cars and trucks in 33 countries; easy place for knowledge to get lost.

Doing it his way

The problem was handed to GM technical fellow Steven Wieneke, who has since developed processes for documenting product knowledge in a Technical Memory-Best Practices database in parallel with another team’s catalogue of engineering-solution activity. He was expected to do it using BP and he did – but with a good measure of KM built in.

But this story is not about document repositories; it’s about the process of populating them and the unexpected benefits.

After six years, Wieneke says that if he had it to do over again he would not use the BP label or KM either. He describes the process simply as building technical memory. He doesn’t criticise or deny the existence of BP and KM in his solution, but insists it’s about neither. It’s about facilitating awareness of technical memory.

“Pure KM is still quite a mystery to me,” Wieneke says (tongue-in-cheek). “All businesses are knowledge-based. The issue is whether the knowledge is visible, valued, accurate, relevant, shared, really understood. In my mind, KM is not about bringing knowledge to people but assisting them in seeing it all around them. Their knowledge is embedded in their processes, products or services. I argue that KM is more about knowledge awareness and meta-knowledge.”

Wieneke did not have to start from scratch. Everything GM did from the early 1980s to the end of the century set the stage for the consolidation of company-wide engineering knowledge (although it was not the purpose at the time). For example, GM recognised that its autonomous structure of product-engineering organisations across the globe had created a culture of knowledge hoarding, not sharing.

GM therefore began a series of North American product-engineering reorganisations, which most recently concluded with the consolidation of car engineering groups from five to two (car and truck) and finally to one.

Responsible engineers

Also in the late 1990s, engineering executives identified subject-matter responsible engineers (SMREs) – 200 from car and truck engineering with experience in the various aspects of designing, developing or manufacturing a vehicle. Prior to 2000, SMREs were trouble shooting, mentoring, developing and refining new product technologies.

From the beginning, they were the ‘go to guys’. They were what Wieneke calls ‘phenomenal troubleshooters’. “Many operate in the expert state of ‘not aware that I know’ and GM’s objective was to bring them back into an ‘I’m aware that I know’ state so they could better articulate the whys and the whats.”

SMREs currently have an average of ten years’ experience and many have as much as 20 or 30 years. That level of experience is needed more than ever now that the SMREs are the primary best-practice authors for the technical memory database launched in 2000.

Wieneke used an existing taxonomy to charter 138 best practice teams across 33 centres of expertise to work with the SMREs. Today there are upwards of 1,000 engineers (ten per cent of the total) engaged in populating and maintaining technical memory, a database of explicit knowledge. About one-third of the database is updated every year.

During the first six months, some 300 two-hour coaching sessions were held to provide instructions on what best practices at GM are and are not. In a nutshell, a product best practice is knowledge about design features that control the desired outcome. “It’s the whats, whys, whos, wheres and whens,” says Wieneke. It is not about ‘how tos’. At GM there are other technical documents that are sometimes confused with BP such as ‘requirements’, which contain only the ‘shalls’. A BP is a knowledge-sharing document.

“We deliberately limited the scope of a best practice to five or six related design parameters, a nugget,” Wieneke says. “Limiting the scope allowed the SMRE to write a best practice over the course of 40 hours, while working on other assignments. The limited scope additionally allowed a group of peers to review, agree and technically approve the BP in a timely manner. These technical reviews would prove to be the most time-consuming aspect of the process.”

Activity metrics

The BP knowledge base was up and running by 2001 with 687 best practices by the end of that year. The focus remained on the authors and continued additions to the database with the metric being the number of best practices approved. In 2002, the annual number jumped to 2,522. By 2006, that figure had increased to 4,063.

In 2003, the focus shifted from authors to users. A metric of ‘best practices viewed’ was added with 36,553 recorded that year, rising to 168,777 in 2006.

Wieneke says these activity-based measurements are important, but outcome metrics have not been possible until now due to the three-to-six-year lag between design and outcomes, such as reduced warranty costs, and improved JD Power and Consumer Report rankings. Nevertheless, “the best-practices initiative, combined with others implemented within project engineering in the early years of the programme, has quickly contributed to reduced structural costs, improving product quality and competitiveness.”

Remember, the goal for this project was to capture tacit knowledge, codify it and make it available electronically as an engineering-solution catalogue and technical-memory database – explicit knowledge. Interestingly, it resulted in a role reversal – improvement of the flow of tacit-to-tacit knowledge became the by-product and now engineers are more widely and personally connected than ever before. Teams look like communities of practice (CoPs) and knowledge sharing is not just flowing in documents but through the human network that produces them – KM without the name.

And then there’s the learning component, which was occasioned by the need to assure that best practices and other technical sources reflected the most current new learnings and preventions.

Wieneke makes a distinction between “lessons” and “learnings.” “Lessons,” Wieneke says, “are thing’s gone wrong and corrected.” At GM, Wieneke says, “Learnings are things gone right that we want to re-use—adopt or adapt. With lessons, we want to capture the preventions not the corrections. Corrections are not necessarily the best means of prevention.”

Closed-loop learning

An internal audit of GM’s North American lessons-learnt process revealed that the lessons were not being consistently addressed. In April, 2004, the lessons-learnt process was replaced with a visible learning process called closed-loop learning. Closed-loop learning ensures that valued lessons and learnings are inserted into three categories of intellectual capital:

Technical excellence (individual know-how);
Intellectual property (best practices and other written technical resources);
Technical exchanges (key meetings focused on information and knowledge).

With this step, the knowledge-sharing culture has spread from the roughly 1,000 engaged initially to more than 10,000 engineers. Anyone can now bring a solution for a lesson (problem) or a new learning (solution) to the appropriate SMRE at any time. In this way lessons (trouble) become learnings (solutions) and are made accessible to every engineer.

The old lessons database was shut down in January 2006.

The new mandate for the teams in 2006 was not only to maintain the system in North America, but also to globalise it across all regions. Wieneke and his colleague Karla Phlypo saw it as an opportunity. “It initiates a new wave of training in all of our knowledge tools and processes,” says Wieneke. “We have the opportunity to improve the fidelity of the best practices, from heuristic to experimental to scientific, resulting from design for Six Sigma training and project completions across product engineering.”

The globalisation is already adding to a solid list of accomplishments:

Technical memory has enabled the connection of design engineers with SMREs by publishing rosters in global technical memory and across the web-enabled enterprise-wide organisation chart;
The global SMREs have increased the number of approved global best practices from zero to more than 4,063 outside North America;
The cost avoidance for applying Best Practices is measured in millions of dollars;
Product engineering has a visible learning process to ensure GM’s intellectual capital is current and relevant;
Sharing, adopting and adapting these practices across GM Global Engineering [GM North America, GM Asia Pacific, GM Europe and GM Latin America] are integral to the work;

Although not solely a result of the initiative:

Product quality has dramatically improved;
Time to market has been accelerated;
Structural cost has been reduced;
The engineering culture is progressing from hoarding to sharing knowledge and from reinventing to adopting and adapting what is already known.

Outcome metrics

Early outcome metrics are already beginning to validate the product engineering initiatives. During the 36 months in service, for vehicles sold during 2000 through 2003, actual warranty costs dropped by almost 20 per cent below forecasts.

The catalogue of engineering solutions, technical memory and the closed-loop learning are three of the current 10 activities identified as the engineering enablers driving the warranty cost down.

If he had it to do over again, Wieneke would recommend the emphasis should be on implementing a visible, enterprise-wide learning process rather than lessons learnt or best practices.

“The learning process will necessitate identifying intellectual capital which eventually justifies creating and maintaining intellectual properties like best practices,” he says.

He believes documenting what you know does as much for the author as the end user by surfacing and clarifying what is known and – most importantly – identifying the ‘whys’, ‘whens’ and ‘wheres’.

And the unexpected but welcomed byproduct of a natural human knowledge network made it apparent that some of the separate but similar goals of best practices, document management, learning, knowledge management and even design for Six Sigma cannot only work together, but enhance one another when the architect blends the best of each into one holistic bundle.

Jerry Ash is KM coach, founder of the Association of Knowledgework, http://www.kwork.org, and special correspondent to Inside Knowledge. He is author of the Ark Group’s latest major reports, Next Generation Knowledge Management and Next Generation Knowledge Management II. To order either of these, contact Adam Scrimshire at publishing@marketing.ark-group.com. Jerry Ash can be reached at jash@kwork.org.

A GM paper will be published later in 2007 as a case study in Knowledge Management for Services, Operations and Production Industries, by Tom Young and Nick Milton, Chandos Publishing. The case study itself will be more detailed than this report and is titled Adopting and Adapting Product Best Practices across General Motors Engineering Six Years Later. Steven Wieneke of General Motors can be contacted via e-mail, steven.wieneke@gm.com.

Wieneke will be guest moderator for AOK’s STAR Series Dialogues, June 18-29. AOK membership is free and you can join online at: http://www.kwork.org/explain_join.html.

Nine essential steps to learning

During the six-year development of product engineering technical memory, Wieneke and his team found nine steps essential for implementing and sustaining an enterprise-learning process:

1. Create taxonomy by area or community of practice (CoP);

2. Identify a ‘subject-matter-responsible person’ for each CoP;

3. Make CoPs visible;

4. Identify key individuals (the main internal customer) in each CoP;

5. Make visible what the CoP must know;

6. Make an ‘intellectual capital ledger’ visible for each CoP:

Technical excellence (education, training, mentoring);
Intellectual properties (Best Practices and other written technical sources);
Technical exchanges (peer assists, after-action reviews, peer reviews, design reviews).

7. Identify sources of lessons and learnings for enterprise (long-term emphasis should be on learning, innovation, invention);

8. Make the enterprise-learning-process visible;

9. Leverage meta-knowledge (knowledge about knowledge) practitioners.

Six Sigma definitions

Six Sigma is defined in many ways. Here’s one of many, from Steven Wieneke:

“A method or set of techniques, Six Sigma has also become a movement focused on business process improvement. It is a quality measurement and improvement programme originally developed by Motorola that focuses on the control of a process to the point of ± six sigma (standard deviations) from a centerline, or put another way, 3.4 defects per million items. A Six Sigma systematic quality program provides businesses with the tools to improve the capability of their business processes.”

Then what is Design for Six Sigma?

1. Understanding what the customer wants;

2. Creating a design that meets the customers’ requirements and needs;

3. Addressing the variation effect of both the design and uncontrolled factors (like environment or manufacturing) on the design function and performance;

4. Making the design insensitive to variation and balancing interactions to ensure the customers get what they want every time.

Bottom line: Good engineering that ensures the customer gets what the customer wants, every time.