ToR: Development of an Eligibility Tool (USSD) for the Energy RBF in Rwanda

Want create site? Find Free WordPress Themes and plugins.

       

                                               

EXPRESSION OF INTEREST

Development of an Eligibility Tool (USSD) for the Energy RBF in Rwanda

1.      Context of the assignment

Energising Development (EnDev) is a multi-donor, multi-implementer energy access programme currently financed by six donor countries: the Netherlands, Germany, Norway, the United Kingdom, Switzerland and Sweden. The Deutsche Gesellschaft für Internationale Zusammenarbeit (GIZ) GmbH acts as the lead implementing agency of the programme and cooperates closely with the Netherlands Enterprise Agency (RVO) at global level as well as other implementation partners at country level.

EnDev promotes sustainable access to modern energy services that meet the needs of the poor, while being affordable and long lasting. At the same time this bottom-up approach also contributes to positive economic, social and environment development. The goal of EnDev globally is to reach more than 20 million people by 2020.

EnDev Rwanda (https://endev.info/content/Rwanda) is one of the national projects making up the global program. The activities in Rwanda currently include a component supporting the development of micro-hydropower plans (PSP Hydro) and two components providing Results-Based Financing (RBF) to off-grid solar and mini-grid companies. The RBF components promote and support the diffusion of renewable energy (RE) technologies in rural regions by helping private companies overcome market barriers. Since 2014, eligible companies receive financial incentives for the construction and operation of mini-grids and for the sale of off-grid solar systems.

In 2018, EnDev Rwanda started to design a follow-up RBF. It will replicate the successful market-based approach of the current RBF with a social focus. The new RBF will specifically focusing on supporting the poorest households in Rwanda thereby contributing to the government’s rural electrification targets. Depending on the end customer household’s social status (known as Ubudehe category), companies will receive different levels of financial incentives to reduce the contribution paid by end consumers and make systems more affordable. As the new program will differentiate by customer’s Ubudehe category and will only allow for the purchase of one subsidized system per household, a tool is needed to check the eligibility of households and register sales made under the program. Its scope and technical design are outlined below.

2.      Purpose and scope of the RBF Eligibility Tool

The key objective of the Eligibility Tool is to enable solar companies to check if potential customers are eligible for financial incentives under the new RBF. Secondary objectives are “real-time” tracking of installations and disbursements as well as facilitating verification through sales data triangulation.

To fulfil these objectives, the Eligibility Tool will require two functions:

  1. Checking the eligibility of a customer to inform companies about the inventive level the customer is entitled to.
  2. Registering sales made under the new RBF upon installation to update the list of eligible customers and track progress.

It is expected that both functions will primarily be used by sales agents of solar companies operating in Rwanda. However, as the tool will be publically available, customers will have the ability to check their eligibility themselves.

To facilitate the integration of the tool into the operations of partnering companies and ensure the availability of the tool in the field, it is envisioned that the tool will use USSD to perform the functions described. The sections below provide an overview of the envisioned process for each of these functions.

Process 1 – Eligibility check

  1. The sales agent meets a potential customer interested in buying a solar system.
  2. The sales agent asks the potential customer his or her personal ID.
  3. The sales agent enters the personal IT into the USSD tool.
  4. The system returns information on whether the customer is eligible and, if so, for what incentive level.

In this process, a customer’s eligibility is determined by the following criteria:

  • The household of the customer has not bought a system under the RBF yet.
  • The household has no ongoing sale with another solar company, i.e. is not blocked. (This criterion is still being debated and remains optional).
  • The household is not in Ubudehe category 4.
  • The person has a known ID à if unknown, the system will send a notification to try ID of household head

If a household is eligible, the incentive level is determined:

  • by the Ubudehe category of the household.
  • whether the RBF incentive budget can still cover the required incentive for the current sale.

The information needed to determine someone’s eligibility and the incentive level they are entitled to is fetched from two already existing databases, as outlined in chapter 3.

Process 2 – Sales registration

  1. After agreeing on the sale and signing the contract, the sales agent registers the sale with selected key data via the USSD tool.
  2. After the solar system has been installed, the customer confirms the installation of the system by telling the sales agent his HH ID or voucher number (to be decided) that the sales agent enters in the USSD menu to complete the process.

3.      Technical Setup

The eligibility check and sales registration described above requires the use and interaction of three systems:

  1. The RBF USSD Eligibility Tool to be developed under the assignment described in this document.
  2. The Off-Grid Monitoring and Information System (OMIS) set up by EnDev in 2018 for the Ministry for Infrastructure (MININFRA) and the national utility, the Rwanda Energy Group (REG): The OMIS includes a database containing information on all solar home system sales made in Rwanda (incl. customer information). The database will provide the necessary information to cross-check whether a household has already received a subsidized system and will receive and store the information collected through the sales registration.
  3. The Monitoring and Evaluation Information System (MEIS) operated and maintained by the Local Administrative Entities Development Agency (LODA): The MEIS contains up-to-date information on individual IDs, Household IDs and the related social categories (Ubudehe). This information will be necessary in order to determine eligibility and the level of incentive based on Ubudehe category as well as to record and block households that have received a subsidized system. The OMIS already includes a query link to the LODA MEIS, which fetches the Household IDs and Ubudehe categories for sales that are uploaded into the OMIS. Whether the existing link could be used for the eligibility tool or a new link would be required is to be determined by the technical experts.

The technical setup of each of the databases to be accessed is described below.

The eligibility tool will be hosted in Rwanda on a server to be selected and paid by the client directly.

LODA MEIS

The MEIS is a database that contains demographic information for the majority of households in Rwanda, including individual and household IDs, information on members belonging to a specific household and the Ubudehe category. It is written in Java and has a web application with an API that allows interfaces with other systems and the required credentials will be provided. The database is hosted in the National Data Center of Rwanda and operated by the Local Administrative Entities Development Agency (LODA).

OMIS

The OMIS contains sales and customer data for off-grid solar system sold in Rwanda. It currently consists of two components:

  1. a database to store the sales and customer data as well as potential workflow-, process-, and other system data (e.g. history of changes, user accounts, etc.),
  2. a gateway application providing API access to that database and an administrative user interface for importing data into it and viewing and modifying that data.

While the host server has not yet been selected, it is likely that it will be hosted in the National Data Center of Rwanda.

As mentioned above, the OMIS database will need to be extended to also include data collected during sales registration, using the existing gateway application for the USSD communication. In order to accommodate the RBF data and satisfy queries from the USSD eligibility tool, the OMIS database will be extended in parallel to the development of the USSD. While the USSD developers selected for the present assignment are not required to be involved in the programming of the OMIS database or the required API, they are required to coordinate closely with the database team regarding interfaces, queries, data formats etc. The technical setup of OMIS is the following:

Database

The database is hosted in a Linux environment and uses MariaDB as a database server for data storage. Primary project data is kept in a separate database (albeit in the same database server instance) from workflow-, process-, and other system data. This ensures a clean separation of concerns on the database level and allows for a better management of user permissions. The database itself is only directly accessible through the gateway application.

Gateway application

The OMIS gateway application provides access to the database for administrative users via an administrative user interface. In addition, it makes the data available to third-party applications via a RESTful API. Through such an API, any application can access the database using standard HTTP technology (provided it holds adequate credentials).

The gateway application is written in the Java programming language and is built on the Spring Boot framework. All code documentation on database and gateway application and the necessary login credentials will be made available to the developers as needed.

4.      Implementation of RBF USSD Eligibility Tool

For the eligibility check and the sales registration it is proposed to use either Unstructured Supplementary Service Data (USSD) technology for two main reasons:

  1. to ensure user friendliness, as most users would be familiar with using USSD menus,
  2. to ensure nation-wide accessibility where a mobile network is available and via basic phones rather than internet-enabled smart phones.

The selected IT expert company  will be responsible for:

  1. Design, implementation and testing of the RBF web application (USSD)
  2. Facilitating the contract negotiations and USSD setup with the two telecommunications providers MTN and Airtel-Tigo (hereafter referred to as “telcos”)
  3. Troubleshooting and maintenance after roll-out for a period of 24 months

To implement the two processes described above, the system components must interact as sketched out in the following graphics that show the principles of selected data flows.

1) Starting the RBF USSD menu

