STC Imf

Request for Proposal
Shared Services Sector

Planning and Performance GD

- Confidential
This document and the information contained herein is restricted to authorised persons
having a need to know within Saudi Telecom Company (STC) and the approved vendor.

Item Master File Enhancement Project
(IMF EP)

Version: Final
Issue date: 15-May-2010

Request For Proposal
IMF-EP RFP Final Version Business Support Dept Page 2 of 49
Confidential - See First Page For Restrictions

Table of Content
1 INTRODUCTION & OVERVIEW ........................................................................................................ 4
1.1 Statement of Confidentiality ...................................................................................................... 4
1.2 Purpose of the RFP .................................................................................................................. 4
1.3 Project Overview....................................................................................................................... 4
1.3.1 STC Business Requirements ........................................................................................ 4
1.3.2 Background .................................................................................................................. 4
1.3.3 Project Description ....................................................................................................... 6
1.3.4 Baseline Table of Items and Services based on the new code .................................... 10
1.3.5 Recoding current Items (Inventory, Assets and Services) using the new code ............. 11
1.3.6 Cross-Referencing Old to New Item Codes ................................................................ 11
1.3.7 Historical Transactions Data Conversion .................................................................... 11
1.3.8 Relation with Other Projects ....................................................................................... 12
1.3.9 Provision of On-Site PM and Consultants ................................................................... 12
1.3.10 Provision of an Independent Consultant ..................................................................... 12
1.3.11 IMF-EP Timeframe ..................................................................................................... 13
1.3.12 Development of STC Cataloguing Procedures ............................................................ 13
1.4 Anticipated Project Time Frame .............................................................................................. 13
1.5 Vendor Response ................................................................................................................... 13
1.6 Questions relating to the RFP ................................................................................................. 14
1.7 Submission of Proposals ......................................................................................................... 14
1.8 Selection Process & Evaluation Criteria .................................................................................. 14
1.8.1 Vendor Presentation ................................................................................................... 15
1.8.2 Vendors Conference .................................................................................................. 15
2 STC REQUIREMENTS .................................................................................................................... 16
2.1 General Requirements ............................................................................................................ 16
2.1.1 Server and Storage Requirements .............................................................................. 16
2.1.2 Data Networking Requirements .................................................................................. 17
2.1.3 Data centre Requirements .......................................................................................... 17
2.1.4 Security Requirements ............................................................................................... 17
2.1.5 Integration Requirements ........................................................................................... 17
2.1.6 Mediation Requirements ............................................................................................. 18
2.1.7 Data and Application Architecture Requirements ........................................................ 18
2.2 IT Functional Requirements .................................................................................................... 19
2.3 Performance & Workload Requirements ................................................................................. 22
2.4 Reliability, Availability & Serviceability Requirements .............................................................. 22
2.5 Project Deliverables ................................................................................................................ 23
2.5.1 Data Model................................................................................................................. 24
2.5.2 Application Model ....................................................................................................... 24
2.5.3 Contingency Plan ....................................................................................................... 24
2.5.4 Knowledge Transfer ................................................................................................... 25
2.5.5 Documentation ........................................................................................................... 25
2.6 Documentation- and STC Software Ownership ....................................................................... 26
2.7 Project specific Terms & Conditions ........................................................................................ 26
3 VENDOR PROPOSAL REQUIREMENTS ........................................................................................ 27
3.1.1 Mandatory Proposal Outline ....................................................................................... 28
3.1.2 Detailed Instructions and Explanations ....................................................................... 28
4 APPENDIX 1: GENERAL TERMS & CONDITIONS ......................................................................... 45
5 APPENDIX 2: INFORMATION ABOUT STC .................................................................................... 47
5.1 STC - Organisation Overview & Mission .................................................................................. 47

5.2 Current IT Environment ........................................................................................................... 47
5.3 Major Application Systems ...................................................................................................... 48
5.4 STC Test & Acceptance Procedure ......................................................................................... 48

APPENDIX 3: INTEGRATION REQUIREMENTS FOR IT PROJECTS
APPENDIX 4: INFRASTRUCTURE REQUIREMENTS FOR STC IT PROJECTS
APPENDIX 5: ARCHITECTURE REQUIREMENTS FOR STC IT PROJECTS

APPENDIX 6: GENERAL-SECURITY-REQUIREMENTS FOR IT PROJECTS

APPENDIX 7: MEDIATION REQUIRMENTS FOR IT PROJECTS

APPENDIX 8: STC DATA CENTRE HANDOVER POLICY

1 INTRODUCTION & OVERVIEW
1.1 Statement of Confidentiality
This Request for Proposal (RFP) and all materials provided by Saudi Telecom, concerning the affairs of the
company, must be considered confidential. It must not be forwarded to any third party for evaluation or for
any other purpose without the written consent of STC.
When submitting confidential material to STC, the vendor/reseller must clearly mark it as such.
1.2 Purpose of the RFP
The purpose of this Request For Proposals (RFP) document is to invite qualified vendors to submit
proposals for suitable, cost effective solutions for STC for Item Master File Enhancement Project.

STC intends to evaluate and select vendor products & services based on the responses to this RFP and
award contract(s) to the successful vendor(s) for deployment.

This will be a contract for work & services NOT a contract of service. STC will therefore pay only for
results/deliverables not for activities.
1.3 Project Overview
1.3.1 STC Business Requirements

General Directorate of Material Management is vested with the responsibility of planning and managing all
matters related to Materials, Inventory and Warehousing including management and control of STC Item
Master File.

Business Support Department (BSD) of the General Directorate of Planning and Performance holds
overall responsibility for managing Shared Services sectors relationship with the all sector. BSD is also
assigned to manage all IT projects for the sector.

STC is reviewing its strategy in the area of Oracle Business Applications to get them aligned with future
corporate requirements and provide a dynamic foundation for compatibility with latest technologies and
identification methodologies that are accepted within the industry and across standards bodies and
equipment manufacturers. The purpose of this operation is to analyze current STC Material Items Table and
provide advice and support for planning and execution of redesigning the used coding structure and
enhancing its content. In addition to solving operational inadequacies, this redesign should fulfil long term
analytical requirements in all work related to Inventory Items. The plan should provide a methodology for
planning and execution of Items coding, classification and categorization, unique identification, data
enrichment, and defining attributes and accounts. This plan should utilize a naming methodology that is
supported within the industry. The identification solution May also provide the following capability:
o Support for equipment manufacturers compliance to Vendor requirements
o Access to Vendor systems and data repositories.
o Vendor coding standards development.
o Vendor naming standards technical specification documents.

This plan May also focus on the unification of Item coding throughout STC.
1.3.2 Background
During the implementation of Oracle Inventory System, STC designed the currently used Material
Identification Code (MIC Number) which is a seven digit number to identify Material Items, Assets and
Services. The first one, two or three digits identify an entity type or a category and the rest of the number is
reserved for the sequenced item numbers - as the following table shows:


Category Code Category Number of Items
0 Fixed Assets
594
1 Services
225
2 Cables
283
3 Outside Plant (External Network)
965
4 Outside Plant (External Network)
93
500 Office Supplies and Stationary
2825
57 Building Materials
8243
58 Vehicles Materials
2391
6 Outside Plant Equipment and Tools
1890
7 Switching Spare Parts
26716
8 Not Used
-
9 Transmission Spare Parts
9774

(Numbers shown here are not final but can be used as an indication)

This coding and categorization scheme does not support Material Department (Standardization Section)
anymore in dealing with Materials. It does not provide a reliable categorization method. The lack of an
automated tool to deal with categorizing and coding Material Items creates difficulties such as duplicate
codes for the same item and inaccurate items database and absence of technical attributes for Engineering
and Technical items for Telecom Network Material and Spare Parts. The lack of a common identification
methodology creates inconsistent views of information across various organizations within STC. There is no
unifying information infrastructure that would ensure consistent representation of network equipment and
their attributes across multiple organizations and systems. Currently STC utilizes a number of different
naming conventions within different organizations and technology areas. While each area may be effectively
utilizing information based on specialist staff and local area expertise, there is little cross-domain
consistency and automation.

The following list some comments about the current MIC Number:

Old method and process that does not have significance anymore
Does not provide an acceptable coding and categorization scheme
Allows duplicates without an easy way to detect them early in the process
Descriptions does not follow any standard and allow for more duplicates
Gaps within the categorization part
Does not have a modern coding and categorization procedures or tools
Does not have any auditing mechanisms
Does not utilize manufacturers serial numbers
Does not utilize consistent identification and representation of network equipment across multiple
equipment manufacturers
Does not support physical counting especially for Switching Cards (PCBs)

1.3.3 Project Description
The following sections provide a description of the project main tasks, the expected deliverables, the project
approach and assumptions and constraints important for the project implementation
1.3.3.1 Designing new codes for Material, Assets and Services
The selected contractor should first identify and document the present method of operation identifying
existing gaps and requirements to be accommodated in the design of the future method of operation for both
the coding convention and the process for generating.
The selected contractor must perform an overall operation to investigate current item master file and suggest
an appropriate coding scheme with a suitable categorization for material items, assets and services. He
should compare STC item master file to at least three internationally accepted coding schemes to be
selected with Material Department from the following list or other suitable schemes:

Federal Catalogue System
Federal Supply Classification
National Stock Number
National Codification Bureau
United Nation Classification & Coding System
Material & Equipment Standards and Codes (Shell)
North America Industry classification System NAICS (Canada)
NATO Codification System
British Telecom Coding System

