Internal Wikis as Knowledge Base Tools

In my personal life I use this MediaWiki site to organize things that I have written over 20+ years as a blogger. My spouse uses multiple MediaWiki sites as internal organization tools for several groups; for example, he uses one to track and document specifications and history of work projects, another is for a radio group he is a part of and holds information about repeaters, squelch settings, and access rights.

I made the case at My Former MSP (MFMSP) that we should have an internal wiki as a knowledge base but there wasn't much interest. Instead it was argued that that information should go in Connectwise, or that it belonged in SharePoint. In my current position, I might hear the argument that this sort of information belongs in IT Glue - here are my arguments for why that isn't as ideal a solution as an internal wiki.

Ease of Navigation

Everybody knows how to use a properly configured wiki. It is intuitive to click between links and search for articles, it is easy to see that linked articles provide context that may be necessary to understand the project that you're working on.

I think that an internal Wiki would benefit from the familiar structure of Wikis and would make it faster and easier for consultants to learn about the products they're working with and to rapidly find information that will allow them to serve customers. Imagine that a client calls in with a problem - they are not able to access webpage and you don't know if it's because of their firewall or their antivirus. You check ITG and see that they are a former MFMSP client using ESET with a SonicWall Firewall. If a consultant has never worked with those before, they might be lost, or might have to take time to research the products before they can help the client. With an internal Wiki they could simply search "eset" for a quick rundown of what it is and frequent work that we do with them. They could search "sonicwall" and be directed to a page with information about different device types and different service levels and see a short menu right at the top of the page that could take them to "Procedures for Opening a Port for an Outside Vendor."

Wikis are easy to search globally, they include internal links that can help people contextualize the issue they're working on, and they can also link out to customer support pages for vendors like Pax8. Theoretically, a well-constructed Wiki could have an entire onboarding article that would link out to this information for new hires or people brought on through acquisitions.

So the navigation benefits of a Wiki are as follows:

• People are familiar with the format, which allows for rapid searching
• Articles can be easily interlinked, making it simple to gain context
• Wiki article structures allow users to quickly skip to the necessary information via menus
• Articles can contain outlinks to vendor sites (like Microsoft) and to specific internal documents (like ITG Passwords)
• It is extremely simple to create directory pages where you can group together different articles (so you could easily create a Microsoft directory or a VoIP providers directory) for quick reference

Navigation advantages over other options

• Sharepoint sites can easily fall victim to nested folders and unintuitive structures; while they are globally searchable, a search will turn up too much data in many cases as it pulls the searched terms from the body of the text. Wikis are not as subject to nesting issues because of the interlinked articles, a comprehensive global search, and all pages directories built into the platform.
• Connectwise knowledge base pages have a rigid structure imposed by the administrator, if you find that you need to write an article that doesn't fit the structure you need to ask for them to create a category to allow it; this is clunky and time consuming and makes things difficult to find.
• ITG is frustrating to search; while it is incredibly useful for documentation for individual clients it isn't a good place to keep general procedures.

Ease of Writing

Wikimedia sites are organized through wiki markdown language, which is a set of conventions for writing articles that creates a structure to the page. For example, I created the above header by putting two equals signs around the words "Ease of Writing" and I can create a subhead by putting three equals signs around another set of words, or create a higher-level heading by using just one equals sign. The way that I have created pages for Airespring and Sonicwall is by putting two square brackets on either side of those words. Double-brackets around a word that has no extant page will create a link to create that page in red like this: Football whereas double-brackets around a word that has an extant page will simply create a link like this: Firefox.

Markdown is easy to learn and allows you to write documentation leaving notes for yourself as you go. If I am writing an article about firewalls I can list the various kinds of firewalls that we work with in double brackets. Doing so will create empty pages for Meraki, Fortigate, and SonicWall. I can then finish writing the article about firewalls and either click on the red link to write an article about Fortigate, or I can go to the list of "wanted pages" in the wiki navigation and find a slew of pages waiting to be created.

