MIS Guideline For SP in Ethiopia Final 09062016

© UNICEF Ethiopia/ 2016/Tesfaye
MANAGEMENT
INFORMATION SYSTEMS
GUIDELINES FOR SOCIAL
PROTECTION PROGRAMMES
IN ETHIOPIA
Expert Working Group

Richard Chirchir (Development Pathways), Getachew
Berhanu (MoLSA), Fekadu Kassa (MoANRM), Sintayehu
Tadesse (MoLSA), Yves Christian Francois Dublin
(UNICEF), Teklit Adhanom (UJCFSA), Berhe (PSSSA),
Beiniam (POESSA)
May, 2016
Addis Ababa
ACRONYMS
BoLSA Bureau of Labour and Social Affairs
CAPI Computer Assisted Personal Interviewing
CSPMIS Central Social Protection Management Information System
EMIS Education Management Information System
EWG Expert Working Group
GoE Government of Ethiopia
GDP Gross Domestic Product
GPS Global Positioning System
HMIS Health Management Information System
IBEX Integrated Budget and Expenditure System
ICT Information and Communication Technology
ID Identification
ISP Integrated Social Protection
MOLSA Ministry of Labour and Social Affairs
MIS Management Information Systems
NHR National Household Registry
PDA Personal Digital Assistant
PIS Prosecution Information System
PMO Prime Minister Office
POESSA Private Organisation Employee Social Security Agency
PSNP Productive Safety Net Programme
PSSA Public Social Security Agency
RDBMS Relational Database Management System
SCT MIS Social Cash Transfer Management Information Systems
SDD System Design Document
SHA-2 Secure Hash Algorithm
SP Social Protection
SRS System Requirement Study
SSAO Social Security Administration Office
MIS Guideline for SP Programmes in Ethiopia Page ii

SSL Secure Socket Layer
TIN Tax Identification Number
TWG Technical Working Group
UPSP Urban Production Safety Net
WDC Woreda Data Center
MIS Guideline for SP Programmes in Ethiopia Page iii

TABLE OF CONTENTS
1 Introduction ........................................................................ 1
2 The objective of the MIS guideline........................................ 4
3 BACKGROUND AND CONTEXT .............................................. 5
3.1 Components of Social Protection Management Information System .................... 5
3.2 Proposed Model of Integration .............................................................................. 7
4 Administrative and Institutional requirements ................... 12

4.1 Governance and Institutional Arrangements........................................................ 12
4.2 Administrative Structure and Decentralization .................................................... 12
4.2.1 Woreda Level ....................................................................................................... 13
4.2.2 Regional Level ..................................................................................................... 14
4.2.3 National Level...................................................................................................... 15
4.3 Decentralised operations of programme MISs..................................................... 16
4.3.1 Federal and Regional MIS ................................................................................... 16
4.3.2 Woreda MIS ......................................................................................................... 17
4.4 Staff Availability and Capacity............................................................................ 17
5 Business functional requirements ....................................... 18

5.1 Information requirements and reporting Indicators ............................................. 18
5.2 FUNCTIONAL REQUIREMENTS .................................................................... 21
5.2.1 Registration, Targeting and Enrolment ................................................................ 23
5.2.2 Payments and Reconciliation ............................................................................... 25
5.2.3 Graduation/Exit .................................................................................................... 26
5.2.4 Funds Flow Management ..................................................................................... 26
5.2.5 Grievance/Case Management .............................................................................. 27
5.2.6 Reporting ............................................................................................................. 28
5.2.7 Monitoring and Reporting Indicators................................................................... 29
5.2.8 Business Intelligence Tool ................................................................................... 34
MIS Guideline for SP Programmes in Ethiopia Page iv

6 Technological Requirements .............................................. 35
6.1 Data Security and Privacy.................................................................................... 35
6.2 Information and Data Security ............................................................................. 36
6.3 Data Security, Access and Authentication Requirement ..................................... 37
6.4 System Audits for Data Security.......................................................................... 39
6.5 Data Exchange Protocol and Data Exchange Mechanism ................................... 39
6.6 User Interface Requirements................................................................................ 40
6.7 Online Portal (MIS web portal) ........................................................................... 41
6.8 Email Notification................................................................................................ 43
6.9 Query and Advanced Search ................................................................................ 43
6.10 Sizing, Performance, load testing and Scalability Requirements ........................ 44
6.11 Data Backup and Recovery Requirements........................................................... 45
6.12 Technology Platform Requirements .................................................................... 45
6.13 Electronic Document Management and tracking ................................................. 46
6.14 Hardware Infrastructure ....................................................................................... 47
6.15 Telecommunication Networks ............................................................................. 50
7 Services and other Requirements ....................................... 51

7.1 System Development Approach .......................................................................... 51
7.1.1 Waterfall Method ................................................................................................. 51
7.1.2 Prototyping Method ............................................................................................. 52
7.2 System Requirement Study/Gap Analysis ........................................................... 52
7.3 System Design ..................................................................................................... 53
7.4 MIS Development and prototyping ..................................................................... 53
7.5 System Installation and Configuration................................................................. 54
7.6 System Testing..................................................................................................... 54
7.7 Data Migration and Data Entry ............................................................................ 54
7.8 MIS user training and User Acceptance Test....................................................... 55
MIS Guideline for SP Programmes in Ethiopia Page v

7.9 Final Deployment (Go LIVE) .............................................................................. 56
7.10 System Warranty and Maintenance Support Services ......................................... 56
7.11 System Ownership and Source Code requirements ............................................. 57
8 Bibliography ...................................................................... 60
TABLES
Table 1: Results of analysis of SP MISs .......................................................................................... 5
Table 2: Status of SP MIS in October 2015 ..................................................................................... 8
Table 3: Proposed Split of SP MIS functions across MIS elements/components in Ethiopian
context ............................................................................................................................................ 10
Table 4: WOREDA-LEVEL MIS MODULES ............................................................................. 13
Table 5: REGIONAL MIS MODULES......................................................................................... 14
Table 6: NATIONAL MIS MODULES ........................................................................................ 15
Table 7: Essential Information required for a Well-Functioning Social Protection Management
Information System ........................................................................................................................ 19
Table 8: Registration, Targeting and Enrolment Functional Requirements................................... 23
Table 9: Payment and Reconciliation Functional Requirements ................................................... 25
Table 10: Graduation/Exit.............................................................................................................. 26
Table 11: Funds Flow Requirements ............................................................................................. 27
Table 12: Grievance/Case Management Requirements ................................................................. 28
Table 13: Reporting Requirements ................................................................................................ 28
Table 14: Essential Reporting Indicators Needed for a Well-Functioning Social Protection
Management Information System .................................................................................................. 31
Table 15: Business Intelligence Requirements .............................................................................. 34
Table 16: Key Data protection and Information Privacy Principles .............................................. 35
Table 17: Essential Security Control Measures ............................................................................. 36
Table 18: Data Security, Access and Authentication ..................................................................... 37
Table 19: System Audit and Data Security Requirements ............................................................. 39
Table 20: Data Exchange Requirements ........................................................................................ 39
Table 21: User Interface Requirements ......................................................................................... 40
Table 22: Online Portal Requirements ........................................................................................... 41
Table 23: Email Notification Requirements .................................................................................. 43
Table 24: Query and Advanced Search Requirements .................................................................. 43
Table 25: Sizing, Performance, Load Testing and Scalability Requirements ................................ 44
Table 26: Data Backup and Recovery Requirements .................................................................... 45
Table 27: Technology Platform Requirements .............................................................................. 45
Table 28: Electronic Document Management Requirements ........................................................ 46
Table 29: An Analysis of Hardware Options ................................................................................. 48
MIS Guideline for SP Programmes in Ethiopia Page vi

Table 30: System, Ownership and Source Code Requirements ..................................................... 57
FIGURES
Figure 1: Conceptual model of Ethiopia's Integrated Social Protection Management
Information System ............................................................................................................. 7
Figure 2: GEOGRAPHICAL ACCESS LEVELS ............................................................ 16
Figure 3: A Waterfall Model of a Software Development Lifecycle ............................... 51
Figure 4: Prototype Enterprise Application Development Method .................................. 52
MIS Guideline for SP Programmes in Ethiopia Page vii

1 INTRODUCTION
Management Information Systems (MISs) underpins effective social protection schemes,
ensuring effective delivery of the key operational processes, such as registration,
enrolment, payments, and grievances. They also play an important role in facilitating and
supporting programme monitoring. MISs for social protection programmes can be seen as
a reflection of the operational processes of the programme, predicated upon appropriate
technology. A weak MIS will result in poor programme implementation.
As in many developing countries, such as Ethiopia, attempt to design and implement

program MISs are buttressed by a need for greater harmonization and coordination of the
SP sector. Indeed, Ethiopia’s National Social Protection Policy explicitly identifies need
for a central information system1 that makes it possible to identify beneficiaries in location,
number and type of service they need. Additionally, there is further need to keep adequate
data and share it with other government ministries.
In the proposed set up, MoLSA shall have the responsibility of managing and administering
the central SP registry. However, Regional bureaus of Labour and Social Affairs shall be
responsible subordinately to manage and administer the information system at their
disposal. To ensure that the information collection system is complete and consolidated,
government bodies in Federal and regional levels, civil societies, and other non-
governmental organizations providing Social Protection services (all relevant stakeholders
implementing SP programs) need to provide regularly data to the central registry based at
MoLSA.
Therefore, to develop well established and comprehensive programme management