2Eligibility check system process

In this process, the user enters an ID of the potential customer, which the RBF web application uses to determine the customer’s eligibility using two main tests:

 A query is sent to the OMIS gateway application to check whether the person’s household has either received a system already under the RBF, and whether it has an ongoing sale (optional).

In parallel, a second query is sent to the MEIS to check in which Ubudehe category the household associated with the personal ID is. Optionally, as there already is a query link directly between OMIS and MEIS, this link could be considered to be used. If, however, this would slow the performance of the USSD down by too much, a direct link to MEIS will be preferred.

Additionally, the web application must check whether the requested incentive amount is still available in the budget earmarked for the respective Ubudehe category. Based on these three tests, the web application must decide whether the eligibility criteria are met and return the appropriate response (details in annex):

1) Eligible with incentive level X

2) Not eligible / Currently not eligible because of insufficient funds

These eligibility checks and criteria as well as how they are reflected in the database fields are elaborated in the annex.

 

3) Sales registration system process

Example of entering the product type.

The web application will not save any data. Instead, sales information is stored in the OMIS database where it can be processed further. However, the USSD experts will not be responsible for the storage and must only coordinate with the database team that will provide a fully functional API.

The exact information flow for a part of the USSD menu is drafted in annex 1, but may be adjusted at the time of contracting based on the final requirements as well as the feedback from the selected USSD experts.

