File No. J-17060/125/2015-DDU-GKY (342920) Government of India ...

File No. J-17060/125/2015-DDU-GKY (342920) Government of India,

Ministry of Rural Development Department of Rural Development

(DDU-GKY Division) 1st Floor, Western Wing, Thapar House, 124 Janpath, New Delhi 110 001, INDIA

Web: http://ddugky.gov.in/

Request for Expression of Interest from IT Firms for implementation of eKaushal

System for DDU-GKY Program of the Ministry of Rural Development

Country : India

Selection : Quality & Cost Based Selection as per IBRD Guidelines for selection of

Consultants

Name of Project: National Rural Livelihoods Project

Credit No : IDA 4978- IN

1. BACKGROUND

Ministry of Rural Development (MoRD), Government of India, is implementing a placement linked skill

development program called the DDU-GKY i.e. Deen Dayal Upadhyaya Grameen Kaushalya Yojana

(erstwhile Aajeevika Skills Program). DDU-GKY aims at alleviation of rural poverty through skill

development and regular job placement for poor rural youth in the age group of 15-35 years.

DDU-GKY is unique in its design under the National Rural Livelihood Mission (NRLM). It gives priority

to disadvantaged groups such as the SC/ ST/ women/ minorities and people with disability (PWD); it

focuses on market-led training programs to ensure employability of youth and it emphasizes on

partnership with private sector, NGOs, CBOs (Community Based Organization) and others for skilling

and placement delivery.

DDU-GKY is implemented through a 3 tier structure with MORD at the apex as the policy making,

facilitation and coordination agency; the State Skill Missions (SSMs) or State Rural Livelihood Missions

as the state level nodal implementation support agencies and Project Implementation Agencies (PIA)

http://ddugky.gov.in/

who serve as the skill and placement providers under the program. The DDU-GKY envisages a central

role for SSMs in driving the program delivery, its quality and outcomes.

For an effective management of implementation and operation of DDU-GKY, it is proposed to develop

a comprehensive IT system, called eKaushal system. eKaushal system is envisaged to: be available

across both web and mobile, capture data and documents related to program implementation and

operation, support evidence based decision and policy making and facilitate exchange of information

with all the key stakeholders and other skill development programs.

MoRD now intends to select and engage an IT firm (henceforth referred to as eKaushal System

Provider/ eKSP) to design, develop, and implement eKaushal System and support it post

implementation as per the terms and conditions agreed with the Ministry. The MoRD intends to roll-

out the system for users in a maximum period of 3-4 months post start of the project. Therefore, a firm

having a suitable IT application ready with it for deployment and needing very little customization shall

be the best fit. MoRD intends to get the proposed solution, of each vendor responding to this EOI,

evaluated by a committee of technical experts for suitability to MoRD and readiness for quick roll-out

on the basis of pre-defined parameters and methodology.

2. Broad Scope of Work for the eKaushal System Provider (eKSP)

The draft Terms of Reference (ToR) is attached in Annexure I.

The scope of the “bundled services” to be offered by the eKSP to DDU-GKY for implementing and O

& M of eKaushal system shall include the following:

1. Project planning and management

2. Requirement gathering

3. Solution Architecture preparation

4. Design, Development and Testing of eKaushal application including

i. Functional Requirement Specifications (FRS),

ii. Software Requirement Specifications (SRS),

iii. Software Design Document (SDD),

iv. eKaushal application development

v. Testing – Unit and Functional Tests, integration testing, performance testing, security

testing

vi. User Acceptance Testing (FAT/ UAT). MoRD may engage a 3rd party agency for this

purpose

5. Data Migration from legacy system/ other soft format and digitization from paper

6. Providing all requisite system software e.g. database server for running the eKaushal

application. Licenses for such software shall be taken in the name of MoRD

7. Hosting of eKaushal system at a Tier 3 (minimum) Data Center located in India. MoRD may

arrange its own data center, in that case eKSP must assist MoRD in assessing the options

8. eKSP shall recommend bandwidth and other system or network requirements for a smooth

usage of eKaushal system by stakeholders

9. Training and Change Management including hand-holding support at all stages

10. Installation and Commissioning of eKaushal system

11. Pilot testing/ implementation as per mutually agreed project plan

12. Final Acceptance Testing, MoRD may engage a 3rd party agency for this purpose

13. Support to 3rd party acceptance testing, audit, and certification

14. National Rollout and Go-Live

15. Full documentation pertaining to all of above using industry standards for Software

Development & Lifecycle Management and compliant with SEI-CMM

16. Post Implementation (Operational and Maintenance) Services covering the following:

i. Application and Software maintenance and support services (including Maintenance of

eKaushal Application Software and Release Management of subsequent versions) for

eKaushal system to meet the desired Service Levels

ii. Application functional support services including enhancements and changes subject

to mutually agreed change management process

iii. Annual Technical Support (ATS) for all the licensed software

iv. Continuous Improvement of eKaushal application

v. Regular back-up of data, application and documents as per agreed policy

vi. Regular DR/BCP drills and failover testing across both data centers

17. Exit Management and Transition at the end of Contract Period including action plan for

transition to NIC or other MoRD designated data center.

3. List of Modules and Functionalities Required in eKaushal System

The detail of modules and functionalities required in eKaushal system has been described in the ToR.

The following list provides a snapshot of modules and functionalities that will be built into the system.

The list below should be read together with the detailed list given at section 3.1 of the ToR. The list

given at section 3.1 of the ToR also needs to be submitted as a compliance sheet along with relevant

undertaking as specified in this document.

S.No. Module/ Functionality Group

1 User Management

2 Help desk support

3 PRN Registration and management

4 Proposal submission and management

5 Project Initiation

6 Training Center (TC) Management

7 Inspection Management (TC)

8 Candidate Management

9 Batch Management

10 Training Management

11 OJT Management

12 Assessment & Certification Management

13 Placement Management

14 Tracking

15 Fund Management

16 Performance management

17 Default Management

18 External Integration Management

4. SHORT LISTING CRITERIA

S. no. Criteria Evidence Required

I.

The Firm must be incorporated or registered in India under the Indian Companies Act, 1956/2013 and should have been in operation for at least 5 years as on 31st March 2015 in the space of software development, design and support.

- Certificate of Registration or

Incorporation.

- Memorandum of Association

- Annual statutory filings

II.

A Firm may associate with other firms for delivery of services but eligibility requirements will have to be fulfilled by the Prime bidder unless otherwise provided in this REOI document. Also, the bid shall be submitted by the Prime bidder and the contract shall be signed only with the Prime bidder. A Joint Venture (JV) is not allowed.

- Memorandum of Understanding between the prime bidder and its associate firm (if any) clearly demarcating the responsibilities in respect of eligibility and scope of work as required in this REOI document.

III.

The Firm or its associate firm for this assignment should have or should be ready to establish within 1 month of signing of contract, an office within the limits of National Capital Region (NCR) of Delhi with a team of IT employees capable of development, design, implementation and supporting an IT system similar to that required in this REOI/ ToR.

Undertaking from the Company Secretary or the Authorized Signatory.

IV. The Firm should have a valid ISO (9001) certification for software design and development.

Relevant certificate for ISO 9001.

V.

The Firm should have executed OR is executing, at least 2 software development and implementation projects in the Government sector during last 3 financial years (as on 31 March 2015) each with a

A copy of work order/ contract and letter of satisfactory delivery from client along with client contact details.

S. no. Criteria Evidence Required

value of not less than Rs. 50 lakhs. Each project quoted as reference should be at least 1 year old.

VI. The Firm should have a minimum turnover of Rs. 1.5 Crore averaged over the last three financial years as on 31 March 2015.

- Audited financial statements

- Provisional statement certified by CA for 2014-15 in case audited financial statement is not yet prepared.

VII.

The Firm should not be involved in any major litigation that may have an impact of affecting or compromising the delivery of services as required under this REOI.


VIII. The Firm should not be blacklisted by any Central Government Ministry or Department in India.


IX

The Firm or its associate firm for this assignment should have an IT application software readily configurable as per the requirements and features described in this REOI/ ToR and the firm should be ready to deploy the same in MoRD in 3 months post award of contract.

- Undertaking from the Company Secretary or the Authorized Signatory.

- Also, along with the undertaking, a compliance sheet should be submitted identifying each item in the list given under section 3.1 of the ToR as “available” or “not available” in respect of the application software proposed by the bidder.

X.

A firm that has worked in the past with DDU-GKY (erstwhile Aajeevika Skills) division shall not be allowed to participate in this tender process if their last work was found by the division to be incomplete and/ or unsatisfactory.

None

XI. All documents including all the pages of the proposal shall be signed by the duly authorized signatory. The signatory must be authorized through a board resolution or power of attorney from the board.

5. Shortlisting Process and Other Details

The attention of interested firms is drawn to paragraph 1.9 of the World Bank’s Guidelines: Selection

and Employment of Consultants [under IBRD Loans and IDA Credits & Grants] by World Bank Borrowers

(January 2011) (“Consultant Guidelines”), setting forth the World Bank’s policy on conflict of interest.

The EOI will result in shortlisting of firms who will be asked to participate in the RFP process. The

shortlisting process will include assessment of the IT application software proposed by each vendor

responding to this REOI on the basis of criteria specified by MoRD. The IT application software shall

be assessed for suitability to MoRD requirements and readiness for a quick rollout as specified in this

http://www.worldbank.org/html/opr/consult/contents.html

http://www.worldbank.org/html/opr/consult/contents.html

REOI document, by a committee of experts designated by MoRD. The bidder shall provide along with

EOI a brief user manual for its proposed application software which will be used by the expert

committee for assistance during assessment process. The user manual shall also include URL of the

proposed application software and relevant access credentials for the expert committee to login into

the software and test its functionalities and features. The committee shall access the software over

public internet from MoRD office in New Delhi from 7th day onwards after EOI submission date. The

bidder shall ensure availability of its software for the above process and MoRD shall not be held

responsible in any way for any gap in that. MoRD shall inform any change in the above plan to all

bidders responding to this REOI.

The RFP shall be shared with those bidders whose EOI response would be found complete and whose

application software would be found suitable and ready by the expert committee. An agency will

subsequently be selected in accordance with the Quality Cost Based Selection (QCBS) method set out

in the Consultant Guidelines stated above. Further information can be obtained through email addressed

to [email protected] with cc to [email protected] within 7 days of publication of

advertisement in newspaper. No queries will be entertained thereafter.

Expression of Interest must be delivered in a written/ printed form in hard copy and a CD. The envelope

and CD must be clearly superscripted as “Expression of Interest for Implementation of eKaushal

System for DDU-GKY Program of the Ministry of Rural Development” with name, address and

contact details of the firm. Also you are kindly requested to submit the filled up information in the formats

available in this document and deliver the same by Registered Post/ Speed Post/ Courier/ Hand latest

by 15.30 Hrs on 17th day of publishing of advertisement in newspaper at the following address:

Shri. Anil Subramaniam,

Deputy Secretary (Skills),

DDU-GKY Division

Ministry of Rural Development

Thapar House, 1st Floor, Western Wing,

124 Janpath, New Delhi 110 001, INDIA.

mailto:[email protected]

mailto:[email protected]

FORMATS FOR EOI RESPONSE

FORM I: COVERING LETTER

(Company letterhead)

[Date]

To,



DDU-GKY Division


Thapar House, 1st Floor, Western Wing,

124 Janpath,

New Delhi 110 001, INDIA.

Dear Sir,

Ref: Request for Expression of Interest from IT Firms for implementation of eKaushal System

for DDU-GKY Program of the Ministry of Rural Development

Having examined the Request for Expression of Interest (REOI), we, the undersigned, hereby submit

our response for selection of Agency to provide the Services to MoRD.

We attach hereto the response as required by the REOI.

Primary and Secondary contacts for our company are:

Primary Contact Secondary Contact

Name:

Title:

Company/ Organization Name:

Address:

Phone:

Mobile:

Fax:

E-mail:

We confirm that the information contained in this response or any part thereof, including its exhibits

and other documents and instruments delivered or to be delivered to MoRD is true, accurate, verifiable

and complete. This response includes all information necessary to ensure that the statements therein

do not in whole or in part mislead the department in its short-listing process.

We fully understand and agree to comply that on verification, if any of the information provided here is found to be misleading during the short listing process, we are liable to be dismissed from the selection process or termination of the contract during the project, if selected to do so.

We agree for unconditional acceptance of all the terms and conditions set out in the REOI document.

It is hereby confirmed that I/We are entitled to act on behalf of our company/ corporation/ firm/

organization and empowered to sign this document as well as such other documents, which may be

required in this connection.

Dated this Day of 2015

(Signature) (In the capacity of)

(Name)

Duly authorized to sign the Response for and on behalf of:

(Name and Address of Firm) Seal/Stamp of Firm

Witness Signature:

Witness Name:

Witness Address:

Encl: 1. Hard Copy of EOI along with enclosures duly filled in

2. Soft Copy (in CD) of EOI along with enclosures duly filled in

FORM II: CERTIFICATE

(Company letterhead)

[Date]

To,



DDU-GKY Division


1st Floor, Western Wing, Thapar House, 124 Janpath


Dear Sir,

Sub: CERTIFICATE AS TO AUTHORISED LEGAL SIGNATORIES

Ref: Request for Expression of Interest from IT Firms for implementation of eKaushal System for

DDU-GKY Program of the Ministry of Rural Development

I, …………………………………………...……, Director on the Board of Directors/ Trustees of

………….…….……………………….., certify that ………………………………………………… who

signed the above Bid is authorized to do so and bind the organization by authority of its board/

governing body.

(Signature)

Authorized Signatory name (Company Seal)

Designation

FORM III: GENERAL DETAILS OF THE ORGANIZATION

Details of the Organization

Name of organization

Nature of the legal status in India

Legal status reference details

Nature of business/ work in India

Date of Incorporation/ Registration

Date of Commencement of Business/ Work

Address of the Office in Delhi

Address of the Registered Office in India

PAN Number

Service Tax Number

Other Relevant Information

Mandatory Supporting Documents:

a) Certificate of Incorporation from Registrar Of Companies( ROC) / Registration

Certificate as applicable

b) Relevant sections of Memorandum of Association of the organization or filings to the

stock exchanges to indicate the nature of business of the organization

c) Any other specified in this document

FORM IV: UNDERTAKING ON MAJOR LITIGATION

(Organization letterhead)

[Date]

To,



DDU-GKY Division




Sub: Undertaking on Major Litigation



Sir,

I/We as potential bidders do hereby state that our company/ organization is not involved in any major

litigation which may impact the performance of the services to be provided by us, if selected, to be the

eKaushal System Provider for MoRD. We also state that our company has not been/ is not being sued

for any financial irregularity/embezzlement.

Yours faithfully,

(Signature)


Designation

FORM V: UNDERTAKING ON DELHI/ NCR OFFICE


[Date]

