Stc Imf Copy

Request for Proposal

Shared Services Sector Planning and Performance GD

Item Master File Enhancement Project (IMF EP)

Version: Final Issue date: 15-May-2010

- 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.

Request For Proposal Item Master File Enhancement Project Table of Content 1

INTRODUC INTRODUCTIO TION N & OVERVIEW OVERVIEW ........................................................................................................ 4 1.1 Statement Statement of Confident Confidentiality iality ...................................................................................................... 4 1.2 Purpose Purpose of the RFP .................................................................................................................. .................................................................................................................. 4 1.3 Project Project Overvie Overview............................................................................................ w....................................................................................................................... ........................... 4 1.3.1 STC STC Business Business Requireme Requirements nts ........................................................................................ ........................................................................................ 4 1.3.2 Backgro Background und.................................................................................................................. 4 1.3.3 Project Project Descript Description ion ....................................................................................................... 6 1.3.4 Baseline Table of Items and Services based on the new code .................................... 10 1.3.5 Recoding Recoding current Items (Inventory, Assets and S ervices) 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 Relation with Other Other Projects 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 IMF-EP Timeframe Timeframe ..................................................................................................... ..................................................................................................... 13 1.3.12 Development of STC Cataloguing Procedures ............................................................ 13 1.4 Anticipated Project Project Time Frame ...... ....... ....... ....... ....... ....... ....... ........ ....... ....... ....... ....... ....... ... 13 1.5 Vendor Vendor Response Response ................................................................................................................... ................................................................................................................... 13 1.6 Questions Questions relating relating to the RFP RFP ................................................................................................. 14 1.7 Submiss Submission ion of Proposa Proposals ls......................................................................................................... 14 1.8 Selection Selection Process & Evaluatio Evaluation n Criteria Criteria .................................................................................. 14 1.8.1 Vendor Vendor Presentat Presentation ion ................................................................................................... ................................................................................................... 15 1.8.2 Vendors Vendors Conferen Conference ce ........................................................................................... .................................................................................................. ....... 15

2

STC STC REQUIRE REQUIREMENT MENTS S ........................................................................................... .................................................................................................................... ......................... 16 2.1 Genera Generall Requireme Requirements nts ............................................................................................................ ............................................................................................................ 16 2.1.1 Server Server and Storage Storage Requiremen Requirements ts.............................................................................. 16 2.1.2 Data Data Networkin Networking g Requiremen Requirements ts .................................................................................. 17 2.1.3 Data Data centre centre Requireme Requirements nts.......................................................................................... 17 2.1.4 Security Security Requireme Requirements nts ............................................................................................... 17 2.1.5 Integration Integration Requireme Requirements nts .................................................................................... ........................................................................................... ....... 17 2.1.6 Mediatio Mediation n Requireme Requirements nts............................................................................................. ............................................................................................. 18 2.1.7 Data and Application Architecture Requirements ........................................................ 18 2.2 IT Functional Functional Requirements Requirements .................................................................................................... .................................................................................................... 19 2.3 Performanc Performance e & Workload Workload Requireme Requirements nts ................................................................................. 22 2.4 Reliability, Availability & Serviceability Requirements .............................................................. 22 2.5 Project Project Deliver Deliverables ables ................................................................................................................ ................................................................................................................ 23 2.5.1 Data Data Model............................................................... Model................................................................................................................. .................................................. 24 2.5.2 Application Model Model ........ ....... ....... ....... ....... ....... ....... ....... ........ ....... ....... ....... ....... ....... ... 24 2.5.3 Continge Contingency ncy Plan ....................................................................................................... ....................................................................................................... 24 2.5.4 Knowled Knowledge ge Transfer Transfer ................................................................................................... 25 2.5.5 Documen Documentation tation........................................................................................................... 25 2.6 Documentation- and STC Software Ownership ....................................................................... 26 2.7 Project Project specific specific Terms Terms & Condition Conditions s ........................................................................................ 26

3

VENDOR VENDOR PROPOSA PROPOSAL L REQUIREME REQUIREMENT NTS S ........................................................................................ 27 3.1.1 Mandatory Mandatory Proposal Proposal Outline Outline ....................................................................................... 28 3.1.2 Detailed Instructions and Explanations ....................................................................... 28

4

APPENDIX 1: GENERAL TERMS & CONDITIONS ......................................................................... 45

5

APPENDIX APPENDIX 2: INFORMA INFORMATIO TION N ABOUT ABOUT STC.................................................................................... 47 5.1 STC STC - Organisa Organisation tion Overview Overview & Mission Mission.................................................................................. 47

IMF-EP RFP Final Version

Business Support Dept

Confidential - See First Page For Restrictions

Page 2 of 49

Request For Proposal Item Master File Enhancement Project Table of Content 1