After selecting the most appropriate three international standards for STC work, the contractor should advise
to use the best standard for STC to be utilized as a basis for constructing STC Coding Table. If none of the
standards fulfil STC exact requirements, the contractor must design a special coding scheme for STC. The
coding method must follow the specifications of being a Smart Code that fulfils current and future STC needs
and be one of the tools that allow STC Sectors to achieve their strategic objectives. The selected standard
should provide a strong basis for STC IMF to handle all work related to Material Management and cover all
the requirements. In addition to solving operational inadequacies, this redesign should fulfil long term
analytical requirements in all work related to Inventory Items.

STC is currently using MIC number for Inventory Category Items, Fixed Assets Category Items and Services
Category Item. The study should include advantages and disadvantages of whether to continue using one
code for all entities or use a separate code for each, and list the implementation requirements for each
method. The contractor is responsible for finalizing the design of the structure of the new code and securing
the approval of all relevant STC Departments. The general requirements of this project are :

1. To enable an effective management for IMF through developing new business process and
deploying data management tool.
2. To provide a reliable foundation for data used across many applications and departments with
ultimate goal to provide single view of truth (central source). The solution has to provide and
support scalable infrastructure.
3. To recommend a new standard to codify, classify, and categorize items in IMF.
4. To submit a comprehensive Taxonomy scheme with complete codification and classification
structure. The vendor has to perform a proof of concept for his solution and demonstrate his
taxonomy with real life data. In addition, provide a full description of the core of its solution including
: Taxonomy, description of all category levels, assets classification, coding schema to be used,
policy to be used to capitalize assets
5. To include a life cycle approach to handle items in IMF.
6. To improve and maintain data quality and consistent sets of IMF.
7. To support governance, stewardship, and cross-functional coordination.
8. To adhere to security and privacy requirements.

As part of this operation, it is expected that the contractor cover the following detailed requirements:


Requirement Description
1 Extraction and Aggregation data from various systems of record (ERP, Customized applications,
excel sheets, etc.) used by STCs sectors to be part of this project. STC Project Team will perform
the collection of this data.
2 Data Cleansing
The selected contractor should have a proven data reconciliation and analysis tool with a
methodology that provides the ability to characterize data reconciliation and data quality issues in
complex real-world applications with the capability to efficiently design and implement accurate
rules for identifying erroneous information and automatically correcting it. As part of the data
reconciliation and analysis the contractor should:

- De-associate the non-moving, Inactive or Deleted Items from Active Inventory
Organizations.
- Purge non-transactional Items as part of data-cleansing.
- Remove duplicate items.
The data cleansing that will be used should have the following capabilities:
Multiple input and output adapters, allowing interaction with data from databases,
spreadsheets, fixed-field data, flat files and numerous other formats.
Transformation components, enabling conversions such as field-by-field text adaptation,
field merging and segmentation, and field-to-field projection
Sorting and classification components, for segregating records using sophisticated
matching and approximate matching rules and for organizing records within sets.
Scripting components, allowing definition of customized processing rules in any of six
difference languages.
3 Classification
- Define Categories and Category Sets to group items.
- Perform the analysis to justify and choose an appropriate new standard Item Master File
schema based on industry standard.
4 Attribute extraction and Enrichment
- Utilizing the new schema to determine the appropriate attributes to associate with each
category, determine the best method for sourcing attribute data and enrich current entries with
additional attributes.
- Set Item Description standards keeping in mind the analytical requirements of Business.
- Set specific Item Types like Asset, Services and Stores instead of standard types like
Inventory or Expense.
- Set attributes to link Asset and Spare Part item types in a mother & child relationship.
- Review the Unit of Measure of all Items under revised Coding Plan in order to avoid
transactional discrepancy.
- Define Item Templates to assign major attributes that are same for a group of items. Apply
template to create an Item.
- Define Cross-references to establish relationships between Items and entities such as old item
number or supplier item number.
- Associate proper and detailed Expense Account for the Item.
- Assign Items to serials And manufacturer serials.
- Define Item Revisions.
- Define Delete Constraints that are verified before you can delete an Item.
- Determine Centralized(Master Level) or De-centralized control(Organization Level) for an Item.


- Item Categories feature must be activated. The following attribute information should be
captured as part of the network equipment identification across multiple equipment manufacturers in
a consistent manner:
Identify equipment components to the part number and revision level
Capture interchange ability information (to show interchange ability between different
versions)
Identify equipment forward and backward compatibility between equipment revisions.
Define industry guideline for the marking and identification of equipment.
Have an established process in place with equipment Vendors to manage requests
and creation of equipment data.
Provide meaningful coded identifier and stored attribute information as a service.
Solution must track the following information:
o Manufacturer name
o Manufacturers part number
o Specific revision
o Description of device
o System (NE) name
o Technology
o Engineering characteristics
o Financial tracking of equipment assets
Solution must be capable of supporting the following attributes:
Identification
Stencilling
Ordering code
Physical
Height
Width
Depth
Weight
Electrical
Input/Output voltage
Input/Output amperage
Power consumption
Operational
Minimum and maximum operating temperature
Minimum and maximum humidity
Maximum heat dissipation
Port rate
Connector type
Port type
5 Automation :
1- Automated Item Catalogue.
2-Auto Item code generator to follow established standards
3-Automated data classification and cleansing functionalities at the source
4-Match new items to the existing cleaned baseline master file in real time
5-Force the use of standards (category codes, UNSPSC, descriptions, etc)
6-Automatic attribute enrichment
7-New requests to create items must be done through an automated application using a workflow
technology. Item creation actors must be maintained centrally for each requester.
Requester : log in and add items to be created
Finance : add correspondent expense account to those items
Finally Material department creates item on the system and close the request.
8 - A concurrent program to validate the entire process of Item creation and corresponding actions.
9- Investigate into the Business Control Tools required by Management.


10- Cross-Referencing old codes with new codes functionality.

1.3.3.2 Provision, implementation and Knowledge Transfer of Data
Management Tool
The contractor should provide a data management tool that will assist respected STC Departments in the
coding and categorization tasks (cataloguing). Since these Departments use Oracle eBusiness Suite
Applications, it is suggested to use Oracle Tool to simplify the integration activities. If the contractor has his
own Cataloguing Tool and would like to propose its usage by STC, he should do that in a separate option. In
this case, the contractor should include two options in his proposal, one for Oracle and another option for
his special tool. The provision of a non-Oracle EBS tool is an optional element of this project and should be
stated so in the financial proposal
This activity include the provision and implementation of the software in designated Departments and
knowledge transfer to STC employees on the correct usage of the tool so that STC respected Departments
continue using the software on their own with normal support mechanisms. Post implementation on-site
direct support from the contractor is also required for three months in order to make sure the transition is
performed smoothly.
The scope of implementation and knowledge transfer will cover all departments that define new items,
assets or services. These departments include Material, Fixed Assets, Purchasing, Network Engineering,
Network Operations, and Outside Plant. The contractor should account for the largest case with regard to
fulfilling implementation and knowledge transfer requirements for this activity. Not all employees of these
departments will receive knowledge transfer however. Only Procurement Officials in these departments
need to attend knowledge transfer sessions.
It is worthy to mention here that Asset definition in IMF is for financial account orientation during the financial
life of the Asset. This asset life financial cycle covers all procedural steps until asset delivery which is
normally called Asset Acquisition. Once received, the Asset is recorded in Fixed Assets System with a
different code. The contractor should also study this asset life cycle from the point of using MIC number (not
any other aspect) and advice on the best practices in this regard.
It is the responsibility of the contractor to activate and implement this integration to fulfil the requirements of
these departments. The integration purpose is to design and implement New Item Definition Process (along
with associated data) across respected Oracle Modules using Oracle Workflow mechanisms.
If it is decided to use another cataloguing tool, the contractor is responsible for its integration with other STC
applications following STC EAI Standards.

The proposed IMF data management tool should have the following characteristics:
1. A flexible, extensible and open data model to hold IMF data and all needed attributes (both
structured and unstructured).
2. A metadata management capability for items such as hierarchies and bill of materials.
3. A source system management capability to fully cross-reference business objects and to satisfy
seemingly conflicting data ownership requirements.
4. A data quality function that can find and eliminate duplicate data while insuring correct data attribute
survivorship.
5. A data quality interface to assist with preventing new errors from entering the system even when
data entry is outside the IMF application itself.
6. A continuing data cleansing function to keep the data up to date.
7. A comprehensive data security system to control and monitor data access, update rights, and
maintain change history.
8. A user interface to support casual users and data stewards.
9. A data migration management capability to insure consistency as data moves across the real time
enterprise.

10. A single platform to manage IMF data objects in order to prevent the proliferation of new silos of
information on top of the existing fragmentation problem.
11. An analytical foundation for directly analyzing IMF data.
12. A highly available and scalable platform for mission critical data access under heavy mixed
workloads.

1.3.4 Baseline Table of Items and Services based on the new code
The contractor is responsible for the preparation of a baseline table that contains main categories,
subcategories and items for Inventory Material, Assets and services categories. This table should be based
on entities normally used by telecommunication companies like STC. The contractor should map STC
current items assets and services to the new code structure. STC items base table should be based on
similar catalogues in telecom industry or other similar organizations.

