6 Replies Latest reply on May 1, 2018 9:44 PM by Julian Wigman

    Configuration Items Structure

    JohnO Specialist

      Hi Everyone,

       

      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!

       

      Sincerely,

      John

        • 1. Re: Configuration Items Structure
          Julian Wigman ITSMMVPGroup

          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.

           

          Julian

          MarXtar Ltd

          • 2. Re: Configuration Items Structure
            JohnO Specialist

            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.

             

            Thanks again you for all your help.

            Sincerely,

            JV

            • 3. Re: Configuration Items Structure
              Julian Wigman ITSMMVPGroup

              JohnO

               

              Different CI Types...

              • 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!

               

              Julian

              MarXtar Ltd

              1 of 1 people found this helpful
              • 4. Re: Configuration Items Structure
                Julian Wigman ITSMMVPGroup

                JohnOI see you havent marked this question as correct yet;  are you still needing help or advice on this one?

                 

                Julian

                • 5. Re: Configuration Items Structure
                  JohnO Specialist

                  Hi Julian,

                   

                  I think you covered everything. Let me mark this question correct. Thanks again for all your help!

                   

                  Sincerely,

                  John

                  • 6. Re: Configuration Items Structure
                    Julian Wigman ITSMMVPGroup

                    JohnO No problem.

                     

                    Julian

                    MarXtar Ltd