remedy training guide level2 3

V:\corpservices\service-office\Shared Services Projects\Change Release Project\Training\Participant Training Guide_L2&3 v1.1.docx 1

IT Service Management Processes & Remedy

Level 2 & 3 Support Comprehensive User Guide

Version 1.1


Table of Contents

Table of Contents ................................................................................................................................... 2

IT Service Management Processes & Remedy ............................................................................................. 5

Overview ................................................................................................................................................ 5

IT Service Management at Monash ............................................................................................................... 7

Overview ................................................................................................................................................ 7

IT Service Management Introduction .................................................................................................... 8

IT Service Management Functions and Processes ................................................................................. 9

IT Service Management Terminology ................................................................................................. 12

IT Service Management Roles & Responsibilities .............................................................................. 14

Introducing Remedy ..................................................................................................................................... 16

Overview .............................................................................................................................................. 16

Logging onto Remedy .......................................................................................................................... 17

Logging Off Remedy ........................................................................................................................... 18

Remedy Console Access ...................................................................................................................... 19

Navigating Remedy ............................................................................................................................. 20

Overview Console ................................................................................................................................ 21

Incident Management ................................................................................................................................... 22

Overview .............................................................................................................................................. 22

Introduction to Incident Management .................................................................................................. 23

Incident Management Process ............................................................................................................. 24

Accessing & Navigating the Incident Management Console .............................................................. 25

Accessing and Navigating the Incident Management Screen .............................................................. 29

Creating a new Incident Record ........................................................................................................... 38

Creating a new Incident Record – Work Detail ................................................................................... 43

Assigning an Incident Request............................................................................................................. 45

Re-assigning an Incident Request ........................................................................................................ 46

Progressing an Incident ........................................................................................................................ 47

Updating/Modifying an Incident .......................................................................................................... 50

Resolving and Closing an Incident ...................................................................................................... 51

Quick Close Templates ........................................................................................................................ 54

Searching for an existing Incident ....................................................................................................... 55

Searching for an existing Incident – Defined Searches ....................................................................... 56

Searching for an existing Incident – All Records ................................................................................ 57

Continued on next page


Table of Contents, Continued

Service Request Management ...................................................................................................................... 58

Overview .............................................................................................................................................. 58

Introduction to Service Request Management ..................................................................................... 59

Service Request Management Process Flow ....................................................................................... 60

Accessing & Navigating Service Desk Online .................................................................................... 61

Fulfilling a Service Request ................................................................................................................. 63

Searching for a Service Request .......................................................................................................... 64

Problem Management .................................................................................................................................. 65

Overview .............................................................................................................................................. 65

Problem Management Introduction ..................................................................................................... 66

Problem Management Process Flow .................................................................................................... 67

Accessing & Navigating the Problem Management Console .............................................................. 68

Accessing and Navigating the Problem Management Screen ............................................................. 72

Raising a Problem Investigation Request ............................................................................................ 80

Assigning/Reassigning a Problem Investigation ................................................................................. 81

Creating Tasks ..................................................................................................................................... 82

Searching for a Problem Investigation ................................................................................................. 83

Service Level Management .......................................................................................................................... 84

Overview .............................................................................................................................................. 84

Service Level Management .................................................................................................................. 85

Managing Service Targets ................................................................................................................... 88

Production Change & Release Management ............................................................................................... 89

Overview .............................................................................................................................................. 89

Production Change & Release Management Introduction ................................................................... 90

Production Change Management Process Flow .................................................................................. 93

Category and Approval Matrix ............................................................................................................ 94

Categories, Authorities & Lead Times ................................................................................................ 95

Accessing & Navigating the Change Management Console ............................................................... 96

Accessing and Navigating the Change Management Screen ............................................................... 99

Raising a request for Change ............................................................................................................. 108

Raising a request for Change – Work Detail ..................................................................................... 110

Raising a Request for Change - Tasks ............................................................................................... 112

Raising a request for Change – Relationship Detail .......................................................................... 114

Raising a request for Change-Relating Unavailability ...................................................................... 115

Progressing a request for Change ...................................................................................................... 116

Searching for an existing request for Change .................................................................................... 118



Table of Contents, Continued

Searching for a request for Change – Defined Searches .................................................................... 119

Updating/Modifying a Change Request............................................................................................. 120

Asset and Configuration Item ................................................................................................................... 121

Overview ............................................................................................................................................ 121

Asset and Configuration Item Introduction ....................................................................................... 122

Procedure Workflows ........................................................................................................................ 126

Asset Record Overview ..................................................................................................................... 127

Updating Asset/Attributes/Status ....................................................................................................... 131

Relating a Person to a CI ................................................................................................................... 133

Updating Asset Location Details ....................................................................................................... 135

Process Overviews for Asset Management ........................................................................................ 136

Advanced Functions .................................................................................................................................. 137

Overview ............................................................................................................................................ 137

Advanced Incident Functions ............................................................................................................ 138

Advanced Asset Management Functions ........................................................................................... 141

Advanced Service Level Management Functions .............................................................................. 146

Dashboards & Reporting .................................................................................................................... 149

Getting Help with Remedy ........................................................................................................................ 152


IT Service Management Processes & Remedy

Overview

Introduction Welcome to IT Service Management Processes and Remedy – Tier 2 & 3 Support. This course has been developed to provide you with the necessary skills and knowledge to effectively use the IT Service Management (ITSM) system Remedy, in support of ITSM processes at Monash University. The course consists of several topics, all of which comprise of background information, process flows, ITSM screen overviews and walkthroughs. Questions may be asked at any time.

Audience This course has been designed for anyone who works within ITSM operations.

Important: You will only be given access to Remedy once you have completed this course.

Course Schedule This course has been scheduled as follows:

9.00am‐9.15am Introduction and Housekeeping

9.15am – 9.30am Course Expectations

9.30am‐10.00am IT Service Management at Monash

10.00am‐10.30am Introducing Remedy

10.30am‐10.45am Break

10.45am‐12.00pm Incident Management

Service Request Management

Problem Management

12.00pm‐12.30pm Lunch

12.30pm‐4.00pm Service Level Management

Production Change & Release Management

Asset & Configuration Item Management

Advanced Functions

Getting Help with Remedy

4.00pm‐5.00pm Review and practice time

Objectives At the end of this course participants will have achieved the following:

Understand ITSM Terms & Processes used at Monash

Understand your role within the ITSM processes and how Remedy supports these

Record classification and the differences between Incident Management, Service Request and Problem Management

Access and navigate Remedy

Create, Update & Search for Incident, Service Request, Problem and Change records

Understand and navigate the Service Centre Online

Understand additional ITSM processes at Monash such as: o Release Management o Asset & Configuration Management

View & interpret KPI dashboards and standard reporting

Utilise appropriate channels for Help



Overview, Continued

Contents This part contains the following topics.

Topic See Page

IT Service Management at Monash 7

Introducing Remedy 16

Incident Management 22

Service Request Management 58

Problem Management 65

Service Level Management 83

Production Change & Release Management 88

Asset & Configuration Item Management 120

Advanced Functions 136

Getting Help with Remedy 151


IT Service Management at Monash

Overview

Introduction This section of the training guide aims to provide the participant an overall view of the different

terms, processes and tools that are being implemented at Monash University. It will assist in consolidating such training and information obtained through IT Service Enhancement and ITIL Simulations.


Topic See Page

IT Service Management Introduction 8

IT Service Management Functions and Processes 9

IT Service Management Terminology 12

IT Service Management Roles and Responsibilities 14


IT Service Management Introduction

Overview ITSM (IT Service Management) is the management of quality Information and Communication

Technology (ICT) services that meet the needs of the business through a combination of organisational capabilities namely people, processes and technology. The IT Infrastructure Library (ITIL) is the framework that supports IT Service Management and assists in defining terminology and processes.

Important for Monash

Moving to implement IT Service Management processes with the supporting IT Service Management system Remedy, is an important step for Monash University for various reasons, including:

ITSM processes provide quality service to staff, students, academics and researchers;

Provides common University wide ICT support processes and system;

Fully supports the ability to pass calls between support groups and visibility of support requests by providing one IT Service Management system;

Access to standard reports;

ITSM supports the ICT Shared Services projects;

Aligns IT Services with the University objectives.

What does it mean for Monash

Introduction and training of new processes, terminology and supporting ITSM system, which combined will work to improve operational efficiency.

New central ITSM System to replace multiple call logging systems. BMC Remedy 7.6, otherwise known as Remedy, which is a leading global IT Service Management application will take effect on Monday October 18th 2010.

What does it mean for you

There is a new way of dealing with and classifying our records which will be supported by the ITSM system Remedy.

New processes will be in place creating greater ownership and transparency of jobs. IT Service Enhancement training highlighting these processes and how they fit into Monash University has been provided to all impacted users.

Effective Monday October 18th 2010 you will use Remedy to log, track, update and close any records. All new calls will be keyed into Remedy whilst HEAT remains as read only. Existing jobs will still be able to be completed within HEAT for a period of two weeks.


IT Service Management Functions and Processes

Background IT Service Enhancement training delivers key objectives inclusive of:

Extending our knowledge of ITIL terminology, structure and concepts;

Explore core principles of ITIL practices for IT Service Management; and

Placing 2nd Level support into context within the ITIL framework.

Key Messages The following slides detail the key messages and learning’s provided by IT Service Enhancement:

Functions A “Function” is defined as a unit of organisation specialised to perform certain types of work

and are responsible for specific outcomes:



IT Service Management Functions and Processes, Continued

Processes IT Service Management and Remedy will support the following processes:

Incident Management;

Service Request Management;

Problem Management;

Service Level Management;

Production Change & Release Management; and

Asset & Configuration Management.



IT Service Management Functions and Processes, Continued

Roles Various Roles may sit within Functions:

Role Description

First Level Support (Tier 1 Support)

The Service Desk is regarded as the first line of support for customers. As much information as possible is provided to this group to ensure that fewer incidents are assigned to second level support.

Second Level Support (Tier 2 Support)

Second level support groups are often made up of staff with greater technical skills that first level and have additional time to devote to incident diagnosis and resolution

Third Level Support (Third Level Support)

Third level support is provided by internal or external specialist technical groups. These groups may include; Server support, Application Management and Hardware Maintenance Engineers.



IT Service Management Terminology

Overview With the introduction of new processes comes the introduction of new terminology, some of

which you will be familiar with already. Such terminology is recognised globally and falls under the ITIL and IT Service Management framework. At Monash University we are currently focussing on Service Transition and Service Operations.

Service Management Lifecycle

The following diagram details the Service Management Lifecycle:

Term Definition

ITIL IT Infrastructure Library (ITIL) is the best practice framework used in the provision of information technology services.

ITSM IT Service Management (ITSM) is a set of capabilities for managing ICT services. It is centred on aligning IT services with University objectives to provide continuous quality service to students, academics and researchers.

Service Strategy Strategic step within the lifecycle focusing on how to design, develop and implement services.

Service Design Focuses on identifying improvements necessary to maintain value to customers over the lifecycle of services.

Service Transition Focuses on the development and improvement of capabilities for transitioning new and changed services into operations.

Service Operation Focuses on achieving effectiveness and efficiency in the delivery and support of services.

Continual Service Improvement

Provides guidance on the measurement of service performance through the service lifecycle suggesting improvements to ensure that a service delivers the maximum benefit.



IT Service Management Terminology, Continued

Definitions The following terms form part of the new processes within Monash IT Service Management:

Term Definition

Incident Management Incident Management is the process for dealing with all incidents; this can include failures, questions or queries reported by the users usually via phone to the Service Desk.


Service Request Management (SRM) is the workflow and processes that manage a service request through it’s lifecycle from submission through delivery and follow up.

Problem Management The cause of one or more incidents. The cause is not usually known at the time a problem record is created.

Production Change Management

A Change is defined as any addition, modification or removal of any component of the IT infrastructure that may potentially have an effect on the service availability or functionality.

Release Management A release is a major change that is going to significantly impact the functionality of a service, affecting the way consumers interact with that service.

Asset & Configuration Management

A Configuration Item is any component that needs to be managed in order to deliver an IT service.


IT Service Management Roles & Responsibilities

Service Desk The following tables outline the key roles and responsibilities that will be encountered on a

regular basis whilst working on the Service Desk (Level 1 Support): Incident Management

Role Responsibility

User (Customer) Requests support when required and provides all information in support of that request. These requests can be submitted via form (online), email, telephone or walk up.

Service Desk Analyst (Tier 1)

Provides front line interface between the customer and ICT for services supported by ICT, by ensuring that all incidents are recorded, prioritised, resolved, documented and communicated in an efficient and controlled manner and within agreed Service Levels.

Specialist – Subject Matter Expert (Tier 2&3 Support)

Updates and resolves incident requests with relevant information and status changes through the ITSM system. Where required, escalate the incident through the Change Management process.

Group Incident Coordinator (Team Lead/Supervisor/ Queue Manager)

Manages the group queue by distributing requests to Analysts, Specialists and Change Coordinators within the agreed targets as set out by the Service Level Agreements. Where service outages have not been resolved within the SLA, escalate to the service owner.

Service Request Role Responsibility

User (Customer) A user requests information, access or advice on a service offered in the ICT Service Catalogue.

Service Provider Service (or Fulfilment) Providers (i.e. Service Desk Analyst) execute the Service Request by managing the request through it’s lifecycle from submission to delivery and follow up.



IT Service Management Roles & Responsibilities, Continued

Problem Management

Role Responsibility

Specialist Responsible for assigned requests and updating problem investigations with relevant information and status changes. Suggests workarounds and establishes the root causes of identified problems. Propose and implement structural solutions for problems. Change Management is not required.

Problem Coordinator Reviews, justifies and validates the results of individual Problem Investigation and action to be taken with respect to Known Errors. Ensures that the problems for which he/she is responsible progress through the Problem Management process in a timely and prioritized fashion whilst ensuring that information entered is accurate and complete. Periodically reviews his/her problem investigations for which a practical structural solution could not be found. Verifies structural solutions and closes the known errors and problem investigations that he/she manages.

Problem Manager Responsible for the quality and integrity of the Problem Management process.

Problem Management Process Owner

Overall authority and responsibility for the process metrics, policies and procedures. Continuous Service Improvement and reporting that pertains to the performance of the actual process.



Introducing Remedy

Overview

Introduction Effective October 18th 2010 Remedy will be the key IT Service Management system in use at

Monash University. All Service Desk Analysts and Level 2 Support staff will be required to use the system on a daily basis.

Contents This chapter contains the following topics:

Topic See Page

Logging onto Remedy 17

Logging off Remedy 18

Remedy Console Access 19

Navigating Remedy 20

Overview Console 21


Logging onto Remedy

Access Details Remedy is a web based application and can be accessed at anytime via the network at Monash

University.

Logging On Follow these steps to Log On to Remedy:

Step Action

1 Launch your Internet Browser and key in the following URL: https://ServiceDeskOnline.monash.edu/arsys Result: The Monash University Service Desk Online System displays:

2 Type in your:

Username (authcate), and

Password (authcate). Note: Your User name and password are case sensitive.

3 Click on Log In Result: Remedy opens at Overview Console.

Password Remedy usernames and passwords will copy from your Authcate account.


Logging Off Remedy

Logging Off You can log off from various screens within Remedy simply by clicking on the Logout link or

button.

From the Overview Console click on

From the IT Home Page click on located at the top right hand corner.

From the Incident Management Console click on located in the top left hand corner.

Time Out Once you have logged onto Remedy, if you take no action within the system for an hour it will

time out and you will be required to log on again.


