http://www.ilient.com/Sysforums/posts/list/109.page JForum - http://www.jforum.net
Now not only is IT using it to track SR and projects but so is our Building Maintenance group and our Manufacturing Area is using it to track SR for the machines.
They are also exploring the option of using the Knowledge base to manage all their process documentation.

We were looking into Sharepoint to handle their needs but now that I showed them SysAid they claim that they do not need Sharepoint and it does everything that they wanted Sharepoint to do.

Thanks This is a great product.

**By the way, I want a mug/t-shirt**]]> http://www.ilient.com/Sysforums/posts/preList/287/694.page http://www.ilient.com/Sysforums/posts/preList/287/694.page GMT But I haven't decided yet cause I set the SR count as my div's performance indicator. So if I let others in I will lose the automatic tracking I enjoy now cause there will be overhead to "clean" the raw data and do analysis.
]]> http://www.ilient.com/Sysforums/posts/preList/287/703.page http://www.ilient.com/Sysforums/posts/preList/287/703.page GMT How I handle this is to make a report that filters out the categories related to the other departments.
Therefore I can have the reports automatically dump into my email on the first of every month reporting on last month’s numbers.]]> http://www.ilient.com/Sysforums/posts/preList/287/704.page http://www.ilient.com/Sysforums/posts/preList/287/704.page GMT
Most important thing to me was helpdesk function worked

Mind you in saying that would it be good if you could issue different call types for different emails

ie email helpdesk gets called SR

and email to maintenance gets called MR

etc?]]> http://www.ilient.com/Sysforums/posts/preList/287/739.page http://www.ilient.com/Sysforums/posts/preList/287/739.page GMT
Most important thing to me was helpdesk function worked

Find you in sayign that would it be good if you could issue different call types for different emaisl

ie email helpdesk gets called SR

and email to maintenance gets called MR

etc?[/quote]


I did think about getting another copy but I wanted to have only one place to enter all service requests.
This makes it easier on the end user.]]> http://www.ilient.com/Sysforums/posts/preList/287/742.page http://www.ilient.com/Sysforums/posts/preList/287/742.page GMT
I did think about getting another copy but I wanted to have only one place to enter all service requests.
This makes it easier on the end user.[/quote]

I did not want people ringing helpdesk about bulbs or quality issue we get enough call and it has taken enough time to educate people about logging calls correctly with out confusing them ! ]]> http://www.ilient.com/Sysforums/posts/preList/287/744.page http://www.ilient.com/Sysforums/posts/preList/287/744.page GMT Sooner or later those non-IT users will want something change on the system and if you already got legacy data on it... THEN you got real dilema.
I'd like to hear what ilient take on this before I go all out on it.]]> http://www.ilient.com/Sysforums/posts/preList/287/759.page http://www.ilient.com/Sysforums/posts/preList/287/759.page GMT I'd like to hear what ilient take on this before I go all out on it.[/quote]

Both options are working but not perfect. We can list the pros and cons of each method and its up to you to decide which to use.

[size=18][u][b]Option 1 - One SysAid instance that supports IT, maintenance, HR etc..[/b][/u][/size]

In this option you have administrator from multiple departments in one SysAid instance. You need to create admin groups and assign administrators to admin groups. You need also to change permissions so administrator can view/change only SRs assigned to their admin group (e.g. you do not wish that IT will view SRs from HR that might have sensitive information about employees). Then you need to setup the categories usually that the first level will be the target department. The next step is to configure routing rules from each main category to the admin group. You can also configure multiple incoming email account so email sent to HR@mycompany.com will have the correct category.

[b]Pros:[/b]
• One instance of SysAid – less maintenance.
• One end user portal for users.

[b]Cons:[/b]
• Less flexibility as some of the rules cannot be configure for admin group. E.g. you cannot have different working hours for HR and IT.
• You will have only two levels of categories because the main level is taken for the admin group.
• The end user portal is not only for IT now.
• Hard to have special form / fields for each service department.

[size=18][u][b]Option 2 – Multiple Sysaid instances[/b][/u][/size]

In this option you install SysAid instance for each service department. E.g. one SysAid for IT and one separate for HR.

