RFI ITSM Tool _Software__V1. 03 - Final

UNIVERSITY OF WITWATERSRAND, JOHANNESBURG

REQUEST FOR INFORMATION:

IT Service Management (ITIL) Tool (Software) Acquisition and Deployment

Wits Procurement Services Tel: (011) 717-1510 West Campus, Facilities & Services Building Fax: (011) 717-1750 Private Bag 3 Wits 2050

E-mail: [email protected]

1


REQUEST FOR INFORMATION

FOR

ACQUISITION AND DEPLOYMENT OF AN IT SERVICE MANAGEMENT

TOOL

VERSION 1.03

September 26, 2008

CONFIDENTIALITY

Copyright © 2008, by the University of the Witwatersrand. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, or otherwise, without the prior written consent of the University of the Witwatersrand.






2

SECTION 1 - BACKGROUND INFORMATION ............................................................................................... 3

1.1 WITS OVERVIEW...................................................................................................................................... 3 1.2 BACKGROUND ........................................................................................................................................... 3 1.3 SCOPE ...................................................................................................................................................... 4 1.4 SERVICE ACCEPTANCE CRITERIA ............................................................................................................ 5

1.4.1 Mandatory Requirements:............................................................................................................. 5 1.5 COMPATIBILITY / OPERATIONAL CRITERIA ............................................................................................... 6

1.5.1 Current and target business architecture: .................................................................................. 6 1.6 FUNCTIONAL / INTEGRATION CRITERIA .................................................................................................... 7

1.6.1 ITSM Service Desk ........................................................................................................................ 7 1.6.2 ITSM Incident Management ....................................................................................................... 10 1.6.3 ITSM Service Request Management ........................................................................................ 12 1.6.4 ITSM Problem Management....................................................................................................... 14 1.6.5 ITSM Change Management ....................................................................................................... 16 1.6.6 ITSM Release and Deployment Management......................................................................... 18 1.6.7 ITSM Configuration Management.............................................................................................. 20

SECTION 2 REQUEST SPECIFIC INFORMATION................................................................................. 22

2.1 EVALUATION: .......................................................................................................................................... 22 2.2 OTHER CONDITIONS: .............................................................................................................................. 24 2.3 ENQUIRIES: ............................................................................................................................................. 25

SECTION 3 SUPPLIER INSTRUCTIONS ................................................................................................. 26

3.1 COMMUNICATION REGARDING THIS RFI ................................................................................................ 26 3.2 SERVICE PROVIDER’S RESPONSES ....................................................................................................... 26

3.2.1 Confidentiality ............................................................................................................................... 27

SECTION 4 RESPONSE GUIDELINES..................................................................................................... 28

4.1 LETTER OF TRANSMITTAL....................................................................................................................... 28 4.2 SERVICE PROVIDER ORGANISATION ...................................................................................................... 28

4.2.1 Contact Information...................................................................................................................... 28 4.2.2 Reference Sites & Track Record ............................................................................................... 28 4.2.3 CV’s of operational staff .............................................................................................................. 29

SECTION 5 CHECKLIST AND APPENDICES ......................................................................................... 31






3

Section 1 - Background Information

1.1 WITS Overview

The University of the Witwatersrand, Johannesburg is a leading university in Africa, as reflected by its international standing and the quality of its graduates, many of whom have played a major role in founding industries in South Africa, including sectors such as mining, financial services and information technology. The University prepares students for managerial, professional and leadership positions in the public, private and non-governmental sectors. The University of the Witwatersrand has approximately 25,000 students and approximately 6500 staff; it is one of the biggest sources of skills in Africa. The University’s graduates occupy many senior positions in government and industry, and thereby have contributed considerably to the economy.

Wits has embarked on achieving its 2010 strategic objectives, which is based on the upgrading of the University and its research capability to target a ranking in the top 100 global universities. In support of this strategy The Office of the Director: CNS, in order to ensure adequate and appropriate good governance, has adopted the ITIL® best practice framework.

1.2 Background

The aim of the above-mentioned framework adoption project is to achieve a desired state / acceptable maturity level for the following IT Service Management (ITIL) processes:

• ITIL® Incident Management (To ensure incident logging, recording, prioritisation, classification, updating, escalation, resolution and closure in a formal, structured, controlled and accountable manner).

• ITIL® Request Fulfilment (To ensure formalised request classification, logging, recording, authorisation, fulfilment, and reporting)

• ITIL® Change Management (To ensure requesting, recording, assessing, approval, implementation & review of changes in a formal, structured, controlled and accountable manner)

• ITIL® Release and Deployment Management (To ensure requirements management, requesting, recording, building, testing, and deployment of releases in a formal, structured, controlled, and accountable manner)

• ITIL® Problem Management (To ensure problem recording, prioritization, classification, updating, escalation, resolution and closure in a formal, structure,






4

controlled and accountable manner. To provide, maintain and populate an information system [known error database] for purposes of addressing problems areas either before of after occurrences).

