It Incident Management Escalation Log Book by mxo20919

VIEWS: 63 PAGES: 27

More Info
									   Grouping               Requirement



  Accessibility           Good Practice


  Accessibility         Keyboard Control

  Accessibility            Compatibility

 Administration        Continuous Operation
 Administration     Linking Configuration Items




 Administration      Administrative Interface


 Administration         Designing CMDB

 Administration     Global Expiry date for data
 Administration          Web Interface


 Administration        Workflow capability




 Administration        Site Independence
 Administration        Workflow capability
 Administration        Analyst Population

 Administration        Team Specific Expiry
 Administration          Fault Tolerance

 Administration          Load Distribution

 Administration             Upgrading




                    SLA & Service Catalogue
  Agreements              Integration


  Agreements               OLA & UPC



Analyst Interface        Impact Analysis
Analyst Interface      Manual Availability Flag


Analyst Interface     Changing Incident Values

Analyst Interface         Linking Incidents

Analyst Interface         Incident Logging


Analyst Interface        Repetitve Incidents



Analyst Interface         Incident Logging

Analyst Interface          Web Interface
Analyst Interface           Multi-homing
Analyst Interface          Incident Views

Analyst Interface   Proactive Problem Management

Analyst Interface        Standard Changes


Analyst Interface       Change Dependancies



Analyst Interface        Configuration Items



Analyst Interface        Knowledge Capture

Analyst Interface         Mandatory fields


Analyst Interface          Cross-reference

Analyst Interface    Splitting Incidents/Requests
Analyst Interface              Searching


Analyst Interface       Browser Compatibility

Analyst Interface     Parent-Child Relationships

Analyst Interface          Mass Changes



Analyst Interface           Contact Lists
   Analyst Interface               Responses


   Analyst Interface           Escalation prompting
                          Bifurcating workflow for single
   Analyst Interface                  incident
   Analyst Interface            Workflow capability

   Analyst Interface          Impact Analysis GUI

   Analyst Interface                 Booking


   Analyst Interface             Stop the Clock

   Analyst Interface            Linking Incidents
   Analyst Interface           Hand Held Devices

   Analyst Interface             Authentication
      Capacity                  Usage monitoring


       Capacity                    CI capacity

       Capacity                      Trends
  Configuration Items              Bulk Import

  Configuration Items               Baselines


  Configuration Items               Attributes

  Configuration Items       Discovery tool integration


         Cost              Recommended Specification
         Cost                      Cost

         Cost                  Additional Licenses

         Cost                    Licensing Model

         Cost                      Partitioning

Devolved administration   Devolved team administration

Devolved administration   Devolved CMDB administration

Document Management           Document referencing

Document Management            Document Storage
      Email          Incident & Request via Email


      Email               Team Assignment

      Email            Email alerts for analysts




      Email           Spam handling capabilities

      Email               Mail loop handling

      Email              Attachment handling

      Email                 RFC approvals
      Email             Email reverse look-up
                     Batch respond or batch apply
      Email                action to queries
      Email              Attachment handling

     Email              Received email editing
     Email                Emailing Records
     Email              Technical description
End User Interface         Web Interface
End User Interface             Phone
End User Interface        End user alerting

End User Interface       User visibility of calls

End User Interface      Browser Compatibility

End User Interface    Change Communications




End User Interface         MyEd integration



End User Interface    OracleAS portal integration



End User Interface    Preferred contact method
    End User Interface                    SMS Text

    End User Interface                Service Requests

    End User Interface                 Service alerting

    End User Interface                  User Surveys


    End User Interface                  Card Reading

    End User Interface                     Priority

    End User Interface             Public Knowledge Base

    End User Interface                 End user alerting



    End User Interface                Instant Messaging



    End User Interface          Computer Telephony Integration
    End User Interface            End user communication



      External Users                    External Users

         Financial                     Cost Categories
         Financial                        Costings

         Financial                     Time recording

         Financial                        CI Aging
         Financial                       Deprecation

        Financial                        Cost Types
        Generality                      Not IT Specific

        Installation               Discipline Independence


Integration with Institutions          User Population

Integration with Institutions         Analyst Population


   Integration with UAD                 Data Migration

   Integration with UAD                     Logins
  Integration with UoE              Data Migration




  Integration with UoE             Login via EASE

  Integration with UoE          Authorisation Hand-off


  Integration with UoE     Link to Event Monitoring Systems

  Integration with UoE        EDINA License Integration

  Integration with UoE            Link to EdLAN DB

      Localisation               Local Workarounds

     Management                     Team Visibility



     Management                 Automatic Escalations
     Not Required                    Informatics
     Not Required                      EDINA
     Not Required              IS Applications Division

     Not Required                     Reporting


     Performance                   Responsiveness

