RFP 71626 DS2.0Volume1

RFP for Selection of SI for Design, Development, Implementation and Maintenance of CG Digital Government 2.
0 System -
Volume I
Request for Proposal (RFP) for

Selection of System Integrator for Design,
Development, Implementation and
Maintenance of
CG Digital Government 2.0
System
(Volume I)
Scope of Work
RFP No.: 71626/CEO/CHiPS/DS/RFP/2021
dated 8th April 2021
Chhattisgarh infotech Promotion Society (CHiPS)
State Data Centre Building, Near Police Control Room,Civil

Lines, Raipur, Chhattisgarh–492001Tel.: +91-771-4014158
Email: ceochips@nic.in, Website: www.chips.gov.in
Page 0 of 121
RFP for Selection of SI for Design, Development, Implementation and Maintenance of CG Digital Government 2.0 System -
Volume I
Table of Contents
Disclaimer ........................................................................................................ 3
1 About this RFP .............................................................................................. 4
2 Fact Sheet ................................................................................................... 5
3 About Chhattisgarh ........................................................................................ 7
4 About CHiPS ................................................................................................. 8
5 Background Information of Digital Secretariat 1.0 .................................................... 9
5.1 Key Features .......................................................................................... 9
5.2 Current Implementation Status: .................................................................... 10
5.3 Description of Modules ................................................................................. 10
5.4 Digital Secretariat Current Environment ............................................................ 13
5.5 Critical elements of Digital Secretariat 1.0 ...................................................... 14
5.5.1 Logical Architecture ........................................................................... 14
5.5.2 Physical Architecture ......................................................................... 15
5.5.3 Deployment Architecture ..................................................................... 16
5.5.4 Existing Hardware Details ..................................................................... 17
6 Project Overview and Definitions of Digital Secretariat 2.0 ........................................ 17
7 Detailed Scope of Work ................................................................................. 21
7.1 Knowledge transfer and Project Planning ..................................................... 23
7.2 Application Development ......................................................................... 26
7.2.1 System Requirement Elicitation and System Design.................................... 27
7.2.2 7.2.2 Solution Development, Testing and Go-Live of Digital Secretariat 2.0 ..... 35
7.3 Business & Centralize Helpdesk Support ....................................................... 43
7.3.1 Helpdesk ........................................................................................ 43
7.4 Operation & Maintenance of Digital Secretariat 2.0 (post Go-Live) .......................... 45
7.4.1 Application Support and Maintenance ..................................................... 45
7.4.2 Application Monitoring Services ............................................................. 50
7.4.3 User Profile and Account Management .................................................... 50
7.4.4 Periodic Reporting ............................................................................ 51
7.5 Training and Capacity Building .................................................................. 52
7.5.1 Preparation of training aids ................................................................. 53
7.5.2 Training Effectiveness ........................................................................ 53
Page 1 of 121
Volume I
7.6 Infrastructure Hosting & Support ............................................................... 54

7.6.1 Application hosting in SDC and its maintenance ........................................... 54
7.6.2 Operations, Maintenance & Support ......................................................... 54
7.6.3 Disaster recovery ............................................................................... 55
7.7 Exit Management ................................................................................... 55
7.8 Solution Audit and Third-Party Code Review ................................................. 57
8 Roles and Responsibilities .............................................................................. 59
8.1 Roles and responsibilities of CHiPS.............................................................. 59
8.2Roles and responsibilities of SI ....................................................................... 60
8.3Roles and Responsibilities of General Administrative Department, GoCG .................. 61
9 Change Request Management ........................................................................... 61
10 Project Governance ................................................................................... 63
11 Manpower requirement .............................................................................. 65
12 Project Management .................................................................................. 69
12.1 Risk and Issue management ...................................................................... 70
12.2 Requirement Traceability Matrix ................................................................ 71
13 Project Timelines, Payment Terms & Schedule ................................................. 71
14 Compliance to Standards and Certifications ..................................................... 76
14.1 Preference for Open standards ................................................................... 76
14.2 Compliance with Industry Standards............................................................ 76
Appendix A – Functional Requirement Specifications ................................................. 78
Appendix A.1–Functional Requirement Specifications for IHRMS .................................. 84
Appendix B - Data Migration and Integration with State and Central Government Systems . 102
Appendix C - Other Requirements ........................................................................ 103
Appendix D - Service Level Agreement ..................................................................... 105
D.1 Definitions ............................................................................................. 106
D.2 SLA Framework ....................................................................................... 108
D.2.1 Responsibilities of parties ........................................................................ 108
D.2.2 Reporting procedures ............................................................................ 109
D.2.3 Issue management procedures .................................................................. 109
D.2.4 Management escalation procedures and Contact Map ....................................... 110
D.2.5 SLA Change Control .............................................................................. 110
D.2.6 Measurement of SLA ............................................................................. 111
D.2.7 SLA Holiday period ............................................................................... 112
D.2.8 Categories of SLA ................................................................................. 112
Page 2 of 121
Volume I
Project Management Report ............................................................................ 121
Disclaimer
The information contained in this Request for Proposal (hereinafter referred to as "RFP") document
provided to the Bidders, by the Chhattisgarh infotech Promotional Society Raipur, hereinafter referred
to as CHiPS, or any of their employees or advisors, is provided to the Bidder(s) on the terms and
conditions set out in this RFP document and all other terms and conditions subject to which such
information is provided.
The purpose of this RFP document is to provide the Bidder(s) with information to assist in the
formulation of Proposals. This RFP document does not aim to hold all the information each Bidder
Page 3 of 121
Volume I
may require. This RFP document may not be appropriate for all persons, and it is not possible for the
CHiPS, their employees or advisors to consider the business/investment objectives, financial situation
and particular needs of each Bidder who reads or uses this RFP document. Each Bidder should
conduct its own investigations and analysis and should check the accuracy, reliability and
completeness of the information in this RFP document and where necessary obtain independent
advice from appropriate sources.
CHiPS, their employees and advisors make no representation or warranty and shall incur no liability
under any law, statute, rules or regulations as to the accuracy, reliability or completeness of the RFP
document. CHiPS may, in its absolute discretion, but without being under any obligation to do so,
update, amend or supplement the information in this RFP document.
1 About this RFP
CHiPS is the state nodal agency for implementing e-Governance Project in the state of Chhattisgarh.
CHiPS invites on behalf of Department of Electronics and Information Technology, Government of
Chhattisgarh, sealed bids (Pre-Qualification bid/ Technical bid/ Commercial bid) from eligible &
reputed System Integrators for IT Solution provider for “Design, Development, Implementation, and
Maintenance of Digital Secretariat 2.0 solution in the State of Chhattisgarh” and provide support for
a total period of 4 years from the day of Go-Live of applications.
Through this RFP, CHiPS intends to:
 Engage Software solution provider to design, develop, and maintain Public service workflow
digitization application, CG Government HRMS application, web portal, mobile app,
document management system and helpdesk services. These components have been bundled
under the umbrella of Digital Secretariat 2.0.
 All the components mentioned above can be developed afresh or the existing codebase can be
leveraged. CHiPS has an existing Digital Secretariat 2.0 solution which is currently being used
to provide online G2G services in the state. The proposed system should use proven open
source technology to reduce s/w licensing cost.
 Design and Development will involve receiving a knowledge transfer from the existing Digital
Secretariat 2.0vendor of CHiPS.
Page 4 of 121
Volume I
 Study and analyze the existing systems G2G Services. Assessment shall include review of the
current processes/activities performed for delivering the service to the state employees,
operators, key stakeholders and dependencies in service delivery, current level of automation,
non-value added activities/inefficiencies which can be eliminated, district level coordination
and monitoring etc.
 Onboard these G2G Services onto the new application developed as a part of Digital Secretariat
2.0 for Go-live.
 Assist in training, capacity building and change management of different stakeholders for user
adoption of the systems developed as a part of this initiative.
 The aim of the state is to provide complete digital experience to Government Employees. This
will enhance the efficiency and transparency in administration through the implementation of
a comprehensive online workflow application in the all departments of Government of
Chhattisgarh.
Note:
1.CHiPS reserves the right to extend the Term for further period of up to Three (3) Years on the same
terms and conditions, if required.
2. The term CHiPS in this RFP have been used for interchangeably for CHiPS or any
nominated agency by CHiPS.
2 Fact Sheet
1 Tender Number
RFP No.: 71626/CEO/CHiPS/DS/RFP/2021
2 Name of the Work Design, Development, Implementation, &
Maintenance of Digital Secretariat 2.0
3 Name of the issuer of this tender CEO, CHiPS
4 Date of issue of tender document 8th April ,2021
5 Last Date for Submission of 19 April,2021 till 3 pm

written queries by bidders
Page 5 of 121
Volume I
6 Pre-Bid Meeting Pre-Bid Meeting will be held on 22nd April

,2021 through Video Conferencing at 12:30
pm. Video Conferencing link will be shared to
only those bidders whose written queries will be
received till 19th April,2021
7 Publishing of pre-bid 26th April 2021

queries Response
8 Last Date for Submission of Bids 10th May 2021 till 3 pm (Online Submission)
9 Date of Opening of Technical Bids 11th May 2021 at 3 pm at Chhattisgarh Infotech

Promotion Society (CHiPS) Office, Raipur.
10 Date of Technical presentations To be intimated
11 Date of Commercial Bid opening To be intimated
12 Place of Opening of Bids The Office of CEO, CHiPS, State Data

Center Building, Near Police Control
Room, Civil Lines, Raipur, Chhattisgarh –
13 Address of Communication 492001

CEO, CHiPS, State Data Center Building,
Near Police Control Room, Civil Lines,
Raipur, Chhattisgarh 492001–
14 Cost of Tender Document Should have made online payment of Rs.

20,000/- (Rupees Twenty Thousand only) for
the RFP document
15 Earnest Money Deposit (EMD) Rs. 35,00,000/- (Rupees Thirty Five Lakh only).
Online in e-procurement portal
16 Purchase of Tender Document Download fromwww.chips.gov.in or

https://eproc.cgstate.gov.in and the bidders are
required to submit the tender fees online along with
the proposal.
Page 6 of 121
Volume I
17 Validity of Proposal Proposals must remain valid 180 days after

the Submission date.
18 Method of Selection Quality and Cost Based Selection (QCBS)
19 Bid Submission  Bid Submission will be online through

https://eproc.cgstate.gov.in only.
 Bidders are required to submit One Original
Hard Copy of Pre-Qualification & Technical
Evaluation Documents, along with Power of
Attorney, Pre-Contract Integrity Pact and in
sealed cover separately between 03:00 PM to
05:00 PM on last date of bid submission.
Financial Proposal should not be
submitted in hard copy.
 Please note that only online bids will be
considered for evaluation of offers.
 Certification by the bidder that online and
offline documents are identical in all respects
as per Annexure- IX of Vol II.
20 Contact person for queries CEO, CHiPS
Office of CHiPS, Civil Lines Opposite New

Circuit House, Raipur- 492001
Phone: 0771-4014158
Email : ceochips@nic.in
3 About Chhattisgarh
Chhattisgarh, a 21st century State, came into existence on November 1, 2000. Larger than Tamil Nadu,
it is just the right size, and is also fortunate to have a low population density. Good Governance is the
highest priority in this Fast Track State. There is both policy stability as well as political stability.
Page 7 of 121
Volume I
Government has been kept small and the State is in excellent fiscal health. Chhattisgarh is truly a land
of opportunities. With all major minerals including diamonds in abundance, it is the richest State in
mineral resources. There are mega industries in Steel, Aluminium and Cement. Chhattisgarh
contributes substantially to the Human Resources of India.
Several hundred students from the State qualify for admissions in prestigious academic institutions
every year. Bhilai, the knowledge capital of the State, alone sends over 50 students to the elite Indian
Institutes of Technology every year. It is large power surplus is attracting power-intensive industries,
and the State is poised to become the power-hub of the nation. Its central location helps easy power
transmission to any part of the country. 12% of India's forests are in Chhattisgarh, and 44% of the
State's land is under forests. Identified as one of the richest biodiversity habitats, the Green State of
Chhattisgarh has the densest forests in India, rich wildlife, and above all, over 200 nontimber forest
produces, with tremendous potential for value addition. One third of Chhattisgarh's population is of
tribes, mostly in the thickly forested areas in the North and South. The central plains of Chhattisgarh
are known as the “Rice Bowl” of Central India. Female literacy has doubled in the last decade, and
male literacy is higher than India's average. Gender ratio is next only to Kerala. Bastar is known the
world over for its unique and distinctive tribal heritage. The BastarDashera is the traditional
celebration of the gaiety of tribal. Many virgin, unexplored tourism destinations are there is all the
parts of Chhattisgarh.
4 About CHiPS
CHiPS, a Registered Society promoted by the Government of Chhattisgarh, is the nodal agency and
prime mover for propelling IT growth and implementation of IT plans in the State. The Hon’ble Chief
Minister heads the High Powered Governing Council of CHiPS It includes Minister for Finance &
Commercial Taxes, Minister for Commerce & Industry, Minster of IT, and Minister for Education,
Minister for Panchayat & Rural Development, Chief Secretary, and a representative from the Ministry
of Information Technology in Government of India and eminent persons from IT industry. A
professional approach is being adopted for the implementationof IT Projects u sing the services of e-
governance experts and consultants from corporate and academia.
Key Project Undertaken by the CHiPS
 State Wide Area Network -CG SWAN

 E-District(Online G2CServices)
 Common Service Centres (CSC) –Rural CHOiCE
Page 8 of 121
Volume I
 Geographical Information System (GIS)

 e-Procurement
 State Data Centre
 Crime and Criminal Tracking and Network System (CCTNS)
 ShaalaKosh (erstwhile COSMOS)
 Digital Secretariat
 36-Inc
 CM Fellowship
 Bharat Net
5 Background Information of Digital Secretariat 1.0
The Digital Secretariat project bought in a radical change in the existing workflow of government
offices of the Indian state of Chhattisgarh. The project achieved the automation of official work flow
for State Government employees.
The system replaced manual file processing in the state secretariat, thereby reducing the time
consumed during file movement, improving archival facilities, and increasing efficiency. The workflow
system also mapped the roles and responsibilities of all levels of government officials for electronic
movement of files. The scanned copy of supporting documents enabled instant reference and
facilitated quick decision making.
HRMS, a module within the project, is a digitised database of all state and district officials. HRMS
model helped achieve information exchange between departments, informed decision making by the
secretariat, extensive monitoring and evaluation of employee records.
The Project was inaugurated by Hon’ble Chief Minister Govt of C.G. on 1 st of October 2013. The system
used e-Governance as the tool to improve the Accountability, Transparency and Effectiveness in
Government administration.
5.1 Key Features

● Establishing less - paper working in office. Enable proper digitization of all records of
individual departments
● Online DAK/File creation, marking, comments, adding documents, noting and referencing
● Aadhar based e-Sign & (Digital Signature Certificate) DSC Integration for document signing.
Secure and fast
● Send DAK/ file online to inter and intra department users. Real Time tracking of DAK & Files
● Schedule meetings through the system
● Department / Section / machine level mapping of users to prevent any unauthorized access.
● Automate the leave process flow
● Generation of Salary Slip of employees every month
● Online IPR submission
Page 9 of 121
Volume I
5.2 Current Implementation Status:
● 2 Lakh+ files covering 1.36 Cr records across 48 departments digitized and uploaded
● DAK Management, File Management, Meeting, Support Ticket, Leave , ACR, MIS Reports and
IPR have been developed
● Travel Management, EIS, Salary Slip generation modules have been developed.
● More than 2.5 Lakh DAK/File Transaction in State Secretariat
● Over 1000 staff from State Secretariat trained thrice
● 48 departments are using this system in State Secretariat
● HRMS – Implemented Employee Management, Leave, Property Return and Annual
Confidential Report Module
● Available through Android and Hybrid Mobile App
● The Customized System implemented in WCD (e-docket) ,NRDA( Bank guarantee), AG Office
( Court Case Management) and e-Vidhan for CG Vidhansabha with necessary digitization
operation
● DSC/e-sign has been integrated in the system
● DS System received SKOCH award
5.3 Description of Modules
The Office Automation Application suite has been developed through which the processing of
letters and files can be managed, moved and tracked. List of Modules developed in system are
given below
DAK Management: DAK Management automates the processing of DAK. This includes creation of
DAK (electronic and physical both kind of DAK), movement of DAK in the workflow, tracking of
DAK and their management.
Following features have been developed in this module:
 Unique numbering for every DAK

 DAK Inbox, Sent box and disposed box for user
 Mark DAK as Confidential
 Forward multiple DAKs at a time and forward DAK to group
 Move important DAKs to custom folders
 Status tracking of DAK like Seen, Unseen, In File, Not in File, Collecting Info and Disposed
 Create new file from received DAK
 Add DAK to a existing file
 SMS and email notification
File Management:The File Management shall be automated to cater to the file processing
requirements of Secretariat. It shall ensure that files dealing with any subject in any department
are processed in a similar manner. This includes Creating Inward/Outward, Creating File and moving
it, Monitoring File and Tracking, Generating Order and Maintaining record room for Files and
Correspondences.
Page 10 of 121
Volume I
 Unique numbering for every File

 File Inbox, Sent Box and Draft Box for user
 Notesheet and correspondence view
 Online noting , Document & Comment referencing and forwarding
 Create Part files
 Add DAK in file from file inbox
 Set priority and time limit of File
 Digital Signature integration for document signing
 Department / Section wise access to view file.
 Share noting and documents as a draft for review
 SMS and Email Notification on receiving
 File Tracking –Subject, number, user and date wise
 File access management for users
Sample illustration of workflow
Meeting Management and ATR: Meeting Management Module brings productivity into regular
meetings such as weekly, review and project meetings. From creation and scheduling of meetings
to attaching agenda and minutes of the meeting, and action to be taken, collaboration is made
effective. The module also enables cancellation, postponement and nomination of another team
member if the original participant is unable to attend. Post-meeting actions can be assigned based
on the MoM for generating the Action Taken Report.
Page 11 of 121
Volume I
 Committee Creation with documents

 Add members in the committee
 Schedule meetings, update, postpone, cancel meetings
 Upload proposed , final agenda and MoM
 Create Action Taken Report – Assign tasks to depts.
 ATR follow up and reports
Sample illustration of workflow
HRMS Module:The Human Resource Management System (HRMS) Module redefines routine HR
processes into intelligent processes that promote proactive decision making. For instance, leave
management, includes advanced features like apply, cancel, extend and edit along with automatic
assignment of DAK/File to the Link Officer. The HRMS module also includes travel management, IPR
returns, a centralized employee information system and the generation of the Annual Confidential
Report.
 Employee Information System

 Leave Management System
 Travel Management System
 Immovable Property Return (IPR)
 Annual Confidential Report
Support Ticket Module: With the Support Ticket Module, Digital Office provides users with a single
Page 12 of 121
Volume I
window issue resolving platform, with built-in SLA (Service Level Agreement) information. Tickets
can be raised for oneself and on the behalf of others, which will be queued for the technical team.
The module also enables users to provide valuable suggestions.
 System defined SLAs

 User module – create a new support request, track request
 Admin module – Provide resolution
 Escalations
 Convert to CR and PT
 MIS Reports
5.4 Digital Secretariat Current Environment
Service Delivery Channel Direct
Service Category G2G
Project Component Digital Secretariat 2.0 , Mobile App, WCD

eDocket, AG Office MIS
Number of Users 2000 +
Hardware At Chhattisgarh State Data Center
Network CG-SWAN
Digital Secretariat 2.0 The entire development of Digital Secretariat 2.0

Application is based on n-tier architecture which supports
i. Linux environment
ii. Localization (Unicode) support
iii. Public Key Infrastructure (PKI) along with
smart card for Privacy, Authenticity, Integrity
& Non-repudiation;
iv. Aadhar based authentication process
v. MVC (Module View Controller)
vi. ENS (Electronic Notification Scheduler) for
alert messaging.
vii. NMS (Network Management System) for
network monitoring.
viii. Performance monitoring
Page 13 of 121
Volume I
Database The Digital Secretariat 2.0 system utilizes a Postgres

database on the Linux operating system. Robust
authentication features ensure the security of
confidential information.
Servers ● Application Server – wildfly-17.0.0.Final and

JBOSS 7.1.1
● Web Server – Apache
5.5 Critical elements of Digital Secretariat 1.0

5.5.1 Logical Architecture
Page 14 of 121
Volume I
5.5.2 Physical Architecture

Vi ew
JSP / Reque st
Controll er
Busine ss L ogic
(API, Schedu ler, Authen tication)
DAO
Obj ect Rel atio nal Ma pping
Model
(ORM)
Database
Page 15 of 121
Volume I
5.5.3 Deployment Architecture
Page 16 of 121
Volume I
5.5.4 Existing Hardware Details
NO OF
Environme Server Make CP PROCESSOR RAM
PROCE HDD OS
nt Type /Model U (Ghz) (GB)
SSOR
Dell EMC Intel Xeon

Application PowerEdge Silver 4110 2.10
UAT Server R540 2 8 Ghz 256 2.4 TB *3 CentOS
Dell EMC Intel Xeon
Application PowerEdge Silver 4110 2.10
Production Server R540 2 8 Ghz 256 2.4 TB *3 CentOS
Database
Server( Dell EMC Intel Xeon
Postgre SQL PowerEdge Silver 4110 2.10
Production 12) R540 2 8 Ghz 256 2.4 TB *3 CentOS
Database Dell EMC Intel Xeon
Server(Postg PowerEdge Silver 4110 2.10
Production re SQL 12) R540 2 8 Ghz 256 2.4 TB *3 /CentOS
6 Project Overview and Definitions of Digital Secretariat 2.0
Digital Secretariat 2.o aims to streamline, automate and digitize each department’s execution arm i.e
the directorate and all its offices till district level.The vision of the Digital Secretariat 2.0 Project is to
provide complete digital experience to Government Employees. This will enhance the efficiency and
transparency in administration through the implementation of a comprehensive online workflow
application in all the departments of Government of Chhattisgarh.
The project will bring IT enabled transformation in the Government operations.DAK disposal from
Directorate till district office will be online. Application will be enhanced and revamped to support
state wide rollouts.
Digital Secretariat 2.0 also aims to implement an iHRMS(Integrated HRMS module) that will
automate and digitize all processes of employees from Recruitment till retirement throughout their
service period.The Project will also integrate iHRMS with e-Karamchari,e-kosh i.e. Integrated Finance
Management System.
The Digital Secretariat 2.0 proposes to develop microservices architecture based, API enabled
technology components that will cater to the entire G2G delivery life cycle in the state. These
Page 17 of 121
Volume I
technology components aim to transform the efficiency, effectiveness and user experience of how
government operations are executed.
When the functionalities/modules are used by State Government employees,the mobile or web
interface would redirect to the underlying workflow application. The government authorities can also
view applications and provide approvals online.
After confirmation of the action, it will be routed through a workflow specified in theworkflow
application. This will be a low code/no code application, which can help state government line
departments to execute their daily or HRMS related operations in a rapid turnaround time.
Helpdesk application and support services will be available to all the stakeholders and end users in
the government who will use the applications and modules created under Digital Secretariat 2.0 .
In order to ensure smooth functioning of the different technology components, along with continuous
uptake of these new systems under Digital Secretariat 2.0, “Train the Trainer” concept will be adopted.
Their role will be to support government functionaries at the government offices to onboard a new
feature/functionality, customize an existing functionality or assist in any technical challenges they are
facing using the new systems under Digital Secretariat 2.0.
Objective of Digital Secretariat 2.0:

A brief of key objectives of this project are as follows. The detailed scope of work emanates from these
set of key objectives outlined below:-
Efficient Government of Chhattisgarh envisages to build an efficient system that

will cater office automation and Human Resource management
services
Scalable The system should be scalable. All Govt. offices will use this system as
single source of information related to office and resource
management. Integration with other State owned and Got systems will
be possible through this system.
Standardize The letter/ file management system should be as per central secretariat
guidelines. Other modules would also be developed and implemented
as per standards and guidelines set by GoCG
Reduced cost The system would be able to reduce Govt cost by obsoleting use of
paper, un-necessary travel, stamp and courier cost, resource cost.
The proposed system should use proven open source technology to
reduce s/w licencing cost.
Page 18 of 121
Volume I
self-sustainability The system would be sold to any other State Govt/PSU/Central Govt.
after successful implementation in Chhattisgarh. CHiPS will own its
propriety license on behalf of GoCG and generate revenue through this
system.
Definitions
Dak –All communication received/issued by an
office/department.Includeseverytypeofwrittencommunicationsuchasletter,telegram,interdepartmen
talnote,file,fax,e-mail,wirelessmessagewhichisreceived,whetherbypostorotherwise, in
anydepartmentforitsconsideration
Department –Any of the Ministries, Departments, Secretariats and Offices mentioned in the First
schedule to the Government of India (Allocation of Business) Rules, 1961, as amended from ti me to
time. Means any of the Ministry, Department, Secretariat and Office mentioned in the First Schedule
to the Government of India (Allocation of Business) Rules, 1961
Section Means the basic work unit within a Department responsible for attending to items of work
allotted to it. It is generally headed by a Section Officer and includes ‘Cell’,’Unit’ and other like terms.
Note Means there marks recorded on a case to facilitate its disposal , and includes a summary of
previous papers , a statement or an analysis of the questions requiring decision , suggestions
regarding the course of action and final orders passed thereon.
File A collection of papers on a specific subject, assigned a number and consisting of one or more of
the following parts:
(a)Notes
(b) Correspondence
(c) Appendices to Notes/ correspondence
Note -The remarks recorded on a case to facilitate its examination and decision.
iHRMS – iHRMSprovides a simplified solution to employees and admin to access their relevant
information like leaves, staff handbook, Service book, Annual Confidential Reports, Postings and
many other important details relevant to their employment which covers the complete cycle from
onboarding of an employee to their retirement with authorized access to the information available for
various roles.
Page 19 of 121
Volume I
Ensure the Continuity

The support of its incubentSystem Integrator is going to expire soon. As Digital Secretariat is one of
the flagshipproject of Government of Chhattisgarh, and plays very important role in delivery of Govt.
to Govt. (Government to Government) services, the primary objective is to ensure the continuity of
Digital Secretariat Portal so that uninterrupted services for Mantralaya and various govt. offices
continue. This includes renewal of IT support and other software subscriptions and enhance and
revamp existing system so that it can be implemented at state level.
Following are the list of G2G (Govt. to Govt.) services which will be impacted if this project is
discontinued
Mantralaya Services-
DAK/ File Tracking - With intuitive features such as unique numbering for every file, online noting
with document and comment referencing, the ability to set time and priority meeting, file tracking,
department and section wise file access, and digital signature integration, Digital Office ensures faster
meeting of deadlines and increased collaboration. Automate the workflow of DAK and File handling
through, user can create new file put online note and digitally sign the documents.
Online Leave apply, approval – Leave management as per the rule of Govt. of Chhattisgarh,
system automates the workflow of leave approval. Option has been provided to user fo cancel, reject
and edit leave.
Online IPR filing – Immovable property declaration module through system, it automates the
process of IPR filing.
Online ACR filing – Appraisal system for government employees
Online DAK disposalfrom CS office to all departments which includes TL DAK Tracking.
Online file disposal

Online meeting management system in CS Office which includes scheduling committee
meetings through system, ATR
Other Government Department’s-
Vidhan-Sabha Portal (integrated with Digital Secretariat)- In which all departments upload their
Annual Report and Financial Budget which is published in e-Vidhan-Sabha portal.
In Advocate General office- court case management system.

Page 20 of 121
Volume I
Naya Raipur Development Authority (NRDA)- DAK, Bank Guarantee Module is used in Naya Raipur
Development Authority (NRDA)which is also integral part of Digital Secretariat Portal.
R.S.C.L. (Raipur Smart City Ltd.) - File, DAK, Leave Module used in RSCL
WCD – e-docket- - Integrated part of Digital Secretariat which is used in Women and Child
Development department use this portal for movement of letter.
SO one of the very important objective of Digital Secretariat 2.0 is to ensure that existing services
continue uninterrupted for next 5 years.
7 Detailed Scope of Work
Government of Chhattisgarh has envisaged the requirement of a new version of Digital Secretariat
Phase 2 System as a centralized web cum mobile based application which can be accessed by
departmental officials of various departments/ agencies of Government of Chhattisgarh across the
State either on secured intranet and internet using several devices like Laptop, PC and Mobile
Tablets/iPad.
The minimum specified work to be undertaken by the bidder for setting up and operating project has
been categorized as under. However, the SI is expected to conduct a detailed requirement gathering
for validation of requirements already enlisted as a part of this RFP. The SI will have to meet any other
requirements, not listed in the scope of work that may be required in order to establish the fully
functional Digital Secretariat 2.0 system.
Digital Secretariat 2.0 is an umbrella term given to the multiple technology components that will be
developed and is under the scope of work. All the components should be based on Microservices
architecture and be API enabled.
The overall scope is as follows: -
SN Items Scope of Work
1 Knowledge knowledge transfer from the incumbent SI managing existing Digital

Transfer and Secretariat project and project planning for entire 5 years
Project
Planning
2. Application Design, customization/development, test, deploy and maintain
Development application for proposed system .Application Development will be in
3 phases
Page 21 of 121
Volume I
SN Items Scope of Work
3 Central  Establishment of a Centralized Helpdesk at Raipur/Naya Raipur

Helpdesk to provide technical, training and Informational support to all
the users (Internal users) through Toll free number and via email
 Management of Helpdesk Operations by deployment of agents
during the period of contract.
4 Operation and  Establishment of a O&M Team for to provide additional
Maintenance customization/development of new modules, feature
enhancements, defect fixing, etc. during the period of
contract.
5 Training Train the Trainer training - The prerequisite of conducting a TTT
training session is to identify the Master trainers from within the
organization, who would act as the project champions and have
adequate knowledge and information about the usage of System.
These master trainers may be identified from the HQ/Zonal/district/
level
Field Level Training -
The Field level training is more of an operational training to the

HQ/Zonal/District staff and would require both the service provide
and the master trainers to impart the trainings at various levels. This
would include both classrooms based and self-learning modules as
training delivery mode.
6 Data Migration Migration of existing data to new system.
During the years of O & M period any migration activities required to

carry out due to change in Infrastructure, Software, etc. should be
done by O&M team.
7. Integration System Should be based on open standards and have API support for
Scope data import & export so that integration with the Common Services
can be done.Integration with IFMS (Integrated Finance Management
System), e-docket etc. is proposed.
1. Integrate with the existing set of state and central government applications and be future
ready for API based integration with upcoming software applications of CHiPS, APIs for
which will be provided to the SI by CHiPS.
2. Maintain and support of existing Digital Secretariat system. The incumbent SI of Digital
Secretariat needs to be relieved from its duties once selected components of Digital
Secretariat 2.0 are operational. Therefore, different components will go-live in three
Page 22 of 121
Volume I
different phases, with the components having dependency on the incumbent SI going live
first. After that, development of other phases components will continue and go-live.
During this development phase , Basic operation and maintenance of existing DS 1.0 and
components which have gone live will also continue
3. Once, all the components of Digital Secretariat 2.0are live, the major maintenance and
support phase will continue for a period of 4 years.
It must be noted that entry/start criteria for each phase of the project is dependent upon approval of all
the required deliverables (if any) from the previous phase
7.1 Knowledge transfer and Project Planning
1 The SI will have to take a detailed business knowledge transfer from the incumbent SI managing
Digital Secretariat project. The SI will have to undertake guided System Study from the existing
Digital Secretariat .SI and CHiPS officials to understand the existing functioning, Portal
functionalities, manpower structures and any other business information required to formulate the
project plan. Studying of codebase is optional, as the SI may choose to go for fresh development or
customization and prepare a plan accordingly.
2 .Responsibilities of the SI during the Knowledge Transfer Phase shall include the following
(including but not limited to):
i. The new SI will be required to submit a detailed Knowledge Transfer plan at the start of
the KT phase, listing all the activities from their end, including the expectations from
existing SI and CHiPS. A checklist (as part of knowledge transfer plan) needs to be prepared
by the new SI for ensuring proper knowledge transfer. This shall be reviewed and subject to
approval by CHiPS.
ii. The existing SI shall provide all knowledge transfer of the system to the incoming SI to
the satisfaction of CHiPS as per the specified timelines.
iii. The knowledge transfer shall include initial and ongoing training on existing software,
training materials, operations manuals, procedure manuals, source code control and
deployment/ installation guide.
iv. The existing SI shall conduct detailed Knowledge Transfer sessions for the new SI (such
sessions should be recorded by the new SI for future playback) and shall concentrate on the
following:
a) Study of the functional specification documents including the SRS, enhancements log,
user manual documentation of business processes, presentations to CHiPS to confirm
Page 23 of 121
Volume I
understanding
b) Identification and deep dive into all available documents (like SRS, enhancement log,
design documents, User Manual etc.)
c) Details of integration with other systems
d) Details and access to the codes, scripts, jobs, etc. for study and assist in understanding
the documentation of existing Digital Secretariat 2.0 and its various components,
understanding of development, support processes, configuration management processes,
etc.
e) Understanding of various environments (development, UAT, Production etc.), and
obtain training on all the existing tools used, processes followed, and activities performed
is optional as the SI will be expected to set up its own environment in cloud.
f) Understanding of existing client end infrastructure and network management, including
the role of SPOCs and other stakeholder’s profiles
g) Walkthrough of the helpdesk setup and solution.
h) Understand the applicable IT policies and their respective status
i) Understanding of all existing issues in existing Digital Secretariat 2.0 IT landscape and
their impact; the issues faced by the existing SI while implementing and managing the
existing solutions and the resolutions for the same; and also, of any special behavior (if any)
exhibited by the overall solution or the integrated applications.
3. It is clarified that new SI is required to deploy technically competent resources, in the specific
solution areas of existing Digital Secretariat 2.0, during the KT phase and Transition phase.
The existing SI shall not be responsible for imparting any basic technical skillset to the
resources of the new SI, which would be deemed as a pre-requisite.
4. The new SI is required to utilize this time in the most efficient and effective manner, to ensure
complete business knowledge of existing Digital Secretariat 2.0. The new SI should deploy its
project management, domain as well as technical manpower to absorb the KT sessions. They
should conduct site visits to get an understanding of the requirements as and when required.
5. The new SI will be required to submit a weekly status report on the progress of KT activities
6. During this phase, the new SI shall be required to submit a report on the detailed
understanding of existing Digital Secretariat 2.0 system and operations, which will be
reviewed by CHiPS and this will form the basis of start of the design phase.
7. The SI needs to prepare an Integrated Project Plan for the entire project. Project plan should
provide a detailed drill down and interdependencies of all activities to be undertaken. This
includes details of tasks, assigned teams for undertaking responsibilities for the task, schedule of
Page 24 of 121
Volume I
deliverables and milestones, key assumptions and dependencies, associated risks and mitigation
plans.
8. The SI’s work plan should be synchronized with the staff deployment plan proposed;
The deployment plan shall clearly define onsite and offsite deployment plan and personnel under
each deployment category along with engagement period for the project.
9 .The SI should preferably use cloud-based project management tool and provide access to the
same to key stakeholders identified by CHiPS. The tool should provide all features related to
project management requirements of the project. Also, the PM tool should preferably have
function to auto update stakeholders over Email/SMS.
10. SI at any point of time during project cycle may have to adopt and use project management tools
provided by CHiPS.
11. The prepared project plan should allow teams to track the progress of various deliverables and
milestones, through the scheduled review mechanisms.
12.The acceptance of the Integrated Project Plan by CHiPS is necessary before proceeding to the
next phase of the project.
13 .Approval by CHiPS of the proposed plan shall not relieve the SI of any of his duties or
responsibilities under the Contract. However, if the SI’s work plans necessitate a
disruption/shutdown in project operation, the plan shall be mutually discussed and developed
so as to keep such disruption/shutdown to the unavoidable minimum.
14. Considering the long-term nature of this project, the SI may make reasonable assumptions for a
time period beyond two years from project kick-off and provide a top level programof work. This
could be detailed further on a quarterly basis as the time horizon for which the program of work
has been created draws closer.
15.The plan so submitted by the SI shall conform to the requirements and timelines specified in
the RFP.
16 .Any time and cost arising due to failure of the SI to develop/adhere such a work plan shall be
to his account.
Note: The list of deliverables are given below, further a detailed list of deliverables have been
provided in as per Project Timelines, Payment Terms & Schedule of RFP Volume1.
Deliverable(s):
1. Integrated Project Plan including:
a) Milestones
b) Resource deployment
c) Risks and their mitigation plan
Page 25 of 121
Volume I
d) Dependencies
e) Responsibility matrix
2. Configuration of Project Management Tool
3. Submission of Project Charter to include:
a) Risk Management and Mitigation plan

b) Information Security Plan
c) Communication Plan
d) Data Migration plan
e) Training and change management Plan
f) SLA Monitoring and reporting plan
g) Exit Management Plan including transition management
4. Project Plan Presentation to CHiPS
5. Other deliverables include O&M Plan, Test Plan along with User Acceptance Test Plan,
Training Plan, Exit Management & KT Plan and Security Matrix/Plan.
7.2 Application Development

Below are the Technical enhancements envisioned in Digital Secretariat listed below:
1. Entire solution will be hosted on DC-DR architecture for better performance and
services
2. The complete solution will be open source to save licence and development costs in
future.
3. The proposed solution should be platform independent and should support all
Operating systems for with or without virtualization.
4. Restructuring of current application architecture to support open, scalable, Multi –
tenancy and Multi-tier architecture with each tier fully independent with support for
clustering.
5. Entire solution will be available on Mobile app (Hybrid) which will support both IOS
and Android platform. The UI/UX will be redesigned with Tablet, Mobile first approach
then,desktop.
6. QR Code Solution will be integrated with File Management module. All the file related
important information will be captured in QR Code. QR Code will be used for file
tracking where movement of file is physical.
7. Integration with e-Sign, DSC for digital signature, Aadhar based biometeric.
Page 26 of 121
Volume I
8. Integration with OCR Enabled cam scanner in the digitization tool.

9. Integration with whatsapp/ email to share govt. orders, circulars online.
10. The System shall support integrated in - built viewer for viewing documents
(PDF/Word/PPT/Excel).
11. More Technical enhancements will be made in existing portal as per latest technologies
both in web as well as mobile platform.
12. The system shall provide facility of putting text, graphic and image annotations on
scanned document pages.
13. The mobile application should have support for retrieval and archival of documents.
14. System should support integration with Stylus / Voice to text /Touch Screens for text
input
15. Integration with latest open source Business Analytics tool to prepare dashboard which
can give insights in efficiency of file disposal, DAK Disposal, tracking of pendency in
various departments, performance of employees /Departments.
16. Integration of iHRMS with Integrated Finance Management System ( e-Karamchari,e-
kosh)
17. Integration with other State owned and GoI systems will be possible through this system.
18. Onboard diff. departments / directorates to the Digital Secretariat 2.0 solution. This
involves the G2G services leveraging all technology components built under Digital
Secretariat 2.0 . There might be exceptions, wherein the respective state government
line department may want to continue with its legacy system. In this scenario necessary
API based integrations will have to be undertaken and selective technology components
under Digital Secretariat 2.0might be used by the respective state government line
department.
7.2.1 System Requirement Elicitation and System Design
1. The SI will carry out a detailed assessment to prepare the FRS incorporating the
requirements provided by all the stakeholders.
2. As part of the requirement gathering activity, the SI should study the existing Digital
Secretariat application mainly from the business, process and stakeholder point of view. The
SI may choose to reuse or enhance the existing code or may build fresh technology
components altogether. SI needs to work closely with the existing SI for Digital Secretariat and
CHiPS officials to get all the business knowledge pertaining to the application as part of the
scope of work.
Page 27 of 121
Volume I
3. SI will model solution based on the hardware provided by CHiPS
provided inas per Project Timelines, Payment Terms & Schedule clauses of RFP Volume-1
Deliverable (s):
1. Refined FRS covering the functional requirements, data integration requirements, data
management requirements etc.
2. UAT Test C ases
3. Requirement Traceability Matrix
4. Data Flow Diagram (DFD)

Solution Design
1. Preparation of the Software Requirements Specification document containing the business
scope and the detailed description of business and system functions and getting it signed off.
2. The document should contain the requirements providing visual screen shots, portal designs,
login pages, reporting formats etc. for various functions and layouts as part of the system, including
the functions of the systems.
The SI has to consult all the concerned stakeholders and design detailed workflows for all the system
requirements. Detailed workflows need to be designed and signed off from CHiPS. The business
requirements for integration of services/systems will be provided but furthermore
integration points may also have to be diagnosed, diagrams charted out by the SI and accordingly
systems will have to be implemented.
1. The SI should provide detailed wireframes and prototypes demonstrating the User
Interface and User Experience of the proposed Digital Secretariat 2.0 system.
Design Considerations
The proposed solution will provide a holistic guide to implement a high performant, scalable,
extensible and secured system while also provisioning for highest data integrity, least downtime,
reduced maintenance and minimum human intervened support activities.
The key system design considerations and implications are elaborated below .
1) Security and Privacy
The system deals with personal and sensitive data from multiple departments of both in house and
3rd party stakeholders. There are serious cyber security threats to governance applications in general
from external and internal sources as has been brought to light time and again.
Page 28 of 121
Volume I
The system design should provision for a Robust Security as a core feature for Data at Rest and Data
in Motion. Configurable Authentication and authorization with internal and 3 rd Party systems should
be provisioned for. Governance model for Data access should be implemented to revoke and provide
grants to partial contents of a system record. Strong end to end encryption of data (Data at Rest and
Data in motion) must be implemented using applicable measures of strong benchmarked
cryptography, HSM, physical access control, audit trail, monitoring, throttling and robust compliance
processes. System restoration, Impact isolation and recertification of data in eventuality of a Data
breach or Security incident should also be provisioned for.
Security policies and concerns also extend to support and operations personnel. Direct Access to
application servers via ssh, scp, sftp protocols by Operations personnel should be temporary and
restricted to application installation phase. For all practical daily operations, direct access to
application servers via ssh, scp, sftp should be avoided. Instead interfacing Operation Support
applications should be deployed to enable deployments, log analysis. This is important to ensure
security of application data and access trails.
2) Reliability
Given the dynamic, legal and financial nature of the office management system, the sanctity of System
Records and Data accessed through the system is of paramount importance. Responsibility of Data
validation and Data integrity should be restricted to defined Core System components. All System of
Records should have clear Audit trail and anomaly routinues should be set up of early detection and
warnings. System should look to achieve an RPO (Recovery Point Objective) of less than 5 mins and
RTO (Recovery Time Objective) of less than 15 mins. The system is highly transactional and should
support an estimated user concurrency of > 300 while maintaining transactional integrity with
appropriate queuing, messaging, retries and eventing implementations.
Robust certification, validation, benchmarking and onboarding processes for client/extending

applications should be implemented and automated to ensure quality and performance standards. A
federated approach to building the system through an applications eco system over a core platform
will ensure no single point of failure and outages restricted to modular functionality.
3) Scalability
System should be designed to scale both horizontally and vertically by adoption of a loosely coupled
architectural paradigm. A Microservice based approach with clear separation of Data Access, Business
Processing and Data Presentation concerns via creation of Composite services using Granular Services
(Stateless REST APIs) should be adopted. This would provide ability to alter infrastructure for
individual components or modules of the system on demand, as opposed to an overall system upgrade
with higher costs. Asynchronous processing of long running processes and 3 rd Party integrations will
augment system capability, scalability and reduce response time. This approach will allow for
component level tuning, analysis, refactoring and upgrade. Data architecture should provide for a
robust Data indexing and archival processes to support consistent performance with increasing data
volume. Data partitioning and Sharding should be applied to the core data sets. Elastic Search and
Caching augmentation will ensure faster retrieval and reduce complexity and business logic coupling
at application layers.
4) Flexibility and Extensibility
Page 29 of 121
Volume I
The system should be designed as a platform over which client applications can be composed. The
Core platform layer exposes Data access, Workflow and Rule engine features as REST APIs (Open
Standard). This allows a diverse set of independant applications to built over using these APIs. These
federated applications thrive in a Eco system where each of them can be extended, enhanced and
integrated independently thereby allowing for rapid turnaround in inducting the dynamic
requirements both in terms of scale and functionality.
The Core platform should also ensure interoperability of functionality with legacy applications and 3 rd
party systems (ERP implementations etc). This is achieved through In-Channel and Out-Channel
Message Brokers and Data migration strategies. Provisions for Real Time Feed ingestion and
processing should be implemented.
5) Maintainability
The System should feature automated maintenance and recovery as an inherent attribute. Every
component of the system should provide monitoring and metrics gathering interfaces by way of heart
beats, health checks and proactive alerting. Each of the components should be monitored in an non
intrusive manner, metrics obtained such that real time analytical views can be pulled. This is done via
usage of monitoring tools, log analysis both at Network and Application Module level. Module level
issue debugging in a toggeable and secured manner with proper access control should be enabled.
Instead interfacing Operation Support applications should be deployed to enable deployments, log
analysis and metric visualizations. Automated system metric reports should be published with respect
to Performance, Resource Utilization along with configurable alerting thresholds.
A layered approach to Testing the system components should be provisioned where eco system
components can be stubbed, allowing for more agility, reduced inter team/application dependence,
faster issue detection, analysis and mitigation.
Solution Architecture
The SI will develop a detailed design document that meets the users’ requirements captured in the
previous activity. In this activity, the SI shall be required to perform at least the below mentioned
activities:
1. Preparation of Digital Secretariat 2.0 Solution Architecture specifying the Functional,

