SM7 IE

89

SM7 IE

90

SM7 IE

The HP Service Manager Service Desk application enables a service desk operator to document and track received interactions. Service Desk provides one-click access to other Service Manager applications to automatically enter information received in the interaction.

91

SM7 IE

Service Desk (SD) is an integral part of implementing Service Manager in an organization. It equips your business with a comprehensive interaction management tool.

92

SM7 IE

93

SM7 IE

The Service Desk module provides a comprehensive Interaction management system that includes:

•Interaction tracking

•Interaction resolution

•Interaction association

•Interaction closure

Service Desk is the starting point for all help desk contacts. From the time a record is opened, to the time the issue is resolved, and the ticket is closed, Service Desk is the repository for all interaction information.

94

SM7 IE

95

SM7 IE

Receiving and Logging an Interaction

Each contact with a helpdesk, such as a telephone call or an e-mail, is termed an “Interaction.” A person who contacts the helpdesk is termed a “customer.” When an interaction comes into a helpdesk, the operator opens an interaction in Service Desk. If the issue pertains to an existing interaction, the operator can search for and open the existing record.

Register New Interaction Form

To open a new interaction, click Register New Interactions on the Service Desk menu. The New Interaction form (SD.open.interaction) opens for data entry. This form allows the help desk operator to record information about the interaction including:

• Contact and configuration item information – Indicates who is reporting the problem and to what CI the interaction is related.

• Billing and Service Level Agreement (SLA) information – Indicates who should be billed and if they are entitled to service from the helpdesk.

• A description of the issue – Describes the reason for the interaction.

• Category information – (Described on the next page.)

• Assignment group – Identifies the group assigned to review the interaction.

• Urgency – Indicates the impact and urgency of the issue using a 1 – 4 scale, with 1 being Critical and 4 being Low. The assignment group and urgency can be manually entered or automatically assigned by Service Manager based on the interaction categorization.

96

SM7 IE

Each interaction is categorized into four levels. The four-level categorization process includes:

• Category

• Subcategory

• Product Type

• Problem Type

The four-level interaction categorization enables the helpdesk to:

• Select the appropriate Assignment Group

• Assign urgency to any incident generated from the interaction

• Mine data for consistent Problem Management (PM)

• Generate standardized reports

97

SM7 IE

System Administrators can now enable users to use predefined templates when performing Service Desk tasks. A more in-depth discussion on templates and how to create them will occur in the System-Wide Configurations module.

98

SM7 IE

After an interaction is received and logged by the helpdesk, the helpdesk operator attempts first level diagnosis of the interaction. As part of this process, the helpdesk operator can query the knowledge base for a solution to the issue.

• If the operator is able to resolve the interaction, he provides the customer with the resolution details and closes the interaction by pressing the Close button (this saves the interaction record in a Closedstate).

• If the operator is unable to resolve the interaction, he saves the interaction record by pressing Submit, and provides the customer with the interaction number. The customer will use the interaction number as a reference for future interactions regarding the issue, and it will also be used to track and reference the interaction. The interaction is saved in a state of Open-Idle.

The Knowledge Base is an interface to Knowledge Management (KM). The goal of the Knowledge Base is to provide operators easy access to solutions for rapid interaction resolution. The Knowledge Base can be accessed by clicking Search Knowledge Base from the Service Desk Menu or from the Register New Interaction form.

Closing an Interaction

After a helpdesk operator has resolved an interaction and the customer is satisfied with the resolution, the interaction is closed so it can be logged and tracked.

1. Type a description of the solution in the Resolution field on the Resolution tab.

2. Select a Resolution Code.

3. Click Close.

The status of the interaction is automatically set to Closed.

99

SM7 IE

If the helpdesk operator is not able to resolve an issue through first-level diagnosis, the operator escalates the interaction to Incident Management.

1. The operator determines whether or not the interaction is related to an existing incident with the help of Service Manager suggestions.

2. If the interaction is related to an existing incident, the operator links the interaction to the incident. The related incident can be resolved or unresolved.

• If the incident is unresolved, the operator informs the customer and the interaction remains open in an Open-Linked status.

• If the incident is resolved, the operator provides the customer with the details of the resolution and closes the interaction. The closed interaction remains linked to the resolved incident.

3. If the incident is not related to an existing incident, the operator will create a new incident. Information from the interaction is automatically populated into the incident ticket. The operator fills in any additional information.

100

SM7 IE

To escalate an interaction to an incident:

1. The helpdesk operator clicks the Create Incident button on the interaction form.

2. The Potentially Related Records form opens. The form displays all incidents that might be related to the current interaction. If the operator selects a related incident, that record opens displaying the incident associated with the interaction and the incident resolution. At this point, the operator can choose to Link the incident to the interaction, or Edit the incident. If none of the displayed incidents apply to the current interaction, the operator clicks the Open New Incident button, and the Create New Incident Record form opens.

3. If there are no related incidents, the Create a New Incident Record form opens automatically, and data from the interaction automatically populates the incident ticket’s fields. The helpdesk operator verifies the category and enters any remaining data.

101

he421s b.00

In the SD Environment record, ServiceCenter offers five Service Desk Record Relationship Models to manage the closure of interactions in relation to other applications. One of the five models is selected as the global setting for Service Desk within the ServiceCenter system.

SD Record Relationship Models affect the following four record types:

•Service Desk interactions

•Incident Management tickets

•Change Management change requests

•Request Management quotes

All Records Close Independently

Interactions and related application reports can be closed regardless of relationship(s).