INTRODUC INTRODUCTIO TION N & OVERVIEW OVERVIEW ........................................................................................................ 4 1.1 Statement Statement of Confident Confidentiality iality ...................................................................................................... 4 1.2 Purpose Purpose of the RFP .................................................................................................................. .................................................................................................................. 4 1.3 Project Project Overvie Overview............................................................................................ w....................................................................................................................... ........................... 4 1.3.1 STC STC Business Business Requireme Requirements nts ........................................................................................ ........................................................................................ 4 1.3.2 Backgro Background und.................................................................................................................. 4 1.3.3 Project Project Descript Description ion ....................................................................................................... 6 1.3.4 Baseline Table of Items and Services based on the new code .................................... 10 1.3.5 Recoding Recoding current Items (Inventory, Assets and S ervices) 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 Relation with Other Other Projects 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 IMF-EP Timeframe Timeframe ..................................................................................................... ..................................................................................................... 13 1.3.12 Development of STC Cataloguing Procedures ............................................................ 13 1.4 Anticipated Project Project Time Frame ...... ....... ....... ....... ....... ....... ....... ........ ....... ....... ....... ....... ....... ... 13 1.5 Vendor Vendor Response Response ................................................................................................................... ................................................................................................................... 13 1.6 Questions Questions relating relating to the RFP RFP ................................................................................................. 14 1.7 Submiss Submission ion of Proposa Proposals ls......................................................................................................... 14 1.8 Selection Selection Process & Evaluatio Evaluation n Criteria Criteria .................................................................................. 14 1.8.1 Vendor Vendor Presentat Presentation ion ................................................................................................... ................................................................................................... 15 1.8.2 Vendors Vendors Conferen Conference ce ........................................................................................... .................................................................................................. ....... 15

2

STC STC REQUIRE REQUIREMENT MENTS S ........................................................................................... .................................................................................................................... ......................... 16 2.1 Genera Generall Requireme Requirements nts ............................................................................................................ ............................................................................................................ 16 2.1.1 Server Server and Storage Storage Requiremen Requirements ts.............................................................................. 16 2.1.2 Data Data Networkin Networking g Requiremen Requirements ts .................................................................................. 17 2.1.3 Data Data centre centre Requireme Requirements nts.......................................................................................... 17 2.1.4 Security Security Requireme Requirements nts ............................................................................................... 17 2.1.5 Integration Integration Requireme Requirements nts .................................................................................... ........................................................................................... ....... 17 2.1.6 Mediatio Mediation n Requireme Requirements nts............................................................................................. ............................................................................................. 18 2.1.7 Data and Application Architecture Requirements ........................................................ 18 2.2 IT Functional Functional Requirements Requirements .................................................................................................... .................................................................................................... 19 2.3 Performanc Performance e & Workload Workload Requireme Requirements nts ................................................................................. 22 2.4 Reliability, Availability & Serviceability Requirements .............................................................. 22 2.5 Project Project Deliver Deliverables ables ................................................................................................................ ................................................................................................................ 23 2.5.1 Data Data Model............................................................... Model................................................................................................................. .................................................. 24 2.5.2 Application Model Model ........ ....... ....... ....... ....... ....... ....... ....... ........ ....... ....... ....... ....... ....... ... 24 2.5.3 Continge Contingency ncy Plan ....................................................................................................... ....................................................................................................... 24 2.5.4 Knowled Knowledge ge Transfer Transfer ................................................................................................... 25 2.5.5 Documen Documentation tation........................................................................................................... 25 2.6 Documentation- and STC Software Ownership ....................................................................... 26 2.7 Project Project specific specific Terms Terms & Condition Conditions s ........................................................................................ 26

3

VENDOR VENDOR PROPOSA PROPOSAL L REQUIREME REQUIREMENT NTS S ........................................................................................ 27 3.1.1 Mandatory Mandatory Proposal Proposal Outline Outline ....................................................................................... 28 3.1.2 Detailed Instructions and Explanations ....................................................................... 28

4

APPENDIX 1: GENERAL TERMS & CONDITIONS ......................................................................... 45

5

APPENDIX APPENDIX 2: INFORMA INFORMATIO TION N ABOUT ABOUT STC.................................................................................... 47 5.1 STC STC - Organisa Organisation tion Overview Overview & Mission Mission.................................................................................. 47




Page 2 of 49

Request For Proposal Item Master File Enhancement Project 5.2 5.3 5.4

Current Current IT Environme Environment nt........................................................................................................... 47 Major Applica Application tion Systems Systems ...................................................................................................... ...................................................................................................... 48 STC STC Test Test & Acceptan Acceptance ce Procedure 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




Page 3 of 49

Request For Proposal Item Master File Enhancement Project

1