Remedy Console Access

Remedy Consoles

The following table details the different consoles that are available within Remedy. Your permissions within Remedy will determine which consoles you have access to.

Console Details

IT Home Page The IT Home Page provides a quick link taskbar to access various consoles and applications within Remedy. These links are determined by your permissions.

Overview Console The Overview console provides users with access to view in a singular location all the different requests linked to Incident Management that may be assigned to them. This console is reflective of the user’s permissions and may include Problem, Asset and Change Management requests.

Incident Management The Incident Management console is the primary console for Service Desk analysts. It provides a single point from which users can both generate and monitor the progress of incident requests as they move through their lifecycle.

Problem Management The Problem Management console provides problem coordinators and specialists with a single point from which they can create problem investigations, known error and solution database entries. It also provides a place from which they can monitor the progress of problem investigations as it moves through its lifecycle.

Change and Release Management

The Change Management Console provides a dedicated workspace for change managers and coordinators to manage change requests.

Asset Management The Asset Management Console provides Asset coordinators and specialists with a consolidated view of all Monash IT Assets within the University. It provides a place from where they can view, modify and monitor assets.

Landing Page All users will default to the Overview Console when they access Remedy. You can access

additional consoles from the Overview Console where required, or change your default settings via the Preferences option within Remedy.


Navigating Remedy

Overview Within Remedy there are some key icons and fields that will assist you with navigation of the

system and in identifying mandatory fields when completing requests. The table below highlights these icons and fields and explains their functionality.

Note: Additional icons and fields that are specific to a process will be explained where they are used.

Icons & Fields

Icon/Field Description

Bold* Mandatory field

+ Indicates the field has predictive text functionality

Add new customer details specific to a record

Clears the field

Toggle to view additional information within the screen

Expand text area to enter and view further information

Underlined field

Indicates that the field has a hyperlink to an additional screen which allows you to view further information and details

Create a new Record/Work Detail

View an existing Record/Work Detail

Print an existing Record/Work Detail

Refresh a table within Consoles

Expand sections within the Navigation Pane

Click to view drop down lists

Click to view calendar information

Modes Whilst working within Remedy the system can be in one of the following modes; New, Search or

Modify. Remedy modes are colour coded for quick identification and highlighted at the top of each screen. Current Mode: New

Current Mode: Search

Current Mode: Modify


Overview Console

Introduction The Overview Console provides users with access to view in a singular location all the different

requests that may be assigned to them. The requests displayed within this console are reflective of the user’s permissions and may include Problem, Asset and Production Change Management requests.

Screen Overview

Console Areas Area Description

1 Console Header

Identifies the mode (New, Search or Modify) that Remedy is currently in.

2 Console Management

Filter the requests displayed within the Console table, based on Company and View By. View By allows you to filter specifically on support groups you are assigned to.

3 Overview Console Table

View all activities and requests that you are associated with and assigned to.

4 Navigation Pane

Use the Navigation Pane to access various functions and navigate to additional consoles within Remedy.

1

4

2

3


Incident Management

Overview

Introduction Incident Management is the process for dealing with all incidents throughout the incident

lifecycle from Identification and Recording to Resolution and Closure.

Contents This chapter contains the following topics:

Topic See Page

Introduction to Incident Management 23

Incident Management Process 24

Accessing & Navigating the Incident Management Console 25

Access & Navigating the Incident Management Screen 29

Creating a new Incident record 38

Creating a new Incident record – Work Detail 43

Assigning an Incident record 45

Reassigning an Incident record 46

Progressing an Incident 47

Updating/Modifying an Incident 50

Resolving & Closing an Incident 51

Quick Close Templates 54

Searching for an existing Incident 55

Searching for an existing Incident – Defined Searches 56

Searching for an existing Incident – All Records 57


Introduction to Incident Management

Definition An incident is an unplanned interruption to an IT service or a reduction in the quality of an IT

service.

Goal The primary goal of Incident Management is to restore normal service operation to Customers

as quickly as possible and minimise the adverse impact on business operations. This is supported by additional goals such as:

Restore Services as soon as possible to the Customer’s satisfaction and within agreed service level targets (SLTs);

Ensure additional technical and/or managerial support is provided whenever required to resolve an Incident within agreed SLTs;

Provide clear communication to both IT support and customers on the progress of Incident resolution;

Maintain meaningful records e.g. incident history, classification, response and resolution time etc;

Deal with incidents consistently pursuing high quality of service; and

Provide management information such as performance on incident response and resolution time metrics.

Roles & Responsibilities

Throughout the life of the incident the Service Desk acts as a single point of contact for all incoming incidents. It is the responsibility of both the Service Desk and Level 2 Support Groups to provide updates about the progress of incident resolution to the Customer. Also by ensure that they record and monitor all their actions and update the status of the issue in the incident record within Remedy. The following roles and responsibilities have been identified to support the Incident Management processes at Monash University:

Role Responsibility

User (Customer) Requests support when required and provides all information in support of that request. These requests can be submitted via form (online), email, telephone or walk up.

Service Desk Analyst (Level 1 Support)

Provides front line interface between the customer and ICT for services supported by ICT, by ensuring that all incidents are recorded, prioritised, resolved, documented and communicated in an efficient and controlled manner and within agreed Service Levels.

Specialist Subject Matter Expert (Level 2&3 Support)

Updates and resolves incident requests with relevant information and status changes through the ITSM system. Where required, escalate the incident through the Change Management process.

Incident Group Coordinator (Team Lead/Supervisor/ Queue Manager)

Manages the group queue by distributing requests to Analysts, Specialists and Change Coordinators within the agreed targets as set out by the Service Level Agreements. Where service outages have not been resolved within the SLA, escalate to the service owner.


Incident Management Process

Process Flow The process flow diagram below details the Incident Management process:


Accessing & Navigating the Incident Management Console

Overview The Incident Management console is the primary console for any Analyst involved within the

Incident Process. It provides a single point from which users can both generate and monitor the progress of incident requests as they move through the lifecycle.

Navigating to the Incident Management Console

Follow the steps below to navigate to the Incident Management Console:

Step Action 1 From the Overview Console click on the Incident Management link under the

Consoles Navigation bar. Result: The Incident Management Console displays:

Parts & Functions

The following tables explain the parts and functions of different areas within the Incident Management Console.

Console Header

Area Description

Console/KPI tabs Toggle between the Console and KPI tabs to access incidents and reporting.

Close Closes the Incident Management console and returns you to the Overview Console.

Help Access Help functionality within Remedy



Accessing & Navigating the Incident Management Console, Continued

Incident Console Header

Area Description

Company Provides options to filter the incident request records in the Incidents table using the drop down menu.

View By Provides options to filter the incident request records in the Incidents table using the drop down menu.

Refresh updates the console with the latest information.

Navigation Pane The Navigation Pane within the Incident Management Console provides you with quick access to

additional functions and search options to support the information displayed.

Navigation Pane – Incident Counts

Area Description

View Broadcast, or New Broadcast

Opens the broadcast dialog box, from where you can view and delete broadcasts. Unread broadcast messages display the message: “New Broadcast”, along with the number of new messages. The broadcast icon will also turn red.

Incident Counts Display’s the number of Open, Unassigned, Unacknowledged, and Breached incidents for the Company and View By fields.

Navigation Pane – Defined Searches

Area Description

Defined Searches

This area provides a place from which you can run a series of predefined searches. You also have the ability to define custom searches using Manage My Searches.

Manage My Searches

Defines, edits, saves, and deletes custom searches. Saved custom searches appear in the My Searches area of the Defined Searches list. See Note: If no custom searches have been defined, then the My Searches option does not appear.

Watch List Opens the Watch List. Use the Watch List to track an incident record through its lifecycle, even if it is assigned to a group that you do not belong to. Once you add an incident to the Watch List it will stay there until you remove it.




Navigation Pane ‐ Functions

Use the links under the Functions area to complete the following actions:

Area Description

New Incident Create a new Incident Request record.

Search Incident Search the database for current incident request records.

My Profile Set your profile.

Application Preferences

Set your application preferences and application options.

Reminders View and create reminders.

Reports Create and run custom reports.

Manage CIs Search for information about specific CI types and gives you access to the CI records.

Manage Inventory Access the Manage Inventory form of BMC Remedy Asset Management.

Surveys Review and respond to customer surveys.

Process Overview Opens the detailed Incident Management process.

Navigation Pane ‐ Consoles

Use the Consoles field within the Navigation Pane to access additional consoles such as Problem and Change Management. Refer to topic Remedy Console Access on page 16 for full details of Consoles. Note: Consoles that you can access are determined by your permissions and therefore may vary across users.




Incidents Table The Incidents table provides an overview of all incidents request records according to the

company selected in the Company field and the group selected in the View By field.

Area Description

Quick Actions From the drop down you can perform the following quick actions:

Assign to group member: Reassigns the incident request to another member of your group.

Assign to me: Reassigns the incident request to yourself.

Incident Closure: Moves incident requests with a status of Resolved to the Closed status.

Print Prints the selected record.

View Opens and displays the highlighted Incident request.

Create Creates a new incident request record.

Add to Watch List Adds the selected record to the Watch List.

Preferences Update your personal preferences within Remedy.

Details & Tasks

Area Description

Toggles the screen to display Tasks associated with the highlighted incident request.

Toggles the screen from Tasks to display the incident details associated with the highlighted incident request.

Click on the Create icon to create new work information notes against the associated incident.

Click on the View icon to view work information notes and the associated incident.

Incident Details Displays detailed information about the record selected in the Incidents table.


Accessing and Navigating the Incident Management Screen

Introduction In this view, the fields most commonly used for creating, resolving, and updating incident

requests are immediately visible. You can access additional, less frequently used functionality from the tabbed sections of the form or from the links in the Navigation pane. The order in which the fields appear on the form reflects the order in which you gather the information when you create the incident request record. This reduces the amount of time needed to create the record and improves the overall efficiency of the operation.

Creating a new Incident

Complete the action below to open a new Incident request form:

Step Action

1 From the Incident Management Console click on:

The create icon or,

New Incident under the Functions navigation Result: A new Incident Request displays:



Accessing and Navigating the Incident Management Screen, Continued

Parts & Functions

The following tables explain the parts and functions of different areas within the Incident Request screen.

Incident Header The Incident header identifies the current mode that Remedy is in and allows you to action

searches or new requests quickly.

Process Flow Status Bar

The Process Flow Status bar highlights the milestones within the process and steps you through the Incident Management lifecycle from Identification and Recording to Closure. Using the Process Flow Status bar to work through the Incident process will assist you in identifying all mandatory fields and information required at each stage. The current stage that the Incident is in highlights in green for easy identification.




Navigation Pane The Navigation Pane within the Incident Management screen provides you with quick access to

additional functions that support the Incident Management process. Note: Not all functions are currently in use at Monash University.

Navigation Pane – Quick Actions

Navigation Field Description

Assign to Me Assigns the incident request to the person creating the incident.

Auto Assign Using Auto Assignment rules, displays the relevant support groups in which to assign the incident to.

Broadcast Incident

Create and send a new broadcast for a specific incident to the appropriate support groups. Note: this is available to Service Desk only

Customer’s Incidents

Displays the number of incidents for the customer. Click on to view Customer’s Incidents table in a pop up window.

Incident Matching

Look for matching, or similar, incident requests, problem investigations, known errors, and solution entries to assist with resolution of the incident.

Select Operational

Mandatory field – Select the appropriate Operational Category to classify the type of issue the customer is experiencing.

Select Product Mandatory field – Select the appropriate Product Category the customer is experiencing issues with. Note: This will assist in defining the Support Group for Auto Assigning the Incident.

Navigation Pane ‐ Links


View Audit Log View the Audit trail of an existing incident.

Tasks View all Tasks associated with an incident.

Categorizations View the Categorizations that have been selected for the incident.

Search Knowledge Base

Not currently being used at Monash University

Create Knowledge




Email System Email a copy of the incident request to the customer.

Paging System Not currently being used at Monash University.




Navigation Pane – Advanced Functions


Decision Tree Not currently being used at Monash University.

Initiator Script Not currently being used at Monash University.

Impacted Areas Not currently being used at Monash University.

Assignment Script

Assignment scripts correspond to the group to which you are assigning the incident. For example, a networking group might have specific questions for you to ask the user when you assign the incident. Note: 12 assignment scripts have been put in place at Monash for October 18th 2010.

Advanced Search

Provides options in which to do advanced searching for incidents. This will open a new tab in search mode.



Overview Return to the Overview Console within Remedy

Incident Management

Return to the Incident Management Console within Remedy

Reports Links to the Report Console where you can enter parameters to generate reports.




Customer Details


Incident ID Displays the Incident ID number which is automatically generated when a customer name is entered. This ID number can be used as a reference for searching.

SRM ID Displays the Service Request Management (SRM) ID which is generated once the Incident request is saved. This ID number should be quoted to the customer as a record of the incident being logged within the system and can be used as a reference for searching.

Company Select the Faculty/Division which the customer belongs to by using the drop down icon or predictive text. This field will also autofill once a customer is selected.

Customer Search for or enter the Customer’s name using Authcate as the search

Contact Search for or enter the Contact’s name using Authcate as the search. Note: Contact names are only required when someone is logging the incident on behalf of someone else i.e. a PA

Incident Details

Field Description

Notes Text field to enter details about the Incident. This is a free text field with unlimited character functionality. Hint: You can cut and paste information directly into this field.

Template Select the required Template for the incident by placing the cursor in the field and hitting enter. A list of templates to select from your support group will display.

Summary Mandatory field. Free text field to enter a brief description about the Incident. Note: This field is limited to 128 characters.




Incident Details continued

Field Description

Service The Service field relates business service configuration items (CIs) to the incident at the time it is created and is mandatory. Only the Services related to the Customer appear in the selection list for this field i.e. Students will have different Services associated to them than staff.

CI The CI field provides a place for you to indicate to which piece of infrastructure the incident request pertains. Enter this field when you resolve the incident or at any time in the incident request lifecycle.

Target Date Enter target date for resolution or contact to customer.

Impact Identify the impact of the incident on the University by selecting the appropriate level from the drop down list.

Urgency Identify the urgency of the incident by selecting the appropriate level from the drop down list.

Priority The incident priority will default based on the Impact and Urgency that has been selected.

Incident Type Select an incident type from the drop down:

User Service Restoration

User Service Request

Infrastructure Restoration

Infrastructure Event




Work Detail The Work Details tab allows you to create and view work details associated to the Incident.

Field Description

Assigned Group Select the Group you are Assigning the Incident to from the drop down menu.

Assignee Select the Individual Assignee from the drop down menu.

Status Displays the current status of the incident.

Status Reason Displays the status reason once the status moves to Resolved.

Resolution Free text field to note the resolution details of the incident.

Resolution Method Select the relevant resolution method from the drop down menu.




Relationships

Icons & Fields Description

Show Related Drop Down Filter the Incident Relationships displayed using the drop down list

Set your preferences within the Relationship tab

Refresh the Relationships displayed within the table

View the highlighted Relationship

Remove the highlighted Relationship

Request Type Drop Down Select from the drop down list

Quick Actions Drop Down Select from the drop down list




Date & System Information

Field Description

Date Information

Closed Date Displays the date and time the request was closed

Reported Date+ Displays the date and time the request was reported

Responded Date+ Displays the date and time the request was responded to

System Information

Submitter Displays the Authcate of the user who submitted the request

Submit Date Displays the date and time the request was submitted

Last Modified By Displays the user that last modified the request

Last Modified Date Displays the date and time the request was modified

