generic CIs inn CMDB

[DavidT]

hello SN community,

we currently have a CMDB with of course multiple classes, fed with many CIs (servers, apps, netgears, etc).

In a new project, it is asked to have generic CIs, to be used in ticketing (incident, request)

I'm not totally comfortable to create a generic 'mouse' or 'Keyboard' CI in existing 'computer peripheral' class, while we have real CIs in that class.

-> A specific class for generic hardware CIs (of any type)?

In the same idea I need to have the list of meeting rooms as CIs... but 'location' table is not part of the CMDB structure.

A new class directly based on cmdb_ci? how to link to default location table (used by other CIs).

And, I will also need to have a list of installable software (typically MS Office Packs/apps, Adobe products, etc etc). Goal is not to do Software Asset Management (not mature enough for that!) Just to list items as generic CIs for inc/req tickets.

Have you ever had to create such CIs in this type of context?

Suggestions would be appreciated

D.

[Community Alums]

David,

In most situations I've worked in, companies do not necessarily open tasks against Computer Peripherals or desktop software products. This is how I've seen it handled. You have multiple items here, so I am going to break it out a bit:

• For the hardware, the task (incident, problem, etc.) would use the person's computer as the CI, regardless if the issue ends up being the keyboard, the mouse, the monitor, the USB printer, etc. The short description handles getting into the specifics on that because there is often very little value in tracking down to the keyboard level in the CMDB.
• Similarly, with the software, you could open the task against the user's computer as the CI, and then indicate that there is an issue with the software on that computer in the short description and notes. Unless the issue is broader than that particular computer and has to do with the software itself, it often has to do with the configuration of the software (or related software) on the computer. If you really want to get specific, you could have a little fun and create a new field that lets you select from software installations on the selected CI (if you have that data in your CMDB).
• For broader software issues, you can use Application [cmdb_ci_appl] as a means to track issues with software. Then you could have Microsoft Office listed and when those larger issues appear (i.e. All installations of Office when a certain driver is installed), you could use that as the CI.
• For meeting rooms, you could create a table to support this in your environment. Then you have a meeting room CI associated with a particular location. Depending on where you are at or before you build anything custom, you might want to take a look at Facilities Service Management.

I hope this helps get you going.

Ben

[A Westervelt]

I agree on Ben's points 1,2, and 4.

Software is something that is installed directly onto a machine (computer or server). There is already a CMDB table [cmdb_ci_spkg] for this and is neatly kept up to date by your Discovery source. If you don't have a Discovery source, than this is still the ideal place to put your software items you want to have tracked in task management.

Applications can be software and not at the same time. Despite being integrated onto a server, it may not actually be installed but merely running on it. Likewise with cloud applications (hint, ServiceNow) which cannot be Discovered and must be manually maintained by you CMDB admin. Also, this table allows you to easily maintain any application security requests as CIs to trace.

Example: an end-user requests SAP GUI to be installed on their machine versus requesting access to SAP finance. These are two very different workflows that impact SAP in different ways, hence different CIs and CMDB classes.

For meeting rooms, I'd suggest just extending the base cmdb_ci table creating the rooms as individual CIs and setting the location for it, which is already referencing the cmn_location table.

[DavidT]

hey guys,

thx for advices.

1 of the project goals is to transfer current content of a custom table containing 'categories' of inc/req, into the CMDB as CIs. So it looks easy for classic apps (cmdb_ci_appl + all derived classes), business services (cmdb_services). or even the meeting rooms (a new derived class from cmdb_ci as suggested).

But less obvious when 'categories' are for requests in the area of ITAM / Facility management. Unfortunately we don't have maturity & time to implement those processes on a worldwide scope. (but facility mgmt in Geneva looks great )

Also, just to make it clear, we do not intent to list all peripherals/components/desks/elevators of each user/location. We just need "types" of peripherals/components/assets. So a kind of 'class of classes'. In some locations the request fulfillment process uses a lot of details 'categories', so potentially I need as many generic CIs (mainly things that would fall into classic ITAM / Facility area)

We do not use the SN Discovery to feed the CMDB. So we do not gather already 'installed software' from Windows control panel. But I'm not sure even that would match the need.The goal is to propose a clean list of potential installable software a user can request (and what is in control panel doesn't always have the required level of details)

For 'complex' apps we intent to manage a related list of 'modules' to allow the user to refine its inc/req (typically for credentials like you said in your example)

D.