INTRODUCTION & OVERVIEW OVERVI EW

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 t o STC, the vendor/reseller 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 effecti ve 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 results/deliverables not for act ivities.

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 sector’s relationship with the all sector. BSD is also assigned to manage all all IT I T 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 t his 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 solution May also provide the following capability: Support for equipment equipment manufacturers’ manufacturers’ compliance compliance to Vendor requirements o Access to Vendor Vendor systems and data repositories. o Vendor coding standards development. development. o Vendor naming standards technical specification specification documents. o This plan May also focus on t he 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 t able shows:




Page 4 of 49


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)




Page 5 of 49

Request For Proposal Item Master File Enhancement Project 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 i nvestigate current item master f ile 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 fulf ils 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 Ser vices 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 p roject are : 1. 2.

3. 4.

5. 6. 7. 8.

To enable an effective management for IMF through developing new business process and deploying data management tool. 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. To recommend a new standard to codify, classify, and categorize items in IMF. 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 To include a life cycle approach to handle items in IMF. To improve and maintain data quality and consistent sets of IMF. To support governance, stewardship, and cross-functional coordination. To adhere to security and privacy requirements.

As part of this operation, it is expected that the contractor cover the following detailed requirements: IMF-EP RFP Final Version



Page 6 of 49


Requirement Description 1

2

Extraction and Aggregation data from various systems of record (ERP, Customized applications, excel sheets, etc.) used by STC’s sectors to be part of this project. STC Project Team will perform the collection of this data. 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 i mplement 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: 







3

4

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.

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. 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.




Page 7 of 49

Request For Proposal Item Master File Enhancement Project Requirement Description Item Categories feature must be activated. The following attribute information should be captured as part of t he network equipment identification across multiple equipment manufacturers in a consistent manner: Identif y 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: Manufacturer name o Manufacturer’s part number o Specific revision o Description of device o System (NE) name o Technology o Engineering characteristics o Financial tracking of equipment assets o 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 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 t he Business Control Tools required by Management.  



 





 



   



         

5




Page 8 of 49

Request For Proposal Item Master File Enhancement Project Requirement Description 10- Cross-Referencing old codes with new codes f unctionality.

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 t o simplify the integration activities. If the contractor has his own Cataloguing Tool and would like to propose its usage by STC, he should do t hat 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 ment ion here that Asset definition in IMF is f or 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 t he 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 W orkflow mechanisms. If it is decided to use another cataloguing tool, the contractor is responsible for its integration with ot her STC applications following STC EAI Standards. The proposed IMF data management tool should have the f ollowing 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.




Page 9 of 49

Request For Proposal Item Master File Enhancement Project 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 t he 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 nonstandard 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 Item s, Assets or Services, then each entity should have its own base table of prospect main categories, subcategories and items.

STC Items Base Table

Define New Item Process


Approve New Item Process

STC IMF

STC Catalog



Page 10 of 49


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 perf orm 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 f inancials) 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 All organizations = 1062472 Master org =63639

Item master Inventory

Purchasing

Transaction history (All transactions types) Material distributions Inv Organization

All organizations = 1993637

Purchase requisitions

All organizations = 2784853 21 Purchase Requisitions : 21686 Purchase Requisitions Lines: 288845

Purchase orders

Purchase Orders : 32690 Purchase Releases : 115606




Page 11 of 49

Request For Proposal Item Master File Enhancement Project Purchase Orders Lines : 562146 Purchase Orders Shipments : 670850 AP FA Users

Invoices Assets

Lines = 302459payments = 329156 193928 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 t he 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 f or 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 t he 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.




Page 12 of 49


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 Implementation Planning Design, Development & Functional Testing Pilot & Acceptance Testing Production Roll-out Post Implémentation Support

1.5

1 month 1 month 9 months 1 month 1 month 3 months

Vendor Response

The vendor(s)’s Must response to the Following Project Tasks: Designing new codes for Material, Assets and Services o 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 STC’s 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.




Page 13 of 49

Request For Proposal Item Master File Enhancement Project 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 A rabia

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 A rabia

1.8

Selection Process & Evaluation Criteria

Saudi Telecom selects services and solutions based on the best value and affordability in meeting or exceeding the company’s requirements. The Technical and Commercial Proposals may be evaluated separately prior to the final decision. For the t echnical 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 dif fer according to specifi c 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




Page 14 of 49

Request For Proposal Item Master File Enhancement Project 

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 distr ibuted by STC to each vendor. No individual responses to specific vendors will be given prior to the vendor conference.




Page 15 of 49


2

STC REQUIREMENTS

2.1

General Requirements



State-of-the-art Technology



Adherence to Industry Standards



Highly scalable and modular



Application Integration through STC’s 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 f rom 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 STC’s 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 STC’s consolidated environment (CE). The vendor should keep into the account the STC’s High Availability (HA) requirements.

Architectural Element Server Hardware & OS

Standard 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) 






Page 16 of 49

Request For Proposal Item Master File Enhancement Project 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 Envi ronment: 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 Oracle, DB2 HP, SUN, IBM workstation, leading PC Server manufacturers with latest version of HP-UX, Solaris, AIX, Windows and Linux 

