Arts: A Knowledge Management Tool

L505 Essay 4

Chris Dent

2001-02-10

Rudy Ruggles suggests technology can be used to better manage knowledge (Ruggles). He describes a variety of tools that can help an organization to generate, codify and transfer knowledge. For a few years I worked in a mid-sized Internet Service Provider (herein known as The Company) as a lead technician and departmental manager. Throughout that time I was unfamiliar with the terms and tools of knowledge management but created tools for our department that were crucial to the efficiency of the organization. This document tells the short story of one such tool: blackarts, or as it has since been renamed Arts.

Any group with similar goals collects knowledge on tips and tricks that make reaching the goals easier than it would be otherwise. For many groups that knowledge remains tacit; it sits in the minds of the individuals and is unavailable organization-wide as explicit codified knowledge (Broadbent). This lack of distribution can have significant disadvantages for the organization: gains in efficiency are not shared, expertise is not shared and potential training opportunities are lost.

At The Company duties were shared quite widely within departments but only rarely between departments. Early on, inside the systems department it was common to hear or read (in email) the question “How do I do such and such?” with the same “such and such” day in and day out. This was a problem: it wasted time. We compensated, each compensation leading to new problems and new solutions.

At first we tried creating web pages describing a system or service and some of the common tasks associated with it. Initially this would work well, but then as the systems were changed or services were updated the documentation would become out of date. There were also significant time hurdles to overcome to collect all this information into a single monolithic document per service.

The first problem was easily solved. A software tool, webwatcher[1], was created to watch over documents on the web server. Each document was edited to include an owner and an absolute or relative (from the time of modification) expiration timestamp. Each day webwatcher would run through the web server and find documents that had expired and notify the owner with a message suggesting they check the document for relevance and accuracy. The owner would continue to be notified until they updated the document. After a definable time period a “boss” would be notified of any documents that had gone without attention for too long. Any document that had the proper meta-tags for webwatcher had a reasonable chance of remaining fresh and relevant. If they had the tags. If you could find them. If they were written in the first place.

A busy system administrator has little time for what sometimes seems to be the non-crucial task of documentation. Webwatcher was unable to address this problem. If knowledge was not written, how could it be shared? Writing can present a very high barrier to sharing knowledge.

It turns out that the system administrators at The Company were writing documentation all the time, but not in a form that was easily recognizable: they send email all the time. Email about what they’ve done, what they’ve solved, what they are working on. A bright bulb in the department came to me and said, “Why don’t you write an email to web gateway that will allows us to drop something in a web accessible archive as part of the regular email conversation?”

Arts was born[2]. Using terms from the Ruggles article Arts can be described as a knowledge base for the codification and distribution of process, factual, catalog and cultural knowledge. It accomplishes this by providing both a repository for knowledge as well as a process for submitting and maintaining knowledge.

New documents are submitted by email. During an email conversation someone may recognize a particular discussion as worth remembering and respond to it by saying, “blackarts?”[3] It is then incumbent upon the original author to take the message they sent (from their sent-mail folder) and send it into the Arts gateway, perhaps with some editing. The gateway applies meta-tags to the document suitable for webwatcher as well as a creation timestamp and saves it to the repository.

The repository itself is a dynamic table of contents generated from the meta-tags in the documents. Documents may be viewed sorted by section, creation time or modification time. A search mechanism is provided as well.

Arts has proven wildly successful at The Company. Arts at The Company (it is also used elsewhere) has the good luck to be surrounded by a culture that supports submission. People who have lots of documents in Arts have what amounts to street credibility[4]. The greatest benefit gained from Arts has been the provision of inter-departmental knowledge. This has helped to identify communities that exist outside the boundaries of the departments. Arts, though, is not a perfect solution. Like many solutions, it was a quick and dirty effort made to quickly solve a problem that, without intending to, became the final solution.

I’m in the process, using information from the experts in the field, of creating a list of desired features for the next version of Arts[5]. Included are a fair amount of the features discussed by Ruggles:

· Gatekeepers: methods for the ongoing review and raising and lowering of documents within the repository, giving the documents scores. This could be accomplished both with manual scoring by readers as well as a modifier created by the number of times a document is viewed.

· Knowledge Maps: more complete methods of identifying what documents are in a repository. The section headers work relatively well and the search dialogs are effective if you know what you are looking for. If you are browsing, it can get a bit clumsy.

· Commentary: each document would benefit from commentary, either attached to the document or mailed to the author. This commentary would help to make the document more relevant: the author could use the comments during future editing sessions.

· Dictionary/Glossary/Thesaurus: a method for providing a system-wide glossary for Arts is under consideration. I already have a tool that provides infinitely recursive hypertextual linking between words and definition text that could be integrated.[6]

· Web-based editing: the current version requires a document owner to log in to the system on which the files live and use an interactive editor to make changes. A web-based editor is the most frequently requested feature for the software.

· Alternate gateways: the only way to get a document into the system now is to use the mail gateway. Other interfaces should be considered.

· Database repository: the current version stores documents in text files on a file-system. A database repository would provide more flexibility and make some of the other features much easier to accomplish. A database would also allow the repository to be much larger.

There are some tools that already do many of these things. The Everything Engine[7] and WikiWiki[8] are both well-known examples. They, though, are perhaps too anarchic for the enterprise oriented purposes for which Arts positions itself.

Even in its current form Arts provides an effective tool for knowledge codification and for knowledge transfer. Arts meets many of the requirements laid out by Ruggles for knowledge transfer. The gateway provides a method to codify the knowledge and the repository provides the transfer. The repository keeps the knowledge around and ensures its freshness, overcoming the barriers of temporal distance. The repository is available over the Internet, overcoming the barriers of physical distance. The repository can be made as open or closed as necessary as well as be configured to make access as authorized or anonymous as necessary, overcoming the barriers of social distance.

REFERENCES

Broadbent, Marianne. “The Phenomemnon [sic] of Knowledge Management: What does it mean to the Information Profession?”, http://www.sla.org/pubs/serial/io/1998/may98/broadben.html, May 1998.

Ruggles, Rudy. “Knowledge Tools: Using Technology to Manage Knowledge Better”, http://www.businessinnovation.ey.com/mko/html/toolsrr.html, April 1997.

[3] Arts is designed to support multiple repositories, which gives it a way of creating repositories for different departments. The systems department had the first Arts repository, called blackarts. Since then other repositories were created: greyarts, bluearts, yellowarts, proj-arts, etc.

[4] I don’t think there is anyway to create this. It happens with the right mixture of personalities. Companies that try to influence the formation of communities of practice will face large challenges. Identifying and granting autonomous power to leaders inside the communities is the way to go.

[5] I may wish to make the next version of Arts be the center of my final project, if that proves possible. It may require more time that I currently have available.