• ITIL® Service Catalogue Management, enabled by clarification of CNS Service Bundles (To provide a structure document that contains information about all services on offer by CNS. Will clarify service descriptions, customer responsibilities, any applicable metrics, and will assist with classification / categorisation of Incidents, Service Requests and Change Requests).

• ITIL® Configuration management (To support and ensure asset and configuration planning, identification, classification, as well as management and control over asset and configuration information in the appropriate data repositories [Configuration Management Data Base]).

Achievement of the aforesaid objectives is, where appropriate, dependant on business, information systems, and technology architecture design that will culminate in automation of many activities supporting the above-mentioned processes.

1.3 Scope

The scope of the RFI entails the CNS’s requirements around the acquisition and deployment of an IT Service Management Tool (Software) to support CNS’s adoption of the following IT Service Management) processes:

• Virtual Service Desk • Incident Management • Service Request Management • Problem Management • Change Management • Release and Deployment Management • Configuration Management

The supplier must, in view of the aforesaid, be adequately experienced and competent in the IT Service Management (ITIL) tool to provide for the specific needs required.






5

1.4 Service Acceptance Criteria

The goal of service acceptance / qualitative criteria is to support and encourage a good business relationship, good governance, as well as good contract management between CNS and the IT Service Management (ITIL) Tool (Software) supplier.

1.4.1 Mandatory Requirements:

Conformance and adaptation to current and target Information Systems Architecture

• Please note that supplier compliance to these requirements is a pre-requisite for further consideration of the supplier’s response. Non-compliance will culminate in immediate disqualification.

• ITSM Tool to support CNS current and target information systems architecture as depicted below:

��

��

ITSM Tool must be compatible with prevailing logical security application deployed, i.e. Trend Office Scan

ITSM Tool must support linkages for data transfer from the University’s Identity Management System(s)

ITSM Tool must support linkages to the University’s current voice logging system (Phillips CC250)

ITSM Tool to support web-logging / interaction

ITSM Tool to inform process actors via text messaging on designated process triggers requiring intervention






6

1.5 Compatibility / Operational Criteria

The goal of compatibility criteria is to ensure that the envisaged IT Service Management Software Suite can be deployed within the scope of CNS’s current business, information systems, and technology architectures.

1.5.1 Current and target business architecture:

• ITSM Tool to support the (expected) user base, function(s) and process(es) as depicted below:

��

��

��

CNS Service Desk / Service Desk Management Group

� 1 Director

� 1 Service Desk Manager

� 13 Service Desk Agents

� 6500 users

CNS Incident Management Group / Process

� 1 Director

� 1 Incident Manager

� 3 Support Tier Ticket Coordinators

� 5 Members of CNS Senior Management Organisational Group

� 1 Quality Services Manager

� 60 Incident Resolvers (1st, 2nd and 3rd line support)

CNS Change Management Group / Process

� 1 Change Manager


� 10 Members of the Change Advisory Board

� 1 Change Coordinator

� 70 Nominated Change Requestors

� 60 Change Resolvers

CNS Service Request Management Group / Process

� 1 Director


� 60 Request Resolvers (1st, 2nd and 3rd line support)

CNS Release � 1 Director






7

Management Group


� 60 Release Resolvers (1st, 2nd and 3rd line support)

CNS Asset and Configuration Management Group

� 1 Director


� 1 Asset and Configuration Manager

� 2 Configuration Analysts / Librarians

� 60 IT Consultants to interact and update asset and configuration records

CNS Service Request Management Group / Process

� 1 Director


� 60 Problem Resolvers (1st, 2nd and 3rd line support)

1.6 Functional / Integration Criteria

The goal of the functional criteria is to provide functional acceptance criteria to support the assessment of the ability of a supplier’s ITSM Tool to underpin CNS’s service management processes and improvement strategy. The functional criteria are developed as a framework / guideline to determine and validate the basic set of functional and integration requirements as defined in ITIL®:

1.6.1 ITSM Service Desk

��

��

��

1.6.1.1 Ability to support the management of performance metrics and time horizons (Service Level Agreements, Operational Level Agreements, Suppliers Agreements etc)

1.6.1.2 Ability to automate monitoring, notifications, escalation and reporting of progress and achievement against performance metrics and time horizons (service level targets)

1.6.1.3 Ability to facilitate flexible report generation and the production of management reports from historical data and information






8

��

��

1.6.1.4 Ability to facilitate customization of reporting functions. For example, ability to build custom report types based upon multiple field, multiple record selection

1.6.1.5 Ability to allow the creation of different access levels to the organizational knowledge (i.e.: CRUD)

1.6.1.6 Ability to facilitate the lifecycle of organizational knowledge submission, validation, acceptance, update and retirement