DBMS Client Hardware & OS

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-ForIT-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 inf ormation 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 af fect 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 wit h other STC systems such as the Common Language Clone”




Page 17 of 49

Request For Proposal Item Master File Enhancement Project 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 wi thin 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 foll owing 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

STC’s 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).




Page 18 of 49


2.2

IT Functional Requirements IT Functional Requirements Table

Id#

CL= Compliance Level (for an explanation see I-4.3 Requirements ) Item Vendor Response STC Requireme nt CL

1

2.1 FR2.1.1

Application Software (Server Side) Data management Tool Application Software (Client side) - End-User Interface Requirements Client Interface Thick client application (client/server)

FR2.1.2

Web browser (thin client) interface

FR2.1.3

A Graphical User Interface with access to functions with minimum clicks and key strokes A Command line interface

Yes

Command line interface is scriptable

optional

FR-1.1

2

FR2.1.4 FR2.1.2.1

2.2 2.2.1 FR2.2.1.1 FR2.2.1.2

FR2.2.1.3

Arabization Data Unicode Code (ISO 10646) in UTF-8 encoding shall be used. 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. The application shall not contain hard-coded character constants, numeric constants, screen positions, filenames, or pathnames that presume a particular language.


Reference/Short description

Yes

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

optional

Yes Yes

Yes



Page 19 of 49


IT Functional Requirements Table Id#


FR2.2.1.4

FR2.2.1.5 FR2.2.1.6

2.2.2 FR2.2.2.1 FR2.2.2.2

FR2.2.2.3

FR2.2.2.4

FR2.2.2.5

FR2.2.2.6 FR2.2.2.7 FR2.2.2.8 FR2.2.2.9

FR2.2.2.1 0

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). The application shall not concatenate strings to form messages/sentences. Localized and localizable items shall be stored in separate resource files. GUI Unicode Code (ISO 10646) in UTF-8 encoding shall be used. 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. Default alignment of Arabic text for all windows and widgets (menus, textboxes, forms, etc.) shall be right to left. Control symbols for window or if any for other widget should be at the top-left corner of the window or widget. 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. Vertical scroll bars shall be at the left of the window or if any at the left of the widget. Horizontal scroll bars shall start from right and move to left. Progress bars shall fill with time from right to left. The source of the light f or shadow-use in 3-day interf ace shall be assumed at the topright of the screen. Consistent Arabic-English user interface terminology should be used.



Yes

Yes

Yes

Yes Yes

Yes

Yes

Yes

Yes

Yes Yes Yes

Yes



Page 20 of 49


IT Functional Requirements Table Id#


3 FR-3.1

FR-3.2

4 FR-4.x 5 FR-5.1 FR-5.2

Integration Application Integration must adhere to the STC Integration policies and standards. See 2.1.5 Specific dependencies with other applications and minimal set of interfaces required

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

FR -5.3

Produce daily/weekly/monthly reports on access control logs.

6

Item Master File

FR-6.1 FR-6.2

Designing new coding scheme. Item data collection from available sources. Items data cleansing Items data standardization and enrichment Items classification and cataloguing Items and transactions data conversion Design and implement new items cataloguing procedures Provision of classifications and items base table

FR-6.3 FR-6.4 FR-6.5 FR-6.6 FR-6.7 FR-6.8



Yes

Activate the Integration of Oracle with other Oracle Financial and Supply Chain Modules. No. optional Yes

Yes.



Page 21 of 49

Request For Proposal Item Master File Enhancement Project 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 It em 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 t he table below:

Performance & Workload Requirements Table CL= Compliance Level (for an explanation see I-4.3 Requirements ) Vendor Response Id#

PW-1 PW-2 PW-3

2.4

Factor

STC Requireme nt

Data management Tool number of concurrent users Number of new items to store Response times for typical system operations or volumes

CL

Reference/Explanation

100 5000 / month Standard

Reliability, Availability & Serviceability Requirements Reliability, Availability & Serviceability Requirements Table CL= Compliance Level (for an explanation see I-4.3 Requirements ) Vendor Response

Id#

Item

RAS-1

allowable downtime during business hours(min/day) allowable downtime off business hours (min/day) Time for a full system backup Time for a full system restore (h) Remote Manageability Remote Boot Capability Administrator Browser Interface Administrator "Windows" Interface

RAS-2 RAS-3 RAS-4 RAS-5 RAS-6 RAS-7 RAS-8


STC Requireme nt

CL

Reference Explanation

Standard Standard Standard Standard Standard Standard Standard Standard



Page 22 of 49


Reliability, Availability & Serviceability Requirements Table CL= Compliance Level (for an explanation see I-4.3 Requirements ) Vendor Response Id#

Item

RAS-9

Administrator Command Line Interface