Log

The web application should keep a log of handled USSD requests including the used phone number and time stamp. The client would like to have regular reports on this for analysis. While a full admin interface is not required to access the log, the log data should be exported on a regular basis as a CSV or similar file that can be understood by non-IT staff.

Responsibilities

EnDev/client

USSD expert/ contractor

Obtain and pay for USSD code from RURA

 

Assist in contract negotiations with telcos when needed

Take responsibility for the contract negotiations and USSD setup with MTN and Airtel-Tigo covering the activation and operation of USSD codes

Make due payments for the activation and operation of the USSD

Ensure the cooperation of LODA and EDCL and provide contractor with the necessary credentials or login details to query or access the other databases

 

 

Provide translations of the USSD menu to Kinyarwanda in case a bilingual tool is chosen

Selection and payment of server host for the RBF

Advise on the selection of the server host.

Expected deliverables:

  1. Review of the suggested USSD menu flow and suggestions for optimization and a final design document for the USSD menus and web application
  2. USSD operation contracts with the two telcos MTN and Airtel-Tigo* covering the activation and operation of the USSD service

* The applicant is asked to differentiate the proposal by the option of working with only one telco as opposed to both, please consider note on page 9.

  1. Technical development of the agreed-upon USSD application
  2. Thorough testing with test protocols by test users and selected real end-users
  3. Detailed code documentation
  4. Export feature of web application log (report on handled USSD requests) as CSV
  5. Implementation of feedback after the first pilot phase
  6. Maintenance of the USSD application for a period of 24 months

Further Specifications

Language and Encoding Schemes

The general project language to be used in communication and documentation is English. The USSD application will be most likely be bilingual with the options of using English or Kinyarwanda.

With regard to encoding schemes of the USSD, the expert is expected to advise on the choice of UTF-8 or ASCII based on language requirements.

Quality Requirements

EnDev expects highly professional behavior in the design, implementation and documentation of the software. EnDev’s understanding of quality includes, but is not limited to:

  • State-of-the-art and internationally established coding practices
  • Solid testing procedures
  • User acceptance test
  • Anticipating faulty user data entry and building mechanisms to deal with it at every stage of the process
  • Complete and clear code documentation
  • Agile development methods, especially frequent and clear communication with the client and regular feedback sessions
  • Flexibility: Both the method and the software of the contractors must be adaptable to changing requirements communicated by the client during or after implementation. Effort spent on additional features will be compensated as agreed with the client.