1.6.1.7 Ability to create a unique identifier for each knowledge record/document for ease of reference

1.6.1.8 Ability to allow for the entry of free-form text, images, attachments, etc

1.6.1.9 Ability to allow the creation and enforced use of data input rules for creating knowledge records

1.6.1.10 Ability to quickly create knowledge documents from existing incident, problem, change records, etc

1.6.1.11 Ability to allow the creation and maintenance of links between related knowledge documents or records

1.6.1.12 Ability to automate the population of knowledge records with author and owner data, creation date, as well as any other attributes desired by the organization

1.6.1.13 Ability to track and maintain knowledge ownership information

1.6.1.14 Ability to facilitate the identification of redundant or duplicate information, whether in a single record, or multiple records

1.6.1.15 Ability to automate the trending of knowledge use and identification of knowledge gaps

1.6.1.16 Ability to automate the notification of interested parties of new knowledge/solutions applicable to them

1.6.1.17 Ability to facilitate searching of knowledge documents and records

1.6.1.18 Ability to sort the data and documents using different search






9

��

��

parameters, applicable platforms, technology type, etc

1.6.1.19 Ability to show the comparative relevance of the information during a search

1.6.1.20 Ability to link knowledge documents from incident, problem, change records, etc

1.6.1.21 Ability to archive knowledge which is no longer relevant

Integration Criteria

1.6.1.22 Ability to support Incident Management by automating, escalation, and notification activities based on response and resolution targets

1.6.1.23 Ability to provide access performance metrics, time horizons (Service level Targets) applicable to Incident Management (For example, access to Service Level Agreement details, implementation windows, change blackout periods, and availability requirements)

1.6.1.24 Ability to facilitate the linkage of unique service levels to people records or Configuration Items

1.6.1.25 Ability to facilitate the production of real time performance dashboards related to service and process metrics

1.6.1.26 Ability to facilitate the verification and consistency of SLAs in their relationships to the Supplier Contracts and Operational Level Agreements (For example, ensuring that Incident response times in the OLA are not greater than what is promised in the SLA with the customer)

1.6.1.27 Does the Knowledge Management tool and its data repositories form part of, or link to the Configuration Management System

1.6.1.28 Ability to integrate with CMDB to support the association of Knowledge records to CI records

1.6.1.29 Ability to automate the creation of an RFC or service request when knowledge needs to be modified

1.6.1.30 Ability to facilitate the searching of multiple content repositories






10

��

��

1.6.1.31 Ability to facilitate searching of content that is stored in multiple formats

1.6.1.32 Ability to automate the creation and maintenance of FAQs for customer and user access

1.6.1.33 Ability to track how often a document or record is accessed or used

1.6.2 ITSM Incident Management

��

��

��

1.6.2.1 Ability to facilitate the creation, modification, resolution and closure OR cancellation of incident records



1.6.2.4 Ability to facilitate customization of reporting functions? For example, ability to build custom report types based upon multiple field, multiple record selection

1.6.2.5 Ability to support the classification of an incident by IT services as well as technology failure

1.6.2.6 Ability to facilitate the ability to automate incident models and workflow based on record classification (For example, automated prioritization, assignment, and escalation of Incidents based on the record classification)

1.6.2.7 Ability to depict number of target “hops” from incident logging until resolution, number of actual “hops” from incident logging until resolution, and exception reporting on the difference






11

��

��

1.6.2.8 Ability to support the input of free text for the recording of incident descriptions and resolution activities

1.6.2.9 Ability to allow the creation of different access levels to the Incident records (i.e.: CRUD)

1.6.2.10 Ability to restrict the ability to open, modify and close incident records based on role

1.6.2.11 Ability to automate the rapid classification and recording of incidents

1.6.2.12 Ability to support the ability to route and assign incident records to pre-defined support staff or groups

1.6.2.13 Ability to facilitate the association of incident records to user and customer data

1.6.2.14 Ability to enable priority, impact, and urgency indicators to be allocated to incident records

1.6.2.15 Ability to facilitate flexible report generation and the production of management reports from historical incident records

1.6.2.16 Ability to provide a secure historical audit log of all incident updates and resolution activities

1.6.2.17 Ability to facilitate incident closures by utilizing configurable incident closure categorization codes


1.6.2.18 Ability to facilitate incident matching and trending in support of problem identification

1.6.2.19 Ability to enable and maintain the relationships between incident, and problem records?

1.6.2.20 Ability to facilitate the closure of all incidents when the associated problem is resolved?

1.6.2.21 Ability to integrate with a CMDB to support the association of incident records to CI records

1.6.2.22 Ability to provide integration with the request management tool to






12

��

��

rapidly open requests based on an existing incident?

1.6.2.23 Ability to provide integration with the change Management tool to rapidly open changes based on an existing incident?

1.6.2.24 Ability to facilitate self help and communication options (For example, an interface that allows users to check the status of Incidents or view outage information)

