Comment Re:The answer is not *just* software. (Score 3, Interesting) 90
I must de-lurk for this topic.
My company is currently centralizing all of its IT functions from the 42 Europe-wide sites it has. Knowledge management is a nightmare, as the institutional knowledge is spread too thin among the old timers to make any impact for the new people. We have some processes documented, but by far not all of them. We decided we needed a written repository of knowledge, as we are growin at a rate where we can not afford to waste time.
We finally decided on MediaWiki, just like some of the others here have suggested, for pretty much the same reasons. It is just great for unstructured information, and the ability to categorize and very quickly link to other pages has turned out to be very useful. It is very quick to update - no need to muck around with HTML and uploading a page. Just hit Edit, change that IP from 223 to 23, click Save and you're set.
Converting existing Word documents to wiki format is essential for quickly populating the wiki with content. We have a lot of support documents with screenshots. I found out that the best way to do that is to save the Word file as HTML. It will export the images both as JPEGs and PNGs. The PNG is the image as it was imported into Word, at its native resolution, while the JPEG is a result of how it has been processed within Word itself (cropped / framed / recolored). I generally just grab the PNGs, unless the cropping was significant, as the JPEG resolution is fairly low. As for the text, I just grab the plain text from the document and mark it up with wikicode. Fairly painless.
Additionally, I also found a nice tool for converting Excel tables into wikicode, for all those worksheets with server IPs, domain functions and other stuff. Save your Excel as CSV then fire up the converter at http://area23.brightbyte.de/csv2wp.php. Just copy-paste (or upload), and presto! You have a nice wiki table. You can then mark it up with colors and other bling-bling if required. Again, I found the process to be relatively fast and painless.
Keeping with the wiki way, the majority of our pages have unrestricted access. Since I'm not a great believer in security through obscurity, we needed something to protect sensitive information - mostly passwords. The privileged few that need to know can get bumped to a higher security level and access these restricted pages.
http://conseil-recherche-innovation.net/index.php/ 1974/04/10/31-restrict-pages-under-mediawiki is a good page on how to restrict certain pages in MediaWiki. There is only one level of restriction though - the page is either restricted, or it isn't. To my joy I also discovered that while restriced pages also get indexed for searching, they do not show up among the search results if the user is not on the restricted level himself.
By the way, I full agree with the parent - the wiki by itself is not enough, you do need a librarian / knowledge manager to categorize all the braindumps and also to educate people on its mere existence. I also found that you need to pour a certain amount of info into the wiki before it reaches critical mass and people start to really use it. You do need to work a lot on it, especially in the early stages, with importing content. We didn't bother with scope definitions and categories and stuff - since all of this is so easy to change once the data is up, we'll just build it as we go along.
My company is currently centralizing all of its IT functions from the 42 Europe-wide sites it has. Knowledge management is a nightmare, as the institutional knowledge is spread too thin among the old timers to make any impact for the new people. We have some processes documented, but by far not all of them. We decided we needed a written repository of knowledge, as we are growin at a rate where we can not afford to waste time.
We finally decided on MediaWiki, just like some of the others here have suggested, for pretty much the same reasons. It is just great for unstructured information, and the ability to categorize and very quickly link to other pages has turned out to be very useful. It is very quick to update - no need to muck around with HTML and uploading a page. Just hit Edit, change that IP from 223 to 23, click Save and you're set.
Converting existing Word documents to wiki format is essential for quickly populating the wiki with content. We have a lot of support documents with screenshots. I found out that the best way to do that is to save the Word file as HTML. It will export the images both as JPEGs and PNGs. The PNG is the image as it was imported into Word, at its native resolution, while the JPEG is a result of how it has been processed within Word itself (cropped / framed / recolored). I generally just grab the PNGs, unless the cropping was significant, as the JPEG resolution is fairly low. As for the text, I just grab the plain text from the document and mark it up with wikicode. Fairly painless.
Additionally, I also found a nice tool for converting Excel tables into wikicode, for all those worksheets with server IPs, domain functions and other stuff. Save your Excel as CSV then fire up the converter at http://area23.brightbyte.de/csv2wp.php. Just copy-paste (or upload), and presto! You have a nice wiki table. You can then mark it up with colors and other bling-bling if required. Again, I found the process to be relatively fast and painless.
Keeping with the wiki way, the majority of our pages have unrestricted access. Since I'm not a great believer in security through obscurity, we needed something to protect sensitive information - mostly passwords. The privileged few that need to know can get bumped to a higher security level and access these restricted pages.
http://conseil-recherche-innovation.net/index.php
By the way, I full agree with the parent - the wiki by itself is not enough, you do need a librarian / knowledge manager to categorize all the braindumps and also to educate people on its mere existence. I also found that you need to pour a certain amount of info into the wiki before it reaches critical mass and people start to really use it. You do need to work a lot on it, especially in the early stages, with importing content. We didn't bother with scope definitions and categories and stuff - since all of this is so easy to change once the data is up, we'll just build it as we go along.
