Core SI RFP Volume I

Request For Proposal
Request For Proposal (RFP) for Core System

Integrator (CSI) for IT Modernisation Project

Volume I: Functional, Technical and Operational
Requirements

DEPARTMENT OF POSTS
MINISTRY OF COMMUNICATIONS & IT
GOVERNMENT OF INDIA
21
st
April 2011

RFP for Core System Integrator Volume I
Reference No: 12-7/2010-PMU dated 21/4/2011 2 of 354
Contents
1. Introduction .................................................................................................................................... 7
1.1 About Department of Posts .................................................................................................... 7
1.1.1 Overview ......................................................................................................................... 7
1.1.2 Organisation Structure .................................................................................................... 7
1.2 Business Priorities of Department of Posts .......................................................................... 11
1.3 India Post 2012 Project Introduction .................................................................................... 13
1.3.1 Vision of India Post 2012 ............................................................................................... 13
1.3.2 Definition of India Post 2012 ........................................................................................ 14
1.3.3 Proposed Solution Blueprint ......................................................................................... 15
1.4 India Post 2012 Vendor Selection Process ............................................................................ 17
1.4.1 RFP Scope ...................................................................................................................... 18
1.5 Interdependencies between Vendors................................................................................... 19
1.5.1 Mapping of Solution Blueprint to different vendors .................................................... 20
1.5.2 Detailed Interdependencies between vendors............................................................. 22
1.6 RFP Structure ........................................................................................................................ 33
2. Business Functions Covered under the Core SI ............................................................................ 34
2.1 Mail Operations .................................................................................................................... 34
2.1.1 Current State Overview ................................................................................................. 34
2.1.2 To-Be Process Description ............................................................................................ 40
2.1.3 Functional Requirements .............................................................................................. 41
2.1.4 Implementation Plan..................................................................................................... 42
2.2 Logistics Post ......................................................................................................................... 43
2.3 Philately ................................................................................................................................. 46
2.4 Finance & Accounts (F&A) .................................................................................................... 49
2.5 Human Resources (HR) ......................................................................................................... 54
2.6 Customer Interaction Management ..................................................................................... 59
2.7 Call Centre ............................................................................................................................. 63
2.7.3 Operational Requirements ............................................................................................ 64
2.8 Customer Information Management .................................................................................... 71
2.8.1 One View Customer Experience.................................................................................... 71
2.8.2 One View Business Experience ..................................................................................... 71
2.8.3 Customer Analytics ....................................................................................................... 71
2.9 Common Infrastructure Solution .......................................................................................... 72
2.9.1 Enterprise Service Bus (ESB) ......................................................................................... 72
2.9.2 Email solution ................................................................................................................ 72
2.9.3 Directory Services ......................................................................................................... 72
2.9.4 Enterprise Monitoring System (EMS) ............................................................................ 72
2.9.5 Service Desk .................................................................................................................. 73
2.10 MIS & Business Intelligence Services .................................................................................... 75
2.10.1 Mail Operations & Logistics Post .................................................................................. 75
2.10.2 Finance & Accounts ....................................................................................................... 79
2.10.3 Human Resources ......................................................................................................... 85
2.10.4 Call Centre ..................................................................................................................... 90
3. Scope of Work ............................................................................................................................... 93
3.1 Overview of Scope of Work .................................................................................................. 93
3.2 Detailed Scope of Work ........................................................................................................ 93
3.2.1 Supply of Software ........................................................................................................ 93
3.2.2 Supply of necessary central hardware .......................................................................... 93
3.2.3 Design and Build Services.............................................................................................. 93
3.2.4 Implementation Services .............................................................................................. 94
3.2.5 Solution Integration ...................................................................................................... 97
3.2.6 Data Migration Services ................................................................................................ 97
3.2.7 Training ....................................................................................................................... 101
3.2.8 Operations & Maintenance Services........................................................................... 106
4. Technical Requirements .............................................................................................................. 107
4.1 Solution Requirements ....................................................................................................... 107
4.2 Hardware Requirements ..................................................................................................... 122
4.3 Security Requirement ......................................................................................................... 131
5. Operations & Maintenance Requirements ................................................................................. 149
5.1 Service Desk Operations ..................................................................................................... 149
5.2 ITIL ....................................................................................................................................... 149
5.3 Warranty ............................................................................................................................. 150
5.4 Service Level Requirements (SLRs) ..................................................................................... 151
5.4.1 Definitions ................................................................................................................... 151
5.4.2 Service Level Requirement and Targets ...................................................................... 152
5.4.3 Deployment Service Level ........................................................................................... 153
5.4.4 Availability Service Level ............................................................................................. 157
5.4.5 Performance Service Levels ........................................................................................ 159
6. Standards Adherence .................................................................................................................. 169
7. Acceptance Testing, Audit and Certifications ............................................................................. 170
7.1 Deliverable Acceptance ...................................................................................................... 170
7.2 Acceptance Testing ............................................................................................................. 170
7.2.1 Conducting the User Acceptance Test ........................................................................ 171
7.2.2 Inspection of Records .................................................................................................. 172
7.2.3 Acceptance Certificate ................................................................................................ 172
7.2.4 Go-Live and Stabilization Acceptance ......................................................................... 173
7.3 Monitoring & Audit ............................................................................................................. 173
7.4 Certification ......................................................................................................................... 173
8. Annexure ..................................................................................................................................... 174
8.1 Acronyms Used ................................................................................................................... 174
8.2 Volumetric Information ...................................................................................................... 177
8.2.1 DoP transaction volumes for various products and services (numbers in Lakh) ........ 177
8.2.2 Logistics Post Business growth volumes (numbers in Lakh) ....................................... 178
8.2.3 User Estimate .............................................................................................................. 178
8.2.4 Call Centre: No. of call estimates ................................................................................ 180
8.2.5 Phase-wise number of Locations for the Roll-out ...................................................... 181
8.3 To Be Process Flow .............................................................................................................. 183
8.4 Functional Requirement Specifications .............................................................................. 184
8.4.1 Mail Operations .......................................................................................................... 184
8.4.2 Logistics Post ............................................................................................................... 237
8.4.3 Philately ....................................................................................................................... 245
8.4.4 Finance & Accounts ..................................................................................................... 249
8.4.5 Human Resources ....................................................................................................... 287
8.4.6 Customer Interaction Management ........................................................................... 318
8.4.7 Call Centre ................................................................................................................... 330
8.4.8 Common Infrastructure Solution ................................................................................ 334
8.5 RFP Timelines ...................................................................................................................... 354

Table of Tables
TABLE 1: PROCUREMENT AREAS .................................................................................................................. 17
TABLE 2: CHANGE MANAGEMENT SI RESPONSIBILITY MATRIX ....................................................................... 31
TABLE 3: CALL CENTRE REQUIREMENTS - BANKING ......................................................................................... 64
TABLE 4: CALL CENTRE REQUIREMENTS - INSURANCE ...................................................................................... 66
TABLE 5: CALL CENTRE REQUIREMENTS MAIL OPERATIONS ........................................................................... 68
TABLE 6: MIS REQUIREMENTS MAIL OPERATIONS & LOGISTICS POST ............................................................. 75
TABLE 7: MIS REQUIREMENTS FINANCE & ACCOUNTS .................................................................................. 79
TABLE 8: MIS REQUIREMENTS HUMAN RESOURCES ..................................................................................... 85
TABLE 9: MIS REQUIREMENTS CALL CENTRE ............................................................................................... 90
TABLE 10: PROJECT MILESTONES & TIMELINE ................................................................................................ 94
TABLE 11: DATA DIGITIZATION REQUIREMENTS .............................................................................................. 99
TABLE 12: TRAINING REQUIREMENTS FOR HUMAN RESOURCES ....................................................................... 104
TABLE 13: TRAINING REQUIREMENTS FOR HUMAN RESOURCES SELF SERVICE PORTAL USERS .............................. 104
TABLE 14: TRAINING REQUIREMENTS FOR FINANCE & ACCOUNTS ................................................................... 105
TABLE 15: TRAINING REQUIREMENTS FOR MAIL OPERATIONS ......................................................................... 105
TABLE 16: TRAINING REQUIREMENTS FOR LOGISTICS POST ............................................................................. 106
TABLE 17: TRAINING REQUIREMENTS FOR RURAL ICT CLIENT APPLICATION ....................................................... 106
TABLE 18: SOLUTION REQUIREMENTS ......................................................................................................... 107
TABLE 19: HARDWARE REQUIREMENTS ....................................................................................................... 122
TABLE 20: SECURITY REQUIREMENTS .......................................................................................................... 132
TABLE 21: OFFICE-WISE BUSINESS HOURS ................................................................................................... 151
TABLE 22: DEPLOYMENT SERVICE LEVELS .................................................................................................... 153
TABLE 23: AVAILABILITY SERVICE LEVELS ..................................................................................................... 157
TABLE 24: PERFORMANCE SERVICE LEVELS .................................................................................................. 159
TABLE 25: SERVICE DESK SLRS FOR CSI SOLUTIONS ...................................................................................... 163
TABLE 26: SERVICE DESK SLRS FOR L1 SUPPORT .......................................................................................... 164
TABLE 27: CALL CENTRE SLRS ................................................................................................................... 164
TABLE 28: REFERENCE LIST OF STANDARDS .................................................................................................. 169
TABLE 29: DEFECT PRIORITY AND RESOLUTION ............................................................................................. 171
TABLE 30: VOLUMETRIC DATA MAIL PRODUCTS & SERVICES ....................................................................... 177
TABLE 31: VOLUMETRIC DATA LOGISTICS POST GROWTH ............................................................................ 178
TABLE 32: VOLUMETRIC DATA USER ESTIMATES MAIL OPERATIONS ............................................................. 178
TABLE 33: VOLUMETRIC DATA USER ESTIMATES LOGISTICS POST ................................................................. 179
TABLE 34: VOLUMETRIC DATA USER ESTIMATES FINANCE & ACCOUNTS........................................................ 180
TABLE 35: VOLUMETRIC DATA USER ESTIMATES HUMAN RESOURCES ........................................................... 180
TABLE 36: VOLUMETRIC DATA CALL CENTRE ESTIMATES ............................................................................. 180
TABLE 37: NUMBER OF LOCATIONS FOR PHASE-WISE ROLL-OUT ..................................................................... 181

Table of Figures
FIGURE 1: ORGANISATION STRUCTURE AT DIRECTORATE .................................................................................... 8
FIGURE 2: OPERATING STRUCTURE AT FIELD LEVEL ............................................................................................ 9
FIGURE 3: VISION OF INDIA POST 2012 ........................................................................................................ 14
FIGURE 4: INDIA POST 2012 DEFINITION ...................................................................................................... 14
FIGURE 5: SOLUTION BLUEPRINT .................................................................................................................. 16
FIGURE 6: SCOPE OF THE CORE SI ................................................................................................................ 34
FIGURE 7: IMPLEMENTATION PLAN FOR MAIL OPERATIONS .............................................................................. 42
FIGURE 8: IMPLEMENTATION PLAN FOR LOGISTICS POST .................................................................................. 45
FIGURE 9: IMPLEMENTATION PLAN FOR LOGISTICS POST .................................................................................. 48
FIGURE 10: IMPLEMENTATION PLAN FOR FINANCE & ACCOUNTS ...................................................................... 53
FIGURE 11: IMPLEMENTATION PLAN FOR HUMAN RESOURCES ......................................................................... 58
FIGURE 12: IMPLEMENTATION PLAN FOR CUSTOMER INTERACTION MANAGEMENT ............................................. 62
FIGURE 13: IMPLEMENTATION PLAN FOR CALL CENTRE ................................................................................... 70
FIGURE 14: IMPLEMENTATION PLAN FOR COMMON INFRASTRUCTURE SOLUTION ................................................ 74
FIGURE 15: IMPLEMENTATION PLAN FOR MIS ............................................................................................... 92
FIGURE 16: TIMELINES OF VARIOUS RFPS .................................................................................................... 354

1. Introduction
1.1 About Department of Posts
1.1.1 Overview
For more than 150 years, the Department of Posts (DoP) has been the backbone of the countrys
communication and has played a crucial role in the countrys socio-economic development. It
touches the lives of Indian citizens in many ways: delivering mails, accepting deposits under Small
Savings Schemes, providing life insurance cover under Postal Life Insurance (PLI) and Rural Postal Life
Insurance (RPLI) and providing retail services like bill collection, sale of forms, etc. The DoP also acts
as an agent for Government of India in discharging other services for citizens such as Mahatma
Gandhi National Rural Employment Guarantee Scheme (MGNREGS) wage disbursement and old age
pension payments. With 1,55,015 Post Offices, the DoP has the most widely distributed postal
network in the world.
Trends such as urbanisation, increased demand for financial services, increased funding by the
government for the weaker sections and the rural sector, have opened up new opportunities for the
DoP which, in turn has necessitated development of new processes and supporting technology. The
DoP is also faced with twin challenges of increasing competition and continuing advances in
communication technology, especially in mobile telephony and the Internet. In order to provide the
best-in-class customer service, deliver new services and improve operational efficiencies, the DoP
has undertaken an end to end IT modernisation project to equip itself with requisite modern tools
and technologies. The IT modernisation project, India Post 2012, intends to achieve the following:
I. Wider reach to the Indian populace through more customer interaction channels
II. Better customer service
III. Growth through new lines of business
IV. IT enablement of business processes and support functions
As a part of India Post 2012, the DoP has carried out business process reengineering across various
functional areas and has created To-Be processes that will enable it to achieve these objectives. In
order to implement these processes in a sustainable manner, they need to be IT enabled in an
integrated manner that improves operational efficiencies.
1.1.2 Organisation Structure
The DoP comes under the Ministry of Communications and Information Technology. The Postal
Services Board is the apex management body of the Department. The Board is headed by Secretary
(Posts) and it comprises of six Members responsible for various operational areas. Members hold
portfolios of Operations, Planning, Human Resource Development, Personnel, Technology and Postal
Life Insurance. Deputy Directors General, Directors and Assistant Directors General provide the
necessary functional support for the Board at the Directorate. The Joint Secretary and Financial
Advisor (JS&FA) is a permanent invitee to the Board.
The organisation structure at the Directorate is shown below:
Figure 1: Organisation Structure at Directorate
For providing postal services, the operations of the Department are divided into 22 Circles, which
largely are coterminous with the state boundaries (Maharashtra circle includes Goa, Gujarat circle
includes Daman & Diu, West Bengal circle includes Sikkim and Andaman-Nicobar, Tamil Nadu circle
includes Puducherry, Kerala circle include Lakshadweep and North eastern states are covered under
one circle). The operating structure at the field level is shown below:
Figure 2: Operating Structure at Field level

For more information and further details, Bidders may visit www.indiapost.gov.in.

I. Circle Office: The nation has been divided into 22 circles. A Circle Office is an administrative
office headed by the Chief Post Master General who is overall in charge of the operations in the
circle. The Circle Office is also responsible for administrative and HR related activities which
includes recruitment, leave, transfer, training, promotion, Service Book maintenance,
legal/vigilance and performance management among others.
II. Postal Accounts Office: Each circle has a Postal Accounts Office. This office maintains and
compiles the accounts of all the Post Offices and other units. Apart from that, this office is also
responsible for the following:
a. Budgeting
b. Post check/ pairing of Money orders and Cash Certificates
c. Reconciliation of Post Office and Bank transactions
d. Internal Audit
e. Establishment related activities (Processing payroll, GPF Account Maintenance,
Authorisation of Pension)
f. Inter-departmental adjustments with Railways/ other government departments
g. Accounting for pension disbursement for Railways, Telecom, EPF, CMPF

III. Regional Office: Circles are further broken down into 37 Regions. Each Region is headed by a
Postmaster General. Regional Office is an administrative office which is responsible for
administrative and HR related activities which includes recruitment, leave, transfer, training,
promotion, Service Book maintenance, legal/vigilance and performance management.
IV. Division Office: Regions are further divided into Divisions. A Division is headed by a Senior
Superintendent /Superintendent. The Division could either be performing postal functions or be
responsible for running the Railway Mail Service (RMS). The Postal Division manages all Post
offices and last mile delivery, while an RMS Division manages the transmission of mails. There
are total 512 Division Offices. The Divisional head is also an administrative officer responsible for
administrative and HR related activities which includes recruitment, leave, transfer, training,
promotion, legal/vigilance and performance management of their staff within the Division.
V. Sub Division Office: Divisions are further broken down into 1,916 Sub-Divisions. A sub-division is
headed by Assistant Superintendent of Post offices / Inspector Post offices or Assistant
Superintendent Railway Mail Service /Inspector Railway Mail Service. Sub Division Office is an
administrative office which is responsible for administrative and HR related activities which
includes recruitment, leave, transfer, training, promotion, legal/vigilance and performance
management within the sub-division.
VI. Head Post Office: Head Post Office (HO) is an operational unit. HO is authorized for the posting,
receipt, sorting, handling, transmission or delivery of mail. HO offers mail-related services such
as Post Office boxes, postage and parcel. It also offers non-postal services like Banking,
Insurance, Philately, money remittances and retail such as passport applications and sale of
government forms. It consolidates accounts of all SOs under its jurisdiction and reports to the
Postal Accounts Office. It also draws salary and other bills for officials in its jurisdiction and
maintains the service book. HO is classified based upon the number of officials. An HO can be a
General Post office (e.g., Kolkata), Head Post office and Mukhya Dak Ghar. There are total 809
HOs in India.
VII. Sub Post Office: Sub Post Office (SO) is an operational unit located in urban as well as rural areas
which reports to Head Post office. SO provides mail booking services, banking services and
insurance services. It incorporates the account of BOs placed under it and also supplies and
receives funds. There are 24,722 SOs which are classified based on the number of staff. They are
HSG SO, LSG SO, Triple Handed SO, Double Handed SO and Single Handed SO. Some SOs are non-
delivery offices. 5 SOs are Gramin Dak Sewak (GDS) Post Offices which operate for 5 hours every
day.
VIII. Branch Post Office: Branch Post Office (BO) is mostly located in rural areas. All the 1,29,470 BOs
are GDS Post Offices and they operate for minimum of 3 hours and maximum of 5 hours daily.
BOs offer basic services such as mail booking, banking and insurance. In addition to this, BOs are
also responsible for the disbursement of wages under the MGNREGS
IX. Sorting Office: Sorting Offices operate within RMS Divisions. As the name suggests, mail
processing takes place at these sorting offices. Bags are opened and closed and mail is sorted as
per destination at Sorting Offices.
X. Speed Post Centre: Speed Post Centres (SPC) are sorting centres for Speed Post mail. Speed Post
articles booked at various Post Offices are sent to the nearest SPC for sorting and bagged for
their destination. There are 315 national SPCs being serviced by 991 smaller state SPCs.
XI. Record Office: Head Record Offices (HRO) and Sub Record Offices (SRO) report to RMS Division
Offices. Record Offices manage requirement of staff at Sorting Offices. HRO processes salaries
and SRO disburses the salary. Record Offices also maintain records of mail movement. All mail
lists, manifests, etc go to the Record Offices. In case of any enquiry or customer complaint,
Record Offices track the article.
XII. Circle Stamp Depot: 18 Circle Stamp Depots (CSD) across the nation maintain stocks of the
following items which are supplied to Post Offices as and when required:
a. Postage Stamp
b. Service Stamp
c. Postal Stationary
d. CRF Stamp
e. Cash Certificate
XIII. Postal Store Depot: 46 Postal Store Depots (PSD) across the nation stock the following items and
supply to Post Offices as and when required:
a. Books
b. Forms of different kind
c. Articles such as sealing wax, shoes, clothes, footwear, uniform, letter box, computer paper,
carbon paper, cotton twine, locks and keys, chains, umbrellas, RMS trolley, etc.
XIV. Postal Training Centres: Postal Training Centres (PTC) have been established to conduct training
for DoPs workforce. There are 6 PTCs located at Darbhanga, Guwahati, Madurai, Mysore,
Saharanpur and Vadodara. The Centre of Excellence for Postal Technology (CEPT) is located at
the PTC, Mysore campus.
XV. Postal Staff College: Postal Staff College India, is located at Ghaziabad, which imparts induction
as well as in-service training to the Officers of the Indian Postal Service Group A and Postal
Service Group B.
1.2 Business Priorities of Department of Posts
I. Mail Operations: Every year the DoP delivers more than 600 crore articles through its elaborate
network of Post Offices. On the delivery side, the DoP has a large workforce of urban Postmen
and GDS delivery agents to facilitate the delivery of mail to the final recipients. Mail Business is
optimising its products, services and back-end processes to ensure growth in business. Some of
the objectives are:
a. To increase visibility into mail operations (at the article level and overall volume)
b. To enable operational planning for all the DoP facilities through planning tools
c. To improve employee productivity through better manpower planning
II. Logistics Post: Logistics Post provides transportation, distribution, warehousing and logistics
related value added services to the customers. Logistics Post Air, under which air lift is given to
consignments, operates in Delhi, Mumbai, Chennai, Bangalore and North East. Some of the
objectives are:
a. To provide end-to-end supply chain services through a technology-driven logistics network
that provides transportation, warehousing, distribution and e-Logistics
b. To create warehousing capacity by utilising the DoPs vacant sites
c. To offer e-logistics services to tap into the rapidly growing e-commerce market in India

III. e-Commerce: The DoP plans to launch its e-commerce website to harness the power and reach
of the world wide web. Some of the objectives are:
a. To share information related to the DoP, its products and services in a consistent manner
b. To provide capability to do web-based transactions for mails, banking and insurance services
c. Online sale of third party products/services
d. To provide advertising avenues for advertisers

IV. Postal Banking Operations: The DoP is one of the largest providers of financial services in the
country with an account base of around 22 crores and a deposit base of over ` 5,53,234 crores.
The DoPs vision is to be one of the leaders in providing banking and money remittance services
to the citizens of the country with a focus on the rural population. Some of the objectives are:
a. To increase the number of customers from existing 20 crores to 35 crores by 2012
b. To provide multiple delivery channels like internet, mobile banking, ATMs, telephone, cards
thereby bringing access to financial services to the doorsteps of the customers
c. To enable faster money remittances and funds transfers and increase volumes to capture a
50% market share by 2014
d. To become the one stop solution for financial inclusion & microfinance initiatives of
government, public/private sector banks

V. Postal Life Insurance: The DoP provides two types of life insurance: Postal Life Insurance (PLI)
and Rural Postal Life Insurance (RPLI). PLI is offered to employees of all Central and State
government departments, Nationalised Banks, Public Sector Undertakings, Financial Institutions,
local bodies like Municipalities and Zila Parishads, educational institutions aided by the
Government etc. RPLI is the insurance service being offered to the rural populace. Some of the
objectives are:
a. To become the first choice insurer in rural India
b. To develop a fully integrated life insurance platform to enable efficient and cost effective
service to existing and new customers
c. To improve the quality of service being offered to the customers
d. To achieve financial inclusion of the un-insured rural population, while minimizing the cost
of operations

VI. Rural Business: One of the key components of the DoPs vision is to be a socially committed
organisation connecting individuals and businesses. Of the total 1.55 lakh Post Offices, around
10% are situated in urban areas and 90% are in rural areas. On an average, each Post Office in
India serves an area of 21.2 sq. km and a population of 7,174. Some of the objectives are:
a. To achieve financial inclusion of un-banked rural population
b. To enable Branch Offices to make disbursements for social security schemes such as
MGNREGS
c. To improve the quality of services being offered to rural customers
d. To increase revenues by providing retail post services, third party services etc.

VII. Finance & Accounts: The Postal Accounts & Finance (PAF) function forms the backbone of the
DoPs products and services. As the DoP plans for the future, it would be important to tread the
path of sustained cost management and devising effective tools for intelligent business
decisions. Some of the objectives are:
a. To move from cash based accounting to accrual based accounting in specific areas of
operations within the DoP
b. To streamline the processes by eliminating duplication of data entry at different levels
c. To bring efficiencies in Inventory management and Procurement with real time validations
against approved budgets

VIII. Human Resources: Human Resources function comprises of the Personnel (and Establishment)
and Human Resource Development (HRD) groups which serve 2.18 Lakh departmental
employees and 2.74 lakh GDS employees. In order to support the growth aspirations of the DoP,
HR function is looking at redesigning its processes. Some of the objectives are:
a. To provide the administrative offices with centralised and accurate employee information
b. Employee development through improvement in training administration and management
c. To support optimal utilisation of manpower through accurate and timely analysis of
workload
1.3 India Post 2012 Project Introduction
1.3.1 Vision of India Post 2012
India Post 2012 aims at transforming the DoP into a Technology Enabled, Self Reliant Market
Leader. This translates into 5 initiatives covering increased market share and revenues, new
products and services, improved service delivery, motivated workforce and rural development.

Figure 3: Vision of India Post 2012

1.3.2 Definition of India Post 2012
The primary focus of this program is to improve and automate postal services through re-engineering
and creation of efficient operations and systems.
Figure 4: India Post 2012 Definition

The higher service levels will be achieved through significant improvement in operations and
systems. For example, currently 12,604 Head Post Offices (HOs) and Sub Offices (SOs) are
computerised. The rest of the SOs and all BOs are not computerized. India Post 2012 plans to
computerise and connect all Post Offices and run various applications seamlessly across the
network. Currently, majority of the processes are manual. India Post 2012 plans to automate these
processes around standard operating procedures and leading industry practices.
Offer New Products and Services
Empower rural Post offices through technology
Increase Market Share and Revenues
Deliver Improved & Consistent Customer Service
Drive high Employee satisfaction
To Be A
Technology
Enabled,
Self Reliant
Market
Leader
Currently there are 56 stand-alone applications. India Post 2012 intends to build a core set of
integrated applications covering key functions such as Mail Operations, Financial Services, Postal
Insurance, Finance and HR. India Post 2012 also intends to transform the front and back end of the
DoP operations. This re-engineering and improvement of operations and systems is expected to
significantly improve service levels and transparency.
1.3.3 Proposed Solution Blueprint
Proposed Solution Blueprint as described in the following section provides a holistic view of the
overall solution and captures the end-state vision. It defines the basic elements of the solution,
such as different layers and components that enable the solution areas that will drive the India Post
2012 IT modernisation program.
The blueprint has been developed on a comprehensive understanding of the functional and other
requirements of the DoP, based on which the key capabilities expected by the business have been
identified. It provides an overview of how the business capabilities will be enabled and supported by
detailing out the specific set of applications in the various layers of the solution.
The blueprint is built on the principles of flexibility, extensibility, scalability, availability, high
performance and services oriented architecture. It strives to follow existing industry standards and
where standards do not exist, best practices have been used to derive the overall solution blueprint.
It provides as much flexibility as possible to seamlessly incorporate future standards and to build and
integrate new capabilities.
The end-state solution is a critical building block for realisation of the vision for the DoP. This
solution addresses core aspects of the DoP capabilities Mail Operations, Banking, Postal Life
Insurance and Enterprise wide capabilities. This solution enables the following:
Business Enablement layer: enables creation of new products and services in an expedited
fashion, leveraging business process orchestration and business rules engine. This layer
represents various business capabilities enabled from a customers perspective.
Interaction layer: provides customer interaction with the DoP in a consistent manner through
multiple access channels: Web, Call Centre, Retail (Post Office, Point-of-sale), Mobile and
Enterprise Desktop. Each channel will require its own presentation capabilities to the customer.
This layer enables the customer to obtain consistent information, irrespective of the channels
through which the customer interacts with the DoP, such as account information, transaction
details and service offerings. It also enables business partners, premier customers and
Government agencies to transact business with the DoP.
Workflow and Business Process Management Services layer: provides end to end automation
and orchestration of the business processes.
Application Integration Services layer: shows how applications are integrated across the main
application groups as well as within each area. This should provide more seamless information
flow across a business process and between functional units. This will be enabled using an
Enterprise Service Bus which will be based on industry standards such as SOA.
Figure 5: Solution Blueprint

Applications layer: comprises of services-based architecture that will enable Banking, Insurance,
e-commerce and Mail operations capabilities. These services will be designed in a channel-
agnostic fashion. Exposing the DoP capabilities as registry-based web services, will allow these
services to be consumed across delivery channels (i.e., web, mobile, Call Centre, point-of-sale
and IVR), increasing both, cost savings and speed of systems delivery. Fully integrated service-
based architecture will support the solutions adaptability, enabling future capabilities to be
added to the overall system in a principled manner. Once developed, new services can quickly
be leveraged to create composite services and enhanced business processes.
Data Management & Integration Service layer: includes the various data sources for Banking,
Insurance, e-commerce, Mail Operations, Customer Registration and others. This integrated data
layer will provide operational data into the metrics and analytical tools upstream. The data also
enables the MIS/Data Warehousing capabilities for the DoP.
Infrastructure layer: adopts Service Oriented Infrastructure (SOI) approach instead of traditional
technology based approach. SOI is a paradigm for provisioning and automation of virtualised and
integrated infrastructure components that can be described as a service, and provided to any
consuming application requirement. The aim is to create a shared pool of virtualised resources
including servers, storage, network switch, load balancer etc. which can be allocated or de-
allocated to a service independent of the underlying infrastructure.
Security layer: enables an enterprise security framework that will provide a consolidated view of
policies, standards and procedures that are aimed at securing the information assets such as
application, infrastructure, etc.
IT Operations layer: is a description of the processes, organisation, and technology that supports
the IT Operations environment. The operations architecture can be considered a combination of
two disciplines: the operations management of processes, standards and controls and the
technical architecture of those toolsets used to support those processes.
1.4 India Post 2012 Vendor Selection Process
As part of the India Post 2012 Project, the DoP intends to procure products and services to develop:
1. Comprehensive solutions covering Mail, Retail and e-commerce Operations, Logistics and
Warehousing, Postal Banking, Postal Life Insurance, Finance & Accounts, Human Resources
Management and Customer Interaction Channels. DoP also envisages ICT solution to
computerise its rural Post Offices and provide integrated and affordable electronic services at
the Branch Post Office level.
2. IT infrastructure including Data Centre (s), secured connectivity across the entire postal network,
and computer hardware for Post Offices & Railway Mail Offices.
3. Training and change management to ensure readiness of DoP to adopt the solution.
The entire scope has been structured into the following eight areas:
Table 1: Procurement Areas
RFP No. Area
RFP#1 Rural ICT System Integrator (RSI)
RFP#2 Rural ICT Hardware (RH)
RFP#3 Core System Integrator (CSI)
RFP No. Area
RFP#4 Financial Services System Integrator (FSI)
RFP#5 Data Centre Facility (DCF)
RFP#6 Network Integrator (NI)
RFP#7 Mail Operations Hardware (MOH)
RFP#8 Change Management Vendor (CM)
1.4.1 RFP Scope
The indicative scope of various RFPs is defined below, which may undergo changes in the individual
RFPs:
1. Rural ICT System Integrator (RSI): The vendor will be responsible for development of core
application platform; development of MGNREGS application and expansion of already existing
electronic Money Order (eMO) application for RICT Hardware Devices; development of a central
MGNREGS database; Integration with overall India Post 2012 solution architecture and other
core applications such as Mail Operations, Core Banking Solution, Postal Life Insurance; and
solution deployment of the complete Rural ICT solution to approximately 1.30 lakh GDS POs.
2. Rural ICT Hardware (RH): The vendor will be responsible for supply and installation of the
Rural ICT Hardware devices and peripherals to Division Offices for further distribution by DoP to
approximately 1.30 lakh GDS Post Offices; arranging for network connectivity from the local
service provider in the form of 3G, GPRS, GSM, CDMA, EVDO, wired broadband etc.; ensuring
the connectivity during the contract period; and providing support and maintenance for the
Rural ICT Hardware Devices during the contract period.
3. Core System Integrator (CSI): The vendor will be responsible for developing and supporting Mail,
F&A, HR, CIM solutions for all channels (including Rural ICT platform); data migration from the
existing systems; procurement and setup of server hardware; cross-functional area coordination
(Website, Call Centre, eCommerce, application service desk etc.); Systems training material
creation and training execution; and overall integration & SLA management. The vendors
responsibilities include setting up and running a Call Centre for DoP, covering all aspects of DoPs
business, including Mail Business, Banking and Insurance. Additionally, the vendor will also be
responsible for setting up and running a centralized 24x7 Service desk operation. The vendor will
be responsible for all applications except those covered under FSI and RSI.
4. Financial Services System Integrator (FSI): The vendor will be responsible for creation,
installation, maintenance and support of Postal Banking Solution, Insurance, and Enterprise
content management system solutions; ATM Switch (application & hardware); alternate delivery
channels (ATM, web, mobile, Point of sale etc.); migration of banking and insurance data from
legacy system database; maintenance and operations of legacy application like Sanchay post
for banking and PLI Software for PLI till its final amalgamation into new system; Systems
training material creation and training execution during the tenure of the contract. The vendor
will also be responsible for relocation of current PLI (Insurance) server hardware to new Data
Centre (DC) location and ensuring the solution integration with overall solution architecture
under the purview of Core System Integrator.
5. Data Centre Facility (DCF): The vendor will provide Data Centre hosting of Primary Data Centre
in its facility including all facility management services. This will be a Co-location Data Centre at
the vendor facility. The vendor has to provide space, power cooling and other related facilities
for the DoP computing infrastructure at a Tier III Data Centre facility. The facility has to be
scalable, secured and having flexible architecture to meet the DoPs current and future
requirements and should be provided with 24x7 onsite support. In the secondary Data Centre,
the vendor role will build, operate and transfer Disaster Recovery Centre to meet the DoP
requirements. This will be a Captive Data Centre with outsourced operations (BOT Model) at the
DoP facility. As part of this, the vendor will be responsible for assessment, design and
architecture of Tier III Data Centre facility in terms of the civil, electrical & mechanical work,
sourcing, installation & commissioning of the necessary basic Infrastructure like air conditioning,
electrical & network cabling etc., Five years on-site maintenance, 24x7 onsite support as per
SLAs and smooth transitioning by the end of the contract period.
6. Network Integrator (NI): The vendor role will involve networking of all of the DoPs departmental
offices across India. The scope includes project management of NI project; design of the entire
DoP network including the network requirements at Data Centres/Disaster Recovery Centre
(including internet connectivity); network management & operations; procurement and
deployment of networking components for WAN and DC/DR LAN; and smooth transition of
existing network to the new network. The vendor shall also manage and maintain the complete
network infrastructure as deployed till the completion of the project. The vendor shall also set
up the Network Operations Centre (NOC) to provide complete visibility.
7. Mail Operations Hardware (MOH): The vendor will be responsible for procurement of hardware
for Postal and Mail Processing offices such as in-facility desktop computers, printers, scanning
devices/hardware and departmental postmen device hardware. The scope will also cover
maintenance and operations of the hardware during the tenure of the contract.
8. Change Management Vendor (CM): The vendor role will involve stakeholder management -
Aligning stakeholders to the program objectives and understanding their concerns, Change
Readiness Survey- assessment of readiness to accept change, Change Management Workshops
for building change leadership, Communication and Awareness - Engaging and informing
employees about the changes, Training Strategy, Coordination and Scheduling, Capacity
Building.
1.5 Interdependencies between Vendors
The entire scope of India Post 2012 project is organized under 8 RFPs, in a multi-tower model with
vertically integrated towers, in order to expedite the rollout of priority solutions and allow
specialized and full service providers to participate in the procurement process. The vendors
selected would need to work together to ensure smoothness in building and rolling out the
solutions. This section is divided into two parts:
Section 1 Mapping of Solution Blueprint to different vendors
Section 2 Interdependency between different vendors
1.5.1 Mapping of Solution Blueprint to different vendors
The proposed solution blueprint defines the basic elements of the solution such as different layers
and components that will enable the solution areas which will drive the India Post 2012 IT
modernisation program. The proposed solution blueprint has been mapped to highlight the
responsibilities of the vendors selected through the procurement process of the 8 RFPs.

The high-level responsibilities of the different vendors are represented below:
DoP Requirements RSI RH CSI FSI DCF NI MOH CM
Rural ICT application platform
development (SDP)

MGNREGS application
eMO client application
Program Management for deployment of
Rural ICT solution (including hardware)

Mail Operations
Finance & Accounts
Procurement and Inventory
Management

Logistics Operations
Human Resources
Payroll
Customer Interaction Management (CIM)
POS (Point of Sale application)
IVR/Call Centre
Email Solution and Directory Services
SMS Gateway
Enterprise Management System (EMS)
Tools

Business Process Management /
Workflow Platform

Overall Integration using ESB
Analytics & Business Intelligence, Data
warehousing, ETL etc.

Security Solutions (IAM, Anti- Phishing,
Firewall/IPS)

Banking applications
Postal Life Insurance
Enterprise Content Management System
ATM Switch application
RICT Solution & Integration Training
Interface development to enable
integration of Banking, PLI & ECMS
applications with overall solution

Central Server Hardware
Storage (SAN) & Backup solutions
DoP Requirements RSI RH CSI FSI DCF NI MOH CM
Rural ICT hardware devices and
peripherals

Mail Operations Hardware
Supply of client side hardware for
banking and PLI applications at selected
locations

ATM deployment including site
preparation

Data Centre (DC) & Disaster Recovery
Centre (DRC) facilities

Network connectivity for BO locations
(~130000)

Network connectivity of department
offices (~25000 locations)

Network Operations Centre (NOC) setup
and management including network
monitoring tools

Network Management
Training
Stakeholder Management
Change Readiness Survey
Change Management Workshops
Communication & Awareness, Training
Strategy, Capacity Building

Data Migration
Operations & Maintenance
Help Desk
1.5.2 Detailed Interdependencies between vendors
This section detailing the Interdependency between Vendors clearly sets out the interface across the
scopes of work required to be executed by the successful bidders under each of the RFPs for the
successful implementation of the India Post 2012 Project. This section forms an integral part of the
respective scope of work set out in each of the RFPs to be issued by the DoP as a part of the India
Post 2012 Project. The details relating to the scope of work, deliverables and other services
proposed to be procured by the DoP under this RFP are in addition to the interdependency scope set
out below. The details provided herein are binding on the bidders and in case of any conflict or
contradiction between the provisions of this section (Interdependency between Vendors) and any
other section of this RFP, the terms and conditions set out in this section (Interdependency between
Vendors) shall supersede any contradicting information/requirement in the rest of the RFP.
1.5.2.1 Rural ICT System Integrator (RSI)
The Interdependency between the RSI and other vendors is illustrated below:
DoP Requirements RH CSI FSI DCF NI MOH CM
Rural ICT client application deployment
Development & deployment of client
applications for solutions provided by FSI/CSI

SDP Integration with ESB
Data Centre Facilities
SAN Storage
Network for RICT devices at field level
Network for RICT at DC/DR
Data Migration MGNREGS accounts from
Sanchay Post

RICT device training for RSI
User Training Plan
Training on SDP
Change Management
Maintenance of RICT devices
Help Desk

a) Applications
i. RSI will be dependent on DCF vendor for hosting central server applications
ii. RSI will be dependent on RH vendor for RICT solution roll out
b) Storage Solution
i. RSI will be responsible for bringing servers with internal storage for its solutions
ii. RSI will be dependent on CSI for migrating its applications to SAN storage
c) Rural ICT Hardware
i. RSI will be dependent on RH vendor for providing RICT hardware during application rollout
d) Integration
i. RSI will be responsible for providing necessary interfaces, standards and data for integration,
whereas CSI will be responsible for overall integration
ii. Client applications developed by other vendors such as CSI, FSI etc. will be deployed by RSI
on RICT devices using SDP.
e) Financial Transactions
i. RSI will be responsible for MGNREGS account migration from Sanchay Post. FSI will be
dependent on RSI for using the migrated data, if required.
ii. RSI will interface with MGNREGS payment data from State Data Centre (if existing)
iii. RSI will push data on MGNREGS disbursements made by DoP to NREGASoft for MIS
Reporting
iv. RSI will be dependent on DoP for developing client applications based on existing eMO
server application
v. CSI will be responsible for developing the solution for consolidation of accounts data for
Branch Offices
vi. RSI will be dependent on CSI for PoS solution at Rural ICT post offices
f) Training
i. RSI will be trained by RH vendor on devices
ii. RSI will provide application and device training to BPM (Branch Post Master)
iii. RSI will provide training to CSI and FSI on SDP platform
iv. RSI will train CSI on L1 processes of Help desk operations
v. RSI will be interdependent on CM vendor to develop training plans
g) Help Desk
i. CSI will provide overall help desk tools and L1 support for complete infrastructure and
applications, with L2/L3 support provided by RSI. However, RSI will provide intermediate
help desk (L1) support till CSI implements help desk
ii. RSI will continue providing L2/L3 help desk support during tenure of the contract
iii. RSI and RH vendor will be interdependent for helpdesk support pertaining to RICT devices
1.5.2.2 Rural ICT Hardware (RH)
The Interdependency between the RH vendor and other vendors is illustrated below.
DoP Requirements RSI CSI FSI DCF NI MOH CM
Rural ICT client application deployment
Network for RICT devices at field level
RICT device training for RSI
Maintenance of RICT devices
Help Desk

a) Rural ICT Client Application Deployment
i. RSI will be dependent on RH vendor for deployment of the client application on the RICT
devices
b) Rural Network connectivity
i. RSI will be dependent on RH vendor for providing network connectivity for the RICT devices
at the field level
c) Training on use of RICT devices
i. RSI will be dependent on RH vendor for providing training on the use of the RICT devices
d) Help Desk
i. RSI and RH vendor will be interdependent for helpdesk support pertaining to RICT devices
ii. RH vendor will be dependent on CSI for providing L1 Help Desk support when the CSI
provides final help desk tools
e) Maintenance of RICT devices
i. RSI and RH vendor will be interdependent for maintenance of RICT devices
1.5.2.3 Core System Integrator (CSI)
The Interdependency between the CSI and other vendors is illustrated below:
DoP Requirements RSI RH FSI DCF NI
MO
H
CM
Rural ICT client application for solutions
developed by CSI

Point of Sale applications
IVR, Call Centre
SMS Gateway
Analytics & Business Intelligence, Data
warehousing, ETL etc.

Business Process Management/Workflow
Platform

Enterprise Management System (EMS),
excluding Network Management System (NMS)

Integration with ESB for other vendor
applications

Integration of NMS with EMS
Security
SAN Solution
Network for DC, DR and other offices
Network for Branch Offices
Availability of Mail Operations Hardware
User Training Plan
Training for Mail Operations Hardware
Change Management
Help Desk

a) Applications
i. CSI will be dependent on RSI for availability of SDP for deployment of RICT client applications
for its solution
ii. RSI and FSI will be dependent on CSI for availability of integration platform
b) Enterprise Content Management System (ECMS)
i. CSI will be dependent on FSI for integrating its applications with ECMS
c) Enterprise Management System (EMS)
i. FSI and RSI are dependent on CSI for deploying EMS tools
ii. CSI will be dependent on NI for integration with Network Management System (NMS)
iii. CSI will be dependent on DCF vendor for integration with Building Management System
d) SAN Solution
i. RSI will be dependent on CSI for migrating their applications to SAN storage
e) IVR/Call Centre
i. All vendors will be dependent on CSI for IVR/Call Centre services
f) Data warehouse /BI
i. CSI will be dependent on RSI and FSI for designing and building common data warehouse
solutions
ii. CSI will be dependent on RSI and FSI for providing interface with respective solutions for
data warehouse specific integration
g) Mail Operations Hardware
i. CSI will be dependent on MOH vendor for Mail Operations Hardware
h) Rural ICT Hardware
i. CSI will be dependent on RH vendor for providing RICT hardware during application rollout
i) Integration
i. For consolidation of accounts, CSI will be dependent on FSI and RSI for receiving information
pertaining to their transactions
ii. RSI and FSI will be dependent on CSI for providing interfaces to all the applications under its
scope
j) Security
i. RSI and FSI will be dependent on CSI for enterprise wide common security solutions such as
identity and access management
ii. CSI will be dependent on RSI, FSI and NI for centralized security management
iii. CSI will be dependent on NI for providing and monitoring of network security components
k) Help Desk
i. CSI will setup centralized integrated help desk for all internal customer issues and all other
vendors will be dependent on CSI for the same
ii. CSI will be dependent on other vendors for training to handle L1 help desk for their
solutions; however, respective vendors would be responsible for L2 and L3 help desk
support
1.5.2.4 Financial Services SI (FSI)
The Interdependency between the FSI and other vendors is illustrated below:
DoP Requirements RSI RH CSI DCF NI MOH CM
Rural ICT client application for banking &
insurance deployment

Business Process Management /Workflow
Platform

DoP Requirements RSI RH CSI DCF NI MOH CM
Availability and Training of SDP
Integration with SMS Gateway
Integration with India Post portal
Integration of FSI solutions with ESB
Integration with ECMS
Security
Data Migration MGNREGS accounts from
Sanchay Post

Network for Branch Offices
Network for DC, DR and other offices
User Training Plan
Change Management
Help Desk

a) Applications
i. FSI will be dependent on RSI for availability of SDP for deployment of banking and insurance
RICT applications
ii. FSI will be dependent on CSI for availability of User Interface guidelines for web portal
b) Enterprise Content Management System (ECMS)
i. FSI will provide ECMS solution for all applications including CSI and RSI applications. CSI and
RSI will be dependent on FSI for integrating their applications with ECMS
c) Storage & Backup Solution
i. FSI will be responsible for design and implementation of storage and backup solutions for its
applications
d) Integration
i. FSI will be dependent on CSI for defining the interface guidelines for ESB
ii. FSI will be responsible for providing Accounts data to CSI for consolidation
iii. FSI will be dependent on CSI for PoS solution at all post offices.
iv. DoP will be dependent on FSI for providing data as per the requirements for day end
accounts consolidation in their current system
f) Training
i. FSI will be dependent on RSI for SDP training
ii. FSI will train CSI on L1 processes of Help desk operations
iii. FSI will be interdependent on CM vendor to develop training plan
g) Help Desk
applications, with L2/L3 support provided by FSI. However, FSI will provide intermediate
help desk (L1) support till CSI implements help desk
ii. FSI will continue providing L2/L3 help desk support during tenure of the contract.
1.5.2.5 Data Centre Facility (DCF)
The Interdependency between the DCF vendor and other vendors is illustrated below:
DoP Requirements RSI RH CSI FSI NI MOH CM
Space for NOC
Physical Access Control
Enterprise Management System
Training Plan
Change Management
Help Desk

a) Enterprise Management System (EMS)
i. CSI and DCF vendor will be interdependent for integration between Building Management
System and Enterprise Management System
b) Facility Infrastructure
i. NI will be dependent on DCF vendor for Network Operation Centre (NOC) facility and for
hosting of network equipments at both DC/DR facility
ii. RSI, CSI, FSI and NI will be dependent on DCF vendor for physical access control at DC and DR
locations
c) Training
i. DCF vendor will work with CM vendor for developing Training Plan
d) Help Desk
applications, with L2/L3 support provided by DCF vendor. However, DCF vendor will provide
intermediate help desk (L1) support till CSI implements help desk
ii. DCF vendor will continue providing L2/L3 help desk support during tenure of the contract
1.5.2.6 Network Integrator (NI)
The Interdependency between the NI and other vendors is illustrated below:
DoP Requirements RSI RH CSI FSI DCF MOH CM
Space for NOC
DoP Requirements RSI RH CSI FSI DCF MOH CM
Network Connectivity
Bandwidth Sizing
Integration of NMS with EMS
Network Security
Training Plan
Change Management
Help Desk

a) Networking solutions
i. CSI, RSI and FSI will be dependent on NI for deployment of their solution at DC and DR for
network and network security
ii. CSI, RSI and FSI will be dependent on NI for deployment of their solution for network
connectivity
iii. NI will be dependent on RSI, CSI and FSI for bandwidth requirements for respective
applications
iv. NI and CSI will be interdependent for integration of NMS with EMS
b) Training
i. NI will work with CM vendor for developing Training Plan
c) Help Desk
applications, with L2/L3 support provided by NI. However, NI will provide intermediate help
desk (L1) support till CSI implements help desk
ii. NI will continue providing L2/L3 help desk support during tenure of the contract
1.5.2.7 Mail Operations Hardware (MOH)
The Interdependency between the MOH and other vendors is illustrated below:
DoP Requirements RSI RH CSI FSI DCF NI CM
Mail Operations Hardware
Training Plan
Change Management

a) Mail Operations Hardware
i. CSI is dependent on MOH for Mail Operations Hardware
b) Training
i. CSI and MOH are inter-dependent for MOH training
ii. MOH will work with CM vendor for developing Training Plan
c) Help Desk
applications, with L2/L3 support provided by MOH
ii. MOH will continue providing L2/L3 help desk support during tenure of the contract
1.5.2.8 Change Management Vendor (CM)
The Interdependency between the CM and other vendors is illustrated below:
DoP Requirements RSI RH CSI FSI DCF NI
MO
H
Training Plan
Change Management
Table 2: Change Management SI Responsibility Matrix
# Change Management Activity Change Management Consultant Responsibility System Integrator Responsibility
1 Change Management Plan
Develop Change Management plan. CM
vendor shall work with the DoP Program
Management Team, DoP Change Management
team and other vendors.
Provide details of implementation including release
dates, milestones, solution details etc to the CM
vendor
2 Stakeholder Management
Develop Stakeholder Management Plan and
conduct Stakeholder identification, analysis
and reporting
Update the Stakeholders identified by the CM
vendor
3 Change Readiness Survey Sole responsibility of CM vendor
4 Change Network
Create a Change network for India Post 2012
Program
Coordinate with other vendors to collect
relevant material on Solution, timelines etc.
required to keep change leaders in the field
informed about what is happening
Communicate information such as project schedule,
key dates, solution overview, benefits etc. for use in
material for the Change Network to the CM vendor
5 Communication & Awareness
Develop Communication Strategy & Plan
Develop communication content
Work with DoP to implement communication
plan
Provide inputs on timelines, benefits, release dates,
what is in it for role-players etc. to the Change
Management vendor
6
Change Management
Workshop
Sole responsibility of CM vendor
7
Training Strategy Coordination
& Scheduling
Develop integrated training strategy and plan
for training included in the Training Plan by all
System Integrators
Assess training infrastructure capacity
Finalize Training Schedule
System Integrator shall develop the Training Plan for
their respective solutions and communicate the
same to the CM vendor
Develop Training Curriculum
Develop training content and Training Manuals
Evaluate training content and effectiveness of
Training Manuals from a CM point of view and
provide recommendations
Conduct Role Mapping Exercise
Identify Trainers and End Users
Assess DoP Induction requirements
Define approach for Training Effectiveness
Evaluation
Coordinate training delivery across System
Integrators
Assess DoPs current training curriculum and
courses and recommend the required update
as a result of India Post 2012 Program
Report to DoP the details of Training
Completion and feedback received from
System Integrators
Deliver training
Conduct training evaluation
Provide regular inputs on release dates and planned
training dates to the CM vendor
Send training completion reports and feedback
forms to the CM vendor
8 Capacity Building
Develop capacity building approach &
methodology
Develop capacity building Work Plan
Provide recommendations for capacity
building and creation of road map
Identify and document new structures, roles,
job descriptions, Skills, new position details
etc.
Conduct an assessment of Organizational
culture and provide recommendations for the
required cultural changes which will be
beneficial to the DoP in the long run
System Integrator shall provide inputs to the CM
vendor on capacity building requirements such as
new roles, skills, infrastructure, and Organization
structure that is needed to sustain the changes over
the next 5 to 10 years.
The tentative timelines for all the eight RFPs have been given in the Annexure 8.5 (refer Figure 16).
1.6 RFP Structure
This RFP is meant to invite proposals from interested companies capable of delivering the services
described herein. The content of this RFP has been documented as a set of three volumes explained
below:
I. Volume I: Functional, Technical and Operational Requirements
Volume I of this RFP contains details regarding solution and other requirements that the DoP
deems necessary to share with the potential Bidders. The information set out in this volume
includes Functional Overview, Scope of Work, To-Be Process flows, Functional requirements,
Technical Requirements of the solution, desired Service Levels and Roll-out Plan for various
components of the proposed solution.
II. Volume II: Instructions to Bidders
Volume II of this RFP details out all that may be needed by the potential Bidders to understand
the bidding process. This includes the technical and financial forms required to respond to this
RFP as well as to understand the technical evaluation methodology as part of this bidding
process.
III. Volume III: Contractual and Legal Specifications
Volume III of this RFP explains the contractual terms that the DoP wishes to specify at this stage
and includes a draft of Master Services Agreement.
2. Business Functions Covered under the Core SI
The scope of the Core SI will be limited to the areas shown in the Figure 6 below.
Figure 6: Scope of the Core SI

Indicates all the areas of the solution in scope for the Core SI

2.1 Mail Operations
2.1.1 Current State Overview
Transmission and delivery of mails has been the main business of the DoP. As part of its Universal
Service Obligation (USO), the DoP ensures delivery of mail to every corner of the nation. In addition
to these USO products/services, it also offers a range of premium products/services including the
express delivery service.
2.1.1.1 Current Product Offerings
Various products and services being offered under the Mail business are:
1. Letter: refers to communication enclosed in an envelope and addressed. The maximum weight
allowed is 2 kg.
2. Inland Letter Card: refers to communication contained on a sheet of paper with prescribed size
& folding. Inland letter card is used for transmission within India only.
3. Post Card: refers to open communication on a card of prescribed size. This is available in two
varieties: single & reply post card. Post card has stamp of prescribed value impressed on it. Post
cards are meant for transmission within India only. Different types of Post Card are following:
a. Printed Post Card
b. Competition Post Card
c. Meghdoot Post Card
4. Book Packet: may contain paper, cards, parchment etc. not bearing any writing except the name
of the person to whom sent or presented, the name and address of the sender or owner, date
and not more than five words or initials of complimentary nature of signifying presentation.
Stamps are stuck at the top right corner of address. Book Packet is posted without cover or in an
unfastened envelope and the weight limit is 5 kg.
5. Book Packet containing Periodical: are provided special rates only in following conditions:
a. That it is registered with the Registrar of Newspapers in India under the Press and
Registration of Books Act, 1867 (25 of 1867)
b. That the periodical bears in print in any convenient place, either on the first or last page
thereof, the superscription Registered with the Registrar of Newspapers for India under No.
__________________
6. Book Packet containing printed book: are provided special rates only in following conditions:
a. publication is not published at regular intervals
b. shall bear on the outside the inscription Printed books
c. consists of wholly or substantially of reading matter, painting, photography, diagrams or any
other similar matter
d. shall not contain any advertisements other than incidental announcements or list of books
e. each book shall contain the name of the printer or publisher
a. shall not bear any character or inscription reproduced by any means other than printing
7. Registered News Paper: Newspapers/publications may be registered with the DoP and posted
for transmission by inland post. A supplement to the newspaper, bearing the same date as the
newspaper, title printed at the top of each page and transmitted therewith shall be considered
part of the newspaper. The newspaper shall bear in print, in any convenient place either on the
first or last page, the word Registered followed by the registration number that has been
assigned to it by the Supdt./Sr. Supdt. of Post Offices or independent Gazetted Post Master.
8. Blind Literature Packet: Literature for blind in Braille etc. is sent under this category. These are
exempted from payment of following fees besides being exempt from paying the postage:
a. Registration fee
b. Fee for acknowledgement
c. fee for the attested copy of the receipt
Postage free blind literature packets are transmitted by surface route only. If sent by airmail,
airmail charges are charged.
9. Pattern and Sample Packet: It may contain samples of merchandise not having any saleable
value together with or without, any matter which may be sent as a book packet. There must be
no writing upon or in a pattern or sample packet, except the name and address of the sender,
the name and address of the person for whom it is intended, a trade mark, numbers prices and
indications as to the weight, size or quantity to be disposed of. Geological specimen and other
similar objects can also be transmitted via post provided they are not for commercial purpose.
The maximum weight permissible is 2kg. A pattern or sample packet must be posted without a
cover, or with a cover open at both ends, or in an unfastened envelope or other cover which can
be easily removed so as to admit of a ready examination of the contents.
10. Parcel: service delivers anything except certain items prohibited by law. A parcel may contain a
single written communication of the nature of a letter or having the character of a personal
communication, addressed to the addressee of the parcel. Weight of un-registered parcel should
be less than 4 kg and registered parcel should be less than 20 kg (10 kg for parcel booked at a BO
or to be delivered at a BO). Parcel must be presented at the point of sale counter of any Post
Office.
11. Registration: makes the transmission of an article more secure, as it passes through the hands of
postal officers, under special precautions. Post Office is not responsible for the loss of a
registered article, or for any injury which its contents may sustain during the transmission. A
record is kept at all stages the article passes through. At the time of delivery, a proof of delivery
is also obtained in form of a signature from the addressee. Letters, letter cards, book and
pattern packets, blind literature packets and parcels may be registered at any post office for
transmission by post to any other post office.
12. Insurance: In addition to the treatment provided under registered article, Insurance provides risk
cover in case of damage/loss of the article to the extent of insured amount or value of loss
established, whichever is less. The maximum insurance amount is ` 100,000. Maximum limit of
insurance in case of currency notes is only ` 20,000. Special handling is provided to the insured
articles at each stage of processing.
13. Value Payable Letters and Parcels: Value payable option means collection of dues at the time of
delivery of an article from the addressee. Value payable articles can be posted at any Post Office
for delivery through any other Post Office.
14. Speed Post: provides time-bound and express delivery of letters and parcels across the nation
and around the world. Speed Post articles are provided with a unique barcode that can be
tracked through the web. Speed Post deliveries are limited to certain specific Pin codes.
15. Business Post: is a product aimed towards providing value additions to mail service, with the
best possible delivery at lowest possible prices. It provides total mailing solution to businesses,
from mail preparation to mail delivery. Outsourcing the business mail processing needs to DoP
means that the company can redirect precious resources to its core business activities.
16. Bill Mail: service provides for the delivery of communications in the nature of financial
statements, bills, monthly account bills and other items of similar nature posted by a service
provider to customers.
17. National Bill Mail: service is similar to Bill Mail service with the difference that it covers
destinations other than local, which are covered by Bill Mail service.
18. e-IOD: refers to electronic Intimation of Delivery which is a value added service provided by DoP.
This provides electronic information of delivery through e-mail, DoPs website or electronic web-
based access to sender. This service is offered only to the bulk customers.
19. e-Payment: is a comprehensive bill payment service offered by DoP to business customers. It
facilitates collection of bills (telephone bills, electricity bills, university fee, school fee, insurance
premium etc.) through the vast network of Post Offices on behalf of any organization. The
collection is then consolidated electronically and payment is made centrally to the business
partner.
20. Express Parcel: is an express delivery service for parcels weighing upto 35 kgs. This service also
offers free pick-up from customer premises. Each parcel is provided with a unique barcode that
can be used to track the parcel.
21. Media Post: allows for advertisements on postcards, letters, aerogrammes, postal stationary etc.
It also offers media space sponsorships option on letter boxes.
22. Greeting Post: are greeting cards sold by the DoP with pre-paid postage envelopes. The postage
stamps are an exact replica of the greeting card inside the envelope. These greeting cards are
available at all major Post Offices apart from being sold through private distributors of greeting
cards and stationary shops.
23. e-Post: provides the options to the customer whereby one can send messages to any address in
India with a combination of electronic transmission and physical delivery through a network of
more than 1,55,000 Post Offices. Message is sent as a soft copy through internet and at the
destination it is delivered to the addressee in the form of hard copy. This can also be availed by
the corporate customers, by having a business agreement with DoP.
24. Direct Post: is un-addressed printed matter usually carrying a sales message or announcement
designed to elicit a response from a carefully selected consumer or business market. These
comprise of letters, cards, brochures, questionnaires, pamphlets, samples etc. The senders of
Direct Post can specify the numbers and areas, in which the sender wishes the Direct Post
articles to be distributed. However, no commitment is given for delivery of the article to any
particular address or a person.
25. Business Reply: Under this service, a business that wishes to obtain a reply from its client
without putting him to the expenditure of paying the postage charges may attach or enclose
with his communication an addressed reply card, envelope or label of a special design. Such a
card, envelope or label can be posted by the client in the ordinary manner, but without any
stamp. The charge for each article is later collected from the addressee.
26. International Mail, EMS and Parcels: DoP collects mails/articles for delivery abroad. This includes
following products:
a. Letters, Post Cards, printed papers
b. Bulk Bags
c. Literature for the Blind
d. WorldNet Express
e. Flat Rate Box for International Parcels
f. Foreign Money Order
g. Aerogram
27. Retail Post: DoP acts as a one-stop shop to provide a range of services to the customers. Under
this service DoP offers a range of services including the collection of electricity bill, telephone
bills, insurance premium, and collection of taxes and fee for the Government etc. Post office also
sells application forms of UPSC, SSC, AFMC, Universities etc. In addition to this, DoP also
provides other services in association with third parties.
28. e-Value Payable Post: e-VPP is technology driven VPP service available to bulk mailers or those
senders who regularly post a certain number of articles. This service uses e-payment system
instead of VP Money Order, thereby making it much more convenient for the sender. The
addressee is also benefited as no MO commission or any other surcharges for transmission of
funds are required to be paid.
2.1.1.2 As-Is Process Overview
Operationally, Mail business relies upon various modes of transmission i.e. road, railways and air.
Depending upon the kind of product and the distance to be covered, a mix of these modes is utilized
for delivering the service on-time. The DoP has an elaborate network of Mail Motor Service (MMS)
for intra-city mail transfers. For inter-city transfers, Rail Mail Service (RMS) and Air Mail Service are
also used.
The entire supply chain can be represented by the following key activities:
Production & Preparation: The process starts with pre-mailing activities such as printing,
franking, letter folding etc. as part of the DoPs service offering to its corporate customers. In
some cases, the DoP merely applies the address slip and franks the articles, in other cases it also
prints the mail to be sent. These activities are largely manual today, as well as the accounting
being done for the customer is manual.
Acceptance & Induction: Mail is inducted into the supply chain through various interfaces:
Letter Box, PoS counter, Bulk Mail Centre etc. Ordinary mails are inducted mainly through the
letter boxes spread across the country. Accountable mail such as Speed Post or Registered Post
is booked at the Post Office counters. For Accountable mails, the DoP provides the booking
receipt to the customers. Speed Post booked articles have unique barcode that can be used to
track the status of the shipment online. For all other accountable articles, there is currently no
barcode and their tracking can be done manually which can take a long time.
Mail Sorting: Everyday, Post Offices send the collected mails to sorting offices. Currently, there
are different sorting offices for Ordinary mails, Registered Mails, Parcels, and Speed Post. Mails
are sorted at these centres based on the sorting programs defined by the office. After the
sorting is done, the mails are bagged, tagged and sent for transmission to the destination.
Transmission: Mails transmission takes place through various modes. MMS collects the mails
from the Post Office to deliver them at the Mail Sorting Offices. From these offices, after the
mails are sorted, outstation bags are collected and sent to the destination either by rail or air.
Similarly, mails are delivered to the delivery Post Offices by the MMS.
Delivery: Post Office receives the mails for delivery which are then sorted for various beats as
per the sorting plan. Once the beat sorting is done, the postmen collect the bundles and sort
them according to their route. For Accountable articles, Postman carries a delivery slip where he
captures the signature of the recipient.
Currently, most of the processes described above are manual although there are instances of
technology being used like: Accountable article booking, barcode scanning, tracking application for
the Speed Post articles etc. However, these applications are used sporadically and in an inconsistent
manner. Existing IT systems are not designed for efficient data sharing which leads to redundant
activities at various points of the mail-stream. This results in low article visibility as it moves through
the mail stream. Besides the actual movement of articles, creation and retention of records are also
done manually. This necessitates physical movement of records from the RMS offices to HRO and
SRO. Paper based records result in difficulties in extracting information for the purpose of enquiry
resolution or statistics collection.
2.1.1.3 Overview of existing IT Applications
Over the last many years, the DoP has developed many IT applications to cater to specific needs of
various constituents of the supply chain. Of the many applications present, most prominently used
are listed below with high level details on key functionalities and illustrative gaps:
Meghdoot: Meghdoot is the central application having modules related to Point of Sale,
Accounts, Delivery etc.
o Key Functionalities
Books Registered articles, Speed Post and Money Orders
Point of Sale module computerizes all counter operations except Banking
Postman module is used for delivery of accountable articles (Parcels, MO, Registered
Letter) and is used to create the delivery manifest
Despatch module deals with dispatch of accountable mails
Captures the information about the Money Orders paid
o Key Application Gaps
Poor integration between PoS module and Postman module; data needs to be re-
entered
Lot of manual effort needed in preparing the manifest for accountable mails
No real-time 24x7 processing capability
Limited MIS functionalities
Limited compatibility with printers
Lack of integration with Business Intelligence and Admin. systems
No centralised database across locations
No in-built validation checks like verifying applicable Pin codes at the time of booking
Speed Post articles
SpeedNet: This application provides the track & trace capability to the DoP.
Currently being used only for Speed Post service
Allows for capture of various event scans in the system as the article moves from
beginning to the end of the supply chain
Allows for virtual scan of the bags contents
No integration with Meghdoot; leads to redundant data entry at the delivery
No integration with International Postal System (IPS)
No provision for identifying and flagging incorrectly routed articles in the supply chain
No provision for intimating the consignee regarding the expected delivery date
No provision for intimating the consignor regarding the attempted delivery
International Postal System: IPS is a UPU licensed software being used for all inbound and
outbound EMS and accountable articles
Allows for individual item and receptacle scanning
Has provision for UPU label printing
Has defined EDI standard for message exchange
Has functionalities for accounting for international mails
Verification Notes have to be created manually and researched in disparate systems
Full functionality only enabled for Speed Post (EMS)
No interactions with customs department
CRC Software: CRC application is used in the Computerised Registration Centre (CRC) where the
registered mail is processed. The primary use of this application is to generate computerised list
of registered articles.
Used only for registered articles and Money Orders
At the CRC, the Sorting Assistant enters the details of the bag abstracts
Allows entry for individual articles (registration number and PIN code)
System also generates the despatch manifest based on the data entered
No Data flow from Meghdoot to CRC; leads to redundant activity of repeated data entry
No data flow from CRC to Postman module of Meghdoot regarding the volume of mails
being sent
Duplication of data entry during manifests data entry by supervisor and later by the
sorting assistant
No centralized database
Client server based system and not enterprise wide structure
Limited MIS functionalities
Limited data storage capacity
2.1.2 To-Be Process Description
The proposed To-Be processes are aimed to be user-friendly and with built-in checks to ensure
process adherence. The systems that will support these processes shall be closely inter-linked which
would enable quick sharing of information across the network. Better information availability shall
provide better planning & scheduling of key resources and will result in better customer experience.
Some of the highlights of the proposed To-Be processes are:
Production & Preparation
o Bulk Mailer shall be able to schedule online appointment for dropping mail at the Post Office
o Customer shall be able to request for pickup from premises
o Online estimate shall be generated for various products/services
Acceptance & Induction
o Article weight shall be automatically captured at the PoS terminal through integrated
weighing machine
o System shall generate postage based on the service selected, weight, volumetric size and
destination
o All accountable articles shall be provided with unique barcodes
o Article scanning shall be done at the time of bagging; articles shall be nested with the bag
tag
o Electronic Manifest shall be generated at the Post Office and sent to downstream offices
Sorting
o Bags to be scanned at Mail Office upon receipt; thereby receiving all nested articles
o System shall have a QA facility which will define the percentage of bag contents that shall be
scanned individually upon receipt
o Bags shall be provided with intelligent barcodes which will flag an error message if an article
is scanned into wrong bag
o Electronic Manifest shall be generated at the Mail Office and sent to downstream offices
o Electronic Manifest shall also have details of the number and type of the receptacle used
o Optimised planning of manpower depending upon the expected workload through visibility
into the mail volumes
Transmission
o Bags to be scanned when they leave Mail Office; Bags being loaded onto an MMS vehicle to
be scanned and attached with the vehicle GPS/RFID tag
o Ordinary mail bags to be weighed before being despatched from the Mail Office
o At all the TMOs, bags to be weighed and the weight shall be attached to the barcode/RFID
for the bag
o System shall have interface capability with external system such as Airlines and Railways for
tracking the status of bags
o Optimised use of the transport fleet, route planning, load balancing and KPI monitoring
Delivery
o Bags to be scanned at the Post Office when received for delivery
o System shall send electronic alerts to the recipient of an article about the estimated
day/time of delivery
o Accountable articles shall be delivered through Postman handheld devices in some of the
Post Offices; delivery status reflecting near real-time in the system
o Electronic proof of delivery to be captured for all accountable articles
o In case of attempted delivery, electronic alert shall be sent to the sender intimating the
same
o Facilitate electronic money order delivery
o Shall receive request for pickup of booked articles on the Postman beat route and prepares
intimation for the Postman for the pickup
o Shall facilitate accounting of the money payable and receivable for Postmen
The detailed To-Be Process flows are attached in the Annexure 8.3 of Volume I of this RFP.
2.1.3 Functional Requirements
The detailed functional requirements for the envisaged applications for addressing Mail Operations
are attached in Section 8.4.1 of Volume I of this RFP for the following capabilities:
1. Mail Booking / Retail Post Engine (MBE)
2. India Post Visibility System (IPVS)
3. Delivery & Postman Management System (DPMS)
4. Mailer & Logistics Appointment Scheduling System (MLASS)
5. Labour Scheduling System (LSS)
6. Sort Program Library (SPS)
7. Transportation Managements (TMS)

2.1.4 Implementation Plan
Figure 7: Implementation Plan for Mail Operations

2.2 Logistics Post
Logistics Post is a product offering by DoP that manages the entire distribution side of the logistics
infrastructure from collection to distribution, from storage to carriage, from order preparation to
order fulfilment. It moves the shipments by road, rail and air and ensures safe and timely delivery.
Various products/services being offered under the Logistics Post are:
1. Distribution solutions: Logistics Post caters to any demand for moving goods, parcels and
consignments in terms of delivery deadline and quality of service. Additionally, it also offers
monitoring of the delivery progress at all times.
2. FTL and LTS services: Under this service, customers can send their consignments either in full
truck load (FTL) or Less than a Truck Load (LTL), one parcel or multi-parcels, based on their
requirements. Logistics Post uses a special network for carrying and delivering packages and
consignments across the nation.
3. Warehousing services: To make logistics operations cost effective and efficient, Logistics Post
provides warehousing options (storage of goods before dispatch/ delivery) to the customers, on
payment of warehousing charges.
4. Order processing & fulfilment services: Along with warehousing services, Logistics Post also
offers order processing and order management capability that takes a "whole of business"
approach. It provides pick and pack facilities based on specific requirements of the customers
and ships to the destination.
5. Return Logistics: Logistics Post also offers reverse logistics solutions to businesses that require
return services.
6. Logistics Post Air services: DoP runs a Freighter aircraft, touching major towns in the North East
and providing overnight service to its customers. Apart from carrying mails and Speed Post, the
aircraft carries Express Logistics consignments for overnight delivery.
2.2.1.2 As-Is Process Overview
Acceptance & Induction: Currently, customers can either go to a Logistics Post centre (LPC) or
call up the LPC and enquire about or book the services. For a request for a quote about a
particular route, DoP provides the quotes based on the agreed rates with its transporters. If the
customer wants to send the consignment to a destination for which the DoP does not have a
contract with the transporters, it gets the rates from various transporters and selects the best
rate and quotes accordingly.
Warehousing: To provide warehousing services, the DoP is in process of setting up LPCs across
the country. These include large warehouses in the major cities. These centres also act as the
load aggregation centres. Consignments, picked up from the customers premises or dropped at
the centre, are aggregated and sent to the destination. The tariff is charged based on weight,
volume and distance.
Transmission / Transportation: The DoP has fixed the rates for pre-defined routes. For various
routes, DoP has RMS vans or transporters selected through NIT and their capacities are available
to DoP. For the Mail Operations transmission of mails, DoP has its own fleet of vehicles under
MMS, and a large numbers of vehicles are also outsourced. Based on the requirements, the
consignments are sent by road, rail or air. DoP has a fleet of exclusive aircrafts to carry Logistics
Post Air consignments.
Acceptance & Induction
o Online booking of consignment
o Online quote generation for various services
o Online estimation of expected time of pick up and delivery at destination
o Online payment facilities; credit card, debit card, pre-paid account with DoP etc.
o Electronic document transfer from origin to destination for necessary paperwork
o Back end integration with the transportation system to generate requests for pickup
Transmission
o Single view of the total transportation capacity available, both for Mail Operations mail
movement and for Logistics Post movement
o Optimization of vehicle schedules and routes based on the service requests
o Nest the consignment barcode with the vehicle id (GPS/RFID) to have end-to-end view of the
supply chain
o Electronic manifest for each vehicle generated
o Automatic tracking of vehicles for any impending delays and send alerts to the consignee
o System generated electronic alerts for the status of the consignment
o Interface with Air carriers to capture the status of air-bound consignments
Delivery
o Optimization of delivery vehicle schedules and routes based on the work load
o System calculates the demurrage charges
o Multiple modes of payments allowed
o Electronic proof of delivery
Warehousing
o Integrated view of the total capacity available in warehouses across the network
o Customer requests for pick up through multiple channels
o Vehicle scheduling optimization based on the pick up requests
o Periodic report generation of the inventory being held at various centres
o Picking & Packing list generation
The detailed functional requirements for the envisaged applications for Logistics Post are attached in
Section 8.4.2 of Volume I of this RFP for the following capabilities:
1. Warehousing Management
2. Transportation Management
Figure 8: Implementation Plan for Logistics Post

2.3 Philately
Philately division caters to the philately hobbyists by selling commemorative and definitive stamps
through the DoP network. Commemorative stamps are issued to commemorate important events,
prominent personalities in various fields, aspects of nature, beautiful or rare flora and fauna,
environmental issues, agricultural activities, national/international issues, games etc. These stamps
are available only at Philatelic Bureaux and counters or under the Philatelic Deposit Account (PDA)
Scheme. Philatelic Bureaux function in 59 Head Post Offices at Circle Head Offices or in major district
towns. Commemorative stamps are printed in limited quantities.
Definitive stamps are used for day to day postal mailing purposes and are available in various
denominations at all postal counters.
Philatelic material offered by the DoP includes:
1. Mint stamps (unused stamps)
2. First Day Covers (FDCs, which are issued with every commemorative stamp )
3. Brochure (Information sheet accompanying each commemorative stamp )
4. Year-wise Collectors' Packs
5. Miniature/Souvenir sheets which are sometime issued with Commemorative stamps
6. Catalogue of Postage Stamps of India since 1947
Philatelic Deposit Accounting
o Provision for opening of PDA through various channels such as web portal, Call Centre and
Post Office counter
o Provision of multiple payment options such as credit card, debit card, POSB transfers, Bank
transfer etc.
o Online account management such as balance enquiry, recharge, change of address, change
of contact details
o Link to Philately page listing all the stamp releases
o Allow order placement for stamps
o Provision to close PDA through various channels
Stock & Supply of Postage Stamps and Postal Stationery
o Manage the stock & supply of stamps and postal stationery to Post Offices, Philatelic
Bureaux, PDA Holders and CSD
o Provision for electronic alerts for reconciliation of invoice/billing etc. with ISP Nasik and SPP
Hyderabad.
o System generated invoices for inter bureau remittances
o System generated electronic alert to prevent sale of stamps before the date of release
o Online maintenance of stock and supply of philatelic stamps, maintenance of stamp balance
in the system with generation of stamp distribution list to supply to PDA Holders, billers and
Nehru Philately Clubs etc.
o Automatic transfer of unsold philatelic stamps from date of release to general stamp
balances
o Constant update about status of stock and sale
o Daily sale & revenue figures & periodic monitoring at several levels.
The detailed functional requirements for Philately are attached in Section 8.4.3 of Volume I of this
RFP for the following capabilities:
1. Philatelic Deposit Account
2. Stock & Supply of Postage Stamps and Postal Stationery
Figure 9: Implementation Plan for Logistics Post

2.4 Finance & Accounts (F&A)
Currently the DoP, like other government departments, prepares its books of accounts on the Cash
basis of accounting (which means all revenue-income as well as expenditure is recognized at the
time of receipt /discharge of cash). This is a mandatory requirement from the Controller General of
accounts (CGA).
The DoP has identified the need to automate the current manual accounting operations and operate
in an integrated software environment. This will assist in generating more reliable accounts related
MIS for taking managerial and business decisions.
As with all other functions, a detailed As-Is analysis was carried out of the existing accounting
practices. The study has identified the following areas of improvement:
Two types of account reporting to be made available: existing cash-based method and generally
accepted accrual method
To improve the cash, inventory and liability management along with a holistic position for
available cash /bank balances across the department
Provide asset refresh to provide depreciation for fixed assets
Capital budgeting process to be improved through accrual based accounting system
Efficient MIS to aid intelligent financial decision making
Provision of comparable financial statements to enable comparison with other organizations
Implementation of the proposed solution will be the enabler for:
Providing a single view of the financial performance of DoP
Analyzing the performance of individual Head Post offices as profit centres and taking
appropriate business decisions
The current state assessment study of the F&A processes highlights the need for a solution which
helps recognise revenue and costs under detailed Heads of Account at the Point of Sale. It will
enable profit pool analysis, asset accounting, working capital monitoring, stricter audit control as
well as insightful MIS that can be used for informed decision making. Payroll processing, currently
done manually at the HO, shall be centralized at a circle level. Payroll processing software shall help
eliminate redundant manual operations and physical disbursement of salary by cash.
Some highlights of the To-Be processes are:
General Ledger (GL)
o Consolidation of all receipts and expenditures from transactions recorded in different
applications as well as those related to establishment. Governed by common chart of
accounts, Calendars, Accounting Convention and Currency.
o Ability to do multiple reporting
o Accountant at PAO shall have access to the GL function for purpose of extracting daily
transaction reports which can be checked with the physical copies of vouchers at the POs
o The Directorate shall have the access to the GL function for tracking the financial
performance of different Post Offices by Circle
o In order to comply with modern technology applications, the DoP needs to shift to accrual
basis of accounting. However, the reporting of financial performance to the CGA will still
have to be done on cash basis for which relevant reports will be extracted from the system
to comply with the Government of India Accounting policies and Standards
o Shall allow for drill-down from GL to sub-ledgers
Requisition & Procurement
o Generate online indents for operational items like Stamps, Cash Certificates, cheque books,
Journal registers, stationery, etc.
o Generate online indents for procurement of goods/ services through external vendors/
DGS&D
o System shall check the inventory status across the supply chain for the requisitioned items
and generate Purchase Orders for items with insufficient inventory
o System shall check the budget available for the item in the system and accordingly processes
the order
o System shall have the in-built checks defined in the workflow which ensure that proper
authorization is done before any purchase
Accounts Receivables (AR)
o Account Receivable function shall interface with the GL to provide effective working capital
management and capture information.
o System shall maintain detailed sub ledgers for agencies and bulk customers. System shall
also streamline processing of unapplied receipts and tracks their status
o User at the nodal PAO shall interface with the GL function as well as agencies and bulk
customers wherever electronically possible. The user has the option to make manual entries
for receipt generation
Accounts Payable (AP)
o Accounts Payable shall interface with the GL to capture procurement and payment related
information.
o The system shall have detailed sub ledgers governed by vendor type and transaction details.
o It shall have the provision of electronically transmitting the POs (wherever applicable) &
receipts, invoice process, validation, ticket requests, etc.
o User at the PAO shall interface with the Procurement module as well as the Postal Banking
Solution (PBS).
o It shall have an interface with IPVS for receiving information on volumes of mail transferred
by air carriers and price rates
o System shall have an interface with the Procurement module for details on requests raised
by the Post Offices/ Administrative Offices, approval history and the Purchase Order
generated by the Procurement module
o GL shall get updated at the time of paying the invoice and AP gets updated with the receipt
of payment recorded in GL

Asset Accounting
o Asset accounting module shall interface with the budget and procurement modules for
seamless integration and online update of fixed asset inventory
o Shall create liability for purchases made as soon as assets are received at the DoP
o Shall have an interface with the GL to capture procurement of assets
o The system shall have separate asset codes for each asset and calculates depreciation as per
established norms to reflect the correct and fair value of each asset
o Ability to track individual items including any personal effects issued to employees like cell
phones, handheld devices.
Payroll
o System shall calculate the salary of all employees based on the employee database. After
calculating the payroll, disbursal of the salary shall occur through PBS into the bank account
of the employee
o Payroll variables shall be updated by the Post Masters and roll up for consolidation at the
circle level for payroll processing of all circle employees
o System shall interface with other applications for leave records and overtime related
information
o MIS capabilities such as four-month rolling alert report monthly for upcoming retirements in
the next 4 months to plan for cash flows and final settlements.
o MIS report for all payroll processed with details of new joinees and retirees highlighted
separately including total payroll amount and no. of employees
Budgeting
o Support for formulation of various types of budgets
o Budget approval, sanction letters and disbursement advice
o Shall meet all reporting requirements
o Facilitate decision making
o Necessary documents to be stored electronically
o In-built interfaces with other modules like fixed assets, Finance and Accounts (GL),
Procurement, etc.
Costing
o Supports different types of costing
o Facilitates decision making and cost control
o Shall meet all reporting requirements
o In-built interface with other modules like Finance and Accounts (GL), Material Management,
etc.
CSI shall have to incorporate the requirements of Modernised Costing System module being
developed by the DoP. The Users Requirements Specifications (URS), including the information
to be captured at various levels (from PO to Directorate level), along with standardized formats
for the same, information on the data flow, its analysis and various customized MIS reports etc.
which shall be required for decision making at various levels, shall be provided by the DoP for
the costing module. The proposed module shall be a part of pilot testing in Circles/Directorate
and be replicated in other circles as mentioned elsewhere in the document. This would require
coordination with the authority / officers designated by the DoP for this purpose.
Cash Management
o System shall monitor flow of payments and receipts
o Shall have functionality for defining a payment program
o System shall be able to do liquidity forecasting
o In-built interface with other modules like accounts payable and accounts receivable
Inventory Management
o Online status of inventory across the supply chain for stamps, pre printed Cash Certificates,
cheque books for Savings Bank operations, Journal registers, etc.
o Carry out inventory aging analysis
o Shall have the ability to carry out valuation of the existing inventory level across the supply
chain
o Shall track inventory levels on an on-going basis and requisitions new inventory from the
CSD/PSD when the level approaches the re-order level. At the CSD/PSD, when the inventory
falls below the re-order level, an automated procurement request shall be sent to the
respective sanctioning authority for procurement from concerned supplier
MIS Reports Generated
o Daily Transaction Report Report of transactions carried out by Post Office for post check
with vouchers at HO/ SO level
o Transaction Volume Report Report on the volume and amount of transactions done by SOs
and HOs. This will assist in understanding the financial performance of the Post Offices
o All Reports submitted to Directorate from field and by Directorate to Ministry of Finance/
external organizations
The detailed functional requirements are attached in Section 8.4.4 of Volume I of this RFP for the
following capabilities:
1. General Ledger
2. Requisition & Procurement
3. Inventory Management
4. Accounts Receivable
5. Accounts Payable
6. Asset Accounting
7. Payroll
8. Budgeting
9. Cash Management
10. Costing
11. Internal Audit & Inspection
12. Other Systems
Figure 10: Implementation Plan for Finance & Accounts
2.5 Human Resources (HR)
Human Resources administrative structure primarily comprises of 1 Directorate, 22 Circle Offices, 37
Region Offices, 512 Divisional Offices (Postal and RMS) and 1916 Sub-Divisional offices. These offices
are responsible for all administrative and HR related activities which include recruitment, leave,
transfer, training, promotion, Service Book maintenance, legal/vigilance, and performance
management.
Entire workforce is grouped under three cadres: cadre A with approximately 650 employees, cadre B
with approximately 6700 employees and cadre C with approximately 2,10,000 employees. Other
than the departmental staff, the extra-departmental staff strength is approximately 2, 74,000.
HR activities for this workforce are based on a set of pre-defined procedures, processes supported
by the following administrative structure:
Divisional and Sub-Divisional offices are closest to the field and hence are directly responsible for
the largest workforce. The controlling authority at Divisional and Sub-Divisional level is not only
responsible for HR activities but for some business related activities as well
Divisional and Sub-Divisional offices play a key role in recruitment, maintenance of employee
records and training of around 98% of the DoP employees
Directorate, Circle and Region offices are directly responsible for the HR activities of the
remaining 2% of the DoP workforce. Directorate is responsible for policy formulation,
recruitment rules and other procedures
As a result of the above mentioned distribution of work, most of the employee related information is
distributed across the various cadre controlling units, having no integration and consolidated
information at a central level.

Human Resource operations are divided into three functions:
Personnel: Personnel division deals with processes related to recruitment, leave, transfer,
promotion, and performance management. For the purpose of better administration, these
activities for each cadre are controlled by the respective appointing authorities.
Any change in the designation, grade, salary or location as a result of promotion, increment,
transfer or deputation is recorded in the employees Service Book. For all field level staff, Service
Books are maintained at the parent HO. Service Books of employees working in administrative
offices are maintained in the same offices. For promotion related process, Personnel division
also seeks inputs from the Vigilance Department regarding any pending vigilance cases or
disciplinary proceedings against an employee.
Currently, all HR related activities are done manually (on paper) although there are instances of
disparate systems being used sporadically. In absence of any centralised software, the employee
data resides with the cadre controlling administrative offices or appointing authority only. Since
administrative offices are not integrated, there are multiple versions of the same information
and dependencies on other offices for data which causes delays, redundancy and process
inefficiencies. Current system does not provide for a unique employee ID and there is currently
no option/interface where an employee can view details like service records, leave records,
salary slips etc.
Human Resource Development (HRD): HRD division manages the training requirement of
departmental and extra-departmental employees. As part of the training infrastructure, DoP has
six Centres of Excellence for Postal Training, 1 Postal Staff College and around 150 Workplace
Computer Training Centres across India.
Currently, the training administration process is manual, which results in poor visibility on
employee coverage and development. There is no centralised training database with the training
history of employees. There is no formal mechanism to evaluate the learning effectiveness in
terms of knowledge imparted, performance improvement and business benefit of the training.
In addition, the trainer/training feedback is taken on ad-hoc basis using different formats.
Establishment: Establishment division manages the periodic establishment review of workload
and financial analysis of Post Offices. The mainstay of conducting an establishment review is to
arrive at an accurate work-load analysis in Post Offices so as to enable optimal staffing in the
postal unit. The challenge with the current establishment review is the delay caused because of
unavailability of statistical data to calculate the workload. The current process is manual.
Some of the key gaps that have been identified:
Statements (reports) are created manually and maintained in registers. As the volume of data is
high, there is a lot of duplication and delay in collation and recording of the information across
the administrative offices
Disparate systems such as MS-Excel or MS-Word and different templates are being used across
offices
Lack of measurable Key Performance Indicators or Key Result Areas to ensure accountability of
each role and to be measured against the same
A lot of time, effort and resources are spent in compilation and revision of HR data. Data audit is
a challenge in the current process which would lead to data inconsistency and impact reports
and various processes.
Employee joining process
o Integration of employee joining process with recruitment system
o Integration with Payroll system
o Provisioning of Unique ID
o Retention of employee joining documents
Personnel Records
o Centralized Database Updating of central database with changes in employee data
(Transfer, promotion, movement etc.)
o Online update of Service Book
o Employee Self Service
o Integration with Payroll system, Leave Management, Performance Management, Training
Management
o Availability of information such as MIS reports - Gradation List, Seniority List
Leave Management
o Better leave compliance
o Workflow based Leave Management
o Integration of Leave Management with Payroll
Performance Management
o Documentation of objectives (Group A & B)
o Documentation of online self input
o Availability of online Annual Performance Appraisal Report (APAR)
o Integration with promotion process
o Ability to track completion of process on time
Transfer Process
o Update of the online Service Book
o Creation of standardized transfer orders
Recruitment
o Centralized position (Post) management and Vacancy Management
o Efficient and accurate calculation of vacancies
o Integration with recruitment agency
o Integration with employee joining process
Promotion Process
o Availability of APAR from Performance Management system, Vigilance records, Gradation
List
Exit Management
o Workflow based completion of exit formalities such as no-due certificates are collected,
vigilance check is completed
o Ease of calculation of post-retirement benefits
o Ensures that the employee is marked inactive in HR and Payroll records
Establishment Review Process
o Ability to draw statistical data from central data warehouse (Accountable Articles) in
Departmental POs and GDS POs
o Allows for entering unaccountable article data (If cannot be drawn from data warehouse)
o Customized reports to apply time factors to get the working hours
o Process compliance (timely and accurate workload analysis)
Training Administration Process
o Covers PTCs, WCTCs and Divisional and Zonal Training Centres under one process
o Allows for display and maintenance of personalized Training Calendar for employees
o Ensures better class scheduling and utilization of training seats
o Ensures better visibility of target audience
o Ensures better linkage with employee performance and development
The detailed To-Be Process flows are attached in the Annexure 8.3 of Volume I of this RFP.
The detailed functional requirements are attached in Section 8.4.5 of Volume I of this RFP for the
following capabilities:
1. Personnel Information System
2. Leave Management Module
3. Recruitment Management Module
4. Performance Management Module
5. Establishment Review Module
6. Training Administration Module
7. Employees Portal / Managers Portal
Figure 11: Implementation Plan for Human Resources
2.6 Customer Interaction Management
Customer Interaction Management (CIM) refers to management of different channels through which
customers interact with the DoP. Currently, the primary channel used by customers is the Point of
Sale (PoS) counter at the Post Office. The other channel, though with a limited functionality, is the
DoP website (www.indiapost.gov.in) having basic functionalities.
The customer experience is inconsistent across the web and the PoS counters. DoP also does not
currently offer alternate channels like Call Centre or mobile for delivery of its services.
2.6.1.1 Point of Sale Counters (PoS)
Today, in order to make a transaction with DoP, a customer has to walk into the nearest Post Office
and get in the queue at the PoS counters. Some of these counters are dedicated to a specific type of
transaction such as banking, insurance, retail or mail booking. Apart from these, there are multi
purpose counters that carry out all kinds of transactions and the software deployed at these PoS
terminals is called Multi Purpose Counter Machines (MPCM). At the PoS counters, customers can
buy all types of services/products and pay by cash. Currently, there is no provision for any
credit/debit card payment.
Bulk customers drop their consignments at the Mail Business Centres where the consignment is
inducted into the mail stream. For the billing, Book Now Pay Later (BNPL) scheme is provided for
Speed Post articles. BNPL is not offered for Ordinary mail and Registered letter. In the existing
system, the customer accounts are maintained regionally, even for a client with national presence as
there is no centralized database for these PoS applications.
Accounting for corporate customers is done manually. Different files are maintained (sometimes MS
Excel is used) for different types of mails (ordinary, registered, Speed Post) and at the end of the
month, accounts are reconciled manually and bill is prepared.
2.6.1.2 DoP Website
The second major channel used by the customers is the DoP website which has very basic
functionality. It only provides information about the various products and services being offered. For
Speed Post articles, the website provides the track & trace capability. It also has an elementary
customer complaint management and it registers the customer complaints. It also provides Intranet
functionality to the DoP employees.
From the business point of view, the website does not have any functionality for bookings of mails,
carrying out banking or insurance related transactions. Similarly, it does not sell Retail Post items. As
it does not allow any transactions, it does not have any account management features for individuals
or organisations as well.
2.6.1.3 Overview of existing IT Applications
The Point of Sale (PoS) counters use a number of applications:
1. Meghdoot for all the mail operations and insurance transactions
2. Sanchay Post for all banking transactions
3. PLI Software for PLI transactions
4. PoS applications of 3
rd
party merchandisers for retail post transactions such as Reliance Money
application for gold coins, IRCTC application for railway ticketing etc.
The key issue with these applications is that they all work in isolation. Largely, these applications
work in an offline mode, with no central database. Within an application, different modules are not
always integrated properly. This leads to problems in data capturing and data consistency because of
which any meaningful MIS is difficult to obtain.
In addition, operating more than one application creates complexity for the counter PA as he/she
toggles between the various applications. Further, lack of integration between application and a
shared database reduce the DoPs ability to provide single account management and consistent
customer service.
Point of Sale (PoS)
o PoS shall be integrated and shall act as a gateway to Mail Booking Engine, Postal Banking
(developed by FSI), PLI (developed by FSI) and third party applications (developed
externally) to perform various transactions related to these functions.
o The PoS shall have cash management functionality, enabling the DoP to reconcile the
counter balance with the General Ledger and should be able to generate and reconcile the
Post Office opening and closing balances, and update the same on the central server.
o Shall be supported by central and a local server, thus, enabling it to operate on online and
offline environment
o An integrated back-end system shall enable customers (individual and corporate) to carry
out transactions for different products and services using a single account
DoP Portal
o DoP Portal shall enable DoP to share information pertaining to its products and services
o Shall provide the ability to carry out transactions related to mails, banking, insurance and
eCommerce
o It shall have the capability of selling 3
rd
party products online
o Shall have advertising space for businesses
o Shall have single sign-on capability to all its customers (individual and corporate),
advertisers, merchandisers and agents
o Provide various Value-Add Services (VAS) such as print postage, schedule pick-ups, etc.
o Shall have the capability to provide an API that can be plugged in to other websites
Mobile Solution (ability for the DoP customers to leverage mobile channel)
o Carry out transactions related to mail booking, banking, insurance, eCommerce and mobile
remittances
o Track and trace of the articles through sending SMS
o SMS engine to generate mobile alerts at various points in the supply chain
o Register customer complaints and track status of customer complaints
The detailed functional requirements for CIM are attached in Section 8.4.6 of Volume I of this RFP
for the following capabilities:
1. Point of Sale
2. DoP Portal
3. Mobile Solution
The detailed To-Be Process flows are attached in the Annexure (7.1.4) of Volume I of this RFP.
Figure 12: Implementation Plan for Customer Interaction Management
2.7 Call Centre
In the existing operations, the DoP does not have a customer Call Centre where a customer can call
for any information or for transacting. As part of the India Post 2012 project, a customer Call Centre
is being established that would act as an additional channel to provide information and services,
transactions, etc. The key benefits expected from the Call Centre will be that it will enable a broader
Indian population to access products and services that they have not been able to receive in the past
and help improve the customer experience. For example, by allowing customers to do transactions
through the Call Centre, the DoP can expand its reach to customers who cannot visit the Post Office
easily, thus making it convenient for them.
Call Centre capability shall enable the customers to interact with the DoP using 24x7x 365 TOLL free
numbers.
The Call Centre shall be able to do the following functions:-
Provide information related to the products and services
Initiate and carry out transactions
Status update on previous transactions
Take orders or requests for mail booking, banking, insurance and retail post
Resolve customer enquiries such as track and trace of the articles, retail post order fulfilment
etc.
Register customer complaints and track status of customer complaints
Handle enquiries from WorldNet Express Customers and Foreign Postal Operators
The Call Centre shall use a combination of IVR and operator support to provide the complete range
of customer service.
CSI shall bring in the complete Call Centre infrastructure including physical and technical
infrastructure, telephony, security, hardware/software, people, maintenance and bandwidth.

2.7.3 Operational Requirements
Indicative requirements for Call Centre are listed in the following sections.
2.7.3.1 Operational Requirements Finance
Table 3: Call Centre Requirements - Banking
#
Nature of
Transaction
Transaction Description Manual/ IVR
Manual action at the Call
Centre level
Call Centre Output
Interface with
other systems
1. Inquiry
Product information
New accounts /schemes
Debit/ATM card
PO location
Rate of interest/service
charges
3
rd
party products
Both
Provide information from the
manual provided and training
imparted
Status/information PBS
2. Inquiry Balance inquiry Both Fetch details from PBS Status/information PBS
3. Inquiry Transaction Inquiry Manual Fetch details from PBS Status/information PBS
4. Inquiry Transaction history Both Fetch details from PBS Status/information PBS
5. Inquiry Interest earned and paid Manual Fetch details from PBS Status/information PBS
6. Inquiry TDS deducted Manual Fetch details from PBS Status/information PBS
7. Inquiry Cheque Status Both Fetch details from PBS Status/information PBS
8. Inquiry TD details Both Fetch details from PBS Status/information PBS
9. Transaction
Request for interest
Manual
Log in request, generate and
Interest certificate PBS
certificate despatch certificate
10. Transaction Standing Instruction Manual
Log in request and assign to
Circle processing centre
Recording and forwarding PBS
11. Transaction Cheque Book Request Both Data entry/request into PBS Recording PBS
12. Transaction
Statement of account
through fax/email/post
Both
despatch/send statement
Statement of Account PBS
13. Transaction Debit card issue/reissue Manual Data entry/request into PBS Recording and data entry PBS
14. Transaction
PIN issue/reissue for Debit
card
Manual Data entry/request into PBS Recording and data entry PBS
15. Transaction
PIN issue/reissue for internet
banking
Manual Data entry/request into PBS Recording and data entry PBS
16. Transaction Activation for blocked PIN Manual Data entry/request into PBS Recording and data entry PBS
17. Transaction TD renewal Manual
18. Transaction
Request for TD
certificate/statement
Manual
despatch/send statement
TD certificate/statement PBS
19. Transaction
Funds transfer to linked
accounts
IVR None Transaction ID PBS
20. Transaction PO/DD request Manual
respective office
21. Transaction Stop payment Both Data entry/request into PBS Recording and data entry PBS
22. Transaction Bill payment Both
23.
Customer
complaints
Complaint logging Manual
respective office
Complaint ID PBS
24.
Customer
complaints
Transaction discrepancy Manual
respective office
Complaint ID PBS
2.7.3.2 Operational Requirements - Insurance
Table 4: Call Centre Requirements - Insurance
#
Nature of
Transaction
Centre level
Call Centre Output
Interface with
other systems
1. Inquiry Policy servicing
Both (Manual
and IVR)
Check the details from the
Core Insurance System,
agency management system
Status/information
Core Insurance
System, Agency
Management
System
2. Inquiry Proposal status Both Status/information
3. Inquiry
Medical Test Appointment
status
Both Status/information
4. Inquiry Policy status Both Status/information
5. Inquiry Premium due date check Both Status/information
6. Inquiry Premium amount check Both Status/information
7. Inquiry Sum assured check Both Status/information
8. Inquiry Fund value check Both Status/information
9. Inquiry Surrender value check Both Status/information
10. Inquiry Partial Withdrawal amount Both Status/information
11. Inquiry Loan amount check Both Status/information
12. Inquiry EMI for Loan taken Both Status/information
13. Inquiry Tenure of loan Both Status/information
14. Inquiry Rate of Interest of Loan Both Status/information
15. Inquiry Premium updated status Both Status/information
16. Inquiry Policy maturity date info Both Status/information
17. Inquiry Maturity amount info Both Status/information
18. Inquiry
Information about
documents required to be
submitted for policy renewal
19. Inquiry Claim status Both Status/information
20. Inquiry Agent License expiry date Both Status/information
21. Inquiry
Provide product related
information
22.
Customer
complaints
Customer complaint as
regards policy related issues
Manual
Record complaints in Call
Centre Solution
Recording of complaint
with complaint id and
forwarding of complaint
Call Centre
solution
23.
Customer
complaints
Customer complaint against
agents
Manual
Record complaints in Agency
Management System
Agency Mgt.
System
24. Transactions Claim intimation Manual Initiation of transaction Initiation of transaction
Call Centre
solution
2.7.3.3 Operational Requirements Mail Operations
Table 5: Call Centre Requirements Mail Operations
#
Nature of
Transaction
Centre level
Call Centre Output
Interface with
other systems
1. Inquiry
Quote/estimate generation
for various services (Speed
Post, Registered Post, Parcel
Logistics Post etc.)
Manual
Enter the relevant data into
the Point of Sale and provide
the estimate
Quote/estimate Point of Sale
2. Inquiry
Status update of
consignment sent through
the DoP
Speed Post
Registered Post
Logistics consignment
Parcel
VPP etc.
Both
Captures the unique
consignment number and
fetches the status from the
IPVS
Consignment status IPVS
3. Inquiry
Status update regarding the
items ordered through the
DoP website
Both
Captures the transaction
number and fetches the
status from the system
Consignment status WMS, IPVS
4. Booking
Booking of articles through
the DoP under any of the
following:
Speed Post
Registered Post
Logistics consignment
Manual
Carries out the booking
through the PoS and provides
the unique consignment
number to the customer.
Send the pickup request to
the TMS/DPMS (as the case
Confirmed booking of
articles
PoS, TMS, DPMS
Parcel
VPP
Pickup request of these
articles shall be sent to
relevant systems
may be)
5.
Customer
Complaint
Complains for a
missing/delayed
consignment
Manual
Checks the system for the
delay/missing item and raises
a query for the same
Recording of complaint
with complaint id and
forwarding of complaint
IPVS
The detailed functional requirements are attached in Section 8.4.7 of Volume I of this RFP for the following capabilities:
1. Customer Support Centre
2. Interactive Voice Response
3. Reporting

Figure 13: Implementation Plan for Call Centre

2.8 Customer Information Management
Customer Information Management (CIFM) refers to the management of all information related to
the customers across all the services of the DoP: Mails, Banking, Insurance, and Retail Post amongst
others.
This customer information can be utilized for various purposes such as:
1. Providing an integrated interaction experience to all the customers
2. Providing a consolidated view to the DoP to better manage its customers
3. Using customer information for customer analytics
2.8.1 One View Customer Experience
1. CIFM shall provide customers with a single sign-on and single view for all its transaction
requirements
2. CIFM shall consolidate all customer transactions across various services such as Mails, Banking,
Insurance, and Retail Post amongst others
3. CIFM shall integrate with all Customer Interaction Channels to give a standard service quality
across different channels
2.8.2 One View Business Experience
1. CIFM shall enable DoP to view customer information details such as name, address, contact
number, etc.
2. CIFM shall enable DoP to view customer transaction details such as last transactions done,
account balance, credit balance, etc.
3. CIFM shall enable DoP to view consolidated view of the customers by different parameters such
as by services, by balance outstanding, etc.
2.8.3 Customer Analytics
1. CIFM shall provide with reports on customer information on a periodic basis (weekly, monthly
and yearly)
2. CIFM shall provide insights using the customer information available
3. CIFM shall provide insights about the new opportunities for cross-selling, up-selling, etc
4. CIFM shall provide insights about the various products and services offered by the DoP
2.9 Common Infrastructure Solution
2.9.1 Enterprise Service Bus (ESB)
Refer to section 4.1 (Solution Requirements) for the requirements pertaining to ESB.
2.9.2 Email solution
The bidder shall design and implement centralized email and messaging solution including instant
messaging solution for DoP/DoP Authorized users:
General Requirements:
The software license shall be enterprise wide
The bidder shall size and provide necessary hardware and system software based on the
proposed mail solution
Proposed Architecture should have no single point of failure
The detailed functional requirements are attached in Section 8.4.8.3 of Volume I of this RFP. The
sizing should be done for 40,000 accounts.
2.9.3 Directory Services
The bidder shall design and implement centralized authentication and authorization solution for
DoP/DoP Authorized users.
General Requirements:
The directory software license shall be enterprise wide.
The bidder shall size and provide necessary hardware and system software based on the
proposed mail solution
Proposed Architecture should have no single point of failure.
The detailed functional requirements for Directory services are attached in Section 8.4.8.4 of Volume
I of this RFP.
2.9.4 Enterprise Monitoring System (EMS)
Enterprise Management Solution should provide end-to-end, comprehensive, modular and
integrated management of heterogeneous IT infrastructure and application to maximize the
availability of IT services and Service Level Agreement (SLA) performance. The management system
needs to aggregate and correlate events and performance information from the various sources and
tie them to service definitions.
The proposed solution should automatically document problems and interruptions for various IT
services offered and integrate with the service level management system for reporting on SLAs. The
proposed solution must be unified and must also generate a comprehensive view of service with
real-time visibility into service status and identify the root cause of various infrastructure and
application problems as well as prioritize resources based on impact.
The proposed EMS solution must consist of the following core functionalities:
1. Availability and Performance Management System including
a. Virtualization Management System
b. Server Management System
c. Database Management System
d. Monitoring for web-based portals and applications
2. Central Service Management System including
a. Service Management Portal
b. Service Level Management (SLM) System
c. Helpdesk and Ticketing System
3. EMS Integration
The detailed functional requirements for EMS are attached in Section 8.4.8.1 of Volume I of this RFP.
2.9.5 Service Desk
The detailed functional requirements for Service Desk are attached in Section 8.4.8.2 of Volume I of
this RFP.
Figure 14: Implementation Plan for Common Infrastructure Solution
2.10 MIS & Business Intelligence Services
The list of reports described in this section is indicative and CSI shall have to finalise the same during
the SRS preparation and implementation. It must be noted that in addition to the reports listed in
the RFP, the proposed solution should be able to generate reports out of the data readily available in
the system.
The proposed solution shall generate following MIS reports for the DoP, for any specified period:
2.10.1 Mail Operations & Logistics Post
Table 6: MIS Requirements Mail Operations & Logistics Post
# Report Name Report Description Frequency
Report
variation
1.
DoP product-wise
revenue report
Provides the product-wise break-up
(Speed Post, Registered Post, Parcels,
EPP, Retail, Logistics, Inland, Foreign
Article etc.) of DoP revenues
Monthly
Circle, HO, SO,
BO
2.
Product-wise
volumes
Provides the product-wise (Speed Post,
Registered Post, Ordinary , Inland,
Foreign Article etc.) volumes of mail
traffic (delivered) for various delivery
offices
Monthly
Circle, HO, SO,
BO
3.
Processed Mail
Volumes
Provides the product-wise (Speed Post,
Registered Post, Ordinary , Inland,
Foreign Article etc.) volumes of mail
traffic handled at various facilities
Monthly
Delivery
Offices, MPC,
SPC
4.
Traffic in different
weight slabs
Provides weight slab-wise number of
articles booked, average weight of
articles, percentage of traffic
above/below a chosen weight
denomination etc.
Monthly
Booking
Office,
Delivery Office
5. Pincodes missing Share of articles with missing pin codes Monthly Post Office
6.
Network Scan
Compliance Report
Provides the compliance to the
article/bag scanning norms as defined
in the system for all facilities
Monthly
Booking
Office, MPC,
SPC, NSPC,
Delivery Office
7.
Within City Scan
Analysis
Scan analysis per leg of transit within
city as defined in the system
Weekly
Post Office,
NSPC, Delivery
Office
8.
Across City Scan
Analysis
Scan analysis per leg of transit across
city as defined in the system
Weekly
Post Office,
NSPC, Delivery
Office
9.
Delivery
Performance
Report
Provides the % deliveries everyday for
the accountable articles taken out for
delivery that day
Daily
Delivery
Offices
10.
Article Transit
Analysis within City
Measures speed and reliability of
processing of accountable articles from
booking to delivery through capturing
time per leg of transit within city
Weekly City
11.
Article Transit
Analysis across
Cities
Measures speed and reliability of
processing of accountable articles from
booking to delivery through capturing
time per leg of transit across cities
Weekly Routes
12.
Bag Label
Compliance Report
% share of bags without proper bag
labels
Daily
SPC, Mail
Offices
13.
Bag Closing
Adherence Report
Share of articles closed after cut-off
time
Daily
Post Office,
SPC, Mail
Office
14. Mis-sort Report
Share of mis-sorted accountable
articles
Daily
SPC, Mail
Office
15.
Articles not
dispatched in same
set
Share of articles not dispatched in the
same set
Daily
Mail Office,
SPC
16.
Delivery Norm
Compliance Report
Provides the number of days taken
(from acceptance to delivery) for
delivery of various articles (Speed Post,
Accountable etc.). This shall have the
distribution such as x% got delivered in
3 days, y% got delivered in 4 days, z%
got delivered in 5 days and t% got
delivered in more than 5 days
Monthly
Directorate
level
17.
Labour Productivity
Report
Provides the labour productivity (mails
handled/man-day) for different skill-
sets and various facilities
Monthly
Booking
Office, MPC,
SPC, NSPC,
Delivery
Offices
18. Staff Absenteeism Captures the number of staff absent Daily All offices
19.
Vehicle Utilization
Report
Provides the capacity utilization of
Logistics Post vehicles for different
routes
Monthly
Circles,
Warehouses,
Logistics Post
Centres
20.
MMS Schedule
adherence Report
Provides the schedule adherence of
MMS vehicles on the route they follow
to pickup or drop mails at various
facilities
Daily
Division Office,
MMS depots
21.
Warehouse
Capacity Utilization
Report
Provides the capacity utilization of
various Warehouses and Logistics Post
Centres
Monthly
Warehouses,
Logistics Post
Centres
22.
Customer
Complaints
Provides the product-wise break-up of
customer complaints categorised under
key categories
Monthly
Directorate,
Circle, Division
23.
Summary of
Online/offline
booking for POS
Provides terminal-wise summary report
of online versus offline transactions
Daily Post Office
24.
Inventory Reports
for Stamps
Provides the SKU-wise inventory of
stamps for different Post Offices
Daily Post Office
25.
Volume inducted
through
Appointments
Management dashboard capturing the
volume inducted at several offices,
source-destination volumes, customer
volumes, performance, and turn-
around times.
Monthly
Post Office;
Warehouse,
LPC, Bulk Mail
Centres
26.
Beat workload
Report
Report of all items handled by beat
for summary level, report includes
average pieces per beat for a particular
region or office.
Daily Delivery Office
27.
Inventory Reports
for Warehouse
Inventory report of all the items within
the entire supply chain (e.g.
Warehouse, in-transit etc.) of Logistics
Post
Weekly
Warehouse,
LPC
28.
Vehicle
Maintenance
Adherence Report
Provides report on planned v/s actual
maintenance for the India Post owned
vehicles (MMS & Logistics Post)
Monthly
Division Office,
Warehouse,
LPC, MMS
Depots
29.
Transportation
Performance
Report
Summary report provides the
performance of vehicle on scheduled
time versus actual time of arrival.
Shows how many vehicles performed
within scheduled time, and how many
were within 5%, 10% or greater
variation
Monthly
Warehouses,
Logistics Post
Centres, MMS
Depots
30.
Online-Offline
Booking Summary
Report showing terminal-wise % of
online bookings done
Monthly Post Office
31.
Transaction Time
Summary
Report showing average time spent by
the user for each transaction type
Monthly Post Office
32.
Supply Chain
Performance
Report
Report showing on-time articles,
average velocity of articles through the
network, etc. for Accountable articles
Monthly
National,
Circle-wise
33.
Appointment
Schedules Pending
Report
Facility-wise report of all the pending
appointment requests past their due
time for both pick up and drop
Daily,
Weekly,
Monthly
Post Office,
Circle
34.
DoP Appointment
Performance
Report
DoPs performance on servicing an
appointment request (both pick up and
drop). For drop, the time taken for
customer vehicle to drop a
consignment, turnaround time, waiting
time etc. For pickup, the on-time arrival
at pickup address, right type of vehicle
etc.
Monthly
Post Office,
LPC
35.
Customer-wise
appointment
performance
Customers adherence to schedule,
vehicle wait time, late cancellations,
document completeness, order
completeness etc.
Monthly
Corporate
Customer wise
36.
Business Reply Mail
Count
Report showing BRM counts Monthly
Mailer, region,
Post Office
37.
Warehouse
Report
Report for warehousing capacities
available across all the warehouses and
LPCs
Daily
Warehouse,
LPC
38.
Warehousing
Discrepancies
Report
% value of lost products (at cost) of the
total value of products stored
Monthly
Warehouse,
LPC
39.
Warehouse Picking
Accuracy Report
Order picking accuracy (% items picked
as per the picking list)
Monthly
Warehouse,
LPC
40.
Transport
Maintenance Plan
Adherence Report
Plan versus actual maintenance plan
for each of the DoP vehicles
Monthly
Division,
Circle, MMS
Depots
41.
Vehicle Breakdown
Report
Vehicles details, breakdown details,
date of breakdown, type of breakdown,
downtime
Monthly
Division,
Circle, MMS
Depots
42.
Transportation
Performance
Report
Performance of the vehicle against the
scheduled time of arrival
Monthly
Vehicle-wise,
Division, MMS
Depots
43.
Report
Route-wise total vehicle capacity
available, capacity utilized, space
capacity, DoP own capacity, Hired
capacity
Daily
Route wise,
Division, MMS
Depots
44.
Transportation Cost
Report
Route-wise cost for own and hired
vehicles
Monthly
Division,
Circle, MMS
Depots
45.
Transport
Discrepancies
Report
Value of product lost/damaged during
transportation as a percentage of total
goods transported
Monthly
MMS Depot,
Vehicle-wise,
Route-wise,
Facility wise,
Driver-wise
46.
Network Flow for
Office of Exchange
Flow within the Office of Exchange,
including the retention and release by
Customs
Weekly
Office of
Exchange
2.10.2 Finance & Accounts
Table 7: MIS Requirements Finance & Accounts
Report
variation
1. General Abstract
Report on details of revenue and
expenditure of DoP in format required
by CGA
Monthly HoA
2. Circle Abstract
Report on details of Circle level
revenue and expenditure
Monthly Circle, HoA
3.
Daily Transaction
Report
Report on daily transactions carried
out by each Post Office
Daily
BO, SO, HO,
LoB
4.
Transaction Volume
Report
Report on volume and amount of
transaction carried out by PO
Monthly BO, SO, HO
5.
Operational
Procurement
Request Summary
Report listing items procured by Post
Offices (CC, stamp, cheque books, etc)
Monthly
Circle, Region,
Division, Post
Office
6.
Inventory Position
Report
Report showing the inventory position
of CC, stamp, cheque book, etc.
Weekly
By CSD/ PSD/
HO/ SO/ BO
7.
Vendor
Performance
Report
Report showing history of payment
made by other agencies to DoP
Quarterly Vendor
8.
Vendor Summary
Report
Report showing history of transactions
vendor has made with DoP
Quarterly Vendor
9.
Receivable Days
Report
Report showing days receivable by
vendor
Quarterly Vendor
10.
Payable Days
Report
Report showing days payable by
vendor
Quarterly Vendor
11. Receivables Report
Report showing receivables from other
agencies on account of pension paid to
their employees/ BNPL/ adjustment
with Global Postal organization etc.
Monthly Customer
12.
Agency Pension
Paid Report
Report showing amount paid out,
deposits and claims received and
interest earned by DoP
Monthly Agency
13.
Purchase Order &
Invoice Report
Report showing list of Purchase Order
raised and status of invoices against
each Purchase Order
Monthly Post Office
14.
Open Invoice
Report
Report showing details of all open
invoices raised on/ by DoP and related
stages of processing
Monthly
Agency, due
date, invoice
value
15. Liability Report
Report showing liabilities of DoP on
account of purchasing of goods and not
clearing invoice
Monthly
16. Payroll Report
Report showing payroll amount
disbursed to employees and no. of
employees
Monthly
Post Office,
New joinee or
retiree
17.
Upcoming Retiree
List
List of people nearing retirement in
the next 4 months
Monthly NA
18.
Report for receipts/
expenses
Report for receipts/ expenses booked
under Major Head
MH 2235
Monthly
&
Quarterly
HoA
MH 2071 (consolida
ted)
19.
PLI Receipt &
Payments
Report showing PLI Receipt &
Payments (MH 8011)
Monthly
20.
MH 3201-03 - PLI
(Non Plan)
Report showing amount booked under
MH 3201-02-PLI
Monthly
21. Interest payments
Report of interest payments under
Major Head MH 8008 (Cr & Dr)
Monthly
22.
Revenue / Expenses
Report
Report for revenues/ expenses booked
under following Major Heads
MH 0037 - Custom Duty
MH 0021 - Income Tax
MH0051 CRF Stamps
MH 2071 - Telecom Pension
MH 8661 WUSFI
MH 7610 - Loans and advances
Monthly HoA
23.
Report for booked
figures
Report for booked figures under Plan &
Non Plan heads
MH 3201 Plan figures
MH 5201 Plan figures
Monthly HoA
24.
DG Progressive
Statement
Report of booked figures under Major
Heads 1201, 3201, 5201
Monthly
25. Flash figures to CGA
Report for anticipated revenues for
following month
Monthly
26.
Revenue of BD
Schemes
under Business Development
Monthly
27.
Statement of
Central
Transactions
Report of minor head-wise bookings at
the close of financial year
Annual
28.
Journal entries to
SCT
Report of corrections to SCT Report Annual
29. Loans and advances
under Major Head MH 7610
Annual
30.
National income of
States/ Circle
Report Annual
31. RBI Balance Report
Report of reconciliation statement of
RBI balances
Monthly
32.
Financial Review of
PLI Fund
Report describing policies issued,
claims settled, etc.
Annual
33.
Financial Review of
RPLI Fund
Annual
34.
Financial Review of
EDAGIS 92
Annual
35.
PLI Fund Financial
Report
Report on Balance Sheet & Revenue
Accounts
Annual
36.
RPLI Fund Financial
Report
Accounts
Annual
37.
EDAGIS 92 Fund
Financial Report
Accounts
Annual
38.
Statement of PSB
suspense
Report of PSB suspense (Opening
Balance, Booked, Cleared, Closing
Balance)
Monthly
39.
Statement on Penal
interest claims
Report of no. of cases of excess/
unsettled reimbursement with dealing
Bank and penal interest charged
Quarterly
40. Asset Report
Report of assets acquired during year
and cumulative assets at end of year
Annual
41.
Civil Expense
Report
Report for expenses recorded under all
Civil Heads of Accounts
MH 2235
MH 7610
MH 8008
Monthly HoA
42.
Detailed
Appropriation
Accounts Report I
Report on actual expenses booked
versus Plan and Non Plan figures
Annual
43.
Detailed
Appropriation
Accounts Report II
Annual
44.
Detailed
Appropriation
Accounts Report III
Annual
45.
Detailed
Appropriation
Accounts Report IV
Annual
46.
Consolidated
Booked Figures
Report
Report showing consolidated booked
figures under MH 8001, 8002, 8006
Monthly State, UT, HoA
47.
Small Savings
Collections Report I
Report of monthly and cumulative
consolidated booked figures for Small
Savings Collections
Monthly By Scheme
48.
Small Savings
Collections Report
II
Report showing receipts and
outstanding balances of Small Savings
Collections
Monthly By Scheme
49. Drawings Report
Report of drawings from banks (under
MH 8670)
Quarterly
&
Annually

50. Remittance Report
Report showing remittances to banks
(under MH 8677)
Quarterly
&
Annually

51.
Suspense Account
Report
Report showing amount under
Suspense (MH 8661)
Quarterly
52.
Productivity Linked
Bonus Statement
Report for capturing bonuses on
account of extra revenue generated
Annual
53.
Savings Accounts
Report
Report showing no. of accounts in
Small Savings Schemes
Annual
54.
Statement of IMO,
FMO, TMO and
FAMO nos. & Value
Annual
55. Report on IPOs Sold Statement of IPOs sold Annual
56.
Unclaimed PO Cash
Certificates Report
Statement of unclaimed balances PO
CC to Postal revenue receipts
Annual
57.
Forfeited MOs
Report
Statement of forfeited MOs transferred
to Postal revenue receipts
Annual
58.
Live Accounts
Report
Report showing no. of live accounts in
Small Savings Schemes
Annual
59.
Cash Certificates
Report
Statement showing CC issued/
discharged during financial year
Annual
60.
Financial Accounts
Report - I
Statement No. 4 relating to Finance
Account
Annual
61.
Financial Accounts
Report - II
Statement No. 3 & 11 relating to
Finance Account
Annual
62.
POR & Central
Check Register
Statement
Statement of Outstanding Balances Annual By Circle
63.
Adverse Balances
Report
Statement of adverse balances Annual
64.
National Savings
Scheme
for Cash Certificates
MH 8001
MH 8002
Annual
65.
Report for
revenues/ expenses
under Major Head
MH 8006 PPF
MH 8009 GPF
MH 8336 - Civil deposits bearing
interest
MH 8443 - Civil Deposits not bearing
interest
MH 8446
Annual HoA
66.
Report for
revenues/ expenses
under Major Head and Minor Heads
(MH 8446)
Annual HoA
67.
Report for receipts/
expenses booked
Report for receipts/ expenses booked
under Major Head
MH 8446 - Trusted Interest Account
MH 8446 IPO
MH 8446 BPO
MH8446 - Postal Deposits
MH 8446 - Gift Coupons
Monthly HoA
68.
Report for
revenues/ expenses
under Major Head
ROB MH 8553
MH 8661
MH 8680
MH 8787 - Transactions with
Railways
MH 8789
Annual HoA
69. Work Report - I
Report showing status of MO Pairing
work at PAOs
Monthly
70. Work Report - II
Report showing consolidated
statement of un-posted, issue,
discharge, discrepant & interest items
of PO CC
Quarterly
71. Work Report - III
Report on the clearance of items places
under Suspense of IPO paid/ sold
Quarterly
72. Work Report - IV
Report showing advance verifications
of credit of wanting MO paid vouchers
Quarterly
73. Work Report - V
Report of wanting list of MO paid
vouchers/ returns from foreign PAOs
and Home PAOs
Quarterly
74. Work Report - VI Report on GPF Final Payment Cases Quarterly
75. Work Report - VII Report on despatch of GPF Annual Slips Annual
76. Work Report - VIII
Statement of supply of MO Paid
vouchers to Police Department
Bi-annual
77. Work Report - IX
Report on GPF incomplete accounting,
missing Cr/ Dr and un-posted items
Quarterly
78.
State of Work
Report
Circle wise report on work position at
PAO at the end of the month
Monthly
Different
sections in
PAO (Account
Current, MO,
CC, IPO)
2.10.3 Human Resources
Table 8: MIS Requirements Human Resources
# Report Name Report Description Frequency Report variation
1.
Employee
Demographics
Details
Demographics Details (Age, Cadre
Strength, Gender, Staff Strength etc)
Annual
Directorate,
Circle, Region,
Division
2.
Employment Status
Report
List of Employees Joined, Confirmed,
On Probation, Retired
Six-
monthly
Cadre
3.
Revenue generated
per employee
Total Revenue generated /
employees
Six-
monthly
Directorate,
Region, Circle,
Division
4.
Employee Cost
Classification
Report of various staff cost (salary,
allowance, loans, advances, pension)
Annual Directorate
5. Gradation List List of seniority for each cadre Annual Cadre
6. Seniority List List of seniority for each GDS Post Annual Cadre
7.
Summary of Service
Book Changes
Summary of Updates on Service
Book
Six
Monthly
By Employee
8.
Report of Employee
Queries/RTIs
Number and type of employee
queries
Annual
Directorate,
Region, Circle,
Division
9.
Report of Vigilance
Cases
Number and type of vigilance cases
with status
Quarterly
10.
Report of Legal
Cases
Number, type and status of Legal
cases
Quarterly
11. Verification Check
Summary of verification check and
status
Monthly
12.
Exit Management
Formalities
Summary of status of No-dues
certificates and other formalities
Quarterly
13. Pension Orders
Report on status of provisional or
permanent pension order issued
Quarterly
14. Leave Report
List of employees on leave at any
point in time
Need
Based
15.
Leave availed in a
specific period
Total leave availed by employees in a
location
Quarterly
16. Long Leave Record
List of employees on long leave
(medical, EOL, ML) or leave without
approval or absconding
Quarterly
17. Expiring Documents
List of employees for whom the
supporting documents are expiring
Monthly
18.
Summary Leave
Account for
Employee
Summary of Leave Account Balance
for each type of leave
Monthly Employee
19.
Objective Setting
Completion
List of employees who have
completed Objective Setting and
accepted
Quarterly
Directorate,
Region, Circle,
Division
20.
Self Input
Completion
completed Self-Input
Quarterly
21.
Appraisal
Completion
List of employees for whom the APAR
is completed by competent
authorities
Quarterly
22. Summary of APAR Summary of last 5 years APARs
Need
Based
23.
Rule 37 Transfer
Report
List of employees transferred under
Rule 37 and status
Annual
Directorate,
Region, Circle,
Division

24.
Rule 38 Transfer
Report
List of employees transferred under
Rule 38 and status
Annual
25.
Transfer Status
Report
Status of charge report received
(Joined/Declined/Yet to Join)
Monthly
26. Extension Report
List of employees granted extension
in an office/post
Annual
27. Vacancy calculation
Number of vacancies calculated
under each cadre (by Rec Rule and
Category)
Annual
28.
Applications to
Vacancy Ratio
Ratio of number of applications
received for each vacancy
Annual
Cadre,
Directorate,
Region, Circle,
Division
29.
Eligible Candidate
to Vacancy Ratio
Ratio of number of candidates
eligible for each vacancy
Annual
30. Merit List List of Candidates Selected Annual
31. Offer Status Report
Status Report of Offer
Acceptance/Rejection/Extension
offered
Annual
32. Recruitment Cycle Time taken to close a vacancy Annual
33. Recruitment Cost Average cost per recruit Annual
34. Recruitment Report
Number of vacancies closed in each
location (Circle, Region, Division)
Annual
Directorate,
Region, Circle,
Division
35. Recruitment RTIs
Number of Examination related RTIs
received
Annual
36.
Zone of
Consideration
List of Zone of Consideration per DPC Annual
Cadre,
Directorate,
Region, Circle,
Division
37. Promotion Report
List of employees promoted in each
location
Annual
38.
Promotion Status
Report
List of employees who
accepted/declined promotions
Monthly
39. Joining Status
List of employees who joined the
new location/post on time
Annual
40.
Mandatory Training
Completion
completed/not completed the
training after promotion
Quarterly
41.
Utilisation of Plan
Fund
Utilization of Plan Funds (%) Quarterly
Directorate,
Circle and
Training Centres
42.
Training
Cost/Employee
Average training cost employee (INR
per unit)
Six -
monthly
Training Centre
43.
Training Man-hours
per employee
Average Training Man-hours per
employee per year (hours/employee)
Quarterly
44.
Utilization of
Training Seats (%)
Training seats utilised or left vacant Quarterly
45. Training Programs
Number of Training Programs
completed/cancelled per training
centre (number)
Quarterly
46. Self Nominations
Number of self-nominations/Total
Employee Trained (%)
Six
Monthly
Circle
47. Training Numbers
List of employees trained in a
particular period (in number)
Quarterly
Directorate,
Region, Circle,
Division, Training
Centre
48.
Mandatory Training
Completion
List of employees who have not
completed mandatory trainings
Quarterly
Cadre,
Directorate,
Region, Circle,
Division
49.
External Training
Programs Report
List of employees trained in external
training programs
Quarterly
Training
Program
50.
Performance
Development
List of employees trained on training
programs recommended in
performance appraisal
Annual Circle, Cadre
51.
Training
Effectiveness
Report
Employee satisfaction with training
Course (%)
Need
Based
Training Centre
52.
Trainer Satisfaction
Report
Satisfaction with Trainer (%)
Need
Based
Trainer
53.
Participant
Evaluation Report
Participant Evaluation (%)
Need
Based
Training
Program
54.
Supervisor Increase in the
Annual
Training
Feedback Report productivity/performance (%) Program,
Training Centre
55.
Planning
Information Report
Sanctioned Staff Vs Working Staff Annual Division
56.
Periodic Review
Calendar For DO
List of Departmental Post Offices due
for Workload Analysis
Annual Division
57.
Periodic Review
Calendar For GDS
Post
List of GDS Posts due for Workload
Analysis
Annual Division
58.
Periodic Review
Calendar For GDS
PO
List of GDS Post Offices due for
Financial Assessment
Annual Division
59. EST 2
List of all Transactions in a Post
Offices with Values (Pre-defined
format)
Triennial Post Office
60.
Summary of
Operative Work
Hours
Operative Staff Work Hours Summary
after applying the time factors
61.
Summary of
Supervisory Work
Hours
Supervisory Staff Work Hours
Summary after applying the time
factors
62.
Summary of
Delivery Postman
Work Hours
Delivery Staff Work Hours Summary
Triennial By Post Office
63.
Summary of Group
D Work Hours
Group D Staff Work Hours Summary
64.
Summary of GDS
Work Hours
GDS Staff Work Hours Summary after
applying the time factors
65. EST 79
Summary of Entire Post Office
(Woking Hours, Staff Hours)
66. EST 5
Financial Assessment Report for GDS
Post Offices (Pre-defined)
67.
Workload Analysis
for GDS Post
Summary of Workload Summary for
GDS Post (pre-defined format)
Triennial
By GDS Post in
Post Office
68.
Establishment
Review Report
Summary of changes in
Establishment Information
Annual
By Directorate,
Region, Circle,
Division
69.
Allowance Revision Summary of allowance revision for
Annual
Report GDS Post
70.
Financial
Assessment Report
Summary of changes in
establishment Information for GDS
Post Offices
Annual
2.10.4 Call Centre
The system shall have the capability of monitoring specific levels of usage for different services
provided by the Call Centre. Required MIS includes, but is not limited to:
Table 9: MIS Requirements Call Centre
Report
variation
1. Call Usage
Calls received per week, month or
any other desired period. This can be
numeric or graphical representation
of the volumes
Weekly,
Monthly or
any
specified
period
Business,
Nature of call
(enquiry,
complaint
etc.)
2. Call per Phone line Call per phone line or port
Weekly,
Monthly
Call Centre
3. Call Length Average call length Monthly
Business,
Nature of Call
4.
Call Length
variation
Longest call length Monthly
Business,
Nature of Call
5. Dropped Calls
Number of dropped calls after
answering including
Calls that ended while on hold,
indicating that the caller hung up
Call that ended due to entry errors
using the automated system
indicating difficulty in using the
system
Weekly,
Monthly
Call Centre
6. Time to Answer
No. of rings before a call was picked
up (including maximum and
minimum)
Daily Call Centre
7.
Accuracy of
complaint logging
by Call Centre
operators
This is the percentage of complaints
that have been captured incorrectly
by the Call Centre agents making it
difficult to resolve the same
Monthly Call Centre
8.
Percentage of Repeat calls are defined as the calls
Monthly Call Centre
repeat calls made by callers who have already
called the Call Centre on the same
date (from 0.00 hrs to 24.00 Hrs)
preceding this repeat call.
9.
Time taken for
resolution of
complaints /
grievances
This measures the time taken for
resolution of complaints
satisfactorily.
Monthly Call Centre
CSI shall develop a dash board for different functional areas based on the requirement gathered
during the creation of SRS. The information displayed by these dashboards will have to reflect
information on the basis of real-time data.

Figure 15: Implementation Plan for MIS
3. Scope of Work
3.1 Overview of Scope of Work
The following section outlines the broad elements under the scope of work for the Core SI and the
subsequent sections highlight the detailed scope of work for each of these areas. The scope of work
is classified as below:
1. Supply of Software
2. Supply of necessary central hardware
3. Design and Build Services
4. Implementation Services
5. Solution Integration
6. Data Migration Services
7. Training
8. Operations & Maintenance Services
3.2 Detailed Scope of Work
3.2.1 Supply of Software
1. CSI shall supply the software including operating system, application, database and any other
software as required to support the business functions described in Section 2.
2. All licenses shall be enterprise wide.
3. CSI shall supply the security software, including security incident, event, identity and access
management.
4. CSI shall provide the directory and email software for DoP employees.
3.2.2 Supply of necessary central hardware
1. CSI shall carry out the sizing of necessary server hardware required at the Data Centre as well as
Disaster Recovery site for the proposed solution. Hardware includes central server hardware,
storage, backup, and tape library system.
2. CSI shall make sure that the hardware meets the DoPs current and future business needs. While
doing this, CSI must meet the minimum specifications mentioned in Section 4.2 of Volume I of
this RFP.
3. CSI shall supply the appropriate hardware.
4. Client side hardware shall be out of scope of this RFP. However, the CSI shall work with DoP
and/or the respective hardware vendors to validate the suitability of the IT infrastructure for the
implementation of the proposed solution.
3.2.3 Design and Build Services
1. CSI shall develop an architecture that is highly available, scalable, flexible and secure.
2. CSI shall design an integration architecture model and approach, using SOA and ESB approaches
3. CSI shall design and build a data model to share data across multiple systems in the organisation
4. CSI shall design the solution architecture & specifications as per the FRS specified in Annexure
8.3 of Volume I of this RFP and the technical requirements in Section 4 of Volume I of this RFP. In
order to understand the requirements thoroughly, CSI shall visit various offices such as
Directorate, Circle Offices, Division Offices, Post Offices including Rural Post Offices.
5. The solution design shall include, but not be limited to, the design of the application, data, and
security and integration architecture
6. CSI shall design a Business Intelligence platform which will provide a dashboard for monitoring
and measuring business metrics. It shall have the capability to generate customized MIS reports
at various levels.
7. CSI shall be responsible for installation and commissioning of the supplied software.
8. CSI shall develop the required client application (s) which will be deployed using SDP (provided
by RSI) for the Rural ICT Devices covering mail operations, finance & accounts, human resource
etc. and build single Point of Sale application(s) for the RICT platform integrating all the client
applications of the CSI along with those provided by RSI and FSI. These shall be rolled out in
approximately 1,30,000 rural Post Offices.
9. CSI shall build a unified customer interaction layer to enable channel access for multiple users,
modes and services.
10. CSI shall build and maintain complete security architecture based on standards as defined in the
Section 6 of Volume I of this RFP.
11. CSI shall build the monitoring infrastructure for ensuring that systems are functioning as per
SLRs defined in the Section 5.5 of Volume I of this RFP.
3.2.4 Implementation Services
1. The project implementation envisages a Pilot approach where the solution will be first
implemented at few chosen pilot locations.
2. Upon meeting the test and acceptance criteria (refer Section 7 of Volume I of this RFP) that have
been agreed upon by the DoP and CSI, the implementation will be taken up at the remaining
locations.
3. Gaps identified during the pilot shall be addressed by making necessary changes to the
applications, before embarking on the rollout in the remaining locations.
4. CSI shall be responsible for the implementation of all the phases scheduled in the project
implementation plan, within the timelines as indicated in Table 10 below.
Table 10: Project Milestones & Timeline
# High Level Deliverables Time for Completion
1. Vendor on board (On completion of contract signing) T
2.
Team mobilization and Project Management Office set up by the
vendor
T + 0.5
3.
Following plans for the proposed solution:
Final implementation plan
Solution design
Training Plan
T + 2
Data Migration Plan
4.
Detailed design documentation* for the following:
System Requirement Specifications
Detailed test plan including Test cases, Test script for assembly
testing, System integration testing, performance testing and user
acceptance testing
Use cases
T + 4
5.
Supply, Installation and commissioning of all central hardware for
common infrastructure solution (Wave 1)
T + 3
6.
Supply, installation/ customization, testing and commissioning of
common infrastructure solution (Wave 1)
T + 5
7. Completion of Wave 1 solution rollout T + 7
8.
Supply, Installation and commissioning of all central hardware for
Wave 2 & 3 solutions
T + 4.5
9.
Wave 2 solutions
T + 7
10.
Completion of training and roll-out for Wave 2 solution for 100 Pilot
locations
T + 9
11.
Completion of training and roll-out for Wave 2 solution for Phase 1
locations
T + 13
12.
Completion of training and roll-out for Wave 2 solution for Phase 2
locations
T + 18
13.
Wave 3 solutions
T + 9
14. Training and roll-out for Wave 3 solution for 100 Pilot locations T + 12
15.
Training and roll-out for Wave 3 solution for final roll-out across 22
circles
T + 18
16. Overall integration and testing of solution T + 13
17.
Supply, installation and commissioning of hardware and software for
DR
T + 15
18. DC / DR Testing for all solutions T + 16
*Software documentation shall be provided as per IEEE standards
Note: Supply of DR hardware and software shall commence after successful roll-out of solutions
comprising of all Waves (1, 2, 3) at the pilot locations.
Waves shall comprise of the following modules:
# Wave Modules
1 Wave 1
Enterprise Service Bus
Email
Directory
Service Desk
Enterprise Monitoring System
2 Wave 2
Customer Interaction Management
Point of Sale
Mail Operation
Mail Booking Engine
Transport Management System
Mailer & Logistics Appointment Scheduling
Labour Scheduling
Sort Program
Logistics Post
Warehouse Management System
Transportation Management System
Finance & Accounts
General Ledger
Requisition & Procurement
Accounts Receivable
Accounts Payable
Asset Accounting
Budgeting
Cash Management
Costing
Internal Audit & Inspection
Human Resources
Personnel Information
Leave Management
Recruitment Management
Performance Management
Establishment Review
Training Administration
Rural ICT Client application for Point of Sale, Mail Operations and
Finance & Accounts
3 Wave 3
Mail Operation
India Post Visibility System
Delivery & Postman Management System
Philately
Finance & Accounts
Payroll
Other Systems
Human Resources
Self Service Portal (Employee, Manager)
Customer Interaction Management
Web Portal
Mobile Channel
Call Centre
Rural ICT Client Applications for Mail Operations
3.2.5 Solution Integration
1. CSI shall be responsible for overall integration of the solution. CSI must unconditionally agree to
work with other system integrators for integration with applications as may be required by the
DoP through the contract period.
2. The interfaces for proposed solution are specified in the functional requirements which are
attached as Annexure 8.3 of Volume I of this RFP.
3. CSI shall be responsible for identifying the detailed interface requirements for integration of
core applications with other solutions being implemented by FSI and RSI as described in the
section 1.4.1 of Volume I of this RFP. Additionally, CSI shall also coordinate with Data Centre
vendor and Network Integrator vendor for ensuring end-to-end integration. If any additional
interfaces are needed besides those specified in the functional requirements, it will be the
responsibility of the CSI to build those interfaces.
4. CSI shall present the interface requirements to the DoP for review and approval.
5. Any suggestions/ requirements desired by DoP shall have to be included by the CSI.
6. CSI shall be responsible for enveloping, testing and maintaining the interfaces. In case of any
subsequent change, modification or alteration to other solutions being implemented by FSI and
RSI, DoP will provide the Application Programming Interface (API) for those solutions to the CSI
for interface.
7. CSI shall be responsible for setting up the integrated test environment for interface testing
including automated testing software and tools.
8. CSI shall prepare the test cases for system and application testing. CSI shall ensure that the test
cases meet all the testing requirements of the DoP.
3.2.6 Data Migration Services
1. CSI shall carry out the exercise of identifying data migration requirements that would be
necessary for effective implementation of the proposed solution.
2. CSI shall be responsible for formulating the data migration strategy and data migration process
documents. The strategy must include the following: plan, approach/ architecture, tools and
technology for migration, data management, operations and roll out, integrity and verification
post migration. It shall also contain a plan to verify if all the data has been correctly migrated.
3. CSI shall set up the migration process and the environment based on the data migration
strategy.
4. CSI shall be responsible for data migration from the source systems to the new environment.
The DoP will not bear any additional cost for data migration, nor will it be responsible for the
same.
5. CSI shall be responsible for collection and migration of master data, including assets such as
vehicles and buildings, employee records and account records.
6. CSI shall be responsible for data entry of Employee Service Books
7. Data shall be provided to the CSI as is basis in the manual / electronic format as available. Any
format change shall have to be done by the CSI.
8. CSI shall be responsible for migration of operational data as required, including financial
transaction data such as ongoing contracts, employee transaction data such as leave and
training applications.
9. Data Migration has to be done for data in manual and electronic/digital format.
10. CSI shall provide the following:
a. A list of source and target applications for migration
b. Data classification as historical, master and transaction data
c. A strategy for extracting the source data for each type, possible rules to be applied for
cleansing the data
d. Data migration approach for the project (e.g. Big bang, parallel run, incremental migration,
zero down time migration) along with justification for the same
e. A strategy to run the old and new applications in parallel or migrate the application over a
cut over to ensure that the present quality of service is not adversely affected during the
migration phase
f. A definition of target data architecture
g. A strategy for reconciling that all the data has moved to the respective target without any
loss of either quality or quantity
11. In the event of any gaps in data migration, CSI shall discuss the same with DoP, document the
findings and get it signed-off from DoP.
12. In the event of any data that cannot be migrated due to various reasons, CSI shall provide
alternate strategy with concurrence from DoP.
13. CSI shall prepare Operational Manual/ Job Cards for operational staff and conduct training for
the PO/ controlling office personnel and/ or any other third party staff like data entry
operators/auditors etc. during the time of data migration.
14. CSI shall provide technical and functional training in relation to data migration to the identified
team of DoP.
15. CSI shall develop the data conversion programs to convert DoPs current data (residing in
systems) to the new format as required by business.
16. CSI shall run mock data migration tests to validate the conversion programs that have been
written.
17. CSI shall be responsible for assisting the DoP or its consultants in conducting the acceptance
testing and in verifying the completeness and accuracy of the data migrated from the source
applications to the target systems.
18. The DoP or its consultants shall validate the results of the acceptance test carried out post-
migration.
19. The DoP reserves the right to audit / appoint an external auditor to audit the process of data
migration and / or the completeness and accuracy of the data migrated during the entire
exercise of data migrations.
20. Any gaps / discrepancy observed during the audit, as mentioned above, shall be reported in
writing to CSI, who will act upon it and resolve the same immediately or within a maximum of 5
working days from the day of reporting the same unless mutually accepted otherwise.
21. Data shall be made available to CSI at various locations (Post Offices, Division Offices, Circle
Offices, PAOs, etc.) for the purpose of digitization and migration.
22. CSI shall develop and share control reports with DoP for verification of the data both before and
after migration.
23. It is clarified that the ownership of data shall at all times remain with the DoP and CSI shall be
responsible to maintain complete confidentiality of the same.
24. CSI shall be responsible for all loss, inaccuracies, and discrepancies in data arising out of data
migration.
25. CSI shall not charge any extra amount in the future for treatment of document once the
financials have been agreed upon.
26. CSI shall provide detailed risk mitigation plan to address any scenario wherein the data migration
may fail and steps that will be taken to ensure there is no impact or disruption in operations for
DoP.
27. CSI shall provide the solution for legacy data archival for all the applications for HR and Finance
& Accounts.
28. Indicative details of the data digitization requirements are given in Table 11 below:
Table 11: Data Digitization Requirements
# Data
Master
Data
Transaction
Data
No of
items
No of entries/ pages
Data
availability
(Digitized or
Paper)
1. Human Resources
1.
Service Book*
(Data Entry)

218,000
records
An estimated
20,000,000 fields will
need to be
populated
Paper
2. Establishment
Review
155,000 775,000 Paper
3. Employee
Records
496,000 Paper
4. HR related
data
6,700,000 Paper
Finance & Accounts
5. Employee
Payroll
Records -
Current
218,000 218,000 Paper
6. Employee
Payroll
Records-
Historical
2,616,000 Paper
7. Budgetary
Approvals
100,000 100,000 Paper
8. Pension
Records
Current
110,000 110,000 Paper
9. Pension
Records -
Historical
110,000 1,320,000 Paper
10. Asset Details 1,000,000 1,000,000 Paper
Mail Operations
11. Sort Programs Paper/Digitized
12. Mail Motor
Schedules
~1500 Paper
13. Product
Pricing Lists
30-35 Digitized
14. Product
offering wise
PIN mapping
Speed Post Digitized
15. Timing of
Shifts for
different RMS
offices
250 Digitized
*Data Entry of Employee Service Book will be in scope of the CSI Vendor. There will be no scanning
of employee service books.
a. Service Books of those employees who are retiring in a 5 year block from the date of
commencement of the project will not be considered for data entry and will not be in scope
b. Service Books are stored at Divisional Offices - 442 in number
c. CSI Vendor will be required to ensure data entry is done from these 442 locations as far as
possible with deviations if any approved by DoP
3.2.7 Training
3.2.7.1 Types of Training
CSI shall be responsible for conducting only the User Champion Training/ Train the Trainer trainings
for the following User Groups in DoP unless specified in the respective area:
3.2.7.1.1 User Champion and End User Training
1. This training is meant for identified user champions and end users in the relevant offices for all
solutions that will be implemented under the scope of this RFP.
2. This user group will comprise of Postal Assistants from Post Offices, Sorting Assistants from Post
Offices and Mail Offices, and personnel from Finance & Accounts, Human Resources, Technology
and others.
3.2.7.1.1.1 User Champion Training
1. Identified User Champions from Mails, F&A, HR and Technology shall be trained in their
respective solutions/areas as applicable.
2. CSI shall be responsible for delivery of training across DoP locations. CSI shall design a curriculum
and get it approved from the DoP for the training on all aspects of application operations
(hardware/software).
3. CSI shall develop training content and provide training to the User Champions in order to
develop them as Trainers for training the end users in subsequent deployment phases.
4. Training components for Mail Operations are:
a. Functional training for Mail solution
b. Customer service training - Counter Staff
c. ECMS & Data migration training
d. Additional training for DoP User Champions on how to train end users
5. Training components for F&A are:
a. Functional training for F&A solution
b. ECMS & Data migration training
c. Additional training for DoP User Champions on how to train end users
6. Training components for HR systems are:
a. Functional training for HR solution
b. ECMS & Data migration training
c. Additional training for DoP User Champions on how to train end users
7. Training components for Logistics Post are:
a. Functional training for Logistics Post solution
c. ECMS & Data migration training
d. Additional training for DoP User Champions on how to train end users
8. Training components for PoS are:
a. Functional training for Point of Sale solution
3.2.7.1.1.2 End User Training
1. For the pilot phase, CSI shall train all target employees under the Pilot Phase for the identified
Post Offices.
2. DoP User Champions (Trained Trainers) will conduct End User training for all other end users.
3. It is estimated that End User training will be conducted in batches comprising of around 25 to 30
persons and would be carried out in a distributed manner so as to reduce the costs of training
without impacting quality of the training.
4. CSI shall propose an approach to meet this requirement keeping in mind the context of the
workforce and its distribution across India.
3.2.7.1.2 Technical Training
CSI shall impart training to the technical team responsible for carrying out technical activities related
to the system like:
System Administration
Server Management
Database Management
Operating System Management
Application Management
Technology Operations Management
User Management
Security Management
Backup & Recovery Operation & management
Service Desk Management
Disaster Recovery Centre Management
Disaster Recovery Operations Management
3.2.7.1.3 Administrator Training
CSI shall impart training to the identified System Administrators for the proposed solution on
activities such as generation of MIS, managing access control, security and data audits, trouble-
shooting, system and application administration and any other needs as may be identified by the CSI
and the DoP.
# Phase
No. of People
(Indicative)
Frequency Minimum no. of Days
1 Phase 1 200 Once 3
2 Phase 2 500 Once 3
3.2.7.1.4 Executive Awareness Training
CSI shall impart training to selected executives to give them an overview of the proposed solution.
# Phase
No. of People
(Indicative)
Frequency Minimum no. of Days
1 Phase 1 30 Once 2
2 Phase 2 30 Once 2
3.2.7.2 Detailed scope of training
1. CSI shall provide detailed training plan and will work in close co-operation with Change
Management (CM) team to finalize the training strategy and schedule.
2. CSI shall provide training for all the products quoted to meet the scope of the RFP to the
identified users by DoP.
3. CSI shall provide a training curriculum consisting of courses pertaining to system operation,
business-wide application, changed business processes and use of the proposed application.
4. CSI shall ensure that the training content is relevant to the target trainees depending upon the
role played by end users.
5. CSI shall incorporate and implement changes suggested by the CM team in delivery and content.
6. The training exercises will list common business scenarios and input data that the user will enter
to practice with the newly developed application.
7. CSI shall create necessary performance support material such as user manual, job aids, online
reference manual, frequently asked questions, training documentation etc. for use in
conjunction with the class room training material.
8. CSI shall provide training material in hard and soft copies to support training delivery. Training
delivery will primarily be class room training (instructor led/ lab based) and shall include hands-
on training for the proposed solutions.
9. CSI shall ensure that a training environment is made available with business relevant data to
conduct the training.
10. CSI shall ensure that the end user training for a particular Post Office is scheduled and
completed at least a week prior to that Post Office going live.
11. CSI shall provide ongoing training at defined intervals to the identified personnel from DoP.
12. CSI shall train a maximum of 30 trainees in one batch.
13. CSI shall evaluate the capability of the user champions to conduct further training for end users.
In case the user champions need more training, CSI shall train them at no extra cost.
14. CSI shall prepare, circulate and collect training feedback forms from the training participants.
The training feedback report shall be reviewed jointly by CSI and CM team.
15. CSI shall develop and provide training modules for the DoP induction training for new joiners in
the future for all solutions that are in scope of implementation. These will be handed over to the
DoP Training team through the CM team.
16. CSI shall ensure capability development for training staff on the solutions at CEPT, PTCs, PSCI and
WCTCs so that they conduct the system and process training on the new applications in the
future.
17. CSI shall conduct most of the training sessions at the Postal Staff College Ghaziabad (for
Managers), and six Postal Training Centres at Saharanpur, Mysore, Madurai, Darbanga,
Guwahati, Vadodara and around 151 Workplace Computer Training Centres across Circles.
18. CSI shall install the required applications / systems, training server at Data Centre for the
purpose of training at the training centres. There will be no cost payable by DoP for the
application, database and operating system software installation at such training sites. The
training hardware at the data centre should be capable to support a minimum of 200 concurrent
users.
19. DoP will be responsible for identifying the appropriate personnel for all the training
requirements
3.2.7.3 Training Programme for Core Users / User Champions
3.2.7.3.1 Human Resources solution
The solution will be rolled out in two phases
All the trainings shall be conducted in the PTCs and field level training centres
The training for Human Resources as indicated in Table 12 will be conducted by CSI
Table 12: Training requirements for Human Resources
# Phase
No. of People
(Indicative)
Frequency
Minimum no.
of Days
1 Phase 1 1,196 Once 5
2 Phase 2 2,320 Once 5
Self Service Portal (Employee/Manager) solution will be rolled out in two phases
The training for End Users as indicated in Table 13 will be done by User Champions
Table 13: Training requirements for Human Resources Self Service Portal Users
# Phase
No. of People
(Indicative)
Frequency
Minimum no.
of Days
1 Phase 1 13,473 Once 2
2 Phase 2 152,000 Once 2
3.2.7.3.2 Finance & Accounts solution
CSI will be responsible for conducting the training for core users as indicated in User Champion
Training in Table 14
User Champions will be responsible for conducting the End User Trainings

Table 14: Training requirements for Finance & Accounts
# Phase
No. of People
(Indicative)
Frequency
Minimum no.
of Days

User Champion Training
1
Phase 1
840 Once 4
2
Phase 2
2565 Once 4

End User Training

Phase 1
6550 Once 4

Phase 2
19650 Once 4
3.2.7.3.3 Mail Operations solution
Mail Operations training will be given to the User Champions identified by DoP along with the
CM team
All End Users as indicated in Table 15 will be trained by User Champions
Table 15: Training requirements for Mail Operations
# Training Area
No. of People
(Indicative)
Frequency
Minimum no.
of Days
1
POS* User Champion
7,678 Once 5
2
POS* Phase 1 End User
12,000 Once 3
3
POS* Phase 2 End User
23,000 Once 3
4
DPMS User Champion
13,000 Once 1
5
DPMS End User
29,623 Once 1
6
IPVS User Champion
2,154 Once 1
7
IPVS End User
10,000 Once 1
8
LSS User Champion
22 Once 2
9
LSS End User
964 Once 2
10
SPS User Champion
22 Once 1
11
SPS End User
79 Once 1
*MLASS shall be part of this training along with the POS
3.2.7.3.4 Logistics Post
User Champion training as indicated in Table 16 shall be conducted by CSI
End User Training shall be conducted by User Champions
Table 16: Training requirements for Logistics Post
# Training Area
No. of People
(Indicative)
Frequency
Minimum no.
of Days
1
Phase 1 WMS User Champion
10 Once 5
2
Phase 1 WMS End User
50 Once 5
3
Phase 2 WMS End User
34 Once 5
4
Phase 1 TMS User Champion
382 Once 2
5
Phase 2 TMS End User
502 Once 2

3.2.7.3.5 Rural ICT Client Application
The CSI will also be required to train users on the POS application in RICT Solution to the resources
identified by DoP. The scope of the training shall include functional training:
Table 17: Training requirements for Rural ICT Client application
# Training Area
No. of People
(Indicative)
Frequency
Minimum no.
of Days
1 RICT Application Training 4000 Once 2

3.2.8 Operations & Maintenance Services
CSI shall abide by the operations and maintenance terms and conditions as mentioned in Section 5
of Volume I of this RFP.
Seating space shall be provided for ~35 persons by DoP within the DoP premises in Delhi. The CSI
shall make provision for leased line connectivity with necessary IT equipments between the seating
location provided by DoP and the CSIs home location / separate development facility. For the rest
of the resources, seating arrangements shall be provided by the CSI at its own location in the
National Capital Region (NCR).
4. Technical Requirements
4.1 Solution Requirements
Table 18: Solution Requirements
# Common Technical Requirements for solution to be provided by CSI
1.
The solution architecture and system must use open standards based, flexible and extensible
integration interfaces between the various components of the solution.
2.
The solution architecture of the system should be multi-tiered and it should have a minimum
of the following tiers: presentation layer, business logic layer and data layers with well defined
interfaces.
3. The solution offered should be Service Oriented Architecture (SOA) compliant.
4.
The solution architecture should be modular, highly granular, loosely coupled and flexible
which should be able to plug-and-play different components based on the business
requirements.
5. The solution architecture should have no single point of failure within and across tiers.
6.
The solution should include load balancing and other performance tuning mechanism for web,
application, and Database tiers.
7. The solution must support an RDBMS based solution.
8. The solution should allow the system to be built for 64 bit operating system.
9. The solution should support application load balancing and Database clustering.
10. The solution should have capability to integrate with 3
rd
party/ legacy applications.
11. The solution should have the ability to maintain log of transactions at all the tiers.
12.
The solution should have the ability to export data output directly in excel, PDF, text, XML,
HTML, etc.
13.
The solution should be able to import data from various formats (such as Text, Excel, CSV,
XML).
14. The solution should support GUI and/or web-based User Interface.
15. The solution should support remote operation of system administration.
16.
The solution should have the ability to restrict data update/deletion/creation only through
application layer.
17. The solution should support real time transaction processing and master data update.
18. The solution should support data import & export to variety of Databases.
19. The solution should be supported on client with any Operating System like windows, Linux.
20. The solution should support TCP/IP, HTTPS, HTTP.
21. The solution should support version control.
22.
The solution should support the leading back-up vendor products to manage automated
Database back-ups and restore.
23. The solution must be able to integrate Database with leading archival technologies.
24.
The solution should provide online documentation, on-line help, field-level help, screen-level
help etc.
25.
The proposed solution should be able to seamlessly integrate with other business systems
such as ECMS, Banking, Insurance etc.
26.
The solution must be able to seamlessly upgrade services, components and modules without
affecting services.
27.
The solution must support low bandwidth and "near-no" bandwidth conditions for the
transactions.
28.
The solution should be highly scalable to support current and future requirements as per the
volumetric data provided in RFP.
29.
The system should support variance upto 20% in peak volumes as they are subjected to
variances such as festivals, seasons, economic state of the country and customers, regulatory
changes, etc. There should be no impact on the system performance during these scenarios.
30.
The solution should be designed in such a way that the availability to the users is not impacted
in any way while carrying out any planned operations such as daily, monthly or annual
closings, system maintenance, backups, data warehousing, data mining, report generation,
MIS generation or while running batch processes.
31.
The system should support all the standards mentioned in the Section 6 of Volume I of this
RFP.
32.
The solution should include the details of various environments required for design, build and
testing. The minimum environments that should be provided are development, testing,
preproduction and production.
33.
CSI must be able to share schema and other logical models/artefacts with other service
providers such as FSI, RSI etc. for any enterprise data requirements.
34.
The solution should be able to integrate with multiple external payment gateways and SMS
gateways.
35. The solution should ensure that Data integrity should not be lost in any scenario.
36.
The solution should have the ability to:
Provide performance statistics for the CPU/ Memory, Database, Application servers
Predict possible system bottlenecks
37. The solution should have tools to assist administration of:
Configuration Management
Performance Tuning
System Diagnostics
Capacity Planning
38.
The solution should have ability to send alerts to system administrator in case of defaults/
failure/ bottlenecks.

Point of Sale Technical Requirements
39. PoS applications should support Hindi and English.
40.
PoS should have capability to provide local inventory status & synchronies with the central
inventory. Information/data available on POS should be encrypted and secure.
41. PoS should have capability to work as a standalone system or in offline mode.
42.
POS should have capability to integrate with 3
rd
party business applications (i.e. Retail) and
with the inventory on central server as per DoP requirements.
43.
PoS should support all the features of Banking, Insurance and Mail Operations as specified in
functional requirements.
44.
PoS should be able to integrate with components such as General Ledger, Finance & Accounts,
etc.
45.
POS should have the capability to connect with external devices such as card reader, camera,
weigh machine and bar code scanner.

Basic Telephony
46. Solution should support TDM/IP/SIP/Video end-points.
47. Solution should be able to connect to trunks of different protocols i.e. ISDN/IP/SIP.
48. Features such as Call transfer, conference, call forwarding etc should be provided.
49. Restriction of features/services based on user (agent) profile should be feasible.
50. Call billing system to track and report outbound calls.

Resiliency & Monitoring (common for entire Call Centre Infrastructure)
51.
Basic Telephony System, ACD, IVR, CTI & CRM solutions should be resilient with seamless
handover to standby server.
52.
System should be able to provide notification in case of any failure of hardware, application,
trunk failure etc on SMS, email, visual notifications.

Scalability & Life of product (common for entire Call Centre Infrastructure)
53.
All components of the Call Centre system (Telephony, CRM, ACD, IVR, CTI, etc) should be
scalable.
54.
Version upgrades or dot releases of various components of the Call Centre system (Telephony,
Application, ACD, IVR, CTI, etc) should be covered in the initial supply.
55. Upgrade of IVR ports in blocks or individual numbers should be feasible.
56. Upgrade in quantity of ACD/CTI license should be feasible.

Call Centre Technical Requirements Interactive Voice Response
57. System should receive all inbound calls on the toll-free telephone number set up by the DoP.
58.
System should identify customer through Calling Line Identification (CLI) and support
intelligent call routing.
59.
System should include speech recognition engine in order to support and interpret multiple
languages.
60. System should support multiple languages for Text-to-speech capability.
61. System should support all the languages specified in the RFP.
62.
System should be easily configurable that enables the users to change the IVR tree without
any hard-coding.
63. System should support messages scheduling.
64.
System should be able to capture usage details of each customer as the customer traverses
through a call.
65.
System should have an interface through which the customer usage details can be shared with
other solutions.
66.
System should integrate with the rest of the proposed solution to provide seamless Call Centre
performance.
67. IVR System should be able to integrate with DoP's existing database servers for call routing.
68.
IVR solution should include capability to provide reports - to generate utilization reports, call
volume on entry points etc.
69.
IVR should support connectivity with telephony system (same or different) at multiple
locations.
70. IVR system should be able to connect to trunks of different protocols i.e. ISDN/IP/SIP.

Call Centre Technical Requirements Automatic Call Distribution (ACD)
71. System should handle high call volumes efficiently.
72. System should support multiple groups for all call types.
73.
System should provide the capability of combining data with the IVR menu system that can
intelligently rout calls requesting further assistance to a smart ACD.
74.
System should provide highly configurable system for adding/removing users, assigning users
to different queues and defining skill sets.
75. System should support intelligent call based routing.
76. System should allow calls to be transferred within and outside the Call Centre.
77.
System should support the relaying of marketing messages to voice callers while waiting in
queues or when on hold.
78.
System should be capable of providing Call Centre reports on agent performance, group
answered calls.
79. System should allow customization of reports as per requirement.
80.
ACD features such as - call barge-in local and remote, work codes & other standard features
should be available.

Call Centre Technical Requirements Computer Telephone Integration (CTI)
81. System should be able to integrate with setup of a Call Centre solution.
82.
Must be able to interface with the key business applications banking, insurance, mail
operations and RICT along with other third party applications to send/receive data.
83. System should have the ability to generate and service requests.
84. The CTI must be capable of activating the fast dialling feature of the ACD.
85.
Call events should be handled from the system such as hold, retrieve hold, conference,
transfer, etc.
86. CTI should be integrated with core Call Centre system and must be able to update the IVR.
87. Should be able to integrate with setup of a Call Centre solution.

Call Centre Technical Requirements Call Centre Application
88. Call Centre application should support ticket with all related data logging and tracking.
89.
It should enable Managers/Supervisors to monitor the overall performance of the Call Centre
agents and interact when needed.
90.
It should interface with other applications to retrieve information that would be required by
the Call Centre agent to perform various tasks.
91.
It should integrate with the CTI and should be able to pull IVR usage details of the customer
including all options selected by the customer and all details entered by customer from the
time the customer reaches an agent.
92. It should allow the agent to log on to the system and track each ticket.
93. Information of the escalated tickets should be made available as and when required

DoP Website Technical Requirements
94.
The solution should support web based access to all business/enterprise applications through
India Post website.
95.
The website should implement consistent look-and-feel and shall be the single platform for
disseminating information
96. The system should not allow concurrent sessions for the same user
97.
The solution should support two modes of access Anonymous and Secure. While general
contents should be freely accessible, some restricted contents should be made accessible to
registered users only.
98.
The system should automatically log out a customer in case of session breakdowns (e.g.,
communication failure, high inactivity period - these should be parameterized)
99.
The website should implement security features, such as password complexity, automatic
blocking (temporary/permanent) of user logins after given number of unsuccessful login
attempts (should be parametrized), controlled access to content stored on the portal and
logging of security incidents.
100.
The website should also conform to the Guidelines for Indian Government Websites which is
available at http://web.guidelines.gov.in and http://egovstandards.gov.in/.
101.
Some of the secure web contents will be accessible through HTTPS protocol on Secure Socket
Layer (SSL) using web browser.
102.
The Usage Analytics services shall provide the interface that manages and creates reports on
website usage. These analytics reports shall provide usage data such as web hits, number of
visits, duration, usage pattern, web errors etc.
103.
Should provide support for comprehensive audit trail features such as:
Daily activities log are merged into the history log files
Date, time and user-stamped transaction checklist are on-line generated for different
transactions
All transaction screens should display system information including Function ID and Name,
Processing Date, Current Time, Current User, etc.
Daily activity reports are provided to highlight all the transactions being processed during
the day
Unsuccessful attempts to log-in to the system should be recorded
All attempts to access/change system data should be system driven
104.
The website should support all leading browsers such as Microsoft Internet Explorer, Firefox,
Chrome etc.
105.
The website should be able to interface with enterprise applications (Banking, Postal
Insurance, Mail Operations etc.) seamlessly through interfaces provided by applications.
106. The web application should be able to support HTML, DHTML, etc. (Markup language).
107.
The solution should support client side scripting/ programming languages like Java scripts, VB
scripts, Java Applets, ActiveX, etc.
108.
During transaction input, fields are automatically validated to ensure the validity and
consistency of data
109. The website should provide search engine with advanced full-text search capabilities
110. The search engine should be able to search for requests within the site.

Packaged Applications (PA) Technical Requirements
111. The solution offered should be uni-code compliant.
112. The solution should have the ability to support multi currency operations.
113.
The solution should have the ability to connect database through ODBC, OLEDB, JDBC and
through native drivers.
114. The solution should have context sensitive help capability.
115.
The solution should ensure that data is entered/captured only once to minimize data
redundancy.
116.
The solution should have the ability to set up business rules and notify exceptions/ alert/
reminders to users.
117. The solution should include rule based data cleansing/ enhancement tool.
118. The solution should support role-based access control and segregation of duty.
119. The solution should allow for fresh login to the application during online data backup.
120. The solution should provide integrated management for all the components.
121.
The solution should be capable of retaining the data structure and format even after
release/upgrades.
122.
The solution should be capable of maintaining data on continuous basis without affecting
system performance.
123.
The solution should have the ability to configure the meta data for field creation, report
generation etc.
124.
The solution should provide concise overview of parameters like configuration changes,
infrastructure usage, performance, required maintenance activities, potential security issues,
status of business flows and diagnostic test results.
125.
The solution should be able to integrate email systems supporting SMTP for notifications &
workflow.
126.
The solution should be capable of generating user friendly reports across all modules, which
shall be meaningful, consolidated and concise, could work as an effective tool for top
executives for decision making.
127.
The solution should have scalability in terms of:
Number of users
Number of workflows supported
Number of organizational entities
Number of transactions
Data Storage

ESB BPM Technical Requirements
128. Solution should be implemented using SOA and must support the ESB design pattern.
129.
ESB should support SOA standards such as XML, XSLT, BPEL, web services standards and
messaging standards.
130.
ESB should support all industry standards interfaces for interoperability between different
systems i.e. Banking, Insurance, Mail etc.
131.
ESB should support the use of WSDL 1.1 to describe service interfaces, with XML schema being
used as the way of representing the format of data used in XML-based message exchanges.
132.
ESB should support the following integration security standards:
Authentication
Authorization
Encryption
Secure Conversation
Non-repudiation
XML Firewalls
Security standards support
WS-Security 1.0
WS-Trust 1.2
WS-Secure Conversations 1.2
WS-Basic Security Profile
133. The solution should support routing to all internal & external systems.
134.
The solution should define a canonical structure wherever possible and support
transformation to/from all available structures.
135.
The solution should have comprehensive auditing capabilities to support any internal or
external audits.
136. The solution should provide configurable logging feature for supporting error handling.
137.
The solution should provide transaction integrity for all transactions including the long running
and distributed transactions.
138. The solution should include feature of service registry for managing all services.
139. The solution should support synchronous & asynchronous service/message integration.
140. The solution should support graphical modelling environment for process flow.
141. The solution should support long running processes.
142. Business process modelling should support process choreography & process orchestration.
143.
Business process management tool should use Business Process Execution language (BPEL)
standard and provide the facility for the following:
Graphical user interfaces for all configuration, installation and operations activities
Interfaces for the configuration of the users and roles that are business-user friendly
Wizard-like assistants and command line actions for power users
Process designer must provide a UDDI and WSDL service browser
Process designer must support Human workflow/ Human tasks
Process designer should provide inbuilt wizards to model connectivity to packaged apps,
JMS, JCA, AQ, File systems and other legacy systems
Process designer should have some built-in integration services like JMS, FTP, Email
services
Process designer should provide wizards to generate common process flow
Process designer must provide support for non-XML to XML translation
The transformation designer must provide auto mapping and debugging support
Process designer must provide out-of-box, inbuilt reports for historical process/activity
analysis
144.
BPM should have the following facilities for data exchange:
Ability for reading data from multiple data sources to compose a message response
Ability to read messages in XML, DTD and XSD formats
Ability for encoding standards: Unicode, EBCDIC, ASCII, DBCS and code pages
Ability to route messages based on that messages content and rules associated with the
message type
Support for persistence of instances or sessions
145.
The solution should be able to support connectivity using protocols like JMS, HTTP/HTTPS,
Secure FTP, FTP, SMTP, LDAP, SOAP etc.
146.
The Business Process layer should provide the following security functions:
Facility for Role-based user access and logging
Facility for industry standard authentication repositories (LDAP)
Configurable time-out threshold for user sessions
Support data encryption for the transmission of login passwords
147.
The business process management interaction layer should support following transaction
management capability:
It should provide several number of transactional interaction patterns
Support for logging the state of a transaction when it changes
Support for both synchronous and asynchronous transactions
148.
High performance and reliability for the information exchange between multiple systems:
Provide for high availability features
Facility for automatic (configurable) crash recovery including configurable fail over and
redundancy
Facility to prioritize requests. The system to allow the developer to configure prioritization
of requests where it makes sense, in the workflow engine, and automatically takes care of
processing in the process layer.
149.
The business process management and integration platform must provide the following
support for Business Activity Monitoring:
Facility to provide real time information of operation
Facility to provide capability to business users to get the ability to build interactive, real-
time dashboards and proactive alerts to monitor their business services and processes.
Facility to support graphical view of operation
Facility to provide capability to business user to monitor their SLA and KPI.
150.
Facility to provide the following security features for deploying Service-Oriented Architectures
across department level applications:
Web Services Security: Ability for policy-driven security and management capabilities to
existing or new Web services.
Policy management: Ability for migration of policy development from development to
testing, and then on to production. Also allows versioning of policies.
Virtualization Support: Ability to virtualize an underlying Web Service, so that clients do
not learn the address details of the Service.

Mail Operations Technical Requirements - Mail Booking
151. The solution must provide a framework to integrate with multiple mail booking vendors.
152. The solution must integrate with barcode scanner and printer.
153.
The solution should support an online booking (e-payment system) for SMBs with mail room
facility.
154. The solution should support data exchange with RFID enabled systems and applications.
155. The system shall have accounts for facilitating bill collection for Business Partners.
156. The solution should have capability to interfaces with India Post business partners.
157. MBE shall integrate with Franking Machine users (including franking software and hardware).
158.
MBE shall integrate with the remotely managed franking system server at the vendor location
(RMFS server).

Mail Operations Technical Requirements - IPVS
159. The IPVS system must integrate with the DPMS system.
160. The IPVS system must support the 2-9-2 item bar code standard.
161. IPVS system must support the Unique Bar Code Format for Individual Articles.
162. IPVS system must support the UPU-standard 29-character receptacle bar code.
163. IPVS system must support the UPU-standard EDI message formats.
164. IPVS system must support the PREDES message formats.
165. IPVS system must support the PRECON message formats.
166. IPVS system must support the CARDIT message formats.
167. IPVS system must support the RESDES message formats.
168. IPVS system must support the RESCON messages formats.
169. IPVS system must support the RESDIT message formats.
170. IPVS system must support the CUSITM message formats.
171. IPVS system must support the CUSRSP message formats.
172. IPVS system must support the Electronic Verification Notes (eVN) message standards.
173. IPVS system must support the CP87 parcel bill formats.
174. IPVS system must support the CP78 verification note formats.
175. IPVS system must support the CN24 Reporting formats.
176. IPVS system must be able to integrate with and provide interfaces for WMS.
177. IPVS system must be able to integrate with and provide interfaces for TMS.
178.
IPVS system must be able to integrate with and provide interfaces for Railway Carrier Services
(RCS).
179.
IPVS system must be able to integrate with and provide interfaces for Air Carrier Services
(ACS).
180. IPVS system must be able to integrate with and provide interfaces for DPMS.
181.
IPVS system must be able to integrate with Delivery Scanning System and Scanner hardware
and software.
182.
IPVS system must be able to integrate with SMS gateway for sending messages and alert
notifications.

Mail Operations Technical Requirements - DPMS
183. DPMS application should be multi-lingual.
184. DPMS should interface with IPVS solution.
185. DPMS should provide scanning capability.
186.
DPMS should provide the capability of taking an image of the signature on a signed delivery
confirmation form.
187.
DPMS solution should provide the capability for the recipient to sign on-screen for e-Proof-of-
Delivery.
188.
DPMS device should transmit data collected when cradled back at the office or when
wirelessly connected.
189. DPMS system should provide support for electronically generated CN24 standard.
190. DPMS system should provide support for electronically generated CN15 standard.
191. DPMS should integrate with the Mail Booking Engine for printing ePost articles.
192. DPMS should support printing of Unique Article Bar Code and Human Readable ID.
193. DPMS should support printing Online or Phone Booked Article Bar Code Labels.
194.
DPMS should be able to generate a Bar Code containing the original unique ID on the printed
MO request.
195.
DPMS should generate a unique bar code as per the format specified compatible with DPMS
(13 character code 2 character for money order product code MO, 9 digits for unique
number generated and last 2 character would be IN).

Data Warehouse Technical Requirements - Architecture
196. The solution should support BLOB and CLOB objects.
197. The solution should provide user-id and password security, roles and groups.
198.
The ETL server should be 'cluster aware' and support load balancing, fail-over and other
cluster facilities.
199. ETL process should be able to run on a 'grid' of computers or servers.
200. ETL processes should be able to run on different machines or processors.
201.
Data pipelining: Different steps of an ETL process should be able to run on different machines
or processors.
202.
It should allow partitioning to determine on which machine or processor the data has to be
processed e.g. product codes.
203. It should provide adequate scalability to handle clients data volumes.
204. ETL Tools should be able to exchange data with Metadata Management Tools.
205.
The ETL tool should be CWM-compliant; it should support the common Warehouse Meta
Model.
206. It should allow for features/options to provide for version control

Data Warehouse Technical Requirements - ETL Functionality
207.
It should allow to read a data source once and load the results into two or more tables
(Splitting data streams/multiple targets).
208.
It should allow for Conditional splitting. This is same as the condition listed above, but in a
conditional way, for example, if revenue is higher then 1000 put the results in table 1 else in
table 2.
209.
It should have union capability and allow putting rows of different tables with the same
structure into one table or dataset.
210. It should have data aggregation and data duplication (making multiple data sets) capabilities.
211. It should allow unloading a table(s) in a temporary store area to lookup/search values
212.
It should support slowly changing dimensions (hm = manually; wizard = wizard; auto = out-of-
the-box).
213. It should have a mature scheduler that supports dependencies.
214.
It should be able to detect errors within the job, and change the route within the process flow
when a specific error arises.
215.
It should allow for a readability to understand the data attribute movement within the ETL
logic/flow.
Data Warehouse Technical Requirements - Ease of Use
216.
The ETL tool should provide a user friendly GUI for creation of transformation jobs and ETL
sequences.
Data Warehouse Technical Requirements - Reusability
217. Components should be reusable and should be able to handle parameters.
218.
It should be able to divide processes into named small pieces of building blocks (modular
programming).
219.
It should have to define variables within in the transformation data flows. The variable should
be able to use either built-in functions to support simple logical , string and arithmetic
operations.
220. The tool should have features to insert comments in the transformation flow.
Data Warehouse Technical Requirements - Real-time
221. It should be capable of deployment with both real-time and batch data integration needs.
222. It should be able to publish an ETL process and/or target attribute as a web service.
Data Warehouse Technical Requirements - Connectivity
223. It should read/write from industry leading RDBMS using native drivers such as ODBC, JDBC etc.
224. It should read/write Flat File data sources.
225. It should read Flat Files through FTP.
226. It should read XML sources.
227. It should have Bulk Loader support.
228. It should support joined tables as source.
229.
There should be functions available to control the quality of the data (e.g. a matching
transformation or an address cleanser)
230. It should have the ability to create transformation to remove duplicates.
231.
It should have options for data profiling, uniqueness of values, maximum, minimum,
distribution of values etc.
Data Warehouse Technical Requirements - Metadata Management
232. It should integrate with the Data Modelling tools (list tools).
233. It should provide a central metadata repository for E&T information.
234. Metadata should be in an open relational database.
235. Metadata Repository should support multiple platforms/databases (list details).
236. It should provide interface to the Metadata repository (view and modify).
237. It should have a complete set of metadata (technical, business and deployment).
238. It should provide built-in reports on metadata.
239. It should provide easy to use metadata interface for browsing.
240. It should comply with the standards Common Warehouse Model ('CWM').
241. It should be allowed to customized/extended the Metadata repository.
MIS & Reporting Technical Requirements - Technical Architecture
242. The solution should provide for a browser based interface.
243. It should be scalable to support 1000 concurrent users.
244.
It should allow for source connectivity with leading RDBMS (Oracle, DB2, Microsoft, Teradata
etc.)
MIS & Reporting Technical Requirements - Reporting Features
245. The system should support ad-hoc reports.
246.
The system should have calculation capabilities (ability to define complex calculations, user
specific calculations, runtime calculations, etc.)
247. The solution should have the ability to develop custom reports.
248.
The solution should be able to create custom objects/ formulas for repeated use in reporting
tool.
249. The solution should provide standard report templates.
250. The solution should be able to prioritize reports while execution.
251. The solution should have the ability of reporting both at unit level and DoP level.
252. The solution should provide MIS dashboards for the senior management.
253.
The solution should have the ability to format (page size, row, columns, fonts, colours, tables
etc.).
254. The solution should have the capability for capture/share commentary.
255. The solution should have column filters/sorts.
256.
The solution should allow for data manipulation (slice & dice data on the fly, pivoting, sorting,
Ranking, rearranging columns, etc.).
257.
The solution should have data mining capability (options/pattern analysis - ability to search
data for patterns that may not be intuitive using one of many techniques).
258.
The solution should have drill-down capabilities (ability to drill down to various levels of a
hierarchy).
259. The solution should have the capability of raising exception alarms (e.g. email notification).
260. The solution should provide for exception reporting (ability to set certain thresholds).
261.
The solution should have exporting capabilities (ability to copy resulting data to other
applications such as Excel, Notes, CSV.).
262.
The solution should have graphing capabilities such as graphing options, interactive graphs,
ease of use, dynamic update.
263. The solution should provide user friendly GUI to allow easy generation of reports.
264. The solution should provide report outputs in RTF, PDF, Excel, CSV formats.
265.
The solution should have integration capabilities e.g. ability to integrate in existing
environments portal.
266. The solution should allow the user to set preferences.
267. The solution should be able to print (What you see is what you get).
268. The solution should support proxy users or delegation.
269. The solution should be able to distribute reports (Push, Pull).
270.
The solution should have the ability to save data for later use or to a local PC/laptop or for
other users to view. It should support offline viewing.
271. The solution should have point and click query generation capability.
272. The solution should be able to sort/filter without re-querying.
273. The solution should have the ability to schedule reports.
274. The solution should have the ability for report bursting.
275. The solution should allow for drag-and-drop formatting
276.
The solution should have web capabilities and same report functions should be available in the
web as in the GUI.
277. It should be able to publish all the reports on DoP portal
278. It should have the capability to provide refresh-only capability to a user group.
279. It should have the capability for row level security.
280. It should have wizards to help with functionality.
281.
It should allow for user management (ability to maintain user groups, ease of user
administration etc.)
282.
It should be able provide monitoring for systems, performance, availability and data growth
etc.
283.
The solution should have the ability to archive reports and use in Enterprise Content
Management System.
284.
The solution should provide for conditional formatting, based on thresholds or data ranges for
any cell in the report.
285.
The solution should provide access to data and report, based on pre defined user
responsibilities.
286. The solution should have the ability to schedule reports to run at periodic intervals.
287. The solution should be able to send reports electronically to other users.
4.2 Hardware Requirements
The minimum specifications given below will be applicable for both Data Centre and Disaster
Recovery hardware. These specifications are minimum and bidder shall provide the additional
hardware if required by their solution to meet the RFP requirements. In case of any SLA breaches
related to hardware performance, bidder shall provide the additional hardware at no extra cost to
DoP.
Table 19: hardware Requirements
Servers
General requirements of servers
1.
Application and data base servers should be based on RISC/EPIC/X86(Intel/AMD) architecture
with industry standard 64-bit Operating System.
2.
All other servers should also be same OS platform OR any other commercially available and
supported OS platform as per software requirements. The form factor for all other servers
must be Blade only, as per the specifications under Minimum specifications for other servers
(web, management etc.) given below
3. Servers offered should be of latest generation and highest clock speed at the time of supply.
4.
The bidder should design the overall solution such that the variety and number of server
models in Data Centre is minimized in order to improve the management of the overall
solution. Virtualization and consolidation technologies would be given preference.
5.
The bidder should provide requisite licenses for all the system software required for the
database servers including, but not limited to, Operating System, Compilers, Multi-Pathing
software, File Systems, Volume Managers, OS hardening and verification tool, pre-built
failover agents for database and application software, and Clustering Software etc. for
unlimited number of instances.
6.
The bidder should propose a set of minimum 2 consoles (Servers or high-end workstations
with 17" TFT screens with minimum resolution of 1024x768 and KBD/Mouse etc) within the
Data Centre for monitoring and managing the servers. Every server should not be provisioned
with monitor, keyboard and mouse individually. It is envisaged that the servers would be
monitored remotely using the Remote Control facility (NOC).

Minimum Specifications for Database and Application Servers: Following specifications are
applicable to database and application servers of core applications such as Mail Operations,
HRMS and Finance and Accounts.
7.
Application and database servers should be RISC/EPIC/ X86 (Intel/AMD) processor based
servers with processor clock speed of 1.6 GHz or above. Servers offered should be supplied
with 64-bit Operating System. Application OEM or CSI should provide minimum 2 client
references which are running proposed application(s) at locations with minimum 1000
locations or minimum 10000 concurrent users on same platform.
8.
CSI must ensure no single point of failure for production environment and necessary
components must be added to the solution accordingly.
9.
All applications shall fail over on to High availability Server in separate partitions. In case of
failure of any Server, it should be possible to dynamically move CPU and Memory resources
from other partitions to the High Availability Partition without re-booting the system or
partition.
10.
Capacity of High Availability Server shall be calculated in a such a way that in case of failure of
any single application, it shall be possible to dynamically allocate same amount of CPU and
Memory resources (as in production) to the HA partition.
11.
The database and application tier for all modules have to be configured on servers which
support partitioning/virtualization technology. The OS disk for each environment must be
mirrored. Required consolidation/virtualization licenses should be proposed for full quoted
configuration for unlimited number of instances.
12.
The proposed server should have ability to use spare processors which would dynamically kick
in when the active processors fail.
13.
Should support a shared architecture wherein CPU and Memory can be shared between the
different partitions, be it virtual partitions or logical partitions.
14.
It is envisaged that both the physical servers should have similar number of partitions and
every partition on one server should be clustered with respective partition on the other
server.
15.
The proposed partitioning mechanism should have flexibility of assigning resources like CPU,
and Memory to a unit level granularity to each individual partition. The server should have
the configured capability to assign dedicated resources to partitions.
16.
Each partition should be populated with minimum 8 number of Gigabit full-duplex Ethernet
ports OR 2 x 10Gigabit ports for LAN connectivity. Each 10G port must be capable of carving
out at least 4 logical NICs with configurable speeds from one physical port. The server should
have the capability to balance the load across multiple port interfaces in active-active mode
and seamless failover without any data corruption or Application/Database crashing.
17.
The servers should have the capability to balance the load across multiple HBA interfaces in
active-active mode and seamless failover without any data corruption or
Application/Database crashing. Also they should have the capability to support storage arrays
of all leading storage vendors including, but not limited to EMC, Hitachi, HP, IBM, Network
Appliance, SUN, etc.
18. Non-production components must be provisioned outside the production servers
19. The servers in cluster must be sized to give 100% load support in case of a failover
20. The average CPU utilization of the environment must not go beyond 65%
21.
Solution should be sized so that it should have headroom of 100% CPU/Memory upgrade in
future. The database server should be vertically scalable while application servers should
scale horizontally
22. The application layer must be spanned over at least two different servers for load balancing

Minimum specification for other servers (web, management etc.)
Following are the specifications of blade servers for other servers:
23.
These should be 64 bit RISC/EPIC/X-86 (Intel/AMD) CPU with clock speed of 1.6 GHz or above
with industry standard 64 bit Operating System.
24.
Each Server must be populated with minimum 2 multi-cores with highest speed and FSB
available in the server family.
25.
Total number of CPUs and RAM size in all servers to be defined by the bidder as per
application sizing and to meet the performance SLAs.
26.
The blade server should have dual redundant 146GB internal disks in mirror mode or option
of boot from SAN.
27.
Virtualization Software License, allowing for hosting multiple Virtual Machines (VMs) on the
server. The virtualization software should allow for migration of VMs from one physical server
to another physical server.
28.
The blade server should be supplied with minimum 4 nos. of GbE or 2 nos. of 10GbE Ethernet
ports.
29. The blade server should be configured with minimum two 4 Gbps FC adapters or SAS ports.
30.
Each blade chassis should be sized so that it should have headroom of minimum 2 server
blades in future.
31. CD ROM Drive per chassis.
32. Management Module.
Blade Chassis Specification
33.
Description Should provide common resources essential for the Blade
Servers like Power, System Management, Cabling, Ethernet
Management and expansion, external Fibre Channel Storage
switching and connectivity & Redundant I/O Path for all fabrics
34. Midplane
Should support passive or active midplane architecture
35.
Blade Bays
Blade Chassis to accommodate minimum of 8 Full Height Hot
Plug-gable Blade Servers
36.
Ethernet Switch Modules
Redundant Gigabit Ethernet/10GigE Pass-through modules for
each blade server
37.
I/O Path for all Fabrics Chassis should have dual I/O connections from every blade
server to help provide maximum uptime
38.
Fibre Channel Switch
Module
Should have redundant 8 GB fibre channel ports for each blade
server and Redundant hot-swap 8GB Fibre Channel SAN Switch
Modules with no single point of failure
39.
Management Modules Hot swappable management module to communicate with the
system management processor on the Blade Servers from
remote locations
40.
Total No. of Switch/Bridge
Module Slots
8 or above hot-swappable modules
41.
Blower Modules Should have redundant and hot swappable blower or fan
modules
42.
Power Modules
Dual Power Supply to cater power for the blade servers
(redundant). No single point of failure for Power Delivery. No
single fault should take down the entire power bus. Should
have N+N power topologies for higher uptime
43.
Redundancy in Power
Modules
Chassis should have redundant fans and the power supplies and
should be able to provide reconfiguration of fans and power
supplies without manual intervention
44. Form Factor up to 10U - 19" Rack mountable with 28" depth
45.
CD/Diskette/USB CD-ROM/DVD-ROM Drive which can be sheared among all the
blade servers. The chassis should have minimum Two USB 2.0
ports.
46.
Failure Support
Pre-Failure or Post-Failure support for Blades, bridge/switch
modules, I/O modules, management modules, power modules,
blower/fan modules, media tray.
47.
Diagnostics Should support diagnostic features for Blade server, processor,
memory, power supplies, blowers, switch module,
management module
48.
System Management Should provide support for remote console management,
power on/off blades, should monitor power status, operating
system, temperature, disks, blowers/fans, power Modules,
system diagnostic programs provided through the Management
Software
49.
System Panel LED/LCD panel to provide power-on, location, over
temperature, information and system error conditions
50.
Support for heterogeneous
Servers
The chassis should be able to support a mix of Blade Servers
RISC/EPIC/X-86(Intel/AMD)architecture processors
Storage
Minimum specification for Storage Array
51.
The storage array should be supplied with 250 TB usable capacity in a single array and
expandable to 1024 TB in future by addition of only racks, disks and disk enclosures.
52.
The storage should be a Monolithic Storage System(s) and shall support no single point of
failure features, such as Non- disruptive component replacement and hot-replacement of
Interfaces, Disk controllers, Disk drives, Cache memory cards, Micro-code, Power supplies,
Battery systems, Fan subsystems, FC controller and ports, etc. There shall be no significant
performance degradation due to any single failure in the enterprise storage.
53.
Storage-array should be top of the line product with all in-built redundancies to provide No
Data Transaction Loss because of any subsystem/component failure. Furthermore the
storage system should be tried and tested model in production environment for minimum of
six months at the time of submission of RFP.
54.
Storage-array should support zero data loss after committing the write operation to the
application.
55.
The Storage Array should be configured with minimum 256 GB of Cache GB. Additional Cache,
if required based on the proposed solution should be supplied and configured accordingly
56.
Storage system should be configured with at least 32 Backend FC or SAS Disk ports (towards
disks) and at least 32 front end FC/SAS ports (towards FC switch) scalable to 64. Each front-
end port in the storage array should have dedicated processor or cores for delivering high
throughput and I/O performance.
57.
The Storage Array configuration should be sized to deliver minimum 50000 SPC- 1 IOPS at an
average response time of 2ms or less. CSI should also specify the SPC-1 IOPS per disk that can
be achieved with the Storage Array. The Storage Array bandwidth should be at least 3GBps
rated as per SPC-2 benchmark. Performance numbers if not available or published need to be
certified by manufacturer's parent company lab along with detailed lab test report. Storage
should be minimum sized for asked performance workload or as per proposed solution
requirement (whichever is higher)
58. The storage array should support flash/solid state disks.
59.
The array should support automated storage tiering and movement of data within different
tiers of storage namely SSD, FC/SAS and SATA disks without requiring user intervention,
depending on the frequency or pattern of the accessed data.
60.
Storage should be able to work in a heterogeneous environment which may include multi-
vendor storages such as Sun, IBM, HP, EMC, Hitachi etc.
61.
Storage system should be configured with LUN masking software and license for all LUNs
created on the storage system.
62.
The storage array should support native front end connectivity options such as Fibre Channel,
FICON. The array should also support Gig-E for remote replication.
63. The storage should have separate dedicated data signal path and control signal path.
64.
The storage array should be supplied with Thin Provisioning / Virtual Provisioning. Requisite
software licenses should be provided with the storage system for the entire proposed
capacity.
65.
The Supplied array should support features like Cloning and Array based remote replication.
The array should be supplied with license of the mentioned software for the entire capacity
configured.
66.
Storage System should support at least RAID 5/6 and RAID 1/0.Mix and match of disks types &
RAID levels shall be supported.
67.
The enterprise storage arrays should be configured with latest disks with data storage in RAID
levels mentioned below
Minimum 10% of usable capacity shall be on Solid State Disks in RAID 5
Minimum 50% on FC/SAS disks in RAID 1/O
Minimum 40% on SATA disks in RAID 6
The usable capacity is defined as the Net storage capacity available for the application stack,
after deducting the penalties imposed by storage infrastructure requirements, disk and array
formatting, RAID penalties, host OS and file system formatting including overheads for
directory structure and inodes etc or any other penalties which eat away usable disk space.
The disks should be enterprise class disks built for 24 x 7 operations.
68.
Storage Array should support both Spanning and Striping of volume across minimum of 32
channels in active- active configuration.
69.
The storage should support authentication security control, by user and role in order to avoid
unauthorized service actions.
70.
The storage array should support latest versions of operating systems like Linux (RHEL and
SUSE), Windows, Unix (AIX / HPUX / Solaris etc.).The storage system should offer exhaustive
support for all industry leading cluster systems.
71.
The data in cache shall not be lost in case of power failure even in extended power outages. In
the event of power failure, data for total cache supported by the storage array should be
safely written to the disks and system shall perform a graceful shutdown.
72.
The storage system should have proactive maintenance like self monitoring, self-diagnosing
and wherever possible, self-repairing features.
73. The array should support capability to replicate data to a remote site using storage controllers
74.
Suitable rack enclosures from the array manufacturer need to be included for the complete
storage solution.
75.
The storage system should be configured with GUI-based storage management software tools
for management. A single command console should be used for the entire storage system for
all functionalities like SAN & Storage configuration and management, performance
monitoring and reporting analyze performance data, generate customized reports. The
software applied should be capable of monitoring 3rd party storage arrays in a heterogeneous
environment as well.
76.
The CSI should quote all the applicable set of management licenses for the offered SAN and
Storage for the entire capacity configured.
Minimum Specification of SAN Switches
77.
SAN switch should be of director class with 128 ports populated and active. Should have non-
blocking architecture and scalable to 256 ports in a single domain with 8Gbps full duplex with
no over subscription with local switching. Two nos. of Fibber channel switch should be
provided in high availability mode.
78.
Should support 4 GB FC ports and also support 1Gig and 10 Gig Ethernet ports for remote
replication in future.
79.
Switch should support multiprotocol architecture such as FC, FICON, FCIP and emerging
protocol such as Converged Enhanced Ethernet (CEE) and Fibre Channel over Ethernet (FCoE).
80.
SAN Switch should have equal performance from any port to any port on the director for
consistent performance.
81. All the ports should operate at 8Gbps and auto-negotiate to 4Gbps/2Gbps / 1Gbps FC speeds.
82.
All the components should be hot swappable field replaceable units allowing non disruptive
maintenance
83.
There should not be any single point of failure in the switch. The SAN switch should provide
Enterprise-class availability features such as Dual-redundant control processors, redundant
hot-swappable power and cooling subsystems. Power supply and fan assembly should have
different FRU.
84.
The switch shall support different port types such as U_Port, FL_Port, F_Port, E_Port, and
EX_Port.
85. Non disruptive Microcode/ firmware Upgrades and hot code activation.
86.
It should be possible to isolate the high bandwidth data flows traffic to specific ISLs/trunks by
simply using Zoning.
87.
Switch should support Virtual Fabrics feature that enables partitioning of a physical SAN into
logical fabrics and isolation by application, business group, customer, or traffic type.
88.
Cascading of two SAN switches should be possible from any port in any module across the
Director
89.
Switch should provide advanced zoning capabilities and allow health and performance
monitoring capabilities. Support for web-based management and should also support CLI.
90.
Should have proactive fault detection and alerting capability to avoid any hot-spots in the
fabric.
91. The switch should be rack mountable.
92.
Provide Adaptive Networking services such as Quality of Service (QoS) to help optimize
application performance in consolidated, virtual environments. It should be possible to define
high, medium and low priority QOS zones to expedite high-priority traffic.
93.
It should be possible to configure any port in the switch for Fibre Channel Integrated Routing
mode for selective device sharing while maintaining remote fabric isolation or higher levels of
scalability and fault isolation.
94.
It should be possible to configure the switches with alerts based on threshold values for
temperature, fan status, Power supply status, port status.
95.
Switch should support diagnostics features such as port mirroring (SPANport), Syslog, Online
system health, Port-level statistics etc.
96.
Introduction of application blades/storage service cards should not impact the port
throughput or total available ports in the remaining slots of the switch chassis.
97. Throughput of the each switch should be 1024 Gbps or more
98. Should provide 15M LC-LC cables for all the ports.
Minimum Requirements of FC IP routers
99.
At least two routers should be provided at each location. The design should support failover
using redundant configurations, ensuring that in case one of the routers is down, the traffic
can flow through the other router. Actual requirement would be as per the bandwidth
requirement of WAN link to storage infrastructure. In case additional routers are required
based on the requirement of bandwidth sizing for asynchronous storage based remote
replication over IP; the same should have to be proposed additionally.
100.
The proposed FCIP router could be standalone or as part of proposed SAN Switch as a
separate module within the SAN Switch
Tape Library
101. The tape library shall be used for storing backup and the aged data as per the policy of DOP
102.
The Tape Library Unit shall be configured with fibre based Tape Drives, and shall be quoted
with the requisite number of drives and slots as per the dimensioning parameters given in this
document.
103.
It should be possible to take the tapes out of the library without losing their contents so that
monthly/quarterly backup copies may be preserved outside the tape library.
104.
The Tape Library Unit should be configured with fibre based Tape drives, having the following
specifications and features.
105.
The Tape drives should have capacity of at least 1600GB / 3200GB (uncompressed
/compressed)
106.
The Tape Library should be quoted with the requisite no. of slots as per the dimensioning
parameters given in this document for each data centre.
107.
Each of these Tape Libraries must be supplied with minimum 12 drivers and should be
scalable upto minimum 40 drives and at least 3000 slots. Scalability of the number of drives
and slots can be delivered through multiple tape libraries.
108.
The Tape library should be capable to allow addition of slots, add or remove tape drives and
updates of the librarys microcode without scheduled downtime. There should be dual path
for each drive in the library in failover and load balance mode. In case of a path failure, data
should be able to transfer through alternate path.
109.
The tape library should be configured with at least one robot per tape library to address all
the slots in a redundant configuration
Tape Library Specifications
110. Data cartridge capacity 1600 GB / 3200 GB (uncompressed /compressed)
111. Library connectivity 4 Gbps or higher fibre channel
112. Number of drives At least 12 drives
113. I/O slots At least 16 I/O slots
114. Tape Cartridge slots At least 280
115. Virtualization Support for at least 12 logical drives
116. Management Remote, Web browser-based management
117. High Availability Dual Power Supply, Data path failover and load balancing

Disaster Recovery Requirements
The following are minimum requirements and bidder shall propose the solution which is
required to meet the following RTO and RPO requirement as per SLA mentioned in Volume I:
118.
The bidder shall commence supply of DR hardware and software only after successful go-live
of pilot phase or as agreed with DoP.
119.
The hardware and software supply at DR should be equivalent to primary Data Centre
however, vendors shall highlight the areas (especially in software license) if duplicate
component is not required at DR. The entire environment at disaster recovery should be
maintained as a full working copy of primary data centre.
120.
CSI should supply necessary replication software and disaster recovery management software
for replication between DC and DR
121.
Proposed storage system should be capable of doing data replication between similar storage
systems in synchronous or asynchronous mode. Storage system should be capable of
supporting 3-Stage DR if required in future.
122.
Replication software should support data consistency at the respective DR in all eventualities
like link failures, controller failures etc. The method for data consistency should be clearly
explained in the bid.
123.
The hosts connecting to the storage arrays with 2 or more HBAs shall be configured with
specific software for HBA load balancing, multi-pathing and auto failover.
124.
This software should allow multiple path I/O capabilities from the Host and also have the
ability to automatically detect and recover failed paths.
125. It should provide dynamic load balancing and automatic path failover capabilities.
126.
The HBA load balancing and redundancy software should be supplied for the maximum
number of hosts supported in the Storage Array and should also be configured to support the
maximum LUNS supported in the Storage array as a one time configuration.
4.3 Security Requirement
India Post 2012 initiative of DoP will require a robust and resilient information security system to
protect critical digital assets of the organization. With the increase of security incidents against
information technology, the need to develop an Information Security Management System to ensure
the security of the critical digital information has become imperative. An integrated approach in
which security is designed into the management process will help DoP keep its IT environment
robust and ready to handle all security and technology challenges to its Information Technology
deployments.
Following security requirements will define the guiding principle for security architecture which will
be deployed to deliver DoPs functional requirements as described in this RFP. To achieve the
security goals for solution, DoPs aims to deploy a multi-layered detailed security system covering
the overall solution needs.
Table 20: Security Requirements
# Specifications
1. Overall Solution requirement:
1.1.
CSI must ensure that the proposed Security architecture is based on industry best
practices and adheres to the security standards such as ISO 27001, Information security
standards framework and guidelines standards under eGovernance standards
(http://egovstandards.gov.in), Information Security guidelines as published by Data
Security Council of India (DSCI) and shall comply with IT (Amendment) Act 2008.
1.2.
To achieve the security goals for solution, DoP aims to deploy a multi-layered detailed
security system covering the overall solution needs. Following security solutions are not
part of this RFP, however, CSI is required to propose complete security architecture
required for their solution after considering the following solution:
Two layers of Firewall in HA
Network IPS
Fraud Management System for Banking
CSI must ensure that the security solution provided must integrate with the overall
security architecture and solutions of DoP.
1.3.
To maintain confidentiality, integrity and appropriate access to information, CSI must
ensure and incorporate all necessary security and control features for the following:
Databases
Networks (web security etc.)
Operating System
Any other solutions as proposed by the CSI
1.4.
It will be the responsibility of the CSI to work closely with the other System Integrators
such as FSI, Network Integrator, Data Centre etc. to ensure that the solution provided
gets integrated with the overall DoP technology architecture including information
security architecture and with the solutions mentioned under each section.
1.5.
CSI must ensure complete information security of the solution provided, and must
ensure that any other solution required besides those mentioned under Security
Requirements (Section 4.3 of Volume I of this RFP) must be considered as part of the SIs
solution
1.6.
Monitoring & Audit: Compliance with security best practices may be monitored by
periodic Information Security audits / assessments performed by or on behalf of the
DoP. The periodicity of these audits / assessments will be decided at the discretion of
the DoP. These audits / assessments may include, but are not limited to, a review of:
access and authorization procedures, physical security controls, backup and recovery
procedures, and program change controls. To the extent that the DoP deems it
necessary to carry out a program of inspection and audit / assessment to safeguard
against threats and hazards to the confidentiality, integrity, and availability of data, the
CSI shall provide the DoPs representatives access to its facilities, installations, technical
resources, operations, documentation, records, databases and personnel. The CSI must
provide DoP access to various monitoring and performance measurement systems (both
manual and automated). DoP has the right to get the monitoring and performance
measurement systems (both manual and automated) audited / assessed without prior
approval / notice to the CSI.
1.7.
Security Architecture Guidelines
As part of the overall India Post 2012 initiative, DoP aims to deploy a multi-layered
security system to protect critical digital assets of the organization.
To address security at web and delivery channels like Advance Financial Systems (AFS),
CSI needs to follow the below-mentioned architecture guidelines:
1.7.1.
The solution should be based on well known/popular Open Standards with no single
point of failure to facilitate seamless integration with surrounding systems, applications
and delivery channels etc.
1.7.2.
Data pertaining to enrolment process, transaction process as well as the data that is
stored at various points needs to be appropriately secured as per minimum standard
128 Bit AES/3DES encryption.
1.7.3.
The proposed solution architecture should be compliant with security regulations /
standards / guidelines issued by Government of India
2.
Application Security requirements of the proposed application(s)
The CSI must adhere to the following application security requirements while proposing
the solution.
2.1. Access/authentication
2.1.1.
The proposed solution must have capabilities to define user profiles (Capabilities/
Rights).
2.1.2.
The proposed solution needs to facilitate creation of the user IDs at a central level /
distributed level as desired by the DoP.
2.1.3.
The proposed solution must have capabilities to attach the user ID to each and every
action done by the user in the system.
2.1.4.
The proposed solution must have capabilities to check for duplicate record based on
criteria such as user name (first + last name) etc.
2.1.5.
The proposed solution shall be compatible with external two-factor authentication
systems, which DoP may decide to deploy later.
2.1.6.
The proposed solution should support creation of temporary user ID's and access rights
based on number of days, months restrictions or time based restrictions (minutes,
hours).
2.2. Password Requirement
2.2.1. The proposed solution should set a default password upon creation of the user ID.
2.2.2.
The proposed solution should allow the DoP to define password policies. The minimum
password policies to be defined are:
Minimum/ Maximum password length
Alpha numeric combination of password
Compulsory use of special characters
Minimum password age
Password expiry period
Repeat passwords etc.
2.2.3.
The proposed solution should be able to automatically check the passwords with the
password policy, which can be customized by the DoP.
2.2.4.
The proposed solution should enforce changing of the default password set by the
system (at the time of creation of user ID) when the user first logs on to the system. The
proposed solution should enforce all password policies as defined at the time of first
change and thereafter.
2.2.5.
The proposed solution should store User ID's and passwords in an encrypted format with
passwords encrypted using minimum MD5 hash algorithm.
2.2.6.
The proposed solution needs to define overrides for certain set of transaction errors /
warnings and link transactions to specific user IDs. All such overrides should be recorded
for Audit trail.
2.3. User Group Creation
2.3.1.
The proposed solution should be able to form user groups and link rights to such defined
groups.
2.3.2.
The proposed solutions should be able to restrict user access to:
Menus
Sub- menus
Screens
Fields
Reports
Combination of the above
2.3.3.
The proposed solution should perform all restrictions & accesses at the Central level
only. Solution must have a mechanism to enforce such restrictions & access when the
proposed systems are accessed in off-line mode.
2.3.4.
The proposed solution should have all restrictions to be placed within the application
with the help of menu driven options.
2.3.5.
The proposed solution needs to define levels of authorisation, based on user
profile/access level granted. For any sensitive data access / transaction or the privilege
use access, the solution should ensure minimum two levels of authorization.
2.4.
Data in Transit
The proposed solution should be capable of encrypting the password / other sensitive
data during data transmission.
2.5.
Audit logging:
The proposed solution should be able to generate audit trails of all transactions. The
minimum fields that should be captured in the audit trail are:
Date & time stamp
Transaction ID linked to every transaction / activity. Transaction ID has to be unique
and should not be duplicated. Further the transaction ID should be generated
whether the transaction is successful, unsuccessful / rejected.
User ID
Authorised By
Overridden By
2.6.
The proposed solution should allow users to define error messages (parameterisable) for
a particular transaction.
2.7. Access restriction to critical accounts
2.7.1.
The proposed solutions must have capabilities to restrict access to critical accounts /
information to a particular user ID / or a group of user IDs.
2.7.2.
The proposed solutions should not allow any changes to be made to the details of the
transaction after authorization.
2.8.
The proposed solutions should not permit the same individual to modify and authorize
the same transaction.
2.9.
The proposed solution should only allow authorized personnel to change global
parameters.
2.10.
The proposed solution should define Maximum Inactive Time (parameterisable) after
which a user should be automatically logged out of the system.
2.11.
The proposed solution should have the capability to suspend or cancel an inactive user
ID after a defined time frame.
2.12. The proposed solution should have the capability to reactivate suspended user Ids.
2.13.
The proposed solution must have the provision to assign a user ID with highest access
level for querying with no financial transaction authority.
2.14.
The proposed solution should support tracking of all system administration activities
within appropriate system log.
2.15.
The proposed solution should report active users in the system on different parameters
such as location wise, group wise etc.
2.16.
The proposed solution should have Log report of users logging in & out of the system
throughout a period of time.
2.17.
The proposed solution needs to support validation of user ID and password with
customized dictionary for rejections.
2.18.
The proposed solution needs to support defining separate menu options with view /
query options for auditors, non-operational staff.
2.19.
The proposed solution needs to support geographic region wise, branch wise, and
account type wise, transaction type wise facility for fixation of counter/single window
limits.
2.20.
The proposed solution should support monitoring from a remote place (Data
Centre/SOC) on the activities performed by users in various locations.
2.21.
The proposed solution should parameterise different business hours, working hours,
weekly offs, holidays etc. for different locations.
2.22.
The proposed solution should track the changes made in parameter files along with
detailed audit trail.
2.23.
Reports: The proposed solution should generate reports for login access, staff with
multiple level accesses; functionality based access; use Ids disabled, suspended,
cancelled users.
3. End Point Security Solution
3.1.
In order to prevent DoPs network against the threat of viruses, worms, SPAMS, DoP
plans to implement a comprehensive Anti-Virus software solution which shall provide
continuous protection against these threats across all infrastructure layers of network
including desktops, gateways i.e. emails and internet /Web. It will be the responsibility
of the CSI to maintain the overall solution and report the endpoint upgrade/update
status and any failures. CSI must work with different solution providers across multiple
circles for deployment of the agents on the respective end-points.
3.2.
The proposed solution should be able to block devices based on Windows Class ID and
should include USB, Infrared, Bluetooth, Serial, Parallel, fire wire, SCSI and PCMCIA.
Solution should also be able to block and give read/write/execute permission for
mentioned devices.
3.3.
Proposed solution should be able to deploy flexible and different security policies
depending upon the AND/OR relationship of following network triggers e.g. IP address
(range or mask) , - DNS Server , DHCP Server , WINS Server , Gateway Address , TMP
Token Exists (hardware token) , DNS Name Resolves to IP, Policy Manager Connected,
Network Connection (wireless, VPN, Ethernet, dialup).
3.4.
Proposed Anti Spyware solution should be able to bypass Windows File System and
should have Direct Access to NTFS Volume to provide raw Disk Scan for superior Root Kit
protection.
3.5.
Antivirus and Antispyware policy can have options by default to choose High Security
and High performance to have a right balance while deployment in the production
network.
3.6.
The Host-based, self-enforcement - It should use a desktop firewall (built into the agent)
to permit or deny managed endpoints access to the network. This method should offer
the fastest and easiest implementation as it requires: No infrastructure changes and no
additional deployment efforts.
3.7.
System Lock Down - it should be able to Lock down the system by fingerprinting every
executable file on the system. It can then monitor all running applications and terminate
any application for which the agent does not have a matching fingerprint ensuring
application based control.
3.8.
If the host is non-compliant with security policies, Agent can automatically initiate a
restoration action, which can include running command line, downloading and
executing/inserting a file, running scripts, remediating by setting required registries keys,
rechecking the host for compliance, and ultimately granting access for the compliant
host to the network.
3.9.
Solution should have a readymade template able to check & enforce if Microsoft
service/WSUS/SMS is installed, running, install waiting packages, checked for new
packages in defined duration.
4. Anti Virus and Anti SPAM solution for email messaging should include
4.1.
Proposed Antivirus, Anti SPAM solution should be for the SMTP gateway and as well as
for the messaging servers (Messaging servers as proposed by the bidder). This
protection should include content filtering.
4.2. The proposed solution should be able to filter for viruses and SPAMs for SMTP traffic.
4.3.
The proposed solution should have signature technology that eliminates randomization
and HTML-based filter evasion techniques.
4.4. The proposed solution should provide anti-Spam capabilities against multiple languages
5. AntiVirus and URL filtering Web Gateway solutions should include
5.1.
The solution must protect DoPs against latest web threats, including malicious URLs,
spyware, botnets, viruses, and other types of malware, and provide controls for web and
application use.
5.2.
The solution should have flexible deployment options including port SPAN / in line / in
line with proxy etc.
5.3.
The solution must provide multi-layer Inspection including network packets, URLs/IPs,
files, active content, applications, behaviour, all ports and protocols (both inbound and
outbound).
5.4.
The solution must provide multi Layer Malware protection including Malware web
domains (http), Malware IP domains (anything over IP), Content Filter Malware
categories (Malware, Phishing, etc.), Malware Content Scanning, Malware Scan ,
Detection of Compromised endpoints , Infected Client Detection - Network
Fingerprinting, Botnet Detection - Behavioural Modelling.
5.5.
Application Control The solution must Inspects all internet bound traffic for popular
web applications - Signature Based, and should not be reliant only on ports.
5.6.
Protocol Support - Should provide fast protection at the gateway across multiple
protocols for inbound and outbound web traffic.
5.7. Performance - The solution should offer zero latency (less than 2ms).
5.8.
Botnet Defence The solution should have in-built intelligence & co-relation capability
to inspect for, detect, and block active and dormant botnet activities with in the network
endpoints.
5.9.
Application Control - The solution should have advanced application control capabilities
with ability to monitor and control usage by end-users spanning multiple applications.
5.10.
Internet Application Blocking - The administrator should have feature to prevent peer-
to-peer sharing, streaming media, games, and other Internet applications from accessing
the Internet.
6. Security Information & Event Management System (SIEM) Requirement -
6.1.
Security Management in DoPs network is very critical as various security devices and
servers will generate thousands of security logs which need to be analysed and
correlated. Hence, there should be a mechanism to monitor, correlate and notify
Security incidents in the DoP network to remediate them immediately. Along with this,
the solution should provide a mechanism for comparison with best practices such as ISO
270001.
6.2.
The solution should have the capability of collecting the log in real time and storing it in
raw format with no further modifications done on the logs.
6.3. Log Analysis & Storage:
6.3.1.
The SIEM solution must integrate with all the server operating systems, network and
security devices and allow one single global view of all the collector devices and sites
across DOP infrastructure.
6.3.2.
The log generated should be stored in a centralized storage. The period up-to which the
data must be available should be customizable. There must be archival facility through
which the old log data can be pushed to an external device like SAN, NAS, DAS.
6.4.
Log Monitoring: The solution must facilitate monitoring and review of the log data and
should have automated analysis facility. Log monitoring feature should have facility to
generate reports. Facility must be there for management of the log server(s) and clients.
The software must have user management facility with privileges restricting access to
limited resources. Alert facility must generate automatic alert notification based on
specific events.
6.4.1.
The solution must aggregate, normalize, correlate and analyze event log data from the
multiple devices within DoPs infrastructure. It must collect all the data sent from the
device, compress and encrypt log data on the centralized storage.
6.4.2.
The system should have the correlation capability. The system should be updated with
new correlation rules based on new identified attack patterns and threats.
6.4.3.
Log management infrastructure should perform several functions that assist in storage,
analysis and disposal of log data. These functions should function in such a way that the
original logs should not be altered. The log management infrastructure should have the
following functionalities:
6.4.3.1. General
6.4.3.1.1.
Log Parsing The solution must ensure that any Log parsing activities should not alter
the raw log in any format.
6.4.3.1.2.
The solution must provide a mechanism wherein Logs may be normalized and
reformatted for reporting and correlation.
6.4.3.1.3. Event aggregation should preferably happen at the time of co-relation.
6.4.3.2. Storage
6.4.3.2.1.
The logs should be encrypted when stored and solution must provide a mechanism for
integrity checks.
6.4.3.2.2.
The proposed solution must provide Log archival facility which allows retaining of logs
for extended period.
6.4.3.2.3.
The solution must provide support for defining different retention periods for different
devices.
6.4.3.2.4. The SIEM solution should be capable of integrating with a GRC solution.
6.4.3.2.5. The solution should support SAN, NAS and DAS for external storage.
6.4.3.2.6.
The solution must provide target device notification if target device is down or no longer
sending/receiving events.
6.4.4.
The proposed solution should have the capability to provide detailed analysis of security
incidents occurred and recorded by the solution.
6.4.5.
The bidder must provide appropriate storage based on complete requirement of
monitoring.
6.4.6.
The solution must provide correlation support correlation support but not limited to -
Rule Based, Behaviour Based, Vulnerability based, User defined, Baseline based.
6.4.7. Reporting
6.4.7.1.
The system should have out-of-the-box reports for supported devices and compliance
standards for the supported devices. The reports should include standard security
analysis reports and graphs. Any newer reports published by the vendor should be made
available for use at no extra license, it is expected that newer reports published are
provided on a monthly basis for use within DoP.
6.4.7.2. The reports should be available in minimum PDF and CSV format.
6.4.7.3.
The system should have the capability to Schedule Reports using emails on daily, weekly
and monthly basis.
6.4.7.4. Scheduled reports should be available for viewing if desired in future.
6.4.7.5.
The solution should provide a process for creating ad-hoc log queries. This process
should use standard syntax such as wildcards and regular expressions and It should
provide mechanism to allow saving queries.
6.4.7.6.
Any reports that are available out-of-the-box or any customization performed on
existing reports should not require any separate licensing.
7. Identity and Access Management System
7.1. Scope of the solution will cover the following Scope
7.1.1.
Comprehensive and Integrated Identity and Access
Management Solution for Identity Management, Web
Access Management, Web SSO, Enterprise Single Sign-
On
Identity and Access
Management for all Internal
users, Web SSO and Web
Access Management for
external as well as Internal
users
Comprehensive Identity Management, Provisioning,
and Password Management Solution
For all Internal users
Comprehensive Web Access Management and Web
Application Single Sign-On Solution
For all Internal as well as
external users
Comprehensive Single Sign-On solution to access Web,
enterprise and legacy applications
For all Internal users
Comprehensive LDAP v3 directory with X.500
distribution and replication services to deliver a
backbone of servers that have the capacity to scale to
hundreds of millions of entries, to store all identity
information and associated resources.
User store for all Internal as
well as external users
7.2. Functional Requirements for the Identity and Access Management Solution
7.2.1.
The Identity and Access Management solution should consist of Identity Management,
Provisioning, Password Management, Web Access Management, Web SSO, and Single
Sign-On for thick client applications and Server Access Control must provide out-of-the-
box integration among the various sub components.
7.2.2.
The bidder must provide reference able case studies for Web Access Management
Solution for millions of user deployments (minimum one case study to be submitted).
7.2.3.
The solution must provide out-of-the-box Universal Single Sign-On across Web and
Client Server applications.
7.2.4.
The proposed Identity and Access Management solution must also integrate with
applications for Mail operations, Logistics post, e-Commerce, Postal banking operations,
postal life insurance, Human Resources and notification systems like e-Mail, Helpdesk
system etc.
7.2.5.
The proposed Server Access Control solution should be able to protect critical server
infrastructure and minimize security risks by regulating access to confidential data and
mission critical services. The solution should provide policy-based control of who can
access specific systems, what they can do within them, and when they are allowed
access. Specifically, it should proactively secure access to data and applications located
on Linux, UNIX and Windows system servers throughout the infrastructure.
7.3. Technical Specifications for the Proposed Identity & Access Management System
7.3.1. The proposed solution should allow bulk loading of user data.
7.3.2. The proposed solution should support for 'Separation of Duty'.
7.3.3. The solution should support RBAC model.
7.3.4.
The proposed Identity and Access Management System must provide the following
features:
7.3.4.1.
The proposed solution must provide centralized administration of user-ids and password
management.
7.3.4.2.
The proposed solution must provide support for user store on a central LDAP or an
RDBMS.
7.3.4.3.
The proposed solution must provide a central directory of users, their real-world
business information, their accounts, and their access rights across the enterprise
without requiring changes to end-systems.
7.3.4.4.
The proposed solution must allow accounts on end-systems to be discovered, and linked
to users within the administration utility, which can be subsequently used as the single
point of administration.
7.3.5.
Cross Platform / Application - Must provide easy and cost-efficient administration of
users and resources across enterprise security systems and directories.
7.3.6.
Scalable - Must be scalable, open, extensible, and built around standards-based
LDAP/X.500 technology.
7.3.7. Audit - Must provide a consolidated audit trail of administrative operations.
7.4. Other Requirements
7.4.1.
The proposed solution must have APIs to enable additional user management
operations on UNIX, Linux and over and above the default operating system account set-
up.
7.4.2.
The proposed solution must have LDAP interface to enable queries/updates by
authorized third-party customer tools.
7.4.3.
The proposed solution must support enforcement of a centrally-defined security policy,
e.g. for access rights, user names, password lengths.
7.5. Role-based Administration
7.5.1.
The proposed solution must provide access rights based on job function to support
implementation of role-based administration.
7.5.2.
The proposed solution must have a web-interface for simplified user administration that
can be used by HR, business managers to introduce and delete users, and assign them to
job functions.
7.5.3.
The proposed solution should be able to integrate with HR application, CRM application
so as to enable creation of user ids based on data fed to CRM and HR applications.
7.5.4.
The proposed solution must allow users to access critical data through a single, secure
login, while reducing security/password administration.
7.5.5.
The proposed solution should have an embedded work flow which would help in
automating routine tedious tasks like approval processes.
7.5.6.
The proposed solution must provide advanced Web support, to allow for smooth access
and personalization of the user interface for each user. Once a user has been
authenticated to the sign on system, access to all authorized Web applications and
resources must be handled by this system.
7.5.7.
The proposed solution must provide access to only those applications/resources that the
user/customer has authority to.
7.5.8.
The proposed solution should provide capabilities to perform recertification of identities
across the Enterprise.
7.5.9.
The proposed solution should provide capabilities to perform Identity Auditing for
entitlement violations and validations.
7.5.10. The proposed solution must have Out-of-Box integration with Web Services.
7.5.11.
The proposed solution should provide capabilities to have Corporate Directory as well as
Provisioning Directory.
7.5.12.
The proposed solution must provide capabilities to ensure if a user is authenticated at a
low level of security (e.g., password), then they should be forced to re-authenticate
when they attempt to access a more sensitive resource (e.g., one protected by a token
card).
7.5.13.
Priority of these authentication methods should be Administrator specified. It should not
be hard-wired into the product and Administrator should be able to control the priority
of each authentication method.
7.5.14.
The proposed solution must provide feature to ensure that the User should be
permanently (until re-enabled) disabled from using the system.
7.5.15.
The proposed solution should supply significant password management services such as
expiration, min/max lengths, forgotten password support, lock-out, customizable
composition rules, editable password dictionary, etc.
7.5.16.
The proposed solution should support both session and idle timeouts on a per-resource
basis.
7.5.17.
Administrator should be able to specify rules for generating and rolling over encryption
keys (e.g., periodically, or upon command).
7.5.18.
Authentication management system should be capable of supporting automated fallback
to alternative authentication systems.
7.5.19. The proposed solution should support directory chaining.
7.5.20. The proposed solution should provide protection from cross-site scripting.
7.5.21. The proposed solution should support time or location-based policies.
7.5.22.
Administrator should be able to create a policy for any user, any group (including
dynamic groups), any role, or even any ad-hoc set of users who share certain attributes.
7.5.23.
Administrator should be able to create a policy that includes a group of users, with the
exception of certain individuals.
7.5.24.
Administrator should be able to integrate dynamic/external data (at run-time) in the
enforcement of my policies via a Web service.
7.5.25.
Administrator should be able to create policies that perform comparative tests on each
users directory profile information.
7.5.26.
The proposed solution should support controlled impersonation of users allowing
certain users to temporarily use the entitlements of other users without sharing of
passwords.
7.5.27.
The proposed solution should support fine-grained control of access to file, page, or
objects.
7.5.28.
The proposed solution should redirect the user to different web pages based on the type
of failed authentication or authorization that occurs.
7.5.29. The proposed solution should support full replication of all components.
7.5.30. The proposed solution should support automatic failover and failover between clusters.
7.5.31. The proposed solution should do dynamic load balancing across all servers.
7.5.32. The proposed solution should also load balance across directories.
7.5.33. The proposed solution should have extensive caching capabilities.
7.5.34.
The proposed solution should provide 2nd-level caching, so that recently used policies
are separated out into a separate cache. And these caches should be tunable for each
environment; also the caches should be either flushed or refreshed on administrator
command.
7.5.35. The proposed solution should enable or disable logging without restarting the server.
7.5.36.
The proposed solution should enable all agents to be managed from a single
administrative interface. If so the shared secret keys should be automatically rolled-over
on some predefined schedule.
7.5.37.
The proposed solution should support policy information be stored directly in LDAP, so
that a single directory can be used to store both user and policy information.
7.5.38.
Administrator should have full flexibility about where to store both user and policy
information.
7.5.39.
The proposed solution should allow integrating with home grown unique authentication
methods.
7.5.40.
There should be an API to allow easy integration of business logic into the policy
enforcement decisions. e.g., policies based on the content of dynamic user data.
7.5.41.
The proposed solution should use the policy enforcement capabilities of the product to
manage security for custom developed application and it should enforce policies based
on any generic resource, not just Web-based.
7.5.42. There should be an API that supports access to the password attributes in the directory.
7.5.43. The proposed solution must provide API that should support workflow capabilities.
7.5.44.
There should be an API for custom agents and also an API to allow custom directories to
be used for user storage.
7.5.45.
The proposed solution must manage access to applications maintaining unique
credentials for each application per user, eliminating the risks associated with password
synchronization (Applications within the organization may have password strengths
defined based on their sensitivity. Hence each application should continue to have a
password as per the password strength post the implementation of Single Sign-On too).
7.5.46.
The proposed solution must log users into any resource requiring a sign-on including
banking application, email, databases applications, web-enabled applications (DoP may
have a mix of Client Server, Legacy and Web applications. The solution must provide
capabilities to manage all environments from access management perspective).
7.5.47. The proposed solution must integrate with the Web SSO out-of-the-box.
7.5.48.
The proposed solution must control the number of sessions a user may have open
simultaneously on one or more workstations.
7.5.49.
The proposed solution must ensure all user credentials are encrypted in storage and in
transit between all components of the system (since the system deals with sensitive
information like the user credentials, it is needed that the information is encrypted in
storage as well as in transit between all the components of the system).
7.5.50.
The proposed solution must provide capabilities to re-authenticate users before running
sensitive applications (Organizations can identify applications that are sensitive from a
security or other perspective, and require the user to re-authenticate before running
such applications).
7.5.51.
The proposed solution must include an embedded high performance X.500 directory /
RDBMS to provide unparalleled scalability supporting millions of users.
7.5.52.
The proposed solution must support Offline mode functionality to allow users to login
to applications even when the SSO server is not On-line. Offline mode must only be
available for those applications identified for use in the offline mode by the security
administrator.
7.5.53.
The solution must provide a centralized policy /role driven control over authorization to
access applications.
7.5.54.
The logon scripts, policies and the logs stored on the server must be proactively
protected by an access control module.
7.5.55.
The proposed solution must support server farms to distribute load among multiple
servers providing scalability.
7.5.56.
The proposed solution must provide Personalized Application List to users (Users must
be presented an exact view of the applications they have permissions to use).
7.5.57.
The users application list must be automatically refreshed eliminating the need to re-
authenticate when application availability changes.
7.5.58.
Must have an option to extract user information like last successful login, last password
change, which application, how many users are using etc.
8.
Host-based Server Access Control System (HSACS)
The HSACS is a centralized system that controls access to the servers, file systems and
databases in the Data Centre. The solution must cover all systems which are proposed
by bidder under the scope of work mentioned in the CSI RFP and additional systems as
procured under FSI RFP. The specifications of the SACS are as follows:
8.1.
HSACS solution must cover all critical servers at Data Centre/DR as well as other
critical servers
8.1.1.
The HSACS shall control access to all server system (Unix, Linux and Windows) resources
including applications, data files, devices, processes/daemons, and audit files.
8.1.2.
The HSACS shall intercept security-sensitive events in real-time, and evaluate its validity
before passing control to the OS.
8.1.3.
The HSACS shall make no changes to the operating system kernel or binaries. Software
must allow for quick uninstall, if necessary.
8.1.4.
The HSACS shall allow controlling actions and access to resources of all users including
privileged accounts such as root / administrator.
8.1.5.
The HSACS shall provide the ability to designate specific roles like Administrators,
Auditors, and Password Managers etc with appropriate rights. It must also provide the
ability to designate specific users as Subordinate or Group Administrators, to manage
users and file permissions for their group.
8.1.6.
The HSACS shall provide complete file protection by intercepting every file access
request and deciding if the user is authorized to access the file.
8.1.7.
The HSACS shall enable administrators to designate critical files that when changed or
modified, shall generate a suitable alarm and write an audit record.
8.1.8.
The HSACS must support creation of rules for access permissions to various file systems
on per user and group profile basis.
8.1.9.
Users shall be allowed to access the system resources as per the day and time pre-
described in the system.
8.1.10.
The HSACS shall support management and policy distribution across multiple platforms
(Linux, UNIX and Windows) from a central management console. It must support the
deployment of the same policies across multiple servers ensuring consistency of security
policies.
8.1.11.
The HSACS shall support audit trail of all access activities. It shall track user logins,
logouts access to resources and track user names from initial authentication to create
secure and useful audit trails with full integrity. It shall provide a monitoring mode to
record activity of specific users.
8.1.12.
The HSACS shall provide simple to use graphical interface to enable complete
management of all user, group, resource, audit and policy settings, either centrally for
an enterprise or de-centralized to departments or business units.
8.2. HSACS User management
8.2.1.
The HSACS shall provide the facility to set accounts to expire on specific dates,
deactivate accounts on a configurable date or after a configurable amount of inactive
time, lock out accounts after multiple failed logins through a daemon, restrict accounts
logins during configurable times and days, deny access to accounts based on company
holidays.
8.2.2.
The HSACS must ensure that users permissions must always be governed by the original
login ID. Taking over the root account should not grant the user any additional privileges.
8.2.3.
The HSACS shall enable the administrators to share subsets of root authority among
different administrators based on their functional roles.
8.2.4.
The HSACS shall make it possible to automate the creation of complex security policies
with point and click options including control over logins, password quality, user and
group access, system files, attack prevention, network and environments.
8.2.5.
The HSACS shall enable fast addition, change, deletion and modifications to users and
groups across platforms, including synchronization with native operating system
settings.
8.2.6.
The HSACS shall allow controlling actions and access to resources of all users including
privileged accounts such as root / administrator. Must track the "real user" even in case
of surrogates.
8.2.7.
The solution should provide a feature to eliminate passwords from scripts. Via PUPM, it
should be possible to replace hard-coded passwords in scripts with privileged account
passwords that are generated by PUPM only when needed. The solution should provide
a unified web-based console which consolidates all aspects of privileged user
management under a single console host access control and privileged user
management across physical and virtual systems, devices and applications.
8.2.8.
The solution must provide support for IPv6 and FIPS140-2 and must provide Services and
Registry Values Protection.
9.
Two Factor Authentication tokens
Two factor authentication tokens will be used to provide two layer of authentication for
system administration and critical user accounts. It will be bidders responsibilities to
work with different solution providers to deploy the solution and provide support for
integration.
9.1. The solution must provide time-synchronous authentication technology.
9.2.
The solution must support a PASSCODE (combination of a 4 8 digit
numeric/alphanumeric PIN and a pseudorandom token no.) using AES or 3Des algorithm.
9.3. The hardware token should be tamper proof and not have any changeable parts.
9.4.
The solution must have authentication support based on the current Universal
Coordinated Time (UCT) and a supported time buffer.
9.5.
The solution must provide offset correction that is automatically synchronized to
Authentication Server.
9.6.
The solution must support for a multi-tier architecture comprising end user
authenticator, target application / device Agent and an Authentication Server
9.7.
The solution must provide encrypted communication between the components
including the primary and failover servers with the encryption key to change every few
minutes.
9.8. The solution must provide multi platform support for the authentication server.
9.9.
The solution must provide support to define access based on time of day, day of week or
by group or user-defined access.
9.10.
The solution must have provision available to write a custom query (SQL Statement) and
generate the reports based on queries in .CSV, .HTML formats.
9.11. Authentication server should have inbuilt RADIUS Server.
9.12.
Authentication server should support cross realm authentication between primary
servers.
9.13.
Agent APIs to be available in both C and Java and must be delivered along with the
license.
9.14.
Support for web-based provisioning and workflow product that enables users to rapidly
deploy hardware and software tokens.
9.15.
The solution must have support for software to enable a system or Help Desk
administrator to use a web browser to view and modify user, token and extension
record data in the Authentication server database.
9.16.
The solution must provide web-based workflow and support multiple approvers and
distributors and should support delegated administration.
9.17. The solution must support USB Token and OTP LCD display on the same device.
9.18.
The solution must provide support for storage of digital certificates, software tokens and
biometric templates, passwords on the USB Token with OTP LCD display.
9.19.
The Authenticators should be in forms of hardware (e.g., Keyfob) but not in the form
of CDs.
9.20.
The hardware token should have an LCD window capable of displaying minimum of six
digit number.

5. Operations & Maintenance Requirements
5.1 Service Desk Operations
1. CSI shall setup a service desk with qualified personnel to resolve technical queries received from
end users across the department.
2. The scope of the service desk will cover all the software and hardware being deployed as part of
the India Post 2012 program. In doing this, CSI will take over the L2 support from the interim
helpdesks being set up by the FSI and RSI.
3. The service desk shall be available 24x7.
4. The queries shall be answered using a pre-defined Service Operation Procedures (SOPs)
developed in consultation with or provided by respective solution providers.
5. CSI shall be responsible for logging and tracking (till closure) all the queries raised by the end
users.
6. CSI shall be responsible for ensuring proper follow up with personnel responsible for resolving
queries and update resolution status in the system. CSI shall provide report on SLA breaches by
other service providers for L2 and L3 tickets for areas not under the scope of CSI.
7. Service desk shall be required to support all the official languages as defined by the Government
of India or as required by DoP.
8. The system shall have the capability of monitoring specific levels of usage to obtain information
call patterns for different available information on the service.
5.2 ITIL
1. The proposed service delivery architecture must conform to ITIL v3 based practices and
framework. The approach must consider a high-level, strategic view with respect to people,
process and technology, the critical components of ITIL v3 based ecosystem.
2. Proposed solution framework must align to the ITIL processes framework and relationships
which can ease complexity and minimize unproductive detours that can disrupt service
improvement initiatives.
3. The framework must clearly support processes and users intending to reach from point A to
point B and stay on course to continuously-improve rather than continuously-revisit
4. ITIL v3 must be used as the foundation and as the common language so as to ensure focus on
the service lifecycle and provide an easy-to-navigate, high-level view of the ITIL terrain that
executives and implementation experts alike can understand and follow.
5. The proposed solution must drive new or enhanced services to meet user needs giving sufficient
considerations to what it takes to deploy and sustain the service. The focus must be on creating
and managing services across their lifecycle, from planning and delivering new IT services to
maintaining and supporting day-to-day activities all within a cycle of continual improvement.
6. CSI must ensure that the process intersections are clearly illustrated and process activities along
with quality and control mechanisms are clearly defined.
7. Service specifications must be produced for each new IT service, major change or IT service
retirement and it must define and deliver the levels of service the business needs.
8. Some of the key design goals that must be met are mentioned below:
o Design, develop and implement service management
o Design and develop the architecture, processes, policy and documents associated with
strategic IT services to meet current and future business requirements.
o Develop and improve capabilities to transition new and modified services to production.
o Effectively and efficiently provide and support services to ensure value for the DoP and its
users.
o Process activities, requirements, procedures, roles and responsibilities must be tailored to
suite the requirements
o Maintain and create new value for the Users through design improvement, new service
introduction and operations.
o Reduce risk and optimize business/IT integration across the service lifecycle using strategic
controls
5.3 Warranty
The CSI shall adhere to the following:
1. CSI shall provide on-site warranty of all components of hardware and software for the period of
the contract and shall be responsible for any bug removal in the software, any defect in
hardware or deficiency in functionality.
2. CSI shall warrant that the goods supplied under the contract are new, unused, of the most
recent or current models and incorporate all recent improvements in design and materials
unless provided otherwise in the contract.
3. CSI shall warrant that all the goods supplied under this contract shall have no defect arising from
design, materials or workmanship (except when the design and/or material is required by the
DoPs specifications) or from any act or omission of CSI, that may develop under normal use of
the supplied goods in the conditions prevailing at the final destination.
4. CSI shall warrant that solution being deployed do not and will not infringe any Intellectual
Property Rights (IPR) held by any third party and that it has all necessary rights, or at its sole
expense shall have secured in writing all transfers of rights and other consents necessary to
make the assignments, licenses and other transfers of IPR and the warranties set forth in the
contract, and for the DoP to own or exercise all IPR as provided in the contract.
5. During the warranty period, CSI shall undertake system maintenance and replacement or repair
of defective parts or systems.
6. The DoP shall notify CSI in writing of any claims arising under this warranty. Upon receipt of such
notice, CSI shall repair or replace the defective goods or parts thereof, without any cost to the
DoP.
7. If CSI, having been notified, fails to remedy the defect(s) within the specified period, the DoP
may proceed to take such remedial action as may be necessary, at CSIs risk and expense and
without prejudice to any other rights which the DoP may have against CSI under the contract.
8. CSI shall replace any component, which fails more than twice within a quarter. This must be
done free of charge.
9. The warranty should not be void if DoP buys any other supplementary hardware/software from
a certified third party and installs it with these equipments.
10. The obligations under the warranty expressed above shall include all costs relating to labor,
spares, maintenance (preventive and unscheduled) and transport charges from site to
manufacturers works and back for repair/replacement at site or any other part of the
equipment which under normal & proper use and maintenance proves defective in design,
material or fails to confront the given specifications.
5.4 Service Level Requirements (SLRs)
5.4.1 Definitions
For purposes of this Service Level Agreement, the definitions and terms as specified in the contract
along with the following terms shall have the meanings set forth below:
Scheduled Maintenance Time shall mean the time that the System is not in service due to a
scheduled activity as defined in this SLR. Scheduled maintenance time is planned downtime with
the prior permission of the DoP.
Scheduled operation time means the scheduled operating hours of the System for the month.
All 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 within the DC and DR and critical client site infrastructure will be 24x7x365. The
total operation time for the client site systems shall be the business hours of the DoP.
Availability shall mean the time for which the services and facilities offered by the CSI are
available for conducting operations from the equipment hosted in the Data Centre. Availability is
defined as:
{(Scheduled Operation Time System Downtime) / (Scheduled Operation Time)} x 100%
Application Downtime means accumulated time during which the System is totally inoperable
within the Scheduled Operation Time but outside the scheduled maintenance time and
measured from the time the DoP and/or its employees log a call with the CSI team of the failure
or the failure is known to the CSI from the availability measurement tools to the time when the
System is returned to proper operation.
"Service desk" shall mean CSIs 24x7x365 support for incident management and reporting during
this contract.
The business hours for various types of offices are given below in the table 21. The working days
mentioned exclude Public Holidays or any other Holidays observed by the DoP. The CSI however
recognizes the fact that the DoP offices will require to work beyond the business hours on need
basis.
Table 21: Office-wise Business hours
# Type of Office Business Hours
1 Directorate
9:00 AM to 5:30 PM
(Monday Friday)
2
Circle Office, Division Office, Regional Office,
PAF, CSD, PSD
9:00 AM to 5:30 PM
All working days (Monday Saturday)
3 HO, SO
7 Hours 30 Minutes
4 BO
3 - 5 hours daily
5 Record Offices 9:00 AM to 6:00 PM
All days of the week
6 Speed Post Centres
24 hours a day
7 Mail Offices
24 hours a day

"Non-Business Hours" shall mean hours excluding Business Hours.
5.4.2 Service Level Requirement and Targets
The SLRs have been logically segregated in the following categories:
1. Deployment Service Level
2. Availability Service Level
3. Performance Service Level
The following measurements and targets shall be used to track and report performance on a regular
basis. The targets shown in the following table are applicable for the duration of the contract.
5.4.3 Deployment Service Level
Table 22: Deployment Service Levels
# Parameter Description Target Impact Liquidated Damages (LD)
Validation Tools
/ method
1. Project Set-up Time
CSI is expected to mobilize the
team for commencement of the
project
T + 0.5 NA
The DoP reserves the right to
terminate the contract
Project kick-off
meeting, Project
management
office setup
2.
Project Plan
Documentation
Project planning documentation
including:
Final implementation plan
Solution design
Training Plan
Data Migration Plan
T + 2
< 2 weeks
0.5% of the total
implementation services cost
(as per FIN 2.4)
Deliverable sign-
off > 2 weeks
0.25% of the total
(as per FIN 2.4) for each
subsequent week
> 6 weeks
Event of default. Escalation to
DoP and CSI management
3.
Project Design
Documentation
Detailed design documentation
including:
System Requirement
Specifications
Detailed Test Plan
Use Cases
T + 4
< 2 weeks
0.5% of the total
(as per FIN 2.4)
Deliverable sign-
off
> 2 weeks
0.25% of the total
subsequent week
Validation Tools
/ method
> 6 weeks
4.
Hardware delivery &
commissioning
Delivery, Installation and
commissioning of central
hardware required for the
solution implementation at the
Data Centre / Disaster Recovery
Centre
As per
Implementation
Plan (Section
3.2.4, Table 10)
< 2 weeks
0.5% of total hardware value
of DC or DR (as per FIN 2.2)
Acceptance Sign-
off
> 2 weeks
0.25% of total hardware
value of DC or DR (as per FIN
2.2) for each subsequent
week
> 6 weeks
5. Integration & Testing
Overall integration and testing
of all solution components
As per
Implementation
Plan (Section
3.2.4, Table 10)
<4 weeks
0.25% of the software cost
for Wave 2 & 3 (as per FIN
2.3)

> 4 weeks
0.25% of the software cost
for Wave 2 & 3 (as per FIN
2.3) for every subsequent
week
> 8 weeks
6. Training
Training for Wave 1,2,3 solution
deployment as per the timeline
mentioned under
As per
Implementation
Plan (Section
< 4 weeks
0.50% of contract cost for
training for respective
Waves/phases (as per FIN
Training
completion
Validation Tools
/ method
implementation services
(Section 3.2.4, Table 10)
3.2.4, Table 10) 2.5) certificates
> 4 weeks
0.25% of contract cost for
training for respective
Waves/phases (as per FIN
2.5)
> 8 weeks
7. Roll-out
Roll out of Wave 1,2,3 solutions
as per the timeline mentioned
under implementation services
(Section 3.2.4, Table 10); system
documentation including
process flows in a standard tool
As per
Implementation
Plan (Section
3.2.4, Table 10)
<4 weeks
0.5% of the Roll Out cost for
respective waves/phases (as
per FIN 2.4)
Roll-out sign off
> 4 weeks
0.25% of the Roll Out cost for
respective waves/phases for
every subsequent week (as
per FIN 2.4)
> 8 weeks
8.
Resource Deployment
during implementation
Deployment of team resources
as committed in the RFP
response
As per RFP
response
1 change* in a
quarter
0.03% of the total
(as per FIN 2.4)
Project Team
schedule
2 changes* in a
quarter
0.07% of the total
(as per FIN 2.4)
Validation Tools
/ method
> 2 changes* in
a quarter
0.05% of the total
subsequent resource
changed. Escalation to DoP
and CSI management
More than 3
quarters in a
year with
changes* in
resources
0.07% of the total
(as per FIN 2.4). Escalation to
*Unless this change is requested by the DoP

5.4.4 Availability Service Level
Table 23: Availability Service Levels
# Parameter Applicability
Measurement
frequency
Target Impact
LD (to be calculated every quarter
for respective cost head)
1.
Solution (Hardware
and software)
availability at all the
Data Centre
Data Centre Monthly
Minimum of
99.98% uptime
(24x7x365)
9 - 40 minutes
0.5% of quarterly maintenance
charges (as per FIN 2.8)
41-200 minutes
2% of quarterly maintenance charges
(as per FIN 2.8)
>200 minutes
Event of default. Escalation to DoP
and CSI management
2.
Solution (Hardware
and software)
availability at all the
Disaster Recovery
Centre
Disaster Recovery
Centre
Monthly
Minimum of
99.98% uptime
(24x7x365)
9 - 40 minutes
41-200 minutes
(as per FIN 2.8)
>200 minutes
and CSI management
3.
Client application
availability (Pilot,
Phase 1, Final roll
out)
Circle Office, Regional
Office, Divisional
Office, PAF, CSD, PSD
Monthly
Minimum of
99% uptime
(Business Hours)
150 - 300 minutes
301 700 minutes
(as per FIN 2.8)
> 700 minutes
and CSI management
Measurement
frequency
Target Impact
4.
Client application
availability
HO, SO (> 3 Hand) Monthly
Minimum of
99% uptime
(Business Hours)
150 - 300 minutes
301 700 minutes
(as per FIN 2.8)
> 700 minutes
and CSI management
5.
Client application
availability
SO (3 Hand and
below)
Monthly
Minimum of
98% uptime
(Business Hours)
300 400 minutes
401 700 minutes
(as per FIN 2.8)
> 700 minutes
and CSI management
6.
Client application
availability
Single Hand SO
Branch Office
Monthly
Minimum of
97% uptime
(Business Hours)
150 - 300 minutes
300 - 600 minutes
(as per FIN 2.8)
> 600 minutes
and CSI management
7.
Client application
availability
SPC & Mail Office Monthly
Minimum of
99% uptime
400 - 850 minutes
Measurement
frequency
Target Impact
(Business Hours)
851 1300 minutes
(as per FIN 2.8)
> 1300 minutes
and CSI management
8.
Rural ICT Client
application
availability
Branch Offices Monthly
Minimum of
97% uptime
(Business Hours)

for the respective application (as per
FIN 2.8). LD shall increase by 1% for
every subsequent drop in service
level
5.4.5 Performance Service Levels
Table 24: Performance Service Levels
# Parameter Description Target LD Validation tool/method
1.
Application Response
time
Support 600 transactions per second (TPS)
and 60000 concurrent users on the
proposed hardware for Mail Booking
Engine application.
99.9%
0.5% of the quarterly
maintenance charges for
respective application (as per
FIN 2.8) for every incidence
greater than 2 hours
Measured through periodic
audits based on logs and
monitoring tool reports to be
provided by the CSI
and 9500 concurrent users on the
proposed hardware for IPVS and 11000
99.9%
concurrent users on the proposed
hardware for DPMS applications for Mail
Operations.
provided by the CSI
and 200 concurrent users respectively on
the proposed hardware for LSS, MLASS,
SPS, WMS & TMS applications for Mail
Operations and Logistics Post.
99.9%
provided by the CSI
Support 2.5 transactions per second (TPS)
and 22,000 concurrent users on the
proposed hardware for Finance &
Account applications.
99.9%
provided by the CSI
and 1000 concurrent users (for Core HR)
and 12000 - 15000 concurrent users (for
Self Service Portal (Employee/Manager)
on the proposed hardware for Human
Resources applications.
99.9%
provided by the CSI
End to end response time for both query
and transaction should be < 2 seconds at
peak transaction volumes (end user to
central application and back) at DoP site
for sites connected over the WAN
99.9%
provided by the CSI
End to end response time should be < 6
seconds for both query and transaction at
peak transaction volumes (end user to
central application and back) at client site
for sites connected over the broadband
99.9%
provided by the CSI
End to End response time within the DC at
peak transaction volumes (from the
Central Application to the Database and
back) should be < 10 ms (milli-seconds)
99.9%
audits based on logs to be
provided by CSI
2. CPU Utilization
Average daily CPU utilization levels during
business hours should be less than 70%.
Excluding EOD processing time (Batch
processing). Each occurrence, where peak
CPU utilization stays above 70% for 30
minutes or more, shall be counted as 1
incident.
Maximum
of 70%
utilization
on any
server
For each incident of crossing
the upper limit, 0.5% of
quarterly maintenance charge
(as per FIN 2.8)
Monthly Server Utilization
Report
3. Memory Utilization
Average daily memory utilization levels
during business hours should be less than
70%. Excluding EOD processing time
(Batch processing). Each occurrence,
where average daily memory utilization
stays above 70% for 30 minutes or more,
shall be counted as 1 incident.
Maximum
of 70%
utilization
on any
server
For each incident of crossing
the upper limit, 0.5% of
quarterly maintenance charge
(as per FIN 2.8)
Monthly Server Utilization
Report
4. Disaster Recovery Site
Business operations to resume from
Disaster Recovery Site within 4 hours of
the Data Centre failing
100%
1% of annual maintenance
Periodic Audit and helpdesk
report
5. Downtime for servicing
Each planned downtime for all solutions
including hardware, application,
database, security and operating system
servicing (up gradation, bug fixing, patch
uploads, regular maintenance etc.) will
not be more than 4 hours. This activity
will not be carried out during business
hours.
However, activities which require more
than 4 hours or required to be carried out
during business hours will be scheduled in
consultation with the DoP with approved
change request process. In case, the
downtime exceeds the planned hours, the
additional time taken for servicing will be
considered for infrastructure or system
downtime as per availability
measurements table.
100%
As per the Availability SLRs
(refer Table 14)
MIS Reports and Monitoring
Tools
The LD value shall increase by 1% for every 1% drop in expected service level.

Table 25: Service Desk SLRs for CSI Solutions
# Severity Level Severity Level Description Target Resolution Time Target LD
1. Severity Level 1
50 or more users in any circle cannot
access any of the applications as per
the scope of this RFP
All users in a HO/CO/Division
Office/RO etc. cannot access any of
the applications as per the scope of
this RFP
During business hours
Within 30 minutes of the
incident being logged
Non - business hours - Within
4 hours of the incident being
logged
99%
1 % of quarterly maintenance
charges for respective
solution (as per FIN 2.7) for
every 1 % drop
2. Severity Level 2
25 to 49 users in any circle cannot
access any of the applications as per
the scope of this RFP
All users in an SO or Mail Office with 5
or more users cannot access any of
the applications as per the scope of
this RFP
Within 2 hours of the
Non - business hours - Within
6 hours of the incident being
logged
99%
0.5 % of quarterly
respective solution (as per
FIN 2.7) for every 1 % drop
3. Severity Level 3
5-24 users in a circle cannot access
any of the applications as per the
scope of this RFP.
All users in an SO or Mail Office with
more than 2 users cannot access any
of the applications as per the scope of
this RFP
Within 4 hours of the
Non - business hours
Within 4 hours from start of
next business day
99%
0.25 % of quarterly
respective solution (as per
FIN 2.7) for every 1 % drop

Table 26: Service Desk SLRs for L1 support
# Severity Level Severity Level Description Target Response Time Target Penalty
1. All severities
Logging and tracking of all calls in
service desk tool including queries,
incidents, problems, change requests
etc.
Within 5 minutes of the calls
being logged
99%
1 % of quarterly
every 1 % drop
2. All severities
Closure of all calls in service desk tool
after resolution including queries,
incidents, problems, change requests
etc.
Within 15 minutes after call
resolution by L1, L2 or L3
support
99%
0.5 % of quarterly
every 1 % drop
3. All severities
SLA breaches report for other service
providers
CSI to submit detailed SLA
breaches on weekly and
monthly basis for all service
providers
99%
1 % of quarterly
every 1 % drop
Table 27: Call Centre SLRs
# Measurement Definition
Measurement
Frequency
Reporting
period
Target Impact LD
1.
System Uptime
(voice response
available to the
customer
Total uptime in minutes /
Total minutes of operations
in a month. This will be
calculated for window of
Daily Weekly 99.5%
>=98% & <99%
1% of the monthly charges for
Call Centre (FIN 2.6)
>=96.5% &
<98%
Measurement
Frequency
Reporting
period
Target Impact LD
service for 12-hour, 6-
days/week.
>=95% &
<96.5%
<95%
Call Centre (FIN 2.6); Event of
escalation to DoP and CSI
management
2. IVRS Efficiency
Measured as % of calls
satisfactorily disposed off at
the IVRS of the total calls
received
Daily Weekly 25%
>=20% & <25%
>=15% & <20%
<15%
management
3.
Average Speed to
Answer
Measured as % of calls that
are answered by the Call
Centre operators within 20
seconds from the caller
choosing to speak to an
agent.
Daily Weekly >80%
>=75% & <80%
>=65% & <75%
< 65%
management
Measurement
Frequency
Reporting
period
Target Impact LD
4.
Call abandonment
rate
Measured as % of calls that
requested for an agent but
got disconnected before
being answered by the
agent.
Daily Weekly <5%
>=5% & <10%
>=10% & <20%
>20%
management
5. Call quality Score
Scoring of agent calls against
predefined parameters to
ensure that the agents are
adhering to the quality
standards as defined by
DoP. The parameters &
mechanism for calculating
quality score will be
mutually agreed between
DoP & CSI
Daily Weekly >85%
>=80% & <85%
>=70 & <80%
<70%
management
6.
Customer
Satisfaction
Measurement of customers
satisfaction with the way
their query/complaint has
been handled. The CSI shall
be responsible for
Daily Weekly >= 2 >=1.6 & <2
5% of the monthly charges (FIN
2.6)
Measurement
Frequency
Reporting
period
Target Impact LD
maintaining a minimum
level of customer
satisfaction based on the
criteria defined by DoP from
time to time.
The satisfaction level of
callers shall be collected on
a three point scale of 3:
satisfied, 2:No comments
and 1:dissatisfied
<1.6
management
7.
First Time
Resolution
Measured as % of calls
resolved at first line,
without the need for
escalation to other support
groups. The Call Centre
agent is expected to resolve
the issue or answer the
question during the first
contact i.e. while user is still
on telephone to report the
call.
Weekly Monthly 80% -
0.5% of the monthly charges for
Call Centre ((FIN 2.6) for every
2.5% actual FTR below target.
8.
Average handle
Time
Measured as the time taken
to manage a caller. AHT
shall be calculated as the
sum of the average talk
Daily Weekly
<180
seconds
-
0.5% of the monthly charges (FIN
2.6) for every 10 second slab
above target
Measurement
Frequency
Reporting
period
Target Impact LD
time, hold time and wrap
time.

6. Standards Adherence
The CSI must design the system following open standards, to the extent possible and in line with the
requirements described in this RFP, in order to provide for good interoperability with multiple
platforms and solutions being developed by other System Integrators.
Additionally, the solution has to be compliant with industry standards wherever applicable. This will
apply to all the aspects of solution including but not limited to design, development, security,
installation, and testing. There are many standards that are indicated throughout this volume as well
as summarised below. However the list below is just for reference and is not to be treated as
exhaustive.
Table 28: Reference List of Standards
# Description Standard
1. Workflow design WFMC standards Portal development W3C specifications
2.
Information access/transfer protocols SOAP,
HTTP/HTTPS
Interoperability Web Services, Open
standards
3.
Photograph JPEG (minimum resolution of 640 x
480 pixels)
Scanned documents TIFF (Resolution of 600
X 600 dpi)
4.
Adherence to the security standards such as ISO
27001, Information security standards
framework and guidelines standards under
eGovernance standards
(http://egovstandards.gov.in), Information
Security guidelines as published by Data Security
Council of India (DSCI) and complies to IT
(Amendment) Act 2008.
Operational integrity & security
management system to be ISO 17799
compliant
5. Service Management ISO 20000 specifications
Project Documentation IEEE/ISO
specifications for documentation
6. Postal Technical Standards
UPU Technical Standards
UPU EDI Messaging Standards
7. Finance Reporting International Finance Reporting Standards
The proposed solution architecture should be compliant with the following security standards and
guidelines (including but not limited to):
1. IT Act 2000 (revised 2008)
2. Information security standards framework and guidelines standards under eGovernance
standards (http://egovstandards.gov.in)
3. Guidelines issued by Government of India
All hardware, software & network equipments should be IPv6 compliant. The application(s)
developed for DoP should be integrated with the National Service Delivery Gateway (NSDG) to
access common functions such as UID, PAN etc. so as to avoid development of individual
connections in future. The details are available at http://www.mit.gov.in/content/nsdg.
Bidders shall also explain in detail how these standards are being met in the solution offered.
7. Acceptance Testing, Audit and Certifications
7.1 Deliverable Acceptance
1. CSI shall notify the readiness of deliverables by e-mail to DoP.
2. Deliverables shall be submitted in form of Soft copy (by e-mail) and one (1) printed draft of the
deliverable material.
3. Within fifteen (15) working days, DoP will either accept the deliverable or provide the CSI a
written list of requested changes. If DoP does not respond with any change within fifteen (15)
working days, then the deliverable shall be deemed accepted.
4. CSI shall make appropriate revisions for any written list of changes requested by DoP and shall
resubmit the updated final version to DoP, at which time the document shall be deemed
accepted.
5. E-mail confirmation from CSI shall be treated as provisional sign-off, which shall be followed by a
signed document. For any purpose of calculation of days, date on communication related to
provisional sign-off will be treated as the date of acceptance of deliverable.
7.2 Acceptance Testing
1. After consultation with the DoP and/or with any party nominated by DoP, CSI shall prepare and
submit a detailed plan containing test schedule, test procedures & the various performance
parameters for testing as per industry standards & best practices for conducting various tests,
hereinafter referred to as the Test Plan. Necessary instruments, automated testing scripts and
tools, consumables, personnel and other facilities required for conducting the tests shall be
arranged by the CSI. All acceptance parameters as agreed between DoP and the CSI will be
demonstrated during the tests.
2. The acceptance / performance test will be performed after completion of installation and
commissioning of all the components of the solution. Complete hardware and software
conforming to the functional / technical requirements of the RFP must have been supplied,
installed and commissioned properly by CSI prior to commencement of the tests.
3. The acceptance test will be conducted by DoP or external agency nominated by DoP. CSI shall be
responsible for setting up and running the acceptance test without any extra cost to DoP.
4. The acceptance will involve trouble-free operation for seven consecutive days at site. No
malfunction is expected to occur in any component of the solution. CSI shall maintain a log
which shall record the result of the test to establish successful completion of the specificed test
to the satisfaction of DoP. An average uptime of 100% in case of equipment for the duration of
test period shall be considered as acceptable.
5. In the event of hardware and software failing to pass the acceptance test, a period not
exceeding two weeks will be given to rectify the defects and clear the acceptance test, failing
which DoP reserves the right to get the corresponding component replaced by CSI at no extra
cost to DoP or to cancel the order and recall all the payments with interest at 15% per annum
from the date of the respective payments till the time of actual receipt of refund.
6. Successful conduct and conclusion of the acceptance tests for the installed components shall
also be the sole responsibility and at the cost to CSI.
7. CSI will execute the tests and when program changes are made in response to the defects found,
the corresponding test will be executed again. This cycle will be repeated until the test script
associated with the program/interface is successfully executed. All defects found will be
assigned a priority as defined in table below. CSI is expected to close all the defects within the
timeframe approved by DoP.
Table 29: Defect Priority and resolution
# Priority Description
1
Priority 1
CRITICAL - Generally reserved for fatal errors that mean that testing cannot
continue without fix, and/or means that the service cannot go-live. Must be
fixed before go-live.
2 Priority 2
HIGH Used when there is a problem that means that testing can continue on
the scenario using difficult workarounds, and/or significantly impacts the
business' ability to use the application. Must be fixed before go-live.
3 Priority 3
MEDIUM Used when there is a problem that means that testing can continue
with relatively straightforward workarounds, and/or has a minor impact on the
business ability to use the application. Does not need to be fixed before go-live.
Signoff by business of known issue will be required before go-live.
4
Priority 4
LOW Used to highlight minor SIRs that will be fixed only if time permits and
does not impact the businesses ability to use the application (e.g., cosmetic).
Usually an enhancement and scope change request.
8. DoP s right to inspect, test and, where necessary, reject the goods after the goods arrival at
destination shall in no way be limited or waived by reason of the goods having previously been
inspected, tested and passed by DoP or its representative prior to the shipment of the goods.
9. CSI shall also arrange to get the implementation review done by the OEM for the COTS products
being implemented as part of the CSI. CSI shall plan for minimum three such OEM reviews for
each implementation.
7.2.1 Conducting the User Acceptance Test
1. Pilot tests of solution implementation shall be carried out through solution prototype to check
the fulfillment of functional requirements configured as per the approved business blue print.
The prototype validation will go through multiple iterations. The feedback provided to the CSI
after each round of validation must be documented and signed off by the DoP nominated users.
Changes to the solution must be presented to the users in next round of solution validation or
pilot. This will be an iterative process till the solution prototype is signed off as acceptable by the
DoP.
2. Pilot test certificate shall be issued on successful demonstration of all critical functional
requirements and at least 80 % of essential functional requirements as per approved blue print.
3. User acceptance Tests of the solution shall be completed by the CSI as specified in the Test Plan
4. DoP or its representative shall have the right to inspect and/or test the solution to confirm their
conformity to the contract at no extra cost to DoP.
5. The inspections & tests may be conducted in the premises of CSI or its partner, at the point of
delivery and/or at the final destination.
6. CSI shall assist DoP in all acceptance tests to be carried out by DoP. The modalities for conduct of
acceptance tests decided by DoP or its authorised external agency will be final and binding on
CSI.
7. DoP will provide the scope of the acceptance tests to CSI prior to performing the tests. CSI shall
create a detailed acceptance plan and get it approved from DoP. CSI shall arrange for the tests at
the relevant sites in the presence of the officials of DoP and / or its designated representatives.
CSI shall ensure that the tests involve trouble-free operation of the complete system apart from
physical verification and testing and that there shall not be any additional charges payable by
DoP for carrying out this acceptance test.
8. In case of any discrepancy in the hardware / software supplied, DoP reserves the right to
terminate the entire agreement, within a period of 6 months in case CSI does not rectify or
replace the supplied hardware/software and CSI shall take back equipment supplied at CSI costs
and risks. DoP has the right to reject the CSI Supplied Equipment and to seek free replacement
or repair of the equipment or defective components thereof till the completion of acceptance
test and obtaining final acceptance certificate from DoP.
9. The installation-cum-acceptance test will be deemed to be fully and finally accepted by DoP in
the event DoP has not completed and communicated the results of the acceptance tests to CSI
within 60 days of submission of all documents duly accepted by the various locations of DoP to
the PMU. The Installation-cum-Acceptance Test and Check certificates will be jointly signed by
the DoP representative and CSI.
10. In all cases, CSI shall have the sole responsibility for bearing all additional charges, costs or
expenses incurred in correcting, reworking or repairing the defective or non-conforming
hardware/software.
7.2.2 Inspection of Records
All CSI records with respect to any matters covered by this RFP shall be made available to DoP or its
designees at any time during normal business hours, as often as DoP deems necessary, to audit,
examine, and make excerpts or transcripts of all relevant data. The cost of the audit will be borne by
the DoP. The scope of such audit would be limited to Service Levels being covered under the
contract, and financial information would be excluded from such inspection, which will be subject to
the requirements of statutory and regulatory authorities
7.2.3 Acceptance Certificate
1. On successful completion of acceptability test, the acceptance certificate signed by CSI and the
PMU of DoP will be issued. The date on which such certificate is signed shall be deemed to be
the date of acceptance of the system.
2. In case of any defect or deficiencies or other reason for failure of the user acceptance test, DoP
shall notify the CSI in writing of the same
3. The CSI shall promptly remedy any defect and/or deficiencies and/or other reasons for the
failure of the user acceptance Test that the DoP has notified the CSI of. Once the CSI has made
such remedies, it shall notify DoP and shall promptly carry out retesting of the System. Upon the
successful user acceptance Tests, the CSI shall notify DoP of its request for user acceptance
certification.
7.2.4 Go-Live and Stabilization Acceptance
1. After the issue of the user acceptance certificates the CSI will ensure that the Project is rolled
out for production environment, hereafter referred to as Go-live, in accordance with the
timelines specified in the Implementation Plan.
2. DoP shall deploy the operating and technical personnel and all materials and information
reasonably required to enable the CSI to carry out its obligations under Go- Live as specified in
the Implementation Plan.
3. Different modules rolled out for Go-live will be operated in an integrated environment as per the
Implementation Plan. Upon successful operation of the Project in the production environment,
Go-live acceptance certificate will be issued.
7.3 Monitoring & Audit
1. DoP reserves the right to carry out periodic computer security audits to monitor the compliance
with security best practices.
2. The periodicity of these audits will be decided at the discretion of DoP.
3. These audits may include, but are not limited to, a review of access and authorization
procedures, validation of correctness of the program/application/specific operation, physical
security controls, backup and recovery procedures, security controls and program change
controls.
4. To the extent that DoP deems it necessary to carry out a program of inspection and audit to
safeguard against threats and hazards to the confidentiality, integrity, and availability of data,
the CSI shall afford DoP's representatives access to the CSIs facilities, installations, technical
resources, operations, documentation, records, databases and personnel.
5. The CSI must provide DoP access to various monitoring and performance measurement systems
(both manual and automated).
6. DoP has the right to get the monitoring and performance measurement systems (both manual
and automated) audited without prior approval / notice to the CSI.
7. DoP reserves the right to review the user / technical documentation of the proposed softwares
to verify compliance with the technical specifications included in the RFP.
7.4 Certification
After the acceptance of the system, Quality Certification of the all the components of the project
including the applications pertaining to various functional areas and client applications for the Rural
ICT platform is mandatory. The DoP may assign a 3
rd
party(s) such as STQC to perform this task. CSI
shall be responsible for assisting such certification agency, whenever required, at no extra cost to
the DoP.

8. Annexure
8.1 Acronyms Used
Acronym Full Form
AMC Annual Maintenance Contract
APAR Annual Performance Appraisal Report
API Application Programming Interface
BD&MD Business Development and Marketing Directorate
BNPL Book Now Pay Later
BO Branch Post Office (or Branch Office)
BOD Beginning of Day
CEPT Centre for Excellence for Postal Training
CIM Customer Interaction Management
CIFM Customer Information Management
CM Change Management
CO Circle Office
COTS Commercial Off The Shelf
CRC Computerised Registration Centre
CRM Customer Relationship Management
CSD Circle Stamp Depot
CSI Core System Integrator
DC Data Centre
DGS&D Directorate General of Supplies and Disposals
DO Divisional Office
DoP Department of Posts
DPMS Delivery and Postman Management System
DR Disaster Recovery
DWH Data Warehouse
EDI Electronic Data Interchange
EDW Enterprise Data Warehouse
eMO Electronic Money Order
EMS Enterprise Management System
EOD End of Day
ETL Extract Transform Load
F&A Finance and Accounting
FSI Financial Services System Integrator
FTL Full Truck Load
GB & IR Global Business and International Relations
GDS Gramin Dak Sewak
GL General Ledger
GPO General Post Office
GPRS General Packet Radio Service
GPS Global Positioning System
GUI Graphic User Interface
HO Head Post Office (or Head Office)
HoA Head of Accounts
HR Human Resources
HRMS Human Resource Management System
HRO Head Record Office
HTML HyperText Markup Language
ICT Information and Communications Technology
IM Inventory Management
iMO Instant Money Order
IMS Inventory Management Solution
IPO Inspector Post Office
IPS International Postal System
IPVS India Post Visibility System
IVR Interactive Voice Response
JS&FA Joint Secretary and Financial Advisor
KPI Key Performance Indicator
LAN Local Area Network
LCD Liquid Crystal Display
LOB Line of Business
LPC Logistics Post Centre
LSS Labour Scheduling System
LTC Leave Travel Compensation
LTL Less than Truck Load
MB Mail Business
Mbps Mega Bytes Per Second
MBS Mail Booking/Retail Post System
MGNREGS Mahatma Gandhi National Rural Employment Guarantee Scheme
MIS Management Information System
MLASS Mailer and Logistics Appointment Scheduling System
MM Materials Management
MMS Mail Motor Service
MO Money Order
MOH Mail Operations Hardware
MPC Mail Processing Centre
MPCM Multi Purpose Counter Machines
NI Network Integrator
NMS Network Management System
NOC Network Operations Centre
NSPC National Speed Post Centre
OEM Original Equipment Manufacturer
OLAP On-Line Analytical Processing
OOE Office Of Exchange
OPC OpenGL Performance Characterization
OS Operating Software
PA Postal Assistant
PAF Postal Accounts and Finance
PAO Postal Accounts Office
PBS Postal Banking Solution
PG & QA Public Grievances and Quality Assurance
PIN Personal Identification Number
PIS Personnel Information System
PLI Postal Life Insurance
PMG Postmaster General
PMU Project Management Unit
PO Post Office
PO&I Postal Operations
POC Point of Contact
POD Proof of Delivery
PoS Point of Sale
PSCI Postal Staff College of India
PSD Postal Store Depot
QA Quality Assurance
RB Rural Business
RDBMS Relational Database Management System
RFID Radio Frequency Identification Device
RFP Request For Proposal
RH Rural ICT Hardware
RMS Railway Mail Service
RO Regional Office
RPLI Rural Postal Life Insurance
RSI Rural ICT System Integrator
Rural ICT Rural Information and Communication Technologies
SAN Storage Area Network
SLA Service Level Agreement
SMTP Simple Mail Transfer Protocol
SO Sub Post Office
SOA Service Oriented Architecture
SOI Service Oriented Infrastructure
SP Superintendent Posts
SPM Sub Post Masters
SPS Sort Program System
SRM Superintendent Railway Mail
SRO Sub Record Offices
SSP Senior Superintendent Posts
SSPC State Speed Post Centre
SSRM Senior Superintendent Railway Mail
TMO Transit Mail Office
TMS Transportation Management System
TRG Training
TTT Train The Trainer
URL Uniform Resource Locator
VPN Virtual Private Network
VPP Value Payable Parcel
WAN Wide Area Network
WAP Wireless Application Protocol
WCTC Workplace Computer Training Centre
WFM Workflow Management System
WiMAX Worldwide Interoperability for Microwave Access
WMS Warehouse Management System
WSDL Web Service Definition Language
XML Extensible Markup Language
YOY Year on Year
8.2 Volumetric Information
8.2.1 DoP transaction volumes for various products and services (numbers in Lakh)
Table 30: Volumetric Data Mail Products & Services

FY 2011 FY2012 FY2013 FY2014 FY2015
Accountable* Articles

Registered Post 1907 1871 1835 1800 1765
Money Order Issued 800 769 739 710 682
International Mail Traffic 55 53 52 50 49
Speed Post 3139 3824 4660 5678 6919
Express Post 75 77 78 80 82
Bill Mail 7667 9200 11040 13248 15897
Total Accountable article booking 13642 15794 18404 21566 25395
Retail Post transactions 5536 7620 10489 14438 19873
e-Payment transactions 175 192 212 233 256
e-Post bookings 3 4 4 5 6
*Accountable articles shall be required to be scanned throughout the supply chain for tracking
throughout the system. On an average, an article would be scanned 8 times through the supply
chain.

8.2.2 Logistics Post Business growth volumes (numbers in Lakh)
Table 31: Volumetric Data Logistics Post growth
FY2011 FY2012 FY2013* FY2014* FY2015*
Logistics Post Bookings 6 7 9 10 12
No. of Operational Warehouses Nil 10 10 10 10
No of Major LPCs Operational 30 30 30 30 30
No. of Minor LPCs Operational 133 200 200 200 200
* These numbers may undergo slight change as the necessitated by the business requirements
8.2.3 User Estimate
Table 32: Volumetric Data User Estimates Mail Operations

FY 2011 FY2012 FY2013 FY2014 FY2015
Point of Sale/Mail Booking Engine
No. of concurrent users 60,775 60,775 60,775 60,775 60,775
% growth (year on year) - - - - -
No. of transactions per day 3837269 4738074 5951022 7585459 9790187
No. of peak transactions per day 4988449 6159497 7736328 9861097 12727243
% growth (year on year)

23% 26% 27% 29%
No. of concurrent users 5911 6562 7363 8348 9556
% growth (year on year) 11% 12% 13% 14%
Delivery & Postman Management System
No. of transactions per day 4739085 5456817 6327362 7,382,057 8658711
Mailer & Logistics Appointment Scheduling System
No. of transactions per day 5800 6760 7912 9,294 10953
Transport Management System
Labour Scheduling System
Sort Program System
Table 33: Volumetric Data User Estimates Logistics Post

FY 2011 FY2012 FY2013 FY2014 FY2015
Warehouse Management System
No. of transactions per day 100,000 100,000 100,000 100,000 100,000
No. of peak transactions per day 130,000 130,000 130,000 130,000 130,000
Table 34: Volumetric Data User Estimates Finance & Accounts

FY 2011 FY2012 FY2013 FY2014 FY2015
Table 35: Volumetric Data User Estimates Human Resources

FY 2011 FY2012 FY2013 FY2014 FY2015
No. of concurrent users for Core HR 1,000 1,010 1,020 1,030 1,040
No. of concurrent users for Self
Service Portal (Employee/Manager)
12,000
15,000
Assume 5% year-on-year growth
8.2.4 Call Centre: No. of call estimates
Table 36: Volumetric Data Call Centre Estimates

FY 2011 FY2012 FY2013 FY2014 FY2015
Retail Post

Total number or retail post
transactions
32,800,000 38,000,000 38,900,000 41,895,000 44,000,000
Call as a % of transactions 10% 10% 10% 10% 10%
Total No. of Calls 328,000 380,000 389,000 418,950 440,000
Mail Operations
Total bulk articles booked 2,402,325,231 2,642,557,754 2,906,813,530 3,197,494,883 3,517,244,371
Total accountable articles
booked
518,974,203 570,871,623 627,958,786 690,754,664 759,830,131
Articles/Bulk Transaction 5000 5000 5000 5000 5000
No. of bulk transactions 480,465 528,512 581,363 639,500 703,450
Accountable Article
Booked per transaction
2 2 2 2 2
No. of accountable articles
transactions
259,487,102 285,435,812 313,979,393 345,377,332 379,915,065
Total articles transactions 259,967,567 285,964,323 314,560,756 346,016,831 380,618,514
Call as a % of total
transactions
5% 5% 5% 5% 5%
Total no. of calls 12,998,378 14,298,216 15,728,038 17,300,842 19,030,926
Banking
Total number of calls 16,000,000 17,600,000 19,360,000 21,296,000 23,425,600
Insurance
Total number of calls 4,875,000 5,118,750 5,374,688 5,643,422 5,925,593

Total Number of calls 37,153,378 40,816,966 44,452,725 48,429,763 52,781,094
No. of calls / day 101,790 111,827 121,788 132,684 144,606
Peak no. of calls 305,370 335,482 365,365 398,053 433,817
8.2.5 Phase-wise number of Locations for the Roll-out
Table 37: Number of locations for Phase-wise Roll-out
# Type of Office No. Of Offices
Pilot Phase
HO 108
MDG and LSG 12
Triple Hand SO (A CLASS) 0
Double Hand SO 0
Single Hand SO 4
GDS Sub Post Offices/EDSO/BO 300
Mail Office 20
Record Offices 30
Speed Post Sorting Hubs 10
Transit Mail Offices 20
Total 504
Phase 1
HO 241
MDG and LSG 759
Triple Hand SO(A CLASS) 300
Double Hand SO 250
Single Hand SO 200
Mail Office 126
Record Offices 122
Total 15903
Phase 2
HO 457
MDG and LSG 2423
Triple Hand SO(A CLASS) 3030
Double Hand SO 6489
Single Hand SO 11265
Mail Office 200
Record Offices 184
Total 138138

8.3 To Be Process Flow
Attached in a separate document.

8.4 Functional Requirement Specifications
8.4.1 Mail Operations
8.4.1.1 Mail Booking Engine (MBE)
The Mail Booking Engine shall provide DoP with the functionality for booking accountable articles
and selling Retail Post articles. The system shall auto-validate the data related to the articles and
calculate the postage or the sale price accordingly. The system shall enable full visibility and proper
accounting of the articles. Other functionalities performed by the MBE include online parcel pickup
and recording employee work hour details.
MBE will have the capability to book the following products/services:
1. Parcel
2. Registration
3. Insured Articles
4. VPP
5. Speed Post
6. Bill Mail / National Bill Mail
7. Express Parcel Post
8. e-Post
9. International Mail, EMS, Parcel
10. Retail Post
11. e-VPP
12. Logistics Post
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

Point of Sale Counter Terminal Landing Page
1. MB1.1
The Point of Sale Counter Terminal shall allow the user to enter the Mail
Booking Engine portal from the main landing screen
E
Mail Booking Engine Terminal Peripherals
2. 2 MB1.2
The Counter Terminal shall have peripherals connected that enable required
functionality (assumes included screen, keyboard and mouse)

3. MB1.2.1
The Counter Terminal shall have a connected weigh scale that automatically
passes item weight to the terminal.

4.
MB1.2.1.
1
The connected scale must also have a human readable digital display E
5.
MB1.2.1.
2
If the scale is not able to automatically transfer data to the terminal, the user
shall be able to manually enter the displayed weight into the terminal. System
shall also allow the counter clerk to input volumetric data.
E
6. MB1.2.2 The Counter Terminal shall have a connected bar code scanner
7.
MB1.2.2.
1
The bar code scanner shall provide an audible notification on successful scan E
8.
MB1.2.2.
2
The bar code scanner shall provide a visual notification on successful scan E
9.
MB1.2.2.
3
If the bar code scanner is not able to transfer data to the Terminal, the user
shall be able to manually enter bar code characters
E
10. MB1.2.3 The Counter Terminal shall have a connected printer
11.
MB1.2.3.
1
The connected printer shall print receipts for customers E
12.
MB1.2.3.
2
The connected printer shall print adhesive labels with paid postage amount or
bar codes to be affixed to accountable articles
E
13. MB1.2.4
The Counter Terminal shall be compatible to handle a credit/debit/ATM card
reader in the future

14.
MB1.2.4.
1
If the credit/debit/ATM card reader is not present or is not working, the user
shall have the ability to manually enter credit/debit card numbers
E
15.
MB1.2.4.
2
If the customer uses a debit/ATM card, the system shall have the capability to
accept the customers PIN code for identification validation on a PIN code
keypad
E
16. MB1.2.5
The Counter Terminal software solution shall be designed to be touch-screen
compatible (i.e. finger sized selection buttons, on-screen keyboard icon, etc.)
so that future monitor purchases can utilize the touch-screen interface
D
Booking an Individual Accountable Mail Article
17. MB1.3 MBE shall validate data related to the article being booked
18. MB1.3.1 MBE shall prompt the user to enter the destination PIN code
19.
MB1.3.1.
1
MBE shall validate PIN codes as being valid E
20.
MB1.3.1.
2
The system shall prompt users to select the destination city/state based on
the PIN code master available in the system
E
21.
MB1.3.1.
3
The system shall create an address memory so that frequently entered
destinations can be presented as remembered options to the user as the
destination city/state characters are entered (similar to Google browsing
intelligence)
E
22.
MB1.3.1.
4
When the system displays remembered destination options to the user, the
user shall be able to select one of the options such that the remaining
destination information is auto-populated by the system
E
23.
MB1.3.1.
5
When the user selects the city/state, the system shall auto-populate the
associated PIN code
E
24. MB1.3.2
MBE shall display on the screen the weight of the article that was placed on
E
the scale
25.
MB1.3.2.
1
If the scale is not connected, the user shall enter the weight of the article into
the MBE
E
26. MB1.3.3
MBE shall display the possible product types based on the destination entered
(i.e. Speed Post, Registered, International, etc.)
E
27.
MB1.3.3.
1
If the destination entered is not serviced by one of the standard product
types, then that product type shall not be displayed (i.e. Speed Post to certain
rural areas)
E
28. MB1.3.4
When the possible product-types are displayed, the system shall display
beside each product-type the system-calculated postage required
E
29.
MB1.3.4.
1
MBE shall use configurable data to automatically calculate required postage
based on the following attributes of the article:
Product (i.e. Speed Post, Registered, International, etc.)
Origin
Destination
Weight of article
Price of the article (in case of periodicals/books)
Volumetric size of article (input manually)
E
30. MB1.3.5
When the possible product types are displayed, the system shall display
beside each product type the automatically system-determined expected
delivery date range for each product
E
31. MB1.3.6
After the user selects the product desired by the customer, the system shall
allow the user to select multiple, configurable special services (meaning more
services can be added to the list of options) requested by the customer (i.e.
SMS notifications, signature confirmation, etc.)

32.
MB1.3.6.
1
The system shall display special services relevant to the product selected
alongside the additional cost for each service
E
33.
MB1.3.6.
2
If the customer selects SMS notification for sender at time of delivery, the
system shall prompt the user to enter the senders mobile phone number
E
34.
MB1.3.6.
3
If the customer selects SMS notification for recipient on day of expected
delivery, the system shall prompt the user to enter the recipients mobile
phone number
E
35.
MB1.3.6.
4
If the customer selects e-mail notification for sender at time of delivery, the
system shall prompt the user to enter the senders e-mail address
E
36.
MB1.3.6.
5
If the customer selects e-mail notification for recipient on day of expected
delivery, the system shall prompt the user to enter the recipients e-mail
address
E
37.
MB1.3.6. The system shall validate that all e-mail addresses match expected e-mail
E
6 format (include @ and . somewhere after the @)
38.
MB1.3.6.
7
If the customer selects Return Service if the article is for some reason
undeliverable, the system shall prompt the user to enter the senders full
address
E
39. MB1.3.7
After the user has selected any additional services, the system shall present
the final amount of postage due that includes the up-charges for the selected
special services

40.
MB1.3.7.
1
If the customer has selected Speed Post, the system shall display the expected
end to end routing and associated transit times
E
41.
MB1.3.7.
2
For Speed Post bookings, the system shall identify the routing on the printed
Speed Post label
E
42. MB1.3.8
The system shall prompt the user to scan the 2-9-2 bar code sticker that will
be used to track the article

43.
MB1.3.8.
1
The user shall have the ability to enter the bar code number in the event that
the scanner is not working or there is none connected
E
44.
MB1.3.8.
2
Once Speed Net has been completely decommissioned and all scanners have
been upgraded to read the future article bar code the system shall auto-
generate/print unique bar codes, making this scanning requirement
unnecessary in the future
D
45. MB1.3.9
Upon completion of payment transaction (see Accepting Payment
requirements section), all data captured during the article booking shall be
transmitted to the central server
E
Individual Stamp Sales
46. MB1.4 MBE shall provide Stamps sales functionality
47. MB1.4.1
The system shall provide a beginning of day function to record the amount of
postage and petty cash taken to the stamp counter
E
48. MB1.4.2
The system shall provide an end of day function to record the amount of
postage and petty cash returned to the MBE terminal
E
49. MB1.4.3
The system shall reconcile the beginning of day stamp counts and cash
amounts with the end of day stamp counts and cash amounts and raise any
discrepancies to the user
E
50. MB1.4.4
The system shall send stamp transaction details to the Inventory Management
System for tracking of post office stamp inventory
E
Retail Post Sales
51. MB1.5 MBE shall provide the ability to sell Retail Post items to customers
52. MB1.5.1
MBE shall offer the following services:
Sale of goods
E
a. Sale of stationery
b. Sale of packing material
c. Greeting cards of other organizations
d. Sale of gold coins
e. Sale and distribution of souvenirs
f. Sale and distribution of books
g. Sale and distribution of prasadams
h. RBI coins service
i. Sale of Revenue/judicial/Non-judicial
j. Sale of Rakhi/Speed Post/other envelopes
Sale of application forms
k. Sale of UPSC/SSC/RRB application forms
l. Sale of University application forms
Miscellaneous Services
m. Sale of travel related services
n. Railway reservation service (PRS)
o. Sale of event tickets
p. Address verification services
q. Drop-Box services
r. Forex services
s. Subscription services
t. Telecom services
u. Income Tax services
v. Distribution of loans
w. Internet caf services
x. Other agency services
53.
MB1.5.1.
1
MBE shall provide the flexibility for HQ admin users to add new Retail Post
service offerings
E
54. MB1.5.2 MBE shall provide the ability to sell philatelic items to customers E
55. MB1.5.3 The system shall allow the user to add multiple items to the customers order E
56.
MB1.5.3.
1
As additional items are added to the customers order, the system shall auto-
update the amount owed by the customer
E
57. MB1.5.4
Upon completion of payment transaction (see Accepting Payment
requirements section), all data captured during the Retail Post order shall be
transmitted to the central server
E
58. MB1.5.5
If the customer has purchased a Retail Post item stocked by DoP, MBE shall
send order request to WMS for order fulfilment to be processed
D
59. MB1.5.6
If the customer has purchased a Retail Post item NOT stocked by DoP, MBE
shall send the external customer the order request for order fulfilment
D
60. MB1.5.7
The system shall send transaction details to the Inventory Management
System for tracking of post office philatelic and Retail Post inventory
E
61. MB1.5.8
When the system books a VPP or Payment on Delivery article, the system shall
have an outbound interface with Accounts Receivable module for the amount
outstanding against the identification number of the article
E
62. MB1.5.9
If the system is operating in offline mode, the booking shall still occur, but the
user shall notify the customer that the article may not be immediately
available (may be on backorder since the system cant connect to check) and
capture customer SMS/e-mail to notify user when the item will be available
E
63.
MB1.5.1
0
The system shall enable ePayment
64.
MB1.5.1
0.1
The system shall have accounts for facilitating bill collection for Business
Partners
E
65.
MB1.5.1
0.2
The system shall collect bill payment from retail customers for the partner
corporate
E
66.
MB1.5.1
0.3
The system record the customer id number (unique identifier for the business
partner) into the system
E
67.
MB1.5.1
0.4
The system shall have an outbound interface with the customer IT system to
pass on the information pertaining to the payments by its customers
E
68.
MB1.5.1
0.5
The system shall have proper accounting for the money collected on behalf of
its business partner
E
Online Booking and Pickup Requests
69. MB1.6 MBE shall provide the user an online pickup request capability
70. MB1.6.1
MBE shall require the user to enter the address where the article shall be
picked up
E
71. MB1.6.2 MBE shall require the destination address where the article shall be delivered E
72. MB1.6.3
MBE shall allow the user to select the product type (i.e. Speed Post,
Registered, International, etc.)
E
73. MB1.6.4
For International articles, the system shall require the user to enter required
customs declaration information online
E
74. MB1.6.5
For International articles, the system shall require the user to print the
Customs Declaration form to be securely affixed with tape to the article
E
75. MB1.6.6
MBE shall allow the user to select special services (i.e. delivery confirmation,
signature confirmation, etc.) that they would like to include for the article
E
76. MB1.6.7
MBE shall require the user to enter the physical attributes of the article:
weight and dimensions. (Meant only for small & medium business with mail
room facility)
E
77. MB1.6.8
MBE shall calculate required postage based on the data entered by the
E
customer. (Meant only for small & medium business with mail room facility)
78. MB1.6.9
MBE shall create a label to be printed and affixed by the customer on the
article. (Meant only for small & medium business with mail room facility)

79.
MB1.6.9.
1
The label shall include the following required sender/delivery information:
Sender Name
Sender Address
Recipient Name
Recipient Address
Special Services Included
E
80.
MB1.6.9.
2
The label shall include paid postage information. (Meant only for small &
medium business with mail room facility)
E
81.
MB1.6.9.
3
The label shall include the unique article bar code. (Meant only for small &
E
82.
MB1.6.9.
4
The label shall be formatted such that it fits on a standard adhesive label size
that the customer can easily purchase to be fed through a laser printer.
(Meant only for small & medium business with mail room facility)
E
83.
MB1.6.1
0
MBE shall provide users various payment methods as described in the
Payment Options requirements. (Meant only for small & medium business
with mail room facility)
E
84.
MB1.6.1
1
MBE shall generate a receipt for the customer. (Meant only for small &
E
85.
MB1.6.1
2
MBE shall interface with the Delivery & Postman Management System to send
customer pickup requests to the post office where that address is serviced
E
86.
MB1.6.1
3
For city areas, the system shall be compatible with functionality to locate the
closest postman using GPS in postmans device along with the expected beats
of the postmen.

87.
MB1.6.1
3.1
If a postman along that beat has not yet passed the destination entered, the
system shall send an SMS notification to the postman with the closest device
for pickup on remaining beat.
D
88.
MB1.6.1
3.2
In addition to the device SMS, the system shall also send an outbound
interface to DPMS for the expected delivery and postage due
D
89.
MB1.6.1
3.3
If the postman along that beat has already passed the destination entered or
there are no GPS enabled devices in that area, the system shall send an
outbound interface including all of the collected information to DPMS to
schedule the pickup for the following day
E
90.
MB1.6.1
3.4
If the customer chooses to not print the label information, the data sent via
SMS or interface to DPMS shall include the following required sender/delivery
information:
E
Sender Name
Sender Address
Recipient Name
Recipient Address
91.
MB1.6.1
3.5
The label data shall include required postage information for the postman to
collect
E
92.
MB1.6.1
3.6
MBE shall book the article through the handheld being carried with the
Postmen
D
93.
MB1.6.1
3.7
System shall reconcile the amount collected by the Postmen with the
Accounts Receivable module
D
94.
MB1.6.1
3.8
For places where the Postman does not carry the handheld, he will come back
to the office and upload the information in the system in the office through
MBE
E
95.
MB1.6.1
3.9
The label data shall include the unique article bar code E
Booking of Bulk Customers
96. MB1.7 MBE shall provide functionality to induct bulk mail customer drop-offs
97. MB1.7.1
MBE shall allow the user to upload the customers electronic manifest in a
pre-defined file format through a web account. Alternatively, it shall also
allow the user to upload the electronic manifest from customers physical
storage device (CD/DVD)

98.
MB1.7.1.
1
The data to be uploaded from the electronic manifest shall be the following:
Customer ID (assigned at first use of booking or appointment system)
Article ID
Weight of the Article
Recipient Name
Recipient Address
Destination City/State and PIN
Special Service Code for the article
E
99.
MB1.7.1.
2
The system shall display the summary information for the shipment E
100.
MB1.7.1.
3
After uploading the electronic manifest, the system shall calculate the postage
due for the entire transaction based on the information in the manifest
E
101.
MB1.7.1.
3.1
The system shall send a debit transaction to the Accounts Receivable module
for the customer ID to be invoiced for the amount calculated based on the
manifest
E
102.
MB1.7.1. Upon completion of the users scanning (either through handheld scanner or
E
4 through high-speed scanner), the system shall allow an update of the counts
of articles actually in the shipment
103.
MB1.7.1.
4.1
The system shall re-calculate the postage for any discrepancies in counts
between the customers manifest and the actual counts
E
104.
MB1.7.1.
4.2
The system shall send a debit transaction to the Accounts Receivable module
with the customer ID, the additional amount to be invoiced, and the count of
the discrepancy
E
105. MB1.7.2 MBE shall provide the user a bulk customer booking screen
106.
MB1.7.2.
1
MBE shall prompt the user to first weigh a sample article E
107.
MB1.7.2.
2
If the shipment is small enough to be weighed on the scale, MBE shall allow
the user to capture the total weight of the shipment
E
108.
MB1.7.2.
3
If the shipment cannot fit on the scale, MBE shall allow the user to enter the
number of articles included in the shipment that will be validated through
individual bar code scans
E
109.
MB1.7.2.
4
MBE shall prompt the user to select any special services requested by the
customer for the entire shipment
E
110.
MB1.7.2.
5
If the shipment has been bar coded by the customer, the system shall capture
the article bar codes for each PIN code

111.
MB1.7.2.
5.1
For PIN code-wise bundles, the user shall enter the PIN code of the bundle
and then scan each article bar code related to that PIN code without having to
re-enter the PIN code each time
E
112.
MB1.7.2.
5.2
The user shall enter a new PIN code when changing PIN codes for a bundle of
articles for another destination then scan the relevant article bar codes
E
113.
MB1.7.2.
5.3
For city-wise bundles, the user shall enter the first three digits of PIN code of
the bundle and system shall populate the next three digits as 000 and then
scan each article bar code related to that PIN code without having to re-enter
the PIN code each time
E
114.
MB1.7.2.
5.4
articles for another destination then scan the relevant article bar codes
E
115.
MB1.7.2.
6
If the shipment has not been bar coded by the customer, the system shall
include an extra charge for counter bar coding

116.
MB1.7.2.
6.1
The user shall enter the PIN code only of the bundle and then enter the
beginning and end bar code to be applied to that bundle
E
117.
MB1.7.2.
6.2
articles with the same destination then enter the beginning and end bar code
to be applied to the relevant article bar codes
E
118.
MB1.7.2.
7
MBE shall calculate the total charge for the shipment based on the number of
items, weight, destination and special services selected using the bulk postage
table
E
119. MB1.7.3
The customer can pay for the shipment using one of the methods described in
the Payment Options requirements section
E
120. MB1.7.4
If the customer does not want to pay through one of the individual Payment
Options described in section MB1.9, MBE shall use the customers credit or
debit account for payment
E
121.
MB1.7.4.
1
MBE shall allow for new customer creation if the customer does not already
have a DoP credit or debit account. This information must be maintained
locally and centrally (for distribution to other local servers).

122.
MB1.7.4.
1.1
The system shall capture company name, contact information, company funds
approver, and all other fields per the standard DoP customer application form
E
123.
MB1.7.4.
1.2
If the customer is government or semi-government, their account may be
opened as a Book-Now-Pay-Later customer for payments related to Speed
Post and other premium products
E
124.
MB1.7.4.
1.3
If the customer provides deposit (as specified by DoP) through one of the
Payment Options, they shall be setup as a BNPL customer
E
125.
MB1.7.4.
1.4
If the customer is not a BNPL customer, they shall provide advance payment
through one of the Payment Options so that their shipment amount can be
deducted from their credit available
E
126.
MB1.7.4.
1.5
If the customer has an advance payment account, the system shall create a
debit from the customers account for the total amount due
E
127.
MB1.7.4.
1.6
Customer advance payments, debits, and BNPL transactions shall be sent to
the Accounts Receivable module for customer account
E
128.
MB1.7.4.
1.7
If the customer does not have enough funds in their debit account, the system
shall prompt the user to add more funds
E
129.
MB1.7.4.
1.8
If the customer has a BNPL account, the AR module receives an amount due
transaction from the MBE to increase the amount owed by the customer
E
130.
MB1.7.4.
1.9
If the customers account exceeds a configurable threshold of amount due,
the user shall instruct the customer that the booking cannot be accepted
without payment of the overage
E
131.
MB1.7.4.
1.10
If the customers account is in default because a payment was missed, the
system shall prompt the user to send electronic instruction to the customer
that the booking cannot be accepted without payment of the amount due
E
132. MB1.7.5
Upon completion of the payment transaction, the system shall transmit bulk
booking events for each article
E
133. MB1.7.6
If the customer was a new customer, the system shall send a new customer
record to the Customer Database and receive back a unique customer ID that
can be provided to the customer for future use
E
Franking Machine Functionality
134. MB1.8 MBE shall provide functionality to interact with Franking Machine users
135. MB1.8.1
MBE shall accept license fee from the Franking machine user for unique
franking machine (digifrank compliant as prescribed by DoP).

136.
MB1.8.1.
1
MBE shall issue the receipt for the license fee deposited E
137.
MB1.8.1.
2
MBE shall prompt franking machine user to enter Annexure-A fields that are
not already captured through their license number
E
138. MB1.8.2 MBE shall intimate Licensing Authority about license requests E
139.
MB1.8.2.
1
MBE shall enable the Licensing Authority to verify application forms
140. MB1.8.3
MBE shall accept list of clients along with their consent letters who are being
serviced by a franking machine user
E
141. MB1.8.4 MBE shall update application form status E
142. MB1.8.5
MBE shall grant unique license to the franking machine user after Licensing
Authority and field staff physical verification
E
143.
MB1.8.5.
1
MBE shall generate four digitally authenticated Copies of Certificate of License
along with customer relationship numbers to be sent to:
- Franking machine user
- Designated post office/mail office/field post office
- Remotely Managed Franking System centre
- Mail Booking/Retail Post server
E
144. MB1.8.6
The system shall allow Corporate customers to uniquely log into the India Post
MBE

145.
MB1.8.6.
1
MBE shall recognize the customer based on customer relationship number E
146.
MB1.8.6.
2
MBE shall list out all licenses for franking machines possessed by the customer
1 license for each franking machine

147.
MB1.8.6.
2.1
MBE shall show balances against each license E
148.
MB1.8.6.
2.2
MBE shall show license usage pattern E
149.
MB1.8.6.
MBE shall enable selection of individual license for recharge E
3
150.
MB1.8.6.
4
MBE shall accept any of the standard Payment Options E
151.
MB1.8.6.
4.1
The MBE shall credit unique license E
152.
MB1.8.6.
4.2
MBE shall record details of licenses recharged E
153.
MB1.8.6.
5
MBE shall pass the details of licenses recharged to the remotely managed
franking system server at the vendor location (RMFS server)
E
154. MB1.8.7
MBE shall allow authorised user to update the status of any franking machine
license as cancelled or expired
E
155. MB1.8.8
MBE shall provide options for cancellation of Franking Machine licenses as per
DoP SOP
Based on Licensee request
Based on DoP request
E
156. MB1.8.9 MBE shall not allow recharge of the cancelled/expired licenses E
157.
MB1.8.1
0
MBE shall provide options for renewal of FM licenses as per DoP SOP E
158.
MB1.8.1
1
MBE shall process requests for miscellaneous services of Franking Machine as
per DoP SOP
Address change of FM With/without change of licensing authority
Change in license identifier etc.
E
159.
MB1.8.1
2
MBE shall enable selection/update of rebate & refunds provided by post E
160.
MB1.8.1
3
MBE shall provide online forms required for Franking Machine operations (e.g.
Application for renewal of license)
E
Payment Options
161. MB1.9 MBE shall provide numerous payment options
162. MB1.9.1 MBE shall accept cash payments E
163. MB1.9.2 MBE shall calculate required change to be returned to the customer E
164. MB1.9.3 MBE shall be compatible to accept credit card payments E
165. MB1.9.4 MBE shall be compatible to accept debit card payments E
166. MB1.9.5 MBE shall accept ATM card payments E
167.
MB1.9.5.
1
MBE shall allow the customer to enter their ATM card PIN code
168. MB1.9.6
MBE shall have the ability to debit the customers DoP savings account for any
transaction
E
169. MB1.9.7
MBE shall have the ability to debit the corporate customer account for the
services performed for the customer
E
170. MB1.9.8
MBE shall have the ability to debit the customers savings account held at
other banks for any transaction
E
171. MB1.9.9
For corporate/bulk mailer customers ONLY, MBE shall accept cheque
payments
E
172.
MB1.9.9.
1
If the customers cheque does not clear, the customers account shall be
marked with prescribed amount for returned cheque charge
E
Capturing Employee Work Hours
173. MB1.10 MBE shall record employee work hour details
174.
MB1.10.
1
MBE shall automatically capture work hours of users of the terminals
175.
MB1.10.
1.1
For users of the Terminal, MBE shall provide a start shift function where the
user first records the beginning of their work shift
E
176.
MB1.10.
1.2
For users of the Terminal, MBE shall provide an end shift function where the
user records the end of their work shift
E
177.
MB1.10.
2
For employees in an office who do not use the terminal, the Mail Booking
Engine shall provide a means by which the supervisors can manually record
employee work hour details in the system
E
Transferring Data from a Disconnected Office
178. MB1.11
MBE shall provide the ability to dump and load data stored on a local server
that cannot connect to the central server

179.
MB1.11.
1
MBE shall allow a user to perform a daily data dump onto CD or flash drive
that can be taken to a neighbouring connected office
E
180.
MB1.11.
2
MBE shall allow a user to load data from a CD or flash drive containing a data
dump from a neighbouring disconnected office
E
181.
MB1.11.
3
MBE shall automatically transfer the re-loaded data to the central server once
the data dump has been loaded onto the connected office server
E
182.
MB1.11.
4
The data being transferred must be encrypted on the transferring medium E
Mail Accounting Functions
183. MB1.12
MBE shall include an accounting engine for recording transactions done for
sale of products/services

184.
MB1.12.
MBE shall record the sales volumes and pricing data for profitability analytics E
1
185.
MB1.12.
1.1
Each product/service transaction needs to be booked (associated) to a
predefined Head of account (HoA) for proper revenue recognition
E
186.
MB1.12.
1.2
These HoAs will be defined by the PAF division as per GoI guidelines for the
same
E
187.
MB1.12.
1.3
At each End of Day, the mail app will centrally push consolidated GL data
product (HoA) wise from each PO to the GL for consolidation and compilation
of accounts for DoP as a whole
E
Product/Pricing List Functions
188. MB1.13 The system shall include a product & pricing list
189.
MB1.13.
1
The product/pricing list shall be centrally maintained
190.
MB1.13.
1.1
The product/pricing list shall be available to the mail booking engine E
191.
MB1.13.
1.2
The product & pricing list shall be available to other booking channels such as
Rural ICT & web booking
E
192.
MB1.13.
1.3
The product & pricing list shall be maintained with state-to-state variances,
both on product prices and on taxes/tariffs
E
193.
MB1.13.
1.4
Pricing list for Logistics services being offered to the customers shall be
maintained in the system for various routes and options (LCL, LTL, FTL etc.)
E
194.
MB1.13.
2
Each product must be assigned to a predefined Head of Account (HoA) for
proper revenue recognition
E
195.
MB1.13.
3
When new products are added, the system shall not make the new product
available to booking systems until a Head of Account has been assigned to the
new product
E
196.
MB1.13.
4
When a new product is added, the changed product/pricing information shall
be synchronized to the local servers not the entire product/pricing list
E
Booking an Individual International Mail Article
197. MB1.14
MBE shall ensure that the product and documentation meets international
specifications

198.
MB1.14.
1
The system shall validate the article meets sizing restrictions
199.
MB1.14.
1.1
The system shall accept weight of the parcels in kilogrammes E
200.
MB1.14.
1.2
The system shall accept a maximum individual weight of 20 kilogrammes E
201.
MB1.14.
1.3
The system shall provide option of admitting parcels between the weights of
20 and 50 kilogrammes
E
202.
MB1.14.
1.4
The system shall limit parcel to two meters for any one dimension E
203.
MB1.14.
2
The system shall capture address details for addressee and sender E
204.
MB1.14.
3
The system shall verify the details of the article along with the list of restricted
articles in the destination country
E
205.
MB1.14.
3.1
The system shall check with the prohibitions of individual destination country E
206.
MB1.14.
4
The system shall have a checklist which includes:
CP71/CP72 Dispatch note
CN22/CN23 Customs declaration
export licence / import licence
certificate of origin
certificate of health
E
207.
MB1.14.
5
The system shall capture at the time of posting of a parcel, the treatment to
be given in case of non-delivery
Return to sender
Redirection for delivery to the addressee
Abandonment
E
208.
MB1.14.
6
The system at the office of origin shall be equipped to print the CP73 label E
209.
MB1.14.
7
The system shall capture numerous required data elements/forms and
transfer such data to UPU-specified systems
E
210.
MB1.14.
7.1
The system shall allow electronic entry into form
CP71 Dispatch note
CN23 Customs declaration
E
211.
MB1.14.
7.2
The system shall record method of forwarding and to be clearly indicated on
the dispatch note relating to the parcel
E
212.
MB1.14.
7.3
Dispatch note is to be printed in a self-adhesive document pack pasted firmly
to the parcel
E
213.
MB1.14.
7.4
The system shall print for parcels on which a COD charge is applicable the
dispatch note which will bear very prominently the heading "reimbursement"
along with the amount
E
214.
MB1.14.
8
The system shall capture international accounting information E
215.
MB1.14.
8.1
The system shall capture charges, customs duty, and other fees paid out on
behalf of the other on the CN12 form
CN 12 Details of accounts prepared by creditor admin
CP 75 summarized account
CN51 Airmail detailed account
E
Booking ePost at the Counter
216. MB1.15
The system shall allow a user to book an ePost article that will be printed and
delivered by the destination post office

217.
MB1.15.
1
The system shall allow a written note to be recorded into the system E
218.
MB1.15.
2
The system shall accept a note that is to be scanned at the parent office with a
document scanner
E
219.
MB1.15.
3
The system shall prompt the user to record the following data for the article
to be sent via ePost:
Senders name
Recipients name
Recipients full address
E
Booking Individual Article over the Phone
220. MB1.16
The system shall provide an accountable article pickup function through the
DoP Call Centre

221.
MB1.16.
1
The Call Centre screen shall capture sender name and address E
222.
MB1.16.
2
The Call Centre screen shall capture the destination address where the article
shall be delivered
E
223.
MB1.16.
3
The Call Centre screen shall allow the user to select the product type
requested by the customer (i.e. Speed Post, Registered, Money Order
International Articles must be booked online or at post office)
E
224.
MB1.16.
4
The Call Centre screen shall allow the user to select special services (i.e.
delivery confirmation, signature confirmation, etc.) that they would like to
include for the article
E
225.
MB1.16.
5
For city areas, the system shall be compatible with functionality to locate the
closest postman using GPS in postmans device along with the expected beats
of the postmen.
D
226.
MB1.16.
5.1
If a postman along that beat has not yet passed the destination entered, the
system shall send an SMS notification to the postman with the closest device
for pickup on remaining beat.
D
227.
MB1.16.
5.2
In addition to the device SMS, the system shall also send an outbound
interface to DPMS for the expected delivery
E
228.
MB1.16.
5.3
If the postman along that beat has already passed the destination entered or
there are no GPS enabled devices in that area, the system shall send an
outbound interface including all of the collected information to DPMS to
schedule the pickup for the following day
E
229.
MB1.16.
5.4
The data sent via SMS or interface to DPMS shall include the following
required sender/delivery information:
Sender Name
Sender Address
Recipient Name
Recipient Address
Special Services Included alongwith the mail class of an article
E
Booking a Money Order
230. MB1.17
The Mail Booking/Retail Post System shall allow booking of Money Order for
payment to a beneficiary at another location in the country

231.
MB1.17.
1
The shall provide two options for Money Orders:
1. Money Order delivery at the doorstep
2. Customer to approach any connected/service providing Post Office
E
232.
MB1.17.
2
System shall allow capture of the following details for Doorstep Delivery
Transaction:
Sender Name
Sender address
Sender Mobile Phone Number
Amount
Beneficiary Name
Beneficiary Address
Beneficiary Mobile Phone Number
Beneficiary Identification details, if any
Delivery Post office details
Small Text message, if any
E
233.
MB1.17.
3
On selection of transaction where customer would approach the PO, the
system shall allow capture of the following details:
Sender Name
Sender address
Sender Mobile Phone Number
Amount
Beneficiary Name
Beneficiary Address
Beneficiary Mobile Phone Number
Beneficiary Identification details, if any
Delivery Post office details (Greyed out since this MO is payable across the
E
network)
Small Text message, if any
234.
MB1.17.
4
System shall allow selection of sender by means of providing the customer ID
or Account number which would enable debit to the Senders Account (Only
for PBS Branch Account Holders)
E
235.
MB1.17.
5
System shall enable capture of the Senders Mobile number if the same does
not get populated by selection of the Customer ID or Account number
E
236.
MB1.17.
6
System to allow parameterization of a maximum & minimum limit for any
type of transaction
E
237.
MB1.17.
7
System to calculate Commission pertaining to the MO at the prescribed rate E
238.
MB1.17.
8
System shall allow recovery of this commission by debit to the Savings Bank
account in case sender is Account holder (Only in case of a PBS branch)
E
239.
MB1.17.
9
System shall allow capture of Multiple Beneficiaries and their details in the
system
E
240.
MB1.17.
10
System shall generate a Unique reference number (13 character code 2
character for money order product code MO, 9 digits for unique number
generated and last 2 character would be IN) for each type of transaction
booked. The same should be sent to the Sender & Beneficiary via SMS with
the details of the Paying Branch in case of Type 1 transaction
E
241.
MB1.17.
10.1
The unique number shall be sent to the Sender & Beneficiary via SMS with the
details of the Paying Branch in case of Type 1 transaction as well as a printed
receipt presented to the sender
E
242.
MB1.17.
11
System should allow for maker checker concept for authorization of the MO
transaction
E
243.
MB1.17.
12
System should interface with the SMS engine to send a Text Message to
sender and beneficiary for the Booking of Money Order event
E
Money Order Accounting
244. MB1.18
System should enable interface with PBS to debit the sender if he/she is an
account holder (Only in case of a PBS branch)

245.
MB1.18.
1
System shall verify the account balances before transfer of funds in case it is a
request by debit to account (Only in case of a PBS branch)
E
246.
MB1.18.
2
System shall have an accounting interface with GL to enable inter-branch
accounting entries for payment of the MO and knock off the Cash position
entries and the Inter-branch entries after liquidation
E
247.
MB1.18.
3
System should be able to match off the accounting entries and reconcile the
same based on liquidation by the Delivery Branch
E
248. MB1.19
MBE shall have the functionality to sell and discharge the Indian Postal Orders
as per the DoP Standard Operation Procedure
E
Integration Requirements
249. IPVS
MBE shall have an outbound interface to the IPVS sending all of the data
captured in MBE so that IPVS can consolidate the article tracking events,
volume, and employee work hour data with the same data captured
throughout the remainder of the mail network
E
250. DPMS
MBE shall have an outbound interface to DPMS to send articles booked online
or over the phone that require labels to be printed by the postman and taken
on their beat for postage collection
E
251. MLASS
MBE shall have an inbound interface to receive requests for appointment
costing that includes shipment details and additional services requested by
the customer for their shipment. MBE shall then respond with the total cost of
the shipment and services.
E
252. ERP AR
MBE shall have an outbound interface to AR to debit the account with the
charges for the services performed for the customer, to credit account for
deposits made for future services, and to intimate account receivable amount
for Book-Now-Pay-Later (BNPL) service. It shall also use this interface to
confirm that the customers account is in good standing and can accept the
new shipment. Finally, the system shall send VPP or Cash-on-Delivery article
ID and amount due to later be reconciled after successful delivery.
E
253. WMS
MBE shall have an outbound interface to the WMS to send Retail Post order
requests for order fulfilment
E
254. ERP GL
MBE shall have an outbound interface to the GL Solution to send all of the
revenue-generating transaction data (i.e. stamp sales, philatelic sales, Retail
Post, etc.).
E
255. ERP IMS
MBE shall have an outbound interface to the IMS to send stamp, philatelic,
and Retail Post transaction details so that the IMS can track and auto-
replenish inventory within the Post Offices
E
256. PBS
MBE shall have an outbound interface to the PBS in order to debit the account
with the charges for the services performed for the customer.
E
257. HRMS
For the purpose of workload analysis of an establishment (operative and
administrative units), Establishment Review Module of HRMS shall need the
number and value of operations/ transactions happening at each
establishment. The customized interface designed for this purpose shall draw
data for four calendar months, from the data warehouse in the form of MIS
reports. MBE shall ensure that this detail is stored in the data warehouse on a
monthly basis.
E
258.
External MBE shall have outbound interfaces with external customer systems to send
D
Custome
r
non-DoP Retail Post order requests for order fulfilment.
259.
RMFS
Licensin
g
Authorit
y
MBE shall have an outbound interface to send Franking Machine license
information
E
260.
RMFS
Server
MBE shall have an outbound interface to the RMFS server to send Franking
Machine recharge information
E
8.4.1.2 India Post Visibility System
The India Post Visibility System (IPVS) shall enable DoP to record complete end-to-end article
visibility events throughout postal operations. The system shall also interact with MBE to receive
data relating to the articles booked, capture volume information throughout postal operations and
allow for additional processing for international mail articles. The system shall enable internal and
external (such as customers, business partners, etc) users with the complete visibility of the articles.
IPVS shall also capture employee work hour information.
IPVS will have the capability to track and trace the following products/services:
1. Parcel
2. Registration
3. Insured Articles
4. VPP
5. Speed Post
6. Bill Mail / National Bill Mail
7. Express Parcel Post
8. e-Post
9. International Mail, EMS, Parcel
10. Logistics Post
Different products will have different track & trace requirements. For example, Bill Mail articles will
not be tracked throughout the supply chain, only the delivery will be captured on system. For other
accountable articles such as Parcel, Speed Post etc. the article will be tracked throughout the supply
chain.
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

1. MB2.1
IPVS shall allow collection office users to capture outbound bag/volume
information.

2.
MB2.1
.1
IPVS shall allow collection office users to nest individual accountable articles
into unique bar coded bags by scanning the bag bar code then the individual
articles.

3.
MB2.1
.1.1
IPVS shall allow users to scan the standard 2-9-2 item bar code when creating
accountable article bags.
E
4.
MB2.1
.1.2
IPVS shall allow the user to Close the bar coded bag by again scanning the bag
bar code after scanning individual articles into the bag.
E
5.
MB2.1
.1.2.1
Closed bags shall be sequentially marked in the system such that every time a
new bag is created for a destination office, the sequence number for that
destination office increases by 1 to later ensure that no bags are lost between
origin and destination.

6.
MB2.1
.1.3
IPVS shall treat scans of individual articles into bags as en route events for the
individual article scanned.
E
7.
MB2.1
.1.4
IPVS shall store bag manifest data in the central server and transmit such data
to the relevant downstream offices.
E
8.
MB2.1
.2
When RFID system has been enabled, IPVS shall have the functionalities listed
under MB2.1.1 activated through RFID capability
D
9.
MB2.1
.3
IPVS shall allow users to capture details about bags of ordinary mails.
10.
MB2.1
.3.1
IPVS shall allow the user to enter the destination of the bag they are about to
create.
E
11.
MB2.1
.3.2
After placing all of the ordinary mail for that destination into the bag and placing
the bag on the scale, IPVS shall capture the weight of the bag.
E
12.
MB2.1
.3.3
IPVS shall then prompt the user to scan the 2-9-2 permanent bag bar code on
the bag when despatching a new bag.
E
Capturing Data on Inbound Mail Items/Volume
13. MB2.2 IPVS shall capture data related to inbound bags.
14.
MB2.2
.1
IPVS shall scan the incoming ordinary mail bags on receipt. E
15.
MB2.2
.2
IPVS shall scan the incoming accountable mail bags on receipt.
16.
MB2.2
.2.1
IPVS shall accept scans of bags with associated nested articles as en route
events for the individual articles associated with the scanned bag.
E
17.
MB2.2
.2.2
IPVS shall use a configurable (by site) QA frequency value that indicates when
the user must scan each article in an accountable bag individually upon receipt
(i.e. every 5
th
bag, every 10
th
bag, every bag, etc.).
E
18.
MB2.2
.2.3
IPVS shall accept scans from bar code scanners for individual accountable
articles.
E
19.
MB2.2 IPVS shall interface with high-speed scanners or sorters in high volume facilities
E
.2.4 to receive scans for individual accountable articles.
20.
MB2.2
.2.5
If individual article scanning is required by the QA frequency, when the user first
scans the bag, the bag manifest will be displayed on the screen allowing the
user to see the articles expected to be scanned out of the bag.
E
21.
MB2.2
.2.6
As the individual articles are scanned out of the bag, the screen shall refresh
indicating the items that have been received by a checkmark or some other
received indicator.
E
22.
MB2.2
.3
IPVS shall accept scans from bar code scanners for bag scans. E
23.
MB2.2
.4
When RFID is enabled, IPVS shall accept read events from RFID readers for bag
scans.
D
Creating Outbound Bags of Accountable Mail
24. MB2.3
IPVS shall allow users to capture data about outbound accountable mail bags
being created at the facility.

25.
MB2.3
.1
IPVS shall prompt the user to enter the bag destination. E
26.
MB2.3
.2
IPVS shall tie origin, destination, and date created information to the unique bag
bar code generated/printed by the system
E
27.
MB2.3
.3
IPVS shall allow users to nest individual articles into unique bar coded bags by
scanning the new bag bar code and then the individual articles.

28.
MB2.3
.3.1
IPVS shall allow users to scan the standard 2-9-2 article bar code. E
29.
MB2.3
.3.2
IPVS shall allow users to scan the new item bar code E
30.
MB2.3
.3.3
When the new bar code is scanned when nesting the articles into the bag, if the
PIN code does not match the destination PIN codes of the intelligent bag tag,
IPVS shall throw an audible and visual alert to the user informing them the
destination of the bag does not match the destination of the item.
E
31.
MB2.3
.4
IPVS shall allow user to Close the bar coded bag by again scanning the bag bar
code after scanning individual articles into the bag.
E
32.
MB2.3
.5
IPVS shall allow user to associate bag bar code with bag RFID tag by scanning the
bag bar code then the RFID tag bar code.
D
33.
MB2.3
.5
IPVS shall accept the scans of the individual articles into bags as en route events
for the individual article scanned.
E
34.
MB2.3
.6
IPVS shall record the type of bag
35.
MB2.3 IPVS shall pop up a list of types of receptacles on the screen at the scan of a bag
E
.6.1 tag
36.
MB2.3
.6.2
IPVS shall not allow the user to proceed before the type of bag is chosen E
37.
MB2.3
.6.3
IPVS shall link the type of bag with the bag barcode E
38.
MB2.3
.6.4
IPVS shall maintain record of all nested bags in case of a T bag E
Creating Outbound Bags of Ordinary Mail
39. MB2.4
IPVS shall allow users to capture data about outbound ordinary mail bags being
created at the facility.

40.
MB2.4
.1
IPVS shall prompt the user to enter the bag destination. E
41.
MB2.4
.2
After placing the bag on the weigh scale, the user shall be prompted to scan the
unique EB 2-9-2 bar code on the bag to capture the associated weight for the
origin/destination combination.
E
42.
MB2.4
.3
IPVS shall record the type of bag
43.
MB2.4
.3.1
IPVS shall pop up a list of types of receptacles on the screen at the scan of a bag
tag
E
44.
MB2.4
.3.2
IPVS shall not allow the user to proceed before the type of bag is chosen E
45.
MB2.4
.3.3
IPVS shall link the type of bag with the bag barcode E
46.
MB2.4
.3.4
IPVS shall maintain record of all nested bags in case of a T bag E
Transmission Scanning
47. MB2.5 IPVS shall use in-transmission scans for en route events for unique articles.
48.
MB2.5
.1
After placing the bag on the weigh scale, the user shall scan the bag bar code to
capture the associated weight.
E
49.
MB2.5
.2
If the terminal does not have a connected weigh scale, the user shall be able to
enter the weight and then scan the bag bar code to have the associated weight
automatically captured.
E
50.
MB2.5
.3
IPVS shall accept scans of bags with associated nested articles as en route
events for the individual articles associated with the scanned bag.

51.
MB2.5
.3.1
IPVS shall accept scans from bar code scanners for bag scans. E
52.
MB2.5
.3.2
IPVS shall accept events from RFID readers for bag scans. D
53.
MB2.5
.4
IPVS shall accept scans of individual articles into transmission containers as en
route events for the individual article scanned.
E
54.
MB2.5
.5
IPVS shall accept tracking events from the WMS for articles/shipments moving
out of DoP warehouses.
E
55.
MB2.5
.6
IPVS shall accept tracking events from the TMS for articles/shipments tracked
within the TMS.
E
56.
MB2.5
.7
IPVS shall interface with Rail Carrier systems to collect bag ETAs for associated
bags
D
57.
MB2.5
.8
IPVS shall interface with Air Carrier systems to collect bag ETAs for associated
bags
D
Delivery Scanning from DPMS
58. MB2.6
IPVS shall interface with Delivery & Postman Management System to receive
delivery-related events.

59.
MB2.6
.1
IPVS shall interface with delivery scanning solutions for attempted delivery
events for unique articles.
E
60.
MB2.6
.2
IPVS shall send receiver estimated delivery time SMS (if requested in the Mail
Booking Engine) when received at delivery office event received for the article.
E
61.
MB2.6
.3
IPVS shall interface with delivery scans for actual delivery events for unique
articles.
E
62.
MB2.6
.4
IPVS shall send sender actual delivery confirmation SMS (if requested in the Mail
Booking Engine) when delivery event received for the article.
E
63.
MB2.6
.5
IPVS shall interface with DPMS to accept digital signature images for association
to unique articles as delivery confirmation events.
E
64.
MB2.6
.6
IPVS shall interface with DPMS to receive Return to Sender notifications
requiring a new reverse record in IPVS for domestic as well as international mail
E
Capturing Employee Work Hour Information
65. MB2.7 IPVS shall capture employee work hour information.
66.
MB2.7
.1
IPVS shall interface with the Mail Booking Engine to upload retail counter
employee work hour details.
E
67.
MB2.7
.2
IPVS shall record mail processing employee work hour details.
68.
MB2.7
.2.1
In facilities where employee badge swipe or biometric machines are available,
IPVS shall use badge swipes or biometric readings to record employee work
hour details.
D
69.
MB2.7
.2.2
In facilities where employee badge swipe or biometric machines are not
available, IPVS shall provide a means by which the supervisors or users can
manually record employee work hour details in the system.
E
70.
MB2.7
.3
IPVS shall record transmission office employee work hour details.
71.
MB2.7
.3.1
In transit mail offices where employee badge swipe or biometric machines are
available, IPVS shall use badge swipes or biometric to record employee work
hour details.
D
72.
MB2.7
.3.2
In transit mail offices where employee badge swipe or biometric machines are
not available, IPVS shall provide a means by which the supervisors or users can
manually record employee work hour details in the system.
E
73.
MB2.7
.4
IPVS shall interface with the Delivery and Postman Management solution to
upload postman work hour details.
E
Customer Article Visibility
74. MB2.8 IPVS shall present article visibility events to customers.
75.
MB2.8
.1
IPVS shall provide a means by which DoP resources can research all visibility
events.
E
76.
MB2.8
.2
IPVS shall have configurable flags for each product type that indicates which
events are visible to customers through IPVS.

77.
MB2.8
.2.1
IPVS shall provide customers the ability to research tracking events recorded
throughout the network.
E
78.
MB2.8
.2.1.1
IPVS shall provide tracking event data to customers in on-line research format. E
79.
MB2.8
.2.1.2
IPVS shall provide tracking event data to DoP Call Centre for customer call-in
research capability.
E
Overall Network Volume Visibility
80. MB2.9 IPVS shall capture volume information throughout postal operations.
81.
MB2.9
.1
IPVS shall interface with Mail Booking Engine to capture volume originating at
each post office.

82.
MB2.9
.1.1
IPVS shall capture post office volume information by product type. E
83.
MB2.9
.1.2
IPVS shall capture post office volume information by origin/ destination
combination
E
84.
MB2.9
.2
IPVS shall capture volume information at all mail processing facilities.
85.
MB2.9 IPVS shall capture volume information for accountable product types by
E
.2.1 summarizing scan events.
86.
MB2.9
.2.2
IPVS shall capture volume information for non-accountable product types by
accepting weight measurements from connected scales.
E
87.
MB2.9
.2.3
For facilities with scales not connected to an IPVS workstation, IPVS shall
capture volume information for non-accountable product types by allowing
users to enter the weight displayed by the scale into the IPVS workstation for
the unique bag bar code.
E
88.
MB2.9
.2.4
IPVS shall capture mail processing volume information by product type. E
89.
MB2.9
.2.5
IPVS shall capture mail processing volume information by origin/ destination
combination.
E
90.
MB2.9
.3
IPVS shall capture volume information in transit mail offices.
91.
MB2.9
.3.1
IPVS shall capture transmission volume information through bag scan events at
offices that have handheld scanners.
E
92.
MB2.9
.3.2
IPVS shall capture transmission volume information through weigh scales
connected to the IPVS terminal.
E
93.
MB2.9
.3.3
For sites with no handheld scanner or connected weigh scale, the IPVS terminal
shall allow users to enter counts of bags being transmitted.
E
94.
MB2.9
.3.4
IPVS shall capture transmission volume information by product type. E
95.
MB2.9
.3.5
IPVS shall capture transmission volume information by origin/ destination
combination.
E
96.
MB2.9
.4
IPVS shall interface with the Delivery and Postman Management System to
capture destination post office volume information.

97.
MB2.9
.4.1
IPVS shall capture delivery volume information by product type. E
98.
MB2.9
.4.2
IPVS shall capture delivery volume information by postman beat. E
Processing International Mail Articles
99.
MB2.1
0
IPVS shall allow for additional processing for international mail articles.
100.
MB2.1
0.1
IPVS shall generate UPU-standard receptacle labels for mail bags destined for a
Foreign Postal Administration (FPA).
(http://www.upu.int/standards/en/s8_and_s9_user_guide_on_postal_despatch
es-postal_receptacles_en.pdf)

101.
MB2.1 IPVS shall scan outbound items out into bags using the same process as
E
0.1.1 domestic item scanning.
102.
MB2.1
0.1.2
The international receptacle label shall contain the UPU-standard 29-character
receptacle bar code.
E
103.
MB2.1
0.1.3
The international receptacle label shall contain the assigned transportation
information for the bags routing from origin to destination.
E
104.
MB2.1
0.1.4
The international receptacle label shall contain the F-bag identifier if the bag is
the final bag for the days dispatch.
E
105.
MB2.1
0.1.5
IPVS shall generate UPU required forms & paperwork for each bag. E
106.
MB2.1
0.2
IPVS shall generate UPU-standard EDI messages for outbound volume.
(http://www.upu.int/)

107.
MB2.1
0.2.1
IPVS shall generate required PREDES messages for dispatches. E
108.
MB2.1
0.2.2
IPVS shall generate required PRECON messages for consignments. E
109.
MB2.1
0.2.3
IPVS shall generate required CARDIT messages for consignments. E
110.
MB2.1
0.2.4
IPVS shall calculate terminal dues for dispatched volume. E
111.
MB2.1
0.3
IPVS shall receive UPU-standard EDI messages for inbound mail volume.
(http://www.upu.int/)

112.
MB2.1
0.3.1
IPVS shall translate data from FPAs PREDES messages to generate internal IPVS
data for reconciliation when volume arrives.
E
113.
MB2.1
0.4
IPVS shall allow data entry of inbound receptacles.
114.
MB2.1
0.4.1
IPVS shall scan receptacle labels from FPAs. E
115.
MB2.1
0.4.2
IPVS shall scan inbound items out of bags using the same process as domestic
item scanning.
E
116.
MB2.1
0.5
IPVS shall generate UPU-standard EDI messages for received inbound volume.
117.
MB2.1
0.5.1
IPVS shall generate required RESDES messages for received dispatches. E
118.
MB2.1
0.5.2
IPVS shall generate required RESCON messages for received consignments. E
119.
MB2.1
IPVS shall generate required RESDIT messages for dispatches received. E
0.5.3
120.
MB2.1
0.5.4
IPVS shall generate terminal dues for received volume. E
121.
MB2.1
0.6
IPVS shall auto-generate electronic Verification Notes (VN) for FPAs when
discrepancies are identified between FPA PREDES versus received receptacles.

122.
MB2.1
0.6.1
IPVS shall provide users capabilities to further research auto-generated VNs
through querying IPVS data.
E
123.
MB2.1
0.7
IPVS shall provide users the ability to create manual VNs for additional
discrepancies not automatically identified within IPVS (i.e. terminal dues
mismatch, incorrect rates, incorrect weights, etc.)
E
124.
MB2.1
0.8
The system shall capture the details of the parcels at the dispatching office of
exchange on a CP87 bill
E
125.
MB2.1
0.9
The system shall send entries for bulk in the CP87 parcel bill to the destination
administration
E
126.
MB2.1
0.10
The system shall inform origin administration in case of seizure of wrongly
admitted parcel
E
127.
MB2.1
0.11
The system shall prepare a CP78 verification note for parcels retained due to
damage or theft
CP78 verification note
CN24 Report
E
128.
MB2.1
0.12
The system shall interface with international systems to send the electronic
proof of delivery (image file with signature) received from DPMS
E
Creating and Opening Transit Bags
129.
MB2.1
1
IPVS shall allow the user to create and open transit bags to and from other mail
offices/post offices with other bags nested inside.

130.
MB2.1
1.1
IPVS shall allow the user to create transit bags with other bags nested inside.
131.
MB2.1
1.1.1
The user shall build all the inside bags using the normal procedure before
building a transit bag.
E
132.
MB2.1
1.1.2
Once the user selects the option to create the outer transit bag, the system shall
prompt the user to scan all inner bags.
E
133.
MB2.1
1.1.3
After all inner bags have been scanned, the user shall scan the outer bag to
complete the transit bag creation.
E
134.
MB2.1
1.1.4
The system shall validate that the destinations of all of the inner bags match. E
135.
MB2.1
1.1.5
Throughout the rest of the network, any time an outer transit bag is scanned, all
articles associated with one of the nested inner bags shall receive an en route
E
scan event.
136.
MB2.1
1.2
IPVS shall allow the user to open transit bags with other bags nested inside.
137.
MB2.1
1.2.1
IPVS shall allow users to scan the nested bags out of the transit bag. E
138.
MB2.1
1.2.2
IPVS shall allow users to scan the individual articles out of the nested bags. E
Creating Bulk Delivery Bags
139.
MB2.1
2
IPVS shall provide delivery office users the ability to create bags for delivery of
bulk articles to a single customer.

140.
MB2.1
2.1
The user shall select the customer name of the bulk delivery and scan the
articles for that customer.
E
141.
MB2.1
2.1.1
If the customer name does not already exist for the office, the user shall enter
the name to be stored for later use.
E
142.
MB2.1
2.2
The user shall then scan all articles going into the customers bulk delivery bag. E
143.
MB2.1
2.3
Once all articles have been scanned, the user shall scan the unique EB 2-9-2 bar
code on the bag.
E
End-of-Day Reports Created in IPVS
144.
MB2.1
3
IPVS shall provide several end-of-day reports.
145.
MB2.1
3.1
IPVS shall provide a detailed articles received report. E
146.
MB2.1
3.2
IPVS shall provide a detailed articles dispatched report. E
147.
MB2.1
3.3
IPVS shall provide a detailed discrepancy report between articles received and
articles dispatched.
E
148.
MB2.1
3.4
IPVS shall provide a detailed discrepancy report between articles expected and
articles actually received.
E
149.
MB2.1
3.5
IPVS shall provide a detailed volume received report. E
150.
MB2.1
3.6
IPVS shall provide a detailed volume dispatched report. E
151.
MB2.1
3.7
IPVS shall provide a detailed discrepancy report between volume received and
volume dispatched.
E
152.
MB2.1 IPVS shall provide a detailed discrepancy report between volume expected and
E
3.8 volume actually received.
153.
MB2.1
3.9
IPVS shall provide a per person IPVS usage/productivity report. E
Transferring Contents of One Bag into Another Bag
154.
MB2.1
4
IPVS shall provide functionality to systemically transfer all data related articles
associated with one bag into another bag.

155.
MB2.1
4.1
The user shall first scan the transferring bag then scan the bag into which the
articles are being transferred to complete this action.
E
156.
MB2.1
4.2
If the bag into which the articles are being transferred already has associated
articles/destination, IPVS shall validate that the destination of the transferring
bag matches that of the destination bag.
E
Air Carrier Payment Calculation
157.
MB2.1
5
IPVS shall centrally calculate payment amounts for mail transported by air
carriers.

158.
MB2.1
5.1
IPVS shall maintain contract requirements for agreements with air carriers
transporting DoP mail volumes.

159.
MB2.1
5.1.1
IPVS shall maintain data containing price per kg/bag of mail assigned to each air
carrier.
E
160.
MB2.1
5.1.2
The rates must be maintained at a level flexible enough to allow the following:
Different carriers can have different rates
Different lanes (origin/destination) can have different rates
E
161.
MB2.1
5.2
IPVS shall calculate payment due to each carrier once per day for the prior day
and any prior days that had late arriving data that has not been paid.

162.
MB2.1
5.2.1
Payment shall be calculated using the rate per kg/bag and multiplying by the
associated rates.
E
163.
MB2.1
5.2.2
Every bag that has been paid shall be marked in the system as paid. E
164.
MB2.1
5.2.3
In the case that a local scanner has not transmitted its data in time for the next-
day calculation, the system shall be able to look back at unpaid records and
include their payment in the payment calculated on the day it was received.
E
165.
MB2.1
5.3
IPVS shall have the ability to turn on an interface of calculated payment by air
carrier to the Accounts Payable solution.

166.
MB2.1
5.3.1
Payment details shall include kg/bags moved from each origin that were paid in
this payment.
E
167.
MB2.1
5.3.2
The system shall also send the rates used for the payments. E
Confirming Article Counts Associated with MLASS Appointments
168.
MB2.1
6
IPVS shall provide the capability to scan inbound bulk articles against an
appointment ID entered by the IPVS user that was created out by MLASS.

169.
MB2.1
6.1
IPVS shall capture the total count of articles associated with the MLASS
appointment.
D
170.
MB2.1
6.2
IPVS shall have an outbound interface to MLASS to send article counts related to
the MLASS appointment IDs.
D
Alerting/Escalation Capability
171.
MB2.1
7
IPVS shall provide alerting/escalation capabilities for exception articles or bags.
172.
MB2.1
7.1
IPVS shall display alerts on a management console/dashboard for articles that
receive a scan in a facility that is not along the articles expected path based on
reference data showing routings for each origin/destination combination
(missorted articles).
E
173.
MB2.1
7.2
IPVS shall display alerts on a management console/dashboard for articles that
have not received a scan after a configurable amount of time after their
expected arrival at the next destination, but articles that were associated with
the same bag have received scans (lost articles).
E
174.
MB2.1
7.2.1
If IPVS later receives a scan event for a lost article, the alert shall still be
maintained in the system to later identify temporarily lost articles, but the lost
article should no longer be displayed on the management console/dashboard.
E
175.
MB2.1
7.3
IPVS shall display alerts on a management console/dashboard for entire bags
that receive a scan in a facility that is not along the bags expected path based
on reference data showing routings for each origin/destination combination
(misrouted bags).
E
176.
MB2.1
7.4
IPVS shall display alerts on a management console/dashboard for entire bags
that have not received a scan after a configurable amount of time after their
expected arrival at the next destination (lost bags).
E
177.
MB2.1
7.4.1
If IPVS later receives a scan event for a lost bag, the alert shall still be
maintained in the system to later identify temporarily lost bags, but the lost
bag should no longer be displayed on the management console/dashboard.
E
178.
MB2.1
7.5
IPVS shall provide a configurable escalation mechanism where certain
configurable alert thresholds can trigger escalation of alerts to specific e-mail
addresses or SMS mobile numbers.
E
179.
MB2.1
7.5.1
Escalation thresholds shall include the following:
Late bags (ability to group and filter by origin locations)
Misrouted bags (ability to group and filter by origin locations)
Lost bags (ability to group and filter by origin locations)
E
Configurable number of lost articles (ability to group and filter by origin
locations)
Configurable number of misrouted articles (ability to group and filter by origin
locations)
Recording of Articles Damaged in Processing
180.
MB2.1
8
IPVS shall allow the user to record a scan event for a damaged article. E
Monitoring of Railways Transit Section
181.
MB2.1
9
IPVS shall have the facility to provide report on the usage of Railways Transit
section

182.
MB2.1
9.1
IPVS shall have the feature to record the running status of transit section at the
origin of that section
D
183.
MB2.1
9.2
IPVS shall have the feature to record the arrival status of transit section at the
destination of that section
D
184.
MB2.1
9.3
IPVS shall have the facility to generate a status report of various transit sections
(cancelled or otherwise) for a specified period. This shall be used for verification
of the bills sent by the Railways
D
185. MBE
IPVS shall have an inbound interface from the MBE that loads Booked events
for accountable articles into IPVS so that expected downstream events can be
tracked against the article as the article physically moves through the network
and receives downstream tracking scans/events
E
186. DPMS
IPVS shall have an outbound interface to the DPMS that will share electronic
manifests of the bags heading to the Delivery Post Offices. IPVS shall have an
inbound interface from the DPMS that loads postman beat volumes and
Attempted Delivery/Delivery events from the postman scans/entries.
E
187. WMS
IPVS shall have an inbound interface for tracking events for articles moving out
of warehouse.
E
188. TMS IPVS shall have an inbound interface for tracking events captured within TMS E
189. MLASS
IPVS shall have an outbound interface to MLASS to send article counts related to
an MLASS appointment ID
E
190. LSS
IPVS shall have an outbound interface to send LSS actual employee work hours
captured within IPVS for comparison against the planned hours in LSS
E
191. HRMS
number and value of operations/ transactions happening at each establishment.
The customized interface designed for this purpose shall draw data for four
calendar months, from the data warehouse in the form of MIS reports. IPVS
E
shall ensure that this detail is stored in the data warehouse on a monthly basis
192. EDI
IPVS shall have an outbound and inbound interface for EDI messages exchanged
between DoP and Foreign Postal Administrations, Airlines, Customs etc.
E
193.
ECM
(PBS/P
LI SI)
IPVS shall have an outbound interface with ECM to send international
documents generated/received
E
194. IM
IPVS shall have an outbound interface with Inventory Management to pass on
the information pertaining to the bags throughout the supply chain
E
195.
Air
Carrier
s
IPVS shall have an inbound interface with external agencies such as Air carriers
to receive the bag related information for tracking purpose. IPVS shall receive
bag scan information when the consignments are loaded onto the flight and
unloaded from the flights.
D
196. Others
IPVS shall have interface with sorting machines deployed at DoP for mail
sortation purpose
D
8.4.1.3 Delivery & Postman Management
The Delivery and Postman Management System shall enable DoP to keep track of delivery post office
volume and performance of mail articles that pass through the premises. The system shall track
incoming accountable articles and mail volumes and allow for workload balancing in a shift and
between shifts enabling faster turn-around within the facility. For articles that require
acknowledgements or copies to be delivered to the recipient, copies shall be printed at the delivery
post office and the signed copies scanned and uploaded as proof of delivery.
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

Delivery & Postman Management Capabilities
1. MB4.1 DPMS shall provide delivery and postman management capabilities
Presenting Expected Work Load
2. MB4.2 DPMS shall create an expected work load status report for each day or shift.
3.
MB4.2
.1
DPMS report shall populate the list of expected accountable articles booked for
the area under a particular delivery office
E
4.
MB4.2
.1.1
For each expected accountable article, the system shall display the expected
time of arrival at the delivery office.
E
5.
MB4.2
DPMS shall display the volume of incoming ordinary mail bags. E
.2
6.
MB4.2
.3
DPMS shall provide scheduled pick-ups (customer requested specific time) to be
assigned to the postmen.
D
7.
MB4.2
.4
DPMS shall provide expected route pick-ups (customer just requested pickup on
beat) for each postman.
D
Capturing Data on Inbound Mail Items/Volume
8.
MB4.3
.1
DPMS shall scan the incoming ordinary mail bags on receipt (when RFID is
enabled, scanning/reading shall be done through RFID)
E
9.
MB4.3
.2
DPMS shall scan the incoming accountable mail bags on receipt E
10.
MB4.3
.3
DPMS shall use a configurable (by site) QA frequency value that indicates when
the user must scan each article in the accountable bag individually upon receipt
(i.e. every 5
th
bag, every 10
th
bag, every bag, etc.).
E
11.
MB4.3
.4
System shall have the functionality to scan the incoming bags through RFID
system, when RFID is deployed at facilities
D
Beat Level Sorting Data Capture/Holds/Beat Slips
12. MB4.4
DPMS shall capture details about articles per beat through article scanning and
user entry.

13.
MB4.4
.1
After beat level sorting is complete, DPMS shall allow the user to scan
accountable articles that are to be held in the office based on customer
requests.
E
14.
MB4.4
.2
After Hold articles are recorded, DPMS shall allow the user to scan each
accountable article for creation of the postmans beat slip.

15.
MB4.4
.2.1
If the postman is removing any held articles from Hold status to include them
on that days beat, DPMS shall simply allow the user to scan the held articles
while scanning the rest of the articles for the beat slip.
E
16.
MB4.4
.2.2
DPMS shall create a beat slip for each postman that sequentially (alphabetically
then numerically) lists each accountable article for the beat including the
following per article:
Printed bar code of the article
Human readable number of the bar code
Space for postman to record time of delivery/attempted delivery
Space for recipients printed name
Space for recipients signature (N/A if signature not required for that article
E
17.
MB4.4
.3
After all beat slips have been created, DPMS shall provide functionality where
the supervisor can view the discrepancies between the expected manifests and
the actual accountable articles received across all office postmen.
E
18.
MB4.4
.4
DPMS shall capture the number of Business Reply Mail pieces per mailer. E
19.
MB4.4
.5
DPMS shall capture the number of Speed Post Value Payable pieces per
postman after beat sorting.
E
20.
MB4.4
.5.1
When the user enters the number of Speed Post Value Payable pieces per
postman, the system shall also capture the total value of the pieces.
E
21.
MB4.4
.6
DPMS shall capture the total number of ordinary mails per postman after beat
sorting.
E
22.
MB4.4
.7
DPMS shall calculate the total number of accountable articles based on the beat
slip creation scanning.
E
23.
MB4.4
.8
For bulk delivery bags, the user shall scan the bag before taking the bag out for
delivery to indicate all the contents in the bag are being delivered.
E
On-Beat Delivery Scanning, Data Entry, and Window Delivery
24. MB4.5
DPMS shall allow delivery scanning on the beat or at the post office window
through the use of a handheld scanning device.

25.
MB4.5
.1
The device shall allow the user to scan individual accountable articles when they
are delivered.
E
26.
MB4.5
.1.1
The device shall record the time the scan is performed as the time of delivery (I
scan event).
E
27.
MB4.5
.1.2
If proof of delivery is required, the device shall prompt the user to enter the first
initials and full last name of the recipient. It should provide the addressee name;
however, it should also have an option of overriding the same as the recipient
may be different.
E
28.
MB4.5
.1.3
If proof of delivery is required, the device shall provide the capability of taking
an image of the signature on a signed delivery confirmation form for e-Proof-of-
Delivery.
E
29.
MB4.5
.1.3.1
The device shall similarly provide the capability for the recipient to sign on-
screen for e-Proof-of-Delivery.
E
30.
MB4.5
.2
If the article cannot be delivered, the device shall allow the user to scan
individual accountable articles as attempted delivery.
E
31.
MB4.5
.2.1
The device shall record the time the scan is performed as the time of attempted
delivery (H scan event).
E
32.
MB4.5
.3
All data recorded on the beat shall be stored on the device until the data has
been synced to the server in the office.
E
33.
MB4.5
.4
The device shall transmit data collected on beat once it is cradled back at the
office or wirelessly connected.
E
34.
MB4.5
.5
For articles requiring payment collection when delivered, the DPMS shall
capture information relating to the payment.

35.
MB4.5
.5.1
The system shall capture the article ID that is being paid. E
36.
MB4.5
.5.2
The system shall capture the amount of cash collected. E
37.
MB4.5
.5.3
The system shall have an outbound interface to Accounts Receivable confirming
that the article has been paid to clear the amount outstanding.
E
Post-Beat Delivery Scanning and Data Entry
38. MB4.6
DPMS shall allow delivery scanning after the postman has returned from the
beat through the use of a handheld scanning device and their completed beat
slip if the postman did not have a device on their beat.

39.
MB4.6
.1
The device shall allow the user to scan individual accountable articles from their
beat slip to record their delivery (I scan event).
E
40.
MB4.6
.1.1
The device shall prompt the user to enter the time the article was delivered
according to the beat slip.
E
41.
MB4.6
.1.2
If proof of delivery is required, the device shall prompt the user to enter the first
initials and full last name of the recipient. It should provide the addressee name;
however, it should also have an option of overriding the same as the recipient
may be different.
E
42.
MB4.6
.1.3
If proof of delivery is required, the device shall prompt the user to take an
image of the signature with the device from the signed beat slip for e-Proof-of-
Delivery.
E
43.
MB4.6
.2
If the article could not be delivered on the beat, the device shall allow the user
to scan individual accountable articles as attempted delivery.
E
44.
MB4.6
.2.1
The device shall record the time the scan is performed as the time of attempted
delivery (H scan event).
E
45.
MB4.6
.3
All data recorded shall be stored on the device until the data has been synced to
the server in the office.
E
46.
MB4.6
.4
The device shall transmit data collected it is cradled or wirelessly connected. E
47.
MB4.6
.5
For articles requiring payment collection when delivered, the DPMS shall
capture information relating to the payment.

48.
MB4.6
.5.1
The system shall capture the article ID that is being paid. E
49.
MB4.6
.5.2
The system shall capture the amount of cash collected. E
50.
MB4.6
.5.3
The system shall have an outbound interface to Accounts Receivable confirming
that the article has been paid to clear the amount outstanding.
E
51.
MB4.6
.6
The system shall display articles that have been in the office longer than a
configurable number of days.
E
52.
MB4.6
.6.1
If the original sender requested Return Service for the article, the system shall
allow the user to scan the article and create a new record in the tracking
database with the same bar code for the returning article.
E
End-of-Day Reports
53. MB4.7 DPMS shall provide several end-of-day reports.
54.
MB4.7
.1
DPMS shall summarize the scan compliance of the articles due for delivery that
day (expected Delivery scans vs. Delivery and Attempted Delivery actuals).
E
55.
MB4.7
.2
DPMS shall display all items currently on hold in the office. E
56.
MB4.7
.2.1
DPMS shall display how long the held items have been on hold. E
57.
MB4.7
.3
DPMS shall display undeliverable articles in the office (those with an Attempted
Delivery but no successful Delivery event).

58.
MB4.7
.3.1
DPMS shall display articles that have been in the office longer than a
configurable number of days.
E
59.
MB4.7
.3.2
DPMS shall display articles that are in the office with more than a configurable
number of Attempted Delivery events.
E
Capturing Employee Work Hours
60. MB4.8 DPMS shall capture employee work hours.
61.
MB4.8
.1
DPMS shall provide the user the ability to record their shift begin time. E
62.
MB4.8
.2
DPMS shall provide the postmen the ability to record when they leave to go on
their beat.
E
63.
MB4.8
.3
DPMS shall provide the postmen the ability to record when they return from
their beat.
E
64.
MB4.8
.4
DPMS shall provide the user the ability to record their shift end time. E
65.
MB4.8
.5
DPMS shall provide the supervisors the ability to make updates to employee
shift begin/end times.
E
Data Transmission to IPVS
66. MB4.9 DPMS shall interface with IPVS.
67.
MB4.9
.1
DPMS shall interface with IPVS to send article tracking information captured in
DPMS.
E
68.
MB4.9
.2
DPMS shall interface with IPVS to send inbound mail volumes captured in DPMS. E
69.
MB4.9
.3
DPMS shall interface with IPVS to send employee work hour details captured in
DPMS.
E
70.
MB4.9
.4
DPMS shall interface with IPVS to receive inbound bag manifests captured in
IPVS for validation through DPMS.
E
71.
MB4.9
.5
DPMS shall interface with IPVS to send electronic proof of delivery for
international mail
E
International-Specific Notifications
72.
MB4.1
0
DPMS shall allow electronic capture of international-specific notifications.
73.
MB4.1
0.1
The system shall provide for an electronic form CN24 in case the article is
damaged or rifled.
E
74.
MB4.1
0.2
The system shall enable an office to give the reason for non delivery on an
electronically generated CN15 form.
E
Printing ePost Articles
75.
MB4.1
1
DPMS shall allow a user to print ePost items to be delivered by their office or
their associated smaller offices.

76.
MB4.1
1.1
DPMS shall receive an inbound interface from the Mail Booking Engine for ePost
articles that are to be printed for the receiving customer.
E
77.
MB4.1
1.2
DPMS shall print the recipients name and address on the ePost article. E
78.
MB4.1
1.3
DPMS shall print the senders name on the ePost article. E
Printing Online or Phone Booked Article Labels before the Beat
79.
MB4.1
2
DPMS shall have an inbound interface from the Mail Booking Engine to receive
details of articles that were booked online or over the phone prior to the
postman going on the beat that require an article label.

80.
MB4.1
2.1
DPMS shall display the expected pickup articles requiring a printed label to the
in-office clerk sorter performing the original beat-level sorting.
D
81.
MB4.1
2.1
DPMS shall allow the user to print all expected pickup labels so that the labels
can be sorted to the individual postman beats.
D
82.
MB4.1
2.2
The labels shall include the following information:
Sender Name
D
Sender Address
Recipient Name
Recipient Address
Postage Due
Unique Article Bar Code and Human Readable ID
83.
MB4.1
2.3
Printing the bar code label shall trigger the transfer of data back to DPMS and
the creation of the booking event in the system that shall be sent to IPVS.
D
84.
MB4.1
2.3.1
DPMS shall include booking events for pickup articles in the outbound interface
to IPVS with delivery events.
D
85.
MB4.1
2.4
Upon return to the office, the system shall provide a mechanism for the
postman to reconcile the cash collected for the pickup articles.
E
Printing Online or Phone Booked Article Bar Code Labels on the Beat
86.
MB4.1
3
DPMS shall have an inbound interface from the Mail Booking Engine to receive
details of articles that were booked online or over the phone prior while the
postman is on the beat for pickup at a location on the postmans remaining
beat.

87.
MB4.1
3.1
The device shall display the SMS received from the Mail Booking Engine with the
pickup location information.
D
88.
MB4.1
3.1.1
The device shall add the pickup location and details to the device database so
the user can easily reference the required pickups.
D
89.
MB4.1
3.2
When the postman selects the pickup record after arriving at the pickup
location, the system shall display the amount of postage due for the article.
D
90.
MB4.1
3.3
When the postman has confirmed receipt of cash payment, the system shall
print the bar code label to be affixed to the already addressed package.
D
91.
MB4.1
3.4
Printing the bar code label shall trigger the transfer of data back to DPMS and
the creation of the booking event in the system that shall be sent to IPVS.
D
92.
MB4.1
3.4.1
DPMS shall include booking events for pickup articles in the outbound interface
to IPVS with delivery events.
D
93.
MB4.1
3.5
Upon return to the office, the system shall provide a mechanism for the
postman to reconcile the cash collected for the pickup articles.
E
Delivering Money Orders
94.
MB4.1
4
The system shall enable the office to dispense Money Orders.
95.
MB4.1
4.1
The Type 2 MO transaction (money available for pickup at any connected Post
Office) should be accessible across the country for payout.
E
96.
MB4.1 The MO transactions to be delivered to a doorstep shall appear in the delivery
E
4.2 branch queue of MO payments to be made on that day.
97.
MB4.1
4.2.1
System should be able to print the individual MO request with all the details. E
98.
MB4.1
4.2.2
System should be able to generate a Bar Code containing the original unique ID
on the printed MO request.
E
99.
MB4.1
4.2.3
The system shall be able to generate a unique bar code as per the format
specified compatible with DPMS (13 character code 2 character for money
order product code MO, 9 digits for unique number generated and last 2
character would be IN)
E
100.
MB4.1
4.3
The system shall reconcile paid Money Orders through a Delivery scan of the
MO bar code.
E
101.
MB4.1
4.4
System shall allow the destination branch to Return the MO transaction from its
queue to the sender in case the beneficiary does not exist/relocated to
unknown address.
E
102.
MB4.1
4.4.1
The system shall generate an SMS informing the sender of the return. D
103.
MB4.1
4.5
System shall allow the destination Branch to Redirect the MO transaction to
another delivery branch which is closer to the Beneficiary destination.
E
104.
MB4.1
4.5.1
The system shall generate an SMS informing the sender and beneficiary of the
redirection to a different office/address.
D
105.
MB4.1
4.6
If the Money Order has not been collected within 5 months, the system shall
send an SMS informing the sender and beneficiary that the Money Order has
still not been collected.
D
106.
MB4.1
4.7
The system shall send another SMS to the sender and beneficiary 2 weeks
before the 6 month expiration period if the Money Order has still not been
collected.
D
107.
MB4.1
4.8
The system shall send a final SMS to the sender and beneficiary once the 6
month expiration period has ended for the sender to come back to the
originating office and collect the funds.
D
Recording a Redirected Article
108.
MB4.1
5
The system shall allow postmen to record a scan event when the article needs
to be redirected to a new address because the recipient has moved.
E
109.
MB4.1
5.1
The system shall require the postman to enter the new address so that the
system can maintain where the article was redirected for customer complaint
management.
E
Dues Collection
110.
MB4.1
DPMS shall enable collection of dues from recipients
6
111.
MB4.1
6.1
DPMS shall enable creation of daily list of dues to be collected (due postage,
customs duty)
E
112.
MB4.1
6.2
DPMS shall facilitate data entry confirming collection of due postage at the end
of day
E
113.
MB4.1
6.3
For international mail, DPMS shall indicate the customs duty to be collected
from the recipient
E
114.
MB4.1
6.4
DPMS shall have an outbound interface to Accounts confirming the dues
collected under various heads
E
115. MBE
DPMS shall have an inbound interface from the MBE to receive the retail
customer pickup requests to be incorporated with Postmen beats (data
including customers pick up address, type of service, postage due). It shall also
have an inbound interface from the MBE to receive individual customer article
pickup requests that require the postman to print a label before their beat or
while on their beat.
E
116. IPVS
DPMS shall have an inbound interface from IPVS to receive inbound mail
volumes, inbound bag manifests, and inbound accountable article information.
DPMS shall have an outbound interface to IPVS to send article tracking events
(including captured signature if required) and employee work hour information.
E
117. AR
DPMS shall have an outbound interface with AR module to update the Business
Reply Mail customer accounts for the services provided to enable billing and to
record money collected for all successfully delivered payment due articles. This
module will also capture the type of Business Reply Mail opted for by the
customer based on which the charges shall be applied.
E
118. GL
DPMS shall have an outbound interface to the GL Solution to send all of the
cash-collection transactions for articles requiring payment on delivery.
E
119. HRMS
calendar months, from the data warehouse in the form of MIS reports. DPMS
shall ensure that this detail is stored in the data warehouse on a monthly basis.
E
8.4.1.4 Transportation Management System
The Transportation Management System for Mail Operations will enable DoP to manage its fleet of
vehicles that move the mails across the network. It will provide visibility into the day to day
operations, appointment schedules being met, volumes being handled and further recording the
data in electronic format to analyze the capacity utilizations. Furthermore, it will carry out the fleet
maintenance. TMS shall have the capability to track its vehicles at all times through technologies
such as RFID or GPS and will provide this input to the India Post Visibility Solution to provide
complete track and trace.
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

Managing Fleet of Vehicles
1. MB6.1 TMS shall manage the fleet of all vehicles owned by DoP.
2.
MB6.1.
1
TMS shall maintain a list of all vehicles owned by DoP. E
3.
MB6.1.
1.1
TMS shall register all the vehicles into the system. E
4.
MB6.1.
1.2
TMS shall maintain vehicle details (registration numbers, make, year) along
with the facility it belongs to.
E
5.
MB6.1.
2
TMS shall establish the overall fleet capacity of DoP.
6.
MB6.1.
2.1
TMS shall maintain a repository of available fleet capacity of DoP owned
vehicles for MMS.
E
7.
MB6.1.
2.2
TMS shall maintain a repository of available fleet capacity of
hired/contracted vehicles for MMS.
E
8.
MB6.1.
3
TMS shall review the transportation capacity requirements of DoP.
9.
MB6.1.
3.1
TMS shall assess the short-term transportation requirements (for the
immediate execution) based on the scheduling requests received.
E
10.
MB6.1.
3.2
TMS shall highlight any gaps in available capacity and the short-term
transportation requirements based on the scheduling requests received.
E
11.
MB6.1.
3.3
TMS shall assess the long-term transportation requirements based on the
business plans.
E
12.
MB6.1.
3.4
TMS shall highlight any gaps in available capacity and the long-term
transportation requirements based on the business plans.
E
13.
MB6.1.
4
TMS shall plan/manage the maintenance of the fleet.
14.
MB6.1.
4.1
TMS shall plan/manage the maintenance of DoP owned fleet.
15.
MB6.1.
4.1.1
TMS shall prepare a detailed maintenance plan for DoP owned fleet. E
16.
MB6.1.
4.1.2
TMS shall schedule this maintenance into the overall transportation
schedule.
E
17.
MB6.1.
4.1.3
TMS shall track the adherence to this maintenance plan by preparing a
planned versus actual report.
E
18.
MB6.1.
4.2
TMS shall review the maintenance of the hired/contracted vehicles.
19.
MB6.1.
4.2.1
TMS shall maintain a maintenance plan agreed with the contractor. D
20.
MB6.1.
4.2.2
TMS shall track the status of the maintenance plan for its implementation. D
21.
MB6.1.
4.2.3
TMS shall highlight non-adherence to the relevant authorities. D
Vehicle Tracking
22. MB6.2
TMS shall have the capability to later provide a telematics/GPS/RFID based
solution for track & trace purpose

23.
MB6.2.
1
For DoPs own vehicles, TMS shall provide telematics solution to capture the
various operating parameters
D
24.
MB6.2.
2
For the entire fleet (owned and hired) TMS shall have the functionality of
providing GPS/RFID based track & trace solution

25.
MB6.2.
2.1
TMS shall uniquely identify each vehicle through an RFID or GPS device D
26.
MB6.2.
2.2
For hired vehicles, TMS shall be able to provide a unique identifier to the
vehicle by loading a bag with RFID/GPS inside the vehicle
D
27.
MB6.2.
2.3
TMS shall provide the vehicle-wise report on deviation from the approved
route
D
Scheduling Vehicles
28. MB6.3
TMS shall schedule vehicles (pickup and delivery) as per the scheduling
requirements.

29.
MB6.3.
1
TMS shall receive scheduling requirements. E
30.
MB6.3.
2
TMS shall review the vehicle availability. E
31.
MB6.3.
3
TMS shall incorporate the maintenance plan into the vehicle scheduling. E
32.
MB6.3.
4
TMS shall allocate vehicles to various routes as per the optimized schedule. E
33.
MB6.3.
5
TMS shall perform online contingency management. E
Managing Payments
34. MB6.4 TMS shall facilitate contractor payments
35.
MB6.4.
1
TMS shall have inbound interface with the AP for receiving the invoice
details raised by vehicle contractors for the services performed by them for
DoP
E
36.
MB6.4.
2
TMS shall have the ability to process and validate these invoices based on
the actual services performed and agreed rates.
E
37.
MB6.4.
3
TMS shall have an outbound interface with AP for passing on the
confirmation on the invoice for the payment processing
E
Route Management
38. MB6.6 TMS shall manage the routes of the vehicle to be followed.
39.
MB6.6.
1
TMS shall obtain the volume of mail/consignment flow between various
facilities (collected through IPVS).
E
40.
MB6.6.
2
TMS shall determine the route parameters (pick up, locations, volumes). E
41.
MB6.6.
3
TMS shall identify network and route options and select the most optimal
route by performing cost evaluation.
E
42.
MB6.6.
4
TMS shall generate pick-up and delivery plan. E
43.
MB6.6.
5
TMS shall re-route vehicle to manage contingencies. E
Interface with other systems
44. MB6.7 TMS shall interface with other systems
45.
MB6.7.
1
TMS shall have interface with IPVS
46.
MB6.7.
1.1
TMS shall have outbound interface with IPVS to provide visibility on goods
being carried
E
47.
MB6.7.
1.2
TMS shall have inbound interface with IPVS for the volume of
mails/consignments being handled between various network nodes
(facilities)
E
48.
MB6.7.
2
TMS shall have inbound interface with MLASS to receive requests for the
pick-up from customer premises
D
49. IPVS
TMS shall have an outbound interface with IPVS to send transmission events
on the volume of mails/consignments being handled between various
facilities
E
50. MLASS
TMS shall have an inbound interface with MLASS to determine
transportation availability and to receive requests from the customer for
pick-up
E
8.4.1.5 Mailer & Logistics Appointment Scheduling
The Mailer & Logistics Appointment Scheduling System shall enable DoP to keep track of
appointments that customers request for pick up or drop of articles from their premises. The system
shall provide the flexibility for a manual booking of an appointment after providing the relevant
details to service the request. The system shall feed into Warehouse Management and
Transportation Management systems where the dispatch of vehicles and resources allocated can be
monitored. The appointments shall be logged in a database and it will create a visibility across all
servicing locations with respect to the volumes, schedules and compliance. This shall enable better
facilities and resource planning.
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

Scheduling Appointment through Multiple Channels
1. MB3.1 MLASS shall provide multiple channels for customers to schedule appointments
2.
MB3.1
.1
MLASS shall allow web-based appointment scheduling for pickup or drop E
3.
MB3.1
.2
MLASS shall allow phone-based appointment scheduling for pickup or drop E
4.
MB3.1
.3
MLASS shall allow customer to make an appointment in person at the post
office / Logistics Post centre
E
5.
MB3.1
.4
MLASS shall capture sender details
6.
MB3.1
.4.1
MLASS shall capture mobile phone contact details E
7.
MB3.1
.4.2
MLASS shall capture email address E
8.
MB3.1.4
MLASS shall capture postal address E
.3
9.
MB3.1.
5
MLASS shall validate services
10.
MB3.1
.5.1
MLASS shall have an outbound interface with IPVS to pass on services selected
during the appointment scheduling
E
11.
MB3.1
.6
MLASS shall capture consignment information
12.
MB3.1
.6.1
MLASS shall capture number and weight of the consignment E
13.
MB3.1
.6.2
MLASS shall capture the approximate volume (size) of the consignment E
14.
MB3.1
.7
MLASS shall display tentative time and date in case of a pickup request
15.
MB3.1
.7.1
MLASS shall determine the nearest Post office or LPC that will service the
request
E
16.
MB3.1
.7.2
MLASS shall have outbound interface with TMS for providing the pick-up related
information for the TMS to schedule the pickup
E
17.
MB3.1
.7.3
MLASS shall have inbound interface with TMS for receiving tentative time and
date for the pickup
E
18.
MB3.1
.7.4
MLASS shall provide the multiple options of tentative pickup times and prompt
the customer to select one
E
Address Memory
19.
MB3.2
.1
MLASS shall create a senders address memory so that frequently entered
addresses can be presented as remembered options to the user as the address
characters are entered.
D
20.
MB3.2
.2
MLASS shall store previously entered shipper addresses belonging to a
corporate customer account
D
21.
MB3.2
.3
MLASS shall allow the corporate customer to select the appropriate address D
22.
MB3.2
.4
MLASS shall display remembered address options to the user who shall be able
to select one of the options such that the remaining address information is
auto-populated by the system.
D
Booking Confirmation
23. MB3.3
MLASS shall complete the appointment request transaction by confirming
receipt of payment or intent of payment at dropoff/pickup.

24.
MB3.3
MLASS shall log an appointment in the database upon confirmation of payment E
.1
25.
MB3.3
.2
MLASS shall send an electronic (mail/SMS) confirmation (if requested) of
successful appointment transaction
D
26.
MB3.3
.3
If the appointment was made in person, the MLASS shall provide the customer
with a printed receipt
E
27.
MB3.3
.4
MLASS shall provide blank electronic copies of all necessary documentation
((i.e. - customs declaration etc. - Input taken from the services selected for the
articles, could be speed post / international, COD etc) for usage by the sender
E
Appointment Reminder
28. MB3.4
MLASS shall proactively send out the SMS/email appointment reminders if
requested

29.
MB3.4
.1
MLASS shall send reminder at various time buckets e.g. 8hrs prior to
appointment to the shipper / sender
D
30.
MB3.4
.2
MLASS shall also send details about the transaction in the reminder D
Appointment Cancellation
31. MB3.5 MLASS shall process cancellation requests.
32.
MB3.5
.1
MLASS shall have an option to put in a cancellation request. E
33.
MB3.5
.2
MLASS shall receive the transaction details provided by the sender for
cancellation.
E
34.
MB3.5
.3
MLASS shall track cancelled appointments.
35.
MB3.5
.3.1
The system shall allow appointment cancellations 48 hours prior with no system
penalty.
E
36.
MB3.5
.3.2
For cancellations within 48 hours, the system shall mark the appointment as
cancelled with penalty.
E
37.
MB3.5
.3.3
For no-shows, the system shall mark the appointment as no show. E
38.
MB3.5
.3.4
If the customer has a configurable number of cancelled with penalty and no
show appointments, they shall only be given less desirable appointment times.
E
39.
MB3.5
.4
MLASS shall have an outbound interface with TMS for updating the schedule E
Appointment Rescheduling
40. MB3.6 MLASS shall accept rescheduling requests and changes to transaction
41.
MB3.6
.1
MLASS shall re-execute the appointment scheduling process to when an
appointment rescheduling request is submitted by the customer
E
Payment Processing
42. MB3.7
MLASS shall collect payments (through redirection to the payment gateway)
from the customer if the customer chooses to pay ahead of time for the
incoming shipment.

43.
MB3.7
.1
MLASS shall maintain data related to the customer account and their current
balance so that the Accounts modules do not have to be read from for every
transaction.
E
44.
MB3.7
.2
MLASS shall collect advance payments for collection charges. E
45.
MB3.7
.2.1
MLASS shall collect advance payments for drop charges.
46.
MB3.7
.3
MLASS shall provide numerous payment options. E
47.
MB3.7
.4
If appointment is being made at the counter, MLASS shall accept cash
payments.
E
48.
MB3.7
.4.1
MLASS shall calculate required change to be returned to the customer. D
49.
MB3.7
.5
If appointment is being made at the counter, MLASS shall accept cheque
payments.
E
50.
MB3.7
.6
The online version of MLASS shall accept credit card payments. E
51.
MB3.7
.7
The online version of MLASS shall accept debit card payments. E
52.
MB3.7
.7.1
The online version of MLASS shall allow the customer to enter their debit card
PIN code.

53.
MB3.7
.8
At the counter or in the online version, MLASS shall accept ATM card payments. E
54.
MB3.7
.8.1
The system shall allow the customer to enter their ATM card PIN code.
55.
MB3.7
.9
MLASS shall have the ability to debit the corporate customer account for the
services performed for the customer.
E
56.
MB3.7
.9.1
MLASS shall send a debit transaction with the customer ID, debit amount, and
transaction details to the AR module for debit from their account.
E
57.
MB3.7
MLASS shall have the ability to accept pre-payment for the shipments. E
.10
58.
MB3.7
.10.1
MLASS shall send a credit transaction with the customer ID and credit amount
to the Accounts Payable module for credit to their account.
E
59.
MB3.7
.11
If the interface from IPVS for the appointment ID shows that MORE pieces than
were in the electronic manifest were actually inducted, the system shall send
another debit transaction to the Accounts Receivable module for the
discrepancy amount.
E
60.
MB3.7
.12
If the interface from IPVS for the appointment ID shows that FEWER pieces than
were in the electronic manifest were actually inducted, the system shall allow a
customer to either request a refund or leave the funds in their account for a
future shipment.
E
61.
MB3.7
.12.1
If the customer requests a refund through the online MLASS module, the
system shall send a request for refund for the amount specified by the user to
the Accounts Payable module that will issue the refund to the user.
E
62.
MB3.7
.12.2
If the customer requests a refund through the post office counter MLASS
module and the refund is less than a configurable limit, the user shall provide
the customer the cash due and the system shall send a debit transaction to the
Accounts module to reflect the refund against the customer IDs balance.
E
63.
MB3.7
.12.3
If the customer requests a refund through the post office counter MLASS
module and the refund is more than a configurable limit, the system shall send
a request for a refund for the amount specified by the user to the Accounts
Payable module that will issue the refund to the user.
E
64.
MB3.7
.12.4
If the customers account exceeds a configurable threshold of amount due, the
user shall instruct the customer that the booking cannot be accepted without
payment of the amount due
E
65.
MB3.7
.12.5
If the customers account is in default because a payment was missed, the user
shall instruct the customer that the booking cannot be accepted without
payment of the amount due.
E
Customer Management
66. MB3.8
MLASS shall allow for new customer creation if the customer does not already
have an DoP credit or debit account. This information must be maintained
locally and centrally (for distribution to other local servers).
E
67.
MB3.8
.1
The system shall capture company name, contact information, company funds
approver, and all other fields per the standard DoP customer application form.
E
68.
MB3.8
.2
If the customer is government or semi-government, their account may be
opened as a Book-Now-Pay-Later customer.
E
69.
MB3.8
.3
If the customer provides a deposit of predetermined amount through one of the
payment options, they shall be setup as a BNPL customer.
E
70.
MB3.8
.4
The system shall send a new customer record to the Customer Database and
receive back a unique customer ID that can be provided to the customer for
future use.
E
71. MBE
MLASS shall have an outbound interface to MBE to send booking requests and
then receive an inbound interface to receive transaction payment confirmation.
E
72. IPVS
MLASS will interact with the IPVS to log the type of services requested for the
articles, provide the checklist and documentation in electronic format when
bulk mailers are sending international parcels, accountable articles etc. and
show the status of the shipment transaction (pick-up/drop/store).
E
73. WMS
MLASS will pass on information on weight, volume, dimensions and number of
articles to the WMS and will check space availability. Once appointment is
confirmed, the storage space is blocked in the WMS for a particular
confirmation id, customer id and time duration
D
74. TMS
MLASS will interact with TMS to find out the tentative vehicle availability for a
particular date, time, facility id, location name, customer address, service type
(pick-up/drop/store) and route id
D
75. GL
MLASS will interface with Accounts Receivable to receive customer credit
details (i.e. credit owed, credit limit, etc.) and to send customer charges, BNPL
details, and summaries of revenue by category (mail shipments, logistics
shipments, etc.).
E
76.
Custo
mer
Datab
ase
MLASS will interface with the customer database of existing customers to
determine if customer already exists. If the customer does not exist, CRM will
create a new customer account and provide the new unique number.
E
77. HRMS
calendar months, from the data warehouse in the form of MIS reports. MLASS
shall ensure that this detail is stored in the data warehouse on a monthly basis
E
78. MB7.4 SPS shall maintain nationwide sort program templates created by HQ users.
79.
MB7.4
.1
Nationwide sort program templates shall be stored within the system for
individual facilities to have a starting point to create their site-specific sort
programs.
E
80.
MB7.4
.2
HQ users shall be able to create sort program templates for use by specific
facilities.
E
81.
MB7.4
.3
SPS shall notify stored site users on their e-mail addresses when a new
nationwide template has been created.
E
82.
MB7.4
.4
SPS shall allow new templates to be created using any facilitys existing sort
program as a template (copy/paste/edit functionality).
E
8.4.1.6 Sort Program System
SPS will enable DoP to create a central repository of sort programs for all its Mail processing centres.
The system will also track any addition, deletion or modifications made to any existing sort program.
This will also enable the higher offices to have an overview of the all the sort programs of reporting
offices.
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

Maintaining List of Sort Programs
1. MB7.1 SPS shall maintain mail processing sort programs in a centralized data store.
2.
MB7.1
.1
SPS shall store automated equipment sort programs with the following
attributes:
Facility ID
Sort program name
Work operation
E
3.
MB7.1
.2
SPS shall store at least the following bin details for each bin in a sort program:
Bin name
Bin contents (associated PIN codes)
Bin destination facility ID
E
Sort Program Creation/Edit/Delete/Upload/Modification
4. MB7.2 SPS shall provide a sort program upload capability.
5.
MB7.2
.1
SPS shall allow the user to upload a Microsoft Excel sort program that matches a
certain pre-determined format.
E
6.
MB7.2
.2
SPS shall allow the user to upload a text file sort program that matches a certain
pre-determined format.
E
7.
MB7.2
.3
SPS shall provide a capability to let the user manually enter/create a sort
program within the system.
E
8.
MB7.2
.4
Upon completion/upload of a sort program, SPS shall validate that, at a
minimum, all PIN codes are assigned to one and only one bin.
E
9.
MB7.2
.5
SPS shall allow users to delete sort programs when they are no longer in use. E
10.
MB7.2
.6
SPS shall allow users to modify existing sort programs as per new requirements E
Viewing Sort Programs at Higher Level Office
11. MB7.3 SPS shall allow a reporting office user to view all reporting office sort programs.
12.
MB7.3
.1
Upon a facility sort program upload/edit, SPS shall notify the responsible office
(district or circle) that a change has been made.
E
13.
MB7.3
.2
SPS shall require responsible office approval for sort program uploads/edits. E
National Sort Program Templates
14. MB7.4 SPS shall maintain nationwide sort program templates created by HQ users.
15.
MB7.4
.1
Nationwide sort program templates shall be stored within the system for
individual facilities to have a starting point to create their site-specific sort
programs.
E
16.
MB7.4
.2
HQ users shall be able to create sort program templates for use by specific
facilities.
E
17.
MB7.4
.3
SPS shall notify stored site users on their e-mail addresses when a new
nationwide template has been created.
E
18.
MB7.4
.4
SPS shall allow new templates to be created using any facilitys existing sort
program as a template (copy/paste/edit functionality).
E
8.4.1.7 Labour Scheduling System (LSS)
The Labour Scheduling System shall enable DoP to plan employee work schedules. The system shall
enable users to view employee details (such as skills, competencies, availability, job description, etc),
actual employee work details (such as leaves and work hours), and plan employee schedules
accordingly. This shall ensure proper job-skill matching and efficient utilization of the entire
workforce. The system shall also enable users to track actual versus planned performance and take
corrective actions whenever necessary.
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

Storing Employee Work Schedule Details
1. MB8.1
LSS will store employee work schedule details in order to enable matching
work load requirement and employee availability.

2.
MB8.1 LSS will interface with the HR system to obtain employee details (including
E
.1 employee ID, assigned facility, level) for all employees assigned to a mail
operations facility (i.e. post office, mail processing centre, transit mail office,
etc.).
3.
MB8.1
.2
LSS will allow users to enter the following information for employees: On-the-
Job Skills & Competencies, Discontinue Date, Work Assignment, Scheduled
Work Hours, Scheduled Leaves, Scheduled Days Off
E
4.
MB8.1
.3
LSS will obtain the job description of different roles from the HR system. E
Interface to Receive Actual Employee Work Details
5. MB8.2 LSS will interface with IPVS to obtain actual employee work details.
6.
MB8.2
.1
LSS will interface with IPVS to obtain actual employee work hours. E
7.
MB8.2
.2
LSS will assume the employee is on leave if the interface with IPVS returns no
actual work hours on a given day.
E
Workforce Operational Reporting
8. MB8.3 LSS will provide complete visibility into the scheduling of the entire workforce
9. MB8.1 LSS will provide users with scheduling details at various levels E
10.
MB8.1
.1
LSS will provide the scheduling details of every employee E
11.
MB8.1
.2
LSS will provide the scheduling details of all offices E
12.
MB8.1
.3
LSS will provide the scheduling details of all departments E
13.
MB8.1
.4
LSS will provide the scheduling details of all functions E
14.
MB8.1
.5
LSS will provide the scheduling details of all levels E
15. MB8.2
LSS will provide operational report data on actual vs. expected work load at
different offices
E
16. MB8.3 LSS will provide operational report data on the productivity of the employees E
17. HR
LSS will interface with HR system to obtain data related to employee work
details, role description and recruitment.
E
18. IPVS
LSS will have an inbound interface from IPVS to receive actual employee work
hours. This interface will also provide workload and productivity for employees
and different entities.
E
8.4.2 Logistics Post
8.4.2.1 Warehouse Management System (WMS)
The Warehouse Management System will provide DoP the capability to efficiently run its core
warehousing functions: receiving, location tracking, picking, packing, replenishment, shipping,
inventory management & order management. WMS will be integrated with the IPVS, MLASS and
TMS, and provide DoP the necessary data to optimize its key resources utilization. WMS shall also be
linked with the business partners inventory management to have visibility on the inventories of
items. All the items stored in a warehouse shall be uniquely identified and stored where they can be
retrieved efficiently. The management will have a view across all the locations with the inventory
being held, customers being serviced, and space utilization. Operationally the system will generate
picking, packing and dispatch lists and electronically storing the reports.
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

Warehouse Storage
1. 2 MB5.1 WMS shall enable storage of all the items in the Warehouse.
2.
MB5.1
.1
WMS shall uniquely identify all the storage locations available.
3.
MB5.1
.1.1
WMS shall have a central repository of all storage locations available across
the various facilities in the entire supply chain.
E
4.
MB5.1
.1.2
WMS shall further break-down the facilities into easily identifiable storage
locations.
E
5.
MB5.1
.1.3
WMS shall provide the storage locations unique ids. E
6.
MB5.1
.2
WMS shall read the barcodes provided by the business partners on items. E
7.
MB5.1
.3
WMS shall slot all items based on various categories pre-defined in the system.
8.
MB5.1
.3.1
WMS shall maintain a list of categories (voluminous, heavy, size etc.). E
9.
MB5.1
.3.2
WMS shall categorize each item into one of these categories. E
10.
MB5.1
.4
WMS shall allocate unique storage locations to each item to be stored.
11.
MB5.1
.4.1
WMS shall allocate storage location to items based on velocity, size and
material classification.
E
12.
MB5.1
.4.2
WMS shall allocate storage location to items based on storage space
availability.
E
Order Receipt
13. MB5.2 WMS shall receive replenishment orders.
14.
MB5.2
.1
WMS shall receive orders from business partners
15.
MB5.2
.1.1
WMS shall have inbound interface with external business partners system. D
16.
MB5.2
.1.2
WMS shall have defined link with the business partners software. D
17.
MB5.2
.1.3
WMS shall receive & combine orders from same customer originating at
different locations.
D
18.
MB5.2
.1.4
WMS shall capture the order details (quantity, destination, date for
replenishment)
D
19.
MB5.2
.1.5
WMS shall have an inbound interface with MLASS to receive information about
the volume of material expected to come into the system for a defined period.
D
20.
MB5.2
.2
WMS shall receive orders from India Post Mail Booking Engine
21.
MB5.2
.2.1
WMS shall receive intimation when a customer buys an articles/collection of
articles on the DoP portal
E
22.
MB5.2
.2.2
WMS shall receive the order details such as date of delivery, item ID, quantity,
destination address
E
23.
MB5.2
.3
WMS shall replenish the Retail Post stock maintained at the various DoP
facilities

24.
MB5.2
.3.1
WMS shall maintain a stock of Retail Post inventory at each of the facilities and
update it with any sale transaction
E
25.
MB5.2
.3.2
WMS shall prompt re-order based on the pre-defined minimum stock levels for
different facilities
E
26.
MB5.2
.4
WMS shall allocate the locations/facilities for servicing the order and provide
the relevant information to the identified facilities/locations
E
Item Retrieval
27. MB5.3
WMS shall enable retrieving the items stored in the Warehouse based on the
order received.

28.
MB5.3
WMS shall prepare the picking list based on the order received.
.1
29.
MB5.3
.1.1
WMS shall identify the most optimal locations for picking the items to service
an order based on parameters such as reduced material handling, FIFO and
location.
E
30.
MB5.3
.1.2
WMS shall print the picking list for the warehouse personnel to review while
picking.
E
31.
MB5.3
.1.3
WMS users shall use handheld scanners to scan pick-list items as they are
picked.
E
32.
MB5.3
.2
WMS shall prepare the packing list based on the order received.
33.
MB5.3
.2.1
WMS shall decide the packing sequence based on a pre-defined logic. E
34.
MB5.3
.2.2
WMS shall determine the packing requirements from the system. E
35.
MB5.3
.2.3
WMS shall print a packing list. E
36.
MB5.3
.2.4
WMS shall optimize the packing operation by optimizing the packing
combination for the items on an order.
E
37.
MB5.3
.2.5
WMS users shall use handheld scanners to scan packing list items as they are
packed.
E
Document Storage
38. MB5.4 WMS shall store documents electronically.
39.
MB5.4
.1
WMS shall allow users to scan documents into the WMS using the attached
document scanner.
E
40.
MB5.4
.2
WMS shall have the capability to uniquely identify the documents and link
them to a particular consignment.
E
41.
MB5.4
.3
WMS shall have the capability to electronically transfer the document to the
various entities (e.g. LPC, Insurance agencies etc.).
E
Order dispatch
42. MB5.5 WMS shall process the dispatch of the order.
43.
MB5.5
.1
WMS shall prepare/print the labels to be pasted on the consignment. E
44.
MB5.5
.2
WMS shall generate the necessary documentation that needs to be carried for
various forms of transportation.
E
45.
Mb5.5
.3
WMS shall have an outbound interface with TMS to arrange for vehicle for
order dispatch.
E
Manage Cross-docking
46. MB5.6 WMS shall allow cross-docking of shipments. D
47.
MB5.6
.1
WMS shall match the inbound shipments with the outbound shipments and
explore potential cross-docking.
D
48. Invoicing
49. MB5.7 WMS shall raise invoice on customers based on services performed. E
50.
MB5.7
.1
WMS shall interface with the Customer Account solution for accessing the
unified customer account in order to raise invoice on corporate customers.
E
51. Resource Optimization
52. MB5.8 WMS shall optimize the utilization of warehousing space and facilities.
53.
MB5.8
.1
WMS shall provide visibility into all DoP facilities capacity/ utilization. D
54.
MB5.8
.2
WMS shall have an optimizing engine that shall optimally utilize the various
facilities while storing/picking.
D
Distribution
55. MB5.9 WMS shall have a distribution capability.
56.
MB5.9
.1
WMS shall plan for goods distribution based on the order received/business
agreement.
E
57.
MB5.9
.2
WMS shall accordingly prepare the pick-list for the items to be picked up to
service the order.
E
58.
MB5.9
.3
WMS shall prepare the packing list for items to be packed. E
59.
MB5.9
.4
WMS shall generate the label to be put on the items for shipping. E
60.
MB5.9
.5
WMS shall have an outbound interface with TMS to provide shipping
information for these items.
E
61.
MB5.1
0
WMS shall maintain an inventory of the items
62.
MB5.1
0.1
WMS shall maintain an inventory status of items in the Logistics Post supply
chain

63.
MB5.1
0.1.1
WMS shall maintain the inventory status of items stored in the warehouse and
LPCs
E
64.
MB5.1
0.1.2
WMS shall maintain the inventory status of items under transit at various
stages of supply chain
E
65.
MB5.1
0.1.3
WMS shall generate an inventory aging report highlighting the obsolete items E
66.
MB5.1
0.2
WMS shall maintain inventory status of retail post items
67.
MB5.1
0.2.1
WMS shall keep a track of the inventory of retail items sold through the POs
as also through the web portal of the DoP on an ongoing basis
E
68.
MB5.1
0.2.2
WMS shall generate MIS reports to show PO-wise daily inventory position for
each item
E
69.
MB5.1
0.2.3
WMS shall update the inventory level upon the acknowledgement of receipt of
items by the central stores /Warehouse from 3rd party vendors/partners in
the system
E
70.
MB5.1
0.2.4
WMS shall record the quantity and serial number of items received E
71.
MB5.1
0.2.5
WMS shall record and account for discrepancies arising out of physical
verification of inventories
E
72.
MB5.1
0.2.6
WMS shall be able to track ,identify and alert user about obsolete inventory E
73.
MB5.1
0.2.7
WMS shall send automatic trigger to the designated relationship manager for
re-order to 3rd party/business partner when inventory approaches re-order
level
E
74.
MB5.1
0.2.8
WMS shall enable user to manually edit the re-order level which triggers the
automatic procurement request
E
75. MBE
WMS shall have an inbound interface with MBE to receive Retail Post order
requests for WMS to coordinate order fulfilment.
E
76. IPVS
WMS shall have an outbound interface with IPVS to provide the visibility on
the consignment received at the warehouse. Also when the booking is done
through the handheld, the booking shall reflect the status of consignment in
the IPVS.
E
77.
MLAS
S
WMS shall have an inbound interface with MLASS to receive information about
the volume of material expected to come into the system for a defined period.
D
78. TMS
WMS shall have an outbound interface with TMS to pass on the information
regarding all dispatches being scheduled. TMS shall use this information to
schedule the vehicles accordingly.
E
79. IMS
The WMS System shall have an outbound interface to the IMS to send on-hand
inventory details.
E
80.
Custo WMS shall have an outbound interface with Customer Account to update the
E
mer
Accou
nt
customer account for the services provided to enable billing for customers
81. ECM
WMS shall have an outbound interface with ECM to send all the digitized
documents to the central repository
E
8.4.2.2 Transportation Management System (TMS)
The Transportation Management System will enable DoP to manage its fleet of vehicles. It will
provide visibility into the day to day operations, appointment schedules being met, volumes being
handled and further recording the data in electronic format to analyze the capacity utilizations.
Furthermore, it will carry out the fleet maintenance. TMS shall have the capability to track its
vehicles at all times through technologies such as RFID or GPS and will provide this input to the India
Post Visibility Solution to provide complete track and trace.
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

Managing Fleet of Vehicles
1. MB9.1 TMS shall manage the fleet of all vehicles owned by DoP.
2.
MB9.1.
1
TMS shall maintain a list of all vehicles owned by DoP. E
3.
MB9.1.
1.1
TMS shall register all the vehicles into the system. E
4.
MB9.1.
1.2
TMS shall maintain vehicle details (registration numbers, make, year) along
with the facility it belongs to.
E
5.
MB9.1.
2
TMS shall establish the overall fleet capacity of DoP.
6.
MB9.1.
2.1
TMS shall maintain a repository of available fleet capacity of DoP owned
vehicles for Logistics Post Vehicles.
E
7.
MB9.1.
2.2
TMS shall maintain a repository of available fleet capacity of hired/contracted
vehicles for Logistics Post Vehicles.
E
8.
MB9.1.
2.3
TMS shall include the vehicles available in the market (not under DoP
contract, but available for hire at pre-approved rates and a defined SLA) at a
short notice for its available capacity calculation
E
9.
MB9.1.
3
TMS shall review the transportation capacity requirements of DoP.
10.
MB9.1.
3.1
TMS shall assess the short-term transportation requirements (for the
immediate execution) based on the scheduling requests received.
E
11.
MB9.1.
3.2
TMS shall highlight any gaps in available capacity and the short-term
transportation requirements based on the scheduling requests received.
E
12.
MB9.1.
3.3
TMS shall assess the long-term transportation requirements based on the
business plans.
E
13.
MB9.1.
3.4
TMS shall highlight any gaps in available capacity and the long-term
transportation requirements based on the business plans.
E
14.
MB9.1.
4
TMS shall plan/manage the maintenance of the fleet.
15.
MB9.1.
4.1
TMS shall plan/manage the maintenance of DoP owned fleet.
16.
MB9.1.
4.1.1
TMS shall prepare a detailed maintenance plan for DoP owned fleet. E
17.
MB9.1.
4.1.2
TMS shall schedule this maintenance into the overall transportation schedule. E
18.
MB9.1.
4.1.3
TMS shall track the adherence to this maintenance plan by preparing a
planned versus actual report.
E
19.
MB9.1.
4.2
TMS shall review the maintenance of the hired/contracted vehicles.
20.
MB9.1.
4.2.1
TMS shall maintain a maintenance plan agreed with the contractor. D
21.
MB9.1.
4.2.2
TMS shall track the status of the maintenance plan for its implementation. D
22.
MB9.1.
4.2.3
TMS shall highlight non-adherence to the relevant authorities. D
Vehicle Tracking
23. MB9.2
TMS shall have the capability to later provide a telematics/GPS/RFID based
solution for track & trace purpose

24.
MB9.2.
1
For DoPs own vehicles, TMS shall provide telematics solution to capture the
various operating parameters
D
25.
MB9.2.
2
For the entire fleet (owned and hired) TMS shall have the functionality of
providing GPS/RFID based track & trace solution

26.
MB9.2.
2.1
TMS shall uniquely identify each vehicle through an RFID or GPS device D
27.
MB9.2. For hired vehicles, TMS shall be able to provide a unique identifier to the
D
2.2 vehicle by loading a bag with RFID/GPS inside the vehicle
28.
MB9.2.
2.3
TMS shall provide the vehicle-wise report on deviation from the approved
route
D
Scheduling Vehicles
29. MB9.3
TMS shall schedule vehicles (pickup and delivery) as per the scheduling
requirements.

30.
MB9.3.
1
TMS shall receive scheduling requirements. E
31.
MB9.3.
2
TMS shall review the vehicle availability. E
32.
MB9.3.
3
TMS shall perform load-planning for combining LTL wherever possible. E
33.
MB9.3.
4
TMS shall incorporate the maintenance plan into the vehicle scheduling. E
34.
MB9.3.
5
TMS shall allocate vehicles to various routes as per the optimized schedule. E
35.
MB9.3.
6
TMS shall perform online transport scheduling. E
36.
MB9.3.
7
TMS shall perform online contingency management. E
37. Managing Rates
38. MB9.4
TMS shall maintain a comprehensive rate list of contracted rates agreed with
the contractors for different routes and options (LTL, FTL).
E
39. Managing Payments
40. MB9.5 TMS shall facilitate contractor payments
41.
MB9.5.
1
TMS shall have inbound interface with the AP for receiving the invoice details
raised by vehicle contractors for the services performed by them for DoP
E
42.
MB9.5.
2
TMS shall have the ability to process and validate these invoices based on the
actual services performed and agreed rates.
E
43.
MB9.5.
3
TMS shall have an outbound interface with AP for passing on the confirmation
on the invoice for the payment processing
E
Route Management
44. MB9.6 TMS shall manage the routes of the vehicle to be followed.
45.
MB9.6.
1
TMS shall determine the route parameters (pick up, locations, volumes). E
46.
MB9.6.
2
TMS shall identify network and route options and select the most optimal
route by performing cost evaluation.
E
47.
MB9.6.
3
TMS shall generate pick-up and delivery plan. E
48.
MB9.6.
4
TMS shall re-route vehicle to manage contingencies. E
Interface with other systems
49. MB9.7 TMS shall interface with other systems
50.
MB9.7.
1
TMS shall have interface with IPVS
51.
MB9.7.
1.1
TMS shall have outbound interface with IPVS to provide visibility on goods
being carried
E
52.
MB9.7.
1.2
TMS shall have inbound interface with IPVS for the volume of
mails/consignments being handled between various network nodes (facilities)
E
53.
MB9.7.
2
TMS shall have inbound interface with MLASS to receive requests for the pick-
up from customer premises
D
54.
MB9.7.
3
TMS shall have inbound interface with WMS to receive scheduling request for
order fulfilment
D
55. WMS
TMS shall have an inbound interface with the WMS to receive scheduling
request for order fulfilment
E
56. IPVS
TMS shall have an outbound interface with IPVS to send transmission events
on the volume of mails/consignments being handled between various
facilities
E
57. MLASS
TMS shall have an inbound interface with MLASS to determine transportation
availability and to receive requests from the customer for pick-up
E
8.4.3 Philately
8.4.3.1 Philatelic Deposit Accounting
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

Philatelic Deposit Account Opening
1. PH1.1 System shall enable PDA opening E
2.
PH1.1.
1
System shall allow Post Office PA to open a PDA across the counter E
3.
PH1.1.
2
System shall allow the user to open a PDA through web portal E
4.
PH1.1.
3
System shall allow the user to open a PDA through Call Centre E
5.
PH1.1.
4
System shall capture the details of the account E
Payment Options
6. PH1.2 System shall allow multiple payment options for PDA E
7.
PH1.2.
1
System shall allow web payment through debit card/credit card/bank
transfer/ POSB transfer
E
8.
PH1.2.
2
System shall allow cash payment across the counter E
Philatelic Account Management
9. PH1.3 System shall allow online account management for the PDA D
10.
PH1.3.
1
System shall allow online change of address D
11.
PH1.3.
2
System shall allow online change of contact details D
12.
PH1.3.
3
System shall allow online query for account balance D
13.
PH1.3.
4
System shall provide complete transaction history for the account D
Order Management
14. PH1.4 System shall allow online order generation E
15.
PH1.4.
1
System shall provide a link to the Philately page listing all the current releases E
16.
PH1.4.
2
System shall allow the user to place an order for the current release including
the quantities
E
17.
PH1.4.
3
System shall allow the user to place future order for the future release
including the quantities
E
18.
PH1.4.
4
System shall send electronic alerts to the email provided as contact for all
transactions
E
Account closure
19. PH1.5 System shall allow the user to close the account E
20.
PH1.5.
1
System shall allow the user to close the account through the Call Centre E
21.
PH1.5.
2
System shall allow the user to close the account online E

8.4.3.2 Stock & Supply of Stamps
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

Stamp Printing
1. PH2.1 System shall manage the stamp printing process E
2.
PH2.1.
1
System shall maintain detailed list of all categories of stamps, denomination-
wise along with the date of release
E
3.
PH2.1.
2
System shall generate advice for printing of Philatelic stamps to be sent to
RSD Nashik and RSD Hyderabad
E
4.
PH2.1.
3
System shall consolidate the indents raised for definitive stamps by the CSD
along with the denomination
E
5.
PH2.1.
4
System shall generate advice for printing of definitive stamps to be sent to
RSD Nashik and RSD Hyderabad
E
Stamp Receipt at the Office
6. PH2.2 System shall receive the stamps at the destination office E
7.
PH2.2.
1
System shall send electronic alert to the receiving office E
8.
PH2.2.
2
System shall verify the physical receipt versus the invoiced quantity and raise
any mismatch
E
9.
PH2.2.
3
System shall generate variance report to be sent to RSD Nashik and RSD
Hyderabad
E
10.
PH2.2.
4
System shall allow the goods receipt online E
Stamp Inventory
11. PH2.3
System shall maintain the inventory of stamps for each office (Post Offices,
Philatelic Bureaux, CSD)
E
12.
PH2.3.
1
System shall maintain denomination-wise inventory of stamps E
13.
PH2.3.
2
System shall update the stock quantity every day at the close of day
accounting for any stock received and the sale of stamps
E
14.
PH2.3.
3
System shall generate Remittance Advice (RA) in the case of inter bureau
supply
E
Sale of Philatelic Stamp
15. PH2.4 System shall manage the sale of stamps E
16.
PH2.4.
1
System shall ensure that stamps are not supplied to any bureau/ counter
above the authorized limit
E
17.
PH2.4.
2
System shall ensure that philatelic stamps are not sold before their release
date
E
18.
PH2.4.
3
System shall generates stamp distribution list for supply to PDA Account
Holders/ Nehru Stamp Clubs / Dealers as per the choice of the account holder
E
19.
PH2.4.
4
System shall limits the supply to the account holders as per the balance
available in their accounts
E
Disposal of Philatelic Stamp
20. PH2.5 System shall manage the sale/disposal of old philatelic stamps D
21.
PH2.5.
1
System shall update stock of the office as per Write off sanctions issued by
Superintendent with appropriate remarks and generates alert to physically
destroy the stamps
D
22.
PH2.5.
2
Transfers the unsold stamps after one year (configurable) from the date of
release to the General Stamps balance at that office, updating stamps
registers and sends alert
D
Interface with Other systems
23. IM
System shall have interface with Inventory Management module to use the
inventory management functionalities
E
24.
Requi
sition
&
Procur
ement
System shall have interface with Requisition & Procurement module to
generate indents, creation of purchase order and good receipt
E

8.4.4 Finance & Accounts
8.4.4.1 General Ledger (GL)
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

Consolidation of transactions
1.
FA.GL.
1
System shall automatically consolidate summary of transactions from different
applications
E
2.
FA.GL.
1.1
System shall collate revenue/ expenditure received as a summary from PBS at
end of day
E
3.
FA.GL.
1.1.1
System shall get summary input of all PBS accounting transactions by
transaction ID and office of origination of transaction
E
4.
FA.GL.
1.1.1.
1
System shall consolidate summary of transactions already classified under HoA E
5.
FA.GL.
1.2
System shall consolidate revenue/ expenditure from PLI Ledger E
6.
FA.GL.
1.2.1
System shall get summary input of all PLI accounting transactions by
transaction ID and office of origination of transaction
E
7.
FA.GL.
1.2.1.
1
8.
FA.GL.
1.3
System shall consolidate revenue/ expenditure from Mail Booking engine E
9.
FA.GL.
1.3.1
System shall get summary input of all Mail Operations Transactions from the
booking engine by transaction ID and office of origination of transaction
E
10.
FA.GL.
1.3.1.
1
11.
FA.GL.
1.3.2
System shall get summary input of all accounting transactions in MLASS (Mail
& Logistics Appointment & Scheduling Solution) by transaction ID and office of
origination of transaction
E
12.
FA.GL.
1.3.2.
1
13.
FA.GL.
1.4
All transactions shall be posted to GL in batch mode at End of day E
14.
FA.GL.
1.4.1
System shall allow offline transaction files from non connected Post Offices to
be integrated in GL as a batch process
E
15.
FA.GL.
1.4.2
System shall collate revenue/ expenditure received as a summary from
Sanchay Post at end of day
E
16.
FA.GL.
1.4.3
System shall get summary input of all Sanchay Post accounting transactions E
17.
FA.GL.
1.4.4
System shall consolidate summary of Sanchay Post transactions already
classified under HoA
E
Online Accounting
18.
FA.GL.
2
System shall support online accounting entries from Fixed Asset Accounting,
Inventory management, Accounts Receivable, Accounts Payable and
Procurement Functions
E
19.
FA.GL.
2.1
System shall allow for posting of expenses identified as 'recurring' (Payroll, etc)
on a pre-defined logic and shall get posted automatically once the program has
been executed on a specified date
E
20.
FA.GL.
2.2
System shall fetch details of salaries paid to departmental employees from
Payroll Function
E
21.
FA.GL.
2.3
System shall fetch details of other bills/loans drawn by employees from Payroll
Function
E
22.
FA.GL.
2.4
System shall fetch details of Govt. contribution towards NPS for all employees
(Nil Bill) from Payroll Function
E
23.
FA.GL.
2.5
In case of employees not on Payroll, the systems shall support manual input of
drawal of bills and Govt. contribution for the employees
E
24.
FA.GL.
2.6
System shall record expenditures incurred by Administrative offices (Circle
Office/ Regional Office/ Div. Office), CSD, PSD, MMS, RMS, Civil & Electrical
Division
E
25.
FA.GL.
2.7
System shall interface with Accounts Payable function E
26.
FA.GL.
2.7.1
System shall pass accounting entries in GL for payable amount E
27.
FA.GL.
2.7.2
System shall pass entry in GL when payables have been squared off E
28.
FA.GL.
2.8
System shall interface with Accounts Receivable function E
29.
FA.GL.
2.8.1
System shall pass accounting entries in GL for receivable amount E
30.
FA.GL.
2.8.2
System shall pass entry in GL when receivables have been squared off E
31.
FA.GL.
2
System shall support online accounting entries from Fixed Asset Accounting,
Inventory management, Accounts Receivable, Accounts Payable and
Procurement Functions
E
32.
FA.GL.
2.1
System shall allow for posting of expenses identified as 'recurring' (Payroll, etc)
on a pre-defined logic and shall get posted automatically once the program has
been executed on a specified date
E
33.
FA.GL.
2.2
System shall fetch details of salaries paid to departmental employees from
Payroll Function
E
34.
FA.GL.
2.3
System shall fetch details of other bills/loans drawn by employees from Payroll
Function
E
35.
FA.GL.
2.4
System shall fetch details of Govt. contribution towards NPS for all employees
(Nil Bill) from Payroll Function
E
36.
FA.GL.
2.5
In case of employees not on Payroll, the systems shall support manual input of
drawal of bills and Govt. contribution for the employees
E
37.
FA.GL.
2.6
System shall record expenditures incurred by Administrative offices (Circle
Office/ Regional Office/ Div. Office), CSD, PSD, MMS, RMS, Civil & Electrical
Division
E
38.
FA.GL.
2.7
System shall interface with Accounts Payable function E
39.
FA.GL.
2.7.1
System shall pass accounting entries in GL for payable amount E
40.
FA.GL.
2.7.2
System shall pass entry in GL when payables have been squared off E
41.
FA.GL.
2.8
System shall interface with Accounts Receivable function E
42.
FA.GL.
2.8.1
System shall pass accounting entries in GL for receivable amount E
43.
FA.GL.
2.8.2
System shall pass entry in GL when receivables have been squared off E
Common Charts of Account
44.
FA.GL.
3
System shall use common Chart of Accounts E
45.
FA.GL.
3.1
System shall have defined Chart of Accounts for Accrual Accounting as
prescribed by ICAI ARF which shall drive the Chart of Accounts used in PBS, PLI
and Mail ledgers
E
46.
FA.GL.
3.2
System shall have cost codes built-in to map expenses to the correct cost centre
(Circle Office, Regional Office, etc)
E
47.
FA.GL.
3.3
System shall be able to generate financial reports in Cash Based Accounting
format from the Accrual Accounting system
E
48.
FA.GL.
3.3.1
System shall generate Circle Abstract with classification into HoA in the format
as is currently submitted
E
49.
FA.GL.
3.3.2
System shall generate General Abstract with classification into HoA in the
format as is currently submitted
E
50.
FA.GL.
3.3.3
System shall have the ability to handle other reporting under Accounting
standards
E
51.
FA.GL.
3.3.4
System shall be able to create a central data pool with maximum level of
granularity so that reports can be generated in accordance with the regulatory
or management requirement:
E
52.
FA.GL.
3.3.4.
1
Internal & External Financial Reporting E
53.
FA.GL.
3.3.4.
2
Performance Reporting E
54.
FA.GL.
3.3.4.
3
Operational Reporting E
55.
FA.GL.
3.3.4.
4
Reconciliation Reporting - On-line, real-time update or batch (user defined) E
56.
FA.GL.
3.4
System shall support creation/modification/ deletion of Heads of Accounts as
per directives of Ministry of Finance
E
Accounts Consolidation
57.
FA.GL.
4
Accounts Consolidation E
58.
FA.GL.
4.1
System should enable the Accounts Processing Centre to retrieve consolidated
quarterly/annual accounts (no input should be required from the operating
offices as all the accounting data is updated real time in the database)
E
59.
FA.GL. Should be able to consolidate general ledgers using different accounting
E
4.2 periods
60.
FA.GL.
4.3
Should be able to define period start and end dates in the consolidation module E
61.
FA.GL.
4.4
Should be able to make consolidation for the subsequent periods even if the
consolidation of first period is still open
E
62.
FA.GL.
4.5
All codes entered should be able to be validated on-line, and the code
description displayed for visual checking
E
63.
FA.GL.
4.6
Should be able to reproduce the chart of accounts from any of the general
ledgers in the consolidation module as a basis for consolidation
E
64.
FA.GL.
4.7
Should display list of all valid codes and their descriptions at points when codes
are required to be entered
E
65.
FA.GL.
4.8
Should be able to generate the required reports, including: E
66.
FA.GL.
4.8.1
trial balance E
67.
FA.GL.
4.8.2
segmental revenue accounts E
68.
FA.GL.
4.8.3
profit and loss account E
69.
FA.GL.
4.8.4
balance sheet E
70.
FA.GL.
4.8.5
IBNR E
71.
FA.GL.
4.8.6
Cash Flow E
72.
FA.GL.
4.8.7
Calculation of ratios E
73.
FA.GL.
4.8.8
net movement by account showing opening balance at start of the month, all
transactions and closing balance
E
74.
FA.GL.
4.8.9
net movement by account showing opening balance at start of the range of
continuous vouchers , net transactions during the range and closing balance
at the end of the range
E
75.
FA.GL.
4.9
Should be able to convert various office balances of foreign offices in various
currencies into rupees and generate consolidated balance sheet of all such
offices
E
76.
FA.GL.
4.10
Should support prep of a/c where transfer of office takes place during the
financial year from one controlling office to another
E
77.
FA.GL.
4.11
Should have provision for calculation of solvency ratio E
78.
FA.GL.
4.12
Should have provision to track actual transaction dates for various transactions
(prior period items)
E
79.
FA.GL.
4.13
Should be capable of supporting migration of legacy accounting data E
80.
FA.GL.
4.14
It is likely that most reports will be produced by means of an end-user report
writer. Such a report writer should be able to access all data items in the
database to enable a wide range of custom reports to be written (subject to
approval)
E
81.
FA.GL.
4.15
System shall be able to create and maintain accounts and account information
on-line
E
82.
FA.GL.
4.16
System shall be able to create memo accounts for collecting non-financial
statistical information
E
83.
FA.GL.
4.17
System shall be able to segregate expense accounts by division, department
and work, cost or profit centre
E
84.
FA.GL.
4.18
System shall be able to transfer or consolidate accounts and automatically
combine all details
E
85.
FA.GL.
4.19
System shall be able to record settlements and adjustments through journal
entries
E
86.
FA.GL.
4.20
System shall be able to carry out reversal of journal entries E
87.
FA.GL.
4.21
System shall be able to post journal entries in batch E
88.
FA.GL.
4.22
System shall be able to sort information from a header record in each
transaction
E
89.
FA.GL.
4.23
System shall be able to consolidate financial data along the following
parameters:
E
90.
FA.GL.
4.23.1
Within a Division/circle/region E
91.
FA.GL.
4.23.2
Post office level E
92.
FA.GL.
4.23.3
Cost, profit or work centres or administrative office wise E
93.
FA.GL.
4.24
System shall be able to repeat details from the previous journal (e.g. date,
description) while at the same time preventing duplication of journal entry
E
94.
FA.GL.
4.25
System shall be able to enter description for each detail line of a journal E
95.
FA.GL.
4.26
System shall be able to create multiple batches of journal entry at one time,
with predefined authority levels for the same
E
96.
FA.GL.
4.27
System shall be able to automatically accept and post journal entries from
Account Payable, Accounts Receivable, etc.
E
97.
FA.GL.
4.28
System shall have unique number for each journal entry E
98.
FA.GL.
4.29
System shall be able to look-up by account number and description during
entry
E
99.
FA.GL.
4.30
System shall be able to create automatic recurring entries that allocate one
account balance among several others based on ratios
E
100.
FA.GL.
4.31
System shall be able to terminate a recurring journal entry based on the
automatic accumulation of all payments equalling total commitment
E
101.
FA.GL.
4.32
System shall be able to set starting and ending period/year for recurring entries E
102.
FA.GL.
4.33
System shall be able to enter and maintain statistical information either along
with or independently of journal entries
E
103.
FA.GL.
4.34
System shall prevent duplicate posting to the same account E
104.
FA.GL.
4.35
System shall be able to check before a period close that all the vouchers have
been authorized and posted and System shall give a warning if some
unauthorized /unposted voucher remains in the system
E
105.
FA.GL.
4.36
System shall ensure at year-end close that all entries are in balance and that all
periods have been closed
E
106.
FA.GL.
4.37
System shall identify and process accruals with automatic reversal in the next
accounting period
E
107.
FA.GL.
4.38
System shall automatically roll-up detail accounts to summary accounts E
108.
FA.GL.
4.39
System shall be able to calculate and maintain current, prior, and previous year
comparative information
E
109.
FA.GL.
4.40
System shall provide capability to revise invalid journals, subject to predefined
authority
E
110.
FA.GL.
4.41
System shall be able to define a number of suspense codes E
111.
FA.GL. System shall be able to post errors to different suspense codes according to the
E
4.42 source
112.
FA.GL.
4.43
System shall be able to correct transactions posted to suspense real time E
113.
FA.GL.
4.44
System shall have a GL report writer E
114.
FA.GL.
4.45
System shall be able to generate unlimited number of financial reports for
balance sheet, income statement, supporting schedule, cash flow and other
specific account analysis
E
115.
FA.GL.
4.46
System shall be able to specify the contents of each column with no restriction
i.e. current month, current budget, year to date, budget to date, last year to
date
E
116.
FA.GL.
4.47
System shall support online posting of all financial transactions in GL and
updating of all reports
E
117.
FA.GL.
4.48
System shall support drilldown from GL entries to individual transactions E
118.
FA.GL.
4.49
System shall support mapping of transactions to respective operating office
based on user id / office code to facilitate generation of various reports office
wise
E
119.
FA.GL.
4.50
System shall allow all offices to drill down to transaction level in respect of
offices/intermediaries under their administrative control
E
120.
FA.GL.
4.51
System shall provide for what if analysis with option to post / not post to GL E
121.
FA.GL.
4.52
System shall allow user to indicate closure of an accounting period for a given
office and prevent further accounting in the closed period
E
122.
FA.GL.
4.53
System shall enforce uniformity in transaction date and accounting date in
respect of all accounting transactions except those done through Journal
Vouchers, in which case the accounting can be backdated.
E
123.
FA.GL.
4.54
System shall have ability to track backdated adjustments E
124.
FA.GL.
4.55
System shall have facility for Multi currency transaction, indexation, exchange
gain / loss, accounting treatment to Exchange Gains/Loss as per companys
stated Significant Accounting Policy in the Annual Report
E
125.
FA.GL.
4.56
System shall be able to override standard currency exchange rate with each
input transaction
E
126.
FA.GL.
4.57
When the standard exchange rate is overridden, output report generated
System shall show:
E
127.
FA.GL.
the standard exchange rate E
4.57.1
128.
FA.GL.
4.57.2
the override exchange rate E
129.
FA.GL.
4.57.3
the person entering the override transaction E
130.
FA.GL.
4.58
All postings and account balances System shall be maintained in both local
currency and user-defined foreign currencies
E
131.
FA.GL.
4.59
System shall be able to calculate foreign exchange gains/losses E
132.
FA.GL.
4.60
System shall maintain a history of exchange rates. The history shall capture the
effective date of a change to an exchange rate, the date it was changed and by
whom and details of what the rate was changed from/to
E
133.
FA.GL.
4.61
System shall provide multi-currency support with ability for authorized user to
create a new currency and exchange rate in addition to those already available
E
134.
FA.GL.
4.62
System shall permit modification / cancellation of receipts / payment vouchers
only by designated users
E
135.
FA.GL.
5
System shall allow for post adjustment entries in closed period with proper
audit trail and authorization
E
Closing of Accounts
136.
FA.GL.
6
System shall have the ability of periodic and year end closing of accounts be
done as per user defined closing calendar
E
137.
FA.GL.
6.1
System shall carry forward the closing balance of the financial year as opening
balance to the next financial year automatically
E
138.
FA.GL.
7
System shall have the ability to automatically generate General Ledger
Accounts required to support transactions according to modifiable business
rules. Facility to generate the General Ledger Accounts for the DoP as a whole.
If the DoP wishes to generate accounts for particular region or branch only or
for a particular territory/state/LoB, then the ability for such a request must be
available.
E
139.
FA.GL.
7.1
System shall have ability to transfer charge-back and profit to any account
and/or cost/profit centre from any activity.
E
140.
FA.GL.
7.2
System shall have the ability to create parent-child (nested) relationships
between accounts.
E
Reporting
141.
FA.GL.
8
System shall be able to group by : E
142.
FA.GL.
Legal Entity E
8.1
143.
FA.GL.
8.2
Controlling Area / LOB E
144.
FA.GL.
8.3
Profit Centre Hierarchy E
145.
FA.GL.
8.4
Cost Centre Hierarchy E
146.
FA.GL.
8.5
Operating Concern E
147.
FA.GL.
8.6
Product wise E
148.
FA.GL.
8.7
Maintenance of Cash GL E
149.
FA.GL.
8.8
Maintenance of Sundry/Suspense GL E
150.
FA.GL.
8.9
Maintenance of Contra Heads E
151.
FA.GL.
9
System shall have the ability to facilitate book closure at periodical intervals
(monthly, quarterly, half-yearly/yearly or at any user definable time-frame).
E
152.
FA.GL.
10
System shall post all transactions received from other systems directly to a GL
suspense , pending review and adjustment before actual posting :
E
153.
FA.GL.
10.1
Backvalued entries shall be allowed E
154.
FA.GL.
10.2
Time period for back valuation shall be 2 / 3 years which is to be available as
user definable option
E
155.
FA.GL.
10.3
Average balances shall be automatically recalculated E
156.
FA.GL.
10.5
Flag accounts which are inactive through user determined criteria E
157.
FA.GL.
10.6
Suppress printing accounts with zero balance on reports and financial
statements (Flexible)
E
158.
FA.GL.
10.7
Access account numbers and descriptions during data entry E
159.
FA.GL.
10.8
Allow multiple accounting periods to be open at one time E
Interfaces with Other Systems
160.
PBS
system
GL shall have an inbound interface with CBS solution for getting daily summary
of transactions posted in CBS
E
161.
PLI
system
GL shall have an inbound interface with PLI solution for getting daily summary
of transactions posted in PLI
E
162. MLASS
GL shall have an inbound interface with MLASS/ Mail Accounting engine
solution for getting daily summary of mail transactions
E
163. AR/AP
GL shall have an inbound interface with AR/ AP Functions to pass details of
receivables and payables of DoP. The details shall be updated in AR/AP as and
when the receivables and payables are cleared.
E
164. Payroll
GL shall have an inbound interface with Payroll Function to update all the
details of pay bills and other bills drawn by employees of India Post
E
8.4.4.2 Requisition & Procurement
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

Requisition
1. FA.RP.1
System shall allow users at the operational unit (HO/SO) to raise
procurements requests for operational items .System shall treat these users as
light users
E
2.
FA.RP.1
.1
System shall enable HO and SO to send requests for procurement directly to
divisional office or PSD/CSD as case may be
E
3.
FA.RP.1
.1.1
System shall allow for requests from HO& SO to be automatically collated into
the Procurement Function
E
4.
FA.RP.1
.2
System shall interface with Inventory Management Function E
5.
FA.RP.1
.2.1
System shall allow designated users at PAO/CSD/PSD and circle office to view
inventory of all HO/ SO
E
6.
FA.RP.1
.2.1.1
System shall enable user to fix reorder levels and reorder quantities for
different items of inventory
E
7.
FA.RP.1
.2.2
System shall auto monitor the inventory levels across all operative offices and
send auto procurement request to CSD/ PSD when inventory approaches the
pre defined re-order level
E
8.
FA.RP.1
.2.2.2
System shall send request for pre set quantities E
9.
FA.RP.1
.2.2.3
System shall only reorder quantities as defined but allow the user to manually
change the quantities to be ordered only after proper authorisation
E
10.
FA.RP.1
.2.3
System shall keep a timestamp record of the procurement request and
overriding exception approvals if any
E
11.
FA.RP.1
.2.4
System shall generate a MIS report of all procurement requests made, fulfilled
open and expired along with any deviation approvals
E
12.
FA.RP.1
.3
System shall interface with PBS inventory Function to monitor inventory of
security items such as Cheque Book and Cash Certificate/ Stamps and initiate
a procurement request to PSD and CSD respectively when inventory
approaches the pre defined re-order level
E
Request for procurement
13. FA.RP.2 System shall allow for raising request of procurement from external vendors E
14.
FA.RP.2
.1
System shall allow for CSD/ PSD to raise procurement requests to external
vendor
E
15.
FA.RP.2
.1.1
System shall interface with Inventory Management Function E
16.
FA.RP.2
.1.1.1
System shall allow for requests from HO/SO to be automatically collated into
the Procurement Function
E
17.
FA.RP.2
.1.1.2
System shall also allow for manual entry of requests from HO/ SO E
18.
FA.RP.2
.2
System shall allow requisition approvals to be automatically routed through
defined Workflow
E
19.
FA.RP.2
.2.1
System shall allow for request to be approved by Sanctioning Authority (to be
decided according to delegation of financial powers) for financial concurrence
E
20.
FA.RP.2
.2.2
System shall allow for sanctioned request to be routed to Purchasing Director
for placing order with DGS&D
E
21.
FA.RP.2
.3
System shall allow for raising a request of procurement through DGS&D E
22.
FA.RP.2
.4
System shall allow for raising a request of procurement through vendors
selected by tendering process
E
23.
FA.RP.2
.5
System shall indicate the status of the procurement request (Open, Processing,
In transit, Closed)
E
24.
FA.RP.2
.6
System shall interface with Budget Function E
25.
FA.RP.2
.6.1
The Sanctioning Authority shall be able to view the available budget for the
concerned procurement request
E
26.
FA.RP.2
.6.2
System shall make available to the Purchase Officer, the budget available for
the concerned item
E
27.
FA.RP.2
.6.3
System shall update available budget after sanction is approved E
Issuance of Purchase Order
28. FA.RP.3
System shall be able to issue Purchase Orders after approval by Sanctioning
Authority (to be decided according to delegation of financial powers) for
financial concurrence
E
29.
FA.RP.3
.1
System shall be enabled to issue Purchase Orders to DGS&D E
30.
FA.RP.3
.2
System shall be enabled to issue Purchase Orders to vendors selected through
tendering process
E
31.
FA.RP.3
.3
System shall be enabled to issue Purchase Orders to 3rd party/ printer for
replenishment of CSD/ PSD
E
32.
FA.RP.3
.4
System shall map Purchase Orders raised to the requisition raised by PAO/
concerned Admin Office
E
33.
FA.RP.3
.5
System shall allow for delivery of Purchase Orders to DGS&D through email
stored as contact information
E
34.
FA.RP.3
.5.1
System shall allow for change of contact number or email of vendor E
35.
FA.RP.3
.6
System shall allow for delivery of Purchase Orders to vendors via email stored
as contact information
E
36.
FA.RP.3
.6.1
System shall allow for change of contact number or email of vendor E
37.
FA.RP.3
.7
System shall allow for Purchase Orders to be classified by type of purchases/
value of purchases
E
38.
FA.RP.3
.8
System shall compute Income Tax (TDS) and Service Tax for each transaction
wherever applicable at current rates for each Purchase Order issued
E
Goods Receipt
39. FA.RP.4
System shall provide the ability for acknowledgement of receipt of goods/
services online
E
40.
FA.RP.4
.1
System shall enable indenting office to specify consignee entitled to receive
goods from third party/CSD/PSD
E
41.
FA.RP.4
.2
System shall enable the indenting office/designated consignee to acknowledge
receipt of goods through defined workflow and send intimation to Purchase
officer.
E
42.
FA.RP.4
.2.1
System shall record the time stamp of such acknowledgement E
43.
FA.RP.4
.2.2
Upon receipt of goods, an intimation/alert shall also be sent to the indenting
office.
E
44.
FA.RP.4
.2.3
System shall manage invoice-to-order matching - 2/3/4 way E
45.
FA.RP.4
.3
System shall recognize the value of goods received as 'Liability' in GL and also
update the Account Payable Function
E
46.
FA.RP.4
.3.1
System shall send an intimation to the PAO alerting about the receipt of goods
and creation of liability
E
47.
FA.RP.4
.4
System shall enable the Purchase officer to close procurement request after
intimation from consignee through defined workflow
E
48.
FA.RP.4
.5
System shall update Inventory Management Function with details of goods
received upon closure of the request
E
Vendor Account
49. FA.RP.5
System
shall allow for creation of new vendor record
E
50.
FA.RP.5
.1
System shall allow user to enter details of new vendor E
51.
FA.RP.5
.1.1
System shall capture mandatory fields such as PAN No., TIN no., TAN No., Bank
A/c details, etc
E
52.
FA.RP.5
.1.2
System shall prevent creation of duplicate vendor records E
53.
FA.RP.5
.2
System shall be able to classify vendor based on type of goods/ services
procured from them
E
54.
FA.RP.5
.3
System shall be able to provide list of vendors with no or limited activity D
55.
FA.RP.5
.3.1
System shall be able to alert Purchasing Director of vendors with limited
activity for further action
D
8.4.4.3 Inventory Management
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

Inventory Status
1.
FA.IM.
1
System shall track inventory level of cheque books, pre printed CC, stamps ,
materials at various locations
E
2.
FA.IM.
1.1
System shall track inventory at Post Offices on an ongoing basis E
3.
FA.IM.
1.1.1
System shall update inventory level at Post Offices after receipt of physical
goods from CSD/ PSD
E
4.
FA.IM.
1.1.1.1
System shall update the inventory level after indenting office acknowledges
receipt of goods in the system and close the procurement request
E
5.
FA.IM.
1.1.1.2
System shall record the quantity of items received E
6.
FA.IM.
1.1.1.3
System shall record the serial numbers of the of items received E
7.
FA.IM.
1.1.2
System shall update inventory levels of Post Offices on an ongoing basis E
8.
FA.IM.
1.1.2.1
System shall interface with the PoS/ Mail application to update the inventory
of stamps, envelopes and other postal items and update inventory levels
accordingly
E
9.
FA.IM.
1.1.2.2
System shall interface with the PBS solution to monitor issuance of security
items such as cheque books, debit cards and update inventory levels
accordingly
E
10.
FA.IM.
1.2.2.3
System shall interface with the PBS solution to monitor issuance of items such
as pre printed cash certificates based transactions and update the inventory
level accordingly
E
11.
FA.IM.
1.2
System shall be able to track inventory at CSD/ PSD on an ongoing basis E
12.
FA.IM.
1.2.1
System shall update inventory level at CSD/ PSD upon receipt of inventory
from printing press/ 3rd party
E
13.
FA.IM.
1.2.1.1
System shall update the inventory level upon acknowledgement of receipt of
goods by indenting office in the system and close the procurement request
E
14.
FA.IM.
1.2.2
System shall update inventory level at CSD/ PSD to account for the physical
dispatch of material to HO/ SO/ BO after it is acknowledged by the indenting
office
E
15.
FA.IM.
1.3
System shall generate reports to show daily inventory position for each item E
16.
FA.IM.
1.3.1
System shall generate MIS reports for inventory position at Post Office level E
17.
FA.IM.
1.3.1.1
System shall generate MIS report for open inventory transfer requests
between offices
E
18.
FA.IM.
1.3.2
System shall generate MIS reports for inventory position at CSD/ PSD level E
19.
FA.IM.
1.4
System shall be able to track ,identify and alert user against obsolete inventory E
20.
FA.IM.
1.5
System shall record and account for discrepancies arising out of physical
E
Interface with Procurement
21.
FA.IM.
2
System shall interface with Procurement Function E
22.
FA.IM.
2.1
System shall send automatic trigger to Procurement Function for re-order to
CSD/ PSD when inventory approaches re-order level
E
23.
FA.IM.
2.1.1
System shall allow user to manually edit the re-order level which initiates the
E
24.
FA.IM.
2.2
System shall send automatic trigger to Procurement Function for sanction of
procurement at CSD/ PSD when inventory approaches re-order level
E
Interface with GL
25.
FA.IM.
3
System shall interface with General Ledger Function E
26.
FA.IM.
3.1
System shall reflect inventory at CSD/ PSD under Current Assets HoA of GL E
Inventory Management for Retail Post items
27.
FA.IM.
4
Retail Inventory items under WMS E
28.
FA.IM.
4.1
System shall keep a track of the inventory of retail items sold through the POs
as also through the web portal of the DoP on an on going basis
E
29.
FA.IM.
4.2
System shall generate reports to show daily inventory position for each item E
30.
FA.IM.
4.3
System shall update the inventory level upon acknowledgement of receipt of
items by the central stores from 3rd party vendors/partners in the system
E
31.
FA.IM.
4.4
System shall record the quantity and serial number of items received E
32.
FA.IM.
4.5
System shall generate MIS reports to show daily inventory position (quantity
and value) for each item
E
33.
FA.IM.
System shall be able to track ,identify and alert user about obsolete inventory E
4.6
34.
FA.IM.
4.7
System shall record and account for discrepancies arising out of physical
E
35.
FA.IM.
4.8
System shall send automatic trigger to Relationship Manager for re-order to
3rd party/partner when inventory approaches re-order level
E
36.
FA.IM.
4.9
System shall enable user to manually edit the re-order level which triggers the
E
8.4.4.4 Accounts Receivable
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

Customer Tracking
1.
FA.AR.
1
System shall have ability to track customers E
2.
FA.AR.
1.1
System shall be able to create new customer accounts in Order Management
or Account receivables
E
3.
FA.AR.
1.2
System shall have a Sub Ledger for different customers/ agencies for Book
Now Pay Later products
E
4.
FA.AR.
1.3
System shall interface with mail application /POS and update the extent of
order fulfilled based on information received
E
Claims Management
5.
FA.AR.
2
System shall raise claims on respective agencies E
6.
FA.AR.
2.1
System shall raise monthly Invoice on EPF and CMPF for pension amount and
commission
E
7.
FA.AR.
2.2
System shall raise monthly Invoice on Railways for pension amount and
commission
E
8.
FA.AR.
2.3
System shall raise monthly Invoice on Telecom Department for commission E
9.
FA.AR.
2.4
System shall raise monthly Invoice on any other agency for pension amount
and commission as applicable
E
10.
FA.AR.
2.5
System shall raise invoices on bulk mail customers as per the pre defined
milestones
E
11.
FA.AR.
2.6
System shall raise periodic Invoice on International Postal Organizations for
services rendered to deliver articles (EMS, Parcel, Mails) within country
E
12.
FA.AR.
2.7
System shall square off receivables on clearance of payment by the concerned
agency
E
13.
FA.AR.
2.7.1
System shall allow user to nullify receivables from Railways on receipt of RBI
clearance memo
E
14.
FA.AR.
2.7.2
System shall allow set off of receivables and payables at client level E
15.
FA.AR.
2.7.3
System shall allow treatment of negative payables as receivables E
Interface with GL
16.
FA.AR.
3
System shall interface with the GL Function E
17.
FA.AR.
3.1
System shall update receivables GL with Pension and commission amount for
pension disbursed to other agencies (EPF, CMPF, Railways, Telecom)
E
18.
FA.AR.
3.2
System shall update receivables GL with Book Now Pay Later orders fulfilled E
19.
FA.AR.
3.3
System shall update receivables GL with net amount due from International
Postal organizations
E
Receivable Management
20.
FA.AR.
4
System shall calculate receivables due to India Post E
21.
FA.AR.
4.1
System shall maintain Sub Ledger for different customers/ agencies E
22.
FA.AR.
4.2
System shall calculate interest earned on receivables on account of late
payment
E
23.
FA.AR.
4.3
System shall calculate receivable basis interest calculated and advance
payment received
E
24.
FA.AR.
4.4
System shall send notification to agency on amount receivable by DoP E
25.
FA.AR.
4.4.1
System shall specify interest accrued on amount E
26.
FA.AR.
4.4.2
In case online notification cannot be sent, system shall generate a physical
copy of the notification
E
27.
FA.AR.
4.5
Should support adjustment of premium on proposals against amount in the
clients suspense account or against subsidy already received from the
E
government
28.
FA.AR.
4.6
Should support Payment Before Cover option as per Indian regulations E
29.
FA.AR.
4.7
Should be able to maintain an Accounts Receivable master record with details
(Code, Name, Address, Phone no., Email id, Payment Terms, Bank Account
details, Payment history, etc.):
E
30.
FA.AR.
4.8
Should be able to keep track of premium receipt from client in case of
payment through Bank Guarantee and generate alert when payment is not
done before due date
E
31.
FA.AR.
4.9
Should be able to deduct commission recoverable from the payable
commission
E
32.
FA.AR.
4.10
Should allow for creation of receivables at policy level, client level, and
agent/broker and co-insurer levels
E
33.
FA.AR.
4.11
Should allow set off of receivables and payables at client level E
34.
FA.AR.
4.12
Should allow treatment of negative payables as receivables (negative payables
can come into effect when recovery of agency commission due to
refund/cheque dishonour exceeds the commission payable on business
procured for a given agent for a given period)
E
35.
FA.AR.
5
System shall interface with the Pension Auditing Software of Department of
Telecom, EPF, CPMF, Railways
E
8.4.4.5 Accounts Payable
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

Invoice receipt
1.
FA.AP.
1
System shall acknowledge receipt of invoices raised on DoP E
2.
FA.AP.
1.1
System shall allow for three way checking of invoices against Purchase Order
and acknowledgment of receipt (challan)
E
3.
FA.AP.
1.2
System shall support invoice entry along with payment schedules for direct
invoices as well as PO based invoices
E
4.
FA.AP.
1.2.1
System shall also allow for manual entry of invoice details E
5.
FA.AP.
1.3
System shall have the ability to block invoice payments to vendors along with
reason codes
E
6.
FA.AP.
1.4
System shall provide for authorization of release of payment against invoice
raised to DoP through defined workflow
E
7.
FA.AP.
1.4.1
System shall raise alert for approval of invoice to Sanctioning Authority basis
delegated financial powers
E
8.
FA.AP.
1.4.2
System shall record the approvals given by various Sanctioning Authorities for
audit purposes
E
9.
FA.AP.
1.5
System shall maintain Sub Ledgers for various vendors/ agencies E
10.
FA.AP.
1.5.1
System shall receive information on volumes transferred by air carrier and
price rates from IPVS
E
11.
FA.AP.
1.5.2
System shall calculate amount due to air carriers from price and volume
information received from IPVS
E
12.
FA.AP.
1.5.3
System shall maintain records of Railway Haulage charges due to Railways E
13.
FA.AP.
1.5.4
System shall pass accounting entries from vendor Sub Ledger into GL for any
payments made to other vendors/agencies
E
14.
FA.AP.
1.5.5
System shall track different kinds of advance payment made to vendors in the
vendor Sub Ledger
E
15.
FA.AP.
1.5.6
System shall maintain details of payment transactions for different vendors in
Sub Ledgers
E
16.
FA.AP.
1.6
System shall generate list of outstanding invoices and age of invoice E
17.
FA.AP.
1.7
System shall reflect invoice wise outstanding for a particular vendor or group
of vendors
E
18.
FA.AP.
1.8
System shall allow set off of receivables and payables at client level E
Payment
19.
FA.AP.
2
System shall allow for payments to be made to vendors through different
modes
E
20.
FA.AP.
2.1
System shall support flexibility for selecting invoices for payment E
21.
FA.AP.
2.1.1
System shall support selection of invoices that are yet to be paid E
22.
FA.AP. System shall support selection of invoices that are approaching due date for
E
2.1.2 payment
23.
FA.AP.
2.2
System shall have the ability of advance to be given to vendors on the basis of
PO
E
24.
FA.AP.
2.3
System shall allow for partial payment of invoices E
25.
FA.AP.
2.3.1
System shall allow user to indicate whether particular payment will close an
invoice
E
26.
FA.AP.
2.4
System shall have the ability to release payments on account to a vendor and
link it to vendor specific invoice(s) received
E
27.
FA.AP.
2.5
System shall have the ability to facilitate centralized payment for multiple
invoices raised by a vendor
E
Error proofing
28.
FA.AP.
3
System shall provide for error checking E
29.
FA.AP.
3.1
System shall not allow for over payment to vendor E
30.
FA.AP.
3.2
System shall check for and stop duplicate invoices from being processed E
31.
FA.AP.
3.2.1
System shall alert the user against the possibility of duplicate payment E
Interface with Procurement
32.
FA.AP.
4
System shall interface with Procurement Function E
33.
FA.AP.
4.1
System shall create a payables record in AP upon receipt of goods by the
indenting office/designated consignee
E
34.
FA.AP.
4.2
System shall provide for online query of Purchase Orders from procurement
Function
E
35.
FA.AP.
4.3
System shall map invoice to the PO against which it was raised (if applicable) E
Interface with PBS
36.
FA.AP.
5
System shall interface with the PBS Function E
37.
FA.AP.
5.1
System shall make available to PBS, the payment details to be released to the
vendor
E
38.
FA.AP.
5.1.1
System shall interface with PBS notifying it of payments due as per scheduled
payout dates
E
39.
FA.AP.
5.2
System shall allow for user to hold payment to a specific vendor E
40.
FA.AP.
5.3
System shall be able to maintain master accounts payable data E
41.
FA.AP.
5.3.1
Address and contact details E
42.
FA.AP.
5.3.2
Bank details E
43.
FA.AP.
5.3.3
Payment terms E
44.
FA.AP.
5.3.4
Employee remarks E
45.
FA.AP.
5.4
System shall generate reports on Ageing analysis for payments due E
46.
FA.AP.
5.5
System shall maintain and generate reports on Outstandings with reasons and
action plan
E
47.
FA.AP.
5.6
System shall be able to calculate interest on overdue balances as it may be
specified by the user
E
48.
FA.AP.
5.7
System shall be able to capture data for printing cheque automatically from
the system
E
49.
FA.AP.
5.8
System shall be able to print cheque drawn on multiple bank accounts E
50.
FA.AP.
5.9
System shall be able to recover in the event of a failure in the cheque printing
process
E
51.
FA.AP.
5.10
System shall be able to prevent the same cheque from being printed in both
the original and the recovery process run
E
52.
FA.AP.
5.11
System shall reconcile voided, cancelled or returned cheque E
53.
FA.AP.
5.12
System shall generate alerts for cheques pending for more than 7 days E
54.
FA.AP.
5.13
System shall be capable of tracking rejections, retransmissions, returns E
55.
FA.AP.
5.14
System shall be capable of integrating with SWIFT, NEFT, RTGS messages E
56.
FA.AP.
5.15
System shall be able to handle employee expense reimbursement description,
dates and time periods, and cross reference to related sales outcome by:
E
57.
FA.AP.
5.16
System shall distinguish between types of prepaid advances and adjustment
of same while passing the bill
E
58.
FA.AP.
5.17
System shall be able to select bank accounts for disbursements, including
reviewing multiple bank accounts to determine the proper account to issue
checks from
E
59.
FA.AP.
5.18
System shall be able to process manual cheques E
60.
FA.AP.
5.19
System shall be able to issue post dated cheques E
61.
FA.AP.
5.20
In case of posted payment being voided, GL posting System shall be
automatically reversed
E
62.
FA.AP.
5.21
System shall generate alerts / reminders based on the Payment terms with
the Party
E
63.
FA.AP.
5.22
System shall be able to record reasons against payments E
64.
FA.AP.
5.23
System shall provide facility to issue one cheque for multiple
claims/transactions and facility to issue the cheque in name of third party;
System shall allow multiple payees for a single transaction
E
65.
FA.AP.
5.24
System shall have provision to set payment priorities (for cases when limited
funds are available)
E
66.
FA.AP.
5.25
System shall enable electronic funds transfer to partners, vendors towards
any payments
E
67.
FA.AP.
5.26
System shall support integration with the Core applications to alert the
Accounts Processing Centre for various payments due and enable electronic
payments
E
8.4.4.6 Asset Accounting
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

Asset Database
1.
FA.AC.
1
System shall maintain a database of all assets at DoP exceeding ` 5000 in value
at the time of purchase
E
2.
FA.AC.
System shall maintain database of Assets purchased by DoP E
1.1
3.
FA.AC.
1.1.1
System shall fetch detail of assets purchased from Procurement Function E
4.
FA.AC.
1.1.1.1
System shall update list and value of assets owned by DoP upon
acknowledgement of the receipt of assets by the indenting office
E
5.
FA.AC.
1.1.1.2
System shall note the date of purchase of asset E
6.
FA.AC.
1.1.2
System shall record the location of asset E
7.
FA.AC.
1.1.3
System shall record the description of asset E
8.
FA.AC.
1.1.4
System shall record the 'Salvage value' of the asset E
9.
FA.AC.
1.1.5
System shall record the 'Useful Life' of the asset E
10.
FA.AC.
1.2
System shall maintain database of Assets leased by DoP D
11.
FA.AC.
1.3
System shall support automatic posting when an asset is either retired,
scrapped, transferred, etc
E
Depreciation
12.
FA.AC.
2
System shall calculate value of depreciation of asset E
13.
FA.AC.
2.1
System shall notify Purchase officer when asset is nearing the end of its useful
life
D
14.
FA.AC.
2.2
System shall generate reports on a half yearly/ annual basis on list of assets
owned by DoP at Circle level
D
15.
FA.AC.
2.2.1
System shall be able to calculate the book value of asset in report E
16.
FA.AC.
2.3
System shall generate reports on a half yearly/ annual basis on list of assets
owned by DoP at pan India level
D
17.
FA.AC.
2.3.1
System shall calculate the book value of asset in report E
Interface with Budgeting
18.
FA.AC.
3
System shall interface with Budget Function E
19.
FA.AC. System shall make available to the Budget Function asset information for
D
3.1 preparing Budget estimates
20.
FA.AC.
3.2
System shall accommodate a user- definable asset number E
21.
FA.AC.
3.3
System shall be able to accommodate unlimited number of assets E
22.
FA.AC.
3.4
System shall be able to maintain details of written-off assets, whilst excluding
these from general reporting and all current asset valuation calculations
E
23.
FA.AC.
3.5
System shall generate sequential number per asset E
24.
FA.AC.
3.6
System shall be able to enter Project / Department cost centre codes in the
fixed assets system at the time of approval of Capex
E
25.
FA.AC.
3.7
System shall be able to maintain comprehensive fixed assets register,
including:
E
26.
FA.AC.
3.7.1
value of asset E
27.
FA.AC.
3.7.2
date of purchase E
28.
FA.AC.
3.7.3
asset reference code E
29.
FA.AC.
3.7.4
description E
30.
FA.AC.
3.7.5
short name E
31.
FA.AC.
3.7.6
memorandum notes (optional, and up to 1,000 characters) E
32.
FA.AC.
3.7.7
depreciation type E
33.
FA.AC.
3.7.8
depreciation formula E
34.
FA.AC.
3.7.9
accumulated depreciation E
Asset Verification
35.
FA.AC.
4
System shall facilitate inventory verification periodically E
36.
FA.AC.
4.1
System shall be able to categorize assets to facilitate a variety of depreciation
rates
E
37.
FA.AC.
4.2
System shall be able to change the method of depreciation E
38.
FA.AC.
4.3
System shall be able to maintain the status of an asset and related details
stored when the asset is sold or discarded along with a flag to highlight 'sold
/discarded'
E
39.
FA.AC.
4.4
System shall automatically generate the necessary transactions to support
asset write-on's/write-off's
E
40.
FA.AC.
4.5
System shall automatically generate the entry for loss/Profit of sale of assets E
41.
FA.AC.
4.6
System shall automatically generate the necessary transactions to support
asset transfers
E
42.
FA.AC.
4.7
System shall facilitate tracking of maintenance (AMC) D
43.
FA.AC.
4.8
System shall automatically update the location of an Asset as soon as a
Transfer Note is approved for transfer of the asset
E
44.
FA.AC.
4.9
System shall automatically post write-on, write-off and transfer transactions
to the General Ledger
E
45.
FA.AC.
4.10
System shall automatically post depreciation allocations as per user defined
criteria
E
46.
FA.AC.
4.11
System shall request user verification for all transactions/processes performed E
47.
FA.AC.
4.12
System shall be able to post adjustment transactions online to the General
Ledger
E
48.
FA.AC.
4.13
System shall generate annual insurance re-valuation and replacement cost
reports
D
49.
FA.AC.
4.14
System shall be able to generate Asset Valuation Report, by category E
50.
FA.AC.
4.15
System shall be able to generate Asset Write-On, Transfer and write-off
Report, for a given period
E
51.
FA.AC.
4.16
System shall be able generate Asset Write-On, Transfer and write-off Report,
by Cost Centre / Project
E
52.
FA.AC.
4.17
System shall be able to track insurance status of assets, with alerts when
renewal is due
D
8.4.4.7 Payroll
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

Employee Database
1. FA.PY.1 System shall maintain database of Employees at DoP E
2.
FA.PY.1
.1
System shall maintain database of Employees on rolls of DoP E
3.
FA.PY.1
.1.1
System shall update list of Employees when an employee joins or exits E
4.
FA.PY.1
.1.2
System shall record the location where the employee is posted E
5.
FA.PY.1
.1.3
System shall record details about self, dependents , bank account, date of
birth , permanent address etc
E

FA.PY.1
.1.4
System shall record the cadre and designation of employee E
6.
FA.PY.1
.2
System shall maintain database of all salary components of the employee like
Basic salary, HRA entitlement, TA,DA,LTC ,overtime, etc
E
7.
FA.PY.1
.2.1
System shall interface with the IPVS to fetch details of overtime working by
mail operations employees for payroll calculations
E
8.
FA.PY.1
.3
System shall interface with Establishment Review Master to get employee
information for calculating payroll
E
9.
FA.PY.1
.3.1
System shall fetch the leave details of each employee from the leave
management system in .xls or csv format which will be uploaded into the
payroll processing module
E
10.
FA.PY.1
.3.2
System shall fetch the penalty and other details of each employee D
11.
FA.PY.1
.4
System shall notify the Salary processing team of an employees impending
retirement/superannuation based on date of birth record in the system
E
12.
FA.PY.1
.5
System shall support automatic update of salary components based on change
in employees location , status i.e. retired or transferred to a different location
etc
E
Payroll calculation
13. FA.PY.2 System shall calculate payroll of employees in Circle E
14.
FA.PY.2
.1
System shall allow defined users to access payroll data and run payroll for
respective Circles only
E
15.
FA.PY.2
.2
System shall run separate payrolls for different cadres depending on
eligibilities and rules applicable for each category
E
16.
FA.PY.2
.3
System shall have the facility for reimbursements of Leave Travel Concession
(LTC), medical reimbursement, other reimbursements that the employee is
eligible to
E
17.
FA.PY.2
.3.1
System shall check the payment against the overall entitlement E
18.
FA.PY.2
.3.2
System shall dynamically reduce the balance payable based on each part
payment made
E
19.
FA.PY.2
.3.3
System shall allow for employees to view the balance receivable at any time D
20.
FA.PY.2
.4
System shall maintain details of Loans & Advances of each employee on the
payroll
E
21.
FA.PY.2
.5
System shall compute all statutory deductions from salary such as Income Tax,
GPF contributions, HBA, Insurance premium etc(details to be finalized ) and
deduct the same from the Payout figure
E
22.
FA.PY.2
.5.1
System shall define various pay elements like earnings and deductions using a
rule based framework
E
23.
FA.PY.2
.5.1.1
System shall define the rules of earnings and deductions as per the guidelines
of the Government of India/State Governments
E
24.
FA.PY.2
.5.1.2
System shall allow for the rules to be changed in case of directive by
Government of India/State Governments
E
25.
FA.PY.2
.6
System shall have the capability to handle tax computation of employees as
per Income Tax Act
E
26.
FA.PY.2
.6.1
System shall maintain the tax slabs, rates and surcharges and compute the tax
automatically
E
27.
FA.PY.2
.7
Disbursement of payroll shall be done only through bank credit E
28.
FA.PY.2
.7.1
System shall enable payroll disbursement into employee bank accounts
through any of the following three modes by generating a payroll detail file for
uploading into PBS /Sanchay post/ECS of other banks
D
29.
FA.PY.2
.7.1.1
System shall enable credit of the payroll amount directly into POSB accounts
for the identified 4000 PBS enabled branches
D
30.
FA.PY.2
.7.1.2
System shall enable credit of the payroll amount into employees ECS
supported bank accounts with other Public sector banks
D
31.
FA.PY.2
.7.1.3
System shall enable an MIS report for payroll of those employees who do have
any PBS enabled POSB/other bank ECS account and continue to have an
account with a Sanchay Post supported Post office
D
32.
FA.PY.2
.8
System shall generate exception report at every salary processing cycle to
highlight any discrepancies :Missing account nos., wrong account nos., closed
/transferred SB accounts etc.
E
33.
FA.PY.2
.9
System shall post the salary details to GL classified under appropriate HoA E
34.
FA.PY.2
.10
System shall be able to run multiple payrolls in a single instance E
35.
FA.PY.2
.11
System shall be able to maintain a single central payroll repository and be able
to run and access payroll from any location in a centralized or decentralized
manner
E
36.
FA.PY.2
.12
System shall be able to handle the entire tax computation as per Income Tax
Act without any need for repeated manual calculations. The tax slabs, rates
and surcharges System shall be maintained by the system and the tax System
shall be computed automatically
E
37.
FA.PY.2
.13
System shall be able handle the payment of reimbursements. This payment
System shall be set to be checked against the overall limit which will be
dynamically reduced based on each part payment. The balance against this
eligible limit can be viewed for the employee at
E
38.
FA.PY.2
.14
System shall support superannuation computation E
39.
FA.PY.2
.15
System shall be capable of calculating arrears when the scheme is revised E
40.
FA.PY.2
.16
System shall be able to define various formulae and be able to link them to
other calculation formulae / elements such that when there is a rule change
only the component which has undergone a change will be effected (e.g. tax
slabs)
E
41.
FA.PY.2
.17
System shall take care of final settlement process to arrive at net to be
recovered or due
E
42.
FA.PY.2
.18
Simulation option System shall be available that can test run payroll for a
chosen payroll period
D
43.
FA.PY.2
.19
System shall be able to support the retrospective computation of changes to
the various data heads and makes the appropriate computation and payments
in the current period. These include changes in organization data, Employee
E
data
44.
FA.PY.2
.20
A retrospective computation of the salary System shall be initiated
automatically for those employees whenever there is a relevant change. The
appropriate re-computation of the statutory aspects to be carried out. Tax
shall also be automatically calculated.
D
45.
FA.PY.2
.21
System shall be able to prepare and submit quarterly and annual tax returns D
46.
FA.PY.2
.22
System shall support generation of Form 16 and other statutory documents E
47.
FA.PY.2
.23
System shall support integration with HRMS to take care of leave, attendance,
etc.
E
48.
FA.PY.2
.24
System shall be able to facilitate the back dating of allowances E
49.
FA.PY.2
.25
System shall be able to support various pay methods e.g. Autopay, EFT, Cash,
Cheque etc.
E
Maintenance of GPF Accounts
50. FA.PY.3 System shall maintain GPF accounts of DoP employees E
51.
FA.PY.3
.1
System shall post monthly credits to the GPF account E
52.
FA.PY.3
.2
System shall post debits to the GPF account when approved E
53.
FA.PY.3
.3
System shall calculate annual interest on GPF amount and post the same to
the account
E
54.
FA.PY.3
.4
System shall post the annual GPF amount on the employee portal E
55.
FA.PY.3
.5
System shall provide for printing the annual GPF slip E
8.4.4.8 Budgeting
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

1.
FA.BD.
1
The system should provide functionality for formulating various types of
budget like:
E
Cash budget
Expense budget
Capital budgeting
Performance based budget
Zero based budgeting
2.
FA.BD.
2
The system should ensure completeness of data for preparation of budget
(especially when data has to be sourced from other source systems)
E
3.
FA.BD.
3
The system should interface with the procurement module
E
4.
FA.BD.
4
The system should allow purchase orders to be raised for only those items
which have been included in the specified budget (fixed asset budget,
administrative expenditure budget, sales & marketing expenditure budget,
etc.)
E
5.
FA.BD.
5
The budget module shall have an inbuilt workflow defined for approval of all
procurements in line with Government of India regulations and actual
transactions shall take place only after the concurrence of Finance department
has been received

6.
FA.BD.
6
The system should allow payment to be made only for budgeted expenses and
procurements
E
7.
FA.BD.
7
The system should provide functionality to define tolerance limit for the
budget
D
8.
FA.BD.
8
The system have functionality to configure approved Schedule of Authority for
budget approval and for passing of expenditure and payment which have not
been budgeted or are in excess of the budgeted amount
E
9.
FA.BD.
9
Any amendment to a budget should be approved as per the Schedule of
Authority
E
10.
FA.BD.
10
The system should interface with the accounting GL
E
11.
FA.BD.
11
The system should interface with the fixed asset module
D
12.
FA.BD.
12
The system should provide MIS report to highlight the following:
Approved budget
Budget utilized
Budget available
E
13.
FA.BD.
13
The system should generate variation reports (Variance Analysis report) at pre
defined intervals to monitor the budget
E
14.
FA.BD.
14
The system should mail/ circulate MIS reports and variance reports to the
concerned persons
D
15.
FA.BD.
15
The system should have access control privileges in order to protect
E
confidential information
16.
FA.BD.
16
System shall record the disbursals made against approved budgets E
17.
FA.BD.
17
System shall have checks in place to disallow any single purchase in excess of
predefined limits of the DoP ( currently ` 15000)
E
18.
FA.BD.
18
System shall account all procurements done by DoP and disbursed through the
F&A solution
E
19.
FA.BD.
19
System shall record and account for any disbursements under ` 15000 made
directly through F&A only after online approvals of designated users
E
20.
FA.BD.
20
System shall enable MIS reports of Sanctioned budgets, utilization and
disbursement for Internal audit and control purposes
E
8.4.4.9 Cash Management
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

1.
FA.CM.
1.1
The system should monitor payment and receipt flow E
2.
FA.CM.
1.2
The system should have functionality for defining a payment program E
3.
FA.CM.
1.3
The system should have functionality to upload the electronic bank statement
in the cash management system. (The system should support all the formats in
which the bank statements are normally provided in the banking industry in
India)
E
4.
FA.CM.
1.4
The system should have a functionality to manually enter bank account
statement (if any)
E
5.
FA.CM.
1.5
The system should be able to do liquidity forecasting D
6.
FA.CM.
1.6
The system should integrate with the treasury application/ module (if any) E
7.
FA.CM.
1.7
The system should have functionality to create and edit payment advices (if
any)
D
8.
FA.CM.
1.8
The system should print account statements E
9.
FA.CM.
1.9
The system should be linked with the customer's/ vendor's account (if any)
and update the customer's/ vendor's account on receipt of cash from the
customer or a payment being made to the vendor
E
10.
FA.CM.
1.10
The system should support online updation of account as well as batch
updation of accounts
E
11.
FA.CM.
1.11
The system should have functionality to configure critical limits (based on
solvency assessment) in the account
E
12.
FA.CM.
1.12
The system should have functionality to send alerts to the concerned people
when a critical limit is breached
E
13.
FA.CM.
1.13
The system should have functionality to calculate and provide financial ratios
like working capital, etc
D
14.
FA.CM.
1.14
The system should provide functionality of automatic transfer of cash above a
certain limit into pre defined investments
D
15.
FA.CM.
1.15
The system should have Account Reconciliation facility E
16.
FA.CM.
1.16
The system should have access control privileges in order to protect
confidential information
E
17.
FA.CM.
1.17
The system should generate Cash Flow Statement for the defined period D
8.4.4.10 Costing
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

1.
FA.CT.1
.1
The system provide the functionality to define cost unit and cost centre E
2.
FA.CT.1
.2
The costing system should facilitate decision making, cost control and meet
reporting requirement
E
3.
FA.CT.1
.3
The system should facilitate cost assignment and cost tracking for all the cost
units and cost centres
E
4.
FA.CT.1
.4
The system should provide standard costing functionalities E
5.
FA.CT.1
.5
The system generate variance reports to track standard vs. actual E
6.
FA.CT.1
.6
The system should provide/ support the following types of costing: E
Job costing
Absorption costing
Activity Based Costing
Marginal costing
Target costing
7.
FA.CT.1
.7
The system should categorize the cost elements into fixed, variable and semi
variable
E
8.
FA.CT.1
.8
The system should provide the functionality to calculate the cost of production
or cost of rendering the service based on direct material cost/ direct cost
related to provision of service, conversion cost (if any) and non production
cost/ costs not related to rendering of service
E
9.
FA.CT.1
.9
Conversion cost should be computed based on the cost centre E
10.
FA.CT.1
.10
The system should provide the functionality to have a common cost pool for
unassignable costs
E
11.
FA.CT.1
.11
The system should facilitate inventory valuation E
12.
FA.CT.1
.12
The system should allow bifurcation on 'personnel/ employee cost' into in
house employees and contracted employees
E
13.
FA.CT.1
.13
The system should interface with the material management module and have
a common item master
E
14.
FA.CT.1
.14
The system should interface with the financial accounting module E
15.
FA.CT.1
.15
The system should maintain standard as well defined costing templates for the
various products defined by Department of Post
E
16.
FA.CT.1
.16
The system should facilitate Product pricing E
17.
FA.CT.1
.17
The system should facilitate period based cost allocation E
8.4.4.11 Other systems
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

Authorization of Pension Payments
1.
FA.OS.
1
System shall allow for sanctions for Authorization of Pension payments to DoP
employees
E
2.
FA.OS.
1.1
System shall make available to employees, the forms to be filled in for
authorization of Pension payout, through Self Service Portal
E
3.
FA.OS.
1.2
System shall allow for sanctioning of Pension payment to employee by
respective Sanctioning authority through Self Service Portal (Manager)
E
4.
FA.OS.
1.2.1
System shall provide ability of the AO/AAO at the PAO to view and cross check E
5.
FA.OS.
1.2.2
System shall provide ability for the Directorate to view details E
6.
FA.OS.
1.2.3
System shall provide the sanctioning authority to raise an Enfacement Ticket
online
E
7.
FA.OS.
1.2.4
System shall allow for corresponding HO to view ticket online E
8.
FA.OS.
1.2.5
System shall allow for HO to reply to the clarification online E
9.
FA.OS.
1.2.6
System shall allow for the Sanctioning authority to close the ticket on approval E
10.
FA.OS.
1.3
System shall allow for Pensioner to apply for change request through Self
Service Portal
E
11.
FA.OS.
1.3.1
System shall accept application for Gratuity and Commutation E
12.
FA.OS.
1.3.2
System shall accept application for Fund management in a PBS bank E
13.
FA.OS.
1.3.3
System shall accept application for changing location of Pension payout E
14.
FA.OS.
1.3.4
System shall allow for sanctioning of request through Self Service Portal
(Manager)
E
15.
FA.OS.
1.4
System shall communicate the changes made to the respective employee
through Self Service Portal
E
Self Service
16.
FA.OS.
2
System shall allow self service options with respect to New Pension Scheme E
17.
FA.OS.
2.1
System shall allow employees to fill up online forms for applying for NPS E
18.
FA.OS.
2.1.1
System shall record the following information of employees: Name,
Designation, Scale of pay, DoB, Nominee name, % of share
E
19.
FA.OS. System shall allow for employee to view and generate online statement of
E
2.2 deductions under NPS
20.
FA.OS.
2.2.1
System shall maintain the Accounts and supply Annual Statement to
employees
E
21.
FA.OS.
2.3
In case of death of employee, system shall allow for sanctioning one-time
payment of accumulated amount to nominee
E
Authorization of New Pension
22.
FA.OS.
3
System shall allow for Authorization of New Pension E
23.
FA.OS.
3.1
System shall submit electronically form to Circle PAO real time E
24.
FA.OS.
3.2
System shall sent an alert to Circle PAO to assign PRAN E
25.
FA.OS.
3.3
System shall generate an electronically compatible information feed to NSDL
for getting PRAN at the circle office (NPS)
E
26.
FA.OS.
3.4
System shall send the PRAN electronically on line to DDO and the Official E
Pension Payment
27.
FA.OS.
4
Pension Payment E
28.
FA.OS.
4.1
System shall handle Pension payments to DoP employees E
29.
FA.OS.
4.2
System shall sub- classify components of pension E
30.
FA.OS.
4.3
There shall be no limits on the number of sub- classification within a pension
account
E
31.
FA.OS.
4.4
System shall define any specific rules for functioning of different pension
accounts.
E
32.
FA.OS.
4.5
System shall generation of the pension list branch wise. E
33.
FA.OS.
4.6
System shall update the pensioners list on an incremental bases in the event of
new inclusion / deletions in the event of death etc.
E
34.
FA.OS.
4.7
System shall generate an advice branch wise and pension account wise for
any such new inclusion / deletions.
E
35.
FA.OS.
4.8
System shall accept the details of the individual pension account holders
(pensioners) like PPO, Basic pay, Allowances, submission of life certificate, date
of birth, date of commutation, date of starting pension etc.
E
36.
FA.OS.
4.9
System shall capture the signatures of the pension holders and retrieve the
same at any point of time using hot keys (user definable)
E
37.
FA.OS.
4.10
System shall calculate and post pension payments payable to different pension
accounts taking into account:
E
38.
FA.OS.
4.10.1
Salary structures E
39.
FA.OS.
4.10.2
DA / Interim relief rates E
40.
FA.OS.
4.10.3
Others E
41.
FA.OS.
4.11
System shall at least capture key details of the individual pension account
holders (pensioners) like PPO, Basic pay, Allowances, submission of life
certificate, date of birth, date of commutation, date of starting pension etc.
E
42.
FA.OS.
4.12
System shall automatically calculate and post pension arrears on account of
revision of salary structures or DA rates etc.
E
43.
FA.OS.
4.13
System shall integrate with the clearing Function for cheques deposited in the
parent pension accounts
E
44.
FA.OS.
4.14
System shall handle pension payments to the pensioners at the branches as
defined for the particular type of account e.g. pensioners only cash payments
as per limits defined, State Government Pension payment only through
Bankers Cheque etc.
E
45.
FA.OS.
4.15
System shall capture at least the minimum details at the time of payment i.e.
account number, particular of the transaction, amount, name of pensioner,
time and date of payment, mode of payment etc.
E
46.
FA.OS.
4.16
System shall generate and track a particular transaction with the help of a
unique reference number.
E
47.
FA.OS.
4.17
System shall generate a summary of pension payments made as of a particular
date / range of dates at the branch / head office level as parameterized.
E
48.
FA.OS.
4.18
System shall generate an ASCII file for pension payments made by the branch
as per defined flat file structures.
E
49.
FA.OS.
4.19
System shall upload ASCII file generated by branches not under core banking
for all pension payments made by them at the node / link branches.
E
50.
FA.OS.
4.20
System shall generate a report branch wise for all un-reconciled entries at
the parent branch
E
51.
FA.OS.
4.21
System shall automatically generate a report of all un reconciled entries
more than x number of days (parameterizable) at the parent branch
E
52.
FA.OS. System shall generate a consolidated summary for all types of pension
E
4.22 payments (State Government, central government etc.) under a particular
pension account and sub accounts (under central government - defence,
railways, civil pension etc.) as of a pa
53.
FA.OS.
4.23
System shall calculate and directly post pension payments in accounts linked
to the core banking solution from a centralized location
E
54.
FA.OS.
5
The CSI will need to deploy a fraud prevention solution to monitor movement
of cash and other remittances between various post offices
E

Interface with Bank Reconciliation software Public Account Current Software (PACS):
For bank reconciliation, DoP has implemented a separate bespoke solution called 'PACS'
which will compare the CBS bank book data from India post with CBS data received from
the focal point branch of the dealing bank at the circle office/DAP level

55.
FA.OS.
6.1
The F&A system shall have an outbound interface with the PACS solution E
56.
FA.OS.
6.2
The system shall send the daily bank book transactions for each clearing house
post office to PACS solution at every day end for reconciling with the CBS data
received from the focal point branch of the Bank
E
57. 7
FA.OS.
6.3
The Bank Reconciliation shall be done within the PACS solution E
8.4.4.12 Internal Audit & Inspection
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

1. FA.IA.1
User (Auditor) creation with access limited to viewing of EIS, Customer
Transaction data etc.
E
2. FA.IA.2 Ad-hoc report writing facility for the auditors D
3. FA.IA.3 Making ad-hoc queries satisfying the audit needs E
4. FA.IA.4
Interface enabling the data to be downloaded to the audit software for
analysis of data for audit purpose
E
5. FA.IA.5
Concurrent audit whereby transactions/activities deviating from business rules
are diverted on real-time basis to concurrent auditors.
E
6. FA.IA.6 Internal Audit Report Template for writing of Reports D
7. FA.IA.7 Monitoring & Scheduling of Internal Audits, Statutory Audits etc. D
8. FA.IA.8
System shall inform the Internal Audit modules users about any new
product/service/facility to customers/employees (such as loans) introduced by
E
DoP by way of a monthly MIS report
9. FA.IA.9
System shall be able to generate an MIS report highlighting any new product
/ service/facility to customers/employees introduced in the specific Post
Office(s) chosen for audit between the last audit date and current audit date
E
8.4.5 Human Resources
8.4.5.1 Human Resources Management System
#

C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

HRMS Administration & Set-up
1. HR A.1
HR master data is a part of the core HR Data that includes all the master data,
configuration and rules that enable Personnel and HRD transactions in the
application.
E
2. HR A.2
Circle master manages Circle related information such as name, description
etc.
E
3. HR A.3
Region master manages region related information such as name, description
etc.
E
4. HR A.4
Division master manages Division related information such as name,
description etc.
E
5. HR A.5
Sub-Division master manages Sub-Division related information such as name,
description etc.
E
6. HR A.6
Location (City) master manage all the location details of offices (operative and
administrative) such as location name, address, phone number etc, office
demographics, planning information (sanctioned and working strength) against
each post.
E
7. HR A.7
Office master manages Office related information such as name, description,
unique office number etc.
E
8. HR A.8
Holiday master helps in managing Holiday details such as Holiday date, holiday
description, holiday reason etc. Holiday lists can thus be maintained for
different circles and regions if the holidays differ
E
9. HR A.9
Competent Authority (workflow rules) master helps in assigning the
appointing authority, leave sanctioning authority and immediate supervisor so
as to manage the HR processes workflow
E
10.
HR
A.10
Document template manages different document templates that are used in
E
different HR Modules across the software.
11.
HR
A.11
Access control master manages the authorization for various processes based
on the cadre, location, process etc.
E
12.
HR
A.12
Organization Management Master manages the organization hierarchy-
immediate supervisor and reportees for every employee. This will help drive
workflow for employee and manager self service
E
13.
HR
A.13
Training Configuration Master manages the list of all the training centres with
the details of number of classrooms, computers, hostel capacity etc
E
14.
HR
A.14
Establishment Review Master maintains a database of all establishments with
the details such as Unique Post Office No, Type and Classification, Functional
status (Permanent/ Temporary), Planning info (sanctioned staff, working staff,
order number), Locality Status, Year of last establishment review, applicable
rules for kind of work hour reports, Periodicity of Establishment Review,
Master for time norms (for departmental) and point system (for GDS Offices)
E
Personnel Information System
15. HR B.1
Online Service Book is the record of service details throughout the employee
lifecycle in the organization
E
16.
HR
B.1.1
System shall maintain online service book for all departmental employees E
17.
HR
B.1.2
Online Service Book shall have different sections same as the existing service
book
E
18.
HR
B.1.3
Part A of the service book maintains the personal data about the employees
that is entered at the time of joining. System shall maintain the following
personal data:
Employee Identification Number
Employee Name
Fathers Name
Spouse
Permanent Address
Address for Communication
Permanent Home Town
Nationality
Sex
Marital Status
Educational Qualifications (at the time of entry)
Educational Qualifications (subsequently acquired)
Professional and Technical Qualification
Exact Height
Personal Mark of Identification
Caste
E
Date of birth
Employee photo, Signature and Left Thumb Impression
Family Information
Details of the dependents including relationship, their month & year of birth,
studying in school/college, monthly income/pension amount
19.
HR
B.1.4
System shall allow an employee to view the scanned Employee Joining Forms
such as Family Pension Scheme Form, Form I for Nomination for Death-cum-
Retirement Gratuity, Nomination for Benefits under CGEIS Form -8,
Declaration of Details of Family through the service book
E
20.
HR
B.1.5
Part-II of the service book -Certificate and Attestation, shall maintain scanned
copy of the seven certificates for the verification carried out at the time of
joining. System shall allow uploading the scanned documents such as Medical
Examination, Character and Antecedent, Allegiance to Constitution, Oath of
Secrecy , Marital Status, Declaration of Home Town, Verification of entries in
part 1.
E
21.
HR
B.1.6
Part III A of Service Book shall maintain the previous qualifying service and
foreign service. In case the employee has another service book for previous
employment, data shall be entered from that service book
E
22.
HR
B.1.7
Part III B of a Service Book shall maintain the Foreign Service Details -From To,
Post held and name of foreign employer, Leave and Pension Contribution
payable by, Amount of Leave and pension actually contributed actually
Recovered
E
23.
HR
B.1.8
Part IV of the Service Book maintains the History and Verification of Service.
Any entry in the service book is triggered by a change in the Post, Office,
Station, Scale of Pay and Nature of Appointment triggered by events such as
appointment, promotion, reversion, deputation, transfer (including foreign
service), increment, leave and suspension
E
24.
HR
B.1.9
System shall maintain the following details for History and Verification of
Service -Period (From-To), Post, Scale and Office (with station), Pay
(Substantive and Officiating), Triggering Event, Digital Signature of attesting
officer and verifying authority with date, Remarks
E
25.
HR
B.1.10
Remarks column is used to note any information which may not directly
impact the entry in the service book but is worth mentioning to explain the
service record
E
26.
HR
B.1.11
System shall throw an error message if there is any explained gap in the
service record
E
27.
HR
B.1.12
Part V of the service book maintains the Leave Account of the Employee for
the following types of leave
Earned Leave
Half Pay Leave
Commuted Leave
E
Leave not Due
28.
HR
B.1.13
System shall maintain the following details in the leave account- Particulars of
Service completed and leave, completed months of service, leave credited in
the beginning of half year, no of days of leave availed in the past, leave to be
deducted, Total leave at credit in days, Leave taken (from-to), number of days
E
29.
HR
B.1.14
System shall credit/debit the leave based on the eligibility in terms of years of
service. This will interlink with the Leave Management Module of HRMS
E
30.
HR
B.1.15
Any update in the online service book shall be approved by an authorized
official/attesting officer
E
31.
HR
B.1.16
System shall allow the authorized user to administer changes to the
documents or personal details only if the employee requesting a change has
produced the relevant supporting documents
E
32.
HR
B.1.17
System shall display a user friendly view to the employee with details under
relevant tabs and links
E
33.
HR
B.1.18
System shall allow the authorized authority to take a print-out of the service
book in a specified period (say six months) that can be shared with the
employee when He/she raises a request
E
HR B.2 Employee Joining Process and Creation of Employee Record
34.
HR
B.2.1
Once a vacancy is closed on the recruitment module (when selection offer is
made to the candidate), system shall create a dummy employee record which
shall derive data from the recruitment module saving time for data re-entry
E
35.
HR
B.2.2
System creates the employee record and assigns a unique identification
number to the employee.
E
36.
HR
B.2.3
Unique ID and password is communicated to the respective employee at the
time of joining
E
37.
HR
B.2.4
When an employee joins, He/she sends the online charge report to his/her
supervisor, payroll and HR Administration Team
E
38.
HR
B.2.5
Employee Record is activated after the charge report is received. Joining
documents such as joining form, attestation, verification form and certificate
for qualifying examination shall be uploaded on the Document management
system
E
HR B.3 Allotment of Unique Employee ID
39.
HR
B.3.1
Every employee in India Post shall be assigned a seven digit unique employee
number
D
40.
HR
B.3.2
The series of numbers to be used for assigning employee ID should clearly
distinguish the departmental employees from the extra-departmental (GDS)
employees
D
41.
HR
B.3.3
For existing employees, the unique employee ID has to be assigned based on
the year of joining
D
42.
HR
B.3.4
For new employees, the number has to be assigned based on the year of
joining after the selection offers are send to the employees
D
43.
HR
B.3.5
Employee ID can have the year of joining appended at the end so that the year
of joining and seniority can be easily established from the employee number
D
44.
HR
B.3.6
Employee ID has to be retained for 30 years after the employee exits the
organization. If an employee, is suspended or is on deputation, the employee
ID has to be retained for a period as defined by Government of India
E
45.
HR
B.3.7
The provisioning of unique number to employees shall be controlled in a
centralized manner to ensure uniqueness and business logic
E
46.
HR
B.3.8
All the service and personnel records shall be associated with the unique
identification number
E
47.
HR
B.3.9
Unique Employee ID shall be maintained in an Active Directory that can be
used for access control for IPVS, POS, Core Banking Solution, Core PLI Solution,
and Document Management System.
E
HR B.4 Changes in PIS as a result of Probation and Confirmations
48.
HR
B.4.1
System shall maintain the confirmation rules and shall generate list of
employees (meeting confirmation criteria). System trigger process for
confirmation based on defined rules
E
49.
HR
B.4.2
System shall allow tracking of probation period for each new employee and
provide system alerts on probation completion due dates
E
50.
HR
B.4.3
System shall allow an authorized official to make changes to the reporting
authority, location and employment status of the employee
E
51.
HR
B.4.4
System shall retrieve data on training undertaken by the employee and other
details (successful completion certified/tested) as needed for confirmation
E
52.
HR
B.4.5
System shall track passing of required exams (departmental/professional) for
confirmation
E
53.
HR
B.4.6
System shall record & generate alert on successful completion of confirmatory
Training
E
54.
HR
B.4.7
System shall generate list of employees confirmed on the basis of vacant
permanent posts available and should also declare remaining fit candidates to
be confirmed
E
55.
HR
B.4.8
System shall allow authorized user to increase the duration of probation if
employee not confirmed due to given reason (non completion of training or
passing of exam) and allow related authority to define its impact on seniority.
E
56.
HR System shall maintain standard formats of order given by India Post available
E
B.4.9 in the system for issuance of Confirmatory/Extension orders
57.
HR
B.4.10
System shall record/ update confirmation date and location of employee in
data base
E
58.
HR
B.4.11
Once an employee is confirmed his present post, system shall allow making
changes to the salary structure, seniority list, leave configuration, organization
management, workflow management etc.
E
HR B.5 Changes in PIS as a result of Promotion Process
59.
HR
B.5.1
System receives the list of candidates who have been selected for promotion
for a cadre based on seniority or departmental examination
E
60.
HR
B.5.2
System also receives the details such as new location, designation, date of
relieving and date of joining the new location, new and old immediate
supervisor
E
61.
HR
B.5.3
System shall generate standardized promotion/posting letter using the
template, for all employees who have been promoted. Employee receives an
alert to confirm and send charge report on joining the new post/location
E
62.
HR
B.5.4
System shall allow employee to send online charge report to immediate
supervisor of both relieved and relieving official for approval and payroll
department
E
63.
HR
B.5.5
Authorized Officials shall be allowed to update the PIS with the new details.
Other configurations such as leave configuration, organization management,
workflow management configuration, salary etc shall also be changed based
on approval
E
64.
HR
B.5.6
System also tracks the status of charge reports and generate alerts accordingly E
HR B.6 Changes in PIS as a result of Transfer process
65.
HR
B.6.1
System shall allow the appointing authority to draw the list of candidates who
are eligible for tenure transfer after 4 years of service (in a post office or post)
under Rule 37
E
66.
HR
B.6.2
System shall send a alert to the respective employee to send three locations of
preference for transfer or apply for extension with reasons to the appointing
authority
E
67.
HR
B.6.3
System shall do the initial matching of the candidates preferences with the
available options of transfer locations. Transfer decision shall be guided by the
Recruitment Rules and roster points retaining the sanctioned strength as per
defined rules.
E
68.
HR
B.6.4
System shall generate standardized transfer orders after approval from
competent authority
E
69. HR
Candidates join the new location and send charge report to the appointing
E
B.6.5 authority, payroll and personnel department
70.
HR
B.6.6
System can track the completion of charge report after joining the new
location and generate alerts for the candidate
E
71.
HR
B.6.7
System shall allow for exceptions such as special transfer under Rule 38 or
Request for extension in the same office
E
72.
HR
B.6.8
In case of transfer under rule 38, an employee can apply for special transfer
after 5 years for direct recruitment and 3 years after promotion
E
HR B.7 Employee Separation Process/Exit Management
73.
HR
B.7.1
Personnel division starts the exit management process 6 months before the
date of retirement. System shall give the list of employees who are due for
superannuation and voluntary retirement
E
74.
HR
B.7.2
Personnel division shall generate alert for authorized official in accounts
(payroll) department to send the leave encashment certificate consisting of
balance earned leaves for the employee
E
75.
HR
B.7.3
Personnel division shall generate an approval request for the authorized
official in accounts department to calculate and generate certificates such as
Group Insurance Letter, Gratuity, GPF, and Loans & Advances.
E
76.
HR
B.7.4
Personnel division shall generate an approval request for the authorized
official in Administration department to generate for laptops, access card, and
No-Dues from Library.
E
77.
HR
B.7.5
Accounts shall process the retirement benefits and issue a provisional PPO
only after receiving the no dues certificates (online/hard copy) from various
departments
E
78.
HR
B.7.6
System shall track the completion of permanent PPO for the retiring employee E
79.
HR
B.7.7
On retirement, system shall convert the employee record to inactive record E
80.
HR
B.7.8
System shall retain the employee number and employee record for a period as
defined by Government of India
E
HR B.8 Organization Management
81.
HR
B.8.1
The system shall provide for effortless maintenance of the Organization
structure using tree structure and make changes in the structure with respect
to Employee Post, Jobs and the same shall get reflected in the Employee data.
This shall be applicable to making changes in Reporting relationships
E
82. HR B.9
System shall maintain employee and organizational data important for the
workflow management
Employment Status (Confirmed, Probationary, temporary, contract etc)
Recruitment rule applicable (Departmental Exam, Promotion, Direct
E
Recruitment)
Designation
Cadre
Date of joining the Organization
Date of joining the cadre
Immediate Supervisor
Appointing Authority
Reportees
Job History and Promotion Details (Transfer and Promotions)
Emergency Contact Information
History of trainings attended like name of the course, name of the
PTC/Institution, month & year of training, duration of the course in
days/weeks
Awards received by the employee including the name of the award, year of
award, in which discipline/filed and date of receipt of award
History of disciplinary actions against the employee including date of charge,
nature of charge, amount of financial loss to India Post, date of punishment
and nature of punishment
Work done outside India Post on deputation, details
Employee medical details
Blood group
83.
HR
B.10
System shall maintain the salary change details such as Pay details, PF Number,
PAN Number, Bank account information, date of pay change, annual
increment, details of any advances, GPF processed by the payroll department
etc.
E
84.
HR
B.11
System shall maintain the information about the vigilance cases and the status
of a case
E
85.
HR
B.11.1
Any changes in the PIS that makes any changes to the above fields (except
confidential information such as Vigilance clearance and Disciplinary Actions)
E
86.
HR
B.11.2
System shall maintain the vigilance information about the employees. System
shall allow authorized officials to track and change status of vigilance
information of an employee maintaining confidentiality. Following information
can be recorded in the Personnel Information System:
Recordable warning issued
Period of suspension
Treatment of suspension period e.g. as duty, restricted to whatever given etc
Charge Sheet issued under Rule 16 of CCS (CCA) rules 1965 (Minor
Punishments)
Charge Sheet issued under Rule 14 of CCS(CCA) rules 1965 (Major
Punishments)
Minor penalty imposed
Major penalty imposed
E
Period of Penalty
Worked as Inquire Officer/presenting Officer/Defence Assistant in
finalization of any disciplinary proceedings
Prosecution (any criminal prosecution in the court of law)
Period of time when worked as in charge of single/double handed post office
(in vase of postal assistant)
Whether indemnity bond/bank guaranty obtained before posting as
treasurer (in case of postal assistants)
Whether police verification done and PVR is available on record at the time
of entry into the service)
87.
HR
B.11.3
System shall maintain access control for viewing parts of service details. For
example, an employee will not be able to view Vigilance related information.
E
88.
HR
B.12
System shall also allow authorized officials to maintain a log/calendar to track
the court cases regarding matters related to personnel
E
89.
HR
B.13
System shall support uploading/recording relevant details such as
appreciation, award, and certification of an employee.
E

HR
B.14
Acknowledging the Seniority/Gradation List
90.
HR
B.14.1
System shall maintain cadre wise gradation list and seniority list for
departmental and GDS employees respectively for a pre-defined period based
on the seniority (date of joining the present cadre) as defined in Government
of India rules
E
91.
HR
B.14.2
The cadre-wise gradation list shall be viewed and acknowledged by the
respective departmental employee and GDS employees on Employee Portal
and on paper respectively
E
92.
HR
B.14.3
System shall display the cadre wise gradation list relevant to the departmental
employees on his/her Employee Portal for his/her acknowledgement
E
93.
HR
B.14.4
System shall track the completion status of online acknowledgement by
employees on portal
E
94.
HR
B.14.5
System shall send the seniority list for a GDS cadre to an authorized IPO/ASP to
get signatures on the paper based seniority list
E
95.
HR
B.14.6
System shall allow for an employee to send a representation if his/her position
on the gradation list is incorrect
E
96.
HR
B.14.7
System shall draw the seniority/gradation list every year for a specified period
and shall maintain the previous year list as defined by Government of India.
E
8.4.5.2 Leave Management
Leave Management Module is used to configure and maintain information on absence from work, in
accordance with the policies of the organization. This module enables employees to avail leave. It
standardizes the processing of different types of leaves and reduces the amount of data entry and
verification activities at various levels.
#

C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

L 1.2.1
Leave Configuration- Manage Leave Types facilitates the configuration of
Leave types in an organization. There can be more than one Leave type for
the selected configuration period.

1.
L
1.2.1.1
The system shall have the provision to maintain all types of leave like Casual
Leave, Paternity Leave, Maternity Leave, Medical Leave, Commuted Leave,
Extra-ordinary leave, Sabbatical leave, Half pay Leave and Leave not Due
E
2.
L
1.2.1.2
The system shall have the ability to maintain leave eligibilities for each type of
leave depending on the rules specified by India Post
E
3.
L
1.2.1.3
The system shall maintain rules for availing leave, en-cashing leaving, accrual
of leaves, lapsing of leaves, ceilings for accumulation of leaves and rules for
combination of leave types
E
4.
L
1.2.1.4
System shall maintain rules for leave encashment, leave clubbing and leave
truncation rules
E
5.
L
1.2.1.5
The system shall support transfer of people from one leave structure to
another leave structure
E
6.
L
1.2.1.6
The system shall support comprehensive leave approval rules
Barred combination of leave
Leave only for working days
Leave for calendar days
Leave pre-fixing and suffixing with other leaves
Leave pre-fixing and suffixing with weekly-off and paid holidays
Minimum and maximum no of days at a stretch
Maximum no of incidents for any leave
Leave Encashment
Leave Clubbing
Leave truncation (carry forward to next year) rules
Negative Leave Balance Rule
E
7.
L
1.2.1.7
System shall define hierarchical workflows for recommendation and approval
of leaves
E
8.
L
1.2.1.8
System shall support a Business Calendar and Leave Application dates should
be validated against this calendar
E
9.
L
1.2.1.9
System shall support on-line Leave application processing by providing
required workflow
E
10.
L
1.2.1.1
0
System shall allow users to view leaves eligibility and leaves availed E
11.
L
1.2.1.1
1
System shall be able to record the recommendation/ approval/ rejection of
applied leaves and update the employee leave account accordingly
E
12. L 1.2.2
Leave Balance Adjustment helps in adjustment of Leave balance by adding or
deducting the number of Leaves for individual employees or a selection of
employees.

13.
L
1.2.2.1
System shall allow an authorized official to make leave adjustment
(credit/debit) for one or group of employees
E
14.
L
1.2.2.2
Leave Credit configuration facilitates crediting days of leave for an individual or
selection of employees between Confirmed, Contract, Probation and trainees.
E
15.
L
1.2.2.3
The system shall have the provision for accounting for leave including
automatic credit of leave and manual credit / debit / modification /
cancellation/adjustment etc
E
16.
L
1.2.2.4
System shall allow for leave accruals on a monthly / quarterly / half-yearly /
yearly and at the beginning of a month or end of the month.
E
17.
L
1.2.2.5
System shall inform an employee of leaves already deducted or to be deducted
from his/her account in future
D
L 1.2.3 Leave Request is used by an employee to request for leave.
18.
L
1.2.3.1
An employee shall apply for leave through Employee Portal. E
19.
L
1.2.3.2
In case Employee Portal is not available/accessible (for Group D and GDS), an
alternate source shall be arranged to bring the approved leave form nearest to
the system. Authorized Officials shall account for approved leave on the
system
E
20.
L
1.2.3.3
An employee can view details of leave types based on eligibility for him/her,
along with current leave balance
E
21.
L
1.2.3.4
On submission, system shall forward the form for approval based on the
workflow configuration.
E
22.
L
1.2.3.5
System shall support rules that can be set for multiple levels of approval and
for eligibility based approval.
E
23.
L
1.2.3.6
Leave Calendar can be viewed by the employee for preceding and succeeding
year to view the leaves availed and planned training programs
D
24.
L
1.2.3.7
System shall display an error message if there is a date conflict. An employee
can not apply for leave for the date for which the a leave application is already
E
pending or approved
25.
L
1.2.3.8
For medical leave, system shall allow uploading the scanned medical certificate
and fitness certificate from a doctor
E
26.
L
1.2.3.8
System shall generate a warning for any document expiry during the planned
leave period
E
L 1.2.4
Leave Request Approval supports the leave sanctioning authority to approve
the Leave requests raised by employees and that directed to him or her for
approval.

27.
L
1.2.4.1
For casual or restricted holiday leave, leave sanctioning authority is the
immediate supervisor. In all other cases, leave sanctioning authority is the next
higher authority.
E
28.
L
1.2.4.2
The Leave Sanctioning Authority can view the leave request routed to him/her
on his/her Managers Portal and can accept/reject the leave request
E
29.
L
1.2.4.3
System shall allow the Leave Sanctioning Authority to approve the leave
request with his/her comments along with a handover arrangement under
office arrangement or substitute arrangement, if the applicant works in a post
office
E
30.
L
1.2.4.4
System shall maintain the list of leave reserves for making substitute
arrangement in place of a candidate going on leave
E
31.
L
1.2.4.5
System shall generate an alert for the substitute who has been arranged for
that period and his/her immediate supervisor in the post office so as to relieve
him/her
E
32.
L
1.2.4.6
System shall allow the Leave sanctioning authority to view the leave balance of
the applicant
E
33.
L
1.2.4.7
In exceptional cases, the system shall allow the leave sanctioning authority to
give special grant when leave not due or negative leave balance
E
34.
L
1.2.4.8
System shall be able to generate alert for giving reasons if leave application is
rejected
E
35.
L
1.2.4.9
System shall be allow selection of general reasons of rejection from a
dropdown menu and provide a text box for inserting other specific reasons
E
36.
L
1.2.4.1
0
System shall generate an alert on leave approval that can be viewed by the
applicant on his/her Employee Portal
E
37.
L
1.2.4.1
1
System credits the leave account of the employee when He/she sends the
charge report to relinquish the charge from the date of leave. A copy of the
online charge report is received by immediate supervisor, authorized official in
payroll department and personnel division
E
38.
L The substitute assumes charge and sends the online charge report to his/her
E
1.2.4.1
2
immediate supervisor, authorized official in payroll and personnel division.
Employee going on leave shall also send a charge report to relinquish charge.
39.
L
1.2.4.1
3
System can track the completion of online charge report and generate alert for
the employee accordingly.
E
40.
L
1.2.4.1
4
On approval of the leave, system shall calculate payment entitlement and raise
the necessary payment/recovery requisition if needed
E
41.
L
1.2.4.1
5
System shall support conversion of one type of availed/sanctioned leave into
another based on the defined rule
E
42.
L
1.2.4.1
6
If an employee joins earlier/later then approved date then system shall be able
to apply user defined rules for early, late returns and initiate
adjustments/deductions electronically in the Payroll Module after revised
sanction
E
43.
L
1.2.4.1
7
System shall have provision that a salary is stopped if a person is absent for
more than 1 month without proper sanction or as per rules and policies
E
44.
L
1.2.4.1
8
System shall support regularization of unsanctioned absence period by grant
of different types of leave such as Leave with Pay and Leave Not Due
E
45. L 1.2.5 Leave Cancellation allows an employee to cancel an approved leave request
46.
L
1.2.5.1
Employee can log on to Employee Portal and cancel a approved leave request
with the reason
E
47.
L
1.2.5.2
System allows cancellation of only approved leave E
48.
L
1.2.5.3
On submission, the request is forwarded to the leave approver E
49. L 1.2.6
Leave Cancellation Approval allows the leave sanctioning authority to cancel
a leave request

50.
L
1.2.6.1
System shall display all cancellation requests on Leave Sanctioning Authoritys
Managers Portal.
E
51.
L
1.2.6.2
System also allows for part cancellation of leave period. E
52.
L
1.2.6.3
Leave Sanctioning Authority can view the Leave Cancellation request with
reason. He/she can also view the earlier approved leave request and
comments.
E
53.
L
1.2.6.4
Applicant gets an intimation on his/her Employee Portal on approval or
rejection
E
54. L 1.2.7
Leave Regularization allows an employee to regularize leave for past days
without raising a prior leave request.

55.
L
1.2.7.1
System shall allow the employee to apply for leave regularization request on
Employee Portal. Employee inputs the leave type and number of days for
regularization
E
56.
L
1.2.7.2
System shall display only the past dates for leave regularization request E
57.
L
1.2.7.3
System shall display and error message if there is a date conflict. System does
not allow applying for leave in the period for which leave has already been
applied/approved
E
58.
L
1.2.7.4
On submission, the request is forwarded to the leave approver. E
59.
L
1.2.7.5
System shall allow a leave regularization for extended leave period provided it
meets all the leave rules and is approved by the leave approving authority
E
60. L 1.2.8
Leave Regularization approval allows the leave sanctioning authority to
approve a leave regularization request

61.
L
1.2.8.1
System shall display all leave regularization request on approvers Portal. E
62.
L
1.2.8.2
System allows the leave approver to accept/reject the leave regularization
request with comments
E
63. L 1.2.9
Leave Encashment allows the employees to en-cash Earned Leaves, at the
time of retirement

64.
L
1.2.9.1
System shall maintain the Earned leave balance based on the eligibility rules
(such as credit based on completed years of service) for every employee
E
65.
L
1.2.9.2
Employee can apply for the leave encashment on Employee Portal when the
eligibility for the leave encashment is met
E
66.
L
1.2.9.3
System shall have the ability to send reminder to an employee when 300
earned leaves are accumulated in his/her account
E
67.
L
1.2.9.4
The application for leave encashment will be routed to the authorized official
in payroll department for checking eligibility and further processing.
E
68.
L
1.2.9.5
System shall be linked to payroll and employee leave account in online service
book
E
8.4.5.3 Recruitment Management
Recruitment Management Module shall help India Post to manage the recruitment function faster
and more effectively. The module helps in managing post, managing vacancies and calculation of
vacancies, recruitment process and post selection activities. The module shall also allow for
integration with recruitment agency to handle the departmental and direct examination and share
relevant information at different point in time.
#

C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

R 1.3.1 Recruitment Management Module Set-Up
1.
R
1.3.1.1
Post Master maintains the details of all the post, designation, functional unit,
cadre, grade, probation and confirmation rule etc.
E
2.
R
1.3.1.2
Vacancy Master maintains the post, number of vacancy against each post,
designation, grade, recruitment rule, category (General / SC / ST / OBC / Sports
/ PH), region (directorate, circle, region, division or sub-division) job
description and status (Vacant/Occupied)
E
3.
R
1.3.1.3
Recruitment Rules master manages the sanctioned staff under each cadre and
the recruitment rule applicable to the cadre
E
4.
R
1.3.1.4
System shall maintain an annual recruitment calendar for departmental
examination, direct examination and seniority based promotion and track the
completion status of each recruitment
E
R 1.3.2 Post Management
5.
R
1.3.2.1
System shall support to maintain a database of function or job profiles in the
organization with details such as profile name, business unit or function, cadre,
description, responsibilities and effective date (on which the profile was
created) along with the order number.
E
6.
R
1.3.2.2
System shall support associating a post to the job profile. Every post shall have
a unique identification number.
E
7.
R
1.3.2.3
System shall support adding post details such as post number, designation,
function profile, effective date, reason for creating the post, cadre, grade, pay
scale, maximum sanctioned number/head count, age, educational
qualification, reporting authority, number of reportees, experience/seniority
required.
E
8.
R
1.3.2.4
System shall allow taking approval from competent appointing authority
(through Managers Portal ) for any new post created
E
9.
R
1.3.2.5
System shall allow making changes to the number of posts and other
requirements of the post.
E
R 1.3.3 Vacancy Management
10.
R
1.3.3.1
System shall support maintaining a master list of approved vacancies for each
post and other details about the vacancies
E
11.
R
1.3.3.2
System shall allow creation of vacancy under each post with recruitment rules
(direct examination, seniority based promotion, departmental examination),
eligibility details in terms of category and geography (circle, region, division).
E
12.
R
1.3.3.3
System shall comply with the recruitment rules and eligibility defined in the
recruitment master while creating the vacancies
E
13.
R
1.3.3.4
System shall allow taking approval from competent appointing authority
through Managers Portal for vacancies created under each post for each
location.
E
14.
R
1.3.3.5
System shall maintain the status of the vacancy
Vacant-in case no eligible candidate found for a published vacancy or
vacancy number not approved by the approver
Published- If vacancy communicated to the Recruitment Agency
Candidate Selected-if selected candidate approved
Closed-if the selected candidate has joined or rejected offer
E
15.
R
1.3.3.6
System shall allow making changes to the number of vacancies and other
requirements of the vacancy such as category, educational qualifications etc
according to the changes in Government of India rules.
E
R 1.3.4 Calculation of Vacancies
16.
R
1.3.4.1
System shall allow the calculation of vacancies (sanctioned staff minus actual
staff) for each cadre and for different modes of recruitment (such as
promotion, departmental examination and direct recruitment ) and category
E
17.
R
1.3.4.2
System shall generate vacancy list sorted by cadre, ex - cadre & dying post and
appropriate recruitment mode
E
18.
R
1.3.4.3
System shall draw information regarding vacancy that is due for creation
because of superannuation in a specified period
E
19.
R
1.3.4.4
System shall allow online communication via e -mail or browser between
administrative department and other recruitment agencies
E
20.
R
1.3.4.5
Vacancies that needs to be filled by seniority based promotion is
communicated to the respective appointing authority
E
21.
R
1.3.4.6
System shall allow mapping of eligibility requirements against posts / grades /
locations, and at the same time maintenance of a vacancy database
E
22.
R System shall be able to provide for formats for placing advertisements for
E
1.3.4.7 recruitment on external and internal portals for departmental and direct
recruitment
23.
R
1.3.4.8
System shall be capable of short -listing from list of electronic applications
received, on the basis of essential criteria and highlight extent of fulfilment of
desirable criteria for the short-listed candidates
E
24.
R
1.3.4.9
System shall provide facility for uploading of documents of new recruits E
25.
R
1.3.4.1
0
System shall allow creation of employee records and service book for new
recruits
E
R 1.3.5 Seniority Based Promotions
26.
R
1.3.5.1
System shall be able to define cadre specific and general promotion rules E
27.
R
1.3.5.2
System shall store all the rules pertaining to promotion for every cadre E
28.
R
1.3.5.3
System shall allow employees to view the rules for promotion E
29.
R
1.3.5.4
System shall be able to identify vacant posts for promotion E
30.
R
1.3.5.5
System shall be able to generate timely triggers indicating the due date for
promotion process to start based on model calendar
E
31.
R
1.3.5.6
System shall check mandatory conditions such as completion of required
service period and/or completion of required service period at the lower post
from which to be promoted, before promotions
E
32.
R
1.3.5.7
System shall be able to generate list of employees in zone of consideration as
per specific cadre/related general promotion rules
E
33.
R
1.3.5.8
System shall be able to generate final gradation list to be submitted to DPC E
34.
R
1.3.5.9
System shall record details of promotion declined in the past by employees in
zone of consideration
E
35.
R
1.3.5.1
0
Appointing Authority shall view and download online APAR for last five years
from the online PMS
E
36.
R
1.3.5.1
1
For internal DPC, the appointing authority shall have access to vigilance related
information from the PIS
E
37.
R For external DPC, appointing authority shall request for a vigilance clearance
E
1.3.5.1
2
certificate from respective vigilance department
38.
R
1.3.5.1
3
System shall be able to generate online fit list of employees as decided by DPC E
39.
R
1.3.5.1
4
System shall be able to block (keep promotions under sealed cover) employees
from promotion against whom DE/other events are pending till a final decision
in the matter is taken and recorded in the system
E
40.
R
1.3.5.1
5
System shall update employee's grade & pay scale details resulting due to
promotion decisions
E
41.
R
1.3.5.1
6
System shall have the facility to send a communication to the employee in case
he/she is promoted
E
42.
R
1.3.5.1
7
System shall have standard formats of promotion orders available in the
system
E
43.
R
1.3.5.1
8
System shall maintain the status of accepted and rejected offer letters by the
candidates
E
44.
R
1.3.5.1
9
System shall draw the list of GDS staff who are eligible for seniority based
promotion or departmental examination based on the pre-defined rule
E
45.
R
1.3.5.2
0
On selection of a GDS staff as departmental employee (Group D, Postman or
Postal Assistant), his/her record shall be updated in the PIS
E
R 1.3.6. Departmental or Direct Recruitment through a Recruitment Agency
46.
R
1.3.6.1
Recruitment Management Module shall also allow for integration with the
recruitment agency through a interface such as a portal
E
47.
R
1.3.6.2
System shall allow the Personnel division to post the number of vacancies
under each cadre with details about the location, eligibility and category, that
need to be filled through a direct and departmental examination on the
recruitment portal for recruitment agency
E
48.
R
1.3.6.3
Recruitment Agency shall be responsible for the following recruitment
activities as defined in the scope of work of outsourcing proposal:
Issue of Notification
Design the Application Kit
Receiving filled Application Form from candidates
Location wise list of applications received
E
Application Screening and List of Eligible and Ineligible candidates for
Examination
Setting Question Paper and Answer Key
Exam Preparation Exercise
Sending Admit Cards to the Eligible Candidates
Conducting Examination
Evaluation of Answer Sheets
Preparation of Merit List of selected candidates
Helpdesk for handling the queries of the candidates regarding eligibility,
admit card
Maintaining the recruitment portal content
49.
R
1.3.6.4
System shall allow India Post to receive data from recruitment agency at
different point in time such as eligible candidates for examination, merit list of
selected candidates based on the location (circle, region, or division etc) or
category
E
R 1.3.7 Post Selection Activities
50.
R
1.3.7.1
System receives the merit list and forwards the same to the appointing
authority for approval
E
51.
R
1.3.7.2
On approval, system allows for generating standardized selection letter for
selected candidates. For new joinees, the training details are also given which
needs integration with the training administration module
E
52.
R
1.3.7.3
On approval, system creates Unique Employee ID and dummy employee
record on the PIS that shall draw details from the application form that was
earlier filled by the employee
E
53.
R
1.3.7.4
India Post initiates the process of verification of certificates and medical
examination.
D
54.
R
1.3.7.5
The system shall keep provision to record the acknowledgement of offer
letters, medical reports, verified and authenticated testimonials, caste
certificate and other relevant certificates as per the user defined check list
E
55.
R
1.3.7.6
System shall maintain the status of accepted and rejected offers by the
candidates
E
56.
R
1.3.7.7
System shall also notify the list of new joinees and promotees to the respective
training institutes
E
57.
R
1.3.7.8
The system shall support selection of candidates on compassionate grounds E
R 1.3.8 Time Bound Pay Scale Enhancement
58.
R
1.3.8.1
System shall be able to define cadre specific and/or general rules in the system
for Time Bound Pay Scale Enhancement
E
59.
R
1.3.8.2
System shall be able to generate timely triggers indicating the due date for
Time Bound Pay Scale Enhancement in all cases
E
60.
R
1.3.8.3
System shall check mandatory conditions , such as completion of required
service period (completion of required service period) at the post on which
Time Bound Pay Scale Enhancement to be given
E
61.
R
1.3.8.4
System shall access the gradation list for getting the list of candidates E
62.
R
1.3.8.5
System shall update employee's grade & pay scale / pay band / grade pay
details resulting due to the decisions
E
63.
R
1.3.8.6
System shall access APAR report of employee for the required period E
64.
R
1.3.8.7
System shall have access to vigilance clearance information of an employee E
65.
R
1.3.8.8
System shall be able to generate final gradation list to be submitted to DPC E
66.
R
1.3.8.9
System shall be able to generate lists of employees in zone of consideration as
per cadre/general Time Bound Pay Scale Enhancement rules
E
67.
R
1.3.8.1
0
System shall be able to defer grant of Time Bound Pay Scale Enhancement to
employees from against whom a final decision in matters related to vigilance
or other inquiry, has been taken and recorded in the system
E
68.
R
1.3.8.1
1
Policy for Salary revision, Increments consequent upon Time Bound Pay Scale
Enhancement should be maintained in the system on -line and trigger them for
pay fixation process in related module
E
69.
R
1.3.8.1
2
Authorized authority should have the provision to update employee data base,
service book and gradation list in the system
E

8.4.5.4 Performance Management
#

C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

PM
1.4.1
Performance Management Module Set-Up
1. P M 1.4.1.1 System shall support performance management tools, tracking & reporting E
2.
PM
1.4.1.2
System shall be capable to create Performance Management Document for
employees depending on the cadre / grade in the organisation
E
3.
PM
1.4.1.3
System shall have the ability to define performance scale for each parameter
for each cadre / grade so as to ensure that the same measures of performance
are communicated to the appraiser as well as the appraisee.
E
4.
PM
1.4.1.4
System shall define and maintain the workflow based authorizations for the
reporting manager, reviewing authority and accepting authority
E
5.
PM
1.4.1.5
System shall have inbuilt forms for Appraise & Appraiser to fill up E
6.
PM
1.4.1.6
System shall be able to log various stages of employee appraisal and
evaluation process to generate Performance Evaluation forms on -line and
forward them through workflow
E
7.
PM
1.4.1.7
System shall generate alerts to point out if self assessment/review is over due E

PM
1.4.2
Objective Setting
8.
PM
1.4.2.1
Employee shall log-in to the Online Performance Management Module (PMS)
through Employee Portal
E
9.
PM
1.4.2.2
System shall allow the documentation of objectives under various
accountabilities as discussed with immediate supervisor (for Group A and B)
E
10.
PM
1.4.2.3
System shall allow for a reporting authority to set generic objectives for all
operative staff under his/her facilitation (Group C)
E
11.
PM
1.4.2.4
PMS shall allow for the Supervisor to log-in and view /edit objectives for
his/her reportees
E
12.
PM
1.4.2.5
System shall track the status of completion and send reminders/alerts
accordingly
E
13.
PM
1.4.2.6
System shall allow for editing the objectives whenever there is a change in the
organization management as a result of a transfer or promotion
E
14.
PM
1.4.2.7
System shall allow an employee to set two different set of objectives in a
performance year, only in case of a transfer or promotion
E

PM
1.4.3
Self Input and Annual Appraisal (Writing APAR)
15.
PM
1.4.3.1
PMS allows for an employee to log-in and submit the self-input (resume) for
that year
E
16.
PM
1.4.3.2
PMS shall allow for the Supervisor to view the self-input and fill the APAR
form.
E
17.
PM
1.4.3.3
Supervisor can access the PIS to check if any vigilance case is pending against
the employee
E
18.
PM
1.4.3.4
Supervisor can also check the number of trainings completed by the employee
in the year
E
19.
PM
1.4.3.5
For Group A and B, the reporting authority shall fill the APAR and forward the
same to the reviewing authority and then to accepting authority based on
workflow
E
20.
PM
1.4.3.6
Reviewing and Accepting Authority can edit an APAR E
21.
PM
1.4.3.7
System shall support the ability of forwarding the APAR to an external
authority such as Ministry of Communication, who is accepting authority for
posts HAG and above.
D
22.
PM
1.4.3.8
System shall share a copy of APAR with the employee only the final authority
has accepted the APAR
E
23.
PM
1.4.3.9
System shall be able to track the status of completion and send
reminders/alerts accordingly
E
24.
PM
1.4.3.1
0
System shall allow employee t o make representation against adverse
comments reported if any
E
25.
PM
1.4.3.1
1
System shall store finalized appraisal reports with restricted access E
26.
PM
1.4.3.1
2
System shall also store grades in a separate file to be accessed by the system
for confirmation and promotion processing, etc.
E
27.
PM
1.4.3.1
3
Trainings recommended in the APAR shall integrate with the Training
Administration Module
E
8.4.5.5 Establishment Review
Establishment Review is the process of periodic assessment of the workload of the post offices. The
mainstay of conducting an establishment review is to arrive at accurate work load analysis in post
offices so as to enable optimal staffing in the postal unit.
#

C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

E 1.5.1 Set-up the Establishment Review Database
1.
E
1.5.1.1
Establishment Review Database is a master database containing information
about each establishment (post offices and administrative offices) such as:
Unique Number
Post Office Type and Classification
Functional status (Permanent/ Temporary)
Planning info (sanctioned staff, order number), establishment info (actual
staff),
Associated Accounts Office
Post Master and Phone Number
Locality Status (State, District, Urban / Rural, Normal / hilly, Status of locality,
Population, Area served , No of villages)
Year of last establishment review and related changes etc.
Applicable rules for kind of Reports (Supervisory, Operative, Delivery Post
Man, Group D and GDS)
Periodicity of Establishment Review
Master for time norms (for departmental post offices ) and point system
(Branch Offices)
Abolished posts, order number and date (for Head Post offices and Sub Post
Offices)
E
2.
E
1.5.1.2
Authorized officials from the HR Administration Team in each division, region
and circle will manage the workflow for Establishment Review process
E
3.
E
1.5.1.3
Establishment Review shall be a customized interface that shall have the ability
to draw data from the data warehouse for applications such as PBS, PLI, IPVS,
POS, Finance and Accounts
E
4.
E
1.5.1.4
Interface shall maintain the formats required for the workload analysis such as
EST 2, EST 79, EST 5, Workload Analysis for GDS Post
E
5.
E
1.5.1.5
System shall maintain proposal formats (for Conversion of part of temporary
establishment to permanent establishment, continuing remaining temporary
establishment, on creation of new establishment on surrender of old
establishment post, surrender existing establishment posts
(temporary/permanent) cadre review) available in the system so that proposal
can be created.
E
6.
E System shall maintain a master of the time norms and point factors for various
E
1.5.1.6 kinds of post offices and posts
7.
E
1.5.1.7
System shall also maintain the expenditure of running a GDS Post office with
details of number of GDS post and allowances paid
E
8.
E
1.5.1.8
System shall allow the HR Representative to assign a IPO/ASP for verification
of statistics and collection of data that could not be drawn from data
warehouse
E
9.
E
1.5.1.9
System shall maintain the conditions and rules for the kind of reports
(operative, supervisory, Group D, GDS, Postman) that must be generated for
each establishment depending on the classification and working staff
E
10.
E
1.5.1.1
0
System shall maintain the templates for EST 2, EST 79, EST 5, summary of
work hours reports for Supervisory, Operative, Delivery Post Man, Group D
and GDS based on type of post office
E
11.
E
1.5.1.1
1
System shall allow authorized user to perform analytics on sanctioned posts in
a cadre and establishment unit (old/new/to-be)
E
12.
E
1.5.1.1
2
System shall allow generation of lists of permanent/temporary posts at any
time
E
E 1.5.2 Workload Analysis of Departmental Post Offices
13.
E
1.5.2.1
System allows the authorized HR official in the HR Administration Team at
each division to identify the post offices due for periodic review based on the
pre-defined periodicity through the Establishment Review Module
E
14.
E
1.5.2.2
On request, the authorized official will request the MIS team to send data from
the data warehouse that he/she can view in the interface. The kind of data will
be the number of transactions for different products and the value of
transactions (in some cases)
E
15.
E
1.5.2.3
System shall have the ability to draw the statistical information for four
calendar months, regarding the number of transactions of each type
happening in a post office
E
16.
E
1.5.2.4
Authorized users shall send a copy of MIS report to the IPO with filled
statistical data and blank fields so that he/she can collect the data from the
respective post office
E
17.
E
1.5.2.5
Authorized official shall enter the data manually in the interface, data that was
send by IPO
E
18.
E
1.5.2.6
Authorized official shall apply pre-defined time norms from time factor master
file to generate work hour summary reports for operative, supervisory, sorting
postman, GDS and Group D as applicable to the post office
E
19.
E System shall draw information regarding the current staff hours from the
E
1.5.2.7 Establishment Review Master
20.
E
1.5.2.8
System shall bring together the summary of all kinds of work hours summary
reports and the staff hours in EST 79 format
E
21.
E
1.5.2.9
System shall retain one copy of the summary of work hours (EST 79) and
forward another copy to the authorized official in region office along with the
proposal for further consideration
E
22.
E
1.5.2.1
0
Any changes in the Establishment Information as a result of workload analysis
shall be updated in the Establishment Review Master
E
E 1.5.3 Workload Analysis of GDS Posts
23.
E
1.5.3.1
System allows the HR representative for Establishment Review at each division
to identify the GDS post in branch post offices due for periodic review based
on the pre-defined periodicity
E
24.
E
1.5.3.2
System allows the HR representative for Establishment Review to raise a
request for MIS report (in prescribed format) with filled in statistical data for
the defined period
E
25.
E
1.5.3.3
System supports the ability to draw data stored in data warehouse by different
software such as IPVS, POS, Core Banking Solution, and PLI Solution. The kind
of data will be the number of transactions for different products or the value
of transactions.
E
26.
E
1.5.3.4
E
27.
E
1.5.3.5
For data that cannot be drawn from the data warehouse directly, IPO/ASP
shall be collecting that data. System allows an authorized official to input that
data in the MIS report
E
28.
E
1.5.3.6
System shall apply pre-defined point system from master file to generate work
hour summary for various GDS post as applicable to the post office
E
29.
E
1.5.2.8
System shall draw information regarding the current staff hours from the
Establishment Review Master
E
30.
E
1.5.2.9
System shall retain one copy of the summary of work hours and forward
another copy to the authorized official in region office along with the proposal
for further consideration
E
31.
E
1.5.2.1
0
Any changes in the Establishment Information as a result of workload analysis
shall be updated in the Establishment Review Master
E
E 1.5.4 Financial Assessment of Branch Offices
32.
E System allows the HR representative for Establishment Review at each division
E
1.5.4.1 to identify the post offices due for financial assessment based on the pre-
defined periodicity
33.
E
1.5.4.2
System allows the HR representative for Establishment Review to raise a
request for MIS report (in EST 5 format) with value returns (income and
expenditure) for the branch office
E
34.
E
1.5.4.3
System supports the ability to draw data stored in data warehouse by different
software such as IPVS, POS, Core Banking Solution, PLI Solution and Rural ICT.
The kind of data will be the number of transactions for different products or
the value of transactions.
E
35.
E
1.5.4.4
E
36.
E
1.5.4.5
System shall also information about cost (static and dynamic) of running a
establishment such as allowances paid to the GDS employees, number of GDS
post, rent of building as in the prescribed format
E
37.
E
1.5.4.6
For data that cannot be drawn from the data warehouse directly, IPO/ASP
shall be collecting that data. System allows an authorized official to input that
data in the MIS report
E
38.
E
1.5.4.7
System shall calculate the income and expenditure and check the eligibility
against the pre-defined permissible limit of loss
E
39.
E
1.5.4.8
System shall retain one copy of the summary of work hours (EST 5) and
forward another copy to the authorized official in region office along with the
proposal for further consideration
E
40.
E
1.5.4.9
Any changes in the Establishment Information as a result of financial
assessment shall be updated in the Establishment Review Master
E
E 1.5.5 Update the Establishment Review Database
41.
E
1.5.5.1
Any change in the Establishment information as a result of workload analysis
or financial assessment leads to decisions such as:
Up gradation or down gradation of post office
Closure or merger of post offices
Change in the GDS allowances
Redeployment of post
Abolition of Post
Retention of a temporary post office
E
42.
E
1.5.5.2
System shall allow updating the Establishment Review Database with the order
number issued by circle, region or division and date of the order.
E
43.
E
1.5.5.3
System shall also allow updating PIS in line with the changes in Establishment
Review Master as this forms the basis of many HR processes such as Periodic
Review (Workload Analysis), Vacancy Calculation, Payroll, Transfer Process etc
E
44.
E
1.5.5.4
Scope of the Establishment Review Process depends on the scope of the
business operations performed in the post offices. Therefore, any changes in
the operations and activities in the post office shall be taken into account to
revise the line items or time factors for workload analysis. System shall have
the capability to incorporate such changes in future. Items of work or
description of work is likely to undergo changes after implementing of the IT
Modernization. Items of work could be added, eliminated or modified. This will
have to be factored in while configuring the Establishment Review Module.
E
8.4.5.6 Training Administration Module
Training Administration Module manages the process of load curriculum, administer course, and
register candidates for a course, Manage Registration and training evaluation. The module also helps
in monitoring the completion of training programs centrally. Employees of Group A and B can
nominate themselves for various training programs. This module also allows the managers to
nominate their staff for attending training courses.
#

C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

T 1.6.1 Training Set-up
1.
T
1.6.1.1
System shall support the training administration for the entire training
infrastructure (1 PSCI, 6 PTCs, 151 WCTCs and 70 Divisional Training Centres
and 6 Zonal Training Centres)
E
2.
T
1.6.1.2
System shall support online uploading of draft and final Training policy E
3.
T
1.6.1.3
System shall support alignment of training institutes with Training Calendar
and training courses as each training centre is mandated to provide a pre-
define kind of training
E
4.
T
1.6.1.4
System shall maintain the target audience for a training centre as each training
centre is mandated to cater to a training needs of pre-defined
circle/region/division based on geography
E
5.
T
1.6.1.5
System shall maintain the master list for faculty, classroom, number of
computers, hostel accommodation and batch size
E
6.
T
1.6.1.6
System shall authorize the Training centre-In charge of each training centre for
Training Administration activities such as course administration, class
scheduling, Manage Registration, training feedback etc.
E
7.
T System shall authorize appointing/relieving authority and immediate
E
1.6.1.7 supervisor to approve or cancel a nomination through workflow management
8.
T
1.6.1.8
Training and Development needs identified through Performance
Management Module
shall be captured in the system as priority needs for related employees
E
9.
T
1.6.1.9
System shall facilitate training need analysis by allowing employees to fill up
online questionnaires or competency testing system
E
10.
T
1.6.1.1
0
System shall have formats available in the system for proposal creation,
training plan, budget preparation and allocation of training budget to field
units
E
T 1.6.2 Load Training Calendar
11.
T
1.6.2.1
Based on the training set-up, authorized official shall prepare and load the
annual training calendar
E
12.
T
1.6.2.2
System shall allow training institutes to follow standardized training calendar
as loaded centrally by HRD and schedule some training programs based on the
needs of a specific circle/region and division
E
13.
T
1.6.2.3
Every employee can view his/her personalized training calendar for at least
next six months on Employee Portal
E
14.
T
1.6.2.4
System shall track the status of completion of mandatory training and
generate alert for probationary, new promotees and new joinees
E
T 1.6.3 Course Administration
15.
T
1.6.3.1
System shall authorize a training centre in-charge to administer a course by
adding course details such as Target participants, Duration, Maximum and
Minimum Batch Size, Faculty, Program Objectives and Program Content, Select
Course Evaluation Template
E
16.
T
1.6.3.2
System shall send the course details to the respective appointing authorities,
respective HRD team, Faculty and Target Audience
E
17.
T
1.6.3.3
System shall track due date for the course and generate alert for training
administrator and HR.
E
T 1.6.4 Class Scheduling
18.
T
1.6.4.1
System shall allow self-registration(for Group A and B) and Nomination by
Training Administrator
E
19.
T
1.6.4.2
For induction training for new joinees and promotees, the training
administrator shall receive a list of new joinees or promotees from the
Recruitment module
E
20.
T
1.6.4.3
System support maintenance of training profile for each employee including
recommended training, completed courses, certifications in PIS/Service Book.
E
21.
T
1.6.4.4
System shall allow the Training Administrator to search and select candidates
who have not completed a particular training course
E
22.
T
1.6.4.5
System shall allow to nominate candidates based on the pre-defined seat
allocation for each circle, region and division
E
23.
T
1.6.4.6
System shall allow the training administrator to nominate more people than
the batch size
E
24.
T
1.6.4.7
System shall forward the training nomination to respective workflow based
approver/ (relieving authority)
E
25.
T
1.6.4.8
System shall authorize the approver to accept/reject the nominations. E
26.
T
1.6.4.9
System shall maintain the list of leave reserves for making substitute
arrangement in place of a candidate going for training
E
27.
T
1.6.4.1
0
For any rejected nomination, the approver shall provide a alternative for
him/her, for which He/she can view the list of people under her/his circle,
region, division who have not completed that course
E
28.
T
1.6.4.1
1
System shall allow for maintaining a confirmed list and waitlist for the training
program based on the session capacity.
E
29.
T
1.6.4.1
2
Employee gets alert on change in registration status such as Registered,
Wait-Listed or Confirmed
E
30.
T
1.6.4.1
3
For accepted nominations, the supervisors of the registered candidate is
informed so as to relieve him/her for training
E
T 1.6.5 Manage Registration
31.
T
1.6.5.1
System shall send reminders to the enrolled candidates and supervisors E
32.
T
1.6.5.2
System shall draw the report of candidates registered for a particular course E
33.
T
1.6.5.3
Employee shall send a confirmation (with travel details) or request for a
cancellation, 15 days before the training program
E
34.
T
1.6.5.4
System shall request the candidate to register for the next course when
cancelling the current registration. Employee can view personalized training
calendar and schedule of the next training course
E
35.
T
1.6.5.5
In case of a cancellation of a registered candidate, system shall automatically
push the wait-listed candidates up the list
E
36.
T In case of a cancellation of training program when session capacity not met,
E
1.6.5.6 system shall send a system initiated email to the respective candidates
37.
T
1.6.5.7
System shall allow an authorized training in-charge to re-schedule a course E
38.
T
1.6.5.8
System shall maintain the list of cancelled/re-scheduled course and inform the
respective candidates. These candidates shall be given preference while
administering the course in future
D
39.
T
1.6.5.9
System also facilitates mapping training courses to employees based on
training recommended in the APAR. During the Performance Appraisal
Process, it is possible for the Appraiser to recommend specific or generic
training that they feel the appraised employee should undergo.
E
T 1.6.6 Training Delivery
40.
T
1.6.6.1
System shall support sending pre-reads or instructions to the registered
candidates. System shall support the training material in Hindi and English
language.
D
41.
T
1.6.6.2
System shall support marking attendance of the candidates E
42.
T
1.6.6.3
System shall allow online payment transfer to training providers / vendors D
T 1.6.7 Administer Training Feedback
43.
T
1.6.7.1
System shall allow selection of evaluation template from various available
templates. System shall support the templates in Hindi and English language.
E
44.
T
1.6.7.2
System shall have provision for creation of instruments for online evaluation of
training by employees/supervisors whose access and response recorded in the
system
E
45.
T
1.6.7.3
System shall have provision for online tracking of responses uploaded by
related (trainees/supervisors) and generate reminders/escalation to superiors
if not done by due date
E
46.
T
1.6.7.4
System shall have provision for online compilation of responses to evaluation
Instruments
E
47.
T
1.6.7.5
System compiles the consolidated training feedback report and sends to the
HRD Division
E
T 1.6.8 Administer Participant Evaluation
48.
T
1.6.8.1
System allows for a participant evaluation test/assessment with options for
scoring and correct answers. System shall support the test in Hindi and English
language.
E
49.
T
1.6.8.2
System shall draw a report with consolidated results (in percentile) to be
shared with candidates
E
50.
T
1.6.8.3
System shall allow for the scores/ certification to be captured in the PIS.
System shall register an employee for re-training if they fall in the group
(Needs Improvement)
E
51.
T
1.6.8.4
System shall be able to grade the performance of the candidates in 3-4 groups
to identify the best performers and the candidates who need improvement
E
52.
T
1.6.8.5
System shall consider the candidates marked as Needs Improvement for next
training program in a WCTC/Divisional Training Centre
E
T 1.6.9 Post Training Activities
53.
T
1.6.9.1
System allows for updating training record (attendance and evaluation) for an
employee after completion of the training
E
54.
T
1.6.9.2
System shall provide for taking online feedback from supervisor one month
after the training completion. System shall aggregate the result to be used by
HRD Division
E
55.
T
1.6.9.3
System allows for reporting the cost of the training under various heads E
56.
T
1.6.9.4
System shall provide summary analysis of training evaluations, participant
evaluation, attendance, and cost after completion of training.
E
57.
T
1.6.9.5
System shall support the update of training database for GDS, by an authorized
official (such as the IPO/ASP)
E
58.
T
1.6.9.6
System updated the PIS and Online Service Book with the training details and
the scores received in the training
E
59.
T
1.6.9.7
System shall support the training administration for e-learning programs in
future as India Post is planning to go for e-learning in future.
D
8.4.5.7 Employee Portal
Employee Portal is a browser based portal that can be used for used for initiating some of the HR
related transactions. It can also be used to view personal and service records, check the status of
approval of a request raised on Employee Portal. Managers can view the request routed to them by
their employee.
#

C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

1.
EP
1.7.1
Employees shall have access to the following:
Individual log-in ID and password to every employee
E
Ability to view personal and service records such as online service book,
gradation list etc.
Ability to view and edit personal data
Ability to initiate Employee Portal transactions such as:
o Leave Management
o Performance Management
Training Administration
Ability to view the status of a request
India Post News and Updates (common content and location specific)
2.
EP
1.7.2
Managers shall have access to the following:
Besides the above Employee Portal features, managers shall be able to view
the view and accept/reject the Employee Portal transactions directed to
them by his/her staff
Ability to view the relevant information about the employee when approving
a request such as leave balance summary etc.
Ability to view MIS reports , based on authorization
E
3.
EP
1.7.3
Employee Portal also maintains links for Employee Search, Post Offices Search,
Expert Directory, My Service Book, My Training Page etc.
E
4.
EP
1.7.4
Employee Portal shall also provide functionalities such as raising a query for
HR, applying for LTC, Medical Claims, and Cash Advance. Through workflow
management, this shall be routed to the manager for approval and to the
Payroll for processing
E
5.
EP
1.7.5
System shall support the Employee Portal content in Hindi and English
language.
E
6.
EP
1.7.6
HR Administration Team shall be responsible for the following:
Ensure proper workflow management
Track the status of pending approvals
Manage the content on the portal
E
8.4.6 Customer Interaction Management
8.4.6.1 Point Of Sale
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

Overall
1. POS1.1 The solution shall provide PoS support E
2. POS1.2
The system shall provide access to only DoP employees (administrators, users,
etc) using unique employee user id and password
E
Information Management
3. POS2.1
The system shall provide information to the citizens about DoP (such as
history, management, mission, organization, citizen charter, etc.)
E
4. POS2.2
The system shall provide information about various products and services
offered by the DoP
E
5.
POS2.2
.1
The system shall integrate with the Mail Operations system to provide
information about various mail products and services
E
6.
POS2.2
.2
The system shall integrate with the PBS to provide information about various
banking products and services
E
7.
POS2.2
.3
The system shall integrate with the PLI system to provide information about
various Insurance products and services
E
8.
POS2.2
.4
The system shall integrate with Mail Operations system to provide information
about various retail products and services
E
9. POS2.3
The POSS shall support rich media content (such as flash video, audio, or video
(mpeg, mov, asf, etc.); rich content such as a robust user interface)
D
10. POS2.4 The system shall enable Product Data Management D
11.
POS2.4
.1
The system shall provide/leverage new or existing cross-sell rules D
12.
POS2.4
.2
The system shall provide/leverage new or existing up-sell rules D
13.
POS2.4
.3
The system shall provide product bundling D
14. POS2.5 The system shall support Unicode (multiple languages) E
Transaction Management
15. POS3.1 The system shall enable Order Capture E
16.
POS3.1
.1
The system shall enable users to browse, search and compare different
products and services
E
17.
POS3.1
.2
The system shall enable users to place the order for different services E
18.
POS3.1
.2.1
The system shall integrate with Mail Booking Engine for all transactions related
to mail articles
E
19.
POS3.1
.2.2
The system shall integrate with PBS for all banking related transactions E
20.
POS3.1
.2.3
The system shall integrate with PLI system for all insurance related
transactions
E
21.
POS3.1
.2.4
The system shall integrate with Mail Booking Engine to record the Retail Post
sale transaction
E
22.
POS3.1
.2.4.1
The system shall enable users to place order for DoP products (such as Stamps,
Postcards, Envelopes, Stationary, and Philately etc.)
E
23.
POS3.1
.2.4.2
The system shall enable users to place order for DoP featured products (India,
abroad and warehouse)
E
24.
POS3.1
.2.4.3
The system shall provide reservations for the out-of stock products D
25. POS3.2 The system shall allow Order Management E
26.
POS3.2
.1
The system shall provide home pick up, delivery and return of articles and
orders
D
27.
POS3.2
.2
The system shall integrate with IPVS to enable users to create track and trace
alerts
E
28.
POS3.2
.3
The system shall provide customer order history based on the customer id E
29.
POS3.2
.4
The system shall be able to automatically capture the weight of the article
using the weighing machine connected to the PoS counter machine
E
30.
POS3.2
.4.1
The system shall allow the user to manually enter the weight of the article in
case the weighing scale is not connected to the PoS counter machine
E
31.
POS3.2
.5
The system shall be able to read the barcode scanned by the office scanner
connected to the PoS counter machine
E
32.
POS3.2
.6
The PoS shall be able to print out the article labels, barcodes, customer receipt
etc using the printer connected to the POSS counter machine
E
33. POS3.3 The system shall allow order payment management E
34.
POS3.3
.1
The system shall integrate with different systems (Mail Booking engine, PLI and
CBS) and produce a single consolidated bill for all the transactions done by the
customer
E
35.
POS3.3
.2
The system shall be able to process cash payments from the customer against
the bill outstanding
E
36.
POS3.3
.3
The system shall be able to process payments using credit card / debit card /
cash card from the customer against the bill outstanding
E
37.
POS3.3
.3.1
The system shall integrate with the payment gateway using the magnetic card
swipe machine connected to the PoS counter machine
E
38.
POS3.3 The system shall be able to process payments using direct debit from the
E
.4 Postal Savings Bank of the customer against the bill outstanding
39.
POS3.3
.5
The system shall be able to process payments using Bill Me Later Payment
method (e.g. cash on delivery, VPP) for the customers against the bill
outstanding
E
40.
POS3.3
.6
The system shall be able to process payments using cheques from the
bulk/corporate/BNPL customers against the bill outstanding
E
41.
POS3.3
.6.1
The POSS shall not accept and process cheques provided by the individual
customers against any amount outstanding
E
Account Management
42. POS4.1
The system shall provide access to only DoP employees (i.e. administrators and
users)
E
43. POS4.2
The system shall allow only administrators to create/add new user to the PoS
counter
E
44.
POS4.2
.1
The system shall allow administrators to define the user rights and the
transactions which shall be allowed to be performed at the PoS counter
E
45.
POS4.2
.2
The system shall integrate with the Active Directory to add the user profile as
created by the administrator
E
46. POS4.3
The system shall allow users and administrators to access the terminal using
the unique username/user id and password
E
47.
POS4.3
.1
The system shall integrate with the Active Directory to verify the
username/user id and the password
E
48.
POS4.3
.2
The system shall integrate with the local database to verify the username/user
id and the password in case of loss of connectivity with the Active Directory
E
49.
POS4.3
.3
The system shall enable multiple users and administrators use the same PoS
counter using his/her username and password
E
50. POS4.4
The system shall provide users with the flexibility to customize screen views
(e.g. shortcuts for the product/service in most demand)
D
51. POS4.5
The system shall enable users to create dashboards providing summary of all
the recent transactions related to mails, banking, insurance and retail post
E
52. POS4.6
The system shall provide the periodic (end of day/end of week/end of month)
summary of cash position at the counter against all the users using that PoS
counter
E
53. POS4.7
The system shall interface with the "Sanchay Post" (in offices where Sanchay
Post is used for Banking related transactions) to receive the details of all the
credit and debit transactions done at the terminal by different users and
reconcile the end of day cash balance
E
54. POS4.8
The system shall interface with the "Treasurers F&A Module" and generate
E
MIS reports for all the credit and debit transactions done at the various Post
office terminals by different users and arrive at the end of day cash balance
55. POS4.9
The system shall provide the periodic (end of day/end of week/end of month)
summary of login time, logout time, number of transactions and value of
transactions by each PoS counter and each PoS user
E
8.4.6.2 Web Portal
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

Overall Scope
1.
WEB1.
1
The portal shall provide web browser support, cross browser compatibility,
and channel support like mobile platforms (all Mobile OS)
E
2.
WEB1.
2
The portal shall provide access to various types of users E
3.
WEB1.
2.1
The portal shall provide access to customers E
4.
WEB1.
2.1.1
The portal shall provide access to individual customers E
5.
WEB1.
2.1.2
The portal shall provide access to corporate customers E
6.
WEB1.
2.2
The portal shall provide access to merchandisers of retail products and
services
D
7.
WEB1.
2.3
The portal shall provide access to advertisers D
8.
WEB1.
2.4
The portal shall provide access to agents E
Information Management
9.
WEB2.
1
The portal shall provide information about DoP (such as history, management,
mission, organization, citizen charter, etc.)
E
10.
WEB2.
2
The portal shall provide information about various products and services E
11.
WEB2.
2.1
The portal shall integrate with the Mail Operations system to provide
E
12.
WEB2.
2.2
The portal shall integrate with the PBS to provide information about various
E
13.
WEB2.
2.3
The portal shall integrate with the PLI system to provide information about
various Insurance products and services
E
14.
WEB2.
2.4
The portal shall provide information about various Retail products and services E
15.
WEB2.
3
The portal shall manage the content and catalogue E
16.
WEB2.
3.1
The portal shall enable content acquisition and creation E
17.
WEB2.
3.2
The portal shall provide an online catalogue E
18.
WEB2.
3.3
The portal shall enable content maintenance E
19.
WEB2.
3.4
The portal shall support rich media content (such as flash video, audio, or
video (mpeg, mov, asf, etc.); rich content such as a robust user interface) to
enable podcasting and web casting
E
20.
WEB2.
3.5
The portal shall provide versioning and configuration management E
21.
WEB2.
3.6
The portal shall provide dynamic caching E
22.
WEB2.
4
The portal shall manage the product data E
23.
WEB2.
4.1
The portal shall provide product attribute management E
24.
WEB2.
4.2
The portal shall provide/leverage new or existing cross-sell rules D
25.
WEB2.
4.3
The portal shall provide/leverage new or existing up-sell rules D
26.
WEB2.
4.4
The portal shall provide product cross reference and replacement (e.g. offer a
replacement product in the event that the product under view is sold out)
D
27.
WEB2.
4.5
The portal shall provide product bundling D
28.
WEB2.
4.6
The portal shall enable users to customize/configure products D
29.
WEB2.
The portal shall provide advertisements of the merchandisers E
5
30.
WEB2.
6
The portal shall provide Value Added Services (VAS) E
31.
WEB2.
6.1
The portal shall enable users to locate nearest post office/letter box E
32.
WEB2.
6.2
The portal shall enable users to look up PIN code district wise E
33.
WEB2.
6.3
The portal shall enable users to subscribe for e-Newsletter, Direct Mailers, etc. E
34.
WEB2.
6.4
The portal shall provide the service of "Ask an expert service" D
35.
WEB2.
6.5
The portal shall provide Directory Services (e.g. Yellow Pages) E
36.
WEB2.
6.6
The portal shall provide Font Download E
37.
WEB2.
6.7
The portal shall provide Print Postage (refer MB1.6.8-MB1.6.9) D
38.
WEB2.
7
The portal shall provide multiple language translation support E
Transaction Management
39.
WEB3.
1
The portal shall manage the order capture E
40.
WEB3.
1.1
The portal shall enable users to browse, search and compare different
products and services
E
41.
WEB3.
1.2
The portal shall enable users to place the order for different services E
42.
WEB3.
1.2.1
The portal shall integrate with Mail Booking Engine system for all transactions
related to individual mail articles
E
43.
WEB3.
1.2.2
The portal shall integrate with MLASS for all transactions related to bulk mail
articles
E
44.
WEB3.
1.2.3
The portal shall integrate with PBS for all banking related transactions E
45.
WEB3.
1.2.4
The portal shall integrate with PLI system for all insurance related transactions E
46.
WEB3.
1.2.5
The portal shall enable users to shop Retail Post products E
47.
WEB3.
1.2.5.1
The portal shall integrate with Mail Booking Engine to record the Retail Post
sale transaction
E
48.
WEB3.
1.2.5.2
The portal shall enable users to place order for the DoP products (such as
Stamps, Postcards, Envelopes, Stationary, Philately, etc.)
E
49.
WEB3.
1.2.5.3
The portal shall enable users to place order for featured products (India,
abroad and warehouse)
E
50.
WEB3.
1.2.5.4
The portal shall enable users to place order from the merchandiser websites
(India and abroad)
D
51.
WEB3.
1.2.5.4.
1
The portal shall provide the list of merchandiser websites (including foreign
posts for stamps)
D
52.
WEB3.
1.2.5.4.
2
The portal shall enable users to navigate to (and place order on) merchandiser
website
D
53.
WEB3.
1.2.5.4.
3
The portal shall capture the details of the order placed on the merchandiser
website
D
54.
WEB3.
1.2.5.5
The portal shall provide global shopping cart E
55.
WEB3.
1.2.5.6
The portal shall enable users to specify the delivery details (such as address,
time, packaging requirements, etc.)
E
56.
WEB3.
1.2.5.7
The portal shall integrate with IPVS to enable users to create track and trace
alerts
E
57.
WEB3.
2
The portal shall provide order management capability E
58.
WEB3.
2.1
The portal shall provide home pick up, delivery and return of articles and
orders
D
59.
WEB3.
2.2
The portal shall provide Track & Trace of articles and orders E
60.
WEB3.
2.3
The portal shall provide order maintenance E
61.
WEB3.
2.4
The portal shall provide order cancellation E
62.
WEB3.
2.5
The portal shall provide Back-order and wait list D
63.
WEB3.
2.6
The portal shall provide order history E
64.
WEB3.
3
The portal shall provide order payment management capability E
65.
WEB3.
3.1
The portal shall perform the payment calculation E
66.
WEB3.
3.1.1
The portal shall calculate the cost of all the products purchased E
67.
WEB3.
3.1.2
The portal shall calculate the tax/duty to be levied E
68.
WEB3.
3.1.3
The portal shall calculate shipping and handling charges E
69.
WEB3.
3.2
The portal shall provide payment refund processing E
70.
WEB3.
3.3
The portal shall provide Fraud Management i.e. the capability to recognize
fraud occurring on the site through pattern analysis
E
71.
WEB3.
3.4
The portal shall integrate with the payment gateway to facilitate all 3
rd
party
online payments
E
72.
WEB3.
3.4.1
The portal shall enable users to make a direct debit from his/her bank account E
73.
WEB3.
3.4.1.1
The portal shall provide users a list of banks to choose from E
74.
WEB3.
3.4.1.2
The portal shall integrate with the portal of the chosen bank and navigate the
users to his/her bank account
E
75.
WEB3.
3.4.2
The portal shall enable users to make payment using his/her debit card E
76.
WEB3.
3.4.2.1
The portal shall provide users a list of debit cards to choose from E
77.
WEB3.
3.4.2.2
The portal shall integrate with the portal of the chosen debit card
company/bank and navigate the user to the website
E
78.
WEB3.
3.4.3
The portal shall enable users to make payment using his/her credit card E
79.
WEB3.
3.4.3.1
The portal shall provide users a list of credit cards to choose from E
80.
WEB3.
3.4.3.2
The portal shall integrate with the portal of the chosen credit card
E
81.
WEB3.
3.4.4
The portal shall enable users to make payment using his/her cash card E
82.
WEB3.
3.4.4.1
The portal shall provide users a list of cash cards to choose from E
83.
WEB3.
3.4.4.2
The portal shall integrate with the portal of the chosen cash card
E
84.
WEB3.
3.4.5
The portal shall enable users to make payment using 3
rd
party (e.g. Pay Pal)
payment method
E
85.
WEB3.
3.4.5.1
The portal shall provide users a list of 3
rd
party payment options to choose
from
E
86.
WEB3.
3.4.5.2
The portal shall integrate with the portal of the chosen 3
rd
party and navigate
the user to the website
E
87.
WEB3.
3.4.6
The portal shall provide Bill Me Later Payment method (e.g. cash on delivery,
VPP)
E
Marketing
88.
WEB4.
1
The portal shall support brand management to manage customer experience
and brand through products, content, and advertising
E
89.
WEB4.
2
The portal shall support campaign management to create and schedule
campaigns/promotions centred around specific products
D
90.
WEB4.
3
The portal shall support online marketing to integrate with sister sites to foster
cross selling amongst a suite of applications
D
91.
WEB4.
4
The portal shall support email marketing to conduct email campaigns to
promote simple purchasing such as 1-click ordering
D
92.
WEB4.
5
The portal shall support targeted marketing to target specific customer
segments to promote products that the segment is deemed to desire
D
93.
WEB4.
6
The portal shall support comparison shopping to enable users to compare
specific products to determine the best possible choice
E
94.
WEB4.
7
The portal shall support search engine optimization to enhance search results
on search engines such as Google primarily by adding appropriate keywords
throughout the application
D
95.
WEB4.
8
The portal shall support portal integration and placement to produce the
content in a portal user interface through external portals such as yahoo or
MSN
D
96.
WEB4.
9
The portal shall support loyalty programs to promote programs such as
discounts for returning customers, customer buyback (e.g. buy 3 get 1 free).
D
97.
WEB4.
10
The portal shall support integration with 3
rd
party advertising agents (e.g.
adsends)
D
Account Management
98.
WEB5.
1
The portal shall provide account and profile management to all its users E
99.
WEB5.
1.1
The portal shall provide account and profile management to customers E
100.
WEB5.
1.1.1
The portal shall provide account and profile management to individual
customer
E
101.
WEB5.
1.1.2
The portal shall provide account and profile management to corporate
customers
E
102.
WEB5.
1.2
The portal shall provide account and profile management to merchandisers of
retail products and services
D
103.
WEB5.
1.3
The portal shall provide account and profile management to advertisers D
104.
WEB5.
2
The portal shall have the capability to manage the account and profile E
105.
WEB5.
2.1
The portal shall enable users to register their profiles online E
106.
WEB5.
2.1.1
The portal shall enable users to specify delivery/pick-up address E
107.
WEB5.
2.1.2
The portal shall enable users to update delivery/pick-up address (permanent
and temporary)
E
108.
WEB5.
2.2
The portal shall provide a calendar E
109.
WEB5.
2.3
The portal shall provide account & profile viewing and maintenance E
110.
WEB5.
2.3.1
The portal shall enable users to create viewing dashboards providing summary
of all the recent transactions related to mails, banking, insurance and retail
post
E
111.
WEB5.
2.3.2
The portal shall enable users to view transaction history E
112.
WEB5.
2.3.2
The portal shall enable users to view bank account balance, payment amount
outstanding, payment due date, etc.
E
113.
WEB5.
2.4
The portal shall enable users to link various accounts E
114.
WEB5.
2.5
The portal shall enable users to create and manage alerts E
115.
WEB5. The portal shall enable users to create and manage alerts for new products,
E
2.5.1 services, discount, schemes, etc.
116.
WEB5.
2.5.2
The portal shall enable users to define frequency of the account statements
(email/post, monthly/quarterly)
E
Customer support
117.
WEB6.
1
The portal shall interface with the customer Call Centre for order support E
118.
WEB6.
2
The portal shall provide customer support E
119.
WEB6.
2.1
The portal shall support Customer Feedback/Surveys E
120.
WEB6.
2.2
The portal shall support Customer Complaints E
121.
WEB6.
2.3
The portal shall support Customer Requests E
122.
WEB6.
2.4
The portal shall integrate with the Customer Call Centre solution to generate
the complaint registration number to be provided to the customer
E
123.
WEB6.
3
The portal shall enable users to access the list of Frequently Asked Questions
(FAQs)
E
Site navigation
124.
WEB7.
1
The portal shall provide Interactive Site Navigation (e.g. flash based virtual
post)
E
125.
WEB7.
2
The portal shall provide Guided Navigation E
126.
WEB7.
3
The portal shall provide Site Search E
127.
WEB7.
4
The portal shall provide Site HELP E
128.
WEB7.
5
The portal shall provide Site Map E
8.4.6.3 Mobile Solution
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

CIM1 Solutions shall provide responses to enquiry through SMS
1. CIM1.1 Solution shall receive customer enquires through SMS at a number E
2. CIM1.2
Solution shall enable response to enquiries pertaining to the status of a
consignment in the DoP supply chain
E
3. CIM1.3
Solution shall interface with IPVS to check the status of consignment for the
article details given in the customer SMS
E
4. CIM1.4
Solution shall send an SMS alert to the customer providing information about
the status of the consignment
E
CIM2 Solution shall register customer complaints and track the status of complaint
5. CIM2.1 Solution shall receive customer complaints through SMS E
6. CIM2.2
Solution shall register the customer complaint and send an SMS alert to the
customer intimating the customer complaint number
E
7. CIM2.3
Solution shall track the status of customer complaint and send SMS to the
customer informing about the status of the complaint
E
CIM3
Solution shall generate SMS alert at various pre-defined stages in the supply
chain of the DoP

8. CIM3.1 Solution shall have the ability to generate SMS alert for attempted delivery E
9. CIM3.2
Solution shall have the ability to generate SMS alert for estimated time of
delivery
E
10. CIM3.3
Solution shall have the ability to send the SMS alert to contact number
provided while booking the consignment
E
8.4.7 Call Centre
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

CI.CS.1 Scope of the Solution
1.
CI.CS.1.
1
The solution shall support various customer interaction channels E
2.
CI.CS.1.
1.1
The solution shall provide Call Centre Integration support E
3.
CI.CS.1.
1.2
The solution shall provide Interactive Voice Response (IVR) support E
4.
CI.CS.1.
1.3
The solution shall enable customers to connect to the customer support centre
from anywhere in India (24 x 7 x 365 or as indicated) using India Post toll free
telephone number
E
CI.CS.2 The solution shall provide relevant information
5.
CI.CS.2.
1
The solution shall provide general information about India Post (such as
history, management, mission, organization, citizen charter, etc)
E
6.
CI.CS.2.
1.1
The solution shall enable users to locate post office/box nearest to the
customer
E
7.
CI.CS.2.
1.2
The solution shall enable users to look up PIN code E
8.
CI.CS.2.
1.2
The solution shall enable users to better leverage and access information on
the portal, and information regarding the various services available through
the multiple channels
E

CI.CS.2.
2
The solution shall provide information about various Mail, Banking, and
Insurance products and services.

9.
CI.CS.2.
2.1
The solution shall integrate with the Mail Operations system to provide
E
10.
CI.CS.2.
2.2
The solution shall integrate with the PBS to provide information about various
E
11.
CI.CS.2.
2.3
The solution shall integrate with the Postal Life Insurance (PLI) system to
provide information about various Insurance products and services
E
12.
CI.CS.2.
2.4
The solution shall integrate with Mail Operations system to provide
information about various retail products and services
E
CI.CS.3 The solution shall initiate and execute various types of transactions
13.
CI.CS.3.
1
The solution shall integrate with Mail Booking Engine system for all orders and
requests related to individual mail articles
E
14.
CI.CS.3.
2
The solution shall integrate with Mail Booking Engine system for all orders and
requests related to retail post service
E
15.
CI.CS.3.
3
The solution shall integrate with Mail & Logistics Appointment Scheduling
system (MLASS) for all orders and requests related to bulk mail articles
E
16.
CI.CS.3.
4
The solution shall integrate with PBS for all orders and requests related to
banking
E
17.
CI.CS.3.
5
The solution shall integrate with Postal Life Insurance (PLI) system for all
orders and requests related to insurance
E
18.
CI.CS.3.
6
The solution shall integrate with Agency Management system for all orders
and requests related to insurance
E
19.
CI.CS.3.
7
The solution shall integrate with the India Post Visibility System (IPVS) to track
and trace all the articles and products
E
20. CI.CS.4 The solution shall manage the customer complaints E
21.
CI.CS.4.
1
The solution shall enable the user to register the customer complaint and/or
feedback
E
22.
CI.CS.4.
2
The solution shall generate the customer complaint registration number E
23.
CI.CS.4.
3
The solution shall integrate with identified departments to send the mails for
customer complaint resolution
E
24.
CI.CS.4.
4
The solution shall track the status of the customer complaint E
25.
CI.CS.4.
5
The Call Centre shall integrate with the portal to receive the customer
complaints and provide information related to the status of the customer
complaint.
E
CI.CS.5 The solution shall manage the accounts
26.
CI.CS.5.
1
The solution shall provide access to only India Post employees (i.e.
administrators and users) for accessing accounts
E
27.
CI.CS.5.
2
The solution shall allow only administrators to create/add new user and delete
old users to provide access to the Call Centre terminal
E
28.
CI.CS.5.
2.1
The solution shall allow administrators to define the user rights and the
transactions which shall be allowed to be performed at the CSC terminal
E
29.
CI.CS.5.
2.2
The solution shall integrate with the Active Directory to add the user profile as
created by the administrator
E
30.
CI.CS.5.
2.3
The solution shall provide access and authority to make changes to system
configurations only India Post employees (administrators, specified users, etc)
using employee unique user id and password
E
31.
CI.CS.5.
3
The solution shall allow users and administrators to access the terminal using
the unique username/user id and password
E
32.
CI.CS.5.
3.1
The solution shall integrate with the Active Directory to verify the
username/user id and the password
E
33.
CI.CS.5.
3.2
The solution shall integrate with the local database to verify the
username/user id and the password in case of loss of connectivity with the
Active Directory
E
34.
CI.CS.5.
3.3
The solution shall enable multiple users and administrators use the same CSC
terminal using his/her username and password
E
Interactive Voice Response (IVR)
IVR 2 Call Centre & IVR Requirements
35. IVR 2.1 The IVR solution shall be available via the call centre number 24X7X365 E
36. IVR 2.2
The solution shall provide dual-tone multi-frequency (DTMF) signalling menu
service for users to retrieve information from the service.
E
37. IVR 2.3
The IVR services shall be rendered across the various states. The service shall
be accessible in the local language of the state as well as
English and Hindi.
E
38. IVR 2.4
The menu structure shall provide callers with touch tone shortcuts, that can be
used in sequence, which will allow the knowledgeable users to access
information more quickly, without having to drill down through the menu
structure with every call.
E
39. IVR 2.5
The system shall have an on-line help service with:
Instructions for proper use of the service by caller
Menus
Content (information) available to the caller
E
40. IVR 2.6
The service shall respond to user errors with an offer to the users to restate or
re-enter their selection.
E
41. IVR 2.7
The service shall allow users the capability of replaying the message they have
just heard, restarting their session by returning to the main menu, or by
accessing the help menu at any point during the call.
E
42. IVR 2.8
The system shall have capability of presenting a broadcast message at the
start of every call, if it is required at any point during the stage of regular
operations. This message shall be separate and apart form any static
message regarding service availability.
D
43. IVR 2.9
The information shall be provided to the callers after their identification based
on the required query. The system must have an authentication mechanism
through PIN.
E
44.
IVR
2.10
The solution shall be able to support multi-lingual requirements E
45.
IVR
2.11
The information that a user may seek are:
Status of application based on transaction id.
Information on India Post services
E
46.
IVR
2.12
Once the caller initial request has been satisfied, the caller will be prompted
whether or not they wish to request additional information.
E
Reporting Requirements
47. REP1.1 Calls per week, month or other period. E
48. REP1.2 Numeric and graphical representation of call volume E
49. REP1.3 Call per phone line or port E
50. REP1.4 Average length of calls E
51. REP1.5
Calls for each interaction tracked by type ( calls for information on specific
service, calls for specific enquiries)
E
52. REP1.6
Number of dropped calls after answering, including:
Calls that ended while on hold, indicating that the caller hung up
Call that ended due to entry errors using the automated system indicating
difficulty in using the system
E
53. REP1.7
The solution shall provide the periodic (end of day/end of week/end of month)
summary of login time, logout time, number of calls and action taken by each
CSC terminal and each CSC user
E
8.4.8 Common Infrastructure Solution
8.4.8.1 Enterprise Management System
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l
/
D
e
s
i
r
e
d

Enterprise Management System: To provide comprehensive end-to-end availability and
performance management across key parts of the infrastructure and applications. It
should allow identifying trends in performance in order to avert possible service
problems.

1. CI3.1
The solution shall integrate server, application and database performance
information and alarms in a single console and provide a unified reporting
interface for complete environment. The current performance state of the
entire Data Centre environment shall be visible in an integrated console.
E
2. CI3.2
The solution must scale to a large infrastructure while supporting a single web
interface for access to reports.
E

Virtualization Management System: The proposed solution must extend management
capabilities from the physical server environment to the virtual server environment. The
proposed solution must have capabilities to:

3. CI3.3 Monitor complex heterogeneous physical & virtual environment. E
4. CI3.4 Detect, diagnose & remediate root-cause & performance issues. E
5. CI3.5 Visibility into virtual machine (VM) location, configuration & response times. D
6. CI3.6 Discovery to inventory, baseline & identify virtual sprawl E
7. CI3.7
Tracking & Validating Configuration Changes of both host and guest virtual
Machines.
E
8. CI3.8 Virtual Machine Usage reporting & checking compliance to pass audits E
9. CI3.9 Managing resource pools across heterogeneous virtual environment. E
10. CI3.10
Standardize configuration, timely provisioning and appropriate retirement of
Virtual Machines
D
11. CI3.11
The solution should help in overcoming complexities associated with
virtualization by providing visibility into the virtualized Infrastructure,
automating Data Centre processes, pin point root cause & performance issues
inside complex heterogeneous virtual environments.
E
12. CI3.12
The solution must support an architecture that can be extended to support
multiple heterogeneous virtualization platforms, hypervisors and technologies
E
13. CI3.13
The system must be able to discover parent host server and map virtual
machine relationship to their parent host and build up graphical web based
topology map automatically for virtual machines & physical host
E
14. CI3.14
The system should understand parent-child relationship between parent
virtual host & guest VMs and deduce root-cause by automatically suppressing
alarms from guest VMs in case parent host goes down.
E
15. CI3.15
The solution must detect virtual server and virtual machine configuration
changes and automatically update topology.
E
16. CI3.16
Proposed solution should be able to track dynamic movement of virtual
machines (for e.g. vMotion) in virtual environment.
E
17. CI3.17
The system must support enhanced fault isolation to suppress alarms on
logical VMs when physical servers fail.
E
18. CI3.18
The solution must have the ability to collect data from the virtual systems
without only relying on SNMP.
D
19. CI3.19
The solution should provide comprehensive end-to-end performance reporting
for virtual environments.
E
20. CI3.20
The solution must support centralized management of virtual and physical
environments and provide a single central point of control for heterogeneous
environments.
E
21. CI3.21
The system must provide dynamic optimization of virtual resources enabling IT
administrators proactively respond to changing business demands by using
business policy and performance data to allocate and reallocate systems
resources in real-time.
D
22. CI3.22
The system must provide real-time and historical performance of physical and
virtual environments
D
Server Management System
23. CI3.23
The system shall provide the unified performance state view in a single
console. The current performance state of the entire server infrastructure shall
be visible in an integrated console.
E
24. CI3.24
The system must provide lightweight server agents to ensure availability and
performance for target server nodes and deliver scalable, real-time
management of critical systems. It should also be able to automate
monitoring, data collection and analysis of performance from single point.
E
25. CI3.25
Agent(s) on the managed node (server) should be used to monitor both the
system metrics and processes as well as monitor any application(s) running on
that server.
D
26. CI3.26
The system should be able to monitor various operating system parameters
such as processors, memory, files, processes, file systems, etc. where
applicable, using agents on the servers to be monitored
E
27. CI3.27
It should be possible to configure the operating system monitoring agents to
monitor based on user-defined thresholds for minimum warning and critical
states and escalate events to event console of enterprise management system.
E
28. CI3.28
The proposed agents should support operating system monitoring for various
platforms including Windows, UNIX and Linux versions.
E
29. CI3.29
It should also be able to monitor various operating system parameters
depending on the operating system being monitored, yet offer a common
interface for viewing the agents and setting thresholds.
D
30. CI3.30
It should also provide the ability to set thresholds and send notifications when
an event occurs, enabling system administrators and DBAs to quickly trace and
resolve performance-related bottlenecks.
E

The proposed server monitoring agent must support monitoring the following
parameters but not limited to:

31. CI3.31
Processors: Each processor in the system should be monitored for CPU
utilization. It should compare Current utilization against user specified warning
and critical thresholds.
E
32. CI3.32
File Systems: Each file system should be monitored for the amount of file
system space used, which should be compared to user-defined warning and
critical thresholds.
E
33. CI3.33
Log Files: Logs should be monitored to detect faults in the operating system,
the communication subsystem, and in applications. System agents should also
analyze log files residing on the host for specified string patterns.
E
34. CI3.34
System Processes: System agents should provide real-time collection of data
from all system processes. Using this it should help identify whether or not an
E
important process has stopped unexpectedly. It should provide an ability to
automatically restart Critical processes.
35. CI3.35
Application Processes: The agent should be capable of monitoring critical
application processes for any application hosted on the server
E
36. CI3.36
Application log files: The agent should be capable of parsing the application
log files to identify error conditions and automatically take actions based on
pre-defined policies
E
37. CI3.37
Application related metrics: The agent should be capable of collecting system
resource utilization by application or specific application process.
E
38. CI3.38
Memory: System agents should monitor memory utilization and available
swap space and should raise an alarm in event of threshold violation.
E
39. CI3.39
The system must send alerts for an array of server conditions, including
inadequate free space, runaway processes, high CPU utilization and
inadequate swap space and should also have capability to take automatic
corrective actions
D
40. CI3.40
The solution must be able to gather information about resources over a period
of time and provide historical performance and usage information through
graphical reports showing overall performance trends. It should also include a
platform-independent, browser-based console to monitor performance from
remote locations.
E
Database Management System
41. CI3.41
The solution should support monitoring of standard RDBMS such as Oracle,
DB2 and MS-SQL.
E
42. CI3.42
The solution should have out of box monitoring capabilities of various
parameters of standard RDBMS. The solution must include hundreds of
predefined scans for monitoring various database and operating system
resources.
E
43. CI3.43
The solution should have capability of automatic corrective actions for
standard RBMS
D
44. CI3.44
The solution must have a console to enable users to monitor, analyze and take
corrective action from a centralized point. It should also seamlessly integrate
with integrated service management portal for single view
E
45. CI3.45
The solution must support real-time reporting and historical archive store for
performance information. DBAs should be able to drill down through layers of
data to discover the cause of a condition occurring with the databases, or
operating system. These historical reports must also be usable to perform
trend analysis and capacity planning.
E
Management System for Web based Portals and Applications:
46. CI3.46
The solution must determine if the root cause of performance issues is inside
the monitored application, in connected back-end systems or at the network
layer from a single console view
E
47. CI3.47
The solution must proactively monitor real user transactions; detect failed
transactions; gather evidence necessary for triage and diagnosis of problems
that affect user experiences and prevent completion of critical business
processes
E
48. CI3.48
The solution must provide deeper end-to-end transaction visibility by
monitoring at a transactional level.
E
49. CI3.49
The solution should measure the end users' experiences based on transactions
with or without the need to install agents on user desktops.
E
50. CI3.50
The solution should be deployable as a passive listener on the network thus
inducing zero overhead on the network and application layer.
D
51. CI3.51
The system must be able to provide root-cause probability graphs for
performance problems showing the most probable root-cause area within
application infrastructure.
E
52. CI3.52
The solution must provide a single unified view that shows entire end-to-end
real user transaction and breaks down times spent within the application
components, SQL statements, backend systems and external 3rd party systems
for quick trouble shooting.
E
53. CI3.53
The solution must be able to provide graphs and charts for performance
problems highlighting most probable root-cause areas within monitored
application infrastructure.
D
54. CI3.54
The system must be able to provide the ability to create user groups based on
application criteria or location and link user ids to user names and user groups.
E
55. CI3.55
The system must provide the capability to mask critical / confidential data
from the monitored transactions.
D
56. CI3.56
The system must be able to track the HTTP or HTTPS sessions used by a
particular user, so one can see how many sessions there are, and, when a
session is experiencing performance or availability problems, assess the impact
and address any issues for a particular user
E
57. CI3.57 The solution must support all common Java & .NET framework versions. D
58. CI3.58
The solution must provide a real-time application topology map to triage and
quickly pinpoint the component causing a performance bottleneck in the end-
to-end transaction flow.
E
59. CI3.59
The solution must gather available performance indicator metrics from all
within real-time production environments and real user transactions 24x7 with
minimal overhead on monitored applications without sampling.
E
60. CI3.60
The solution must be able to detect production Memory Leaks from
mishandled Java Collections and Sets and isolate exact component creating
leaking Collection or Set (or .NET Memory Leaks within the CLR).
E
61. CI3.61
The system must be able to detect user impacting defects and anomalies and
reports them in real-time:
Slow Response Time
Fast Response Time
Low throughput
Partial Response
Missing component within transaction
E
62. CI3.62 The solution must allow monitoring granularity for all transactions. D
63. CI3.63
The solution must provide real-time monitoring of resource utilization like JVM
memory usage, Servlets, EJB pools, DB connection pools and Threads.
D
64. CI3.64
The solution must be able to identify socket and file Input / Output activity
from the application.
E
65. CI3.65
As a means of detecting poorly performing SQL, the solution must be able to
proactively record all SQL calls, and report on the slow performing ones. The
SQL measurements must be made from within the monitored application not
using an external database agent.
D
66. CI3.66
The solution must monitor performance of all stored procedures being
executed from within the Java/.NET application.
E
67. CI3.67
The system must be able to provide the ability to detect and alert when users
experience HTTP error codes such as 404 errors or errors coming from the web
application.
E
68. CI3.68
The solution should have provision for automatic discovery of business critical
transactions by setting up bounding conditions to describe transactions.
E
69. CI3.69
The solution must provide ability to monitor performance of applications up to
the method level of execution (Java/.Net method) 24x7 in production
environments with negligible impact on monitored application.
E
70. CI3.70
The solution must be able to report on any application errors occurred while
executing application functionalities and pinpoint exact place of error within
transaction call stack.
E
71. CI3.71
The solution must provide levels of thresholds which can be set on alerts and
provide for actions so that alerts can automatically trigger other processes
when thresholds are breached. The proposed solution must not necessitate
any changes to application source code.
E
72. CI3.72
The solution must proactively identify any thread usage problems within
applications and identify stalled (stuck) threads.
E
Integration with Service Management Portal
73. CI3.73
The Service Management System must integrate with the NMS (in addition to
proposed EMS) to collect network related information (alarms, assets, events
etc.) into the central system
E
Integration with Service Desk
74. CI3.74
The Service Level Management System should provide the capability to
calculate and report on network specific SLAs
E
75. CI3.75
The proposed system must completely and seamlessly integrate with the
helpdesk ticketing system. A single integrated helpdesk system with a unified
Configuration management database (CMDB) needs to be created. The
helpdesk system must be able to integrate with the proposed system / DB /
application management tools via event management engine so as to
automatically generate trouble tickets in case of any critical alerts
E
76. CI3.76
The system should provide Asset Management tool which should provide
multiple integration methodologies to assimilate the data supplied from
various management sources. It should integrate with Helpdesk system so as
to provide asset information while opening the Ticket
E
77. CI3.77
The NMS system proposed by NI must also be integrated with helpdesk system
directly or via event management layer to create automatic trouble tickets for
any critical network failures affecting the service delivery infrastructure.
E
78. CI3.78 The Service Level Management must be integrated with the helpdesk. E
79. CI3.79
The proposed management and helpdesk solution must work together to
create an integrated CMDB for better configuration management & change
management process. The proposed end-to-end solution must have a single
central management dashboard for viewing the critical business-centric KPIs in
graph & chart formats
E
8.4.8.2 Service Desk
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

Service Management Portal
1. CI4.1
The solution must provide insight across the IT infrastructure based on a
complete integrated view of each IT service. The solution must provide the
ability to model and monitor business and IT services and represents the
health of various business critical services based on the supporting
E
infrastructure.
2. CI4.2
The system must provide integration with proposed monitoring systems for
physical and virtual servers, databases and applications as well as with service
management systems like CMDB and helpdesk solution.
E
3. CI4.3
The solution must have out-of-the- box integration with network / system
managers & CMDBs and support integration with new data sources, including
event normalization and enrichment
E
4. CI4.4
The system must collect information from other proposed tools to give a
better understanding about how infrastructure and applications comprise
specific IT services, and how infrastructure is impacting the transactions
associated with relevant applications thereby impacting service quality.
E
5. CI4.5
The solution should support role-based service dashboards and service
consoles for management, staff, operations and stakeholders along with
historical reports.
E
6. CI4.6
The system must provide a simple and easy-to-use methodology to build
logical service models to relate all IT components of a service (systems,
databases, applications and transaction). The solution must also enable the
definition and creation of end-to-end, real-time business service models
quickly and efficiently without programming knowledge.
E
7. CI4.7
The solution must have the ability to understand how the infrastructure
impacts critical services, and quickly identify root cause for any services outage
or performance degradation.
E
8. CI4.8
The solution must provide service visualization capabilities including service
management dashboard and topology based views for displaying service
relationships.
E

The solution must provide role-based user access to provide proper service
information to the correct people in ensuring the data is analyzed properly. The
solution must be configured to provide the following :

9. CI4.10
Dashboard views for business and IT owners to understand how the services
are performing as a whole.
E
10. CI4.11
Service topologies for high level IT staff to understand how different service
and infrastructure components relate to each other.
E
11. CI4.12
Capabilities for reporting on services levels, service availability, performance
and health are required
E
12. CI4.13
The solution must provide real-time proactive visibility into how well critical
business services are delivered to end-users based on integrated analysis of
user experience, application transactions and the underlying infrastructure.
E
13. CI4.14
This solution must display the quality, risk, SLA compliance and other
important parameters of critical business services, enabling quick resolution of
E
problems impacting service quality.
14. CI4.15
The solution must integrate and analyze data from other management tools
proposed including application performance management tools for metrics on
real-time and simulated user experience & business transaction behaviour and
infrastructure management tools.
E
15. CI4.16
The solution must provide a layer of intelligence to be able to integrate,
normalize and reconcile information from heterogeneous tools through a
common integration platform based on a real-time integrated service
management model and operational management database (CMDB).
E
16. CI4.17
The solution must create a single central instance of the discovered IT
environment for accurate business service modelling and impact analysis as
well as provide a common view of all critical business service status
information to the stakeholders across the organization and in a format
suitable for their roles.
D

Service Level Management System: The solution must include a comprehensive and
integrated service delivery management to carry out SLA Management, Reporting &
Monitoring. The proposed system must enable building of reusable elements for defining
standard service offerings and for use in building SLAs in the system. The framework
must provide industry standard definitions for:

17. CI4.18 Services - what organization offers (IT systems, Apps, Business Processes) E
18. CI4.19
Service Metrics - define the way the service is measured, based on ITIL v3
standards
E
19. CI4.20
E.g. Availability-% Time Available, Performance-Latency, Performance-%
Packet Delivery, Incident Mgt-Avg. Response Time, etc
E
20. CI4.21
Specific service level metrics Ability to define specific key performance
indicators
D
21. CI4.22
The Service Level Management system should have out-of-the-box integration
with other processes like Request Management, Incident Management,
Problem Management and Change Management.
E
22. CI4.23
The system is expected to provide the ability to define a catalogue of specific
key performance indicators or service level metrics, defining exactly what each
metric means - both the definition and attributes within the systems
framework as well as the business logic to calculate.
E
23. CI4.24
The system must support and contain best practice libraries of industry
standard services/metrics aligned with ITIL v3 standards and allow using these
as a starting point.
E
24. CI4.25
The system must support groupings of predefined KPIs for a service or group of
services as templates.
D
25. CI4.26
The system must provide the ability to configure and manage a list of
templates preconfigured with best practice Service Level Objectives.
E
26. CI4.27
The system must facilitate a new contract/SLA to be quickly deployed based
upon one/several of these templates and the attributes for the specific metrics
changed as necessary (for example, target, time threshold, Incident severity
level) without requiring any specific programming skills.
E
27. CI4.28
The SLA management system must provide the ability to group Services in
many waysfor reporting purposes.
E
28. CI4.29
Solution shall provide an easy-to-use GUI to create a library of weekly and
yearly calendars: Business hours, Peak hours, maintenance windows, holidays,
etc.
E
29. CI4.30
The system must support service life-cycle with status, version and audit trail
control.
E
30. CI4.31
The system must enable defining a set of mandatory items as part of any
contract creation process automatically in order to enforce validation and
drive standardization.
D
31. CI4.32
The solution should provide capability to define a catalogue of reusable
calculation/business logic engines on how to calculate the various Service
Level metrics that can be used. Business logic has to be reusable (define once,
use multiple times) and changing the business logic / calculations should allow
the changes to propagate to any Service Level Obligation (SLO) / Service Level
Agreement (SLA) that uses it.
E
32. CI4.33
Solution should be able to provide a common repository for all agreements
across organization, whether they are SLAs, internal SLAs/ Operational Level
Agreements (OLAs), or vendor underpinning contracts.
E
33. CI4.34
Solution shall manage the SLA state in the life cycle (e.g. draft, current, etc.)
and be able to support start / end dates (i.e. the SLA start date and end dates)
as well as periodical revisions to the SLA (i.e. new targets, new metrics).
Furthermore the system shall track all changes made and allow users to go
back to a previous version of a SLA.
E
34. CI4.35
Authorized users shall be able to customize each element of an SLA, setting
different targets, thresholds/escalation scheme, time period coverage,
penalties, etc
E
35. CI4.36
Solution shall offer easy interfaces to handle the calculating of dependent
service level indicators. End to End Transaction data and operational
availability measurements must be used to calculate the End-to-End Service
Delivery indicator. Solution should be able to link metrics dependent or related
to one another
E
36. CI4.37
Solution shall be able to manage different kinds of process oriented Service
E
Level Objectives
37. CI4.38
Solution shall be able to manage specific quality analysis metrics such as,
Latency, Packet Drop Ratio, etc.
D
38. CI4.39
The system must enable manage and report on Metrics including, but not
limited to:
By Service/ Product/ Process
Areas of measurement (e.g. Availability, Performance, Incident
Management)
Geographic Location
D
39. CI4.40
Solution shall be able to support the easy creation & management of multiple
SLAs and be able to view and report on them from individual SLA perspective,
as well as performance rolled up for the overall organization.
E
40. CI4.41
Solution should support specifying different measurement targets for different
time periods (for example, higher availability is required during peak hours)
E
41. CI4.42
Solution should provide the capability to link addresses from within the
Contract or Service catalogue a link to external or internal sources (documents,
files, web pages etc.).
E
42. CI4.43
Solution should be able to support scheduled and un-scheduled maintenance
windows for an SLA and consider those when reporting performance and
calculating service credit/debit
E
43. CI4.44
Solution should provide the Ability to Create Multiple levels of Threshold
settings
D
44. CI4.45
Solution shall provide the ability to easily create & deliver warning
notifications and alerts, built around multiple levels of thresholds and the SLA
target for each SLO/SLI, i.e. upon occurrence of a SLA / SLO threshold
exception, an action shall be triggered (notification, highlight etc.)
E
45. CI4.46
The solution should have the ability of system to automatically generate
results of penalties / bonuses on specified basis.
D
46. CI4.47
From the SLA & agreed upon metrics stored in the SLA Management module,
an authorized user should be able to generate a printable version of the SLA
in a standard format, like MS Word. Contents of the printable version should
be configurable. Support for several export templates should be available.
E
47. CI4.48
Solution should provide the ability to add exceptions (like excluded time
periods) to contracts both before committing SLA and while effective. For
example, after SLA is in effect an Exceptional downtime occurs and it is
agreed upon/negotiated with the bidder. An exception to the specified
tracking period must be allowed to be added (preferably through a simple GUI)
that will cause the system to exclude a particular set of data/events that
occurred during that time period. The system must automatically take this into
E
account when doing the service level reporting, without a user is having to
manually re-do metric formulas/calculations.
48. CI4.49
The proposed solution must also provide an audit trail to be maintained in the
system on who has added & when that exception was added.
E
Solution shall provide the means to perform searches for:
49. CI4.50
SLA contracts according to all SLA parameters: e.g. Supplier, customer, service,
revenues, geography;
E
50. CI4.51
SLA failures (or conformances) according to all SLA parameters: e.g. Supplier,
customer, service, revenues, geography
E
51. CI4.52
Authorized users should able to create ad-hoc reports without the need for
specialized knowledge. The system shall also provide the ability for users to
create personal reports that only they have access to, as well as reports that
are shared (accessible by multiple users).
E
52. CI4.53
The solution should be able to automatically produce scheduled pre-defined
SLA performance reports and distribute them, when required through email.
The solution should also be capable of exporting reports and/or the underlying
data, to the following formats such as, MS Excel, PDF, HTML, CSV
E
53. CI4.54
The system shall provide the ability to point and click on any graphically
represented service level value in a chart and drill down to the next level of
information making up that result.
E
54. CI4.55
A performance dashboard integrated with the SLA Management module shall
be available within the SLM tool, by utilizing icons and colour coding for quick
identification for warnings, severity levels.
E
55. CI4.56
The system must enable an end-to-end graphical overview based on the
contract definition for immediate understanding of Contract and Service
relations (relationship of Underpinning Contracts, OLA and SLAs). The graphical
overview must also provide and display Contracts, Services, Obligations and
technical items with the appropriate relationships and dependencies in order
to quickly understand complex contracts and service relations within the
service delivery chain.
E
56. CI4.57
The dashboard should support a view showing all the Services, their status as
related to all the SLA commitments and what contract parties are being
impacted by below-level performance.
E
57. CI4.58
An Incident or Trouble-ticket, related to a specific Configuration Item, which is
created manually or automatically by integration of the monitoring systems
with the helpdesk, should be automatically associated with the related Service
Level Agreement.
D
58. CI4.59
The Service desk, which includes the SLA management system and CMDB,
should be capable of integration with third party monitoring tools.
E
59. CI4.60
Collection of data must be close to real time for metrics such as availability &
response time and collected in batch mode for operational data such as from
Help Desk.
E
60. CI4.61
Solution shall be able to manage the following types of SLAs: Helpdesk, Data,
Applications, Web services, Voice, Wireless, LAN, WAN, Security, Storage,
Systems/servers
E
Helpdesk and Ticketing System (including CMDB and Asset Management)
61. CI4.62
The system must be ITIL-v3 based and provide support for various defined ITIL
processes
E
62. CI4.63
The solution must provide flexibility of logging, viewing, updating and closing
incident manually via web interface.
E
63. CI4.64 The web interface console would also offer access to knowledge database. E
64. CI4.65
The solution must provide classification to differentiate the incident via
multiple levels/tiers of categorization, priority levels, severity levels and impact
levels.
E
65. CI4.66
The solution must be able to provide flexibility of incident assignment based
on the best practices as defined in ITILv3.
D
66. CI4.67
Each escalation policy must allow easy definition on multiple escalation levels
and notification to different personnel
E
67. CI4.68
The escalation policy would allow flexibility of associating with different
criteria like device/asset/system, category of incident, priority level,
organization and contact.
E
68. CI4.69
The solution must provide web-based knowledge database to store useful
history incident resolution.
E
69. CI4.70
The knowledge management system must be compliant with KCS (Knowledge
Centred Support) which define best practices for knowledge management.
D
70. CI4.71
The knowledge management system must have a natural language search
engine that is capable of automatically relating the appropriate knowledge
article with the Incident / Problem description.
D
71. CI4.72
The solution must contain built-in knowledge tools system that can provide
grouping access on different security knowledge articles for different group of
users.
E
72. CI4.73
The solution must provide seamless integration to log incident/problem
automatically through integration with other proposed tools such as EMS
event management, server management, database management, network
management system
E
73. CI4.74 The solution must be able to log and escalate user interactions and requests. E
74. CI4.75
The solution must provide status of registered calls to end-users over email
and through web.
E
75. CI4.76
The solution must have an updateable knowledge base for technical analysis
and further help end-users to search solutions for previously solved issues.
E
76. CI4.77
The knowledge management system should be capable of automatically rating
the knowledge articles based on usage and also automatically deleting
knowledge articles that have not been used for a specified period of time
based on policy.
D
77. CI4.78
The solution must have the ability to track work history of calls to facilitate
troubleshooting.
E
78. CI4.79
The solution must support tracking of SLA (service level agreements) for call
requests within the help desk through service types.
E
79. CI4.80
The solution must support request management, problem management,
configuration management and change requests management.
E
80. CI4.81
The solution must be capable of assigning call requests to technical staff
manually as well as automatically based on predefined rules, and should
support notification and escalation over email, web etc.
E
81. CI4.82
The solution must have an integrated CMDB for better configuration
management & change management process. The solution must have a top
management dashboard for viewing the helpdesk KPI in graph & chart formats.
E
82. CI4.83
The solution must support remote management for end-user & allow analysts
to do the desktop sharing for any system located anywhere, just connected to
internet.
E
83. CI4.84
The Change Management system should have out-of-the-box integration with
Incident Management, Problem Management and Service Level Management.
E
84. CI4.85
It should be possible to define sequential as well as parallel tasks in the Change
Management workflows.
D
85. CI4.86 The system should provide a graphical view of the different workflows. D
86. CI4.87
The proposed asset management solution should provide the features
specified below:
a. Asset tracking Vendor details
b. Maintenance and repair information
c. Purchasing and contracts information (purchases, leases, warranties
and so on)
d. System location, and user or owner contact information.
E
87. CI4.88
The asset management for IT solution should include mature work
management processes and support for proactive work activities. It should
provide built-in report designers and viewers, as well as role-based dash-
E
boards, that can help to view information that can be acted on in ways that are
meaningful to IT and business staff.
88. CI4.89
The asset management solution must support automated asset life-cycle
management. It must provide management of assets from requisitioning,
through delivery, installation and configuration, servicing and maintenance
over the life of the asset, to finally decommissioning and returning or disposing
of the asset.
E
89. CI4.90
Asset management solution should combine maintenance, procurement and
contract management for IT assets into one easy-to-use Web interface.
D
90. CI4.91
Asset management solution should provide means to automatically track and
efficiently manage the complete life cycle of assets. This asset lifecycle
functionality should permit the tracking and management of IT assets through
initial request, approval, procurement, contract, receipt, deployment, asset
installs, moves, adds, changes (IMACs), and retirement.
E
91. CI4.92
Asset management solution should control procurement and maintenance
agreement costs. It should provide thorough and accurate asset tracking that
helps in making key business decisions effectively, redeploy assets where
needed and avoid over-provisioning.
E
92. CI4.93
Asset management solution should follow standards-based approach and
should provide the capability to integrate with key financial and HR systems, as
well as automated asset discovery applications.
E
93. CI4.94
Proposed solution should facilitate IT operations staff to use asset
management to proactively plan IT needs. The software should help plan,
review and report on work, resources and costs associated with implementing
IT infrastructure changes. Plus, it should notify support staff about changes
and schedule rollouts.
E
94. CI4.95
Asset management solution should provide capability to manage IT spare parts
inventory which is an important part of maintaining any asset. The Inventory
module should tracks materials needed for maintenance. It should keep track
of items in stock, indicates when stock falls below user-defined reorder points,
creates purchase requisitions and purchase orders to restock needed items,
and reports items received.
E
95. CI4.96
Asset management solution should provide capabilities to manage preventive
maintenance (PM) work that needs to be done on regular schedule in order to
keep assets running efficiently. The applications in the Preventive
Maintenance module should help to plan and budget for regular maintenance
work by planning the labor, material, service, and tool needs of your regularly
scheduled maintenance and inspection work orders.
E
96. CI4.97
Asset management solution should provide software license management so
as to track your software license entitlements and compare those entitlements
E
to deployed inventory.
97. CI4.98
Asset management solution should provide the facility of reconciliation to
match deployed hardware and software data to procurement and asset or
materials management data. It should also facilitate in establishing the basis
for reconciliation.
E
8.4.8.3 Email Solution

#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

Mail & Messaging solution should have the following features
1. CI1.1 Should provide support for LDAP V3 Directory access E
2. CI1.2
The mail messaging software must have integration with proposed Directory
solution
E
3. CI1.3 Should provide support for digital signatures. D
4. CI1.4
Should provide support for simple, flexible administration using a Web
browser or any other management console.
E
5. CI1.5 Should support tools for message tracking and monitoring management. E
6. CI1.6
Should support for clustering and automatic fail over and load balancing
services.
E
7. CI1.7 Should provide support for POP, IMAP4, SMTP and Web based Access. E
8. CI1.8 It should support SSL encryption with 128/ 168 bit keys. E
9. CI1.9 Should provide for Simplified Server Monitoring. D
10. CI1.10
Should provide easy creation of new database usage, activity, replication, and
ACL monitors.
E
11. CI1.11 X.509 V3 support - that provides a standard for all digital certificates. E
12. CI1.12 Periodic or per-message notification when the quota is exceeded. E
13. CI1.13 Support for automation of administration tasks through GUI or scripting D
14. CI1.14
Should be capable of implementing Private Blacklist, Private White lists and
DNS White lists.
E
15. CI1.15 Should support S-MIME browser access of email. E
16. CI1.16 Should be capable of providing policy based administration controls. E
17. CI1.17 Should provide for horizontal and vertical scalability. D
18. CI1.18
Should provide reporting features to monitor Statistics and Events on the
servers.
E
19. CI1.19
Should be complied to enforce government compliance & regulation
requirements.
E
20. CI1.20
Should be able to provide archiving & message indexing/ journaling
capabilities
E
21. CI1.21
Should be able to provide customizable message classification depending on
type of messages
E
22. CI1.22
Should be able to provide end to end encryption with a minimum of 128 bit
key encryption.
E
23. CI1.23
Should have capability to enforce email retention settings on users so emails
can be retained/archived/deleted as per state policies.
E
24. CI1.24 Should support feature for Sent messages to be recalled by the sender. E
25. CI1.25
Should support TLS encryption between different messaging server roles to
help ensure that all the messaging data transferred between messaging
servers is encrypted.
E
26. CI1.26
Should support browser based email access with features including
schedulable separate out-of-office messages for internal and external users,
S/MIME support, Really Simple Syndication (RSS) subscriptions etc.
E
27. CI1.27
Should have capability to provide visual guidance on the best dates and times
for meeting, based on the schedules of invitees and resources.
E
28. CI1.28
Should support Multi-Mailbox Search Administrators should be able to
perform fast, full-text search across all mailboxes if required for legal or other
purposes.
E
29. CI1.29 Unified Messaging Support: E
30.
CI1.29.
1
Messaging System should support following Unified Communication
capabilities.
E
31.
CI1.29.
2
IVR Capabilities to access email, voice mails, calendar and contacts by ordinary
phone.
D
32.
CI1.29.
3
Emails, Voice Mails and Fax redirected to Inbox. E
33.
CI1.29.
4
Speech Enabled Auto-attendant. D
34.
CI1.29.
5
Should support integration with IP or non-IP PBXs. D
35.
CI1.29.
6
Notification when a caller leaves a voice message D
36.
CI1.29.
7
Secure Real-time transport protocol should be supported E
37.
CI1.29.
9
Quality of service (QoS) should be supported by using differentiated service E
38. CI1.30 Should provide core anti-spam capability out-of-box E
39. CI1.31
Should support integrated Mobile Messaging without any third party plug-ins
of software with following features:
E
40.
CI1.31.
1
Should provide with Up-to-date notifications synchronization with Pocket PC ,
Nokia & Symbian & based smart phones (Push Based Mobile Messaging) with
no third party middleware services
E
41.
CI1.31.
2
Should provide integrated Support for HTML Messages - Rich HTML mail for
mobile devices is supported. Replying to an e-mail should preserve the HTML
formatting for all other users in the thread
E
42.
CI1.31.
3
Should support enforcement of security policies on Mobile devices. E
43.
CI1.31.
4
Should support remote wipe out of Mobile Devices by central administrator E
44.
CI1.31.
5
Should Support remote wipe on Mobile Devices.
D
E
45. CI1.32
The solution should provide in built journaling, which can be enabled internally
or externally or user based. Journal messages could be archived with-in server
or taken off to another system
E
46. CI1.33
Should provide MRM (Message Record Lifecycle Management) for email
retention and expiration using organization policy.
E
Instant Messaging (IM) solution should have the following features but not limited to:
47. CI1.34
The ability for authorized users to send and receive instant messages (IM) to
other authorized users.
E
48. CI1.35
Should support the industry-standard protocols Session Initiation Protocol
(SIP) and SIP for Instant Messaging and Presence Leveraging Extensions
(SIMPLE)
E
49. CI1.36
Messages can be sent to a single individual user or to a group of users. Groups
of users can be created dynamically by adding users to an existing IM session,
or can be defined in advance as a list or group. Use of existing group
definitions, such as in directory service
E
50. CI1.37 Should support integration with centralized directory services E
51. CI1.38
Ability for logging and archiving of the communications in all IM sessions for
records management or regulatory compliance. Logging of IM sessions for only
specific pre-identified users.
E
52. CI1.39
Ability for visual and audible alerts to the intended recipient upon arrival of an
IM message. Mode(s) of alerts under user control.
D
53. CI1.40
Should provide Instant Messaging & Presence capabilities through a browser
based interface
E
54. CI1.41 Support for instant messaging and presence capability from mobile device E
55. CI1.42
Solution should have capability to protect against unsolicited instant messages
(SPIM filters)
D
56. CI1.43
Should support seamless access to remote users without the need for Virtual
Private Networking (VPN)
E
57. CI1.44
Should support the Users to send and receive files from within IM
conversations
D
58. CI1.45 Should support the Users to use a Tablet PC D
8.4.8.4 Directory Services

#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.
Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

1. CI2.1 Centralized authentication and authorization mechanisms for users E
2. CI2.2
Directory Services solution for all DoP Departmental/Post/Mail offices and
other third part resources for user authentication and access rights
E
3. CI2.3 Should support high-availability E
4. CI2.4 Should be LDAP v3 Compliant E
5. CI2.5 Support for open standards e.g. XML E
6. CI2.6
Should be able to replicate data between servers and support cascading
replication
E
7. CI2.7 Support for Group policies and software restriction policies E
8. CI2.8
Support settings to configure various desktop or user related settings via
centralized control like Browser setting, desktop restrictions, program
restrictions, admin controls, software deployment etc.
E
9. CI2.9 Feasibility for all manual functions to be automated using group policies. D
10. CI2.10
Support for integrated authentication mechanism across operating system,
messaging services.
E
11. CI2.11 Out of the box integration with the mail and messaging solution D
12. CI2.12
Enhanced authentication mechanism which supports authentication across
multiple Operating systems like Windows and Unix/Linux.
E
13. CI2.13 Ability to integrate with other Standards based Directory system for E
synchronizing user accounts and passwords.
14. CI2.14 Support for Access Control Lists (ACLs). E
15. CI2.15
Should have capability of implementing restrictions over accessing the
directory data at different levels
E
16. CI2.16
Should support multi factor authentication; Support for user authentication
through user ID/password, X.509v3 public-key certificates, or Anonymous
authentication
E
17. CI2.17
Support security features for smart cards, public key infrastructure (PKI), and
x.509 certificates
E
18. CI2.18
Should have simple and flexible administration using GUI or web browser to
perform administration tasks
E
19. CI2.19
Provision of APIs to programmatically manage each component of Directory
Service.
D
20. CI2.20
Support for modifiable and extensible schema both manually and
programmatically
E
8.5 RFP Timelines
Figure 16: Timelines of various RFPs

Core SI RFP Volume I

Uploaded by

Copyright:

Available Formats

Core SI RFP Volume I

Uploaded by

Document Information

Original Description:

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

Core SI RFP Volume I

Uploaded by

Copyright:

Available Formats

Request For Proposal

Request For Proposal (RFP) for Core System

You might also like