itsm s/w spec - barclay rae consulting itsm software... · web viewsupport staff at all levels can...

CUSTOMER MANAGEMENT SOFTWARE SPECIFICATION V 1.0

Company X

Company X

Customer Management Software ITSM Software Specification

SAMPLE FOR REVIEW

Prepared by

Version 1.0 (Date 2005)

This is a DRAFT of requirements for a Customer Management ‘Front End’ solution which is proposed for Company X operations

1


Company X

Requirements - Information Gathering

Format for scoping workshop – Date

Topic Comments

2


Company X

Contents.

Overview...........................................................................................................................4Objectives.........................................................................................................................5Requirements for Support Centre & Service Management.........................................6

OVERVIEW OF SYSTEM REQUIREMENTS................................................6OVERVIEW OF TECHNICAL REQUIREMENTS...........................................81 FUNCTIONAL REQUIREMENTS...........................................................111 Key Requirements....................................................................................................112 Customer Configuration..........................................................................................113 Customer Profile......................................................................................................124 Asset Configuration (For asset Recording and Reporting).....................................134.1 Asset Profile..........................................................................................................135 Incident & Problem Logging...................................................................................155.1 Incident/Problem Logging Screen Configuration:...............................................176 Incident Management Workflow..............................................................................187 Incident & Problem Tracking..................................................................................198 Service Level Agreements........................................................................................209 Change Management...............................................................................................2210 Reporting Requirements.........................................................................................2211 Suggested Sample Reports.....................................................................................2412 Format of Reports..................................................................................................2413 Scheduling of Reports............................................................................................2514 Additional Functionality........................................................................................252 TECHNICAL REQUIREMENTS..............................................................271 Overview..................................................................................................................272 Interfaces..................................................................................................................273 Performance.............................................................................................................284 Security.....................................................................................................................285 Contingency/Resilience............................................................................................283 SUPPLIER REQUIREMENTS.................................................................301 Company Stability....................................................................................................302 Product Assurance...................................................................................................303 Product Installation..................................................................................................30

3


Company X

BACKGROUND

This project supports the efficient and effective management of Customer Service contacts across Company X Operations across Europe.

Overview

The system will

Basic requirements must be met as follows:

Intuitive, simple call logging and updating

Graphical User Interface

Sub-second response times

Customer Database

Asset Management Database (Inventory)

Single key access to Customer records and call history

Dynamic on-line Escalation

User-friendly system administration

Flexible system development

150+ users, with pricing to cover between xx to xx concurrent users

User-defined reporting

Proven UNIX or NT or Windows XP stability

Enterprise Management interfaces (i.e. procurement, personnel data)

Web integration

Knowledgebase integration / development

Systems must able to be used effectively over a WAN

4


Company X

Objectives

The primary objectives of Service Management and this implementation are as follows:

1. Improved Customer Service to IT Customers

Faster response from the Support Centre and Support Groups

Fast Incident determination

Faster resolution of Incidents - first and second level

Higher first level resolution rate from the Support Centre

Consolidation of Support Centre as single point of contact for all IT issues

2. Consistency of approach and efficiency across all IT support areas.

Common procedures for call handling/customer care

Common SLA methods and management

Improved and consistent escalation procedures

Improved tracking of calls

Improved operational efficiency of IT support

Improved communication between IT departments and suppliers

Integration with Configuration and Change Management

Support the End-to-End Service Management process.

3. Single central source of Management Information.

User defined reporting

Ad hoc and scheduled reports

Common measurements across departments

Trends analysis of Incident / Problem types, locations, customers, equipment etc.

Roll over analysis of Incident / Problem trends

5


Company X

Requirements for Support Centre & Service Management Overview of System Requirements.Call LoggingConsistent on-line logging and tracking, with full audit trail facilities is required to improve referral, communication and tracking of Incidents and Problems between the Support Centre and Support Groups. The system must support the ITIL model for Service Management processes. The system should include the facility to distinguish between Incidents, Problems, and Changes - i.e. an Incident may be caused by an ongoing Problem or Change and can be quickly closed with reference to an outstanding Problem etc. Incidents need to be able to be linked to Problems to facilitate Problem Management by easily identifying related Incidents.