Incident Owner

Owner Group+ Displays the Support Group the user who created the request is associated with

Owner Displays the owner of the Incident


Creating a new Incident Record

Overview Creating new incidents accurately records disruptions to services provided by IT to its

customers. All incidents must be fully logged within Remedy and capture details such as customer, classification and service information. Capturing these details ensures that the information recorded is accurate and complete.

Before you begin

Ensure you have navigated to and opened a new Incident Request as detailed on page 27 – Creating a new Incident.

Adding Customer Details using Authcate

Follow the steps below to add customer details using their Authcate to an Incident record:

Step Action

1 Enter the customers Authcate in the Customer field and press enter:

If.. Then..

Remedy identifies a unique match

The customer and associated company details automatically populate

An INC number generates

Remedy identifies a partial match

A list of customers are displayed for selection o Highlight the correct customer o Click select

The customer and associated company details automatically populate

An INC number generates

2 Click on the Customer hyperlink field to validate the customer details.

If.. Then..

The customer details are correct Close the People form and move to step 7

The customer details are incorrect Close the People form and Move to step 3

3 Click on the Customer toggle icon to display the customer contact details.

4 Click on the edit icon Result: The Phone Details pop up window displays:

5 Enter the customer’s contact details and click OK. Note: This updates the customer’s phone details for this incident only. Advise the customer as per current processes on how to amend their details permanently

6 Click on the Customer toggle icon to return to the original screen.



Creating a new Incident Record, Continued

Adding Customer Details using Authcate ‐ Continued

Step Action

7 If required, enter the contact name by entering their Authcate in the Contact field and hit enter.

If.. Then..


The contact details automatically populate


A list of customers are displayed for selection o Highlight the correct contact customer o Click select


8 Click on the Contact hyperlink field to validate the contact details.

If.. Then..

The contact details are correct Close the People form and move to step 9

The customer details are incorrect Close the People form and complete steps 3 through 6 for the contact information.

9 Move onto entering Incident details on page 39.




Adding Customer Details using Name or ID Number

Follow the steps below to add customer details using their ID number or name to an Incident record: Step Action

1 Place your cursor within the Customer field and hit enter. Result: The People Search pop up displays to search for the customer

2 Are you searching by the Customer name or ID number?

If.. Then..

Customer Name Enter in the first and last name of the customer within the Person Information fields

Tip: Fields are case sensitive.

Click Search

Highlight the customer from the entries returned

Click on Select. Result: The customer and associated company details automatically populate and an INC number is generated.

Move to step 3

Customer ID number

Enter the customers ID number into Staff/Student# within the Person Information fields

Click Search

Highlight the customer from the entries returned

Click on Select. Result: The customer and associated company details automatically populate and an INC number is generated.

Move to step 3

3 Click on the Customer hyperlink field to validate the customer details.

If.. Then..

The customer details are correct Close the People form and move to step 8

The customer details are incorrect Close the People form and move to step 4




Adding Customer Details using Name or ID Number ‐ continued

Step Action

4 Click on the Customer toggle icon to display the customer contact details.

5 Click on the edit icon Result: The Phone Details pop up window displays:

6 Enter the customer’s contact details and click OK. Note: This updates the customer’s phone details for this incident only. Advise the customer as per current processes on how to amend their details permanently

7 Click on the Customer toggle icon to return to the original screen.

8 If required, enter the contact name by entering their Authcate in the Contact field and press enter.

If.. Then..




A list of customers are displayed for selection o Highlight the correct contact customer o Click select


9 Click on the Contact hyperlink field to validate the contact details.

If.. Then..

The contact details are correct Close the People form and move to step 9

The customer details are incorrect Close the People form and complete steps 3 through 6 for the contact information.

10 Move onto entering Incident details. Refer to page 41.




Adding Incident Details

Follow the steps below to add Incident details:

Step Action

1 Enter notes regarding the incident in the Notes field. You can also copy and paste information into this field.

Hint: Click on to expand the field.

2 Is a Template available for use?

If.. Then..

Yes Place the cursor in the template field and hit enter o Select a template from the list that displays o Click on select o The information associated to that template populates the

incident Hint: If you know the name of the template that you want to use, then simply type in the first couple of letters and press enter.

Continue to step 3 and complete as required.

No Continue on to step 3

3 Enter a brief description of the incident in the Summary field.

4 Select the Business Service that is impacted from the Service drop down list.

5 Select the appropriate Impact for the incident from the drop down list.

6 Select the appropriate Urgency for the incident from the drop down list.

7 Select the relevant Incident Type from the Incident Type drop down list.

8 Click on Select Operational to display and select the relevant Operational Categorization.

9 Click on Select Product to display and select the relevant Product impacted.

10 Select the relevant Reported Source type from the Reported Source drop down list.



Creating a new Incident Record – Work Detail

Overview When you begin working on an incident request, you must make sure that you keep careful

work information entries in the Work Details area of the incident request record, explaining what you have done. For example, you might want to add a note that a particular CI was deployed, and include the date. You can add work information entries to an incident request record directly from the Incidents table, or you can add them to open incident request records.

Before you begin

Ensure you are within a newly created incident as detailed on page 37 – Creating a new Incident Record. Note: Work Information Detail entries are optional at the time of creating a new incident.

Adding Work Detail to an Incident

Follow the steps below to add Work Details to an Incident:

Step Action

1 Within the Work Detail tab, click on the Create icon Result: The Incident Work Info displays

2 Select the relevant Work Info Type from the drop down list.

3 Enter a brief description of the incident in the Summary field. Note: This field is limited to 128 characters.

4 Enter details in the Notes field to support the Work Information. Hint: You can cut and paste information directly into this field.



Creating a new Incident Record – Work Detail, Continued

Adding Work Detail to an Incident ‐ Continued

Step Action

5 Are you attaching documents to the Work Info entry? (For Example: A screen shot of an error message that the customer is experiencing.)

If.. Then..

Yes Click on the Add button

Browse for and select the required document and click on OK

Note: You can add up to 3 documents to 1 Incident Work Entry


6 Ensure the Locked field has defaulted to No. This ensures that the Work Info can be modified at a later date if required.

7 Choose the type of view access:

Public: This is the preferred option as it allows the customer to see the work information entry.

Internal: The customer will not be able to see the work information entry.

6 Click on Save Result: The Work Info entry will now be saved against the Incident record.


Assigning an Incident Request

Overview All Incident Requests are required to be assigned to a support group or individual to ensure that

is followed up and completed as appropriate and in line with processes.

New Assignment

When a new Incident Request is created one of the following actions can happen:

The Auto Assigning rules used by Remedy Incident Management automatically assign the incident request to the most appropriate group when the incident request record is saved.

Select the most appropriate support group from the Auto Assign function.

If the incident request is created from a template that has an assignment group predefined, the incident request is assigned to the predefined assignment group.

The incident can be assigned directly to the individual creating it.

Select the appropriate support group from the Assigned Group drop down.

Before you begin

Ensure you have created a new incident record as detailed on page 37 – Creating a new Incident Record.

Assigning Options

Refer to one of the following options to assign an Incident as appropriate: Option Action

1 Auto Assign clicking on Save This assigns the incident based on predefined mapping. Automated assignment can be based on the customer organization, location, operational categorization, or product categorization.

2

Auto Assign using the Auto Assign icon This assigns the incident based on predefined mapping. Automated assignment can be based on the customer organization, location, operational categorization, or product categorization.

3

Assign to Me

4 Select the appropriate support group from the drop down


Re-assigning an Incident Request

Overview There may be instances when an Incident request is assigned to a Support Group or Individual in

error, or alternatively as part of the process it requires to be reassigned to another group or person. You can reassign an incident to either an individual or a support group from within an existing incident request by manually reassigning the incident request to the most appropriate group or individual.

Reassigning incident requests

Follow the steps below to reassign an Incident request:

Step Action

1 Open an existing incident request record.

2 Navigate to the Work Detail tab.

3 Which assigning option do you want to use?

If Then

Auto Assign

Use the shortcut in the Quick Actions section of the Incident Request

form to reassign an incident

Assign to Me

Use the shortcut in the Quick Actions section of the Incident Request form to reassign an incident to yourself (Assign to Me)

Manual Select the appropriate support group from the drop down

4 After selecting an Assigned Group, select the Assignee from the drop down list.


Progressing an Incident

Overview The Process Flow Status bar highlights the milestones within the process and steps you through the Incident Management lifecycle from Identification and Recording to Closure. The current stage that the Incident is in highlights in green for easy identification.


Using the Process Flow Status bar to work through the Incident process will assist you in identifying all mandatory fields and information required at each stage. The Process Flow Status area also guides you through the stages of the incident lifecycle. At each stage, the status bar provides applicable options you can move to. When you select an option, you are prompted with a pop up box to enter data required to complete the stage. You can also enter optional data in the dialog box.

Refer Example below:



Progressing an Incident, Continued

Different Process Flow Status Bars

Depending on the type of record you are creating the process flow status bars will change to support the process (i.e. Problem Investigation or Production Change Management). Whilst the options within the Process Flow Status Bar may change, the steps in using the bar remain the same and will still provide you with a pop up window for any information that is required.

Request Types Process Flow Status Bar

Refer to the images below to view the different types of Process Flow Status bars that you will encounter: Incident / Service Request

Problem Investigation

Production Change Request

Stage Options The table below identifies the stages you can move an Incident through via the Process Flow

Status Bar:

Current Stage Progress to

Identification and Recording Investigation and Diagnosis

Resolution and Recovery

Incident Closure

Investigation and Diagnosis Resolution and Recovery

Incident Closure

Resolution and Recovery Incident Closure



Progressing an Incident, Continued


You can retrieve an Incident at anytime from within the Overview or Incident Management Console to progress it on as required.


Follow the steps below to progress a record through the various lifecycle stages: Note: In this example an existing Incident is being progressed from Investigation and Diagnosis to Resolution and Recovery.

Step Action

1 From the Process Flow Status bar, click on the drop down arrow from the current stage to display the list of options available to move the incident to Resolution and Recovery. Refer to example below:

2 Click on Next Stage > Resolution and Recovery. Result: The Modify Incident pop up box displays prompting you for any additional or required information:

3 Complete the required fields as highlighted as mandatory (bold) and any additional information to support the progression of the Incident.

4 Click on Save Result: The Incident moves onto the next stage and updates the status as appropriate.


Updating/Modifying an Incident

Overview To update an incident request, open the incident request and then update the details as

required. Click save when you finish.

Before you begin

Refer to Creating a new Incident – Work Detail page 42

Adding additional Work Info Entries

When updating an Incident you can create additional Work Info entries to detail additional information or steps and work undertaken as part of the Incident process.

Modifying existing Work Info Entries

If the work information entry is not locked, you can modify any field on it. The following steps describe how to modify the notes, add attachments, lock the entry so it cannot be modified later, and change the viewing access level.

Step Action

1 From the Incident Management console, select the incident request record and navigate to the Work Info tab.

2 From the list of work information entries, select the work information record that you want to update.

3 Click View

4 Make the required modification:

If Then

You want to update the note

Click inside the Notes field and type the changes

You want to add an attachment

Right‐click in the attachment table and select Add from the menu that appears then follow the on screen instructions. Note: Attachments to work information entries are only available from within the specific Incident.

To lock the entry From the Locked list, select Yes or No. Note: If you select Yes, the work information entry cannot be modified after you save it.

To change the view access level

From the View Access list, select: Internal or Public from the View Access list.

Internal: if you do not want the customer to see the work information entry.

Public: if you want the customer to see the work information entry.


Resolving and Closing an Incident

Overview At Monash all Incidents will go through a two (2) step closure process by utilising an automatic

closure period after the status within an Incident is set to “Resolved”. Incidents will be automatically closed after 10 working days if no further contact is made by the Customer. Only once this has happened will the Incident move to Closed and cannot be re‐opened. This procedure may also trigger a Customer Satisfaction survey once the Incident record is formally closed.

Process Once all the action required on an Incident has been completed you can move the Incident,

using the Process Flow Status Bar, through the process to the Incident Closure stage:

An Incident will only be moved to the Closed stage once the customer has confirmed and accepted the resolution and the status has been updated accordingly:

If the Customer confirms acceptance of resolution, the Incident Assignee sets the status to “Resolved – Customer Confirmed Resolution.”

If the Customer has not been contacted, the Incident Assignee sets the status to “Resolved – Customer Follow‐up Required”.

Important Note: Whilst it is the responsibility of the assignee to contact the customer, the Service Desk will be required to monitor all Incidents with a status of “Resolved – Customer Follow Required”, and contact the customer where required.



Resolving and Closing an Incident, Continued

Incident Closure Process Steps

Complete the following steps to move an Incident through to Incident Closure:

Step Action

1 From the Process Flow Status bar, click on the drop down arrow from the current stage to display the list of options available to move the incident to Incident Closure. Refer to example below:

2 Click on Next Stage > Incident Closure

3 Result: The Modify Incident pop up window displays for the required information to be completed:

4 Complete the required fields as highlighted as mandatory (bold) and any additional information to support the progression of the Incident.

5 Can the customer confirm acceptance of the resolution?

If… Then…

Yes Set the Status field to “Resolved – Customer Confirmed Resolution.”

No Set the Status field to “Resolved – Customer Follow‐up Required”.

6 Click on Save Result: The Incident moves onto the next stage and updates the status as appropriate.



Resolving and Closing an Incident, Continued

Incident Closure Process Steps ‐ Continued

Step Action

7 Set the Resolution Method from the drop down options; • On Site Support • Self Service • Service Desk Assisted • Remote Control

Rules for closing and re‐opening Incident records

The following rules apply when moving an Incident through the Resolved and Closed stages:

All Incident records with a status of ‘Resolved’ will be automatically closed after 10 working days if no further contact has been made by the Customer.

The Incident will only be re‐opened from a ‘Resolved’ state if it is deemed by the Service Desk to be a continuation of the same incident and not a new or similar occurrence, in which case a new Incident record must be created and linked.

Incident records cannot be re‐opened from a Closed status.

Additional Info The process flow bar is key in moving through a process, however there are additional options

that can be used at anytime:

An incident can be moved through the stages of the process at anytime by clicking on the

Next Stage button . This will move the incident through the process stages and prompt you for any required information.

An incident can be resolved at any time by clicking on the Resolve button . This will move the incident through to the Incident Closure stage and prompt you for any required information.


Quick Close Templates

Overview Many calls that come through to the Service Desk can be for Incidents or Requests that are

common and quick and easy to resolve, such as Password resets. To support these calls and using the template functionality within Remedy, “Quick Close Templates” have been developed. These templates will assist Service Desk in recording these calls, efficiently and accurately whilst supporting any reporting requirements.

Quick Close Templates

The following table outlines the Quick Close templates that are currently available within Remedy:

Template Category Tier 1 Template Name

Quick Close Callista Password Reset

Quick Close SAP Password Reset

Quick Close Staff Password Reset

Quick Close Student Encumbrance

Quick Close Student Internet Quota Query

Quick Close Student Labs. Enquiry

Quick Close Student Laptop Network Configuration

Quick Close Under Age Authorisation

Quick Close WES Assistance

Creating an Incident using a Quick Close Template

Follow the steps below to create an Incident using a Quick Close template:

Step Action

1 From the Incident Management Console click on:

The create icon or,

New Incident under the Functions navigation

2 Enter the customers details (refer to Creating a new Incident Record – Adding Customer Details pg 37).

3 Within the Template field type the name of the Quick Close template you want to use (refer to the table above).

3 Hit Enter:

If.. Then..


