Companies that want to convert from their current company wiki system to Confluence must overcome a few challenges: existing users are used to working with the platform, changing systems always involves trade-offs, and transferring existing content is complex and painful. In the previous article, we described these common challenges in detail. In this article, we will explain why the switch to Confluence is still a good idea and why the exhausting migration process is still worth the effort.
Wikis for intra-company usage are becoming well established as both commercial and open source applications. This article gives an overview of criteria and requirements involved in the decision making process, along with a comparison of our proprietary Wiki Confluence System and its open source competitors, Foswiki and MediaWiki.
All wiki systems have the same basic functions: opening, editing and saving documents. These functions can be covered in a single Wikipedia paragraph. The functions of a more advanced business wiki, however, are more complex. A business wiki is not simply a web lexicon, but rather is intended to systematically handle a variety of processes in the company.
In general, the establishing of a wiki must be supported through a series of measures. If these activities are successful, the system – as I know from my own experience – will quickly be accepted and used by employees. At //SEIBERT/MEDIA, TWiki has been used since June 2007, now containing a total of eight Webs. The main Web alone grew to contain more than 1000 topics within just a few months.
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.
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?
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. Following in the footsteps of examples 1-22 and 23-44, 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: the first 22 can be found here; now, 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.
At //SEIBERT/MEDIA, we’ve been working on a wiki for years. Through our day-to-day work as well as through dozens of enterprise wiki projects, we have experienced – thanks to innumerable different 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.