Change / Request ManagementThe system must provide the functionality to log and manage Requests for Change (RFC’s) following an ITIL compliant Change Management process.Pre-defined Change ‘templates’ should be offered to select standard RFC lifecycles e.g. Standard hardware procurement, New User, Payroll application amendment. These will include multiple stages and multiple tasks within each stage. Stages and tasks may run concurrently or be dependent upon completion of an earlier stage or task. It should also be possible to create online ad-hoc RFC lifecycles for non-standard Changes.

Configuration ManagementIncident, Problem & Change functionality must be underpinned by a Configuration Management database. This should provide a hierarchical asset structure to track & record software & hardware Configuration Items (CIs), including multiple attributes, some financial information and relationships between different CIs.

Asset ManagementThe system must provide the functionality to manage assets once purchased, through installation to disposal. The system must support stream-lined processing from an item arriving in stock, to being installed, recorded in the inventory and disposal. It must be possible to record, monitor and report back on an asset including purchase cost, depreciation, location, user, age, service contract and maintenance charges..

Service Level ManagementThe system should be able to support multiple SLAs, using pre-set response and fix times set against Incidents and Problems, Customers and Configuration Items. These should be definable and traceable within multiple sets of working hours - e.g. 08.00 - 18.00 Monday - Friday for one department, 07.00 - 22.00 for another, 24 hours per day for another department/system etc.

Incident and Problem records should include Reason For Failure information - for SLA reports. Reports should be able to track fix times of re-referred Incidents and Problems between Support Groups from a Customer perspective. This should clearly identify the total elapsed time for an Incident/Problem regardless of when it was referred or re-referred between Support Groups and the response & turnaround times of each Support Group and/or 3rd party.

6


Company X

Escalation & Status NotificationThe system must be capable of auto-escalating Incidents and Problems nearing or reaching their service level targets. This should include re-referral, re-prioritisation, and alarms on-line and via e-mail and sms.The system should provide simple, fast access to views on the status of Incidents, Problems and Changes, filtered by Owner, Location, Division, Department, Status, Priority, Category and Equipment etc.

User InterfaceIn order to ensure that the system is properly and fully utilised, the system must be user-friendly. Support Centre and Problem Management systems are often regarded as inconveniences, particularly amongst Technical Support Groups and it is therefore essential that this should be easy and intuitive to use. This must have a Graphical User Interface (GUI) and allow fast and efficient logging and updating of records using ‘point and click’ (as well as ‘hot-key’ usage), on-line help, and screen and field validation relevant to the user, function or group. Graphical tools - e.g. buttons, colour coding - and fast simple system navigation should be available wherever possible.

ReportingReport creation should be simple and intuitive, not requiring a high level of technical expertise. The report writer should provide parameter-driven functionality, with the capability of performing mathematical and logical calculations on the data. Reporting should allow a variety of views, summaries and trend analysis of Incident, Problem and Change data and must be created and run by staff using the system. Ad Hoc reporting facilities should also be available.

KnowledgeBaseA knowledgebase capability is required to provide quick access to historical records, suggested resolutions and standard package on-line technical manuals. The Support Centre can utilise this function to develop their technical knowledge and increase first level resolution. The knowledgebase can also provide first line diagnostics data for support analysts, as well as rules and procedures for change management. This functionality should be made available to all users of the system i.e. Support Groups, management, users etc with integration to existing/new internal knowledgebases/manuals i.e. customer advice notes.

Access to Technical & Process/Procedure DocumentationThe system should allow system users to access process, procedure and technical documentation through the menu system. The menu system should provide the ability to link to relevant Internet and Intranet sites/pages and information stored on LAN/WAN servers.

Customer SatisfactionThe ability to measure and record Customer Satisfaction e.g. through surveys. It should also be possible to gauge a Customer’s previous level of satisfaction from a Customer Satisfaction Rating assigned when closing their last Incident.

7


Company X

AdministrationSystem administrators, whose profile need not be highly technical, should control changes to the system. They should be able to define and build fields, screens and reports as well as controlling access levels to individuals and groups.

System UtilisationThe system must provide access for 150+ users, with up to 60 concurrent users. 2000 records logged each month with this expecting to rise to around 5000 to 6000 in the event that a suitable call logging application is made available. 6000 Customer records & approximately 15000 Configuration Items are currently supported. The system must be fully flexible to support future development and expansion as support requirements may change.

Archiving/Data ManagementThe system should provide the facility to configure the archiving of historical data. Archiving should be automatic and provide options within the configuration to archive by defined categories.

Scalability.This system must be fully flexible to support future development and expansion as support requirements may change.