To,



DDU-GKY Division




Sub: Undertaking on Office in Delhi NCR



Sir,

I/We as potential bidders do hereby state that our company/ organization or our associate company

for this assignment has or shall establish, within 1 month of our signing of contract with DDU-GKY,

MoRD, an office in the National Capital Region of Delhi with a team of IT employees capable of

development, design, implementation and supporting an IT system similar to that required in this REOI/

ToR.

Yours faithfully,

(Signature)


Designation

FORM VI: UNDERTAKING ON BLACKLISTING


[Date]

To,



DDU-GKY Division




Sub: Undertaking on Blacklisting



Sir,

I/We as potential bidders do hereby state that our company/ organization is not blacklisted as of date

with any Central Government Ministry or Department in India.

Yours faithfully,

(Signature)


Designation

FORM VII: UNDERTAKING ON IT APPLICATION SOFTWARE


[Date]

To,



DDU-GKY Division




Sub: Undertaking on IT Application Software



Sir,

I/We as potential bidders do hereby state that our company/ organization or our associate company

for this assignment has an IT application software readily configurable catering to the requirements

and features described in this REOI and we shall be ready to deploy the same in MoRD in 3 months

post award of contract. We hereby agree to provide access to the above IT application software for

assessment during the bid process by the committee designated by MoRD for this purpose and we

shall provide all necessary support in that process.

Yours faithfully,

(Signature)


Designation

Enclosure: Compliance sheet for the list of functionalities given at section 3.1 of the ToR

ANNEXURE -I

TERMS OF REFERENCE

FOR SELECTION OF eKAUSHAL SYSTEM PROVIDER (eKSP) FOR

THE MINISTRY OF RURAL DEVELOPMENT

1.1 Background

Ministry of Rural Development (MoRD), Government of India, is implementing a placement linked skill

development program called the DDU-GKY i.e. Deen Dayal Upadhyaya Grameen Kaushalya Yojana (erstwhile

Aajeevika Skills Program). DDU-GKY aims at alleviation of rural poverty through skill development and regular

job placement for poor rural youth in the age group of 15-35 years.

DDU-GKY is unique in its design under the National Rural Livelihood Mission (NRLM). It gives priority to

disadvantaged groups such as the SC/ ST/ women/ minorities and people with disability (PWD); it focuses on

market-led training programs to ensure employability of youth and it emphasizes on partnership with private

sector, NGOs, CBOs (Community Based Organization) and others for skilling and placement delivery.

DDU-GKY is implemented through a 3 tier structure with MORD at the apex as the policy making, facilitation

and coordination agency; the State Skill Development Missions (SSMs) or State Rural Livelihood Missions as

the state level nodal implementation support agencies and Project Implementation Agencies (PIA) who serve

as the skill and placement providers under the program. The DDU-GKY envisages a central role for SSMs in

driving the program delivery, its quality and outcomes.

For an effective management of implementation and operation of DDU-GKY, it is proposed to develop a

comprehensive IT system, called eKaushal system. eKaushal system is envisaged to be available across both

web and mobile, capture data and documents related to program implementation and operation, support

evidence based decision and policy making and facilitate exchange of information with all the key stakeholders

and other skill development programs.

i. Key Features, Stakeholders, Roles and Responsibilities The key features of DDU-GKY program, the major stakeholders and their roles and responsibilities are given below. This document should be read together with the extant guidelines/ SOP/ notification issued by MoRD for complete and accurate understanding about the DDU-GKY program.

S.No. Feature Area / Stakeholders

Feature Details

1. Program Delivery Framework

A placement linked Skilling Program with a mandate for placement of a minimum of 75 % of the trained candidates at minimum remuneration of Rs 6000 pm.

Placement linked, market driven training for 3 months to 12 months.

Implemented through Project Implementation Agencies, who are funded a minimum of Rs 13696 to Rs 26602, depending upon the program duration.

Training to include basic IT, spoken English and soft skills apart from domain specific skills

Training to align with National Occupation Standards of NSDC/SSC and/or relevant standards of NCVT.

2. Target Beneficiaries

Poor (Below Poverty Line) Rural youth in 15-35 years age group

Upper age limit of 45 years in case of particularly Vulnerable Tribal Groups

Youth who have worked as labourers in MGNREGS work sites for at least 35 days in each of the previous three years and others from marginalized sections as may be defined by the program

33% candidates to be women

50% of target candidates from SC & ST families (nationally, as actual ratio will vary for each state depending on their percentage share in population)

15% to belong to minorities

3% to belong to differently abled (PWD)

3 Role of States The States are categorised into two – AAP (Annual Action Plan) States and YP (Yearly Plan) states.

Both AAP and YP States will be implementing DDU-GKY projects, however, the power to sanction projects will be devolved only to AAP States. They will do so according to an annual action plan approved by the EC in MoRD.

The EC of MORD will sanction projects from YP States based on the recommendation by CTSA and the State SRLM.

• Contribution of state share as per DDU-GKY guidelines • Establish skills team at State, district & sub-district level • Empanel Technical Support Agency (TSA) • Conduct Skill Gap Assessment • Preparation of Annual Action Plan (AAP) in case of AAP states and

Yearly Plan in case of YP states • Facilitation in mobilizing and identifying target groups - Identifying

districts and inviting PIAs • Appraisal of Project Proposals (AAP States)

– Seeking proposals by PIAs throughout the year – Score card to be used for appraising projects – Conduct Project Appraisal Committee(PAC) meeting and

approving the proposals • Monitoring (both AAP & YP states)

– Ensure that PIAs maintain quality of training infrastructure, content, human resources and delivery

– Conduct once in bi-monthly quality inspection/ audit of each training centre

– Ensure that PIA receives instalments within 30 days of becoming eligible

• Other activities – Establish Migration Support Centers – Establish Career Guidance Centres – Organize Job Melas – Establish DDU-GKY alumni program – Conduct training and capacity building programme for GP

• Helping PIAs bring all projects sanctioned under SGSY1 to an orderly

closure is the joint responsibility of both the state and central

governments 4. Role of District

Administration • Preparation of youth database at panchayat level. • Assist PIA in mobilization of rural candidates. • Identify and enable access to suitable public infrastructure in these districts for undertaking skilling projects. • Enable assistance for tracking of candidates who have been given placement through involvement of community based organizations (CBO), self-help groups (SHGs) or Panchayati Raj Institution (PRIs). • Monitoring of Projects and inspection of training centres.

5. Program Monitoring Stages

• Level -1 PIA o Weekly online monitoring of data uploaded daily by training centre o Aadhar authenticated Bio metric geo tagged time stamped attendance

of trainees and trainers o CCTV recording of class room proceedings o Monthly inspection of training centres by Q team of PIA

• Level -2 SRLM(with help of DRDA & State TSA) o Fortnightly issue of advisory to PIA based on online report of PIA Q-

teams o Bi- monthly inspection of training centers to verify Q team online

report o Only approved formats to be used.

• Level -3 MoRD (with help of Central TSA) o Fortnightly issue of advisory to SRLM based on inspection of SRLM

advisory and online report of PIA Q-teams o Periodic inspection of training centers to verify SRLM inspection

report and PIA Q team online report o Only approved formats to be used.

6. Program Monitoring Components

• Field appraisal of project proposals • Due diligence of proposed training centres before start of training • Inspection of training centres periodically after start of training • Beneficiary Monitoring

o UID / Aadhar enabled enrolment, attendance, and payments, o Placement tracking using pay-slips o Verification of bank accounts o Post placement tracking for one year

• Training Monitoring

1 These are multistate projects sanctioned by MoRD prior to DDU-GKY till 2013-14 under SGSY programme. They are

monitored directly by MoRD with the help of CTSAs with very little involvement of state governments. Going forward, no

new MSP will be sanctioned.

o Quality of trainers o Compliance of content with NCVT/ SSC standards o Training monitoring – English, Soft skills & Computer skills o Training monitoring – Domain skills

• Post-Training Monitoring o Counselling o Job Fairs o On the Job Training o Placement verification o Post placement support payment o Work readiness and employability centres o Migration Support Centres

• Fund Management o First instalment release o Claim for 2nd, 3rd and 4th instalments o Fund transfer, generation of challans/ orders, fund reconciliation

with fund management system/PFMS and Banks o Career Progression payment verification o One year retention payment verification

• Third party certification

7. Roles of PIA • Undertake Skill Gap Analysis (SGA) in the target area and trade • Identify Prospective Employers • Attend PIA training programs • Prepare and Submit Project Proposals

o Registration at Central level o Online submission of proposals o MOU to be signed within 24 hours of project being approved/

sanctioned • Establish Training Centers and get it certified by SRLM or CTSA

o Standards for physical infrastructure, furniture, facilities, training aids etc.

o Quality of trainers o Trainers competency to be verified by Q teams o Setting performance benchmarks and periodic assessments

• Course content to be certified o NCVT, SSC or others certified by MoRD o Certification of proprietary brands by MoRD

• Mobilisation, Counselling and selection of beneficiaries • Candidate mobilization through Panchayat saturation • Selection of candidates through Screening, Aptitude assessment, and

interest assessment • Trainee enrolment through parental consent • Ensuring Quality Training and Placement

o Use of geo-tagged, time stamped biometric attendance authenticated with Aadhar

o Daily online inventory check and reporting o Periodic quizzes and tests and publishing of results

o Install video audio recorders in each classroom and labs and upload clips

o Distance education / virtual training using live studio based broadcasts by master trainers

• Ensure timely payment of allowance to trainees and trainers • Compliance with Program guidelines and/ or Standard Operating

Procedure (SOP)

8 CTSA/ TSA Central and State Governments may engage TSAs in monitoring and quality control. TSAs will undertake: • Monitoring of training

o Due diligence of training centre o Inspection of training centre o Monitoring of video /audio clips and reports uploaded by PIA

• According approvals on behalf of MoRD or State • Recommending approvals to MoRD or State • Monitoring compliance of PIAs with the Program guidelines and/ or SOP • Compiling and submitting reports to MoRD/ State.

2.1 Overview of eKaushal system The eKaushal system would be a web-based solution to be used by all the stakeholders of DDU-GKY program including MoRD, States and Union territories to manage, generate MIS reports, assess status and perform other functions of the DDU-GKY program. eKaushal system would follow an n-tiered and modular architecture. The main functionality groups and their overview is given below. The eKSP may note that the functionality is dependent on various guidelines and associated documents and may require changes over the period of the contract to be in compliance with them. It is also noted that DDU-GKY is a new program with evolving processes and the eKSP is required to undertake detailed process mapping in consultation with key stakeholders to arrive at the FRS and SRS.

S.No. Functionality Group Description

1. PIA Registration 2 This module enables PIA to register Online and submit the Project proposal online, post registration. The Module will have all the validations built in place, to ensure the PIA’s submit the required mandatory information to enable approval or rejection of PIA registration. Upon approval, Permanent Registration Number (PRN) is assigned to the PIA.

2. Proposal Submission DDU-GKY program is designed in a PPP model. The implementation agencies are called the ‘Project Implementation Agency’ or PIA. The PIAs are responsible for carrying out skill gap assessment, enrollment, training, counselling, placement, post placement support, career progression and other services. The PIA will submit online proposals (with various supporting documents) through the eKaushal system which are either approved or rejected based on various factors including an online score card. A PIA may submit multiple proposals to DDU-GKY. The module should populate info from PIA registration modules.

2 Currently this module is developed and maintained by NIC. This will need to be incorporated in eKaushal.

3. Proposal Management

Upon submission of proposals by a PIA, initial screening of the proposals based on documents will be done by MoRD. Incomplete proposals are rejected and eligible proposals are taken up for a detailed desk appraisal by the Central Technical Support Agency (CTSA). CTSA will recommend the proposal based on the pre-determined set of parameters including field visit findings. All recommended proposals will be sent to respective SRLMs for their feedback. Upon the receipt of SRLM feedback, the recommended proposals are evaluated by Project Screening committee of MoRD and proposal cleared by the screening committee will be submitted to Empowered Committee for approval. A dashboard and MIS based decision making is expected to enable various committees in approving / rejecting the proposal. The results of committee meetings are to be captured in eKaushal system with additional follow-up alerts. eKaushal system shall enable approval of committee online if need be. Once the project is duly approved by the EC, sanction order needs to be generated by the eKaushal system. Based on the sanction order, and the submission of Prospective Work Schedule by the PIA, the draft MoU is generated in the eKaushal system which will be duly signed between the CTSA, SRLM and the PIA and later captured into eKaushal system.

4. Fund Management & Transactional Recording

The funds are released to the PIA in various tranches and after completion and verification of various milestones. The eKaushal system would thus need to track the current milestones, status of funds utilization, trigger alerts for funds release in an escalating manner , generate Utilization certificates and project ‘Statement of Accounts’ for each projects and in various groups. eKaushal will also generate pay invoices to push to external funds management system. The eKSP may note that eKaushal system is to integrate with PFMS / another Fund Management System as advised by MoRD. The eKSP shall also support/ facilitate and transition from one FMS to another. The PFMS systems is an online fund management, fund release and re-conciliation system used by various government agencies. It enables transfer of funds to various agencies and to beneficiary accounts and is inter-linked with the core banking system of over 90 banks all across India. The eKSP would thus need to study the PFMS/ other FMS system extensively for integration and to avoid duplicate functionality.

5. Monitoring and Quality Control

DDU-GKY has various 3rd party stakeholders and agencies for audit and monitoring of PIAs, their trainings, training centers, performance, training material, fund utilization, beneficiary status, beneficiary attendance, counseling, placement and salary monitoring and various other components. Moreover the monitoring requirements may differ between the States and between States and the Center. Monitoring components would need to integrate with location based components of GIS based geo-tagging and bio-metric based beneficiary tagging.

6. Beneficiary Management

The DDU-GKY program intends to perform mobilization of beneficiaries, tracking beneficiaries and their status and further use the information for various value-added services that may be provided over a period of time.

Thus, a module dedicated to mobilization, tracking beneficiaries and beneficiary data is required and which would leverage the UID number/ SECC –TIN / NPR-TIN (National Population Registry data of Census department, GOI) as key identifiers. Additional information such as training details, assessment & certification details, employment details, wage payment details, progress of trainee’s overtime would also need to be tracked through the eKaushal system for a minimum period of 1 year after completion of training.

7. Training Center Management

DDU-GKY prescribe due diligence for infrastructure at training center before commencement of the training. Every Training Center requires have certain facility as per check list in the guidelines and the Standard Operating Procedures (SOP). Module includes allocation of Class room Management, Aadhar authenticated Biometric Attendance for Students and complete tracking of the Academics for every student. Regular inspection of the training centers by the Q team of PIA, SRLMs and CTSA have to be captured as per the extant guidelines and SOP.

8. Trainer’s Management

