Brad, I understand your restrictions. I asked if this could possibly be utilized to track software because if it is utilized for software you really want to use the OOB structure. The reason is because Software License Management/Software Library etc. needs certain pieces of this to work.
Also - I would recommend some time spent researching federated data. This is a very useful way to show data that is not in the CMDB. However, it looks like it is. I would be careful about biting off on the idea of not managing data in the CMDB. In practical application across I have found if there is someone who will manage the data in the CMDB it is essential to collect it there. Often times objections to storing it in the CMDB are made out of an apprehension to change. My normal stance is that if there is someone who can manage it in the CMDB or there is a big benefit add (benefit add covered below), it should be in there. Obviously, if a customer already has a vendor management system in place to manage their data your chances are slim that you will be able to win that over for CMDB use. There is also another aspect to this and that is use ability of the data. What I mean, is if you can show the benefit-add for the use of the CMDB that's where you will win more often than not. If there is a logical link between their data living in the CMDB and how it can show a living picture somehow that's the best. For instance, servers stored in the CMDB can be attached to Incident tickets (SRM can use these too) thusly making the Incident Ticket more intelligent. These servers can then be linked to trend incidents if applicable. This can be used to populate trends with a server or even into knowledge articles etc. Also, these servers are utilized with BMC monitoring (BEM/SIM,TMART etc) This makes the whole picture work together. You can also utilize the Purchasing console to hook into vendor webservices and start the lifecycle of a CI in the CMDB from procurement to lifecyle retirement 20 years down the road. Huge benefit add. Therefore, if you can somehow tie the data being discussed to how it can intelligently receive benefit from being in the CMDB, you will gain greater ground. I will be honest here, as a consultant, I will say the biggest roadblock to all of this is funding and cooperation (Silo management --yes, I made that up :-)). It not usually funding from a Remedy perspective as normally a lot of this functionality is already installed, just no one uses it. Good luck with your CMDB. A Step by Step Guide to Building a CMDB is a great book that you can get from the Remedy downloads site with your contract ID. For some light fireside reading :-) Josh On Thu, Jan 30, 2014 at 12:26 AM, BradRemedy <[email protected]> wrote: > ** > Hi > > That data is more customer base for us - there are multiple products > associated to a brand and a brand is associated to a customer. > > All that information will allow us to determine the market which *could* be > linked to a site. > > We have started having some good discussions around the CMDB and what > should be stored etc and the suggestions I have received here I have > mentioned in the meeting which has taken the conversation to a whole new > level. It has, to be honest with you, taken us out of the mind set of "just > put the data in the CMDB" to ask questions like "Where do we put it?", "Why > do we need to put it there?" , "Who will access it? " etc. > > > Sorry - not sure if that answers your questions and I have to be careful > what information I post on here due to company restrictions. > > Thanks again for the help and assistance again. > > > On Wed, Jan 29, 2014 at 10:44 PM, _ <[email protected]> wrote: > >> ** >> Hey Brad- quick question. When you say Market, Brand and Product, would >> those possibly refer to Software at some point? >> >> >> On Wed, Jan 29, 2014 at 12:51 AM, BradRemedy <[email protected]>wrote: >> >>> ** >>> Hi >>> >>> Firstly, thanks for the fantastic advice and answer's everyone - really >>> appreciate it and makes this tough task alot easier to do knowing that I >>> have some great advice and direction. >>> >>> The other 3 forms / data that I need to put somewhere is closely related >>> to the company and site information that we have. The 3 other forms hold >>> our Market, Brand and Product information which are all related to each >>> other. >>> >>> I am going to go through the information you guys have supplied and give >>> it some more thought and investigation. This version 8 upgrade we are doing >>> is extremely important and I want to make sure I get my foundation 100% >>> correct so that everything runs smoothly and makes sense. >>> >>> Looks like the CMDB part of this project is going to be some new >>> learning and looking forward to that. If you guys have any recommended >>> white papers you think I should read then please let me know. Obviously I >>> will check the support site and browse around there to see what I can find >>> that may help guide us. >>> >>> Thanks again for the advice - appreciate it. >>> >>> Cheers >>> Brad >>> >>> >>> On Tue, Jan 28, 2014 at 8:28 PM, Mueller, Doug <[email protected]>wrote: >>> >>>> ** >>>> >>>> Brad, >>>> >>>> >>>> >>>> A good question to ask. >>>> >>>> >>>> >>>> The CMDB is a configuration database that is used to hold configuration >>>> items within your environment and >>>> >>>> the relationships between them. There should always be a consumer for >>>> this data that is going to use that >>>> >>>> data to make business decisions or take business actions. >>>> >>>> >>>> >>>> You do not want non-configuration data in the CMDB. It is NOT a data >>>> warehouse. >>>> >>>> >>>> >>>> You say that of your 4 forms, one is site information. Well, if that >>>> is site information that matches the idea of >>>> >>>> the configuration of your environment with different sites that you >>>> want to be able to relate to, then this >>>> >>>> is a good example of data to put into the CMDB. Now, how many fields >>>> to you have? Do they all map into the >>>> >>>> CMDB fields? Is there a lot more data that fits into the CDM (Common >>>> Data Model) that BMC provides? Is >>>> >>>> that additional data "CMDB worthy" or is it really extra details needed >>>> only under certain circumstances? >>>> >>>> >>>> >>>> So, you may end up creating sites AND having a form for the "additional >>>> data" that is not CMDB appropriate >>>> >>>> and link the items by reconciliation ID for example. >>>> >>>> >>>> >>>> So, some thought here. >>>> >>>> >>>> >>>> As for the other three forms, are they configuration items? Is there >>>> value for other applications seeing this >>>> >>>> data in the CMDB and the relationships? If so, then consider loading >>>> it (again, it may be some in the CMDB >>>> >>>> and some not). If not, then definitely to the custom form route and do >>>> not put it into the CMDB. >>>> >>>> >>>> >>>> So, a couple of layers of thought here. >>>> >>>> >>>> >>>> I know this is not a specific yes/no answer, but hopefully it gives you >>>> the parameters to think about for >>>> >>>> making the decision. >>>> >>>> >>>> >>>> Doug Mueller >>>> >>>> >>>> >>>> *From:* Action Request System discussion list(ARSList) [mailto: >>>> [email protected]] *On Behalf Of *BradRemedy >>>> *Sent:* Tuesday, January 28, 2014 1:50 AM >>>> *To:* [email protected] >>>> *Subject:* Data Holding: Customize CMDB or create Custom Remedy Form? >>>> >>>> >>>> >>>> ** >>>> >>>> Hi Guys >>>> >>>> >>>> >>>> Quick Question that just wanted come advice from everyone on. Basically >>>> we are busy upgrading our system to version 8.1 and ITSM 8.1. We are busy >>>> planning our data migration and wanted to know what you guys think of the >>>> following. >>>> >>>> >>>> >>>> We currently have 4 different remedy forms on our old system with data >>>> that we want to migrate to our new version. The new version is installed on >>>> a new server as a clean OTB Install. >>>> >>>> One of the remedy forms and data is Site information which we were >>>> thinking of placing into the CMDB however the other 3 are our custom data >>>> that doesn't really fit anywhere in the CMDB. >>>> >>>> >>>> >>>> Is it advisable to add a new custom class to the CMDB to hold this >>>> information and then form the various relationships or should we rather >>>> create this data on our new remedy environment and not customize the CMDB >>>> at all? >>>> >>>> >>>> >>>> Any advice or assistance would be appreciated. >>>> >>>> >>>> >>>> Thanks >>>> >>>> Brad >>>> >>>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>>> >>> >>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