Overview of Technical Requirements.Systems Management.SQL / Oracle is the current in-house database management system standard.Alcatel IP Touch is the telephony system in place.

Interfaces.The system must be able to interface with the MS Outlook e-mail system for Incident and SLA alerts. This should also allow messages to be sent ‘always on top’ to Support Groups and/or individuals. These messages will inform Incident owners of urgent issues in their area where the SLAs are nearing thresholds and when thresholds have been exceeded. The interface should also allow Incident reports to be automatically generated by customer input from standard e-mail forms and via the web. Automatic escalation according to a SLA table should allow simple broadcasting (for information) as well as changes to Incident status - e.g. increased priorities, change of ownership. Customers should also be able to enquire on the status of their Incidents via e-mail and web forms.

The system should also be able to acknowledge receipt of the e-mail Incident, and automatically broadcast a message to the user on closure (also via e-mail).The system should be able to link with standard industry interfacing protocols - VIM/MAPI/TAPI/TSAPI, and be capable of future integration with automated Network and Systems Management systems and platforms - and interactive voice response units (IVRs). Future CTi functionality must be supported - e.g. screen popping, and customer records presented on screen to (CLi searching customer database).

The system should be able to accept Incidents from external systems tools to raise Incident logs automatically according to pre-defined filter criteria.

8


Company X

Interfaces to Inventory Management and Change Management systems must be via intelligent links to include the ability to capture relationships between data entities. An example of this is - links to an Inventory database must include the ability to pull audit data on the inventory records, associated changes/links to a Change system must include the ability to identify related Problems and Changes etc. Web integration is required to allow Customers to log new Incidents, access to knowledgebase (self-help) and Incident status information via either the Internet, Intranet or Extranet.The system should also provide interfaces to Oracle Financials, in particular the web based procurement module for capturing inventory purchases. (See also page 26 under Orders database)

Performance.Proven response times across the local and wide area network must be:Sub-second to each terminal/desktop for call logging.Incident or Inventory records searches should be returned within 2 second. Keyword or free-format searches should be returned within 2 secondsThe system will be accessed by up to 150+ users, including up to 60 concurrent users. Similar demonstrable proven usage is required.The system should be proven stable on the above platform and provide 99.6 % availability 24 hours per day, 365 days per year - i.e. no more than one total day downtime.

Security.The system should provide encrypted algorithm password protection.The system should provide user-definable field level access control - e.g. security access should be controllable by user group and individual system user, to data fields such as category, component type, customer group etc. Read/add/delete/re-open access should similarly be user-definable at field and individual/group level.All system users should be able to view relevant open and closed Incidents and Problems at any time. User-defined screen layouts should be possible to provide different groups with relevant views of Incident and component details.

Database Integration.The system should provide proven integration with Inventory Management, Change Management, Telephony and Network Management systems. The system should be able to import inventory records from existing inventory and asset management systems.In future the system will be expected to interface with automated network management systems. This should be capable of raising automatic Incident logs from system generated alarms. The system should provide - or integrate with - a problem solving knowledgebase to provide on-line help. The tool should instigate a resolution option based on key problem details and keyword spotting from free-format text in problem descriptions. The underlying data structure should be an industry standard RDBMS SQL compliant database supporting DDE and OLE. The vendor/author must supply a data model of their system. The system should provide user-friendly system administration functions i.e. not a system programming function. Tailoring of screens and database entities should be easily performed without vendor or systems programming resources. The vendor should supply training as required in development of the application - this training requirement should not exceed 5 days for an experienced DBA to be able to re-

9


Company X

configure various parts of the system i.e. capable of re-designing screens and changing database entities and relationships. The system must be capable of web based functionality - i.e. application running over the intranet. This should help facilitate easy rollout and future installations.

Contingency/Resilience.The system should provide the facility to archive records automatically, according to user defined criteria e.g. all Incidents, Problems, Configuration or Change issues over 12 months old, status ‘closed’ and category ‘password’. The supplier should provide full information on acceptable database sizing to support this. It is expected that up to 5,000 Incident, Problem and Request records may be logged each month in future (currently 10,000). The whole system must be resilient such that it can be quickly recovered after outages or unexpected conditions e.g. using mirroring or equivalent technology.

A comprehensive system log should be available for analysis in the event of system failure. Retrieval access times to archived data should not be excessive and should correspond to the age or user-defined priority of the data - i.e. 3-month old data should be accessible more quickly than 2 year old data, Virus category problems are accessible more quickly than password category.

