Information & Communication Services ANALYSIS REPORT ITSMS Project – Phase 1 Release: Date: April 11, 2007 Author: Susan Hall Owner: Tom Mortimer Client: 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 issue 7 May 2007 26 April 2007 Changed response time table as per Workshop feedback DM Approvals - This document requires the following approvals: Name Signature Title Date of Version Page 1 /home/website/convert/temp/convert_html/54b569274a7959776c8b46ef/document.doc Printed 22/05/2022
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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:
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
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
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
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
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
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
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
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
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
Department Analysts EP..............................................................................................................67Touchpaper categories and lists..........................................................................................................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
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:
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.
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
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?
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
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
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:
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).
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
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
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.
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
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
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.
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
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.
- 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
Email
- Change all 2nd level email signatures to Service Desk contact details
- Direct all Incidents, Service Requests, Feedback, Comments from all University Web Pages to ICS SD via Touchpaper Web Portal.
- Direct all ICS generic email to Service Desk – Phase 2
R 34 Guidance and training will be provided to Users and Analysts on the SPOC for contacting ICS and how to deal with Users bypassing the Service Desk.
Common structured dialogue
R 35 Providing a common structured dialogue for all ICS staff at all levels of support to User Incidents and Requests.
Using a common technique presents a professional and well-structured support to the User and ensures nothing is forgotten.
This will include:
User ‘pickup’, i.e. agreed response times
Consistent User response dialogue for phone, face to face and email
R 37 The design of the Touchpaper Portal will cover all ICS Services and Support processes in place for these services.
ICS service catalogue
Centralstrategicsystems
Central Online
Information
Consultancy
CentralLearning &Teachingfacilities
ICS Service Desk
ICT Training
DisabilityICT Support
Email
Datastorage
DesktopServices
NetworkAccess
Telephones
R 38 The Service Catalogue will be published on the Touchpaper Portal
Knowledge Base MG, BY
Knowledge Process MG
R 39 There will be a process for maintaining the Knowledgebase
There will be two new procedures with the implementation of Knowledge Management, a procedure for adding to the Knowledge Base and a procedure for modifying or removing knowledge from the system. The steps and owners are shown in the following two tables.
Adding to Knowledge DatabaseStep Who
Data requirement (initiation from idea) User, SD, 2nd Level AnalystValue of data (frequency of question) SD - KM
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
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.
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:
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
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
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.
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
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.
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:
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
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.
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.
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.
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.
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:
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
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.
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.
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):
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:
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
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.
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
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.
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].
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.
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
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
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
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
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)