Wikis as a Knowledge Artifact and a Knowledge Flow

In my previous post I came to the conclusion that knowledge is both an artifact and a flow. As part of the learning process, you learn the state of knowledge as it exists at that time. Then, as time progresses, things change and you now need to know the changes to the knowledge artifact. You need to know the flow. New students and new additions to the firm start with the now revised artifact. For effective knowledge find-ability and transfer in the firm, you need both the knowledge artifact and the flow.

In my example of a practices and procedures policy, initially everyone needs to know this knowledge artifact. But once you learn the policy, you care about the flow of changes to the artifact. The new person joining the firm needs to only learn the revised policy in effect on their first day. The new person may have some need to find out what the policy used to be, but the old flow is generally of limited value to them.

A wiki fits wonderfully into this paradigm of knowledge as an artifact and a flow. A wiki combines the knowledge artifact and the knowledge flow into one.

With a wiki page, as with any document, I discover the knowledge artifact as it exists and can learn it. The wiki then goes to the next step that a normal document cannot go to by creating a flow. With a wiki, I can subscribe to the wiki and have the wiki send me the flow of changes to the wiki.

If I have the need to see the historic changes in the knowledge artifact, I can use the history feature of the wiki. Even better, I can see who made the changes and when the changes were made.

In converting the practices and procedures policy from a word document to wiki, I convert it from dry document to more useful living document. In a wiki, the policy becomes both a knowledge artifact and a flow. As I update the policy, the wiki sends the subscribers the flow of changes. They get alerted that a change has occurred and see the change. They do not need to save the email notifying them of the change, because the change is now synthesized into the knowledge artifact. A wiki also saves a step for the drafter of the changes. The drafter need not remember to send out an email notice of the changes and need not decide who should be the recipients of the email. The wiki sends out the notification of the changes to its subscribers.

If I am away from operating in the area of the policy and then come back to operating in the area, I can quickly and easily compare the policy as I historically remember it to the policy in its present state. I can create my own combined flow of information.

As another example, I have a collection of real estate transfer tax laws from across the United States. For each state, I describe ways to structure a real estate transaction so that the transfer does not trigger the payment of a transfer tax. In Maryland, a transfer of the equity-ownership in a real estate owning company does not trigger the transfer tax. Maryland recently enacted a change to its transfer tax statute that now imposes a transfer tax with certain transfers of this type. I can send out an email alert to my group about the change and then incorporate the new provisions into my collection. If my collection were a wiki, I need only make the change in the collection and the wiki will have captured the new information and will send out the notification to the subscribers.

I believe that wikis should be and will become an important tool for knowledge management within law firms.