information system (MIS) with its clearly defined and designed processes, and to ensure
harmonization or integration of similar programmes or for the coordination of programmes
within and across SP functions, the development process of MIS must follow accurate steps
including preparatory design activities, in particular technical documentation that describe
the operational processes and that represent the basis for the development of the MIS.
There are a number of terminologies that are sometimes used interchangeably to refer
different components of SP MISs. For the purposes of this guideline, MISs are defined as
broad systems that enable the flow and management of information within SP programmes.
Importantly, functional SP MIS can range from a purely paper-based system to a highly
1
This is the term that is used on the National Social Protection Policy Document. The terminology has since
been further clarified in section 3.2 (components/elements of social protection management information
systems in Ethiopian context).
digital one; an MIS does not need to be fully computerised. However, the more
computerised it is, the higher the chance that the system is more transparent, contains more
checks-and-balances - reduces the risk of fraud - and is more efficient. However, fully
computerized systems can be difficult to operate in developing country contexts where staff
may not have the required skills, equipment may not be available and power outages may
be prevalent. Therefore, choices and trade-offs should be considered when setting up a SP
MIS. The key building blocks that inform the integrated SP MIS as envisioned by the
national social protection policy include:
Box 1: General definitions of SP MIS concepts
 A database is a system intended to organize, store, and retrieve large amounts

of data easily and a ‘registry’ is an official written record of names or events or
transactions.
 An MIS (“Programme MIS” in Social Protection Context) is a system that
transforms the data that is retrieved from a programme’s database (or in some cases,
different databases linked to different “modules”) into information that can be used
for efficient and effective management.
 Single Registry is a listing (database) of all people/households who have been
registered (i.e. interviewed using either a census or on-demand registration
approaches)2.
 An integrated system for information management3 refers to the broader system
that enables the flow and management of information within and between SP
programmes (and sometimes beyond, to other sectors).
2
A census method means that the programme attempts to visit all households to undertake targeting; an on-
demand method means that applicants are expected to visit specific registration points to apply for the
programme.
3
The specific terminology and conceptual model of Ethiopia's Integrated Social Protection Management
Information System is laid out in chapter 3.2.
MIS Guideline for SP Programmes in Ethiopia Page 2

This document therefore focuses on detailing the necessary steps and processes in order to
develop an integrated comprehensive, electronic MIS that meets the needs of all current
and future SP programmes in Ethiopia. The document is divided into seven chapters:
- Chapter 1 introduces the guidelines;

- Chapter 2 outlines the objectives of the guidelines;
- Chapter 3 sets out the background and context of integration based on previous
consultative processes by MoLSA and stakeholders;
- Chapter 4 presents administrative and institutional requirements necessary for
successful implementation of the integrated programme MISs;
- Chapter 5 describes the high level functional and technical specifications;
- Chapter 6 describes the technical requirements; and
- Chapter 7 is detailed step by step guidelines of the implementation approach of
integrated SP MISs in the Ethiopian context.

2 THE OBJECTIVE OF THE MIS GUIDELINE
This guideline is designed to address the following goals and objectives:
 Provide detailed guidance to the SP stakeholders to develop their programme based

MISs and to the elaboration of terms of references of MISs;
 Ensure new program MISs are based on specifications that allow them to
communicate with each other, with existing MISs, and with a central social
protection MIS (CSP MIS);
 Help those programs that do not have Management Information Systems (MISs) to
develop them based on minimum standards for effective and efficient functioning;
 Ensure that modifications and upgrades of existing MISs enable them to
communicate with each other and with a central social protection MIS (CSP MIS);
and when appropriate, draw data from the national household registry;
 Provide a foundation for development of functional SP MISs, building of the
National Household Registry and Central Social Protection Reporting System; and
 Act as a reference material for the GoE officers involved in designing and
implementing SP MISs.

3 BACKGROUND AND CONTEXT
3.1 COMPONENTS OF SOCIAL PROTECTION MANAGEMENT INFORMATION

SYSTEM
Social Protection (SP) policy in Ethiopia envisions establishment of an integrated social
protection management information system that makes it possible to identify beneficiaries
in location, number, type of service they need, to keep adequate data and exchange them
with others. In terms of governance, the policy envisions shared responsibility between
three actors namely, MoLSA, Bureau of Labour and Social Affairs (BoLSA) and Non-
Government Organisations. According to the SP policy, MoLSA would be responsible for
managing the Central Social Protection Management Information System (CSP MIS). The
regional bureaus of Labour and Social Affairs are responsible subordinately to manage and
administer the information system at their disposal. The non-state actors would provide
complementary role to government bodies in Federal and regional levels by providing
reports on social protection services.
From results of rapid assessment conducted in October 2015, SP sector programmes in

Ethiopia run basic MISs (either paper-based, excel-based, mix of Excel and Paper or basic
MIS modules that computerise limited programme functions). This finding is a good
opportunity for set up of integrated and electronic social protection MIS. This is because
Ethiopia could build new MIS on very strong and recent software development framework
without baggage of legacy systems. As a matter of fact, nearly all the MISs are either being
re-designed or in the processes of being designed.
The following analysis provides the current state of MIS categorised on the following main
SP policy thematic areas: (i) social assistance (ii) social security (iii) social justice. Results
of the analysis are presented in table 1 below:
Table 1: Results of analysis of SP MISs
Policy Theme Findings
Social  A National Household Registry (NHR) shall be designed for PSNP

Assistance and UPSP covering rural and urban areas respectively;
 PSNP has a paper based system. The aim is to improve the system and
move it into electronic platform. It shall use data from NHR once in
place ;
 A Programme MIS shall be developed for UPSP. It shall use data from
NHR;

 SCT MIS has been developed for pilot social cash transfer (sub-
component of PSNP) in four Woreda’s: Halaba, Shashego, Adami
Tulu and Dodota. This is expected to inform the database for direct
support beneficiaries.
Social  Private Organisations Employee Social Security Agency (POESSA)
Security runs a manual and excel-based MIS which tracks private sector
employee contributory pension (retirement, disability and survivors);
 Public Social Security Agency (PSSA) runs manual MIS for a number
of its functions. The MIS runs on electronic database (built on
Structured Query Language (SQL) Server) that is used to capture
pensioner’s details;
 POESSA and PSSA collect details of the employees, key of which
include Tax Identification Number (TIN), names, date of birth, date
of employment, photo, marital status, spouse details, children details
and salary.
 Social Security Administration Office (SSAO) is in the process of
being established. Once set up, there will be a “Social Security”
Management Information System that will computerise the core
processes – such as employee registration, contribution collection,
claims management, payment administration and fund management-
for both agencies (POESSA and PSSA).
Social Justice  Ministry of Justice maintains two mechanisms of data management:
(i) manual templates for reports (ii) an electronic database,
Prosecution Information System (PIS);
 PIS is installed in police stations and is used to register cases including
those affecting vulnerable groups i.e. Children, disabled and elderly;
 PIS is grounded because of the following challenges: (i) lack of
technical capacity to support the system as a result of staff turnover;
(ii) Lack of awareness among system users i.e. prosecutors and police
officers

3.2 PROPOSED MODEL OF INTEGRATION
Figure 1: Conceptual model of Ethiopia's Integrated Social Protection Management Information
System
As illustrated in figure 1, the proposed model for integration of SP MISs in Ethiopia

comprises of the following four elements:
 Platforms. E-Government, National ID and Woreda net form the key
foundation for the proposed integrated SP MIS in Ethiopia. In fact, International
evidence5 indicates that some form of unique ID for individuals is needed to
integrate information and data within and among SP programmes, and beneficiaries
with other systems and programmes. The best practice is to adopt the existing
unique identification number, typically a national ID, rather than creating new IDs
for the purpose. On this note, Ethiopia Vital Registration Department is in the
process of setting up a national ID system. In addition, WoredNet an e-government
platform has been established. WoredaNet connects more than 611 Woredas,
regional and federal government offices across the country using terrestrial and
satellite-based network. It is designed with the primary objective of providing ICT
services such as video conferencing, directory, messaging and Voice Over Internet
Protocol, and Internet connectivity to the Federal, Regional and Woreda level
4
As envisioned on PSNP program design document, the national household registry will function as registry
of the poor. It will also be used by the humanitarian system.
5
Barca, V. and Chirchir, R. (2014) Demystifying Data and Information Integration Concepts, DFAT,
Australia.

government entities. It is therefore expected that integrated SP MIS shall benefit
from Woredanet and other e-government initiatives.
 Registries. From the assessment, it was evident that that there are two desired
registries: (i) National Household Registry (NHR) which shall act as a database of
actual and potential beneficiaries PSNP and UPSP programmes 6. The elements of
NHR shall be further designed. In a Nutshell, key questions include mechanism of
data collection (census or on-demand), frequency of update, information to be
collected and ranking criteria. (ii) The employee registry is expected to provide a
basis for integration for private and public agencies namely, POESSA and PSSA.
The other broad question is whether cross-checking should be undertaken between
the national household registry and the employees’ registry.
 Programme MISs. Table 2 below sets out the status of SP MIS.
Table 2: Status of SP MIS in October 2015
Ministry Management Status and comments

Information System
Ministry of Prosecutor Currently not in use. The issues that hinder its
Justice Information System implementation of PIS - (i) lack of technical
(PIS) capacity to support the system as a result of
staff turnover (ii) lack of awareness among
system users – should be addressed
Ministry of Health Management The MIS is functional. HMIS is an example of

Health Information System a well implemented system in Ethiopia. The
(HMIS) MIS is in use at Woreda, Region and National
level.
Ministry of Education EMIS is currently in use. But, it should be

Education Management upgraded to incorporate the indicators of the
Information System proposed school feeding programme;
(EMIS)
Ministry of Urban Production There is currently no MIS for UPSP. Therefore,

Urban Safety Net (UPSP) a new MIS should be designed and developed.
Development, It should draw data from NHR.
Housing and
Construction
6As envisioned on PSNP program design document, the national household registry will function as registry
of the poor. It will also be used by the humanitarian system.

Ministry of Productive Safety PSNP currently runs a paper-based MIS. This
Agriculture Net Programme should therefore be replaced with an electronic
MIS. The new MIS should draw data from
NHR once in place.
Ministry of Direct Support Social Cash Transfer MIS has been designed
Labour and Beneficiaries and piloted in four Woredas of Halaba,
Social Affairs Shashego, Adami Tulu and Dodota. The new
MIS should be designed and developed based
on the lessons learned and good practices of the
other MIS implementations (e.g. HMIS) and
the NHR data once in place.
Private organizations Currently POESSA MIS is in use. But, an

