I feel that it is quite tedious to create separate windows/forms for each CI. Our current ticketing system allows us to select an "Asset Type Name" and manually enter the rest of the items details pertaining to that selected item. If we need to query a particular asset type all we do is filter search to only Asset Type Name that contains a particular item.

Screenshot is shown below:

Another idea in mind was to create a separate drop down menu for one CI. For example, Workstation window has a drop down menu called "Asset Type" and it has "Laptop" and "Desktop" on it. Asset windows also has a drop down menu called "Asset Type" and it has "Signature Pads", "Aircards", and "USB drives".

If I need query a list of aircards for example, I should be able to get a list of aircards. I was wondering all the items on every CI "Asset Type" are store in one table? Sometimes we like to add more item types. Let me know your thoughts about this. Any help is always appreciated!

All CI’s inherit from the “Configuration Item” object in the same way that all ITSM processes inherit from the “Process” business object.

I don't see any reason why you couldn’t just have 1 window for all CI’s under “Configuration Item” and then have a “type” dropdown list of your own to distinguish between the CI types.

Of course as they’ll be effectively all in the same object you’d have to setup dynamic windows to show/hide irrelevant fields for the different types maybe and we know how much of a pain that can be from the Service Request side of the house. Also you wouldn't have different images for the types if you wanted to go down the CI structures route.

IMHO it does take time to create the CI windows, most customer rarely have more than a dozen of these in their CMDB so the window design is a one-off task to do but not onerous really.

The biggest issues with CMDB design normally come from versioning and having the right attributes created at the correct level especially if you want both automatic and managed versioning available at the same time. The one-way enablement (only) makes it even more tricky so rule of thumb is then “measure thrice, cut once” for sure.

JulianWigman If you don't me asking you another question which is why are there several default CI's listed under Configuration Management. We are thinking of just using just one CI which is "Asset" for all items including laptops, workstations, printers, monitors, etc.) I just don't understand what is the purpose of having all these separate CI's where you can just use one.

Different forms for each as not all data is common; eg # of bins, paper size on a printer, screen resolution of a monitor.

If you have Asset Manager license then different lifecycles per CI type.

If you are licensed for CI structures (Impact analysis) then different images for each CI type make diagram easier to follow.

Some CI types can be set as containers for your Service Catalogue

You can set Business Object behaviours of separate CI types; calendaring for example for loan CI types

Different versioning setups for CI types as well; Managed versioning for Servers versus automatic versioning for laptops and workstations etc

There’s nothing wrong with you using just one CI Type if the above isnt important to you but personally haven't come across any other customers taking this approach other than at a limited level, for example having one CI type for pcs or network equipment and then setting its sub type via another field. At the end of the day though a CI doesn't change type, hey “once a printer, always a printer” so apart from less imports and windows there isn't too much overhead otherwise IMHO.

One downside of many CI types though is deciding where to create attributes as they all inherit from the base “Configuration Item” object. This needs a bit of careful planning especially if you are combining with different versioning strategies (managed and automatic) too as it’s a one-way path when you turn on versioning and nightmare if you get the strategy wrong. Do not version the top level “configuration item” object with a certain versioning type unless you want ALL children to inherit that versioning type as well!