Infrastructure, Data, Deployment, Network and Security Architecture for the proposed
application.
2. Preparation of Digital Secretariat 2.0 System Design Document specifying the construction
details of the system, each system component’s interaction with other components and
external systems, and the interface that allows end users to operate the system and its
functions
3. Development of Security Plan
4. Dashboard and Analytical Report design
5. Exceptions and Business Alerts definitions.
Page 30 of 121
Volume I
1 General
Guidelines 1. Solution components should be based on open source technology
and should be provided with necessary support
2. The solution design should be based on open industry standards

and protocols
3. The solution should be centrally deployed and globally accessed
4. The solution should provide interoperability across Cloud and on-

premise providers, platforms.
5. The solution should utilize “best practices” and should preferably

follow design driven architecture.
6. The solution will have to use microservices basedarchitecture

for all environments Container Architecture.
7. The solution should be modular, scalable and may be flexible as a

true ‘Cloud Deployable’ solution.
8. Mobility services (mobile applications) should be a key .solution

component i.e. all the features can be accessed through mobile
applications.
2 Application 1. The solution design should be on microservices based

architecture for all environments.
2. The solution design should focus on developing workflow and
business transaction,rulesmanagement,configuration
management.
3. The solution design should be done in such a manner that
components are loosely coupled; ensuring that the application
components are treated individually, and dependencies are
reduced. The SI should ensure that addition, removal, failure or
update of one component has a minimum impact on other
components.
Page 31 of 121
Volume I
4. The SI should ensure that services should be written in such a way

that they can be automated for testing. Test automation is
necessary to ensure services can be upgraded, re-factored, etc.
without breaking other services that use them. The SI should
ensure that all services should be inherently versioned, and all
invocations must specify the version of service.
5. The SI should ensure that new versions of services should be
backward compatible with at least one or two previous versions so
that users of the service can start using new version of the service
without mandatorily making changes to their code.
6. The solutions design should provide for service abstraction, to
control what part of the service logic of an application needs to be
private (hidden) and which parts need to be made public
(consumable).
7. The solution should not only be modular in nature but be
adaptive to converse with other technology components such as
platforms and databases, complete with management suites or
with the induction of adaptors and interfaces or even smaller
bespoke solutions to support the same.
8. All applications must take into account appropriate security,
performance, efficiency and maintainability issues based on the
functional, technical and non-functional requirements and the
defined SLAs.
9. The SI needs to set up, operationalize and maintain system for

APIs and web services.
10. While doing application development and maintenance the SI is

expected to follow and comply with the processes as per CMMi
Level 5 standards.
11. The IPR for the Digital Secretariat 2.0 Solution would be with
CHiPS.
12. The ownership of the product licenses, wherever applicable

,would be with CHiPS. Nature of licenses must be perpetual.
Page 32 of 121
Volume I
13. The solution must be supported by at least ‘N-1’ versions of any

underlying products. This will be required in case some / other
functionalities become non-functional upon deployment on the
latest version, or in case a roll-back is required.
15. The SI shall provision for following environments –
a. Development environment
b. Testing /UAT / Pre-Production/Staging environment
c. Sandbox (for API deployment)
d. Production environment
3 Data 1. Data will be owned, shared, controlled and protected as a
corporate asset of the CHiPS.
1. Data should only be accessed through application / interfaces for

create, update and delete. There should not be any direct access
to the data layer for users.
2. The SI shall provide the details of data synchronization strategy
both in batch mode and in real time. CHiPS, in consultation with
SI, shall decide on the methodology of data synchronization based
on service requirements
3. Data Entry: All the data entry in the system shall be bilingual
English and Hindi (Unicode). System should support both
languages
The diagram below depicts the envisioned solution components and application layers.
Segregation of Data access and Application Business Logic concerns will ensure extensibility and data
integrity of the system while decoupling the custom logic from the core system design.
Page 33 of 121
Volume I
Presentation Web Apps – CG Mobile Apps –

Monitoring Suite
DS , Support CG DS, Support
Client Applications
3 rd Paty A uth
Services
File Mgmt Meeting Correspondence
(LDAP/AD/UiDAI)
SMS Gateway
Business Legal Case Annual Report Attendance
Logic Email
Federation
Office Bulletin HRMS RTI
Legacy Apps
Feed Aggregator Social Integration ...
ERP/COTS
Integration
Application APIs (Extension)
Authentication & Content

User Provisioning
Authorization Management
File/Document
Reporting
Core Rule Engine Workflow Engine Store
Framework Out Channel
Data
Broker (Export) Cache/
Access
Entity Metadata Event Queue Elastic
Scheduler Search Data
Provisioning Manager In Channel
Broker (Feeds)
Audit & Logging Notification &
... Message Brokers
Framework Alerts
(Exchange)
Core Platform APIs (Data Access) Data Store
Core Platform APIs

The Core platform APIs contain the generic nucleus of Workflow management, Content Management
logic and algorithms. This layer is solely responsible for direct persistent storage access, System of
Record, data retrieval and manipulation. Core workflow management logic is exposed as a generic
data API, using which wrapper Application APIs can be built to enhance and extend functionality.
These APIs will ensure appropriate validation and data integrity of the system records.
Application APIs – Extensions

These APIs encapsulate the functional requirements and Data Aggregation responsibilities using the
Core Data Apis tolookup and manipulate persistent data. These API implementations encapsulate all
module specific business logic and exposes the business functionality through REST APIs for
consumption and representation by upstream applications.
Client Applications
Client Applications which provide the User interface and represent the authorized data on the end user
device. These applications are typically Web applications and Mobile client Apks. They consume the
Application APIs for data and are responsible for providing the intuitive human interaction interfaces,
Dashboard and encapsulate all end user view logic. All Web security threats are mitigated at this layer.
Integration Handles
Page 34 of 121
Volume I
This component implements a Data exchange broker to ingest data from external applications into the
system by way of a Data handling pipeline (preprocessing, rejection, data sync).This component allows
for integrating the system with 3rd Party enterprise products and data interchange.
It is also responsible for exposing data feeds from the e-office system to subscribed applications in a secure
manner.
provided in as per Project Timelines, Payment Terms & Schedule clauses of RFP Volume-1
The deliverables for this activity are mentioned below:
1. High Level Solution Architecture Document (including ER Diagram and Data Flow
Diagram)
2. High Level Design Document and Low-Level Design Document (including Schema
Diagram)
3. Detailed Solution Architecture, including:
o Application architecture
o Data flow architecture
o Enterprise architecture
o Database structures
o Security architecture
o Integration architectures
o Network architecture
4. Use Cases
5. Application delivery checklist
6. UI/UX prototypes and wireframes
7. All Policy, Plan & Methodology Documents covering aspects mentioned above
7.2.2 Solution Development, Testing and Go-Live of Digital Secretariat 2.0
Development of Digital Secretariat 2.0
1. The SI shall develop the software in accordance with the approved requirement specifications,
design specifications, and according to the project plan and carry out the unit testing of the
software in accordance with the approved test plans. The overall Digital Secretariat 2.0setup shall be
implemented in following environments i.e.
Page 35 of 121
Volume I
a) Development environment
b) Testing environment/UAT environment/ Pre-Production/Staging environment
c) Sandbox (for API deployment)
d) Production environment
2. The SI needs to provide software configuration, customization and installation reports to CHiPS.
3. The SI should ensure solution sustainability to meet all RFP requirements, any additional
procurement required will have to be taken by the SI with no additional cost to CHiPS
4. Other related requirements are mentioned below:
a. The application software developed by the SI must be user friendly so that users can access
it without having extensive training.
b. The lifecycle for each phase should be independent, i.e. different teams should work in
parallel to complete the track activities per the given timelines.
c. The SI shall also supply any other tools required to complete the integrated solution
requirements. For the integrated solution, the SI shall supply:
i. S oftware & p erp etua l licen se s
ii. Tools, documentation and prepare a list of items supplied. Tools shall be part of the
solution. SI should provide technologies matrix.
iii. Supply latest supported version of all software to support the solution and any
other software, tools and bolt-on/add-on application.
iv. System Documentation both in hard copy and soft copy.
The deliverables for this activity are mentioned below:
1. Development of all components of Digital Secretariat 2.0 as explained at the start of scope
of work section
2. Delivery of Software , Operational/ Technical manuals, Library Files, Setup Programs etc.
3. Integration of all standalone systems developed and enhanced. Also, integration with other
strategically important applications or systems identified during requirement gathering
phase.
4. Unit testing results.
Page 36 of 121
Volume I
5. Solution Testing.
Planning for testing

1. Once the SRS is approved and design has started, the SI would refine all necessary Test Plans
(including test cases), i.e., plans for Unit Testing, Performance Testing, Integration and
System Testing and User Acceptance Testing.
2. Test cases for UAT would be refined by SI and approval of the same is to be obtained by CHiPS.
3. The Test Plans also include planning for the testing to demonstrate the ability to integrate with
3rd party solutions. The Test Plans should also specify any assistance required from CHiPS and
should be followed upon by the SI.
4. The SI is required to get a sign-off / approval on the Test Deliverables (Strategy, Plan,
Designs and Specifications etc.) in order to commence the testing for the proposed
solution.
5. The SI is required to make all necessary arrangements for testing (integration, system,
functional and user acceptance) including the preparation of test data, scripts where
necessary; and procurement and setup of test environments shall be the responsibility of the
SI.
provided in as per Project Timelines, Payment Terms & Schedule clauses of RFP Volume-1.
Deliverable(s):
 Refined Test Plan

 Refined Test Design
 Final Test Case Specification
System Testing, Integration Testing, UAT

1. The SI shall run the test cases and test data and get them validated by CHiPS. The test cases
shall be comprehensive covering all scenarios according to specifications, requirements,
and design. The test data shall be comprehensive and address all scenarios identified in the test
cases. The SI should also prepare the test data for all required integrations.
2. There should be provision for all kinds of testing viz. performance, system, integration, load,
performance, stress etc.
Page 37 of 121
Volume I
3. User Acceptance Testing needs to be performed for all the systems developed, enhanced and
integrated
 GAD will nominate representatives from different user groups/depts based on inputs
from the SI and would facilitate UAT. The SI would make the necessary changes to the
solution to ensure that it successfully passes through UAT. CHiPS will facilitate
coordination between GAD and SI.
 It is mandatory for SI to incorporate / consider test cases as part of UAT test cases for
those customized and/or extensions and/or configured functionalities identified
from traceability matrix.
 GAD would issue certification of acceptance for which it shall verify availability of all
the defined services as per the contract signed between the SI and CHiPS. The
System Integrator shall be required to demonstrate all the services / features /
functionalities as mentioned in the agreement. Prerequisite for carrying out UAT activity
shall be:
i. All documentation related to solution and relevant acceptance test

document should be completed & submitted before the final acceptance test
to CHiPS.
ii. The training requirements as mentioned should be completed before the final
acceptance test.
Licenses/ Manuals/ Brochures/ Data Sheets/ CD/ DVD/ Media for all the supplied components should
be provided to CHiPS
Note: The list of deliverables is given below, further a detailed list of deliverables have been
Deliverable (s):
1. Test Data
2. Testing Reports
3. Necessary modification in software for passing the UAT
Performance Testing &Security Certifications

1. Performance testing of the solution would be carried out using the envisaged peak load with
a multiplier, to monitor the application response times and other performance parameters.
Performance testing would be carried out every 6 months to ensure the application
Page 38 of 121
Volume I
performance is as per requirement. Any additional software and any other components
required to meet the performance SLAs, would be provided by the SI at no extra cost.
2. SI is required to submit the report for the performance testing to CHiPS; the testing will be
monitored by CHiPS or any agency appointed by CHiPS.
3. Performance testing would include load / stress testing. This would need to be carried out on
the exact architecture as would be used in the production environment (solution
architecture as well as computing capacity). All necessary tools to carry out testing would be
provided by SI.
4. SI is required to obtain STQC certificate within 3 months of Go-live of all module and must
maintain the same throughout the contract duration
Deliverables:
1. Performance Test Reports
2. Security Certifications
Go – Live
1. For the purpose of RFP, “Go-Live” has been divided into 3 phases.
Go-live phase 1-the enhanced version of all existing modules of DS1.0 with state level
implementation and configuration and customization capability. It will include following
functional components defined in Annexure 1
1. FR01 – Correspondence/Letter Management System.
2. FR02 – File & Office Note Management
3. FR03 – Manual File tracking Management(Public Viewed)
4. FR07 – RTI Query Management
5. FR13 – Court Case Management
6. FR05 – IHRMS (IPR, ACR, Leave Management system)
Go live Phase 2 - It will include following components defined in Annexure 1
FR05 - IHRMS (all its remaining components)
Go Live Phase 3 –It will include all remaining Functional Requirements defined in
Annexure 1
Page 39 of 121
Volume I
The below describe the criteria of acceptance:
Requirement Criteria of acceptance
Functional  The Digital Secretariat 2.0system developed/customized by SI

Requirements shall be reviewed and verified by the CHiPS or its nominated
Review agency or TPA against the functional requirements signed-off
between CHiPS and SI.
 One of the key inputs for this testing shall be the traceability
matrix to be developed by theSI for Digital Secretariat 2.0
system.
 Apart from Traceability Matrix, SI may develop its own testing
plans for validation of compliance of system against the defined
requirements.
 The acceptance testing w.r.t. the functional requirements may be
performed by independent third-party agency (external
auditors) as well as the selected internal department users (for
User Acceptance Testing).
Security review The software developed for Digital Secretariat 2.0system shall be
audited by the CHiPS or its nominated agency or TPA from a security
and controls perspective. Following are the broad activities to be
performed by CHiPS or its nominated agency or TPA as part of Security
Review. The security review shall subject the Digital Secretariat 2.0
system to the following activities:
 Audit of Network, Server and Application security mechanisms

 Assessment of authentication and user control in application,
component or modules
 Assessment of data encryption mechanisms implemented for the
solution
 Assessment of data access privileges, retention periods and
archival mechanisms
 ·Server and Application security features incorporated etc.
Performance  ·Performance is another key requirement for Digital Secretariat

2.0system and CHiPS or its nominated agency or TPA shall
review the performance of the deployed solution against certain
Page 40 of 121
Volume I
key parameters defined in requirements and the service level

metrics described in this RFP and/or agreement between CHiPS
and SI.
 ·Such parameters include request response time, work-flow
processing time, concurrent sessions supported by the system,
Time for recovery from failure, Disaster Recovery drill etc.
 ·The performance review also includes verification of scalability
provisioned in the Digital Secretariat 2.0 system for catering to
the requirements of application volume growth in future.
Availability  Digital Secretariat 2.0 system should be designed to remove all

single point of failures.
 Appropriate redundancy shall be built into all the components to
provide the ability to recover from failures.
 The CHiPS or its nominated agency or TPA shall perform
various tests including network, server, security, DC/DR failover
tests to verify the availability of the services in case of
component/location failures. (Annexure-check)
 CHiPS or its nominated agency or TPA shall also verify the
availability of Digital Secretariat 2.0 services to all the users in
the defined locations.
Manageability  CHiPS or its nominated agency or TPA shall verify the

review manageability of the Digital Secretariat 2.0 system
 The manageability requirements such as remote monitoring,
administration, configuration, fault identification etc shall have
to be tested out
Service level  The Acceptance Testing and Certification agency shall verify the
monitoring accuracy and completeness of the information captured by the
system Service Levels monitoring system implemented by the SI and
shall certify the same.
 The solution deployed for service levels measurement shall be
configured to calculate the penalties as defined in the SLA. The
SI shall provide complete access to the Service Levels
 Reporting System/BI tool including the manner in which the
Page 41 of 121
Volume I
configuration of the system has been done.

 The SI shall provide full access to generate reports from the
systems to CHiPS officials or its nominees.
Project  CHiPS or its nominated agency or TPA shall review the project
Documentation documents developed by SI including requirements, design,
source code, installation, training and administration manuals,
version control etc.
 Any issues/gaps identified by CHiPS or its nominated agency or
TPA, in any of the above areas, shall be addressed by the SI to the
complete satisfaction of CHiPS.
Data quality  CHiPS or its nominated agency or TPA shall perform the Data
Quality Assessment for the entire data
 The errors/gaps identified during the Data Quality Assessment
shall be addressed by SI before moving the data into production
environment, which is a key milestone for Go-live of the solution.
In case there is any shortcoming (which does not impact any of the Service levels) in the
deliverables as above, CHiPS may, at its discretion, permit Conditional Go-Live. However, SI is
responsible for completion of all related pending activities identified within 3 months or earlier of
conditional GO-LIVE. It is to be noted that the next phase timelines shall be initiated at time of
Conditional Go-Live approval.
Note: The list of deliverables are given below, further a detailed list of deliverables have been provided
in as per Project Timelines, Payment Terms & Schedule clauses of RFP Volume-1.
Deliverable(s):
1. Defe ct Reports
2. At the end of Go-Live:
i. Updated system design documents, specifications,
ii. Latest source code, application deployment files, configuration files for entire
solution
iii. Updated user manuals, administration manuals, training manuals etc.
iv. Software change logs etc.
Page 42 of 121
Volume I
Solution Documentation
1. The SI shall document all the installation and commissioning procedures and provide the same
to the CHiPS within one week of the completion of the go-live.
2. The SI shall be responsible for preparing process documentation relating to operation and
maintenance of the solution. The process documents shall be formally signed off by CHiPS.
3. All documentation will be supplied both in Hardcopy and Softcopy format.
4. Each process document shall clearly define the roles and responsibilities, detailed steps for
execution the defined task, detailed configuration steps etc.
5. CHiPS expects the SI to document the operations and management processes as per
standards defined in “Compliance to Standards and Certifications” in Volume 1 of this RFP
7.3 Business & Centralize Helpdesk Support
This track includes setting up a centralized helpdesk support for the from 2nd month onwards after
awarding of contract , meant for smooth user adoption and support of government department
users only. SI will set up the helpdesk and will be provided a space at CHiPS office along with
physical amenities such as office space, internet connectivity, furniture, etc. CHiPS will also bear costs
towards electricity and other physical infrastructure related costs. Laptops & mobile phones along
with helpdesk software costs will be borne by SI.
7.3.1 Helpdesk
Helpdesk will operate on all 7 days (9:00 am to 8:00pm) .Helpdesk will provide technical and
functional support on all modules of DS by phone, email which includes L1 as well as L2 support.
Helpdesk will resolve tickets are in timely and efficient manner as per SLAs defined in Appendix-D
Service Level Agreement
L1 or level 1 support includes interacting with the customers, understanding their problems and
then creating a ‘ticket’ against it. A ‘ticket’, also referred to as ‘incident’ is then routed to the L2 or level
2 support. Sometimes the request/grievance raised by the customer is very minor and can be solved
by the L1 support as well.
L2 or level 2 support manages the tickets which are routed to them by the L1. These
tickets/incidents may require some technical knowledge which the L1 team does not possess, in this
scenario the L2 support takes over.
The minimum services envisaged through the helpdesk includes:
i. Guiding stakeholders on usage of Digital Secretariat 2.0
Page 43 of 121
Volume I
ii. Assisting stakeholders on IT related issues providing status of applications

iii. Escalating business related grievances to right authorities in CHiPS and other
concerned government departments
L3 is the last line of support and comprises of a technical team which addresses the technical issues.
Sometimes the issues reported by customers cannot be solved by L1 & L2 .In that case, the L3 team
analyses the issue and fixes it. The issues which the L3 team gets involved are code/development related
fixes
1.The SI shall select & arrange for the skilled and qualified manpower required for running
the Helpdesk to respond to queries only after they have been provided with proper training as per
industry standards.
2. During the first year, Helpdesk will provide L1, L2 and L3 support on existing solution DS1.0 till
all phases of DS2.0 go Live. Under this minimum 1 resource will provide L1 Support and minimum 2
resources who will provide technical support (L2 & L3) ,will be deployed in CHiPS till Go Live of all
phases.
Additionally, SI need to deploy minimum 5 support staff in Mantralaya for entire 5 year duration who
will provide functional, hand holding support ,trainings in Mantralaya and directorates.
Till Go Live all the phases, SI will be paid separately for O&M of existing solution as defined in
Section.12 Project Timelines, Payment Terms & Schedule. After that Help-Desk will come under into
regular O&M of Digital Government
3. All the issues on logging shall be assigned a severity level based on definition below. Basic
guidelines for assigning severity are as follows:
Severity Definition
Severity 1 problems are the ones which have a critical business
Level 1 impact. These problems will have any of the following
characteristics:
 Complete or part of any service unavailable (including APIs)
 Incorrect behavior of the system
 Security Incidents
Page 44 of 121
Volume I
Severity 2 problems are the ones which have a significant business

impact. These problems will have any of the following
Level 2
characteristics:
Severity 3 problems are the ones which have a minimal business
impact. These problems will have any of the following
Level 3
characteristics:
 No impact on processing of normal business activities

 A low impact on the efficiency of users
 Has a simple workaround
 Enhancement requests
4. All the responses by the helpdesk support team would be recorded and a quality audit would
be carried out by the CHiPS or its representative.
5. To ensure service quality, CHiPS shall conduct regular and random audits.
7.4 Operation & Maintenance of Digital Secretariat 2.0 (post Go-Live)

The SI will operate and maintain all the components of the Digital Secretariat 2.0 System for a period
of four (4) years from the date of Go-Live of Phase 3.
In the each year of O&M, SI need to onboard minimum 5 departments (Directorates) and its district
line offices.
The O&M is divided into the following parts:
7.4.1 Application Support and Maintenance
Application support includes, but not limited to, production monitoring, troubleshooting and
addressing functionality/availability and performance issues and implementing system change
requests etc. The SI shall maintain the application software in good working conditions; and perform
changes and upgrades to the applications as requested by the CHiPS. All tickets related to any
issue/complaint/observation about the system shall be maintained in an ITIL compliant
comprehensive ticketing solution which should be provided as part of Phase 1 Go live. Key activities to
be performed by the SI during the application support phase are as follows:
Page 45 of 121
Volume I
1. A department/Directorate can be said to be on-boarded if it uses atleast 7functional module (as

per Annexure 1) and any 3 components of iHRMS of Digital Secretariat 2.0 for its operations, as
per requirement of the state government line departments and GAD and there are more than 500
successful transactions through the system. Out of 7 functional modules, below 4 are mandatory
to implement .These are :
FR01- Correspondance management system/ Letter management system,
FR03 -Manual file tracking management system
FR07-RTI Query management system
FR013-Court case management system.
These requirements would be signed off by Department and only then SI will begin work on them.
The activities required to be undertaken by SI for on-boarding are as follows: -
a. Assisting department in Business process re-engineering
b. Provide technical support for user creation, workflow management of public services and
grievance management
c. Provide support with API based configuration.
d. Provide support in data quality and database related issues.
e. Provide technical support in UI/UX related issues.
f. Provide support in reporting, analysis and dashboard creation.
g. Provide detailed training, documentation and troubleshooting support to ensure maximum

