In the OOB solution, the CMDB asset is not listed in the Operational Categorizations. My company is thinking it is wrong for us to change the Operational Categorizations because Remedy has already given us the "best practice" categorizations out of the box. Management's argument is "we should follow the OOB model and not include the CMDB asset in the Operational Categorization level." Find the CMDB asset in the Product Catalog. For example (Operation Cat): request network create request account enable/lock request backup modify request hardware install
Product Tier 1:Software Tier 2: Application Tier 3: Third Party Tier 4: Hewlett Packard Tier 5: HP Openview. My concern is reporting... If I have to build queries, OOB there are 11000 Product catalogs that say: Tier 1:Software Tier 2: Application Tier 3: Third Party With the OOB model, if I want to find how many HP Openview installs happened in February, then I would have to run a query against 11000 records for Tier 1 (Software), 11000 records for Tier 2 (Application), etc... until I drill down to HP OpenView stored in Tier 5. Plus, this would mean we would need to make these 8 fields (operation & product) required to get this data. Am I missing something? In a message dated 3/18/2010 7:05:45 P.M. Eastern Daylight Time, marc...@cpchem.com writes: Funny thing… I was just going over Categorization in the ITSM 7.5 Admin course part 1. J One of the examples their fictitious company used in figuring out how to define Ops Tiers is: I need the support to <Tier1> <Tier2> on my <Tier3> (I need the support to install software on my desktop). There is also an example of “symptom-based” categorizations. (<Network support – end user> <Data> <Unable to access network files>). I prefer to user Ops Tiers as <noun> <noun> <verb> (<Telecom><voicemail><how to> or <Application> <Software> <Install>) and if OpsTier1 is application, then a product must be specified (enforced thru workflow). Matt is right… good list! HTH, Marcelo From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Kathy Morris Sent: Thursday, March 18, 2010 5:13 PM To: arslist@ARSLIST.ORG Subject: Re: Operational and Product Categorization ** For Model #1 we will still use the Product categorizations in addition to the Operational Categorizations. We would just have the CMDB asset on the 3rd Tier. Trying to get as much accurate info into the classification of the ticket. Reporting Requirements was the reason for the two different models. Reporting requirements are very important to us, as well as the routing, approvals, resolutions, etc.. In a message dated 3/18/2010 6:01:06 P.M. Eastern Daylight Time, m...@worsy.co.uk writes: ** Kathy There will be many opinions on this, so I would suggest you analyse from a different angle. You need to consider: 1. Reporting Requirements 2. Service Level Agreements 3. Routing Rules 4. Approval Rules 5. Task categorisations 6. Resolution Categorisation 7. Categorisations for incident vs Change vs Problem vs etc 8. Multi tenancy of all the above (if applicable) 9. Maintaining all of the rules above Once you understand that, it’ll help drive how the Categorisations need to be set up. To answer your questions specifically: 1. The advantage of Model 2 is the flexibility you can use to create Products AND operational Categorisations. Remember with op Cats none of the tiers are mandatory (common customisation though) so an end user can select 0, 1, 2 or all 3 tiers. 2. No but if you do combine them consider how you would implement CMDB in the future and thus have to rework your categorisations. Personally I find your second option the best, a very high level descriptor (Failure) followed by a second describing the area (Performance) followed by a layer of extra granularity (Connectivity) for example. Matt From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Kathy Morris Sent: 18 March 2010 9:39 PM To: arslist@ARSLIST.ORG Subject: Operational and Product Categorization ** Hello, We are trying to figure an approach for operational and product categorizations: A technical write-up suggested the following for Operational Categorizations: Model #1 Tier 1: install (verb) Tier:2: Telecommunication (service) Software Tier 3: Voicemail (CMDB Asset) I remember reading that there was some value in having the CMDB asset on Tier 3. Model #2 option was: request network create account With Model #2, the CMDB asset is not listed, and we would need to combine the Ops with the product categorizations in order to capture the asset. What are the advantages of one option over the other? Is there any loss if we just use the Operational categorizations? Are these 6 fields (Ops and Prod categories) mandatory usually? or are just the Ops normally required fields? I am building the service catalog to start building Operational Categorizations. Does anyone have any recommendations; lessons learned. This is painful. I have a team that just wants to map the CTI's into the Operational Categorizations. _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers Are"_ _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers Are"_ _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