Close Interactions When Related Record Closes

The interaction is automatically closed by the system when the last related record is closed.

Cannot Close Related Record Until Interactions Are Closed

Interactions must be closed before any related records can be closed. If a user attempts to close a related record that is associated with an open interaction, the system displays an error message and does not permit the closure.

Cannot Close Interactions Until Related Records Are Closed

All related records must be closed before an interaction can be closed. If a user attempts to close an interaction that has an open related record, the system displays an error message and does not permit the closure.

102

he421s b.00

The Full Service Desk model considers the notification requirements of the customer. The closure process of an interaction depends on the value specified in the interaction’s Notify By field. There are four possible values for the Notify By field:

•None – When the related record is closed, the interaction is closed by the system and the customer is not notified.

•E-mail – When the related record is closed, an e-mail message is sent to the customer, and the system automatically closes the interaction.

•Telephone – When the related record is closed, an action is added to the interaction requiring the helpdesk agent to phone the customer to ensure their satisfaction. The interaction cannot be closed until all required actions have been achieved. Once the action is marked complete, the operator can manually close the interaction.

•Other – Used to specify other methods of contacting the customer.

The above diagram shows the final steps of the flow in a situation where the Notify By field is set to E-mail. Once the system sends the e-mail, it automatically closes the interaction, without need for helpdesk operator intervention.

103

he421s b.00

The above diagram shows the final steps of the flow in a situation where the Notify By field is set to Telephone. In this situation, the interaction is closed manually by the helpdesk operator.

104

SM7 IE

It is important to note that “Interactions” are stored in the incidents table, while Incident tickets are stored in another table.

105

SM7 IE

All out-of-box Service Desk forms are identified with an “SD” prefix, for easy recognition.

SD.open.interaction – The form displayed when Register New Interactions is chosen. This form is used to capture the initial interaction information, such as contact information, categorization, affected Configuration Item, urgency, and issue description. Interactions can be either Submitted or Closed from this form.

SD.update.interaction – The form displayed when an existing interaction is displayed or updated. Operators can update the interaction record, view history, view related records, or Close the interaction from this form.

106

SM7 IE

Service Desk is a front-end module for other Service Manager applications. The example shows several incoming interactions, and displays several different paths that data may take from the initial interaction.

Interaction 1: A typical interaction that can be resolved by the helpdesk. This does not require data to move from SD into a related record. For example, a user calls needing to have his network password reset. The operator performs the action, and closes the interaction.

Interaction 2: This is a one-to-one relation between SD and a related application. For example, a user calls needing software installed on her workstation, generating a Request ticket.

Interaction 3: It is possible (but not common) to create multiple related application records based on one SD record. An example might be an interaction which generates two separate change requests. If this situation occurs, an alternate option is opening multiple or cloning SD tickets.

Interaction 4 and Interaction 5: Another typical scenario where multiple users are affected by a single issue. For example, a printer goes down, and ten users call about the same outage. The SD application gives the ability to associate an interaction with an existing related ticket; a many to one relation.

After an interaction is documented in the incidents table, it becomes the source of one or more functional processing requirements. The issue(s) recorded on the interaction can initiate a new incident ticket, change record, or part or service request.

When other applications become involved, related records are created in tables specific to those applications. 107

SM7 IE

Every time a user creates a relationship or association between an interaction record and another application record, the system stores that relationship as a record in the screlation table. The screlation record is used by the system to enable backtracking and accountability between related records in the same or separate applications.

108

SM7 IE

When a record in another application is opened from an interaction, the system automatically sends data from selected fields in the interaction to the new related record. The system moves the appropriate interaction data into the incident, change, or quote records.

The link records above define the fields that move data from Service Desk to related applications:

•Interaction to Incident – screlate.incidents.problem

•Interaction to Change – screlate.incidents.cm3r

•Interaction to Quote – screlate.incidents.ocmq

109

SM7 IE

Incident Management automates reporting and tracking an incident, or groups of incidents, associated with a business enterprise. Incident Management enables you to identify types of incidents, such as software, equipment, facilities, network, and so on, and track the resolution process of these incidents.

Incident Management is more than a message service. The appropriate personnel can escalate and reassign incidents. Incident Management can also automatically issue alerts or escalate an incident that is not resolved on a timely basis. For example, if a network printer is disabled, a technician or manager can escalate the incident to a higher priority to ensure the incident gets fixed quickly.

110

SM7 IE

The Incident Management (IM) module provides the capability to classify an incident. IM records information regarding the assignment impact, urgency of the incident, and affected configuration items. The goal of incident management is to get the user back to work as quickly as possible by ensuring that:

•Incidents are resolved quickly.

•Solutions minimize both risk and negative impact on the infrastructure.

•Information for trend analysis is available.

111

SM7 IE

112

SM7 IE

113

SM7 IE

114

SM7 IE

Incidents can be created in several ways such as:

•Escalating an interaction from the Service Desk application to an incident

•Creating an incident directly from the Incident Management application

•Generating an incident through automated processes

After an incident is created, the assignment group retrieves the incident. The incident ticket can be retrieved from an Incidents Favorite or by using Search IM Tickets. The assignment group reviews the incident and determines whether they have the expertise to resolve it.

•If the incident is within the scope of the assignment group’s area of expertise, the group “accepts” the incident, and a technician is assigned. The technician begins to diagnose the incident. If additional information is required from the customer, the technician contacts the customer directly or asks the helpdesk to assist.