possible user adoption.
Note: In case there are no requirements from the state government line departments, then
the SI would be expected to continue the O&M activities for the public services already on
boarded to the Digital Secretariat 2.0 solution
2. Changes in the modules/application after Go-live
Page 46 of 121
Volume I
After the Go-live of modules/application, there might be minor configuration changes, alterations
in business processes or additional workflow requirements that may be requested by the respective
departments. These modifications need to be undertaken by the SI on a case to case basis.
3. Compliance to SLA
The SI shall ensure compliance with SLAs of this RFP and any upgrades/major changes to the software
shall be planned by the SI while ensuring that the SLA requirements are met at no additional cost
to the CHiPS.
4. Annual Technology Support
The initial infrastructure VMs/Servers will be provided by CHiPS. But once VMs are handed
over to SI for Solution deployment , It will be maintained by SI like monitoring all critical
parameters is VM, applying relevant OS Upgrade patches etc
5. Application Software Maintenance
a. The SI shall provide continuous and indefinite support through on-site

team/telephone/E-mail/ installation visits as required.
b. The SI shall address all the errors/bugs/gaps in the functionalities of the solution (vis-à-vis
the FRS and SRS signed off) at no additional cost during the O&M phase.
c. All patches and upgrades from use of any open source software shall be implemented by the SI
All patches shall have to be updated on a fixed interval, say quarterly basis. Security patches can
be updated on immediate basis. Each release comes with a risk of system stabilization and
hence periodic updates with full testing needs to be done to mitigate the risk. Technical upgrades
of installation to the new version, as and when required, shall be done by the SI. Any version
upgrades of the software/tool/application will be done by the SI after seeking prior approval
from the CHiPS and submitting the impact assessment of an upgrade as such.
d. Any changes/upgrades to the software performed during the support phase shall be subject
to comprehensive and integrated testing by the SI in order to ensure that the changes
implemented in the system meet the specified requirements and do not impact any other
existing functions of the system. A detailed process in this regard will be finalized by the SI in
consultation with the CHiPS.
e. An Issue log shall be maintained by the SI for the errors and bugs identified in the solution as
well as any changes implemented in the solution and shall be periodically submitted to the
CHiPS team.
Page 47 of 121
Volume I
f. The SI will inform the CHiPS (at least on a monthly basis) about any new
updates/upgrades available for all software components of the solution along with a detailed
action report. In case of critical security patches/alerts, the SI shall inform the CHiPS
immediately along with any relevant recommendations. The report shall also contain the SI’s
recommendations on update/upgrade, benefits, impact analysis etc.
g. The SI needs to execute updates/upgrades though a formal change management process and
subsequently update all documentations and Knowledge databases etc.
h. The SI will carry out all required updates/upgrades by following defined processes at no
additional cost.
6. Problem identification and Resolution:
a. Errors and bugs that persist for a long time, impact a wider range of users and are difficult
to resolve in turn lead to application hindrances.
b. The SI shall resolve all the application problems through implementation of the identified
solution (e.g. system malfunctions, performance problems and data corruption etc.)
c. Monthly reports on problems identified and resolved would be submitted to CHiPS team
along with recommended solutions.
7. Change and Version Control
All planned or emergency changes to any component of the system shall be carried out through the
approved Change Management process. The SI needs to follow all such processes (based on
industry ITSM framework) at all times. For any change, SI shall ensure:
a. Detailed impact analysis is conducted
b. All Change plans are backed by Roll back plans
c. Appropriate communication on change required has taken place
d. Requisite approvals have been received
e. Schedules have been adjusted to minimize impact on the Production environment
f. All associated documentation is updated post stabilization of the implemented change
g. Version control is maintained for all software changes
The SI shall define the Software Change Management and Version Control Process. For any changes
to the solution, the SI has to prepare detailed documentation including proposed changes and
impact to the system in terms of functional outcomes/additional features added to the system etc.
The SI shall ensure that software version control is carried out for the entire contract duration.
Page 48 of 121
Volume I
8. Maintain configuration information
The SI shall maintain version control and configuration information for application software and
any relevant system documentation.
9. Training
The SI shall conduct trainings for the system users whenever there is any change in the system
functionality. All Training plans have to be mutually agreed on with the CHiPS team.
10. Maintain System documentation
The SI shall maintain at least the following minimum documentation with respect to the CHiPS system:
a. High level design of whole system
b. Low level design for whole system/module design level

c. System Requirements Specifications (SRS)
d. Any other explanatory notes about system
e. Trace ability matrix
f. Compilation environment
11. The SI shall also ensure that any software system documentation is updated with regard to the
following:
a. Source code is documented
b. Functional specifications are documented
c. Application documentation is updated to reflect on-going maintenance and enhancements

including FRS and SRS in accordance with the defined standards
d. U s e r m a n u a ls a n d t r a i n i n g m a n u a ls a r e u p d a t e d t o r e fle ct on -g o in g
changes/enhancements
e. Standard practices of version control and management are adopted and followed
12. All project documents need to follow a proper version control mechanism. The SI will be required
to keep all project documentation updated and ensure the updated project documents are submitted
to the CHiPS by the end of next quarter in case of any change.
13. For application support, the SI shall assign a dedicated software support team to be based at the
CHiPS and SI’s location as a single point of contact for resolution of all application related issues. This
team will receive and resolve all the application related tickets/incidents. In the technical proposal,
Page 49 of 121
Volume I
the SI needs to provide the proposed application support team structure including the number of
team members proposed to be deployed along with roles and skills of each. The Application support
team shall comprise of the SI’s employees.
14. Any software changes required due to problems/bugs in the developed software/application will
not be considered as part of change control and will have to be completed by the SI at no additional
cost (even if it requires any enhancements/customizations).
SI shall be responsible for maintaining all the master data for the Digital Secretariat 2.0that would include
the following:
i. Web Portal
ii. Mobile Application
iii. Workflow Engine
iv. Document Management system

7.4.2 Application Monitoring Services
SI needs to continuously monitor the health of applications or technology components under Digital
Secretariat 2.0. There needs to be consistent efforts to diagnose, fix and optimize performance of the
code and systems deployed.
7.4.3 User Profile and Account Management

1. Routine functional changes that include user and access management, creating new report formats,
and configuration of reports.
2. SI shall provide user support in case of technical difficulties in use of the software,
answering procedural questions, providing recovery and backup information, and any other
requirement that may be incidental/ancillary to the complete usage of the application.
3. The SI shall perform user ID and group management services. The user-id naming &protocol
shall be designed and implemented for all the user ids. Such naming convention and protocol
shall be signed-off with the CHiPS.
4. The SI shall maintain access controls to protect and limit access to the authorized end users
of CHiPS and other concerned stakeholders.
5. The services shall include administrative support for user registration, creating and
maintaining user profiles, granting user access and authorization, providing ongoing user
password support, announcing and providing networking services for users and providing
administrative support related to Digital Secretariat 2.0 Solution.
Page 50 of 121
Volume I
6. System administration tasks such as managing the access control system, creating and
managing users, disaster recovery mechanism etc.
7.4.4 Periodic Reporting
The Digital Secretariat 2.0 system shall provide a facility for generating and viewing online, real-time
project, BI and MIS reports for services handled during a specified period, transaction density trends for
any specified periodicity (hourly, daily, weekly, monthly) and any bottleneck situation creating
dependency at any stage. The BI and MIS reporting system shall be an integrated system which shall
provide user-friendly reporting for points of access like – CHiPS and/or Designated monitoring
office. The SI shall provide complete access to the service levels Reporting System including the manner
in which the configuration of the system has been done, SRS and system manuals. Full access to
generate reports from the systems to CHiPS officials or its nominees or GAD .Also, in addition to the
reports that are identified in the RFP, it must be appreciated that so far as a particular data is available
in the system it should be possible to get a report on that for the sake of helping CHiPS or its
designated agencies in analysis and/or decision making.
The system shall provide BI and MIS reporting with multiple “Slice and Dice” options to generate reports
in flexible formats based on user specific needs. The MIS reporting requirements can be stated from
the following perspectives:
The SI would also be provided APIs and requisite permissions for accessing legacy data from the
existing Digital Secretariat 2.0application. This would be handed over during the knowledge
transition period from the Digital Secretariat 2.0 SI. Therefore, Digital Secretariat 2.0 SI will have to
help out the CHiPS officials in retrieving legacy data as per requirement.
From the Digital Secretariat 2.0 system perspective, the reports should present historical, statistical and
predictive views in addition to the daily/weekly/monthly views. In regard to the above, The SI shall
submit the following period reports (but not limited to) to CHiPS:
a. Updation of Documentation on successful completion of O&M operations for each quarter
b. Regular updation of all policies designed by SI for CHiPS
c. Updated system design documents, specifications
d. Latest source code, application deployment files, configuration files for entire solution Software
change logs etc.
e. Corrective Action report in response to the any audit findings/ other concerns as identified
by CHiPS
f. SLA Monitoring Reports
Page 51 of 121
Volume I
7.5 Training and Capacity Building
1. The SI will have to conduct high level orientation workshops for the decision makers in
government departments. The workshops need to be scheduled across the development
lifecycle of Digital Secretariat 2.0 technology components. There should be at least 5 workshops
arranged in one quarter with maximum seating of 20 people to appraise the decision makers on
the recent developments and way forward. Also, this platform may be leveraged to communicate
the support required from decision makers.
2. The SI will have to conduct detailed technical trainings with concerned stakeholders and scheme
implementers on different components of Digital Secretariat 2.0. For each component
developed at least 5 training sessions per quarter need to be arranged with seating of 20-30
people throughout the duration of project. The main aim of these workshops is to enhance user
adoption of the new systems and solve all doubts pertaining to usage of the new systems
3. Comprehensive training and orientation manuals need to be prepared by the SI.
4. The workshops and trainings will be arranged by SI at the location decided by CHiPS/
Departments. The costs (Travelling, Lodging, Boarding, etc.) related to trainers and training
material (manual, booklet, diary, pen, etc.) needs to be borne by SI. The infrastructure
(training hall, projector) for training shall be arranged by CHiPS/ Departments.
5. Below are the 3 types of trainings that SI will be required to do for diff.
departments
Train the Trainer Training
The prerequisite of conducting a TTT training session is to identify the Master trainers from
within the organization who would act as the project champions and have adequate knowledge
and information about the usage of DS System. These master trainers may be identified from
the zonal/region/district level and would act as the primary interface for the implementation
team or the Department staff for any operational or process difficulty they may face.
Field Level Training

The Field level training is more of an operational training to the Region/District staff and
would require both the service provider and the master trainers to impart the trainings at
various levels as mentioned below. This would include both classrooms based and self-
learning modules as training delivery mode.
Region/District level training–The main objective of this training would be to train the
participants about the application functionality, reporting capability, basic IT awareness. The
Page 52 of 121
Volume I
training would majorly be classroom based, however self-learning modules may also be used.
Change Management Training
Region/District level training–The main objective of this training would be to train the
participants about the application functionality, reporting capability, basic IT awareness. The
training would majorly be classroom based, however self-learning modules may also be used.
The indicative deliverables for this activity are mentioned below:
1. Training Calendar and Curriculum
2. Training Material, Training Manuals, Troubleshooting Manuals, etc.
3. Training Sessions, Questionnaire and Evaluation Results
7.5.1 Preparation of training aids

1. The SI will prepare all the requisite audio/visual training aids required for successful
completion of training for all stakeholders/persona. These include the following:
a. Training manuals for Public/CHiPS officials
b. Presentations
c. User manuals.
d. Operational and maintenance manuals for the modules.
e. Application/modules training prototype for hands on training using dummy data.
f. Regular updates to the training aids prepared under this project.
g. FAQs
3. The SI will maintain a copy of all the training material on the Portal/website and access will be
provided to relevant stakeholders depending on their need and role. The access to training on the
portal would be finalized with CHiPS.
7.5.2 Training Effectiveness
The SI has to ensure that the training sessions held are effective and that the attendees would be able
to carry on with their work efficiently using the guidance provided as part of the training. Hence, it is
necessary that the effectiveness of training sessions is measured. The SI will prepare a
comprehensive feedback form that will capture all necessary parameters on measuring the
effectiveness of the training sessions. This form will be discussed and finalized with the GAD. After
Page 53 of 121
Volume I
each training session, feedback will be sought from each of the attendees on either printed feedback
forms or through a link available on the web portal. One member of the stakeholder group would be
involved in the feedback process and he/she has to oversee the feedback process. The feedback received
would be reported to the CHiPS which will share with GAD for each training session.
For each training session, the Service Provider will categorize the feedback on a scale of 1 to 10, where
10 will denote excellent and 1 will denote unsatisfactory.
The training session would be considered effective only after the cumulative score of the feedback as an
outcome of the process [sum of all feedback divided by number of attendees] is more than 6
7.6 Infrastructure Hosting & Support

7.6.1 Application hosting in SDC and its maintenance
CHiPS desires to host the Digital Secretariat 2.0 in State Data Centre, Chhattisgarh.
The SI shall be responsible for installation of all the software and licenses required for the successful
hosting of the Digital Secretariat 2.0application and all ancillary in-scope software. The SI will be
provided with list of infrastructure available. Once the VM/Servers handed over to SI, SI will be
responsible for doing its software maintenance like upgrading OS to the latest patch, Monitoring Health
of VMs/server (vital parameter like storage Utilization etc)
7.6.2 Operations, Maintenance & Support
The SI shall be responsible for providing 24*7*365 days support for Digital Secretariat 2.0. The
maintenance and support shall include following activities –
i. Ensuring Uptime and utilization of the infrastructure handed over to SI and raise alerts as per
SLAs.
ii. In the event of a disaster at DC site, activation of services from the DR site is the responsibility of
SI.
iii. The SI shall be responsible for providing support for all system software at the SDC for the entire
contract period.
iv. On expiration / termination of the contract, SI to handover complete data in the desired format to
the CHiPS which can be easily accessible and retrievable. SI shall also provide support for
transitioning to another SI.
v. SI shall provide provision for viewing live Dashboards for Daily report, utilization etc. through the
monitoring tool/self-provisioning tool.
Page 54 of 121
Volume I
vi. SI to provide list of key contact persons with contact details with escalation hierarchy for resolution
of issues and problems. This shall be via an Incident Management system.
vii. MIS Reports - SI shall submit the reports on a regular basis in a mutually decided format. The SI
shall workout the formats for the MIS reports and get these approved by the CHiPS.
7.6.3 Disaster recovery

I. The SI shall ensure availability of application at DR site within India and will be responsible
for configuring application (solution) at DR site.
II. The exact address of the Primary Site (DC) and Disaster Recovery Site (DR) shall be shared to
the SI by SDC Team.
III. The DC & DR shall operate on Active-Passive mode. DR shall be exact replica of DC ad shall
operate at 100% compute as DC during outages.
7.7 Exit Management
Near to the completion of the project/expiry of the contract the SI needs to plan for an exhaustive
Knowledge Transfer exercise which shall ensure that on expiry of the engagement, CHiPS or its
designated agency is able to operate the project going forward and provide services to different
Departments. During an exit management process following key activities (indicative list of activities)
shall be required to be performed by the SI.
1. Transfer of Assets: The SI ensure transfer of assets to CHiPS within three month from the
date of expiry of contract / termination of contract.
2. Co-operation and Provision of Information: During the exit management period, SI shall
allow CHiPS access to information reasonably required to define the then current mode of
operation associated with the provision of the services to enable the client to assess the
existing services being delivered.
3. Confidential Information, Security and Data: The SI will promptly on the commencement
of the exit management period, supply to the CHiPS or its nominated agencies the following:
 Information relating to the current services rendered and performance data relating to the
performance of the services; documentation relating to project, Project’s Intellectual Property
Rights; any other data and confidential information related to project; all current and updated
components
 Project data as is reasonably required for purposes of the project or for transitioning of the
services to its SI in a readily available format.
 At any time during the exit management period, SI will be obliged to provide access of
information to CHiPS and / or any replacing SI in order to make an inventory of the Assets (mainly
Page 55 of 121
Volume I
from software and applications point of view), layouts, diagrams, schematics,

documentations, manuals, catalogue, archive data, IP addressing, Live data, policy
documents or any other material related to the Project.
 All other information (including but not limited to documents, records and agreements) related
to the services reasonably necessary to enable the CHiPS and its nominated agencies, or its
Replacing SI to carry out due diligence in order to transition the provision of the services to
CHiPS or its nominated agencies, or its Replacing SI (as the case may be).
4. Exit Management Plan: SI shall provide CHiPS with a recommended exit management plan
("Exit Management Plan") which shall deal with at least the following aspects of exit
management in relation to the SLA as a whole and in relation to the Project Implementation, the
Operations and Management SLA and Scope of work definition.
 A detailed program of the transfer process that could be used in conjunction with a
CHiPS/Replacement SI including details of the means to be used to ensure continuing
provision of the services throughout the transfer process or until the cessation of the services
and of the management structure to be used during the transfer.
 Plans for the communication with such of the SI, staff, suppliers, customers and any related
third party as are necessary to avoid any material detrimental impact on Digital Secretariat
2.0project’s operations as a result of undertaking the transfer;
 Plans for provision of contingent support to Digital Secretariat 2.0Project and
CHiPS/Replacement SI for a reasonable period (minimum one month) after transfer.
 SI shall redraft the Exit Management Plan annually thereafter to ensure that it is kept relevant
and up to date.
 The Exit Management Plan presented by the SI shall be approved by CHiPS or/and its
nominated agencies.
 DC/DR document along with updated software documentation and asset registers, and
operational documents will be provide by SI to CHiPS.
 The terms of payment as stated in the Payment Schedule include the costs of the SI
complying with its obligations under this Schedule.
 In the event of termination or expiry of SLA, Project Implementation, Operation and

Management SLA or Scope of Work each Party shall comply with the Exit Management Plan.
 During the exit management period, the SI shall use its best efforts to deliver the services.
 Payments during the Exit Management period shall be made in accordance with the Terms of
Payment Schedule.
Page 56 of 121
Volume I
 This Exit Management plan shall be furnished in writing to CHiPS or its nominated agencies
within 15 days from the receipt of notice of termination or three month prior to the expiry this
Agreement.
The SI needs to ensure that the strategic control of entire solution is transferred to CHiPS or its
nominated agency.
7.8 Solution Audit and Third-Party Code Review
1. Before Go Live of each phase and after UAT sign off , SI need to get Information Security
Audit done from CERT-In empanelled vendors of GOI /GoCG at its own costand submit its
closure report within 15 days after go-live.
2. The SI is required to get a detailed STQC Audit within 3 months after completion of go-Live
of all 3 phases.
This will include following-
i. Application Functional Testing
ii. Security Testing including data security
iii. Performance Testing
iv. Vulnerability assessment including Network Architecture and Deployment review
v. Penetration Testing
vi. SLA Reporting System, Audit trails configuration and monitoring process
vii. IT Security Process Audit (in line with ISO 27001 standards)
This will be covered under Milestone -8, M8 as per Project Timelines, Payment Terms &
Schedule clauses of RFP Volume-1.
3. During O&M Phase, SI need to get Information Security Audit done from cert-in empanelled
vendors of the developed Digital Secretariat 2.0Solution every Year, cost of which will be
borne by CHiPS. For the same, SI will get the system audited by 3rd party auditors as per
directions of CHiPS. Further, SI shall provision an option for online audit option for Auditors
such as CAG.
4. Functional audit should cover at least the following (but not be limited to):
i. User Authentication
Page 57 of 121
Volume I
 Review user account management
 Privilege management and access restriction user ID Scrutiny and evaluation
ii. User authorization
 Segregation of Duties
 Evaluating access controls
 Critical access review
iii. Auditing and logging
 Recording of security events for future investigations and access controls
 Change management review
 Modification done to the programs and the configurations
 Segregation between the development and production
 Testing process
 Quality assurance
iv. Configuration management
 Verification and evaluation of configurations relating to business processes

6. The SI should close all vulnerabilities, observations & recommendations of an audit and the
cost of closure of all such audit vulnerabilities, observations & recommendations to be borne
by SI.
7. Upon rectification based on the recommendations, the IS Auditor will be required to re-audit
the system to ensure that all recommendations accepted for inclusion are complied with.
8. Scope of work also covers evaluating the confidentiality, safety & security of the data &servers,
assess & strengthen the security posture of IT systems and networks for protection against
external threats, by way of remote infrastructure security assessment, internal threats, by way
of on-site infrastructure security assessment and integrated system threats, by way of
application security assessment.
9. Confidentiality: All documents, information and reports relating to the assignment would be
handled and kept strictly confidential and not shared/published/supplied or
disseminated in any manner whatsoever to any third party.
Third Party Code Review
Page 58 of 121
Volume I
1. The SI is required to support an annual Third Party Code Review done for the developed
solution. The cost of conduct of third party code review will be borne by the CHiPS.
2. Planning for the Third Party Code Review needs to be done in consultation with CHiPS. The
SI needs to update all relevant documentation and make available the latest source code for
the purpose of third party audit.
3. The ‘Third Party’ to conduct the Code Review should be the OEM for the development platform
for the first time. Thereon, CHiPS in consultation with SI shall decide on the agency to
undertake such review
4. The code review shall include but not be limited to:
i. Defect count starting UT till UAT
ii. Functional coverage
iii. Coding Standards compliance
iv. Performance parameters being considered at all the tiers of the solution
v. Modularity being maintained
vi. Batch job scheduling and kick off parameters
vii. Performance and load test results review5. The cost of rectification of any
recommendations shall be borne by the SI.
5. All suggestions and recommendations that are required to be incorporated as a result of
the third-party audit shall be the responsibility of the SI.
8 Roles and Responsibilities

