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.gov<mailto: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 ITSM....but 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 pain....but then again...the users could create rules to auto-delete the ones that don't apply to them....I 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.ca<mailto: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, but we used the "Assign to Individual" practice, which is becoming increasingly more difficult as the group grows and as their support model grows. We are now at 7.6.04. I am looking at suggesting that we leave them in one support group, and I would add the "Product Name" field to the assignment notification message, allowing them to determine if the assignment is for them or not. My dilemma is on how to convince them that this would be the best way to proceed. Your input on this matter would be most appreciated. Thank you, Susan Champagne **************************************************************** The information contained in this e-mail and document(s) attached are for the exclusive use of the addressee and may contain confidential, privileged and non-disclosable information. If the recipient of this e-mail is not the addressee, such recipient is strictly prohibited from reading, photocopying, distributing or otherwise using this e-mail or its content in any way. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
