|
|
|
www.ASPonline.com
|
ASP Forum
Wiki Format for Knowledgebase?
"We're thinking about adopting a Wiki format (collaborative
knowledgebase) for our Web support content. Has anyone tried
this approach or can offer advice?" Please share your thoughts.
—Nancy from Newark
Nancy,
"In Collective Wisdom: Transforming Support with
Knowledge", I recommended against using a wiki for
knowledge management. It's the one thing in the book I wish
we hadn't written.
The earlier posters are right—wikis can only work when
there is serious process around them to make sure that content
is findable, usable, and fresh. But if you use such a process,
like Knowledge-Centered Support (KCS), wikis can provide great,
flexible, and cost-effective support for it.
(To this point, it's important to distinguish between wikis,
the tools, and wikis, a way of collaborating. The completely
open and self-organizing way that wikis evolve—that is,
the process—isn't quite right for support knowledge,
although it's closer than most people suspect.)
We just put the first open-source Wiki-based implementation
through the Consortium for Service Innovation's KCS Verified
process. It's all free software, including the KCS
customizations. It's based on MediaWiki and Lucene. Let me
know if you're interested in piloting it and I'll send a link
with instructions.
—David Kay david@dbkay.com
Principal
DB Kay & Associates
We at SUNY Delhi have begun to use a wiki as a knowledge base
to suppert not only our help desk but also our longer term
strategic planning. The wiki is just one element as we move
from a Help Desk serving as a just-in-time service (call when
you have a problem and we'll fix it), to a strategic resource
for long term IT development on campus.
The idea is that issue tracking systems (tickets, systems
monitoring, etc.) populate the knowledge base with both the
incidents reported and the solutions provided (even suggested).
Issues that are either commonly reported, or require some
technical development are then open to all to assess, consider,
collaborate on, etc. by not only the IT staff but the campus
community as well. This then becomes our starting (staging
point) for our planning in IT development. As the original
issues are identified (through the initial report through the
Help Desk), assessed (needs/resource analysis) and then planned
(design, development, deployment), the wiki serves as a
communications channel that captures and distributes issues, a
collaboration medium between stakeholders to identify and
resolve issues and even a documentation tool to capture the
thought process and decision making for future reference.
Our system (using Atlassian's Confluence) is up at:
https://snydelwd.delhi.edu:8443/dashboard.action
University of Rhode Island's, as an example, is much more
developed. and is available at:
http://podcast.uri.edu:16080/~helpdesk/wiki/index.php/ITS_Helpdesk:Searching
—Patrick Masson massonpj@delhi.edu
Chief Information Officer
College of Technology at Delhi, State
University of New York
617/746-4670
Wiki will work fine as long as the number of posts is relatively
small, the people inputting knowledge items are closely knit, and
the overall team of contributors and users is small.
Wiki is unlikely to scale well, and if the content grows to an
order of hundreds or thousands of entries, the administration will
tend to become overwhelming.
The Wiki format would also not on its own provide the necessary QA
controls nor an ability to search or filter searches on things like
- peer ratings of the document
- ratings of the author
- re-use frequency
- category : such as version, product, product sub-area, etc.
- success ratings
- easy ability to promote to external publication (customers)
Consider how difficult it will be to weed out obsolete, never-used,
or poor quality items after doing using the Wiki for a few year,
and with several hundred documents captured.
—Matthew H. Loxton matthew.loxton@mincom.com
Director - Product Support Services
Wiki will work fine as long as the number of posts is relatively
small, the people inputting knowledge items are closely knit, and
the overall team of contributors and users is small.
Wiki is unlikely to scale well, and if the content grows to an
order of hundreds or thousands of entries, the administration will
tend to become overwhelming.
The Wiki format would also not on its own provide the necessary QA
controls nor an ability to search or filter searches on things like
- peer ratings of the document
- ratings of the author
- re-use frequency
- category : such as version, product, product sub-area, etc.
- success ratings
- easy ability to promote to external publication (customers)
Consider how difficult it will be to weed out obsolete, never-used,
or poor quality items after doing using the Wiki for a few year,
and with several hundred documents captured.
—Matthew H. Loxton matthew.loxton@mincom.com
Director - Product Support Services
We use Media wiki internally for a wide variety of things,
from reporting stats, to internal documentation, to project
plans, to sales information, etc.
It takes a real discipline to write the support articles that
you want to post and to organize them sensibly on wiki and you
would probably have to bolt in a search engine. We use the
Nutch search engine with our wikisite, which is also open
source. If you have the people to write the articles and
manage the site, then I think wiki is great and can be opened
to customers. It won't come together without a significant
effort and some dedicated resource.
—Harold Feinleib harold_feinleib@aperture.com
Aperture Technologies
[Any other advice on this question? Please send an email to
membership director Jane Farber at jfarber@asponline.com, and we'll
post your feedback.]
|
|
|
