Design Document (1.69Mb Word).doc.doc

Information & Communication Services

ANALYSIS REPORT

ITSMS Project – Phase 1

Release:Date: April 11, 2007

Author: Susan HallOwner: Tom MortimerClient: NIPB

Document Number:

paperid/yymm/cc/Vn.n

Document History

Document Location - The source of this document is on the University network in location:

Revision History

Revision date

Previous revision date

Summary of Changes Changes marked

First issue7 May 2007 26 April

2007Changed response time table as per Workshop feedback

DM

Approvals - This document requires the following approvals:

Name Signature Title Date of Issue

Version

Distribution - This document has been distributed to:

Name Title Date of Issue

Version

/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023

Information & Communication Services


Paper ITSMS Project

Purpose of Document

The purpose of this document is to present information or present proposals for approval which have been produced as a result of the Analysis stage of the ITSMS project. The recommendations in this document will contribute to the design of the solution.

Circulation of this document is for the ICS Management Team in the first instance. After the allowed consultation period comments and discussion will be incorporated into a final version of the document.

Action required: the ICS Management team are required to consider the recommendations in this document and approve / amend recommendations as appropriate.

R Approval (Y/N) Change Comments

1 Y

Knowledge Manager Operational coordination of Service RequestsOversee end-to-end process of creation of New Service Requests in conjunction with change managementThere will be a strong link between this role and the Change Manager

Clarify terminology on roles

2 Y

This role may be rotated within the unit Possible rotation

3 Superceded

R 1To support the Incident Management process all communications with the Incident Manager will be logged in Touchpaper.

4 Y The Incident Management Calendar will hold information about


Paper ITSMS Project

critical business times for the University e.g. Exam times and matriculation. The use of the calendar could be expanded for use in conjunction with other ITIL processes such as Change Management and Release Management in future phases of the implementation.

5 Y

Service Requests will be handled in the same way as Incidents under the Incident Management process, however these will be reported on separately as Service Requests are a normal part of the service and do not reflect interruptions or failures. Will handle both in the same way –

explain6 Y DMc**** Definition of Problem Manager role7 Y8 Y

9 Y ICS-LiaisonFurther work needed – Liaison Officer Role and check S3 relevance

10 Y Clarify linkage with User group types11 Y All privileges ICS-manager – all privileges12 Y Needs clarification13 Y should ‘should’14 Y15 Y MW/CR CMDB – next phase16 Y17 Y R 2 No inbound

email is planned within first implementation.

Add ‘User’ transition


Paper ITSMS Project

There will be a transition period of 3 months when emails will be accepted along with guidance on using the web portal. The portal must be intuitive, therefore the portal will be developed in conjunction with a user focus group.

18 Y

Assignment to 2nd level Your Incident no.??? has been assigned with the appropriate team. You should receive a response within ?? working hours. Please contact us via the ICS Service Portal with any further information or query regarding this Incident.

(Closure) Please contact us via the ICS Service Portal with any further information or query regarding this Incident otherwise this Incident will be automatically Closed after 10 working days. Clickable line on portal

19 Y

20 YManagers

21 Y Priority? Refer to group discussion22 Y Meet23 Y

24 Y EPInternal reports – review contracts – speak with JK


Paper ITSMS Project

25 Y26 Y Relevance of Service Catalogue27 Y28 Y29 Y Generic email

30 Y

Educate 2nd level Analysts on phone contact

Direct all ICS generic email to Service Desk – Phase 2

31 Y32 Y33 Y34 Y

35 Y

R 3 There will be a process for maintaining the Knowledgebase

36 Y37 Y38 Y39 Y40 Y

41 Y

R 4 Feedback will be requested from Users at the closure of all calls (optional) and at regular points in the calendar.

Option for feedback42 Y43 Y44 Y45 Y46 Y47 Y48 Y49 Y


Paper ITSMS Project

50 Y51 Y Resolution52 Y53 Y

54 Y DMSort out services and definition of response

55 Y

56 Y EP

eDirectory Data Table: change of Import fields from eDirectory to TP attributes (Appendix).

57 Y EP Incident Management roles table updated

58 EPIncident notes table update – added Responded column, changed Dept to School


Paper ITSMS Project

RecommendationR 1To support the Incident Management process all communications with the Incident Manager

will be logged in Touchpaper. 2R 2 No inbound email is planned within first implementation. There will be a transition period

of 3 months when emails will be accepted along with guidance on using the web portal. The portal must be intuitive, therefore the portal will be developed in conjunction with a user focus group. 3

R 3 There will be a process for maintaining the Knowledgebase 5R 4 Feedback will be requested from Users at the closure of all calls (optional) and at regular

points in the calendar. 5R 5 Incident Management roles will be established 12R 6All roles will have assigned lead and deputy lead or another member of their Unit/

department to reduce single points of failure. 15R 7To support the Incident Management process all communications with the Incident Manager

will be logged in Touchpaper. 15R 8To support the Incident Management Process an Incident Management calendar will be

established and maintained by the Incident Manager (within Touchpaper) 15R 9Standard definitions will be used for Incident Management 17R 10The flow of information between Incident Management and Problem Management will be

a joint responsibility between the Incident Manager and the Problem Manager. 17R 11The Problem Manager will be responsible for the coordination of problem solving

activities and will assess and recommend appropriate problem solving training for Incident Management staff. 18

R 12Where available, standard ICS templates will be used for documentation. 19R 13User types will be defined as described in User Types table. 19R 14Group types will be defined as described in Group Types table. 20R 15Roles and privileges will be defined as described in Roles and privileges table. 21R 16Integration will be required as described in eDirectory fields and rights section 21R 17Department support Analysts should be assigned Analyst rights within Touchpaper 22R 18To ensure consistency the department names require to be aligned with eDirectory and so

will be part of the import from eDirectory. 23R 19Locations for site and building will be held in Touchpaper 23R 20Guidance will be provided to all Incident Management staff on using Incident Management

notes. 23R 21No inbound email is planned within first implementation. There will be a transition period

of 3 months when emails will be accepted along with guidance on using the web portal. The portal must be intuitive, therefore the portal will be developed in conjunction with a user focus group. 24

R 22Standard templates will be used for sending Email to Users at fixed points within the Incident Management Process. 24

R 23No email to analyst on assignment of Incident to Unit/Service – local IM responsible for assignment to individual Analyst. 25

R 24The default View displayed to Analysts on connection to the Touchpaper Console will be the Console Welcome page. 25

R 25Incidents will be assigned to units according to ICS Service affected 26R 26Incident reporting will be carried out on a regular basis and presented to the Local Incident

Managers on a monthly basis. 27


Paper ITSMS Project

R 27During the Incident Management Lifecycle in addition to the standard actions, there will be optional actions. 27

R 28Touchpaper will record elapsed time between various Incident status points 27R 29All Incidents will have a call back response level, time available to be determined for each

Response Level. This will be built into the Incident process. 28R 30ICS require a clear definition of supported services including policy on areas unsupported.

28R 31The SPOC for ICS will be known as the Service Desk 30R 32The change of name from Helpdesk to Service Desk will be publicised to the User

community 30R 33The routes for Users contacting ICS will be the Service Desk via Web Portal, Phone and

Face to face 30R 34Guidance and training will be provided to Users and Analysts on the SPOC for contacting

ICS and how to deal with Users bypassing the Service Desk. 32R 35Providing a common structured dialogue for all ICS staff at all levels of support to User

Incidents and Requests. 32R 36The Touchpaper Portal will be the primary interface to ICS. 33R 37The design of the Touchpaper Portal will cover all ICS Services and Support processes in

place for these services. 36R 38The Service Catalogue will be published on the Touchpaper Portal 36R 39There will be a process for maintaining the Knowledgebase 36R 40 Problem solving training will be delivered by the Problem Management Process 39R 41Initial Incident categorisation will be based on Service > sub-service > symptom (generic)

39R 42Resolution Incident categorisation will be based on cause 39R 43Training will be provided to Incident Management staff on categorising Incidents 40R 44Measures will be taken to improve assignment quality 40R 45Feedback will be requested from Users at the closure of all calls (optional) and at regular

points in the calendar. 40R 46A standard Incident Process will be used by all support staff 40R 47Training will be provided on the standard Incident Process 41R 48The reporting facility within Incident Management will be utilised in many different ways

43R 49There will be a two stage closure process. 43R 50Frequently asked questions will be entered into the Knowledge Base 45R 51All User facing Service Requests will be processed via the Service Desk, 46R 52Service Desk will have ownership of all Service Requests. 46R 53A standard template will be used within Touchpaper as a form for Users to log a Service

Request. 47R 54Touchpaper Hot Topics to be used for top Service Requests. SH 47R 55There will be reporting on Service Requests for volume, resolve time and User feedback.48R 56The ICS services will be advertised on the Touchpaper Portal 48R 57Response times will be trialed within ICS according to the response times matrix. 59R 58Each Escalation within a response level will be associated with escalation actions. Error!

Bookmark not defined.R 59A minimal implementation is all that is possible within the Phase 1 timescale, and will

utilise data already being captured. 64


Paper ITSMS Project

Table of ContentsPurpose of Document............................................................................................................................2Proposals / Information.......................................................................................................................12Introduction.........................................................................................................................................12

Roles - IM and local IM roles and responsibilities EP (MG – Knowledge Management)..........12Objective and Scope for Incident Management EP.....................................................................15Definitions - Incident, Service Request, Problem, Known Error… EP,TM,SH,DMc..............17

Configuration Templates SH...........................................................................................................18Technology..........................................................................................................................................19Touchpaper Administration................................................................................................................19

User Types EP............................................................................................................................19Group types EP............................................................................................................................20Roles and Privileges EP...............................................................................................................21Company groups EP.....................................................................................................................21eDirectory fields and rights EP....................................................................................................21Department Analysts EP..............................................................................................................22

Touchpaper categories and lists..........................................................................................................23Departments EP............................................................................................................................23Locations SH................................................................................................................................23Incident notes JC,EP...................................................................................................................23Email manager EP........................................................................................................................24

Inbound...................................................................................................................................24Outbound.................................................................................................................................24

Analyst views TM,EP.................................................................................................................25Assignments TM,EP...................................................................................................................26Reporting SH............................................................................................................................27Optional actions EP......................................................................................................................27Working time EP,DM...............................................................................................................27Response times and actions DM..................................................................................................28Unsupported EP...........................................................................................................................28

Service Desk........................................................................................................................................30Three routes for contacting the Service Desk. EP............................................................................30

Web Portal...................................................................................................................................30Phone...........................................................................................................................................30Face to face.................................................................................................................................31

Target value for percentage of total Incidents bypassing the Helpdesk is 15% EP........................31Common structured dialogue......................................................................................................32

100% communications to be sent out by the Service Desk. This should be for proactive communications as well as reactive. JC.......................33

Communications within the Incident process JC.........................................................................33Touchpaper Self-service Portal for logging, monitoring and tracking Incidents. JC, BY.............33

Design of Portal JC,BY...............................................................................................................34Knowledge Base MG, BY...............................................................................................................36

Knowledge Process MG...............................................................................................................36Central store for knowledge - Touchpaper KB initially MG (with BY)......................................37Procedures/policies for maintaining the knowledgebase MG......................................................38Roles and Responsibilities for maintaining the knowledgebase.....................................................38

Incident Management..........................................................................................................................38Target value for % of Incidents closed at 1st level is 65% MG.......................................................38

FAQs - Top 10 MG.....................................................................................................................38


Paper ITSMS Project

Problem solving training DM......................................................................................................39Target value for % of Incident incorrectly categorised is 20% CR.................................................39

Defined levels of categorisation for Incidents, generic at lowest level TM/MG........................39Training for Service Desk on how to categorise Incidents TM/MG............................................40

Target value for Incidents incorrectly assigned to 2nd level is 5% EP,TM....................................40Automated feedback request set out via Touchpaper. JC................................................................40Standard Incident Management process workflow in Touchpaper. TM..........................................40

Process flow TM,MG..................................................................................................................40Tracking / monitoring TM,MG...................................................................................................43Reporting TM,MG..................................................................................................................43Closure TM,MG......................................................................................................................43

FAQs for all services available in the Knowledge Base. MG,BY..................................................45Training for 100% staff DM............................................................................................................45