employee social integrated MIS for Social Security should be
security agency established.
(POESSA)
Public Social Currently PSSA MIS is in use. But, an

Security Agency integrated MIS for Social Security should be
(PSSA) established.
In order to comprehend (a) who is receiving (b) what type of assistance (c) where the
assistance is received and (d) when the assistance is transferred, MoLSA shall design
Central Social Protection Management Information System (CSP MIS) that keeps sector
information for planning, coordination and monitoring. CSP MIS shall maintain summary
information of key indicators. To scope out the details of the SP level indicators, a
comprehensive sector monitoring and evaluation framework should be developed. In terms
of objectives, CSP MIS should be used for planning, coordination and monitoring of SP
sector.
In terms of functionality, SP MISs typically supports the following7:
 Registration. Registration of applicants, using either a census or on-demand
method8 for targeting and registration;
7Chirchir, R. and Kidd, S. (2011) Good Practice in the Development of Management Information systems
for Social Protection. P.2.
8A census method means that the programme attempts to visit all households to undertake targeting; an on-
demand method means that applicants are expected to visit specific registration points to apply for the
programme.

 Targeting. Identification of those to be accepted onto a programme (i.e. the
beneficiaries);
 Enrolment. Enrolment of eligible beneficiaries;
 Grievance Management. Management and monitoring a grievance process;
 Co-responsibility. Monitoring compliance with conditions (where applicable);
 Updates. Identifying those who should be removed from a programme when no
longer eligible (exit/graduation) or because they have died;
 Payments. Producing lists of those who should receive payments and the level of
payment that should be given;
 Reconciliation. Identifying those beneficiaries who have been paid and those who
have not collected their benefits; and
 Programme Monitoring. Notifying programme managers when different
processes have happened or should happen e.g. when a payment is due or when
beneficiaries are due to exit.
In an integrated set up, SP functions could be implemented by a number of MIS elements.
For instance, NHR could handle registration and targeting functions while PSNP MIS
could be used to computerise enrolment of beneficiaries, payments, case management,
monitoring of compliance with conditions. Finally, CSP MIS will be used to handle
monitor SP level functions and SP level. Table 3 below outlines tentative distribution of
SP MIS functions across three key elements.
Table 3: Proposed Split of SP MIS functions across MIS elements/components in Ethiopian
context
Function Targeting Programme MIS Central

Registry Reporting
System
Registration  ** Not applicable
Targeting  ** Not applicable
Enrolment Not applicable  Not applicable
Grievance Management Not applicable  Not applicable
Co-Responsibility Not applicable  Not applicable

Updates Not applicable  Not applicable
Payments Not applicable  Not applicable
Reconciliation Not applicable  Not applicable
Programme Monitoring Not applicable  Not applicable
Programme/Registry   Not applicable

Reporting
Sector Monitoring Not applicable Not applicable 
Sector Reporting Not applicable Not applicable 
** Individual entitlement programmes may have their own registration and targeting
functions.
It should be noted that the matrix set out in table 1 above is not applicable across all the SP
thematic areas as described on the national social protection policy. In some instances, the
targeting registry and programme MIS functions could be delivered using single
programme MIS. If such were the case, then these programme MISs could also provide
monitoring and reporting information to the central reporting system. To avoid any
confusion in terminology, the guidelines will use the term “integrated social protection
management information system (ISP MIS)” to refer to the combination of targeting
registry, programme MIS and central reporting system.

4 ADMINISTRATIVE AND INSTITUTIONAL
REQUIREMENTS
4.1 GOVERNANCE AND INSTITUTIONAL ARRANGEMENTS

There are a number of social protection programs in Ethiopia (Social Assistance: Social
safety nets, Livelihoods and employment support, Social insurance, Social Security,
Access to health, education and other social services, Social Justice) like PSNP (Public
work, direct support, PDS, Livelihood), UPSNP (new), Social security or pension, health
insurance, school feeding and so on. These programmes are implemented by various
ministries such Ministry of Labour and Social Affairs, Public Social Security, Ministry of
Education, Ministry of Health, Ministry of Justice, Ministry of women, children and youth
affairs, Ministry of urban development, housing and construction, Micro and small
enterprises agency, Private organizations employee social security agency and World
Bank.
Additionally, there are numerous stakeholders spread throughout directorates and

ministries at the federal level. An ISP MIS requires input from programmes and service
providers and would at the same time feedback data back to those stakeholders in need.
During the development of an ISP MIS, it is prudent to establish a team of people who will
lead and oversee its design and implementation. These teams could be grouped into two:
(i) a system development team and (ii) a steering team. The system development team shall
ensure that the overall goal of the MIS project is achieved and would be responsible for
solving any broad issues or challenges. On the other hand, the technical team would
monitor the tasks and deliverables of the project.
4.2 ADMINISTRATIVE STRUCTURE AND DECENTRALIZATION

The modules proposed for the ISPMIS Development should be divided according to
Ethiopia’s geographical levels: Woreda level, regional level, national level. Details are
outlined in tables below.

4.2.1 Woreda Level
Table 4: WOREDA-LEVEL MIS MODULES
MODULE CHARACTERISTICS
Registration Module which shall allow the user to enter and manage the household
Module members entered in the system. The options include Registration,
Household poverty and kebele food insecurity indexes Calculation,
Validation and Classification of Results. This module will have the
ability to receive information from files located in mobile devices.
This module should work on either online or offline modes.
The case management module shall computerise individual processes

Case of Updates, Appeals, Complaints and Duplicates. Each process shall
Management follow the business requirements set out in the respective programme
Module operational manuals. This module should be accessible on both online
or offline modes.
This module is a tool that shall be used for internal monitoring of

Indicators outcomes. It will work in either online or offline mode. This module
Module will manage development of density maps as long as GPS information
is collected from each household.
This module shall be used to manage the household information.

Woreda officials will access it either in online or offline mode. This
Household Card module will be utilised to manage questions and requests by
Module households approaching PSNP offices to learn about their status. Any
new information can be shared with Regional Office where the
information is approved.

This module shall allow the user to define the sample of households
that will be part of the spot check verification in the field. The sample
determines if the data collection process meets the minimum agreed
Spot-check quality standard. Information is entered in the system and differences
Module of variables and scores are calculated to make the decision of whether
the data collected from a geographic area is approved or rejected, or
even increase the sample size of data collection to be able to better
make a decision.
This module shall allow the user to update the outcome of graduation
Graduation processes which are managed by the community. The graduation
Module module should link to the targeting module or household registry to
update socio-economic status of the household.
4.2.2 Regional Level

Table 5: REGIONAL MIS MODULES
MODULE MAIN CHARACTERISTICS
This module shall be used to manage the presentation and analysis of

the indicators generated by all processes in the cycle. Indicators can
be generated in order to compare different Woredas. Using these
Indicators indicators, it may also generate visits to different Woredas to verify
Module performance. The statistics and reports produced by this module can
be valuable tools in support of policy-decisions and operational
adjustments. These products can also guide the follow-up and
eventual evaluation of the program.

This module shall be used to collate information at
Graduation/Exit
regions for the final decision-makers to determine on who
Module
is graduating/exiting the programme.
4.2.3 National Level

Table 6: NATIONAL MIS MODULES
MODULE MAIN CHARACTERISTICS
This module shall be used to manage receipt and sharing of

Data information with other systems or databases linked to other
Sharing sources. It is should also able to generate reports which analyse,
Module summarize and link information and can be used to support
institutional decision making.
Indicators Module This module should allow the user to compare between indicators
to generate alerts and arrange visits to different regions to verify
performance. If necessary, this module will allow the user to
compare between Woredas and regions to verify that certain
region is monitoring their performance.
Administration Module Module for recording the operational structure of the Programme,
defining the several access levels pertaining to the distinct
operational units/personnel, along with their geographic location,
levels of dependency with regard to upper levels (if applicable).
In addition, the administration module should also serve to define
key and specific parameters of the PSNP project cycle.

Figure 2: GEOGRAPHICAL ACCESS LEVELS
4.3 DECENTRALISED OPERATIONS OF PROGRAMME MISS

Assessment at Woreda level of other MIS project implementations (e.g. eHMIS, PASS and
EMIS) indicates that Internet connection in Ethiopia at the Woreda and Regional levels is
very erratic. Due to this challenge, it is therefore necessary to design any Programme MIS
consisting of two components: (i) Web-based – but can operate in offline mode – MIS at
Federal and Regional level (ii) Web-based –but can operate in offline mode – MIS at
Woreda level.
4.3.1 Federal and Regional MIS

This web-MIS should be hosted at MoLSA and line ministries Servers for Federal MIS and
at Regional Offices. Both MISs will operate online, but will principally function in an
offline mode in case of erratic Internet connection. Having a web-based system should not
imply that it is mandatory for it to operate on the Internet. The Web-Based MIS should
have web capability, but can operate on dual modes (offline and online). This dual
operation mode should be an insurance against dependence on erratic Internet.

4.3.2 Woreda MIS
In order to distribute implementation and use of the Programme MISs, it should be fully
functional MIS at Woreda. In a number of developing countries’ MISs, it is common to set
up MIS at Federal/Regional level and provide access at the Districts9. However, Ethiopia
is unique for three reasons: (i) many government programmes are decentralized (ii) similar
MIS implementation – such as those of PSNP, EMIS and eHMIS – fully run at Woreda
with mechanism of replicating data to the Regional level and (iii) internet access is very
erratic – in terms of speed and reliability - at the Woredas. Therefore, Woreda shall be the
key focal point for Programme MIS implementation and by extension programme
operations. In this regard, Programme MIS should be designed with controls to validate
the data captured. From the Woreda Programme MIS, data shall then be automatically
synchronized to Regional MIS or manually handed in (in case there is not Internet
connection).
4.4 STAFF AVAILABILITY AND CAPACITY