Privacy and Encryption

The IT expert company must ensure that the data handling in the context of the RBF eligibility tool meets standards of the General Data Protection Regulation (GDPR) of the European Union. This implies that personal information must not be shared with third parties and it must always be transparent what happens with personal data. The IT experts are expected to assist EnDev in documenting what exactly happens with personal information, where it is stored and who has access, so that EnDev can inform the users accordingly. Any data transmitted to the contractor for testing or piloting is to be treated as confidential and is not to be disclosed to any third parties. Encryption using SSL or equivalent is required to ensure security.

Property Rights

The software developed under this project will become property of GIZ. The contractor has no right to it nor the right to share it with third parties or sell it unless explicitly permitted to do so by the client. If suggesting to use proprietary software, e.g. their own, the applicant will need to suggest a contractual arrangement specifying if and how a transfer of the developed USSD application is possible in case the cooperation between the applicant and GIZ is terminated.

5.      Maintenance

Lastly, the selected IT expert company will be responsible for technical support for a period of 24 months after handover.

6.      Deliverables, Timeframe and Expected Workload  

The table below shows the deliverables, their timing and the expected workload in days.

 

week

 

Activity (expected workload in days)

0

1st

2nd

3rd

4th

5th

6th

7th

8th

Total days

Contracting (expected  mid March 2019)

 

 

 

 

 

 

 

 

 

 

Review of the USSD menu flow in a final design document

 

 

 

 

 

 

 

 

 

2

Operation contract negotiations and USSD setup with MTN and Airtel-Tigo

 

 

 

 

 

 

 

 

 

6*

Technical development of the agreed-upon USSD application

 

 

 

 

 

 

 

 

 

10*

Testing

 

 

 

 

 

 

 

 

 

2

Export feature of web application log as CSV or similar file

 

 

 

 

 

 

 

 

 

2

Code documentation

 

 

 

 

 

 

 

 

 

2

Implementation of feedback after the first pilot phase

 

 

 

 

 

 

 

 

 

4

Maintenance of the USSD application for a period of 24 months

 

 

 

 

 

 

 

 

 

To be proposed by applicant*

Total days

28

                       

Important note: The applicant is asked to differentiate the proposal, i.e. required workload and respective budget, for the option of working with only one of the telcos as opposed to both. The three options will be:

  1. Operation of USSD service with only MTN
  2. Operation of USSD service with only Airtel-Tigo
  3. Operation of USSD service with both telcos

Based on the exact costs for each option, if different, and considerations regarding the use and coverage of the service, the client will decide on one of the options.

Travels

The project implementation will take place in Kigali, Rwanda. No travels outside Kigali are needed.

7.      Coordination and Supervision

The IT expert company will report to a focal point at EnDev Rwanda to be appointed as well as the IT consultant from energypedia consult who will oversee the implementation of this project and facilitate communication between the implementer and relevant stakeholders. Close collaboration will be required with the OMIS database developers.

8.      Required Profile of the consultant/consulting company or team

The company is expected to have the following essential qualifications and experience:

  1. Academic degree in computer science, computer engineering, IT or related field
  2. A minimum of three years of experience in USSD creation with at least two reference projects similar to this project
  3. Work experience in Rwanda
  4. Detail-oriented and self-motivated
  5. Positive attitude, team player, clear communication
  6. Excellent English skills required

ANNEX 1

1.      Detailed USSD Process 1: Eligibility Check

Step

 

 

User activity with mobile handset

Direction

USSD message on screen

USSD web application

1.

User dials

*123#

à

 

Documents request in log

2.

 

ß

 

“Welcome to the RBF. Press

(1) To check someone’s eligibility for RBF incentives

