Five Key Differences between Wikipedia & Enterprise Wikis

wiki_use_pollEnterprise wikis (the ones primarily used at work for things like meeting agendas and minutes, managing projects, documentation and reports, etc.) and Internet wikis (Wikipedia and Wikitravel are popular examples) differ in several significant ways:

1. Organization and Access

Internet wikis often have all content housed in one “place,” so that anyone can access the entirety of the site’s content. Enterprise wikis, by contrast, allow for information to be organized in individual workspaces based on project, department, team, etc., and access to those spaces can be granted to specific people.

2. Security

Internet wikis are often open for anyone to read and edit, sometimes without even requiring one to login. Enterprise wikis are typically not open to the public or partially open, i.e. some spaces are open but others are not. To access an enterprise wiki, you have to login, and your account has to have permissions set so that you can access particular spaces. Permissions can also be set at the page level, so that a person might login, access a particular space, and have editing rights on some pages, but only viewing rights on others.

3. Integration

Enterprise wikis are designed to allow user account, group, and access information to be provisioned from authentication and authorization systems like LDAP and Active Directory, so that a person can login to the enterprise wiki with the same credentials that they use to access email, the company network, etc.

4. Typical Uses

Enterprise wikis are often used for:

  • collaboratively building documentation
  • creating and maintaining knowledge bases
  • project management
  • gathering tacit knowledge (knowledge not related to any specific project but essential to getting things done in an organization)
  • meeting management, from agenda to minutes and action items.

Generally, an enterprise wiki will be used in a much wider variety of ways than an Internet wiki, because it is intended to support the wide-ranging needs of the people within an organization. Internet wikis tend to be used primarily for one main application, as is the case with Wikipedia.

5. Contribution Level

On public wikis, we often speak of the 90-9-1 Theory, which explains that 90% of users will “lurk” or simply browse pages, 9% will contribute occasionally, and 1% will contribute frequently, and account for most of the contributions to the wiki.

On an enterprise wiki, the contribution level is much higher based on the fact that people are contributing as part of the daily course of their work, as opposed to voluntarily contributing to a public, Internet wiki. This contribution isn’t necessarily compulsory, as a top-down mandate will usually hinder more than help wiki adoption. Instead, it’s the result of well-executed wiki adoption strategies that place the wiki at the center of the core activities of a team, such as meeting management, building a support knowledge base, or collaboratively writing documentation for a product.

Share Five Key Differences between Wikipedia & Enterprise Wikis

