1 of 14

Programme

SUJOG-Feacal Sludge & Septage Management (FSSM)

The Government of Odisha (GoO) has initiated a programme called "SUJOG - Sustainable Urban Services in a Jiffy by Odisha Government" through the Housing and Urban Development Department (H&UDD). The primary objective of this programme is to implement e-governance services across the Urban Local Bodies (ULBs) in the state. Its aim is to ensure that urban services are delivered to citizens in a seamless, transparent, and trackable manner. The programme has successfully been implemented in 115 ULBs in Odisha, and citizens can access these services through the DIGIT platform.

Facilitating effective sanitation management, the DIGIT Sanitation platform is currently live in 70 ULBs in Odisha. This platform specifically focuses on managing Feacal Sludge Management (FSM) in these areas. The programme aims to bring a paradigm shift in the way urban governance happens in the state by way of digitalisation. Its beneficiaries include citizens, the ULB administration, various government departments, and several other actors involved in the service delivery value chain.

One of the leading states in the domain of urban Feacal Sludge and Septage Management (FSSM), Odisha has already demonstrated effective city-wide FSSM systems in several ULBs with the commissioning of 108 FSTPs across 107 cities by September 2022, with further scale-up across all 115 ULBs underway. To ensure the continued and efficient delivery of FSSM services to all its citizens, the state has partnered with eGov Foundation (eGov) to roll out a Digital FSSM platform for managing the ULB-level operations and monitoring the performance of the FSSM service delivery.

The SUJOG-FSSM platform was successfully piloted in the three ULBs of Berhampur, Balasore, and Dhenkanal in December 2021. After successfully demonstrating three pilot ULBs, the programme has been approved by the HUDD (vide Letter No. 8951, and dated 20.05.2022), and communicated to all the ULBs and the other stakeholders involved in the rollout. Subsequently, the platform has been scaled up to cover 70 ULBs in Phase-1 and Phase-2. The platform will be further scaled up across all the 115 ULBs of Odisha, covering 119 Faecal Sludge Treatment Plants (FSTPs) to bring efficiency, transparency, and speed in the delivery of faecal sludge management services to the citizens through an online interface.

The Pilot

The pilot journey of SUJOG FSSM in Odisha across three ULBs can broadly be categorised into two phases - a phase before and March 2022. During the first phase, the prime focus was on training the end users online and driving citizen adoption through IEC campaigns. However, after three months of consistent efforts, multiple factors hindering the change management on ground surfaced. During the meeting held towards the end of February with HUDD and the key stakeholders involved in implementation, it was decided to investigate the reasons for low adoption rates across ULBs, and put in dedicated efforts towards enhancing the same.

Multiple field visits were conducted by various team members from the SUJOG FSSM implementation unit and following actions were taken towards enhancing the adoption:

Infrastructure procurement: One of the key gaps observed was the lack of connectivity for various users, especially the ones at FSTP. Following this observation, government orders were issued by the special secretary for the procurement of infrastructure. A constant monitoring mechanism with commissioners/EOs and the special secretary led to a quick infrastructure procurement across all three FSTPs & ULB offices .
In-person refresher training across all ULBs: One learning was that online training was not as effective as in-person, especially with the users in the FSM value chain. There was a spike in the number of requests being logged in the system by the employees as soon as the in-person refresher trainings were conducted across the 3 ULBs.
Daily adoption monitoring helped enhance the ownership among various users. This also helped establish a stronger support system for the quick resolution of issues.
The team identified the product enhancements that needed to be implemented to further improve the adoption. Two major enhancements that happened as a result are the option for recording the payment post the service, and multi-trip capabilities for each request.
Following the above efforts and enhancements, adoption across pilot ULBs has improved drastically. The number of requests before March 2022 (since December 2021) stood at 237 for all three pilot ULBs. The requests between March 2022 and May 2022 were nearly five times higher at 1,167. Given the significant improvement in adoption, a letter was issued to prepare the ULBs for a phased implementation of a statewide rollout of SUJOG FSSM in May 2022.

Phase 1 roll-out:

Preparations for the phase 1 rollout emerged from the learnings the implementation team had during the pilot phase. Phase 1 ULBs were selected following multiple discussions with the state officials & TSU. Following steps ensured the sustained adoption of the application across all ULBs:

Infrastructure readiness: Infrastructure assessment was conducted across all these ULBs before the data collection process. Letters were issued to expedite the infrastructure procurement, and ensure all the ULBs and FSTPs were equipped sufficiently for recording the requests and closing them on a real-time basis.

Involving DUDA officials in configuration: Data collection for configuring the application happened through DUDA officials, who were responsible for data collection and verification in their respective districts. This ensured that the data collection process was quicker and error-proof.

Partnership with OWA for training: Train-the-trainer approach was taken for ensuring successful knowledge transfer to all the potential end users of the application. OWA master trainers were trained to conduct the training sessions with the end users. This smoothened the interactions between trainers and trainees as all the master trainers were well versed with the users skillset and also training in the state language, Odia.

Extensive training sessions were conducted over a span of three days to ensure successful knowledge transfer to over 100+ end-users across 37 ULBs. Interactive sessions by the master trainers helped the end-users understand the steps quickly and start using the application themselves. All the trainees were able to demonstrate the application's usage by the end of the training session. This eased the efforts towards driving adoption among the phase 1 ULBs.

Weekly monitoring of adoption and support for the ULBs: All the state officials involved in the rollout of SUJOG FSSM were part of weekly mentoring sessions. These sessions acted as a channel where the ULBs could discuss insights, ground level challenges, and issues related to the platform and obtain quick resolution. This also ensured sustained adoption. Over 90% of the applications are being recorded on the platform across ULBs, keeping in view the current feature availability on the platform.

Bi-weekly reviews with ULB representatives: The EOs and COs were involved in the bi-weekly calls which were chaired by the additional secretary and engineer-in-chief. The calls revolved mostly around discussing and identifying the gaps in FSM service delivery and SUJOG-FSSM adoption. These calls were also leveraged to discuss policy level changes, identify issues, and challenges from the ULB SPoCs and executives, or TRPs, for immediate action.

