We have already summarized 111 solid reasons for using an enterprise wiki. Now with the help of some concrete examples we are going to show you how an enterprise wiki can actually benefit your firm. We now close our series with 22 more concrete use examples.

We’ve already published 111 good reasons for enterprise wikis. Now we’d like to show through example use cases just what you can do with an enterprise wiki. //SEIBERT/MEDIA has distilled 66 examples for use cases. Let’s move on to use cases 23 to 44.

We have summarized in our weblog 111 good reasons for using an enterprise wiki. But how can such a system blossom and show its added value and Return on Investment? What are some concrete examples of how companies can implement an enterprise wiki? Which possible uses make sense? Which of them are truly useful? And which of them can actually improve your efficiency? We have collected 66 ways to use wikis in organizations. Here are the first 22.

Within a company there can be many approaches for the development of texts as well as the sharing of texts for further revision. We could, for example, write a text in Word and then load the final version into the enterprise wiki. We could also send around texts by e-mail, asking colleagues to read them and, if necessary, to make changes. But we could also develop a text directly within a wiki. What should we think of this particular work process?

More and more companies that already work with Microsoft products (so basically all companies) as well as those companies wishing to follow a “unified Microsoft strategy” are installing SharePoint as a solution for internal collaboration – Microsoft’s answer to the Enterprise 2.0 hype. Is MS SharePoint a real alternative to a sophisticated enterprise wiki application like Confluence? For this article, we have set up criteria that we believe a system must fulfill in order to suffice as a professional wiki system for companies.

A usability test, that only takes five seconds? Admittedly, it is almost too good to be true. The reservation against Five Second Tests, a specific form of remote usability testing, is great by and large. Experts traditionally place a lot of value on a clean methodology and clean results. Skepticism toward a new and simpler method is understandable. But Five Second Tests is the smallest project with a not insignificant benefit – as long as tasks and questions are selected sensibly.

If in the opening phase of a wiki adoption it should be difficult to activate employees to participate, this is often because employees haven’t been properly brought up to speed and misunderstand the whole idea of a wiki. One symptom of this is the fear of sharing knowledge.

At //SEIBERT/MEDIA, we’ve been doing our work on a wiki for years. Through our day-to-day work as well as through dozens of enterprise wiki projects, we’ve experienced – thanks to innumerable different example cases – how useful and valuable a wiki can be on a number of levels. Therefore, we believe it is high time to compress the arguments for a wiki into the limited space offered by tweets to make our points as efficiently as possible.

A summary of our journey with TwentyFeet until our launch. We tried a lot and made a lot of mistakes. The biggest was to overestimate the interest of big tech blogs and to underestimate the power of people like Robert Scoble. If you are working for a startup, you should read this.

Wikis for enterprise use, both those available commercially as well as those available in open-source contexts, have become quite sophisticated. This article introduces and evaluates possible requirements as well as decision-making criteria. An absolute necessity for the evaluation of a wiki system is that you have a clear picture of the requirements for the system – this is the first and most important step as there are numerous criteria and factors to consider when choosing the correct system.

The establishing of a Wiki is necessarily accompanied by a change in the communicative practices within a company. In comparison to technological and organizational aspects, the component of “company culture” typically plays a somewhat lesser role during the introduction of a Wiki, yet certain kinds of resistance can hinder the success of the project within this context as well.

From dozens of enterprise Wiki projects, we know that the successful introduction of a Wiki into a company typically depends on three factors: technology; organization; and culture. In the first of these three articles we focused on the requirements of technology. This report will now focus on the organizational factors for a promising Wiki project.

An enterprise Wiki is not only a new technology for many employees (at least within the company environment); it also requires a change in the normal communication- and collaboration patterns throughout the entire company. Through our experiences with dozens of company Wiki projects, we know that the successful introduction of a Wiki usually depends upon three factors: technology; organization; and culture. This article – the first of three articles on this topic – is dedicated to the challenges of technology.

This post outlines how you’ll probably use Google Wave in the future and also gives you advice on how to implement it in your company or your team of coworkers. It also reveals some big usability problems in the current version. Those issues aside, I would like to show you the advantages of the “wave” once again and describe some cool use cases that might make you love it at some point in the future.

A so-called mailto link automatically starts an e-mail program – even if you don’t even use this program. Mailto links on websites are problematic for three main reasons: They lead to usability problems, make tracking more difficult, and could also represent a security risk.

Many companies are unsure of how a successful Wiki-project should be started and executed. This article will give you an overview of this topic and inform you of the basics. //SEIBERT/MEDIA/ offers transparent services. Ultimately, as the saying goes, we’re also just cooking with water, but we’ve also collected many experiences regarding the process for Wiki-projects, which we will happily explain here – regardless of whether or not you are currently executing a project with us, are planning a project with us, or simply wish to be more successful with your Wiki – without our help.

What is going to happen when you are – always and everywhere – online? As a matter of fact, I haven’t advanced any deeper analyses regarding what would happen; I am merely offering a couple of thoughts. I would be happy to see comments and discussion about the following topics.

High opportunity costs can be incurred if the wiki layout isn’t customized. In this article, we will offer you a couple of arguments and explanations to answer why it is worth having your wiki professionally designed.

Without professional knowledge management, companies are losing potential, wasting resources, and acquiring unwanted competitive disadvantages. Industry giant Microsoft has rolled out its own application, SharePoint, which allows data to be centrally deposited and edited. But is MS SharePoint really a good alternative to a fully developed company wiki application? Our answer is a definitive “no”.

By using management dashboards, your company’s managers will have access to a better overview and more transparency. By dashboards, we mean graphical evaluations that represent certain quantifiable key numbers in charts and make time segments visible through trending. This compiles information into a critical mass in an easily understandable and accessible way.