1.6.2.25 Ability to facilitate the use of knowledge and or support scripts for incident diagnosis and resolution

1.6.3 ITSM Service Request Management

��

��

��

1.6.3.1 Ability to facilitate the creation, modification, fulfilment and closure of service request records



1.6.3.4 Ability to facilitate customization of reporting functions? For example, ability to build custom report types based upon multiple field, multiple record selection

1.6.3.5 Ability to depict number of target “hops” from service request logging until resolution, number of actual “hops” from service request logging until resolution, and exception reporting on the difference

1.6.3.6 Ability to provide a pre-defined list of services which can be requested by end users

1.6.3.7 Ability to have well-designed interface, making it easy for users to find services and order from a standard ‘menu’ of pre-defined






13

��

��

service options

1.6.3.8 Ability to provide the requestor with an entitlement-based view of the services they are authorized to request

1.6.3.9 Ability to automate request routing for appropriate authorizations (e.g.: Financial, security, etc.)

1.6.3.10 Ability to support the ability to route and assign service request records to pre-defined support staff or groups

1.6.3.11 Ability to allow the end user to submit service requests, get detailed request status visibility, and cancel service orders that are no longer necessary

1.6.3.12 Ability to automate the rapid categorization (e.g.: Provisioning vs. request for information), classification and recording of service requests

1.6.3.13 Ability to allow for matching of new requests against existing requests

1.6.3.14 Ability to facilitate customizable thresholds for automated escalation

1.6.3.15 Ability to enable priority, impact, and urgency indicators to be assigned to service request records

1.6.3.16 Ability to facilitate the creation of business rules for specific requests or groups of requests in order to automate the process, tasks, notifications, etc

1.6.3.17 Ability to facilitate complex request workflows through sequential and parallel tasking

1.6.3.18 Ability to facilitate the analysis of Service Requests to identify trends / measure ongoing demands for specific services and requests for those services

1.6.3.19 Can the tool link to feeds from other tools and departments, and provide information to other tools and departments (e.g.: HR, facilities)







14

��

��

1.6.3.20 Ability to support the automated creation of request records from open incident records

1.6.3.21 Ability to support incident trending and problem identification related to Requests

1.6.3.22 Ability to integrate with CMDB to support the association of request records to CI records

1.6.3.23 Ability to provide linkage between service request records and the Service Catalogue

1.6.3.24 Ability to facilitate billing or recover for services rendered (i.e.: Does it link to a financial tool or module)

1.6.3.25 Ability to support automated costing and billing during / following request fulfilment

1.6.3.26 Ability to automate the recording and reporting of the ongoing costs of request management against particular cost centers, etc

1.6.3.27 Ability to open a service request through the Service Catalogue interface

1.6.3.28 Ability to provide email notifications to end users and other interested parties as the request fulfilment progresses

1.6.3.29 Ability to provide support for the coordination of back-end fulfilment across multiple other tools and processes (e.g.: Access Management process for access requests, Portfolio Management system for project or enhancement requests, and non-IT systems for requests such as facilities work orders)

1.6.4 ITSM Problem Management

��

��

��

1.6.4.1 Ability to facilitate the creation, modification, and closure of problem records






15

��

��



1.6.4.4 Ability to facilitate customization of reporting functions.

1.6.4.5 Ability to support the ability to distinguish between an incident and problem records

1.7.4.6 Ability to facilitate the automated matching of incidents to problems and known errors

1.6.4.7 Ability to support the ability to route and assign problem records to pre-defined support staff or groups

1.6.4.8 Ability to enable impact and urgency codes to be assigned to problem records

1.6.4.9 Ability to facilitate progress tracking and monitoring of problems

1.6.4.10 Ability to provide historical data on problems and known errors for use by support staff during the investigation process

1.6.4.11 Ability to facilitate the entry of free text for the recording of problem descriptions and resolution activities


1.6.4.12 Ability to facilitate the association of problem records to change records

1.6.4.13 Ability to integrate with CMDB to support the association of problem records to CI records

1.6.4.14 Ability to facilitate the association and maintenance of the relationships between incident and problem records

1.6.4.15 Ability to facilitate the automated creation of problem records from incidents records






16

��

��

1.6.4.16 Ability to enable the problem management team to communicate status and progress reports, as well as temporary solutions and workarounds to the Service Desk staff

1.6.4.17 Ability to automate the increase in the severity or impact classification of a problem according to the number of associated incidents and/or the number of end users affected

1.6.5 ITSM Change Management

��

��

Functional Criteria

1.6.5.1 Ability to facilitate the recording and storage of change requests in an easily accessible format



1.6.5.4 Ability to facilitate customization of reporting functions.

1.6.5.5 Ability to allow only authorized personnel to submit change requests

1.6.5.6 Can the tool support the entry of free text as well as the use of codes for change request classification (category and priority)?