Touchpaper training plan - demo and official DM......................................................................45Procedures training plan - workshop and official DM.................................................................46

Service Requests.................................................................................................................................46Service Desk will have ownership of Service Requests. SH.......................................................46Table of SR and units involved SH..............................................................................................46Standard template to be established in Touchpaper. SH,BY......................................................47

Workflow for top 10 SRs SH..........................................................................................................47List of main Service Requests SH................................................................................................47

Reporting on Service Requests for number per month, response time and User feedback. ..... SH,DM48

Service Level Management SH,DM................................................................................................48Services DM/SH..............................................................................................................................48

Using the Touchpaper prioritisation matrix for Urgency and Impact we will establish internal response times. DM........................59

Matrix showing prioritisation DM...............................................Error! Bookmark not defined.Use Touchpaper to support automated escalation of Incidents. DMError! Bookmark not defined.

Actions for each level of escalation within Touchpaper SH/DM Error! Bookmark not defined.Use Touchpaper MI and Crystal Reports to establish reporting by Incident Type and Response times. DM.................59

List of reporting requirements DM.............................................Error! Bookmark not defined.Use Touchpaper to support the ICS Liaison process. DM...............................................................61

Requirements for the ICS Liaison process DM............................Error! Bookmark not defined.Configuration Management................................................................................................................61

Establish high level structure for CMDB and map this is Touchpaper. CR................................61Planning the CMDb in Touchpaper............................................................................................61Full CMDb implementation........................................................................................................61Further development of the CMDb.............................................................................................64

Consultation SH............................................................................................................................65Management team SH......................................................................................................................65Analysts - workshops SH.................................................................................................................65

Content............................................................................................................................................65Workshop format............................................................................................................................65Roles................................................................................................................................................66Participant selection........................................................................................................................66

Appendix.................................................................................................................................................67Introduction.........................................................................................................................................67

eDirectory fields and rights EP....................................................................................................67


Paper ITSMS Project

Department Analysts EP..............................................................................................................67Touchpaper categories and lists..........................................................................................................68

Departments EP............................................................................................................................68Locations SH................................................................................................................................68

Touchpaper Self-service Portal for logging, monitoring and tracking Incidents. JC,BY..............71Design of Portal JC,BY...............................................................................................................71

Service Requests.................................................................................................................................74Service Desk will have ownership of Service Requests. SH.......................................................74Table of SR and units involved SH..............................................................................................74

Configuration Management................................................................................................................79Establish high level structure for CMDB and map this is Touchpaper. CR................................79

eDirectory Data...........................................................................................................................81


Paper ITSMS Project

Proposals / Information

This document was written by the project team to propose the design of the solution for each of the project Work Packages:

Work Package LeaderService Desk Emily PattersonIncident Management Tom MortimerService Requests Susan HallService Level Management Dave MurieConfiguration Management Chris Reid

Against each heading the author’s initials have been noted, according to the following table:

Project resource InitialsEmily Patterson EPSusan Hall SHBrian Yeomans BYAnnie Muir AMDamien Mcguiness DMcTom Mortimer TMMichelle Gavine MGChris Reid CRJulie Christie JCDave Murie DM

The document is in two parts: Technology Service Desk and Incident Management Work Packages

Introduction

Roles - IM and local IM roles and responsibilities EP (MG – Knowledge Management)

R 5 Incident Management roles will be established

The following roles will be involved in the Service Desk and Incident Management process:

Role ResponsibilityIncident Manager Ownership for quality checking

Incidents, identifying issues & suggesting solutions

Monitoring the workflow of Incidents and Service Requests and co-ordination of support staff (first and second-line)

Be accountable for the co-ordination and


Paper ITSMS Project

resolution of all Incidents and Service Requests

Monitoring the effectiveness of Incident Management and making recommendations for improvement

Accountable and responsible for production and provision of regular management reports

Interface with other process teams to ensure complete delivery of ITIL methodology

Operational responsibility for delivery of all Incident Management activities

Holding monthly Incident Management meetings with Local Incident Managers

Local Incident Managers Incident Managers within each ICS unit with responsibility for:

Liaising with the Incident Manager Attending regular Incident Management

meetings Day-to-day Incident Management

activities including briefing 2nd level support staff on priorities

Work with Unit Head to manage negotiation of resources of other workloads e.g. other processes such as Problem Management.

Monitor even distribution of workload Quality check of unit’s Incident &

Service Request workflow Unit Head / Line Manager Appoint to role of Local Incident

Manager ensuring resilience Support of Local Incident Manager role Quality check of Local Incident

Manager responsibilities Deal with resource issues concerning

Incidents and Service Requests Be a point of escalation for Local

Incident Manager

Incident Management staff 1st Level Incident registration Day-to-day Incident Management

activities Routing Service Requests to support

groups when Incidents are not closed Initial support and classification ownership, monitoring, tracking and

communication Incident investigation and diagnosis


Paper ITSMS Project

(including resolution where possible) Resolution and recovery of Incidents not

assigned to second-line support Closure of Incidents.

Incident Management staff 2nd Level Second-line support (specialist groups that may be part of the Service Desk) will be involved in tasks such as:

Day-to-day Incident Management activities

Handling Service Requests Monitoring Incident details, including

the Configuration Items affected Incident investigation and diagnosis

(including resolution where possible) Detection of possible Problems and the

assignment of them to the Problem Management team for them to raise Problem records

Resolution and recovery of assigned Incidents.

Knowledge Manager (See Knowledge Management Process)

Oversee Knowledge Process Ensure template completed Ensure required training completed

before data release Co-ordination of all steps of the process

including communication Regular reporting Co-ordinate improvements to process Review feedback from Users (possibly

use of surveys) Co-ordinate Knowledge activities

between units

Knowledge Administrator (See Knowledge Management Process)

Input/amend/remove data to/on/from the system

Liaise with Knowledge Manger Quality checking Look at suggestions for improvement to

design/layout of KB

Service Request Coordinator Operational coordination of Service Requests

Oversee end-to-end process of creation of New Service Requests in conjunction with change management

Authorise New Service Requests


Paper ITSMS Project

Providing reports to Local Incident Managers and Unit Heads

There will be a strong link between this role and the Change Manager

Service Portal administrator Administration of the Touchpaper Service Portal

School IT Support Analysts Support for departments at analyst levelSchool Support (End User) Department support end Users have the

responsibility of acting as the central point in their department for registering IT Incidents and Service Requests sometimes on behalf of another member of staff from their department.

End User Responsibility to register own IT Incidents giving full and accurate information

R 6All roles will have assigned lead and deputy lead or another member of their Unit/ department to reduce single points of failure.

R 7To support the Incident Management process all communications with the Incident Manager will be logged in Touchpaper.

R 8To support the Incident Management Process an Incident Management calendar will be established and maintained by the Incident Manager (within Touchpaper)

The Incident Management Calendar will hold information about critical business times for the University e.g. Exam times and matriculation. The use of the calendar could be expanded for use in conjunction with other ITIL processes such as Change Management and Release Management in future phases of the implementation.

Objective and Scope for Incident Management EP

The primary objective of Incident Management is to restore normal service operation as quickly as possible and minimise the adverse impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained.

A request for new or additional service (i.e. software or hardware) is often not regarded as an Incident but as a Request For Change (RFC). However, practice shows that handling of both failures in the infrastructure and of Service Requests are similar, and both are therefore included in the definition and scope of the process of Incident Management. The word ‘Incident’ in this chapter applies to both, if not explicitly stated otherwise, although organisations may decide to develop their own Service Request procedures to isolate them from the more technical issues.


Paper ITSMS Project

Service Requests will be handled in the same way as Incidents under the Incident Management process, however these will be reported on separately as Service Requests are a normal part of the service and do not reflect interruptions or failures.

Within the more technically oriented systems-management function, an automatically registered event such as exceeding a disk-usage threshold is often regarded as part of ‘normal’ operations. These events are included in the definition of Incidents even though service delivery to Users is not affected.The Incident Management process is split down as follows:

Inputs: Incident details sourced from (for example) Service Desk, networks or computer operations Configuration details from the Configuration Management Database (CMDB) Response from Incident matching against Problems and Known Errors Resolution details Response on RFC to effect resolution for Incident(s).

Outputs: RFC for Incident resolution; updated Incident record (including resolution and/or Work-

arounds) Resolved and closed Incidents Communication to Users Management information (reports) Incident Management activities Incident detection and recording Classification and initial support Investigation and diagnosis Resolution and recovery Incident closure Incident ownership, monitoring, tracking and communication

Definitions - Incident, Service Request, Problem, Known Error… EP,TM,SH,DMc

R 9Standard definitions will be used for Incident Management


Paper ITSMS Project

Terminology DefinitionIncident Any event that is not part of the standard

operation of a service and that causes, or may cause, an interruption to, or a reduction in, the quality of that service.

Service Request Every Incident not being a failure in the IT Infrastructure

Problem Unknown underlying cause of one or more Incidents

Known Error An Incident or Problem for which the root cause is known and for which a temporary Work-around or a permanent alternative has been identified. If a business case exists, an RFC will be raised, but, in any event, it remains a Known Error unless it is permanently fixed by a Change.

R 10The flow of information between Incident Management and Problem Management will be a joint responsibility between the Incident Manager and the Problem Manager.

Information flow from Incident Management to Problem Management

Category From To Information required1. Incidents with Details IM PM Which service impacted?

Number of Users?User Details

Who?Where?

Severity?Priority?Error messages?Symptoms?Linked Incidents

2. Workaround/Resolutions IM PM What 1st line support advised User.3. Updated Problem Record PM IM PM Identifier

PriorityAnalysisDiagnosticsFurther Info/Testing from IMStatus

With Problem ManagerWith Problem TeamWith 3rd Party (external)With Change ManagerWith Configuration ManagementWith Release Management

4. Workaround Solutions PM IM PM IdentifierClear, simple, concise details of workaround.

5. Known Error PM IM PM Identifier


Paper ITSMS Project

Details of root causeTimeline for resolution

R 11 The Problem Manager will be responsible for the coordination of problem solving activities and will assess and recommend appropriate problem solving training for Incident Management staff.

Configuration Templates SH

The Service Desk and Incident Management solution will include outputs in the form of: Roles and Responsibilities Policies Procedures Training Technology Documentation Communications Test Scripts (A test script will be used to test the primary functions of the Touchpaper

Console and the Touchpaper Web Portal. The test script will cover each technology component of the solution. The standard SOE test script will be used.)

R 12Where available, standard ICS templates will be used for documentation.

ACTION: please advise of any templates that should be used.

Technology

Technology comprises the administration of the Touchpaper system and lists/categories required for the Incident Management process.

Touchpaper Administration

There are four different User types within the Touchpaper Console: Account Manager, Analyst, Contact, End User. This allows Users to have access which is pertinent to their role. Based on conversations with University of Dundee, only two of the User types will be used: Analyst and End User.

User Types EP

User types will be divided by:

User type Sub-type1 Sub-type2 Description

Analyst ICS Analyst ICS unit imported from eDirectory

All ICS staff


Paper ITSMS Project

School IT Analyst School imported from eDirectory

Non-ICS school IT support <see section: School IT Support Analysts>

End User Standard End User Staff All University staff

Student All University students

Other All other eDirectory account Users e.g. Associate, Visitor, etc

School Support User <see section - Department Support>

S3 Account Holder

External

ICS-Liaison

R 13 User types will be defined as described in User Types table.

Group types EP

Groups are used to arrange the Users according to job function, expertise, or other similar function. Users can belong to more than one group.

Group type Group

Support Business Improvement

Network Infrastructure

Workstations and Desktop

Servers and Storage

Service Desk

Corporate Information Systems


Paper ITSMS Project

Strategic Information Management

Admin

Teaching & Learning Support

Directors

Department IT Support

Company Staff

Student

Other

Dept Support

S3 Account Holder

User S3 Department Users (import from eDirectory)

Supplier 3rd Party (import from ICS Purchasing database)

External contact

R 14 Group types will be defined as described in Group Types table.

Roles and Privileges EP

Roles are a set of privileges that are linked to Users and groups. Users can have zero, one or more roles. By default new groups and roles have no privileges, privileges must be granted.

Role Access PrivilegesEndUser – Staff/UG/PG Portal Log Incident