DDU-GKY emphasize on quality of training imparted, in which Trainers, Master Trainer would play a significant role. This module would maintain central data base of trainers across the PIAs, trades and also monitor their performance through grading and integrating with other modules.

9. Learning & Training Management

The learning management functionality would include management of the learning resources of the PIAs including – Trainings, Training Centers, Placements, Counseling etc. and various artifacts and would include data elements on learning efficacy and effectiveness with the ultimate objective being to improve the quality of the learnings and by increasing the capabilities of the PIAs. It will also include open source / other learning material that can facilitate self-paced learning for certification.

10. External System Integration

The eKaushal system must effectively interface with various external systems for data exchange and fund management purposes. The key set of external system integrations envisaged are:

PFMS/ Other FMS system as described earlier. The eKSP shall integrate with one (1) system and support any change/facilitation if required

State systems – Various states are in advanced stages of implementation/ operation. eKaushal system would need to interface with skill management systems being used in few states including Andhra Pradesh, Gujarat, Odisha, Rajasthan, J&K and Bihar for data exchange and MIS updation.

BPL/ SECC/ NPR 3– eKaushal system may need to interface with State/ Central level SECC and NPR data for beneficiary validations. The socio-economic caste census (SECC) data is eventually to be used in place of BPL data for identification of beneficiaries. eKaushal system processes would need to validate against SECC data, as a part of the MIS.

3 http://secc.gov.in/welcome

http://secc.gov.in/welcome

Aadhar / UID4 - Aadhar is a bio-metric enabled identification system providing a unique ID number to each enrolled individual. The eKaushal system would need to integrate with Aadhar particularly for beneficiary identification and attendance. Additional details about Aadhar, its authentication framework, e-KYC can be found in http://www.uidai.gov.in. The consultation with UIDAI/ RGI in particular will focus on understanding as how eKaushal system will interface with platform of UIDAI/National Population Register for all authentication and related activities. Biometric attendance taken at training center of PIAs will have to be authenticated with the server of UIDAI.

PIA Websites – The eKaushal system shall integrate either with PIA websites for data upload or shall enable PIAs to enter training and other related data directly on the eKaushal system.

Monster.com/ Other Job Sites – eKaushal shall interface with jobs sites as decided by DDU-GKY. This shall be used for facilitating placement of DDU-GKY beneficiaries.

NSDC and NSDA guidelines and systems for training standards, and assessment & certification. eKaushal system shall integrate with or provide access to Sector Skill Councils for carrying out assessment and certification of DDU-GKY trainees.

NCVT / SDIs being implemented by DGET - eKaushal system shall integrate with or provide access to NCVT/ DGET for carrying out assessment and certification of DDU-GKY trainees.

DDU-GKY envisages secure certification for all its graduates. eKaushal system should have facility to integrate with Pitney Bowes secure certification system.

MGNREGA system would need to be integrated for exchange of data e.g. related to beneficiaries.

11. Labour Market Information systems

This is being developed by National Skill Development Authority. eKaushal system as well as MOLE (Ministry of Labor and Employment) will have functionality to utilize the system seamlessly for relevant data exchange.

12. Rating of all stakeholders engaged in implementations

DDU-GKY envisage a system which allows for objective reasons for rating for following entities engaged in implementation

• PIAs • Training Centers • Employers • Trainers

The eKSP may note that above functionalities are not stand alone and there is significant interaction across the various functionalities for operational management of the project and MIS reporting. It may also be noted that

4 http://uidai.gov.in/

http://www.uidai.gov.in/

http://uidai.gov.in/

the above is an indicative (and not exhaustive) high level description of the required functionality. Further, the functionalities will have to be built in compliance with the guidelines/ SOP issued by the Ministry/ department/ division, as amended from time to time. This will be subject to application change management process as applicable and agreed between MoRD and the agency. The requirements and specifications described under different sections of the RFP shall be read together and collated appropriately by the bidder/ eKSP to arrive at the complete set. Any apparent conflict across different sections of the RFP shall be brought to the notice of MoRD for clarification and interpretation, during bid process or after start of the project. The bidder/ eKSP shall not assume any interpretation in such a case and MoRD’s interpretation shall be final and binding on the bidder/ eKSP at all stages of the bid process/ project.

3.1 List of Modules and Functionalities required in eKaushal system

S.No. Module/ Functionality Important note for reference Available (YES/NO)

1 User Management

A Role Creation by MoRD MoRD Should be able to create roles which can be assigned to users as per process.

B Role Approval by MoRD

C User Creation by respective stakeholders

Each Stakeholder should be able to manage the users for themselves. Ring fencing Concept should be addressed.

D Assignment of Location to users by respective stakeholders

Each User should be able to allocate a location (district wise) based on the sanctioned Project's State.

E Password Management Provision for "forget password", change password etc

F Lock / Unlock User Admin level provision for pre-defined stakeholders

2 Help desk support

A Issue logging Online Provision for registering the issues related to e-Kaushal by all stakeholders and tracking the status of all issues.

B Issue resolution

C MIS Report (Help desk support)

3 PRN Registration and management

A Registration

As per SOP/ guidelines/ notification/ processes defined by DDU-GKY

B L1 Verification

C L2 Verification

D Approval & PRN generation

E MIS Report (PRN Registration)

F Change in allotted PRN data

4 Proposal submission and management

A New Proposal submission


B Desk Appraisal - L1 Verification

C Detailed Desk Appraisal

D Field Appraisal by CTSA

E Recommendation by CTSA

F Approval of Recommendation by CTSA

G EC Agenda Preparation

H EC Approval Recording

I EC Approval Authorization

J IFD Sanction/ Concurrence

K Sanction order generation

L Project Closure

M MIS Reports (Proposal Management)

N

Change in Proposal Data (including pre as well as post EC approval ) Change Proposal Form Data - EC/Notifications

Changes in a Project can happen before or after the sanctioning of Project by MoRD.

O Approval of Change in Proposal Form Data - EC/Notifications

P Project Termination (foreclosure)

In case of Foreclosure, system should facilitate handling of on-going operations in the Project so as to minimize loss to the beneficiary group.

Q Project Update To record the timelines and documents of all sanctioned projects

5 Project Initiation

A Prospective Work schedule submission (PIA)


B Prospective Work schedule Approval by CTSA

System should have provision for Approval/Rejection/Allow Modification by PIA before approving.

C MoU Printing


D Project Commencement order generation

E Project Execution Readiness Submission by PIA

F Project Execution Readiness Approval by CTSA

System should have provision for Approval/Rejection/Allow Modification by PIA before approving. Additionally, there should be option to partially approve it based on various parameters of the Readiness Form

G Mobilisation plan submission (GP Saturation)


H Mobilisation plan Approval by State (GP Saturation)

I Revision of Mobilization Plan (GP Saturation)

J Revised Mobilisation plan Approval by State (GP Saturation)

K MIS Reports (GP Saturation Reports)

L MIS Reports (Project Plan)

6 Training Centre Management

A PIA Human Resource Registration As per SOP/ guidelines/ notification/ processes defined by DDU-GKY

B HR information Updation - Edit Profile

D HR Profile Print

C De-Register/Allocate Human Resource

System should have provision for mapping or de-mapping a Human Resource at any given point of time.

D Training Centre Registration

The system should enable recording of civil infrastructure of a training center independent of a project sanctioned to a PIA

E Residential Facility Registration

The system should enable recording of civil infrastructure of a residential facility independent of a project sanctioned to a PIA

F Training Centre Allocation to a project

The system should enable PIAs to map registered training centers without or with one or more residential facilities and human resources associated to the training center for due diligence by Q team.

G Training Centre Due-Diligence by PIA Q team (Online Mode)


H Training Centre Due-Diligence by PIA Q team (Offline Mode)

I Training Centre Due-Diligence - Approval by CTSA / SRLM (Online)

J Training Centre Due-Diligence - Approval by CTSA / SRLM (Compatible with tab and with offline capability)

K Residential Facility Updation

L Training Centre Facility Upgradation

The system should allow addition of civil infrastructure as well as proposal for new trades.

M Closure of Residential Facility

The system should allow closure of a residential facility without affecting the status of a training center.

N Training Centre Facility Update (daily failure report)


O CCTV footage upload by PIA on a sample basis

P Review of CCTV footage by CTSA/SRLM

Q Termination of Training Centre

System should facilitate handling of on-going operations in the Training centre so as to minimize loss to the beneficiary group.

R Training Centre Status Update

System should include option to mark a TC as 'Inactive' as an intermediate status and again activate it as per the requirement of PIA. This should ensure all entities associated with Training Centre are handled before marking it as 'Inactive'.

S Training Centre locator - Google Map

This should provide recording and display of geo coordinates of training center

T MIS Reports (Training Centre Management)

This should include Fortnightly Daily Facility Update Report as per SoP

7 Inspection Management (TC)

A Sampling for TC inspection

Sampling should consider a Batch status before sampling the candidates from it, and should follow SoP.

B Training Centre Inspection (Online)

This should include option to generate Inspection Form with pre-filled sampled data, as well as completely filled-in Inspection form data (along with PRINT option)

C Training Centre Inspection (Compatible with tab and with offline capability)

This should include option to generate Inspection Form with pre-filled sampled data, as well as completely filled-in Inspection form data (along with PRINT option)

D Issue of Advisories

The system should allow issue of advisories as a part of inspection process.

E Compliance to Advisories by PIA


F Closure of Previous Advisories in subsequent Inspections

G Raise Default for Non Compliance

H Approval of Default for Non Compliance

I MIS Reports (INSPECTION)

8 Candidate Management

A Candidate Registration – By candidate System should maintain Candidate Pool at Global as well as PIA level.

B Candidate Registration - Facilitated

System should allow registration of candidates through authorized centers and not limited to PIAs only.

C Candidate Information Updation


D Candidate Authorization

E Candidate Profile print

F Candidate Screening & Selection

G MIS Reports (Candidate Management)

9 Batch Management

A Batch Creation

Batch Creation should adhere to the Batch size guideline as per the associated Classroom's Dimension

B Batch Modification The system should allow modification in batches in accordance to SOP

C Extension of Freeze Date by TSA/SRLM


D Batch Closure – Classroom/ OJT

E Batch Termination – Q Team/ SRLM/ TSA

F Transfer of Batches to other Centres

G MIS Reports (Batch Management)

10 Training Management

A Training Curriculum

System should have provision to define Training Curriculum as per the structure followed by NCVT/SSC.

B Creation of Training Plan


C Updation of training Plan

D Search/ Selection/ Transfer of Candidate

E Transfer confirmation

F Enrolment of a candidate

G De-enrolment of candidate from a batch (within freeze period)

H Trainee Information Update

I Manual Drop-out of trainees

J Manual Attendance - Trainee

K Manual Attendance - Trainer

L Upload of Attendance - Batch wise

M Aadhar authenticated Biometric Attendance for Trainee

N Aadhar authenticated Biometric Attendance for Trainer

O Integration with Aadhar system

P MIS Reports (Batch Management)

11 OJT Management

A OJT Plan submission As per SOP/ guidelines/ notification/ processes defined by DDU-GKY

B OJT Attendance

C OJT Completion Updation

System should have provision for marking OJT completion status Batch as well as Candidate wise.

D MIS Reports (OJT Management) As per SOP/ guidelines/ notification/ processes defined by DDU-GKY

12 Assessment & Certification Management

A (PIA Interface)

i. Internal Assessment Marks Updation


ii. External Assessment Plan submission

iii. Authorization of external assessment plan

iv. Change request for External Assessment plan

v. Re-evaluation Request of External Assessment

B (Certifying Agency

Interface)

i. Empanelment of Assessing Agency

ii. De-listing of Assessing Agency

iii. Approval of Assessing Agency Allocation

iv. Approval of change request

v. Approval of External Assessment Results

C (Assessing Agency

Interface)

i. Empanelment of Assessors

ii. Delisting of Assessors

iii. Approval of Assessors’ Allocation

iv. Allocation of Assessor for Re-Evaluation

v. Recommendation of External Assessment Results

D (Assessor Interface)

i.Updation of conduct of Assessment

ii. Updation of External Assessment marks

iii. Updation of Re-evaluation status

iv. Updation of Re-Evaluation Marks

E Independent assessor registration

F Approval of assessor by SRLM/ MoRD

G Certificate updation or generation through Pitney Bowes

H Integration with SSC (NSDC)

I Integration with NCVT (DGET)

J MIS Reports (Assessment Management)

K Recording Assessment of candidates The system should be able to follow the process defined in SOP

L Recording Certification of candidates The system should be able to follow the process defined in SOP

13 Placement Management

A Employer database creation


B Employer data Verification by CTSA

C Employer Work Place database creation

D Employer Work Place data Verification by CTSA

E Placement including re-employment

F Retention including monthly update and documentation

The system should enable recording of placement related transactions as defined in SOP

G Separation from employment


H Employer Work Place transfers

I Foreign Placement

J MIS Reports (Placement Management)

K Integration with job portal

14 Tracking

A Sampling for Tracking

B Recording Tracking activities

Candidate should be tracked for Placement for a duration of one year, and each month's placement data should be recorded.

C Tracking Masters - parameters (creating objective parameters)

The masters should be designed to enable objective analysis of tracking activities and record objective observations of the tracker.

D MIS Reports (Post Placement tracking) As per SOP/ guidelines/ notification/ processes defined by DDU-GKY

15 Fund Management

A (Candidate

Entitlements)

i. Travel & Food disbursement charges for Non-residential candidates As per SOP/ guidelines/ notification/

processes defined by DDU-GKY

ii. Uniform distribution

iii. Post-Placement support

The system should be able to distinguish the location of placement and ascertain eligibility of PPS to candidates.

B Release of Funds to CTSA from MoRD and States (YP)


C Release of Instalments to PIAs by CTSAs/ States (AAP)

D Integration with Public Finance Management system

E MIS Reports on Candidate Entitlements

16 Performance management

A Project Management Dashboard for PIA


B Project Management Dashboard for CTSA/ SRLM

C MoRD

D TSA

E SRLM

F PIA

G Project

H Training centre

I Employers

17 Default Management

A Generation of alerts (against milestones including PPWS)

The system should generate alerts for defined milestones to enable stakeholders to monitor the events.

B Issue of notice to PIA – Yellow alert

Each Notice issued should be mapped against a default raised in a Project. System should have provision to auto-flag the various defaults defined in SoP on User Dashboard.

C Issue of notice to PIA – Red alert


D Issue of notice to PIA – reminder

E Reply to notices by PIA

F Intimation to MoRD (YP)

G Issue of show cause notice to PIA

H Disposal of notice The system should generate history of defaults to enabale disposal of notice and penal action.

I Penal action against PIA

18 External Integration Management

A SRLM

Various states are in advanced stages of implementation/ operation. eKaushal system would need to interface with skill management systems being used in few states including Andhra Pradesh, Gujarat, Odisha, Rajasthan, J&K and Bihar for data exchange and MIS updation

B PIA