STC Requireme nt Standard

CL

Reference Explanation

RAS-xx

2.5

Project Deliverables

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

Deliverables Table Component

Remarks

1. 1.1

Hardware Server Hardware (including operating system and all required utilities)

1.2 1.4

Client Hardware Hardware Maintenance & Support

2 2.1

Software Oracle DBMS software

2.2 2.3 2.4 2.5 3.

Application software (server-side) Data Manegement tool RTU Development/ Customization to meet STC requirements Client GUI Application (Arabized): Data Manegement tool Development/ Customization to meet STC requirements Integration specific software (e.g. adapter, developments) Software Maintenance & Support Services

3.1

Project management & consultancy services

3.2

Installation, Customisation & Integration Services

3.3

Implementation Services

3.3 3.4

Transfer of Knowledge and Documentation Project auditing, Quality control & assurance three different time periods each runs for one week

3.5 -

Post-implementation on-site support for a period of 3 months Operation and Administration Skills Development & Technology Transfer


N/A Perpetual Licenses for all software required. See point 1.3.9 above. N/A N/A

N/A Perpetual License required Yes. Perpetual License required

100 users. Concurrent User Licenses Yes if necessary. Included in the licence. For tasks details refer to points 1.3.4-1.3.8 and 1.3.11-1.3.14 All tasks to be carried out on-site at STC All tasks to be carried out on-site at STC All tasks to be carried out on-site at STC Yes. Should be a non-vendor affiliated, independent consultancy. See point 1.3.14 above Yes. Performed by an Arabic speaking f unctional consultant and a technical consultant.



Page 23 of 49

Request For Proposal Item Master File Enhancement Project Beside the necessary hardware, software and services the vendor shall provide the f ollowing.

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

o

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. A Create, Read, Update, Delete (CRUD) Matrix showing the business units creating, reading, updating and deleting entities and attributes. 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, f ield-name, data type, -length, codes, allowable values, validity of null values and so on are described here. Modules will be creating, r eading, updating and deleting entities and attributes. (CRUD Matrix)

This must reflect any customizations that have been done t o 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 c omponent 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.




Page 24 of 49


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 f uture 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 t he 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 vendor’s 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 STC’s 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 m anuals, 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 t he 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.




Page 25 of 49


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.




Page 26 of 49


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 i n 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 t he mandatory proposal outline including the numbering (i.e "I-4 Solution Overview.doc")




Page 27 of 49


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 Company’s 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




Page 28 of 49

Request For Proposal Item Master File Enhancement Project 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 t he 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.




Page 29 of 49


Compliance Level Table Code FC

Description Fully compliant. This is out of the box functionality. The only customisation required may be using some configuration/administration module/s of t he application. Requires only changing configuration (text) files. Requires writing a script or program, which accesses the application via an API, object orientati on 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. same as above but Work Effort <= 1 man month same as above but Work Effort > 1 man month Requires changing the source code of the application and a new built of one or more modules. Work Effort <= 1 man month same as above. Work Effort > 1 man month Not compliant. Functionality is not provided/available.

C1 C2

C3 C4 C5 C6 NC

Below is a sample part of a requirements table filled.

IT Functional Requirements Table CL= Compliance Level Item

Id#

...

CL ...

Reference/Short description ...

Yes

FC

Yes

C2

see I-6, Section 2-3. The software will accept postscript input, which can then be reprinted to a postscript printer. see I-6, Section 2-5. This requires use of the XYZ feature.

...

...

FR3.7

Application Software (Server Side) Must accept Postscript formatted bill print files as input

FR3.8

Must accept PCL formatted bill print files as input

3

...

Vendor Response

STC Requirement

...

...

...

...

The vendor should explain if and how customised modules will be integrated in f uture distributions.

I-4.4

Capacity Table and Growth Potential of the Cataloguing Tool

Capacity Table Id#

C-1 C-2 C-3

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)

Data Manegement tool concurrent users Data Manegement tool Number of new items to store Response times for typical system operations or volumes




Page 30 of 49

Request For Proposal Item Master File Enhancement Project 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 pr ovided 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 vendor’s 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 O utputs (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)




Page 31 of 49


Input Phase Output Table Inputs

Phase/Activities 2. document current IT infrastructure (4 weeks)

O1.1 … I2.1 PIA physical architecture document I2.2 STC’s business process descriptions, applications environment I.2.3 … …

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

…

Outputs/Deliverables 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 t o be maintained/updated by STC. This should not be m ore than half a page per output. State in which time interval these outputs should be updated.

I-10.3 Project Management The vendor’s 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 …



Page 32 of 49

Request For Proposal Item Master File Enhancement Project 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, l eased lines, etc. I-11.4 Knowledge Transfer list number and kind of STC staff and state i s 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 t he responding company, its principals and also any other partner companies who would be involved in this project’s 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

[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]