•If the incident is not within the scope of the assignment group’s expertise, they contact the helpdesk. The helpdesk reassigns the incident ticket to another group.

115

SM7 IE

Assigning a Technician

After an incident is retrieved and accepted by an assignment group, a technician takes ownership of the ticket by entering the appropriate operator id in the Assignee Name field (using Fill is highly recommended). The status of the incident ticket changes from Open to Work in Progress. The change in status permits the organization to track the time between when the ticket is opened and when a technician is assigned. Incident Management uses clocks to track time intervals for incident tickets.

Obtaining User Information

If a technician needs information from the customer to resolve the issue, the technician attempts to contact the customer. If the customer is unavailable, the incident ticket is reassigned to the helpdesk. When the ticket is reassigned, the incident clocks and the incident ticket are suspended. The helpdesk monitors the suspended ticket and continues to attempt to contact the customer. After the information is received, the incident clock is restarted, and incident ticket processing continues.

116

SM7 IE

117

SM7 IE

After an incident is diagnosed, the assignment group determines whether or not a solution is available.

• If the group cannot identify a solution, the incident is reassigned to the helpdesk. The helpdesk finds another assignment group to address the issue.

• If a solution is found, the group determines if the solution is permanent or temporary. The group provides and tests the solution, and the incident is closed.

To close an Incident Ticket:

1. After an incident is resolved, the technician clicks Close.

2. The Resolution tab appears.

3. The technician confirms if the solution is permanent or temporary.

4. The technician enters a description of the solution, then selects a closure code. If the fix is temporary, a temporary fix closure code is used. If the fix is permanent, a closure code that reflects the incident’s resolution is assigned.

5. The ticket information is stored for future use.

Best Practice: Incident tickets should be continually updated by the assignment group. All activity and information obtained should be documented on the ticket on the Action/Resolution tab.

118

SM7 IE

An important aspect of the Incident Management process is validating the incident resolution with the customer. Validating incident resolutions decreases repeat calls to the helpdesk and increases overall customer satisfaction. The assignment group technician or the helpdesk operator who took the initial interaction can contact the customer to validate the resolution.

The following process describes the helpdesk operator’s role in validating a resolution.

1. The helpdesk operator monitors resolved incidents where the customer has requested a call back.

2. If no call back is required, the interaction is closed automatically and the customer is notified.

3. If a call back is required, the operator contacts the user and verifies that the resolution was satisfactory.

• If the customer is satisfied, the interaction record is closed.

• If the customer is not satisfied, the incident is reopened.

119

he421s b.00

The IM Environment Record determines the overall settings for the IM module.

To access the Incident Management Environment record:

From the System Navigator:

Menu Navigation > System Administration > Ongoing Maintenance> Environment Records> Incident Management Environment.

Some of the most frequently used settings of the IM Environment are:

•Use Paging? - Adds a new record to the problem table each time a ticket is updated.

•Use Journalled Updates? - Makes any information entered in the Actionstab a permanent part of the record that cannot be deleted.

• Most to Least Recent – Lists updates to the record chronologically beginning with the most recent.

• Least to Most Recent – Lists updates to the record chronologically beginning with the least recent.

•Use Resolved Status? - Activates the two-step closure process in IM.

We will discuss Profile records in more detial in the Systems Administration section of the class.

120

he421s b.00

The closure model for Incident Management is determined by the Use Resolved Status? setting in the IM Environment record. When Use Resolved Status? is checked, the Two-Step Closure Model is in use, and when it is unchecked, the Single-Step Closure Model is in effect.

The ability to Resolve or Close within the Two-Step model is regulated by the IM Profile record of the user in question.

121

he421s b.00

When the Single-Step Closure model is in use, the Inactivate and Mass Inactivate settings on IM Profiles are irrelevant, and the only relevant setting is the Close option.

In the Two-Step Closure Model, users with the Close ability in their IM profile will see the Resolve button when updating open incident tickets, and can use that to take the ticket to a Resolved status. Users with the Inactivateability checked in their IM profile will see the Close button when examining Resolved incident tickets, and can use that to move the ticket to a final Closed status. Users with the Mass Inactivate ability checked in their profile will have the Close Resolved Tickets option available in the List Options of a record list that contains incident tickets. Selecting that option will take all incidents from the record list that are in a Resolved state and take them to Closed.

122

SM7 IE

The probsummary table is the primary table in Incident Management and stores all data about the current state of an incident ticket. The probsummary table is designed to perform efficient queries and run reports.

123

SM7 IE

The problem table maintains detailed historical records on all actions against incident tickets. It has fewer keys, so searches on individual fields other than number and page are less efficient than in the probsummarytable.

Note: Use of this table is optional, and is set in the IM environment record.

Paging

Paging is a detailed approach to history, but requires additional storage space. Paging is set up in the Incident Management environment record.

•When the Paging option is selected, Service Manager writes a new record to the problem table each time an incident record is added, updated, or closed. This method permits historical “snapshots” of the incident ticket.

•When the Paging option is not selected, a record is written to the probsummary table only. This method permits you to view only the latest update to the incident ticket.

To view all pages of a record:

1.Click Options > Page List to view this historical pages of an existing incident ticket.

124

SM7 IE

Data storage

When you open an incident ticket, the system writes a new record containing all the data fields into the probsummary table. Each time you update the incident ticket, the system overwrites the record in the probsummary table. When you close the incident ticket, the system overwrites the record in the probsummary table. As a result, only the latest data from the incident ticket is available. To view historical data about the incident ticket, use theproblem and activity tables.