[b]Pros:[/b]
• Much more flexibility – each service department can have a totally different configuration.
• Each department will have separate end user portal.
• You can define special fields and form for each service department.

[b]Cons:[/b]
• More maintenance. However SysAid do not require intensive maintenance so its not too hard to support t multiple systems.
• The SysAid agent can work only with one SysAid and you can install only one SysAid agent per machine. That means that the SysAid agent will work with SysAid IT and other system will access the end user portal with direct link. Workarounds for that are to enable Single Sign on (so users will not have to login for each instance) and customize the end user portal so it will have links (and icons..) to the other SysAid instances.


I did not add cost to considerations because actually the extra cost will be very similar between the options.

I mentioned before that both options are not perfect however I think that the benefits to have SysAid for all the service departments are much larger then to wait that we will have better solution. Currently we have many success stories of SysAides who extend SysAid to all departments some of them use option 1 and some option 2.


Some suggestion to improvements we plan:
• Option 1 - Have more flexibility to define rules for each admin group.
• Option 1 – Create separate form for each SR type.
• Option 2 - Better integration with multiple SysAid instances.




]]> http://www.ilient.com/Sysforums/posts/preList/287/773.page http://www.ilient.com/Sysforums/posts/preList/287/773.page GMT http://www.ilient.com/Sysforums/posts/preList/287/791.page http://www.ilient.com/Sysforums/posts/preList/287/791.page GMT Do not underestimate the complexity and scalability of legacy data.
Once officially used it will be real production data that will populate sysaid. If for whatever reason it doesn't work it will potencially be a hell to migrate those data from sysaid to something else.

Hence Besides this fine points :
• Option 1 - Have more flexibility to define rules for each admin group.
• Option 1 – Create separate form for each SR type.
• Option 2 - Better integration with multiple SysAid instances.

Two other crucial improvement that will determine sysaid survival in the industry is backward compatibility among it's own version as the modules grow (the cmdb thing should shed some light by now) and open architecture (not necessarily open source...) that leave users' options open when sysaid simply do not fit in the company's business process and or policy (as the company grow I mean so whatever feasibility study before procurement is irrelevant).

On a more practical aspect, until the ability to produce reports/charts of sub category is provided... implementing sysaid for other division now, on my site, will do more harm than good.

]]> http://www.ilient.com/Sysforums/posts/preList/287/3422.page http://www.ilient.com/Sysforums/posts/preList/287/3422.page GMT On a more practical aspect, until the ability to produce reports/charts of sub category is provided... implementing sysaid for other division now, on my site, will do more harm than good.
[/quote]

100% agreed.]]> http://www.ilient.com/Sysforums/posts/preList/287/3423.page http://www.ilient.com/Sysforums/posts/preList/287/3423.page GMT On a more practical aspect, until the ability to produce reports/charts of sub category is provided... implementing sysaid for other division now, on my site, will do more harm than good.
[/quote]

100% agreed.[/quote]

This is already in development process and will be available soon in our upcoming version! [url]http://www.ilient.com/Sysforums/posts/list/296.page#778[/url]
Also, full backward compatibility is always a key factor of new developments,
The key to a successful product over time is finding the right balance between [u]new features and modules [/u]Vs. [u]compatibility [/u]to previous versions.

Oded
]]> http://www.ilient.com/Sysforums/posts/preList/287/3429.page http://www.ilient.com/Sysforums/posts/preList/287/3429.page GMT And it will be quite an achievement if that could be consistently done cause even some of the worlwide leading software companies can't deliver....]]> http://www.ilient.com/Sysforums/posts/preList/287/3433.page http://www.ilient.com/Sysforums/posts/preList/287/3433.page GMT
Sometimes incompatibility is part of the business model. Sometimes even Software with marginal usability is quite successful (and earns a lot of additional money due to the necessary consulting...), just have a look at SAP. ]]> http://www.ilient.com/Sysforums/posts/preList/287/3435.page http://www.ilient.com/Sysforums/posts/preList/287/3435.page GMT
That's how SAP and *ehem* others.... got away with it.
*wicked smile*

]]> http://www.ilient.com/Sysforums/posts/preList/287/3447.page http://www.ilient.com/Sysforums/posts/preList/287/3447.page GMT