Add attachment

DeptSupport Portal (as above) +Log Incident for another end User in own department

Analyst-DeptIT Portal (as above) +Add note


Paper ITSMS Project

Role Access PrivilegesAnalyst-ICS Portal & Console (as above) +

Add assignmentAdd taskAdd problemResolveUnresolveRespond to End UserWith End UserWith 3rd Party

Local Incident Manager Portal & Console (as above)Analyst-ServiceDesk Portal & Console (as above) +

Back from EndUserBack from 3rd PartyCloseReOpen

ICS-Administrator Portal & Console All Incident rightsICS-Manager Portal & Console All privileges

R 15 Roles and privileges will be defined as described in Roles and privileges table.

Company groups EP

<See within Groups section>

eDirectory fields and rights EP

R 16 Integration will be required as described in eDirectory fields and rights section

Users and all hardware held in eDirectory will be automatically imported from eDirectory to Touchpaper overnight. A history of this event will be required.

Touchpaper users key field will be a single attribute populated by a combination of eDirectory fields:

Touchpaper eDirectoryID <Workforceid>(1st char stripped) – <Givenname> <Surname>

In order to minimise Touchpaper administration there is a requirement to automate group identification of End Users and Analysts within the import wherever possible. To achieve this automation, an additional eDirectory field is required. This field will identify into which Group new or amended imported Touchpaper Users and Analysts belong. This field will be automatically populated by a default value during creation of new and amended eDirectory accounts according to data imported from SITS (students) and P3 (staff).


Paper ITSMS Project

eDirectory default value will correspond to Touchpaper Company>Student, Company>Staff or Company>Other group. Staff within the ICS container (all ICS Analysts) will automatically populate with default value corresponding to Support group.

There is currently no means of automatic identification of Users and Analysts out with the default groups above. These will require to be manually administered. Touchpaper administrator will have rights to change the eDirectory field value within a restricted set of values corresponding to each of the Touchpaper Group types.

Touchpaper require to supply ICS with requirements for population of this eDirectory field e.g numeric or text field. Import mechanism requires to be adaptable in order to incorporate development of new groups.

See Configuration Management section for list of eDirectory attributes matched with TP attributes

School IT Analysts EP

School IT support will be placed in the School IT Support group with corresponding rights. This will assist in including the school IT support personnel into the overall support of IT support provision for all University staff and students. This group will have rights to add updates directly into the Touchpaper Incidents concerning their school. (See appendix for details)

R 17 Department support Analysts should be assigned Analyst rights within Touchpaper

School Support (End User)Department support end Users have the responsibility of acting as the central point of contact in their department for registering IT Incidents and Service Requests sometimes on behalf of another member of another member of staff from their department.. The Department Support personnel will have the rights to register an Incident or Service Request on behalf of another User within their department and to query all Incidents and Service Requests registered for their department. (See appendix for details)

Touchpaper categories and lists

Departments EP

R 18 To ensure consistency the department names require to be aligned with eDirectory and so will be part of the import from eDirectory.

Proposed attribute:

eDirectory field Touchpaper Example Staff Example StudentO College Code CASS ASSC

Department Number School Code AS03 ASSC-PSYCOU Dept name Economic Studies UNDERGRAD 03 ASSC-PSYC


Paper ITSMS Project

Context Context economics.AS.dundee UG.AS.dundee

Locations SH

Touchpaper will hold a drop down list of locations at two levels: Campus Buildings

(see appendix for details of locations)

R 19 Locations for site and building will be held in Touchpaper

Incident notes JC,EP

Incident notes will be used to record information about Incidents during the whole Incident Management process. Incident notes are an important record of the history of an Incident and with the implementation of Touchpaper will have increased visibility to the User.

R 20 Guidance will be provided to all Incident Management staff on using Incident Management notes.

Notes Categories

Responded Incident Notes With User With 3rd Party

Back from User

Back from 3rd Party

By telephone Additional info from User

Additional info required

On-site warranty repair

Additional info Repaired

By email Update from ICS Analyst

Testing required

Off-site warranty repair

Test results Replacement

By Face-to-Face Update from School Analyst

Authorisation required

Non-warranty repair

Authorisation Unable to repair

Update from School Support User

Purchase Response

User called for update

Query – waiting on 3rd party

More info requested

Contacted User Support contractContacted 3rd partyUpdate to 3rd partyUpdate from 3rd party

Email manager EP


Paper ITSMS Project

InboundAll Users and Analysts will be actively directed to Web Portal.

R 21 No inbound email is planned within first implementation. There will be a transition period of 3 months when emails will be accepted along with guidance on using the web portal. The portal must be intuitive, therefore the portal will be developed in conjunction with a user focus group.

This will be part of future development of proactive infrastructure monitoring and controlled automatic error reporting.

Outbound

R 22 Standard templates will be used for sending Email to Users at fixed points within the Incident Management Process.

Email sent to User on:

1st response (automatic email) Your Incident no.??? has been recorded …. Please quote this Incident number in all correspondence regarding this Incident.

Assignment to 2nd level Your Incident no.??? has been assigned with the appropriate team. You should receive a response within ?? working hours. Please contact us via the ICS Service Portal with any further information or query regarding this Incident.

Notify of Resolution status Your Incident no.??? regarding <Title> has been resolved …<Resolve Note content> Please contact us via the ICS Service Portal with any further information or query regarding this Incident otherwise this Incident will be automatically Closed after 10 working days.

Touchpaper allows a range of actions on the change of status of an Incident and these may be used to alert the analyst.

Email sent to Assigned Analyst on:

Assignment of Incident to individual Analyst

Added Note

Returned from User

Returned from 3rd Party

R 23 No email to analyst on assignment of Incident to Unit/Service – local IM responsible for assignment to individual Analyst.


Paper ITSMS Project

Analyst views TM,EP

R 24 The default View displayed to Analysts on connection to the Touchpaper Console will be the Console Welcome page.

The Console Welcome Page will display the results of queries. The default queries to be displayed are:

1st Line Analysts

Incidents assigned to Unit and/or Service/s <to be agreed> All Assigned Incidents by descending Incident number

[DM] NB. In response to feedback from ICS-MT and workshops, it has been agreed that incidents will be assigned to service teams, not Units. See Table of Sub-services on page 52.

2nd Line ICS Analysts

Incidents assigned to self Incidents assigned to own Unit and/or Service/s <to be agreed>

Department IT Analysts

Incidents assigned from all Users in their department, sorted by ascending Incident number Incidents from all Users in their department, Status With User

Managers

All Assigned Incidents, Status Assigned, to Unit and/or Service/s <to be agreed> All Assigned Incidents, by Unit, sorted by descending Incident number All Assigned Incidents, by Service, sorted by descending Incident number

All views will display:

Incident Ref.no.

User name

User Dept Incident Status

Incident Title

Creation date

Date last worked on

Assignments TM,EP

R 25 Incidents will be assigned to units according to ICS Service affected

****

Where an Incident has not been resolved at 1st level it will be assigned to 2nd level support. The content of the Incident Category field/s will suggest which area to Assign to by automatically


Paper ITSMS Project

populating Assign to field. This can be changed by choosing from a drop down list of Services. ICS procedures will follow a two stage assignment:

Stage 1 – assigned by 1st level Analysts

Category (Service/Type) SubService <see section 111)

Options for Assign to

There are two options to use for the area Incidents are to be assigned:

1. Unit

Stage 2 – assigned according to system in place in Units (by local IM and/or unit head)

Unit/Service <to be agreed> AnalystIndividual Analysts

Reporting SH

R 26 Incident reporting will be carried out on a regular basis and presented to the Local Incident Managers on a monthly basis.

Incident volume refers to the total number of Incidents that are handled by the Incident Management process.

Mean elapsed time shows how much time was taken to achieve Incident resolution or circumvention. The time is broken down by impact code.

Incident response time refers to the percentage of Incidents handled within the agreed upon response times, which may have been specified in Service Level Agreements by impact code, for example.

The percentage of Incidents closed refers to the percentage of Incidents closed by the Service Desk without reference to other levels of support.

Optional actions EP

R 27 During the Incident Management Lifecycle in addition to the standard actions, there will be optional actions.

Optional Actions to be made available at each Status point for all Analysts:Add Note


Paper ITSMS Project

Add Attachment

Optional Actions restricted to role of Analysts-ICS and above:Add AssignmentAdd S3 NoteAttach IncidentAdd TaskAdd ChangeAdd ProblemCreate ProblemCreate Change

Working time EP,DM

R 28 Touchpaper will record elapsed time between various Incident status points

ICS require to provide particular schools/departments with monthly reports detailing Incidents reported along with actual working time spent on each Incident ‘worked on’ within requested dates. Current reports required are:

School/Department reports1. Currently Assigned Incidents with total time worked on2. All Incidents Worked on in a given month with total time worked on

ICS unit reports1. Summary report by School/Dept with total working time within requested dates2. Summary report by School/Dept, broken down by ICS Analyst with total working time within

requested dates3. Summary report by ICS Analyst, broken down by School/Dept with total working time within

requested dates

Touchpaper require to provide a mechanism to record all ICS analysts working time broken down per Incident per analyst with date/time work done.

Response times and actions DM

R 29 All Incidents will have a call back response level, time available to be determined for each Response Level. This will be built into the Incident process.

All Response Levels will be based upon a Calendar of 09:00 – 17:00 Monday to Friday. This will include all Bank Holidays. However there is a 9 – 10 day period over Christmas and New Year in which ICS do not provide support. Each of these days will be put into the Calendar as Holiday days.

In proposing that framework, they considered that the appropriate response time for any Incident needed to be predicated upon three factors: priority, urgency and impact.

Priority could be classified as Low, Medium or High, and needs to be determined by urgency plus impact plus availability of resources. It may also be contingent on other factors where relevant.


Paper ITSMS Project

Urgency is an assessment of the speed with which an Incident requires resolution.

Impact reflects the likely business effect the Incident will have on the service.

Low Medium HighStandard 2 days [DM] 2 days [DM] 2 days [DM]Important 2 days [DM] 1 day 1 dayUrgent 1 day 1 day 1 hour [DM]NB Table modified 7 May in accord with feedback from Response Times workshop.

Unsupported EP

R 30 ICS require a clear definition of supported services including policy on areas unsupported.

Incidents requesting support for an unsupported service will be recorded. This will include user information, classification of incident and details of the request. All unsupported incidents will be Closed by Service Desk.

Life Cycle of an Unsupported Incident

Example of unsupported: Windows Vista OS

OS - unsupported Webmail on Vista - unsupported, fix provided by Email service UoD WiFi Network Service - unsupported, future development


Record :UserService/TypeStatus - Unsupported

Inform User of unsupported policye.g. None, best effort, future development

Closed by Service Desk

Paper ITSMS Project

Service Desk

Three routes for contacting the Service Desk. EP

R 31 The SPOC for ICS will be known as the Service Desk

R 32 The change of name from Helpdesk to Service Desk will be publicised to the User community

ICS Service Desk will be the Single Point of Contact between ICS services and Users, on a day-to-day basis. It will be the focal point for reporting Incidents and making Service Requests.

R 33 The routes for Users contacting ICS will be the Service Desk via Web Portal, Phone and Face to face

Web Portal

Touchpaper Web Portal will give User a 24x7 point of entry to Service Desk. This will give Users ease of access resulting in increased speed of resolution and reduced demand on support resources. Users will be actively encouraged to use the Web Portal.

Users will register their own Incidents and queries.

Users will be automatically given an Incident number at time of registration of Incident.

Users will have the ability to check on the progress of their own Incidents and Service Requests

Users will register their own Service Requests and check on their progress. These will be automatically routed through particular Service Requests process so reducing timescale of completion of request.

Users will have the ability to search knowledge base for solutions

Department Support will have the ability to register an Incident or Service Request for others in their department.

Department Support will be able to check on progress of their own departments Incidents and Service Requests

Department IT Analysts will have the ability to register an Incident, check on progress of Incident and update an Incident record.

Phone

Phone pickup 8.45am – 5pm


Paper ITSMS Project

Phone pickup will be within 3 rings

Out with pickup times voicemail message will

- guide caller to Web Portal

- prompt caller to leave name and phone number on voicemail