Both methods (Paging and Activity records) can be used individually or simultaneously. Use of paging is set in the IM Environment Record. Use of activity records is automatic.

125

SM7 IE

Incident Management Forms

Incident tickets can be initiated in multiple ways:

• From an interaction record

• From a quick entry form (apm.quick) within IM

Incident Management provides three tracking forms to view and modify incident data. Each tracking form has specific functionalities:

• IM.template.open - Permits data input for the initial description of the incident and additional category-specific information.

• IM.template.update - Permits technicians to assign the incident, report the status of the incident, and inform users what action was taken.

• IM.template.close - Permits the incident solution to be entered and the incident to be closed.

Maintaining these forms requires careful consideration. There are two options for forms management:

• Template Forms - New fields can be added to the out-of-box template forms to permit new category-specific information to be entered.

• Category-Specific Forms - Each active category can have its own open, update, and close forms designed specifically for that category. As there are three forms for every active category, this method requires more maintenance.

Best Practice: Using template forms is the preferred method for forms management, as maintenance is more efficient and less time-consuming.

Note: Remember that gui-based clients will look for the “.g” version of forms.

126

SM7 IE

127

SM7 IE

The Alert Level of an incident ticket (stored in the status field of the record) is used to trigger alerts and notifications, based on the time since a ticket was updated, and the category of the ticket. It is automatically updated based on timers initiated at ticket inception and at each update.

The following example illustrates an incident ticket moving through these stages:

•An incident starts in an open status, and remains there until it is updated. After the ticket is updated for the first time, it never returns to an open status.

•After the specified interval for the ticket’s category passes without an update to the incident, it escalates to a status of alert stage 1. The assignment group is notified that the ticket has reached this alert level.

•The ticket is updated and automatically moved to an updated status.

•After the specified interval passes without another update, the incident again escalates to alert stage 1 and the assignment group is notified.

•A further specified interval passes without an update, and the ticket escalates to alert stage 2 and the assignment and Stage 2 Alert group are notified.

•Another specified interval passes without an update, and the incident escalates to alert stage 3, and the assignment and Stage 3 Alert groups are notified.

Each time an incident ticket is updated, the alert and escalation process restarts, which could create an infinite process. To prevent this, the DEADLINE ALERT is scheduled for a specific interval after the open time of the ticket, which is not affected by any updates. Once this deadline interval is reached, the ticket goes into DEADLINE ALERT regardless of its current status. It remains in DEADLINE ALERT regardless of how often the ticket is updated.

Alert level intervals can be set in the category record within IM, or using SLM.

128

SM7 IE

An assignment group is a group of technicians responsible for categories of incident tickets. The assignment group receives notification when an incident ticket is opened or escalates. Each incident ticket should be assigned to a group.

The assignment group record includes the group(s) to notify when a ticket reaches alert stage 2 and alert stage 3, and the duty calendar to use.

A separate tab lists the operators in the assignment group. Note that unlike profiles, which are added to an operator record, assignment group records contain the list of operators that belong to that particular group.

To access assignment group records:

•In the System Navigator, from Menu Navigation, expand Services, then expand Incident Management. Double-click Security Files, and then click Search/Add in the Assignment Groups section.

•On the Incident Management menu, click Security Files, and then click Search/Add in the Assignment Groups section.

•From the Main Menu, Utilities > Administration > Security > User Administration > Incident > Incident Management Assignment Groups.

129

SM7 IE

Categorization permits the helpdesk operator to clearly define an incident ticket. This permits:

•Tickets to be assigned to an assignment group with applicable skills

•Specific reports to be generated on the types of issues recorded by the helpdesk

IM provides the four levels of categorization above for an incident ticket. (These same four levels are also used within Service Desk and Problem Management)

Each level has its own table that stores dependency information. This permits users to follow a path with recursive link records, and enables them to specify how a ticket is categorized.

130

SM7 IE

The category record determines which forms are displayed within IM and is used to determine the interval between the alert stages. Interactions, incident tickets, and problem management records have assigned categories. Many categories are predefined.

Access category records using one of the following methods:

•In the System Navigator, from Menu Navigation, expand Services, and expand Incident Management. Double-click Security Files and click Search/Add in the Categories section.

OR

•On the Incident Management menu, click Security Files and click Search/Add in the Categories section.

Best Practice: This is not a preferred method for setting an initial assignment group. The preferred place to set the initial assignment group is in a Product Type record.

131

SM7 IE

132

SM7 IE

The browse form has all fields set to read-only, to allow users with limited access to view, but not change, incident tickets.

Category specific forms require more maintenance than template forms, as each category that uses category-specific forms requires maintenance of three different forms (the open, update, and close forms for that specific category), so the preferred method of forms maintenance is to use the template forms (referenced above).

If category-specific forms are used, the template forms can be copied and used as a starting point for the category-specific forms.

Note: The base names of the forms are referenced in the category record, even though GUI client users will see the .g versions.

133

SM7 IE

The intervals are expressed as:

•Constant over time: All tickets for this category use the same interval to move through the screen changes without any additional conditions.

•Dynamic Intervals: Intervals change based on conditions of the ticket, such as urgency, location, contact person, or combination of conditions that require different intervals. The alert.time field is the one that must be set by the calculation in the Expression for Stages 1 through 3, and the deadline.alert field is the one to be set for the DEADLINE ALERT calculation.

Important: An expression written in the Expression field takes precedence over an interval in the Interval field.