Procurement Stipulations           Extant Software

       Releases                  Package Releases

       Reporting             KPI monitoring and reporting


       Reporting                  Service Reporting

       Reporting                Availability Reporting

       Reporting                   Ad Hoc Reports
       Reporting               Service Outage Analysis



       Reporting                  Reason for Failure

       Reporting                 Service Availability

       Reporting                     Metric Tree
      Security                 Encryption

      Security                 Encryption
 Service Catalogue         Online Publication

Service Support Flow     Known Error Database




Service Support Flow   Linking between Disciplines




 Site Independence         System partitioning


 System Continuity           Maintainability

   Tool Structure        1 to many to 1 mapping


   Tool Structure            RFC linkages

     Workflow                RFC workflow
     Workflow               Diary Integration

     Workflow              Change Checklist
                                               Description

The application must not breach disability discrimination legislation and must demonstrate good practice
in line with the level 'Double A' of the Web Content Accessibility Guidelines v 1.0 produced by W3C.
Disabled users and analysts must not be treated less favourably than non-disabled users and analysts.
The system should be usable without needing a pointing device, so that it can be used solely by keyboard
control. Are all spaces on the page accessible via keyboard only? Please provide any documentation on
keyboard control/shortcuts.
Please list with which accessibility products the supplied software is compatible, including package name
and version numbers where applicable
The system must not have to be withdrawn from service in order to carry out system administrator
activities and shall be designed to be usually available 24 x 7
Relationships between CI’s must be able to be created and easily updated.
The University is looking for a product which must be able to be developed by themselves to deliver a 'fit
for purpose' solution to their business without investing extensive resource in 3rd party consultancy each
time they require minor amendments (reporting/screen design etc). Please confirm:a) This ethos is
supported by your organisation b) The training provided by your organisation to support this c) To the
extent that this development requires programming skills. NB It must be possible for the administration of
the system to be undertaken by trained personnel who are not equipped with programming / development
skills
Different Configuration Item input and output screens, dependant on the CI type, should be definable.
These screens should be able to be developed with a screen design utility that does not require developer
intervention i.e. Drag & Drop
For data retention policy & housekeeping, it should be possible for closed incidents older than a specific
age to be automatically purged.
The administrative interface should be a web interface
Any workflow process should be able to be designed preferably via a graphical workflow designer. The
system should provide the ability to easily define business processes that are not restricted to IT
processes
It should be possible for each institution to make changes to their user and analyst user interfaces without
affecting the same user interfaces used by the other institutions. Each institutions support analysts and
support groups should be separate and not visible to other sites. It should be possible to allow an
institution to modify the appearance of notification messages independantly to that of the notification
messages templates used by other institutions.
The ability to custimise the look and feel and workflows may be present
It may be possible to automatically assign analysts to teams based on their HR data.
Team leaders may be able to opt for a modified expiry date for closed calls that differs from the global
expiry date.
What level of system failure can the Application tolerate before the application is unusable?
Given the stated architecture please state the recommended configuration for Load Distribution. Please
state any limitations that make this impossible.
When upgrading the product, what work is involved to support customised features, such as customer
specific forms, within the new version
The tool must have both Service Catalogue and Service Level Agreement (SLA) functionality. The SLA
functionality must provide links to, for example, Incident Management, so that Customer Impact and
Urgency (=Priority) information may be used during Incidents. Similarly links must be maintained to
Problem and Change Management. Incident Management activities that contribute to Service Level
Targets in the SLA must be able to be automatically monitored. These SLAs must be independantly
maintained for each institution, including escalations, reporting, etc.
Operational Level Agreements and Underpinning Contracts must be maintained in the tool. These must
be able to be linked to the relevant SLAs to facilitate creating SLAs and addressing elements of SLAs
unsupported by OLAs or UPCs.
The system must be able to link configuration items to the impact on a service for Incidents (Component
Failure Impact Analysis), changes, and for pro-active problem management (for example, highlighting a
Single Point of Failure). In particular Services supporting Vital Business Functions must be able to be
highlighted.
Analysts must be able to flag CIs (including Services) as unavailable
It must be possible to change key values of Incident records during their lifetime - e.g. user, priority,
category, component, SLA etc. Ability to do so must be restricted by User and/or Group. These changes
must be recorded in the incident history
The functionality must exist to link Incidents together, so as to remove the need to update multiple
Incidents during a Major Incident.
The ability must exist to be able to log incidents against users and/or Configuration Items (CIs) and
or/location
Pro forma (templates/Quick tickets) Incident records must be able to be generated, allowing fast
Incident/fault logging of repetitive incidents - e.g. password resets. Please indicate if there is a limit on the
number that can be available on screen.
Analysts must be able to display incident details whilst composing a response and must then be able to
escalate incidents functionally (for example, to 2nd line teams) and hierarchically (to more senior
management). After escalation, ownership must remain with the Service Desk, even whilst 2nd line staff
are working on a resolution.
The analyst interface must be a web browser interface with full functionality as described in these
requirements.
Analysts must be able to be in multiple teams and have different roles in each team.
Analysts must be able to have multiple screens and Incident/Problem reports open as required.
The tool must have the ability to open problem records independently of any incidents. These records
must be associated with configuration items, sytems, services or locations.
The ability to have Standard Changes should exist, with appropriate workflow assistance where
appropriate
The ability to create dependencies on Changes or Problems should exist. For example (trivially), the the
books cannot move until the book shelf is installed, the book shelf cannot be installed until the room
lighting is replaced.
The full history details of Configuration Items (CIs) should be available. The ability to view CIs by type
and to identify CIs with Incidents, Problems, Known Errors or Changes should be possible. NB a User is
consider a Configuration Item. It should be possible to view this information whilst logging an Incident and
be possible to drill down to more detailed information.
The ability to apply scripting questions as part of the Incident data collection process should be available.
Analyst prompting on current incidents, related known errors, etc to speed incident matching and selection
of appropriate workaround should be present. A knowledge base that records fixes to previously
encountered Incidents, should be available and easily interrogated.
Logging of user-defined mandatory fields should also be possible - e.g. key fields required for minimum
input and before saving a call.
Analysts should be able to fast track to other sections of the system for reference during Incident/Problem
logging - e.g. CMDB/on going incident list – without requiring the closing of the current record or losing
data input.
End user reports often include multiple incidents or requests, so the system should be able to split this up
into unique incidents.
Searching facility should cover all fields, thus minimising "unsearchable" data
The analyst interface should be fully functional across the following browsers and platforms - Windows IE
6.0sp2+ & Firefox 3+, MacOS Safari 3.2.3+ & Firefox 3+, Linux Firefox 3+. Please detail any missing or
degraded features for these combinations.
When a parent record is closed, the child records should also be closed, for example, on closing a major
incident.
It may be possible to apply a change to multiple CI's without having to open and update each record
separately.