8.1 Roles and responsibilities of CHiPS
1. Provide office space for onsite Project Team.
2. Provide servers/VMs on which solution is to be hosted.
3. Coordination between all the stakeholders for providing necessary information for the study and
development / customization of the necessary solution.
4. Coordinate with the SI for conducting workshops for the Stakeholders.
5. Monitoring of overall timelines, SLAs and calculation of penalties accordingly.
6. Assist in conducting UAT for the application solution deployed.
7. Help in getting the Acceptance Certificate from GAD on successful deployment of the software
application, and for other components of the Scope of Work (wherever required).
8. Any other requirements that could arise during operations for effective governance and to meet
any administrative requirement.
Page 59 of 121
Volume I
9. Ensuring the staff members and other stakeholders attend the training programs as per the schedule
defined by the SI and agreed upon by CHiPS.
10. Undertake agreements with stakeholders for integration with their systems.
11. Provide sign off on the deliverables of the project.
8.2Roles and responsibilities of SI

1. Supply, installation, commissioning and maintenance of all software required to meet
functional and non-functional requirements of Digital Secretariat 2.0 system as specified in this
RFP.
2. Solution will be hosted on SDC servers. Once the servers /VMs handed over to SI, its
maintenance, patch upgradation, monitoring utilization and other parameters responsible for
smooth functioning of application will be SI’s responsibility.
3. Process re-engineering and on boarding of services to the Digital Secretariat 2.0solution.
4. Meet the defined SLAs for the performance of the system.
5. Procure, install and manage Helpdesk ,SLA management, Server monitoring & Project
Management tools. Before accepting the tool and its reports, CHiPS will duly audit the tools.
6. Develop and undertake necessary trainings for CHiPS staff.
7. Provide workstations/laptop/mobile phones for the manpower deployed at CHiPS. The

ownership of these devices will remain with SI.
8. Provide necessary support for the resolution of bugs, patches & upgrades of the software
solution.
9. Provide necessary technical support to CHiPS for the purpose of identification of hardware
requirements.
10. Provide necessary manpower for managing the Change Requests
11. Design various manuals like User manual, Trouble Shooting manual etc. for the system.
12. Management and quality control of all services and infrastructure.
13. Any other services which is required for the successful execution of the project.
14. Generation of MIS reports as per the requirements of CHiPS.
15. Support in all kinds of audit requirements, arranged by CHiPS
16. Generation of the report for the monitoring of SLAs.
17. Adherence to all notifications and communication set forth by CHiPS in context of the scope of
services.
Page 60 of 121
Volume I
8.3Roles and Responsibilities of General Administrative Department, GoCG

1. Provide policy level guidance to the CHiPS
2. Issue instructions to departments regarding implementation.
3. Nominate committee for conducting UAT with departments and after UAT provide
Acceptance Letter.
4. Monitor the progress of the Digital Secretariat Phase 2 project and providing necessary
guidance and assistance.
5. Decision making support for policy, regulatory and other relevant changes and on
issues relating to the GPR needs for the Project.
6. Provide necessary financial support to project.
9 Change Request Management

1. The purpose of the Change Request procedure is to control changes to the Digital Secretariat
2.0 Solution.
2. The change request procedure has the following objectives:
i. To protect the environment from uncontrolled changes
ii. To minimize the occurrence of unintended affects during the implementation of

necessary changes
iii. To avoid implementation of any changes which is not reviewed, approved or analyzed.
iv. To control the impact of changes and minimize the effect on effective as well as efficient service
delivery.
3. The CHiPS will be authorized to review, approve and schedule all changes to the Digital
Secretariat 2.0application. All decisions of the CHiPS will be final and binding on all parties
involved.
4. Change Management Life Cycle: The life cycle of all changes initiated during the contract period
of the SI.
5. All the changes will be done by O&M team deployed by SI at CHiPS .
6. The O&M team will do all change requests at no extra cost to CHiPS.
7. Any change in statutory/ regulatory/executive /administrative requirements (refer Appendix A,

B and C) of this volume of RFP) for the list of functional, non-functional and general
requirements.
8. Any configuration, performance tuning, mitigation of security observation during annual/

periodical audits, changes required to accommodate patches, upgrades, bugs fixing, etc. which
are required for the operation of the project shall not qualify as change request.
Page 61 of 121
Volume I
9. The functional requirements given in the RFP are indicative only and not exhaustive in any manner
and/or kind and/or form and shall be finalized in consultation with CHiPS during Software
Requirement Specification.
10. All the development / customization/ configuration must meet the requirements for security,
performance and ease of use for operations, administration and management.
11. Any report whose data is residing in the Digital Secretariat 2.0solution or which can be arrived
at by using some logic on the available data will not fall/ qualify as change request.
The entire change request process will be implemented as mentioned below. The proposed timelines
for each steps / activity and the corresponding responsibility center is also shown in the table below:
S. No. Process Responsibility
1. Authorized official from SI requesting a change will initiate SI

a request by filling up the ‘Change Initiation Form’.
2. CHiPS will evaluate the change request for risks, process of CHiPS
evaluating & implementing change, time required for
completing the change(s) and any other additional
requirement / information needed to clarify the Change
requested.
3. The CHiPS will discuss and provide adequate responses to the CHiPS
queries / suggestions from the SI on the requested
change. If the change is very big , it will take necessary
approvals from state steering committee and
communicate the final decision with the SI.
4. Based on the responses provided by CHiPS ,SI will provide SI

timelines for implementation.
5. CHiPS will evaluate the timelines and take up with CHiPS
6 requesting
SI will thendepartment.
initiate the change following a standard SDLC SI
procedure like requirements gathering, design,
development and testing, etc., as required, along with
proper documentation at each stage.
Page 62 of 121
Volume I
8. Once the change is completed as per agreed timelines and CHiPS

specifications, CHiPS /Dept. representatives will do the
User Acceptance Testing and Auditing respectively to
implement
14. If CHiPS the change
or Implementing Dept. gives any new requirement or change request, the SI should
follow the change management procedure to implement the change.. The requirements for
required infrastructure to implement the change should be specified by the SI so that CHiPS can
make necessary provisions. The change request procedure would be considered complete only
when the training is imparted to the target users for whom the change is being done and the
feedback is evaluated by CHiPS.
15. Any change requirement not pertaining to items and scope listed or elaborated in the current RFP
can be undertaken by CHiPS through separate service provider(s); further, in case of additional
volume of work (beyond the indicated volume in the RFP), CHiPS has an option to undertake
such additional work through separate service provider(s).
10 Project Governance
1. The project would require a close supervision and appropriate project control for successfully meeting
the objectives and its timely completion. The following stakeholders / Committees / working groups
are proposed for adequate program governance:
a. Project Steering Committee
b. State Project Management Unit
2. Project Steering Committee
 Under the chairmanship of GAD Principal Secretary, participating departments and state
Project management unit will review and approve Project report prepared by the vendor
 Will include members from participating departments to provide domain expertise during the
entire length of the project and help in building up a sustainable model for the services
wherein processing of manual applications will be completely discontinued.
 Decision making support for policy, regulatory and other relevant changes and on issues
relating to the GPR needs approval in Project Steering Commitee
 Take an appropriate decision on the mode and degree of integration of the process, systems
and institutional infrastructure of various Government Departments as well as the
infrastructure created under Project to ensure service enablement and delivery.
 Oversee the functioning of the Project and providing necessary guidance and assistance.
Page 63 of 121
Volume I
3. State Project Management Unit (SPMU) would comprise of a team of CHiPS & its consultant
who would be responsible for monitoring all the project implementation, operations and
maintenance activities, on behalf of CHiPS, and provide status reports, action taken
reports, recommendation on deliverables, risks, etc.
4. SPMU would be responsible for addressing all issues related to proposed change requests by the
SI. The committee would approve / reject (as case may be) all proposed change requests from the
SI, following an appropriate Change Control Process defined in the RFP.
5. SI Project Manager: PM will serve as a single-point contact within the institutional

framework for the purpose of project monitoring / reporting purposes and should be deployed
at CHiPS by the selected SI. The PM will be responsible for day to day coordination between PMU
and all implementation teams. PM will be responsible for all the activities within the project
scope and will report to Project Management Unit / Team. They will be directly responsible for
providing Periodic Project Statuses, Tasks Schedule and Action Taken Reports (ATRs).
6. Project Delivery Team: They will be the actual project delivery team deployed at CHiPS by
the SI and will work on all areas of the implementation phases. They may also constitute of various
other teams as required for successful implementation
7. The SI shall form a project team comprising the following key positions:
i) Project Manager – Technical Lead (for management of day to day operations of the project)
ii) Infrastructure Specialist/System Administrator
iii) IT Application Expert ( Full Stack )
iv) DBA /Database Specialist
v) Business Analyst
vi) UI/UX specialist
8. Project Review Meetings: The following will be required to be undertaken by the SI during the
duration of the project:
i) Weekly Status Review Meeting
ii) Monthly Project Review Meeting
iii) Defect Meetings (during major and minor release cycles)
iv) Issue Management Meetings (on need basis)
Page 64 of 121
Volume I
SI is required to prepare a detailed Action Taken Report for all meetings to ascertain and maintain a
log of actions required and taken for successful project delivery
11 Manpower requirement
1. SI has to provide proposed resources for all the roles as mentioned in the pt. 12.16. The proposed
resources must be part of the project team and must be available for discussion with the client at
CHiPS, Raipur.
2. SI shall assess the requirement of resources to design and implement the solution including number,
skill sets and duration and provision the same for implementation of this project.
3. SI has to necessarily maintain a team of requisite size of skilled professionals as per the
requirements of the project.
4. SI shall propose the team structure and deployment plan of resources onsite for the project.
5. The resources proposed must not be changed unless replaced with equivalent or higher
qualification and experience.
6. The manpower shall be deployed by the SI for executing operations, management and
maintenance of the Digital Secretariat 2.0 system, as per terms specified in this RFP and agreed
with CHiPS
7. SI shall ensure that all the resources deployed for Digital Secretariat 2.0(including its sub-
contractors/OEM) undergo suitable trainings in relation to processes to be operationalized under
Digital Secretariat 2.0, security aspects of the project and maintain the confidentiality of data.
8. The personnel deployed should be adequately trained and adequate in number to meet all
operational, technical, functional and other requirements of the infrastructure and processes of
the Digital Secretariat 2.0.
9. The SI would be required to maintain personnel files with the following details of the
personnel deployed at CHiPS:
a. Name and contact details (address, phone number, email id)
b. Name and contact details of professional reference (at least 1)
c. ID proof photocopy (any one of Aadhaar, Passport, PAN card or any Central/ State
Government issued ID card)
d. Professional and educational qualifications

Page 65 of 121
Volume I
10. CHiPS would be provided a copy of all these documents (updated on a monthly basis or before
joining) and may conduct an audit for compliance purpose to check minimum qualification
requirements specified above.
11. Electronic / Biometric attendance registers will be maintained by CHiPS and SI is required to provide
Aadhaar details of team deployed to CHiPS. SI will maintain adequate leave reserve for personnel
deployed.
12. The personnel deployed by the SI (or by sub-contractor/OEMs) should be their employees and
they will have absolutely no claim to any category of appointment in any Government organization.
The terms of employment for the personnel deployed by the SI shall be strictly as agreed between
them and the SI. Also, the SI shall be completely responsible to personnel deployed by him for
payment of salary, perks, incentives, any monetary and non-monetary compensation and all
statutory contributions like Insurance, ESI and PPF, meeting requirements of Central
Minimum Wages Act, etc. Any touting activity taken up by any of the SI personnel will be taken
very strongly against SI and necessary action will be taken by the CHiPS against the personnel
and/or SI.
13.The team which mandatorily needs to be deployed onsite at CHiPS/Departments is given in the
table below
Time during Time during

which resource which resource
Resume
should be should be
S. No. Resource Needed in
deployed deployed
TQ
(Development (O&M Phase-
Phase) 16 quarters)
100 % availability 100 % availability

1. Project Manager (1) during entire during entire Yes
project life cycle project life cycle
2 Solution Architect(1) 50% Availability (on need basis) Yes
Page 66 of 121
Volume I
50%
Infrastructure
availability(3
3. Specialist/System 100% availability Yes
days availability
Administrator (1)
in a week)
50%
DBA /Database availability(3
4. 100 % availability Yes
Specialist (1) days availability
in a week)
IT Applications
5. Expert(Full stack) (1 100 % availability 100 % availability Yes
resource)
Business Analyst(1
6. 100 % availability 100 % availability Yes
Resource)
25%
availability(2
7. UI/UX specialist 100 % availability No
days availability
in a week)
SI will be
Developers (Full evaluate the
8. Stack)(Min 5 years . number to meet Min.2 resources No
experience) the timeline and
deploy accordingly
SI will be evaluate
Mobile App developer the number to
9. (Hybrid App )(Min. 5 meet the timeline Min.1 resource No
years experience) and deploy
accordingly
SI will be evaluate
the number to
Tester(Min. 3 year
10. meet the timeline Min.1 resource No
experience)
and deploy
accordingly
For existing
application L1 Support –
Technical Helpdesk
L1 Support-Min. 1 Min. 2 resources
11. (L1,L2 & L3) Support No
resource L2 & L3 – Min.2
Resources
L2& L3-Min. 2 resources
technical resources
Page 67 of 121
Volume I
* Min. 5 hand * Min. 5 support

holding support staff in
staff in Mantralaya Mantralaya
for DS 1.0 Support. * Min. 2 support
* SI will evaluate staff in which
Functional Support the number to ever new
Staff/ Handholding meet the timeline directorate Go
12. No
support Staff/Training for DS 2.0 and Live happens (for
Staff deploy accordingly 2 Months)
* 1 Support staff
in each division
of CG.
Total Divisions-
6
No , Will be
paid As per
Will be deployed Will be deployed
Finance dept,
Additional Support based on request based on request
13. Order rates for
Staff from Dept. Paid by from Dept. Paid
Asst.
dept. by dept.
Programmer
Position .
No , Will be
Will be deployed Will be deployed
paid As per
based on request based on request
14. Data Entry Operator Collectorate
from Dept. Paid by from Dept. Paid
rates, Raipur
dept. by dept.
for DEO
11.1 Sub-contracting
The following is the list of functionalities/ requirements for which the SI may provision for sub-
contracting service (only one sub-contractor) for the Digital Secretariat 2.0 project.
1. Sub-contracting can only be done after approval from CHiPS.
2. SI is to ensure single level sub-contracting is only undertaken. Direct sub-contractors of SI is

not be allowed to further sub-contract work to other agencies.
3. Quarterly self-certification by the SI that all personnel deployed are either employees of the
SI or allowed under the established sub-contracting arrangements should be submitted to
CHiPS.
4. Sub-Contracting is allowed for only Junior positions (Tester, Technical Helpdesk

(L1,L2,L3) Resources, Fuctional Support Staff/Handholding/support staff/Training
Staff, Additional Support Staff, Data Entry Operator) as mentioned in pt.13 of Section 11
Manpower Requirement.
Page 68 of 121
Volume I
1. Sub-contracting would be subject to the following conditions:
a) All sub-contracting contracts must be entered into by the SI.
b)All sub-contracting arrangements of the SI must be approved by the CHIPS prior to

commencement of services by the SI.
c) CHIPS retains the right to request discontinuation of sub-contracting of activities at any time
during the contract period and such activities will have to be performed by the SI directly or
by a subcontracting agency acceptable to CHIPS.
d)The SI will be responsible for meeting all obligations of its sub-contractors and the delivery
of goods and services mentioned in all volumes of this RFP. The SI will be solely responsible for
all acts of its sub-contractors
e) CHiPS reserves its right to subject the sub-contractors to security clearances as it deems
necessary and ALL the personnel of the sub-contractor before they are appointed to the Digital
Secretariat 2.0project.
2. The SI will be responsible for:
a) The management of its sub-contractors who are a part of the proposal and for the delivery of
all products and services in accordance with the agreement.
b)The supply, delivery and installation, commissioning of all products and providing all services
as submitted in their proposal.
c) Internal arrangement between the SI and its sub-contractors is left to the SI, subject to
relevant clauses in Volume - 3 of this RFP.
12 Project Management
SI will deploy an open source project management tool to manage and operate all processes of the
project using a proven SDLC methodology in consultation with CHiPS. The SI is required to
design and implement a comprehensive and effective project management methodology and use
efficient and reliable PM tool/application with access provided to identify stakeholders.
The SI shall address at the minimum the following using PM Tools:
1. Define an organized set of activities for the project
2. Establish and measure resource assignments and responsibilities
3. Construct a project plan schedule with milestones
Page 69 of 121
Volume I
4. Measure project deadlines, progress of the project against set deadline, budget figures, and
performance objectives
5. Communicate the project plan to stakeholders with meaningful reports
6. Provide facility for detecting problems and inconsistencies in the plan
7. Provide Dashboards
8. Maintain all documents/deliverables/approvals
9. During the project implementation the SI shall report to the CHiPS, on following items:
a. Results accomplished during the period (fortnightly) ;
b. Cumulative deviations to date from schedule of progress on milestones as specified in

this RFP read with the agreed and finalized Project Plan;
c. Corrective actions to be taken to return to planned schedule of progress;
d. Proposed revision to planned schedule provided such revision is necessitated by

reasons beyond the control of the SI.
e. Other issues and outstanding problems, and actions proposed to be taken.
10. Progress reports on a fortnightly basis and project quality assurance reports
11. Audit trail and searchable history of all artifacts presented and approved shall be
maintained on tool/application where admin password shall be in the custody of CHiPS
12. This tool/application shall be used, maintained and enhanced as per CHiPS requirement
throughout the project lifecycle for all software, documentation, project, control or change
requests
13. The SI should maintain a document repository and shall maintain version control of the
documents using the document management solution with appropriate controls for
document approvals
SI at any point of time during project cycle may have to adopt and use project management tools
provided by CHiPS.
12.1Risk and Issue management

1. The SI shall develop a Risk Management Plan and identify, analyze and evaluate the project
risks, developing cost effective strategies and action plans to mitigate those risks.
2. The SI shall carry out a Risk Assessment exercise and document the Risk profile of the project
based on the risk appetite and prepare and share the enterprise risk register. The SI shall
develop an issues management procedure to identify, track, and resolve all issues faced on
Page 70 of 121
Volume I
the project. The Risk management plan and issue management procedure shall be carried out
in consultation with CHiPS.
3. The SI shall monitor, report and update the project risk profile. The risks should be discussed
with CHiPS and a mitigation plan should be identified during the project review/status
meetings. The Risk and Issue management should form an agenda for the Project Steering
Committee meetings as and when required
12.2Requirement Traceability Matrix

1. SI shall be responsible for maintenance of a Requirement Traceability Matrix through-out
the project.
2. SI would ensure that Digital Secretariat 2.0is fully compliant with the requirements and
specifications as mentioned in the RFP. For ensuring this, SI shall prepare a Requirements
Traceability Matrix on the basis of Functional Requirements Specifications (FRS) and Technical
Requirements provided by CHiPS (updated by SI as necessary) and the System Requirements
Specifications (SRS) prepared by SI.
3. This matrix would keep track of the requirements and trace their compliance through
different stages of the project including software design, coding, unit testing, integration
testing, user acceptance testing and final acceptance testing. The requirements traceability
matrix would be a live document throughout the project, with the SI team updating the matrix
at every stage to reflect the compliance of each specification at every stage. All changes made
on the document should allow PM application/tool to auto inform over SMS/Email to key
stakeholders.
4. Through the duration of the project, CHiPS will periodically review the Traceability Matrix.
CHiPS would provide the final approval once they are satisfied that all requirements are met.
13 Project Timelines, Payment Terms & Schedule
The detailed project timelines, milestones, list of activities, deliverables and payment schedule
during the project life cycle have been provided in the table below. The SI will have to prepare
detailed project plan as per the details outlined in the table.
Payment Terms
a. The Invoice will be submitted after achievement of every Milestone. The payment will be
Page 71 of 121
Volume I
made within 30 days after submission of Invoice.
b. The Invoice will be submitted after every quarter during Operation and Maintenance Phase.
The payment would be made within 30 days after submission of Invoice.
c. All taxes, duties and other charges of the products and services to be duly paid by the SI.
d. The SI shall satisfactorily perform work as specified under the Tender to the CHiPS. CHiPS
will release the requisite payment upon receipt of the invoice, which would be verified within
2 weeks of receipt of the invoice.
e. All payments agreed to be made by CHiPS to the SI in accordance with the Bid shall be
inclusive of all, statutory levies, duties, taxes and other charges whenever levied/ applicable
including costs of maintenance, if any and CHiPS shall not be liable to pay any such levies/
other charges under or in relation to this Contract and/ or the Services.
f. No invoice for extra work/ change order on account of change order will be submitted by the
selected bidder unless the said extra work/ change order has been authorized/approved by
CHiPS in writing.
g. The payment shall be made to the SI after deduction of all applicable penalties, taxes, etc.
h. In case of any changes by Government in statutory levies, duties and taxes then actual levies,
duties and taxes on the date of billing would prevail.
i. CHiPS shall be at liberty to deduct penalties from the invoices raised by the SI as calculated
by CHiPS for non-adherence to Service Level Agreements as mentioned in Appendix D-
Service Level Agreement.
j. All payments to the SI shall be subject to the deductions of tax at source under Income Tax
Act, and other taxes and deductions as provided for under any law, rule or regulation. All
costs, damages or expenses, which CHiPS, may have paid or incurred, for which under the
provisions of the Contract, the SI is liable, and CHiPS shall deduct the same from any dues to
the SI. All payments to the SI shall be made after making necessary deductions as per terms
of the Contract.
k. For Products and/ or Services supplied from outside India, the SI shall be entirely responsible
for all taxes, stamp duties, license fees, and other such levies, payable in India.
l. For Products and/ or Services supplied locally, the SI shall be entirely responsible for all
taxes, duties, license fees, etc., incurred until delivery of the contracted Products or Services
to CHiPS.
Timelines and Payment Schedule as given in Table Below –
Page 72 of 121
Volume I
Sr Milestone Activity Deliverable Timeline Payment

No. in Days
1 Project Initiation & Team Resource Deployment Plan T+10

Mobilization days
2 Existing Business knowledge • Knowledge transfer plan approved T+40 5%

Application transition from the by CHiPS Days
Handover-M1 incumbent DS SI • Weekly status report on knowledge
transfer
• AS IS and System Appreciation
Document (SAD) on completion of
knowledge transfer
3 Helpdesk Set up Helpdesk and * Helpdesk SOP T+20 5%
and Support technical as well as * Roaster of Resources deployed Days
Team functional support team * Helpdesk Software deployment
for existing application
(Scope of work as per 8.3)
4 MPP for 5 Project management plan Master project plan in .xls/.mpm T+40
year for all 5 years Exit Management plan Days
5 SRS Prepration for phase • SRS for Phase 1 T+50