In effect, STC will have a base table that contains currently used items and any item to be used in the future
differentiated by a status attribute. Whenever a new item is suggested by respected departments, it should
be selected from the base table and entered into STC catalogue as suggested in the diagram below. The
diagram suggests a high-level flow, but the contractor should advise on the best practice in this regard. If the
cataloguing tool allows for more than one catalogue, both Base Table and Catalogued Items Table would be
accommodated by the same tool. This suggested process should alleviate the addition of items in a non-
standard format and content. A process needs to be defined to handle exceptional cases. Any source of
codes should be able to be integrated to the STC EAI Bus through web services APIs.
If it is decided to have a separate code for Inventory Items, Assets or Services, then each entity should have
its own base table of prospect main categories, subcategories and items.

Define New
Item Process
STC Items
Base Table
STC
Catalog
Approve New
Item Process
STC
IMF

1.3.5 Recoding current Items (Inventory, Assets and Services) using the new
code
After the design of the new code(s) and the preparation of categories table, the contractor should convert
existing codes to the new codes. As a preparation step, it would be necessary to first review existing codes
in the Item Master File with respected STC Departments to discard unused codes and record comments on
the usage of the rest of the codes.

The contractor should study current items and perform a data enrichment and standardisation task. All items
should be catalogued based on the new scheme after duplicate items are removed.
In technical terms, this is a data conversion activity of STC IMF from the old format to the new format that
includes enriched data as well. The Contractor will be responsible for activation, preparation and making the

necessary fields in Item Definition screens in Oracle Inventory ready for use by Material Dept. This includes
specifically the Category fields since they are the most affected by this operation.
The result of this activity should be a new Master File that contains all currently used entities with the new
code structure as a unique identifier and an enhanced content. If it is decided to have a separate code for
each entity, each entity should have its own Master File or a portion of it containing old instances of the
entity with the new code.
The contractor should coordinate with Financial Systems Support (FSS) and Enterprise Systems (ES)
Departments as well as User Departments in performing this activity to secure both business and technical
implementation requirements
1.3.6 Cross-Referencing Old to New Item Codes
The vendor should provide or activate a cross-reference function to end-users of respected departments
from within their Oracle Application Role to handle search and find as well as map and match between the
old and the new codes. Users in respected departments should be given a knowledge transfer sessions on
the usage of this function. If this capability is part of the new cataloguing tool or the functionality can be
provided by customizing the Inventory system (cross referencing), it should be covered in implementation
and knowledge transfer activities.
1.3.7 Historical Transactions Data Conversion
All item codes (MIC number) in previous transactions in all related Oracle Applications i.e. Inventory, Fixed
Assets and Purchasing (including other applications especially financials) should be converted to the new
code. The contractor should make sure that all related STC Departments continue their work without any
disruption with the ability to deal with historical transactions as normal, but using the new code.

This activity should be performed with full cooperation and guidance of ES and FSS Departments in order to
facilitate transition and go-live requirements. The following table shows the number of transactions As of
2009

Production instance Volume

Number of records
Inventory
Item master All organizations = 1062472 Master org =63639
Transaction history (All
transactions types)
All organizations = 1993637

Material distributions All organizations = 2784853
Inv Organization 21
Purchasing
Purchase requisitions
Purchase Requisitions : 21686
Purchase Requisitions Lines: 288845
Purchase orders
Purchase Orders : 32690
Purchase Releases : 115606

Purchase Orders Lines : 562146
Purchase Orders Shipments : 670850
AP Invoices Lines = 302459payments = 329156
FA Assets 193928
Users 2262
Note : Cancelled inactivated lines included

The conversion can be performed using Oracle Inventory options to modify the item code characteristics i.e.
Updated attribute. The contractor is responsible to investigate this capability and design a set of rigorous
steps to perform the update of the code. Once done properly in the IMF, all other modules within EBS will
refer to the correct item without modifying the actual transactions data using the internal referencing
mechanisms provided by EBS. The contractor should test this process thoroughly in the test environment
and perform it in the production environment with respected IT departments and staff during go-live phase.

The scope of the data conversion task covers only Oracle EBS modules.

A different strategy will be followed for other applications. Other non EBS applications will be identified by
STC project team. The new code will be communicated to IT departments responsible for supporting those
applications and they will be requested to cater for the change. The selected contractor for this project will
have a support role and assist those departments in performing the change by supplying them with the
required data in the format they require in addition to consulting them to the right way of achieving this
change. Currently, the number of non EBS applications, that use MIC Number and require changing to the
new code, is not known and the number might not be high. This possible activity is listed here to inform the
contractor of the possibility that this can happen for his planning purposes. It is expected that this kind of
support and assistance can be provided by the selected contractor technical staff that will be provided for
this project.
1.3.8 Relation with Other Projects
This operation should be performed in full coordination with other running STC related Projects. Other
Projects that implement new Oracle Modules or enhance Current Oracle Modules depend on the results of
this operation. It is expected to perform this Operation in conjunction with these projects so that they would
be implemented utilizing the new coding scheme and not modified in a later stage. The selected Contractor
should participate or at least consult with related Project Management Offices regarding this coordination.

1.3.9 Provision of On-Site PM and Consultants
The selected Contractor should provide a qualified Project Manager to be responsible for all stages of the
project and manage the rest of the Contractor staff. He should coordinate all project activities with respected
departments under the supervision of Material Management Department. One permanent (English/Arabic
Language Speaking) Functional Consultant is also required to be available during the project lifetime with
periods of heavy end-user related involvement and periods of low actions. One or more Technical
Consultants should be part of the Contractor staff and be available when needed to perform related technical
tasks and coordinate with respected IT departments.

Other project staff availability arrangements can be negotiated with vendors especially for technical tasks
that do not require on-site participation.

1.3.10 Provision of an Independent Consultant
The selected Contractor should include in his financial proposal a projected cost for providing a qualified
independent consultant specializing in Supply Chain Systems (Inventory System) using Oracle eBusiness
Suite to be selected by STC. The independent consultant should participate in the project under the
supervision of Material Department during the project to review major deliverables and advice on the project
course of action with regard to Business and Technology alignment to requirements. It is planned to have
the independent consultant available in three different time periods each runs for one week.


1.3.11 IMF-EP Timeframe
Many other projects and Tasks in STC depend on the completion of this project. Accordingly, STC requires
that all the activities of this project be completed in 12 months from its starting date. Vendors should
calculate the project tasks costs based on this time frame. If the selected contractor has any reservation
based on his previous experience with similar projects, he should state that providing a suggested time
frame.
1.3.12 Development of STC Cataloguing Procedures
The contractor is required to complement the implementation of the Cataloguing Tool with a well-designed
set of processes and procedures that govern the use of the tool. These procedures should be based on best
practices in telecom or similar industries. It is the responsibility of the contractor to study the current
procedures followed to define new items, assets and services in STC and suggest the best practices to be
used in conjunction with the new cataloguing tool.

Cataloguing procedures should identify process flows and steps in addition to defining the roles of the
persons performing these procedures with their qualifications.

The procedures should be directly mapped to the tool with correlation between the tool components and the
procedural steps.

1.4 Anticipated Project Time Frame

This project will start on a date mutually agreed between the successful vendor(s) and Saudi Telecom and
will be completed within 15 months. The target durations for each part of the project are summarised in the
following table:

Project Time Frame Table
Task Duration
RFP, Evaluation, Proof-of-Concept, Vendor
Selection & Contract Finalization
1 month
Implementation Planning 1 month
Design, Development & Functional Testing 9 months
Pilot & Acceptance Testing 1 month
Production Roll-out 1 month
Post Implmentation Support 3 months
1.5 Vendor Response

The vendor(s)s Must response to the Following Project Tasks:
o Designing new codes for Material, Assets and Services
o Provision, implementation and Knowledge Transfer of Data Management Tool

The vendor(s) shall submit a Technical and a Commercial Proposal with complete technical information and
pricing details of their products & services, which will meet or exceed STCs requirements & specifications
as described in this document.

The vendor shall also propose a clear implementation strategy and methodology and provide it's corporate
profile & scope of capability information.

Structure and format of the proposal has to strictly follow the requirements and instructions as set out in
section 3 Vendor Proposal Requirements

In order to expedite the evaluation process and fairly evaluate all proposals it is mandatory that the general
Terms & Conditions are being accepted.

Failure to agree to or comply to any of these terms and conditions and/or not following the required
mandatory outline and/or not providing required information as softcopy and/or proposing payments
not linked to deliverables will result in a bidder's proposal being disqualified from the evaluation.

1.6 Questions relating to the RFP
Vendors who have questions regarding this Request for Proposal are requested to direct them in writing to:

Saudi Telecommunications Company (STC)
Purchasing & Contracts Department
P.O. Box 87912
Head Quarters Building
STC - King Abdulaziz Compound
Mursalat
Riyadh 11652
Kingdom of Saudi Arabia

1.7 Submission of Proposals
All proposals should be submitted to the following location on or before: Wednesday 21/07/2010

Saudi Telecommunications Company (STC)
Purchasing & Contracts Department
P.O. Box 87912
Head Quarters Building
STC - King Abdulaziz Compound
Mursalat
Riyadh 11652
Kingdom of Saudi Arabia

1.8 Selection Process & Evaluation Criteria
Saudi Telecom selects services and solutions based on the best value and affordability in meeting or
exceeding the companys requirements. The Technical and Commercial Proposals may be evaluated
separately prior to the final decision.

For the technical evaluation STC uses a weighted scoring approach based on requirements compliance and
company capability to determine the value of a proposal. The pure technical value is normally weighted at
60%, the company capability at 40% but this may differ according to specific project requirements.

The proposal will also be qualified according to its responsiveness according to following criteria:

Shows understanding of the problem/s
Adequately addresses stated objectives (e.g. makes recommendations)
Addresses standards, prototypes and other key issues.
Exhibits creative thinking with proper clarity
How complete the response is

How well the proposal conforms to the required response outline and format
1.8.1 Vendor Presentation
A vendor may be asked by STC to make a presentation and/or arrange a meeting to clarify any portion of his
response and/or to further explain how STC's requirements will be met.

1.8.2 Vendors Conference
If the amount of vendor questions asked is substantial and/or may indicate that important parts of the RFP
have not been understood properly and/or can and are interpreted differently, STC may call for a vendor
conference.

The purpose of the vendor conference is to provide STC's clarification regarding information given in the
RFP.

All questions either written and received prior to the vendor conference, or received at the conference or
asked at the conference will be read aloud and will receive oral responses.

The questions and answers will be compiled into one document. This document will be distributed by STC to
each vendor.

No individual responses to specific vendors will be given prior to the vendor conference.

2 STC REQUIREMENTS
2.1 General Requirements
State-of-the-art Technology
Adherence to Industry Standards
Highly scalable and modular
Application Integration through STCs EAI Platform
Bilingual Arabic/English capability on all applicable user interfaces
All software whether off the shelf, customized or developed should be provided with perpetual,
irrevocable, non-exclusive licenses.
Defect warranty for software should be provided for one year.
The vendor should monitor the system capacity according to the agreed upon SLA between the
vendor and STC.
Saudi Telecom should be notified for any incident regarding system capacity, and system
performance through specific contact name from Saudi telecom.
The vendor must provide registration process for backup activities, applying patches or fixes on the
systems
Maintenance or subscription for software should include version upgrades.
All hardware proposed should have a minimum of one year on-site warranty including parts and
labour.
Maintenance for hardware should include on-site support with guaranteed call response times.

Vendor proposed solutions must comply with STC's current architecture, integration and
Infrastructure requirements. (These are detailed in the following sections)

2.1.1 Server and Storage Requirements
If the proposed solution comprises of servers, which will be placed in the STC's Data Centre then the
proposed solution(s) should comply with STCs architecture standards listed in the table below. If the
vendor's proposed solution requires Processing Resources (Servers), the vendor should size the
components (CPU, I/O for Data & Network, Memory, and Clustering) that exist in one of the STCs
consolidated environment (CE). The vendor should keep into the account the STCs High Availability (HA)
requirements.

Architectural Element Standard
Server Hardware & OS 1. HP Consolidated Environment (HP-CE)
Existing consolidated environment running HP-UX 11i and consisting
of the following hardware:
HP Superdome 9000 partitions containing PA8800 processors,
memory, I/O boards for data and network
2. IBM Consolidated Environment (IBM-CE)
Existing consolidated environment running AIX 5L and consisting of
the following hardware:
IBM eServer 570 with POWER5 processors, memory, I/O boards
for data and network
3. Sun Consolidated Environment (Sun-CE)

Existing consolidated environment running Solaris 8 and above and
consisting of the following hardware:
Sun fire 25K with Sparc4 processors, memory, I/O boards for data
and network
4. Non-Consolidated Intel Environment: Windows-E/Linux-E
Windows-E: Windows operating systems on leading Intel platforms
Linux-E: Redhat Linux (RHEL 2.1 and RHEL 3) as well as SuSE
Linux (SLES 8 and SLES 9) servers running on leading Intel platforms
DBMS Oracle, DB2
Client Hardware & OS HP, SUN, IBM workstation, leading PC Server manufacturers with
latest version of HP-UX, Solaris, AIX, Windows and Linux

STC operates a Fibre Channel Storage Area Network (SAN), which is used to provide connectivity between
the servers and the storage in Riyadh Data Centre.
If the proposed solution comprises of servers, which will be placed in the STC's Data Centre then all
application and data will reside on external disk storage and/or other near on-line storage (as appropriate).
Internal Disk storage shall only be proposed to accommodate the operating system.
(See STC-Infrastructure-Requirements-for-IT Projects-v2 that details the server and storage
requirements.)
2.1.2 Data Networking Requirements
If within the solution significant data networking equipment is deployed then the proposed solution has to
show schematic and logical diagrams about the network connectivity along with clear details of the proposed
network equipments. Bill of Quantity, type and model have to be presented. The vendor has to make sure
that the proposed network equipments comply with the standard list of network equipments and that all
requirements documented in the following document are met. (see: STC-Datanetwork-Requirements-For-
IT-projects-v1.2).
2.1.3 Data centre Requirements
This is applicable to all the new projects especially for vendors who are implementing for the first time in the
Data Centre. It is also beneficial for vendors who have worked in this environment before but need to refresh
their information on STC Data Centre standards.

All procedures and policies defined in the following document must be met. See: SYSTEM HANDOVER
POLICY
STC Data Centre (System Handover Policy.doc))
2.1.4 Security Requirements
The proposal has to take into account the principles and procedures described in the separate document:
STC-General-Security-requirements-for-IT-Projects-v4 as well as ISO International Standards.
(see: International Standard ISO/IEC 17799. First edition. 01/12/2000)

The vendor should provide monitoring process for his staff according to the Information Confidentiality
agreement.
The vendor must provide registration process for any activity that could affect the information security.

2.1.5 Integration Requirements
Saudi Telecom is expecting to be constantly exposed to major changes in its business domain and depends
on its flexibility to adapt to these changes on the business as well as on the technical side of its operations.

The contractor should provide the necessary APIs allowing the proposed solution to be integrated with other
STC systems such as the Common Language Clone


As one approach of improving it's capabilities in this regard Saudi Telecom has established a common Data
and Application Integration infrastructure for its IT environment to simplify and speed up all aspects of
integration of data and applications as well as to gain flexibility when implementing new systems and
services, and/or when changing related business processes.

This requires that all new IT related projects support Saudi Telecom's integration approach and policies
consistently and comprehensively.

To facilitate this, Saudi Telecom's Data and Application Integration group has identified requirements,
policies and procedures that must be satisfied by all IT related projects conducted. Saudi Telecom's
departments and teams responsible for the herein described project need these being met and request the
relevant commitment being documented by the respective contractors within their proposals.

To allow potential contractors to properly declare commitment and compliance, and to plan and implement
accordingly, these normative requirements, policies and procedures are published as part of Saudi
Telecom's project specifications i.e. this RFP through the following document:
STC-General-Integration-Requirements-For-IT-Projects-v5.5 (Also Excel sheet)

2.1.6 Mediation Requirements

STC's current mediation environment consists of mediation systems from multiple vendors and STC is
moving strategically to a unified mediation architecture. Network elements and/or systems must support an
open environment to support any mediation device with open standard interface protocols. The vendor shall
comply with all STC's mediation policies and procedures.
(see: STC-Mediation-Requirements-For-IT-Projects-v2.5)

2.1.7 Data and Application Architecture Requirements

STCs requires its information technology infrastructure to support its business objectives and also allow
flexibility in adapting to dynamic changes within this domain. To this end, we have defined a list of Data and
Architecture requirements to:
Better support future technology decisions
Enable the sharing of information resources and computing environments all over STC
Reduce complexity
Cut costs and
Support rapid solution development/deployment
This also includes the requirements regarding the Enterprise Data Warehouse (EDW) utilized within STC.

The vendor has to comply to ALL these architectural principles, requirements and guidelines. These are
included in the: STC-Architecture-Requirements-For-IT-Projects-v1.6

STC also requires that Data Models for the solution be provided in a softcopy format. (see section 2.5.1).

2.2 IT Functional Requirements

IT Functional Requirements Table
CL= Compliance Level (for an explanation see I-4.3 Requirements )
Id# Item STC
Requireme
nt
Vendor Response
CL Reference/Short description
1 Application Software (Server
Side)

FR-1.1 Data management Tool Yes
2 Application Software (Client
side) - End-User Interface
Requirements

2.1 Client Interface
FR-
2.1.1
Thick client application
(client/server)

Yes if
provided out
of the box
by the
Cataloguing
System.

FR-
2.1.2
Web browser (thin client)
interface

Yes
FR-
2.1.3
A Graphical User Interface with
access to functions with
minimum clicks and key strokes
Yes
FR-
2.1.4
A Command line interface

optional
FR-
2.1.2.1
Command line interface is
scriptable

optional
2.2 Arabization
2.2.1 Data
FR-
2.2.1.1
Unicode Code (ISO 10646) in
UTF-8 encoding shall be used.
Yes
FR-
2.2.1.2
If the application does not
support Unicode, it shall be able
to convert data from its local
code page/character set to
Unicode and vice versa.
Yes
FR-
2.2.1.3
The application shall not contain
hard-coded character
constants, numeric constants,
screen positions, filenames, or
pathnames that presume a
particular language.
Yes