Time intervals are expressed in a dd hh:mm:ss format, with a space between the days and hours. Days are optional, but hours and minutes are mandatory.

Intervals for Stage 1 through Stage 3 are calculated incrementally. For example, the interval specified in the Stage 2 interval is the amount of time between reaching Stage 1 and going to Stage 2 (in the above example, 4 fours). So, in the above example, if a ticket goes without an update for 4 fours, it moves to Stage 1 alert status. If it goes another four hours without update (for a total of 8 hours), it will move to Stage 2, and if it goes a further 4 hours (for a total of 12 hours without update), it will move to Stage 3 alert status. Any update will reset the alert timer, and take the ticket back to an updated status.

The interval for DEADLINE ALERT does not get reset upon update, and the deadline timer continues to count from the time the ticket is opened. In the above example, a ticket could be updated every 12 hours and reset to updated status, but once the ticket is open for two days, it moves to DEADLINE ALERT and will remain at that status until closed.

134

SM7 IE

The Service Desk Approval tab sets approval requirements for the Service Desk interaction by calling an approval definition record attached to the category selected. An approval will now be added the process flow for the corresponding Service Desk interaction. OOB, the tab is mainly used with the Service Catalog and Employee Self-Service (ESS).

For example, an ESS user has a regular Service Desk profile that enables them to log on to Service Desk only through a self service Web client URL. A user with an ESSM-Approval profile such as a manager can approve service catalog requests specified by a dollar amount or company. Typically, this capability is given to high-level managers with a need to approve special requests but who have no need to use HP Service Manager on a regular basis.

135

SM7 IE

Subcategory Information is the second level of definition. It permits you to divide a category into multiple related subcategories.

For example, the client system category is divided into two subcategories:

• software

• Hardware

Subcategory records are stored in the subcategory table. Subcategories can be set as active (appearing in Fill lists) or inactive.

To add or view records in this table:

• From the Incident Management menu, click Tools > Subcategory.

OR

• From the System Navigator, navigate to Services > Incident Management > Tools > Subcategory.

136

SM7 IE

Product Type Information is the third level of definition. It permits you to divide the subcategory into multiple related product types. Product Typerecords are stored in the producttype table. Within the product type record, you can enter the severity for the product type and set the initial assignment group.

For example, the software subcategory of the client system category is divided into the following product types:

•desktop

•email client

•non standard apps

•none

•standard applications

•utilities

Best Practice: This is the preferred method for setting the assignment group.

137

SM7 IE

Problem Type Information is the fourth level of definition. It permits you to divide the product types into multiple problem types.

Example: the utilities product type is divided into the following problemtypes:

• backup software

• virus software

• remote access

• other

• none

138

139

SM7 IE

140

SM7 IE

Service Manager’s Change Management application provides a process for requesting, managing, approving, and controlling changes to your organization’s network environment, facilities, telecommunications, or other resources compliant with ITIL workflows and best practices. ServiceCenter’s Change Management system of Categories, Phases and Approvals allows you to customize your change processes but maintain the requirements of ITIL.

141

142

143

Change Management Process Flow

• The requester submits a change. The user selects a category and enters the required data.

• The change request is sent to the approval group(s). Management determines a list of users authorized to approve a change request. Change Management maintains a list of approvals for each change category. Approvals are based on an analysis of the request.

• A change request can be reviewed at any time.

Best Practice: An alert for each change category should be set to notify the appropriate people of the new change. Notifications via email, internal mail, or paging can be sent to a specific group at any phase in a request’s life cycle (open, update, close, approved, or disapproved).

When a Request is Denied:

• Notifications are sent.

When a Request is Deferred:

• A denied change request can be deferred for future review.

• Status is changed to deferred when the request is updated.

• Notifications are sent and alerts are scheduled.

When a Request is Approved:

• The request is updated to reflect the current status as work is accomplished.

• The request is closed after work is completed.

• Notifications are sent.

144

Category Description

Application Manages production application changes.

HW server Manages HW server changes.

Hardware Manages hardware changes.

MAC Manages general moves, adds and changes.

RFC Request for change.

RFC – Advanced Manages the operational risks and costs of system-wide changes,

such as moving personnel, assets, and systems of a single business

unit or multiple business units.

Security Manages changes in security profiles and user accounts.

145

A phase determines how forms are viewed by the users, approval requirements, and

intervals at which alerts are sent. A phase can be approved, denied, or deferred.

When action is taken on a phase, the change is moved to the next phase. When a

change has no more phases, the change is closed.

Note: You can use predefined phases or create new phases to reflect your

organization’s business requirements.

146

• Tasks are work processes that help complete a change request.

• Tasks are classified by categories.

• Tasks are broken-down into phases.

• Work cannot proceed to the next phase until all associated tasks are complete.

Example: Basic tasks to replace a hard drive include: ordering the new drive; backing

up the old drive; installing the new drive. All tasks belong to a “parent” change. The

start and end dates of tasks should fall within the start and end dates of the change.

147

• When a change request is made, the change may need to be submitted for

approval.

• The associated category and phase determines the approvals required for the

change.

• Based upon security settings in the phase definition, Change Management

requires completed approvals before the change request can move to the next

phase.

Note: An approval is agreement by a user (approver), or a group of users (approval

group), to accept the risk, cost, and responsibility to implement a change or complete

a task.

148

• The responsibility of an approval group member is to review, accept, or deny

the change.

• Membership in the approval group is specified by the member’s operator and

profile record. Members specified in the array receive messages when change

