[kwlug-disc] Recommendations for Help Desk/Knowledgebase software

[Oksana Goertzen]

Most Help Desk solutions include some knowledgebase component.  When we
moved
to the Help Desk solution we're currently using we did not move over our
knowledgebase.
I doubt that we would move over any of our current Help Desk framework.  The
knowledgebase
articles would be relatively easy to move over as they are simply files with
a few keywords
as organization... no search.  Only Tech utilizes this system.. so the
better part of say,
8 people... give or take a few.



On Thu, May 13, 2010 at 1:09 PM, unsolicited <unsolicited at swiz.ca> wrote:

> Oksana Goertzen wrote, On 05/13/2010 12:00 PM:
>
>  Hello All,
>>
>> We are entertaining some ideas around getting rid of our existing
>> Help Desk system and replacing it, hopefully with something open
>> source.  We also have a Knowlegebase system we use in Lotus Notes.
>> We'd like to consolidate those two things. Does anyone have any
>> recommendations?  We use ZENworks (ZCM) for desktop management, patching
>> and inventory, etc.
>>
>
> I don't have anything specific, but your description seems to indicate that
> you're looking to go beyond trouble ticketing to deployment as well. i.e.
> Subject line and desired functionality may not quite be the same thing -
> which is only to say, responders / repliers, make sure you respond to
> 'both.'
>
> - you might also consider, and consider specifying, your migration
> requirements. It will be a chore, no matter what you go to, to migrate
> things over, but no doubt some things will be easier than others, especially
> if you get to a short list of two and one looks to be more accommodating
> than the other.
>
> My own experience says:
> - Each iteration of the implementation of such functionality brings staff
> higher up the learning curve as they 'get their heads around this stuff'. A
> consequence of which is each new system moved to must be more and more
> capable, thus more and more complex and inter-related, and the effort to
> implement greater and greater. So, I guess, go into this with eyes wide
> open.
> - The single most important part of this process is for you and staff to
> sit down and define just what all you want it to do. Essentially, create
> pass/fail criteria, and a way to evaluate disparate functionality out to a
> 'which is best' decision.
>
> Some day I'll get around to implementing egroupware for myself, bringing
> the ticket <-> task <-> project relationship together. It's not going to be
> pretty, and I'm going to have to adapt myself to the software, not the other
> way around, but I expect the result to be worth the effort.
>
> I doubt, however, that egroupware will be as complete and sophisticated a
> solution as you are already running. Nor, as far as I know, has it any
> deployment aspects to it.
>
> _______________________________________________
> kwlug-disc_kwlug.org mailing list
> kwlug-disc_kwlug.org at kwlug.org
> http://astoria.ccjclearline.com/mailman/listinfo/kwlug-disc_kwlug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20100513/63ca15c5/attachment.htm>