Field visits: The eGov team visited 29 ULBs to understand the on-ground situation. The purpose of the visits was to comprehend the FSM value chain and the operational status of FSTPs. The visits were planned and shared with the ULBs, and the team met with FSSM SPocS (sanitation experts/sanitation nodal officers), executives, and EOs/COs during the visits to clarify their viewpoints. All 29 FSTPs were visited, and in-depth discussions with SHG members and technical resource personnel were held. We were able to see things more broadly and understand the gaps that was impeding adoption and service delivery. The state was then informed of the learnings for them to take the necessary action.

Product Features, Roadmap, and Data Captured in SUJOG-FSSM:

The platform enables multiple stakeholders to interact: Citizens, ULB FSSM executives, cesspool operators, and technical resource personnel from FSTPs. This allows a citizen to raise a desludging request by providing minimum information, and a ULB FSSM executive to take action on the raised request or log in request on behalf of a citizen. In the process, citizens are regularly informed of the status of their requests. The role of the technical resource person is to then close all the requests raised once the cesspool operators dispose of the septage in the FSTPs. This ensures the maintenance, monitoring, and tracking of the entire FSM value chain.

Expected Outcomes

The expected outcomes after optimal and efficient usage of the SUJOG-FSSM platform are mentioned below:

Access to quality e-service delivery of FSSM that is consistent and supported by local governance systems at ULBs (and also at FSTPs).
Inclusion of private players within the ambit of the FSSM transformation, besides providing oversight to the ULB administration.
Revenue generated from the FSSM services is captured in the platform. It will help in devising enhanced revenue models for operation and maintenance.
The dashboard must be accessible to all stakeholders, and any warning signs about implementing the FSSM in any geographic area can be promptly and efficiently handled.
The data and details recorded in the platform can be used for an in-depth study of the cities' FSSM effort by focusing on areas that need improvement or improved enforcement.
Greater transparency in the entire value chain, such as real-time tracking of cesspool vehicles (GPS integration), payment systems, etc.
The robust monitoring system in the platform will help city administrators to implement scheduled desludging of septic tanks for all properties and design performance-based contracts for the private DSOs.

Here are the articles in this section:

Functional customisation
Technical customisation
Program rollout plan
Adoption metrics
Implementation plan
Implementation guide
Implementation checklist

Functional Customisation

Sujog-FSM is implemented as a part of SUJOG for the state of Odisha. Odisha is currently on v1.3 of DIGIT Sanitation. The following is the list of changes made to the product for implementation:

1. Localisations:

The localisation changes are done according to the application flow:

2. Additional Builds: Urban-rural convergence is an initiative that aims to ensure access of sanitation services to all gram panchayats (GPs) via urban local bodies (ULBs) located closest to them. With efforts in implementing decentralised waste management across 114 ULBs as well as enabling the rural population to avail sanitation facilities from urban areas located nearby, eGov with CPR (post-field observations and research) decided to include gram panchayats in SUJOG FSSM as part of this initiative. See details of the customisation here.

3. The following MDMS have been configured.

Property-type
Property Sub-type
Slum Names
GP List
Village List
FSTP details

4. The following user categories/roles have been created:

5. FSM Related builds deployed

6. URL and Credentials of SUJOG-UAT environment for reference.

ULB employee URL : https://sujog-dev.odisha.gov.in/employee/user/login

Citizen URL : https://sujog-dev.odisha.gov.in/citizen/user/login

Credentials:

ULB employee Username : EMP-AND-000167

FSTPO Username : EMP-AND-000168

Password : eGov@123

Urban-Rural Convergence

Background

Urban-rural convergence is an initiative that aims to ensure access of sanitation services to all gram panchayats (GPs) via Urban Local Bodies (ULBs) located closest to them. With efforts in implementing decentralised waste management across 114 ULBs as well as enabling the rural population to avail sanitation facilities from urban areas located nearby, eGov with CPR (post-field observations and research) decided to include gram panchayats in the FSM application as part of this initiative.

Introduction

Under the urban-rural convergence (U-RC) GPs are tagged to ULBs which will service desludging requests for households in the respective GPs. The process-flow across the value chain, and actors would remain the same. However, the logic of pricing and billing of requests from GPs may vary from requests within the limits of the ULB itself.

Currently, the factors that are being considered to determine pricing are :

Location of the GP
Distance of the GP from ULB
Distance of GP from the FSTP

Considering these pricing inconsistencies, we are designing and releasing a simple version of the urban-rural convergence system. With the success of a statewide rollout, larger populations and households can have access to and benefit from the FSM module and subsequently the service with speed, and at scale.

Core Value Hypothesis

The users’ needs and the value this feature would provide are as follows:

If we allow households from GPs to raise (or ULBs to record) requests in the FSM application, they will use it responsibly which would result in reduced public dumping with the waste collected and disposed of properly.
If we allow ULB admins to view inputs from GPs in the FSM module on the dashboard, they will use it responsibly and improve the quality of service by making better data-driven decisions.

Solution - Quick Win

Using the above, we have outlined modifications in the FSM module to include gram panchayats:

A field/option to select gram panchayats tagged to a locality from a list to be provided while creating a new desludging application. The amount per trip field will be changed to a free text field instead of an auto-calculated and auto-populated amounts field, and the demand will be generated based on the new amount added.

As the actual amount will be known once the DSO/driver reaches the citizens’ location and sees the property + distance, an option to update the amount per trip is provided where the user updates the trip to start the service.

Risk/Limitations

Addressed in the Out of Scope section.

Out of scope:

The above solution should cover the majority of U-RC use cases, but there are scenarios (edge cases) that deviate from the options. Workarounds for the same are suggested here.

*assumption to be validated post launch.

From our on-ground research and observations, of the 40-60 requests the ULB receives for desludging, 4-7 of them are from GPs. This implies that approximately 10% of the total requests per month are from GPs. The above percentage of occurrence is within that 10%. These use cases will be handled in future versions.

Detailed Solution

While creating a New Desludging Application, a radio button to select gram panchayats is provided. The list of GPs is shown in the dropdown and this field will be based on the Locality selected in the "Location Details" section. The radio button is selected by default on “Within ULB Limits”. By selecting gram panchayat and the name of the gram panchayat from the dropdown, the Amount per trip field (in the Payments Details) section is changed to a free text field. The total and advance are calculated based on the same.