- instruct caller of response time to their voicemail message

Service Desk staff will handle call in a professional and consistent manner:

- Consistent formal greeting

- Employ active listening and questioning

- Summarise the call and advise of action to be taken

- Give User the call Incident number

- If closing call advise procedure for re-opening if required

- Where unable to Close at 1st level inform User of assignment to 2nd level and expected response time

Face to face

Face to face desks will be

Staffed at publicised times

Staff will dress appropriately displaying ICS identification card

Be consistent and professional in speech and body language

Give User the call Incident number

If closing call advise procedure for re-opening if required

Where unable to Close at 1st level inform User of assignment to 2nd level and expected response time

Target value for percentage of total Incidents bypassing the Helpdesk is 15% EP

The target value for Incidents bypassing the Service Desk is 15%. In order to achieve this target the Service Desk requires to:

Users

- Inform of identity change to Service Desk

- Inform of benefits


Paper ITSMS Project

- Educate on changes to procedures e.g. Web Portal, phone, face to face desks

ICS Analysts


- Educate ICS staff on changes to procedures

- Train on How to re-route to Service Desk from all methods of contact

Department IT Analysts


- Educate on roles and responsibilities

- Educate on procedures

- Train on use of Touchpaper Portal and client

Phones

- Amend 2nd level voicemail message to route to Web Portal or SD x88000

- Educate 2nd level Analysts on phone contact

- Investigate routing all support phones to 88000 - would 2nd level require 2nd 'private' phone line

Email

- Change all 2nd level email signatures to Service Desk contact details

- Direct all Incidents, Service Requests, Feedback, Comments from all University Web Pages to ICS SD via Touchpaper Web Portal.

- Direct all ICS generic email to Service Desk – Phase 2

R 34 Guidance and training will be provided to Users and Analysts on the SPOC for contacting ICS and how to deal with Users bypassing the Service Desk.

Common structured dialogue

R 35 Providing a common structured dialogue for all ICS staff at all levels of support to User Incidents and Requests.

Using a common technique presents a professional and well-structured support to the User and ensures nothing is forgotten.

This will include:

User ‘pickup’, i.e. agreed response times

Consistent User response dialogue for phone, face to face and email


Paper ITSMS Project

User identification e.g. name, identification number or Username

Capture contact detail information (confirm if already in CMDB)

Capture information appropriate to the Incident and supporting Service.

Incident or Service Request only closed on agreement of User i.e. two stage closure

Service Request processes available via Touchpaper Web Portal

Knowledge and procedures review

All reference materials and procedures used by Users and ICS Support staff to be well maintained, kept up-to-date and regularly reviewed, including:

standard checklists

training manuals

knowledge base

documented Known Errors and solutions

documented Change Management

documented Services including support levels

product and application documentation

hardware documentation

100% communications to be sent out by the Service Desk. This should be for proactive communications as well as reactive. JC

Communications within the Incident process JC

(60 - when) Comms for IM stages (61 - how) Templates (62 – who) SD staff or TP?Call logged YES TPCall closed YES TPCall assigned YES TPCall action out of date/catchup YES/NO SDMore info/ testing/ authorisation required YES/NO SD/Analyst

Touchpaper Self-service Portal for logging, monitoring and tracking Incidents. JC, BY

R 36 The Touchpaper Portal will be the primary interface to ICS.


Paper ITSMS Project

Design of Portal JC,BY

dependant Then User type and available on every part of the site

Hot Topics lists major Incidents, problems and changes. Ties in with Noticeboard


Paper ITSMS Project


Paper ITSMS Project

R 37 The design of the Touchpaper Portal will cover all ICS Services and Support processes in place for these services.

ICS service catalogue

Centralstrategicsystems

Central Online

Information

Consultancy

CentralLearning &Teachingfacilities

ICS Service Desk

ICT Training

DisabilityICT Support

Email

Datastorage

DesktopServices

NetworkAccess

Telephones

R 38 The Service Catalogue will be published on the Touchpaper Portal

Knowledge Base MG, BY

Knowledge Process MG

R 39 There will be a process for maintaining the Knowledgebase

There will be two new procedures with the implementation of Knowledge Management, a procedure for adding to the Knowledge Base and a procedure for modifying or removing knowledge from the system. The steps and owners are shown in the following two tables.

Adding to Knowledge DatabaseStep Who

Data requirement (initiation from idea) User, SD, 2nd Level AnalystValue of data (frequency of question) SD - KM


Paper ITSMS Project

Collation of data on standard template OwnerTemplate submitted and assigned Owner submits to KMSelect and assign to Owner (service dependent)

SD - KM

Quality check of data SD - KMTraining requirements acknowledged and implemented to SD

Owner

Data input to KD – weekly and urgent KD AdminData Release notification

Added to Portal Hot Topics issue – Yes/No ICS Weekly Update

Portal AdministratorOwnerCommunication & Information Officer

Amending or Removing Data from Knowledge DatabaseStep Who

Check number of hits to data KM/Portal AdministratorRegular/ad hoc meetings re data SD & KMFeedback from Users to fine tune data SD & KMRelevance of data OwnerChange/amend Owner/KMData Release notification for changes

Added to Portal Hot Topics issue – Yes/No ICS Weekly Update

Portal AdministratorOwnerCommunication & Information Officer

Central store for knowledge - Touchpaper KB initially MG (with BY)

Standard data input template introduced to ensure capture of all relevant information: Which service it relates to Owner Unique reference number Classification categories Keywords for accurate searches Who is it relevant to (likely to be impacted) When it is relevant; start date, expiry date Training requirements eg for SD, PG’s etc Data/information, including description, steps, screen shots etc. New, change or removal of data

Example: (The example will be the output of a focused workshop with ICS staff)

Standard TemplateServiceOwnerReference no Automatically generated by systemClassification category


Paper ITSMS Project

Keyword searchStatus of data New

Amendment Removal

Who will want to knowWhen will data be requiredTraining required

Who needs training Description of training

Yes/No

Data to be input Description Steps Screen shots

Release date of Data to KB

Procedures/policies for maintaining the knowledgebase MG

All data to be input to the KD to be processed through the Knowledge Management procedure

All data submitted using standard template Continuous service enhancement through User surveys/ feedback ie was this data

helpful/useful?

Roles and Responsibilities for maintaining the knowledgebase

Two roles will be required by the Knowledge Management Process, namely the Knowledge Manager and the Knowledge Administrator.

Knowledge ManagerSee roles and responsibilities

Administrator for Knowledge BaseSee roles and responsibilities

Incident Management

Target value for % of Incidents closed at 1st level is 65% MG

FAQs - Top 10 MG

To allow Service Desk Analysts to quickly access commonly asked questions the top 10 FAQs will be maintained in the system. The initial top 10 FAQs asked by students and staff are noted in the appendix to this document, and these will be updated by the Knowledge Management Process.

Forgotten passwordNew student User details


Paper ITSMS Project

Pay2Print tutorialRequest for -t teaching User detailsUnknown student User detailsGeneral printing problemsNot enough credit to printWebmail 7.0 - Prompted for login details more than once off campusUnattended PCsWireless Connection Tutorial

Problem solving training DM

R 40 Problem solving training will be delivered by the Problem Management Process

Target value for % of Incident incorrectly categorised is 20% CR

Defined levels of categorisation for Incidents, generic at lowest level TM/MG

Categorisation will be defined at two points in the Incident Management process, the first on opening an Incident at the detect and record stage of the Incident Life Cycle and the second at closure, which will allow for more accurate and concise reporting.

Open CategoriesWhen a new Incident is recorded the selection of an open category will be determined by the following inputs:

Service – one of the twelve services within ICS e.g. email service, network etc Sub-service or type e.g. if the service is email, the sub-service might be webmail Effect (generic symptom) of the Incident e.g. can’t send mail, no access, slowness etc

R 41 Initial Incident categorisation will be based on Service > sub-service > symptom (generic)

The outputs will be: Assignment of the Incident to the correct service Accurate and concise reporting on service availability

Resolution categoryOnce an Incident has been investigated and resolved the information gathered through the Incident Life Cycle will result in the standardisation of accuracy in selection of the Resolution category. The categories will be further determined by the cause of the Incident with the following inputs:

Cause e.g. hardware (network, servers), software (SOE, web browser)

R 42 Resolution Incident categorisation will be based on cause

With such clearly defined Resolution categories the outputs will be:


Paper ITSMS Project

Accurate reporting, including trends and issues Better Problem Management Request for Change Identify a new Service Request Identify new data/information that can be submitted to the Knowledge Base Identify a Hot Topic Identify a new Known Error Identify a need for training (User community and ICS) Facilitate better communication both to the User community and within ICS Units

s

Training for Service Desk on how to categorise Incidents TM/MG

R 43 Training will be provided to Incident Management staff on categorising Incidents

Target value for Incidents incorrectly assigned to 2nd level is 5% EP,TM

R 44 Measures will be taken to improve assignment quality

Current incorrect assignment from 1st to 2nd level is 10%. This requires to be reduced to 5%. Improved symptom based initial categorization of Incidents using Service/Type. Opening category/subcategory suggests Assignee 1st level training Services and description in CMDB Knowledge Base Scripts Service Requests Feedback mechanism from 2nd level

Automated feedback request set out via Touchpaper. JC

R 45 Feedback will be requested from Users at the closure of all calls (optional) and at regular points in the calendar.

Standard Incident Management process workflow in Touchpaper.TM

Process flow TM,MG

R 46 A standard Incident Process will be used by all support staff

R 47 Training will be provided on the standard Incident Process


Paper ITSMS Project

Incident Detecting and RecordingAn Incident may be initiated from a number of different sources, most commonly from a User, but it could also be from a problem detected by second line support or from a system that monitors services and the IT environment. Service Requests are also dealt with in the Incident Management Life Cycle. The introduction of the Touchpaper software will allow first line and second level support to record the Incident through the Client software and also Users will be able to record an Incident through a Web Portal.

The activities involved in this stage are: Record basic details of the Incident including who, what when, configuration details etc Alert specialist support group(s) if necessary Start procedures for handling the Service Request

Outputs will be: Communication with the User Updated details of Incidents The recognition of any error on the CMDB (Config Management DataBase)

Initial Classification and SupportIncident information recorded in the previous stage are now analysed to try discover the reason for the Incident. Activities include:

Classifying Incidents and Service Requests Matching against Known Errors Informing problem management of the existence of new Problems and of unmatched or

multiple Incidents Assigning impact and urgency, and therefore defining priority Assessing related configuration details Identifying a RFC Providing initial support (assess Incident details and find quick resolution) Closing the Incident or routing to a specialist support group (functional escalation) and

informing the Users.Outputs

RFC (Request For Change) for Incident Resolution Updated Incident details Work-arounds for Incidents or Incidents routed to second or third line support Specifying the service with which the Incident is related Associate with SLA (Services Level Agreement) where appropriate Select/define the best specialist or group to handle the Incident Identify the priority based upon the business impact Define what questions should be asked Determine a primary reporting matrix for management information Identify a relationship to match against Known Errors

Initial support involves resolution of Incident to the satisfaction of the User by the Service Desk. The resolution may be derived from several areas including

Identification of a Known Error Service Desk expertise A knowledge search


Paper ITSMS Project

If the Incident has not been solved during initial support it is progressed to Investigation and Diagnosis.

Investigation and DiagnosisIf the Incident has not been solved during initial support it is progressed to Investigation and Diagnosis. This stage may involve second line support.

Inputs Updated Incident details Configuration details

Activities: Assessment of the Incident details Collection and analysis of all related information and resolution Including any Work-around or a route to second-line support

Once the Incident has been assigned to a support group it should Accept assignment of the Incident, note time and date ensuring

1. The Incident status and its history are regularly updated2. The User, via the Service Desk, is kept informed of progress

Advise the Service Desk/User of any workaround. Review the Incident against Known Errors problem, solutions, planned changes or

knowledge base Record all details applicable to this phase of the Incident Life Cycle including:1. Solution2. Classification added or updated3. Update of all related Incidents4. Time spent

Reassign Incident to Service Desk for closure action

Resolution and RecoveryDuring the Resolution and Recovery stage the focus is returning the Users service to normal status using an action that will resolve an Incident. This may be a Workaround.

Resolution: concerned with fixing the Incident