The eKaushal system shall integrate either with PIA websites for data upload or shall enable PIAs to enter training and other related data directly on the eKaushal system

D Labour market information system (LMIS ) of NSDA

This is being developed by National Skill Development Authority. eKaushal system will have functionality to utilize the system seamlessly for relevant data exchange

E PAN (for validation) NSDL database for PAN data verification during PRN / Proposal

F CIBIL (for validation)

Checking CIBIL score of PIA / authorised persons during Proposal Management

G MCA 21 (for validation)

Verifying with Ministry of Corporate Affairs database for the PIAs during Proposal management

H Ministry of Overseas Indian Affairs (for validation)

Verifying with Ministry of Overseas Indian Affairs database for the PIAs during Proposal management

I MGNREGA system

This system is implemented by MoRD for managing implementation and monitoring of MGNREGA. Integration will be required for exchange of data and verification e.g. of beneficiaries.

J SMS gateway For communicating the information to the concerned stakeholders triggered by pre-defined set of events

K Email system

4.1 Summary Scope of Work for Implementation Agency

The scope of the “bundled services” to be offered by the eKSP to DDU-GKY for implementing and O & M of eKaushal system shall include the following:

1. Project planning and management in consultation with and concurrence of MoRD including i. Governance structure

ii. Approach and methodology iii. Resources being deployed iv. Schedule of activities v. Allocation of resources and time to project tasks

vi. Issue escalation and resolution mechanism vii. Risks and proposed risk mitigation

viii. Any other relevant item 2. Requirement gathering including

i. Comprehensive Stakeholder assessment – Identify and define user requirements ii. Assessment of existing systems/ data/ templates/ forms/ reports

iii. Assessment of State Skilling Solutions iv. Requirement gathering from line ministries v. Interface requirement gathering from UIDAI / SECC / NPR/ NIC/ Job portal (e.g. Monster)/ PIA’s

websites and others as indicated in this ToR vi. Integration requirement gathering from eFMS/ PFMS

vii. Assessment with donor agencies, if any required. 3. Solution Architecture document preparation:- Business Processes of DDU-GKY and High-level

Architecture of eKaushal system 4. Design, Development and Testing of eKaushal application including

i. Functional Requirement Specifications (FRS), ii. Software Requirement Specifications (SRS),

iii. Software Design Document (SDD), iv. eKaushal application development v. Testing – Unit and Functional Tests, integration testing, performance testing, security testing

vi. Final or User Acceptance Testing (FAT/ UAT) vii. Pilot testing in live environment

5. Data Migration from legacy system / other soft format and digitization from paper including data of SGSY projects

6. Hosting of eKaushal system at a Tier 3 (minimum) Data Center located in India 7. eKSP shall recommend all the stakeholders about sufficient bandwidth and other system or network

requirements for a smooth usage of eKaushal system 8. Training and Change Management including hand-holding support at all stages 9. Installation and Commissioning of eKaushal system 10. Pilot implementation as per mutually agreed project plan 11. Final Acceptance Testing, MoRD may engage a 3rd party agency for this purpose 12. Support to 3rd party acceptance testing, audit, and certification. 3rd party agency shall be engaged by

MoRD 13. National Rollout and Go-Live 14. Full documentation pertaining to all of above using industry standards for Software Development &

Lifecycle Management and compliant with SEI-CMM 15. Post Implementation (Operational and Maintenance) Services covering the following:

i. Application and Software maintenance and support services (including Maintenance of eKaushal Application Software and Release Management of subsequent versions) for eKaushal system to meet the desired Service Levels

ii. Application functional support services including enhancements and changes subject to mutually agreed change management process

iii. Annual Technical Support (ATS) for all the licensed software iv. Continuous Improvement of eKaushal application v. Regular back-up of data, application and documents as per agreed policy

vi. Regular DR/BCP drills and failover testing across both data centers 16. Exit Management and Transition at the end of Contract Period including action plan for transition to

NIC or other MoRD designated data center.

5.1 Detailed Scope of Work for the Implementation Agency The following sections detail out few aspects of the scope of work to be performed by the eKSP. The eKSP shall be responsible for the successful completion / execution of the activities listed in the following paragraphs, as well as implementation of the proposed solution, as specified in this TOR. Broadly the Scope of Work for the eKSP is as follows: 1. Project planning and management

The success of implementation of eKaushal system depends on all the stakeholders. The eKSP is required to design and implement a comprehensive and effective project management methodology together with efficient & reliable tools and structures.

a) Project Management Office -The eKSP shall setup a Project Management Office (PMO) to manage the implementation and rollout of eKaushal system. The requirements of the PMO are provided below:

i. The PMO will be an operational PMO which shall provide oversight and management of the all activities, take implementation decisions, research best practices and provide guidance & co-ordination to all stakeholders.

ii. The PMO shall be the primary vehicle for communication between all the stakeholders and the eKSP.

iii. The PMO shall follow industry standards of Project Management e.g. PMBOK or PRINCE2

iv. The PMO shall be effectively transition to DDU-GKY upon completion of the contract for continued growth, management and operation of eKaushal system and other systems

v. The PMO may include members deployed by DDU-GKY/ MoRD

vi. Senior level personnel of the eKSP shall operate as part of the PMO.

b) Scope of Project Management Activities- As part of the Project Management, eKSP shall be responsible for the following:

i. Create an organized set of activities for the project with activities, timelines and resource plans and continuously monitor the schedule and activities

ii. Coordinate and collaborate with all stakeholders

iii. Establish and measure resource assignments and responsibilities

iv. Construct a detailed project plan schedule including milestones

v. Measure project baseline, deviations, deadlines and performance objectives

vi. Communicate the project plan to stakeholders with meaningful reports

vii. Detect problems and inconsistencies in the plan and take corrective actions

viii. Project management reporting shall include – results accomplished during the period, cumulative deviations from plan and schedule, corrective actions taken, plan revisions, outstanding issues and expected actionable. Additionally change control, issue tracking and risk assessment and mitigation shall be a part of the project management activities. During the project implementation phase the reporting will be at least bi-weekly.

ix. The performance of PMO and the project management activities shall be reviewed by Project Director and other committees on a regular basis

c) Maintain Project Management, Configuration Management and Issue Tracker Tools

Project Management Tool: To have an effective project management system in place, it is necessary for the eKSP to use a Project Management Information System (PMIS). The eKSP shall address at the minimum the following using PMIS:

a. The PMIS shall be web-accessible over the internet

b. The eKSP shall keep the project plan and all related artifacts up-to-date during the course of the project.

c. The Project Plan and related documents shall be accessible to DDU-GKY personnel over the web

d. The eKSP shall provide a 1 day workshop on tools installed for Project Management

e. In order to help with the project management, the eKSP shall use a suitable standard, proven off-the-shelf project management tool

f. The tool shall provide the dashboard view of the progress on project milestones to DDU-GKY and other stakeholders.

ii. Configuration Management Tool: The eKSP shall keep all project documents up-to-date during the course of the project. In order to help with the version/configuration management for all documents (including source code and all other project artifacts), the eKSP shall use a suitable standard, proven off-the-shelf configuration management tool (preferably with unrestricted redistribution licenses). The eKSP shall install the configuration management software at the beginning of the project. The configuration management tool shall be accessible to DDU-GKY personnel over a web interface.

iii. Issue Tracker: The eKSP shall employ a suitable and proven tool for tracking issues (preferably with unrestricted redistribution licenses) through the execution of the project. The eKSP shall enable DDU-GKY users to access and use the same over a web interface.

iv. The eKSP shall provide the required infrastructure (software, hardware) for Project Management Tool, Configuration Management Tool and Issue Tracker tool and maintain the same through the duration of the project. All the data shall be passed on to DDU-GKY at the closure of the contract as a part of knowledge-transfer.

v. The eKSP will setup an online repository on PMIS / Configuration Management Tool for providing centralized access to all project documents including manuals and other materials. The online repository would be maintained by the eKSP through the engagement period.

2. Requirement gathering and As-Is assessment a. Assessment of State Skilling Solutions - The eKSP will lead consultations with the States and Private

Companies engaged in skilling solutions where skill based MIS are already in place. Skills related MIS are already used in Andhra Pradesh, Telangana, Gujarat, Odisha, Rajasthan, J&K, Bihar and Uttar Pradesh whereas it is under development in Kerala and Tamil Nadu. eKSP will require to check the list of such states at the beginning of project and shall plan accordingly.

b. Skilling application used by private sector - There are large private agencies who are MoRD or NSDC training partners where ERP based MIS are in place, needed to be in studied. These consultations will specifically determine what ICT systems are in place and collect all details of the hardware, software application process workflows service level. Technical details, interface points etc. Also engage with all relevant internal and external ICT vendors to understand the existing and mandatory policies, procedures and standards that will affect the design and development.

c. Requirement gathering from line ministries - The eKSP will gather requirements from all internal and external stakeholders including other line ministries identified by Skills Division of MoRD.

d. Interface requirement gathering from UIDAI - The consultation with UIDAI in particular will focus on understanding as to how the eKaushal system will interface with platform of UIDAI/National Population Register for authentication and other activities.

e. Integration requirement gathering from PFMS/ other FMS/ other systems – The eKSP shall conduct consultation with NIC, Comptroller General of Accounts (CGA), and other system owners/ implementation agencies to understand the various interface and integration requirements

f. Stakeholder assessment – The eKSP shall have discussion at various levels in DDU-GKY organization at the central, state and sub-state level to understand the requirements from the end-users. Consultations would need to take place with all the stakeholders including beneficiaries, PIAs, TSA, SRLMs, Approval agencies and monitoring agencies

g. Data Center / Backup Options h. O&M Plan, Timelines for Pilot and Rollout

i. Service Levels and measurement methodology j. State Level and Central Training needs

3. High-Level Architecture Document – Based on the various discussion and consultations, the eKSP shall

provide the following in the High-Level Architecture document: a. High-level Architecture at the Center and State levels including software, hardware, networking

and other requirements b. Assessment and Requirements from each of the studies done in (2 ) above. c. User Assessment – Number of users, frequency of use, duration of use, estimated number of user-

interfaces per user type, data uploading/ exchanging requirements – size, type etc. d. Module, Sub-Module, Business Processes design and Requirements mapping e. Methodology for integration with each of the external systems f. System Software List g. Estimated Data Requirements, Requirements for analytics, Storage

4. Design, Development and Implementation of eKaushal Application

a. Development of Functional Requirement Specification (FRS) and System Requirement Specifications (SRS) eKSP shall develop the complete FRS and SRS as per the requirements stated in the TOR and based on their study and analysis in (2) and (3) above. The eKSP is expected to get sign-off on the FRS & SRS from DDU-GKY.

b. Implementation of eKaushal system The implementation should incorporate the following (but not limited to):

i. Implementation of all the modules as per this TOR refined by the FRS and SRS ii. Implementation of the interfaces required with the external system.

iii. Develop User Interface (UI) as prototype and demonstrate the UI to respective stake holders and get the final approval from them.

iv. Implementation of the eKaushal Portal v. Integration with SMS Gateway and email system used/ provided by MoRD for sending alerts /

notices from eKaushal system vi. Design shall articulate module and sub-module level interfaces and traceability matrix shall be

defined to ensure all the functionality described in the TOR and FRS are covered. vii. Establishing a data quality, data management, data security and data integrity framework

covering modelling of existing data defining the quality attributes evaluating existing data

quality levels determine data quality priorities and identify remedies.

viii. The implementation shall also include presentations in the form of dummy screens that is

user–friendly so that user can easily understand and validate the FRS.

c. Testing – Unit and Functional Test

The eKSP will perform the necessary Unit and Functional Tests. The Unit and Functional test reports will need to be signed-off by DDU-GKY.

d. Continuous Improvement of eKaushal Application The eKSP shall initiate processes for the continuous improvement of the eKaushal application and databases. These processes would need to be formally recorded in the form of a roadmap with

timelines and execution strategy and would become a part of the project management schedule. These changes will also be subject to the applicable and agreed system/ application change management process.

5. Installation and Commissioning of eKaushal system

The eKSP through the PMO shall co-ordinate with DDU-GKY, for completion of installation and commissioning of eKaushal solution and the system software. eKSP shall be responsible for ensuring operational readiness for eKaushal system. The report of the installation and commissioning inspection shall be signed by both eKSP and DDU-GKY, which shall be part of the Final Acceptance Test (FAT).

6. Implementing Non-Functional and Technical Enhancements

The eKSP shall, based on the design, expected number of users, expected concurrency, number of transactions/ reports generated per day / hour, peak times and other factors implement the non-functional requirements – availability, uptime, response time and back-up strategy.

7. Data Migration

The eKSP would migrate or digitize the legacy data in soft or paper form. The legacy data includes SGSY projects, YP projects (sanctioned by MoRD) and the projects sanctioned by AAP states. The migrated data/ documents shall be used in production database for integration as well as in development/ staging environment for end-to-end testing of the application. The eKSP would need to create strategies for ensuring data updates, modifications, validations and changes including creation of necessary interfaces to ensure data corrections. 8. End-to-end testing of the eKaushal application

The eKSP would perform end-to-end testing of the entire eKaushal system. The test cases to be covered should include all the functionality, use cases, real-time simulations, built in checks and alerts, workflows, performance testing and integration testing etc. The integration as well as performance & security testing report would need to be signed-off by DDU-GKY before Pilot. It may also be noted that functional tests will follow UAT, pilot in Live, change implementation on the basis of learning from pilot, re-testing and final roll-out i.e. Go-Live. 9. Pilot

The eKSP is responsible for completing pilot for the complete end-to-end system in mutually agreed set of states (2 AAP states and 2 – YP states). The States shall be decided after consultation with and approval of DDU-GKY. During the pilot all the feedback, and bugs shall be captured systematically by the eKSP and resolution of bugs/ issues and incorporation of the feedback/ changes shall be completed, tested and approved by DDU-GKY before releasing the application for the next stage. The eKSP is expected to continue with remaining development, data uploading/ modifications and application changes during the Pilot phase and plan for full rollout.

10. FAT

The system shall be declared “Go-Live” after completion of the Final Acceptance Test (FAT) and approved by DDU-GKY. eKSP is responsible for developing the FAT Plan and approval from DDU-GKY before starting the FAT. The FAT plan shall include the following (but not limited to):

a. Test cases demonstrating all functionality and system requirements stated in the SRS.

b. Test cases and procedures to demonstrate integrated functioning of system components and sub-components of the TOR including external systems

c. Test procedure to demonstrate high availability, performance, manageability and security of the ICT infrastructure deployed

d. Test procedure to demonstrate the processes and tools deployed for measurement and enforcement of all the SLA parameters.

11. Training and Change Management

