Knowledge repository/"Intranet" LO7771

Ben Compton (BCOMPTON@novell.com)
Fri, 07 Jun 1996 00:32:31 -0600

Replying to LO7754 --

Valdis writes in response to a message I posted a couple of days ago:

>Ben, IMHO you have tried to store too much data, made it way too
> complicated.

I agree. This was our first conclusion. However, we're required by
upper-management to document the solution to 75% of the problems we solve.
The philosophy behind this requirement is that a problem should only be
solved once. I agree with the philosophy, but the problem with documenting
so much data is that its quantity quickly makes most of it meaningless.

> Herb Simon, Nobel Prize laureate[Economics], was asked how he
> seemed to know so much about a wide variety of topics. His
> colleague was truly amazed, he had never met anyone with such
> broad knowledge. Herb smiled, and answered, "Oh that's easy, I
> keep my knowledge in my network of friends and colleagues" He
> simply knew which expert to go to when.

Yep, that's my primary strategy. I don't know any other way to process and
store a variety of knowledge. I think it was Einstein who was asked how
many feet were in a mile, he responded that he didn't bother to memorize
facts he could look up in a book. The same basic principle seems to apply
to knowledge networks. One of the problems with this approach in an
organization, however, is that attrition can quickly reduce collective
expertise. IMHO, it is important to build a system where attrition does
not cause a noticeable disturbance in the knowledge network.

Another problem with this approach is that it does very little to document
knowledge that needs to be shared with customers, suppliers, distributors,
etc. When the knowledge domain (I hope that is the right expression)
extends beyond an organization, it is important to be able to document
that knowledge in such a way that it is easily accessible and understood
by those whose success depend upon it.

> Ben, if you want to throw technology at the problem, then maybe
> you keep a simple data base of WHO is connected to WHOM about
> WHAT.

I agree with this as well, and we're actually in the process of
implementing such an approach. One of the problems we face, however, is
that the formal documentation of expertise has very little to do with
where the actual expertise resides. The real knowledge is still acquired
from the informal networks (the thread on informal networks has been very
enjoyable for me, as that is how most of the knowledge gets transferred in
my department). This makes knowledge acquisition and preservation a very
individual effort; it is not always a team effort, and therefore, our
collective knowledge (and memory) is not always as reliable and complete
as it should or could be.

BTW, we didn't blame the technology for our failure; the problem was the
way we used that technology. When I was consulting, I'd tell my clients
that if they're going to use technology to automate their business
processes, they'd better make sure they're good processes. Otherwise, the
only thing technology is going to do is expedite probable problems and
failures.

Thanks for the feedback, it was valuable information.

-- 

Benjamin B. Compton ("Ben") | email: bcompton@novell.com Novell GroupWare Technical Engineer | fax: (801) 222-6991

Learning-org -- An Internet Dialog on Learning Organizations For info: <rkarash@karash.com> -or- <http://world.std.com/~lo/>