10


Company X

1 Functional Requirements

1 Key Requirements

Requirement Mandatory Desired

Incidents and Requests will be logged against the appropriate Customer records.

Incidents and Requests will be quickly logged at the first level. (The system should aim to support first level resolution)

Those calls not resolved at the first level will be passed to the relevant support teams and available analysts on-line, or by system alert or via e-mail and sms.

The system will provide fast, simple tracking of calls on a variety of views - customer, department, problem owner etc.

Auto escalation of calls nearing or missing SLA/OLA targets will alert staff and management on-line, or via e-mail or sms.

(System)User-defined reporting will provide multiple views on Incident and Problem trends and support performance.

Distributed Usage – Users and Customers raising calls

2 Customer Configuration

Customer Configuration Mandatory DesiredA database of Customer records will be built from existing databases, to which associated hardware and software details can be associated.

Field key access to the customer records should then be possible during Incident and Problem logging - i.e. customer name/Asset number/LOGIN should provide fast access to all available customer and asset details

Customer configuration Table Mandatory DesiredFirst Name

‘Key User’ status

Surname

Secondary Contact Name ( If call placed on behalf of other user)

Company Department/Division

User Type (B2B, B2C)

Department (Organisational unit)

11


Company X

Phone

Mobile/Pager

Mail/Login

Products / services

Service Level Requirement

3 Customer ProfileEntity Description

First Name

‘Key User’ status

Name

Status Flag

Surname Name

Secondary Contact Name If call placed on behalf of other user

Department Departmental charge code

Division Company X Division etc.

Department Organisational unit

Phone User phone number

Mobile/Pager User Mobile Number

Mail/Login System/E-Mail Login id

Privileges Application access/privileges

Building Physical location

Room Physical location

Floor Floor Location

Desk Desk Number

Service Level Requirement SLA Category

Link to Corporate system (User defined key)

i.e. TRENT person ID.

12


Company X

4 Asset Configuration (For asset Recording and Reporting)

Asset customer Configuration Mandatory DesiredA database of Asset records will be built from existing Inventory and Maintenance records, to which associated customer details can be associated.

Field key access to the customer records should then be possible during Incident and Problem logging

4.1 Asset ProfileAsset configuration Table – Key Items include: Mandatory DesiredAsset Number

Equipment Type

Make

Model

Serial Number

Location

Parent Configuration Item(s)

Child Configuration Item(s)

Customer ID (Key field)

Department/Cost Centre

Support group responsible

SLA

OLA

Comments

Type of asset e.g. PC, printer

Date purchased

Purchase price

Date due for renewal

Depreciation

Information/comments about the asset

Key user

Maintained

13


Company X

Maintenance level

Maintenance charge

14


Company X

5 Incident & Problem Logging

Incident / Problem Logging Mandatory DesiredIncident and Problem logging screens should aid fast logging - with drop down menu/drill-down options on fields.

Values should be validated against user-defined tables.

Incident and Problem records should be easily and quickly created with minimal typing using point and click selections validated against user-defined tables.

Logging of user-defined mandatory fields should also be possible - e.g. key fields required for minimum input.

It should be possible to change key values of Incident and Problem records during their lifetime - e.g. priority, category, component, SLA etc. Ability to do so should be restricted by User and/or Group.

Pro forma (template) Incident records should be able to be generated, allowing fast problem logging of repetitive problems - e.g. password resets.

Call logging staff should - subject to appropriate security levels - be able to update or add Inventory records whilst logging Incidents and Problems.

It should be possible to link Incident priorities to ‘key’ equipment or Customers.

During Incident and Problem logging it should be clear if the customer is a ‘key user’, with the facility to alert relevant members of staff that a key user has logged a call (via e-mail or sms).

It should be easy to check previous or outstanding Incidents and Problems reported by a Customer.

In addition it should be possible to gauge a Customer’s previous level of satisfaction from a Customer Satisfaction Rating (assigned when closing their last Incident to record “as close to the event” so that Support Centre analysts can use this indicator to develop stronger relationships with the customer).

System users should be able to fast track to other sections of the system for reference during call logging - e.g. Inventory/outstanding problems list - without requiring to close the current record or lose data input.

Printing of call details should also be easily facilitated without having to escape from the current record.

15


Company X