eKSP shall provide training to the department end users including CTSA, PIAs and state officials. eKSP shall setup and perform training to the concerned officials before the pilot and national rollout as well as repeat training after rollout as mutually agreed. Training should cover all the end-user functionality covered in the eKaushal application. Training to state officials shall be conducted in the respective State headquarters (SHQ). Training would need to be scheduled in advance in consultation with DDU-GKY / state including no. of batches and batch size. eKSP shall be responsible for trainers, training content and training aids. However, logistics for trainees including venue related arrangements shall be provided by MoRD/ state or respective stakeholder as advised by eKSP in advance and as decided by MoRD. The training strategy, plan and training content shall be finalized in consultation with and approval of MoRD. All training material developed by the eKSP shall be owned by DDU-GKY. Training material to be provided shall include:

Handouts

PowerPoint Slides

Segregation of content on user role as well as by functionality

Computer-Based-Training (CBT) – Material to be provided in softcopy format and also loaded and operationalized through eKaushal portal

CBT shall be usable online or should be downloadable

CBT shall use text, voice-over, animation/ graphics, screen shot including workflow process captures

12. National Rollout

After satisfactory completion of the FAT, DDU-GKY shall assess the readiness for the National Roll-out and give approval for the same to eKSP.

13. Handholding Support

In addition to training, eKSP shall provide 1 (one) resource per state for onsite handholding support for the eKaushal application during the implementation phase (pilot or national rollout) for at least 4 (four) weeks from start of implementation in that state. Travel and lodging/ boarding expenses shall be reimbursed by MoRD on actuals as per the applicable norms. The onsite resources shall report to the officer designated by MoRD/ State and shall be backed up with a central team comprising at least 5 (five) members deployed dedicatedly by the eKSP for supporting the implementation and operation post implementation. The central team shall

have requisite representation of solution architect, developer, tester, database expert and hardware expert. There shall be at least 1 senior resource deployed at MoRD for coordinating the implementation with MoRD, states and eKSP’s team (central/ onsite) and post implementation support. Post the implementation phase i.e. beyond 4 weeks during pilot/ rollout, onsite handholding support at a state level will be provided at the request of MORD, to be reimbursed by MoRD at the rates mutually agreed and set out in the contract.

14. Support to 3rd party acceptance testing, audit, and certification

DDU-GKY may choose to perform 3rd party acceptance test, audits and certification of the eKaushal software. eKSP is required to provide full support to any such requirement including access to its premises, review of software development processes, audit of development environment and personnel etc. 15. Project Documentation

The eKSP shall create and maintain all project documents that would be passed on to DDU-GKY as deliverables as per the agreed project timelines. The documents created by the eKSP will be reviewed and approved by the Governance Structure Setup/ PMO through DDU-GKY.

a. DDU-GKY would also approve any changes required to these documents during the course of the project.

b. DDU-GKY will be the final signatory authority on the documents.

c. Where necessary, the eKSP shall update the documentation based on changes and submit a new version of the document to DDU-GKY

d. All final project documents are to be submitted in bound hardcopy and in a softcopy/ CD format for archival by DDU-GKY

e. All project document shall have a version number and major changes from the last submission shall be highlighted in the beginning of the revised documents

f. Documents and all artifacts generated by the project shall be kept in revision/ version controlled system with released documents accessible to DDU-GKY and working documents (read-only) accessible to PMO.

g. Project documents include but are not limited to the following:

i. Assessment and Requirement Gathering reports with MoMs

ii. Detailed Project Plan

iii. FRS document

iv. SRS document

v. Software Design Document (SDD)

vi. Business Process documents

vii. High-level Architecture

viii. Design Document for development and customizations performed

ix. All Test Plans and test cases

x. Solution deployment architecture

xi. Requirements Traceability Matrix

xii. Change Management and training approach and Plan

xiii. SLA and Performance Monitoring approach and Plan

xiv. Transition and Knowledge Transfer approach and Plan

xv. Issue Logs/ tracker system

xvi. User manuals

xvii. Administrator manuals

xviii. Training manuals

xix. Security policy

xx. Back-up and restoration policy

xxi. Disaster recovery/ Business continuity plan

xxii. Software Change Management policy

xxiii. Incident management strategy and Technical helpdesk manual in compliance with ITIL, ISO 20000 and other relevant industry standards

h. The eKSP shall prepare the formats/templates for each of the deliverables upfront based upon industry standards (e.g. ISO) and the same will be approved by DDU-GKY prior to its use for deliverables.

i. All project documents are to be kept up-to-date during the course of the project.

j. The eKSP shall maintain a log of the internal review of all the deliverables submitted. The logs shall be submitted to DDU-GKY on request.

k. All project documentation shall conform to the highest standards of software engineering documentation.

16. Post Implementation (Operational and Maintenance) Services covering the following:

a. Software maintenance and support services (including Maintenance of eKaushal Application

Software and Release Management of subsequent versions) for eKaushal to meet the desired Service Levels consistently.

b. Application functional support services including changes and enhancements in a time-bound manner.

c. Annual Technical Support (ATS) for all the licensed software and hardware including a formal arrangement with OEM/ solution vendor for support in a time-bound manner.

d. Operations and maintenance during the course of the contract. The O&M phase shall start after successful completion and approval of the FAT for the first set of modules. During the O&M phase the eKSP is expected to perform following activities:

i. Deployment of technical helpdesk for providing support to system users during 9 am to 6 pm through Monday to Saturday except for National Holidays. Helpdesk should be in place from start of pilot implementation itself.

ii. Providing helpdesk phone and email for both inbound and outbound traffic. There should be a minimum of 4 phone lines for dedicated use of helpdesk.

iii. Deploying requisite no. of helpdesk personnel at all levels (L1 to L3). L1 should consist of at least 4 personnel. Also eKSP should have a formal arrangement with OEM/ solution vendor for L4 support in a time-bound manner.

iv. Providing ticket logging, issue resolution and reporting to complainant. Requisite reports and logs shall be maintained for issues and resolutions including helpdesk personnel identification and date/ time stamp for review of MoRD.

v. Deployment of O&M team as per the agreement in terms of Number of staff, skills and experience including personnel for hardware and infrastructure monitoring.

vi. All the bugs reported during the O&M phase shall be fixed by the eKSP as per the SLA defined in this TOR.

vii. Updation of Databases

viii. The eKSP shall deploy suitable processes to continuously monitor the capacity of the overall system usage including servers, storage, network and bandwidth etc. and make necessary arrangements for capacity enhancement in order to fulfil prevalent SLA requirements. eKSP shall keep DDU-GKY informed at all times about capacity utilization and enhancement applied.

17. Exit Management and Transition at the end of Contract Period – The eKSP will document exit

management and transition strategy and get the same approved by MoRD. The strategy shall address, inter alia, application hosting arrangement, application code, 3rd party licenses, technical team profile, data structure, data back-up, and project document back-up including FRS, SRS, software design (both high level / HLD and low level design/ LLD), user manual and administrator manual.

6.1 Indicative Solution Architecture

The indicative solution architecture of the eKaushal system is illustrated below. The main focus of DDU-GKY is to ensure the setup and operation of a comprehensive, updated and current eKaushal system and its components and the effective operation and management of the same as per the requirements of this TOR and the Service Level Agreement (SLA).

Figure 1: Indicative Solution Architecture of eKaushal system

eKaushal Web Presence

eKaushal Portal / Portal Integration – Web / Tablet / Handheld / SMS / State Configuration

The key architectural requirements of eKaushal solution are summarized below:

Key Architectural requirements of eKaushal system

1. eKaushal system would be designed as web enabled, n-tiered solution with informational, collaborative and transactional services.

2. eKaushal system should be designed on Open API architecture so as to provide distributed processing and facility for other stakeholders & application developers to build their own applications around the APIs provided by eKaushal system. Those applications would interact with eKaushal system through the APIs and process or exchange data & information as needed by MoRD or those stakeholders. None-the-less, eKaushal system would also provide its own user interfaces for those stakeholders who don’t have their applications in order to execute requisite business processes.

3. The eKaushal system would be ‘one-stop-solution’ for DDU-GKY. The web enabled solution shall provide interface for managing and operating all the functionalities of the solution.

4. Other than as stated above, eKaushal solution should not require the installation of any specific client software, except accelerators for offline processing and web components for access through the web-interface unless agreed by MoRD.

5. The eKaushal portal should be web configurable for each state. Each State should able to select its name and login where the data and functionality for only that State is enabled.

6. The eKaushal application shall interface with an SMS gateway for alert functionality.

7. The web based solution should follow the tiered approach allowing for horizontal and vertical scalability at the access tier, web tier, messaging/ integration tier and database and hardware levels. For e.g. it be possibly to provide for redundancy at the web level or add another DBMS at the database level without making changes to other tiers.

8. The solution should be designed to handle exception conditions with meaningful messages.

9. The solution should be designed through use-case scenarios / process flow models which shall be part of the FRS.

10. eKaushal shall have role-based search capability. For e.g. a stakeholder should be able to search for his records in the system.

11. eKaushal solution should allow for independent component registration and availability, enable process flows (including ad-hoc process flows) and ad-hoc MIS report generation.

12. eKaushal solution should allow for saving user profiles and browser level user specific management.

13. eKaushal system should implement best practices for online security based on the transaction type and the architecture should be designed to enable image based security, secure socket communication, one-time-passwords and digital signatures for signing / approval of documents.

14. The eKSP shall review and modify the user interface design for the screens with the input of PMO, DDU-GKY and other stakeholders and ensure sign-off.

15. eKaushal solution should enable to promote a ‘live-architecture’. The web site shall not be designed to carry a static set of documents and information. The eKSP shall create a content generation and management plan along with DDU-GKY to ensure content is updated on a regular basis.

16. To begin with there may be around 10 lakh beneficiaries to be trained through DDU-GKY and that may scale up to 30 lakh. eKaushal solution should have capability to handle all related processes and transactions as indicated in the RFP and support the concurrent user sessions as per specified service levels. That may necessitate scaling up the infrastructure, both horizontally and vertically, beyond the initial setup and therefore system design must provide for such scalability.

17. As the eKaushal system may be accessed from remote locations with minimal connectivity, the architecture should be designed to be operate in low-bandwidth environment. The eKSP shall design a services-frequency-bandwidth matrix, provide for state-saving architecture / transaction locking, offline processing (e.g. forms download) and use other strategies to enable critical services to operate in low/no bandwidth environment.

18. eKaushal system integration mechanism shall conform to the IFEG Standards5 and guidelines issued by Department of Information Technology (Deity), Government of India. The Government of India has other policies and guidelines including the IT Act, Security, Data6 etc. that would need to be followed by the eKSP. Additionally, for Aadhar integration and usage various standards and guidelines have been published by UIDAI7 that would need to be followed.

The N-Tier architecture for the eKaushal system has been adapted in order to have flexibility to incorporate changes, scalability and phased wise implementation of components in a layer. It focuses on layered foundational building blocks covering presentation layer for the end-users with associated core business functional layer, an integration layer providing integration of core applications with data layer (centralized databases) and external systems like Aadhar, State systems, PFMS etc. Management & Administration and security functions are integrated with all the layers. The Infrastructure layer provides all the physical infrastructure like servers, storage and network devices is hosted out of a Data Center backed up. Brief descriptions of each of the layers are described in the following section.

i. User profile The eKaushal platform will be typically used by the DDU-GKY staff at the Head Quarter (HQ) and NRLM staff at the State and field level functionaries across India and by the PIA’s and various supporting agencies such as TSAs etc. The application shall be extensively used by the PIAs as all the procedural and documentation formalities for a project shall be through the eKaushal interface. Monitoring & Appraisal agencies shall upload data such as beneficiary information, attendance, video records, training center assessment and various other details through the eKaushal application.

5http://egovernance.gov.in/standardsandFramework/IFEG 6http://deity.gov.in/content/standards-policies 7https://developer.uidai.gov.in/site/

http://egovernance.gov.in/standardsandFramework/IFEG

http://deity.gov.in/content/standards-policies

https://developer.uidai.gov.in/site/

Other government departments would use the eKaushal system as a decision support system for approval or projects, utilization of funds and gauging the effectiveness of fund usage. The PFMS/ other FMS system would interact with eKaushal system for fund transfer and would send data back to eKaushal system for re-conciliation. eKaushal system would thus need to have accounting and reconciliation functionality. Beneficiary would interact with eKaushal system to ascertain status and get records or get payment reports etc. For beneficiary identification, the eKaushal system would need to interface with Aadhar system of UIDAI. The Help-Desk setup by the eKSP would use eKaushal system to deliver helpdesk services and resolve issues.

ii. Presentation Layer – eKaushal Portal The functional requirements for eKaushal Portal are provided below:

Functional Requirements of eKaushal Portal

1 The ‘eKaushal Portal’ term is used here in terms of functional completeness. eKSP may note that it may not necessarily be a separate (standalone) portal but may be a sub-portal of DDU-GKY or MoRD.

2 Should provide a "User Friendly Interface" using principles of minimalistic, functional User Interface design tested through prototyping and feedback from end-users.

3 Portal shall support users with disabilities and should be accessible by screen readers, client side CSS, captioning etc.

4 Shall have online help, FAQs, Computer Based Training/ Visualization through walkthroughs, videos etc. for users.

5 Shall have the ability for end-users to provide online feedback. The feedback shall be simultaneously sent to the Project Director of the department and the Project Manager of the eKSP or other designated personnel by DDU-GKY.

6 Access to the portal will be through login-password. The eKSP shall install and identity management solution and enable 'Single-Sign-On' (SSO) for the all the users at the eKaushal portal including password renewal, expiry, security and authentication as required.

7 The portal would be accessed using most of the standard web browsers and such details shall be furnished by the eKSP.

8 The portal shall provide role based access to all the functions/features of eKaushal system based on the rights assigned.

9 The eKaushal portal will integrate with an email server by eKSP for sending emails to departmental personnel.

10 The eKaushal portal shall integrate with the SMS Gateway/ email server provided by MoRD to be used for sending SMS / email alerts to users. The integration and implementation of SMS Gateway/ email service shall be the responsibility of the eKSP. The procurement of gateway service and bulk sms packages shall be the responsibility of MoRD.

11 There shall be proper integration of eKaushal portal to/ from any other government portal as and when they are hosted. Such portal would include National Portal of India (india.gov.in) or MoRD portal or NSDC portal.

12 Should act as a gateway to the underlying functionalities in eKaushal system

13 Should provide access to the centralized database of the system through the user interface

14 The portal shall provide a responsive and compatible interface on mobile devices i.e. the portal shall be accessible and shall enable usage using internet browser on a standard mobile device.

iii. Core Application Layer The eKaushal system core application layer shall consist of the modules and overview of which has been provided in Section (2.1). Details of requirements is provided in Section (7.1).

iv. Application Integration Layer eKaushal application would have to interface and integrate with various applications / databases to provide the functionalities as envisaged in this TOR. Some of these systems are in a constant state of evolution thus necessitating the use of standardized integration and information exchange formats. The eKSP may refer to IFEG standards of GoI which may be used for integration and may choose to use a standard integration methodology or common-of-the-shelf component (COTS) such as an enterprise service bus (ESB) for the integration. The following section details the components requiring integration to enable the application functionalities.

