In
Carla's latest
blog post, she writes: "A year ago, I thought wikis would be the workhorses of
Web 2.0, but it seems that the allure of social networking and blogging is
winning out." That may be true--who am I to argue with Carla!--but I have noticed
an uptick in the buzz around enterprise wikis recently.
Earlier
this month, The New York Times wrote about Diplopedia, the U.S.
Department of State's internal wiki, and how it's changing the way things get
done at the organization. By providing specific examples of the information
that can be found on Diplopedia--everything from biographies of political
figures to instructions on how to get food delivered to the main State
Department building--the NYT article demonstrates how a well-administered wiki
can save employees time, facilitate the transfer of tacit knowledge, and
encourage collaboration.
Success
stories like this one are particularly valuable because they explain the tangible
business benefits behind the slick new tools (and as the article says, "if
wikis can work at the State Department, with its fabled bureaucracy and
attention to protocol and word choice, they can work anywhere.") I think most
people know what a wiki is by now and are familiar with Wikipedia, but that
doesn't mean they grasp how a wiki would work in an enterprise context.
For anyone struggling to understand how wikis can be used in business, I highly recommend Stewart Mader's Website Magazine article "5 Effective Wiki Uses." It's a quick read, but it lays out how (and why) wikis are effective tools for:
- project management
- customer/client collaboration
- documentation
- online community
- policies, FAQs, guidelines, and best practices
What I particularly like about Mader's article is that it goes beyond the hype to point out the diversity of potential wiki applications. For example:
A wiki can be especially useful for commonly needed information, like FAQ, guidelines, HR or purchasing policies. Editing permissions can be set so those responsible for these policies have the ability to edit them as needed and everyone else can read them. This eliminates the need to distribute paper copies of policies each time a change is made. Instead, the HR department can simply send an email announcing changes, with a link to the full policy page on the wiki.
Because so many people associate wikis with
Wikipedia and its "everything can be edited by anyone" philosophy, it's nice to
be reminded that enterprise wikis can have much stricter editorial policies.
It's possible to use a wiki to distribute information without giving all
readers the ability to add, modify, and delete content. (Note: For information on this, check out Mader's article "5 Differences Between Wikipedia and Enterprise Wikis.")
I know I've just scratched the surface on the great
wiki-related content out there. If you come across any articles or case studies, please share the links below.
Hello, Lauren, and thanks for highlighting Diplopedia to APQC members. I wanted to make a comment about Mader's recommendation for using wikis for definitive information. It is certainly true that one can restrict editing privilieges, but if you restrict them too much, then your "wiki" is just a content-management system, not a place for open collaboration.
The publishing policy constitutes the main difference between a "real" wiki and a web site that merely uses wiki software. A wiki's content is "innocent until proven guilty": it assumes that the contributors are responsible adults, and that what they contribute is probably valuable. Wiki articles are only locked down if a serious problem arises with them. Otherwise, changes appear in the open, where everyone can see them, and there is no "final" version of the article.
By contrast, a conventional Web site assumes that all changes and additions are problematic, and must be vetted by a central authority. That's a prudent method of managing a site for rules and regulations. But it's not a wiki.
Eric,
Thanks so much for your comment. I certainly agree that some of Mader’s suggested wiki uses do not represent “true wikis” in the sense you describe—and perhaps I was imprecise in using the term “wiki” versus “wiki technology.” However, I still think there is value in encouraging organizations to use wiki technology for a broader range of tasks, even ones that are less collaborative.
My reason for this is that any application of wiki technology will help users become familiar with the tools, how they work, and what they’re capable of. At the end of his article, Mader says: “In a very short time, people can learn how to use the wiki and put any one of these examples into practice. Once they do so, they will wonder how they got along without it.” Organizations or departments that don’t understand the concept behind or don’t feel comfortable implementing a “true wiki” like Diplopedia might be willing to experiment with a more restricted, limited application. Once employees start using the technology, it may be easier for them to see (and communicate) the benefits that a truly collaborative wiki would provide.
Lauren
Lauren and Eric,
This is the distinction between what I call "Internet Wikis" (ex: Wikipedia) and "Enterprise Wikis" (ex: the wiki your organization would use internally). The reality inside an organization is that some information does need to be secured, either from reading, editing, or both.
The principle I advise my consulting clients to use with an enterprise wiki is: "Share as much as you can. Secure only what needs to be private."
I see both Internet and Enterprise wikis are two different types of true wikis. On the internet, being 100% open is necessary to building healthy participation levels from a virtual community. In an organization, the people are already there (employees), so the wiki needs to be focused on allowing some control over access to meet the variety of needs and uses and become indispensable to employees.
To be clear on one thing, though, wikis and content management systems are fundamentally different . A content management system puts restrictions at the end of a process (i.e. people can submit content, but it must be approved before it's published), while a wiki puts any restrictions at the beginning of a process (i.e., a person has to have edit access to contribute to a wiki page, but once they have access, anything they contribute is immediately published and readable by others).
The chief place where access is important with Enterprise wikis is at the interface between the organization and the outside world. Enterprise wikis typically require an employee to log in (just as they would log in to access their email, the corporate network, internal WiFi, etc.) but beyond that, there's typically a lot of access and openness between teams, departments, etc.
Best regards,
Stewart
Stewart,
Thanks so much for the additional clarification. Your description of the differences between a wiki and a CMS is particularly helpful in this context.
One of the things I am taking away from this conversation is the fact that certain buzz words that we all throw around—“wiki” is a great example—mean different things to different people. I think some people see a wiki as any application of wiki technology, whereas others feel that the term implies a philosophy as well as a tool. When an organization is thinking about implementing a wiki, it’s important to explicitly define the term in the context of the project being contemplated and make sure all stakeholders are on the same page.
James Robertson of Step Two Designs has an interesting article about the various ways in which organizations can use wikis: http://www.steptwo.com.au/columntwo/two-uses-for-wikis/
His argument is that the two main uses for wikis in the enterprise are as collaboration tools and as intranets.
Lauren