As an MSP you’re going to hear customer complaints about a myriad of confusing technologies. That can be both a blessing and a curse, especially when it comes to managing a company’s policies and procedures. Throw in document management and you understand why so many people both worship and despise a product like Sharepoint. Everyone knows how incredibly powerful Sharepoint can be when managed properly. But there are situations where Sharepoint is overkill and a simpler solution might be a better choice.
I’ve worked for a number of small companies that push Sharepoint aside in favor of a homegrown solution. I’ve seen them attempt to integrate WordPress or Drupal into their workflow with mixed results. Your solution may have worked well when you had 10 employees, but does it scale to 50 or 100 or more? Unmanaged or undermanaged internal sites will collapse under their own weight if not maintained. I recall taking a business trip for a small company that had buried its travel policy so deeply on a Sharepoint site that nobody ever consulted it. Have you ever been told to find a document on your intranet, and couldn’t find it? We’ve all been there, but what can be done?
This week, I want to look at why MSPs might consider installing a workplace wiki for their customers (or even themselves) instead of SharePoint or another intranet software solution. A wiki is generally simple to manage and easy to update and provides basic collaboration tools for teams. I’ve spent most of my career using Sharepoint, and it works for many people. But it’s not always the best solution, especially for smaller companies whose documentation and policy needs are simple to moderately complex.
I’m able to see all my wiki contributions at a glance including edits at our company wiki
I should note here that wiki engines come in many shapes and sizes and are available from dozens of vendors. Most are free while a few are proprietary. They are frequently written in PHP, but Java and PERL are popular too. You can install wiki software on your own servers or pay someone to host it for you, similar to SharePoint. Of course, Wikipedia keeps an updated comparison of wiki software. I’m most familiar with MediaWiki, so that’s what I’ll reference in this article.
Before you dust off a server and begin installing a wiki engine, it’s wise to take a step back and consider your reasons for wanting a wiki in the first place. Let’s cover a few reasons to install your own wiki:
- You want to create an inexpensive company intranet anyone with a browser can access.
- You want to publish documents, policies and procedures to a central location.
- You want a central location where documents can be shared.
- You have many authors who will update the wiki frequently with meeting notes, agendas or new company procedures.
- Sharepoint is too expensive or too complicated.
To be fair, there are reasons why a wiki might not be a good choice. They include:
- You’re looking for blogging or newsgroup features.
- Your company manages complex file formats. Wikis are great with HTML, but may not support advanced file types without plugins.
- You don’t have someone who can maintain the wiki once it’s running.
- Your company demands lots of oversight and peer review. Wikis can be free-wheeling which may not fit your company’s culture.
Your decision to implement a wiki for a customer might not come down to the bullet points I provided, but they are good start for assessing your needs. You may be asked to install a wiki for a customer who requires more advanced content management tools found in SharePoint. Helping your client understand what a wiki can and can’t do will help them understand your desire to provide them with a platform that matches their needs. A wiki is for many, but not all.
Each company has information that’s available to all employees such as the employee handbook, travel guidelines and expense report procedures. Other information such as employee information and financial information will need to be locked down. Each wiki engine handles security differently, but all allow the administrator to apply security to areas of a wiki, even setting up security groups. For example, marketing might have full access to add, edit or delete pages within the Marketing section of the wiki, but have only view privileges in the HR area section of the wiki. These settings are applied when the administrator creates an employee profile.
Even if the wiki engine you choose doesn’t provide the level of security you company demands, plugins are probably available that give you even more granular control of the site and its contents. Advanced security features can be found in the documentation section of the wiki engine.
SimpleSecurity is an extension that extends the native security of MediaWiki
If you find yourself creating complex security models for your team, a wiki may not be the right tool for your group. For example, using our wiki to disseminate information that changes over time, such as an event list for the marketing team is where it thrives over other solutions. Employees who contribute to these events can subscribe to the page listing all events and will be notified when changes to the page have been made, much like RSS.
So you’ve created this fantastic wiki full of valuable company information, and you want to make sure it’s not lost if disaster strikes. If you’ve offloaded hosting to another company, they should provide sufficient data backups on your behalf. But if you’re running a local wiki engine you’ll have the choice to store pages as separate text files or as records in a database. Generally, using a database provides tighter security and improved stability.
Most wiki engines store data in two places: database and file system. Most of your critical data will be stored in your database while skins, extensions and images will be found in the file system so you’ll want to confirm both are backed up regularly. As you might expect, wiki engines such as MediaWiki provide detailed instructions for manually backing up your wiki.
I’ve seen a number of small companies go the the text file route for one main reason: it makes backups a cinch because all you need to do is backup the directory that holds all those text files. This might feasible for small sites, but I strongly recommend using a SQL/MySQL solution for larger sites. This will give you the best performance along with ability to scale your site as it grows.
I had a boss who said he had a customer for life, he could get them using Sharepoint. That probably sounds derogatory on the surface. But he understood how difficult and time consuming it is to move off one system to another. The same applies to wiki engines, even if they are easier to install and manage. Once each department has populated their area of the website, they aren’t going to be thrilled to move it to another system anytime soon.
I’ve seen wiki engines installed that were seldom used and some that grew to become the backbone of internal communications. The success or failure of a wiki can often be tied to the whether or not someone within the organization was made responsible for it. An MSP might have advised and installed the ideal wiki engine for their customer. But if it’s left unmanaged, it will fail, just like any other website.
If you want to dip your toe into the wiki stream, try a hosted solution. Assign a couple of people to test it out without a lot of restrictions. Observe how they use it over a few months. Those within an organization who create content on a regular basis (policy makers, bloggers, marketers) make good wiki testers. I’ve not personally used a hosted wiki before, but Confluence is one I’ve seen mentioned over and over. They offer a free trial as well.
Have you installed a wiki engine for your group? If so, what engine do you prefer?