Adding and maintaining configuration item information occurs at various stages of a CIs life cycle and is performed by different people. Use the following guidelines when entering CI descriptive or status information.
When to Make Changes
Specific life cycles exist for different CI classes. In general, all life cycles contain the following phase:
...
| columnStyles | width:200px,width:350px,width:125px,width:125px,width:175px |
|---|
| sortColumn | Field Name |
|---|
| sortIcon | true |
|---|
...
On Order
...
Non-Operational
...
Pending Install
...
Operational
...
Installed
...
Operational
...
Retired
...
Non-Operational
...
There are some additional options available for these fields and these are detailed below.
CI Maintenance Form Field Definitions
Each CI class has a different maintenance form designed to collect the information specific to assets in the class. However, there is certain information that is required for all CIs regardless of class. The following table lists these fields. The fields are listed in alphabetical order by field name and not in the order they appear on the CI maintenance form. If the form you are presented with in ServiceNow does not include all the fields listed here then make sure you are using the view named Default view. If you are in the default view then notify the OIT Help Desk or one of the CMDB Administrators.
...
...
| columnStyles | width:175px,width:350px,width:350px,width:75px,width:75px |
|---|
| sortColumn | Field Name |
|---|
| sortIcon | true |
|---|
...
Name
...
Provide the unique name used to identify the asset represented by the CI. Naming standards exist for most CI classes and these should be followed as closely as possible. A list of naming standards is located Here.
...
None
...
Description
...
| Expand |
|---|
| title | View Installation Status options and definitions... |
|---|
|
- Absent - Asset is cannot be located or otherwise accounted for.
- In Maintenance - Asset is offline or otherwise unavailable due to maintenance.
- In Stock - Asset is not currently being used but is in inventory and can be deployed if needed.
- Installed - After project tasks are completed and the work is in production, an evaluation is performed to highlight project performance.
- On Order - Asset has been ordered or is being developed and is not yet ready for installation.
- Pending Install - Asset has been acquired or development is complete but the asset has not yet been installed for use.
- Pending Repair - Asset requires maintenance and is not available for use but maintenance has not yet started.
- Retired - Asset has reached its useful life and has been removed from service. Retired assets are typically salvaged or otherwise disposed of.
- Stolen - Asset has been physically removed without permission or acknowledgement of OIT management.
|
...
Installed
...
Current functional state of the project. When changing a project state only the following transitions should be used:
When the Current State is: | It should only be changed to: |
|---|
Pending | Work in Progress, Closed Withdrawn |
Work in Progress | Hold, Closed Complete, Closed Incomplete |
Hold | Work in Progress, Closed Complete, Closed Incomplete |
Closed Complete | No option |
Closed Incomplete | No option |
Closed Withdrawn | No option |
Note that changing a project State to or from Work in Progress or any of the Closed states can have unexpected side effects.
| Expand |
|---|
| title | Click Here for more information. |
|---|
|
Project State Rollups and Roll Downs Project task states roll up. The state of parent tasks becomes read only and is updated automatically when you change the states of child tasks. Project task states can roll up if: - The state of the child task is manually changed and there are no other conditions on the parent task.
- The state of the child task is changed to Work in Progress or Closed. These states roll up to the parent. Pending and Open do not roll up to the parent task.
Project states can also roll down: If you change the state of a project to Closed, all tasks under it change to Closed Complete. If a closed project or closed task is reopened, all tasks under it change as follows: - If the project or parent changes from Closed to Pending or Open:
- Child tasks change to Open.
- If the project or parent changes from Closed to Work in Progress:
- Child tasks with a Start on date that has passed are changed to start ASAP and the State is changed to Work in Progress.
- Child tasks with a Start on date that has not yet passed retain the same start on date but the state is changed to Open.
|
...
| Expand |
|---|
| title | Click here for State options and definitions... |
|---|
|
- Pending - Projects that have been partially entered but are not yet ready for formal submission due to missing or evolving information or requirements. Also, projects that have complete information but have not been initiated due to timing, available resources, or other coordinating events.
- Work in Progress - Active projects that are consuming resources.
- Hold - A project that has reached the Work in Progress state but needs to be paused for timing, available resources, or other coordinating events.
- Closed Complete - The project has been completed and no more activity is being tracked against it.
- Closed Incomplete - Work on the project was started but the project is being abandoned without having achieved the defined goals.
- Closed Withdrawn - The project did not pass the PENDING stage but will no longer be considered for dedicating resources to.
|
...
Pending
...
The intended date the project should begin. If the Calculation field is set to Automatic then the planned start date is set to the earliest time that the project schedule allows. For example, if the project task is created at 3:00pm and the default schedule is in use (which has an 8:00am start date), the default task start is 8:00am the next day.
Click the calendar icon and select a date to start the project. Projects do not automatically start on the planned start date. The project actually starts when you click Start project or set the State to Open or Work in Progress.
...
The intended date the project should end. This field can be set manually but it will be recalculated if the Planned duration or Planned start date fields change. This date is used when preparing reports showing project performance based on dates (i.e,. projects completed early or late).
...
The expected duration of the project. The duration is recalculated if the planned end date changes. The duration also considers the project schedule, accounting for any non-work time in the schedule. For example, if the default schedule is used, with a standard 8-hour work day, a project that starts at 8:00am on July 1 and ends at noon on July 2 is calculated as 1 day and 4 hours, not 28 hours. Any project or project task with no children is restricted to a maximum duration of 1,500 days.
...
| Expand |
|---|
| title | Click here for Calculation options and definitions... |
|---|
|
- Automatic - Begin dates, end dates, and percent complete will be automatically rolled up based on individual task dates and completion percentages from project tasks. Experienced users may want to use this option, but the results can be confusing for less experienced users and the results will rarely coincide with values generated by tools other than ServiceNow (e.g., MS Project).
- Manual - Begin and ending dates and percent complete will not be rolled up from individual project tasks. This is the recommended setting in nearly cases.
|
...
Manual
...
| Expand |
|---|
| title | Click here for Risk options and definitions... |
|---|
|
- Critical - Project is either stalled or is at imminent risk of becoming stalled. The project team cannot resolve the issue without direct attention from the project executives. Immediate action is needed to get the project moving again.
- High - There is a certainty that the project will be impacted by something that is outside the control of the stakeholders. This can include loss of resources (staff, funding, etc.), excessive scope creep, significant noncompliance with project requirements, major testing failures, etc. If remedial action is not taken, the project will stall.
- Moderate - It is possible that the project will be impacted by something outside the control of the stakeholders. This can include changes in system architecture, nontrivial changes to project scope, changes in project staffing, reduction in funding, etc. If remedial action is not taken, the project will be able to continue but milestones may be missed or deliverables may have to be re-evaluated.
- Low - A risk has been identified but the remedy is easily managed within the framework of the project organization. (It is to be expected that most projects will fall into this category most of the time.)
- Planning - Work on the project has not yet started.
|
...
Planning
...
Provide a brief, overall summary of the current state of the project. This information will be used on reports used to inform stakeholders on the project status. Updates to this field will overwrite previous status information and the previous information is not automatically saved. If you want to preserve an archive of the status notes, they should be copied to the project's Work notes field before being updated here.
...
Proposal Section
Use this section to provide specific details about the project. If you have more information than is practical to enter into any of the fields then provide the information as documents attached to the project record and reference the documents in the proposal fields.
...
Use this section to identify aspects of the project that may impact or be impacted by OIT's overall system architecture. For each category, indicate whether the statement applies. Where a statement does apply, provide a brief comment indicating the nature of the impact or interaction. If you respond "Yes" to two or more statements, you will be contacted by someone from the ARB to determine whether a full ARB review of your project will be necessary.
...
No
...
No
...
No
...
No
...
No
...
No
...
If the project requires integration with external or third-party technologies or solutions, reply "Yes" and include a list of the external technologies and how they will be used over the course of the project.
...
No
...
Optional
...
This is a read-only field indicating the recommendation for next steps based on the responses to the statements. There are three possible outcomes:
- No "Yes" responses: No action by the ARB will be required.
- One "Yes" response: It will be suggested that you review your project plan with someone who has expert knowledge of the area that will be impacted.
- Two or more "Yes" responses: You will be instructed to contact the ARB and set up a preliminary review of your project. Depending on the outcome of that review, you may be required to present your project plans to the ARB for a more thorough review.
...
n/a
...
Scorecard Section
Use this section to provide project scoring information. See Project Scorecard for details of how project scoring works and a definition of each scoring factor.
Project Team Section
All project require a project team. At a minimum, a project must have a Project Manager and Executive Sponsor identified. See Project Team Roles & Responsibilities for information on other project team members.
Project History Section
This section contains an ongoing list of changes to the project information and additions to the Work notes field. The section is intended for reference only and has no fields that can be directly updated.
Checklist Section
Provides the ability to define steps and track the progress of tasks without creating additional records. Adding items to a chacklist and checking off completed items does not automatically update the percent complete or state of the task or project.
Time Cards Section
Create time card entries and log time worked against a project or task.
...
...
Adding and maintaining configuration item information occurs at various stages of a CIs life cycle and is performed by different people. Use the following guidelines when entering CI descriptive or status information.When to Make Changes
Specific life cycles exist for different CI classes but in general, all assets go through the following phases:
Image Added
Changes are required to the CI record in the CMDB whenever an asset moves from one phase to the next in its life cycle. Changes reflecting the current operational state of an asset may also be required while the asset is in service (Phase 4). The two primary attributes used to indicate the current life cycle phase of an asset are Install Status and Operational Status. These are used as follows:
| Table plus |
|---|
| columnStyles | width:200px,width:350px,width:125px,width:125px,width:175px |
|---|
| sortColumn | Field Name |
|---|
| sortIcon | true |
|---|
|
Phase |
State | Install
Status | Operational
Status |
Set by |
|---|
Phase 1:
Request & Approval | No CI is required at this stage since the asset is not part of the actual configuration. This phase ends when the approval has been received to acquire or develop the asset. | n/a | n/a | n/a | Phase 2:
Ordering & Acquisition | The asset has been ordered from a supplier or, for software or systems, a project has been initiated to develop the asset. This phase ends when the asset is ready to be installed in an environment where testing can begin. | On Order | Non-Operational | Asset owner, project manager, or CMDB administrator | Phase 3:
Installation & Testing | The asset is being installed and tested. (Note that this does not always mean "production" since many systems are installed for the purpose of developing and testing software.) This phase ends when the asset is fully functional and is ready to be used for its intended purpose. | Pending Install | Operational | Asset owner or CMDB administrator | Phase 4:
In Service & Maintenance | The asset is performing the function for which it was intended. Throughout this phase, the asset will undergo periodic maintenance, upgrades, failures, and fixes. At some point, the usefulness of the asset will come to an end and it will be taken it out of service. This phase ends when the asset has been removed from service. | Installed | Operational | Asset owner or CMDB administrator | Phase 5:
Asset Retired | The asset is not needed for its original purpose and is no longer being used. | Retired | Non-Operational | Asset owner or CMDB administrator |
|
There are some additional options available for these fields and these are detailed below.
CI Maintenance Form Field Definitions
Each CI class has a different maintenance form designed to collect the information specific to assets in the class. However, there is certain information that is required for all CIs regardless of class. The following table lists these fields. The fields are listed in alphabetical order by field name and not in the order they appear on the CI maintenance form. If the form you are presented with in ServiceNow does not include all the fields listed here then make sure you are using the view named Default view. If you are in the default view then notify the OIT Help Desk or one of the CMDB Administrators.
| Table plus |
|---|
| columnStyles | width:175px,width:350px,width:350px,width:75px,width:75px |
|---|
| sortColumn | Field Name |
|---|
| sortIcon | true |
|---|
|
Field Name |
Description |
Choices |
Default |
Required |
|---|
| Provide the unique name used to identify the asset represented by the CI. Naming standards exist for most CI classes and these should be followed as closely as possible. A list of naming standards is located Here. | | None | Yes | | A concise description of the asset that can be used to clarify the CI name. The description should never be more than a paragraph and rarely more than a few sentences. If a more detailed description is needed then either include a link in the description or attach a document to the CI record. | | None | Yes | | Additional information about the asset. The Comments field is not usually shown on reports and inquiries against the CMDB table unless specifically requested. | | None | No | | Provide the name of the primary group responsible for supporting the asset in production. This is usually the group that would be contacted first for questions and technical support. | Select from reference list | None | Yes | | If there is one specific person in the support group who provides support for the asset, name that person here. It is generally not a good idea to name a person in this way since assignments and responsibilities change frequently. It is recommended that this field be left blank. | Select from reference list | None | No | | If there is a specific support group that should be automatically assigned to all incidents relating to the asset then name that group here. Leave this field blank if the assignment group is the same as the support group. It is recommended that this field be left blank. | Select from reference list | None | No | | If there is one specific person in the assignment group who should be automatically assigned to all incidents relating to the asset then provide that person's name here. It is generally not a good idea to name a person in this way since incidents will be assigned to that person whether he or she is available or not. It is recommended that this field be left blank. | Select from reference list | None | No | | For assets that are supported for a specific functional unit other than OIT, provide the name of the group here. Use this field only if the asset is used by a single functional unit. | Select from reference list | None | No | | For assets that are supported for a specific functional unit other than OIT, provide the name of the person primarily responsible for the asset. | Select from reference list | None | No | | Select the appropriate installation status of the physical asset represented by the CI. Note that the default value for this field when adding a new CI is Installed. This indicates that the asset has been acquired or developed and is in place, ready for use. If this is not the case than change the installation status as needed. | | Expand |
|---|
| title | View Installation Status options and definitions... |
|---|
| - Absent - Asset is cannot be located or otherwise accounted for.
- In Maintenance - Asset is offline or otherwise unavailable due to maintenance.
- In Stock - Asset is not currently being used but is in inventory and can be deployed if needed.
- Installed - After project tasks are completed and the work is in production, an evaluation is performed to highlight project performance.
- On Order - Asset has been ordered or is being developed and is not yet ready for installation.
- Pending Install - Asset has been acquired or development is complete but the asset has not yet been installed for use.
- Pending Repair - Asset requires maintenance and is not available for use but maintenance has not yet started.
- Retired - Asset has reached its useful life and has been removed from service. Retired assets are typically salvaged or otherwise disposed of.
- Stolen - Asset has been physically removed without permission or acknowledgement of OIT management.
|
| Installed | Yes | | Select the appropriate operational status of the physical asset represented by the CI. Note that the default value for this field when adding a new CI is Operational. This indicates that the asset is online and is being used as intended. If this is not the case than change the operational status as needed. | | Expand |
|---|
| title | View Operational Status options and definitions... |
|---|
| - Operational - Asset is fully deployed and is ready for use. This status should only be used when the installation status is Installed.
- Non-Operational - Asset is offline or otherwise unavailable due to maintenance or repair.
- Repair in Progress - Asset is offline being repaired.
- DR Standby - Asset is installed and ready to be used for disaster recovery purposes. Assets marked with this status should not be used for any other purposes as they must be immediately available when needed.
|
| Installed | Yes | | Indicates the origin of the CI record representing the physical asset. When adding CIs manually this should be set to Manual Entry. When assets are added via an automated discovery process the field will be updated by the automated process. | Select from list | None | Yes | | The date the CI was last reviewed for completeness and correctness. | Date | None | No | | Name of the person who typically provides first line support for the asset. Multiple names are allowed and a group name may be provided. Although this may contain the same information as the Supported by and Assigned to fields, it is not a replacement for those fields. Supported by and Assigned to are used to auto-assign incidents while Tech Support is used for reference only. | Free form | None | No | | Name of the person who typically provides second line support for the asset. Multiple names are allowed and a group name may be provided. Although this may contain the same information as the Support group and Assignment group fields, it is not a replacement for those fields. Support group and Assignment group are used to auto-assign incidents while Tech Support is used for reference only. | Free form | None | No | | Disaster Recovery criticality used to prioritize the recovery of assets in the event of a major disaster. A knowledge base article that contains details of what the options mean is available Here. This field is mandatory for the Business Service and Application classes. However, it can also be used by individual support teams to document DR priority for assets supported by the team. | | Expand |
|---|
| title | View Details of DR Criticality options... |
|---|
| - 15 Minutes
- 6 Hours
- 24 Hours
- 5 Days
- 30 Days
|
| None | No |
This section is used to document relationships and dependencies between assets. |