System Study 1 • FRS for Phase 1 Days
and design • UAT test plan for Phase 1
for Phase 1-
6 M2 • Solution design and architecture T+60 2%
Solution Design for phase- Doc for Phase1 Days
1
7 Deployment for User • Refined UAT Testing plan T+90
acceptance testing -phase • Finalized Test cases Days
1
8 Beta/UAT Testing •Testing Data T+100 5%
• Testing Reports Days
* User procedures manual
• Report on necessary changes made
in the software to meet expectations
of UAT
*UAT Sign Off
Software
Development,
9 Testing, • Application delivery checklist – T+110
Deployment, checked Days
UAT & Go- • Installation, commissioning and Go
live of Phase- -live phase 1 report
1 -M3 Training and Go live • Operations manual
phase-1 • Training material
• Filled training feedback form
10 Hypercare support after * Daily status Report on Issues after T+ 125 2%

go-live GO -Live Days
*Weekly Transaction Report
* Min. 500 successful transactions
through system
11 SRS Prepration for phase • SRS for Phase 2 T+110
System Study 2 • FRS for Phase 2 Days
for Phase 2-
12 M4 • Solution design and architecture T+120 2%
Solution Design for phase- Doc for Phase 2 Days
2
Page 73 of 121
Volume I
13 Deployment for User • Refined Testing plan T+180

acceptance testing -phase • Finalized Test cases Days
2 • Testing Data
• Testing Reports
14 • UAT Sign Off T+200 5%

• Application delivery checklist –
checked
UAT Testing and Sign off • Installation, commissioning and Go
phase-2 -live phase 2 report
• Intermittent maintenance &
Software support plan
Development,
15 Testing, Prod deployment config & •Operations manual T+210
Deployment, User Training •User procedures manual
UAT & Go- •Training material
live of Phase- • Technical & Role wise User manual
2 -M5 (with visual
help kits) of the application software
•Attendance & Training
reports with feedback forms
16 Go Live + 15 days •Installation, commissioning and Go T+225 5%

Hypercare support ( -live phase 2 report
* Daily Status Report on Issues after
GO -Live
* Min. 500 successful transactions
through system
•Intermittent maintenance & support
plan
17 SRS Preparation for phase • SRS for Phase 3 T+200 2%
System Study 3 • FRS for Phase 3
for Phase 3-
18 M6 • Solution design and architecture T+210
Solution Design for phase- Doc for Phase3
3
19 Deployment for User • Refined Testing plan T+320
acceptance testing -phase • Finalized Test cases
3
20 Beta/UAT Testing •Testing Data T+340 5%

• Testing Reports
• Report on necessary changes
Software made in the software to meet
Development, expectations of UAT
Testing, *UAT Sign Off
Deployment,
UAT & Go-
21 • Application delivery checklist T+350
live of Phase-
– checked
3 -M7
• Installation, commissioning
and Go -live phase 2 report
Training and Go live • Operations manual
phase-3 • User procedures manual
• Training material
Page 74 of 121
Volume I
22 Hypercare support after * Daily status Report on Issues T+365 5%

go-live after GO -Live
* Min. 500 successful
transactions through sysytem
23 M8 STQC Audit of all STQC certificate from STQC T+450
modules
24 M9 O&M of existing system * Attendance of manpower deployed T+30 -- 10% (2.5%
for till Go-live of all as per Manpower clause T+395 for each
phases. * List of resources quarter)
*QGR Report detailing Issues
resolved
25 a) Deployment of •Signed Attendance Register This phase Remaining
Manpower •Software will be 48% of
b) New Development and Development/enhancement/ divided contract
M10 Enhancement/ up- up-gradation/ into 16 value will be
Operational gradation/ modification in modification reports quarters divided into
and the Digital Secretariat - •Periodic Testing reports remaining. 16 quarters
maintenance Phase 2 •Application Uptime report (3% will be
of 4 years Application •Issue Tracker/ Call paid each
Phase-4(This c) Managed Services Register/Log reports of help quarter for
milestone will during Support and desk O&M)
start after Maintenance Period •Consolidated Helpdesk Report
completion of Services on Calls Logged, Resolved and
first 3 d) Min. 5 directorates and Escalated
phases) i.e their line offices to be
after brought into DS each year
completion of of O&M. For this 10% of
milestone M8 each quarter will be on
hold and released after
year end after completion
of target.
26 M11- Exit Exit Management. This
•Exit Management Team composition 16th 3 % of last
Management will be tied to 16th quarter
as part of exit management plan. Quarter quarter +
payment . •Updated User Manual ,Design & PBG will be
* In case of extension, the
SRS documents of release after
last quarter of extended
the application software in one hard successful
period will be tied to Exit
copy and one soft Exit
Management copy (in DVD) Management
•Updated Application software with
source code in
two sets of DVDs along with source
code and/or license
of third party AP
Remark: The above mentioned delivery schedule shall be applicable subject to fulfilment of obligations
by CHiPS for respective milestone, wherever applicable. In case of delay in action taken by CHiPS,
same number of days would be added in the delivery period.
Page 75 of 121
14 Compliance to Standards and Certifications
14.1Preference for Open standards

The Digital Secretariat 2.0system must be designed following open standards, to the extent
feasible and in line with overall system requirements set out in this RFP, in order to provide for
good interoperability with multiple platforms and avoid any technology or technology
provider lock-in.
14.2Compliance with Industry Standards

For a big set up like Digital Secretariat 2.0, it is imperative that the highest standards applicable
are adhered to. In this context, the SI will ensure that the entire Digital Secretariat 2.0 solution
is certified, wherever applicable, and is in compliance with the applicable standards. Following
table depicts the standards which CHiPS intends to get certified within 6 months of Go-Live .
However, the list below is just for reference and is not to be treated as exhaustive.
Solution Element Standards
Information access/transfer protocols W3C Specifications
Portal Development W3C, GIGW
Software Development Process Management CMMI Level 5
Interoperability API, Web Services, Open Standards
Scanned documents PDF (Image Format)
Document encryption PKCS specifications
Information Security/ Operational Integrity & Security ISO 27001 certification (or above) *
Management
Operations ISO 9001 certification (or above) *
IT Infrastructure management EITM specifications
Service Management ISO 20000 specifications (or above)
Project Documentation IEEE/ISO/CMMi (where applicable)

specifications for documentation
Business Continuity Management ISO 22301
Page 76 of 121
Solution Element Standards
IT Governance COBIT
IT Operations ISO 20000/ITIL
Document the Operations and Management Standards ISO 20000-1:2011 or relevant latest
standard
a) The Standard/Certification will be the latest version as at the time of implementation. In