v. Application Components The following application components are envisaged in eKaushal system :

a. Document Management System

The eKaushal system will be a repository for all DDU-GKY/ NRLM related data and transactions including approvals at various stage e.g. for Proposals from PIAs, approvals for fund release etc. The digital documents would thus need to be stored within the eKaushal system. Storage Area Network (SAN) will have to be provided for storing of these documents.

The eKSP would review the storage requirements during the course of FRS preparation and communicate the same to DDU-GKY for storage enhancement.

Following types of documents will need to be digitally generated/ maintained:

Proposal Documents – Proposals, Supporting Documents, Videos, Approvals at various levels, MoMs etc.

Fund Transaction Documents - All Fund Sanction, Transfers and Disbursements documents – Notices, transfers, challans and other associated documents

Beneficiary Documents - Application Details, Photographs, Supporting Documents, Attendance records, Pay-slips, Placement Details etc.

Monitoring& Appraisal Documents – From Monitoring and appraisal agencies

Approval and Orders –Internal approvals/ Government Orders / Process documents/ Notifications etc. as passed by the Govt. with respect to DDU-GKY

Any other document DDU-GKY deems necessary

A DMS system is envisaged in the eKaushal. Following are the key features needed (not limited to) for the DMS:

1. Metadata: Information regarding the document shall be stored in the form of Metadata. Metadata may for example, include the date the document was stored and the identity of the user storing it.

2. Integration: The DMS shall integrate document management directly into the eKaushal applications and databases. It should be possible to access documents through the workflow. For example a search on a PIA should also list all the associated documents.

3. Capture: Should be able to accept and process images of paper documents from scanners or multifunction printers.

4. Indexing: Should be able to implement indexing for retrieval & tracking of electronic documents. Indexing should support simple method such as keeping track of unique document identifiers to more complex form by providing classification through the documents' metadata or even through word indexes extracted from the documents' contents, where feasible.

5. Storing electronic documents: Functionality for document management from creation to deletion and integrated with offline storage.

6. Document security: Should be able to implement compliance requirements for certain documents (if required).

7. Digital Signatures – The DMS should provide support for digital signatures

b. Workflow Engine

The workflow engine should be able to define the series of states and events in a workflow process, the order in which they must be performed, permissions defining who can perform them. The workflow engine shall support the following functions (not limited to):

1. The Workflow engine should provide role specific functionality and configuration. 2. The Workflow engine should support multi-hierarchy processes 3. The Workflow engine should integrate with the Portal and the DMS 4. Workflow engine should support ad-hoc workflows 5. The Workflow engine should allow for alerts and notifications, provide queuing of tasks/

activities and allow for task prioritization. 6. The workflow should allow for escalation mechanism for notifications, alerts and

actionables according to pre-defined business rules 7. The workflow should provide each user a dash-board view of the tasks, alerts, notifications,

new arrivals etc. upon log-in into the system. 8. The Workflow engine should provide support of Digital Signatures and allow for digitally

signing approvals/ orders to remove manual based processing. 9. Workflow engine should allow for file management and ‘Office file’ notes. 10. The Workflow engine should have search capability including textual matching search. 11. The Workflow engine should allow for assignments to groups (e.g. a work may be assigned

to a State Office instead of an individual). 12. It should be possible to configure the options in a particular workflow state. For example, if

there is no Delete function defined for the current state, the engine does not make it possible for users to delete an item in that state.

13. Should be able to define and continuously improve business processes 14. The system should support workflow / process management in a hierarchical as well as non-

hierarchical (matrix management) approval paths. It should be possible for a super user to

quickly change the approval hierarchy / path of a workflow based on changes in the organization / process/ business requirements. It should also allow annotations/comments as part of the process management.

15. The system should allow for re-organization of hierarchy of reporting units.

c. Identity Management

The identity management solution is to be used across the portal, workflow, DMS for providing role based access to the functionality and single sign-on functionality. The ID management solution should be an industry standard component (LDAP/ Active Directory) or similar platform integrated model and integrate across the modules and external interfaces.

d. Reporting Engine and Business Intelligence

The Reporting Engine should be an industry standard report generation engine for quickly creating and managing reports. The reporting engine shall including Business Intelligence capabilities. The eKSP would need to build requisite interfaces to the Reporting Engine if required. The Reporting Engine should be integrated with the eKaushal Portal and should allow for standard and ad-hoc reports to be created by end-users. Reporting engine should have the capability for chart, drawing and analysis based presentations of reports. The system should be integrated with office automation products (e.g. MS Office/ Open Office) products. The system should be integrated with Office Excel for ad-hoc reporting / analysis. In other words, it should be possible to download reports in various formats for analysis by DDU-GKY users. The spreadsheet should be integrated and dynamically linked with the application to support export/import data.

e. GIS

The primary functionality for GIS usage is to enable Geo-tagging of various events and records particularly for monitoring and management. For e.g. it should be possible to geo-tag the bio-metric devices and attendance of trainees / trainers.

f. Master Data Management

Master data management feature has to be provided for each module/ functionality as required for

making that module/ functionality usable by application users and reporting purpose of DDU-GKY.

The basic master data related to geography, bank details, pin code should comply with the standard

data structure as per the GoI guidelines.

vi. Electronic Fund Management PFMS (Public Finance Management System) adapted by the Ministry of Finance, GoI or any other Electronic Fund Management system (eFMS) is to be used for the DDU-GKY. However, the above mentioned requirements of the eFMS need to be fulfilled and integrated with the eKaushal system. Hence, the eKSP is expected to study and get acquainted with the PFMS/ other FMS as necessary, find the gaps against above functionality requirements (if any) and develop wrapper or plug-ins to meet the requirements and integration with the eKaushal system. DDU-GKY will facilitate coordination with PFMS / eFMS developer. The primary functionalities required are detailed as below:

eKaushal system Platform: Requirements for Integration with PFMS/ Other FMS

1. eKSP shall design eKaushal system for integration with PFMS/ Other FMS for budget monitoring, fund transfer, Fund utilization, Utilization Certificates, Payment Remittance and reconciliation and, AC/ DC funds

2. PFMS/ Other FMS integration and data exchange formats shall be provided by DDU-GKY. eKSP shall design the system to enable the data exchange interfaces with PFMS / Other FMS as per the standards provided by PFMS

3. eKaushal system should include field required by PFMS/ Other FMS for transaction processing including users IDs, Bank Account Numbers, Branch, IFSC codes etc.

4. eKaushal system should have processes to enable fund payment in installments or against bills as per the requirement of MoRD, trigger payments against defined milestones or bills and approvals thereof, fund status maintenance and reporting, repatriation of funds from defaulting parties, reconciliation with data received from PFMS/ Other FMS, and so on

5. eKSP should modify the interfaces as required by PFMS/ Other FMS during the implementation and O&M stage

6. eKaushal system should support digital signature requirements of PFMS/ Other FMS

7. The proposed system should be able to perform required business functions as per TOR scope and should be able to seamlessly integrate with PFMS/ other FMS as necessary.

8. The eKaushal system platforms should support SSL for secure communication over the web.

9. eKaushal system should be able to store/ process/ extract audit or information through the PFMS/ Other FMS.

10. During and after the integration with eFMS it may be required that the interface is modified or need to be transitioned to a new system as per any updates to the rules / procedures/ orders of GoI. The eKSP shall support any such migration/ transition for the eFMS systems.

vii. Data Layer The various application components would operate on the data in this layer. The data layer thus consist of all the major (but indicative) key databases to be implemented under eKaushal system. The data layer should be using data APIs for exchange of data and information with other stakeholders as well as for report generation. Report generation should involve minimal data processing at eKaushal application level whereas data formatting and presentation schema should be executed by the user application or browser as the case may be. a. PIA Database The central database will store details (not limited to) of all the PIA (both current and legacy) shall be stored and maintained:

PIA details

Proposal Details

Contract Details

Training Details

Beneficiary details

Fund Details

Performance Details

b. Beneficiary Database The database shall store the beneficiary details, UID number, trainings taken, results, placement, post placement tracking etc.

c. Monitoring Agencies This database shall store the details of monitoring and appraisal agencies and their projects completed and performance.

d. Funds/ Transaction Database Transaction table will have summary of each disbursement transaction and authentication status and audit information. The storage shall be re-used after the retention period of the transaction information (to be decided by DDU-GKY). e. Audit Information Database This database will store all the audit information generated through transactions as described in the TOR.

viii. External Systems The interfaces to external systems has been discussed in earlier sections. This section is provided for completeness.

The eKaushal system is required to interface with other applications and systems including but not limited to PFMS, Aadhar and the Skills Management systems in the states described earlier.

Central Plan Scheme Monitoring Solution or another eFMS is a centralized fund management system and allows for Direct-Benefit-Transfer (DBT) to end-users.

ix. Management & Administration Following are the functionalities envisaged to be primarily enabled through an Enterprise Management System (EMS).

Application Management o The solution should provide an integrated tool to manage the whole application during the

operation and management phase. The eKSP shall propose mechanism and tools for monitoring the performance and availability of the system and information required to measure the SLAs and calculation of the penalties. These reports should be available periodically and whenever required.

Diagnostics and tuning o The system to produce sufficient error messages and logs for easy diagnostics for faster trouble

shooting. o All the tuning parameters in the system should be configurable through an interface instead of

hardcoded in the application.

Configuration and Change Management o All the change requests during the operation & management phase shall go through the

Change Control Notification (CCN) process.

Help Desk o eKSP shall implement a Help Desk, which should enable all end users to log any issue related

to the software, functionality or system and seek support from the help desk.

o DDU-GKY shall implement an escalation mechanism for monitoring of help desk requests and resolution provided.

o Users at various offices should be able to register the bugs/complaints in this application/ solution with various details.

o Reports on pending bugs / complaints along with the age analysis on time taken for resolution will have to be provided.

Integration with BPO o Apart from the above helpdesk for system users, DDU-GKY shall setup a separate Call Center /

BPO for handling queries or grievances from stakeholders and document processing for identified processes. Few functions required of the BPO may be executed in the eKaushal system directly and for few other functions, BPO system may be integrated with eKaushal system for data/ information exchange. eKSP shall provide access to BPO agents as approved by MoRD and shall work with BPO agency for effective integration between the two systems.

7.1 Functional Requirements & Processes The following section describes the functional requirements of few key modules envisaged in eKaushal system. The features listed for the modules/ sub-modules however are indicative not exhaustive. The eKSP during the course of requirement analysis will develop the detailed requirement. eKSP would also need to document all the features in detail in their respective FRS and SRS documents. It may also be note that eKSP is expected to ensure that all workflow /process related validations are built and automated in the eKaushal system. All the modules to be developed to be pre-populated in case of availability of data. The eKSP will need to undertake a modular approach as per the existences of MoRD in planning and then deploying modules.

i. User Management

A. User Management

a. The eKaushal system shall allow for creation of user ids for each stake holder.

b. The primary id for stake-holders shall act in administrative role and the stakeholders shall be able to create further users within their domain based on pre-defined roles.

c. There shall be no back-end creation of users under any circumstances except primary user creation.

ii. Proposal Management

A. PIA Registration

a. This module enables PIA to register Online and submit the Project proposal online, post registration. The Module will have all the validations built in place, to ensure the PIA’s submit the required mandatory information to enable approval or rejection of

PIA registration. PIA registration and all subsequent activities like proposal submission etc. will be work flow enabled.

b. MoRD personnel shall login and review the PIA details and will either approve or request for additional information.

c. Once PIA is approved in the system, Permanent Registration for the PIA is generated to be used for identification of the PIA and future reference in eKaushal system. While generating PRN, PIA shall also be provided with unique user id and password for logging into the system

d. It should incorporate the current approval process including document check in three levels