Efficiently and effectively administrating and implementing a program based MIS requires
sufficient personnel dedicated to these tasks. Based on the responsibilities defined within
the institutional agreements, a clear organizational structure and units have to be
established for the MIS.
Identifying personnel who can administer a program MIS and formalising their roles and
responsibilities is a precondition for structured and timely information management.
Therefore, the following factors should be put into consideration:
1. Sufficient and competent staff, especially at local level (capacity, training, retention
etc.);
2. Define capacity as critical and budget for it;
3. Ensure capacity transfer in consultant contracts etc.;
4. Perform a capacity assessment upfront to analyse strengths and weaknesses to be
addressed;
5. Adopting long term vision for capacity development and training; and
6. Develop good practice workshops and sharing across different locations.
As part of the implementation of the ISP MIS strategy, a comprehensive capacity needs
assessment shall be undertaken in the Ethiopian context with the aim of providing specific
guidelines and recommendations on how to strengthen government capacity for long-term
sustainability of the MIS.
9
Similar to Woreda’s in the context of Ethiopia.

5 BUSINESS FUNCTIONAL REQUIREMENTS
5.1 INFORMATION REQUIREMENTS AND REPORTING INDICATORS

The following information requirements are indicative of the minimum requirements that
each SP Program MIS must comply with.

Table 7: Essential Information required for a Well-Functioning Social Protection Management Information System
Applicant/ Application Payment Exit Programme Case

Recipient Management
Process Grievance Process Process Process Details
Name Date applied**10 Date of submission of Transfer amount Date of re- Programme start date
grievance certification name
Date of birth/age Status of Reason for complaint Frequency of payment Date due to Partners
application exit
programme
Sex Date decision Stage in process Expected dates of Date exited Start Date
made/Date of payment programme
(and date)
enrolment**
Address (with Result of decision Date of resolution Dates of actual Reason End Date End Date
community/ (yes/no) payment for exiting
district, village
etc) programme
ID number Date registered** Decision on initial appeal Scheduled for Size of Types of co-
payment Transfer responsibility
Socio-economic Status of Reason for complaint Amount collected

status Applicants
10
** These information variables should be specifically defined based on the programme manual of operations. For programmes such as PNSP date of
application is not relevant, but this could be defined as date of registration.

Applicant/ Application Payment Exit Programme Case
Recipient Management
Process Grievance Process Process Process Details
Available of Types of service Reason for complaint Service to be accessed Reason for
Basic Services Non-
complaints
Photo Reason for Date applicant informed Reasons for - Coverage

rejection difference between
(optional)
scheduled and paid
amounts
Biometrics - Confirmation of action - Name of proxy
taken
(optional) recipient
- Date of submission of - Date of birth/age of
further appeal proxy
- Stage in process - Sex of proxy
- Date of resolution - ID number of proxy
- Decision on to Recipient
further appeal
- Date when
applicant was
informed of
decision
- Confirmation of
action taken and
date
- Implementing
MIS Guideline for SP Programmes Agency
in Ethiopia Page 20
5.2 FUNCTIONAL REQUIREMENTS
ISP MIS is expected to automate the following functions:
 Household/Beneficiary registration and management11: ISP MIS should capture

a complete demographic information of household head and its members, the socio-
economic indicators and other details according to the household registration
format. It should use the existing IDs (such as national ID, birth certificate number)
in the database for effective record management and tracking of the household and
its members.
 Targeting12: Program MIS should apply the program-based rule as per the
programme guidelines and the electronic generation of the targeting list for
verification and compliance. SP MIS should be designed with an electronic-
targeting aid, which will automatically produce a listing of potential beneficiaries
based on targeting for SP programmes. A verification list should be produced by a
user to check for inconsistencies and inaccuracies.
 Enrolment: SP Program MIS should generate enrolment list as per the targeting
guidelines to facilitate the information update of the eligible beneficiaries. SP MIS
should also provide a module where each beneficiary is enroled based on careful
assessment and verification of the details.
 Funds Flow Management: ISP MIS should capture the flow of funds within the
respective SP programmes with an aim to effectively monitor and manage the
budget allocations, distributions and actual payments made to the eligible
beneficiaries in each of the programmes. Scoping will be undertaken to explore
linkages to IBEX and to clarify any requirements to comply with the Government’s
public financial management system.
 Administration: ISP MIS should provide a single sign-on mechanism whereby

authorised users navigate various modules of the MIS based on the user access
rights and privileges to perform their respective business functions.
11
This information will eventually be captured by and stored in the national household registry.
12
The actual application of the targeting module will reflect the procedures of the programs, which may
evolve over time.

 Payments (Transfers to Beneficiaries/Recipients): ISP MIS should generate the
electronic payment lists including the automatic calculation of allowances to be
paid or disbursed based on the program payment cycle and business rules in order
to make payments to the beneficiaries; allows to perform automatic payment
reconciliation. For the fee waiver schemes, the MIS shall produce a list of
beneficiaries and track the invoices from the service providers e.g. hospitals or bus
companies. For the cash transfer schemes, a standard payroll format will be agreed
between the programme management and the PSP. An online approval process
should be built on SP MIS for authorizing the payments before submitting the list
to a PSP. Once the payments have been made to the beneficiaries, a report (manual
and electronic) should be sent back to Programme and used to reconcile the
payment cycle. Alternatively, an automated link could be established between
Programme MIS and PSP’s MIS.
 Grievance handling: ISP MIS should be designed with a module to manage and
monitor various kinds of complaints and grievances made in order to improve the
programmes service delivery and monitoring aspects. The Grievance process
should be designed to reflect the fact that much of these processes are managed at
Kebele level and will likely be reported up in aggregate. The system prompts for
timelines for resolving grievance.
 Case management/linkage to Basic Services.
 Reporting and Business Intelligence tool: MIS should generate various kinds of
in-built and ad-hoc reports at various levels in each of the programmes for effective
monitoring, programme improvement and well informed decision making. It
should also be designed with an enterprise level business intelligence tool to
support MoLSA data warehouse needs, use of statistical/quantitative techniques
and apply industry proven Business Intelligence & Forecasting techniques/tools.
 M&E and reporting: MIS should generate information and indicators for
Monitoring and Evaluation of the programs.
The following section set out detailed ISP MIS business requirements.

5.2.1 Registration, Targeting and Enrolment
Table 8: Registration, Targeting and Enrolment Functional Requirements
No. Functional Requirements
1. Registration
2. The system should track and maintain detail information of individual household
members such as (not limited to) Unique ID, Name, Gender, Date of Birth/age,
relationship with the head of the household, geographical location (Federal, Region,
Woreda and Kebele), mobile number, marital status and other socio economic
characteristics of the households based on the specific program needs/operational
manual/guidelines.
3. Function to maintain/update a unique households/beneficiaries account.
4. Ability to support application filing, approval processes for the selected beneficiary
of each program by the designated authorities. This includes ability to generate list
of beneficiaries in the agreed format for approval, and ability to (scan) maintain the
approved list in the system for audit purposes.
5. Ability to track household and their member(s) according to the individual identifiers
and be able to track them throughout their lifespan.
6. Ability to retain the same beneficiary identification number regardless of whether a

beneficiary moves to a different location within the country.
7. Ability to create automatic pop-up alerts for validation if any duplicate household
records were found in the database. In case of duplicate records found, the system
should provide an exception with a list of identical records. Also track action in case
of duplicate records.
8. Ability to maintain the database of household members and their family details and
be able to keep track of movements and other changes that might occur during their
lifespan.

9. Ability to check potential duplicate household and/or family members and give
system warnings or flag if certain household information matches (data validation
based on the text fields), such as when name, address, date of birth of members are
identical so that it records corrective action to be taken.
10. Targeting and Enrolment

11. Functionality to record programme specific criteria which shall be applied to the
households for identifying the poor based on the criteria provided by the indicators
and/or based on the programme rules.
12. Functionality to generate poverty ranking using programme rules and be able to
apply thresholds or cut-offs based on the program defined rules and criteria.
13. Functionality to re-generate such poverty ranking in case of change of any household
indicators and be able to maintain the change history of scores and indicators.
14. Functionality to generate list of registered households in the predefined format

(enrolment format) for any change or edits required in the household information.
15. Update, searching and reporting

16. Functionality to view, sort, and print data in electronic format at any given time.
17. Functionality to search household and/or beneficiary by name, address, and other
registration data items; Ability to search beneficiary by name, address, and other
registration data items to determine beneficiary unique identification number.
18. Functionality to update information only by the authorized users of the system
controlled by user access rights and controls. All these change histories should be
stored on the database system and should be able to generate reports on change
occurrence.

19. Functionality to generate household and member management information, such as,
households or members by geographical, selected registrations, and predetermined
criteria.
20. Functionality to generate predefined and ad-hoc based reports.
5.2.2 Payments and Reconciliation

Payments to the beneficiaries are made based on the payment rules in each of the programs.
This function will support the automation of the payment process to facilitate effective
tracking and management of payment process and its reconciliation. Detailed payment and
reconciliation functional requirements are set out in table 4 below.
Table 9: Payment and Reconciliation Functional Requirements
No. Payment and Reconciliation
21.
Function to determine the amount to be paid to the eligible beneficiaries based on the
specific program criteria maintained in the system.
22. Ability to automatically prepare budget estimation for planning purposes.
Ability to print budget plan following standard format required by the programs’
guidelines.
23. Ability to define payment rules based on the respective programme business criteria
and link them while generating beneficiaries list for payment.
24. Ability to maintain details of payment service providers such as banks etc.
25. Generate various kinds of MIS reports related to payments as required by the
programs.
26. Reconciliation
27. Ability to update or upload feedback information (reverse feed) on payments
according to the payments made (payment reconciliation).