Based on field observations, the actual amount is only known once the vehicle reaches the citizens’ location. Hence, an additional field to edit the amount per trip is provided along with the Update Trips in the pop-up before starting the service. The FSM calculator calculates the total amount and balance based on the same, and the billing service generates the demand accordingly.

Which municipal, business and core services would these changes affect?

Specifications

A new tenant service must be created in the MDMS for gram panchayats. The necessary updates as per the following must be made in fsm-address and fsm-geolocation entity list.

List of entities:

- Locality

- City

- Gram panchayats

Create Desludging Application:

Selecting Gram Panchayat

Payment Details- Advance Amount

Update Trips:

Payment Details- Balance Amount

Success Criteria

The success criteria for U-RC are:

Metrics to track

We will track the metrics below to gather learnings on the impact of these changes on FSM to share it on the FSM dashboards and reports. But more specifically, we will track the metrics to see:

If our hypotheses are correct?
Is the FSM services more accessible(given criteria above)?
What are the unanticipated implications?

Additionally, we must monitor guardrails to ensure there are no major implications on the ULBs’ ability to handle requests (for example, major changes to the volume of requests and difference in SLAs of service between GP and non-GP).

Guardrails

Garima Implementation

Here are the articles in this section:

User Interface Design

Product Requirement Document

User Interface Design

Following are the steps to assign a sanitation worker and vehicle

The DSO/ULB employee can assign a sanitation worker and vehicle in a single screen.

The DSO can assign the vehicle and search for a sanitation worker using the Garima ID. The exact available match is displayed. Note: When we search with the Garima ID, the API will return name and mobile number along with the searched ID.

-Single driver can be assigned.

-Multiple helpers can be assigned.

If the searched worker is not available, an error message "Worker not found! Please register!" is displayed. The DSO can register the sanitation worker by clicking on “Register New Sanitation Worker”. The sanitation worker can either be added as a driver or helper as per requirement

Once the details are filled , the DSO clicks on “Register and Assign”.

The details of the worker should be auto-populated in the previous screen, that is, “Assign Vehicle and Sanitation Worker”.

The sanitation worker is assigned and the details are displayed in the application page.

Product Requirement Document (PRD)

Introduction

Sanitation worker safety is of national importance. The national mandate for the same is issued under the “Emergency Response Sanitation Unit (ERSU)”. The Urban Management Centre (UMC) is leading the implementation of ERSU across Odisha. As part of ERSU, UMC along with the state of Odisha has rolled out a programme on sanitation worker benefits called 'Garima' whose main objective is to identify, monitor, and support sanitation workers and their families.

eGov is collaborating with UMC on “Sanitation worker safety” for Odisha, which includes building the platform and product capabilities for Garima

About UMC

The Urban Management Centre is a non-profit organisation with a mission to “Make Cities Work for Everyone”. Since 1997, it has strengthened the local governance through technical support, policy formulation and implementation, and dedicated capacity building. The UMC works closely with the Government of India, as well as state governments across India. The UMC has institutionalised several key innovations in urban governance across India, including a shift towards service-level benchmarking of urban services, evidence-based planning, and capacity building of government stakeholders.

About Garima

The Housing and Urban Development Department, Odisha, launched the Garima scheme in 2020. The statewide scheme aims to ensure the dignity and welfare of 20,000 core sanitation workers who are exposed to hazardous working conditions, including coming in close contact with faecal sludge in toilets, septic tanks, and sewer treatment facilities.

The scheme highlights that the first step to empower sanitation workers is by recognising them as professionals entitled to safety, benefits, and rights with specific skill-sets and capabilities. To identify the number of sanitation workers, the state has rolled out a robust methodology to create a database of sanitation workers through the generation of unique IDs. The state has been able to create a dynamic database of 15,000-plus informal sanitation workers who can now avail the entitled benefits.

Objective

The objective of the collaboration between eGov and UMC through an integration with Garima is to create a record of service delivery to:

Provide enumeration and benefits to sanitation workers.
Identify the percentage of services with evidence of safe practices.

eGov, through its DIGIT FSM platform - implemented in Odisha - can serve as a data capturing layer for the above and provide access to this information to UMC. The plan is to start with Phase 1. The following will be the scope of work across the partnership:

Scope of Work

The UMC in Odisha has been able to create a unique database of 15,000-plus sanitation workers. This database will serve as a registry integrated with DIGIT FSM, to capture transactional information around data requests served by these workers. This information will further be made available to the UMC. The following will be a part of this:

Provision of ULB/DSO to assign one or more sanitation workers to each request:
1. Sanitation workers will be made available via integration with the Garima database through API in the workflow.
2. Since the Garima ID may not be well known to the ULB/DSO, a search functionality is to be made available via the entry of a phone number.
3. Preview details of the selected sanitation worker for confirmation.
Capture sanitation worker details if a sanitation worker is not available in the Garima database. As per discussions with UMC, details required for the generation of a provisional Garima ID are First name, Last name, DOB, Gender, Mobile number and City details.
Provide aggregated data around how many requests are served by date via unique Garima IDs by API to UMC.
There will be no linking between the Garima worker and vendor done in Sujog FSM.

Detailed Solution

Along with assigning a vehicle, the DSO will assign sanitation workers to a request. The sanitation workers will be assigned by entering the Garima ID. If the Garima ID number exists in the database, details of the sanitation worker, that is, name and Garima ID to be displayed on the screen for the DSO to confirm. In case, the Garima ID does not exist, the DSO will enter sanitation worker details (First Name, Last Name, DOB, Gender, Mobile number). A DSO may assign one to many sanitation workers to a request. However, entering a minimum of one sanitation worker to a request is mandatory.

The following data will be made available from Garima to Sujog via APIs:

Details of sanitation workers registered in Garima (Name, Mobile Number and Garima ID).

The following data will be made available to UMC via APIs:

Aggregated data around how many requests are served by date by unique Garima IDs by API to the UMC.

Workflow with Garima integration:

What changes would affect which municipal, business and core services?

Specifications

Updating Application | DSO in Progress

a. Adding sanitation worker

b. Registering a new sanitation worker

Change in the Backend

Design

Find the mock-ups below:

The DSO/ULB employee can assign a sanitation worker and vehicle in a single screen.

Single driver can be assigned.
Multiple helpers can be assigned.

Once the details are filled , the DSO clicks on “Register and Assign”.