Id# Item STC
Requireme
nt
Vendor Response
FR-
2.2.1.4
The application shall use all
international functionality (dates
and date formats, sorting,
character typing, etc.) offered
by the operating system
(instead of realizing this in a
proprietary way in its code).
Yes
FR-
2.2.1.5
The application shall not
concatenate strings to form
messages/sentences.
Yes
FR-
2.2.1.6
Localized and localizable items
shall be stored in separate
resource files.
Yes
2.2.2 GUI
FR-
2.2.2.1
Unicode Code (ISO 10646) in
UTF-8 encoding shall be used.
Yes
FR-
2.2.2.2
If the application does not
support Unicode, it shall be able
to convert GUI texts from its
local code page/character set to
Unicode and vice versa.
Yes
FR-
2.2.2.3
Default alignment of Arabic text
for all windows and widgets
(menus, textboxes, forms, etc.)
shall be right to left.
Yes
FR-
2.2.2.4
Control symbols for window or if
any for other widget should be
at the top-left corner of the
window or widget.
Yes
FR-
2.2.2.5
Drop-down menus and lists
should have the selection arrow
at the left side. Items of lists and
drop-down menus should be
right justified.
Yes
FR-
2.2.2.6
Vertical scroll bars shall be at
the left of the window or if any
at the left of the widget.
Yes
FR-
2.2.2.7
Horizontal scroll bars shall start
from right and move to left.
Yes
FR-
2.2.2.8
Progress bars shall fill with time
from right to left.
Yes
FR-
2.2.2.9
The source of the light for
shadow-use in 3-day interface
shall be assumed at the top-
right of the screen.
Yes
FR-
2.2.2.1
0
Consistent Arabic-English user
interface terminology should be
used.
Yes

Id# Item STC
Requireme
nt
Vendor Response
3 Integration
FR-3.1 Application Integration must
adhere to the STC Integration
policies and standards. See
2.1.5
Yes
FR-3.2 Specific dependencies with
other applications and minimal
set of interfaces required
Activate the
Integration
of Oracle
with other
Oracle
Financial
and Supply
Chain
Modules.

4 Mediation
FR-4.x No mediation is required. No.
5 Security
FR-5.1 Access control integrated with
OS.
optional
FR-5.2 Ability to assign users to
groups, who have different
access privileges to subsets of
application data (i.e. power- vs.
end users)

Yes
FR -5.3 Produce daily/weekly/monthly
reports on access control logs.
Yes.

6 Item Master File

FR-6.1 Designing new coding scheme.
FR-6.2 Item data collection from
available sources.

FR-6.3 Items data cleansing
FR-6.4 Items data standardization and
enrichment

FR-6.5 Items classification and
cataloguing

FR-6.6 Items and transactions data
conversion

FR-6.7 Design and implement new
items cataloguing procedures

FR-6.8 Provision of classifications and
items base table

Detailed IT Functional Requirements Description

FR-1.1
The contractor should provide an automated tool that will assist respected STC Departments in the
coding and categorization tasks (cataloguing). Since STC Departments use Oracle eBusiness Suite
Applications, it is suggested to use Oracle Tool or data manegemtn tool to simplify the integration
activities.
FR-3.2
Oracle Tool or data manegemtn tool should be integrated with Oracle financial and supply chain
systems. The contractor should also support IT departments in modifying other systems that uses
inventory items data (i.e. are integrated with Inventory System) to conform to the new item code
structure in the Item Master File.
2.3 Performance & Workload Requirements
The proposed solution has to at least meet or exceed the performance- and workload requirements
characterised by the factors listed in the table below:

Performance & Workload Requirements Table
Vendor Response
Id# Factor STC
Requireme
nt
CL Reference/Explanation
PW-1 Data management Tool number
of concurrent users
100
PW-2 Number of new items to store 5000 /
month

PW-3 Response times for typical
system operations or volumes
Standard

2.4 Reliability, Availability & Serviceability Requirements
Reliability, Availability & Serviceability Requirements Table
Vendor Response
Id# Item STC
Requireme
nt
CL Reference Explanation
RAS-1 allowable downtime during
business hours(min/day)
Standard
RAS-2 allowable downtime off
business hours (min/day)
Standard
RAS-3 Time for a full system backup Standard
RAS-4 Time for a full system restore
(h)
Standard
RAS-5 Remote Manageability Standard
RAS-6 Remote Boot Capability Standard
RAS-7 Administrator Browser Interface Standard
RAS-8 Administrator "Windows"
Interface
Standard

Reliability, Availability & Serviceability Requirements Table
Vendor Response
Id# Item STC
Requireme
nt
CL Reference Explanation
RAS-9 Administrator Command Line
Interface
Standard
RAS-xx

2.5 Project Deliverables
The deliverables of this project are summarized in the table below:

Deliverables Table
Component Remarks
1. Hardware
1.1 Server Hardware (including operating system and all required
utilities)
N/A
Perpetual Licenses for all software
required. See point 1.3.9 above.
1.2 Client Hardware N/A
1.4 Hardware Maintenance & Support N/A

2 Software
2.1 Oracle DBMS software N/A
Perpetual License required
2.2 Application software (server-side)
- Data Manegement tool
- RTU
- Development/ Customization to meet STC requirements
Yes. Perpetual License required
2.3 Client GUI Application (Arabized):
- Development/ Customization to meet STC requirements
100 users.
Concurrent User Licenses
2.4 Integration specific software (e.g. adapter, developments) Yes if necessary.
2.5 Software Maintenance & Support Included in the licence.
3. Services For tasks details refer to points
1.3.4-1.3.8 and 1.3.11-1.3.14
3.1 Project management & consultancy services All tasks to be carried out on-site at
STC
3.2 Installation, Customisation & Integration Services All tasks to be carried out on-site at
STC
3.3 Implementation Services All tasks to be carried out on-site at
STC
3.3 Transfer of Knowledge and Documentation Yes.
3.4 Project auditing, Quality control & assurance
three different time periods each runs for one week
Should be a non-vendor affiliated,
independent consultancy. See
point 1.3.14 above
3.5 Post-implementation on-site support for a period of 3 months
- Operation and Administration
- Skills Development & Technology Transfer
Yes. Performed by an Arabic
speaking functional consultant and
a technical consultant.


Beside the necessary hardware, software and services the vendor shall provide the following.
2.5.1 Data Model

As part of the Customer Specification Document (CSD) the vendor shall provide various types of data
models and meta data about the delivered solution. These data models will be provided in softcopy format
using industry standard and recognized tools (e.g. Erwin, power designer etc). This includes, but not limited
to:

Detailed Entity Relationship Diagram (ERD) of the solution along with a high-level one.
The vendor shall provide the ERD entity relationship diagram, as will as other related models /
diagrams, for the data part of the solution whenever it is applicable.
The vendor should commit to deliver the customized data and application models after applying the
customizations required by STC

Metadata :
Business Metadata - refers to definitions/descriptions of entities/objects, their attributes and
relationships from the end user point of view formulated in business language.
o It should be possible for one entity to have multiple definitions, depending upon the
business context. For example, a service may be defined differently by the network
operations department and by the marketing department.
o A Create, Read, Update, Delete (CRUD) Matrix showing the business units creating,
reading, updating and deleting entities and attributes.
o The CRUD matrix should be detailed up to attributes level for each entity.
Technical meta data - describes each entity and attribute in sufficient detail for implementation
in the form of tables and fields (i.e. RDBMS) and/or files/reports and fields (i.e billing details file).
Information such as table-name, filename, report-name, field-name, data type, -length, codes,
allowable values, validity of null values and so on are described here.

Modules will be creating, reading, updating and deleting entities and attributes. (CRUD Matrix)
This must reflect any customizations that have been done to the system.
2.5.2 Application Model

Where applicable, as part of the Customer Specification Document (CSD), the vendor shall provide
application model(s) detailing how the solution has been architected. At least, the following models should
be provided:
Component-based architectural view that shows the component the enterprise has and the
relationship among them. If necessary, a detailed architectural model of each component may be
provided.
Functional architectural view that shows the functional boundaries of the solution.
Integration model that defines the interfaces required between the delivered application and those
that interface with it.

2.5.3 Contingency Plan
The vendor shall provide a contingency plan by using the document template "Contingency Plan, Version
0.1 22/05/02". This is included in the Data Centre Requirements document.

2.5.4 Knowledge Transfer
Transfer of Knowledge is defined as: information, knowledge, and procedures that are needed to assume
the day-to-day operation and maintenance as well as future enhancements of the application/system.

The transfer of knowledge shall follow a process that includes:
participation of STC personnel throughout the project,
documentation,
walk-through(s).
Knowledge Transfer Sessions which should include the following topics:
o Specific code set training
o New process training
o Overview of product catalogs and how best to leverage these within the corporation
o Data quality issues and solutions

The successful vendor shall provide all technical, operational and administrative knowledge transfer required
for STC personnel to successfully conduct activities related to the implemented solution.
The vendors proposal should clearly state the knowledge transfer that will be provided and how many staff
they recommend to provide knowledge transfer.
Knowledge transfer shall be delivered by supplier-approved and qualified individuals.
2.5.5 Documentation
STC recognizes that the availability of comprehensive, well-organized and easy to use documentation is
critical to both the short and long-term success of any project.

Therefore documentation developed by the vendor shall be supplied both in printed and electronic format to
allow for easier modification in the future:

Documents shall be submitted at least as 3 paper copies and as a softcopy. Softcopies shall be
provided in HTML-, Microsoft Office- or PDF format.
Documents shall be provided on machine-readable media (preferably CD-ROM) three times.
Documents nay be provided by e--mail, if specifically agreed to by STC
Licensing terms of the documentation must allow storage in and use through STCs document
management system and its intranet.
Licensing terms must allow STC to produce specifically customized documentation for STC's own
internal use.

Out-of-the-box Web browser access is considered a quality increase for the proposed solution.

Updates and Maintenance
STC anticipates that modifications and updates to the project documentation, both electronic and paper, will
be required. Documentation updates may include user manuals, system documentation (logical and
physical) and system operations.

