ServiceDesk

 View Only
  • 1.  SD.IncidentManagement Modifications

    Posted Apr 13, 2012 12:31 PM

    As all of you know, ServiceDesk is not without flaw and most of us have to modify it heavily to make it fit into our organizations In light of recent developments with SD 7.5 and the fact that the primary process are being locked from modification, it might be nice to have a set of modifications that are currently done to SD.IncidentManagement by current SD clients and then allow Symantec to either respond now, respond at Vision or at least see what is being done a much broader scale then their relatively limited auditing of X number of clients. 

    I will start. The following are just a few of the modifications that we've had to make to just SD.IncidentManagement

    1. Emails - There are several email components in the process that need modification because the generic text just doesn't work.
    2. Additional Tasks - We've added additional tasks such as seraching our internal website and more.
    3. The ability to re-assign subtasks. This is currently not allowed by default, the workflow has to be modified to add this setting to subtasks
    4. Permissions - Since permissions aren't set granularly inside of the portal, we have to set additional permissions for different groups inside of the process.
    5. Email Groups upon assignment/reassignment - This one took a while. Certain groups, not all, like to be notified when they have a new incident or when an incident has been reassigned to them, however they don't like being emailed every time a subtask is changed or when the main incident has been changed. We have this working now after a long battle.
    6. General text and requirements - Most text in the resolve or work incident pages have been changed and we also don't require certain elements that are currently set to be required, both in incident re-assignment as well as incident resolution. (One being the category having to be selected all the way to the end of the hierarchy).

    These are just a few of the major changes that we have had to make. I invite you all to chime in with what you have had to do as well.



  • 2.  RE: SD.IncidentManagement Modifications

    Posted Apr 13, 2012 12:53 PM

    Top of my head...

    1) Multiple mailboxes - This was the beauty of Altiris 6 and going from the 10+ we had to try to sqeeze in to 4 mailboxes...   and if we are stuck on one???  

    2) Custom headers and footers based on classification (we have two level one support desks using this software)

    3) Changes to the incident management form in order and custom fields.

    4) AD look ups for information that the Service Desk db does not have.

    5) Notifications on priority changes, reassignments, VIPs, and e-mail responses to tickets.   Not the chatty Send Group e-mail stuff.

    6) Permission for any worker to modify any ticket.  

     



  • 3.  RE: SD.IncidentManagement Modifications

    Posted Apr 13, 2012 05:48 PM

    There are many things in the SD.IncidentManagement workflow that we did:

    1. Added a drop-down to change the status on the reclassify task. This is important for us because it allows the worker to have control of what the status of the incident is and not something from the processes

    2. Hid a lot of fields that we don't use on the reclassify forms

    3. Combined the Edit Incident Details task into the Reclassify and removed it

    4. When a reclassification is made it does not go out the Dialog Workflow so it does not send an email after doing so

    5. Hid the the Seach Google, Search Google Groups, Search MS Technet, Suggest Self-Service and Start pcAnywhere smart tasks. These should really be put in the Other Actions

    6. Added the ability to delete subtask templates. Added a sort so they appear alphabetically.

    7. Changed group email notifications to use the group email instead of the users in the group emails

    8. Set permissions on who can use certain smart tasks

    9. Set Admin permissions for those who work the ticket so they can view private comments (which is broken the way they have it)

    10. If a user chooses to reopen the incident in the resolve task, reassign the ticket back to the worker that resolved it

    11. Change the timeout of the resolve task to two days and send an email informing the user that their incident has been closed if it times out

    12. Changed the Set Task to Emergency in the Main Incident Work model to use the SD.RoutingRules instead of what was there

    13. Various changes to the emails to include more information

    14. Allow reassignments on sub-tasks

    15. Do a check to close all sub-tasks if the main task has been closed

    16. Disabled/bypassed forms that like locations and departments since we don't use that or to reduce the number of clicks required to do things

    17. Email the primary worker when all subtasks are completed

    18. Customized the survey

    That's just some of the things I've done to the SD.IncidentManagement workflow but the biggest one for us will be how they handle permissions. Our HR and Payroll staff are adament that no one should be able to view incidents assigned to them due to confidentiality and have adminstrative rights to remove users/groups from the incidents.

    I want to see how they handle permissions from the console but they're going for a one size fits all approach which won't fit the needs of many. Most of the things that we did are simple enough to do but we'll see if the Service Desk designers do them.

     



  • 4.  RE: SD.IncidentManagement Modifications

    Posted Apr 16, 2012 11:53 AM

    I have also done some of the same things. I also took away the option for the regular users to set the priority.



  • 5.  RE: SD.IncidentManagement Modifications

    Posted Apr 17, 2012 05:52 PM

    Another one that I remembered: 

    We add all groups and some users to the Reassignments selection pane so that our techs don't have to search each time they reassign and incident.



  • 6.  RE: SD.IncidentManagement Modifications

    Posted Apr 17, 2012 07:26 PM

    I wonder if they'll lock down the reassignment workflow which they really shouldn't. I don't think they'll add all the groups and users to the list and I know our workers will not be happy having to do a search all the time to reassign an incident.



  • 7.  RE: SD.IncidentManagement Modifications

    Posted Apr 18, 2012 09:40 AM

    We'll have to see. So far they've said just the primary processes but there are reassignments inside of SD.IncidentManagement as well as SD.IncidentEscalation and both locations need to be changed in order to make the look and feel be the same throughout ServiceDesk.

    I think that's another frustrating thing about SD; there could be many ways to perform a function which is the benefit from a workflow perspective but different workflows and projects that come with SD are done differently dependig on the project. An example of that is adding these groups. In one workflow you look up the group and add it to a variable collection, in another workflow you simply add each group to a variable collection directly! It makes making changes from a customer stand-point very complicated and I would imagine from a support standpoint its a nightmare. Standardizing how things are done could make everyone's life easier.



  • 8.  RE: SD.IncidentManagement Modifications

    Posted Apr 18, 2012 10:34 AM

    The biggest issue I have with ServiceDesk is it takes longer to get any tasks done as opposed to Helpdesk which is the only one we've used. Want to reassign a ticket easily? Nope, you have to do a search for someone instead of a drop-down or listbox. Want to create a ticket easily? Nope you have to go through 4-5 different forms confirming every action you do.

    Our workers just want to get in and out of the tickets instead of waiting for forms to load, clicking on endless confirmation forms (I've bypassed forms in our customization) and everything is unecessarily longer just for the sake of it. I hope the developers understand this when they're working on the 7.5 update because they really need to reduce the number of clicks to get things done.



  • 9.  RE: SD.IncidentManagement Modifications

    Posted Apr 18, 2012 10:57 AM

    Here is what would have been ideal (and the age between Altiris 6 and 7, IMO... they had some time)...   they needed to make a transition between helpdesk and ServiceDesk/ITIL.   This lack of transition caused some of the major workflow changes because you can only change so much of a process.  

     

     



  • 10.  RE: SD.IncidentManagement Modifications

    Posted May 01, 2012 12:14 AM

    One of the things we had to do was change the reopen assignments after the incident was closed to the worker that resolved the incident (both in the resolve/reopen task and after the incident is closed). Why they chose to assign tasks to Support I, Administrators, and Service Managers doesn't make sense to me especially if you've customized the SD.Email.Monitor to inform the workers when a ticket has been updated by email.

    I really do hope the developers are listening to the needs of users because when they lock down the processes we're at the mercy of how they think it should work and some of their decisions have been questionable.