The details of the worker should be auto-populated in the previous screen, that is, “Assign Vehicle and Sanitation Worker”.

The sanitation worker is assigned and the details are displayed in the application page.

Risks/Limitations

There is no way to validate the correctness/uniqueness/verifiability of the Garima database.
For sanitation workers not available in the system, the same details will have to be added multiple times for requests assigned to the workers until they are included in the system.
The collection of information on safety equipment used is based on citizen feedback and may not be accurate or complete.

Out of Scope

The above solution should cover the majority of Garima use cases. However, there are scenarios that deviate from the options:

Technical Customisation

DIGIT UI Implementaton: Guidelines & FAQs

Development Setup

Repo:

Use the dev branch as the base branch for development.

Clone the repo and start using the following steps:

## install

yarn install

## start dev server

yarn start

Adding or modifying modules

Modules are enabled by the MDMS config at.
To add and enable any module in the new UI, src/App.js needs to be changed.
Till PGR, we used to export the module and links were added to the registry. Now, adding to the registry is part of the modules themselves. We export only the init function of the module to take care of all the initialisations. Going forward, these init functions will have to be called. We will create the init function of PGR as well. These init modules must be called after initLibraries.

Changing CS

CSS classes are published over CDN and can be seen at: https://unpkg.com/@egovernments/digit-ui-css/dist/index.css

Any class can be overwritten. Make changes in the src/index.css file.

Customising Fields in a Form

Add any new component created in the registry,

Digit.ComponentRegistryService.setupRegistry({

SelectName: SelectName

});

If API calls are failing, the do the following:

Check src/setupProxy.js for proxy url in dev mode.

If API calls are failing with no authorisation token, then do the following:

Create a .env file with following:

REACT_APP_USER_TYPE=

REACT_APP_CITIZEN_TOKEN=a3e5f0a2-4ff0-4680-855e-75051fb3e8f7

REACT_APP_EMPLOYEE_TOKEN=061bad07-c0d5-4200-a74f-ca5ed090cf30

REACT_APP_GRO_TOKEN=43af4c18-6418-4a35-8484-31f0700f465a

REACT_APP_LME_TOKEN=fa9f4184-dc64-495d-bded-31674c71b09e

FSM UI Implementation: Guidelines & FAQs

Enable FSM

It is done on dev via:

Create a new branch for the state if already doesn’t exist from the master of repo:

To add and enable any module in the new UI, src/App.js needs to be changed.

We only export the init function of the module to take care of all the initialisations:

import { initFSMComponents } from "@egovernments/digit-ui-module-fsm";

const enabledModules = ["FSM"];

initFSMComponents();

Changing CSS

CSS classes are published over CDN and can be seen at: https://unpkg.com/@egovernments/digit-ui-css/dist/index.css

Any class can be overwritten. Make changes in the src/index.css file.

Customising Fields in a Form

Add any new component created in the registry,

Digit.ComponentRegistryService.setupRegistry({

SelectName: SelectName});

The config has different items in the application form. The new config, if made, needs to be initialised at Digit.Customizations.FSM.applicationFormConfig

label: is the employee side label
texts: is used for citizen side step form

- t: translate function to be used to convert a key to localized text. e.g., t("CS_CREATECOMPLAINT_MOHALLA")

- config: current step config as shown above

- onSelect: on clicking of next or input, this handled to be called to save the data in the form state

- userType: employee or citizen

- formData: the current form state

Customising Views

Application details can be customised via defining: Digit.Customizations.FSM.getApplicationDetailsTableRows

The function will be passed following params:

id: application id
service: application response object
role: currently logged in user role CITIZEN or EMPLOYEE
t: function used for translation

Customising Inbox Status Filter

Following customisations are available:

userRole : Role of the logged in user for application of customisation.
statuses : List of statuses that needs to be shown for the specified user.
zeroCheck : Check if the total application count for any status is 0 to hide or rearrange the list.
fixed : Limits the status filter list to the specified list.

Technical Specification: Urban-Rural Convergence

Overview

Initiative to provide access to sanitation services to all gram panchayats (GPs) via urban local bodies (ULBs) located closest to them.

Objective

DIGIT Sanitation plans to provide a provision of sanitation services to rural areas to their nearby cities.

Author

Document History

Approvals

Use Case

As a ULB employee, he/she is creating applications to cater to the sanitation needs of local communities in urban areas. Similarly, he/she should also cater to the same sanitation needs of rural bodies which are close to the urban regions.

ULB employees need a provision in a system while creating a new application whereby they can either choose local municipalities or urban supported villages. Based on their choice, they will be able to select either locality/mohalla or gram panchayat (GP) areas from the respective master data dropdown list. The caveat here is if a ULB employee chooses a GP, then the trip amount field should be editable so that he/she can fill any logical amount based on the offline calculation instead of an auto-calculated amount that is already there in an application in case of urban bodies.

ULB employees or DSO operators should also be able to edit the number of trips. The final amount should be a multiple of the initial amount entered into an application with the number of trips.

Technical Components & Design

Need to update MDMS data: Boundary-data.json
- Need to add a new child hierarchy for GP under city which will be parallel to a locality. A sample is given at the end of this document.
System will use the below URL to fetch the localities or GPs and their corresponding villages.
- In the case of localities, pass boundaryType as “Locality”.
- https://dev.digit.org/egov-location/location/v11/boundarys/_search?hierarchyTypeCode=REVENUE&boundaryType=Locality&tenantId=pb.amritsar
- In the case of GP/villages, pass the boundaryType as “GP”.
- https://dev.digit.org/egov-location/location/v11/boundarys/_search?hierarchyTypeCode=REVENUE&boundaryType=GP&tenantId=pb.amritsar
By default, the 'Urban' option will be pre-selected in the radio button in the above wireframe and the dropdown will have the locality/mohalla master data (existing behaviour). If an employee selects “ULB supported village”, then the locality/mohalla dropdown will be replaced by GPs and the village dropdown data on the fly.
- Also, the "Amount per Trip" field will be editable with no pre-defined calculated value. Hence, the below API will not get called for URC flow (when “ULB supported village” is selected”):

https://dev.digit.org/fsm-calculator/v1/billingSlab/_search?tenantId=pb.amritsar&propertyType=RESIDENTIAL.APARTMENT&capacity=2000&slum=NO&_=1676626310996