It should be possible to contact users dynamically based on Configuration Items, that is, to enable all
users of a service or all users associated with a particular server to be contacted. This contact should
take note of the preferred contact method recorded for a user. Contact may be via MyEd, email or SMS.
A library of standard responses to queries may be available, to reduce typing for repetitive responses.
This may include "mail merge" facilities to automatically populate name, etc. For example "Dear
Student_Name, your username is s1234859". Similarly, analysts may be able to draft responses prior to
sending them.

Analyst prompting for appropriate escalation routes (both hierarchical and functional) may be available.
Once an incident is logged a suggested assignment may be made based on associated CI details.
Where an incident requires parallel action by multiple teams, that incident may be assigned to two teams
simultaneously rather than sequentially.
Workflows may be overridden (with logging) at runtime.
A Graphic User Interface (GUI) showing the relationships between CIs (Service view) and the impact,
should a CI become unavailable, may be in place.
It may be possible to bookmark particular incidents, problems, service requests, etc. This bookmarks may
be inidividual or team specific.

A ‘stop the clock’ facility - i.e. to suspend the SLA escalation - may be available. This may be security
controlled to limit the authority to key individuals or groups and invocation should be logged.
The system may automatically detect potential repeated calls from the same person about the same
subject, and allow them to be linked
Please describe the extent to which hand held devices can query the system and/or enter data.
Specify the preferred authentication methods for The Application. Describe other authentication
mechanisms supported by The Application, in particular Microsoft Active Directory.
It must be possible to monitor the usage of a component or a service
It must be possible to monitor the capacity of a CI and to be able to integrate with external monitoring
tools, either via a scheduled import of data or via an API. Please describe which capacity related
automated imports are possible and which APIs are supported.
It should be possible to model future or changed capacity requirements. This should include tools to aid
trend analysis and to aid in finding bottlenecks in services, systems and processes.
It must be possible to bulk import CIs from a site. Please explain how you will achieve this.
The functionality to baseline a CI or baseline a ‘service’, should exist. The ability to view historic
baselines should be available.
Each CI should be assigned a unique reference number. The CI status field should be present and
customisable to reflect the requirements of the institution, i.e. ordered, development, change pending etc.
The ability to prioritise CI’s, based upon business criticality, should be an option.
The ability to interface with an automatic discovery tool that populates the CMDB with hardware and
software CIs should be available. This discovery tool must not require a locally installed client.