Whenever changes or updates occur a correction sheet shall specify the document number and title, date of
the original issue, the date of the effective change, and change bars designating the changes.

When major changes to a document are made, as determined by the vendor in its reasonable discretion, a
complete revision of the document shall be issued and delivered in accordance with the original instructions
for this documentation item. Revisions must be numbered and dated.

2.6 Documentation- and STC Software Ownership
STC shall have all ownership of and title to all software developed, modified or adapted for STC in the
course of this project, and all associated documentation of the complete system, including any and all plans,
drawings and vendor's special utilities. STC shall have the sole right to produce, publish, or otherwise use,
such software, modifications and documentation within STC provided it is only for its own internal purposes.

Upon completion of the project the vendor shall turn over all STC-provided documents as well as all
material, reports, product documentation and work in progress documentation relating to this project.
2.7 Project specific Terms & Conditions
See points 1.3.12 - 1.3.14 above.

3 VENDOR PROPOSAL REQUIREMENTS
Proposals are required to strictly follow the description in this section.
Proposals deviating from the required format and structure will be disregarded for further evaluation.

Vendors are encouraged to provide any additional and relevant information in the appropriate section in the
proposal (see the mandatory proposal outline).

Proposals shall be submitted as 3 hard copies as well as a softcopy in Microsoft Word format. All tables in
the proposal shall be also provided as softcopies in Microsoft Excel format.

If the proposal is submitted in multiple files the splitting must be done following the mandatory proposal
outline listed below. The filenames must conform to the headings of the mandatory proposal outline
including the numbering (i.e "I-4 Solution Overview.doc")

3.1.1 Mandatory Proposal Outline

Table of Content
SECTION I TECHNICAL PROPOSAL
I-1 Cover Letter
I-2 Statement of Conformance
I-3 Table of Content
I-4 Solution Overview
I-4.1 Overview
I-4.2 Architecture Diagrams
I-4.3 Requirements Compliance
I-4.4 Capacity Table and Growth Potential
I-4.5 Project Implementation Plan
I-5 Detailed Solution Description
I-6 Sizing Approach
I-7 Hardware Specifications & Features
I-8 Software Specifications & Features
I-9 Operation & Data Security
I-10 Project Implementation Approach
I-10.1 Timeline and Major Milestones
I-10.2 Project Work Plan
I-10.3 Project Management
I-11 Implementation Requirements
I-11.1 Human Resources
I-11.2 Office Equipment and Space
I-11.3 Connectivity and Communications
I-11.4 Knowledge Transfer
I-12 Further Technical Information
I-13 Vendor Profile & Scope of Capability Information
I-14 Reference Projects and -Customers
I-14.1 Company Profile
I-14.2 Companys Presence in Saudi Arabia and in the Middle-East Region
I-14.3 Company Partnerships and Alliances
I-14.4 Company Scope of Capability
I-15 Softcopies Technical Proposal
SECTION II COMMERCIAL PROPOSAL
II-1 Cover Letter
II-2 Table of Content
II-3 Pricing Tables
II-4 Warranty Entitlements, Terms & Conditions
II-5 Further Commercial Information
II-6 Softcopies Commercial Proposal

3.1.2 Detailed Instructions and Explanations

Vendor Response Cover Page goes here.

Section I Technical Proposal
THIS SECTION SHOULD NOT CONTAIN ANY FINANCIAL INFORMATION.
I-1 Cover Letter

I-2 Statement of Conformance
(to the terms and conditions of this RFP.)
PLEASE DO NOTE THAT THE ABSENCE OF THIS STATEMENT WILL MAY RESULT IN
DISQUALIFICATION OF THE PROPOSAL.

I-3 Table of Content

I-4 Solution Overview
If alternatives are proposed, provide a Solution Overview for each alternative. Add the name or number of
the alternative after all I-4 headings.

I-4.1 Overview
Short description of the proposed solution/s containing a technical description only and no pricing
information.

I-4.2 Architecture Diagrams
Hardware-, software architecture, interconnect/networking diagram.

I-4.3 Requirements Compliance
The vendor has to describe compliance to all requirements mentioned in 2.1 General Requirements

The vendor has to fill all requirements tables (see Section 2 STC Requirements) and include them here.
The answer in the column "CL" (Compliance Level) in all requirements tables must be one of the codes from
the Compliance Level Table below.

The column "Reference/Explanation" has to start with a reference (listing the section number and page
number) in Section I-5 Detailed Solution Description where a detailed description can be found followed by a
short explanation. Text entered in these cells should not exceed 3 lines.

If either the abbreviation or the reference is missing, this will be considered non-responsive and rated as
Not Compliant (NC). Blank cells in the Vendor Response column will also be rated as NC.


Compliance Level Table
Code Description
FC Fully compliant. This is out of the box functionality. The only customisation required may be using
some configuration/administration module/s of the application.
C1 Requires only changing configuration (text) files.
C2 Requires writing a script or program, which accesses the application via an API, object orientation
or other interface (i.e. XML). No source code of the application is changed. These customisations
will work with a new distribution of the application.
Work Effort <= 1 man week.
C3 same as above but Work Effort <= 1 man month
C4 same as above but Work Effort > 1 man month
C5 Requires changing the source code of the application and a new built of one or more modules.
Work Effort <= 1 man month
C6 same as above. Work Effort > 1 man month
NC Not compliant. Functionality is not provided/available.

Below is a sample part of a requirements table filled.
CL= Compliance Level
Id# Item STC
Requirement
Vendor Response
... ... ... ... ...
3 Application Software (Server
Side)

FR-
3.7
Must accept Postscript formatted
bill print files as input
Yes FC see I-6, Section 2-3.
The software will accept postscript
input, which can then be reprinted to a
postscript printer.
FR-
3.8
Must accept PCL formatted bill
print files as input
Yes C2 see I-6, Section 2-5.
This requires use of the XYZ feature.
... ... ... ... ...

The vendor should explain if and how customised modules will be integrated in future distributions.
I-4.4 Capacity Table and Growth Potential of the Cataloguing Tool

Capacity Table
Id# Factor Installed
Capacity
Maximum in the box
Capacity
(no new boxes)
(no additional floor
space)
Maximum tested
Capacity
(verified by
benchmark or
real world installation)
C-1 Data Manegement tool
concurrent users

C-2 Data Manegement tool
Number of new items to store

C-3 Response times for typical
system operations or volumes

I-4.5 Project Implementation Plan
in Microsoft Project format, less than one page, including all proposed Preliminary Acceptance Tests
(PATs).

I-5 Detailed Solution Description
Detailed description of the proposed hardware, software, connectivity, services and implementation.

I-6 Sizing Approach
Detailed description of the approach as well as all methods, procedures and variables used for the
sizing of the proposed hardware- and software platform/s.

All information, data and tools used must be provided, to allow STC to redo the sizing and arrive at
the same result as the vendor.

This information should preferably be provided as MS-Excel table/s.

I-7 Hardware Specifications & Features

I-8 Software Specifications & Features

I-9 Operation & Data Security
see the separate Document: "STC, General Security Requirements, (ver 1.0)"

I-10 Project Implementation Approach

I-10.1 Timeline and Major Milestones

I-10.2 Project Work Plan
The vendors proposal shall include a high-level work plan.
The successful vendor shall be required to develop a detailed project work plan with STC, which
includes the activities that will be undertaken to achieve the project objectives and deliverables within
the required time scales. The work plan shall show clearly, who will undertake the activity and the
scheduled dates to start and complete each activity.

Description of all the major project phases and the activities in the form of an Input Phase Output
(IPO) table.
In the left column list the inputs that are prerequisites and/or required for this phase. Number Inputs,
Phases/Activities and Outputs (see below).
Underline inputs, which are required from - or must be provided by STC.
In the middle column list the phase and its main activities. After the phase enter its duration enclosed
in round brackets.
In the right column list the outputs/deliverables produced by the execution of this phase.
Underline outputs, which must be maintained/updated by STC.
Outputs may be input to other phases. Outputs not being inputs to other phases are final deliverables.

(Text in the table below serves as example only, replace by your own)

Input Phase Output Table
Inputs Phase/Activities Outputs/Deliverables
O1.1
I2.1 PIA physical
architecture document
I2.2 STCs business
process descriptions,
applications environment
I.2.3

2. document current IT
infrastructure (4 weeks)

A2.1 identify and describe
business processes
A2.2 identify and describe
applications
A2.3

O2.1 Documentation of current
IT infrastructure (business
processes, applications,
platforms)
O2.2

Outputs to be maintained by STC

Description of each output that has to be maintained/updated by STC. This should not be more than half a
page per output.

State in which time interval these outputs should be updated.

I-10.3 Project Management
The vendors proposal shall include an organization structure, proposed team members and a
description of their roles within the project. The proposed team shall include a Project Manager and
must name the persons who are committed to the project.

STC requires vendors to provide CVs for all their proposed team members. The CVs provided must
indicate clearly the expertise and experience each team member possesses, which is relevant to the
scope of work.

The vendor must provide a detailed breakdown of manpower resources that are to be committed to
the project and indicate how they may be used (for example management, technical or technology).
Any subsequent changes to the project team members must be agreed with STC.

All work is to be undertaken within the Kingdom and at STC premises unless otherwise agreed with
STC.
The successful vendor shall provide regular progress reports and participate in management reviews
as required by the Project Sponsor. The project shall be managed in accordance with the approved
project work plan and any deviations subject STC change control procedures.

I-11 Implementation Requirements
I-11.1 Human Resources

