I believe so, but that doesn't make it the best situation for all.  Some
would prefer not to use Op Cats, or limit their use, for their own reporting
reasons.

For your reporting example, you're assuming QBE, which would be a little
more difficult.  However, if you use SQL, you could bypass the first 4 Prod
Cat fields in your query.

Rick

On Fri, Mar 19, 2010 at 7:41 AM, Kathy Morris <kathymorris...@aol.com>wrote:

> **
> So does this mean if I use both the Operation Cat and Product Cat under
> Model 1 - this would be the better solution?  (the model with the CMDB asset
> included).
>
>
>
>
>  In a message dated 3/19/2010 10:19:53 A.M. Eastern Daylight Time,
> remedyr...@gmail.com writes:
>
> ** The use of the first example you noted in the 7.5 class is dependent on
> the use of both the Product Catalog and the CMDB for CI information.
> Without it, it just doesn't work, because there will be gaps in the data.
> With it, reporting has options in terms of depth and detail, and
> categorization becomes easy enough that even end users can do it with a high
> level of accuracy, minimizing the need for an SRM-like front-end.
>
>
> Rick
>
> On Thu, Mar 18, 2010 at 4:04 PM, Martinez, Marcelo A 
> <marc...@cpchem.com>wrote:
>
>>  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"_
>>
>
> _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_
>
> _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"

Reply via email to