The template information automatically populates

Move to step 4


A list of templates are displayed for selection o Highlight the correct template o Click select

The template information automatically populates

Move to step 4

5 Click on Save Result: The Incident is Resolved and Saved and will move to Closed as per the Closure process.


Searching for an existing Incident

Overview You can search for Incident request records from the Incident Management console, via:

Search using an Incident (INC) number,

Predefined searches,

Create and save your own custom searches using advanced qualifications, or

Search all of the records using the Search Incident form.

Searching on a specific INC number

Each time an Incident request is created it automatically generates an Incident or INC number. This number is specific to the Incident and can be used as a reference for searching.

Steps Follow the steps below to search for a specific Incident using an INC number:

Step Action

1 From the Incident Management console Navigation pane navigate to:

Functions Search Incident. Result: The Incident request form appears in Search Mode

2 In the Incident ID field enter in the INC number Example: INC000000000192

Hint: Entering the last three digits (192 in the example above) will also work within this field.

3 Press Enter. Result: The specific Incident will display in Modify mode.


Searching for an existing Incident – Defined Searches

Defined Searches

The Defined Searches area of the Navigation pane contains a series of predefined searches that you can use to look for incident request records. For example: Use a predefined search to locate all Open Incident Requests with a priority of Critical. The predefined search function searches records that are associated with you through your Authcate or Support Group ID.

Searching for an Incident using Defined Searches

Follow the steps below to search for an Incident using Defined Searches: Step Action

1 Ensure the Company and View By fields in the Incident Console area are pointing to the appropriate company and support group.

2 From the Incident Management Console, navigate to the Defined Searches area of the Navigation Pane.

3 Open the search category that corresponds to the search you want to run and then select a specific search option. Example: To view all Open and Unassigned Incident requests select the following:

All Open Unassigned All Priorities Result: All Open Unassigned Incident requests at all priority levels will display in the Incident Management Console table.



Searching for an existing Incident – All Records

Searching all Records

The following procedure describes how to search all incidents. Use this type of search when you are looking for an incident that is not associated with your ID or your group’s ID, or at any time you wish to search all incidents.

Steps Follow the steps below to search for all Incident requests:

Step Action



2 Use the fields to enter in your search parameters. To reduce the number of incidents returned in the search, enter as much information as you can.

3 Click Search. Result: The search results table displays with all the records that match the search criteria.

4 Locate the specific record you want within the table, and double click to display it in Modify mode.



Overview

Introduction The term ‘Service Request’ is used as a generic description for many varying types of demands

that are placed upon the IT organisation by Customers. Many Service Requests are actually small changes – low risk, frequently occurring, low cost, etc. (e.g. a request for password reset, a request to install additional software, a request to relocate some items of desktop equipment) or maybe just a question requesting information – but their scale and frequency, low‐risk nature means that they are better handled by a separate process. This is to ensure that Service Requests do not congest and obstruct the normal Incident and Change Management processes, which have different purposes and goals.

Contents This chapter contains the following topics.

Topic See Page

Introduction to Service Request Management 59

Service Request Management Process Flow 60

Accessing & Navigating Service Desk Online 61

Fulfilling a Service Request 63

Searching for a Service Request 64


Introduction to Service Request Management

Definition A Service Request is a request from a Customer for information, advice, or for access to a

service offered in the ICT Service Catalogue.

Purpose The purpose of Request Management is to ensure that all services requested by Customers are

fulfilled effectively and efficiently.

Goals Request Management is the process of dealing with Service Requests from Customers. The goals

of the Request Management process include:

To provide a channel for Customers to request and receive standard services for which a pre‐defined approval and qualification process exists

To provide information to users and customers about the availability of services and the procedure for obtaining them

To source and deliver the components of requested standard services (e.g. licences and software media)

To assist with general information, complaints or comments.


The following roles and responsibilities have been identified to support the Request Management processes at Monash University:

Role Definition

User (Customer) A user requests information, access or advice on a service offered in the ICT Service Catalogue.

Service Provider Service (or Fulfilment) Providers (i.e. Service Desk Analyst) execute the Service Request by managing the request through its lifecycle from submission to delivery and follow up.


Service Request Management Process Flow

Diagram The process flow diagram below details the Service Request Management process:


Accessing & Navigating Service Desk Online

Overview The term ‘Service Request’ is used as a generic description for many varying types of demands

that are placed upon the IT organisation by Customers. Many Service Requests are actually small changes – low risk, frequently occurring, low cost, etc. (e.g. a request for password reset, a request to install additional software, a request to relocate some items of desktop equipment) or maybe just a question requesting information – but their scale and frequency, low‐risk nature means that they are better handled by a separate process.

Service Centre Online

A Service Request can be initiated by the Customer from a variety of channels e.g. online, phone or email to the Service Desk, however the majority of Service Requests will be initiated via the web front‐end, Service Desk Online, where they may also report and issue or fault (incident). In line with Remedy, Service Desk Online becomes live on October 18th 2010.

Navigating to the Service Centre Online

Follow the steps below to navigate to the Service Desk Online webpage:

Step Action

1 Launch your Internet Browser and key in the following URL: www.ServiceDeskOnline.monash.edu. Result: Service Desk Online displays:

Screen Overview

Area Description

1 Service Categories Provides a navigation area where you can drill down into various menu options depending on the request.

2 Search Bar Search for a particular form.

3 Navigation Bar Provides access to frequently used options and actions as well as snap shot of all current requests in progress.


1

2

3


Accessing & Navigating Service Desk Online, Continued

Raising a Service Request via Service Centre Online

The following steps apply when a customer raises a Service Request via Service Centre Online:

Step Action

1 The customer logs onto to Service Desk Online and locates the appropriate Service Request form within the catalogue of Service Requests available. Note: If the required form is not available within Service Desk Online then current processes still apply.

2 The Service Request form is completed and submitted within Service Desk Online.

3 Once the request has been submitted a Service Request record automatically generates within Remedy inline with the Incident process and with the following details:

REQ ID number

Incident Type generate as User Service Request

Customer details

Request details

Category information

Service Level information

Assigned Support Group Note: The initial Service Request assignee is typically the Service Centre analyst (Tier 1), however, some Service Requests will route directly to Tier 2 support groups.

4 Automatic notification is sent to the assigned Support Groups, and the Incident Management queue updates.

5 A ‘Service Request Created’ notification is sent to the Customer.


Fulfilling a Service Request

Process Details Depending on the type of Service Request and the assigned Support Group, either the Service

Desk or Tier 2 support groups will carry out the tasks and activities required to actually fulfil the request.

The following points apply when fulfilling a Service Request:

The Service Request process and fulfilment steps are the same as the Incident Management process and are reflected as such with the same Process Flow Status bar.

All activities undertaken should be fully documented in the Service Request in the same way as all activities are documented against an incident record so that a complete historical record is maintained at all times.

Whilst most Service Requests that come through Service Desk Online will populate an assigned support group (via a template), standard Assigning and Re‐assigning processes still apply.

Process Steps Refer to the table below when working on Service Requests:

If you want to… Then refer to… Page

Create a Service Request through Service Desk Online

Accessing and Navigating Service Desk Online 60

Create a Service Request within Remedy

Creating a new Incident Record Note: Ensure you select the correct Incident Type as User Service Request

37

Assign a Service Request Assigning an Incident Record 44

Reassign a Service Request Reassigning an Incident Record 45

Updating/Modifying a Service Request

Updating/Modifying an Incident

49

Resolve and Close a Service Request

Resolving and Closing an Incident 50

Search for an existing Service Request

Searching for a Service Request 63


Searching for a Service Request

Searching on a specific REQ number

Each time a Service Request is created it automatically generates a Request or REQ number. This number is specific to the request and can be used as a reference for searching.

Steps Follow the steps below to search for a specific Service Request using an REQ number:

Step Action



2 In the SRM ID field enter in the REQ number Example: REQ000000000103


3 Press Enter. Result: The specific Service Request will display in Modify mode.


Problem Management

Overview

Introduction Problem Management aims to resolve the root causes of incidents therefore minimising impacts

of incidents and problems on the business that are caused by errors within the IT infrastructure. The Problem Management process includes the activities required to diagnose the root cause of incidents and to determine the resolution to those problems.


Topic See Page

Introduction to Problem Management 66

Problem Management Process Flow 67

Accessing & Navigating the Problem Management Console 68

Accessing & Navigating the Problem Management Screen 72

Raising a Problem Investigation Request 80

Assigning a Problem Investigation 81

Creating Tasks 82

Searching for a Problem Investigation 83


Problem Management Introduction

