Re: Product Categorizations and the Elephant Rhyme
Chris, Are you keying off the Site field to figure out which Tier 1 support group takes the incident? Jennifer Meyer From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of strauss Sent: Thursday, April 09, 2009 6:37 PM To: arslist@ARSLIST.ORG Subject: Re: Product Categorizations and the Elephant Rhyme If that is all that there is to the Service Catalog, then BMC has been blowing a lot of smoke about it in my opinion. Our CFG:ServiceCatalogAssoc contains the 53 Global CTI that our helpdesk defined before we went live and Don imported with Data Management, plus a few I added to support campus-wide outage reporting. We have another 154 non-Third Party Product CTI that we also imported or defined in four major categories: Computing Services, Desktop Software, Hardware, and Infrastructure. Don built all of this in consultation with the central helpdesk, who incorporated many of these CTI into their Incident templates. We gave every one of the colleges and departments, who each have their own Company, the ability to define their own CTIs within their company, but so far NO ONE has done so in almost a year of production. To me, a Service Catalog entry should exist at a hierarchical level above CTI, as was hinted at but not realized in ITSM 5.x, but I have never found that implemented in the ITSM apps in a practical way. The closest is the Business Service configuration item in Asset Management/CMDB, but like everything in the CMDB it is a Product categorization, not an Operational categorization. There does not appear to be any place that you can tie OpCats and ProdCats together under a defined IT Service at what I have always perceived to be the Service Catalog level. Whenever I have heard people talk about a Service Catalog, I was looking for something where you can define an IT Service like Payroll Services and it will have some OpCats for Incidents and Changes to use, and some ProdCats that define the system CIs and component CIs that make up the IT Service. Without the top-level connection, it's the same huge pile of incomprehensible categorizations that we cussed and discussed for the last decade, and finally discarded. I think we actually got the closest to this in our old 5.x app when we added a second tier to the Summaries in the Requester Console, and the top tier included things like Student Computing Services, Distributed Computing Services, and Administrative Computing Services as well as more specific things like Residence Networks. Even the helpdesk staff MUCH preferred to use the Summary menus (which carried over into Help Desk cases just like they did in the Requester -New Request form) to quickly categorize a ticket than to wade through the CTI menus, even after we gave them a pull-right hierarchical menu of the CTIs to navigate. Today they have learned to use the 40 some odd incident templates defined by their manager in almost the same way. Looking back, I don't see very many support staff on our ITSM 7 system making use of even the existing categorizations. I reviewed ~16,200 incidents from the last 11 months and the vast majority of those with populated categorizations (6,676) were either generated by Kinetic Request, or by the central helpdesk which uses incident templates wherever possible. The rest had no CTI whatsoever. Once ITSM 7 made it optional data, and without any emphasis from IT managers in most of our support groups to enter it for reporting, CTI usage plummeted. Something to think about if we ever want to do really detailed reporting. On the other hand, we have heard many comments over the last year that the support staff users like this version better than previous ones since they can get tickets into it quicker, so we gained in speed what we lost in detail. Your mileage _will_ vary! Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Meyer, Jennifer L Sent: Thursday, April 09, 2009 12:53 PM To: arslist@ARSLIST.ORG Subject: Re: Product Categorizations and the Elephant Rhyme ** Thank you, Chris, Rick, and Don for your feedback. Chris, Thank you for a very well-reasoned argument. I always value your input highly. As you said, there are a number of different ways to configure assignment in Remedy 7.X, and keying on CTI may not be the best method to use for every organization. Personally, I'd rather thoroughly train the first-level help desk in the business process and allow them to make intelligent decisions, but if that happened in the real world, we wouldn't need assignment rules. The assignment method was decided long before I joined the organization, and I'm not in a position to change it; however, neither is MET (Thanks, Rick!). The last time I
Re: Product Categorizations and the Elephant Rhyme
Hi Jennifer, I am answering this question for Chris Strauss. Short answer on keying off Site, is No. We key off customer organization/department-by legacy University practice. Therefore, the tier-1 support will be furnished by whatever support group is tasked to support that department (in the usage of Organization/Department within a Customer company). Added granularity is required for some Administration organizations, where one department among several is supported by, say, group 2 whereas everyone else under that higher-order entity is support by group 1. Then, I have built rules for all departments within that organization to guarantee full apportionment. For many groups on campus, rules at the Organization (or even Company!) level are sufficient. This triage frequently aligns with physical location-but not completely, and 'Site' is not our criteria. I hope this helps clarify our implementation. Don W. McClure, P.E. Applications Manager, Call Tracking Administration University of North Texas dwmac (at) unt (dot) edu From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Meyer, Jennifer L Sent: Monday, April 13, 2009 7:52 AM To: arslist@ARSLIST.ORG Subject: Re: Product Categorizations and the Elephant Rhyme ** Chris, Are you keying off the Site field to figure out which Tier 1 support group takes the incident? Jennifer Meyer From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of strauss Sent: Thursday, April 09, 2009 6:37 PM To: arslist@ARSLIST.ORG Subject: Re: Product Categorizations and the Elephant Rhyme If that is all that there is to the Service Catalog, then BMC has been blowing a lot of smoke about it in my opinion. Our CFG:ServiceCatalogAssoc contains the 53 Global CTI that our helpdesk defined before we went live and Don imported with Data Management, plus a few I added to support campus-wide outage reporting. We have another 154 non-Third Party Product CTI that we also imported or defined in four major categories: Computing Services, Desktop Software, Hardware, and Infrastructure. Don built all of this in consultation with the central helpdesk, who incorporated many of these CTI into their Incident templates. We gave every one of the colleges and departments, who each have their own Company, the ability to define their own CTIs within their company, but so far NO ONE has done so in almost a year of production. To me, a Service Catalog entry should exist at a hierarchical level above CTI, as was hinted at but not realized in ITSM 5.x, but I have never found that implemented in the ITSM apps in a practical way. The closest is the Business Service configuration item in Asset Management/CMDB, but like everything in the CMDB it is a Product categorization, not an Operational categorization. There does not appear to be any place that you can tie OpCats and ProdCats together under a defined IT Service at what I have always perceived to be the Service Catalog level. Whenever I have heard people talk about a Service Catalog, I was looking for something where you can define an IT Service like Payroll Services and it will have some OpCats for Incidents and Changes to use, and some ProdCats that define the system CIs and component CIs that make up the IT Service. Without the top-level connection, it's the same huge pile of incomprehensible categorizations that we cussed and discussed for the last decade, and finally discarded. I think we actually got the closest to this in our old 5.x app when we added a second tier to the Summaries in the Requester Console, and the top tier included things like Student Computing Services, Distributed Computing Services, and Administrative Computing Services as well as more specific things like Residence Networks. Even the helpdesk staff MUCH preferred to use the Summary menus (which carried over into Help Desk cases just like they did in the Requester -New Request form) to quickly categorize a ticket than to wade through the CTI menus, even after we gave them a pull-right hierarchical menu of the CTIs to navigate. Today they have learned to use the 40 some odd incident templates defined by their manager in almost the same way. Looking back, I don't see very many support staff on our ITSM 7 system making use of even the existing categorizations. I reviewed ~16,200 incidents from the last 11 months and the vast majority of those with populated categorizations (6,676) were either generated by Kinetic Request, or by the central helpdesk which uses incident templates wherever possible. The rest had no CTI whatsoever. Once ITSM 7 made it optional data, and without any emphasis from IT managers in most of our support groups to enter it for reporting, CTI usage plummeted. Something to think about if we ever want to do really detailed reporting. On the other hand, we have
Re: Product Categorizations and the Elephant Rhyme
Thank you, Don, that does help. Jennifer Meyer Remedy Technical Support Specialist State of North Carolina Office Of Information Technology Services Service Delivery Division ITSM ITAM Services Office: 919-754-6543 ITS Service Desk: 919-754-6000 jennifer.me...@its.nc.govmailto:jennifer.me...@its.nc.gov http://its.state.nc.us E-mail correspondence to and from this address may be subject to the North Carolina Public Records Law and may be disclosed to third parties only by an authorized State Official. From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of McClure, Don Sent: Monday, April 13, 2009 10:47 AM To: arslist@ARSLIST.ORG Subject: Re: Product Categorizations and the Elephant Rhyme Hi Jennifer, I am answering this question for Chris Strauss. Short answer on keying off Site, is No. We key off customer organization/department-by legacy University practice. Therefore, the tier-1 support will be furnished by whatever support group is tasked to support that department (in the usage of Organization/Department within a Customer company). Added granularity is required for some Administration organizations, where one department among several is supported by, say, group 2 whereas everyone else under that higher-order entity is support by group 1. Then, I have built rules for all departments within that organization to guarantee full apportionment. For many groups on campus, rules at the Organization (or even Company!) level are sufficient. This triage frequently aligns with physical location-but not completely, and 'Site' is not our criteria. I hope this helps clarify our implementation. Don W. McClure, P.E. Applications Manager, Call Tracking Administration University of North Texas dwmac (at) unt (dot) edu _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Product Categorizations and the Elephant Rhyme
I've followed this thread with interest. Although not directly related to why categorisations should be used for assignments, there are other reasons that Op/Prod Cats should be used. - KPIs that will allow the measurement of the effectiveness efficiency the IT services provided, the state of the infrastructure, and the processes themselves e.g. avg incident response/resolution times, assignment bounce - Reporting of the KPI's - And obviously, the assignment and workflow process. Ideally you're using the Op/ProdCat to support the auto-assignment in order to get the Incident to the correct place the first time, thereby reducing the need to bounce the incident to another queue if it is assigned incorrectly. The last thing that should be considered in the arguement is the initial vs actual Op/Prod Cat. The initial could be considered as the Op/ProdCat captured on the Classification tab However when the incident was resolved, the Op/Prod Cat on the Resolution tab captures the actual. E.g. we initially thought the incident was caused by a network outage, but the actual cause was the user failed to turn on their PC (with appropriate Op/Prod Cats to support both). So, although not answering your specific question around Op/Prod Cats Assignments, there are other benefits of why Op/Cats are useful to use. BTW if you haven't seen it already, take a look at thenew Incident screen on ITSM7.5 - the Op/Prod Cat fields are nowhere to be seen on the new Best Practice view. From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Meyer, Jennifer L Sent: Friday, 10 April 2009 12:24 AM To: ARSList Subject: Product Categorizations and the Elephant Rhyme ** Listers, Please help me with this one. One of my management users got hold of an external source that said categorizations don't have to be used for routing. Somehow, the user misunderstood what the external source was attempting to communicate, grabbed hold of the elephant's tail, and is now trying to tell us we don't need to use Incident assignment rules based on Operational and Product Categorizations to route tickets to the correct support group. Unfortunately, we route tickets in our system based on categorizations, but this user stubbornly clings to his part of the elephant. Of course, I have Rick Cook's excellent A New Paradigm of Generic Incident Classification, BMC's Best Practices documentation, and several other things I've dug up which refer obliquely to CTI (OpCats) and assignment. The problem is I ***KNOW*** CTI is used for assignment. You don't have to use it for that, but I've been using it that way since 6.X. It's so ingrained that I take it for granted that everybody else knows that, too. Does anybody have a best practices document that explicitly states that Incident assignment is based on categorization? Jennifer Meyer __Platinum Sponsor: RMI Solutions ARSlist: Where the Answers Are html_Platinum Sponsor: RMI Solutions ARSlist: Where the Answers Are html___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Product Categorizations and the Elephant Rhyme
Jennifer, you could show Mr. Elephant Tail (MET) books and best practices until the cows come home - if you haven't convinced him by now, you need someone else to fight this battle. I think I would suggest that you try these tactics: 1) Find the manager/director who uses the output data from the Assignments to make forecasts for support staffing, etc., and have that person explain the facts of life to MET. 2) Ask MET to suggest to the Support Manager how Incidents ARE supposed to be routed if Categorizations aren't used, and why he would want you to be the only Remedy customer on the planet to NOT use them for assignment (make him prove HIS concept rather than you defending yours). Tell MET that once he and the Support Manager work out how that would work, then you will support their decision. This will make MET carry his position to logical conclusions, where it will break down. 3) If the organization is heavily ITIL-centric, there must be a champion/guardian of that process somewhere around - sic that person on MET. 4) Figure out how much doing things MET's way would cost in customizations to product, longer MTRs, etc., and then have the Support Manager ask MET if he would like to fund that from his budget. 5) If it's possible (don't know his org chart relationship with you), ignore him and continue to do it the way you know best. The more pressure put on him to prove he's right, the more likely he is to back down as he slowly figures out he's wrong. Rick On Thu, Apr 9, 2009 at 7:24 AM, Meyer, Jennifer L jennifer.me...@its.nc.gov wrote: ** Listers, Please help me with this one. One of my management users got hold of an external source that said categorizations don’t have to be used for routing. Somehow, the user misunderstood what the external source was attempting to communicate, grabbed hold of the elephant’s tail, and is now trying to tell us we don’t need to use Incident assignment rules based on Operational and Product Categorizations to route tickets to the correct support group. Unfortunately, we route tickets in our system based on categorizations, but this user stubbornly clings to his part of the elephant. Of course, I have Rick Cook’s excellent “A New Paradigm of Generic Incident Classification,” BMC’s “Best Practices” documentation, and several other things I’ve dug up which refer obliquely to CTI (OpCats) and assignment. The problem is I ***KNOW*** CTI is used for assignment. You don’t have to use it for that, but I’ve been using it that way since 6.X. It’s so ingrained that I take it for granted that everybody else knows that, too. Does anybody have a best practices document that explicitly states that Incident assignment is based on categorization? Jennifer Meyer __Platinum Sponsor: RMI Solutions ARSlist: Where the Answers Are html_Platinum Sponsor: RMI Solutions ARSlist: Where the Answers Are html___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: Where the Answers Are
Re: Product Categorizations and the Elephant Rhyme
You're right as usual, Chris. But she said that they were already using Categorizations for Assignment. While testing paradigms is a practice we should all undertake, changing the entire support model is an undertaking that requires buy-in from all users and owners of the Support model. It doesn't sound like Jennifer's organization has those things in place. Categorizations are not REQUIRED for ITSM 7 Assignments to function. However, they may be required for the structure of your Support Organization to function, and they may be required for current reporting purposes. Just because you set the Cats from templates doesn't mean that they aren't being used, just that the values are automatically chosen. The broken 2000 Op Cats situation (which is not at all abnormal, BTW) is precisely why I cut through the Gordian knot with my idea for generic Op Cats. The bottom line is that the tool and the ITIL protocols are there to support the organization, not the other way around. Can the Support model change? Sure. Whether it should is for each company to decide. Rick On Thu, Apr 9, 2009 at 8:10 AM, strauss stra...@unt.edu wrote: ** I’m going to have to challenge your assumptions here, just as mine were when we first began testing the 7.x applications several years ago. I’m not sure that in 7.x it is a best practice to key on CTI anymore; the app basically discards it as a requirement, and the new 7.x assignment engine doesn’t even support it very well, not when compared to the very specific ways that CTI were processed in 3.x through 6.x applications. Based on our testing of the 7.x apps (where assignment rules using location and/or categorization no longer have reliable outcomes unless every rule is mutually exclusive) we decided to drop category as a determining factor, and key on Organization to tie our customers to a particular distributed support organization based upon their payroll accounting numbers. All tickets opened for a group of customers paid under one account (and assigned to a specific Organization in their location values) route to a particular distributed support organization by default, as set in an explicit assignment rule (there are ~25 desktop support organizations). When we have one Department in an Organization that needs a different routing than the others, the only way you can make that work in 7.x is to build separate, mutually exclusive assignment rules for EVERY Department in the Organization, not just the one that differs, or you will get inconsistent assignments. If you still want to incorporate CTI in the assignment processing, you will be forced to build all of the rules to be at the same level (C or T or I, not some combination of the same as pre-7.x) and make them mutually exclusive. Whatever you were using for 5.x or 6.x isn’t going to work. Our users are, quite frankly, much happier processing large quantities of tickets without any categorization at all, focusing on Assignment and occasionally Ownership. They only categorize them when they need to do so for reporting purposes, and we have facilitated that as much as possible by using a lot of Incident Templates to apply categorizations. They HATED the over 2,000 categorizations that we used in the 3x, 4x, and 5x systems, and don’t miss them at all in 7.x. The other way we have made this easy is to make a lot of the tickets entered through Kinetic Request use the same, pre-defined Incident templates, which can control not only the CTI but the assignment as well. Another factor in your use of categorization is going to be how your organization(s) does reporting. Here almost all reporting is by assigned and/or owner group, and was that way even when we had a VERY detailed categorization scheme. Our message to managers when we implemented 7.x was, if you want categories to report on, you will have to define the ones that are important to you (very few have), and then convince your IT staff to use them, as the 7.x app no longer enforces their use. Only the central helpdesk and a couple of the central support groups they work closely with have seen fit to define many CTIs, and they use them through Incident templates in order to help with their reporting. So in our perception, and in our analysis of the 7.x application behavior, CTI are no longer a driver for assignment, only for reporting. Don McClure did all of the testing on assignment rules, and will draft you a more detailed answer when he has a chance, but suffice it to say that the 7.x apps are no longer designed to use CTI as a primary driver for assignment, in part because they no longer do the kind of sequential matching that the earlier versions did that allowed you to make very specific automatic assignments based on different levels of the CTI data. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing IT Center http://itsm.unt.edu/
Re: Product Categorizations and the Elephant Rhyme
Jennifer-- I do not know of such a document. In fact, in ITSM 7.X that feature is not supported as one would like. Basic set theory is at work here: the assignment routine tries to match on a specific intersection (yes, set theory term, presumes all required terms are .true.) of ALL fields in the 'Routing Order' box where a value is entered. This transaction is a single set-theory 'union', where non-match of any one criteria sets a value of 'false'. Refer to the 'Routing Order' section of Assignment Configuration-each box can have a value, and those left blank are presumed to be 'wildcard' (match anything) for the purpose of assignment. The critera of 'Contact Company', 'Organization', 'Department', 'Category', 'Type', and 'Item' are all equally placed, NOT hierarchical, and a match on *all* is required to activate a particular assignment (of course, one field or more could match as a wildcard for that field only). In our experience, if more than one rule COULD match, the rule selected from among matches is indeterminate-we have verified that behavior via filter/SQL logging more than once in our endeavors. Therefore, the only way to guarantee *exactly* one rule match, is to make these assignment records mutually exclusive-so if one rule is generated for a combination of catagory/type/item within one 'contact' grouping, separate specific rules must be generated individually for ALL CTI within that contact. This principle also applies to grouping of operational CTI and product CTI-if one item is matched custom within product CTI and a particular operational CTI, separate rules are required for all other products within that operational CTI as well. The situation simplifies greatly in absence of Multiple Tenancy; if one only has one company, then this situation simplifies to JUST operational CTI and Product CTI.Yes, this is a paradigm-shift from earlier HelpDesk versionsand I'll bet most of us did not want to get this far into set theory again. Nicky and others-routing is simply an automation of an organization's selected processes. Our tier-1 groups here at the University are first-responders for incidents for their designated customer base, independent of operational or product categorizations. In fact, we usually prefer that customers NOT try to designate CTI-we see such designation as a support-staff function, and many user complaints on earlier HelpDesk versions centered on CTI being required by requestor on initial report! Don W. McClure, P.E. Applications Manager, Call Tracking Administration University of North Texas dwmac (at) unt (dot) edu From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Nicky Madjarov Sent: Thursday, April 09, 2009 11:15 AM To: arslist@ARSLIST.ORG Subject: Re: Product Categorizations and the Elephant Rhyme ** While we don't have the service affected identified in the incident, problem, change, etc. (end even if we do, I'd love to have categorization within the affected service) how can one route everything properly if not using the categorization. I have seen months spent by managements to determine proper categorization, and either way they end with too few or too many. My present approach is to embed the actual service (as per service catalog) into the 2'd level of categorization, keep the first to reduce the choices, and use 3'd and further to define specifics. This way you can throw everything from level 2 below in the hands of the service managers to define what they need. Regards, Nicky Madjarov phone: 973-202-4278 Find out how to bust your AR System performance @ http://www.SpeedUpARS.com - Original Message - From: Rick Cookmailto:remedyr...@gmail.com Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Sent: Thursday, April 09, 2009 11:29 AM Subject: Re: Product Categorizations and the Elephant Rhyme ** You're right as usual, Chris. But she said that they were already using Categorizations for Assignment. While testing paradigms is a practice we should all undertake, changing the entire support model is an undertaking that requires buy-in from all users and owners of the Support model. It doesn't sound like Jennifer's organization has those things in place. Categorizations are not REQUIRED for ITSM 7 Assignments to function. However, they may be required for the structure of your Support Organization to function, and they may be required for current reporting purposes. Just because you set the Cats from templates doesn't mean that they aren't being used, just that the values are automatically chosen. The broken 2000 Op Cats situation (which is not at all abnormal, BTW) is precisely why I cut through the Gordian knot with my idea for generic Op Cats. The bottom line is that the tool and the ITIL protocols are there to support the organization, not the other way around. Can the Support model
Re: Product Categorizations and the Elephant Rhyme
I think it depends entirely on the tools that you have deployed. We do not have either SRM or Asset or anything in our CMDB, so we don't really have a place to define our Service Catalog. I haven't found an actual place in ITSM where you are supposed to define it, anyway, but maybe it is in SRM which we have never seen. You can define Business Services as CIs in Asset Management, but we don't have that either. If you are defining all of your services in the 2nd level of the CTI, then that does make them available at a uniform level for any routing rules that you want to define. Given the way the ITSM 7 apps work, that sounds like a viable approach for many organizations as long as all of the rules are at one level and mutually exclusive. We don't have ANY routing rules defined that use CTI, only Location. That is because our routing is always organizational by default, with the only exceptions being defined in our Kinetic Request system. There, the service catalog consists of four categories of service items (public, students, faculty/staff, and IT support staff as made visible to a user by normal ARS group permissions). Almost every service item uses an Incident template to create the ticket, and so the CTI, Assignee Group, and Owner Group are explicitly defined in the service item tasks or the template. They do not rely on automatic assignment rules at all. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Nicky Madjarov Sent: Thursday, April 09, 2009 11:15 AM To: arslist@ARSLIST.ORG Subject: Re: Product Categorizations and the Elephant Rhyme ** While we don't have the service affected identified in the incident, problem, change, etc. (end even if we do, I'd love to have categorization within the affected service) how can one route everything properly if not using the categorization. I have seen months spent by managements to determine proper categorization, and either way they end with too few or too many. My present approach is to embed the actual service (as per service catalog) into the 2'd level of categorization, keep the first to reduce the choices, and use 3'd and further to define specifics. This way you can throw everything from level 2 below in the hands of the service managers to define what they need. Regards, Nicky Madjarov phone: 973-202-4278 Find out how to bust your AR System performance @ http://www.SpeedUpARS.com - Original Message - From: Rick Cookmailto:remedyr...@gmail.com Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Sent: Thursday, April 09, 2009 11:29 AM Subject: Re: Product Categorizations and the Elephant Rhyme ** You're right as usual, Chris. But she said that they were already using Categorizations for Assignment. While testing paradigms is a practice we should all undertake, changing the entire support model is an undertaking that requires buy-in from all users and owners of the Support model. It doesn't sound like Jennifer's organization has those things in place. Categorizations are not REQUIRED for ITSM 7 Assignments to function. However, they may be required for the structure of your Support Organization to function, and they may be required for current reporting purposes. Just because you set the Cats from templates doesn't mean that they aren't being used, just that the values are automatically chosen. The broken 2000 Op Cats situation (which is not at all abnormal, BTW) is precisely why I cut through the Gordian knot with my idea for generic Op Cats. The bottom line is that the tool and the ITIL protocols are there to support the organization, not the other way around. Can the Support model change? Sure. Whether it should is for each company to decide. Rick On Thu, Apr 9, 2009 at 8:10 AM, strauss stra...@unt.edumailto:stra...@unt.edu wrote: ** I'm going to have to challenge your assumptions here, just as mine were when we first began testing the 7.x applications several years ago. I'm not sure that in 7.x it is a best practice to key on CTI anymore; the app basically discards it as a requirement, and the new 7.x assignment engine doesn't even support it very well, not when compared to the very specific ways that CTI were processed in 3.x through 6.x applications. Based on our testing of the 7.x apps (where assignment rules using location and/or categorization no longer have reliable outcomes unless every rule is mutually exclusive) we decided to drop category as a determining factor, and key on Organization to tie our customers to a particular distributed support organization based upon their payroll accounting numbers. All tickets opened for a group of customers paid under one account (and assigned to a specific Organization in their location values) route
Re: Product Categorizations and the Elephant Rhyme
I can see how this is helpful when you have staff planted in different locations that act as an extended service desk, but what about issues that require someone in the centralized I.T. group to fix? If someone has a problem with one of your enterprise-wide applications, maybe it should always be routed to a specific group. For example, if you need a restore of your shared drive from backups, most likely there is a group that handles all backup/restore requests that will address it. What about email issues, or problems with an application built in-house that requires a programmer to be involved? I can see plenty of examples where using Categorizations would be helpful for routing. I don't see how it is possible to have a template for every single scenario, especially in a situation where you are dealing with a campus full of people that probably have admin rights on their own machines and install all sorts of crazy hardware and software that is not supported by I.T. It seems like by not using categorizations you will end up with the service desk doing more of the assignment routing manually than is necessary. Shawn Pierson From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of strauss Sent: Thursday, April 09, 2009 12:31 PM To: arslist@ARSLIST.ORG Subject: Re: Product Categorizations and the Elephant Rhyme ** I think it depends entirely on the tools that you have deployed. We do not have either SRM or Asset or anything in our CMDB, so we don't really have a place to define our Service Catalog. I haven't found an actual place in ITSM where you are supposed to define it, anyway, but maybe it is in SRM which we have never seen. You can define Business Services as CIs in Asset Management, but we don't have that either. If you are defining all of your services in the 2nd level of the CTI, then that does make them available at a uniform level for any routing rules that you want to define. Given the way the ITSM 7 apps work, that sounds like a viable approach for many organizations as long as all of the rules are at one level and mutually exclusive. We don't have ANY routing rules defined that use CTI, only Location. That is because our routing is always organizational by default, with the only exceptions being defined in our Kinetic Request system. There, the service catalog consists of four categories of service items (public, students, faculty/staff, and IT support staff as made visible to a user by normal ARS group permissions). Almost every service item uses an Incident template to create the ticket, and so the CTI, Assignee Group, and Owner Group are explicitly defined in the service item tasks or the template. They do not rely on automatic assignment rules at all. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Nicky Madjarov Sent: Thursday, April 09, 2009 11:15 AM To: arslist@ARSLIST.ORG Subject: Re: Product Categorizations and the Elephant Rhyme ** While we don't have the service affected identified in the incident, problem, change, etc. (end even if we do, I'd love to have categorization within the affected service) how can one route everything properly if not using the categorization. I have seen months spent by managements to determine proper categorization, and either way they end with too few or too many. My present approach is to embed the actual service (as per service catalog) into the 2'd level of categorization, keep the first to reduce the choices, and use 3'd and further to define specifics. This way you can throw everything from level 2 below in the hands of the service managers to define what they need. Regards, Nicky Madjarov phone: 973-202-4278 Find out how to bust your AR System performance @ http://www.SpeedUpARS.com - Original Message - From: Rick Cookmailto:remedyr...@gmail.com Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Sent: Thursday, April 09, 2009 11:29 AM Subject: Re: Product Categorizations and the Elephant Rhyme ** You're right as usual, Chris. But she said that they were already using Categorizations for Assignment. While testing paradigms is a practice we should all undertake, changing the entire support model is an undertaking that requires buy-in from all users and owners of the Support model. It doesn't sound like Jennifer's organization has those things in place. Categorizations are not REQUIRED for ITSM 7 Assignments to function. However, they may be required for the structure of your Support Organization to function, and they may be required for current reporting purposes. Just because you set the Cats from templates doesn't mean that they aren't being used, just that the values are automatically chosen. The broken 2000
Re: Product Categorizations and the Elephant Rhyme
Thank you, Chris, Rick, and Don for your feedback. Chris, Thank you for a very well-reasoned argument. I always value your input highly. As you said, there are a number of different ways to configure assignment in Remedy 7.X, and keying on CTI may not be the best method to use for every organization. Personally, I'd rather thoroughly train the first-level help desk in the business process and allow them to make intelligent decisions, but if that happened in the real world, we wouldn't need assignment rules. The assignment method was decided long before I joined the organization, and I'm not in a position to change it; however, neither is MET (Thanks, Rick!). The last time I had Remedy training was 6.0, (2005) so I'm learning 7.X on the job. We support a very large company with multi-tenancy from a central hub, so keying off organization won't work for us. In our case, generic OpCats and ProdCats work quite well. We also use assignment rules tied to every support group. Thank you again for your excellent response. I learned quite a bit reading it. P.S. Service Catalog is defined in CFG:ServiceCatalogAssoc. We import it from the 25+ page Foundation Data Spreadsheet. Don, You put a lot of detail into your explanation; the set theory model was an apt method to describe it. We create mutually exclusive assignment records. I've learned through filter logging that if any support group does not have an assignment rule, some of the OOB workflow fails. We also have a SPOC (Tier 1 Help Desk) for each tenancy, so all incidents are owned by that tenancy's SPOC and assigned to Tier 2 support by SPOC personnel. As I mentioned above, if Tier 1 were trained as well as we'd all like assignment rules would be redundant. Rick, I'm a huge fan of your Generic Incident Classification document, as you already know. I keep a copy on a flash drive that's on me at all times, and it's come in very useful. The chief issue with MET is that he's an individual (actually, two individuals) with whom we have a very cordial working relationship, and we'd prefer to keep him on our side. Also, as happens too often in organizations, process definition and enforcement in management is somewhat lax. I'm convinced this is a communication issue that we can overcome by showing MET more of the elephant. I strongly suspect MET got wind of an argument similar to the one Chris first made, interpreted it incorrectly, and doesn't have a strong enough grasp of the assignment process to follow it through to its conclusion. Chris's argument is really solid, but it's not the assignment process we're using. Thank you, gentlemen, for putting so much thought and concern into your responses. If you folks should happen to come across anything indicating Categorizations are a solid method for assignment, please do send it my way. Even if it's from '95 to '02, and has the Remedy or P-word logo on it, at least it looks official. Jennifer Meyer Remedy Technical Support Specialist State of North Carolina Office Of Information Technology Services Service Delivery Division ITSM ITAM Services Office: 919-754-6543 ITS Service Desk: 919-754-6000 jennifer.me...@its.nc.govmailto:jennifer.me...@its.nc.gov http://its.state.nc.us E-mail correspondence to and from this address may be subject to the North Carolina Public Records Law and may be disclosed to third parties only by an authorized State Official. __Platinum Sponsor: RMI Solutions ARSlist: Where the Answers Are html___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Product Categorizations and the Elephant Rhyme
Our system works for us since the vast majority of issues for faculty and staff are handled by their distributed computer support groups, where all of the Incidents are routed first by default. Almost all of the functions you mentioned are administered at the distributed unit level, even if they are hosted on a central service (active directory accounts and permissions, Exchange mail, disk storage), and are only escalated to the central group when the distributed group cannot handle the issue. Even backups and restores are distributed (local) - the colleges run their own file and print servers, in their own domain within the central AD system. The central helpdesk provides the equivalent first line support to all students, so that is their default routing, and a lot of the centrally supported system tickets (student email, distance learning apps, etc.) all start at the central helpdesk for triage anyway. For anything that is very specific, and is a routine request from customers supported by more than one distributed support group (like data wiring requests, which any employee can enter and all route first to DataComm, then TeleComm), there is a Kinetic Service Item that directly assigns new incidents to the appropriate central support group. BTW, the majority of desktops, especially Windows machines, are deployed for faculty/staff by their college/departmental IT staff without admin rights for the end user, with a very wide variety of software packages available to them as needed. Since this is very college or department specific (even the OS is college specific - you won't find any Macs supported in the college of business, or many Windows machines in visual arts or music), any attempt to route a ticket for application support centrally will have to be turned back. We also have a number of colleges/departments in one building, with small IT staffs, who don't use Remedy for internal ticketing at all. Their faculty know to use the Kinetic web to report a problem with the distance learning or PeopleSoft webs, which are centrally supported, but they generally email, call, or walk a few doors down to their network manager for local issue support. We don't / can't MAKE them use Remedy for internal ticketing, but as soon as any IT support organization grows to several people supporting users in multiple buildings, or even on multiple campuses, they quickly move to a model where everything gets ticketed as an incident, but it is still 98% internal to that organization. In our environment, where some groups want a few CTI for reporting but most groups don't want to have to deal with the overhead, dropping CTI-based routing made sense; we have always used location-based routing as our primary method, all the way back to Help Desk 3. The changes in the assignment processes in ITSM 7 made it easy for us to just simplify everything when we migrated, and at this point (11 months in production) we have not found any reason to regret it. Maybe if we had BMC Analytics or Dashboards we would see it differently, but we keep losing the budget battle for those. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Pierson, Shawn Sent: Thursday, April 09, 2009 12:42 PM To: arslist@ARSLIST.ORG Subject: Re: Product Categorizations and the Elephant Rhyme ** I can see how this is helpful when you have staff planted in different locations that act as an extended service desk, but what about issues that require someone in the centralized I.T. group to fix? If someone has a problem with one of your enterprise-wide applications, maybe it should always be routed to a specific group. For example, if you need a restore of your shared drive from backups, most likely there is a group that handles all backup/restore requests that will address it. What about email issues, or problems with an application built in-house that requires a programmer to be involved? I can see plenty of examples where using Categorizations would be helpful for routing. I don't see how it is possible to have a template for every single scenario, especially in a situation where you are dealing with a campus full of people that probably have admin rights on their own machines and install all sorts of crazy hardware and software that is not supported by I.T. It seems like by not using categorizations you will end up with the service desk doing more of the assignment routing manually than is necessary. Shawn Pierson ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Product Categorizations and the Elephant Rhyme
This may be an excellent opportunity to compare and contrast the two approaches for organizational functions. If I understand this correctly, I and Shawn have central help desks that rely heavily on automated routing to choose from thousands of functions. Chris and Don seem to have a distributed system that relies on locally distributed service centers with a high knowledge level so uses assignment mappings as a fallback. Is this an accurate summation? Jennifer Meyer From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of strauss Sent: Thursday, April 09, 2009 2:54 PM To: arslist@ARSLIST.ORG Subject: Re: Product Categorizations and the Elephant Rhyme Our system works for us since the vast majority of issues for faculty and staff are handled by their distributed computer support groups, where all of the Incidents are routed first by default. Almost all of the functions you mentioned are administered at the distributed unit level, even if they are hosted on a central service (active directory accounts and permissions, Exchange mail, disk storage), and are only escalated to the central group when the distributed group cannot handle the issue. Even backups and restores are distributed (local) - the colleges run their own file and print servers, in their own domain within the central AD system. The central helpdesk provides the equivalent first line support to all students, so that is their default routing, and a lot of the centrally supported system tickets (student email, distance learning apps, etc.) all start at the central helpdesk for triage anyway. For anything that is very specific, and is a routine request from customers supported by more than one distributed support group (like data wiring requests, which any employee can enter and all route first to DataComm, then TeleComm), there is a Kinetic Service Item that directly assigns new incidents to the appropriate central support group. BTW, the majority of desktops, especially Windows machines, are deployed for faculty/staff by their college/departmental IT staff without admin rights for the end user, with a very wide variety of software packages available to them as needed. Since this is very college or department specific (even the OS is college specific - you won't find any Macs supported in the college of business, or many Windows machines in visual arts or music), any attempt to route a ticket for application support centrally will have to be turned back. We also have a number of colleges/departments in one building, with small IT staffs, who don't use Remedy for internal ticketing at all. Their faculty know to use the Kinetic web to report a problem with the distance learning or PeopleSoft webs, which are centrally supported, but they generally email, call, or walk a few doors down to their network manager for local issue support. We don't / can't MAKE them use Remedy for internal ticketing, but as soon as any IT support organization grows to several people supporting users in multiple buildings, or even on multiple campuses, they quickly move to a model where everything gets ticketed as an incident, but it is still 98% internal to that organization. In our environment, where some groups want a few CTI for reporting but most groups don't want to have to deal with the overhead, dropping CTI-based routing made sense; we have always used location-based routing as our primary method, all the way back to Help Desk 3. The changes in the assignment processes in ITSM 7 made it easy for us to just simplify everything when we migrated, and at this point (11 months in production) we have not found any reason to regret it. Maybe if we had BMC Analytics or Dashboards we would see it differently, but we keep losing the budget battle for those. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Pierson, Shawn Sent: Thursday, April 09, 2009 12:42 PM To: arslist@ARSLIST.ORG Subject: Re: Product Categorizations and the Elephant Rhyme ** I can see how this is helpful when you have staff planted in different locations that act as an extended service desk, but what about issues that require someone in the centralized I.T. group to fix? If someone has a problem with one of your enterprise-wide applications, maybe it should always be routed to a specific group. For example, if you need a restore of your shared drive from backups, most likely there is a group that handles all backup/restore requests that will address it. What about email issues, or problems with an application built in-house that requires a programmer to be involved? I can see plenty of examples where using Categorizations would be helpful for routing. I don't see how it is possible
Re: Product Categorizations and the Elephant Rhyme
Concerning question on Distributed Environment--short answer is : yes. By Chris' description below, our environment is characteristically different from many encountered in the commercial world, public entities, and maybe even other academic centers. We do rely on legacy knowledge in 60-odd support groups to know their local environment, so central IT folks do not have to learn an area's specific concerns 'on-the-fly'. And, summarizing description by Chris, often those group-specific items show many more peculiarities than similarities. Local experience is that central support often *fails* all consumers equally in this diverse environment, rather than facilitating prompt consumer service. We have very few applications where both installation and implementation is actually Enterprise-wide-as Chris mentioned, even backups/file-sharing/printing are more localized than centralized. Customer-relations criteria should place the consumer first. Our support-staff folks are here for agile handling of consumer's needs; therefore, we rely on that consumer's location (logical location, specific college/school/group) for placement of Incident reports, and that is how our environment is built. Finally, we do utilize a system-wide default which will route any un-assignable Incidents to our central help desk for further handling-and to ensure that no Incident goes unhandled for lack of designation. By my last count, I have seen four (4) such incidents out of 17,000+ records over the last year. Don W. McClure, P.E. Applications Manager, Call Tracking Administration University of North Texas dwmac (at) unt (dot) edu From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Meyer, Jennifer L Sent: Thursday, April 09, 2009 2:23 PM To: arslist@ARSLIST.ORG Subject: Re: Product Categorizations and the Elephant Rhyme ** This may be an excellent opportunity to compare and contrast the two approaches for organizational functions. If I understand this correctly, I and Shawn have central help desks that rely heavily on automated routing to choose from thousands of functions. Chris and Don seem to have a distributed system that relies on locally distributed service centers with a high knowledge level so uses assignment mappings as a fallback. Is this an accurate summation? Jennifer Meyer From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of strauss Sent: Thursday, April 09, 2009 2:54 PM To: arslist@ARSLIST.ORG Subject: Re: Product Categorizations and the Elephant Rhyme Our system works for us since the vast majority of issues for faculty and staff are handled by their distributed computer support groups, where all of the Incidents are routed first by default. Almost all of the functions you mentioned are administered at the distributed unit level, even if they are hosted on a central service (active directory accounts and permissions, Exchange mail, disk storage), and are only escalated to the central group when the distributed group cannot handle the issue. Even backups and restores are distributed (local) - the colleges run their own file and print servers, in their own domain within the central AD system. The central helpdesk provides the equivalent first line support to all students, so that is their default routing, and a lot of the centrally supported system tickets (student email, distance learning apps, etc.) all start at the central helpdesk for triage anyway. For anything that is very specific, and is a routine request from customers supported by more than one distributed support group (like data wiring requests, which any employee can enter and all route first to DataComm, then TeleComm), there is a Kinetic Service Item that directly assigns new incidents to the appropriate central support group. BTW, the majority of desktops, especially Windows machines, are deployed for faculty/staff by their college/departmental IT staff without admin rights for the end user, with a very wide variety of software packages available to them as needed. Since this is very college or department specific (even the OS is college specific - you won't find any Macs supported in the college of business, or many Windows machines in visual arts or music), any attempt to route a ticket for application support centrally will have to be turned back. We also have a number of colleges/departments in one building, with small IT staffs, who don't use Remedy for internal ticketing at all. Their faculty know to use the Kinetic web to report a problem with the distance learning or PeopleSoft webs, which are centrally supported, but they generally email, call, or walk a few doors down to their network manager for local issue support. We don't / can't MAKE them use Remedy for internal ticketing, but as soon as any IT support organization grows to several people
Re: Product Categorizations and the Elephant Rhyme
That's an excellent explanation, Don. Thank you. This thread is generating intense interest in my local group, so if anyone uses a different routing/assignment scheme, please share with us. I may have to post a Wiki. P.S. I did manage to find a knowledgebase article referring to CTI and assignment for 6.X. Jennifer Meyer From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of McClure, Don Sent: Thursday, April 09, 2009 4:27 PM To: arslist@ARSLIST.ORG Subject: Re: Product Categorizations and the Elephant Rhyme Concerning question on Distributed Environment--short answer is : yes. By Chris' description below, our environment is characteristically different from many encountered in the commercial world, public entities, and maybe even other academic centers. We do rely on legacy knowledge in 60-odd support groups to know their local environment, so central IT folks do not have to learn an area's specific concerns 'on-the-fly'. And, summarizing description by Chris, often those group-specific items show many more peculiarities than similarities. Local experience is that central support often *fails* all consumers equally in this diverse environment, rather than facilitating prompt consumer service. We have very few applications where both installation and implementation is actually Enterprise-wide-as Chris mentioned, even backups/file-sharing/printing are more localized than centralized. Customer-relations criteria should place the consumer first. Our support-staff folks are here for agile handling of consumer's needs; therefore, we rely on that consumer's location (logical location, specific college/school/group) for placement of Incident reports, and that is how our environment is built. Finally, we do utilize a system-wide default which will route any un-assignable Incidents to our central help desk for further handling-and to ensure that no Incident goes unhandled for lack of designation. By my last count, I have seen four (4) such incidents out of 17,000+ records over the last year. Don W. McClure, P.E. Applications Manager, Call Tracking Administration University of North Texas dwmac (at) unt (dot) edu From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Meyer, Jennifer L Sent: Thursday, April 09, 2009 2:23 PM To: arslist@ARSLIST.ORG Subject: Re: Product Categorizations and the Elephant Rhyme ** This may be an excellent opportunity to compare and contrast the two approaches for organizational functions. If I understand this correctly, I and Shawn have central help desks that rely heavily on automated routing to choose from thousands of functions. Chris and Don seem to have a distributed system that relies on locally distributed service centers with a high knowledge level so uses assignment mappings as a fallback. Is this an accurate summation? Jennifer Meyer From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of strauss Sent: Thursday, April 09, 2009 2:54 PM To: arslist@ARSLIST.ORG Subject: Re: Product Categorizations and the Elephant Rhyme Our system works for us since the vast majority of issues for faculty and staff are handled by their distributed computer support groups, where all of the Incidents are routed first by default. Almost all of the functions you mentioned are administered at the distributed unit level, even if they are hosted on a central service (active directory accounts and permissions, Exchange mail, disk storage), and are only escalated to the central group when the distributed group cannot handle the issue. Even backups and restores are distributed (local) - the colleges run their own file and print servers, in their own domain within the central AD system. The central helpdesk provides the equivalent first line support to all students, so that is their default routing, and a lot of the centrally supported system tickets (student email, distance learning apps, etc.) all start at the central helpdesk for triage anyway. For anything that is very specific, and is a routine request from customers supported by more than one distributed support group (like data wiring requests, which any employee can enter and all route first to DataComm, then TeleComm), there is a Kinetic Service Item that directly assigns new incidents to the appropriate central support group. BTW, the majority of desktops, especially Windows machines, are deployed for faculty/staff by their college/departmental IT staff without admin rights for the end user, with a very wide variety of software packages available to them as needed. Since this is very college or department specific (even the OS is college specific - you won't find any Macs supported in the college of business, or many Windows machines in visual arts or music), any attempt to route