In the Windows environment it should also be possible to have multiple screens and Incident reports open as necessary.

Once a call is logged it should be clear from the Component or Software details, which support group, or individuals are responsible for its resolution - this should include primary and secondary contacts.

The system should include a mechanism to indicate the presence, absence or availability of support staff throughout the day - i.e. like an ‘IN/OUT’ board.

Support Centre staff must be able to allocate Incident and Problem reports or Requests to appropriate support staff using the system.

It should be simple to identify and sort Incidents and Problems by category, priority, responsible group, individual, SLA status etc.

Support Centre and IT staff should be able to access historic information on similar call types - e.g. by customer/equipment type/category. This can also include procedural details, customer and departmental information. This should facilitate increased and speedier first level resolution as analysts can try previous resolutions to problems before referring to further support staff.

Support Centre and Support staff should have access to common package resolution details - e.g. ‘how to’s’ in MS products and common problem resolutions as well as FAQs.

Customers and users should be able to automatically raise Incidents via standard e-mail forms or the web.

Customers and users should be able to check on progress of calls via standard e-mail forms or the Web.

Incident & Problem records should contain summary Customer details -as required by each Support Group/Support Centre.

16


Company X

5.1 Incident/Problem Logging Screen Configuration:

On-line (live) status

Incident/Problem category(for logging)

Cause category(for closing)

Priority

Impact - e.g. partial impact/department down

Incident/Problem Owner Group & Assignee

Unique reference number

One line summary description details

Free form description and resolution details

Date and time stamped user id details of call logger/acceptor/resolver

Date and time stamped actions i.e. contacts made/stages reached/actions done

Date & time stamped user-id details of call closer and any other user defined steps in the Incident/Problem lifecycle

Projected SLA time scales (response and fix) for user defined stages in lifecycle

An SLA ‘clock’ clearly showing elapsed life of the Incident/Problem within pre-defined or user-allocated timescales

Date & time stamped user-id details of any updates during the call progress

Actual SLA measurements for any user defined stage in the lifecycle

SLA Reason for Failure code

17


Company X

6 Incident Management Workflow

Incident Management Workflow Mandatory DesiredThe Support Centre Analyst identifies the caller from one key reference - e.g. name, etc. With this information they quickly retrieve the caller’s phone number, department, ‘Key User’ status etc. and confirms these details with the caller.

If any details are incorrect the Support Centre Analyst can update the relevant database on-line or can log an exception.

The Support Centre Analyst then asks for key details of the Incident or Request and logs a free-form text description and assigns an appropriate fault category, SLA priority and impact code.

The system then allocates an escalation plan for fix and response times to the record and identifies to the Support Centre Analyst the relevant Support Group responsible.

If the Support Centre Analyst cannot resolve the Incident, they can access a knowledgebase to identify solutions - this will provide options based on key details logged and from keyword spotting in free-format text.

A system clock will clearly allow the Analyst to add the amount of effort they are spending on each Incident or Problem. A real time clock will calculate elapsed time spent by each Group/Analyst

If the Incident cannot be resolved via the knowledgebase then the Support Centre Analyst assigns it immediately to the appropriate Support Group, based on responsibility area information clearly defined on the system - e.g. if raised against a Network Hardware this is designated to belong to Network Administration.

Support staff receive Incidents/Requests and identify on-line their acceptance and work progress using status codes - i.e. ‘Acknowledged, Investigating, Pending’ etc.

If the Incident is not acknowledged, or target response and fix times are not met, the system will inform the Support Centre on-line or via e-mail. Similar alerts can take place as defined by users for warnings of SLA thresholds - i.e. 30 minutes before the target is due.

Escalation or alerts via e-mail or sms can be facilitated to Management if Incidents are raised against pre-defined ‘Key Users’.

Further escalation can take effect if calls remain unresolved past their SLA thresholds - i.e. to management or to senior support staff on-line or via e-mail or sms.

Support staff at all levels can access historic records of similar Incidents or Problems filtered by customer, equipment, category,

18


Company X

department etc.

The system can also provide integration with standard troubleshooting and fault resolution on common packages.

Once resolved the technical Support Group will update the record with a causative categorisation - e.g. caused by user error - and check that the resolution information is valid for future reference.

Support staff will return calls to Support Centre responsibility for final closing and/or confirmation with customers. This should be an automated process.

