Table of contents
Service Asset and Configuration Management - ITIL® Process
Setting up a CMDB (coming soon)
The Service Asset and Configuration Management process is managed in the Configurations module; it represents the heart of Octopus due to the relations that can be established between its components and all other modules. It is often referred to as the CMDB.
This article explains how to set up the structure of the module, in order to constitute a powerful relational database of configuration items (CIs) that will be used throughout Octopus.
Configurations Module Structure
To configure the structure of CIs, you need the Administer Octopus permission in order to access Tools > Reference Data Management... > CI. Before creating or importing CIs, it is appropriate to adapt the structure to your context and infrastructure reality, by identifying the essential components and their configuration that will be part of your IT service delivery.
The Status represent the lifecycle of CIs; you can enlarge the lifecycle by including specific status applied to software development (designing, building, testing, deployment, etc.).
The CI status can be configured in Tools > Reference Data Management... > CI > Status.
- Add a status : right click on Status, select add, enter status name in French and English, and save. The status will be available in CI records
- Delete a status : right click on a status and delete. Note that the system will refuse to remove the status if a CI is currently using the status
- Merge a status : if two status have a similar use, they can be merged. Select the status to be merged into the other one, then click the Merge button, and select the status that will remain
The time range identifies the service range of a CI.
You can refer to Event Management - Octopus Module, that explains how to configure a CI service range.
Relationship Types define the bidirectional relationships that exist between 2 CI types. Then, each CI type will be associated thru the authorized relationships to other CI types. The Types section below explains this configuration.
To add a relationship type:
- Right click on Relationship Types and then click on Add
- Enter the description and its opposite description, in French and in English; for example, Includes and Is included in
- Save and Close
In Octopus, several CI types are preconfigured to facilitate the initial configuration of the Configurations Module. According to the CI types, the configuration can be simple, as with a module or a lot more complex, as with an information system; authorized relationships, attributes and categories bring you the flexibility to determine the right level of complexity to apply to each CI type.
At the top of the CI Type window, you must make the following selections:
- French Name
- As this field cannot stay empty, in a unilingual context, add the same name as in English
- English Name
- You can pick the icon that will appear in lists for CIs of this type.
- And you can determine if the CI type is active or not
The configuration of a CI type implies several tabs, as described below.
- Permission for modification: apply a custom permission for a CI type. For example, the modification of a "Server" CI type can be restricted to assignees having this permission in their role. This allows increased security when necessary. See the Customize permissions for a CI type section in Role Management
- Is a document: adds a Document tab un the CI record when this CI type is designated as a document. These CIs represent procedures, user guides, infrastructure documentation, processes, etc.
- Is a computer: means this CI type can be inspected with WMI
- Replacement Duration: by indicating a theoretical lifetime (in years) and the suggested replacement value, Octopus is able to calculate, based on the purchase date, the replacement year and the replacement value of a CI; this data is useful in asset replacement initiatives. This information will show up in the Maintenance tab of each CI and will be specific to this CI type. For example, the workstation CI type could have a theoretical lifetime of 3 years, with a suggested replacement value of $1,200.00. Based on the purchase date, Octopus calculates the replacement year and will present the suggested value for each workstation. According to the CI level used, the expected replacement year could be modified directly in the CI.
The Relationships Tab establishes the authorized relationships between CI types. This avoids unwanted (or technically impossible) relationships between CIs. Then, when establishing a relationship from a source CI to a destination CI, only the authorized relationships for these CI types will be presented.
Relationship dependencies can be established. There are 3:
Required for operating
The Required for operating dependency is used to identify CIs whose operation depends on the operation of another. For example, a server on which is installed an application; the availability of the application depends on the operation of the server.
The Cost Distribution dependency reports the total cost of ownership (TCO) to the total cost of ownership of another CI (total cost of ownership = purchase cost + maintenance cost). For example, if a module is related to an application, The TCO is calculated for the module will be reported on the application's TCO.
The Composition dependency associates a CI to another CI in a exclusive hierarchical relationship similar to a parent-child relationship. Then, when creating a request, we will see the "children" CIs connected below the parent CIs. In Octopus, such composition relationships exists between workstations and softwares.
An attribute is an important information about a CI that needs to be recorded and followed. Some attributes are automatic (inspected by WMI), others can be manually entered. It is important to identify the necessary attributes implicated into the IT service delivery, no more no less, otherwise, the CI maintenance becomes too complex and costly. The Attributes Tab manages addition, edition and deletion of attributes. An example of the extended use of attributes could be recording books as CIs; we could add attributes such as Last Edition Date, ISBN number, Publisher, etc.
The Categories Tab categorizes certain types of CI. The example below shows printer categories. Another example could be the different server categories: physical, virtual, clusters.
The Maintenance Tab specifies the group / assignee responsible for the CI type. This information is used in the configuration of the Planned Request Management Module.
The CI record contains a set of fields that are organized to quickly find the information about a CI. The top part shows the name, status, criticality, manufacturer/model, serial/inventory numbers, service range, the responsible department and main contact, site/local and category, if any.
Note that list of Manufacturer and Model fields can be configured, in Reference Data Management.
The lower section contains several tabs that are explained below.
Example of a CI record
The Relationships Tab consolidates the relationships of the CI with one or several other CIs. When you add a relationship, the system presents the authorized relationships, defined in the CI type configuration, in Reference Data Management.
To add a relationship:
- Click the button to add a relationship
- From the Link CI window, search for the CI to link and select it
- Specify the relationship type - only the authorized relationships configured for that CI type will be available
- Click OK
The image below shows the new relationship. If you want to view a diagram of all relationships for this CI, click on the icon located above the list of relationships.To find out more about visualizing CIs, see the How to use the graphic CMDB section.
The Configuration Tab contains all the related attributes of a CI record. Depending on the case, attributes are automatically detected with WMI or imported otherwise, along with those created with the CI type that can be entered manually. We recommend a task for updating CI record(s) when they are implicated in SR, problems and changes. This will ensure that CI information is maintained.
The Costs Tab contains financial information related to a CI record. This is where you can recompute CI costs; this action calculates the total cost of ownership (TCO), which includes Total Purchase Cost + Total Maintenance Cost.
The Maintenance Tab details the CI maintenance like the designated responsible group or assignee for the CI, the replacement information, if the maintenance is done by an external supplier and the planned request for this CI.
The Requests Tab contains requests linked with the CI. These include all request types: incidents, service requests, problems, changes, and events.
The Note Tab allows you to enter a particular note about the CI. This field is free text, and a red dot appears when information is written in the field.
Attached Files Tab
The History Tab contains all the modifications done to a CI record by an Octopus user. It keeps track of the modified attribute, its initial and new value, the new one, the date and time and the name of the person who make the change.
Keep the Change History Option
This option, which is available in the attributes of a CI, has a direct impact on CI's history, since it can prevent the history from being updated. The value of the attribute is updated, but when an attribute does not have this box checked, the changes made will not be saved in the history.
Creation of a CI
The creation of a CI can be done manually or with an import. The CI name constitutes the unique key of the Configurations Module; thus two CIs cannot have the same CI name.
For more details on the creation or update of a CI via an import, you can refer to the following articles:
ADSIReader -Integration to Active Directory (to import CIs)
WMIUpdater - Updating the computer configuration (to update CIs)
DataImporter - Import CI (to create and/or update CIs)
Manual Creation of a CI record
The manual creation of a CI record is done in 2 steps:
Step 1 : Recording of the CI
- Go in the Configurations Module
- Click the Create a CI action
- From the Create CI window, enter the information; by default, note that the Type and Name fields are mandatory. The type is chosen from a drop down list, but the name is a text field that must be unique. Note that other CI fields can be designated as mandatory in Tools > Configure fields..., in CI type section.
Step 2 : Documentation of the CI
Once the CI record is created, document the rest of the information from the top section and the tabs of this CI. We refer you to the CI Record section for a more complete description.
Deletion of a CI
A CI can deleted by clicking on the red X icon. Note that if a CI is already linked to a request, the system prevents deletion.
Specific Actions in Configurations Module
This action makes it possible to modify simultaneously one or more CIs. You can keep the value, empty it, unless the field is mandatory, or change the value.
The following items can be modified:
- When changing a type a checkbox allows to keep the same manufacturer and model.
- Service Range
- Main Contact
Start by the selection of one or more CIs with SHIFT, CRTL or ALT+A and then select Change CI.
A window will open to offer the available choices. Select the items to change, and empty or pick the new value.
The Default permissions for the Configurations Module are the following:
- Create a CI
- Modify a CI
- Modify CI status
- Recompute all CI costs
- Delete a CI
- Access the configuration management module
- Modify Location, Main Contact and Category
As the Configurations Module is directly related to other Octopus modules, it is possible to extract multiple information that will be used to analyze a particular situation or the impacts of a change.
There are 3 reports in the Statistics Module, in the Problem Statistics section:
- Problems > Most problematic CI : displays CIs with the highest number of incidents or problems
- Problems > Most problematic CI models
- Problems > Most problematic CI types
Many lists are available in the Configurations Module. Each list displays in brackets the amount of items contained in it. The default lists are:
- Computers never reached by WMI and Computers with WMI error : see the WMI Error Report section of the WMIUpdater - Updating the computer configuration article
- CI recently created (last 30 days): displays the list of CIs manually or automatically created in the last 30 days; note that the period can be adjusted by modifying list criteria
- CI covered by a service contract
- CI under warranty
- CI with expired warranty
- CI under lease
- Non-managed software: this is a filter of software installed on equipment connected to the network; by designating softwares that do not need to be managed on a daily basis, we restrict the view to only see softwares useful for operational management of CIs. The WMI detection will remain, but those CIs will be automatically classified in the non-managed software list.
- License control: see the License Management article for more information.
Other lists concerning CIs can be interesting. The possibilities are endless. For example, we may want to consult regularly, within the Service Asset and Configuration Management process:
- CIs grouped by status
- Retired CIs
- CIs affected by incidents, problems, changes, etc.
See the List Customization article to optimize your use of lists.
Exporting Lists to Excel
See the How to export data to Excel article. Once data is exported, it can be manipulated with Excel charts.
How to use the graphic CMDB
The CI visual mode aims to show all relationships in a graph based on one CI. This is a very useful tool, specifically for troubleshooting or to do impact analysis when planning a change.
Use the View relationships button to access it.
Once in graphic mode, some operations allow viewing information from different angles. The available options are:
- Levels : By default the graph will display 3 relationship levels from the selected CI. This amount can be changed using the up and down arrows or edited directly in the field. Use the Apply button to confirm and see the modifications.
- Relationships : Allows to select the displayed relationship types. For example: Is connected to, Depends on, Has for dependent, etc. Use the Apply button to confirm and see the modifications.
- CI Types : Allows to select the displayed CI types: Server, Workstation, etc. Use the Apply button to confirm and see the modifications.
- Hierarchical (left to right)
- Hierarchical (top to bottom)
- CI Label : Allows to change what needs to be displayed to represent the CI. By default, the CI name is displayed, but other attributes can be added, for example; the IP address, the CI type, the site, etc.
- Relationship Label : Allows to change what needs to be displayed to represent the relationship. By default, the relationship name is displayed, but other options are available.
Using a barcode reader
You can use a barcode reader to search a CI from a serial number. You can also use it to create a CI or update an existing one.
Here is how to use a barcode reader in Octopus:
- Click the quick search zone of any module.
- Scan the barcode.
- If only one serial number corresponds to the number scanned, it will come up.
- If more than one serial number corresponds to the number scanned, Octopus will show the list of CIs found.
- If no CIs correspond to the number scanned, Octopus will offer a choice between creating a new CI or adding the serial number to an existing one.
A CI is found
More than one CI found
No CI found - Create a new CI
No CI found - Modify an existing CI
Definitive Media Library
In ITIL®, there is a concept called Definitive Media Library (DML). The DML groups approved versions of all software CIs. This library can also contain related CIs such as licenses and documentation. The DML is controlled by the Service Asset and Configuration Management process.
Thus, in the Octopus context, each approved software version can be recorded as a DML CI type, in which we identify a link to the authorized installation file. It is then easy to group all those CIs and get a list of the DML content.
Software Development Management
If you have an internal software development team, you can exploit the flexibility given by the CI status configuration. For example, you create a CI record for a new application and you follow its development through specific status: designing, building, testing, QA, in deployment, until it is in operation.
Thank you, your message has been sent.