Recovery: concerned with ensuring the User is back to where they were before the Incident occurred.

ClosureThe Service Desk will contact the User to confirm that the Incident has been resolved to their satisfaction.

Activities involved in this stage are:Service Desk should ensure that:

o details of the action taken to resolve the Incident are concise and readableo classification is complete and accurate o resolution/action is agreed with the User –

All details applicable to this phase of the Incident control are recorded, such that: o the User is satisfied


Paper ITSMS Project

o the time spent on the Incident is recordedo the person, date and time of closure are recorded.

Tracking / monitoring TM,MG

Tracking – at any stage throughout the Incident Life Cycle, the Incident can be tracked to see the status of the Incident.

Incidents can be tracked by ICS through the Touchpaper client Incidents can be tracked by the User through the Touchpaper Portal Continuous communication with the User with regard to progress and status can be

automated by the software or manually by 1st and 2nd level support

Monitoring – the role of monitoring an Incident throughout it’s entire Life Cycle will be the responsibility of the Incident Manager and the Local Incident Managers and will involve the close monitoring of status changes. This in turn may require a hierarchical escalation dependent upon:

Priority Impact OLA’s SLA’s Breaches

Reporting TM,MG

R 48 The reporting facility within Incident Management will be utilised in many different ways

Volume of Incidents Department reports for individual units OLA reports to indicate any areas of concern ie breaches SLA reports to indicate any areas of concern ie breaches Reports on work recorded for departments with S3 support Highlighting hot topics Highlighting a Request for Change

Closure TM,MG

R 49 There will be a two stage closure process.

With Incidents that are passed to Second level support, their role will be taking part in the investigation and diagnosis, resolution and recovery of an Incident, but then assigned back to the Service Desk.

The Service Desk will then communicate with the User (email, telephone, face to face) to advise that the Incident has been resolved. Only when the User is able to confirm that they are satisfied that the Incident has been resolved to their expectations, will the Incident be closed and signed off using the Resolution categories.


Paper ITSMS Project

INPUTS OUTPUT ACTIVITIESROLES &

FUNCTIONIncident details RFC Detect and record First line supportConfiguration details Resolved and closed Initial classification

and supportSecond line support

Matching against KE’s Communication to User

Investigation and diagnosis

Third line support

Resolution details Management info Resolution and recovery

Incident Manager

RFC response Additions or amendments for KD

Closure Service Desk Manager


Paper ITSMS Project

FAQs for all services available in the Knowledge Base. MG,BY

R 50 Frequently asked questions will be entered into the Knowledge Base

Training for 100% staffDM

Touchpaper training plan - demo and official DM

Half-day session for all ICS staff.Run over 4 slots to maximise opportunity for attendance.This will cover navigation and use of the Touchpaper tool as initialised for our own use - ie tailored training for ICS

Procedures training plan - workshop and official DM

Internally delivered training session.Also repeat sessions to maximise opportunity for attendance.Will be tailored to ICS needs as identified by the previous workshops (see Section 1.33).Will cover ICS procedures for incident management & interface with processes not wholly encompassed by ITSMS Phase 1 (eg service requests, change management, and other issues surfaced at the workshops).

Service Requests

Service Desk will have ownership of Service Requests. SH

This means that any new Service Requests raised as Requests for Changes (RFC) should be coordinated by the Service Desk. This should complement the Change process by providing standard templates and guidance for the creation of new Service Requests as described in the following table:

Standard template for TouchpaperOnline form Fields to include:

Manadatory fieldse.g. Username

Workflow Assigned groupActionStatusTime requiredIncident Notes

Closing information Template for return to UserOperational Information requirementsTraining requirements for Service Desk staff Details of FAQs

Training resources etcIncident categorisation opening For automated classification


Paper ITSMS Project

Incident categorisation closing For automated classificationCMDB relationships For automated classification

R 51 All User facing Service Requests will be processed via the Service Desk,

R 52 Service Desk will have ownership of all Service Requests.

Table of SR and units involved SH

See Appendix

Standard template to be established in Touchpaper. SH,BY

R 53 A standard template will be used within Touchpaper as a form for Users to log a Service Request.

Workflow for top 10 SRs SH

R 54 Touchpaper Hot Topics to be used for top Service Requests. SH

List of main Service Requests SH

In Phase 1 of the ITSMS project the top 10 Service Requests will be entered into Touchpaper. A Service Request has been chosen for each Service delivered by ICS. The proposed list is shown in the table below:

Service Service RequestCentral Learning & Teaching Facilities Booking Request for Computer Training Room

Central Strategic Systems Access to Cognos / Register to use Cognos

Central Online Information Website Development

Consultancy & Project Management Request project management consultancy

Data storage Quota Increase

Desktop Request new software on SOE

Disability ICT support Request Special Software in IT Suites

Email Increase Mailbox Quota

ICT Training & Skills Development TS Request for Staff Training Course

Network Access Installation of new network outlets


Paper ITSMS Project

Service Desk / Directorate Services Student - New UserSoftware request (CD)

Telephony New Phone Request

Other Service Requests will also be recorded in Touchpaper however this will not be for full workflow. The import of Service Requests will be an ongoing activity.

Reporting on Service Requests for number per month, response time and User feedback. SH,DM

R 55 There will be reporting on Service Requests for volume, resolve time and User feedback.

Service Level Management SH,DM

Services DM/SH

R 56 The ICS services will be advertised on the Touchpaper Portal

ACTION: decision on wording of service descriptions

Each service offered by ICS features:o Training on how to access the service and make best use of it for your learning and teaching needso Ongoing development in line with University requirementso Prioritised support for Incidents accessible via the ICS ServiceDesk

Support charter will cover the supported environment as described by the list of ICS Services, outlined in the following table:

Service Description (previous) Description (revised)

Central Learning & Teaching Facilities

This service provides a range of facilities and services to support learning and teaching. It includes the provision of: ICT facilities in Lecture theatres; IT Suites of workstations; audio-visual equipment including video conferencing; and a small-group facility for staff training. Support for learning and teaching includes prioritised call-outs for lecturers, examinations & assessment and

Provision and control of facilities and equipment for learning and the delivery of teaching. This includes: ICT facilities in Lecture Theatres; IT Suites of workstations; audio-visual equipment including video conferencing; a small-group facility for staff training, examination & assessment support & video services.


Paper ITSMS Project

general support for core University software as well as video services.

Central Online Information

This service manages corporate online electronic information resources. For example, the University’s website provides outward-facing information about the University, accessible via the internet, and internal University information is available online via the University intranet. Anticipated future developments of this service include the provision of a University Portal for access to online information and business systems.

Management of corporate online electronic information resources. This includes: the University’s website which provides outward-facing information about the University accessible via the internet, and internal University information via the University intranet.

Central Business Systems (Note: change from Central Strategic Systems)

This service provides support and development of both core and second tier University business systems. Systems supported are Payroll, Personnel & Planning (P3), Financial Management, Student Management, Email, eDirectory Services, Estates Management, Residences Management, Oracle Database Management . Interruption to these core services will have a major impact on the business of the University. The service is large scale and used off campus and on all of the University campuses.

Support and development for core and second tier University high-dependency business applications. This includes: Payroll; Personnel & Planning (P3); Financial Management; Student Management; Email; Directory Services; Estates Management; Residences Management; Oracle Database Management.

Consultancy & Project Management

This service provides support for major developments and changes to University business processes that currently or potentially utilise ICT systems, supporting continuous improvement and quality assurance; it may involve the use of business analysis, project management and leadership, and programme coordination methods to ensure high quality outcomes are delivered in a timely and effective manner and give value for money.

Provision of business analysis and project management for major ICT-related developments, and support of continuous improvement and quality assurance. This service includes: requirements gathering; options appraisal; feasibility assessment; business case development; present/future state process modelling; effort, time & costs estimation; cost benefit analysis; value for money; impact assessment, and the use of PRINCE2 methods to control the delivery of major business changes to budget and timescales.


Paper ITSMS Project

Data storage Provision and control of storage that is accessible via the University’s network, management of data and backup procedures.

Desktop Desktop Services provide advice, support and management for agreed standard desktop hardware and software, as part of a managed environment for University of Dundee staff and students. Desktop Services aim to provide secure and reliable access to University ICT systems in support of the University’s administration, research and learning & teaching functions.

Desktop Services provide advice, support and management for agreed standard desktop hardware and software, as part of a managed environment for University of Dundee staff and students. Desktop Services aim to provide secure and reliable access to University ICT systems in support of the University’s administration, research and learning & teaching functions.

Disability ICT support

This service provides, in collaboaration with other departments, ICT support and advice for those with disabilities. It includes: provision of specialist support for students and staff, and visitors, with dyslexia and disabilities; provision and support of an IT Suite for students with disabilities; monitoring, evaluation of, and provision of University guidance on, compliance with disability legislation; provision of advice on, and assistance with purchase of, assistive technology; C & IT support for staff in the Disability Services Unit and the Scottish Disability Team, including management of C & IT requirements and purchasing; and training.

Provision of ICT solutions, support and advice for those with disabilities. This includes: specialist support for students, staff and visitors with dyslexia and other disabilities; specialist IT Suite for students with disabilities, guidance on assistive technology, and guidance on compliance with disability legislation.

Email Service to provide email functionality and mailbox to all staff and students og the University. All mailboxes are hosted on resilient hardware and email is routed via resilient message transfer agents. Users can access their email using GroupWise clients for Windows and Apple Macintosh and via webmail. This service provides additional functionality in the form

Provision of resilient email functionality and mailbox for all staff and students of the University. This service covers Windows and Apple Macintosh clients and access from the Internet and includes: email; calendaring; task management; address books; spam mail detection and gateway virus detection.


Paper ITSMS Project

of calendaring, task management and address books. Suspected spam is identified and delivered to client Junk Mail folders and virus checking on the gateway ensures that no infected messages are accepted. Interruption to this service, however slight, will have a major impact on the business of the University. The service is large scale and used both off campus and on all of the University campuses.

ICT Training & Skills Development

This service provides the training and development as part of the University's skills development programme. It includes: provision of specialist support for students and staff, and visitors, with dyslexia and disabilities; provision of training related to disability requirements (e.g. training on assistive technology, training of University IT staff on addressing disabled needs); tutor-led courses for Microsoft Office, GroupWise and other University systems, provided for University staff; provision of self study materials to help improve computer skills at people’s own pace and within their own time limits; ICS is an accredited European Computer Driving Licence (ECDL) testing centre for this internationally recognised qualification; provision of tailored courses specific to department needs Co-ordination and administration of the ITi; C&IT induction training for students; end-User service documentation; ICS will provide a skills framework to be made available to other University department employing C&IT staff in order to promote and manage C&IT-related professional development and training; Staff C&IT induction; provision,

Provision of training and development as part of the University's skills development programme. This includes: tutor-led courses and self-study materials for services and software provided by ICS; bespoke courses tailored for specific needs; European Computer Driving Licence (ECDL) testing; co-ordination and administration of ITi C&IT induction training for entrant students, and provision of a skills framework for other University departments employing C&IT staff.


Paper ITSMS Project

maintenance and development of a specialised facility for tutor-led IT training

Network Access

This service provides the infrastructure and support for provision of a network connection to students and staff of the University to enable access to the internet, file storage, email, VLE, applications software and data. This is a high priority service on which many business critical activities of the University depend. Interruption to service will have a major impact on the business of the University. The service is large scale, used in every part of the University Campuses.

Provision and support of a resilient network infrastructure to connect ICT devices. This service includes: wired access in all University buildings; wireless access in all learning & teaching areas.

Service Desk This service is a Single Point of Contact between Users and ICS. The Service Desk handles all Incidents and Service Requests, provides first line User support, is responsible for Incidents and supplies management information. It also provides an interface for other activities such as Change, Problem, Release and IT Service Continuity Management.

Provision of a Single Point of Contact for all ICT queries between Users and ICS. This includes: handling all Incidents and Service Requests; provision of first line User support; taking responsibility for Incidents.

Telephony This service provides IP telephony and specialist telephony (e.g. ISDN) to staff, and emergency telephony via PABX to staff and students of the University to enable effective conduct of the University’s business. This is a high profile and high priority service on which many business critical activities of the University depends. Interruption to service, however slight, will have a major impact on the business of the University. The service is large scale, used in all of the University campuses.