If customers indicate that the call is still unresolved Support Centre can re-open and re-assign the record as necessary (e.g. only Support Centre staff might have re-open authority).

Problem resolution must be separable from call closing - i.e. the system must support multiple user-defined status codes, independent of data input in other fields - e.g. resolution text.

Integration with other workflow based or scheduling systems (for managing end to end processes like “orders to installations”)

7 Incident & Problem Tracking

Incident / Problem Tracking Mandatory DesiredIncidents and Problems should be traceable on-line using multiple sort criteria on any field e.g. by responsible group, customer, department, location, equipment type, asset number, system, date, status, category.

Lists presented by these queries will show totals and these can then be further sorted by priority, date, status etc.

There should be an on-line viewable audit trail of every update to the Incident/Problem record - date, time, user id, details of changes made.

There should be clear audit of change in Incident/Problem ownership, to allow reporting on re-referred problems (i.e. when passed from Support Centre to 2nd Level Support).

The system should automatically generate a unique reference number that can be used by the Customer for future enquires, although key access to calls should not be limited to this.

Incidents and Problems should auto-escalate over time - within varied service availability windows - according to pre-defined SLA targets.

This should be (system) user definable, with overdue or newly escalated Incidents/Problems being broadcast to groups and individuals on-line or via e-mail or sms, and according to SLA

19


Company X

thresholds.

Targets should be capable of being defined by Incident/Problem priority, equipment type or user/department.

Incidents and Problems should also be able to be redirected to different owners during their lifecycle.

Connections between Incident, Problem and Change records should be identified to show analysis of root causes - e.g. causative category/customer/equipment type/department/location

This should allow many-to-many relationships to be easily identified between Problems and Incidents - i.e. multiple Incidents linked to one Problem/Change etc.

Tracking of Incidents and Problems should be simplified with user-defined colour coding - e.g. by priority/SLA status/key customer group/assigned group

8 Service Level Agreements

Service Level Agreements Mandatory DesiredThe system should be able to support multiple SLAs, using pre-set response and fix times set against Incidents and Problems, customers and equipment.

These should be definable and traceable within multiple sets of working hours - e.g. 08.00 - 18.00 Monday - Friday for one department, 07.00 - 22.00 for another, 24 hours per day for another department/system etc.

The SLA escalation tables should be capable of being updated on-line, given the relevant authority, by users of the system.

The system should be able to escalate Incident and Problem reports over time according to the SLA assigned. This should include re-referral to other groups or individuals, increasing of severity (impact), and external alerts to other users and management via e-mail, sms etc.

The system should be able to calculate downtime of systems and components (including related configuration items), according to Incident status.

Incident and Problem records should 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. Customer unavailable/staff shortage/higher priority problem taking precedence.

20


Company X

A ‘stop the clock’ facility - i.e. to suspend the SLA escalation - should be available. This should be security controlled to limit the authority to key individuals or groups.

Example of SLA fix and response times:

SLA Table

SLA Priority Response Time Hrs

Fix Time Hrs

Escalation Procedure

Priority 1

Critical

Priority 2

Urgent

Priority 3

Medium

Priority 4

Low

Priority 5

Request

21


Company X

9 Change Management

Request Management Mandatory Desired

The system must provide the functionality to log and manage Requests for Change (RFCs) following an ITIL compliant Change Management process.

The Change Management functionality must be fully integrated with Incident, Problem & Configuration Management.

The Change Management system should also be clearly and easily identified or separated from the other functional areas to avoid confusion and error.

Pre-defined Change ‘templates’ should be offered to select standard RFC lifecycles e.g. Standard hardware procurement, New User, Payroll application amendment. These will include multiple stages and multiple tasks within each stage. These should include cross-references where applicable. E.g. Turnover reference number / Dendrite reference number.

Stages and tasks may run concurrently or be dependent upon completion of an earlier stage or task.

It should also be possible to create online ad-hoc RFC lifecycles for non-standard Changes.

Different levels of authorisation will be required for RFC approval depending upon the ‘type’ of Change i.e. Project, Major Task, Minor Task

Development worklists of outstanding RFC tasks by Customer Division will be required to allow tasks to be prioritised and viewed by priority

Timesheet functionality to record & track all Development staff time spent, by RFC and tasks within the RFC.

The viewing of RFC by stage and to be able to view the time spent on tasks in a number of different ways e.g. Division, Department, System, Project, Task.

10 Reporting Requirements

