Most Help Desk solutions include some knowledgebase component.  When we moved<br>to the Help Desk solution we're currently using we did not move over our knowledgebase.<br>I doubt that we would move over any of our current Help Desk framework.  The knowledgebase<br>
articles would be relatively easy to move over as they are simply files with a few keywords<br>as organization... no search.  Only Tech utilizes this system.. so the better part of say,<br>8 people... give or take a few.<br>
<br><br><br><div class="gmail_quote">On Thu, May 13, 2010 at 1:09 PM, unsolicited <span dir="ltr"><<a href="mailto:unsolicited@swiz.ca">unsolicited@swiz.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Oksana Goertzen wrote, On 05/13/2010 12:00 PM:<div><div></div><div class="h5"><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hello All,<br>
<br>
We are entertaining some ideas around getting rid of our existing<br>
Help Desk system and replacing it, hopefully with something open<br>
source.  We also have a Knowlegebase system we use in Lotus Notes.<br>
We'd like to consolidate those two things. Does anyone have any<br>
recommendations?  We use ZENworks (ZCM) for desktop management, patching and inventory, etc.<br>
</blockquote>
<br></div></div>
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.'<br>

<br>
- 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.<br>

<br>
My own experience says:<br>
- 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.<br>

- 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.<br>

<br>
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.<br>

<br>
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.<br>
<br>
_______________________________________________<br>
<a href="http://kwlug-disc_kwlug.org" target="_blank">kwlug-disc_kwlug.org</a> mailing list<br>
<a href="http://kwlug-disc_kwlug.org" target="_blank">kwlug-disc_kwlug.org</a>@<a href="http://kwlug.org" target="_blank">kwlug.org</a><br>
<a href="http://astoria.ccjclearline.com/mailman/listinfo/kwlug-disc_kwlug.org" target="_blank">http://astoria.ccjclearline.com/mailman/listinfo/kwlug-disc_kwlug.org</a><br>
</blockquote></div><br>