28. Ability to generate the list of beneficiaries who are unpaid and maintain the history
for their payment in future.
29. Ability to generate record of a beneficiary payment status such as the last payment
data, payment amount, information on payment transfer and also the future maturity
date and amount.
30. Ability to maintain the payment reconciliation history for future reference.
5.2.3 Graduation/Exit
Table 10: Graduation/Exit
No. Graduation/Exit
31.
Ability to maintain the exit/graduation criteria for each program under various
program schemes and automatically identify and enlist the beneficiaries/households
that matches the program exit/graduation criteria.
32. Ability to record all the events of the exit criteria and automatically stop any grants
once the criteria has been applied and approved to the record.
33. Ability to deregister beneficiaries/households for program exit/graduation and to

allow retrieval of deregistered beneficiaries’ details from archive.
34. Ability to provide draft decision to disapprove graduation for printing and storing.
5.2.4 Funds Flow Management

The proposed Program MIS solution should have the ability to track budget estimate and
financial reporting. This means preparation of budget estimation, financial reports and
other types of reports as a requirement at all levels (Federal, Region, Woreda level). It
should also be designed with modules to calculate benefits and payment. This means, it
should be capable of calculating total benefits for each beneficiary household/beneficiaries
following government regulations. Finally, it should support payment activity and

reconciliation. In this respect, it should be able to link with the PSP MIS for payment
information exchange (including the generation of a monthly list of beneficiaries in agreed
format), payment reconciliation/settlement with payment agencies and state treasures.
Table 11: Funds Flow Requirements
No. Requirements
35. Ability to automatically prepare budget estimation to serve budget planning

purposes; Ability to print budget plan following standard format.
36. Ability to generate financial indicators as required for monitoring and reporting
purposes.
37. Ability to automatically generate financial reports following predetermined

requirements and formats.
38. Ability to prepare and print liens of receipt for each beneficiary.
39. Reconciliation
40. Ability to update or upload feedback information (reverse feed) on payments
according to the payments made (payment reconciliation). Set minimum
standards for the two systems to talk to each other.
41. Ability to generate the list of beneficiaries’ not paid and unpaid benefit.
42. Ability to generate record of a beneficiary payment status such as the last
payment data, payment amount, information on payment transfer and also the
future maturity date and benefits.
5.2.5 Grievance/Case Management

The proposed solution should support generation/collection of appeal form complainants,
and allow to manage and track appeal cases.

Table 12: Grievance/Case Management Requirements
No. Requirements
43. Ability to provide electronic forms for each type of Grievance and Complains
online and offline.
44. Ability to enter and maintain information of appeals cases.
45. For each category of service requested, the system should issue a unique Case
ID. Such cases should be recorded and scaled up as per the case management
criteria set.
46. Ability to allow users to set priority to appeal cases.
47. Ability to record treatment / resolution strategies and relevant authorities.
48. Ability to track the implementation of case treatment / resolution strategies and
update case status.
49. Ability to provide warning list for unresolved cases for a prefixed period of
waiting time.
50. Ability to record feedback from complainants for case resolution treatment.
51. Ability to generate MIS on total number of service/case request in a

day/week/month/year; types of requests made, status of case registered (opened,
pending, processed, resolved, unresolved, and closed).
5.2.6 Reporting
The proposed SP Program MIS solution should have extensive functionality to generate
various kinds of standard programme operational reports and other predefined reports in
specific standard as needed for programme monitoring and administration. Table 13 sets
out sample reporting requirements.
Table 13: Reporting Requirements

No. Requirements
52.
Extensive functionality to generate various kinds of MIS reports based on the
data available and user-defined input parameters selected by the user.
Such reporting structure should be able to meet the requirements at the various
levels of the users such as the senior management might require MIS reports for
policy and planning purpose whereas the operational staffs might need reports to
manage day-today functions of the program.
53.
The reports generated should also be exported into formats such as PDF, Excel
etc.
54.
Ability to generate all kinds of reports that are currently maintained manually.
55.
Ability to allow caching for standard and/or common periodic reports to avoid
redundant effort in report generation and improve the system performance.
56.
Ability to allow custom reports to be defined and added in the MIS without a
need to write code.
57.
The system should provide dashboards, analysis and drill-down ability.

58.
Reporting tool should have the capability to generate ad-hoc reports.

59.
5.2.7 Monitoring and Reporting Indicators

The National Social Protection Policy and GTP II of Ethiopia envision establishment of an
ISP MIS capable of capturing, analysing and disseminating information pertinent to the
number of citizens benefiting from different social protection programmes. It is envisaged
that ISP would lead to more equitable distribution of resources, provide oversight of
multiple schemes, establish links with other services and increase efficiency through
economies of scale.

The SP stakeholders require detailed, real time information for program implementation
that will be based on a limited number of standardised key indicators across all programs.
The information will help monitor the effectiveness and efficiency of implementation of
social protection programs and communicate the achievements of the desired outcomes
and impacts.
Table 14 below sets out the essential indicators for a well function SP MIS. These
indicators are derived from GTP II, National Social Protection Policy and National Welfare
Monitoring Survey. Even though there might be variations on the reporting indicators
based on the objectives of each SP programme, the indicators set out in Table 14 are
standard indicators that should be maintained by each of the social protection programme.
The SP sector monitoring indicators that are derived from programme log frames that are
presented in Annex 1. It should be emphasized that these are basic indicators. It is expected
that a comprehensive M&E strategy shall be developed complete with detailed M&E
indicators that would be monitored across the sector.

Table 14: Essential Reporting Indicators Needed for a Well-Functioning Social Protection Management Information System
Programme
Process Reporting Indicators Use of the Report
Registration  Number of registered applicants  Determine the accuracy of the registration

disaggregated by sex and age process
 Number of registered applicants  Determine the percentage of records with
disaggregated by socio-economic status incomplete or missing data
 Assist in the targeting process
Targeting/Enrolment  Number of potential targeted  Determine the accuracy of targeting mechanisms

beneficiaries  Determine the transition rates of beneficiaries
 Number of actual targeted beneficiaries from targeting to payments
 Number of applicants rejected as a result
of appeals or any other reason approved
by the programme
 Number of applicants included
 Number of potential beneficiaries that did
not enrol and reasons why not
Payments  Number of beneficiaries to be paid after  Efficiency of the payment process

enrolment  Adequacy of the benefit size as percentage of
 Benefit size/Level Poverty line
 Number beneficiaries who received the
payments in timely manner
 Number of beneficiaries aggregated by
payment cycle

Programme
Graduation/Exit  Number of beneficiaries  Determine the accuracy of graduation process

graduating/exiting from the program  Determine the number of beneficiaries
 Number of beneficiaries graduating from the programme and reasons
graduating/exiting from the
programming according to the criteria
Financing/contributio  Amount of  Identify sources of finance and Composition of

n/ Expenditure government/employee/beneficiary’s/ social expenditure as of GDP
Employers contribution  determine the Composition of expenditure and
 Amount of donor’s contribution percentage of Government budget
 Amount of others contribution  Efficiency of the expenditure
 Amount of Expenditure disaggregating
by benefit/administrative
Grievance handling/  Number of complaints submitted  Effectiveness of the targeting mechanisms based
Complaints disaggregated by age and sex and social- on the number of appeal cases
economic  Complaints about programme performance
 Number of complaints resolved  Frequency and nature of changes to beneficiary
 Number of Beneficiaries included/add as details
a result of appeals or any other reason
approved by the programme
 Number of Beneficiaries removed as a
result of appeals or any other reason
approved by the programme

Programme
Case  Types and number of Services available  Determine the effectiveness of Linking Social
Management/Linkag  Number of beneficiaries comply to the co- protection beneficiaries to basic to basic services
e to Basic Services responsibility disaggregated by Co-
responsibility
 Type of reason for non-complaints

5.2.8 Business Intelligence Tool
Table 15: Business Intelligence Requirements
No. Requirement
60. The MIS should have strong integration with business intelligence tool13 to support MIS
data warehouse needs, which is an integral part of an integrated MIS.
61. Such business intelligence tool should be implemented to analyse huge amounts of data for
meaningful conclusions and also use statistical/quantitative techniques and apply best
Business Intelligence & Forecasting techniques.
62. Functionality to generate graphical reports, ad-hoc reports and ability to perform data
analysis.
13It is a standard IT product that allows users to perform data analysis and generate various analytical reporting.

6 TECHNOLOGICAL REQUIREMENTS
6.1 DATA SECURITY AND PRIVACY

The Draft Data Protection Proclamation defines a legal basis for handling of information
in the Federal Democratic Republic of Ethiopia relating to people living within. It is the
main piece of legislation that governs the protection of personal data in Ethiopia. Ethiopian
ICT data protection policy protects individual privacy, including people’s right not to have
information relating to their family or private affairs unnecessarily revealed or the privacy
of their communications infringed.
Table 16: Key Data protection and Information Privacy Principles
Principle Provisions
Notice People should be given notice when their data are being collected.
Purpose and Personal information should only be used for the purpose for which it has been
disclosure proposed.
Consent The information should not be disclosed without the knowledge and consent
of the person to whom it relates.
Security The information should be kept secure from any potential abuse.
Access Subjects should be allowed to access their personal information and to correct
any inaccuracies.
Accountability Those who collect and manage the information are in an ethical-legal
relationship with the subjects of that information, to whom they should be
transparent and accountable.