Provision and control of facilities and equipment for learning and the delivery of teaching. This includes: ICT facilities in Lecture Theatres; IT Suites of workstations; audio-visual equipment including video conferencing; a small-group facility for staff training, examination & assessment support & video services.

Each Service will contain sub-services, as shown in the table below:


Paper ITSMS Project

Service Sub-service Team Team members Remarks

Central business systems

Associate Users Administration Entire unit –Lynne ChristieCatherine HullLorraine DuffyEve SwinleyLinda Kolacz Jean StewartLynne O'ConnorAmanda Cummings


Botanics


Coda Database apps Stephen Elwell-Sutton, Judith Goligher, Camilla Grannum, Steven Jones


Cognos Database apps Stephen Elwell-Sutton, Judith Goligher, Camilla Grannum, Steven Jones


DHCP (from Departmental support staff only)

eDirectory team Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift

Except allocation of addresses - dependent on IP, covered either by Ops (IT Suites, Park Place, ICS Matthew) or Departmental Support


Disabled accounts Operators Mike Berry, Blair Finlay, Alison Norrie, Sandy Norrie


eDirectory account management



eDirectory rights eDirectory team Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift


eVision Database apps Stephen Elwell-Sutton, Judith Goligher, Camilla Grannum, Steven Jones

If requested


Gladstone Database apps Stephen Elwell-Sutton, Judith Goligher, Camilla Grannum, Steven Jones


Health Service Database apps Stephen Elwell-Sutton, Judith Goligher, Camilla Grannum, Steven Jones


Home directories Operators Mike Berry, Blair Finlay, Alison Norrie, Sandy Norrie


ID cards Database apps Stephen Elwell-Sutton, Judith Goligher, Camilla Grannum, Steven Jones?


Imanager (from Departmental support staff only)



LDAP authentication eDirectory team Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift


Life Sciences finance Database apps Stephen Elwell-Sutton, Judith Goligher, Camilla Grannum, Steven Jones?


Login authentication eDirectory team Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift


Netstore eDirectory team Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift


Paper ITSMS Project


Oracle Database apps Stephen Elwell-Sutton, Judith Goligher, Camilla Grannum, Steven Jones, Damien McGuinness


PAMS (P3) Database apps Stephen Elwell-Sutton, Judith Goligher, Camilla Grannum, Steven Jones, Damien McGuinness


Password portal eDirectory team Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift


Raisers Edge Database apps Stephen Elwell-Sutton, Judith Goligher, Camilla Grannum, Steven Jones, Damien McGuinness


SLP (from Departmental support staff only)



SMS (SITS) Database apps Stephen Elwell-Sutton, Judith Goligher, Camilla Grannum, Steven Jones, Damien McGuinness

If requested


Student quotas Operators Mike Berry, Blair Finlay, Alison Norrie, Sandy Norrie


ZENworks server side issues (from Departmental support staff only)


Central learning & teaching facilities

AV support (fixed infrastructure)

VTeCS VTeCS team


Exams Exam team Steve Aitken, Ewan Munro


IT Suite environment Teaching support team

Entire unit IT Suite issues


Learning & teaching Teaching support team

Entire unit


Lecture theatre Fast response team

Steve Aitken, Ewan Munro, VTeCS team


Pay2Print Print service team

John Hough, Andy Swiffin


Portable AV equipment VTeCS VTeCS team


Print toners in IT Suites Operators Mike Berry, Blair Finlay, Alison Norrie, Sandy Norrie


Printers on PrintService queues

Print service team

John Hough, Andy Swiffin


User accounts (including -t teaching accounts)

Teaching support team

Entire unit


Video conferencing VTeCS VTeCS team


Paper ITSMS Project


Wireless support for teaching rooms/IT Suites?

Fast response team

Steve Aitken, Ewan Munro, VTeCS team

Central online information

Hermes SOMIS team Charles Christacopoulos, Julie Christie


ICS communications Information Officer

Julie Christie


ICS Web page queries Information Officer

Julie Christie


New web site? ? ?


Personal web pages Web dev team Entire unit


RAE support ? ?


SOMIS services SOMIS team Charles Christacopoulos, Julie Christie


SRIS ? ?


University portal ? ?


University web page queries

Web dev team Entire unit


VLE down/slow Servers team Entire team Service Desk can resolve other problems or refer to Learning Centre


Web down/slow Servers team Entire team


Web services Web dev team Entire unit

Consultancy & project management

Business analysis Business Improvement team

?


Consultancy for users with no S3 agreement (chargeable)

Desktop team Entire unit


Liaison - ICS & Colleges/Central Admin

Liaison Officers List to be supplied by Dave Murie


Network consultancy Network infrastructure team

Entire unit


Project management Business Improvement team

?


Quality assurance Business Improvement team

?


Supporting ICS strategic plan

Business Improvement team

?

Data storage Application hosting Servers team Entire team

Data storage Application specific services Servers team Entire team

Data storage Backup and restoration services

Operators Mike Berry, Blair Finlay, Alison Norrie, Sandy Norrie

Data storage Data operations ? ?

Data storage DNS Servers team Entire team

Data storage Engineering ? ?

Data storage Legacy services ? ?


Paper ITSMS Project

Data storage Operations ? ?

Data storage Restorations Operators Mike Berry, Blair Finlay, Alison Norrie, Sandy Norrie

Data storage Server quota Servers team Entire team E.g. out of space

Data storage Servers down/slow Servers team Entire team

Data storage UNIX Servers team Entire team

Data storage UNIX account creation/details


Desktop Hardware support Desktop team Entire unit

Desktop SOE desktop support Desktop team Entire unit For staff members who have S3 agreements

Desktop Student profiles Desktop team Entire unit

Desktop Windows SOE for PC (including login scripts)

Desktop team Entire unit

Disability IT support

Disability support Disability support team

Andy McMahon, Norma Rodley Including disability support for exams

Email All email issues except "Generic email" (online form) or GroupWise quota (online form)

email admin team

Alan Gauton, John Hough, Brian Russell, Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift, Tobi Wood

Email Blackberry support Blackberry support

Mary Shrimpton, Ian Swift, Tobi Wood, John Houh, +Admin??

Email Email administration email admin team


Email Email backups and restore email admin team


Email Email client update email admin team


Email Email client usability email admin team


Email Email gateways email admin team


Email Email routing email admin team


Email Email servers email admin team


Email Email storage email admin team


Email Email user support email admin team


Email Generic email (online form) Operators Mike Berry, Blair Finlay, Alison Norrie, Sandy Norrie

Email GroupWise quota (online form)



Paper ITSMS Project

Email Secure IMAP email admin team


Email Secure webmail email admin team


Email Spam and virus filtering email admin team


Email University email account email admin team


ICT training & skills development

IT induction (ITi) ITi team Steve Aitken, Anne-Marie Greenhill, Dave Murie, Emily Patterson


Training queries Training team Steve Aitken, Ewan Munro, Norma Rodley


Training room Training team Steve Aitken, Ewan Munro, Norma Rodley

Network access Access to JANET/Internet ?

Network access Access to UoD network Network infrastructure team

Entire unit

Network access Building security ? ?

Network access DHCP - allocation of addresses


Network access Equipment rooms Network infrastructure team

Entire unit

Network access FaTMAN-specific services Network infrastructure team

Entire unit

Network access IT security Network Security team

Simon Bennett, Bob McGregor, Alastair MacPherson, Mark Williams

E.g. network abuse, firewall, etc., but not physical security such as alarms, doors, etc.

Network access JISC RSC services ? ?

Network access Liason with Estates & Buildings (on infrastructure)

Network infrastructure team

Entire unit

Network access Netcomms project Netcomms management

Chris Reid, Mike Whitehead

Network access Network access specialist servers


Entire unit

Network access Network core Network infrastructure team

Entire unit

Network access Network issues Network infrastructure team

Entire unit

Network access Network management Network infrastructure team

Entire unit

Network access Network monitoring Network infrastructure team

Entire unit


Paper ITSMS Project

Network access Network security Network Security team


Network access Operation of UoD network Network infrastructure team

Entire unit

Network access Operations ? ?

Network access Remote off-campus access Network infrastructure team

Entire unit

Network access Residences - student network


Entire unit

Network access Specific network access requirements


Entire unit

Network access VPN queries Network Security team


Network access Wired IPT support Network infrastructure team

Entire unit

Network access Wired network access Network infrastructure team

Entire unit

Network access Wireless network access Network infrastructure team

Entire unit

Purchasing Licence certificates Administration Entire unit –Lynne ChristieCatherine HullLorraine DuffyEve SwinleyLinda Kolacz Jean StewartLynne O'ConnorAmanda Cummings

Purchasing Licence purchase Administration Entire unit –Lynne ChristieCatherine HullLorraine DuffyEve SwinleyLinda Kolacz Jean StewartLynne O'ConnorAmanda Cummings

Purchasing Network forms for charging Administration Entire unit –Lynne ChristieCatherine HullLorraine DuffyEve SwinleyLinda Kolacz Jean StewartLynne O'ConnorAmanda Cummings

Service Desk Complaints Directorate Tom Mortimer

Telephony Emergency telephone provision - via PABX

Administration Entire unit –Lynne ChristieCatherine HullLorraine DuffyEve SwinleyLinda Kolacz Jean StewartLynne O'ConnorAmanda Cummings


Paper ITSMS Project

Telephony IP telephone provision Administration Entire unit –Lynne ChristieCatherine HullLorraine DuffyEve SwinleyLinda Kolacz Jean StewartLynne O'ConnorAmanda Cummings

Telephony Phone administration Administration Entire unit –Lynne ChristieCatherine HullLorraine DuffyEve SwinleyLinda Kolacz Jean StewartLynne O'ConnorAmanda Cummings

Telephony Specialist telephony provision

Administration Entire unit –Lynne ChristieCatherine HullLorraine DuffyEve SwinleyLinda Kolacz Jean StewartLynne O'ConnorAmanda Cummings

[DM] Table replaced in line with feedback from ICS-MT and workshops, and following further discussion by the project team.

Using the Touchpaper prioritisation matrix for Urgency and Impact we will establish internal response times. DM

Matrix showing prioritisation DM

Priority could be classified as Low, Medium or High, and needs to be determined by urgency plus impact plus availability of resources. It may also be contingent on other factors where relevant.

Urgency is an assessment of the speed with which an Incident requires resolution.

Impact reflects the likely business effect the Incident will have on the service.

Low Medium HighStandard 2 days [DM] 2 days [DM] 2 days [DM]Important 2 days [DM] 1 day 1 dayUrgent 1 day 1 day 1 hour [DM]

R 57 Response times will be trialled within ICS according to the response times matrix.


Paper ITSMS Project

Use Touchpaper to support automated escalation of Incidents. DM

Actions for each level of escalation within Touchpaper SH/DM

R 58 Each Escalation within a response level will be associated with escalation actions.

[DM] In response to feedback from ICS-MT and the Response Times workshop, a notional “fix” time matrix will also be implemented, with escalation actions to assist analysts prioritise their work.

Low Medium HighStandard 10 days 10 days 10 daysImportant 10 days 5 days 5 daysUrgent 5 days 5 days 5 hours

Escalation actions can specify:

• Notifications – messages and destinations for the messages • Reassignments – assigning the process to a different person for progressing • Changes in priority • Changes in associated colour

In phase 1, only response actions will be used. There will be an option to develop Resolution actions at a later date (mainly for Service Requests).

Response action:There will be 1 escalation action within the User Response escalation. This will happen after 4 hours, and will send an email to the Assigned Analyst, reminding them to contact the End User.

Notification Reassignment Priority change Colour change1 min +1 Green12 hours +1 Amber80% Analyst, IM15 hours IM, Management

team+1 Red

100% Incident Manager

The 12 hour and 15 hour actions are based upon 4 hours to breach and 1 hour to breach respectively. These ratios will also be used in all other Response Levels.

Equivalent times and actions will be configured for other response levels (2 days, 1 day and 1 hour):


Paper ITSMS Project

Response timesPriority Low (2 days) Medium (1 day) High (1 hour)Amber trigger (80%) 12 hr 48 min 6 hr 24 min 48 minRed trigger (91.7%) 14 hr 40 min 7 hr 20 min 55 min

