The problem with Categorization Subclasses is that you cannot introduce new attributes with different permission group. In cases where, for example, it is not acceptable for server servicing group to change PC configurations which is the domain of PC servicing group you cannot put everything in BMC_ComputerSystem Class
Victor On Tuesday 13 of May 2008 17:30:03 Rick Cook wrote: > And BMC's #1 rule on customizing the CMDB CDM is to try to create > Categorization Subclasses under an existing class structure before creating > new classes. Creating new classes and subclasses should be reserved for > situations that can be proven to not fit into any of the existing ones. > That's how BMC_ComputerSystem can be used to contain almost all > discoverable IT assets. > > Rick > > On Tue, May 13, 2008 at 8:19 AM, Phil Murnane <[EMAIL PROTECTED]> wrote: > > ** > > > > Kevin: > > > > > > > > This situation is not a ploy to sell services. In its simplest form, the > > fact is that ITIL adoption is a complex endeavor, and if your > > organization is not willing to front-load their effort, then ITIL > > adoption may not be for them. Everything that Chris mentioned is > > important. Beyond what Chris wrote, it's necessary to understand the > > thought processes that lead him to write what he did. > > > > > > > > If your concern is future usability, then it is necessary to make your > > very best effort to anticipate what the future needs will be. Only after > > this process is grossly conlcluded can the CMDB be configured to meet the > > need. Along with this concept, understand that the expected need will > > never exactly match the actual future need, and so all you can do is make > > your best effort. > > > > > > > > Just like CQI, ITIL is a journey, not a destination. > > > > > > > > Less philosophically, my strongest recommendation to a customer is to not > > add any new attributes or classes unless there is a demonstrable business > > need for the new class/attribute. In my experience, customers are often > > suprised how many CIs can be tracked using simply the BaseElement class. > > My personal #1 rule of CMDB: unless there is a business need to consume > > the data, do not store the data in the CMDB. This rule extends to the > > Product Catalog, in that if there is no need to consume the data, then > > there is no need to categorize the data. > > > > > > > > Also, as Shawn mentioned, if you're using BMC's AM module, you have many > > restrictions in the day-to-day use of your data, so some of these > > questions, when pursued to their logical conclusion, will lead you to "it > > doesn't matter." > > > > > > > > Just My $0.02, > > > > --Phil > > > > > > ----- Original Message ---- > > From: Kevin Pulsen <[EMAIL PROTECTED]> > > To: arslist@ARSLIST.ORG > > Sent: Tuesday, May 13, 2008 6:35:07 AM > > Subject: Re: ITSM 7, CMDB CI and Product Definitions > > > > ** Thank you Shawn for your reply. > > > > My concern is, and this is what I have heard from BMC, when designing > > your Product categories, you need to think ahead to the design of the > > CMDB as well. It's all interrelated and affects reporting, trending > > analysis etc. > > > > I find it very difficult to design my Product categories and place all of > > the Non-Asset items in an 'OTHER' category, only to find out 2 years down > > the road our CMDB is messed up and mostly useless. > > > > Was this information from BMC a ploy to sell more Professional Services? > > > > I just hope to look enough ahead of the road to see the brick wall coming > > at me, that's all. > > > > Thanks again, > > > > Kevin P. > > > > > > > > ** > > > > Part of the problem is that there are no good answers to your questions. > > By default, we put things in the BMC_ComputerSystem class, unless it fits > > in somewhere else. So a Blackberry technically is a computer, just a > > tiny one. So is a calculator. > > > > > > > > Stuff that doesn't have a class and isn't anything remotely close to > > being a computer goes in as "equipment". > > > > > > > > I'm wary of creating new classes unless there is a demonstrable need for > > it that is so strong we can't live without it. My users already hate > > that they have nothing in Asset Management to be able to search across > > the different classes (e.g. how do you find, in ITSM, all Assets located > > on the third floor of a certain building? The data exists, but there is > > no screen for users to pull that type of information.) New classes make > > the system harder to use. In fact, rather than creating a bunch of new > > classes, we've hidden some of the OOB classes to make the system easier > > to navigate. > > > > > > > > Shawn Pierson > > > > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > > html___ > > > > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > > html___ > > ___________________________________________________________________________ >____ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