Definition A `problem' is an unknown underlying cause of one or more incidents; it is often identified as a

result of multiple incidents that exhibit common symptoms. Problems can also be identified from a single significant Incident (e.g. Major Incidents with a high Impact).

Purpose Problem Management is responsible for managing the lifecycle of all problems.

The primary objectives of Problem Management are:

To prevent problems and resulting incidents from happening,

To eliminate recurring incidents,

To minimise the impact of incidents that cannot be prevented.


The following roles and responsibilities have been identified to support the Problem Management processes at Monash University:

Role Definition

Problem Coordinator Reviews the Incident/s that are related to the service(s) for which is identified for the Problem record

Ensures that the Problems for which he/she is responsible, including the ones that have been identified within the Availability and Capacity Management processes, progress through the Problem Management process in a timely and prioritised fashion

Ensures that the information entered in the problem investigations and known errors that he/she manages is accurate and complete.

Periodically reviews his/her problem investigations for which a practical structural solution could not be found.

Verifies structural solutions and closes the known errors and problem investigations that he/she manages.

Tier 2 Problem Assignee/Specialist

Suggests workarounds for problems.

Establishes the root causes of identified problems

Proposes structural solutions for problems.

Implements structural solutions for problems if Change Management is not required.

Updates the problem investigations with relevant information and status changes.


Problem Management Process Flow

Process Flow The process flow diagram below details the Problem Management process:


Accessing & Navigating the Problem Management Console

Overview The Problem Management console provides problem coordinators and specialists with a single

point from which they can create problem investigations, known error and solution database entries. It also provides a place from which they can monitor the progress of problem investigations as it moves through its lifecycle.

Navigating to the Problem Management Console

Follow the steps below to navigate to the Problem Management Console:

Step Action

1 From the Overview Console click on the Problem Management link under the Consoles Navigation bar. Result: The Problem Management Console displays:

Console Header

Area Description

Console/KPI tabs Toggle between the Console and KPI tabs to access incidents and reporting.

Close Closes the Problem Management console and returns you to the Overview Console.

Help Access Help functionality within Remedy.



Accessing & Navigating the Problem Management Console, Continued

Problem Console Header

Area Description

Company Provides options to filter the Problem Management records in the Problem table using the drop down menu.

View By Provides options to filter the Problem Management records in the Problems table using the drop down menu.

Refresh updates the console with the latest information.

Navigation Pane – Problem Counts

Area Description



Problem Counts Display’s the number of Open, Unassigned and Unacknowledged, Problems, and Open Known Errors for the Company and View By fields.


Area Description

Defined Searches

This area provides a place from which you can run a series of predefined searches. You also have the ability to define custom searches using Manage My Searches.

Manage My Searches

Defines, edits, saves, and deletes custom searches. Saved custom searches appear in the My Searches area of the Defined Searches list. See Note: If no custom searches have been defined, then the My Searches option does not appear.





Area Description

New Problem Create a new Problem Investigation record.

Search Problem Search the database for current Problem Investigation records.

New Solution Not currently in use at Monash University

Search Solution Search the database for current Solution records

New Known Error Not currently in use at Monash University.

Search Known Error Not currently in use at Monash University

My Profile Search for information about specific CI types and gives you access to the CI records.

Application Preferences

Access the Manage Inventory form of BMC Remedy Asset Management.

Reminders Review and respond to customer surveys.

Reports Opens the detailed Incident Management process in SMPM if the full SMPM application is installed and configured. Otherwise, it opens a high level diagram of the incident management process.

Manage CIs Search for information about specific CI types and gives you access to the CI records.

Manage Inventory Access the Manage Inventory form of BMC Remedy Asset Management.

Process Overview Opens the detailed Problem Investigation process.


Use the Consoles field within the Navigation Pane to access additional consoles such as Incident and Change Management. Refer to topic Remedy Console Access on page 16 for full details of Consoles. Note: Consoles that you can access are determined by your permissions and therefore may vary across users.




Problem Table The Problem table provides an overview of all the Problem Investigation records that match the

criteria specified in the Company and Assigned To fields, or alternatively records that were retrieved by the most recently completed search (i.e. Predefined Searches).

Area Description

Create Creates a new incident request record.

View Opens and displays the highlighted Incident request.

Print Prints the selected record.

Preferences Update your personal preferences for the table.

Problem Detail & Tasks

Area Description

Toggles the screen to display Tasks associated with the highlighted incident request.

Click on the Create icon to create new work information notes against the associated incident.

Click on the View icon to view work information notes and the associated incident.


Accessing and Navigating the Problem Management Screen

Introduction In this view, the fields most commonly used for creating, resolving, and updating problem

investigations and known errors are immediately visible. You can access additional, less frequently used functionality from the tabbed sections of the form or from the links in the Navigation pane. The order in which the fields appear on the form reflect the order in which you gather the information when you create the problem investigation record. This reduces the amount of time needed to create the record and improves the overall efficiency of the operation.

Creating a new Problem Investigation

Complete the action below to open a new Problem Investigation form:

Step Action

1 From the Problem Management Console click on:

The create icon or,

New Problem under the Functions navigation

2 Select Problem Investigation from the Problem Type drop down options.

Result: A new Problem Investigation form displays:



Accessing and Navigating the Problem Management Screen, Continued

Parts & Functions

The following tables explain the parts and functions of different areas within the Problem Investigation screen.

Problem Header The Problem header identifies the current mode that Remedy is in and allows you to action

searches or new requests quickly.


The Process Flow Status bar highlights the milestones within the process and steps you through the Problem Investigation lifecycle from Identification and Classification to Closed. The current stage that the Problem Investigation is in highlights in green for easy identification.




Navigation Pane The Navigation Pane within the Problem Investigation screen provides you with quick access to

additional functions that support the Problem Management process. Note: Not all functions are currently in use at Monash University.


Field Description

Assign to Me Assigns the incident request to the person creating the incident.

Auto Assign Using Auto Assignment rules, displays the relevant support groups in which to assign the incident to.

Broadcast Problem

Create and send a new broadcast for a specific incident to the appropriate support groups.

Select Operational

Mandatory field – Select the appropriate Operational Category to classify the type of issue the customer is experiencing.

Select Product Mandatory field – Select the appropriate Product Category the customer is experiencing issues with. Note: This will assist in defining the Support Group for Auto Assigning the Incident.

Navigation Pane – Links

Field Description

Tasks View and relate Tasks associated to the Problem Investigation

View Audit Log View the audit trail of a Problem Investigation

Categorizations View the Categorizations that have been selected for the Problem Investigation.

Search Knowledge Base


Create Knowledge



Field Description

Email System Email a copy of the Problem Investigation to the customer

Process Overview

Link to the Problem Investigation Process Overview




Navigation Pane –Advanced Functions

Field Description

Impacted Areas Link areas within the Business that are impacted by the Problem Investigation

Advanced Search

Provides options in which to run advanced searching for Problem Investigation. This will open a new tab within Remedy in Search mode.


Field Description

Overview Return to the Overview Console within Remedy

Problem Management

Return to the Problem Management Console within Remedy

Reports Navigate to the Report Console where you can enter parameters to generate reports.

Problem Coordinator Details


Problem ID Displays the Problem Investigation ID number which is automatically generated when a Problem Coordinator is entered. This ID number can be used as a reference for searching.

Coordinator Group

Automatically defaults to display the Support Group that the Problem Coordinator belongs to.

Problem Coordinator

Automatically defaults to the support analyst creating the Problem Investigation. This can be changed by clearing the field and entering another coordinator.

Problem Location

Automatically defaults to display the location associated to the Problem Coordinator.




Problem Details


Service The Service field relates business service configuration items (CIs) to the Problem Investigation at the time it is created and is mandatory. Only the Customer Services that you are entitled to see appear in the selection list for this field.

Summary Free text field to enter a brief description about the Problem Investigation. This is a mandatory field and is required to be completed when creating the record. Note: This field is limited to 128 characters.

Notes Free text field to enter additional details about the Problem with unlimited character functionality. Hint: You can cut and paste information directly into this field.

Problem Details Continued


CI The CI field provides a place for you to indicate to which piece of infrastructure the Problem Investigation pertains. Enter this field when you resolve the Problem or at any time in the Problem Investigation lifecycle.

Investigation Driver

Specifies the reason for the investigation, i.e. High Impact Incident

Target Date Enter target date for resolution or contact to customer.

Impact Identify the impact of the Problem on the University by selecting the appropriate level from the drop down list.

Urgency Identify the urgency of the Problem by selecting the appropriate level from the drop down list.

Priority The Problem priority will default based on the Impact and Urgency that has been selected.




Work Details The Work Details tab allows you to create and view work details associated to the Problem

Investigation.

Field Description

Assigned Group Select the Group you are Assigning the Problem Investigation to from the drop down menu.

Assignee Select the Individual Assignee from the drop down menu.

Vendor Not currently used at Monash University

Vendor Ticket Number

Not currently used at Monash University

Status Displays the current status of the Problem Investigation.

Status Reason Displays the status reason once the status moves to Resolved.

Workaround Enter details to any identified Workaround within the free text field.

Resolution Free text field to note the resolution details of the Problem Investigation.





Show Related Drop Down Filter the related records displayed using the drop down list










Date & System Information

Field Description

Date Information

Workaround Determined On

Displays the date and time the workaround was determined and entered into the system

Known Error Created Displays the date and time the known error was created

Last Completed Date Displays the date the record was last updated.

System Information

Submitter Displays the Authcate of the user who submitted the record

Submit Date Displays the date and time the record was submitted

Last Modified By Displays the user that last modified the record

Last Modified Date Displays the date and time the record was modified


Raising a Problem Investigation Request

Overview Problems can be detected from a range of sources, including internal and external customers,

Service Desk and Tier 2 Support. All the relevant details of the problem must be recorded in Remedy so that a full historical record exists. The Problem record can then be classified and forwarded to the appropriate Tier 2 support group for investigation.

Process Description

The following process outlines how detected Problems are recorded, classified and handled by the Problem Co‐ordinator (person detecting). This may be a Service Centre analyst or a Tier 2 Support Group analyst.

Steps Follow the steps below to raise a Problem Investigation:

Step Action

1 Within the Problem Investigation screen ensure the following information has defaulted:

Field Defaulted to

Coordinator Group

Your support group. If you are assigned to multiple groups you can change as required.

Problem Coordinator

Your name. This can be changed to the person who has detected the problem.

Problem Location Problem Coordinator’s location

2 Select a Service that is being impacted by the Problem Investigation from the drop down list.

3 Enter a brief description of the Problem Investigation in the Summary field.

4 Update the Notes field with any additional information.

5 Complete the following mandatory fields:

Investigation Driver (e.g. High impact, Recurring etc)

Operational Category

Product Category

Impact

Urgency Note: Problem prioritisation should also take into account the severity of the problems ‐ for example:

Can the system be recovered, or does it need to be replaced?

How much will it cost?

How many people, with what skills, will be needed to fix the problem?

How long will it take to fix the problem?

How extensive is the problem (e.g. how many CIs are affected)?

6 Identify and assign the Problem Investigation to the most appropriate Tier 2 group for Investigation and Diagnosis activities.

7 Click on Save Result: The Problem Investigation record is forwarded to the assigned support group.


Assigning/Reassigning a Problem Investigation

Overview All Problem Investigation are required to be assigned to a support group or individual to ensure

that is followed up and completed as appropriate and in line with processes.

New Assignment

When a new Problem Investigation is created one of the following actions can happen:

The Problem Investigation can be assigned directly to the individual creating it.

Select the appropriate support group from the Assigned Group drop down.

Before you begin

Ensure you have created a new, or are within an existing Problem Investigation.

Assigning Options

Refer to one of the following options to assign an Incident as appropriate: Option Action

1

Assign to Me

2 Select the appropriate support group from the drop down


Creating Tasks

Overview If internal assistance is required, the Problem Assignee generates ad hoc tasks from within the

Problem record, with descriptions of what needs to be accomplished and forwards them as appropriate.

Note: The Problem Assignee has overall responsibility to manage the tasks and ensure that work is completed so that Problem Investigation can progress.

Relating Tasks to a Problem Investigation

Follow the steps below to add Tasks to a Problem Investigation:

Step Action

1 Within an open Problem Investigation record, navigate to Links > Tasks.

2 Click on Create

2 Result: The Task form displays:

3 Complete the following required fields:

Name—Enter a descriptive name of the task.

Summary—Enter a brief description of the task. Note: The Type field defaults to Manual when you create an ad hoc task.

5 Within the Requester tab:

Requester information automatically defaults to the person creating the task.

Requested For ‐ enter details about the person who is the intended target for the task

7 Within the Assignment/Dates tab – complete the following fields to assign the task:

Assignee Group: Select a task implementer group from the list.

Assignee: Optionally, select a task implementer from the list.

Scheduled Start Date: Enter an estimated start date.

Scheduled End Date: Enter an estimated end date. Tip: You may want to set the Start Date and End Date to be different from the dates of the parent change request.

9 Click Save.


Searching for a Problem Investigation

Searching on a specific PBI number

Each time a Problem Investigation is created it automatically generates a PBI number. This number is specific to the request and can be used as a reference for searching.

Steps Follow the steps below to search for a specific Problem Investigation record using a PBI number:

Step Action

1 From the Problem Management console Navigation pane navigate to:

Functions Search Problem. Result: The Problem Investigation screen appears in Search Mode

2 In the Problem ID field enter in the PBI number Example: PBI000000000103


3 Press Enter. Result: The specific Problem Investigation will display in Modify mode.


Service Level Management

Overview

Introduction Service Level Management has been implemented at Monash University to ensure that all

operational services and their performance are measured in a consistent and professional manner throughout the IT organisation. This enables accurate analysis and reports that the services meet the requirements of the University.


Topic See Page

Service Level Management 85

Managing Service Targets 88


Service Level Management

Definition A Service Level Agreement (SLA) is a negotiated agreement between the customer and the

service provider which may refer to the delivery time of performance of a service.

Summary Targets are set for Responding to and Resolving individual Incidents. Service Level Agreement

(SLA) targets are defined by what percent of the time Incidents are expected to meet their targets. The achievement of these targets is measured and reported. Email notifications are sent to designated individuals at defined points in the life cycle of individual Incidents and when SLA performance falls below defined levels.

Implemented Initially, Service Level Agreements have been put in place for the following:

Incident Management where Priority = Critical

Incident Management where Priority = High

Incident Management where Priority = Medium

Incident Management where Priority = Low Where Priority is defined within Remedy, utilising a Prioritisation formula (Refer to Advanced Functions)

Business Times The following times default to support the SLA’s unless otherwise identified within the Service

Level Targets.

Day Open Time Close Time

Monday 08:00 18:00

Tuesday 08:00 18:00

Wednesday 08:00 18:00

Thursday 08:00 18:00

Friday 08:00 18:00

Saturday ‐ ‐

Sunday ‐ ‐

Christmas Shutdown: Thursday 23rd December 2010 – Monday 3rd January 2011

Australia Day: Wednesday January 26th 2011

Easter: Friday April 22nd – Tuesday April 26th 2011

Anzac Day: Monday April 25th 2011

Note: These are subject to change based on current calendar year



Service Level Management, Continued

Incident Targets The following table details the Incident targets:

Target Details

Response targets The time between Incident creation and when the person who requested an Incident (Customer) is informed that someone is working on it. That response to the Customer is in the form of an email, which is initiated when the Incident is assigned to an individual and the Status is “In Progress” or beyond.

Resolution targets The time between Incident creation and when the Incident is Resolved (in “Resolved” status or beyond).

NOTE: If an Incident is returned to an earlier Status than “Resolved” (eg. “In Progress”) the clock that measures the actual resolution time will restart. This might happen if the Customer explains that the Incident wasn’t actually completed successfully and the Assignee agrees to reopen the Incident for further activity.

Prioritisation Formula

When a user selects the impact and urgency of an Incident the following table calculates the priority weighting.

Impact

Extensive/Widespread Medium(9) High (19) Critical (24) Critical (29)

Significant/Large Medium(5) Medium (15) High (20) Critical (25)

Moderate/Limited Low (3) Medium (13) High (18) High (23)

Minor/Localised Low(0) Medium (10) Medium (15) High (20)

4 Low 3 Medium 2 High 1 Critical

Urgency

Service Level Targets

Service Level targets are the benchmarks that are set for service performance. Service Level Management procedures are in place to monitor performance against these targets with an escalation process associated with them to enable timely action when services are in breach of their targets. The following Service Level Target (SLT’s) have been put in place: Incident Priority

Response Target Resolution Target Measured During

Critical 15 minutes 4 hours 24 x 7

High 30 minutes 4 hours Monash Business Hours 8am – 6pm)

Medium 2 hours 1 day Monash Business Hours (8am – 6pm)

Low 8 hours 2 days Monash Business Hours (8am – 6pm)



Service Level Management, Continued

Roles and Responsibilities

The following table outlines the roles and responsibilities involved in Service Level Management:

Role Responsibility

Operational Line Manager A person managing an operational team that contributes to the delivery of one or more ICT services. In Monash, managers at this level are accountable for their team’s performance in meeting ITSM process targets such as incident and problem resolution, service request fulfillment, responding to change requests, etc.

Service Manager This role is responsible for:

negotiating service level agreements with customers and

reviewing them at least annually

the quality of one or more services delivered to customers

ensuring that service achievement reports are published in

a timely manner and are accurate

ensuring any breaches or near misses of service levels are

investigated and improvement actions implemented

conducting service reviews with customers on a regular

basis (monthly or quarterly)

Service Level Manager This role owns the SLM process and is responsible for:

ensuring that the process goals and objectives are achieved

keeping process documentation and this framework aligned

to the changing needs of the University

reviewing process performance on a regular basis

ensuring that opportunities for improvement are identified

and input into continual service improvement

working with the Accounting process to ensure that

services are costed so that those costs can be recovered


Managing Service Targets

Details Service Level Management within Remedy shows both overview and in‐depth information

about the incident in relation to the applicable service targets. You can view request‐based service targets attached to incident requests. This enables you to see whether the service target has been met, missed, or is in a warning state.

Viewing Service Targets

Follow the steps in the table below to view service targets related to an incident request

Step Action

1 From the Incident Management console, open the relevant incident request record

2 View the SLM Status icon from the Navigation pane as detailed below

Status: Not Attached. No service target is attached to the incident.

Status: Attached. Green: The service targets are in compliance.

Status: Warning. Yellow: At least one service target is at risk.

Status: Breached. Red: At least one service target did not meet its

goal.


Production Change & Release Management

Overview

Introduction The purpose of Production Change and Release Management is to ensure that:

standardised methods and procedures provide efficient and prompt handling of all changes

all releases impacting service areas are documented, catalogued, communicated and available to all users as well as operational and support areas, all changes to service assets and configuration items are recorded in the Configuration Management Database (CMDB), and overall business risk is minimised.


Topic See Page

Production Change & Release Management Introduction 90

Production Change Management Process Flow 93

Category and Approval Matrix 94

Categories, Authorities & Lead Times 95

Accessing & Navigating the Change Management Console 96

Accessing and Navigating the Change Management Screen 97

Raising a request for Change 108

Raising a request for Change – Work Detail 110

Raising a Request for Change ‐ Tasks 112

Raising a request for Change – Relationship Detail 114

Raising a request for Change‐Relating Unavailability 115

Progressing a request for Change 116

Searching for an existing request for Change 118

Searching for a request for Change – Defined Searches 119

Updating/Modifying a Change Request 120


Production Change & Release Management Introduction

Definition A Change is: any action, physical, logical, or procedural, which adds, modifies, or removes:

an authorised, planned or supported IT service, or

a service component. A Release is a:

a major change that is going to significantly impact the functionality of a service, affecting the way consumers interact with that service.

Goals The goals of production change and release management are to respond to the:

Customer’s changing business requirements while reducing incidents, disruption and re‐work, and

University and ICT staff requests for change while aligning the services with the business needs.

The goals of release management are to:

deploy releases into production and establish effective use of the service to deliver value to the customer

be able to build, test and deliver all required capabilities and accomplish the stakeholders’ requirements and deliver the intended objectives

deliver consistent high quality releases by completing all appropriate key activities: o planning o designing o building & development o testing and acceptance o communication and training o release distribution and implementation o review and learning

support transition to service operations to reduce incidents, disruption and re‐work.



Production Change & Release Management Introduction, Continued

Types of Changes

There are varying types of change as detailed below:

Change Type Description

Standard A change (for example a server reboot) that has been pre‐approved by the CAB. This change type can only be used within template format.

Minor A change is planned and scheduled with approval by a Line Manager prior to implementation.

Moderate A change that requires both Technical Approver(s) and the ICT Change Manager approval. This ensures that all technical aspects, clarity and completeness are covered effectively. Note: The Production Change Manager may determine if additional approvers are required.

Major A change that requires both Technical Approver(s) and the ICT Change Manager approval. This ensures that all technical aspects, clarity and completeness are covered effectively. The Change Advisory Board (CAB) also reviews and approves the change and advises the Production Change Manager of any concerns.

Major & Extensive

As with major this change will also be reviewed by the CAB and then sent onto the Executive Committee for approval.

Emergency A change is implemented based on verbal approval from the appropriate approver. Once it is implemented a Request for Change record is completed within Remedy. Note: Where possible the ICT Change Manager must be notified.

Release The Release Manager reviews the record and ensures that a Release Plan has been initiated as part of the process.



Production Change & Release Management Introduction, Continued


The following roles and responsibilities have been identified to support the Production Change and Release Management processes at Monash University;

Role Responsibility

Change Owner (Change Coordinator)

To create, plan, implement, track and close changes related to services that their support group is responsible for.

Assesses requests for change that originated from Incident or Problem Management.

Determines the risk and impact for requested changes

Prepares implementation by creating tasks

Monitors the progress of change

Change Manager Complete overview of the infrastructure and knows details of what is to be changed.

Reviews the risk and impact analysis to ensure that it has been completed thoroughly.

Ensures that appropriate actions have been planned to minimize both the risk of failure and the impact on users during change implementation.

Ensures that the timing of planned implementations does not conflict with other planned changes or events.

Obtain approvals for changes.

Change Approver A stakeholder who reviews and approves a change at any stage in its lifecycle. This could be a Line Manager, the Change/Release Manager, the CAB or the Executive Committee and they are responsible for:

reviewing details of relevant changes and releases

determining and identifying issues, risks, and their likely impact

providing required approvals to proceed

ensuring that resources are available to complete the change or release.

Release Manager A two part role that includes the Release Process Owner role responsible for the design, implementation and operation of the Release Management process; and the Release Functional Manager role responsible for the daily management of releases and communications to the ICT community.


Production Change Management Process Flow

Process Flow The following details the process flow as used in Production Change Management, incorporating

Release Management:


Category and Approval Matrix

Category Matrix The matrix below displays how the Change Category is calculated based on Risk and Impact:

<‐ Impact ‐>

4 3 2 1

<‐ Risk ‐>

1 Minor Minor Moderate Major

2 Minor Minor Moderate Major

3 Moderate Moderate Moderate Major

4 Moderate Moderate Major Major

5 Major Major Major Major

Approval Matrix The matrix below displays at what point approvals are required through the Change

Management process:

Approval Standard Minor Moderate Major Emergency Release

Review None None None Line Manager ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

Change ManagerNone

Line Manager ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

Change Manager

Business None None None CAB None CAB

Implement None Line Manager Line Manager ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

Change Manager

Line Manager ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

CAB Line Manager

Line Manager ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

CAB

Close None None None Change Manager Change Manager Change Manager


Categories, Authorities & Lead Times

Details The following table details the authority and lead time required for change implementation:

Change Category Change Criteria Change Authority/Approver Implementation Lead

Time (Business Days)

Standard or Pre Approved

Routine, documented, low complexity, low risk, low impact, regular tasks

Not required, but task must be Pre‐Approved for implementation by the Change Advisory Board (CAB)

0

Emergency Immediate implementation in response to an incident

Verbal approval to proceed with the Change by an ICT Manager and approval for the record is the Production Change Manager

0

Expedited Implementation is required prior to the associated lead time

Change Manager validates case for expediting Moderate – Line Manager / Change Manager Major – ECAB

As Requested

Minor Low business impact Team Leader/Manager 2

Moderate Moderate business impact Production Change Manager 5

Major Potential for Significant business impact

Change Advisory Board (CAB) 10

Major/Extensive Potential for Major business impact

CAB with manual escalation to ICT Directors

20

Release Major change that is going to significantly impact the functionality of a service, affecting the way consumers interact with that service

Change Advisory Board (CAB) 10


Accessing & Navigating the Change Management Console

Overview The Change Management Console provides a dedicated workspace for managing change

requests. This console enables change managers and change coordinators to easily access, review and action Change and Release requests.

Navigating to the Change Management Console

Follow the steps below to navigate to the Change Management Console:

Step Action 1 From the Overview Console click on the Change Management link under the

Consoles Navigation bar . Result: The Change Management Console displays:



Accessing & Navigating the Change Management Console, Continued

Change Management Console Header

Area Description

Manager Console

The primary interface for change managers, providing quick access to the information you need and to the procedures that you perform most often. Note: Available to the Service Management Office (SMO) only.

Support Console

The primary interface for support staff, especially change coordinators, providing a dedicated workspace for working on change requests. It provides quick access to the information and procedures that you need daily, so you do not need to open consoles. It highlights the most important details associated with changes requests, for example, tasks associated with changes, work information, and important broadcasts.

Closes the Change Management Console and returns you to the Overview Console.

Access the Help functionality within Remedy.

Navigation Pane The Navigation Pane within the Change Management Console provides you with quick access to

additional functions and search options to support the information displayed.

Navigation Pane – Change Counts

Area Description



Change Counts Display’s the number of Open, Unassigned, Unacknowledged, and Breached incidents for the Company. and View By. fields.


Area Description

Defined Searches This area provides a place from which you can run a series of predefined searches. You also have the ability to define custom searches using Manage My Searches.

Manage My Searches

Defines, edits, saves, and deletes custom searches. Saved custom searches appear in the My Searches area of the Defined Searches list.

Watch List Opens the Watch List. Use the Watch List to track a Change record through its lifecycle, even if it is assigned to a group that you do not belong to. Once you add a Change record to the Watch List it will stay there until you remove it



Accessing & Navigating the Change Management Console, Continued


Area Description

New Change Create a new Change Request record.

Search Change Search the database for current change request records.

My Profile Set your profile.

Application Preferences.

Set your application preferences and application options.

Reminders. View and create reminders.

Reports. Create and run custom reports.

Flashboard Provides a simple dashboard style report.

Surveys. Review and respond to customer surveys.

Process Overview Opens the detailed Change and Release Management process.


Area Description

Manage CI’s Search for information about specific CI types and gives you access to the CI records.

Manage Inventory

Not currently in use at Monash University.

View Calendar Opens the calendar function.

Time Segments Search, select or create the following time segments:

Create Business Event

Modify Business Event

Create Op. Category Location

Modify Op. Category Location

Configuration Item (CI)

Atrium Impact Simulator

Opens Impact Simulator.


Use the Consoles field within the Navigation Pane to access additional consoles such as Problem and Incident Management. Refer to topic Remedy Console Access on page 16 for full details of Consoles.


Accessing and Navigating the Change Management Screen

Introduction The Change form is used to request a change and track the progress from the Initiate stage to

the Closed stage. This form also shows the impact that the change has to the organization. The Change form is used to relate tasks to different support groups, and allows you to relate the change to configuration items that are being modified.

Raising a new Change Request

Complete the action below to open a new Change Request form:

Step Action

1 From the Change Management Console click on:

The create icon or,

New Change under the Functions navigation Result: A new Change Management Request displays with defaulted information within it:



Accessing and Navigating the Change Management Screen, Continued

Parts & Functions

The following tables explain the different parts and functions within the Change Management screen:

Change Management Header

The Change Management header identifies the current mode that Remedy is in and allows you to action searches or new requests quickly.


The Process Flow Status bar highlights the milestones within the process and steps you through the Production Change and Release Management lifecycle from Identification and Recording to Closure. The current stage that the Incident is in highlights in green for easy identification.

Navigation Pane The Navigation Pane within the Change Request screen provides you with quick access to

additional functions that support the Production Change and Release Management process. Note: Not all functions are currently in use at Monash University


Area Description

Impact Simulator Opens the Impact Simulator.

Select Operational

Opens the Operational Catalog Listing dialog box. You can search for an operational categorization to fill the Operational Categorization fields of the change (in the Classification tab).

Select Product Opens the Product Selection dialog box. You can search for a product categorization to fill the Product Categorization fields of the change (in the Classification tab).

Requested For Specify who has requested the change by adding in customer details

View Calendar Opens the Change Calendar. For information, see “Using the Change Calendar” on page 153.

Navigation Pane – Links

Area Description

Categorisations View the Op Cat and Prod Cat and change as necessary

Impacted Areas Mandatory field ‐ List and view the business areas that are impacted by the Change.

Financials Not currently used at Monash University




Navigation Pane – Functions

Area Description

Copy Change Activated only in Modify mode. For information, see “Copying” change requests” on page 343.

Email System Sends an email to relevant or associated parties with information regarding the request for change.


Area Description

Advanced Search Provides options in which to do advanced searching for Change records. This will open a new tab of Remedy in Search mode.

Service Management Office Only

Modify Business Events

Modify Op. Category Location

Time Segments

Suppress Request Creation

Remedy will block a Service Request from being generated from the request for change.

Navigation Pane – Create Other Requests

Area Description

Create Incident Incident form appears. The relevant details from the change are copied to the incident

Create Problem Problem form appears. The relevant details from the change are copied to the problem.

Create Known Error

Known Error form appears. The relevant details from the change are copied to the known error.

Create Release Release form appears. The relevant details from the change are copied to the release.


Use the Consoles field within the Navigation Pane to access additional consoles such as Problem and Change Management. Refer to topic Remedy Console Access on page 16 for full details of Consoles.




Change Details ‐ Coordinator


Change ID Displays the Change ID number which is automatically generated when the request for change record is saved.

Coordinator Group

Displays support group associated with the change coordinator creating the request for change (automatically defaults)

Change Coordinator

Automatically defaults to the support analyst creating the request for change. This can be change by clearing the field and entering another user.

Change Location

Displays the location associated with the change coordinator (automatically defaults)

Change Details ‐ Description


Service Displays the Incident ID number which is automatically generated when a customer name is entered.

Template Select the required Template for the request for change by placing the cursor in the field and hitting enter. A list of templates available to your support group will display.

Summary Free text field to enter a brief description about the request for Change. This is a mandatory field and is required to be completed when creating the record. Note: This field is limited to 128 characters.

Notes Free text field to enter additional details about the request for Change with unlimited character functionality. Hint: You can cut and paste information directly into this field.




Change Details ‐ Type


Change Type Defaults to Change and should remain so when raising a Change Request. Change to Release if appropriate.

Class Defaults to Normal. You can select the Class of change from the drop down list. Note: Do not use Latent or No Impact

Change Reason

Select the reason for the change from the drop down list.

Target Date Enter a target date for follow up or completion if required.

Impact Defaults to 4‐Minor/Localised. You can change the Impact by selecting from the drop down list.

Urgency Select the Customer Urgency level from the drop down list. Note: This defaults to low and should be left at low.

Priority Select the IT Priority from the drop down list.

Risk Level Defaults to 5‐Insignificant. Risk level is determined by a number of factors including Urgency, Priority and Risk Questions.

Monash Category

Defaults based on information entered into Impact and Risk. Will appear once the record has been saved.

Risk Scales displays a list of questions which are required to be answered in order to assist in determining the Risk Level.




Work Detail

Field Description

Status Displays the current status of the request for change.

Status Reason Displays the status reason once the status moves to Implement.

Manager Group Select the Service Management Office from the drop down list.

Change Manager Change Managers available within the Service Management Office are available within the drop down list.

Approval Table

The following buttons in the Change form are applicable to Approvers:

View Notifications Not currently in use at Monash University

Add Creates a new individual or group to approve the change

Approve Enables either a change manager or change coordinator to approve the change on behalf of the selected approver, if they are defined as alternates

Reject Enables either a change manager or change coordinator to reject the change on behalf of the selected approver, if they are defined as alternates




Tasks


Preferences Set your preferences within the Task tab for individual table views.

Refresh Refresh the table views within the Task tab.

Request Type Select the type of Task you want to create from the drop down list.

Relate Relate the type of task you are creating to the record.




Relationships


Show Related Drop Down Filter the Relationships displayed using the drop down list










Date/System

Field Description

Date Information

Scheduled Start Date+ Mandatory field ‐ Enter the date and time the request for change is scheduled to begin

Scheduled End Date+ Mandatory field ‐ Enter the date and time the request for change is scheduled to end

Actual Start Date+ Mandatory field ‐ Enter the date and time the request for change actually began

Actual End Date+ Mandatory field ‐ Enter the date and time the request for change actually ended

Completed Date Defaults with the completed date and time stamp once the request is completed.

Earliest Start Date Defaults with the lead time based on the Monash Change Category

Requested Start Date+ Required to be entered if the business has requested a start date.

Requested End Date+ Required to be entered if the business has requested an end date

Timing Reason If the scheduled start date is earlier than the earliest start date, the change is required to be expedited and you will be required to select a reason from the drop down list.

Time Spent Resolving Change Request – not currently in use at Monash University

System Information

Submitter Displays the Authcate of the user who submitted the request

Submit Date Displays the date and time the request was submitted


Raising a request for Change

Overview The Change form is used to request a change and track the progress from the Initiate stage to

the Closed stage. This form also shows the impact that the change has to the organization. The Change form is used to relate tasks to different support groups, and allows you to relate the change to configuration items that are being modified.

Background In most instances a Request for Change (RFC) is derived from a request for IT work in the form

of an Incident or Service Request and logged within Remedy. The request is analysed and assigned to the appropriate support group responsible for providing/managing the service who will then determine the feasibility of the request and assign a Change Owner.

Before you begin

Ensure you have navigated to and opened a new Change Management request as detailed on page 90 – Raising a new Change Request.

Raising a Request for Change (RFC)

Follow the steps below to create a new Change Request:

Step Action

1 Within the Change Management screen, ensure the following information has defaulted: Note: These fields can be changed if required.

Field Defaulted to

Coordinator Group Your support group – multiple groups that can be changed

Change Coordinator Your name

Change Location Your location

Change Type Change

Class Normal

Impact 4‐Minor/Localized

Urgency 4‐Low

Priority Low

Risk Level 5‐Insignificant

2 Select a Service that is being impacted by the Change Request from the drop down list.

3 Enter a brief description of the Change Request on the Summary field.


4 Enter notes regarding the Change Request in the Notes field. You can also copy and paste information into this field.


5 Select a Change Reason from the drop down list. (not mandatory)



Raising a request for Change, Continued

Creating a Change Request ‐ Continued

6 Are the Impact and Urgency fields correct?

If.. Then..

Yes Continue to step

No Select the appropriate Impact level from the drop down list

Select the appropriate Urgency level from the drop down list Note: The Priority field will reflect the changes to Impact and Urgency immediately.

7 Determine the Risk Level by clicking on and answering the Risk Assessment Questions. Note: Risk level will update once you save the record.

8 Click on Select Operational to display and select the relevant Operational Categorization.

9 Click on Select Product to display and select the relevant Product impacted.

10 Click on Links > Impacted Areas to record the areas that will be impacted by the change. Tip: Within this field select Company followed by Site.

10 Click on Save Result: The request for Change saves in Draft mode and defaults the Manager Group to SMO and Change Manager to Tony Minutolo.


Raising a request for Change – Work Detail

Overview Throughout the lifecycle of a Request for Change you will be required to update the record with

Work Information Entries. As part of the Production Change Management process at Monash University, several Work Information Entries have been identified as mandatory and will be required to be entered against the record in order for the request to be approved. These include:

Business Justification

Install Plan

Test Plan

Back Out Plan

Communications Plan (General Information)

Adding Work Detail to a Change Request

Follow the steps below to add Work Details to a Request for Change Record: Note: For each of the areas listed above you will be required to create separate Work Info entries for each one.

Step Action

1 Within the Work Detail tab, click on the Create icon. Result: The Change Work Info displays

2 Select the relevant Work Info Type from the drop down list. Ensure you create a separate Work Info entry for each of the following:

Business Justification

Install Plan

Test Plan

Back Out Plan

Communications Plan (Select General Information as the Work Info Type)



Raising a request for Change – Work Detail, Continued

Adding Work Detail to a Request for Change Record

Step Action

3 Enter a brief description of the Change Work Info in the Summary field. Note: When creating an entry for Communications Plan, ensure you enter “Communications Plan” within this field. Note: This field is limited to 128 characters.

4 Enter details in the Notes field to support the Work Information. Hint: You can cut and paste information directly into this field.

5 Attaching documents to the Work Info entry?

If.. Then..

Yes Click on the Add button

Browse for and select the required document and click on OK


6 Ensure the Locked field has defaulted to No. This ensures that the Work Info can be modified at a later date if required.

7 Choose the type of view access:

Public: This allows the customer to see the work information entry.

Internal: The customer will not be able to see the work information entry.

8 Click on Save Result: The Work Info entry will now be saved against the Incident record.

9 Repeat the steps 1‐8 to create additional Work Info Entries.

Work Details where the Change is a Release

Where a Change type is a Release, then a Release Plan is required to be added as an additional Work Info Entry. Follow the steps above to add the additional Work Info Entry. Note: When creating an entry for Release Plan, ensure you select General Information as the Work Info Type and enter “Release Plan” within the Summary field.


Raising a Request for Change - Tasks

Overview In the Implement stage of the Request for Change process, the change coordinator reviews all

the tasks that are needed to complete the request. Generally, change requests are divided into smaller units, called tasks. These tasks are then assigned to task implementers who complete them A single change can have an unlimited number of tasks, which display within the Tasks tab.

Relating Tasks to a Request for Change

Follow the steps below to add Tasks to a Request for Change Record:

Step Action

1 Within an open Request for Change record, navigate to the Tasks tab.

2 In the Request Type field, select Ad hoc from the drop down list, and then click Relate. Result: The Task form displays with certain fields populated from the change request.

3 Complete the following required fields:

Name—Enter a descriptive name of the task.

Summary—Enter a brief description of the task. Note: The Type field defaults to Manual when you create an ad hoc task.

4 Within the General tab:

The Company field defaults to the details of the Change Location field.

If the task is to be assigned to a different department or company fill in the relevant information.

5 Within the Requester tab:

Requester information automatically defaults to the person creating the task.

Requested For ‐ enter details about the person who is the intended target for the task

6 Within the Classification tab – complete the following fields:

Product Categorization

Operational Categorization.



Raising a Request for Change - Tasks, Continued

Relating Tasks to a Request for Change ‐ Continued

Step Action

7 Within the Assignment/Dates tab – complete the following fields to assign the task:

Assignee Group: Select a task implementer group from the list.

Assignee: Optionally, select a task implementer from the list.

Scheduled Start Date: Enter an estimated start date.

Scheduled End Date: Enter an estimated end date. Tip: You may want to set the Start Date and End Date to be different from the dates of the parent change request.

8 Within the Relationships tab – if required, search for and then relate configuration items, LDAP objects, and software library items that are needed with this task.

9 Click Save.


Raising a request for Change – Relationship Detail

Overview Typically, change requests occur because a CI needs to be upgraded (such as an operating

system) or needs repair (such as a server). Using BMC Remedy Change Management, you can relate unavailable CIs (also known as outage records) to their related change request. By relating an unavailable CI record to a change request, you can track its history, and the costs related to changes to the CI.

Adding Relationship details to a Change request

Follow these steps to add Relationship details to the Change request: Note: In these steps a Configuration Item is related to the Incident.

Step Action

1 From the Request Type drop down list select Configuration Item

2 Click on Search Result: The CI Relationships Search screen displays:

3 Enter the relevant CI information or Product Categorization information and click on Search. Result: Remedy returns all relevant CI’s

4 Highlight the appropriate CI within the table

5 Click on the Relationship Type drop down and select “Related to”

6 Click . Result: Remedy provides an information message that the CI has been successfully related to the Incident.


Raising a request for Change-Relating Unavailability

Process Steps Follow these steps to relate Unavailability to a request for Change:

Step Action

1 Open a change request, and then click Relationships tab. The Relationships tab shows the requests that you can relate to the change.

2 From the Request Type field, select Configuration Item, and then click Search.

3 On the CI Relationships Search form, complete the search criteria tabs with the relevant information, and then click Search.

4 In the Relationship Type field, select the type to relate with the change request, for example, Related to.

5 Click Relate with Unavailability.

6 Enter the unavailability settings (for example, Scheduled Full and the scheduled start and end dates), and then click Save.

7 Close the CI Relationships Search dialog box.


Progressing a request for Change

Overview The Process Flow Status bar on the Change form steps you through the change process from the

Initiate stage to the Closed stage. It provides a visual mechanism to track the five stages of a change request, as indicated by best practices in ITIL processes.

Process Flow The Process Flow Status bar guides you through the stages of the change life cycle from stage to

stage. To advance through the change request, click the process flow accelerators as shown below:

At each stage, the status bar provides accelerators applicable to the current stage. For example, you can use accelerators to move the request to a Pending status, cancel it, or forward it to the next stage. By using the process flow accelerators, you are following ITIL best practices. When you select an accelerator, you might be prompted to enter the data required to complete the stage. For example, when you are in the Plan & Schedule stage you are prompted to enter the required start and end date of the change request and its tasks.



Progressing a request for Change, Continued

Steps Step Action

1 From the Process Flow Status bar, click on the drop down arrow from the current stage to display the list of options available to move the request for change through the various stages. Refer to example below:

2 Click on Next Stage Result: Remedy will prompt you for any additional information required in order to progress to the next stage; such as:

Requested Start Date

Change Manager

3 Complete any required fields identified.

4 Click on Save Result: The request for change moves onto the next stage and updates the status as appropriate.


Searching for an existing request for Change

Overview You can search for request for change records from the Change Management console, via:

Predefined searches,

Create and save your own custom searches using advanced qualifications

Search all of the records using the Search Change form, or

Search using a request for change (CHQ) number.

Searching on a specific INC number

Each time a request for change is created it automatically generates a change or CHQ number. This number is specific to the request for change and can be used as a reference for searching.

Steps Follow the steps below to search for a specific request for change using a CHG number:

Step Action

1 From the Change Management console Navigation pane navigate to:

Functions Search Change. Result: The request for Change form appears in Search Mode

2 In the Change ID field enter in the CHG number Example: CHQ000000000049


3 Press Enter. Result: The specific request for change will display in Modify mode.


Searching for a request for Change – Defined Searches

Defined Searches

The Defined Searches area of the Navigation pane contains a series of predefined searches that you can use to look for request for change records. For example: Use a predefined search to locate all Assigned Change rolls such as Closed Changes. The predefined search function searches records that are associated with you through your Authcate or Support Group ID.

Searching for an Incident using Defined Searches

Follow the steps below to search for a request for change using Defined Searches:

Step Action

1 Ensure the Company and View By fields in the Change Management console area are pointing to the appropriate company and support group.

2 From the Change Management Console, navigate to the Defined Searches area of the Navigation Pane.

3 Open the search category that corresponds to the search you want to run and then select a specific search option.


Updating/Modifying a Change Request

Overview To update request for change, open the change record and then update the details as required.

Click save when you finish.

Before you begin

Refer to Creating a new request for Change – Work Detail page 112

Adding additional Work Info Entries

When updating a request for change you can create additional Work Info entries to detail additional information or steps and work undertaken as part of the Change process.

Modifying existing Work Info Entries

If the work information entry is not locked, you can modify any field on it. The following steps describe how to modify the notes, add attachments, lock the entry so it cannot be modified later, and change the viewing access level.

Step Action

1 From the Change Management console, select the Change request record and navigate to the Work Info tab.

2 From the list of work information entries, select the work information record that you want to update.

3 Click View

4 Make the required modification:

If Then

You want to update the note

Click inside the Notes field and type the changes

You want to add an attachment

Right‐click in the attachment table and select Add from the menu that appears then follow the on screen instructions. Note: Attachments to work information entries are only available from within the specific Incident.

To lock the entry From the Locked list, select Yes or No. Note: If you select Yes, the work information entry cannot be modified after you save it.

To change the view access level

From the View Access list, select: Internal or Public from the View Access list.

Internal: if you do not want the customer to see the work information entry.

Public: if you want the customer to see the work information entry.


Asset and Configuration Item

Overview

Introduction Asset Management is the Process responsible for tracking and reporting the value and

ownership of financial Assets throughout their Lifecycle. Asset Management is part of an overall Service Asset and Configuration Management Process (SACM).


Topic See Page

Asset and Configuration Item Introduction 122

Procedure Workflows 126

Asset Record Overview 127

Updating Asset/Attributes/Status 131

Relating a Person to a CI 133

Updating Asset Location Details 135

Process Overviews for Asset Management 136


Asset and Configuration Item Introduction

Objective Monash specific objective: Identify, control, record, report, audit and verify ICT assets

Goals To define and control the components of services and infrastructure and maintain accurate

configuration information on the historical, planned and current state of the services and infrastructure. This optimises the performance of service assets and configurations, improves the overall service performance and optimises the costs and risks caused by poorly managed assets e.g. service outages, fines, correct licence fees and failed audits.


The following roles and responsibilities have been identified to support the Service Asset Management processes at Monash University;

Role Responsibility

Service Asset and Configuration Management Process Owner

Overall authority and responsibility for the process metrics, policies and procedures. Creates and reviews reports that pertain to the performance of the actual process.

Approver Decides whether to approve or reject requests for the acquisition of new CIs.

Asset/Configuration Manager

Responsible for the overall quality and integrity of the Configuration/Asset Management processes and the CMDB ITSM tasks include:

Determining scope, depth and breadth of CMDB

Planning and scheduling CMDB Audits

Creating and reviewing operational reports

Comparing CI records to physical CIs

Producing exception reports

Creating Incident or Change records to address exceptions

Responsible for conducting periodic audits of the CMDB



Asset and Configuration Item Introduction, Continued


Role Responsibility

Asset/Configuration Coordinator

Submits purchase requisitions after this has been requested by Change Management. Informs purchasing after ordered CIs have been delivered in good condition. Ensures that CIs get labelled after they have been delivered. Ensures that the information of the CIs is kept up to date. Maintains the information of external organizations that supply, or support, CIs for which the group of the configuration administrator is responsible. Registers and updates the contracts and license certificates for the CIs for which the configuration administrator's group is responsible. Maintains the links of the CIs that the configuration administrator's group is responsible for. These are the links between a CI and other CIs, its supplier, its contracts, and the service infrastructures that it is a part of.

Purchasing Agent Obtains quotes from suppliers for CIs which acquisition has been requested Requests approval for ordering CIs after the quotes have been collected. Submits purchase orders for CIs which acquisition has been approved. Updates purchase line items after configuration administrators have confirmed the receipt of CIs for which purchase orders were submitted.




Purpose The following figure shows the ICT Asset Management Process and the ICT Asset Lifecycle. This

document refers to segments of the inner circle, the ICT Asset Management Lifecycle stages and the procedures within them.

Purpose The following figure shows the ICT Asset Management Process and the ICT Asset Lifecycle. This

document refers to segments of the inner circle, the ICT Asset Management Lifecycle stages and the procedures within them.

Figure 1 Asset Management Process/ Procedures

The ICT Asset Management Lifecycle focuses on tracking the status and attributes of ICT assets and tracking any changes made to them. The following table shows the ICT Asset Management Procedures within the different lifecycle stages.

Procurement Process

Request: The Request procedure is used when a Monash person requires an asset, a service request is raised, approved, checked against the Monash standard equipment list and assigned to IT Support for deployment if inventory exists or purchasing for procurement. Purchase Order Creation: This procedure involves Purchasing performing budget checks, raising a purchase order. Receipting: The receipting procedure is used when an ICT asset is received by Monash from a vendor, this procedure involves checking the asset against the purchase order, attaching Monash identifiers and updating the asset record and creating an asset record within the CMDB (Configuration Management Database). Software – New/Modify Licence Certificate: This procedure ensures that when a new software contract, certificate or license is required it is tracked in the CMDB which allows software compliance checks and harvesting to be run.




Deploy Process Deploy:

The Deploy procedure is used to deploy all Monash ICT assets, this procedure ensures any changes to the asset are tracked within the CMDB. Software – Deploy: The software Deploy procedure ensures that software deployed on Monash machines is tracked within the CMBD and is compliant with the software contracts/ certificates.

Validate Process

Stock‐Take: The Stock‐Take procedure is used, primarily, for the annual SAP asset audit. A list of assets to be audited will be sent to the asset manager who will be responsible for ensuring all ICT assets are audited, either by discovery or manual stock take. Software Compliance/ Harvest: The Software – Compliance/ Harvest procedure allows software which is not frequently used to be harvested and ensures that software contract/ certificates are compliant. Unrecorded Asset Exception: The Unrecorded Asset Exception procedure is used when a Monash ICT asset is identified which cannot be found in the CMDB. This procedure ensures that the asset record is created or updated to accurately reflect the physical asset.

Maintain No asset management procedures exist within this stage. Asset maintenance is covered by

procedures from the Incident, request and change processes.

Support Reuse/ Harvest

The Reuse/ Harvest procedure is used when an asset is no longer required by the user or reaches end of life. This procedure involves removing any sensitive data / software and preparing the asset for return to inventory or disposal.

Retire Decommissioning:

The Decommissioning procedure ensures that Monash ICT assets are properly prepared for disposal and are disposed of appropriately.


Procedure Workflows

Asset Lifecycle Management Overview

The following diagram shows how the different stages of the Asset Life Cycle linked:

Asset Lifecycle Management procedures

The following diagram shows the flow of the Asset Lifecycle Management procedures. While many of the procedures may be initiated at different points in the asset lifecycle, the typical flow is shown below:

1Request/

Procurement

5Retire

2Deploy

3Validate/ Verify

4Support/ Maintain


Asset Record Overview

Overview This section details the areas of the asset/ CI record which will be updated through the asset

lifecycle.

CI Information

Field Name Description

CI ID A unique identifier for this asset record

Tag Number The Tag number refers to the Monash identification tag on the asset. (usually the EQ sticker)

Serial Number The Serial Number of the Asset

Part Number The Part Number of the asset, usually near the serial number tag of the asset

Supported Is this asset supported by the Service Centre?

Company The Monash Faculty or Office this asset belongs to.

Primary Capability The primary role/ capability of this asset.

Status/ Status Reason

The current lifecycle status and reason of this asset. Refer to the status/ status reason table for more information

Impact The impact this asset would have on a service if it went down

Urgency The urgency if the asset is down

Priority The priority of the incident to restore this asset

Users Affected The number of users affected if this asset were to go down

Additional Information

Any additional information on this asset



Asset Record Overview, Continued

General Attributes

The general tab is used to categorize CIs and specify location and lifecycle information:


Product Categorization

Product Categorization Tiers

The 3 tiers of the assets product category

Product Name The product name of the asset. This field links to additional product information

Model/ Version The Model Number or Version of the Asset. Select from the drop down list if available

Manufacturer If the manufacturer is not automatically populated then enter the manufacturer of the asset

Supplier Name The supplier/ Vendor for this asset

Location

Region Region/ Country

Site Group Campus

Site Building

Floor Floor

Room Room

Lifecycle

Received Date The date the asset was first installed

Installation Date The date the asset becomes available for use

Available Date The date the

Return Date

Disposal Date The date of the last time the asset was seen by the network discovery

Last Scan Date




Specifications Tab

The attributes stored in the Specifications tab is determined by the CI Type of the asset, this tab contains technical specifications of the asset

People Tab The people tab is used to associate people with assets, such as the user of the asset


Full Name The full name of the person or Support group related to this asset

Role The role of the person related to the asset

Type the type of record this CI is related to (People, People Organisation, or Support Group)

Primary Contact Is this person the primary contact for this asset?

Access Permitted Does this person have access to this asset record?




Relationship Details

The relationship details tab shows the relationship with other CIs, this tab is used for viewing technical information about the sub components of the asset.

Financials Tab The financial tab is traditionally used to store the costs associated with owning the asset,

however, Monash is only using a few of these fields as shown below.


Ownership Type The ownership type of the asset, this is where an asset is flagged as internally leased.

Purchase Date The date the purchase order for this asset was raised

Over $5k? The ‘Over $5k’ checkbox is used to flag assets which are included in the SAP system as financial assets. Checking this box will include the asset in certain financial reports


Updating Asset/Attributes/Status

Overview Used to track the stage the asset is at within it’s lifecycle and is required to be updated inline

with the ICT Asset Lifecycle Procedures.

Access the Asset Record

Follow the steps below to access an Asset Record:

Step Action

1 Open the Asset record as follows:

If accessing the asset record through the Service Request/ Incident Record,

then click on the ‘CI+’ field label

the asset management console, search for the appropriate asset using the advanced filter fields. Open the asset record by clicking ‘View’

2 Result: The Asset screen displays

3 Update the ‘Status’ of the asset by selecting the appropriate status from the drop down list

4 If applicable, select a ‘Status Reason’ from the drop down list

5 Update the required fields in each of the attribute tabs

6 Click ‘Save’



Updating Asset/Attributes/Status, Continued

Update Asset Status

To update the ‘Status’ of an asset, select the appropriate status from the drop down list (Refer to the Appendix for a full list of Statuses)

Note: If applicable, select a ‘Status Reason’ from the drop down list


Relating a Person to a CI

Steps To update the people related to an asset follow the steps below:

Step Action

1 Select the ‘People’ tab and click Add

2 Choose if the person in question is the primary contact for the asset

3 Click ‘OK’

4 Enter the appropriate search criteria and click ‘Search’

5 Select the person and click ‘Select’



Relating a Person to a CI, Continued

Step Continued Step Action

6 Select the Role (Used By) of the person relating to this asset, Click ‘OK’

7 Remove any old relationships which no longer apply by selecting them and clicking ‘Remove’

8 Click ‘Yes’ when prompted ‘Are you sure?’

9 Click ‘Save’


Updating Asset Location Details

Overview Whenever an asset is moved or deployed it is important to update the location details within

the asset record.

Asset Location Updates Steps

Follow the steps below to update the location of the asset:

Step Action

1 Navigate to Location within the General Tab of the Asset screen

2 Using the drop down options select the following:

Region

Site Group (Campus)

Site (Building)

Floor (number or single letter)

Room (full room number, eg. “G35”)

3 Click on Save


Process Overviews for Asset Management

Overview A single service request exists for the entire ICT Asset request to deploy process

Throughout this process updates to service requests are made via adding a work detail each time an update is made to request ie. Purchase order is raised and therefore standard steps should be taken to update a Service Request with Work Info Entries as required.

Rejecting a request

When it is required that a request is rejected, a standard Work Info Entry is to be completed detailing why you are rejecting the request. Ensure you complete the following:

Update the Status of the asset to ‘Cancelled’ from the drop down list

Click ‘Save’ to save the changes to the Service Request/ Incident.

Attaching Support Documentation to the Request

Where you are required to attach supporting documentation to a request, a standard Work Info Entry is to be completed including the attachment. Ensure you complete the following:

If required, update the ‘Status’ and ‘Status Reason’ of the Service Request/ Incident

Click ‘Save’ to save the changes to the Service Request/ Incident


Advanced Functions

Overview

Introduction Remedy has many variables and functionalities available to users, some which are used on a

daily basis and some that is used less frequently. To try and capture some of those less frequently used functions, an Advanced Function section has been included to support ongoing training and development.


Topic See Page

Advanced Incident Functions 138

Advanced Asset Management Functions 141

Advanced Service Level Management Functions 146

Dashboards & Reporting 149


Advanced Incident Functions

Adding Work Info Entries via the Incident Table

Follow the steps below to add work information entries from the Incidents table:

Step Action

1 From the Incident Management console, select the incident request record

2 At the bottom of the Incident Management console, if the Tasks table is visible, open the Incident Detail area by clicking Show Incident Detail.

3 Click Create

4 Enter the work information details in the Incident Work Info dialog box.

5 To add an attachment to the record, right‐click in the attachment table and select Add from the menu that appears.

6 Choose whether to lock the work log. Note: If you select Yes, you cannot modify the work log after you save it.

Choose the type of view access:

Internal: Choose this if you do not want the customer to see the work information entry.

Public: Choose this if you want the customer to see the work information entry.

Click Save.



Advanced Incident Functions, Continued

Creating Relationship Details within Incidents

By defining and maintaining relationships among records, you can create an overview of the connections and interdependencies among the current record and additional service issues. An incident can be related to any of the following record types:

Configuration item

Another incident

Known error

Problem investigation

CI unavailability

Request for Change

Release

Before you begin

Ensure you are within either a new or existing Incident and have navigated to the Relationships tab.

Adding Relationship Details to an Incident

Follow these steps to add Relationship details to the incident: Note: In these steps a Configuration Item is related to the Incident.

Step Action

1 From the Request Type drop down list select Configuration Item

2 Click on Search Result: The CI Relationships Search screen displays:

3 Enter the relevant CI information or Product Categorization information and click on Search. Result: Remedy returns all relevant CI’s

4 Highlight the appropriate CI within the table

5 Click on the Relationship Type drop down and select “Related to”

6 Click . Result: Remedy provides an information message that the CI has been successfully related to the Incident.



Advanced Incident Functions, Continued

Moving Resolved Incidents back to In Progress

Use the following procedure to move an incident request record with a status of Resolved back to the In Progress status. You do this if the reported resolution did not resolve the incident request, and further work is needed.

Step Action

1 Search for and retrieve an existing resolved incident.

2 Open the resolved incident in Modify mode.

3 In the Status field, select In Progress.

4 Click Save Result: The incident moves back to the Resolution and Recovery stage and the status changes from Resolved to In Progress.

Searching for an existing Incident Custom Search

The custom search functionality allows you to define and save custom searches based on criteria you select. After you save the custom search, it appears in the My Searches area of the Defined Searches list. NOTE: The My Searches option only appears after a custom search is defined and saved.

Step Action

1 In the Defined Searches section of the Navigation pane, click Manage My Searches.

2 In the Search Name field, enter a name for the search.

3 Click Build Search Qualification to open the Advanced Qualification Builder dialog box, and then define the search qualification.

4 From the Keywords or Fields selection boxes, select the keywords or record fields on which you want to search.

5 To insert operators (+, =, >, <, and so on), click the appropriate operator button. Do not forget to place literal values between double quotation marks. For example: Search for incident requests that meet the following criteria:

Impact => 2‐Significant/Large or 1‐Extensive/Widespread

Service = Payroll Service

the Last Resolved Date >= 07/19/2008 (‘Impact’ = “2‐Significant/Large” OR ‘Impact’ = ”1‐Extensive/Widespread”) AND ‘Service’ =“Payroll Service” AND ‘Last Resolved Date’ >= “07/19/2008”

6 Click Select to close the Advanced Qualification Builder, and then click Save.

7 Close the Manage My Searches dialog box. The search appears in the Defined Searches list, under My Searches. NOTE: The My Searches node appears only when a custom search is defined.


Advanced Asset Management Functions

Check Inventory Part of the request procedure IT Support will check the ICT Asset inventory for a suitable asset

rather than raise a purchase order

Step Action

1 Within the Remedy Asset Management Console, under the defined searches navigation bar, select ‘By Computer by Status’, then select ‘In Inventory

2 Use the advanced filter section to filter the inventory items to the product required

3 If there are no results, then the selected asset is not available in inventory

4 If required, view additional detail of an asset in the Configuration Items list by

selecting the record and clicking ‘View’

Click ‘Close’ to return to the configuration item list

5 If a suitable asset is found, then Inventory does exist, take note of the CI name to allow the CI to be referenced in future steps



Advanced Asset Management Functions, Continued

Checking for Available Software Licences

If you get a request to install then they can check to see if there is enough current licences:

Step Action

1 Open the Software Asset Management Contract Console

2 Select the license certificate to be checked, and click ‘View Certificate’

3 In the ‘Functions’ Navigation bar, click ‘Compliance Details’

4 Review the number of licenses purchased and number of licenses deployed fields

5 If the ‘number of licenses deployed’ + the number of licenses to be deployed as part of the service request exceeds the ‘Number of licenses purchased’ then the required number of spare licenses do not exist

Otherwise, spare licenses do exist




Add/Remove Links to Related CI’s

CI’s or Assets may be dependent on other CI’s, recording these links allows other users to see

the impact of any updates they make to other CI’s.

Step Action

1 Within BMC Remedy, open the Asset record Note: If accessing the asset record through the Service Request/ Incident Record, then click on the ‘CI+’ field label. Otherwise, within the asset management console, search for the appropriate asset using the advanced filter fields. Open the asset record by selecting the required CI and clicking ‘View.

2 Select the ‘Relationships’ tab

3 To remove a relationship, select the relationship to be removed and click ‘Remove’




Add/Remove Links to Related CI’s Continued

Step Action

4 To Add a relationship to another CI;

Under ‘Request Type’ select Asset record

Under ‘CI Type’ select the type of CI to be linked to

Click ‘Search’

Use the search fields identify the required CI, select the CI

Select the ‘Relationship Type’, and click ‘Create’

Select the type of relationship from the dropdown box, Click ‘OK’

5 Save and Close the asset record




Status Reason Update to Asset/CI Status – refer to the table below for detailed explanations.

Status Status Description Status Reason Status Reason Description

Received The item represented by the CI was received in shipping.

Received in Good Order

The asset was received in good order as per the Purchase Order

To Be Returned The asset was received but is to be returned to the vendor

Being Assembled The item is being assembled

Deployed The item has been deployed and is in use

Discoverable The asset is connected to the Monash and is auto discoverable

Off‐Line The Asset is not connected to the Monash network or is not discoverable

In Repair The item is down for maintenance

Down The item is down and not functioning

Scheduled The asset has been scheduled for repair

Maintenance The asset is down due to regular maintenance

Out of Service The asset is out of service and cannot be repaired

End of Life The item is no longer being deployed

Returned The asset has been returned to IT Support

Obsolete The asset is obsolete or no longer meets the minimum requirements

Extended Use Requested

The user of the asset has requested extended use of the asset

Transferred The item was Transferred to another location

Delete The CI is marked for deletion Obsolete The asset record is no longer required in the CMDB

In Inventory The item is in inventory but not yet deployed

New The asset has not been deployed

Used The asset has been deployed and returned to inventory

On Loan The item is on loan to another location

Ordered The item has been ordered but is not yet available

Disposed The item is no longer available and was disposed

Missing – Lost/ Stolen

The has been lost or stolen

Obsolete The asset has reached the end of its useful life

Damaged The asset has been damaged and is beyond repair



Advanced Service Level Management Functions

Incident Targets for Individual Incidents

SLA TARGET (for cumulative Incident performance over a period of time): Each Incident either does, or does not, meet its Response target. It is either a ‘hit’ or a ‘miss’. Similarly each Incident either does, or does not, meet its Resolution target. Each of these is a data point in calculating what percent of the time Incident targets are met. The SLA Target is the minimum level of successful Incidents, measured as a percent of the total. “Target at Risk” allows an early warning email to be sent (if desired) prior to the performance dropping down to the SLA Target. NOTE: An Incident will not be included in the SLA measurement until it is in “Closed” status. The reason for this is that although the clock stops when the Status is “Resolved”, an Incident that hasn’t reached “Closed” status could be reopened, which restarts the clock. SLA Targets and Target at Risk:

Incident Priority Target Target at Risk

Critical 90% 92%

High 90% 92%

Medium 90% 92%

Low 90% 92%



Advanced Service Level Management Functions, Continued

Email Notifications Related to Incidents/SLA’s

These are emails sent to designated people at defined points in the life cycle of an Incident. There can be multiple points in the life cycle of an Incident which trigger emails. What Triggers an SLA email notification, in an individual Incident? Emails are triggered at defined points in the life cycle of an Incident. These trigger points are expressed as a percentage of the Incident Target. For example: A target might be set that an Incident should be responded to within 2 hours. This means the Incident needs to be assigned to an individual and the Incident Status needs to be “In Progress” or beyond. If there is a Response milestone of 50% an email will be sent to the designated person 1 hour before the target time is reached, to remind them no Response has been provided to the Incident Customer. Email notification trigger points, for individual Incidents:

Incident Priority

Response 1 Response 2 Resolution 1 Resolution 2 Resolution 3

Critical 50% 100% 50% * 80% 100%

High 50% 100% 80% 100% ‐

Medium ‐ ‐ 100% ‐ ‐

Low ‐ ‐ 100% ‐ ‐

* This email is sent to the Assignee. Using a High Priority Incident as an example, an email is sent 15 minutes and 30 minutes after Incident creation, if the Incident has not met the Response criteria at those points in time. An email will be sent 3 hours 12 minutes (80% of 4 hours) and 4 hours after Incident creation, if it has not met the Resolution criteria at those points in time. What triggers an email notification, in an SLA? Using the Critical Incident SLA as an example, the aim is to achieve the Response and Resolution targets at least 90% of the time, during the review period. If the actual performance dips below 92% (target at risk) an email will be sent. If the actual performance dips below 90% (target) an email will be sent.

Incident Priority

Target Email sent? Target at Risk Email sent? Review Period

Critical 90% Yes 92% Yes Quarterly

High 90% No 92% Yes Monthly

Medium 90% No 92% Yes Monthly

Low 90% No 92% Yes Monthly

Who Receives Incident and SLA email notifications? All Incidents are assigned to a Support Group. Any person in that Support Group who has a Functional Role of “Incident Manager” assigned to their profile, will receive SLA emails notifications for that Support Group.



Advanced Service Level Management Functions, Continued

Pause the Clock Under specific conditions the measurement of achieving the Incident targets can be paused.

This may be legitimate when the Support Group Assignee is waiting for the Customer to answer a question or provide further information, vital to completing the Incident. This happens when:

a) Status = Pending

AND b) Status Reason is one of the following:

Hold Requested by Customer

Awaiting Customer Action

Awaiting Service Request Completion

Future Enhancement


Dashboards & Reporting

Overview Reporting and compliance checks within Remedy provide Monash University the opportunity to

effectively monitor and manage not only Service Level Agreements, but also overall use and compliance of information within the system. This in turn can impact both customer and staff satisfaction when dealing with IT at Monash. Remedy has standard KPI dashboards and Reporting functionalities available.

Viewing KPI Dashboards

Within the Incident and Problem consoles in Remedy, you can quickly and easily navigate to the KPI’s tab which displays a dashboard of target information.

Steps Follow the steps below to navigate to the KPI’s dashboard within the Incident Management

Console:

Step Action

1 From the Incident Management Console click on the KPI’s tab within the header

Result: The KPI dashboard displays:



Dashboards & Reporting, Continued

Steps Continued Step Action

2 Use the Navigation Pane within the dashboard to view various details in relation to Incidents recorded:

3 Once completed, navigate back to the Incident Management console by clicking on the Console tab.

Standard Reports

Remedy has approx 150 standard reports that are able to be extracted, printed and viewed at any time. You can access the Report function from any console within Remedy at anytime.

Steps Follow the steps below to search for and view reports:

Step Action

1 From your selected console (i.e. Incident Management) navigate to Functions > Reports within the Navigation Pane. Result: The Report Console displays is Search mode:



Dashboards & Reporting, Continued

Steps Continued Step Action

2 Select your desired report from the Report Name drop down list.

3 Enter any additional search information if required.

4 Select a file destination in which to save the report.

5 Select Run Report


Getting Help with Remedy

Post Go Live Support

From Monday October 18th for a period of 2 weeks, floor support will be provided each day within your immediate area, by a minimum of two project team members. Please feel comfortable to ask your floor support members any question in relation to Remedy as they are there to assist you and make your transition as smooth as possible. You will be able to identify your floor support member by the green t‐shirts they will be wearing.

Quick Reference Guides

Quick Reference Guides have been provided to each of you for a quick referral of frequently accessed information. These support the comprehensive training guide where you will be able to access more detailed information.

Remedy Online Help

You can access help from within Remedy at any time simply by clicking on the help icon

which is available within each screen.

Permissions within Remedy

If at anytime you feel you permissions or access is not correct within Remedy, please contact your line manager in the first instance to confirm your requirements. You can then follow up with an email to ICT Shared Services who will review your access accordingly.

remedy training guide level2 3

Documents

internalorpublicfrom

removethehighlightedrelationship

verifies structural

deletes custom

free text

specific ci

front line

problem management