e. Provision for changing the data by PIA with necessary approvals ] {after generation of PRN

f. Categorisation of PIAs based on the pre-defined set of criteria including the financials, experience should be incorporated in eKaushal system

B. Submission of New Proposal

a. Upon login to the system the PIA shall be able to submit new proposals as per the format provided in accordance with the requirement of the scheme/ sub scheme with necessary supporting documents. Document may relate to Financial Details, training Experience, beneficiary details, trainer details, course details, placement details, PIA certification profile etc.

b. eKaushal system will perform a validation check on the submitted proposal in accordance to predefined parameters before submission.

c. On submission of the proposal(s) emails/ alerts are issued to the relevant stakeholders for application tracking

C. Proposal Processing

a. Proposal processing begins with a desk review of the proposal with documents submitted in conformity with appraisal parameters.

b. Concurrence given by SRLM along with their observations on each project proposal is captured into the system

c. Concurrence and observations of Technical Support Agency on each project proposal is captured into the system.

d. eKaushal system generates an appraisal report based on a pre-design score-card e. Proposal is either recommended or rejected

iii. Contract Management

A. Approval of the EEmpowered Committee

a. For all the projects that are recommended, eKaushal system generates the note for EC Committee through a pre-defined formation along with a notes files

b. Additionally information such a dashboard of PIA’s proposal, Funds, Utilization Certificates (UC) are also generated in eKaushal system

c. Upon completion of the EC meeting the MoM and Action items are entered into the eKaushal system

d. Based on the action items necessary alerts and emails are sent to the respective stakeholders

B. Signing of MoU

a. Upon approval of projects from EC the eKaushal system automatically generates the MoU in a pre-defined format

b. The documents are sent through the workflow for the approval of finance, the result of which is captured into the system.

c. The process of fund release is initiated in eKaushal system

iv. Scheme Management

A. Scheme Management

a. The eKaushal system shall enable management of schemes and sub-schemes. b. The eKaushal system shall enable management of proposal parameters under

scheme(s) and sub-scheme(s) c. The eKaushal system shall allow for change management of the schemes

v. Funds Management

A. Generate Total Fund Requirements

a. The system shall calculate the total funds requirements for the projects and the per project fund disbursement, instalment number etc.

b. The Requirements should be generated as per the prevailing guidelines of DDU-GKY. c. Additional details required for PFMS/ Other FMS based fund disbursements are checked

such as account numbers, Bank name, IFSC code etc.

B. Generate Fund Release Orders

a. The eKaushal system calculates the details of and generates the fund release order which is passed to the PFMS / Other FMS system upon approval by DDU-GKY.

C. Transfer of Funds

a. All fund transfers including intra-department and to beneficiaries/ PIAs/ banks/ agencies would need to recorded and monitored through the Fund Management module

b. Digital Signatures shall be used for fund transfers and approvals where feasible c. DDU-GKY must be able to view the released amount for their areas in the portal d. Officers at various levels to view the status of the fund transferred or released

D. Re-conciliation and Accounts Statements

a. At the end-of-the disbursement cycle, there shall be reconciliation of the funds b. Audit/ logging trail for notification and receipt should be implemented for all fund

related transactions need to implemented c. Data pull and re-conciliation from PFMS/ Other FMS system needs to be implemented d. Upon monitoring and review the eKaushal system should be able to generate UCs and

Project Statement of Accounts

E. Management of mandatory payments under scheme(s)/ sub-scheme(s)

a. The eKaushal system should be able to record mandatory payments under different heads payable to beneficiaries either directly or through integration with PFMS/ Other FMS system as may be decided by the MoRD.

b. The eKaushal system shall be able to report on the status of mandatory payment payable, paid and still payable to beneficiaries.

c. The eKaushal system shall allow for recording verification details of mandatory payments in accordance with the guidelines

vi. Monitoring and Quality Control

A. Project Monitoring Agency Registration

a. eKaushal system shall allow for online registration and management of project monitoring agencies through pre-defined formats.

b. The project monitoring agencies shall be able to login to the system to provide information and documentation which shall be review by DDU-GKY program

Upon registration, the eKaushal system shall appropriately classify the agencies.

B. Submission of Monitoring Reports

a. Project monitoring agencies shall be able through submit their reports online through the eKaushal system

b. The project monitoring agencies shall be able to submit reports through handheld applications with geo-tagging at the field level.

C MIS Reports on Project Monitoring Agencies

a. eKaushal system shall provide MIS reports with respect to the monitoring agencies, quality control criteria and their performance through various dashboard views.

vii. Training Center Management

A. Training Center Management

a. PIAs should be able to record details of training centers which may have residential facilities in accordance to the guideline parameters and notification issued.

b. The eKaushal system shall be able to maintain the record of staff deployed at training centers

c. The eKaushal system shall be able to handle change management related to training centers.

d. Necessary Approval process for Training Centres (Due-Diligence) by CTSAs in YP states and SRLMs in AAP states after the verification by Q team shall be incorporated

e. Provision for daily updating the status of the training centre facilities f. Capturing the inspections carried out by the concerned stakeholders across

timelines g. Capturing compliance of gaps observed during the inspection

viii. Beneficiary Management

A. Beneficiary Registration

a. Beneficiaries shall be tagged using their UID / Aadhar number / SECC b. PIA shall be able to submit the list and register beneficiaries in the system

B. Beneficiary Management

a. System should allow for view the status of the beneficiaries allowing drill down to a single individual.

b. It should be possible to see the status of beneficiary, record attendance (through field based handheld / Aadhar linked biometric application), monitor progress of various dimensions, placement status, salary disbursements etc.

c. Provision needs to be there for planning, conducting, reporting and storing assessment and certification of beneficiaries directly or through integration with NSDC/SSC/NCVT systems

d. It should record placements of beneficiaries as per requirements of the guideline and notifications issued in due course and, maintain database of employers through a work flow.

e. System should allow tracking and monitoring of beneficiaries at least for a year after completion of training

ix. Batch Management

A. Batch Management

d. PIAs should be able to create batch in eKaushal system as per work flow and dynamics of batch and closure of the batch.

e. The eKaushal system shall allow for change management of the batch

x. Learning Management

A. Curriculum design and training plan

a. The eKaushal system shall enable recording of curriculum by implementing agencies and shall be available for verification and ratification by Certifying Agencies.

b. The eKaushal system shall allow the development of training plan in accordance with curriculum for trades and other training components to be used for quality control by stake holders at different stages of the project.

c. Provision shall be there for updating the training plan on a day to day basis d. Time tabling facility, Session feedback from students to teachers and from

teachers to students, Quiz, Giving assignments, its submission and evaluation, Discussion board and Videotaped computer based testing, off line and online.

B. Assessment Management

a. The eKaushal system shall enable certifying agencies, assessment agencies and assessor to interact with the system and record the results of assessment.

b. The eKaushal system shall provide the facility of separate interface for all the actors involved in the assessment of candidates.

c. The eKaushal system shall allow for change management of the assessment workflow

d. The eKaushal system should enable integration with the existing certification agencies like SSCs and NCVT as possible.

xi. Reports & Analysis

A. Report Generation

1. a. Following reports (but not limited to) are expected through the system and/or available on the portal:

i. The complete set of transactions with PIAs, Monitoring agencies and Fund Management system

ii. Fund transfer status (with past history) for the PIAs including un-disbursed fund transfer.

iii. Geography wise disbursements and coverage. iv. Reports on fund allocation vis-a’-viz cumulative disbursements both project

wise, State wise, geography wise and in both absolute values, percentages along with graphs.

v. Reports on individual project performance and beneficiaries with details such as coverage, age, gender, differentials over last disbursement cycle etc.

vi. Time Intelligence for reporting - The system should have in-built Time intelligence for reporting in various formats

vii. The system must have the ability to generate basic graphical means of representing data such as bar graphs, scatter diagrams, pie charts etc.

viii. The system must have the ability to export the generated reports into various formats such as .pdf, .xls, .ppt, .doc etc.

ix. The system should support Ad-hoc reporting requests. x. The system should provide dashboards, analysis and drill-down ability.

xi. Each report offers category totals and grand total figure wherever applicable/specified.

xii. DDU-GKY may choose to add additional reports as and when required. The eKSP should plan to develop a set of standard reports generally required by different stakeholders.

xiii. Reporting tool should have the capability to generate ad-hoc reports, should use dashboards and use data visualization tools.

xiv. Reports need to be designed based on stakeholder perspectives.

xii. Management of Audit Information

A. Audit Trails

The information required for the audit, which may be performance audit, financial/ statutory audit or social audit shall be maintained by the system. The list below is indicative, however the complete audit information required shall be fixed after the discussion with DDU-GKY during development of the SRS. a. For all the transactions in disbursement of funds:

i. Transaction ID (if required) ii. Beneficiary ID / PIA ID

iii. Disbursement Mode iv. Disbursement Approver v. Other disbursement details

vi. Amount vii. Time Stamp

viii. Mode: Cash/ EBT ix. Account No. x. Bio-metric where applicable: passed / failed

b. Financial Audit Information and transactions: i. To & from account #

ii. ID of the person (digital signature) who has transferred the fund iii. ID of the person who has received the fund iv. Time stamp v. Amount

vi. Status (successful, failed, re-tried etc.) Note: Security and retention period of all the data should be defined and followed. The eKSP may note that the above fields are indicative only and DDU-GKY may choose to add additional fields where found necessary.

c. System shall have audit trails built in for all the activities performed by the super user in the system for all activities described in the TOR. Such audit trails, at a minimum, shall capture the details of name of the user, changes made, date of changes etc. This section must be accessible only to administrators and Super Users.

xiii. Generic & Administrative Functions

A. General Administration

a. Creation and maintenance of the standard master data including (but not limited to) the

following:

1. District, Subdivision, Block and Panchayat/ village names. 2. Schemes being offered. 3. Government administrative structure (Role based) at the districts, sub divisions,

blocks and village level. 4. Role IDs. 5. Mapping of disbursement agencies/ modes with Districts, sub-division, blocks and

villages.

b. Creation and updation of user ids for the system users and establishment of linkages between the user id, administrative role, department and location along with the privileges to perform the defined responsibilities.

c. Enable role based access to the department employees for entering the data into the system

d. All the mentioned activities shall be performed using the application interface only. No direct access should be provided to the backend data for providing any kind of transaction in the system.

B. Other Key functional requirements

a. The system should provide for automated e-mail alerts and workflow notifications including reminders to enter data and communicating the status of workflow etc.

b. The system should have a GUI based interface to create and maintain calculation/validation rules. These rules should be server centric for ease of maintenance.

c. The system should have capability to add new guidelines without major changes. d. The system should have provision for instructions for data entry, in order to guide users. e. The system should allow the user to enter specific supporting details like attaching

documents at all levels. f. It should also have inbuilt facility to send reminders and alerts based on target dates of

the user activities.

The eKSP may note that the above functionalities in the modules are indicative and are ‘to-the-best-of existing knowledge’ of DDU-GKY. The functionality would need to be detailed out and modified during the course of requirement gathering/ documenting, FRS/SRS development and system development & testing as per the requirements of DDU-GKY. Any change in requirement after the FAT of system has been concluded as specified in this document and system is declared Go-Live shall be handled as per the agreed Change Control Process.

8.1 Technical Requirements

eKaushal Platform: High-level Solution requirements

1. The proposed Web based architecture of the system should be based on the standard n-tiered architecture.

2. The proposed architecture should allow for common-off-the shelf (COTS) components based on a well-accepted industry standards.

3. The solution should provide user-centric design.

4. The solution should provide bi-lingual interface, in English and in Hindi. The user would have choice to choose the language option and view as well as enter contents in the language of choice. The eKSP should note that the data storage would also be in English and Hindi. The eKSP shall use Unicode characters sets.

5. Should support Service Oriented Architecture for service delivery.

6. Should support industry standards such as XML for data sharing as well as implementation of form validations.

7. Should provide alert functionalities (SMS, email) to communicate with identified users at DDU-GKY and other departments (as identified by DDU-GKY).

8. The proposed system should be able to perform required business functions as per TOR scope

9. The eKaushal platforms should support SSL for secure communication over the web.

10. Must be able to upgrade services, components, and modules without affecting the production system.

11. The proposed solution should be highly scalable to accommodate current and future requirements as per the information provided in this document.

12. The proposed solution design should allow for scalability at each tier level and allow for horizontal scalability.

13. The solution must support low bandwidth and "near-no" bandwidth conditions for the services defined in the functional requirements where feasible. However parties agrees that there is a minimum bandwidth that is required for user connectivity.

14. The solution should have no single point of failure within and across tiers.

15. The solution must support industry standard RDBMS systems.

16. ta The architecture should be such that the system is available to users 24 X 7 X 365 days a year without any unapproved down-time

17. Page load time, login response-time, ‘on-click’ load time for the Portal should be less than 2 seconds when the eKaushal solution is accessed over the Data Center LAN.

18. Average transaction response time, ‘On-submit’ response-time, or any other database access/ search time should be less than as defined in the SLA when the eKaushal solution is accessed over the Data Center LAN through the Portal.

19. The solution must be able to support any standard operating system – Windows, Linux or equivalent

20. The proposed solutions component must also have revision / version control system.

21. Solution shall be designed to interface with delivery channels like SMS, Phone, and IVR as and when they may be introduced.

Integration / Enterprise Service Bus (ESB) – Technical Requirements

1. ESB must support all industry standards interfaces for interoperability between different systems i.e.: core applications, Work Flow system, DMS, Reporting etc.

2. The Enterprise Service Bus must be based on open standards and support multiple OS platforms.

3. The Enterprise Service Bus should support XML Security

4. Enterprise Service Bus should enable different integration methodologies including legacy systems

5. 5.

Enterprise Service Bus should enable / support Service Oriented Architectures

6. Enterprise Service Bus should provide flexibility to be able to track exceptions occurred during any process. Also it should support manage errors that stop application process (fallout, stop process, etc.)

7. Enterprise Service Bus should provide capabilities like filtering, correlation, aggregation and pattern matching.

8. The ESB should support instance recovery

9. ESB should support various performance features e.g. pooling, throttling etc.

10. The ESB should support various open standard based application, databases and other servers with full functionality.

11. The Enterprise Service Bus must have development framework for extending its capabilities to newer integration touch-points and protocols.

Bulk Data load – Technical Requirements

1. The proposed solution should support Extraction from single/multiple heterogeneous sources.

2. The proposed solution should support direct-path bulk loading for applicable RDBMS.

3. The proposed solution should support incremental loading of tables.

4. The proposed solution should support logging and notification of rejected records on account of database constraints.

5. The proposed solution should support error handling into flat file or database tables.

6. Ability to connect to multiple heterogeneous data sources.

7. Upgrade of the platform should not necessitate upgrade of the source or target databases.

8. Extensive library of built in transformations should be provided so as to minimize writing of code.

9. No loss of work in case of temporary connection failures to the repository.

10. Support for multithreaded operation or internal parallelism to handle large quantities of data processing.

11. The proposed solution should support single centralized repository.

12. Easy deployment in centralized or distributed deployment strategies and support for complete release management.

13. Ability to define separate security rules for various environments (Dev, QA and Production).

14. Security support for deployment or user security for release control.

15. The proposed solution should support time based scheduling and external scheduling tools

Data Replication - Technical Requirements

1. The proposed solution should support data replication between various industry standard databases.

2. The proposed solution should support real-time data replication at database level

Application Server – Technical Requirements

1. Proposed solution should be built on standard industry platforms such as J2EE / .Net etc.

2. The system should support scalable architecture to support clustering at each layer i.e. Web server, Application server and Database for Fault Tolerance & Load Balancing.

3. Proposed application server should have published benchmarks.

4. Support for hot redeployment side-by-side/production redeployment

5. Must support iterative development

6. Proposed Application Server should support Migration / Upgradation / Modernization of current applications / software without any major changes.

7. Support any standard development / implementation platform such as Microsoft Windows.

8. Application server should be capable of Log Handling, Connection pool tuning

9. Should provide the functionality to set Performance thresholds

10. Must provide the GUI for Application / platform monitoring and Diagnostics

Database Management System (DBMS) – Technical Requirements

1. The DBMS must be able to recover automatically from storage and server failures.

2. The DBMS shall support, active-active clustering with the objective of ensuring scalability and highest availability of the core platform.

3. The switch over during failures shall remain transparent to all the Application Servers and end-users and they shall be able to continue working without re-logging into Application.

4. There should be a scope to bring back the failed system into the configuration both automatically and manually without disrupting applications with zero downtime.

5. The DBMS should be available in all the hardware architectures, operating systems (Major Unix, Linux and Windows environments) with identical functionalities

6. The DBMS should have the capability to store relational, text, and image data structures within the database.

7. The DBMS should be able to scale up multiple terabytes in decentralized and centralized environment.

8. The DBMS should allow to achieve horizontal/vertical scalability (number of databases, users, connections etc.).

9. The DBMS should be able to scale seamlessly by adding more resources in terms of CPUs, Systems and Storage solutions available in the market without any downtime.

10. The DBMS should be able to provide easier migration / upgradation to next version with minimal or no downtime.

11. Ability to service concurrent multiple read and write requests without the need of building separate replicated environments. Should have the ability to handle deadlock situations.

12. The DBMS should support protocols like ODBC, JDBC (Thin and Thick), OLEDB, ADO .Net, Oracle Net8 for connecting from various applications.

13. Single database image should be available, in the clustered environment without need for any physical bifurcation / allocation / reconfiguration to the servers in the cluster.

14. The DBMS should be able to provide workload distribution across the servers in the cluster.

15. Should have the functionality to replicate the schema, tables and data to remote databases.

16. The system must provide optimized data access, intelligent caching and clustering support.

DBMS – Non-functional Requirements

1. The database should be having built-in, auto installed utility for managing the database over LAN and WAN using browsers.

2. Ability to schedule and automate management tasks and notifies alerts.

3. Should have Automated/manual performance analysis with detailed diagnosis of the cause of performance related issues with possible resolutions.

4. Option for Automated/manual identification and tuning of high load SQL Statements.

5. Support Automated Patch Distribution that eliminates the time consuming effort of determining which patches are applicable and required and the actual manual download of the patches.

6. Provide advisory-based performance tuning tool that help to tune SQL statements.

Document Management System (DMS)

1. The DMS should support multiple document formats including images, text (English/ Hindi)

2. The DMS should be able to restrict users to viewing all or selection versions documents.

3. The DMS with document management facilities should be capable of managing electronic documents as separate but related entities, while maintaining the link between them.

4. The DMS with document management facilities should be able to interface with related packages, including image processing, workflow systems and web services whilst retaining full control of existing electronic records.

5. The DMS should also have an integrated audit log.

6. The DMS should also have user and group management functionalities.

7. The DMS should also have document pre-visualization for different formats.

8. The DMS should have support for SSL communications

9. The DMS should have Comprehensive search options.

10. The DMS should also have Linear and Matrix barcode compatibility.

Audit Trails & Logs

1. The eKSP and the DDU-GKY should agree on a timeframe for which old audit logs will be maintained for ready reference in the system. The old records may be archived.

2. The application should log all application transaction details including, but not limited to, time stamp, operator, approver IDs, update/modification trail etc.

3. The application should protect its audit records from unauthorized deletion, modification, or disclosure

Data Protection

1. The application should store password and other key data content in encrypted form.

Session Management

1. The application shall put a limit on the maximum time length of an idle session, which should ensure that automatic session termination takes place after expiry of the specific time length.

2. The system should provide capability to modify the maximum time length of idle sessions dynamically.

3. The application users should be able to explicitly terminate a session (logout).

4. The application should not store authentication credentials on client computers after a session terminates.

Backup & Recovery

1. The backup and restoration policy should be framed and provided to the DDU-GKY as a deliverable by the eKSP.

2. The eKSP shall be responsible for monitoring all backup of data that is stored within the new system in accordance with the backup policy.

3. eKSP shall implement the required backup solution for regular / scheduled backups which would be monitored and reported by eKSP.

4. A backup schedule shall be prepared by the eKSP and the same shall be implemented with approval of the DDU-GKY.

Application Security Requirements

1. Internal Users (DDU-GKY Users/departmental operators) should not be able to login to the application, without providing login credentials.

2. The application should have capability to enforce required password policy (e.g. minimum password length, complexity requirements, password age etc.).

3. The application should lock out a particular user after performing a configurable number of unsuccessful attempts.

4. User Authentication & authorization related transactions should be encrypted.

5. Application should restrict access to a user whose password has expired until the user changes the expired password.

6. The application should display an appropriate message upon successful login or a warning after failed login attempt.

7. The application should enable the creation of different user groups, and the assignment of different privileges to each group.

8. The application should support role based access control to enforce separation of duties.

9. In case the system is being accessed by other systems / web services / interfaces, the system should perform due authentication.

10. It is preferred that no direct access to the database is provided to any external agency unless required and approved by the DDU-GKY.

11. Any uploaded file to the application system should be scanned thoroughly before allowing the uploaded file to reach IT application system for storage.

12. The application should also support the Maker-Checker concept wherein a user who creates a record or request should not be able to approve or update the record or request.

Data Security Requirements

1. Restrict DBA access to the database through back-end even for certain administrative activity.

2. Flexible and adaptable controls over who, when, where and how applications, databases and data can be accessed.

3. Prevent access to sensitive application data by highly privileged users. Application Super user should not be able to select, insert, update or delete data from CBDB, audit databases.

4. The database should support role based access control, user based privileges to manage data. The DB access will be restricted to eKSP personnel only for the purpose of management and maintenance.

5. Should support password management mechanism with expirable passwords.

6. Support standalone / integrate with Operating system security.

7. Option to encrypt data before transferring over a network Datacenter LAN communication will not be encrypted.

8. Option to encrypt the data stored in the database on need basis.

9. Should support SSL and PKI

10. Should support for auditing to track and monitor user behavior with details about the level of detailing stored by the system and ability to reverse changes

11. Support for roles for the purpose of applying security (database/object level) to a group of users with the ability to assign server permissions to a role and add/remove users to the role.

UI Requirements

1. Application should have consistent look and feel across software applications

2. Consistent and logical navigation flow and tool-tip information wherever relevant

3. Uses standard GUI features (e.g., drop-down menus, dialog boxes, toolbar buttons)

4. Data formats are consistent throughout application windows

5. Menu options can be accessed via keyboard commands and/or arrow keys. Mouse-only access to options should be avoided

6. Controls on page must respond properly to Tab order and hot-keys (alt-keys)

7. Interface recovers gracefully from anticipated user errors (e.g., invalid input)

8. Information and error messages are useful, accurate, and correctly spelled

9. Unnecessary warnings do not appear

9.1 Solution Deployment Requirement a. The eKaushal solution should be deployed in a Data Centre (minimum Tier III as per TIA 942) in India

and shall be fully backed up by an external DR/ BCP site

b. Disaster Recovery and Business Continuity Planning (BCP) to be provided through another Data center of equivalent specification and capability located in a different seismic zone in India

c. Requisite data replication mechanism shall be established between the two data centers and requisite bandwidth shall be provided for replication

d. Data centers shall have requisite provision for staging environment in addition to production environment

e. Data centers to have requisite provision for server hardware, SAN based storage, and server & network load balancers etc.

f. eKSP shall provide all the requisite system software and their licenses in the name of MoRD. System software shall include web/ application/ database server.

g. Data centers must avoid ‘single point of failure’ at all stages and must provide sufficient redundancy in respect of infrastructure including power supply redundancy (entire path from source to the equipment), network source redundancy, server clustering, network device clustering and so on with the goal to achieve “no data loss” and “no denial of service”

h. Aiming at the above goal, appropriate RTO and RPO for data center service shall be established in consultation with and concurrence of MoRD

i. Data centers to have comprehensive security system as per ISO 27001 and other industry standards j. Requisite bandwidth to be provided at Data center and Disaster Recovery center in order to meet

specified performance and service levels

Following schematic diagram presents the indicative deployment architecture

Figure 2: Deployment Architecture – Indicative

a. The First part shows various types of users and ways of accessing the application and web servers. All users including PIAs, DDU-GKY Officials, and States shall access the eKaushal Portal via the internet, in which case they will hit the internet router before getting access to the Portal Web Services in the De-Militarized Zone through a firewall. Internal users of the eKSP may access the servers inside directly through switch in the Data Center.

b. The Web-servers for the eKaushal Portal and application will be placed in the de-militarized zone. The

web services may be consumed directly by the stake holders and departments to implement certain functionalities. These servers are connected to the application servers in the militarized zone through the core switch.

c. The common shared services like LDAP/ Active Directory, Anti-Virus, Server performance etc. will also

be need to be consumed by the application and these servers will also be accessed via the core switch.

10.1 Implementation Approach & Plan

i. Project Implementation Plan The implementation of the activities as detailed in the Scope of Work for the eKSP during the project is divided into two phases: Development Phase, where the eKaushal application and modules are built/ integrated. The Development phase would also include various integration requirements outlined in this TOR.

After the Go-live of the project, the scope of work would move into the Operation, Maintenance and Continuous Improvement Phase, where eKaushal application will be maintained and operated as per the defined SLAs. The detailed implementation plan and timelines shall be submitted immediately on the issuance of the letter of intent/ signing of the agreement and approved by DDU-GKY. The plan shall at least cater to the following broad categories:

a. Requirement gathering b. Development c. Testing by eKSP d. Testing by 3rd party e. Training f. Pilot g. Rollout h. Go-Live i. O & M

ii. Project Tenure

The duration of the project shall be for a period of 5 years from the date of signing of the agreement and as per the terms in the MSA (Master Services Agreement). The project tenure shall include implementation till Go-Live and O & M post Go-Live.

iii. Project Governance Framework

The project Governance Framework will be defined by the DDU-GKY. The eKSP is required to provide a detailed project progress reporting plan and periodic reports to the DDU-GKY and/or designated agency/ person.

11.1 Service Level Agreement

i. Service Levels and Definitions

1. The Implementation Agency shall monitor and maintain the stated service levels to provide quality customer services.

2. eKSP would need to size the hardware appropriately keeping in view the requirements in this TOR, the FRS & SRS and the required Service Levels.

3. eKSP would manage, monitor, co-ordinate the O&M for the hardware and other equipment to ensure service levels are attained.

4. Penalties, unless explicitly prescribed otherwise, shall be deducted from the quarterly payable accrued to the eKSP.

5. During the Operation and Maintenance period the eKSP is expected to keep the actual service levels above the specified level.

6. Penalties shall be levied only for the reasons attributable to the eKSP. 7. Any risks/ issues foreseen by the eKSP shall be brought to the notice of the DDU-GKY immediately before

implementation/ operation for mutual agreement on the course of action to be taken. If the eKSP falters

in one or more of the Service Level resulting in a breach, then deduction in the Quarterly pay-out to the eKSP is calculated according to the methodology prescribed in this section or as approved by DDU-GKY.

ii. Availability of Services Service availability is defined as:

a. {(Scheduled operation time – Service downtime) / (scheduled operation time)} x 100% b. Where: “Scheduled operation time” means the scheduled operating hours of the Service for

the month. All planned downtime on the Service would be deducted from the total operation time for the month to give the scheduled operation time. Planned downtime will not be done during business hours. Occurrence and duration of a planned downtime shall be with prior consultation and approval of DDU-GKY.

c. “Service downtime” means accumulated time during which the Service is totally inoperable due to in-scope Service failure and will be measured on a monthly basis from the time DDU-GKY officials or any of the stake holders including the eKSP team, reports to or logs a call with the help desk to report the failure or the failure is known to the eKSP from measurement tools to the time when the Service is restored to normal operation as mutually agreed.

Sl No.

Service Level Parameter

Minimum Requirements (Baseline)

Penalty Basis of measurement / Remarks

1. Availability of

eKaushal

application to users

95% 1% of the O&M fee

payable to the eKSP for the

measurement period

The measurement of the

service availability will be

based on the EMS reports to

be provided by the eKSP and

reviewed by the DU-GKY.

iii. Performance of the System

During the O&M phase, the eKSP is expected to maintain the performance level as demonstrated and approved during the FAT/ 3rd party testing. Non availability or lower performance of the application, web services and databases (as defined in the TOR) shall also be considered as downtime and measurement of the service level shall be done through help desk issue tracking system. Additionally, The eKSP shall monitor the usage level of application and report the no. of users each day of a month along with average, maximum, and minimum login duration across users and provide the information to MoRD. This information shall be used appropriately for monitoring system capacity utilization.

Sl No.


Minimum Requirements (Baseline)

Penalty Basis of measurement / Remarks

2 Average Page load

time for eKaushal

portal

3 seconds 1% of the

O&M fee

payable to the

eKSP for the

measurement

period

Page load times shall be measured

over a leased circuit or equivalent

of 256 Kbps

Automated tool shall be used for

this purpose with 4 test

transactions per hour

Measured as the elapsed time

between the action link/ button

being clicked and its response

page appearing completely

Test data to be identified distinctly

and path taken by test data to be

similar to real transaction

DNS servers should simulate

access by end user and not

answered locally

Cache to be cleared before every

transaction used for measurement

Average must be achieved with

more than 90% of the transactions

being within 3 seconds and 9% of

the transactions being within 3-4

seconds range

iv. Information Security

During the O&M phase, the eKSP is expected to maintain the security controls as demonstrated and approved during the FAT/ 3rd party testing. Non availability of eKaushal system by the eKSP due to application security issues and/ or loss of data due to the reasons attributable to the eKSP shall be considered as breach. eKSP shall document a comprehensive security policy for eKaushal system and implement the same after approval of DDU-GKY. eKSP shall implement a comprehensive incident management system for logging, tracking, and reporting of incidents as well as their resolution.

Sl No.

Service Level Parameter Penalty Basis of measurement / Remarks

3 Maintenance of System

security and Data integrity

Rs. 100,000/- per

confirmed

incident and

established

security breach

or data loss or

data integrity

compromise in

the quarter.

Measurement shall be based on incidents of

data loss or security breach or compromise in

the integrity of the data reported at the help

desk and/ or reported to DDU-GKY or incident

logging through Firewall/ IPS or Virus / Malware

Infections in the servers which has not be

detected / removed.

In the event of any data loss due to intentional or accidental deletion by customer or customer representatives, eKSP shall not be responsible for the data loss incident and shall not be liable to pay any penalty for such incident. Further there may be security incidents which may not be detected due to the type of attack (ex. Day 0 virus attacks) and eKSP shall not be liable to pay any penalties in respect of such attacks which cannot be reasonably detected by the deployed systems. However, eKSP shall take necessary measures including deployment of additional hardware/ software necessary and sufficient for enhancing the security and stopping similar attacks in future.

i. Helpdesk Services eKSP shall set up a responsive Helpdesk service for ensuring a timely support to system users and helping record/ resolve/ report the issues/ bugs in the system.

Sl No.


Baseline Metric Penalty Basis of measurement / Remarks

4 Response time for

resolution of

Bugs/ Issues

related with the

Application

Software or any

software deployed

by eKSP.

Critical (where

the services are

not available)

<=4

Hours

Rs. 5000/-

deducted on a pro-

rata basis for every

hour of delay

beyond the

baseline metric.

The criticality of issues/

bugs shall be defined by

eKSP in consultation with

and concurrence of MoRD

before implementation /

operation.

The issues/bugs will be

logged and tracked through

issues/ Bug tracking system.

The helpdesk shall log the

issue and its criticality shall

Non-Critical

(where services

are available,

but not at

<=16

hours

Rs. 1000/-

deducted on a pro-

rata basis for every

hour of delay

optimal

performance

level)

beyond the

baseline metric.

be recorded by helpdesk

system during logging.

ii. Manpower Replacement Timelines The eKSP is expected to maintain the manpower deployed during development and operation & maintenance phase as per the TOR and the manpower deployment plan submitted to DDU-GKY. In case the eKSP has proposed any deviation in terms of manpower deployment plan in the proposal, DDU-GKY’s decision on the deployment plan will be final. If replacement of any resource is sought by DDU-GKY or due to attrition in the deployed team, the eKSP shall replace the resources within 30 working days. In case any replacement of manpower is sought by the eKSP, the eKSP should replace the manpower with equivalent or better skills and experience. Any deployment/replacement of the resources has to be approved by the DDU-GKY.

File No. J-17060/125/2015-DDU-GKY (342920) Government of India ...

Documents

Transcript of File No. J-17060/125/2015-DDU-GKY (342920) Government of India ...