Fix timesPriority Low (10 days) Medium (5 days) High (5 hours)Amber trigger (80%) 64 hr 32 hr 4 hrRed trigger (91.7%) 73 hrs20 mins 36 hr 40 mins 4 hr 35 min

Use Touchpaper MI and Crystal Reports to establish reporting by Incident Type and Response times. DM

List of reporting requirements DM

Use Touchpaper to support the ICS Liaison process. DM

Requirements for the ICS Liaison process DM

Implementation to support capture of liaison issues, and to permit both structured reports and ad hoc queries for Liaison Officers and management team.

Configuration Management

Establish high level structure for CMDB and map this is Touchpaper. CR

Planning the CMDb in Touchpaper

The implementation of Touchpaper is being carried out in several phases. In the current Phase 1, we need to establish a minimal CMDb, but to do so we also need to have some idea of the eventual full structure requirements. Therefore the outline of a full structure is considered here first, and then consideration given to which parts are needed for Phase 1.

Full CMDb implementation

The CMDb structure should reflect the relationships between services, software and hardware. It should also facilitate the final sign-off of Incidents.To start with supported Users, they are part of an organisational unit.The organisational unit has a contract with ICS to deliver certain services.Users see these services delivered by means of a desktop, which in turn runs on local hardware.The local hardware is connected via the network to enable the desktop to communicate with back-end software (or directly onto the Internet).This back-end software runs on virtual or actual servers, and may depend on separate storage systems.So a proposed high-level structure for the CMDb could be:


Paper ITSMS Project

a) Users (within Organisational Units) – e.g. U/G students, Finance staff

b) Services (and their Functional Components) – The 12 ICS Services

c) Desktop components – e.g. Local operating system, locally run applications

d) End User hardware – e.g. User’s PC, printer, IPT handset

e) Network/communications infrastructure – e.g. Cabling, switches, links to FaTMAN

f) Back-end Software – e.g. DbMS, server operating system, mail gateway software

g) Virtual or physical Server & Storage Systems – e.g. SAN, partition on a server

Note:The environment (locations, cabling, power, etc.) underpins all the physical devices above.OLAs and maintenance contracts with external suppliers underpin all of the above.Documentation will be held on Services, Operations, Contracts, etc.Each of these high levels will be further sub-divided, as the example shown in Appendix 1


Paper ITSMS Project


Paper ITSMS Project

Phase 1 implementation

R 59 A minimal implementation is all that is possible within the Phase 1 timescale, and will utilise data already being captured.

While there are some 30 databases currently maintaining some CMDb-type data, only the following are proposed for linking to the CMDb:

a) Users - User data will be imported from eDirectory every night. Appendix 2 shows a proposed mapping between Touchpaper attributes and those from eDirectory. It is unclear at this point how Touchpaper distinguishes between End Users and Analysts.

b) Services – These will be manually entered as part of the Touchpaper setup. It may be necessary to distinguish between the Functional Components of, for example, Central Strategic Systems.

c) Desktop components – No desktop data is proposed to be stored.

d) End User hardware – Currently eDirectory Workstation Objects captures information only from workstations running the SOE. Zen Inventory is imminently to be implemented, but initially for a restricted range of machines. Appendix 3 shows the attributes that can be captured. HDBrowser currently supplies a wider range of information about workstations, and it is therefore not proposed to store any information on workstations.

e) Network/communications infrastructure – No network data is proposed to be stored, pending implementation of the iTRACS system.

f) Back-end software – It is proposed that a simple list of major software applications be compiled and linked to the servers (and virtual servers) on which they run.

g) Virtual or physical Server & Storage Systems – Again it is proposed that a simple list of servers (and the partitions they are divided into) be compiled and stored in the CMDb.

h) Environment – No environmental data is proposed to be stored, pending implementation of the E&B asset management system.

i) Operations and Maintenance Contracts – As the Service Definitions are developed, it is expected that their dependency on Operations and Underpinning Contracts will be stored in the CMDb.

j) Documentation – No documentation is proposed to be stored.

Further development of the CMDb

A major project will be required to consider and implement the further development of the CMDb. Zen Asset Management will no doubt be a major tool for capturing information about the hardware connected to the network, and the software running on it. The iTRACS cable management system will supply information about the network cabling. And all the diverse currently-maintained configuration databases should be incorporated into the CMDb.


Paper ITSMS Project

Consultation SH

Management team SH

The ICS Management team will be consulted in advance of ICS staff to ensure consistency with the project deliverables which were identified by the ICS Management team during the Initiation workshop held 12th December 2006.

Analysts - workshops SH

In the Analysis stage of the ITSMS Phase 1 project all ICS staff will be consulted on the design of the ITIL Service Desk and Incident Management supported by Touchpaper.

To ensure that the project makes appropriate consultation to allow staff to give input and get the most benefit, the project team are proposing the following workshop format.

Content

Workshops will be focused on specific outputs and areas of interest.

Topics:

Roles and responsibilities The Service Desk - Single Point of Contact The Incident Management Process Incident Categories Response Times Portal Design Knowledge (the process, FAQs and Hot Topics) Problem Solving Service Requests The Configuration Management Database

Workshop format

The workshop will be run over a morning or afternoon and will be split into 2 parts. The first part with provide the necessary background information to allow participations to the required input. The second part will be interactive and will very from workshop to workshop depending on the output required.

The table below is intended to give an overview of the workshop structure.

Item Time allowedPart OneWorkshop ground rules 10 minsTouchpaper demonstration 30 minsDefinitions and background (supported by a fact 20 mins


Paper ITSMS Project

sheet)Objectives / deliverables 10 minsCoffee and biscuits 20 minsPart TwoInteractive workshop

Roles

The workshop will have a leader, a member of the ITSMS project team and will be assisted by a facilitator.

The facilitator will have the responsibility for taking the notes and a record of decision making and circulating these back to the group for approval within 1 week.

Participants will be expected to make an innovative, constructive and supportive contribution to the workshop teams to help achieve the necessary outputs (defined at the start of the workshop).

Participant selection

Project Liaison Officers will be asked to communicate with Unit Heads to organise participants for the workshops. Each unit will be invited to propose a participant for each workshop. All ICS staff will be given the opportunity to participate so if there are more unit members than workshops the unit should send 2 staff to one or more of the workshops.


Paper ITSMS Project

Appendix

Introduction

eDirectory fields and rights EP

School IT Analysts EP

The following list of School IT Support Analysts is a current working list compiled by Helpdesk staff through knowledge of ICS school contacts. ICS Communication Officer will compile and maintain an accurate list of School IT Analysts agreed with the Schools.

School Contact Phone/Ext E-mailApplied Computing Andy Cobley 85078 [email protected].

ukArchitecture Hugh Campbell 85267/85374 [email protected] Angela Dunsire 88815 [email protected] Health Sciences

Kevin Moran 2-20007 [email protected]

Dental Paul Hughes 2-35779 [email protected] of Jordanstone

Paul MacKinnon – DesignPeter Bevan – MAI/TVI

8537085334

[email protected]@dundee.ac.uk

Engineering (EP) Dave Husband – CivilDave Allan – Electrical

8435884392 or 84393 or

88611


Education & Social Work

Linda KolaczGeorge MarkieGeorge MassieFiona BattlesLee MilbyRoss Haggart

71-424471-433571-439671-431371-430571-4212

[email protected]@[email protected]@[email protected]@dundee.ac.uk

Law Mark Cargill 84600 [email protected] Library Eddie Delaney

Karin Culley8518185181


Life SciencesIan TennantPaul O’ConnorBarry CaudwellKiran OzaJessica Probst

8422784249842498424984249

[email protected]@[email protected]@[email protected]

Medical Computing Ann FentonJill Martin

2-325642-32564


Medical Education(Tay Park)

Don Cathcart 81960 [email protected]

Nursing Corinna Mollison 85904 [email protected] John Morris 84621 [email protected] Iain Gordon 84040 [email protected]


mailto:[email protected]




Paper ITSMS Project

School Support (End User)

The following list of School/Department Support (End User) is a current working list compiled by Helpdesk staff through knowledge of ICS school contacts. ICS Communication Officer will compile and maintain an accurate list of School/Department Support (End User) agreed with the Schools.

Admissions Bruce McBay 85085 [email protected]

CALS Bridget Cook 85173 [email protected]

Estates & Buildings Karen Brough 88363 [email protected]

EVision/SITS Martin GloverKeith Duncan

8554985665


Finance Shelia AlexanderYvonne Howarth

8522385186


Gardyne Library John McCaffery 71-4264 [email protected]

History Sara Reid 84512 [email protected]

Registry Pat HarrisonNorma Stewart

8537685392


Town & Regional Planning

Tracey Dixon 85241 [email protected]

VLE Margaret AdamsonRichard Parsons

8431784265


Touchpaper categories and lists

Departments EP

Locations SHSite BuildingMain City Campus Airlie Place, 1Main City Campus Airlie Place, 10Main City Campus Airlie Place, 12Main City Campus Airlie Place, 14Main City Campus Airlie Place, 15 - Rear Squash CourtsMain City Campus Airlie Place, 16-18Main City Campus Airlie Place, 2Main City Campus Airlie Place, 4Main City Campus Airlie Place, 6Main City Campus Airlie Place, 8Main City Campus Airlie Place, Odds 3-15Main City Campus Ash Street, 17A Main City Campus Belmont Hall Block G, Belmont TowerMain City Campus Belmont Hall Block H, Balfour FlatsMain City Campus Belmont Tennis CourtsMain City Campus Biological Sciences Institute Main City Campus Fulton - BoilerhouseMain City Campus Bonar HallMain City Campus Caird House






Paper ITSMS Project

Main City Campus Caird House Cottage Main City Campus Carnegie Main City Campus CarnelleyMain City Campus Chaplaincy CentreMain City Campus Civils Link (Geotechnical Extension)Main City Campus Computing CentreMain City Campus CrawfordMain City Campus Crawford, BungalowMain City Campus Crawford, Studio AMain City Campus Crawford, Studio BMain City Campus Cross Row, 1Main City Campus Cross Row, 3Main City Campus Dental HospitalMain City Campus Dental SchoolMain City Campus Dundee Contemporary Arts Centre

Main City CampusDundee University Students Association (DUSA)

Main City Campus Estates & Buildings Main City Campus EwingMain City Campus Ewing AnnexeMain City Campus Fleming Gymnasium Main City Campus FranklandMain City Campus FultonMain City Campus Greenfield Place, 3/3a Main City Campus Greenfield Place, 7 Main City Campus Harris EastMain City Campus Harris Jute Shed Main City Campus Harris NorthMain City Campus Hawkhill Glasshouses EastMain City Campus Hawkhill Place, 5-7 Main City Campus Incubator 2Main City Campus LibraryMain City Campus MatthewMain City Campus Medical Sciences InstituteMain City Campus Microcomputer CentreMain City Campus Nethergate, 162Main City Campus Nethergate, 164Main City Campus Nethergate, 166Main City Campus Belmont New Student Residences Main City Campus Heathfield New Student Residences Main City Campus New Teaching BlockMain City Campus Old Medical SchoolMain City Campus Old Technical Institute (OTI)Main City Campus OMS-Carnelley LinkMain City Campus OTI College Hall PG CentreMain City Campus OTI College ShopMain City Campus OTI Resource Centre Main City Campus Park Wynd 15 (Jam Factory)Main City Campus Park Wynd 2-8 site only (OTC building)Main City Campus Perth Road 11Main City Campus Perth Road 1-3Main City Campus Perth Road 21Main City Campus Perth Road 23/25 Main City Campus Perth Road 2A & 4Main City Campus Perth Road 8 Main City Campus Peters BuildingMain City Campus Peterson Hall - North Block Main City Campus Peterson Hall - South Block

Main City CampusPeterson Hall (Inc Greenfield Place 3a,7,8)

Main City Campus Queen Mother Building Main City Campus Roseangle 27 Main City Campus Roseangle 4 Main City Campus Roseangle 5 Main City Campus Roseangle 6


Paper ITSMS Project