13 Comments

  1. and one striking similarity : in both cases, wikipedia and enterprise wikis, some will ask : Can I trust the wiki content ?

    As there is no approval before publishing, some feel uncomfortable in trusting a wiki content, even in the enterprise context.

  2. @MB – I think you’re looking at it through the wrong lens. The traditional way we think about content is to assign someone to write a draft, which is then reviewed, changed, and approved.

    A wiki should be used for activities that don’t need levels of approval before publishing, and to influence a change to practices that require fewer approvals. Here’s how:

    Get your team to produce content together from the start. In this model, you don’t need approvals because people agree to be involved and provide constant input throughout the process, instead of only getting involved at a late stage to review and approve what others have produced.

    The notion of approvals has been created as a response to the practice where someone (usually a manager) is not involved in content production because they’re usually busy attending meetings. When an organization chooses to adjust the way they work at all levels, including better meeting management using a wiki, managers and others who would traditionally only approve content can now get more involved at that earlier stage, which reduces the need for the approval process.

    This is a different way of thinking about work, but it’s much more efficient for people at all levels. Inside an organization, you really shouldn’t have to worry about trust as much as you would on a public wiki. People are there to do their jobs, and an environment with a high level of trust is conducive to high quality work.

    In a recent New York Times article on the US State Department’s Diplopedia, Eric M. Johnson of the department’s Office of eDiplomacy remarked about trust and wikis: “There are plenty of ways to commit career suicide; wikis are just the newest one.” So if people are really worried about trust, then it’s a much larger issue that’s really unrelated to the wiki.

  3. Hi Stewart,

    may be my point was a bit off topic.

    Nonetheless, I guess points that may increase trust in the wiki content are :
    * content production process as you have describe it
    * space rights management : for example if you know that the “intranet network” section of the wiki is only editable by the network team, you may assume that the information found on that section is correct
    * no anonymous edits allowed : so that everyone is held responsible for content he/she writes
    * the wiki is the only place to find some information , that is there is no additional document to give information that is to be found on the wiki

  4. @MB Your latest points are right on target! Whenever I work with an organization on their internal wiki use, I advise them:

    * To require names be associated with edits, because everyone should be able to take credit or be held accountable for their contributions.

    * To make sure the structure of the wiki, i.e. the various spaces reflect the existing structure of the organization. As you say, people inside the organization should be able to rely on the idea that content in the “intranet network” space was authored by that team.

    * The wiki should be a Magnet for information, so that people get used to the idea that it’s both the go-to place to find what they need, and the place to add new information others will need.

    Stewart

  5. There are some additional characteristics that make a particular wiki more pertinent to the needs of an enterprise:
    1. Ability to integrate information from external data sources as well as to expose information to external tools and applications
    2. Provision of templates (and forms) for consistent and easy data entry (without requiring every user to be familiar with the wiki markup)
    3. Automated or easy cross-linking between wiki content
    4. Reusability of content (without copying and pasting or manually linking it everywhere)
    5. Easy and precise access to information
    6. Integration with MS Office
    7. Support for WebDAV

    zAgile offers Wikidsmart for Confluence that extends it to provide 1-5 above. Recent releases of Confluence also have support for 6 and 7, as well as the items you mentioned above.

    The open source product is available for download as well as hosted for an easy test drive. http://www.zAgile.com

  6. Kristi Kuhn says:

    Enterprise wikis seem to be just for the company and workers, not the readers; while Internet wikis allow the readers to have more of an input into the content. Personally, I think the Enterprise wikis need a lot of security because it has work-related content and is important to the worker as well as the company. Internet wikis are wonderful because comments and information can be shared easily. The Wikitravel is a wonderful tool that I have discovered and love reading the different travel guides.

  7. As per point 1 I agree that Enterprise WIKIs are usually deployed based on project or department basis. However, I would like to stress that the Enterprise should make this information available to the whole organisation (given the correct access rights) as part of its ECM strategy – removing the continuation of information silos.

  1. uberVU - social comments - Nov 19th, 2009

Leave a Comment

WIKIPATTERNS
A Practical Guide to Improving Productivity and Collaboration in Your Organization
  • Amazon.com
  • Enterprise Wiki Software Guide
  • Design Pattern Library
  • Wikipatterns book: a practical guide to improving productivity and collaboration in your organization

    USING WIKI IN EDUCATION
    Case Studies from the Classroom
  • Amazon.com
  • Teaching Students to Share Knowledge
  • Examples & Resources
  • Using Wiki in Education wiki book


    Email Twitter RSS
    Loading
  • Monthly Archive and 'Best of' since October 2005
  • 21 Days of Wiki Adoption Video Series English | Hebrew
  • 8 Things You Can Do With an Enterprise Wiki
  • Failure to Launch: Factors Behind Stalled Wiki Adoption
  • How do Successful Institutions Respond to Change?
  • Your Website as a Museum; Your Content as Exhibitions
  • Lock-Step Equity: Knowledge Sharing & the Bottom-Line
  • Info Wants to be Free. It Also Wants to be Expensive
  • How to do a Better Job of Project Collaboration
  • Starting Your Company's Wiki? Don’t Forget Design
  • Research Report: Why Businesses Don't Collaborate



  • random image

    PHOTO ESSAYS
    Click the photo above, or choose a photo essay from the list
  • Airbus Factory - Toulouse, France
  • Istanbul, Turkey
  • Porto, Portugal
  • Sydney, Australia