<< Click to Display Table of Contents >> Navigation:  Standard Features > Asset Management > Asset DB > Asset Form

Each asset or configuration item (CI) in the Asset DB has the following form structure, which is divided into form sections:

 

Header

•Title of asset

•State: A generic state model makes it possible to map the life cycle of each asset type. Next to the "State" drop-down field, you can display the entire model graphically. The model opens read-only in a new tab. The model will close again when you close the tab. In the graphic, the currently selected state is highlighted in yellow, and all subsequent states that are directly possible from this state are marked with a red arrow. Due to defined rules, some state changes can only occur under certain preconditions (mandatory fields, dependent values) or are not possible. When a new asset/CI is created manually, it always starts in the "New" state.
 

 

The most important information in the asset is displayed summarized in 4 tiles, similar to the ticket.

If a tile does not contain any information, this tile is hidden.

 

The tiles contain the following information:

 

•1. tile: asset type, unique asset number, assigned category

•2. tile: defined criticality of the asset, number of assigned logical successors of this asset, general automatic note

•3. tile: number of links to open tickets, persons, organizational units

•4. tile: state of the asset with corresponding color (green: active; orange: restricted; red: inactive; gray: all other states)

 

•

 

Section: "Properties"

•Attributes: The administrator can define any attributes for each asset type, which describe all necessary detailed information of the asset/CI type as an individual attribute list with corresponding values. Attributes can be detail typing of an asset type or further descriptive functions or characteristics (example: asset type: printer; attributes: Printer type: laser; Manufacturer: XY; Sheet feed: A4; WLAN-capable: yes; Software version firmware: 1.2.3 etc.). This allows completely free content management of the assets/CIs.
 
In addition to the attribute list, the following function buttons are available:

oUpdate the attributes from the asset type: If the administrator has added new default attributes for the asset type in the meantime, these can be loaded into the attribute list via update. New attributes can only be added by the administrator of the asset management database.

oCreate Reminder: If date values are stored in the attribute list (e.g. for an attribute "End date of warranty"), the user can create a reminder for the attribute by selecting the attribute. The date value of the attribute is automatically transferred to the reminder.

 

•Change history: The change history is an automatically generated list of all important changes that have been made to an asset/CI. This provides you with an easy-to-trace documentation of its life cycle. This history records the following changes:

oAdding/changing an attribute

oAdding/removing an organizational element (person or company/organizational unit)

oChange of a dependency (add/remove a dependency)

oChange of the state of the asset/CI

 

Section: "Details"

 

•Responsible: The responsible group or user can be entered for each asset/CI. The responsibility itself has no special authorization restriction, but is used for easier filtering by responsibilities if required.

•

•Primary user: Information about the user to whom this asset is primarily assigned. If a baramundi integration is available, the primary user will be assigned automatically via the import (if the e-mail address in bMS and the ticketing system master data match). The primary user will also be added to the list of users (Organization section) each time it is changed.

•Name: The name of the asset can be specified individually. This is displayed as the title. Is filled via the import in case of bMS integration.

•Unique number: An asset/CI must have a unique number. The system itself assigns a unique number (prefix CI with a sequential number) if you create it manually. Alternatively, you can assign your own unique letter-number combinations. These can be serial numbers or other unique identifiers, for example. This number is important, for example, to be able to identify the correct asset/CI for updates in the case of imports.

•Criticality: The criticality is scaled from 0 to 9 and is relevant for calculating the impact if this asset/CI fails. The administrator can define a matrix by which the impact due to the failure is automatically calculated from the combination of the criticality and the assigned ticket. A high criticality of the asset/CI is to be assigned, especially for central technical systems when potentially high impact on operations or security is possible.

•Category: Each asset/CI can be assigned to an individual category in order to perform appropriate filtering and evaluations, which can also be important in ticketing.

•Location: Assignment of a dedicated location for this asset for filtering, evaluations and as information for the service employee if an on-site mission is necessary for this asset.

Section Description

•Description: Free text for optional description of the asset/ CI.

Section: "bMS" (baramundi Management Suite)