Main City Campus Roseangle 7 Main City Campus ScrymgeourMain City Campus Scrymgeour ExtensionMain City Campus Seabraes Lane 1Main City Campus Seabraes Residences, Roseangle Main City Campus Sir James Black Building Main City Campus Sports Biomedicine Building Main City Campus Sports CentreMain City Campus Springfield 10 Main City Campus Springfield 11Main City Campus Springfield 12Main City Campus Springfield 13Main City Campus Springfield 15/16 Main City Campus Springfield 17Main City Campus Springfield 18Main City Campus Springfield 2Main City Campus Springfield 21Main City Campus Springfield 22Main City Campus Springfield 23Main City Campus Springfield 24Main City Campus Springfield 26Main City Campus Springfield 28Main City Campus Springfield 4Main City Campus Springfield 7Main City Campus Springfield 8 (G Floor Flat)Main City Campus Springfield 9Main City Campus Structures LaboratoryMain City Campus TowerMain City Campus Tower ExtensionMain City Campus Well Road 11 Main City Campus Well Road 13 Main City Campus Well Road 7 Main City Campus Well Road 9

Main City Campus Wellcome Trust Biocentre

Main City CampusWest Hendersons Wynd Storehouse (Formerly Comet)

Main City Campus White Top Centre Riverside Riverside - Changing Rooms Riverside Riverside - Groundsmans House Riverside Riverside - Pavilion Riverside Riverside - Stores West Park & University House Perth Road 319 - Gardeners CottageWest Park & University House Perth Road 325 - Elmslea Cottage West Park & University House

Perth Road 325 - University House (Elmslea)

West Park & University House West Park 1 & 1A (Gardeners Cottages) West Park & University House West Park Conference Centre West Park & University House West Park Hall (Annexe block) West Park & University House West Park Hall West Park & University House West Park VillasTaypark Perth Road 480 - Taypark Lodge Taypark Perth Road 484 - Taypark House

Botanic GardensBotanic Gardens - Greenhouse & Boilerhouse

Botanic Gardens Botanic Gardens - Public Toilet BlockBotanic Gardens Botanic Gardens - Services Building

Botanic GardensBotanic Gardens - Tractor Shed & Ancillary Accom.


Paper ITSMS Project

Botanic Gardens Botanic Gardens - Visitor Centre

NinewellsBlackness Road, 430, Braeknowe + Annexe

Ninewells Ninewells Hospital & Medical School

Wimberley Wimberley Houses, Glamis Drive (houses 1-26)

HillsideHillside Halls of Residence, Flats 1-46 Menzies Hill

Taymills Taymills Block A see Mike SpenceTaymills Taymills Block B see Mike SpenceTaymills Taymills Block C see Mike SpenceTaymills Taymills Block D see Mike SpenceFife Fife College of Nursing & MidwiferyInchyra Inchyra Boat ShedGardyne Road Gardyne Road Residence - RedholmeGardyne Road Gardyne Road Residence - WestwoodGardyne Road Gardyne Road Residence - WinnocksGardyne Road Gardyne Road, Northern College Campus

Touchpaper Self-service Portal for logging, monitoring and tracking Incidents. JC,BY

Design of Portal JC,BY


Paper ITSMS Project

Tabbed layout (TP)Coporate design vs ICS/standalonedesignAccessibility considerationsUser needs/wantsHostingAdministration of siteDefinitionApplication

User categories for viewing

Single sign onMulti sign on like VLE

Sign on:

Technical

Testing

DesignStatus (see mindmap)Log a call (see mindmap)

Jobs

IncidentsProblemsChangesEasy/meaningful/understandableUser categories determine infodisplayed

Factors

Hot Topics (TP)

FAQs (ICS)Right AnswersAsk a question (TP)Publications & Policies (ICS)

Knowledge Centre

Additional news?Noticeboard (TP)

Call log a call via this areaService Information (ICS)LinksHow will we manage this?About usWork with usContact usProjectsIntranet

ICS

Components/modulesConfirmation of services

Awareness of services/subservicesMarketing/Education

IT Service Desk portal designproposal

From components/modules in overview mindmap.


Paper ITSMS Project

Job noServiceSub serviceDescriptionDate loggedLast updated

Summary

for analystsfor super users?

Technical notes

for all usersTracking informationEst date of delivery/closure

Detail (open a job)

Active jobsGenerate a job like this toolArchived jobs

Users (basic info)Super user (advanced info)Analyst (expert info)

Give enough info for the type of user

? Can a secretary log a call for theirsuperior?

User categoriesJob Status

From log a call in overview mindmap


Paper ITSMS Project

EasyPrepopulated with known informationDrop down boxes of predefined options

FactorsSuggest they search this first.

Knowlege CentrePrepopulated info

Select from a listAutomatically assigned

Service request/Quick Call

Clarifies their selectionis educated about our classifications

User:Summary description appears when aservice is selected

Service

Clarifies their selectionis educated about our classifications

User:Sumary description appears when aservice is selected

Sub service

Description of incidentRequires to be assigned by HD

Incident

Is it a:

MeSomeone elseFor a group egCollege/School/Dept/Unit

It's for:

FieldsLog a call

Service Requests

Service Desk will have ownership of Service Requests. SH

Table of SR and units involved SH

ICS

Uni

t

Use

r fa

cing

/ op

erat

ion

al

Mon

thly

vol

umes

Bus

ines

s Im

prov

emen

t

Co

rpo

rate

Info

rmat

ion

Sys

tem

s

Dir

ecto

rate

Ser

vice

s

He

lpde

sk

Ne

twor

k In

fras

truc

ture

Ser

vers

and

Sto

rage

Str

ate

gic

Info

rmat

ion

M

anag

emen

t

Tea

chin

g S

uppo

rt &

T

rain

ing

Wor

ksta

tion

& D

esk

top

Service Service Request


Paper ITSMS Project

Central Learning & Teaching Facilities

Booking Request for Computer Training Room UF 1

TS Provide Support for On-line Exams UF 1

TS New PC for New / Or Refurbished Lecture Room O 1

SR -t Request for Login Details UF 49 1

Printing - paper/toner replacement O 13 1

Central Strategic Systems

Application for access to eDirectory

O 1 Access to Additional

Data Services in Cognos UF 1

Access to Cognos / Register to use Cognos UF 1

Password Reset for Cognos UF 1

Access to Congos from Another Machine / Access Cognos from a Different Workstation UF 1

Enhancement Request for Cognos UF 1

Create New Database for Room Bookings 1

Delete Data or Records / SITS UF 1

Database Updates / Imports within SITS 1

Password Change for Student UF 1

Password Change for Teaching Account UF 1

New Associate User Account UF 1

Renew Associate User Account UF 1

eDirectory Rights Assignment for department support O 1


Paper ITSMS Project

eDirectory Rights Assignment for SOE management O 1

eDirectory Rights Assignment for ICS staff O 1

Workstation Import Assignment O 1

New DHCP Subnet O 1 Assign rights to

DHCP Subnet O 1 New IP Address

Assignment O 6 1 Change to

Student/Staff Codes O 60 Account Swap O 9 Account Merge O 1 PCounter release

station setup O 1 PCounter printer

setup O 1 Access to SITS O 1 eDir - Change User

details on account (e.g. surname) O 1

eDir - disable account O 1

Change password (staff) O

Central Online Information

Create a Publication

O 1 Create a Publication

in Alternative Format O 1 Department

Freedom of Information Request O 1

Website Updates O 1 Website

Development O 1 Mass Emailer about

an Issue or News O 1 Submit News for the

Weekly Update O 1 Consultancy & Project Management

Request project management consultancy UF 1

Request business analysis consultancy UF 1


Paper ITSMS Project

Data storage Quota Increase UF 6 1 File Restoration UF 4 1 Network

Administration Request for Unix Password UF

4

1 Additional Disc

Space on Netware Server UF

1 Change Backup

regimeO

1 1 Desktop Request new

software on SOE 1 Additional software

installation 1 Hardware repair 1 Disability ICT support

TS Special Software in IT Suites UF 1

Email Change of

Ownership of a Generic Mailbox UF 3 1

Create a Generic Mailbox UF 8 1

Increase Mailbox Quota UF 20 1

Create a Distribution List Containing External Addressess UF 8 1

Creation of a GW Distribution List from Scratch UF 8 1

ICT Training & Skills Development

TS Request for Staff Training Course

UF 1 Network Access

Changing the use of existing network outlets UF 1 1

Installation of new network outlets UF 8 1

Request Permission to Connect for a O 1


Paper ITSMS Project

server Changes to Firewall

Rules (to allow specific services) O 1

Disconnect a rogue system from the network O 1

Change edge switch port configuration O 1

Request change to DNS O 1

Service Desk Student - New User 76 1 Distance Learner -

New User 20 1 Student - Change

Password 49 1 Telephony Call Forward Setup UF 6 1 Catalogue Request UF 1

Change of Class of Service UF 7 1

New Phone Request UF 49 1

Password Change for Voicemail UF 6 1

Call Forward / Pick-up Groups UF 5 1

Change of Call Forward Number UF 1 1

Change of Name or Title UF 29 1

Password Change for Myphone UF 1 1

Request for Voicemail UF 10 1

Order a Blackberry UF 4 1

Order a Mobile Phone UF 2 1

Order International bundle - Blackberry UF 11 1

Directorate Services Travel booking O 8 1 Room booking O 4 1 Catering O 2 1 Returns O 9 1

Software request (CD) O 16 1

Purchasing - software O 6 1

Purchasing - hardware O 1

Maintenance O 4 1 Consumables O 8 1


Paper ITSMS Project

Training enquiries O 38 1

Configuration Management

Establish high level structure for CMDB and map this is Touchpaper. CR

A Organisational unitsU/G studentsP/G studentsStaff

Analysts

B ServicesFunctions

C Desktop componentsOperating systemsLocally-run applications

D End User hardwareDesktopsLaptopsTelephone handsetsPrintersOther peripherals

E Network/Communications InfrastructureCabling

Network outletWAP

Network equipmentTelephony

F Back-end softwareOperating SystemsDbMSApplications

G Server & storage systemsServers

PartitionsStorage systemsBackup systems

Operations

Underpinning ContractsSuppliers


Paper ITSMS Project

DocumentationSLAsOLAsContractsOther

LocationsCampus/Buildings/Floors/Rooms


Paper ITSMS Project

eDirectory Data

Touchpaper CMDb eDirectoryAnalyst End UserAttribute Re

marks

Attribute Remarks Attribute LDAP Name Description (Staff) Description (Students)

ID ID DUNUNIuserCode (new field created for TP use = workforceid with 1st char stripped out)

DUNUNIuserCode staff ID number student matric number

Name Name CN cn Login ID Login IDSurname Surname Surname sn surname surnameFirst Name First Name Given Name givenName first name (preferred

name if exists)first name

Title Title Title title Mr, Mrs, Miss, Dr etc STUDENT

Email Address Email Address

Internet EMail Address mail SMTP email address SMTP email address

Phone Phone Telephone number telephoneNumber registered internal telephone number

registered internal telephone number (postgraduates only)

Mobile Phone Mobile Mobile mobileType EmployeeType employeeType Clerical, Academic,

Associate, Honorary, Technical

UG, PG-Taught, PG-Research

Student Status

Employee Status employeeStatus blank Current, Pending, Normal Complete, Withdrawn, etc


Paper ITSMS Project

Department OU ou department name UNDERGRAD / POSTGRAD + college code + school code

College Organization for now, refined later

o P3 College code SITS College code

School departmentNumber for now, refined later

departmentNumber Department or school College code – School Code

Context DUNUNIobjectContainer (new field created for TP use = eDirectory context)

DUNUNIobjectContainer

TPUsertype TPUsertype DUNUNITPUserType DUNUNITPUserType

workforceid workforceid workforceid workforceid (M or X) + staff ID number

(U or P) + student matric number


Paper ITSMS Project

Appendix 3 – Hardware Configuration Information

Workstation Objects Zen InventoryNameIP Address IP AddressGroup membershipZenworks applicationsZenworks effective policiesZenworks associated policiesHistory of logged-in Users

ManufacturerModelModel numberAsset tagSerial numberProcessor familyOS typeOS versionNovell client versionMAC addressBIOS typeNIC typeMemory sizeDisk InformationVideo type


Design Document (1.69Mb Word).doc.doc

Technology

Transcript of Design Document (1.69Mb Word).doc.doc