Knowledge in
a Flash . . . Cube (download zipped Word 6.0 version) Rick Dove, Paradigm Shift
International, www.parshift.com, |
"I need a fish to eat", the poor man said, "please tell
me how to get one." "Take this hook and line", replied the fisherman, "put a worm on the hook, go to the dock there, drop it in the water, and soon you'll catch a fish." Ten minutes later the man was back with thanks for the fisherman and a fish for dinner. He did as he was told every evening that week until Sunday, when, after two hours, he gave up and went home empty handed. After some time on Monday and no fish he came back to ask the fisherman what was wrong. "Simple", the fisherman said, "the weather has changed and the fish are now biting under the bridge. And it is a bigger fish this time so you'll need a heavier line, a larger hook, and a small fish as bait." Ten minutes later he had his fish for dinner. Doing as he was told he was successful every night that week, and on Friday he thanked the fisherman for teaching him how to fish. "You know how to fish last week and you know how to fish this week" the fisherman said, "But next week you will not know how to fish." Any good fisherman will tell you that he is still learning how to fish; but lifelong learning is not our point. Our point is that a straightforward procedure is not knowledge; at best it is simply information. You have knowledge when you can use fundamental skills creatively under novel conditions. You have knowledge
when you can use In our last essay here (#49, Jan. '99) we
described a packaging concept for transferring knowledge, not mere information, at high
speed within an organization - packaging that knowledge plug-compatibly with what people
already knew. We described a packaging format and rationale which we depict here in both
abstract and actual graphic representations. |
![]() |
A local metaphor in a specific industrial setting might focus on a manufacturing process or other business practice that everyone in the organization respects for its ability to work well under all manner of changing conditions - such as the accompanying diagram of a Just-In-Time assembly line. But local metaphors don't have to be about something in the work environment - they just have to be about something everyone respects in common for its ability to accommodate changing conditions. |
![]() |
See essays 33 (Aug 97) & 35 (Oct 97) for fine print |
Most of you may not be fisherman, but probably have some idea what
fishing is about, and probably even know a fisherman or two who's competency you respect.
With this as a respected process we all have in common, we could use it to package a local
metaphor. One requirement of a good local metaphor is that a lot of explicit detail not be required in order for the important concepts to be understandable. The first thing we need to do is to describe our problem in terms of the types of change it must deal with effectively - the structured problem definition. If we focus our interests on fresh water fishing the proactive change requirements might include, most importantly, changing our empty hand to one with a fish in it; and then improving the time it takes to get a fish and the predictability of success. Eventually we'd like to migrate toward some simple salt water fishing; but for sure we want to expand out fresh water capability to most all fish types; to handle shore, dock, and boat fishing; and to handle lake, river, and stream fishing. On the reactive side, we'll need to deal with broken tackle, a variety of different fish types at any moment, and variations in weather conditions. If we should be so fortunate to find a school of fish or a feeding frenzy, we want to be prepared to take advantage of that and not be capacity limited below what the regulations allow. And of course, we'll want to be able to reconfigure our tackle and our bait to match changing or unexpected conditions. With these requirements met we should be able to enjoy a wide range of fishing experience. If you find something missing here, perhaps it is because you wish a different experience than I, or perhaps we should have collaborated on the development of this problem definition. In any event, the structure in this definition came from our attention to eight different types of change. Now on to the structured solution framework. The strategic themes we'd like to achieve in our fishing experience are simple: catch it quick, and catch consistently. The principle activities we will employ include configuring tackle, choosing bait, choosing location, choosing time, and choosing style. Our solution resources will be represented as a pictorial icon pool for things you might find in the tackle box with its many divided compartments, such as a variety of hooks, sinkers, artificial baits, and floats; along with a variety of live bait as the occasion suggests. And of course some different weights of fishing line for different fish sizes, weights and orneriness; and a few different rods with interchangeable reels. The application story will be a short two-pages that describes a few typical resource configurations to a few different fishing conditions, making the point by example that we have highly reconfigurable resources that are assembled to take advantage of whatever conditions prevail at the moment, and that experience and experiment teaches us how to improve our configurations. Next we'll draw some pictures of two or so collections of the resource icons assembled into typical "fishing systems" that parallel examples in the story. And while we're at it, we'll briefly state who is responsible for assembling and reconfiguring these systems, and for maintaining the pool of reusable resources. In this case these responsibilities all fall to the fisherman. Finally, we will structure our story points into each of the ten RRS principles in action (Oct 97), showing how the application of these principles contributed to the adaptable capabilities we required in our problem definition. We have a simple intuitive example here that will not require any further structural detail. We'll that's my fish story for the day. |
|
Would you like to offer some thoughts or add to the dialog?
Your sending of a comment automatically grants us permission to edit and
post at our discretion.
Send your comment to ![]() |
========= Reply ========================= From: paul@jpcripwell.com (Paul Cripwell) Date: Tue, 16 Feb 1999 I read this paper and some other things on your website and found them basically interesting but they all seemed to be centred on one very important concept: It is possible to proceduralize the transfer of information to knowledge as well as their application. I have found this concept throughout many articles on both Knowledge Management and Information Engineering and find it almost impossible to believe that this can be turned into any kind of turnkey system. If you had read recent articles from HIS HIGHNESS (ugh!) Bill Gates this is exactly what Microshaft is trying to do; create a software package that does everything for you. One of my strongest arguments against the procedural concept is: Every one is entitle to thier own opinion and in many cases competing views can both be correct. This would not be tenable in current software or even advanced AI. There are some additional thoughts on my website and you might be interested in the Information Overload and What is Information pages. Cheers, Paul ========= Reply ========================= Another body of knowledge you might find informative about process and procedure for information transfer into knowledge can be found in situation theory. A web search on this phrase will turn up quite a bit. I agree that Information Technology vendors too often exaggerate the support that technology can provide in the areas of knowledge management and knowledge capture. The domain of knowledge is the brain, not the disk drive. Nevertheless, IT does have valuable support to offer, not only in libraries and catalogs, but especially in collaborative connection and infrastructure. People come in many thinking and learning varieties. One quick cut is known popularly as the left and right brain dominance differences - logical vs gestalt, detailed vs holistic, bottom up vs top down, sequential vs parallel. I have found over the years that presenting a gestalt picture to a dominantly logical thinker fails to transfer any knowledge, just as a procedural view generally fails with gestalt dominant thinkers. My experience leads me to feel that most of the people I try to communicate with in operational business environments are in the logic dominant area - probably because their promotion to positions of management have been facilitated by their generally more effective communications capability. In any event, these minds prefer a procedural view point of what to do and why, rather than an equally valid mind map of contradictory and broader information. Thus, since I hope to have an effect on decision makers of all kinds, I find it necessary to develop procedural tools - on occasion I liken this to dressing up a sheep in wolf's clothing. Even the Zen master employs procedures. ========= Reply ========================= |
|