This blog post is also available as a guest article at Atlassian’s Confluence Blog.
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.
1. Open-Source-Software or a commercial wiki product?
In principle, it is necessary to differentiate between free open-source wikis and commercial systems. Does your company like using open-source-software? This is by no means an exception: Within the open-source domain, there are professional, sophisticated systems supported by large, engaged communities. Moreover, open-source is, well, “sexy”. Or would your company prefer to avoid open-source-software? That is also not out of the ordinary and completely legitimate. Many companies show a clear tendency towards one or the other of these two directions.
2. Price?
Is your company ready to pay licensing fees for a wiki? Which fees will be required for which system? Regarding commercial systems, you have to consider costs beyond the simple purchase price, such as the follow up costs for support as well as plug-ins, assuming that these will in some cases be necessary.
3. Are high quality plug-ins available?
The expansions are what make wikis into real enterprise wikis. Are processes that you wish to depict supported by suitable expansions? Are these plugins fully developed? These questions require the testing of the available expansions for stability and quality.
4. Does an active community already exist?
It’s important that enterprise wikis are consistently undergoing further development. Enterprise 2.0 is an extremely fast growing field within which new demands and possibilities are constantly arising. If there’s no development community latching onto new trends and understanding performance wishes, then the system is quickly out-of-date. Is free support through the community – which is normal for many wikis – guaranteed? How many different service providers are there and what is the quality and depth of knowledge of these service providers?
5. Is this particular Wiki a known quantity?
No company has a burning desire to be the first to discover that a seemingly innovative solution is actually no solution at all. Enterprise wikis have been around since 1998. We strongly advise taking a look at who is established and respected in this field. This is why references and experiences from other companies and service providers with wiki experience play such an invaluable role.
6. What kind of technologies?
Which programming languages are being used (e.g. Java, Perl, PHP)? Is the wiki based on a databank (e.g. mySQL) or on files? Should the wiki be integrated into a company-wide search system? What kind of demands will there be on performance and scalability? Here, of course, your IT department will often list certain requirements. Experience shows, however, that demands such as “Only Java!” or “In any case mySQL!” play no role at all in the day-to-day operations of the wiki or even the systems administration.
7. System functionalities?
The range of functions is a decisive criterion: The wiki needs to be able to depict business processes and must be able to fulfill the demands posed by day-to-day work. When evaluating functionality, you should invest a significant amount of time. Does the system offer a well-thought-out, flexible plan for granting permissions? Can you set up different wiki areas? Can the wiki display, for example, tables, charts, etc.? Does the system offer a native WYSIWIG editor? And so on.
8. Usability and Design?
Motivating employees and creating a critical mass of users are both critical factors for success when introducing a wiki. Ideally, workers should use (happily) the wiki every day and see it as a permanent, integrated component of the infrastructure. Does the software fulfill central usability standards? Is the GUI easy to use? Can the layout of the wiki be adapted to fit the corporate design of your company? How difficult is the administration?
9. Requirements for the project?
Should the enterprise wiki only be implemented in certain departments or across the board? Is it a test run based on the initiative of a department or a full-on rollout following a company decision? How many users are there likely to be? Scalability and the prerequisites for smooth integration into the existing IT-infrastructure play an important role during the introduction of the wiki.
10. Migratability of the data?
Many companies would like – or even need – to keep open the option to move their data at a later date and transfer it into other systems. So can the data be migrated into another system in the most automatic way possible? How difficult is this process?
11. Does the wiki offer simple system administration?
Very important factors for simple system administration include fast backups, updates that can be easily installed, the possibility of reacting quickly to exploits, etc. Also, you shouldn’t forget during the evaluation to make sure that you can run the wiki on various operating systems.
In our experience, technology is not the most important factor for a wiki project (organizational measures are much more critical for its success), but you shouldn’t ignore it entirely, either. It’s important to analyze your company’s requirements very early on in the process and to find which system will most optimally support the processes that should be depicted. //SEIBERT/MEDIA can help you do this.
Are you considering introducing a wiki? Are you evaluating promising software? Do you need support with an up-and-running wiki project? We are experts in business communication and would be happy to consult with you, so please contact us.