Need to add configuration (mdms: UrcConfig.json) for configuring URC feature (Enable/Disable) and facilitating the switch on/off feature for the URC. MDMS data will be as shown below:

{
    "tenantId": "pg.angul",
    "moduleName": "FSM",
    "urcConfig": [{
        "URCEnable": true
    }
    ]
}

The above MDMS have two configurations:
- URCEnable: This flag will be used to enable or disable the URC flow altogether. If this flag is false, then we will not have URC flow (no radio buttons will come) and the existing flow (urban) will happen as it is. If this flag is true, then the radio button will appear. By default, the 'Urban' option will be selected and if the user selects “ULB supported village", then the URC flow will continue as mentioned in above points.
Need to store GP and Village as part of additional details(in eg_fsm_address). Also add one more key as boundarytype in additional details to capture (Locality or GP/Village) to determine if the application created is for RURAL or not so that in the near future it will be helpful for the analytics and statistics in dashboards.
Default value for this key(boundaryType) will be Locality to support backward compatibility
Add Vehicle log would also have the option to select Urban (Default option) or Rural. If Rural gets selected the text name of an element would be replaced from “Locality” to “Gram Panchayat” for a text field.
Introduction of a boundarytype as additionalDetails in vehicle_trip table to capture if the vehicle log is created for GP or not.
- Default value for this column will be Locality to support backward compatibility.

Sample MDMS (boundary-data.json)

{
  "tenantId": "pb.amritsar",
  "moduleName": "egov-location",
  "TenantBoundary": [{
      "hierarchyType": {
        "code": "REVENUE",
        "name": "REVENUE"
      },
      "boundary": {
        "id": 1,
        "boundaryNum": 1,
        "name": "Angul",
        "localname": "Angul",
        "longitude": null,
        "latitude": null,
        "label": "City",
        "code": "od.angul",
        "children": [{
            "id": "2",
            "boundaryNum": 1,
            "name": "Baniabahal",
            "localname": "Baniabahal",
            "longitude": null,
            "latitude": null,
            "label": "Locality",
            "code": "VIL1"
          },
          {
            "id": "3",
            "boundaryNum": 1,
            "name": "Hulurisinga",
            "localname": "Hulurisinga",
            "longitude": null,
            "latitude": null,
            "label": "Locality",
            "code": "VIL2"
          },
          {
            "id": "4",
            "boundaryNum": 1,
            "name": "Angul town",
            "localname": "Angul town",
            "longitude": null,
            "latitude": null,
            "label": "Locality",
            "code": "VIL3"
          },
          {
            "id": "5",
            "boundaryNum": 1,
            "name": "Other",
            "localname": "Other",
            "longitude": null,
            "latitude": null,
            "label": "Locality",
            "code": "VIL4"
          },
          {
            "id": 6,
            "boundaryNum": 1,
            "name": "GP 1",
            "localname": "GP1",
            "longitude": null,
            "latitude": null,
            "label": "GP",
            "code": "GP1",
            "children": [{
                "id": 11,
                "boundaryNum": 1,
                "name": "Village 1",
                "localname": "Village local 1",
                "longitude": 74.871552,
                "latitude": 31.63089,
                "label": "Village",
                "code": "SUN04",
                "pincode": [143001],
                "area": "V-Area1",
                "children": []
              },
              {
                "id": 12,
                "boundaryNum": 1,
                "name": "Village 2",
                "localname": "Village local 2",
                "longitude": null,
                "latitude": null,
                "label": "Village",
                "code": "SUN11",
                "pincode": [143001],
                "area": "V-Area1",
                "children": []
              }
            ]
          },
          {
            "id": 8,
            "boundaryNum": 1,
            "name": "GP 2",
            "localname": "GP2",
            "longitude": null,
            "latitude": null,
            "label": "GP",
            "code": "GP2",
            "children": [{
                "id": 13,
                "boundaryNum": 1,
                "name": "Village 3",
                "localname": "Village local 3",
                "longitude": 74.871552,
                "latitude": 31.63089,
                "label": "Village",
                "code": "SUN04",
                "pincode": [143001],
                "area": "V-Area1",
                "children": []
              },
              {
                "id": 14,
                "boundaryNum": 1,
                "name": "Village 4",
                "localname": "Village local 4",
                "longitude": null,
                "latitude": null,
                "label": "Village",
                "code": "SUN11",
                "pincode": [143001],
                "area": "V-Area1",
                "children": []
              }
            ]
          }
        ]
      }
    },
    {
      "hierarchyType": {
        "code": "ADMIN",
        "name": "ADMIN"
      },
      "boundary": {
        "id": 1,
        "boundaryNum": 1,
        "name": "Angul",
        "localname": "Angul",
        "longitude": null,
        "latitude": null,
        "label": "City",
        "code": "od.angul",
        "children": [{
            "id": "2",
            "boundaryNum": 1,
            "name": "Baniabahal",
            "localname": "Baniabahal",
            "longitude": null,
            "latitude": null,
            "label": "Locality",
            "code": "VIL1"
          },
          {
            "id": "3",
            "boundaryNum": 1,
            "name": "Hulurisinga",
            "localname": "Hulurisinga",
            "longitude": null,
            "latitude": null,
            "label": "Locality",
            "code": "VIL2"
          },
          {
            "id": "4",
            "boundaryNum": 1,
            "name": "Angul town",
            "localname": "Angul town",
            "longitude": null,
            "latitude": null,
            "label": "Locality",
            "code": "VIL3"
          }
        ]
      }
    }
  ]
}

Standard Operating Procedure (SOP)

The programme's scope includes rolling out the DIGIT-based FSSM platform across all the 115 ULBs of Odisha, covering 119 FSTPs, in a phased manner. The choice of the FSTPs within phases will be based on their operational readiness and the availability of TRPs in the state.

The multi-step approach that commences with go-live readiness planning across all ULBs is showcased below:

Infrastructure Checklist for the ULBs and FSTPs

Programme Governance Structure

Training & Capacity Building