Given the stated architecture please provide details of your recommended infrastructure specification to
meet our performance requirements and to deliver greatest levels of resilience and fault tolerance.
Please provide itemised quotes for the application purchase, maintenance and licensing costs.
Please provide an estimated pricing structure for additional licenses should they be required at a later
stage.
Please describe your licensing model. Currently the University of Edinburgh has 938 system users in 144
teams.
There is a requirement to partition the database/application, please indicate if this is possible stating the
number of partitions available and any additional costs associated, within section.
Devolved queue management must be able to define their team's workflow and process. This should
include team specific fields.
Devolved administration should be possible with access to the Configuration Management Database
(CMDB) should be controlled by permissions to ensure its integrity.
The facility to upload, attach or reference documents (e.g. from CMDB) to RFCs, Incidents or Problems
should exist i.e. Test and Back out Plans
It should be possible to store documents with appropriate access and version control, for example,
Continuity Plans, Continuity Testing Regimens, Capacity Plans, etc
End users must be able to automatically raise Incidents/Requests via emails sent to a central email
account, automatically receiving notification that their incident has been logged. A notification of update
must be provided to the Service Desk and/or Support Resources. This must be possible for each
institutions systems with recognition of the user's institution and appropriate assignment. This may be via
the "To" field.

The system must be able to assign calls automatically to the relevant inboxes according to business
distribution rules defined by the University. Describe how your system can perform this function.
Alerting via email must be available i.e. alerts to 2nd Line Analysts when an Incident or Problem tickets
has been assigned to them for action. This must be possible for analysts in any institution.
The system must be able to filter spam effectively, including using the information provided in headers
(the University scores incoming email using SpamAssassin). It must be easy to assess and retrieve
genuine emails wrongly classified as spam and must prevent the reopening of closed calls by spam. It is
not possible to define a definitive address whitelist, however whitelisting based on "known" users must be
possible.

The system must be able to detect and prevent mail loops due to delivery failures or auto responses, etc.
The system must be able to send and receive email attachments, including the use of international
character sets.

The ability to assess/approve/close RFCs via email and/or Blackberry and/or web interface should exist.
A user should be identified automatically based on the known email addresses for that user.

