Ben wrote...
> 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.
Solve a problem only once? Upper management's philosophy sounds good on
paper, but does it ever work like this REAL life? IMHO, I don't think so.
Upper Management seems to have a machine model of the organization in
mind. They seem to think that a learning organization means instant
learning -- we did it once, therefore we should have ALL of the knowledge
about it. The problem they solved once will show up again, in another
part of the organization, dressed in a different suit and hat, with
different conditions surrounding it. At first it may not even appear as
the same basic problem. A machine orientation would likely fail in this
situation. An adaptive, learning entity would not -- it would eventually
solve the problem through experimentation, feedback and prior
experience/learning.
The Institute for Research on Learning(IRL) has done some great work on
'communities of practice'(CoP) -- "where learning takes place". This
whole approach started at Xerox PARC where they were monitoring Xerox
repair people who were self-organizing around common complex problems
because their training and manuals did NOT provide the answers. They
helped each other solve complex problems. They knew who had run into what
situations before. By belonging to a community an indivual could learn
new things and have access to a pool of unwritten/implicit knowledge [my
guess is that much of this complex knowledge could not be made explicit
and written down -- they learned in the apprenticeship mode] Ben, is this
not true of much of the complex knowledge around computer networks these
days? CoPs have another powerful effect -- if you don't belong, you don't
learn. This has many implications for individual, group and
organizational performance -- but that is probably another thread.
> 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.
Yes. Maybe your approach should be not to store the knowledge needed to
solve a problem, but store the 'pointers' to that knowledge -- the links
to the nodes with the knowledge. Again, the YAHOO/WWW model. Maybe you
could even implent the solution as an intranet in HTML? A large knowledge
network map accessible by anyone in the organization and key stakeholders
outside Novell.
> 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.
Yes, there are some network principles you could follow to build a network
that would be minimally affected by the removal of one or more nodes. One
of the dramatic 'what ifs' we do with our client management when feeding
data back about their networks is to selectively remove nodes from the
network and see the results [we display their networks up on a screen via
a laptop computer running our interactive network analysis program].
Sometimes a node is removed, and nothing much happens -- some paths in the
network are lengthened, but everyone can still reach everyone else
reamaining. Other times the removal of a node produces dramatic results!
Where there was once a large interconnected network [of knowledge
exchange] there are now 2,3,4,5,6,etc disconnected clusters that cannot
reach each other! The removal of some nodes causes some groups/networks
to fragment greatly. These are the people you do not want to loose... not
before you build alternate routes between the groups they would fragment
by leaving.
>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.
If you are tracking key knowledge and the pointers to it, your knowledge
network map should show all of the nodes and links that are
important[whether internal or external] for any given topic/domain.
Different knowledge domains would reveal different connections between the
nodes.
>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.
Yes! When you automate a mess, you ust get a faster mess! The irony is
that a faster mess is usually worse than a slow mess ;-)
Valdis Krebs
Krebs & Associates
Cleveland, OH
Los Angeles, CA
--"Valdis E. Krebs" <InFlow@cris.com>
Learning-org -- An Internet Dialog on Learning Organizations For info: <rkarash@karash.com> -or- <http://world.std.com/~lo/>