"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 knew 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 are recognized as having knowledge when you can use fundamental skills creatively under novel conditions.

In our last column we described a packaging concept for transferring knowledge, not just information, at high speed within an organization: packaging that knowledge plug-compatibly with what people already knew. We described a packaging format and rationale that we depict here in both abstract and actual graphic representations.

Here we will take a deeper look inside our “flash cube,” at the nature of the packaged knowledge, and see that it is structured to help provide an insight into a whole class of problems and not merely today’s fish.

Last time we talked about creating a generic metaphor that makes explicit the tacit knowledge which everybody understands about something they respect as functioning well. We call this a local metaphor because the knowledge is local to the people we are interested in. After we package the local metaphor in our flash cube pattern, and help everyone become comfortable with this representation, we then introduce all new knowledge in the same packaging pattern.

Basically the local metaphor provides everyone with a template of language and culture for describing problems and their related solutions.

The reason this works is because the packaging pattern is not simply syntactic (convey location: describe the problem in the upper left corner, describe the solution in the upper right corner, etc.); but rather a semantic (conveying meaning) framework that tells us to describe the problem in terms of the nature of change it must address, and to describe the solution in terms of its relationship to a specific Reusable-Reconfigurable-Scalable change-proficient architecture. Thus, we provide to every person a common knowledge pattern that can be overlaid with specific information about virtually any business practice, production process, product design procedure, or other knowledge of interest.

To be sure, there is a lot of information unique in each new piece of knowledge to be dealt with; but in each case it is cast in a very familiar pattern. The person attempting to understand the knowledge will know exactly where to find the answers to a common and familiar set of questions. The depth of understanding that comes after practice and experience is not conveyed in the abstract package; but the information and conceptual framework necessary to guide practice and employment are there.

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.

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 isn’t 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 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 experiences. 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 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, showing how the application of these principles contributed to the adaptable capabilities we required in our problem definition. We have a simple intuitive ex-ample here that will not require any further structural detail. We’ll that’s my fish story for the day.