Miscellany

When one looks at KBE, process comes to mind as an important aspect. Witness the COE Forum thread titled “KBE OneLiner?”. This was an effort by several to describe KBE succinctly enough to capture attention of management and to, perhaps, obtain resources. Such attempts are not without grounds. Take a look and judge whether these attempts were successful. Participate, if you will.

In the entrepreneurial realms, some suggest that one has to be able to tell the money guy or gal about one’s business in an elevator ride (hence, the use of ‘elevator speech’). Could KBE benefit from such a description encapsulated in a very short format? Here are some examples.

• KBE is an engineering process that creates, maintains and distributes engineering templates and tools that are adaptive and contain embedded logic and company design knowledge
• KBE is embedding engineering decisions into your process
• KBE is a tool to automate designing & manufacturing processes for reuse, thus resulting in time cost reduction of Product Development

KBE seems to have an intuitive appeal to the technical community. But, the appeal can also be there for the managerial when the potential productivities (and related savings) are stated correctly. Yet, it has not been easy to sustain support and focus KBE applications; despite a growing workbench collection, there has not been a general agreement on need or approach.

Many recent papers appearing under the auspices of COE look at practices, as in the effort to define the best practice being conducted with the Forum as the coordinating scheme, or Tips & Techniques as in a recent ‘Ask the Experts’ session (June 20, 2006, Knowledgeware Tips and Tricks). Yet, there are questions that need to be considered (see 2007 COE KBE Sessions) even if they appear to esoteric from the strict practices viewpoint.

In an overview of KBE that has been a joint effort by many, KBE can be seen as facilitating a type of ‘end user computing’ that is necessary in the information age of which PLM is an example. ‘end user’ in this context denotes the SME for any of the myriad disciplines that are part of PLM. We need to look at the success related to use of the SME in complicated processes. Do we know how the SME learns through experience how to balance the operational with the ontological? That is, any practice needs a foundation.

In KBE, due in part to its multi-disciplinary framework, ‘practice’ will be multi-fold, but there are two main ones to consider here: KBE in practice and KBE in development. Some early types of KBE merged the fine line between these two, perhaps wrongly, through an extensible language. Some KBE approaches do not have a meta-facility, as of yet; it is an open issue as to the need for this. However, without some ‘meta’ means, what will be the means for establishing coherency?  

The intuitive appeal of KBE is similar to that found with computational intelligence. There are many ways to explain how AI appeals to us. But, looking at KBE in particular, it is a concrete example. And, KBE has an additional appeal which is important in the larger scheme; it affords us the opportunity to map models to real entities thereby offering opportunities for improvement both in function and truth.

For more information, contact John at john.m.switlik@ieee.org