Human Resources Requirements Table
Vendor team
(named resources in FTE)
STC project team
(by function in FTE)
STC top management, middle
management and subject
matter experts availability


CVs of all vendor project personal have to be included
I-11.2 Office Equipment and Space
list the amount of office equipment and space needed for the project
list explicitly if office space and/or equipment is needed on STC premises like in the data centre
I-11.3 Connectivity and Communications
list all the systems/equipment project personnel needs to access
specify any communications equipment/facilities like mobile phones, telephone lines, leased lines, etc.
I-11.4 Knowledge Transfer
list number and kind of STC staff and state is required to receive instruction/ knowledge transfer and
what other kind of knowledge transfer will be used in this project
I-12 Further Technical Information
(The vendor may here included any further technical information, which he considers necessary
and/or helpful to describe, explain and/or detail the proposed solution.)
I-13 Vendor Profile & Scope of Capability Information
The following information should be provided with respect to the responding company, its principals
and also any other partner companies who would be involved in this projects activities.
I-14 Reference Projects and -Customers
Provide a list of similar projects successfully completed, with special references to projects at telecom
service providers (similar to STC).

Reference Projects
Year Country Company Duration
(months)
Size
(Mio. $USD)
[vendor:
enter
staring
year of
project
as
NNNN]
[vendor: enter country
name where project
was implemented
[vendor: enter company name for
which the project was
implemented]
[vendor:
enter
project
duration
in
monts]
[vendor: enter
project
budget in
millions of $
USD
Contact Person Project Title
[vendor: enter the
name, title, telephone
number, fax number
and e-mail address of
an employee of the
company above,
whom STC may
contact]
[vendor: enter the project title]
Project Description
[vendor: enter a short narrative of the project scope. The description of one project
should not exceed one page]

[vendor: copy the part below as often as necessary]

Year Country Company Duration
(months)
Size
(Mio. $USD)
[vendor:
enter
staring
year of
project
as
NNNN]
[vendor: enter country
name where project
was implemented
[vendor: enter company name for
which the project was
implemented]
[vendor:
enter
project
duration
in
monts]
[vendor: enter
project
budget in
millions of $
USD
Contact Person Project Title
[vendor: enter the
name, title, telephone
number, fax number
and e-mail address of
an employee of the
company above,
whom STC may
contact]
[vendor: enter the project title]
Project Description
[vendor: enter a short narrative of the project scope. The description of one project
should not exceed one page]

Provide a list of reference customers (local & overseas); contact details should be provided should STC wish
to refer to them.
Reference Customers
Country Company Industry
Sector
Contact
[vendor: enter appropriate
information]

[vendor: expand as necessary]

I-14.1 Company Profile
- Financial Report for Year 2009
- Commitment to Research & Development
- Total employees (2009), consultancy & technical staff strength
- Year founded etc.
I-14.2 Companys Presence in Saudi Arabia and in the Middle-East Region
Own offices, agents, re-sellers or business partners.

What company resources will be made available on-site, in-country or overseas for the
implementation and support for this project
I-14.3 Company Partnerships and Alliances
Please list all current partnerships and alliances involving your company related to the sale,
distribution, or development of products or services, including the purpose for and duration of the
collaboration.
I-14.4 Company Scope of Capability
Provide copies of recent research and analysis documents published by leading independent
consultants regarding the quality and value of the products, services, market strengths and the future
status of the company.

I-15 Softcopies Technical Proposal
CD-ROMs to be included here containing all the tables in MS-Excel format and entire technical
response to the RFP in MS Word Format or RTF.
This should contain only technical information and NO COMMERCIAL INFORMATION.

Other formats like PDF or PowerPoint will not be accepted.

Vendor Response Cover Page goes here.

Section II Commercial Proposal

II-1 Cover Letter
This should be the same letter as provided under I-1.
II-2 Table of Content

II-3 Pricing Tables
One set of tables has to be provided for each alternative solution being proposed.

Note: All prices should be in Saudi Riyals and should be valid for a minimum of 90 days from the
closing date for this RFP.

P0 - Overall Pricing Table
Purchase Price
Description Amount Remarks
1 Hardware N/A [vendor: enter total of table P1]
2 Software [vendor: enter total of table P2]
3 Services [vendor: enter total of table P3]
4 Knowledge Transfer [vendor: enter total of table P4]
Total Purchase Price

Annual Maintenance and Support
Description Amount Remarks
Hardware 1.year N/A N/A
1 Year Total Hardware 0

Software 1.year N/A Should be included in the software license
1 Year Total Software 0

Grand Total

The 3 Year Grand Total equals Total Purchase Price.


P1 - Summary Hardware Pricing Table
Qty Req. = Quantity Required
AMS = Annual Maintenance and Support Charges
Description Unit Price Qty
Req.
Total price AMS Remarks
P1.1 Server Hardware (including operating system and all
required utilities)
N/A N/A N/A N/A
[vendor: enter subtotal of
table P1.1]

Total P1

P1.1 - Detailed Server Hardware Pricing Table
Item
Code
Item Description Unit Price Qty
Req.
Total price AMS Remarks
[vendor: enter detailed suggested server hardware] N/A N/A N/A N/A

Subtotal P1.1


2.1 Application software (server-side)
- including Advanced Cataloguing System
(Oracle tool)
- RTU
server 1 [vendor: enter subtotal of
table P2.2]

P2.1 - Detailed Application Software Pricing Table (server side)
RTU = Right To Use
RTU Unit = Licensing Unit i.e. # of processors, # of named users, etc.
Item Code Item Description RTU Unit Unit
Price
Qty req. Total price AMS Remarks
[vendor: enter proposed software]

Subtotal

P2-Summary Software Pricing Table
RTU = Right To Use
(Unit) = Licensing Unit i.e. # of processors, # of named users, etc.
Description RTU Unit Unit
Price
Qty Req. Total price AMS Remarks
2.2 Client GUI Application (Arabized):
- Development/ Customization to meet STC
end-user GUI requirements
user 100 [vendor: enter subtotal of
table P2.3]
2.3 [vendor: enter other proposed software] [vendor: enter subtotal of
table P2.5]

Total


P2.2 - Detailed Client GUI Application Software Pricing Table
RTU = Right To Use
Price
[vendor: enter r proposed software]

Subtotal

P2.3 - Detailed other Software Pricing Table
RTU = Right To Use
Price
[vendor: enter other proposed
software]

Subtotal


P3 - Summary Services Pricing Table
Description Man
days
Total
Charges
Remarks
3.1 Project Management & Consultancy Services [vendor: enter subtotals of table P3.1]
3.2 Installation, Customisation & Integration Services [vendor: enter subtotals of table P3.2]
3.3 Implementation Services [vendor: enter subtotals of table P3.3]
3.4 Testing & Acceptance Services (according to STC's procedure) [vendor: enter subtotals of table P3.4]
3.5 Project Auditing, Quality Control & Assurance Services [vendor: enter subtotals of table P3.5]
3.6 Post-implementation on-Site Support Services
- Operation and Administration
- Skills Development & Technology Transfer
[vendor: enter subtotals of table P3.6]
3.7 [vendor: enter other proposed services] [vendor: enter subtotals of table P3.7]
Total

Note: For the following tables, rates should include all travel & accommodation expenses for people sourced from overseas.

P3.1 - Project Management & Consultancy Services Pricing Table
oSS = Number of on Site Staff
Rate/md = Rate per Man-day
Man days = Total Man-days required for the activity
Item
Code
Activity Description oSS Rate
/md
Man
days
Total
Charges
Remarks
Project Management
Master Data Management Consultancy
Functional Consultancy
Technical Consultancy
[vendor: enter other proposed services]

P3.1 - Project Management & Consultancy Services Pricing Table
Item
Code
/md
Man
days
Total
Charges
Remarks
Subtotal

P3.2 - Installation, Customisation & Integration Services Pricing Table
Item
Code
/md
Man
days
Total
Charges
Remarks
Installation Services
Customisation Services
Integration Services
Subtotal

P3.3 Implementation Services Pricing Table
Item
Code
/md
Man
days
Total
Charges
Remarks
Implementation Services
End-User Knowledge Transfer Services

P3.3 Implementation Services Pricing Table
Item
Code
/md
Man
days
Total
Charges
Remarks
Supporting IT Departments in modifying systems and
interfaces that integrate with Inventory System

Subtotal

P3.4 - Testing & Acceptance Services Pricing Table
Item
Code
/md
Man
days
Total
Charges
Remarks
Testing Services
Acceptance Services
Subtotal

P3.5 - Project Auditing, Quality Control & Assurance Services Pricing Table
Item
Code
/md
Man
days
Total
Charges
Remarks
Project Auditing, Quality Control & Assurance Services
Subtotal

P3.6 - Post-implementation On-site Support Services Pricing Table
Rate/md = Rate per Man day
Rate/mm = Rate per Man month
Item
Code
Activity Description Skill-set Rate
/md
Rate /mm Remarks
Operations & Administration
Development & Customization

P3.7 Other Services Pricing Table
Item
Code
/md
Man
days
Total
Charges
Remarks
Subtotal

Note: assigned staff from the vendor or its partners should spend sufficient time on skill development of assigned STC staff so that at the end of
the term they will be ready to take-over the tasks with confidence.

P4 Summary Knowledge Transfer Pricing Table
Format = How is the Knowledge Transfer conducted - classroom, CBT- etc.
Rate/Stud. = Rate per Student
Stud./Class = Number of Students per Class
Dur. = Duration in days
Qty. = number of Knowledge Transfer Classes
Item Code Description Format Rate
/Stud
Stud.
/Class
Dur. Qty. Total Charges
New Item Code Training Course classroom 15 2
Advanced Product Catalogue formal Knowledge Transfer for End-Users classroom 15 3
Advanced Product Catalogue formal Knowledge Transfer for
Administrators and Support Staff
classroom 15 1
[vendor: enter other recommended knowledge transfer]
Total

II-4 Warranty Entitlements, Terms & Conditions
Description of the entitlements, terms and conditions on all warranties provided with the products included in the proposal.

II-5 Further Commercial Information
The vendor may here include any further commercial information, which he considers necessary and/or helpful to describe, explain and/or detail the
proposed solution.

II-6 Softcopies Commercial Proposal
CD-ROMs to be included here containing all the tables in MS-Excel format and the entire response to the RFP in MS Word Format or RTF.

Other formats like pdf or powerpoint will not be accepted.

4 APPENDIX 1: GENERAL TERMS & CONDITIONS
a) All information made available to prospective vendors including information collected during the
preparation and evaluation phase shall remain the property of STC and shall be handled as
confidential and restricted to authorized persons having a need to know within Saudi
Telecommunications Company (STC) and the authorized vendor.

The respective RFP document and any information contained herein may be neither in whole nor in part
made accessible or forwarded to any third party without prior, expressive, written consent from STC.
b) Proposals will only be accepted from vendors having been invited to respond to this RFP.
c) All proposal documents shall become property of STC and will not be returned to the vendor.
d) STC shall reject any proposal that does not agree to or comply to any of these terms and conditions
and/or does not follow the required mandatory response outline and/or does not provide required
information as softcopy and/or does propose payments not linked to deliverables.
e) STC selects on the best value/price performance and on best meeting the company requirements.
Therefore STC does not commit to award a contract to the lowest price offer.
f) Having received final vendor proposal submissions, it is STCs intention to select the most appropriate
solution.

