Asset Management best practice around EUC CI/Asset user associations

[Dan Herrick]

We have a problem with OOB SN fields for assets not meeting the requirements we have. We have a proposed solution and I would like feedback on it, or any other thoughts around a better way to manage this with as little customization to SN as necessary.

My question comes down to: "What is the best practice around associating end user computing CIs/Assets with people who use, manage, and own them, when those 'people' are actually 'groups'?"

For context, we are implementing hardware asset management for end user computer (EUC) devices such as laptops. We are a university for whom all such assets are not centrally procured and the financial "ownership", while ultimately all owned by the university, is considered from a department perspective. As well, our desktop support is distributed among various groups (generally organized by department) and generally there is support group assigned to manage a collection of assets, rather than a person. Finally, we have many multi-user computers (such as in computer labs) for which special consideration needs to be made.

Introduction

Out of the box (i.e., by default), ServiceNow includes these fields to associate a device with a person: Assigned To, Managed By, Owned By 

ServiceNow defines these terms as the following: 

• Assigned to: Person using or primarily responsible for this item. 
• Managed by: Person who maintains the asset. 
• Owned by: Person who has financial ownership of the asset. 

By default, ServiceNow carries the following assumptions: 

• Each of the above-named fields maps to a specific individual. This is explicit: ServiceNow uses a reference field to the User table. 
• The individual who (primarily) uses the computer is the same individual who is issued the computer. ServiceNow conflates usage of the computer with assignment of (and delegated property responsibility for) the computer.

The problem is that in actual practice, it may be a group or more than one individual that is more appropriate for each field. 

• Usage/Assignment: ServiceNow assumes that each device is associated with a specific individual who uses it (and only that individual uses it). We know that is not the case with all devices, particularly multi-user devices such as are used in computer labs and classrooms. Consider this example: When the manager of a QA testing group is administratively assigned the computer to use for her/his group, the manager is unlikely to be the one actually using it (and potentially registering support cases against it). 
• A group of people may “manage” a computer. For example, the technician on duty that day or who is assigned the incident against the computer may be the individual who manages that computer on that day, and not others. 
• Ownership (which we consider to be financial responsibility and decision-making ability) is normally at the department level.  

Because ServiceNow default settings and assumptions do not capture the university's standard business models, nor requirements we have for multi-user computers, we must define custom fields that allow for group associations. 

Our Proposed Solution

We would like to define these generic associations: Assigned To, Used By, Managed By, Owned By 

Each of the above associations can be made to an individual or a group. Note that in the nomenclature, “Group” is added at the end for group associations, while individual associations use the basic version of the name. (In other words, if it doesn’t say “Group” in the name, “Individual” is implied.) 

Association	Scope	Explanation
Assigned To	Individual	Administratively assigned to a person for use. The person is responsible for the asset while it is assigned to them. This field is not automatically populated by management tools like SCCM.   This field and “Assigned To Group” are mutually exclusive. Only one may be non-blank at a time.
Assigned To Group	Group	Administratively assigned to a group, business unit, or functional unit for use. The Group will have a responsible person in the Group’s settings. This field is not automatically populated by management tools like SCCM.  This field and “Assigned To” are mutually exclusive. Only one may be non-blank at a time.
Managed By	Individual	Person who maintains the asset. For hardware assets, this is less common than a Group assigned to maintain the asset.  This field and “Managed By Group” are mutually exclusive. Only one may be non-blank at a time.
Managed By Group	Group	Group who maintains the asset. For hardware assets, this is more common than an Individual assigned to maintain the asset.   This field and “Managed By” are mutually exclusive. Only one may be non-blank at a time.
Owned By	Individual	Person who has financial ownership of the asset. For university-owned assets, this should not be used.  This field and “Owned By Group” are mutually exclusive. Only one may be non-blank at a time.
Owned By Group	Group	Group who has financial ownership of the asset. Due to financial ownership, the Owner also has decision-making authority over lifecycle events (when it should be repaired, be retired, etc.), its value, appropriate use, and to whom it should be assigned.  This field and “Owned By” are mutually exclusive. Only one may be non-blank at a time.
Used By	Individual	Person who primarily uses the item, if applicable. For a single-user computer, this will most often match the Assigned To field. This field is automatically populated by integrated management tools such as SCCM and is allowed to be blank.  There is no corresponding “Group” association for this type.

Derivative Data 

“Individuals” are entries in the User table. These entries are populated in ServiceNow automatically from our AD.

“Groups” must be manually populated in a Group table. A group is a set of users who share a common purpose. Each Group has the following characteristics: 

• Display Name: The name displayed in associated lists and forms in ServiceNow. This name is selectable and searchable. 

• Parent Group: (optional) The Group to which this sub-Group belongs. 
• Responsible Person: This is a valid User Object from the User table. This is the person who “manages” the group (however that is defined: Administratively, organizationally, etc.) 

[Josh Beute]

Excellent breakdown of the OOtB details, and also describing the "workaround", thank you!

[Dan Herrick]

Thanks Josh. Since you responded, I'm adding some additional detail:

"Groups" - Since we already have a list of Departments (as a Group) that are populated and maintained by an external source, but this table doesn't list all possible groups we would want to track, we added another table where we can ad hoc add groups as described above, and then the "x By Group" fields above use a pastiche table that consists of Department table + ad hoc table as selectable options.