Function only available with integrated baramundi Management Suite option

This section is only displayed if the asset is an endpoint managed by baramundi Management Suite (bMS). This means that this asset has been inventoried from bMS as an endpoint and is also updated via this or bMS jobs can be executed on this asset.

 

The section contains the following fields and functions:

 

 

•Show Details to Endpoint: The button allows retrieving detailed information of a selected endpoint at any time and to display it in a window. This is current information from the endpoint that is not stored in the ticket system (various parameters and the list of software installed on the endpoint).

•Executing Job: Selection of all available jobs and execution of the job on the current asset (only jobs are selectable according to the asset / endpoint type and the current user is allowed to execute the particular job). If no optional later execution time is set, the system tries to execute the job immediately, otherwise the execution waits for the time. In order to activate execution, this button must be pressed for each job in any case.

•Execution time: Optional time at which the job should be executed (if the job should be executed in a maintenance window or when the asset/endpoint is available at a certain time).

•BMC: Opens this Endpoint with the baramundi Management Center. Note: this only works when the BMC is installed at the current computer

•Jobs: List of job executions with display of the respective job execution state (planned, started, successful, unsuccessful). This documentation of the executions enables a continuous traceability of what actually happened on the endpoint. If the job execution was not successful, an error message is displayed, which was sent back by the bMS server. The list of job executions can be refreshed using the "Refresh" button. The list is automatically refreshed only on the first day of execution, if no final feedback on the job state is then available, the state is set to "unknown" and the cause may have to be researched directly in bMS. Furthermore, a planned job can be canceled manually.

Section: "Organization"

Within the form section "Organization", reference lists of the assigned organizational units and persons using this asset/CI are displayed.

Here, new references can be added or existing references can be removed using the "+" or "-" buttons. Assets can be assigned to one or more persons or organizational units.

•Assigned companies/org.units: The company or organizational unit to which this asset/CI is assigned is listed here. This assignment is useful if an asset cannot (only) be assigned to a specific person.

•Assigned persons: The persons to whom this asset is directly assigned are listed here. When a person is selected as the affected person in a ticket, the list of the person's direct assets is displayed.

 

 

Section: "Tickets / Tasks"

This section contains the following lists, which can be directly maintained:

•Assigned tickets: All tickets related to the selected asset are listed here. The list shows open and closed tickets.

•Assigned tasks: All tasks related to the selected asset are listed here. The list shows open and completed tasks.
 

Section "Dependencies"

This section defines the relationships of an asset/CI.

•"Contained in" / "Contained": The list shows whether the asset is part of another or contains other assets. Therefore, this link represents a "physical relationship". This can be used, for example, to document installed parts of a product.

•"Predecessor / Successor": These lists describe "logical" relationships of the CIs to each other, i.e. hierarchical or functional relationships. Such a relationship can be, for example, a business application that is based on several sub-services. Using the relationships, a ticket processor can very quickly get an overview of which other assets/CIs may be affected by an incident or by a change to the respective asset/CI.

 

The logical relationships can be displayed (up to a maximum of 4 levels up and down) via the relationship tree button between the lists, as in the Asset Explorer. The current asset/CI always represents the starting point.

 

 

 

Section "Contract"

For the asset type "Business Service", the additional section "Contract" is displayed (function "Service Orientation"). The assigned SLA contract valid for this asset/CI is displayed here.

 

An SLA contract allows you to set predetermined response and resolution times. When a ticket is linked to an affected asset, the System checks for an SLA contract and selects the SLA with the most critical times for handling the ticket.

Section "Comments"

•Comments: A general comment field allows saving a comment about the asset at any time. The comment is saved with username, time stamp and the information about the current state of the asset/CI.

Section "Attachments"

•Attachments: Standard function to upload attachments to the asset/CI. Attachments can be a maximum of 10 MB per file.

Section "History"

Similar to ticketing, the manager can see the form section "History" in an asset form. Here, all changes that were made to the asset manually by a user or automatically by the system are displayed in detail in a list that cannot be manipulated.