However STC reserves the right to not award a contract in respect of the required products and services
and may reject any or all proposals received in response to this RFP.

STC has no obligation to explain to unsuccessful vendors the reasons for not proceeding with their
proposals.
g) Subsequent to submission of proposals vendors shall be prepared to discuss any aspect of the
proposal, deliver presentations, arrange client reference, etc. at the expense of the vendor.
h) STC shall not be liable for any cost incurred by vendors in preparing their responses to this RFP or for
any additional information, demonstrations or presentations during the course of the proposal evaluation
process.
i) STC reserves the right to partition the work into sub projects and offer it to one or more vendors, whom
the company considers are most suited to undertake the work.
In such cases the selected vendors are required to fully co-operate with other selected vendors to
collectively fulfill the objectives and requirements for the project.
j) STC reserves the right to cancel the project at any time prior to signing a contract for any reason and
without being liable for any cost incurred by the vendor before and/or during RFP preparation and/or
contract negotiation.
k) Vendors are not permitted to sub contract any part of the project without STCs prior written agreement.
l) STC has the right to amend the project plan and the content of phases, if necessary, before or during
the project.
m) Vendors proposals must be valid for 90 days from the closing date of submission of proposals. STC
reserves the right to extend this period for a further 30 days with the same terms and conditions.
n) Prices quoted in vendor proposals must be in Saudi Riyals and must be fixed for the validity period of
the proposal.
o) STC shall not be liable for taxes, accommodation, equipment, transportation, traveling, and any other
expenses that are incurred by the vendor's staff during the contract execution.
p) Contracted staff is required to be in attendance on STC premises Saturday to Wednesday (07:30 to
16:00) inclusive. Additional working hours and days can be negotiated.

q) STC shall have all ownership of and title to all software and/or files developed, modified or adapted for
STC in the course of this project, and all associated documentation of the complete system, including
any and all plans, drawings and vendor's special utilities. STC shall have the sole right to produce,
publish, or otherwise use, such software, modifications and documentation within STC provided it is only
for its own internal purposes.
r) Upon completion of the project the vendor shall turn over all STC-provided documents as well as all
material, reports, product documentation and work in progress documentation relating to this project.
s) The laws and regulations of Saudi Arabia shall apply to awarded contracts.

5 APPENDIX 2: INFORMATION ABOUT STC
5.1 STC - Organisation Overview & Mission
The Saudi Telecommunications Company (STC) is the prime provider of telecommunication services in
Saudi Arabia. It offers an expanding range of wired, wireless, voice and data services and facilities to
customers in all major geographical regions in the Kingdom.

STC has undertaken as its mission to provide world-class telecommunication services to its customers.
STC's efforts have achieved substantial growth in main services such as Basic Telephone Service and
Wireless Service.

The following table summaries some of the key organization statistics:

Total number of staff 20,275
Number of staff based in Riyadh

15,000 (approx)
Number of main staff locations (kingdom wide) 23
District Offices (kingdom wide) 13
Customer Service Offices (kingdom wide) 300
Basic telephone lines 3,750,000
Wireless Mobile 11,000,00+
Pagers

472,481
Source: STC Corporate Planning

5.2 Current IT Environment
The enterprise information systems in the STC's IT environment are grouped into two main categories
namely 'Centralized Operations & Maintenance or COM' and 'Information Systems or IS' and STC's Data
Network provides connectivity between Systems (COM/IS), Network Elements, Control Centers and End-
users.

In addition to the enterprise systems, there are Intranet; Internet & messaging systems and other specialized
and departmental application in the STC IT environment.

COM systems are used to control, monitor and manage the telecommunication network components which
can be broadly divided into Switching and Transmission systems, whereas IS systems are used on the
business end for Billing & customer care, Business Support Systems and other business related information
systems.

A wide variety of telecommunication and business applications are hosted on large and medium sized Unix
and other server platforms at STC, in addition there are Intel processor based servers distributed
throughout STC locations mainly for messaging, intranet and other departmental applications.

Also, there are new initiatives in the IT environment such as e-Business, Data Warehousing etc. that would
bring in further diversity into the IT infrastructure at STC.

5.3 Major Application Systems
The following table summarizes the major application systems currently in operation at STC and it is
expected that system implemented under this project may have to interact with some of these systems.

Major Application Systems Table
System Group Components Base Application Platform/DBMS
Business Support
System (BSS)
Financial, Material, HR,
Procurement
(ERP)
Oracle Financials IBM RS/6000-
AIX, Oracle
Customer Care & Billing
(CC&B)
Customer Service,
Provisioning, Billing, Usage
Services for Wireline &
Wireless
IBM Integrated Customer
Management System
(ICMS)
IBM AS/400,
DB2/400
Centralized Operation &
Maintenance (COM)
OSS for Switching,
Transport, Signaling &
Wireless domains
Various applications from
telecom equipment vendors
(Lucent, Ericsson, Siemens)
HP9000 & Sun
Servers with
Oracle or Sybase
or Informix
Mediation Billing and Service
Provisioning
COMPTEL MDS HP9000 Servers
Oracle DBMS
EDW Enterprise Data Warehouse Teradata EDW NCR, Teradata
(see STC-
Architecture-
Requirements
document
attached)
Other Revenue Data mart, Call
Center, GIS etc.
Various Various
Note: there are numerous interfaces implemented for application and data level integration between the
above system groups and applications.

5.4 STC Test & Acceptance Procedure
Acceptance of project deliverables and of the project as a whole is based on deliverables passing tests.

Tests verify if STC requirements are met.

Acceptance is generally done using the following documents and tests in a five step process:

1. Customer Specification Document (CSD):
The objective of the CSD is to provide a comprehensive specification describing the full functionality
of the system (including all customisations done) as well as its interworking and connections with
and to other systems.
This document has to contain a requirements cross-reference, which maps features and functions to
the project requirements. This will be used as a basis for formulating tests.
This document is primarily composed of two documents: As-Is study Report and To-Be study Report
including a gap analysis showing how to close the gaps in the To-Be solution. A sample CSD can be
provided at the beginning of the project.
This document has to be updated whenever a requirement changes.

2. System Qualification Test (SQT):
The objective of the SQT is to demonstrate the functionality and performance of the solution,
systems, applications, services.
STC performs the SQT execution with support by the vendors staff. Issues resulting from the SQT
are recorded in approved log sheets.
Every effort has to be made by the vendor to resolve all the SQT issues before PAT. Any
outstanding issues are carried forward to the PAT.

3. Installation Test (IT):
The objective of the IT is to verify the completeness of the delivery and demonstrate the correct
installation and integration of the solution, systems, applications and services.
The IT is performed by the vendor at each site and its execution is always witnessed by
knowledgeable STC staff which is capable to verify and evaluate the IT test results.

4. Preliminary Acceptance Test (PAT):
The objective of the PAT is to verify the results of the IT as reported by vendor and to determine that
the solution completely suffices STC's requirements.
STC executes the PAT with support by the vendors staff.
Outstanding issues resulting from PAT are recorded in the official Outstanding Issues Log (OIL). The
issues are resolved in accordance with Clearance of Outstanding Items procedures from the joint
vendor and STC Working Group.

5. Final Acceptance Test (FAT):
FAT is performed towards the end of the warranty period to verify the performance of the solution,
systems, applications, and services in the real production environment.

For a detailed description of the Test & Acceptance Procedure refer to the separate document: " "Project
Implementation and Acceptance Process, Version 1.0".

STC Imf

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

STC Imf

Uploaded by

Copyright:

Available Formats

Request for Proposal

Shared Services Sector

You might also like