Training and capacity building are considered to be an important aspect of this rollout. The Odisha Water Academy (OWA), which has been established as a Centre of Excellence under the Water Corporation of Odisha (WATCO) and the Housing & Urban Development Department (HUDD), Government of Odisha, is playing an important role in ensuring the sustainability of the programme by taking up the training and capacity building responsibilities. The participants from the 33 ULBs of phase-1 have successfully completed the training programme held under the Odisha Water Academy (OWA) at Unnati Bhawan, Bhubaneswar, on September 20th and 21st, 2022.

Empowering the FSSM stakeholders with the knowledge of the platform, the various services that are going to be delivered through it, and its key features and functionalities, are going to be key to driving the adoption of SUJOG-FSSM at all levels of the service delivery chain. With this objective in mind, the multi-tier training structure has been designed.

Multi-tier training structure

It is proposed that the complete training plan and the creation of the training assets will be owned by eGov Foundation, while the master trainers for training the ULB FSSM executives and TRPs will be provided by OWA from its pool of resources with the support of eGov Foundation. These master trainers will be trained by eGov Foundation, and they will further disseminate the knowhow to ULBs, first at a central location, and then physically by visiting each of the ULBs within a cluster for refresher sessions.

eGov to onboard and train the master trainers identified by Odisha Urban Academy.
Master trainers will help in training the ULB employees with support from OWSSB and eGov during the go-live training sessions.
Master trainers will hand-hold the ULB, and collect feedback from them post training.

Training sessions for ULB FSSM executives and technical resource personnel

Nominated participants from the ULBs will be trained by OWA master trainers at a central location, which would be Bhubaneswar. The training will be conducted in two batches.
The master trainers (MTs) will train the ULB-nominated persons (1 nominee from each ULB and 1 technical resource person) to become field trainers in their ULBs. In turn, these field trainers will be responsible for training all the other users, such as ULB operators, FSTP operators, PSSO staff, etc.
After training the field trainers, MTs will be expected to conduct assessments to ensure the effectiveness of these trainers. The MTs will also inform the ULB nominees about the adoption metrics and how to track these metrics on an ongoing basis.
In case the ULBs are not able to send the participants to a central or cluster location, the OWA MTs will need to travel to each of the ULBs to conduct in-person training. All the expenses associated with such travels undertaken by the MTs will be borne by the OWA. MTs will be expected to carry their own laptops.
If the ULB nominees are traveling to a central location, the to and fro travel cost will be borne by the individual ULBs, while the stay and local commute within Bhubaneswar will be borne by the OWA.
If the ULB nominees are traveling to a district/cluster location, all the costs (travel, stay and any other expenses) will be borne by the individual ULBs.
Resource requirements (to be arranged by OWA) for central or cluster location:

Training venue/hall with computers and internet connectivity with a capacity of hosting tentatively 95-100 persons (central location).
Big screen TV.
Projector.
Refreshments and other basic amenities for trainers and trainees.

Roles and responsibilities

Capacity building and adoption post go-live

The process is set up with the ULBs to meet and discuss the challenges, issues and insights from experiencing the platform and field, and to share it across with fellow ULBs. It is conducted at regular intervals with the help of the eGov team and ULB nominated individuals. This call is utilised to resolve issues (L1) from and bridge the knowledge gaps, if any. L2 issues are immediately raised as JIRA tickets and assigned to the impel team for quick resolution. This weekly call for capacity building also acts as a clear communication channel directly with the team for addressing portal, knowledge, and policy level issues.

Adoption Metrics

Change management and review plan

Weekly monitoring and support: All the state officials involved in the rollout of SUJOG-FSSM are part of weekly mentoring/monitoring sessions, which act as a channel for the ULBs to discuss insights, on-ground challenges, and issues related to the platform to obtain quick resolution. This ensures sustained adoption, resulting in over 90% of incoming requests being recorded on the platform across ULBs.

Bi-weekly reviews with ULB representatives: The EOs and COs were involved in the bi-weekly calls, which is chaired by the additional secretary and engineer-in-chief, to discuss and identify gaps in FSSM service delivery and SUJOG-FSSM adoption. Additionally, identified issues, policy change requirements, and challenges facing ULB workers were also highlighted for immediate resolution.

Learnings and Recommendations

Learnings from the pivotal problems

The pivotal problems that were explored during the pilot phase are listed below:

eGov, in partnership with the Government of Odisha, abstracts the challenges and pivotal problems that the SUJOG-FSSM platform will address:

Broken chain of custody from waste generation to safe disposal.
Non-availability of verifiable, trusted data at various levels of aggregation to all actors.
Absence of well-defined standards for sanitation.
Stakeholder behaviour is often misaligned with safe sanitation practices.

Initial gaps in driving adoption

The initial gaps in driving adoption during the pilot phase are mentioned below:

Infrastructure gaps across ULBs.
Lack of regular monitoring and understanding the gaps in usage.
Change in personnel handling the application.
Gaps in refresher training to the ULB personnel.

Actions taken based on the learnings

The actions taken during the pilot phase and before the onset of phase-1 are enlisted in the below sections.

Pilot ULBs

Letters for procuring the infrastructure across all ULBs and FSTPs.
Regular monitoring of daily usage through the adoption tracker.
In-person refresher training across all ULBs.
A strong support system to resolve the issues, if any on a regular basis.

Phase-1 ULBs

Monitoring the infrastructure procurement across all ULBs and FSTPs.
Plan for hands-on-training to ULB SPOCs and employees who are going to use the application.
Adoption monitoring at all levels and a support system to resolve issues, real-time.

Recommendations for process standardisation across the state based on the ongoing engagement and field visit:

For a seamless state-wide scale up and adoption by the ULB employees and citizens, it is important to standardise processes and policies in the service delivery process. Following are the key recommendations for standardisation and steps to be taken to implement the same:

Allocating FSSM executives responsible for taking all desludging requests from the citizens: Within ULB, a single person should be made responsible for handling the FSSM requests coming from the ULBs own phone helpline/14420/walk-in citizens, and logging them into the SUJOG-FSSM platform and assigning them to desludging operators (DSOs). This person will be the designated FSSM executive in the ULB. This person could be the sanitation dealing assistant (DA), or the single window operator or an ALF member as per the FSTP operations arrangement within the ULB. They should fulfill the following basic criteria:

- Have basic computer literacy.

- Work within the sanitation wing (FSSM) of the ULB.

- Have a sound understanding of the FSSM operations followed in the ULB.