This makes writing a Wiki easy in two ways:

1. Markdown makes it very simple to create structured, orderly pages.
2. "Wanted Pages" means that you don't have to stop and explain yourself every time you realize that you've stumbled across another subject that needs an article, functionally taking notes for you as you write.

Yes, it is Labor Intensive

Creating good documentation in any schema is labor intensive. There will be a lot of writing, there will be a lot of editing, there will be a lot of work. At the moment, we all have a lot of work because there isn't an easy-to-navigate form of documentation. If someone has a question about an app, they have to search the app themselves or log in to sites that use the app or check an individual client's ITG or search in sharepoint. There is no on solid starting point, so consultants fall back on asking each other or doing web searches and end up wasting time.

Making any good wiki is an enormous undertaking. Even this wiki that I use as a blogging tool has required significant effort to plan and construct. But it doesn't get any easier as you grow. We are at the best possible point to create an internal wiki as a knowledge base. We are integrating information from multiple MSPs (each with different practices and procedures), we are looking to add more clients and acquisitions to our company, but we are not yet so large that creating this kind of documentation would be an impossible undertaking. (And, hey, you've got a team member who happens to be a good technical writer who is fantastic at wiki management).

Making a knowledge base is never going to be easier than it is right now.

A Good Wiki is Never Done

Everyone knows that perfect is the enemy of good. Something that I think is less frequently discussed is that some is better than none.

If a business waits until it has perfectly organized knowledge base articles and fully idealized structures before rolling out a plan, then things don't get rolled out as the process is tinkered with. The great thing about a Wiki is that it will never be perfect. You start with one article, and then you expand. You fill in the gaps as they pop up, you correct outdated information as it arises. You make notes as you go, your wanted pages list is ever-expanding, but you end every article with more information available to readers than they had when they started.

This is also an intensely collaborative tool - I am good at writing wikis and good at formatting and good at structure. Perhaps Ben is NOT good at those things, but he has specific knowledge of a tool that nobody else has. Ben can still easily create a page on an internal wiki and write down what he knows, and someone can come in later and fill in more knowledge or format it in a more readable way. This would mean that our documentation is constantly evolving, while still keeping a visible history of the edits and changes made that we could refer back to.

A wiki knowledge base is something that could grow with us, incorporating information from future acquisitions and amassing a deep knowledge of tools, apps, and techniques that would serve to make us more efficient workers and better providers for our clients.

But our processes ARE documented

We have processes documented for individual clients in ITG and in Autotask checklists - these are GREAT for specific clients, but less great for general information. I'll use myself as an example here: Dan recently taught me how to reset passwords in AD. That's good knowledge to have! I'm aware that all of our consultants have that knowledge, but it would still be good to have that process laid out in case we end up hiring someone like me who doesn't know that, or doesn't know where to look for a domain controller password, or who isn't familiar with Datto (as the employees at MFMSP were not familiar with Datto until very recently).

Another example: Do you know how to create a Microsoft tenant for a new user at Pax8? It's not something that you do all the time, and it's not something you do multiple times for a single user so it's not going to be in ITG, but it is something that will come up occasionally. I have created a document that explains how to do that - but is it in my personal OneDrive where I keep documents that shouldn't be edited by other users? Is it in a SharePoint folder about vendors? Is it linked in the Ops chat? I can explain it to you - but what if I'm out sick, or on a call or in a meeting?

Or the Ops Procurement Process - I've described the procurement process a few times and have sent out a couple of explainers, but people who don't ask for quotes or pricing regularly forget, and then information gets lost.

We document processes for our clients, but not for ourselves. An internal Wiki wouldn't serve as a replacement for ticket checklists or for client documentation in ITG, it would be a place to get the information that we need without having it buried in a set of nested folders or sent in an email six months ago.

Concluding Thoughts

I think wikis are great, I think we need one, and I think that I could be a lot of help in developing this as a tool for our team.

Links on this page (for demo purposes)

• MFMSP
• ESET
• SonicWall
• Ops Procurement Process