Knowledge of product, knowledge of practice

---

Some companies make things, some do things. Different focus, different business, different approach to KM.

OK, so that is an oversimplification - most companies are a mix of Doing and Making; they have product departments where they Make things, and sales/marketing/support departments where they Do things. However there are still two types of KM approaches; the approach that focuses on Product, and the approach that focuses on Practice.

A typical practice-based organisation would be the Army. They don't make things, they do things, and their KM approach is all about the development and improvement of Practice. They develop their doctrines, they develop Communities of Practice, and they focus on continual practice improvement. We see the same in the oil sector. The focus is on Practice Improvement. Communities of Practice, Best Practices (or whatever you prefer to call them), Practice Owners - the entire focus is on knowledge of Practice, Practice Improvement, and Doing Things Better.

A typical product-based organisation would be an aircraft manufacturer or a car manufacturer. They exist to make things, and their KM approach is all about the development and improvement of Product. They develop product guidelines. In DaimlerChrysler, their Electronic Book of Knowledge was about motorcar components, and their tech Clubs were more Communities of Product than Communities of Practice. The experts are more likely to be experts on a product, than experts on a practice area. With the more complex products, were design knowledge is critical, KM can become Knowledge Based Engineering, with design rationale embedded into CAD files and other design products. The Air Force, in contrast to the Army, is focused primarily on Product learning - learning about the Plane itself, much of which learning is shared with the aircraft manufacturer. For a Product based organisation, the entire focus is on knowledge of Product, Product Improvement, and Making Better Things.

The danger in KM comes when you try to impose a solution where it does't apply. KM should be pragmatic, and consist of "horses for courses", rather than a one-size-fits-all approach. This is also true for divisions within large companies. While the sales division, or the new business division, or the projects division may need Communities of Practice, perhaps the division that makes the products needs Communities of Product, so that Knowledge of Product can be transferred across company boundaries. Perhaps the traditional tools of Learning Before, During and After need to look at Product knowledge as well as Practice knowledge, and look for improvements in Product as well as improvements in Practice.

The idea of Communities of Product is an interesting one, as these Communities may extend beyond the designers and Developers, to include the Sales force and the Service Engineers, who also need product Knowledge, and can supply learning about the Product in Sales, and the Product in Use.

Ultimately the Product Community can extend to the Users of the product  - the customers themselves. That's when it really gets interesting!