Reporting Requirements Mandatory DesiredThe report generator should be user definable, and parameter driven such as by Category, Priority, Customer, Support Group, Analyst, System, Date etc. It should be capable of using these fields to provide multiple sort arguments.

Screen displays and reports should be produced from search criteria for rapid response to customer queries on outstanding calls e.g. –

22


Company X

Customer name

Fault number

Date

Reports should be able to show the exceeding of thresholds as exception reports - e.g. show all instances of one Customer reporting more than two Incidents in each month, show all instances of one component for which more than one Incident is raised per month.

Reports should be able to calculate and show resolution times against different SLA targets - response times and fix times - and show summary information on Incidents missing the targets.

Reports should be able to be created that show trend analysis of Incident data - e.g. monthly numbers of Incidents by category, department etc.

Reports should be able to track fix times of re-referred Incidents and Problems between Support Groups from a Customer perspective. This should clearly identify the total elapsed time for an Incident/Problem regardless of when it was referred or re-referred between Support Groups.

The report generator should be able to perform mathematical calculations and show average resolution times of Incidents and Problems across departments and against SLA targets, as well as simple totals.

The report generator should include an interrupt facility to allow users to quit from potentially long searches - e.g. if too few parameters are defined. Alternatively these searches should be barred automatically and require an override.

Reports for managing assets effectively e.g. information on depreciation, age to inform renewals purchasing. Reports on assets on maintenance and the associated costs.

23


Company X

11 Suggested Sample Reports

Suggested Sample Reports: Mandatory DesiredPercentage resolved by each Support Group

Breakdown of Incidents, Problems and Requests by Customer groups

Breakdown by equipment item

Incidents/Problems outstanding by length of time

Outstanding by Support Group.

Downtime analysis by Resolver Group/Reason for Failure

Calls by Logging Category/period

Calls by Cause Category/period

Common Incidents by volume/period

Calls by Resolver Group/period

Calls by Support Analyst/period

Time spent resolving calls by call/support person/support group/period

Acceptance levels of customer sign-offs from ad hoc post solution survey

Mean time to fix/respond

Mean Time Between Failure (MTBF) by equipment.

Variance of response times to SLA

Variance of fix time to SLA

Variance of response/fix times by Priority

SLA Exception Reports

SLA Reason for Failure analysis

12 Format of Reports

Format of Reports Mandatory DesiredReports should have graphical conversion facilities into graphs/pie charts etc.

Print previews on screen prior to printing.

Reports should be ‘Customer presentable’ - i.e. of sufficient presentation quality to distribute to customers.

24


Company X

13 Scheduling of Reports

Scheduling of Reports Mandatory DesiredReports should be able to be run intermittently on request or scheduled in batch mode at pre-determined dates and times.

Show 12-month rollover to include seasonal trends.

For distributing reports (based on circulation lists) the system should be able to integrate with Exchange 2003

14 Additional Functionality This section highlights what functionality from the old “bolt-on” systems will be required in the new ITSM system. We do not wish to have to maintain these disparate non-integrated systems once we have the new ITSM, the functionality in these should be replaced by the functionality within the new ITSM.

Knowledge Base & Bulletin Board Mandatory DesiredFull knowledgebase functionality is available including:

provision of options based on key details logged

from keyword spotting in free-format text with natural language

searching and integration with external knowledge packages

This should include a self-help function that also provides Bulletin board functionality.

Other Mandatory Desired

HR and Telephony Systems Mandatory Desired

HR Data should be sharable between the new ITSM system and the Trent HR system and the Telephony system

Orders Database Mandatory Desired

25


Company X

Tasking Database Mandatory Desired

Time & Task Recording Mandatory Desired.

26


Company X

2 Technical Requirements

1 Overview A business critical application with a high level of proven technical quality is required. The system must provide a high level of resilience and fast recovery capability. Availability is required 24 hours a day, seven days a week, depending on server – i.e. no major overhead on housekeeping.

The Company X infrastructure comprises:

Cisco 6500 x3 & 3750-48P x72 network IP & IPX transport protocols Sun Solaris & Microsoft Intel application servers Microsoft file & print servers Windows 95, 2000 & XP desktop environment Oracle & M/S SQL database architecture Alcatel IP & Siemens ISLX telephony systems Business Objects for reporting

2 Interfaces

The following integration should be supported & proven: Microsoft Exchange 2003 mail system Network Management/automation tools interface e.g. SMS Web integration Microsoft Office components Oracle Financials

