CI Assemblies/Configurations – How To Use Them – Part 1

CI Assemblies, or Configurations as they used to be called prior to Service Desk Express 9.6, are the basis for grouping Configuration Items, or Inventory Items prior to 9.6, together by location. What I thought I would write about in this post are my views on best practice for using them and some of the tricks/tips you might want to employ/watch out for in your own organisation.

A little imagination required…

I am going to try and explain the use of CI Assemblies through three, hopefully relevant, examples relating to a single, hopefully relevant, organisation. So for the purposes of this post, imagine an organisation spread over a number of sites, with assets and users in a variety of different buildings and rooms. Imagine that this organisation has a mix of laptop and desktop based users, using shared printing facilities and, to make it a bit more complex, using roaming profiles and hot desks. Finally, imagine that this organisation wants to be able to bill departments based on the assets assigned to them/their users.

So how could you implement this?

The first thing to understand is the database structure relating to CI Assemblies:

As you can see from the figure above, Configuration Items are linked to CI Assemblies on a one to many relationship such that a single configuration item can only be linked to a single CI Assembly but a single CI Assembly can have many configuration items assigned to it. Slightly harder to understand, a single CI Assembly can be linked to multiple clients AND a single client can have multiple CI Assemblies i.e. a many to many relationship. This is what provides us the flexibility to handle the example above but at the same time it provides an added level of complexity that needs to be very carefully handled, particularly when it comes to writing reports. More on that later.

So back to the question – how could you implement this?

Solution

The first thing I would suggest you do is add one or more modules to provide a definitive list of locations. Out of the box Service Desk Express doesn’t understand the concept of sites using CI Assemblies to manage locations. The building and room fields in the database are free text which can lead to data inaccuracies as a result of misspelled or abbreviated building names. I would suggest you build three new modules for Sites, Buildings and Locations as per the schema below:

So now each CI Assembly can/shall have a definitive location.

It is critical that your organisation agrees on a naming convention for CI Assemblies. I would suggest that you have a different naming convention based on the type of CI Assembly for reasons that will become apparent.

Now you can create a single CI Assembly for each desk in each location using the following naming convention for the CI Assembly ID: SSS_BBB_LLL_DDD where:

• SSS is a three letter site code
• BBB is a three letter building code
• LLL is a three letter location code and
• DDD is a three letter desk code.

This sounds like a lot of work and it is. The good news is that generally this information is relatively static data so once entered/imported the hard work is done.

Next we can assign all the fixed assets – desktop PCs, monitors, docking stations to these locations. For those users that are fixed to a given desktop PC I would then assign that CI Assembly to that Client. Hot Desks are frequently billed by department so I would link the hot desk CI Assemblies to the department manager.

OK, so that sorts out the hot desks and fixed desks. What about the mobile users.

Create a single CI Assembly for each user with a CI Assembly ID equal to their Client ID as a naming convention. Into this CI Assembly would go each user’s laptop, mobile phone, PDA etc. and potentially, depending on how you manage software licenses, each user’s software licenses. When a user logs a ticket with the Service Desk, the Service Desk is able to check where they are say and consequently link that CI Assembly ID to that user giving them a pick list of assets based at that location. That will sort out the mobile users.

So why does the system need to allow multiple users to own/use a single CI Assembly? Amongst other reasons – printers! We need to create a CI Assembly for each shared networked printer using an appropriate  naming convention (I’ll leave this one up to you). Assign the relevant configuration item (aka the printer) to it and then link each user that uses that printer to it. WHY????

Think for a moment about the Service Desk Agent – takes a call from Joe/Jane Public and is now able to say, “What is the issue?” and now has an appropriate configuration item to link to EASILY pretty much no matter what the answer is. This results in amazing data for analysis and take problem and change management to an exciting new level.

In the next post in this series I will look at some of the ways (read business rules etc.) that can be included to reduce the manual burden associated with the solution I have proposed above. Additionally, we will look at some of the issues/techniques for reporting on this solution.

As always, hope this has proved informative. Any comments, positive or negative always welcome. Thanks for reading.

• asset management
• CI Assembly IDs
• configurations