request phases containing their group are opened.

• To add a name to an array, update the operator record to use a change profile

that specifies the group as an approval group.

149

Requests for change advance in phases according to a predefined schedule. Alerts

monitor the progress of these phases. Change Management treats an alert as an

event and sends predefined notifications.

• You can define standard or customized alerts for any phase.

• You can control the naming convention used for an alert.

• You can control who is notified for each alert.

Example: A late notice alert notifies a management group that a request for change

approval is overdue. It updates the alert status field in the change record to include

the late notice.

150

151

• Each data table (cm3r and cm3t) contains a total of five structures.

• It is important for any new fields added to the cm3r or cm3t system definition

records be added to the appropriate structure.

152

A change category can have multiple sequential phases. In the chart above, the

MAC change category has three change phases, Analysis, Approval, and Testing.

153

154

To create a new category from an existing record:

1. Click Menu Navigation > Change Management > Changes > Change Categories

> Search Changes.

2. Click a Change Category record to view it in the Category form.

3. Replace the name in the Category Name field with the new category name.

4. Modify fields that need to be changed for the new category and list the appropriate

phases. Click a row to select a new phase from the drop-down list. You can also type

a new phase name that you want to create for the new category. You must specify at

least one phase in the Phases array to create a category.

5. Click Add.

• If a listed phase does not have a corresponding Phase record, Change

Management prompts you to create a new phase record. Click Yes.

6. The default COMPANY MASTER Phase record appears.

7. Type the new Phase Name and modify any necessary information.

8. Click OK when the information in the phase record is complete.

9. Click Continue.

10.Click OK.

Best Practice: If possible copy an existing category and corresponding records; the steps

are minimized

155

The New Change Category and New Change Phase checklists contains the

components of the change category and phase definition that are to be implemented.

It is important to complete these checklists before beginning any modifications to

ensure all stakeholders are informed and agree on the categories and phases.

Note: See Appendix B for a New Change Category and New Phase Definition

Checklist.

Procedures for creating change and task categories and change and task phase

definitions are similar. The few exceptions are discussed in the Building Task

Categories and Phase Definitions lesson.

156

The category-specific forms provide tabs with information and access to data fields.

The form for each category can display tabs conditional to category requirements.

For example, not all category forms will require an Approvals or Tasks tab.

• COMPANY MASTER records can be modified according to an organization’s

needs with category-specific forms as its Default View.

• The category-specific tabbed form is defined as the Default View on the

category phase definition record.

• If the COMPANY MASTER records are used to create new phase definitions in

the current base system, the master forms are accessible through the Views

button only.

• The Approvals tab uses a subform to display read-only approval information.

• The Tasks tab uses a subform to present the list of tasks associated with the

change record through a virtual join.

Regardless of which method of forms maintenance you use (master forms or tabbed

forms), you need both a .g and a non-.g (base) form for each named format if both

GUI and text clients are using Change Management.

157

The primary data tables for Change Management (cm3r and cm3t) are comprised of

structures. New fields must be added to the correct structure. You can add any field

to the cm3r table that you created in a subform or any tabbed category form that do

not exist in the table. The newly created category-specific data fields should be added

to the middle structure. Use the Database Dictionary utility to add the new fields.

To access the cm3r table using the Database Dictionary utility:

• To access the Database Dictionary from the Menu Navigator, select Menu

Navigation > Tailoring > Database Dictionary or use the ServiceCenter

Command Line by typing dbdict and press the Enter key.

158

If needed or required, various Service Manager tools can be used to further automate

and control the new category’s change management process flow. The decision of

which tool and the timing of when to create the relevant records depends on the

business needs of the organization.

159

Certain change and task phases require approvals before the process can advance.

Approval and member groups must be created for each phase named in a new

category.

160

Associate any alert conditions with the phase definitions for the new category.

161

A primary configuration task in Change Management is configuring new Category

and Phase Definition records. You can either copy existing records or start from

scratch. If a phase definition record does not exist for your new category, then

Change Management will guides you in creating the new phase and gives you the

opportunity to modify phases that do exist. The system validates each phase

definition’s approval groups, alerts, formats, scripts, and task categories, and prompts

you to create any additional items.

Best Practice: This can be accomplished more quickly if you copy an existing

category and corresponding records. Retrieve a list of all current category records

and select the category to copy. Change the name of the category, click Add. Modify

fields for the new category as required.

Note: When creating a change phase definition that does not already exist, the

system presents the COMPANY MASTER Phase Definition record (for changes) to

be used as a default and modified as necessary.

SM7 IE

162

SM7 IE

163

SM7 IE

The Configuration Management module enables you to track configuration items within your infrastructure. Configuration Management helps you manage items, contracts, add configuration items to contracts, and manage contract and payment details. Because applications within Service Manager access configuration data for current information, this module enables calls, incidents, change requests, and other issues received by the helpdesk to be resolved efficiently.

164

SM7 IE

Configuration Management helps you keep track of the hardware and software on your network, tracking them by creating configuration item records. Other Service Manager applications can access the configuration item information from Configuration Management.

Example: if you create an incident ticket, Incident Management can access the hardware component information from the configuration database and insert it into the new ticket.

Enterprise discovery tools can be used to add configuration records automatically and update them using agents that route device configuration information to the Configuration Management application.

The Configuration Management application shares a set of tables that describe the common attributes of all devices, the specialized attributes of different devices, and the relationships among them.

165

SM7 IE

