Well, you are obviously managing DNS changes, so that means that there needs to be some way of classifying them. However, they aren't technically objects, so that makes them difficult to manage as CIs, unless you want to manage them as server attributes or something. So it would seem that having some categorization around them for the CM module would probably do the trick.
As far as Release goes, it has it's place, but I think if you can make it work with Changes and Tasks without having to twist or compress the process, you're probably fine without Release. If you find that you have large projects that need to be managed and scheduled at multiple sites or on multiple timelines, having a Release encompassing several RFCs, which can still have Tasks subordinate to them, is probably the way to go. Rick On Mon, Oct 11, 2010 at 1:55 PM, Martinez, Marcelo A <[email protected]>wrote: > How does your company categorize DNS changes in Change Mgmt? Do you have it > under Ops Cat Tiers or set up as a product? > Does your company have a criticality level for these? Do you differentiate > between 'creating' vs. 'modifying' them? > > I'm just trying to see how others classify these.. seems as if lately we've > had an influx of DNS changes (new or mods) and my current classification > isn't in line with what the change is requesting. > > ARS 7.1 > ITSM 7.0.03 > > ----------------------------- > > On another note, to the people already using ITSM 7.5 / 7.6 ... Do you use > Release Mgmt or can you get by with just Chg Mgmt? > > > > Thanks all - > > Marcelo > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > 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"