Contact Person [vendor: enter the name, title, telephone number, fax number and e-mail address of an employee of the company above, whom STC may contact]

Duration (months)

Size (Mio. $USD)

[vendor: enter project duration in monts]

[vendor: enter project budget in millions of $ USD

Project Title [vendor: enter the project title]

Project Description [vendor: enter a short narrative of t he project scope. The description of one project should not exceed one page]

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




Page 33 of 49

Request For Proposal Item Master File Enhancement Project Year

Country

Company

[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]

Contact Person

Duration (months) [vendor: enter project duration in monts]

Size (Mio. $USD) [vendor: enter project budget in millions of $ USD

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 t he 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 Company’s Presence in Saudi Arabia and in the Middle-East Region Own offices, agents, re-sellers or busi ness 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 f uture status of the company.




Page 34 of 49

Request For Proposal Item Master File Enhancement Project 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 R TF. 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




Page 35 of 49

Request For Proposal Item Master File Enhancement Project 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 1 Hardware 2 Software 3 Services 4 Knowledge Transfer

Amount

Remarks [vendor: enter total of table [vendor: enter total of table [vendor: enter total of table [vendor: enter total of table

N/A

P1] P2] P3] P4]

Total Purchase Price Annual Maintenance and Support Description Hardware 1.year

1 Year Total Hardware Software 1.year

1 Year Total Software

Amount N/A

Remarks N/A

0 N/A

Should be included in the software license

0

Grand Total The 3 Year Grand Total equals Total Purchase Price.




Page 36 of 49


P1 - Summary Hardware Pricing Table Qty Req. = Quantity Required AMS = Annual Maintenance and Support Charges Description P1.1 Server Hardware (including operating system and all required utilities)

Unit Price

Qty Req.

Total price

AMS

N/A

N/A

N/A

N/A

Remarks [vendor: enter subtotal of table P1.1]

Total P1

P1.1 - Detailed Server Hardware Pricing Table Qty Req. = Quantity Required AMS = Annual Maintenance and Support Charges Item

Item Description

Unit Price

Qty Req.

Total price

AMS

[vendor: enter detailed suggested server hardware]

N/A

N/A

N/A

N/A

Code

Remarks

Subtotal P1.1



Page 37 of 49



P2-Summary Software Pricing Table RTU = Right To Use (Unit) = Licensing Unit i.e. # of processors, # of named users, etc. Qty Req. = Quantity Required AMS = Annual Maintenance and Support Charges Description 2.1 2.2 2.3

Application software (server-side) including Advanced Cataloguing System (Oracle tool) RTU Client GUI Application (Arabized): Data Manegement tool Development/ Customization to meet STC end-user GUI requirements [vendor: enter other proposed software]

RTU Unit

Unit Price

Qty Req.

Total price

AMS

Remarks

server

1

[vendor: enter subtotal of table P2.2]

user

100


Total

P2.1 - Detailed Application Software Pricing Table (server side)



P2-Summary Software Pricing Table RTU = Right To Use (Unit) = Licensing Unit i.e. # of processors, # of named users, etc. Qty Req. = Quantity Required AMS = Annual Maintenance and Support Charges Description 2.1 2.2 2.3

RTU Unit

Application software (server-side) including Advanced Cataloguing System (Oracle tool) RTU Client GUI Application (Arabized): Data Manegement tool Development/ Customization to meet STC end-user GUI requirements [vendor: enter other proposed software]

Unit Price

Qty Req.

Total price

AMS

Remarks

server

1


user

100



Total

P2.1 - Detailed Application Software Pricing Table (server side) RTU = Right To Use RTU Unit = Licensing Unit i.e. # of processors, # of named users, e tc. Qty Req. = Quantity Required AMS = Annual Maintenance and Support Charges Item Code

Item Description

RTU Unit

Unit Price

Qty req.

Total price

AMS

Remarks

[vendor: enter proposed software] Subtotal



Page 38 of 49



P2.2 - Detailed Client GUI Application Software Pricing Table RTU = Right To Use RTU Unit = Licensing Unit i.e. # of processors, # of named users, e tc. Qty Req. = Quantity Required AMS = Annual Maintenance and Support Charges Item Code

Item Description

RTU Unit

Unit Price

Qty req.

Total price

AMS

Remarks

AMS

Remarks

[vendor: enter r proposed software] Subtotal

P2.3 - Detailed other Software Pricing Table RTU = Right To Use RTU Unit = Licensing Unit i.e. # of processors, # of named users, e tc. Qty Req. = Quantity Required AMS = Annual Maintenance and Support Charges Item Code

Item Description [vendor: enter other proposed software]

RTU Unit

Unit Price

Qty req.

Total price


P2.2 - Detailed Client GUI Application Software Pricing Table RTU = Right To Use RTU Unit = Licensing Unit i.e. # of processors, # of named users, e tc. Qty Req. = Quantity Required AMS = Annual Maintenance and Support Charges Item Code

Item Description

RTU Unit

Unit Price

Qty req.

Total price

AMS

Remarks

AMS

Remarks

[vendor: enter r proposed software] Subtotal

P2.3 - Detailed other Software Pricing Table RTU = Right To Use RTU Unit = Licensing Unit i.e. # of processors, # of named users, e tc. Qty Req. = Quantity Required AMS = Annual Maintenance and Support Charges Item Code

Item Description

RTU Unit

Unit Price

Qty req.

Total price

[vendor: enter other proposed software] Subtotal



Page 39 of 49



P3 - Summary Services Pricing Table Description 3.1 3.2 3.3 3.4 3.5 3.6 3.7

Project Management & Consultancy Services Installation, Customisation & Integration Services Implementation Services Testing & Acceptance Services (according to STC's procedure) Project Auditing, Quality Control & Assurance Services Post-implementation on-Site Support Services Operation and Administration Skills Development & Technology Transfer [vendor: enter other proposed services]

Man days

Remarks

Total Charges

[vendor: enter subtotals of table P3.1] [vendor: enter subtotals of table P3.2] [vendor: enter subtotals of table P3.3] [vendor: enter subtotals of table P3.4] [vendor: enter subtotals of table P3.5] [vendor: enter subtotals of table P3.6]

[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


P3 - Summary Services Pricing Table Description 3.1 3.2 3.3 3.4 3.5 3.6 3.7

Man days

Remarks

Total Charges

Project Management & Consultancy Services Installation, Customisation & Integration Services Implementation Services Testing & Acceptance Services (according to STC's procedure) Project Auditing, Quality Control & Assurance Services Post-implementation on-Site Support Services Operation and Administration Skills Development & Technology Transfer [vendor: enter other proposed services]

[vendor: enter subtotals of table P3.1] [vendor: enter subtotals of table P3.2] [vendor: enter subtotals of table P3.3] [vendor: enter subtotals of table P3.4] [vendor: enter subtotals of table P3.5] [vendor: enter subtotals of table P3.6]

[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 th e activity Activity Description

Item Code

oSS

Rate /md

Man days

Total Charges

Remarks

Project Management Master Data Management Consultancy Functional Consultancy Technical Consultancy [vendor: enter other p roposed services] IMF-EP RFP Final Version


Page 40 of 49



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 th e activity Item Code

Activity Description

oSS

Rate /md

Man days

Total Charges

Remarks

Subtotal

P3.2 - Installation, Customisation & Integration Services Pricing Table oSS = Number of on Site Staff Rate/md = Rate per Man-day Man days = Total Man-days required for th e activity Item Code

Activity Description Installation Services Customisation Services Integration Services [vendor: enter other p roposed services] Subtotal

oSS

Rate /md

Man days

Total Charges

Remarks


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 th e activity Activity Description

Item Code

oSS

Rate /md

Man days

Total Charges

Remarks

Subtotal

P3.2 - Installation, Customisation & Integration Services Pricing Table oSS = Number of on Site Staff Rate/md = Rate per Man-day Man days = Total Man-days required for th e activity Activity Description

Item Code

oSS

Rate /md

Man days

Total Charges

Remarks

Installation Services Customisation Services Integration Services [vendor: enter other p roposed services] Subtotal

P3.3 – Implementation Services Pricing Table oSS = Number of on Site Staff Rate/md = Rate per Man-day Man days = Total Man-days required for th e activity Activity Description

Item Code

oSS

Rate /md

Man days

Total Charges

Remarks

Implementation Services End-User Knowledge Transfer Services IMF-EP RFP Final Version


Page 41 of 49



P3.3 – Implementation Services Pricing Table oSS = Number of on Site Staff Rate/md = Rate per Man-day Man days = Total Man-days required for th e activity Item Code


oSS

Rate /md

Man days

Total Charges

Remarks

Supporting IT Departments in modifying systems and interfaces that integrate with Inventory System [vendor: enter other p roposed services] Subtotal

P3.4 - Testing & Acceptance Services Pricing Table oSS = Number of on Site S aff Rate/md = Rate per Man-day Man days = Total Man-days required for th e activity Item Code

Activity Description Testing Services Acceptance Services [vendor: enter other p roposed services]

oSS

Rate /md

Man days

Total Charges

Remarks


P3.3 – Implementation Services Pricing Table oSS = Number of on Site Staff Rate/md = Rate per Man-day Man days = Total Man-days required for th e activity Activity Description

Item Code

oSS

Rate /md

Man days

Remarks

Total Charges

Supporting IT Departments in modifying systems and interfaces that integrate with Inventory System [vendor: enter other p roposed services] Subtotal

P3.4 - Testing & Acceptance Services Pricing Table oSS = Number of on Site S aff Rate/md = Rate per Man-day Man days = Total Man-days required for th e activity Activity Description

Item Code

oSS

Rate /md

Man days

Remarks

Total Charges

Testing Services Acceptance Services [vendor: enter other p roposed services] Subtotal



Page 42 of 49



P3.5 - Project Auditing, Quality Control & Assurance Services Pricing Table oSS = Number of on Site Staff Rate/md = Rate per Man-day Man days = Total Man-days required for th e activity Item Code


oSS

Rate /md

Man days

Remarks

Total Charges

Project Auditing, Quality Control & Assurance Services [vendor: enter other p roposed 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 Operations & Administration Development & Customization [vendor: enter other proposed services]

Skill-set

Rate /md

Rate /mm

Remarks


P3.5 - Project Auditing, Quality Control & Assurance Services Pricing Table oSS = Number of on Site Staff Rate/md = Rate per Man-day Man days = Total Man-days required for th e activity Activity Description

Item Code

oSS

Rate /md

Man days

Remarks

Total Charges

Project Auditing, Quality Control & Assurance Services [vendor: enter other p roposed services] Subtotal

P3.6 - Post-implementation On-site Support Services Pricing Table Rate/md = Rate per Man day Rate/mm = Rate per Man month Activity Description

Item Code

Skill-set

Rate /md

Rate /mm

Remarks

Operations & Administration Development & Customization [vendor: enter other proposed services]

P3.7 – Other Services Pricing Table oSS = Number of on Site Staff Rate/md = Rate per Man-day Man days = Total Man-days required for th e activity Activity Description

Item Code

oSS

Rate /md

Man days

Remarks

Total Charges

[vendor: enter other p roposed services] Subtotal IMF-EP RFP Final Version


Page 43 of 49


Request For Proposal Item Master File Enhancement Project Note: assigned staff from the vendor or its partners should spend sufficient time on skill development of assigned STC staff so that at th e 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 New Item Code Training Course Advanced Product Catalogue formal Knowledge Transfer for End-Users Advanced Product Catalogue formal Knowledge Transfer for Administrators and Support Staff [vendor: enter other recommended knowledge transfer]

Format classroom classroom classroom

Rate /Stud

Stud. /Class

Dur.

15 15 15

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.

Qty. 2 3 1

Total Charges

Request For Proposal Item Master File Enhancement Project Note: assigned staff from the vendor or its partners should spend sufficient time on skill development of assigned STC staff so that at th e 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 New Item Code Training Course Advanced Product Catalogue formal Knowledge Transfer for End-Users Advanced Product Catalogue formal Knowledge Transfer for Administrators and Support Staff [vendor: enter other recommended knowledge transfer]

Format

Rate /Stud

classroom classroom classroom

Stud. /Class

Dur.

15 15 15

Qty.

Total Charges

2 3 1

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 c onsiders 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 i n MS-Excel format and the entire response to the RFP in MS W ord Format or RTF. Other formats like pdf or p owerpoint will not be accepted. IMF-EP RFP Final Version


Page 44 of 49



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 f rom 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 c ontract to the lowest price offer.


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 f rom 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 c ontract to the lowest price offer. f)

Having received final vendor proposal submissions, it is STC’s 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 c ourse 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 f ully co-operate with other selected vendors to collectively fulfill the objectives and requirements for t he 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 STC’s 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.




Page 45 of 49

Request For Proposal Item Master File Enhancement Project 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 sof tware, 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 t his project.

s)

The laws and regulations of Saudi Arabia shall apply to awarded contracts.




Page 46 of 49


5 5.1

APPENDIX 2: INFORMATION ABOUT STC 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 it s 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 Endusers. In addition to the enterprise systems, there are Intranet; Internet & messaging systems and other specialized and departmental application in the S TC 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 I T infrastructure at STC.




Page 47 of 49


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 wit h some of these systems.

Major Application Systems Table System Group Business Support System (BSS) Customer Care & Billing (CC&B)

Centralized Operation & Maintenance (COM)

Mediation EDW

Components

Base Application

Platform/DBMS

Financial, Material, HR, Procurement (ERP) Customer Service, Provisioning, Billing, Usage Services for Wireline & Wireless OSS for Switching, Transport, Signaling & Wireless domains

Oracle Financials

IBM RS/6000 AIX, Oracle

IBM Integrated Customer Management System (ICMS)

IBM AS/400, DB2/400

Various applications from telecom equipment vendors (Lucent, Ericsson, Siemens)

Billing and Service Provisioning Enterprise Data Warehouse

COMPTEL MDS

HP9000 & Sun Servers with Oracle or Sybase or Informix HP9000 Servers Oracle DBMS NCR, Teradata (see STC ArchitectureRequirements document attached) Various

Teradata EDW

Other

Revenue Data mart, Call Various Center, GIS etc. 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.




Page 48 of 49

Stc Imf Copy

Recommend Documents