1.6.5.7 Ability to facilitate the monitoring and tracking of the lifecycle of a Change request Ability to facilitate the ability to control, read, write, and modify access for change management staff, change builders, testers, etc., to update change records throughout the change lifecycle

1.6.5.8 Ability to support the ability to route and assign change records to pre-defined support staff or groups






17

��

��

1.6.5.9 Ability to facilitate the ability to reject changes

1.6.5.10 Ability to facilitate the recording of impact assessment information within the change record in order to support the change authorization process

1.6.5.11 Ability to facilitate the production of change schedules

1.6.5.12 Ability to facilitate the recording of back-out procedures within the change record

1.6.5.13 Ability to facilitate the scheduling of change reviews for implemented changes after definable time periods


1.6.5.14 Ability to establish and maintain the logical association between incidents and changes (For example, automated linkage when a Change record is created based on an existing incident record)

1.6.5.15 Ability to facilitate the communication of change information and schedules that can be distributed to the role players such as the Service Desk and user groups (For example, the use of email, change schedules and whiteboard communication methods)

1.6.5.16 Ability to establish and maintain the logical association between problem records and changes (For example, automated linkage when a Change record is created based on an existing problem record)

1.6.5.17 Ability to facilitate the task of updating CI information in the CMDB (For example, is the Change tool integrated with the CMDB to the level that CI records can be associated to the Change record and be updated as part of the Change Management workflow)

1.6.5.18 Ability of the change tool to access CI detail to assist in the assessment of Change authorization (For example, the use of impact information such as relationships and CI criticality when considering authorization of a Change request)

1.6.5.19 Ability to facilitate integration with release and deployment activities by supporting release and change workflow integration at the task and record level






18

��

��

1.6.5.20 Ability to facilitate the identification of post implementation impact and resource utilization for completed changes (For example, are Incidents and Problems resulting from an implemented Change easily identified? Also, can planned vs. actual resource utilization be tracked and analyzed?)

1.6.5.21 Ability to integrate with the CMDB to gather or validate required information for release builds and deployment activities?

1.6.5.22 Ability to facilitate the update of the CMDB with new version and CI information after the deployment of a release

1.6.5.23 Ability to integrate with CMDB to support the association of release records to CI records

1.6.6 ITSM Release and Deployment Management

��

��

Functional Criteria

1.6.6.1 Ability to facilitate the management of the full lifecycle of release and deployment management



1.6.6.4 Ability to facilitate customization of reporting functions

1.6.6.5 Ability to facilitate the establishment and governance of release readiness criteria (For example, the ability to establish tasks or auditable requirements which support the decision process for determining if all release requirements have been met for deployment approval)

1.6.6.6 Ability to incorporate or integrate with a Definitive Media Library (DML)






19

��

��

1.6.6.7 Ability to support workflow integration with a DML to support release deployment and provisioning activities

1.6.6.8 Ability to facilitate the building, bundling and scheduling of different types of release packages for deployment

1.6.6.9 Ability to facilitate the flexible identification and control of all aspects of a release package such as software, hardware, documentation, training requirements, etc

1.6.6.10 Ability to support the ability to route and assign release records to pre-defined support staff or groups

1.6.6.11 Ability to facilitate the authorization and scheduling of release deployments in conjuncture with a Change Management process and tool

1.6.6.12 Ability to facilitate the enforcement and coordination of release validation and testing activities

1.6.6.13 Ability to facilitate the versioning of release components and packages

1.6.6.14 Ability to facilitate the management of the rollback of release packages to previous versions


1.6.6.15 Ability to ensure that release deployments are subject to scheduling and approvals requirements managed by the change management process

1.6.6.16 Ability to facilitate the automated updating of the CMDB based prior to or following an approved release

1.6.6.17 Ability to facilitate the management and tracking of software licenses

1.6.6.18 Ability to have the Ability to handle varying Release models such as large-scale or phased deployments






20

1.6.7 ITSM Configuration Management

��

��

Functional Criteria

1.6.7.1 Ability to facilitate the registration and management of an organization’s logical, physical and virtual Configuration Items (CIs)? For example, services, systems, hardware, software, documents, virtual machines, etc

1.6.7.2 Ability to facilitate the recording of user definable CI attributes (For example, serial number, version, and location attribute)

1.6.7.3 Ability to facilitate the control of attributes through role based security and business rules

1.6.7.4 Ability to facilitate the automated validation of CI data through use of data validation and reconciliation techniques (E.g.: Enforcement of standard naming conventions and reconciling federated data sources)

1.6.7.5 Ability to facilitate the establishment of user definable relationships between CIs (For example, parent/child, peer-to-peer, upstream/downstream, installed on, hosts, etc...

1.6.7.6 Ability to support user defined CI lifecycle status management - planned, ordered, under development, in test, implementation, production, in repair/maintenance)