Enabling private operators to use the SUJOG-FSSM: ULBs need to ensure that all the private operators are empaneled to the ULB, and mandatorily start logging the applications in the SUJOG-FSSM portal or inform the ULB FSSM executive for each application and trip as they are using the services of the FSTP. This will bring the private operators within the ambit of the FSSM transformation and provide an oversight to the ULB administration. It will ensure that ULBs will have some oversight on the quantum of requests serviced by private operators and check any potential mishandling of sludge. The requests serviced daily can be reconciled against the number of trips at the FSTP end. For this:

- ULB EOs to issue notices to all private DSOs operating within the ULB to comply with rollout requirements (data and training) and start using the SUJOG-FSSM platform to record the requests.

- ULBs to ensure that mandatory usage of the SUJOG-FSSM platform by private DSO gets included in the licensing terms either immediately or at the time of renewal of license as per the rules of the current contract.

Standardising pricing of trips by cesspool vehicles: In phase-1 ULBs, there are certain ULBS where there are different pricing of trips by cesspool vehicles for multi-trips. For example, a ULB which has a 3,000 liter capacity of cesspool vehicle, the price of the first trip to an applicant’s location will be Rs 900 and for the second trip, it will be Rs 700. Besides, there are different pricing of the same volume of cesspool vehicles across ULBs. In case of urban-rural convergence, the pricing structure devised as of now is for panchayat areas within a certain radius (say 20 km) from the ULB boundary, and service charges include a base price plus fuel charge (say, base price is Rs 1,200 plus fuel charges @6 km per litre). Therefore, standardising the pricing of trips by cesspool vehicles will be explored.
Collation of details regarding entities where there is zero pricing: There are certain entities (such as a ULB itself, community toilets, etc.) from which no fees are collected for septic tank/pit cleaning. The same is also applicable for slums in certain ULBs. Therefore, ULBs will have a list of entities where zero pricing is there to avail cesspool cleaning services.
Streamlining and standardising the agreement between a private DSO and the ULB: Currently, there are three types of mode of operation of cesspool vehicles in ULBs that are “ULB Owned and ULB Operated”, “ULB Owned and Privately Operated” and “Privately Owned and Privately Operated”. However, in case of private DSO, there are scenarios that were explored during the phase-1 training session, which will be considered while designing/structuring the agreement of a private DSO with the ULB:

a. ULB Owned & Privately Operated:

i. Kashinagar Case:

Each trip amount is deposited by a private DSO daily at the ULB. At the end of month, a fixed amount (say Rs. 12,000) is given to the private DSO. (Cases may also arise where instead of a fixed amount, a trip-wise amount may be given to a private DSO daily or at the end of month).

ii. Khordha Case:

ULB & private agreement is done in which a private DSO pays a one-time amount (say Rs 5 lakh for 2 vehicles) to ULB for some years (say 7 years). During these 7 years, the manpower cost, and maintenance cost is taken care of by the private DSO, and it also keeps all the trip amounts with them.

b. Privately Owned & Privately Operated:

i. Angul Case:

Currently, the private DSO is taking the amount of all trips without giving any amount to the ULBs. But the ULBs are planning to send a letter to the private DSO to pay a certain amount to the ULB (at FSTP) for each trip that is being disposed of at an FSTP as the FSTP is a government property used by a private DSO.

Program Rollout Plan

Task

Status

Dependency

Responsibility / Owner

Start Date

End Date

Revised Date

Comments

Implementation Plan

Task

Owner

Assigned To

Dependency

Effort Estimation (Days)

Start Date

End Date

Revised Start Date

Revised End Date

New End Date

Status

Comments

Implementation Guide

Implementation Approach

This section presents an outline of the methodology used for implementing Feacal Sludge Management (FSM) on a state-wide level. The implementation process is divided into seven distinct stages, each with specific entry and exit criteria, as well as designated roles and responsibilities. These measures are put in place to ensure objective monitoring and decision-making, ultimately contributing to the overall success of the programme. The document provides detailed information about each stage.

The estimated timeline for completing the implementation programme is approximately 38 to 42 weeks. It is, however, essential to accomplish the activities and meet the exit criteria established for each stage in order to adhere to this timeline.

FSM Implementation Stages

Stage 0: Programme Setup/Onboarding

This set of initial crucial activities is initiated after receiving an enrolment letter or a Memorandum of Understanding (MoU) from the state. Successfully completing these activities ensures that the programme begins with essential personnel, teams, and funding.

Duration: 4-6 weeks
Entry criteria: Acceptance letter/MoU from the state
Exit criteria:

- Finalise the FSM programme vision

- Secure funding for the programme

- Establish the state-specific procurement process

- Complete team sign-up and onboarding

Stage 1: Programme Kick-Off

This stage may require multiple interactions/meetings with different interest groups. The principal objective of these interactions is to identify the scope and planning strategies for phasing/rollout, create an active collaboration and governance approach, as well as agree on a high-level timeline for the engagement.

Duration: 4-6 weeks
Entry criteria:

- Programme setup (Stage 0) is complete

- Implementation partner is signed-up

Exit criteria:

- Publish the programme charter

- Implementation plan agreement with priority features and broad timelines

- Programme governance model

- Programme success metrics

- Capacity building

- Data preparation/collection kick-off from the pilot urban local bodies (ULBs)

- Cloud infrastructure procured

Key activities:

- Project kick-off meeting and consultation with stakeholders

- Identify and agree on a high-level scope and exclusions

- Identify pilot ULBs

- Product walkthroughs

- Define the project steering committee structure and the project governance process

- Define the phases of rollout/deployment

- Agreement on deployment priorities and high-level delivery timelines

- Identify and study all FSM processes

- Citizen services/channels around it

- Finalise the programme success metrics for rollout, adoption, and governance adhering to the vision of the programme

- Internal capacity building, programme logistics at the state-level and ULBs, as per the current scenario

- Collection of baseline data to measure end-line target for the product (revenue generated, total properties in ULBs, etc.)

- Circulation of baseline data collection templates to the state

Stage 2: Solution Design

During this stage, it is expected that key state officials and subject matter experts will collaborate with the implementation team by sharing state acts and policies, and providing interpretation. This stage serves as a foundation for incorporating the state-specific product features into the product configuration report.

Duration: 4-6 weeks
Entry criteria:

- Programme charter

Exit criteria:

- State sign-off and the publication of FSM processes, data templates, and workflows

- Finalisation of the rollout plan in different phases

- Product configuration report sign-off

- Agreement on necessary state-specific product customisations

- Finalisation and state sign-off on the programme tracking mechanism

- Establishment of an initial reporting structure

- Definition of dashboard key performance indicators (KPIs)

- Sign-off on the data approach, including collection, migration, correction, sync-up, and validation

- Completion of a detailed project plan

Key activities:

- Standardisation of all FSM processes

- Initiation of policy changes, if necessary, based on the defined processes

- Definition of success criteria

- Conducting a product familiarisation workshop

- Initiation of master data collection from pilot ULBs

- Finalisation of data migration, collection, and sync-up approach as per requirements

- Finalisation of the data validation approach

- Finalisation of dashboard design for programme tracking

Stage 3: Configuration & Customisation

This stage involves a series of developments, according to the detailed project plan, to ensure the smooth functioning of the customised product. It includes activities such as master data collection and environment setup. Additionally, monitoring and maintenance strategies are implemented.

Duration: 6-8 weeks
Entry criteria:

- The product configuration report has been signed off by the state

- Sign-off on the data approach (data collection, migration, correction, sync-up, and validation)

- State sign-off and publication of FSM processes, data templates, and workflows

- Detailed project plan

Exit criteria:

- Configured/customised product ready for User Acceptance Testing (UAT)

- Establishment of monitoring, support, and maintenance for dashboards

- Finalisation of initial reporting and dashboard key performance indicators (KPIs)

- Identification of participants for the UAT session

Key activities:

- Setting up development environments

- Development/customisation of reports and dashboards

- Development/integration of the portal

- Integration with third-party systems (Example: payment gateway, handheld/POS device)

- Updating user manuals and other key documents

- Preparation and execution of test cases

- Setting up monitoring, support, and maintenance processes, tools, and dashboards

- Identifying nodal officers at the ULB level for day-to-day support

- Migration and verification of pilot ULB data in accordance with the data agreement signed off by the state

Stage 4: UAT & Go-Live

During this stage, a product demonstration followed by a hands-on session is conducted for ULB officials. The necessary training for ULB officials and identification of resources required for User Acceptance Testing (UAT) take place. Additionally, the establishment of the state support team, and the initiation of the required processes occur.

Duration: 2-3 weeks
Entry criteria:

- Configured/customised product ready for UAT

- Availability of pilot ULB officials associated with FSM for UAT and training

Exit criteria:

- UAT sign-off & go-live for pilot ULBs

- Setup of review and monitoring cadence

Key activities:

- UAT environment setup

- Identification and resolution of issues/bugs

- Regression UAT and sign-off from pilot ULBs/state

- Setting up of the production environment

- Establishing the support centre and related processes (helpdesk)

- Conducting training sessions for users and trainers

- Identifying master trainers from the ground for simultaneous training

- Training the support resources

- Implementing marketing and promotion activities

- Conducting the go-live and launch event

- Setting up of the review and monitoring cadence/team

- General FSM implementation activities link

Stage 5: Rollout

After a successful go-live in the pilot ULBs, and subsequent fine-tuning to stabilise the product, the solution will be gradually rolled out to the remaining ULBs in phases. The state team's guidance and support will be necessary to create rollout plans and ensure the availability of the required infrastructure for training and deployment in each ULB.

Duration: 5-6 weeks
Entry criteria:

- Successful pilot implementation in the state

- Less than 3 open critical incidents (issues) related to the product, implementation, and data

Exit criteria:

- Operational adoption tracking and review cadence established

- Effectiveness of the helpdesk assured

- Resolution of critical bugs

- Initiation of programme success metrics tracking

Key Activities:

- Configuring ULBs phase-wise according to the project plan

- Verifying and migrating ULB data phase-wise based on the data agreement sign-off provided by the state

- Implementing a bug ticketing tool for resolving ground-level issues by the state team

- Conducting user training at the district-level

- Rolling out the solution pan-state in phases

Stage 6: Sustenance and Ongoing Improvement

The final stage involves implementing strategies to ensure the long-term sustainability of the product in the state. Systems are established to continuously track data, and provisions are made to enhance the product based on new insights from the data.

Duration: Ongoing process
Entry criteria:

- Rollout phase 1 (First set of ULBs where the rollout will occur after the pilot

Key activities:

- Conducting adoption review meetings in line with the programme's vision, chaired by the programme head

- Implementing plans for ongoing sustenance, including:

a. Funding arrangements

b. IT support

c. Assessing process effectiveness and making improvements as needed

Roles & Responsibilities

Steering Committee: The steering committee comprises the senior bureaucrats and leaders from the state, HUDD, EY, PwC, eGov, and Janaagraha. They are responsible for the overall programme guidance, and fulfill the domain advisory role.

Project Management Unit (PMU): This unit will be responsible for the execution of the programme on behalf of the state team. They work in close collaboration with the ULBs, the technical partner (eGov), and other stakeholders.

eGoV team: The eGoV team is the technical partner of the project, and it will provide all necessary support to the state concerning implementation, programme design, etc.

Resource requirements for the PMU required to be formed by the state:

The technical implementation team should have the following technical skill-sets to work on FSM:

Development team skill-set

Java and REST APIS
Postgres
Maven
Spring framework
Basics of 2D CAD Drawings
Git
Postman
YAML/JSON

DevOps team skill-set

Strong working knowledge of Linux, command, VM Instances, networking, storage.
The session, cache, and token handling (Redis-server).
Understanding of VM types, Linux OS types, LoadBalancer, VPC, Subnets, Security Groups, Firewall, Routing, DNS.
Experience setting up CI like Jenkins and creating pipelines.
Artifactory - Nexus, verdaccio, DockerHub, etc.
Experience in setting up SSL certificates and renewal.
Gitops, Git branching, PR review process. Rules, Hooks, etc.
JBoss Wildfly, Apache, Nginx, Redis and Postgres.

Implementation Checklist

This document calls out the various tasks the teams need to perform before the FSM application is released to production.

TQM Gate 2 Plans & Checklist

Implementation Plan, Readiness Checklist, Adoption/Training Plan, Change Management Plan/ Review