Thanks for the quick reply Rick, I do appreciate your input. It's been a long while since I've had my hand in ITSM (since 5.0). I've trained on CMDB 1.0.
As you can see pretty easily that I am trying to keep the Application out of trouble down the road when the other module start coming on board. As the instantiations of the classes start occurring, the new ITSM processes for IM, and PM are almost completely there. Thus cutting out that need to customize those applications all the way around to the point the system ends up becoming non-upgradeable. The next question to be asked is: What's the good way to travel to determine the closest CI Class to use? I am thinking we're going to have to do a gap analysis of the original RFC (Manual Process) and then navigate around the CMDB for the class that best describes this thing called "Circuit" and add the attributes to that. (Surely there has to be other industries that are in the same spot that would benefit from this kind of Change Management Process - Communications Management based companies?). -d _____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook Sent: Wednesday, December 26, 2007 1:05 PM To: [email protected] Subject: Re: ITSM Change RFC Design Question David, I was thinking of option #2 before you even mentioned it. The key thing for me is whether you can keep the Class data up to date without too much work. Also, I would (if you haven't already) use CMDB 2.x - the class structure is more easily adapted to your purposes. Rick _____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of David K Hill Sent: Wednesday, December 26, 2007 12:43 PM To: [email protected] Subject: ITSM Change RFC Design Question ** I just want to get an opinion of other developer's ideas to see if I am going down the right path with this design strategy for our RFC (Request for Change) of the ITSM Change Module. The situation is this: 1. We have requirement to capture additional information that would be considered important for the request for change of a telephony or network "Circuit" in a network topology. That is, a customer would like to "Add", "Change", or "Remove" items that are deemed as "Circuits" in his network topology. A circuit is, for a lack of a better word, a collection of information describing two endpoints, ownership, support structure, location, punch down coordinates, costing, configurations etc. 2. They would like to have this information included for the review and approval stages of the RFC. That is some how available. (e.g. Location, Circuit ID, POC info, support info etc.) It would just be just another kind of RFC to submit, review, approve and implement. 3. At the same time, we would like to keep the OOB functionality of the ITSM Change module untouched to allow us upgrades in the future. (I know this sound contradictory). 4. We need the extended data to be available in reports so that RFC data is available along with the Circuit Here are some of the scenarios that I am thinking might satisfy the requirements. 1. Scenario: Create a separate form that captures the information that is different from the RFC and do a data driven workflow relationship to relate the extraneous data on a one to one relationship. Create work flow that will capture the information on "Create" and "Modify" of RFC that are classified in this Tier 1, Tier 2 and Tier 3 categorization. The only caveat here is that we have to take in consideration of the Upgrades and preserving our changes in the work flow and forms every time we upgrade the system. (ITSM). 2. Scenario: Create a CI Class that can be instantiated as a "Circuit" that captures the special attributes listed above and use it as a Relational item instead of creating a special form to denote a "Circuit" concept. I am thinking if we build/create a class that captures the fields we can use the Configuration Management components and the other Suites such as AM, PM, IM etc. out of the boxes with no additional work flow changes. Do we know of a CI that is indicative of a "Circuit" per se'? Looking through the existing CI, I can see some classes that would come close to the idea of a "Circuit". I would just need to add the extra info fields. I am thinking that a Circuit CI could show a relation ship of all the child devices/components that are affected. If we could go with Scenario 2 and it's my understanding that everything would behave natively. We would derive data driven Work Flow that will automatically relate the Circuit CI to the RFC at create/modify time. The only problem I can see is that I will have to build a special class to support this kind of CI. Am I going about this the right way? Thanks for any thought you may have in this. David Hill Verizon Business __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