Service Manager’s Configuration Management out-of-the-box workflow tracks the configuration items that comprise an organization’s infrastructure.

The Configuration Management process is divided into three separate process flows:

•Data Collection

•Data Review and Validation

•Maintenance

166

SM7 IE

The Configuration Management process begins with a inventory of all IT components. The goal of the physical inventory is to determine “What do I have?” Knowing what CIs an organization owns provides a benchmark and helps the organization plan for changes in infrastructure. The physical inventory can be performed manually or automatically.

Configuration Management links to auto-discovery tools, and integrates with existing network and system management tools. The auto-discovery tools automatically update CI records by feeding device configuration information to Configuration Management. After the data is collected, it is entered into the repository. CIs can be entered manually, imported from existing systems, or populated automatically.

When collecting data consider:

What level of data is required?

For example, a PC can be considered a single configuration item, or it can be broken down into a CPU, monitor, keyboard, and mouse.

What type of information is required for each asset?

Different types of information can be collected for each item, such as manufacturer, type, part number, location, and owner. It is important to determine which pieces of information are relevant to your organization.

What size database is required?

Smaller databases require less maintenance but store less information. Larger databases store more information but require more maintenance.

167

SM7 IE

Data Review and Validation

After the configuration data is collected, data standards are reviewed. Data standards can involve requirements regarding the type and amount of information collected for each configuration item. In some cases, data may not match standards. If the data does not match the standards, you can investigate and resolve the exceptions or change the standards.

Resolving exceptions to the data standards includes:

•Identifying additional components.

•Updating legacy assets that were not automatically populated.

•Describing CI relationships, CI owners, or CI locations.

168

SM7 IE

Maintenance ensures that an organization’s infrastructure is stable. Example: Running maintenance reports could indicate that a particular type of copier requires more maintenance than another.

Other maintenance tasks include:

•Reconciling and assigning licenses to CIs

•Assigning leases and service contracts to CIs

•Reviewing assignment groups

•Reviewing CI relationships and dependencies

This information helps organization plan for the future upgrades and be proactive in their purchasing and decision making.

169

SM7 IE

Configuration Item (CI) - the ITIL term for a component of an infrastructure or item associated with an infrastructure that is (or will be) under the control of Configuration Management. In Service Manager, CI records are stored in the device table and are therefore tracked through a device record in the Configuration Management application.

CIs can vary in complexity, size, and type. For example, objects or processes within the Service Desk infrastructure are recorded in the database as Configuration Items (CIs). A CI can include an entire system with all hardware, software, and documentation, a single software application, a software license, or a hardware device, or office furnishings.

To work with CIs in Configuration Management, navigate to Services > Configuration Management > Resources > Manage Hardware. This shows the Manage CI form, with information common to all CI types. In order to completely fill out all information for a CI, the user must specify the Type of the CI, then press the New button on the toolbar. This will show the fields and tabs specific to the particular CI type, and allow the user to complete data entry.

The Configuration Item field contains an identifier that is unique to the CI across the entire enterprise.

170

SM7 IE

Examples of CI types include:

• Telecommunications

• Business Service

• Computer

• Furnishing

171

SM7 IE

A business enterprise may have a large number of CIs to acquire, install, repair, or manage in a variety of activities. Because many of these CIs are the same model or have another defining characteristic, creating CI groups is a simple way to classify CIs, simplify tracking, and managing changes.

Making global changes to CI groups is easier than updating them one at a time. Change Management can automatically open tasks for all CIs in a group. Service Level Management enables you to attach a CI group to a Service Level Agreement (SLA) instead of attaching each CI individually to an SLA. Thereafter, Service Level Management can generate response and outage information at a CI group level.

CI groups are stored as Configuration Items of the “CI Group” type. To view CI Groups, navigate to Services > Configuration Management > Resources > Manage Hardware, and search for CIs of the “CI Group” type. Each particular kind of CI group is created and edited differently.

172

• A business service in Service Manager show how different CI’s are related to each other either through logical relationships, physical relationships, or both.

For example: an Email Service will contain the email servers, the software to make the email work, and the database where the email is stored. Along with this is a service-based SLA and people to manage the service.

173

Outage spreading is a feature that lets you set parameter around a business service for down condition, so that the user or manager is notified. This is essentially setting alerts against a business service. You can also set alerts against a CI group.

If users can access more than one email server when another goes down, then you would only track the outage for the individual item – the server. If you had a situation where some people are on different servers, then when the server goes down, some people are automatically down.

174

If you have grouped CIs, and you issue a service pack, you can make the change relevant to the group. E.g. when you’re issuing a patch to a server and a

There are two types of groups

1) Baseline: pre-defiend as a particular configuration. Must be changed using change control. Enables statement management

2) Ad hoc: lets you create groups based on lists and queries. E.g. all computers_server. No state management

175

SM7 IE

Baseline CI Groups are created through the Baseline Group wizard (Services > Configuration Management > Resources > Baseline Group Wizard).

When creating a Baseline group, specify the Group Name and the CI Typeof all the CIs that will be part of the baseline group. Next, optionally enter Filter Criteria which determine which subset of the CIs of the given type will be members of the initial version of the Baseline group.

Subsequent versions of the Baseline group can be added by selecting Add Version when viewing the Baseline group record. Each version can have its own set of Filter Criteria, and its own State (which can be changed by selecting Change State from the Options menu).

The members of a Baseline group can be displayed by selecting Show Members from the toolbar. All the CIs for a particular version of the Baseline group can be modified in bulk by selecting the version line and pressing Bulk Update.