6.2 INFORMATION AND DATA SECURITY
Information security is a broad discipline that has two aspects: a logical aspect and a
physical aspect. Logical security controls include firewalls and access controls, whereas
examples of physical security measures are doors, gates, and badges. Both kinds of
measures exit to protect the information gathered in an MIS, so it follows that there should
be a set of standards on information security for social protection programmes.
These standards should be based on international best practices such as ISO 27001 on
Information Security Management System (ISMS) from the International Organization for
Standardization.
Table 17: Essential Security Control Measures
Control Description
Access Access controls on social protection MISs, including controls to authenticate and
Control permit access only to authorized individuals and controls to prevent users from
providing beneficiary information to unauthorized individuals who may seek to obtain
this information by fraudulent means.
Physical Access restrictions at physical locations containing beneficiary information, such as
Security buildings, computer facilities, and records storage facilities to permit access only to
authorized individuals.
Encryption Encryption of electronic beneficiary information, including while it is in transit or in
storage on networks or systems to which unauthorized individuals may have access.
Procedures Procedures designed to ensure that any modifications of the beneficiary information
system are consistent with the social protection programme’s information security
programme.
Segregation Dual control procedures, segregation of duties and personnel background checks for
of Roles staff with responsibilities for or access to customer information.
Intrusion Monitoring systems and procedures to detect actual and attempted attacks on or
Detection intrusions into social protection MISs.
Systems

Backup and Measures to protect against destruction, loss, or damage of beneficiary information
Continuity due to potential environmental hazards, such as fire and water damage or technological
Plans
failure.
6.3 DATA SECURITY, ACCESS AND AUTHENTICATION REQUIREMENT

Table 18: Data Security, Access and Authentication
No. Requirement
63.
The security of the system shall be built in by a combination of Login
Identification and passwords. The security shall be provided at the Operating
System Level (Level 1), Application Login Level (Level 2) and at the
Menu/Program Execution Level (Level 3), and are user definable.
64.
User login, pin-based authentication should be implemented based on the
requirements.
65.
The system should be completely secure and fool proof with incorporation of
industry standard proven data encryption techniques and methodologies.
Those encryption techniques should be audited in timely manner to detect
loopholes and updated with the latest patches, in order to ensure that the
mechanisms are fitted with the latest security features.
66.
Implementation of Secure Socket Layer (SSL) is must for web-based MIS
system.
67. The system shall provide access control based on the user role types and their
privilege level to access certain system functions and system data. Concepts of
Triple-A: Authentication, Authorization and Access Control should be
implemented to stay in line with the latest security techniques.

No. Requirement
68. The system shall support a capability to define virtually unlimited number of
user types with differing sets of access privilege levels.
69. The system shall block the user account for a parameter-driven length of time
after a parameter-driven number of invalid log-on attempts.
70. In case of multiple unauthorized attempts of administrator access, the case

should be reported immediately to the designated maintenance and security
staffs of the MIS through Email, pop-up notification.
71. The system shall provide a capability for the users to change their password.
72. The system shall provide a facility to force users to change their password after
a parameter-driven time period.
73. The system shall provide definable password enforcement rules, including but
not limited to:
 Password length
 Required Alpha & numeric character
 Not same as previously used password
74. The system should provide two factor authentication
75. The strength of the passwords provided by the users can be measured and
suggested as Weak, Medium and Strong.
76. The system shall encrypt passwords before storage using the Secure Hash
Algorithm (SHA-2) encryption algorithm or equivalent latest version.
77. The access control security function shall provide a facility for the system
administrator to suspend an existing user’s access rights for a specified period
of time or indefinitely.

No. Requirement
78. The system shall provide a functionality to automatically lock a user session
after a definable period of inactivity.
79. The system shall maintain a log of changes to user access rights.
6.4 SYSTEM AUDITS FOR DATA SECURITY

Table 19: System Audit and Data Security Requirements
No. Requirements
80. The system shall maintain an audit trail of any changes or updates made in any
information that are considered vital and if made should maintain the audit log
with information such as
- Log the users who are accessing the system;
- Log the parts of the application that are being accessed;
- Log the fields that are being modified;
- Log the results of these modifications;
- Timestamp.
81. Ensure an audit trail is kept for all transactions and all audit transactions logged
are kept on the database.
82. Ability to generate system audit reports.
6.5 DATA EXCHANGE PROTOCOL AND DATA EXCHANGE MECHANISM

Table 20: Data Exchange Requirements
No. Requirements
83. The system shall have a functionality to exchange data with other relevant
databases in other external institutions such as with National ID database,

Birth registration database in a most secure environment through a
standardized data exchange protocol designed, developed and implemented.
84. Data exchange within the system at different levels via the internet shall be
encrypted.
85. The system shall have functionality to export/import files based on the
standard template defined through web services and/or API.
86.
The system should be able to maintain the log of such data imports being
performed by the authorized users. The log should maintain information such
as:
 Name of the file exported
 Login ID
 Timestamp
6.6 USER INTERFACE REQUIREMENTS

Table 21: User Interface Requirements
No. Requirement
87.
The system shall provide a configurable facility to design and print reports in
English Language.
88. The main system shall be a Brower based application (web based) that should
work over the Intranet/Internet.
89. The system shall provide intuitive, appropriate interfaces for the different
groups of users.
90. The system shall provide a user interface which is highly user friendly, easy
to navigate and ensure fast loading of interface.

91. The system shall include formal and logical error checks and validation to
ensure the data integrity and quality.
92. It should also have inbuilt facility to send reminders and alerts based on target
dates of the user activities.
93.
The system should have a GUI based interface to create and maintain
calculation/validation rules.
94.
The system should have provision for instructions for data entry, in order to
guide users (online help and tool tip).
95.
Localization: ease to adapt or convert for use in a particular region local
language (other than the one it was originally developed for), including the
language of the user interface (UI), input, and display, and features such as
time/date display and currency.
6.7 ONLINE PORTAL (MIS WEB PORTAL)

Table 22: Online Portal Requirements
No. Requirement
96. The system shall have a functionality to broadcast general information and
announcements using MIS portal.
97. The system shall have a functionality to manage the content of the portal
displayed for public viewing (content management functionality).
98. The system should be able to generate ID and password for

beneficiaries/authorized third parties and allow them to view and query their
profile online using his/her secured login ID and password.

99. All functions in MIS are accessed using a Single Sign on through portal with
https implemented.

6.8 EMAIL NOTIFICATION
Table 23: Email Notification Requirements
No. Requirement
100. The system shall have a functionality to trigger email notification as defined
in the business rules parameters. For instance, MIS should be able to send
automatic email notification to the MIS users when
(i) user is created
(ii) password is changed
(iii) user is disabled etc.
101. The content of such email shall be user configurable.
6.9 QUERY AND ADVANCED SEARCH

Table 24: Query and Advanced Search Requirements
No. Requirement
102. The system shall provide simple and advanced query and search facilities to
all users or the system. The access privileges of user and group the user
belongs to must govern the scope of the information permitted by query and
limited in the search results.
103. The data generated because of selection of such query criteria should be
exported to MS-Excel; download and /or print in PDF format.

6.10 SIZING, PERFORMANCE, LOAD TESTING AND SCALABILITY
REQUIREMENTS
Table 25: Sizing, Performance, Load Testing and Scalability Requirements
No. Requirement
104. The system shall be capable of handling online functionalities for a database
of at least 8 million households with an average estimate of 5 individual
members under a single household.
105. The system processing shall be scalable to support the volume estimates for a
period of 10 years at a 10% annual growth rate.
106. The system shall be designed to handle an estimated two thousand

simultaneous connections (online users) when it is ultimately rolled out.
107. Page load time, login response-time, ‘on-click’ load time for the Portal should
be less than 3 seconds when the online MIS is accessed over the Intranet.
108. Average transaction response time, ‘On-submit’ response-time, or any other

database access/ search time should be less than 5 seconds when the MIS
solution is accessed over the Intranet.
109. Given the network infrastructure challenges in Ethiopia, the solution must
support low bandwidth and "near-no" bandwidth conditions for the services
defined in the functional requirements.
110. The solution should be highly scalable to accommodate current and future
requirements within the scope of the current program.

6.11 DATA BACKUP AND RECOVERY REQUIREMENTS
Table 26: Data Backup and Recovery Requirements
No. Requirement
111. The backup and restoration policy should be framed and provided based on
the resources and infrastructure available in Ethiopia.
112. The Firm shall be responsible for monitoring all backup of data that is stored
within the system in accordance with the backup policy during the project
period.
113. Shall implement the required backup solution for almost real time /
scheduled /automatic backups which should be monitored and reported.
114. Must implement data recovery mechanism in case of database failover.
6.12 TECHNOLOGY PLATFORM REQUIREMENTS

The technology platform to be adopted for the design and development of ISP MIS should
meet the requirements set out in table 22 below:
Table 27: Technology Platform Requirements
No. Requirement
115.
The solution must support industry standard enterprise RDBMS systems.

116.
For centralized MIS System:
Architecture: Web based
Back end: MS SQL (preferred)or equivalent enterprise level

RDBMS
Front end: Dot net/PHP/Java/ or its equivalent
Application Server: Internet Information Services/apache or its equivalent
Operating System: Windows Server/Linux or its equivalent
Interface Brower compatibility: Mozilla compatible/Internet Explorer/Google

chrome or its equivalent
6.13 ELECTRONIC DOCUMENT MANAGEMENT AND TRACKING

Table 28: Electronic Document Management Requirements
No. Requirement
117.
The system should have the functionality to upload scanned images and
maintain the history for future retrieval. For instance, the user should be able
to upload photograph of a beneficiary/household or any other relevant
supporting document (such as electoral ID card, birth registration certificate,
etc.).
118.
Such documents/images to be uploaded should have user definable document
category, for instance, photograph, electoral ID, birth registration certificate,
application form etc.

119.
The system should allow the user to enter specific supporting details like
attaching documents at all levels.
120.
Scanned images could be in the form of PDF, word, Excel, JPG files.
121.
The maximum file size to be uploaded should be user definable and validated
in order to restrict large file sizes upload.
6.14 HARDWARE INFRASTRUCTURE

The choice of hardware resources (such as desktop computers, handheld devices, and
laptops) should be guided by the application software requirements of the MIS.
Hardware and data transfer architecture is influenced by software needs as well as

contextual constraints. It is therefore important to:
 Scope appropriate hardware and modes of transfer based on needs and solutions
available in each context;
 Where possible make use of automatic online transfer data transfer mechanisms