The system must be able to interface with the existing M/S Outlook e-mail system for Incident and SLA alerts. This should also allow messages to be sent ‘always on top’ to Support Groups and/or individuals. These messages will inform Incident owners of urgent issues in their area where the SLAs are nearing thresholds and when thresholds have been exceeded.

The interface should also allow Incident reports to be automatically generated by customer input from standard e-mail forms and via the web. Automatic escalation according to a SLA table should allow simple broadcasting (for information) as well as changes to Incident status - e.g. increased priorities, change of ownership. Customers should also be able to enquire on the status of their Incidents via e-mail and web forms.

The system should also be able to acknowledge receipt of the e-mail Incident, and automatically broadcast a message to the user on closure (also via e-mail).

The system should be able to link with standard industry interfacing protocols - VIM/MAPI/TAPI/TSAPI, and be capable of future integration with automated Network and Systems Management systems and platforms - and interactive voice response units (IVRs).

27


Company X

The system should be able to accept Incidents from external systems tools to raise Incident logs automatically according to pre-defined filter criteria.

Web integration is required to allow Customers to log new Incidents, access to knowledgebase (self-help) and Incident status information via either the Internet, Intranet or Extranet. Suppliers will need to explain/demonstrated the level of web functionality available in their product.

3 Performance Proven response times across the local and wide area network must be Sub-second

to each terminal/desktop for call logging.

Incident or Inventory records searches should be returned within 2 seconds.

Keyword or free-format searches should be returned within 2 seconds

The system will be accessed by up to 150+ users, including up to 20 - 60 concurrent users Similar demonstrable proven usage is required.

The system should be proven stable on the above platform and provide 99.6 % availability 24 hours per day, 365 days per year - i.e. no more than one total day downtime. This is dependent on availability of underlying Company X systems.

4 Security The system should provide encrypted algorithm password protection.

The system should provide user-definable field level access control - e.g. security access should be controllable by user group and individual system user, to data fields such as category, component type, customer group etc.

Read/add/delete/re-open access should similarly be user-definable at field and individual/group level.

All system users should be able to view relevant open and closed Incidents and Problems at any time.

User-defined screen layouts should be possible to provide different groups with relevant views of Incident and component details.

5 Contingency/Resilience The system should provide the facility to archive records automatically, according to

user defined criteria e.g. all Incidents and Problems over 12 months old, status ‘closed’ and category ‘password’. The supplier should provide full information on acceptable database sizing to support this.

28


Company X

It is expected that up to 15,000 Incident, Problem and Request records may be logged each month in future (currently 10,000). The database must be resilient such that it can be quickly recovered after outages or unexpected conditions e.g. using mirroring or equivalent technology.

A comprehensive system log should be available for analysis in the event of system failure.

Retrieval access times to archived data should not be excessive and should correspond to the age or user-defined priority of the data - i.e. 3-month old data should be accessible more quickly than 2 year old data, Virus category problems are accessible more quickly than password category.

29


Company X

3 Supplier Requirements

1 Company Stability Any supplier should be able to satisfy Company X that they are a financially stable

and reliable business partner.

If the supplier is not the manufacturer/author of the product then the manufacturer would also need to be identified as financially suitable.

2 Product Assurance Supplier should indicate how many full ITIL Implementations have been carried out

with clients in the UK.

Details of at least 5 fully integrated ITIL implementation sites in the UK must be provided – 3 for reference and visit – one which should be in the xxx sector (preferably xxx).

The supplier must provide support as required by Company X via a Support Centre, with a facility for out of hours support if required - e.g. voice messaging/escalation to pagers etc. The timings for cover provision should include core operational times 8am to 6pm alongside 24*7 support

An active User Group is required to demonstrate how product improvement can be made or raised as a client.

The supplier must demonstrate a commitment to the product and this market for at least 10 years.

3 Product Installation The supplier must be able to provide on request, full project management and

planning for implementation, as well as training and full user and technical documentation.

Supplier should use a proven project management approach – e.g. PRINCE2

The supplier should preferably have achieved ISO9000 accreditation & be in the process of attaining BS 15000. Full project planning, technical and business specification documents and procedures should be available at any time to Company X.

Full software development application support must be available if required.

END OF DOCUMENT

30

itsm s/w spec - barclay rae consulting itsm software... · web viewsupport staff at all levels can...

Documents