Baseline groups are useful to track which CIs have undergone a planned upgrade, or other attribute change, as reflected by the Filter Criteria for each version. Use of the Show Member Counts option from the Optionsmenu can let techs know how many CIs match up with each Baseline group version, to aid in tracking.

Note: Filter Criteria cannot be edited once a version is created. To change Filter Criteria, a new version must be added. The Query column on the Baseline Group record is only visible to users with the ICMAdmin capability word.

176

SM7 IE

Both types of Ad Hoc CI Group are created though the Manage Configuration Item Groups wizard. To run the wizard:

• Perform a search for CIs.

• Select List Options > Create/Edit AdHoc CI Groups.

In the wizard, choose whether to Create new group, or Edit existing group.

When creating a group, choose whether to create a Query group (which will save the query that was used to display the record list) or a List group (which will add the CIs currently in the record list to the new List group).

When editing existing groups from this wizard, adding and removing CIs from the list can be done to List Groups, while updating the existing query modifies Query Groups. Edits done by this wizard will replace the existing list of CIs in List Groups, or will replace the existing query of a Query Group.

CIs may be manually added and removed from existing List groups by displaying the CI Group record and adding and removing items from the Group Members array.

CIs may also be added to existing CI List groups by displaying the CI, and selecting Edit AdHoc CI Groups from the Options menu. The resulting wizard will ask whether the displayed CI should be added to or removed from an existing CI List group, and prompt the user to choose the group.

Users may find out which group(s) a CI belongs to by selecting Show Associated Groups from the Options menu when displaying the CI.

177

SM7 IE

178

SM7 IE

devtype table

Each CI placed into Configuration Management has a specific type (client system, telecom, office electronics, etc.). The devtype table defines each CI type.

• There is one devtype record for each defined CI type.

• Each record stores specific information, including the attribute table name for the CI type, view form name for the CI type, and subtypes available (if any).

• A record is created in the devtype table when a new CI type is created.

device Table

The device table is a central repository for CI information.

• One record for each CI.

• Records provide information to populate forms used by Configuration Management, as well as other Service Manager applications such as Incident Management.

• The type of the CI determines the form used to display the CI information.

• Only information common to all CIs resides in the device table.

• Records are uniquely identified by the logical.name field.

Attribute Tables

Contain data specific to a particular CI of a specific type. This is in addition to the general data stored in the device table.

• Up to one attribute table for every different CI type (not required).

• Standard naming convention (the table name matches the CI type name).

• The logical.name field is the unique identifier, and is used to relate information in the device table to information in the attribute table.

179

SM7 IE

The forms used by Configuration Management are:

•device form

•view form(s)

Device Form

• Standard form naming conventions apply (device is the base form and device.g is the gui form).

• It is used to query fields common to all device types.

• Since the fields on this form are common to all device records, there is only one device form.

• This is the form displayed until and unless a specific device type is specified.

View Form(s)

• A table does not literally exist for the View form. A virtual table defined by a joindefs record combines the device and attribute fields. Field names on the form must match the names in either the device table or the attribute table.

• Permit searching, viewing, adding, updating, and deleting data in both the device and attribute tables simultaneously.

• The view form for a CI type is specified by the record in the devtypetable.

Best Practice: When creating a new view form for a CI type, start by copying the device.template.g form, and adding the type-specific fields to the copy. This retains functionalities like the Relationships tab.

180

SM7 IE

•A record in the joindefs table (usually named join<type>) defines the relationship between the device table and an attribute table. The example above shows a record that relates the device table to the server table.

•A record in the erddef table defines the entity relationship between any two tables and their corresponding fields. For Configuration Management, this is a one-to-one relationship that connects the logical.name in the device table to the logical.name in an attribute table.

A joined query is a query executed against two different Service Managertables. It returns data from both the tables.

Configuration Management uses joined queries to enable you to search a specific CI type (rather than the inefficient method of searching all CI records) by using the search form for that specific CI type. To execute this type of search, select Search Specific Type from the Options menu of the Manage CIs form. A Service Manager wizard walks you through selecting the CI type and takes you to the view form for that specific CI type.

Example: If you want to find all computers of a specific brand, select theComputer device type. The view form appears for you to enter the searchcriterion. The search is executed for all Computer devices instead of allsystem devices.

181

SM7 IE

To be available to users, CI types must have the following five elements:

• devtype record

• View form

• Attribute table (optional)

• joindefs record (optional depending on use of Attribute table)

• erddef record (optional depending on use of Attribute table)

Service Manager provides a wizard which walks you through the steps of creating these elements of a CI type, and performs many of the operations for you. The Add Device Type wizard is most effective when run after creating the view form that is to be used to display CIs of the new type.

Service Manager provides a template form (device.template.g) which can be copied and altered to create the new view form for the new type. Any type-specific fields should be placed onto the new view form, as this form will be examined by the wizard.

Next, the Add Device Type wizard will ask questions about the new CI Type. The wizard will examine the form for the CI Type, and ask if you wish to create an attribute table if there are any fields in the form that do not exist in the device table. It will ask for the name of the attribute table, which will typically be a new table. It will ask for the name of a joindefs record (leaving this blank will create one with a default name), and ask if the CI Type is to be made available.

The wizard then creates the necessary attribute table (with the corresponding field structure), and creates joindefs and erddef records to enable the proper joining of the device and attribute tables, and creates the devtype record that ties the CI Type to the proper view form and attribute table.

182

SM7 IE

183

184