FW: [EXTERNAL] Re: Support Groups: Best Practice?
Susan: I’m going to jump in here and say that we’ve gone down the “better granularity” path and it’s not everything it’s cracked up to be, though it does make some kinds of reporting easier. To give you an example of what I’m talking about, our primary service desk alone currently sits at about 13 support groups. And our application support folks (we currently have about 107 app support groups) want a separate support group for every application. This makes for really cluttered picklists and creates a lot of confusion about where to assign things, even when the service desk has work instructions from the support group in question. People who want to be in several groups for oversight purposes complain about the number of notifications they receive. A lot of people set up Outlook rules to move EVERYTHING from our ITSM Prod server to somewhere else and end up missing a lot of the notifications we send them, and then complain that ITSM isn’t sending notifications (I kid you not!!). We created a customization for IM where if an email is sent to our Prod server and the Subject Line includes the Incident ID, that email gets added to the Work Info for that ticket. I use that feature regularly so I can sidestep the most common Outlook rules that people tend to set up. The trick to doing things the one support group way is you have to make sure there is a way to do three things: 1.Assign the tickets appropriately. For how we do business, the assignment rules are woefully inadequate. For our desktop support groups, we’d love to be able to assign tickets to the Supported By group for the CI, or at least based on CI location instead of customer location. Some groups have individuals assigned to dispatch tickets, but not all groups need that, and the easier you can make this for your groups, the better. 2.Manage the different types of requests once they’ve been assigned. With 7.6.04 (what we’re currently on), you’ll probably have to customize your incident console by adding some fields from HPD:HelpDesk to pull this off. We’re looking at upgrading to 8.1 and one of the neat things about that is that there are a lot of fields from HPD:HelpDesk that individual users can add to the incident console, so it gives you greater flexibility in setting a default and users greater flexibility in configuring the incident console to show what is useful for them. 3.Report on the different things that need to be reported on. I think that gets harder with a single support group, because at least in our case, our Op and Prod Cats don’t seem to cover all the needs. And anytime you have to rely on human effort to categorize a ticket properly, there is always a margin of error, simply because people see things differently, and some don’t want to have to hunt around for the correct categorization, so they just pick something generic or something random. This might be easier with well-thought out Categorizations, though. A good approach might be to aim for something more middle of the road – add support groups only when there’s no other viable option to accomplish the 3 items above. Though if you have a CAB that oversees your ITSM changes, it might be good to take this discussion to them. Good luck! Natalie Stroud SAIC @ Sandia National Laboratories ARS/ITSM Reporting Specialist Albuquerque, NM USA nkst...@sandia.govmailto:nkst...@sandia.gov ITSM 7.6.04 SP2 – Windows 2003 – SQL Server 2008 From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Tuesday, July 08, 2014 8:37 AM To: arslist@ARSLIST.ORG Subject: [EXTERNAL] Re: Support Groups: Best Practice? ** Susan, I can't speak specifically to ITSM Support Groups, because I don't run ITSMbut sometimes what is best for the user is not best for the administrator. From what you have described, they want 35 support groups for better granularity of responsibilities, and of course, not all 30 members would be in all groups. As a user, I can tell you that receiving emails that are of no relevance to me, that force me to look at them to figure out if it applies is a painbut then again...the users could create rules to auto-delete the ones that don't apply to themI don't know...it's truly up to you...but the more granular groups may allow for better end reporting of issues :) On Tue, Jul 8, 2014 at 8:18 AM, Champagne, Susan schampa...@hsnsudbury.camailto:schampa...@hsnsudbury.ca wrote: ** Hi folks, I'm looking to get some advice on what the best practice is regarding Remedy support groups. I have a group of 30 support staff members, who support many different applications, and many individual modules in some applications. They are asking that I create individual support groups for each area of support. This would be 35 support groups. Originally, when we built the system in 2009 (7.0.03), we had one support group for these people
Re: [EXTERNAL] Re: Support Groups: Best Practice?
Thank you for your input Natalie, I am a one-person team supporting Remedy in our organization, so, I am always happy to have input from others. I will give your suggestions and guidelines consideration as I continue to chew this over. Susan Champagne From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Stroud, Natalie K Sent: July-08-14 11:21 AM To: arslist@ARSLIST.ORG Subject: FW: [EXTERNAL] Re: Support Groups: Best Practice? ** Susan: I’m going to jump in here and say that we’ve gone down the “better granularity” path and it’s not everything it’s cracked up to be, though it does make some kinds of reporting easier. To give you an example of what I’m talking about, our primary service desk alone currently sits at about 13 support groups. And our application support folks (we currently have about 107 app support groups) want a separate support group for every application. This makes for really cluttered picklists and creates a lot of confusion about where to assign things, even when the service desk has work instructions from the support group in question. People who want to be in several groups for oversight purposes complain about the number of notifications they receive. A lot of people set up Outlook rules to move EVERYTHING from our ITSM Prod server to somewhere else and end up missing a lot of the notifications we send them, and then complain that ITSM isn’t sending notifications (I kid you not!!). We created a customization for IM where if an email is sent to our Prod server and the Subject Line includes the Incident ID, that email gets added to the Work Info for that ticket. I use that feature regularly so I can sidestep the most common Outlook rules that people tend to set up. The trick to doing things the one support group way is you have to make sure there is a way to do three things: 1.Assign the tickets appropriately. For how we do business, the assignment rules are woefully inadequate. For our desktop support groups, we’d love to be able to assign tickets to the Supported By group for the CI, or at least based on CI location instead of customer location. Some groups have individuals assigned to dispatch tickets, but not all groups need that, and the easier you can make this for your groups, the better. 2.Manage the different types of requests once they’ve been assigned. With 7.6.04 (what we’re currently on), you’ll probably have to customize your incident console by adding some fields from HPD:HelpDesk to pull this off. We’re looking at upgrading to 8.1 and one of the neat things about that is that there are a lot of fields from HPD:HelpDesk that individual users can add to the incident console, so it gives you greater flexibility in setting a default and users greater flexibility in configuring the incident console to show what is useful for them. 3.Report on the different things that need to be reported on. I think that gets harder with a single support group, because at least in our case, our Op and Prod Cats don’t seem to cover all the needs. And anytime you have to rely on human effort to categorize a ticket properly, there is always a margin of error, simply because people see things differently, and some don’t want to have to hunt around for the correct categorization, so they just pick something generic or something random. This might be easier with well-thought out Categorizations, though. A good approach might be to aim for something more middle of the road – add support groups only when there’s no other viable option to accomplish the 3 items above. Though if you have a CAB that oversees your ITSM changes, it might be good to take this discussion to them. Good luck! Natalie Stroud SAIC @ Sandia National Laboratories ARS/ITSM Reporting Specialist Albuquerque, NM USA nkst...@sandia.govmailto:nkst...@sandia.gov ITSM 7.6.04 SP2 – Windows 2003 – SQL Server 2008 From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Tuesday, July 08, 2014 8:37 AM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: [EXTERNAL] Re: Support Groups: Best Practice? ** Susan, I can't speak specifically to ITSM Support Groups, because I don't run ITSMbut sometimes what is best for the user is not best for the administrator. From what you have described, they want 35 support groups for better granularity of responsibilities, and of course, not all 30 members would be in all groups. As a user, I can tell you that receiving emails that are of no relevance to me, that force me to look at them to figure out if it applies is a painbut then again...the users could create rules to auto-delete the ones that don't apply to themI don't know...it's truly up to you...but the more granular groups may allow for better end reporting of issues :) On Tue, Jul 8, 2014 at 8:18 AM, Champagne, Susan schampa