where there is reliable connection and substitute with batch offline systems where
connections are not reliable;
 To avoid clogging bandwidth, transfer only specific data variables;
 Set up Virtual Private Network to ensure faster, dedicated and secure transfer of
data; consider advantages of using Computer Assisted Personal Interviewing
(CAPI) using PDAs or mobile phones (data validation in the field).

Table 29: An Analysis of Hardware Options
Model Technology Implementation Feasibility

PDA-based The beneficiary list is - The model requires a central - The PDA is portable and
Decentralized captured on a PDA database server and PDAs allows registration to be
Model (Personal Digital Assistant) available at the community done in real
on a real-time or near real- level.
time basis. The PDA is a Time. It merges several
portable computer that can - The PDAs are then configured technologies, thus reducing
be fitted with a rugged to send data to the national the costs of procuring
casing to protect it from servers using GSM/GPRS/ separate gadgets such as
harsh environmental EDGE/3G mobile phone laptops and cameras. It
conditions. Some PDA connectivity. comes with GSM
models also have smart card functionality, thus making
capability while others it possible to send data
from remote areas.
Scanners and cameras. - The disadvantage is that
PDAs can be loaded with an there are fewer developers
operating system such as who provide solutions
Windows Mobile and can tailored to this platform.
host applications such as There is also the risk of
standard MIS solutions. The data loss, but GPRS/EDGE
PDA’s battery can last for data transfer can reduce this
48 hours with continuous risk.
use.
Laptop- based The beneficiaries are The laptops loaded with the The laptop is portable but a
Decentralized registered on a laptop on MIS system are distributed to PDA is a lot lighter.
Model real time or near real time. the community level. The
Laptops are portable and information collected and Mobile registration is
relatively lightweight entered locally is then sent to therefore possible. There
computers. They can be the national servers via are many developers that
loaded with standard synchronization or connectivity provide solutions that run
operating systems and options. on this platform. The risk
applications software. associated with this model
Laptops have a rechargeable is that data will be lost
battery that can last for three through the theft or
hours with continuous use. breakdown of the
equipment.

Model Technology Implementation Feasibility
Desktop- based The beneficiaries are The desktops are installed with The use of paper reduces
Decentralized registered on paper forms. the MIS system at the district or the chances of data being
Model The information is then any other administrative level. lost because there is a paper
entered into the nearest Data are collected from the trail for the registered
desktop computer. beneficiaries using designed households. However, there
paper forms and are then is considerable duplication
entered into the nearest of effort in entering the
computer. If collected at the information both onto
local level, the data are then paper and then into the
forwarded to the district for computer.
consolidation and subsequently
to the national level.

6.15 TELECOMMUNICATION NETWORKS
Ethio Telecom, a telecom company under the Ministry of Communication and Information
Technology, Govt. of Ethiopia, is the sole agency responsible for providing the Telecom
and Internet Services in Ethiopia. Ethio Telecom is making all out efforts to not only
modernize and expand the existing communication network countrywide but also to
improve the quality of service and reliability, and to eventually provide the Telecom and
ISP services to its customers at affordable rates.
The complete communication infrastructure of WoredaNet, a Government network for e-

Governance, was provided by Ethio Telecom. WoredaNet, Government network for e-
governance, has been created by the Government and there are around 600 Woredas spread
across the country and other different Federal Level Ministries and Regional Level bureaus
connected to it. Each end location has fibre router (epon) or an ADSL router or a VSAT
terminal (only in the remote rural areas where reaching by fibre not possible) and they are
able to connect to each other using the MPLS cloud of the Telecom and ISP operator of
the country, Ethio Telecom.
The WoredaNet has National Data Center (NDC) at Prime Minister Office (PMO) at the
Federal level. There are 11 Regional Data Centre (RDC), one meant for each Region of the
country and provides services to the Regional bureaus of that region. The Woreda Data
Centre (WDC) at the Woreda level provides services to the Woreda level offices. The
WoredaNet spread across the country, is the backbone of the Government’s e-Governance
network with NDC, RDC and WDC becoming the main support centres.
Therefore, a social protection programme that is running a centralised web-based MIS

could easily decentralise and extend access to the system to users across the country by use
the WoredaNet or VPNs (virtual private networks).

7 SERVICES AND OTHER REQUIREMENTS
7.1 SYSTEM DEVELOPMENT APPROACH

During ISP MIS development, it is essential to plan the stages of the process — analysis,
design, development and implementation — carefully in advance. Some approaches to
developing software are faster than others and thus deliver the MIS solution more rapidly.
Several software development methods exist to streamline the software development

process and each one has its own benefits and drawbacks. We recommend that you first
decide on one development method or a combination development method. The following
are some development methods:
- Waterfall Method
- Prototyping Method
7.1.1 Waterfall Method

Figure 3: A Waterfall Model of a Software Development Lifecycle
Water-fall model is suitable for following situations:
- Project is large, expensive, and complicated.

- Project has clear objectives and solution.
- Pressure does not exist for immediate implementation.
- Project requirements can be stated unambiguously and comprehensively.
- Project requirements are stable or unchanging during the system development life
cycle.

- User community is fully knowledgeable in the business and application.
- Team members may be inexperienced.
- Team composition is unstable and expected to fluctuate.
- Project manager may not be fully experienced.
7.1.2 Prototyping Method

Figure 4: Prototype Enterprise Application Development Method
The following processes must be undertaken in sequence to ensure proper implementation

of the SP MIS in Ethiopia: Prototyping is suitable under the following situations:
- Project is large with many users, interrelationships, and functions, where project
risk relating to requirements definition needs to be reduced.
- Project objectives are unclear.
- Pressure exists for immediate implementation of something.
- Functional requirements may change frequently and significantly.
- User is not fully knowledgeable.
- Team members are experienced (particularly if the prototype is not a throw-away).
- Team composition is stable.
- Project manager is experienced.
7.2 SYSTEM REQUIREMENT STUDY/GAP ANALYSIS

A detailed system requirement study (SRS) of all the programmes at the beginning of the
project. SRS should be done not only taking existing business process flows into
considerations but also considering potential future requirements and possibilities. This is
meant to ensure that the MIS architecture should have the capability to scale up in future

as demands and requirements grows. The SRS should also evaluate the existing process
gaps so that MIS is able to streamline and strengthen the programme operations.
When conducting SRS, there should be close consultations with technical working group
(TWG). TWG is expected to facilitate requirement study and arrange meetings, discussions
with the relevant stakeholders.
Output:
The output of this activity is a comprehensive and consolidated System Requirement Study
Document of all the programmes based on the existing process flows, gaps and proposed
process improvements. SRS document should be reviewed/commented and signed off by
EWG.
7.3 SYSTEM DESIGN

Once the SRS document is approved, the next step is to conduct the System design for ISP
MIS. This entails documentation of the underlying database structure and reflecting both
backend architecture and front-end interface design. The System Design Document (SDD)
should also reflect the table definitions and overall database model of MIS that this
document could be used as a future reference document if needed.
Output:
The output of this activity is a comprehensive documentation of the System Design

Document based on the approved SRSD. It should be signed off by EWG.
7.4 MIS DEVELOPMENT AND PROTOTYPING

The next stage is the development of the system based on the agreed SRS and SDD using
the proposed technology framework. During this activity, an iterative development
approach is applied. The progress made in developing the system should be demonstrated
to the stakeholders on regular interval of time. This will ensure that the development efforts
meet user expectations.
Output:
The output of this activity is also the iterative prototyping of the developed application to
review and provide quick comments on the progress made during this activity.

A proper architecture is the key to develop a SP MIS; Tiered and properly architected MIS
must have the following attributes:
7.5 SYSTEM INSTALLATION AND CONFIGURATION

This activity involves installation and configuration of the system in the hardware/servers
allocated for MIS hosting.
Output:
System installation report that should be presented to the EWG.
7.6 SYSTEM TESTING

Once the system is successfully installed and configured, the next step is to perform the
MIS user testing. The TWG, including the operational staffs from MoLSA must participate
in system testing. Testing will be conducted to ensure that the system meets the business
requirements and is developed in line with the agreed system requirement and design
document. The contracted suppliers/developers must incorporate all the missing features,
functionalities and/or any bugs/errors encountered/identified during the system testing.
During this stage, the suppliers/developers are also expected to provide user training to
MoLSA staff.
Output:
The output of this activity is a fully functional MIS ready for final deployment and issuance
of User Acceptance letter issued by Steering Committee. At this stage, the following should
also be delivered:
- Prepare training plan.

- Prepare and delivery training manuals.
- Prepare and deliver core user training.
- Prepare and deliver technical training.
7.7 DATA MIGRATION AND DATA ENTRY

In case of data in electronic formats, migration plans should be put in place. This should
be undertaken in two stages. First migration for the purpose of system testing and validating
data accuracy and completeness and, final data migration when the system goes into final
deployment (Go LIVE).

Output:
The output of this activity will be electronic data migration into MIS platform
incorporating:
- Assessment of existing electronic data and formats;

- Development of data migration utility tools;
- Prepare final data conversion strategy;
- Final Data conversion/migration to the new system (MIS).
7.8 MIS USER TRAINING AND USER ACCEPTANCE TEST

MIS training is important for any successful implementation of the MIS project. The
developers/suppliers are expected to undertake a comprehensive training to the users of the
MIS at various levels with an aim of ensuring that MoLSA staff are able to use the system
independently and perform various transactions as desired. From the outset, the developers
are expected to draft a Training Plan for acceptance by the TWG outlining the training
activities, audiences, number of participants, curriculum, etc. to be completed during the
project period. It is anticipated that a “train the trainer” approach would be adopted.
 The developer is expected to develop a MIS user-training programme for the

following personnel;
 Users of SP programmes: The target audience of such training programs are users
such as the staff at the Woreda, Region and Federal level, employee as a normal
user, other senior authorities and management staffs, among others.
 System Administrators: The MoLSA will nominate members of staff to undergo