(2) To register an RBF-supported sale

(3) Confirm a sale

 

3.a

User presses 1

à

 

 

3.b

User presses 2

à

See sales process below

 

4.a

 

ß

 

“Please type individual ID followed by #”

 

5a

User types ID #

à

 

 

6.a.1

 

ß

 

In case of known ID:

“The person with ID number XXXXXXXX

– Is not eligible for an RBF incentive or

– Is eligible for an RBF incentive of 60% or

– Is currently blocked due to ongoing sale or repossession

In case of eligible:

(1) To register a sale, press “2”

(2) To end, press “3”

Queries the OMIS database fields “Eligibility status” and “Eligibility level” for the requested ID

 

Queries the MEIS database field “Ubudehe category” for the requested ID

 

6.a.2

 

ß

 

In case of unknown ID:

“Unknown ID. Type correct ID or try household head ID”

 

7.a.1

User presses 2

à

User is sent to step 3.b

 

7.a.2

User types new ID

à

User is sent to step 6.a.1

 

           

2.      Detailed USSD Process 2: Sales Registration

Step

 

 

User activity with mobile handset

Direction

USSD message on screen

USSD web application

Comments/

questions

 

1.

User dials

*123#

à

 

Documents request in log

 

2.

 

ß

 

“Welcome to the RBF. Press

(1) To check someone’s eligibility for RBF incentives

(2) To register an RBF-supported sale

(3) Confirm a sale

 

 

3.a

User presses 1

à

See eligibility check process above

 

 

3.b

User presses 2

à

 

 

 

4.b

 

ß

 

“Please enter individual ID number followed by #”

 

 

5.b

User enters ID #

à

 

 

 

6.b

 

ß

 

“Please select company

(1) Company A

(2) Company B

(3) Company C

(4) Company D

(5) End registration process”

 

 

7.b

User selects X

à

 

 

 

8.b

 

ß

 

“Please select location

(1) Province A

(2) Province B

(3) Province C

(4) Province D

(5) End registration process”

 

Level of location (province, district, sector, cell village) to be decided. Multiple menus if necessary

9.b

User selects Y

à

 

 

 

10.b

 

 

“To complete the sale and confirm installation of system, please enter household ID number/voucher (tbd)”

 

This step can be completed right after the contract signing when the system is installed on the same day or after up to two weeks (tbd) after contract signing. In the latter case, user should be able to jump to the HH ID step in the very top menu of step 2.

11.b

User enters household ID #

 

 

 

 

12.b.1

 

 

In case of HH ID matching individual ID and no system has been registered:

“Thank you. The sales registration with RBF is complete.” Application ended

Database changes the field voucher status to “Used” for all individuals connected to the used HH ID.

 

12.b.2

 

 

In case of HH ID matching individual ID, but system is registered:

“This HH ID has already been used.” Application ended

 

 

12.b.3

 

 

In case of HH ID not matching individual ID:

“Household ID does not match individual’s ID. Please press

(1) To reenter Household ID followed by #

(2) To start process with different individual ID.” Sent back to step 4.b

 

 

 Application deadline

The interested companies should submit their technical and financial offers, in sealed and separated envelops, to the reception desk of the following address not later than 07 March 2019 at 4h00 pm:

GIZ – Kigali Office

KN 41Ave, N° 17 – Kiyovu

B.P 59 Kigali – Rwanda

  • Please mention on the envelops “Development of an eigibility tool USSD for the energy RBF in Rwanda”.
  • The financial offer must be in Rwf and VAT excluded.
  • Don’t forget the RDB registration certificate of business , and last VAT clearance certificate

NB: only companies are accepted, individual consultant will be rejected.

For any other information, do not hesitate to ask, send email to: procurement-rw@giz.de

                                                                            

Did you find apk for android? You can find new Free Android Games and apps.
Don't Miss Another Job Opportunity !

Join over 15,000 people who get notified daily. Enter your Email Address and subscribe for free.

(Visited 16 times, 1 visits today)