1.6.7.7 Ability to facilitate role based access to the CMDB for read, write, and modify activities

1.6.7.8 Ability to facilitate the recording of CI baselines or historical information (For example, reverting to a previous version of CI Configuration in the event that a Change fails)

1.6.7.9 Ability to support data federation and reconciliation with other data sources within the Configuration Management System

1.6.7.10 Ability to facilitate the verification of the CI data with the actual physical environment by automated or manual means (For example, the use of Systems Management tools to validate real time vs. static information)

1.6.7.11 Ability to facilitate the linking of CI records to source content






21

��

��

residing in the Definitive Media Library

1.6.7.12 Ability to enable priority, impact, and urgency indicators to be assigned to configuration items/records

1.6.7.13 Ability to facilitate customization of reporting functions (For example, ability to build custom report types based upon multiple field, multiple record selection)

1.6.7.14 Ability to support the ability to route and assign configuration records to pre-defined support staff or groups

1.6.7.15 Ability to provide flexible management reports regarding CI inventory, asset and financial information to facilitate Configuration audits


1.6.7.16 Ability to facilitate the integration and association of CMDB data with Incident records

1.6.7.17 Ability to facilitate incident management in providing business criticality and impact indicators of failed CIs for classification of Incident records

1.6.7.18 Ability to facilitate the integration and association of CMDB data with problem management records

1.6.7.19 Ability of the CMDB to facilitate proactive problem management by identifying infrastructure components that are problematic or unstable (For example, does CI status accounting provide information about weak or maintenance prone configuration items)

1.6.7.20 Ability to facilitate the integration and association of CMDB data with the change management records

1.6.7.21 Ability to facilitate the assessment and approval of change requests by providing information on impacted CIs

1.6.7.22 Ability to prevent changes from being made to the IT environment without authorization via change management (For example, CIs which are in a locked status due to month end schedules or controlled attributes which require a change record relationship for update)






22

��

��

1.6.7.23 Ability to facilitate the identification of different RFCs that pertain to the same CIs

1.6.7.24 Ability to provide a form of (graphic) display to show the relationships between CIs

1.6.7.25 Ability to facilitate the automated discovery and re-establishment of relationships when CIs are added, deleted, or updated

Section 2 Request Specific Information

2.1 Evaluation: Responses will be evaluated using a predefined set of evaluation criteria. The evaluation criteria is designed to reflect WITS’ requirements in terms of identifying a suitable supplier and to ensure the selection process is transparent and afford all suppliers a fair opportunity for evaluation and selection. A high level view of the aforesaid evaluation criteria is as depicted hereunder, and suppliers are required to indicate their acceptance accordingly:

Criteria Description ��

��

2.1.1.1 Completeness of the tender document and any other value added services provided.

Conformance to the mandatory requirements, qualitative, compatibility / operational, and functional / integration criteria:

2.1.1.2 Conformance to the mandatory requirements, as depicted above

2.1.1.3 Conformance to the qualitative criteria, as depicted above.

2.1.1 Requirements

2.1.1.4 Conformance to the compatibility / operational criteria, as depicted above.






23

2.1.1.5 Conformance to the tool specific ITSM functional criteria.

2.1.1.6 Conformance to the tool specific ITSM integration criteria.

2.1.2.1 Is the supplier an authorised ITSM tool sales partner & service provider

2.1.2.2 Does the supplier have a good track record? (with references)

2.1.2.3 How many years has the supplier been in existence?

2.1.2.4 How many tool deployments has the supplier been engaged in the last 5 years?

2.1.2.5 What is the supplier’s short / medium / long term strategic intent

2.1.2.6 Where is the supplier represented in terms of a) geographic location, b) existing customer base, c) products or services provided, and d) number of staff to support its service / install base?

2.1.2.7 What are the supplier’s staff competency and skill levels to support this RFI’s delivery?

2.1.2 Company profile and experience

2.1.2.8 Should the supplier’s response and tool be accepted, will the resulting revenue exceed 50% of the supplier’s annual turnover?

2.1.3 Broad Based Black Economic Empowerment

*BEE Status with appropriate certification required.

2.1.4 Existing relationship with higher education institutions

Has the supplier delivered and deployed similar products to higher education institutions in South Africa / Internationally?






24

2.1.5 Communication style and willingness to provide information

To what extent is the supplier willing to support a research environment, specifically with regard to technical discussions, workshops in support of holistic solutions, sharing of experiences, etc;

Please note that -

• Submitted responses will be evaluated based on the above criteria and requirements as also discussed in the appendices.

• Submitted responses should conform to this format, i.e.

o where Yes / No answers are required, to provide Yes / No answers only;

o where answers to other closed / open ended questions are required, to provide answers accordingly; and

• Any response that does not conform fully to the instructions and requirements in this RFI may be disqualified.

2.2 Other Conditions:

Indicate in respect of each item, whether you concur or not. Each appropriate space must be clearly marked "Yes" or "No". Further elaboration or explanations can be made on separate attachments to your reply. In such cases, the correct cross-reference must be made, as comments opposite that particular paragraph as well as on the applicable attachment/s. Failure to do so will imply non-compliance.

��

��

!"!"# �$%&'� &'�%'&'(�)� �

�� WITS will not accept any responsibility for accounts/expenses incurred by the successful supplier.

�

!"!"! ��(� ��* �+ $&�(',��

�� The supplier will also ensure that he/ she complies with all relevant local authority by-laws in terms of trading licenses, etc.

�

!"!"- �+.$+�( �,� �,��,��& �+�',*) �






25

��

��

�� A selected RFI will be subjected to a formal RFP process �

�� WITS reserves the right not to invite responses or proposals from any WITS employee/contractor/consultant or service provider or their direct family

�

!"!"/ '�*$�(�'�& �+&�(',��)� �

!"!"0 �+�+�+��+�) �

�� WITS reserves the right to contact references. �

�� WITS reserves the right to do a credit check on all suppliers �

��

��

��

2.2.6 WITS would prefer a vendor who can supply software products & services (please indicate your ability to provide these services accordingly)

2.2.7 WITS requires a close business partnership and understanding with the vendor that enables a research environment, specifically supporting technical discussions, hold workshops in support of holistic solutions, etc.

2.2.8 The Vendor must allow a suitably skilled Wits person to administer, support, and configure the IT Service Management Tool at all times.

2.3 Enquiries: Enquiries with regard to this document must be forwarded in writing to:

The ICT Procurement Category Manager

University of Witwatersrand Physical address: Wits West Campus, Facilities and Services Building Postal address: Private Bag 3 WITS 2050, Johannesburg






26

Telephone: - 011 717 1510 Fax: - 011 - 717 1750 E-mail: [email protected] Enquiries with regard to the technical requirements stated in this document must be forwarded in writing to:

The Director (acting): Computer Network Services

University of Witwatersrand Physical address: 1st Floor, Senate House Postal address: Private Bag 3 WITS 2050, Johannesburg Telephone: - 011 717 1662 E-mail: [email protected]

Section 3 Supplier Instructions

3.1 Communication Regarding this RFI

Suppliers who do not abide by this provision risk disqualification from consideration at the time of the Response’s evaluation.

Responses to the RFI must be returned to the WITS Procurement Services for ATTENTION: THE ICT PROCUREMENT CATEGORY MANAGER, no later than 12:00 on Wednesday, 08 October 2008, with reference RFI FOR IT SERVICE MANAGEMENT TOOL – COMPUTER NETWORK SERVICES.

3.2 Service Provider’s Responses

This RFI consists of the documents enumerated in the WITS Transmittal Letter and enclosed therewith. The RFI must be prepared and submitted in strict conformity with the instructions set forth in this document and the Transmittal Letter. Failure of respondents to comply with all requirements contained in these instructions may render the RFI non-responsive, in which case it will be disqualified from consideration.






27

The respondents must prepare and submit their responses to the RFI in the format prescribed by the Response Guidelines.

The response must be delivered before 12:00 PM on the deadline as indicated. Any response received after the closing time may be disqualified.

Please note that the response must be on printed/bound copies

The use of facsimile or email for delivery of the final response is not acceptable and any response submitted in such manner will be disqualified.

The format of the response should be as follow:

• 2 X printed and bound copies of the main response document with attachments

• 1 X Soft copy on CD or flash drive of the response (documents must be in original format and must not be in PDF format)

• Please ensure to indicate your company name clearly on each page footer or the main response document, as well as Appendix pages

3.2.1 Confidentiality

This RFI and all materials submitted by WITS must be considered confidential. The respondent must not use, disclose, or release information contained in the RFI documents to any third party except for the sole purpose of preparing their response.

When submitting confidential material, the respondent must clearly mark it as such and indicate the conditions of use.






28

Section 4 Response Guidelines

All responses must conform to the structure described in section 4 below and include the detailed completion of section 2, submitted in full with each response:

4.1 Letter of Transmittal

Include a letter of transmittal, on an official letterhead of the submitting organisation, signed by an authorised representative of the organisation. Also, include the names of individuals authorised to negotiate with WITS.

4.2 Service Provider Organisation

4.2.1 Contact Information

i. What are the corporate address, mailing address, e-mail address, and phone number of your company's main offices?

ii. Who in your local office will be our primary contact during the evaluation process? Provide their e-mail address, direct phone and fax numbers and an address if different from the one above.

iii. Who in your organisation is authorised to negotiate a contract with WITS? Provide their names, direct phone numbers, fax numbers and e-mail address.

4.2.2 Reference Sites & Track Record

Company reference table:

References supplied must comply with the following minimum requirements:

• The reference must be a current client that has done business with your company for longer than two years

• The contact person supplied must be a senior manager / director at your client • At least three references must be supplied (maximum of five references)






29

4.2.3 CV’s of operational staff

Please submit the CV’s of operational staff that will be responsible to sell, manage and implement the solution within the formats below.

CV of Service (Field) engineer

Name and surname

Period with company

Position

CV of sales coordinator

Name and surname

Period with company

Position

Qualifications

Projects of similar nature Client name Duration of involvement Turnover of project

Project 1

Project 2

Project 3






30

Qualifications


Project 1

Project 2

Project 3

CV of IT engineer

Name and surname

Period with company

Position

Qualifications


Project 1

Project 2

Project 3






31

Section 5 Checklist and Appendices

DOCUMENTS YES NO

RFI Response

Vendor Registration Form (Appendix B)

Letter of Transmittal

General Conditions Table

Reference sites Provided

Contact Information-Sec 4.2.1

Reference Sites –Sec 4.2.2






32

Appendix A – Vendor Registration Forms

Forms must be fully completed and all supporting documents submitted.

Dear Potential Supplier/Vendor/Service Provider

In order to be on WITS Procurement Database as an approved Vendor you have to complete applicable forms and submit required information

Attached please find a Vendor Registration Form for your perusal and completion. You are requested to provide as much detail as possible, covering all sections and attaching all relevant documents.

In addition, please supply the following documents and/or details in order to accurately determine your company’s BEE and SME status:

• BBBEE Accreditation Document(if available) • Company Registration documents, Share certificates and joint venture agreement(s). • Copies of the ID documents of Directors/members/shareholders. • Tax Clearance Certificate • Vat Certificate(Where Applicable) • Company organogram • Company letterhead. • An Copy cancelled cheque or stamped letter from the bank, verifying the banking

details. (Please note that any changes to bank details in future will be subject to the same requirement and only original documents will be allowed)

Kindly Submit requested information with your RFI response:

Regards

Chabeli C Ramakatane

Chief Procurement Officer






33

REGISTRATION OF SUPPLIERS ON WITS PROCUREMENT DATABASE

Supplier Registered Name:

Business Registration No:

Vat Registration Number

Trading Name:

Physical Address

Postal address

Nature of business:

Types of products/services provided:

Commodity Group

Main Telephone No.:

Fax No.:

Web site:

Sales Department: Contact Person:

Sales Person Contact Number:

E-Mail 1(Company)

E-Mail 2(Sales Person)

BANKING INFORMATION Savings Cheque Trans

Bank Name/Account Number/Branch

1. OWNERSHIP

1.1 Is there equity ownership by BEE? Yes No

1.2 Is this a Joint Venture entity? Yes No

1.3 If 1.1 or 1.2 is yes, provide names of Black Directors hereunder and % shareholding/holding company:

% %

% %






34

1.4

What is Black ownership percentage? %

What is Black Women ownership percentage?

%

2. EXECUTIVE MANAGEMENT AND BOARD MEMBERS’ INVOLVEMENT

2.1 List All Black Directors/Board Members:

Name Position Name Position

What is Black directorship percentage? %

What is Black Women Directorship Percentage %

2.2 What percentage does Black Senior Management constitute? %

NB: Please provide an organogram from Directors to Junior Management, indicating racial classification

3. HUMAN RESOURCES

3.1 Is there an Employment Equity plan in your organization? Yes No

3.1.1 If yes, indicate the DOL status with regards to the plan and attach certificate:

3.2 Please complete the following Employment Equity statistics:

Male Female

Occupational Levels

African Coloured Indian White African Coloured Indian White Total

Top Management






35

Senior Management

Professionally qualified experienced specialists and mid-management

Skilled technical and academically qualified workers, junior manage-ment, supervisors, su-perintendents

Semi-skilled and discretionary decision making

Unskilled and defined decision making

TOTAL

3.3 Skills development expenditure as a proportion of total payroll:

3.3.1 What is your total payroll per annum? R

3.3.2 What is your total training expenditure for the past financial year? R

3.3.3 What percentage of training expenditure was allocated to HDI’s? %

4. INDIRECT EMPOWERMENT

4.1 Does your company have a Preferential Procurement Policy and if so do you have scorecard to measure that? Yes No

4.2 What percentage of goods/services was sourced from Black suppliers?

%

4.3

Have you invested or offered business and non-business related support to BEE companies? Yes No






36

If yes, state:

Company Total Assets Nature of Investment/Support

5. SMME STATUS

Total full-time paid employees

Total annual turnover Total gross asset value (fixed property excluded)

REMARKS

(for office use)

6. TRADE REFERENCES

Please provide at least three trade references:

Client Contact Person Contact Number Account Number

1)

2)

3)

I hereby declare the information provided is true and correct.

________________________________________________

___________________________

DATE

________________________________________________