Why e-mail when you can wiki?

Whenever we have an ITAM conversation these days, it’s in the context of ITIL… and since ITIL is primarily a service framework, it leads into the integration of asset, service and change disciplines.

Just last week a customer, service desk manager, quizzed us about whether and how to use a knowledge base product that they own but haven’t implemented.

Here’s my take on traditional KM products for ITSM - meaning, the kinds of tools that come with or are sold with help desk tools, so you can track common problems and build a reference knowledgebase.

1. They’re pretty mature, and there are plenty of good tools available
2. The “out of the box” datasets that are available will cover a lot of common problems
3. The really hard (expensive/laborious/tedious/unrealistic) part for most customers comes when they realize that it’s their custom apps and unique problems that most need a KB, and someone has to manually create and review that info.
4. That’s where the discipline breaks down and you get a “half-done” implementation.

Now, here comes a new idea - Wiki’s. If you haven’t heard of it, check out www.wikipedia.com. The basic idea is a web-based, user editable encyclopedia.

So let’s apply this to an IT shop:

1. You can open the content to everyone from end users to developers.
2. It’s a true collaborative model: everybody gets to comment, even _edit_ the entries. Of course for sensitive info you’ll want some controls.
3. The Service Desk agents have a quick, keyword-based way to look up common problems that are specific to their environment.
4. 2nd, 3rd level and management can share info like code comments, even change information - the structure of a wiki is so open that you can take it almost any direction. A wiki could be a faster/easier/more effective way to track this info.
5. In general, you could use a wiki to be the catch-all respository of unstructured info that would otherwise stay locked in the various silo’s of help desk, change, app dev, user communications, etc.

Here’s a great quote from the article:
“You’re fostering greater transparency and a culture of working openly,” said Ross Mayfield, CEO of Socialtext. “It helps break down false silos and provide more shared knowledge that people can build on. With a wiki, you’re sharing control over a resource that anyone can edit. That shared control over time actually fosters trust. That’s one of the intangibles of value inside the enterprise. But imagine what it might mean between trading partners.”

Now, the downsides:

1. It’s open source. You may have policy roadblocks for that. You may also need new skills and of course you’ll need labor time to set up the technical implementation.
2. You’ll need an evangelist, maybe several - maybe one for each major silo in your IT shop, plus one or more for your customers. And of course like any project / application rollout, you might want a full project / change / adoption plan.
3. It’s not as structured as some of your silo tools (a help desk KB or a code library for example). Your pilot testing might end up telling you that you’re needlessly duplicating data or effort.
4. It’s not as mature as the silo tools - security and controls for example might not be where you need them.

My advice? Start small and simple, do it as a pilot test with a defined user group, learn some lessons and gradually scale up.

Scott Braden

Technorati Tags: asset management software asset manager software license fixed asset manage configuration management itil asset software audit standardinternal audit project management

—–