How do you structure Asset when each instance of a laptop can have variable hardware (different RAM, processor, etc.)?

garrett_griffin · ‎11-17-2015

-----

I have a client that is a fairly small company and allows their employees some flexibility within a particular laptop model.

How should this be structured? Do all instances of a hardware model need the exact same specs?

Community Alums · ‎11-17-2015

Garrett,

There are different ways you can handle this from the Model perspective:

Just do a single model record to represent the model of the device
Create individual model records to represent the different default configurations from the vendor

I typically recommend the latter, as that gives you more flexibility with regards to identification. For example, a manufacturer could put out a recall on laptops with an i5 processor but not the ones with an i7 processor. Or maybe a notice is put out on devices with a solid state drive but not those with a magnetic drive. Having separate models for the different default configurations can help isolate the appropriate systems.

Model records themselves, however, do not have fields for processor and RAM because these items can be changed in many systems. This type of information is maintained at the CI record because it represents the operational configuration of the item. Just like the OS and software installations can change on the device, so can some of the hardware characteristics. This is one of the great things about having Assets and CIs in the same system and linked. You track the configuration information in the CI and it does not need to affect the Asset record. If you track RAM or other components as consumables or assets, you can still tie them back to the asset record as part of an upgrade or change to that configuration, though.

I hope this helps get you going.

Ben

View solution in original post

A Westervelt · ‎11-18-2015

Unfortunately, you are at the whim and mercy of the manufacturer and how they define the devices they create.

Lenovo is the only vendor I have found that sets the model as the SKU rather than the model family like most do. I have a normalization rule that replaces the SKU with the family has the Model Name and then shunts it off to Model Number.

rjstefani · ‎11-18-2015

Hi Ben,

We are currently creating individual model records to represent the different default configurations from the vendor. I do have a question about one of your comments.

You state that the model records themselves do not not have fields for processor and RAM because these items can be changed in many systems. This type of information is maintained at the CI record because it represents the operational configuration of the item. Just like the OS and software installations can change on the device, so can some of the hardware characteristics.

I 100% agree with that statement, but would it not be advantageous to store what RAM, Processor and OS come with the hardware on the model table? Wouldn't this allow you to more effectively manage what hardware came with from the vendor v.s. what is active in your environment? I have made several requests to my development team to add fields on the model to store the models default configuration, and there has been hesitation.

Examples as to why I believe we would do this is as follows: Our organization orders Model x with 4 GB of RAM from the vendor. At times we install an additional 4 GB of RAM to Model x. If we rely only on the CI for that information, it will appear that Model x came with 8 GB of RAM straight from the vendor, which may make it appears if it were another model in our organization. If we store what the models default configuration came with on the model, we could compare that it came with 4 GB of RAM and we installed an additional 4GB of RAM.

Community Alums · ‎11-18-2015

Hi Ryan,

This seems like a perfectly valid reason to me to add these types of details to the Model record. You could even set up some reporting to identify when the information is different.

Ben