training in System Administration, database management and administration.
Outputs:
- Prepare training plan.

- Prepare and delivery training manuals.
- Prepare and deliver core user training.
- Prepare and deliver technical training.
- Conduct training.
- Gather and evaluate training feedback.
- Finalize operational acceptance criteria.
- Handover of all the deliverables as outlined in the key deliverable section.
- Obtain User Acceptance Test.

7.9 FINAL DEPLOYMENT (GO LIVE)
The final deployment will commence after the issuance of user acceptance test and when
the final successful data migration into MIS takes place. During this stage, the developer
is expected to assist and provide technical guidance to MoLSA to ensure its smooth
operation and facilitation in final deployment.
Output:
The output of this activity is the operationalization/implementation of SP MIS.
7.10 SYSTEM WARRANTY AND MAINTENANCE SUPPORT SERVICES

The system warranty and maintenance support services shall be for a period of 24 months
effective from the issuance of user acceptance letter. During this period, the developer must
ensure that all issues encountered, such as bugs/errors and functionality change request
must be resolved on timely manner and support the smooth operation of the ISP MIS. The
warranty period should cover all minor feature enhancements, customizations, addition of
reports in MIS as demanded by the users as long as it is within the scope of the covered
programmes.
Output:
The output of this activity is to support MoLSA in ensuring the smooth operation of the SP
MIS and timely resolution of any bugs/errors encountered during the period, including
incorporation of minor enhancements, addition of reports etc. Specific tasks of the
Developer support staff include:
 Bug/error fixing/installation of patches, upgrades etc.

 Addition or incorporation of more/new functionalities as long as it fits within the
scope and nature of the program;
 Conducting regular user training in English language as required;
 Overall system management, supervision and monitoring to ensure its smooth
operation and implementation;
 Establishing proper data backup and support mechanism to assist users to
effectively operate the system without any technical problems;
 Provision of in-depth technical support and guidance during the data entry, update
process;
 Building MoLSA internal technical capacity to gradually take over the system
before the contract ends.
 Performing the duties and tasks related to program scope as requested by MoLSA.

7.11 SYSTEM OWNERSHIP AND SOURCE CODE REQUIREMENTS
On average the useful life of computer hardware is five years. Conversely, software
technology evolves rapidly. Yet, the two — software and hardware ‒are both important
MIS components. When policymakers are deciding what type of application software and
source codes (either proprietary or open-sourced) to use, they need to take into account any
potential technological changes in software.
For example, if they decide to procure proprietary software, then they may wish to enter
into an escrow agreement with the software developer in which an independent trusted
third party – e.g. banks or law firms — would receive and store MIS source code in case
the supplier goes out of business. This would ensure the continuation of support and
customisation of software by another entity should the developer become insolvent.
Table 30: System, Ownership and Source Code Requirements
No. Requirement
122. GoE will fully own the MIS platform without any preconditions whatsoever.
123. The Developer shall handover all the source codes and technical documentation of
the system without any preconditions.
124. For any other proprietary third party software used, the developer shall provide
perpetual and valid license for at least period of 5 (five) years.

Annex 1: SP-MIS Indicator Matrix selected from log frame of SP Sector– Monitoring Progress (To be completed)
Sample MIS Indicator Matrix selected from log frame of PSNP-IV
Results Indicators Actual result (and where Annual target 2015/16 % of annual target realised
available historical data) to date
Support for Direct project beneficiaries 7200000 7200000 -

building core (Number)- (Core)
instruments and
Female beneficiaries (Percentage- 3600000 3600000 -
tools of social
protection and Sub-Type: Supplemental)- (Core)
DRM systems, -
Beneficiaries of Safety Nets programs 7200000 7200000
(number) (Number)- (Core)
Delivery of Average net number of months of 3.20 -
safety net and house hold food insecurity (Months)
enhanced access
% increase in average value of -
to livelihoods
services for household assets (Percentage)
vulnerable rural 0.00 10.00
households, %of clients who receive community- -
based nutrition counselling services
(Percentage)
40.00 50.00
%of clients reporting that they can -
provide adequate meals for their
family for12 months a year
(male/female) (Percentage)

Results Indicators Actual result (and where Annual target 2015/16 % of annual target realised
available historical data) to date
0.00 10.00
%of clients receiving regular -
payments within the agreed time
frame (20 days for cash and 30 days
for food) (Percentage)
60.00 70.00
%of clients receiving contingency 0.00 -
resources within
60 days of identification of need
(Percentage)
65.00
%of client households reporting that -
their livelihoods has benefitted from
public work created assets
(male/female) (Percentage)
20.00 20.00

8 BIBLIOGRAPHY
Ayala, F. (2014) Assessment of the PNPS Targeting System and Feasibility Study for moving
into a National Household Registry. Draft Report.
Barca, V. and Chirchir, R. (2014) De-mystifying data and information management concepts,
Department for Foreign Affairs and Trade (DFAT): Canberra, Australia.
Chirchir, R., and Kidd, S. (2011) Good Practice in the Development of Management Information
System for Social Protection: Pensions Watch, Briefing 5. HelpAge International, London.
Government of The Federal Democratic Republic of Ethiopia, (2014). National Social

Protection Policy. Addis Ababa, p.19.
Government of the Federal Democratic Republic of Ethiopia, (2012). Software Quality

Assurance Guideline for Development and Purchase of Enterprise Application Software for
Enterprise Architecture of FDRE.
ISO. (2013). ISO/IEC 27001 - Information security management. [online] Available at:
http://www.iso.org/iso/home/standards/management-standards/iso27001.htm [Accessed 31 May
2016].
National Social Protection Policy of Ethiopia, (2012). Monitoring and Evaluation System, p.21
[online] Available at: http://phe-ethiopia.org/resadmin/uploads/attachment-188-
Ethiopia_National_Social_Protection.pdf [Accessed 31 May 2016].
UNICEF. (2016). Fatima Yesuf, 25, brings her 8 months old daughter to the Metiya health center
for checkup and to receive the Plumpynuts food supplements. Retrieved from:
https://www.flickr.com/photos/unicefethiopia/26912340384 [Accessed 8 June 2016].
WoredaNet-Ethiopia Government Network, (2016). [online]. Available at:

http://unpan1.un.org/intradoc/groups/public/documents/un-dpadm/unpan034887.pdf
- - 60

MIS Guideline For SP in Ethiopia Final 09062016

Uploaded by

Copyright:

Available Formats

You might also like

MIS Guideline For SP in Ethiopia Final 09062016

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MIS Guideline For SP in Ethiopia Final 09062016

Uploaded by

Copyright:

Available Formats

© UNICEF Ethiopia/ 2016/Tesfaye

Expert Working Group

MIS Guideline for SP Programmes in Ethiopia Page ii

MIS Guideline for SP Programmes in Ethiopia Page iii

3.2 Proposed Model of Integration .............................................................................. 7

4 Administrative and Institutional requirements ................... 12

4.2 Administrative Structure and Decentralization .................................................... 12

4.2.1 Woreda Level ....................................................................................................... 13

4.2.2 Regional Level ..................................................................................................... 14

4.2.3 National Level...................................................................................................... 15

4.3 Decentralised operations of programme MISs..................................................... 16

4.3.1 Federal and Regional MIS ................................................................................... 16

4.3.2 Woreda MIS ......................................................................................................... 17

4.4 Staff Availability and Capacity............................................................................ 17

5 Business functional requirements ....................................... 18

5.2 FUNCTIONAL REQUIREMENTS .................................................................... 21

5.2.1 Registration, Targeting and Enrolment ................................................................ 23

5.2.2 Payments and Reconciliation ............................................................................... 25

5.2.3 Graduation/Exit .................................................................................................... 26

5.2.4 Funds Flow Management ..................................................................................... 26

5.2.5 Grievance/Case Management .............................................................................. 27

5.2.6 Reporting ............................................................................................................. 28

5.2.7 Monitoring and Reporting Indicators................................................................... 29

5.2.8 Business Intelligence Tool ................................................................................... 34

MIS Guideline for SP Programmes in Ethiopia Page iv

6.2 Information and Data Security ............................................................................. 36

6.3 Data Security, Access and Authentication Requirement ..................................... 37

6.4 System Audits for Data Security.......................................................................... 39

6.5 Data Exchange Protocol and Data Exchange Mechanism ................................... 39

6.6 User Interface Requirements................................................................................ 40

6.7 Online Portal (MIS web portal) ........................................................................... 41

6.8 Email Notification................................................................................................ 43

6.9 Query and Advanced Search ................................................................................ 43

6.10 Sizing, Performance, load testing and Scalability Requirements ........................ 44

6.11 Data Backup and Recovery Requirements........................................................... 45

6.12 Technology Platform Requirements .................................................................... 45

6.13 Electronic Document Management and tracking ................................................. 46

6.14 Hardware Infrastructure ....................................................................................... 47

6.15 Telecommunication Networks ............................................................................. 50

7 Services and other Requirements ....................................... 51

7.1.1 Waterfall Method ................................................................................................. 51

7.1.2 Prototyping Method ............................................................................................. 52

7.2 System Requirement Study/Gap Analysis ........................................................... 52

7.3 System Design ..................................................................................................... 53

7.4 MIS Development and prototyping ..................................................................... 53

7.5 System Installation and Configuration................................................................. 54

7.6 System Testing..................................................................................................... 54

7.7 Data Migration and Data Entry ............................................................................ 54

7.8 MIS user training and User Acceptance Test....................................................... 55

MIS Guideline for SP Programmes in Ethiopia Page v

7.10 System Warranty and Maintenance Support Services ......................................... 56

7.11 System Ownership and Source Code requirements ............................................. 57

MIS Guideline for SP Programmes in Ethiopia Page vi

MIS Guideline for SP Programmes in Ethiopia Page vii

As in many developing countries, such as Ethiopia, attempt to design and implement

Therefore, to develop well established and comprehensive programme management

Box 1: General definitions of SP MIS concepts