case any standard/certification is withdrawn or replaced with a new
standard/certification, the SI has to ensure that the new standard/certification is taken
within defined timelines or within 6 months of declaration of such change. Cost relating to
compliance with the above standards/certification including documentation and
certification fees etc. to be borne by the SI.
b) Apart from the above the SI need to ensure compliance of the project with Government of
India’s IT security guidelines including provisions of:
The Information Technology Act, 2000” (revised 2008) and amendments thereof and
Guidelines and advisories for information security published by Cert-In/MeitY
(Government of India) issued till the date of publishing of tender notice. Periodic changes in
these guidelines during project duration need to be complied with.
c) The SI shall also adhere to the relevant guidelines and standards (as applicable) issued by
CERT-IN, MeitY and Government of India including the following –
 CERT-In security guidelines for Indian Government websites (http://www.cert-

in.org.in/)
 E-SAFE Guidelines for Information Security (http://egovstandards.gov.in/ )
 e-Governance Standards for Preservation Information Documentation of e-Records
(http://egovstandards.gov.in/ )
 e-Governance standards on Biometric standards (http://egovstandards.gov.in/ )
 Framework and Guidelines for Use of Social Media for Government Organisations
(http://meity.gov.in/writereaddata/files/Approved%20Social%20Media%20Framework
%20and%20Guidelines%202.pdf)
 Guidelines for Indian Government Websites (http://egovstandards.gov.in/ )
Page 77 of 121
d) Along with the guidelines of GoI, the SI should ensure compliance with State guidelines
and acts, inclusive of and not limited to, Open API policy and Chhattisgarh Aadhaar Act, 2018
along with Aadhaar Act, 2016.
e) SI should register that, changes should be made in the system, in accordance with any
Central/State Government Act - concerning data security and privacy, and data sharing - passed
during the period of system development/implementation.
Appendix A – Functional Requirement Specifications

This is a low code or no code platform which will help departments bring their services from
offline to online mode with simple configuration changes. With this tool they will be able to create
forms, API enabled data fields, workflows, notifications, documents etc. i.e. all functionalities
required over a service delivery lifecycle. It will enable departments to configure workflows as per
business logic through simple functional drag and drop activities.. This will provide dashboard
and reports that aid in decision making and improving scheme operations.
Required office automation areas are as follows. Details of which is elaborated in succeeding
paragraphs :
FR01 - Correspondence/Letter Management System

FR02 - File & Office Note Management
FR03 –QR Code Based- Manual File Tracking Management (Public View required)
FR04 – Digitization Management Tool (with scanning through mobile enabled).
FR05 -Travel Management and TA/DA
FR06-Vidhansabha / Parliamentary Query Management
FR07 - RTI Query Management
FR08 -Knowledge Management System and Record Management System
FR09 -Integrated Human Resource Management System
FR10 -Bank Guarantee (BG)/ Earnest Money Deposit (EMD) Management
FR11- Conference Room booking
FR12 - Visitor & Gate Pass Management
FR13– (Court Case)-Court Cases Management
FR14 - Committee and Meeting Management
FR15 - Calendar, tasks and reminders
Page 78 of 121
FR16 – Dashboard and MIS reports
FR17 – Grievance Management System for Government Employees
FR01 Correspondence/Letter Management System & FR02 File & Office Note Management :
DS II completely automates file & DAK management from creation to archival of files and DAK. All decisions can be
captured in the file itself and remain intact throughout the lifetime of the file. Effective transformation to paperless
office environment by providing functionalities like electronic correspondence/file creation, management, movement
and performance of related tasks flagging, indexing, noting, referencing, search/ retrieval, Digital Signature.
Features -
 The system should be capable & configurable enough for complete File & Letter Life Cycle
Management.
 Integration with e-Sign for digital signature
 Publish orders/letter to web portal in public domain
 The System shall support integrated in - built viewer for viewing documents (PDF/Word/PPT).
 The system shall facilitate zoom-in/zoom-out, zoom percentage and Zoom Lens to zoom in on a part
of image and other image operations like Invert, rotate, etc.
 The system shall provide facility of putting text, graphic and image annotations on scanned document
pages.
 The mobile application should have support for retrieval and archiving of documents.
 System should support integration with Stylers / Voice to text /Touch Screens for text input
 Document Management System
 Integration with latest Business Analytics tool to prepare dashboard which can give insights in
efficiency of file disposal, DAK Disposal, tracking of pendency in various departments, performance
of employees /Departments
 System should define process of maintain following registers online - DAK, Avak, Javak,Stock and
Asset register
FR03 Physical File Tracking Management :

To track the movement of physical office files for various office work file tracking system will be used.
Features -
QR Code Solution will be integrated with File Management module. All the file related
important information will be captured in QR Code. QR Code will be used for file tracking
where movement of file is physical.
 System should able to design/ create/ print bar code label/ QR label.
 Incoming/ Outgoing by QR/Bar code readers in Mobile App
FR04 - Digitization Management Tool

Digitization management will help the user to upload scanned documents in logical format.
Features –
Page 79 of 121
 Meta data capturing
 Document upload along with OCR CAM Scanning through mobile App
 Bulk document upload
 Verification and acceptance of scanned copies by designated authority
FR05 Travel Management and TA/DA :
Travel management module is proposed to ease the process of booking and approvals during official travel, this will
act as a single window system from where request to reimbursement process will be monitored.
Features -
 User group creation as per the policy
 Add / Update entitlement/allowance accrording to the policy
 Workflow for request and approval
 Advance and Expense settlement
FR06 Vidhansabha / Parliamentary Query Management :

Vidhansabha / Parliamentary query received by the department needs to be responded in the time bound manner.
Vidhansabha / Parliamentary queries should be routed via proper channel for collection of data/ reply or comments,
which is subsequently approved for onward submission to Vidhansabha/ Parliament.
Features -
 Enter vidhansabha/parliamentary query into system
 Route the query to the concerned department to record the necessary information
 Consolidate input received from departments into reply
 Get approval for parliament query reply on workflow
 The system should send the alerts to the department officials through email, dashboard alerts, and
send reminders on deadlines for query response before the due date
 The system should record the status of vidhansabha/parliamentary query
FR07 RTI Query Management:

RTI is a process pertaining to providing information to people. A lot of times the same information is sought by different
people. In such cases the automated process follows the entire information sharing life-cycle in a cost and time effective
manner. Throughout the process information is collected and shared within the organization in a seamless manner and
maintained in a knowledge repository for future reference.
Features -
 System should be able to enter RTI query
 System should be routing the query to the concerned department to record the necessary
information
 System should collate information from the respective departments and create a response
 System should create a workflow for the approval
Page 80 of 121
 The system will set a deadline and priority for the resolution of RTI request based on the type of
RTI request as per the departmental policy and provide option for setting deadlines and priority for
exceptional cases
FR08 Knowledge Management System and Record Management System :

KMS willbe single repository of all documents of state for eg. Orders, Acts, State govt. Civil Rules etc will be uploaded
and from where all department/ministry users can access the information. It enables users to create and manage
electronic documents that can be viewed, searched and shared.
Online Record Management System will redefine SOPs how records (Files ,etc) will be stored manually as well as in
Online mode
Features –
 It will also be capable of keeping track of the different versions of modified documents by different
users.
 It will maintain Online register of Manual records along with Online register of Files and DAKs
 Centralized Document Repository with folder wise categorization
 Managed subscriptions and sharing of Docs
 Folder Layout for easy navigations
FR 09 Integrated Human Resource Management System :

Government of Chhattisgarh has envisaged a comprehensive Human Resources Management System for employees
and HR managers of all departments across the state. Through HRMS, all human resources management activities will
be transacted electronically through internet, so as to provide timely disposal of HR issues of the employees and
motivate them to perform efficiently. HRMS will accurately project, account, and monitor revenue expenditure and
enable efficient utilization of government resources. The decision makers will do effective planning and utilization of
existing manpower by identifying their skills. Time and energy of government employees will be saved by the automated
HRMS resulting optimum utilization of their services.
Features –
 Man Power Planning
 Recruitment
 Confirmation
 Transfer Posting, Joining and Deputation
 Seniority List
 Promotion
 Increment / Pay Fixation - Time Bound Pay Scale Enhancement
 Attendance Management
 Leave Management which includes all types of leaves (EL , CL, Commutated etc.)
 Annual Confidential Report (ACR)
 Training and Learning Management including Training Implementation
 Payroll Processing
 Other Employee Entitlement – Loans and Advances
 Other Employee Entitlement – Claims (TA & Medical Reimbursement)
 GPF / Part Final
 Departmental Enquiry
Page 81 of 121
 Court Case
 Awards
 Employee Grievance Redressal
 Employee Exit - Superannuation
 Employee Exit (Other Exits) –(Death ,Termination, VRS and Resignation,
 Compulsory Retirement and Absorption/ Samvillyan)
 Immovable Property Return (IPR) Module
 Digitization of E-Service book for all Depts.
 Attendance Management including integration with biometric.
 Integration with iFMS (Integrated Finance Management System)
The short FRS of IHRMS is given in Appendix A.1

FR10 Bank Guarantee (BG)/ Earnest Money Deposit (EMD) Management :
As part of contracts departments opts for BG/EMD which is allocated for a limited validity. On completing of work
BG/EMD will be return to the vendor. In case of penalty full or partial amount will be recovered from BG/EMD
Features –
 System should allow to capture the information related to BG/EMD along with the scan documents
 System should push reminders for expiry / renewal of BG
FR11 Conference Room booking :

For joint meetings and trainings conference room booking request would be initiated and approval for request is
generated.
Features –
 Submit request for conference room for given date
 Service desk to book conference room with approval of concerned in-charge
 User should receive the notification on approval/dismissal of the request along with the comments.
 System should generate report for calendar bookings, record for weekly/monthly bookings.
 System should display booking status/ availability status in grid format for weekly/ monthly.
FR12 Visitor & Gate Pass Management :

Visitors entering the office will be monitored and managed by the central office, and system should support entering
the details of visitor in the system and provide a temporary access after approval from concerned officer.
Features –
 Office to provide visitor pass to visitor.
 Collect the visitor pass on exit from the premises.
 Capture and manage bio-metric information of visitor.
 System will capture visitor's contact, address details and identification Proof will be recorded in the
system. The Webcam will help in capturing the image of the visitor.
FR13 Court Cases Management :

Repository of the all on-going and archived cases with in the department, department will create/update cases. System
will generate reminders/notification on future hearing and keep all the court case related data centrally.
Page 82 of 121
Features –
 Capability to Create a Court Case file which will include various case details such as Case no, Case
Type, Date of Filing, Case details, Court Order details, Hearing date, Order date etc.
 Capability to add various documents in the Court Case file related to the case such as OIC from dept,
hearing dates
 Capability to provide alerts for the upcoming hearings.
 Capability to Cross-reference all dates for one case, one client, one attorney, a group, or the entire
office.
 Capability to generate the Case Diary having complete details and history of the cases.
 Capability to provide a mechanism for analysis of work flow, case status, and types of cases opened
and closed
 Capability to maintain an audit trail of entries and changes
FR14 Committee and Meeting Management :

System would have capability to create committee and members , based on this user can schedule meetings and post
meeting follow ups are also done through this module.
Features –
 The system should have the capability to constitute the committee with its members and convener
details.
 The system should have the capability to define the role of each committee member.
 The system should provide User Inbox where committee members/approvers can view the pending
request for approval.
 The system should have capability create tasks against Minutes of the meeting (MoM)
 The system should have capability generate Action taken report for the meeting
 System should have facility to submit the appointment request to officials
FR15 Calendar, tasks and reminders:
Personalized module for users to enter tasks, reminders in order to follow up important activities, system
should provide reminders/notification to users for better time management.
Features –
 Create activity in calendar with supporting documents.
 Add other participants and set reminders.
 System will notify users in regards to upcoming activities
 Modify/Delete activity
FR16 Dashboard and MIS reports:

Interactive dashboard and customized MIS reports for quick decision making and tracking.
Features –
 Role based dashboard
 Dynamic reports
 Export the result to PDF and Excel
Page 83 of 121
FR17 Grievance Management System for Government Employee
Using these module government employees can raise their issue which will be directly routed to the concerned
department. To avoid discontent among employees that can arise out of real or imaginary reasons.
Features –
 Fair and speedy means of dealing with complaints.
 Provide Safe environment for employees to raise their concerns.
 Procedure should be sufficiently simple so that it can easily and quickly be explained to each new
employee.
Appendix A.1–Functional Requirement Specifications for

IHRMS
Bidder is required to prepare detailed SRS based on requirements gathering. Additional
features/functionalities can be added till sign-off of the SRS. This FRS is just to aid the bidder
on functionalities needed. It should not be treated as signed off version from department.
Department & existing employee on boarding & New Employee Registration
Module Name Department & existing employee on boarding & New Employee Registration
Req. ID Requirement Business Rule (if any)
System should allow super admin to add department

DO-001 name in the department master
DO-002 System should allow super admin fill up department

on boarding form
System should allow super admin to upload request

DO-003 letter given by department to activate the services for
department
Super admin will ensure that employee data from

DO-004 karmic sampada has been fully migrated to the new
HRMS system
Page 84 of 121
Once super admin has activated the department ,
DO-005 employee data from karmic sampada will be visible Valid only for existing employees
in each employee's login
System will employees to login and verify the

DO-006 registration details and modify the details if required
Once verified employee needs to submit the data using

OTP / DSC in order to confirm that data is correct, This
DO-007 will be one time activity for non - editable fields
Once the employee has verified the details same will

DO-008 be updated in online service book
Once employee is recruitment is done , concerned

clerk will enter basic details of employee in the new This is valid only for new employees
DO-009 system and will generate credentials for first time
login
Employee will login these credentials for the first

DO-010 time and change password mandatorily
Employee will verify the details entered by the clerk

DO-011 and request for change if any in case non editable
fields are not correctly entered
DO-012 Employee will enter rest of the details and submit the
same with OTP / DSC
System will send intimation to reporting officer of

DO-013
employee
Once the employee has entered the details same will

DO-014 be updated in online service book
DO-015 System should generate Personal file that auto

populates data from registration based on fields
selected
Page 85 of 121
Employee recruitment
Module Name Employee recruitment
REC-001 System should be integrated with SLCM for getting

employee recruitment data.
System should allow registration of employee once

REC-002 recruitment process is done and data is received from
SLCM.
Employee id in case of existing

System should generate employee id after registration is employees to be mapped to
REC-003 completed. employee id received from
migrated data.
System should have audit trails for tracing transactions

REC-004
performed by all the users.
Posting
Module Name Posting
PO-001 System should allow dealing clerk to verify and process

candidates for posting
PO-002 System should allow user to select the department for

posting of the employee
PO-003 System should allow user to select more than once

candidates for posting to same department
System should send posting request to next level(US/

PO-004 Secretary) after submission of request by dealing clerk
System should generate unique posting id for each of the

PO-005 employee posting request generation once user has
submitted request
Page 86 of 121
System should allow configurable workflow for approval of
requests i.e. number / designation of stakeholders in
PO-006 workflow etc. must be allowed to be changed by department
admin
PO-007 System should US / secretary to view the posting requests

and approve / send back requests
PO-008 System should allow selection of more than one posting

requests and approve
PO-009 System should send back requests to dealing clerk that are
rejected by US/ Secretary
PO-010 System should show rejected / action pending posting

requests in dealing clerk's login
Once approved , posting order is generated in pdf format

PO-011 and sent on email / login automatically to employee and
concerned department
PO-012 System should give option to print the posting order
PO-013 System should allow selection of more than employees
PO-014 System should send automatic notification to accounts

section for PRAN generation
PO-015 System should have audit trail for tracing transactions

performed by all the users
Service book:
Module Name Service Book
System should allow employees (to verify auto populated

SB-001 fields in service book (from data migration) (existing
employees only)
System should allow employees to edit the fields that are

SB-002 incorrectly populated.( Fields that are to be kept
editable will be decided at a later stage)
Page 87 of 121
SB-003 System should not allow to modify non-editable fields
for e.g. DOB , Date of Joining etc.
SB-004 System should allow employee to enter data in the fields

that are not auto populated
System should allow uploading of the required documents PDF document be allowed of size
SB-005
max 3 MB each
SB-006 System should allow uploading medical certificate

before entering service book (new employees)
System should allow department user to verify the

SB-007 medical certificate uploaded by employee and give
approval to enter the service book
System should allow employee or department to enter

SB-008 data in service book as per fields given in service book
form
SB-009 System should allow department user to verify the medical

certificate uploaded by employee and give approval to enter
the service book
System should allow employee or
SB-010 System should allow employee or department to enter department to enter data in
data in service book as per fields given in service book service book only after the
forms verification of the medical
certificate is done
System should allow employee to submit service book

SB-011 using OTP/DSC.
SB-012 System should generate unique reference number once

service book is submitted
SB-013 System should generate email / SMS notifications to

employee and concerned department DDO with unique
reference number
System should send service book the login of concerned This is only valid for new
SB-014 department’s DDO for verification employees
System should allow DDO to review service book of each

SB-015 employee
SB-016 System should allow preview of document uploaded with

service book , rather than requirement of each document to
be downloaded
System should allow DDO to review service book of

SB-017 more than one employee and mark as approved and sign
with the help of OTP / DSC
Page 88 of 121
Notification should be sent to
System should allow DDO to add review comments
reporting officer in case of certain
SB-018 against service book entered by employee
fields only.(To be identified later)
System should further employee to edit of certain details

SB-019 in service book at a later stage. For e.g. nomination
details etc.
Notification should be sent to

System should send notifications to employee's reporting officer in case of certain
SB-020 reporting officer in case of change / edit done by fields only.(To be identified later)
employee.
SB-021 System should allow configuration of workflow by

admin of department to allow change of levels of
approval etc.
. System should have audit trail in place to trace changes

SB-022 done to any service book with username / timestamp
etc.
System should allow only
SB-023 Service book will be integrated with all other modules of department to update certain
HRMS for e.g. Leave, Payroll etc. fields. Employee must not be able
to change these details
System should allow only
SB-024 System should allow department to regularly update the department to update certain
employee service record as and when any changes happen fields. Employee must not be able
related to employee postings, promotions, salary revisions,
to change these details
leaves , increment etc
SB-025 System should allow uploading of scanned service book for

existing employees
SB-026 System should have audit trail for tracing transactions

Employee Confirmation
Module Name Employee Confirmation

Notification should be sent for
System should generate automatic notification to
the cases where 2 years have
CONF-001 department admin for the employees nearing probation
been completed from the date of
completion
joining
System should allow delegation of confirmation case to

CONF-002 another department employee in case required
Page 89 of 121
Tentative list of details
• Probation Period
• ACR Details
The System should allow the user to fetch details for the • Any Complaints/ Enquiry
CONF-003 employees from relevant modules /details against the employee
• Supervisor feedback
• Overall work conduct
• Mandatory requirements for
confirmation
System should allow department user to view confirmation
CONF-004 criteria
First reminder to be sent on 30
days before confirmation date
Second reminder to be sent on 20
System must send reminders to department user for days before confirmation date
CONF-005 pending confirmations (nearing end date and beyond Third reminder to be sent on 10
end date) days before confirmation date
Daily reminder to be sent after
confirmation due date
System should allow department user to approve

CONF-006 confirmation or extend probation period on the system
The System should allow the user to provide comments

CONF-007 in case of both approval of confirmation and extension
of the probation
CONF-008 System should allow user to send confirmation case to

another level of approval in case required
System should generate automatic notification to concerned

CONF-009 department and employee about the confirmation approval
or probation extension
System should generate PDF document of the order

once the case is processed and send automatically along
CONF-009 with the notification to employee / department
Confirmation module will be integrated with all other

CONF-010 modules of HRMS for e.g. Service book , leaves ,
Recruitment , ACR, enquiry etc.
CONF-011 System should have audit trail for tracing transactions

Page 90 of 121
Employee Increment
Module Name Employee Increment
System should allow configurable set up of business rule

INC-001 in masters for applying increment (percentage ,
frequency etc.)
Increment - 3 % on basic pay

INC-002 System should auto apply increment on selected employees
Frequency - Twice a year (Business
based on configured rules
rules may change)
INC-003 System must allow department user to review the

increments of each employee
INC-004 System should allow user to change the increment applied

employee wise and in bulk for all employees
System should allow department user to select multiple

INC-005 employee increments and review and send these to
further level for approval
INC-006 System should allow department user to view & approve

the increments applied by the system
INC-007 System should send notification of increment for each

employee to accounts section
System should auto generate notifications to employee

INC-008 and department after certain date as entered in masters
/ in the form
System should auto update service book on completion

INC-009
of increment cycle
This module will be integrated with all other modules of

INC-010 HRMS for e.g. Service book , ACR, enquiry , payroll etc.
System should have audit trail for tracing transactions

INC-011 performed by all the users
Employee Transfer
Module Name Employee Transfer
Page 91 of 121
System should allow concerned department user to raise

TR-001 request for an employee transfer by entering employee
id and clicking on search
System should allow concerned department user to

TR-002 enter reason of transfer , suggested department to
transfer to etc.
System should allow approval of transfer request within

TR-003
the department
TR-004 System should allow department user to review and approve

/ reject the transfer request
TR-005 System should allow user to enter comments for

rejection / approval of transfer request
System should send the transfer request to GAD for further

TR-006
processing
System should allow GAD user to change the
TR-007 department and other fields as identified during
requirements stage
System should allow GAD user to review and approve the
TR-008
transfer request
System should generate automatic notification to the

TR-009 employee and department on approval of transfer
request
System should allow GAD user to raise transfer request

TR-010 for an employee transfer by entering employee id and
clicking on search
System should send the transfer request to GAD secretary

TR-011
for approval
TR-012 System should allow GAD sect.to edit the fields as identified
during requirements stage
System should allow GAD sect . to review and approve

TR-013
the transfer request
System should generate automatic notification to the

TR-014 employee and department on approval of transfer
request
System should allow configuration of workflow by

TR-015 admin of department to allow change of levels of
approval etc.
TR-016 System should generate PDF of transfer order and send

along with the notification over email
System should auto update service book upon approval

TR-017
of transfer request
Page 92 of 121
This module will be integrated with all other modules of
TR-018 HRMS for e.g. Service book , ACR, enquiry , payroll etc.
System should allow selection of department to be

TR-019 transferred even if the department is not yet onboarded
in the system
System will generate warning message if the employee is

TR-020 transferred to a department that is not yet onboarded
If the transferred to department is not yet on boarded ,

TR-021 system should by pass approval workflow and approve
the same and show the message that is was auto approved
by the system
TR-022 System should generate list of employee transferred to

the department that are not yet onboarded

TR-023 performed by all the users
Manual Process - In case of manual transfer user will be

TR-024 allowed to update the department of employee where he has
joined. Further he will be allowed to update relieving and
joining dates and upload the orders
Leave Management
Module Name Leave Management
Page 93 of 121
Tentative leave types -
Earned leave
Half pay leave
Commuted leave
Leave not due Extra-
ordinary leave
Leave to probationer, a person on
probation and an apprentice Leave
preparatory toretirement
Leave beyond the date of retirement,
System should allow definition of leave type compulsory retirement or quitting of
LM-001 master which will enable super admin to define service
leave types. This shall be configurable Maternity leave Paternity
leave
Child Adoption Leave
Special disability leave for injury
intentionally inflicted
Special disability leave for accidental injury
Power to grant special disability leave
Power to grant leave Other than special
disability leave
and study leave
System should allow configuration of leave rules

LM-002 basis employee type, department type of leave Refer to Leave rule book
etc.. These rules shall be configurable by super
admin as and when required
System should allow users to apply for different

LM-003
type of leaves (Form 1)
System will allow application to be approved by
LM-004 Authorized User / Head of
Department/Competent Authority
System should auto credit leave account of every Earned leave in advance in two
LM-005 Government servant who is serving in a installments of 15 days each on 1st
department other than a Vacation Department as January and 1st July every calendar year.
per defined rules
Maximum of 15 days reduced by the

number of days actually availed of, shall
System should credit leave account of an be credited to his leave account as
LM-006 employee who joins a new post without availing earned leave:
full joining time as per rules Earned leave at his credit together with the
unavailed joining time allowed to
be so credited shall not exceed 300 days.
Leave carried forward plus the credit for

LM-007 Systems should automatically carry forward leaves
the half year, should not exceed the
to next half year as per rules
maximum limit of 300days:
LM-008 System should allow granting of earned leaves at

a time only upto180 days
System should allow users to view leaves eligibility

LM-009
and leaves availed
Page 94 of 121
1. Applications for leave on grounds
other than ill health should be
System should not allow user to apply leaves after made at least three weeks before such date.
LM-010 the prescribed time limit 2. This limit would be six weeks if the
leave applied for is preparatory to
retirement.
System should allow uploading of medical

LM-011 certificate in application for leave , wherever
applicable
System should be able to record the approval/

LM-012 rejection of applied leaves and update the
employee leave account accordingly
System should support a Business Calendar and

LM-013 Leave Application dates should be validated
against this calendar
System should retain all leave history

LM-014
(approved, rejected)
System should have defined hierarchical

LM-015 workflows for recommendation and approval of
leaves. This shall be configurable by super
admin
LM-016 System should be able to generate alert for giving

reasons if leave is refused.
System should allow selection of general reasons

of refusal of leave from a dropdown menu and
LM-017 provide a text box for inserting other specific
reasons. These reasons can be modified in the
reason master
System will support backdating of leave by the

LM-018
authorized user
System should have pre- defined and
LM-019 configurable rules for the functionality of recall to
duty before expiry of leave.
System should allow competent authority to
LM-020 grant return from leave before the expiry of
leave period
System should allow to upload fitness certificate
LM-021 to resume duty in case of employee suffering from
tuberculosis
Module shall be integrated with attendance system
LM-022 , payroll for calculation of leaves and salary
Page 95 of 121
System should allow employee to upload Bond
to be executed by A Government servant in
LM-023 permanent / not in permanent employ when
proceeding on study leave or extension of study
leave (Where ever required)
This module will be integrated with all other

LM-024 modules of HRMS for e.g. Service book , ACR,
enquiry , payroll etc.
LM-025 System should have audit trail for tracing

transactions performed by all the users
Annual Confidential Report
Module Name ACR

System should allow employee to and submit the self-
ACR-001 appraisal form to the next authority (i.e. Reporting
Authority)
System should send a notification in form of an email and
ACR-002 dashboard popup to the intended user(s) in the hierarchy
System should display all the information filled in by the

ACR-003
applicant in the self-appraisal
System should allow the authorized user to add comments
ACR-004 and provide grades as per the form displayed for the user
The user(s) will be able to submit the form to the next

ACR-005 authority in the hierarchy after providing the respective
comments and grading
System should allow the user(s) to have access to the

ACR-006 comments and grades provided by the user(s) which are below
in the hierarchy
System should send notification to the respective branch/

ACR-007 user for filing the ACR report once the ACR is freezed
System should allow authorized user / DEO to maintain

ACR-008 details of employee appraisals, assessments and review of
assessments
ACR-009 This module would be integrated with Employee Service

Record, Leave Management module ,enquiry etc.
Page 96 of 121
The System should send a notification to the employee
ACR-010 along with all required user(s) once the grades are freezed
by the final authority in the hierarchy
The System should display only the final Grades and

ACR-011
comments to the employee
The System should provide a representation form to the

ACR-012 employee and allow the employee to provide the
representation as per the form
The System should allow the authorized user (in this case
ACR-013 accepting authority) to scrutinize the representation
The System should allow the Authorized user to interact

ACR-014 with the employee all other involved in order to understand
the case in a better way
The Authorized user (in this case the accepting authority)

ACR-015 should be given the privileges to access all the comments
and grades provided by all the authorities in the hierarchy
ACR-016 The System should allow the authorized user to access all
the service records of the employee
The System should allow the authorized user to change the
ACR-017 final comments and expunge any of the comments provided
ACR-018 The System should have the marking based mechanism

for appraisal system for all the authorities
The System should also send the reminder notifications for

ACR-019
all any pendency
ACR-020 performed by all the users
Grievance Management
Module Name Grievance Management

System should allow raising grievance for retired as well
GM-001 as present employees to file grievance by filling in the
form for grievance.
System should generate unique reference number for each
GM-002
grievance raised
GM-003 System should send notifications to centralized

grievance team for grievance raised
GM-004 System should forwarded the grievance raised to the

concerned department.
System should allow the user at the department to

GM-005 provide the comments on the grievance request after
enquiry
Page 97 of 121
System should allow department user to send the grievance
GM-006 to other department in case wrong department is selected
by the user
GM-007 System should also send reminder notifications for pending

request as well as when a request is closed
System should allow the user to update the verification

GM-008 report for the respective grievance requests
GM-009 System should allow the user to generate the grievance

report for the respective requests
System should allow the user to share the order with all
GM-0010
concerned users/ branches
GM-011 performed by all the users
Departmental Enquiry
Module Name Departmental Enquiry
System should allow concerned officer to raise show

EN-001 cause notice to employee by entering employee id and
searching
System should send notification to the concerned employee

EN-002 after the SCN is issued
EN-003 System should allow employee to reply to SCN and upload

documents if any
EN-004 System should allow concerned officer to view reply to show

cause notice
System should allow Concerned officer to examine reply.

Also will be able to Issue Penalty/Appoint Enquiry
EN-005 Officer/ Drop Charges as per requirement of case.
System should have the provision for recording

EN-006 Departmental Enquiry & proceedings
System will allow enquiry officer to prepare and submit

EN-007 detailed report to the Competent Authority
EN-008 System should have configurable workflow to be

changed at a later stage
Page 98 of 121
System should allow concerned officer to generate
EN-009 statement of pending cases on a monthly basis which
describes the status of the cases.
System should support searching of case by employee

EN-010 number (ID), employee name, case number (ID) etc.
EN-011 System will have the facility to close the case.

EN-012 performed by all the users
Employee Exit and Pension Management
Module Name Employee Exit

System should allow master to be created reasons for exit Reasons of exit - retirement , VRS ,
EE-001
Resignation
EE-002 System should generate automatic notification 2 years

before the retirement date to the employee
EE-003 System should auto calculate date of retirement based

on date of joining and retirement age
System should allow employee to fill pension and PF form

EE-004 with all the details and submit to concerned department
System should allow concerned officer tin department to

EE-005 view the form and uploaded documents and review the
form
System should allow department officer to send the form
EE-006 back to employee after giving comments if any
discrepancy found in the form
System should allow employee to edit the details and upload
EE-007
documents if required
System should allow officer to review the updated form
EE-008 and documents and send to accounts section for further
processing
Accounts section can either approve or send back the form
EE-009 to employee/ department to update if any discrepancy
found
EE-010 System should send the approved pension details to IFMS

via integration for further processing pension
This module will be integrated with service book to fetch

EE-011
details like nomination etc.
System should allow to apply for VRS by filling in online
EE-012
form
Page 99 of 121
System should check the length of the service basis joining 20 years of service length is
EE-013
date of the employee mandatory for applying VRS
System should allow concerned officer to view the VRS
EE-014
and approve or raise queries
System should allow employee to edit the form and upload
EE-015
document if required
EE-016 System should allow concerned officer to send the form

for further processing dues to accounts section
System should fetch relevant fields from service book and

EE-017
will be non –editable
System should allow employee to submit resignation online
EE-018
by filling in the required form
System should allow concerned officer to review the
EE-019
form and raise queries / approve
System should allow employee to edit the form and upload
EE-020
document if required
System should allow officer to view and update last working
EE-021
date basis rules configured
System should send the approved form with accounts
EE-022
section to further process dues
EE-023 The system should generate the certificate/letter related

to VRS, Resignation etc.
System should allow accounts section to notify employee

EE-024
if dues pending from employee
EE-025 The system should generate retirement orders.
The system should automatically stop GPF deductions 4
EE-026 months prior to retirement date of employee.
The system should generate the relieving letter for an

EE-027
employee.
System should generate alerts to the employee for filling
EE-028 the pension papers and submitting it to department

EE-029
System should be integrated with IPEG and e-Pramaan for
EE-030
data exchange
EE-031
System Administration
Module Name System Administration
Page 100 of 121

ADM-001 System should have one admin of each department and
one super admin above all department's admin
Department admin will perform all functions related to

ADM-002 his department and super admin will be responsible for
managing department admin users
ADM-003 Super admin will define department admin while on

boarding of department in the system
ADM-004 System should allow department admin to reset password

for his / her department employees only
ADM-005 System should allow super admin to reset password of

all department admins
System should allow configuration of role and

designation of each employee within the department
ADM-006 with the help of offline utility upload. Upload utility to be
filled in by department and sent to super admin offline.
Uploading will be done by super admin
System should capture additional or exceptional roles
ADM-007
assigned to a user
System should provide feature to modify approval
ADM-008
workflow
System should capture effective time period for the
ADM-009
additional roles
System should provide an authentication mechanism

ADM-010 which controls access to System and which validates each
user attempting access at the start of each user session
ADM-011 Users should be able to access the applications their NIC or

any other official email id
System should provide definition of a user profile for

each user known to system. A user profile must always
ADM-012 identify a functional role for the user, and must enable
allocation of access control
System should support the definition of a set of user roles,

which control the assignment of rights to specific functions
ADM-013 or groups of functions; and must restrict any ability to
define or customize these roles to an administrator
System should ensure that all users are allocated to one or
ADM-014 more user role(s).
System should enable the allocation of a security category,

and predefined access control group membership, to a role
ADM-015 so that all users allocated to that role automatically inherit
the access permissions of the role
Page 101 of 121

System should support the definition of pre-defined access
control groups which identify business or other functional
groups, so that, in principle, any user can be a member of
ADM-016 any group, and differing groups at differing times; and
must restrict this ability to allocate and reallocate to a
Administrator
System must limit access to folders and records which have
been allocated a pre-defined access control group, only to
ADM-017 those users who are members of that group
System shall be able to archive transactional database

ADM-018 records to prevent long term speed concerns. The solution
must also feature functionality for efficient retrieval of
archived data.
System should be able to automatically record an audit

trail of events under the control of System, storing
ADM-019 information about action which is being carried out, The
object(s) to which the action is being applied , The user
carrying out the action, The date and time of the event
System should track and record information about events
ADM-020 in the audit trail without manual intervention
Appendix B - Data Migration and Integration with State and

Central Government Systems
Data Migration
Before go live of each phase SI should ensure data is migrated from existing application to new
enhanced version and make sure that old data is available to users for use.
During the 4 years of O & M period any migration activities required to be carried out due to
change in Infrastructure, Software, etc. should be done by bidder at no extra cost. This will not
be considered as any change request and should be done by deployed O&M team
Integration
System should be based on open standards and have API support for data import & export so that
integration with the Common Services can be done.
 Integration with Centralize Grievance system

 Integration with e-Sign (UIDAI) for Biometric & OTP Verification and Signing
 Integration with Stylers for text input or any state of the art technology available for this
Page 102 of 121

 Expose and use API for other applications
 Integration with IFMS applications like e-kosh, pension management system.
 Integration with e-docket.
 Integration with CDAC SMS Portal
 Integration with NIC’s email system
 Any other as per requirement of dept. going live on DS
Appendix C - Other Requirements

The system requires different interfaces like user, software and communication to interact with
each other.
General
The following standards may be adhered to the project:
 Web Standards will be followed to ensure consistency across the web pages. The site will
be best viewed with latest Internet Explorer and standard screen resolution.
 Terminology used in the interface/pages will be easily understandable by the user.
 Language interoperability will be a part of Digital Government2.0
 All interface/pages performing similar functionality will have consistent look and feel.
Appropriate titles will be given to each page. The titles will specify the functionality of the
page.
 Access to the functionality of the application will be controlled based on the user type.
 Navigation facilities will be provided to navigate from one page to another page with
minimum number of clicks.
 The selection and navigation related facilities in all screens must be standard. Buttons will
be labeled appropriately. The input screens will require least number of key presses and
mouse clicks.
 Customized error messages for invalid input will be provided in all the pages whereas
completion/confirmation messages will also be displayed on successful processing of data
Operational Requirements
Recoverability
In any course of failure system should be ready for fallback mechanism. The system can switch
from PR to DR site immediately in case of system failure.
Page 103 of 121

 All data and applications should be restored immediately.
 To manage hardware failure, data will be backed up on tape drives at regular intervals
 The database must be capable of being restored to its condition of no more than 1 hour
before the corruption occurred.
 In case of processing site is destroyed, the application must be able to be restored as

soon as possible.
System Availability
The application must be available to users on absolutely continuous basis. Any scheduled
maintenance activity should be carried out during the night hours. System unavailability is least
acceptable during 0800 to 2000 hours during any day.
Performance
The portal for Digital Secretariat 2.0 will match the user expectations with regard to performance
requirements. Creation of necessary ICT infrastructure will be created at State IT headquarters,
government departments and for other stakeholders. Further, trial/test run will be conducted
across the state with participation of authenticated users of different departments. This will help
to understand how fast the system handles individual requests in order to figure out the average
response time. Trial/Test run will also provide information on throughput in terms of no. of
requests the system can handle and concurrency in terms of no. of users working simultaneously.
Based on the outcomes, system will be tuned for optimum performance. Optimum performance
will ensure minimum time which a user has to spend for getting the response to avail any service
through the Digital Secretariat 2.0 portal.
Data retention
The system shall retain application information for infinite time. Different forms of data include
system documentation, audit records, database records, access records etc. System shall archive
the data from time to time as defined by the system administrator.
Conventions/standards
Page 104 of 121

All global data standards are to be followed in the system. Microsoft standards are followed for
windows, Institute of Electrical and Electronics Engineers (IEEE) for data formats, etc.
Recommended Technology Stack

Solution Type
Operating System Open Source
Web server Open Source
Application server Open Source
ORM Open Source
UI Scripting Framework Open Source
Reporting/Search Open Source
SQL Data base Postgre SQL 12 – EDB Standard

support
Application & Core Services Open Source

– APIs
Content Management Open Source

System
Workflow Open Source
Rule Engine Open Source
Reporting Framework Open Source
Continuous Integration Open Source
Testing Tools Open Source
Appendix D - Service Level Agreement

The purpose of this Service Level Agreement (hereinafter referred to as SLA) is to clearly define
the levels of service that shall be provided by the SI to the CHiPS and other stakeholders for the
duration of the Project Term.
Page 105 of 121

SLAs shall become part of Agreement between the CHiPS and the SI. SLAs define the terms of the
SI’s responsibilities in ensuring the timely delivery of the deliverables and the correctness of the
same based on the agreed performance indicators as detailed in this section. The SI has to comply
with service level requirements to ensure adherence to project timelines, quality, functionality
and availability of solution.
Liquidated Damages shall not be levied in the following cases:
• There is a Force Majeure event affecting the SLA which is beyond the control of the SI.
• The non-compliance to the SLA is due to reasons beyond the control of the SI.
Note:
• Theft cases, by default, would not be considered “beyond the control of SI”. However, in
certain cases, based on circumstances and certain locations, the CHiPS may agree to qualify
as “beyond the control of SI”. The same may be mutually agreed and signed between the SI
and the CHiPS.
• Power shut down of less than 1 hour would not be considered as “beyond the control of SI”.
• SI is also required to note that in case of SLAs not being made applicable for cases considered
as “beyond the control of SI”, the SI would still need to replace the component (if it is not
functional as per SLA) within the SLA defined for resolution of Critical/ High/ Medium/ Low
Priority level incidents.
D.1 Definitions
For the purposes of this service level agreement, the following definitions and terms shall have meaning
as tabulated below:
# Term Definition
a. Uptime Shall mean the time period for the specified services / components with
the specified technical service standards are available to the users.
Uptime, in percentage, of any component (Non-IT and IT) can be
calculated as:
Uptime = {1- [(Downtime) / (Total Time – Scheduled Maintenance

Time)]} * 100
Page 106 of 121

# Term Definition
b. Downtime Shall mean the time period for which the specified services /
components with specified technical and service standards are not
available to the user department and excludes downtime owing to
Force Majeure & Reasons beyond control of the SI.
c. Not Keeping Shall mean that the SI does not deploy the proposed quantity and
Manpower quality of manpower to meet the system requirements or a person
deployed is not reporting to duty.
d. Incident Refers to any event/abnormalities in the functioning of the Services

specified as part of the Scope of Work of the SI that may lead to
disruption in normal operations of the system.
e. Response Time Shall mean the time elapsed from the moment an incident is reported
(For Incidents) in the Helpdesk, over phone or by any applicable mode of
communication, to the time when a resource is assigned for the
resolution of the same.
f. Response Time Time elapsed between receipt of request at the server and issuance of
(For Software) response by the server
g. Resolution Shall mean the time taken (after the incident has been reported at the
Time (For helpdesk) in resolving i.e. diagnosing, troubleshooting and fixing the
Incidents) reported incident
h. Non-Working All Sundays, 2nd and 3rd Saturdays of Months and all Public Holidays
Days declared by Government of Chhattisgarh
i. Business hours 10am to 6pm on all days except non-working days
j. Days All Working and Non-Working days (365 days in a calendar year)
k. 24*7 Three shifts of 8 hours every day, this is applicable for all seven days of
the week without any non-working days
l. Scheduled The time that the System is not in service due to a scheduled activity as
Maintenance defined in this SLA. The scheduled maintenance time would not be
Time during 16X7 (7:00 am to 11:00 pm) timeframe. Further, scheduled
Page 107 of 121

# Term Definition
maintenance time is planned downtime taken after permission of
CHiPS.
m. Scheduled The scheduled operating hours of the System for the month. All
operation time scheduled maintenance time on the system would be deducted from the
total operation time for the month to give the scheduled operation time.
The total operation time for the systems and applications will be
24X7X365 (per year).
n. “Helpdesk The support centre which shall handle Fault reporting, Trouble
Support” Ticketing and related enquiries during this contract. Helpdesk support
is to be provided as per service window defined in this RFP.
o. Incident Any event/abnormalities in the functioning of the any of SI

provided/implemented software services that may lead to disruption in
normal operations of the Cloud, Data Centre, System or Application
service
D.2 SLA Framework
This section describes the SLA framework for this contract comprising of the following:
 Responsibilities of parties
 Reporting procedures
 Issue management procedures
 Management escalation and contact map
 SLA change control
D.2.1 Responsibilities of parties
The responsibilities of the CHiPS are:
 Reporting defects and problems to the SI’s representative as soon as possible

 Providing early warning of any organizational, functional or technical changes that
might affect SI’s ability to deliver the services described in the SLA
 Provide administrative support to SI to resolve incidents in a timely manner
Page 108 of 121

The responsibilities of SI are:
 SI is responsible for delivering the services described in scope of work as per the service
levels detailed in this document.
 Additionally, SI is responsible for:
o Reporting problems to the CHiPS as soon as possible
o Enable the CHiPS to monitor the SLA
o Providing early warning of any organizational, functional or technical changes that
might affect SI’s ability to deliver the services described in the SLA
o Resolve the production incidents in a timely manner
 Immediate action will be taken to identify problems and follow up with appropriate
action to fix identified and those reported issues as quickly as possible.
 Overall coordination with CHiPS for effective implementation
D.2.2 Reporting procedures

The SI’s representative will prepare and submit SLA performance reports in an agreed upon
format by the 7th working day of subsequent month of the reporting period. The reports will
include “actual versus target” SLA performance, a variance analysis and discussion of appropriate
issues or significant events.
D.2.3 Issue management procedures

 This process provides an appropriate management structure for the orderly
consideration and resolution of business and operational issues in the event that quick
consensus is not reached between CHiPS and SI. It is expected that this pre-defined
process will only be used on an exception basis if issues are not resolved at lower
management levels.
 Either CHiPS or SI may raise an issue by documenting the business or technical
problem, which presents a reasonably objective summary of both points of view and
identifies specific points of disagreement with possible solutions.
 CHiPS and the SI’s representative will determine which committee or executive level
should logically be involved in resolution. A chain of management escalation is defined
in next section.
Page 109 of 121

 A meeting or conference call will be conducted to resolve the issue in a timely manner.
The documented issues will be distributed to the participants at least 24 hours prior to
the discussion if the issue is not an emergency requiring immediate attention.
 Management of CHiPS and SI will develop a temporary, if needed, and the permanent
solution for the problem at hand. The SI will then communicate the resolution to all
interested parties.
 In the event a significant business issue is still unresolved, the arbitration procedures
described in the Contract will be used.
D.2.4 Management escalation procedures and Contact Map

 The purpose of this escalation process is to provide a quick and orderly method of
notifying both parties that an issue is not being successfully resolved at the lower
management level. Implementing this procedure ensures that CHiPS and SI’s
management are communicating at the appropriate levels.
 Escalation should take place on an exception basis and only if successful issue
resolution cannot be achieved in a reasonable time frame.
 Either CHiPS or SI can initiate the procedure
 The “moving party” should promptly notify the other party that management
escalation will be initiated
 Escalation will be one level at a time and sequentially
Management escalation will be defined as shown in the contact map below

Name Designation Party Contact
CHiPS
SI
D.2.5 SLA Change Control

It is acknowledged that the SLA may change as CHiPS’s business needs evolve over the course of
the contract period. As such, this document also defines the following management procedures:
 A process for negotiating changes to the SLA
 An issue management process for documenting and resolving particularly difficult
issues
Page 110 of 121

 CHiPS and SI’s management escalation process to be used in the event that an issue is
not being resolved in a timely manner by the lower level of management
Any changes to the levels of service provided during the term of the Service Level Agreement will
be requested, documented and negotiated in good faith by CHiPS and SI. CHiPS or SI can request
a change. Changes will be documented as an addendum to this attachment and, consequently, the
Contract. If there is any confusion or conflict between the Contract and this document, the Tender
and its addendums, the Contract will supersede.
The parties may amend this SLA by mutual agreement in accordance. Changes can be proposed
by either party. The SI’s representative may initiate an SLA review at least bi-annually, if required.
Unresolved issues will be addressed using the issue management process described in Clause
Section D.2.3 of this document.
The SI’s representative will maintain and distribute current copies of the SLA document as
directed by CHiPS. Additional copies of the current SLA will be available at all times to authorized
parties.
All negotiated SLA changes will require changing the version control number. As appropriate,
minor changes may be accumulated for periodic release (e.g. every quarter) or for release when a
critical threshold of change has occurred.
D.2.6 Measurement of SLA

The SLA metrics specify performance parameters as baseline performance, lower performance
and breach. All SLA calculations will be done on quarterly basis. The SLA also specifies the
liquidated damages (LD) for lower performance and breach conditions. Payment to the SI is
linked to the compliance with the SLA metrics.
The mentioned SLA parameters shall be measured as per the individual SLA parameter
requirements and measurement methods, through appropriate SLA Measurement tools to be
provided by the SI and approved and audited by CHiPS for accuracy and reliability.
SI shall provide the necessary tools required to measure the SLA parameters mentioned in this
Agreement. The SI shall be generating monthly SLA reports to CHiPS. CHiPS may appoint a
Third-Party Agency to audit the performance, accuracy and integrity of the tools generating SLA
data and also review the monthly SLA reports for SLA penalty computation.
The CHiPS shall also have the right to conduct, either itself or through any other agency as it may
deem fit, an audit/revision of the SLA parameters. The SLAs defined, shall be reviewed by the
Page 111 of 121

CHiPS on an annual basis after consulting the SI, Project Management Consultants if any, and
other experts. All the changes would be made by the CHiPS post consultation with the SI and
might include some corrections to reduce undue relaxation in Service levels or some corrections
to avoid unrealistic imposition of liquidated damages, which are noticed after project has gone
live.
Total liquidated damages to be levied on the SI shall be capped at 25% of the contract value. The
CHiPS would have right to invoke termination clause of the contract in case the overall liquidated
damages equals or exceeds 25% of contract value.
If SLA penalty calculations exceed 15% of the quarterly payment for two consecutive quarters or
25% in any quarter, then CHiPS may take appropriate action including termination of the contract
and invoking the Performance Bank Guarantee.
D.2.7 SLA Holiday period
The first quarter post successful Go-Live (phase 1 and phase 2 and phase 3) shall be termed as holiday
period for SLAs, wherein the SLAs shall not be applicable on the SI (but it must be monitored and
measured). This SLA holiday period is only for the purpose of streamlining the operations and monitoring
of the systems and processes.
D.2.8 Categories of SLA
Category SLAs
Manpower  Team mobilization, Setting up of Project Management Office and

commencement of work
 Minimum Tenure of Manpower (Applicable for Key Manpower
Personnel)
 Non-Availability of Acceptable Resource (Applicable for Key
Manpower Personnel)
Milestones  Attainment of key milestones as defined in Volume I clauses Project

timelines, Payment terms & schedule,
Operational SLR  System Usage Reporting

 Monitoring
 Back up and recovery Services Meterics Log
 Security breach including Data Theft/Loss/Corruption
Page 112 of 121

Category SLAs
Software  Critical Applications Availability

 Non-Critical Applications Availability
 Application Performance for Critical Applications
 Application Performance for Non-Critical Applications
 Software Patches and Updates
Security  Security Incident Closure

 Security Vulnerabilities Closure
Helpdesk  Helpdesk Incident Response Time

 Helpdesk Incident Resolution Time (P1 – Severity 1)
 Helpdesk Re-opened Incidents
Miscellaneous  Project Management Report
Category-I: Manpower
SLR(Service Level Measurement Parameter Penalty

Requirement)
Team mobilization, Number of days from the prescribed time-limit • No delay: No
Setting up of Project from the date of signing (Refer Pt. 13 of Vol1 Liquidated damage
Management Office and of RFP). • Every week (or part
commencement of thereof): INR
1
work Rs.10,000 per
resource per week (or
part thereof from the
milestone payment)
Page 113 of 121

Number of months of actual deployment. This • At least 6 months:
Minimum Tenure of SLA will be calculated separately for each No Liquidated
Manpower resource of SI damage
• Less than 6 months
but more than or
equal 4 Months: INR
Rs.10,000 per
resource
2
• Less than 4 months
but more than or
equal 2 Months: INR
Rs.20,000 per
resource
• Less than 2 months:
INR Rs.30,000 per
resource
Non-Availability of In case SI is not able to provide approved • Zero days: No
Acceptable Resource replacement of resource in a timely manner. Liquidated damage
Upon replacement of resource, the number of • Every week (or part
days for which a position remains vacant due thereof from the
3 to unavailability of resource acceptable milestone payment):
INR 50,000 per
resource
Category-II: Key Milestones
SLR(Service Level Measurement Parameter Penalty Breach

Requirement)
Key Milestones
Page 114 of 121

Achievement of Key 0.25% of the
Milestones (other contract value
than Go-Live) on- per week (or part
time on or before thereof from the
1 the deadline as milestone
mentioned in the payment) from
contract without the due date.
delay. To be measured in number of
Achievement of Key weeks of delay (or part 0.5% of the If the Go-Live gets
Milestones ( Go- thereof) from the timelines contract value delayed beyond 16
Live) on-time on or mentioned in the Volume 1 of per week for week(s) from the due
before the deadline this RFP every date (delay solely
as mentioned in the subsequent week attributable to the SI),
2 contract without (or part thereof then CHiPS reserve
delay. from the the right to invoke the
milestone termination clause in
payment) from addition to the
the due date. liquidated damages
mentioned above.
Category-III: Operational SLR
SLR(Service Level Measurement Parameter Penalty Breach

Requirement)
Service Availability
1 System Usage Always Available- No
Reporting(with Penalty
Detailed MIS) MIS Reports /Online
Reporting tool Not Available -0.25% of
total quarterly invoice
value
Page 115 of 121

2 Version Maintenance Always Available- No
Logs: To maintain Penalty
System Log/Online
detailed log for all
Monitoring Not Available -0.25% of
version related Tool/Application total quarterly invoice
change and Log/MISetc value
document history
3 Monitoring : Real- Always Available- No

time dashboard to be Penalty
made available for Online Application
monitoring purposes Monitoring Tool to Not Available -0.5% of total
measure various SLA quarterly invoice value
parameters
4 Back-Up and Always Available- No

Recovery Services System Log/Online Penalty
Metrics Monitoring
Tool/Application Log/MIS Not Available -0.5% of total
etc quarterly invoice value
6 Security breach Any security breach case of serious

including Data incident detected INR << 5 breach of
Theft/Loss/Corruptio Lakhs>> for each such security
n incident. wherein the
data is stolen
or corrupted,
Government
reserves the
right to
terminate the
contract.
Page 116 of 121

Category-IV: Software
SLR(Service Level Measurement Parameter Penalty

Requirement)
Uptime of Refer to Annexure D, Section D.1 for definition of

Application and Uptime.SLA will be measured 24x7 on a quarterly • >= 99.9%: No Liquidated
Mobile App (>= basis, for each critical component damage
99.9%) • < 99.9% and >=99%: 2% of
Both User / Admin Portal and Mobile App and APIs
Quarterly Amount (QAP)
(where applicable) should be more than >=99.9 %
• <99%: 5% of Quarterly
Amount
1
Application
Performance for  If Response time < 2
Critical sec ,NoPenalty.
Applications
 If Response time >2
(DAK,File,IHRMS)
sec<8sec,2% of
Transaction quarterly invoice per
meeting the incident reported.
Response Time would be calculated as time
prescribed Target elapsed between sending a request from client to
 If Response time
Response Time (2 server and receiving the response. Response time
>8sec,5% of
seconds) for of services to be measured at an interval of 30 quarterly invoice per
Business minutes and all transactions not meeting incident reported.
Transactions for prescribed Target response time is recorded in
critical Application Monitoring Tool.
2 components
Application  If Response time < 5

Performance for sec ,NoPenalty.
Non-Critical
Applications  If Response time >5
sec<8sec, 2% of
Transactions quarterly invoice per
meeting the incident reported.
prescribed Target  If Response time >
Response Time (5 8sec, 5% of
seconds) for quarterly invoice per
Business incident reported
3 Transactions for
Page 117 of 121

non-critical
components
With in 1 month – No
Liquidated Damage
Software Patches
and Updates Number of days elapsed from the availability of >1month Rs 5000 per patch
latest patches on the system components.
4
Document Captured Values in System Log, Monitoring tool. If Retrival Time>2 seconds<8
Retrieval Time
Retrieval Time: Average of 2 second on retrieval of seconds-1 percent of
(File, Letter, quarterly invoice per
an average size of file, which is in use within last
Report ,Scanned
three months ;with 2000 concurrent users logged- incident reported
Documents )
in on the system with sizeable data in database If Retrieval Time > 8 second-
5 percent of quartely invoice
5 per incident reported
Search Search time for a document archived with different

Experience(Search search options in a sizeable database. If Retrival Time>2 seconds<8
archived seconds-2 percent of
Average of 2 seconds on data collected on running quarterly invoice;
documents with
system with average load for one month
different If Retrieval Time >8 second-
keywords and 5 percent of quarterly
other relevant invoice
6 texts)
Page 118 of 121

Category-V: Security
Security Vulnerabilities Closure
SLR(Service Level Requirement) Measurement Parameter Penalty
Security
Security Vulnerabilities Closure To be measured in number of • No Delay: No Liquidated
(Security vulnerabilities detected days of delay (or part thereof) damage
during Periodic Security beyond prescribed time-limit of • Delay (<=7 days): Rs. 50,000 per
Assessment (Vulnerability 7 days. incident per day
Assessment, Penetration Testing, • Delay (> 7 days): Rs. 1,00,000
etc.) should be closed within pre- (One Lakh) per incident per day
defined timelines.)
Category-VI: Helpdesk
Response Time
Call /TicketsType Response Time Measurment Penalty (Response Time)

Parameters(Response
Time)
PRIORITY 1 Tickets Respond to call
(System not immediately(within
operational / More 15 mins.)
than 100 users
affected)
PRIORITY 2
Percentage of incidents
(System is
acknowledged and respond
impaired/More than
Incidents within SLR in a reporting
10 users less than
acknowledge and quarter
100 users affected)
respond once a • >=95% of No Liquidated
ticket/incident is damage .
Respond to call
logged through any of • <95%: 1% of Quarterly
PRIORITY 3 immediately
the agreed channels. Amount Payable (QAP) per
(System is running (within 30
one-percentage drop below
with no significant minutes.)
the target of 95%
impact/ Single user
requests)
Page 119 of 121

Resolution Time
Call /Tickets Type Resolution Time Measurment Penalty(Resolution

SLR Parameters(Resolution Time)
Time)
PRIORITY 1 Tickets Within 4 hours Resolution Time
(System is not of problem exceeding 4 hours from
operational ) reporting call logging shall attract
a penalty of Rs.10000
per hour up to 8 hours
for each such incident
PRIORITY 2 Resolved within • <=24 hours (No delay):
Time taken (after the
(System is impaired) 24 hours of No Liquidated damage
incident has been
problem • >24 hours: For each 2
reported at the
reporting hours of delay, 0.25% of
helpdesk) in resolving
Quarterly Amount
i.e. diagnosing,
Payable (QAP)
troubleshooting and
fixing the reported
PRIORITY 3 Resolved within incident. • <=48 hours (No delay):
(System is running 48 hours of No Liquidated damage
with no significant problem • >48 hours: For each 8
impact) reporting hours of delay, 0.1% of
Quarterly Amount
Payable (QAP)
Re-opened Incidents •<=2%: No Liquidated

(For all incidents damage
which are •>2%: 1% of Quarterly
designated resolved Target: Less than 2% Amount Payable (QAP)
by the SI, but are re- per one-percentage
opened by the client drop below the target of
) 2%
Page 120 of 121

Category-VII: Miscellaneous
Project Management Report
Definition Details
Service Level Till go-live, the monthly reports are required to be submitted by the SI. After go-
Requirement live, the quarterly reports are required to be submitted by the SI. These reports
should be submitted within prescribed time-limit as follows:
 On or before the 7th of next month (Monthly Report)
 On or before the 15th of next month (Quarterly Report)
Measurement of For purpose of calculation, the percentage will be rounded-off.

Service Level
Parameter
Liquidated Monthly Reports: Rs. 10,000 (Ten Thousand) per incident of delay per week
damage for Non-
Quarterly Reports: Rs. 50,000 (Fifty Thousand) per incident of delay per week
achievement of
SLA Requirement
Page 121 of 121

RFP 71626 DS2.0Volume1

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RFP 71626 DS2.0Volume1

Uploaded by

Copyright:

Available Formats

RFP for Selection of SI for Design, Development, Implementation and Maintenance of CG Digital Government 2.

Request for Proposal (RFP) for

Chhattisgarh infotech Promotion Society (CHiPS)

State Data Centre Building, Near Police Control Room,Civil

7.6 Infrastructure Hosting & Support ............................................................... 54

Project Management Report ............................................................................ 121

1 About this RFP

Through this RFP, CHiPS intends to:

3 Name of the issuer of this tender CEO, CHiPS

4 Date of issue of tender document 8th April ,2021

5 Last Date for Submission of 19 April,2021 till 3 pm

6 Pre-Bid Meeting Pre-Bid Meeting will be held on 22nd April

7 Publishing of pre-bid 26th April 2021

9 Date of Opening of Technical Bids 11th May 2021 at 3 pm at Chhattisgarh Infotech

10 Date of Technical presentations To be intimated

11 Date of Commercial Bid opening To be intimated

12 Place of Opening of Bids The Office of CEO, CHiPS, State Data

13 Address of Communication 492001

14 Cost of Tender Document Should have made online payment of Rs.

16 Purchase of Tender Document Download fromwww.chips.gov.in or

17 Validity of Proposal Proposals must remain valid 180 days after

19 Bid Submission  Bid Submission will be online through

20 Contact person for queries CEO, CHiPS

Office of CHiPS, Civil Lines Opposite New

Key Project Undertaken by the CHiPS

 State Wide Area Network -CG SWAN

 Geographical Information System (GIS)

5 Background Information of Digital Secretariat 1.0

5.1 Key Features

5.2 Current Implementation Status:

5.3 Description of Modules

 Unique numbering for every DAK

Following features have been developed in this module:

 Unique numbering for every File

Sample illustration of workflow

Following features have been developed in this module:

 Committee Creation with documents

Sample illustration of workflow

Following features have been developed in this module:

 Employee Information System

 System defined SLAs

5.4 Digital Secretariat Current Environment

Service Delivery Channel Direct

Service Category G2G

Project Component Digital Secretariat 2.0 , Mobile App, WCD

Number of Users 2000 +

Hardware At Chhattisgarh State Data Center

Digital Secretariat 2.0 The entire development of Digital Secretariat 2.0

Database The Digital Secretariat 2.0 system utilizes a Postgres

Servers ● Application Server – wildfly-17.0.0.Final and

● Web Server – Apache

5.5 Critical elements of Digital Secretariat 1.0

5.5.2 Physical Architecture

5.5.3 Deployment Architecture

5.5.4 Existing Hardware Details

Dell EMC Intel Xeon

6 Project Overview and Definitions of Digital Secretariat 2.0

Objective of Digital Secretariat 2.0:

Efficient Government of Chhattisgarh envisages to build an efficient system that

Ensure the Continuity

Online ACR filing – Appraisal system for government employees

Online file disposal