Multiple responses to separate reports of same incident, multiple deletion of spam emails, etc
Please confirm if multiple attachments can be sent with emails.
Please confirm it if is possible to remove confidential body text or attachments from incoming emails and
whether this action is logged.
The ability to email an Incident, Request or Problem record may exist.
Describe technically the method used by the software to produce emails to users.
End users must be able to raise an incident or service request via a webform
Users must be able to phone the Service Desk with Incidents and Service Requests
End user alerts must be able to sent via email
It must be possible for users to monitor & review calls via a web interface for which they are the
designated user. It must be possible to exclude information from this user view.
The end user interface must be fully functional across the following browsers and platforms - Windows IE
6.0sp2+ & Firefox 3+, MacOS Safari 3.2.3+ & Firefox 3+, Linux Firefox 3+
The system should be able to display a Forward Schedule of Change and Projected Service Availability
via a web interface.
The University of Edinburgh Portal (MyEd) is based upon uPortal software; uPortal is based upon open
standards based product using Java, XML, JSP and J2EE. More information is available @
http://www.uportal.org. The University is seeking a seamless integration between the MyEd Portal and
the proposed software with functionality being delivered via MyEd channels with single sign on (SSO
Cosign http://www.umich.edu/~umweb/software/cosign/). Suppliers should confirm the compatibility of the
system with uPortal and University’s proposed approach. End users should be able to raise, track and
update Incidents/Requests via the MyEd portal. Notification of any update should be provided to the
Service Desk and/or Support resources. Please provide details on any functionality of the application that
cannot be delivered via MyEd channels.

The system should provide a means of integration from UAD's OracleAS portal. UAD would like users to
be able to log, view and update calls from the OracleAS portal. (More information on OracleAS portal is
available @ http://www.oracle.com/technology/products/ias/portal/documentation.html)
It should be possible to record the user's preferred method of notification and be able to contact them via
that method. Are users asked for preferred method of communication and how is this recorded - how
does the system prompt to ensure user's preferred method of communication used. How many times the
system ensure communication is received in the preferred method?
Please confirm if there are options to report incidents or contact users using SMS text messages and
provide details on how this is performed
The initiation of Service Request workflows, via an user email email or portal request, should exist i.e.
Leavers/Joiners process
It should be possible to use the system to communicate with users on the status of services, including
routine announcements and service availability.
It should be possible to sample user satisfaction, either automatically or by providing lists for telephone
follow-ups.
It may be possible for users to be identified using their University ID Card, permitting pre-population of
user fields at the Service Desk. This may be either via the magnetic stripe, interfacing with an Oracle
database, or via a barcode reader.
An activity may be flagged with a due date such that the priority changes automatically as the date
approaches. This may be linked to Customer specified data, for example, SLA
Users may be able to interrogate the Knowledge Base with dynamic feedback capture, for example was
this helpful? X% found this helpful, Y% also searched for
The system may provide opt-in end user automatic alerting on status updates (e.g. via SMS, email, web
portal)
Users may be able to contact the Service Desk via a real time chat facility. Describe this, if available,
including whether this is via a built-in facility, via a third party client (for example, Windows Live
Messenger) or via both. Note whether the chat is logged and if the contact may be transferred to email or
phone if it proves necessary.
The functionality should exist to integrate CTI technology into the system in the future, should the
requirement exist. At a minimum, the system should identify the caller automatically and pre-populate user
fields for the Service Desk. Please identify whether this functionality exists and with which telephony
services it can be integrated.
Please list other mechanisms available for communicating information to users of the application.
The system should be able to cope with external users - either defined or ad hoc. External applicants may
be required to register with the eVisitor application. The user would be registered as a Cosign Friend with
the unique username generated being the users email address.
http://www.projects.ed.ac.uk/areas/servicemgt/idmgt/DIR069/eVisitorService.doc
Costs must be able to be categorised as Capital/Operational, Fixed/Variable, Direct/Indirect, Absorbed or
Unabsorbed
Costs must be able to be assigned to customers or to services.
It should be possible to allocate time spent to activities, for example, incidents, problems or releases.
Time spent should be able to be reported based on service, project or budget.
CI aging should be present such that reports may provide information on license, maintenance or support
expiry and aging equipment that may be due for replacement.
It may be possible to automatically depreciate the value of Cis.
It may be possible to tag cost types (People, Accommodation, Hardware, Software, External, Transfer) for
services and may be possible to subdivide the types by associated elements.
The system must be usable for Service Management in non-IT Services.
It must be possible to implement each service management discipline separately. For example, a fully
populated CMDB must not be a pre-requisite for the implementation of problem management.
The system must integrate with feeds from the HR databases, visitor registration systems, student record
systems and institutions organisational structure. Ideally this will be a dynamic polling, however please
state if this will be a batch process.

The system must allow for the devolved creation of support analysts and groups by each institution.
The system should be able to import existing calls from the University of Abertay Dundee (UAD) call
management system Touchpaper HelpDesk. The Touchpaper system stores previously logged calls and
outstanding calls in a Microsoft SQL Server database.
The system should support a means of single sign-on authentication from a remote site (UAD) and / or
Shibboleth authentication.
The system must be able to import the existing University of Edinburgh Call Management System calls,
maintaining, at a minimum, the user, call data (perhaps flattened) and team assignments. This must be
done for all open calls at a minimum. Please describe how you intend to achieve this import.

Authentication to the tool for users and analysts must be via the University's single sign on which is a
Cosign service combined with Kerberos (SSO Cosign http://www.umich.edu/~umweb/software/cosign/).
Describe the facilities provided to support authentication using the University of Edinburgh SSO solutions,
i.e. Cosign and Kerberos, highlighting any foreseeable issues.
The system should be able to pass authorisation requests to other University systems. This may be via
Kerberos, Active Directory or LDAP. Please state which of these are currently possible.
The system should be able to link to various event monitoring systems. Please state with which systems
integration is possible and describe how it works. The University uses ZenOOS (MySQL), and several
Microsoft systems (MOM/Service Centre for Windows, Active Directory).
The system may be able to integrate with the EDINA License database (Helios) such that users may be
linked to their institutions licensing agreements.
The system may be able to take a feed from the EdLAN DB which provides the DHCP assignment
information for the University.
The system may allow partitioning or flagging of Incidents/KEDB/Knowledge base to allow for school or
college specific workarounds, etc
The functionality must exist to enable Line Managers to view the ‘queues’ of their teams, and individuals
within that team, in relation to all current and historical activities assigned.
The system must be able to escalate Incident and Problem reports over time according to the SLA
assigned. This must include re-referral to other groups or individuals, increasing of severity (impact), and
external analysts alerts, other users and management (both hierarchical & functional escalation). It must
also be possible to escalate issues manually.
Data migration from Informatics' Best Practical - RT
Data migration from EDINA existing incident management system
Data migration from IS Apps' Change Control tool
Centralised reporting on local support teams is not required. For example, IS will not require monitoring of
the performance of local computing officers
The system must respond quickly enough to allow support staff to use it effectively during a face-to-face,
on-line chat or telephone interaction without asking the user to wait. It must have a similar perceived
responsiveness to the CMS.
The software upon which the evaluation is based must be an extant version, and must be scaleable to
operate effectively in the University.
It may be possible to relate multiple Changes to a Package Release, maintaining all the relevant
Parent/Child relationships.

Reporting must include at a minimum first time fix rate and % accurate escalation from first to second line.
The system must be able to produce reports on services, including Service Level Agreement Monitoring
(SLAM) charts. These reports must include the following: Mean Time Between Service Incidents, Mean
Time Between Failures, Mean Time To Recover.

Availability should be linked to Services and reporting should be possible against Services and SLAs.
The system should facilitate ad hoc reporting, either internally or via SQL/ODBC/Business Objects.
Please specify which are possible.
It should be possible to easily analyse the causes of a service outage.
Incident and Problem records may include Reason For Failure information - for SLA reports. This
indicates why the SLA was not met - not simply resolution details. Typically this will be a table of relevant
codes and descriptions that can be accessed and a value added to the Incident/Problem report - e.g. User
unavailable/staff shortage/higher priority problem taking precedence.
The system may be able to calculate downtime of services and components (including related CI’s),
according to Incident status.
A "metric tree" may be provided such that metrics are agregated by the system to form higher level
measures.
The University expects the application to be able to encrypt all web data using HTTPS. Clearly describe
any conditions where this is not employed.
Please confirm whether data encryption is possible within the database or to files stored locally on the file
systems of the servers. Please detail any associated costs.
The ability to publish the Service Catalogue on the Intranet may exist.
A Known Error Database (KEDB) facility must exist within the tool for the recording of temporary
workaround solutions identified through Problem Management activities.
The capacity must exist to link incidents to problems/known errors to changes (many to one). Once a
Release has eliminated a Known Error, the linked Known Error and Incidents must be updated and the
associated Workaround flagged as (potentially) obsolete. The functionality must exist to create a Problem
Record from a single or multiple Incident Record(s), with appropriate information being transferred across.
From a Problem record/Known Error the functionality must exist to create an RFC, again with appropriate
information being transferred.
The system must provide a layer of partitioning either within its software or database to allow for a
completely separate fully working system for which all of the separate institution user accounts, incidients,
problems, changes, CI's etc can be recorded separately and not be visible to the other institutions (with
the aknowledged exception of system administration access in the University of Edinburgh). Please
explain how you will achieve this.
The University must be able to recover in less than one day, however expects to be able to do so in less
than half a day. Suppliers should describe how they are set up to meet this requirement and clearly state
any circumstances when this cannot be met.
The tool must be able to support Services with complex Configuration Item relationships, such that all
disciplines must be able to cope with a one to one, one to many and many to one relationships.
An RFC should be linked to any associated Problems and Incidents. Such Problems and Incidents should
be closed when the RFC has been successfully implemented. All associated RFCs should be visible from
within each Problem Record.
The system should allow different authorisation/assessment processes to be invoked depending on the
type of change.
Scheduled tasks may be entered automatically into the analysts diary (Exchange, Oracle)
Checklists and cross linking may be provided. This might include a prompt to check if changes have
Continuity implications, etc.
     RefNumbers                  Discipline          Weighting Key   Weighting Description



          17                        N/A                   1          Mandatory Requirement


          44                        N/A                   2             Highly Desirable

       162, 163                     N/A                   5             For Information

        41, 42             Availability Management        1          Mandatory Requirement
         31               Configuration Management        1          Mandatory Requirement




      23, 43, 62                    N/A                   1          Mandatory Requirement


      73, 84, 205         Configuration Management        2             Highly Desirable

          88                Incident Management           2             Highly Desirable
          49                         N/A                  2             Highly Desirable


      46, 81, 201                   N/A                   2             Highly Desirable




  231, 234, 235, 238                N/A                   2             Highly Desirable
         228                        N/A                   3                Desirable
         107                        N/A                   3                Desirable

         129                Incident Management           3               Desirable
         169                         N/A                  5             For Information

         170                        N/A                   5             For Information

         171                        N/A                   5             For Information




12, 176, 178, 179, 180,
181, 182, 186, 189, 242   Service Level Management        1          Mandatory Requirement


       187, 188           Service Level Management        1          Mandatory Requirement



125, 184, 190, 196, 198    Availability Management        1          Mandatory Requirement
     194          Availability Management   1   Mandatory Requirement


     24            Incident Management      1   Mandatory Requirement

      7            Incident Management      1   Mandatory Requirement

     22            Incident Management      1   Mandatory Requirement


     25            Incident Management      1   Mandatory Requirement



 33, 35, 36        Incident Management      1   Mandatory Requirement

    11                     N/A              1   Mandatory Requirement
    227                    N/A              1   Mandatory Requirement
   34, 66          Problem Management       1   Mandatory Requirement

     18            Problem Management       1   Mandatory Requirement

     82            Change Management        2      Highly Desirable


     87            Change Management        2      Highly Desirable



64, 75, 76, 96   Configuration Management   2      Highly Desirable



 51, 54, 55        Incident Management      2      Highly Desirable

     63            Incident Management      2      Highly Desirable


     65            Incident Management      2      Highly Desirable

     89            Incident Management      2      Highly Desirable
     93                     N/A             2      Highly Desirable


     241                   N/A              2      Highly Desirable

     221           Incident Management      2      Highly Desirable

     118           Change Management        3         Desirable



     112         Configuration Management   3         Desirable
   138, 139           Incident Management         3         Desirable


     115              Incident Management         3         Desirable

     108              Incident Management         3         Desirable
     99                        N/A                3         Desirable

     120          Service Continuity Management   3         Desirable

     106                      N/A                 3         Desirable


     123            Service Level Management      3         Desirable

     140              Incident Management         3         Desirable
     131                       N/A                3         Desirable

   166, 167                    N/A                5      For Information
     217              Capacity Management         1   Mandatory Requirement


   219, 220           Capacity Management         1   Mandatory Requirement

   215, 218           Capacity Management         2      Highly Desirable
     232            Configuration Management      1   Mandatory Requirement

    77, 86          Configuration Management      2      Highly Desirable


78, 79, 85, 200     Configuration Management      2      Highly Desirable

   74, 145          Configuration Management      2      Highly Desirable


146, 168, 244                 N/A                 5      For Information
  147, 148                    N/A                 5      For Information

     150                      N/A                 5      For Information

     149                      N/A                 5      For Information

     151                      N/A                 5      For Information

   19, 226                    N/A                 1   Mandatory Requirement

      45            Configuration Management      2      Highly Desirable

 72, 94, 105                  N/A                 2      Highly Desirable

202, 203, 216                 N/A                 2      Highly Desirable
 27, 37     Incident Management   1   Mandatory Requirement


40, 236     Incident Management   1   Mandatory Requirement

29, 237     Incident Management   1   Mandatory Requirement




   3               N/A            1   Mandatory Requirement

   4               N/A            1   Mandatory Requirement

   5               N/A            1   Mandatory Requirement

   83       Change Management     2      Highly Desirable
   52       Incident Management   2      Highly Desirable

   95       Incident Management   2      Highly Desirable
   57                N/A          2      Highly Desirable

  98                 N/A          3         Desirable
  124                N/A          3         Desirable
  164                N/A          5      For Information
  39        Incident Management   1   Mandatory Requirement
  38        Incident Management   1   Mandatory Requirement
  237       Incident Management   1   Mandatory Requirement

            Incident Management   1   Mandatory Requirement

  240              N/A            1   Mandatory Requirement

 69, 70     Change Management     2      Highly Desirable




9, 11, 28   Incident Management   2      Highly Desirable



  243       Incident Management   2      Highly Desirable



 37, 97     Incident Management   2      Highly Desirable
     90, 117           Incident Management      2      Highly Desirable

       80              Request Management       2      Highly Desirable

       48            Service Level Management   2      Highly Desirable

       56            Service Level Management   2      Highly Desirable


       116           Configuration Management   3         Desirable

  85, 102, 103         Incident Management      3         Desirable

       114             Incident Management      3         Desirable

       136             Incident Management      3         Desirable



    110, 134           Incident Management      3         Desirable



  53, 135, 172         Incident Management      3        Desirable
      165                       N/A             5      For Information



     50, 58          Configuration Management   2      Highly Desirable

206, 207, 208, 209     Financial Management     1   Mandatory Requirement
     175, 210          Financial Management     1   Mandatory Requirement

  137, 211, 225        Financial Management     2      Highly Desirable

       213             Financial Management     2      Highly Desirable
       212             Financial Management     3         Desirable

       214             Financial Management     3         Desirable
       222                       N/A            1   Mandatory Requirement

                               N/A              1   Mandatory Requirement


     13, 132         Configuration Management   1   Mandatory Requirement

       233                     N/A              1   Mandatory Requirement


       229             Incident Management      2      Highly Desirable

       239                     N/A              2      Highly Desirable
       6              Incident Management      1   Mandatory Requirement




   10, 20, 224                N/A              1   Mandatory Requirement

    91, 104         Configuration Management   2      Highly Desirable


 100, 101, 195         Event Management        2      Highly Desirable

      111           Configuration Management   3         Desirable

    113, 132        Configuration Management   3         Desirable

      130             Incident Management      3         Desirable

    32, 128                   N/A              1   Mandatory Requirement



  47, 121, 183      Service Level Management   1   Mandatory Requirement
      141                      N/A             4       Not Required
      142                      N/A             4       Not Required
      143                      N/A             4       Not Required

      144           Service Level Management   4       Not Required


      1, 2                    N/A              1   Mandatory Requirement

       21                     N/A              1   Mandatory Requirement

      119             Release Management       3         Desirable

 14, 15, 26, 177    Service Level Management   1   Mandatory Requirement


14, 173, 174, 191   Service Level Management   1   Mandatory Requirement

    192, 193         Availability Management   2      Highly Desirable

   14, 92, 223                   N/A           2      Highly Desirable
       199           Availability Management   3         Desirable



      122           Service Level Management   3         Desirable

      126            Availability Management   3         Desirable

      185           Service Level Management   3         Desirable
   59                     N/A                  2      Highly Desirable

  60                      N/A                  2      Highly Desirable
  127          Service Level Management        3         Desirable

   16            Incident Management           1   Mandatory Requirement




8, 18, 30           Service Support            1   Mandatory Requirement




  230                     N/A                  1   Mandatory Requirement


   61                     N/A                  2      Highly Desirable

  197          Configuration Management        1   Mandatory Requirement


 67, 68          Change Management             2      Highly Desirable

  71             Change Management             2      Highly Desirable
  133                   N/A                    3         Desirable

  204       IT Service Continuity Management   3         Desirable
RefNo Requirement            Description
       Easier team context
   109 switching
                             (a) appropriate statements from banks or, where
                             appropriate, evidence of relevant professional
   152                       risk indemnity insurance;
                             (b) the presentation of balance-sheets or
                             extracts from the balance-sheets, where
                             publication of the balance-sheet is required
                             under the law of the country in which the
   153                       economic operator is established;
                             (c) a statement of the undertaking's overall
                             turnover and, where appropriate, of turnover in
                             the area covered by the contract for a maximum
                             of the last three financial years available,
                             depending on the date on which the undertaking
                             was set up or the economic operator started
                             trading, as far as the information on these
   154                       turnovers is available.
                             (e) the educational and professional
                             qualifications of the service provider or
                             contractor and/or those of the undertaking's
                             managerial staff and, in particular, those of the
                             person or persons responsible for providing the
   155                       services or managing the work;
                             (g) a statement of the average annual
                             manpower of the service provider or contractor
                             and the number of managerial staff for the last
   156                       three years;
                             All candidates will be required to provide
                             certification drawn up by an independent body
                             attesting the compliance of the economic
                             operator with quality assurance standards based
                             on the relevant European standards. (9 Quality
   157                       ISO 9001)
                             Certificates drawn up by official quality control
                             institutes or agencies of recognised competence
                             attesting the conformity of products clearly
                             identified by references to specifications or
   158                       standards.
                             A statement of the principal goods sold or
                             services provided by the supplier or the services
                             provider in the past 3 years, detailing the dates
                             on which the goods were sold or the services
                             provided; the consideration received; the identity
                             of the person to whom the goods were sold or
                             the services were provided (Q 14 in Quality
   159                       Questionnaire)


                             A check may be carried out by the contracting
                             authority or by a competent official body of the
                             State in which the candidate is established, to
                             verify the technical capacity of the candidate;
                             and if relevant, on the candidates study and
   160                       research facilities and quality control measures;
                         An indication of the proportion of the contract
                         which the services provider intends possibly to
161                      subcontract
245 Sorting of columns
Responsible Person Category    Discipline   Weighting Key

                   Technical      N/A            3


                     EFT          N/A            5




                     EFT          N/A            5




                     EFT          N/A            5




                     EFT          N/A            5



                     EFT          N/A            5




                     EFT          N/A            5




                     EFT          N/A            5




                     EFT          N/A            5




                     EFT          N/A            5
EFT   N/A   5
Weighting Description

      Desirable         Taken out to usability - not able to define


   For Information      Was in PQQ




   For Information      Was in PQQ




   For Information      Was in PQQ




   For Information      Not in requirements, but will be requested separately.



   For Information      Was in PQQ




   For Information      Was in PQQ




   For Information      Was in PQQ




   For Information      Was in PQQ




   For Information      Was in PQQ
For Information   Was in PQQ
                  Taken out to usability

								
To top