Date post: | 14-Jan-2015 |
Category: |
Technology |
Upload: | billy82 |
View: | 1,108 times |
Download: | 0 times |
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
Page 1
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
Information & Communication Services
Page 2
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 3
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 4
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 5
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 6
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 7
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 8
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 9
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 10
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 11
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 12
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 13
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 14
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 15
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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.
Page 16
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 17
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 18
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 19
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 20
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 21
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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).
Page 22
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 23
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 24
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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.
Page 25
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 26
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 27
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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.
Page 28
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 29
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 30
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 31
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
Paper ITSMS Project
- Educate on changes to procedures e.g. Web Portal, phone, face to face desks
ICS Analysts
- Inform of benefits
- Educate ICS staff on changes to procedures
- Train on How to re-route to Service Desk from all methods of contact
Department IT Analysts
- Inform of benefits
- 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
- 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
Page 32
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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.
Page 33
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 34
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
Paper ITSMS Project
Page 35
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
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
Page 36
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 37
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 38
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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:
Page 39
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 40
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 41
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 42
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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.
Page 43
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 44
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 45
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 46
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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.
Page 47
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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.
Page 48
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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.
Page 49
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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.
Page 50
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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:
Page 51
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Central business systems
Botanics
Central business systems
Coda Database apps Stephen Elwell-Sutton, Judith Goligher, Camilla Grannum, Steven Jones
Central business systems
Cognos Database apps Stephen Elwell-Sutton, Judith Goligher, Camilla Grannum, Steven Jones
Central business systems
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
Central business systems
Disabled accounts Operators Mike Berry, Blair Finlay, Alison Norrie, Sandy Norrie
Central business systems
eDirectory account management
eDirectory team Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift
Central business systems
eDirectory rights eDirectory team Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift
Central business systems
eVision Database apps Stephen Elwell-Sutton, Judith Goligher, Camilla Grannum, Steven Jones
If requested
Central business systems
Gladstone Database apps Stephen Elwell-Sutton, Judith Goligher, Camilla Grannum, Steven Jones
Central business systems
Health Service Database apps Stephen Elwell-Sutton, Judith Goligher, Camilla Grannum, Steven Jones
Central business systems
Home directories Operators Mike Berry, Blair Finlay, Alison Norrie, Sandy Norrie
Central business systems
ID cards Database apps Stephen Elwell-Sutton, Judith Goligher, Camilla Grannum, Steven Jones?
Central business systems
Imanager (from Departmental support staff only)
eDirectory team Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift
Central business systems
LDAP authentication eDirectory team Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift
Central business systems
Life Sciences finance Database apps Stephen Elwell-Sutton, Judith Goligher, Camilla Grannum, Steven Jones?
Central business systems
Login authentication eDirectory team Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift
Central business systems
Netstore eDirectory team Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift
Page 52
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
Paper ITSMS Project
Central business systems
Oracle Database apps Stephen Elwell-Sutton, Judith Goligher, Camilla Grannum, Steven Jones, Damien McGuinness
Central business systems
PAMS (P3) Database apps Stephen Elwell-Sutton, Judith Goligher, Camilla Grannum, Steven Jones, Damien McGuinness
Central business systems
Password portal eDirectory team Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift
Central business systems
Raisers Edge Database apps Stephen Elwell-Sutton, Judith Goligher, Camilla Grannum, Steven Jones, Damien McGuinness
Central business systems
SLP (from Departmental support staff only)
eDirectory team Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift
Central business systems
SMS (SITS) Database apps Stephen Elwell-Sutton, Judith Goligher, Camilla Grannum, Steven Jones, Damien McGuinness
If requested
Central business systems
Student quotas Operators Mike Berry, Blair Finlay, Alison Norrie, Sandy Norrie
Central business systems
ZENworks server side issues (from Departmental support staff only)
eDirectory team Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift
Central learning & teaching facilities
AV support (fixed infrastructure)
VTeCS VTeCS team
Central learning & teaching facilities
Exams Exam team Steve Aitken, Ewan Munro
Central learning & teaching facilities
IT Suite environment Teaching support team
Entire unit IT Suite issues
Central learning & teaching facilities
Learning & teaching Teaching support team
Entire unit
Central learning & teaching facilities
Lecture theatre Fast response team
Steve Aitken, Ewan Munro, VTeCS team
Central learning & teaching facilities
Pay2Print Print service team
John Hough, Andy Swiffin
Central learning & teaching facilities
Portable AV equipment VTeCS VTeCS team
Central learning & teaching facilities
Print toners in IT Suites Operators Mike Berry, Blair Finlay, Alison Norrie, Sandy Norrie
Central learning & teaching facilities
Printers on PrintService queues
Print service team
John Hough, Andy Swiffin
Central learning & teaching facilities
User accounts (including -t teaching accounts)
Teaching support team
Entire unit
Central learning & teaching facilities
Video conferencing VTeCS VTeCS team
Page 53
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
Paper ITSMS Project
Central learning & teaching facilities
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
Central online information
ICS communications Information Officer
Julie Christie
Central online information
ICS Web page queries Information Officer
Julie Christie
Central online information
New web site? ? ?
Central online information
Personal web pages Web dev team Entire unit
Central online information
RAE support ? ?
Central online information
SOMIS services SOMIS team Charles Christacopoulos, Julie Christie
Central online information
SRIS ? ?
Central online information
University portal ? ?
Central online information
University web page queries
Web dev team Entire unit
Central online information
VLE down/slow Servers team Entire team Service Desk can resolve other problems or refer to Learning Centre
Central online information
Web down/slow Servers team Entire team
Central online information
Web services Web dev team Entire unit
Consultancy & project management
Business analysis Business Improvement team
?
Consultancy & project management
Consultancy for users with no S3 agreement (chargeable)
Desktop team Entire unit
Consultancy & project management
Liaison - ICS & Colleges/Central Admin
Liaison Officers List to be supplied by Dave Murie
Consultancy & project management
Network consultancy Network infrastructure team
Entire unit
Consultancy & project management
Project management Business Improvement team
?
Consultancy & project management
Quality assurance Business Improvement team
?
Consultancy & project management
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 ? ?
Page 54
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Operators Mike Berry, Blair Finlay, Alison Norrie, Sandy Norrie
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
Alan Gauton, John Hough, Brian Russell, Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift, Tobi Wood
Email Email backups and restore email admin team
Alan Gauton, John Hough, Brian Russell, Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift, Tobi Wood
Email Email client update email admin team
Alan Gauton, John Hough, Brian Russell, Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift, Tobi Wood
Email Email client usability email admin team
Alan Gauton, John Hough, Brian Russell, Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift, Tobi Wood
Email Email gateways email admin team
Alan Gauton, John Hough, Brian Russell, Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift, Tobi Wood
Email Email routing email admin team
Alan Gauton, John Hough, Brian Russell, Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift, Tobi Wood
Email Email servers email admin team
Alan Gauton, John Hough, Brian Russell, Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift, Tobi Wood
Email Email storage email admin team
Alan Gauton, John Hough, Brian Russell, Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift, Tobi Wood
Email Email user support email admin team
Alan Gauton, John Hough, Brian Russell, Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift, Tobi Wood
Email Generic email (online form) Operators Mike Berry, Blair Finlay, Alison Norrie, Sandy Norrie
Email GroupWise quota (online form)
Operators Mike Berry, Blair Finlay, Alison Norrie, Sandy Norrie
Page 55
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
Paper ITSMS Project
Email Secure IMAP email admin team
Alan Gauton, John Hough, Brian Russell, Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift, Tobi Wood
Email Secure webmail email admin team
Alan Gauton, John Hough, Brian Russell, Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift, Tobi Wood
Email Spam and virus filtering email admin team
Alan Gauton, John Hough, Brian Russell, Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift, Tobi Wood
Email University email account email admin team
Alan Gauton, John Hough, Brian Russell, Kevin Shrimpton, Mary Shrimpton, Andy Swiffin, Ian Swift, Tobi Wood
ICT training & skills development
IT induction (ITi) ITi team Steve Aitken, Anne-Marie Greenhill, Dave Murie, Emily Patterson
ICT training & skills development
Training queries Training team Steve Aitken, Ewan Munro, Norma Rodley
ICT training & skills development
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
Operators Mike Berry, Blair Finlay, Alison Norrie, Sandy Norrie
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
Network infrastructure team
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
Page 56
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
Paper ITSMS Project
Network access Network security Network Security team
Simon Bennett, Bob McGregor, Alastair MacPherson, Mark Williams
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
Network infrastructure team
Entire unit
Network access Specific network access requirements
Network infrastructure team
Entire unit
Network access VPN queries Network Security team
Simon Bennett, Bob McGregor, Alastair MacPherson, Mark Williams
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
Page 57
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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.
Page 58
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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):
Page 59
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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:
Page 60
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 61
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
Paper ITSMS Project
Page 62
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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.
Page 63
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 64
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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.
Page 65
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
[email protected]@dundee.ac.uk
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
[email protected]@dundee.ac.uk
Life SciencesIan TennantPaul O’ConnorBarry CaudwellKiran OzaJessica Probst
8422784249842498424984249
[email protected]@[email protected]@[email protected]
Medical Computing Ann FentonJill Martin
2-325642-32564
[email protected]@dundee.ac.uk
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]
Page 66
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
[email protected]@dundee.ac.uk
Finance Shelia AlexanderYvonne Howarth
8522385186
[email protected]@dundee.ac.uk
Gardyne Library John McCaffery 71-4264 [email protected]
History Sara Reid 84512 [email protected]
Registry Pat HarrisonNorma Stewart
8537685392
[email protected]@dundee.ac.uk
Town & Regional Planning
Tracey Dixon 85241 [email protected]
VLE Margaret AdamsonRichard Parsons
8431784265
[email protected]@dundee.ac.uk
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
Page 67
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 68
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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.
Page 69
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 70
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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.Page 71
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 72
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 73
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 74
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 75
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 76
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 77
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 78
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
Paper ITSMS Project
DocumentationSLAsOLAsContractsOther
LocationsCampus/Buildings/Floors/Rooms
Page 79
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 80
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 81
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023
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
Page 82
/tt/file_convert/54b569274a7959776c8b46ef/document.doc Printed 10/04/2023