Implementing Microfinance Information Systems

clearsleepingbagSecurity

Nov 30, 2013 (3 years and 6 months ago)

196 views

Forum sur les politiques réglementaires de la
microfinance en Afrique

Kigali, Rwanda

25


27 mars 2009




Implementing Microfinance Information Systems


Loretta Michaels

Technology Consultant, CGAP

February 8, 2012




2

2

CGAP is an independent policy and research center dedicated to
advancing financial access for the world's poor
.


It is supported by over 30 development agencies and private foundations
who share a common mission to alleviate poverty.


Housed at the World Bank, CGAP provides market intelligence, promotes
standards, develops innovative solutions and offers advisory services to
governments, service providers, donors, and investors.

At a glance:


7

locations: offices in Washington
DC and
Paris,
with 5
regional
representatives based in Abidjan, Dhaka,
Moscow, Nairobi, and
Ramallah


~50 staff


~70
countries with CGAP activities


150,000+ copies of CGAP publications distributed
annually

CGAP: Who we are

3

CGAP Technical Guide: Information Systems


Developed by CGAP’s IS Program, an initiative of CGAP
and the EU/ACP Microfinance
Programme



Practical guide, templates, and tools to help MFIs and
other financial institutions make the best technology
decisions for your institution.



Available at www.cgap.org/publications


3

4

Selection

Project Preparation

Needs Analysis

Introduction

Implementation

5

Selection

Project Preparation

Needs Analysis

Introduction

Implementation

6


The number of
MFIs

still using manual systems is dropping, to
below 18%*, as
MFIs

acknowledge benefits of improved IS



Growing interest amongst
MFIs

in new technologies to improve their
outreach and customer service


Mobile banking, ATM kiosks, smart cards, biometrics, hand
-
held
devices, tablets



What’s often holding
MFIs

back on these new technologies is
limitations in their own back
-
end systems



Keen interest in implementing upgraded IS, but concerns about
cost/ROI and need to do it right the first time, save future headaches


Why Are We Here?

* CGAP 2009


CGAP has released a technical guide to assist in implementation
of MFI Information Systems

7

What

a good

IS can


and
cannot
-

do for an
MFI’s

sustainability


Focus on profitability


Quality loans


Provision for loan loss reserve


Community accepted and
appropriate accounting
procedures


Gathering and reporting of
accurate and timely information




Increased productivity and
efficiency


Lower transaction cost per loan


Greater outreach in rural and
urban areas


Faster delivery of more products
and services


More accurate and timely
reporting


Better decision making

NO

YES


An IS is not a substitute for good business practices

8


Reinforces discipline in accounting and portfolio tracking


Can link all data pertaining to a customer or customer group hence
provide a consolidated view of each customer or group


Allows for single entry of data that can then be used by many people.
Data once entered can be accessed, manipulated and used by all
users. Thus MIS reduces duplication of effort and increases speed of
work.


Integrates information and process


Supports workflow and procedures for users


Can be ported to remote areas via laptop or mobile technology


Applications can be customized or enhanced to support new
products and institutional growth

What are the key uses for IS?


Important to view IS as an investment, not just a cost

9


WHO:


This isn’t “just” an IT project


Information Systems impact ALL business units and operations in
an organization, and implementation requires input and
involvement from across the organization, along with senior
management support


WHAT:


Information Systems (IS) capture and store data, process data to
produce meaningful and relevant reports, and support operations
by enforcing defined processes and providing an audit trail.


WHY:


Information Systems “embed” an institution’s business processes
and support its products and services.


How these systems are designed and implemented has a direct
impact on business outcomes

Where does IS
Implementation Fit Into Overall
Operations?


IS needs to be an enabler of
-

and be driven by
-

the organization’s
overall strategy

10

Asset mgmt

Treasury mgmt

REPORTING

Financial reporting

Management
reporting

FINANCE & ACCOUNTING

ADMINISTRATION

Finance

Accounting

Chart of
accounts

HR administration

Payroll management

Share mgmt

Regulatory
authorities
reporting

Sub
-
ledger
updates

Accounting GL

Operational
reporting

Budget mgmt

LOANS

SAVINGS

Solidarity
groups

Savings account

Current account

TRANSFERS

Collateral mgmt

Credit Scoring

Individual loans

Overdraft account

Term deposit

Planned savings

Group savings

Guarantor mgmt

OTHERS

PRODUCTS AND SERVICES

PLATFORM/INFRASTRUCTURE MANAGEMENT

Archive
management

Backup and
restore

Configuration
management

Hardware
management

Network
management

User/Passwor
d admin

Interbranch

Interbank

International

Batch

Payment card

Check mgmt

Foreign exchange

Insurance

Client information
management

Customer Relationship
Mgmt (CRM)

CLIENTS

Potential client information
management

ATM

Mobile

Banking

POS

Teller mgmt

PDA

DELIVERY
CHANNELS

BACK OFFICE

FRONT
OFFICE

What’s Usually Included in an IS System?

11


Project Preparation



Needs Analysis



Selection



Implementation



Management

Key Steps to Consider in Implementing IS

12

Selection

Project Preparation

Needs Analysis

Introduction

Implementation

13

2.1 Articulate the Business Objectives


Define the business problem


Define goals & objectives


Assess risks


Agree outcomes with top management


2.2 Secure Resources to Execute Project


Form Steering Committee


Form PMO


Develop preliminary budget


2.3 Establish a Plan


Gather documentation


Develop Change Management Plan


Draft Project Plan

Project Preparation


Do This First!


Need to develop a clear understanding of the problem (
s
) to be
addressed, expected outcomes, potential risks & resources needed

14

Project Preparation


Articulate the Business
Objectives

Key questions to answer:



Why are you doing this?


What is the business problem you’re trying to address?


What do you expect to gain from this project?


What’s going on in the business environment that you need to
consider (competition, changing customer demand, regulation,
donor requirements)?


What sorts of functionality and capacity are you looking for?


What processes will be touched here, what can change, what can’t
change?


Any technical limitations?


What are the overall goals and objectives?


What risks do I anticipate that will impact schedule, scope or
resources?


Target here is to agree realistic goals & outcomes with senior
management and obtain the resources needed to execute

15

Project Preparation


Articulate the Business
Objectives


FairFund

Example



The specific goals of the new
FairFund

IS system are to:



Limit
FairFund’s

risk for further fraud


Enable management to project their cash flow needs two to
three months in advance


Enable better management of portfolio quality, even in times of
aggressive growth (branches, staff, loans, products)


Enable more flexibility and better tracking of the new individual
loan product and future savings
product(s
)


Important to develop indicators to measure the progress of these
goals

16

Project Preparation


Steering

Committee &
PMO


Steering Committee


A cross
-
functional team ensures institution
-
wide acceptance and
that everyone’s needs are incorporated into the effort



Made up of senior management from across organization


Ensures project is meeting intermediary targets


Provides forum to evaluate critical issues


Makes decisions & provides direction to PMO


Project Management Office (PMO)



5
-
8 people, IT staff & business unit staff, led by senior or mid
-
level
manager


Responsible for implementing Project Plan & managing day
-
to
-
day tasks


Engages with staff across organization to solicit input & guidance


Responsible for change management via regular communications

17

Project Preparation


Establish

a Plan

Key Steps:


1.
Gather existing documentation


Does documentation even exist around policies and procedures??


Are policies and procedures consistent across the organization?


How can we inform vendors of what we need if we don’t have the
information ourselves?



2. Develop change management plan


Who needs to buy
-
in to this project?


What are their issues and concerns?


What needs to be communicated with which stakeholders, by
whom, and how often?


3. Draft project plan


Be sure to outline anticipated costs, timing, interdependencies
and decision points


Do your homework early on and don’t underestimate the need to
continually get buy
-
in across the organization

18

Project Preparation


Draft Project

Plan

Example Table of Contents:


1)

Steering Committee and PMO membership

2)

Project goals and objectives

3)

Preliminary budget (hardware, software, implementation and
maintenance)

4)

Risks and mitigating actions

5)

Change management/communication plans

6)

Project timeline and major tasks, including deliverables and
persons responsible



Plans can change, but it’s important to have guideposts and targets
for measuring project success

19

Project Preparation


Key Takeaways


Establish a clear plan to execute the project


Complexity of IT projects demands good planning



Drive for clarity on project goals and be realistic about the
resources available


Need to set reasonable expectations



Staff buy
-
in across all key business units is critical


Regular communication with all stakeholders is key



Understand the institution’s threshold for tradeoff between cost
and scope


Plan for all possible scenarios and expect need for tradeoffs


Good preparation now won’t completely eliminate future problems,
but will ensure they can be easily dealt with

20

Selection

Project Preparation

Needs Analysis

Introduction

Implementation

21

Needs Analysis

3.1 Define Requirements


Existing products and processes


New products, processes and channels


Operational requirements and technical specifications


Additional considerations


3.2 Prioritize requirements


3.3 Obtain sign
-
off




The needs analysis is the single most important aspect of the
project!

22

Needs Analysis


Why is this critical?


A needs analysis forms the basis of an RFP
requirements
document
, which will be an integral part of any vendor contract



Conducting the needs analysis forces you to conduct in
-
depth
analyses of your existing processes and helps expose
opportunities for improvement and streamlining



Business unit/stakeholder input here will give you a reality check
on how things “really” happen in your organization today, and
helps ensure buy
-
in down the road



A good needs analysis takes time, but will result in better services,
prices and products






Poor inputs here will affect the rest of the project

23

Needs Analysis


What makes

a successful
requirements document?


Emphasize the aspects that are key to the institution’s core
processes rather than attempt to define all functional points in
detail


Allows you later to adapt non
-
core functions to the solution
rather than look for a solution that does everything you need
(
hint: it doesn’t exist
)



Be flexible and avoid being too prescriptive


Detail
what
the institution wants to achieve, not necessarily
how


vendors often know solutions you haven’t thought of



Be specific and comprehensive, avoid unnecessary detail


Want to ensure vendors focus on the important stuff






Focus your energies on what you absolutely “must” have rather
than all the “nice to haves”

24

Needs Analysis


How do you begin to define
requirements?

Key Categories to Consider:


1.
Functional requirements, now and in future


Tasks, processes, inputs, outcomes, information generation


2. Operational requirements


Controls, security, parameters


3. Technical requirements


Integration with legacy systems, centralized vs. decentralized
architecture, in
-
house vs. hosted, existing dbases, scalability,
redundancy





No single person or team will know the requirements for the whole
organization


need everyone’s input to do this right

25

Type of Requirements

Tools

Responsible

Functionality Requirements


existing products, processes,
channels

Business Process Mapping


Interviews with staff

Business owners, department

managers


PMO

Functionality Requirements


new products, processes,
channels


Business Plan/strategy
documents


Interviews with management

Business owners, department

managers


PMO


Steering Committee

Operation Requirements

Operations manual


Internal audit manual


Interviews with staff and
management

Business owners, department

managers


PMO


Steering Committee

Technical Specifications

IT strategy


Technical environment
questionnaire

IT team

Needs Analysis


Resources for
r
equirements

gathering

26

Needs Analysis


Business Process Mapping

Process mapping
gathers
,
organizes
, and
displays
facts about an
organization’s current processes, so that knowledgeable people can
study and streamline them. The key steps include:


Process identification
--

attaining a full understanding of all the steps of
a process and all the processes in a business.


Information gathering
--

identifying objectives, risks, and key controls in
a process.


Interviewing and mapping
--

understanding the point of view of
individuals in the process and designing actual maps


Analysis
--

utilizing tools and approaches to make the process run more
effectively and efficiently.




Key questions to ask when starting out are whether process maps
already exist and whether they reflect current reality

Pass Book

Pass Book

Customer

Deposit Slip

Deposit Slip

27

Needs Analysis


What should process
mapping

tell you?


Where are data collected? By whom?


Where are data entered into a computer or manually
aggregated?


How does that information flow to the next process?


Who needs what information and when?


What decisions need to be made? By whom?


A key aspect of any process mapping is to validate the processes
with the staff who actually do the work


What information is required to make those decisions?


When do the decision makers need information and in what
format?


Where is information stored? Are copies made? Where?


Where are the leverage points and critical processing points
where the process could be improved, for service &/or
efficiency purposes?

28

Needs Analysis


One simple mapping
example


A good process map doesn’t need to be complex, it just needs to
accurately reflect what happens at each step

Front
Office

Board

MIS

Exec
Dir

Region

Finance

Over
10,000?

Over
1,000?

HQ


Centralized operations:
MFI processes all loans at the head
office in Lagos regardless of value. Loan applications are
collected by officers on a daily basis then taken to the regional
office and then sent to the head office via courier.


Highly manual, paper
-
based process
: paper applications are
sent to the regional offices and via courier to head office for
processing then sent back. At head office, documents are
moved from the front office to the current MIS and finally to
finance before they are sent back via courier to the regional
offices.


MIS with inadequate controls to prevent fraud
: MFI acquired
microfinance software called
GREATMIS
. The software covers
the following areas: 1: members management, 2: loan
processing, disbursement and collection, and 3: finance. The
software as currently implemented has weak controls,
esp

around loan disbursement and collection.


Frequent inaccurate reporting to clients
: based on findings
from the member groups visited, members get periodic
inaccurate statements and schedules generated by the software.


29

Needs Analysis


What about future needs?


Any functionalities anticipated for future
operations?



Bear in mind tradeoffs between flexibility for future needs and costs
of building in that flexibility (e.g., modular platforms)


What sort of growth plans do you have?


Geographic expansion?


New products and services?


Any firm partnership plans that will
impact your needs?


30

Needs Analysis


Are new channels planned
for the future?

Regional, full
-
service branches

ATMs

Mobile Vans

Satellite branch

Kiosk in
market

Mobile Banking

Agents

31

Needs Analysis


Don’t ignore
o
perational

requirements

Back
-
office, non
-
product related processes are just as important as
the main functional requirements:


Want to make sure you can manage the system and get the
information you need WITHOUT vendor support


Cash management in branches and
headquarters


Closing operations at end of day in branches


Operations reports


types, who can generate,
data archiving


Setting and management of parameters and
adding new parameters (e.g., new branches,
new reports)


Internal audit requirements


User management, defining and managing roles
and authorities

32

Needs Analysis


Technical specifications


Integration with legacy systems


Network architecture (e.g., centralized
vs

non
-
centralized)


Hosting environment (Licensed model,
SaaS
?)


Technical environment (operating system, links to databases)


Other specs? Processing speed, time, offline/batch data entry


Growth and scalability requirements


Bear in mind current systems and future evolutions (e.g., open APIs,
open source tools)

33

Needs Analysis


Centralized
vs

Decentralized


More complex doesn’t always mean better


need to consider
system
-
wide environment and needs

Centralized

Decentralized

Description


䅬氠扲慮b桥h 湥nw潲o敤e慮搠
牵r

f牯r c敮e牡汩le搠s敲e敲e☠
摢慳d


卹st敭 t桡h 牵湳 扡bk
-
潦f楣攠
慣t楶楴楥i 慴

e儬 w楴栠f楥汤i
潰敲慴楯os 牵渠m慮畡汬a 潲o潮o
汯l慬as敲e敲e


偲潳


o敡e
-
t業攬

n
整w潲o
-
w楤i

慣c敳s t漠摡da


却牥慭汩湥搠syst敭
m慮慧敭敮e f牯r 潮攠汯l慴楯i


卩p灬敲I m潲攠牯扵rt
contingency policies &
measures


卩p灬楦楥搠畳敲em慮慧敭敮e
☠灲潦楬敳


F慳t敲e異杲慤敳


䱥is 數灥湳pve


Doesn’t depend on reliable
connectivity or electricity


䅬汯As m潲攠f汥l楢楬楴y f潲o
汯l慬汹
-
摲楶敮es潬畴楯湳


Cons


M潲攠數灥湳pve


o敱畩牥e 牥汩慢汥

楮i敲湥e
connection & bandwidth


Can be more expensive to
support WAN


o敱畩牥e sk楬汥搠fT st慦f


䱯湧敲

t業攠t漠c潬污o攠syst敭
-
w楤攠摡d愠f潲os整t汥l敮tI
analysis


Harder to link to other
networks (ATM, mobile money)


34

Needs Analysis


Software as a Service
(
SaaS
)?


In
SaaS
, a vendor hosts and maintains the system, offers it to
customers via an internet connection on a subscription

based pay
-
per
-
use model


Lots of benefits:


Can be cheaper, easier, faster to implement,
BUT…


Some downsides, too:


Requires regular internet & electrical connectivity


Currently fewer choices out there


Can get very expensive with rapid scaling


Limits your control over system and access to raw data


Less flexibility in terms of new features and customization


Service Level Agreements (
SLAs
) are critical in a
SaaS

solution



Helpful to conduct a 5
-
yr TCO comparison of licensed vs.
SaaS

solutions

35

Needs Analysis


Other considerations


Be comprehensive about your needs but be flexible, know your
priorities, and keep tradeoffs in mind


Staff capabilities


IT management


is a strong team there already?


Are IT staff able to do standard maintenance & management?


User capabilities


Are most staff comfortable with computers, both at HQ & branches?


How much training will be required and who will give it?


Understand security needs and have various levels


Make sure there’s a local service provider for after
-
sales service (or
a willingness to create one)


Don’t tie your MIS to an NGO, donor or other TA provider


If you sever those ties later you don’t want to have to change your MIS


Your business environment


Specific language/script requirements? Currency?


Regulatory & donor reporting needs?


Links to other systems such as mobile payments, or a credit bureau?

36

Needs Analysis


Prioritization

is critical to
success of the project


The more functions you deem essential, and the less you’re willing
to change some processes, the more the system will cost


When will the various functionalities be needed?


How willing are you to consider changes to your lending and
institutional policies and work processes to accommodate a new
system?


What additional skills are needed to run the system, and how will
staff competencies be improved to effectively use the system?


How will you support and maintain the system?


Will you need additional infrastructure to support the new
functionality? What is the cost benefit of the infrastructure versus
the functionality?

37

Needs Analysis


Key Takeaways


A good needs analysis takes time now but will save cost and time
later


Maintain focus on the stated project objectives


Don’t let scope creep take over



There is a tradeoff between functionality and cost


Prioritize functionalities and be willing to change some of your
processes if necessary



Strive to be specific and comprehensive


But not overly detailed


let the vendor help you think through
solutions, some of which might not need technical fixes



Ensure adequate sign off by the necessary parties


Plan for all possible scenarios and expect need for tradeoffs

38

Selection

Project Preparation

Needs Analysis

Introduction

Implementation

39

Selection


Don’t underestimate the value of a proper procurement process


be
clear and consistent about your methodology

4.1 Prepare the Tender



4.2 Issue Request for Proposal


4.3 Evaluate Proposals and Award Tender


Develop short
-
list for further evaluation


Attend demonstrations by short
-
listed bidders


Make recommendation to steering committee


4.4 Negotiate contracts with sufficient leverage to ensure successful
delivery


Software license


Implementation support


Ongoing maintenance and support



40

Selection


The “typical” RFP


There’s no single standard RFP. Just remember: Garbage In,
Garbage Out.

1. Institutional Overview of MFI and Operating Environment


Mission, background, purpose and scope of project


Business process maps of current processes


Summary of reports


Technical environment


2. Response Guidelines


Vendor profile, credentials, references


Solution overview, including product history, technical specifications, network
architecture recommendations, and options


Pricing for license, implementation and ongoing maintenance


Pricing and process for implementation and support


RFP submission and for response (when and how to submit)


3. Evaluation Methodology


Quantitative


Qualitative


4. Requirements Document


41

Selection


A
Fairfund

Example from
Framework Document


Want to clarify all your needs with comments

42

Selection


A
Fairfund

Example from
Framework Document


Don’t be afraid to raise questions here or ask for suggested
solutions

43

Selection


Clearly articulate the RFP process


Want to make sure the process is as transparent as possible


Besides sending directly to selected vendors, post RFP on
website, local & international papers, relevant industry sites


Provide enough time for proper responses


Set up process for vendor questions (clear rules, timeframes,
types of questions, how to submit) and provide answers to all
vendors


Request further info from vendors if interested


Contact references


Determine short list of vendors


Plan demonstrations of their systems






44

Selection


What do you want out of a vendor
demonstration?


Be as thorough as possible with a demo


you have to live with this
system for a long time


Determine in advance what you want to see (develop test script)


Examples: open new account account, generate reports, post
payments, set up new loan product, query on various
parameters, set up new user


If possible, send sample of
MFI’s

data to vendor for demo (e.g.,
products and services, copies of loan agreements, key reports)


Have vendor walk through core functionality, user
-
defined
functionality and any interesting out
-
of
-
scope functionality


How do current forms (e.g., passbook) fit into system capabilities


What end
-
of
-
day procedures are needed by IT department


How does system handle exceptions


Does system run well in YOUR specific environment (e.g., minimum
connectivity, load testing)

45

Selection


S
oftware

licensing


Be very clear about what you want and what you’ll get for your
money


sorting it out “later” is an expensive option


Software licensing is not a product purchase, it’s a
right to use


Typically means price per user or per range of users


Issues to address include:


Is the license indefinite, or for a fixed period of time?


In price per user, is it per
named user
, or per
concurrent user
?
Not everyone who uses the system will use it at same time


Is there a copy of the software in escrow to protect the MFI?


Clarify what’s included in the license fee and what’s not (e.g.,
customization or upgrades, translation)


What’s involved in implementation support? (project management,
training (user & IT staff), data migration, user testing, etc.)


Maintenance & support: be sure to outline a specific and
comprehensive service level agreement (SLA) that covers types &
amount of support, issue resolution & escalation, timeframe, etc.

46


Get professional help with defining the technical specifications


Use outside, third
-
party evaluators?


Vendor should have a strong tech background AND interest in
microfinance


Speak with current and former clients of the vendor (
s
)


Make sure you integrate your portfolio and accounting data/software


Understand safety and redundancy of your data in a remote server
situation (
eg
, web
-
based or
SaaS

system)


Vendor should train staff, should also be there for
implementation/switchover


If migrating from one system to another, run both in parallel for a while
until staff is comfortable with new one (but not too long)

Selection


S
ome

suggestions

47

Selection


Key takeaways


The value & importance of a competitive process cannot be
overstated!


Design the evaluation methodology to find the best solution for the
institution’s
business
needs, not just the best technical solution


Reduce risk by conducting a thorough product demonstration and
contract negotiation


Be prepared to adapt some processes to the new IS solution

48

Selection

Project Preparation

Needs Analysis

Introduction

Implementation

49

Implementation


Time to transition the solution from a plan to a functioning system

5.1 Develop the Implementation Plan



5.2 Implement system and conduct user acceptance tests (
UATs
)


5.3 Conduct data migration


Design switchover strategy


Identify key risks


Migrate data


5.4 Close the project




50

Implementation


Develop Implementation Plan



No two implementations are the same, even with the same system


Project management and communications


Timing, LOE, resources, communications plan, PMO schedule, risks,
measurement


Hardware, system software, and infrastructure


Hosting arrangements, H/W, S/W & I/F requirements for HQ and branches,
configurations, power/connectivity, facilities


Configuration and parameterization


Interface with vendor


Customization


Prioritize, manage vendor deliverables, test scripts


Changes to business processes


Document, test, align, communicate


User acceptance tests


Develop test cases, conduct & measure


Training


Develop materials, determine formats, identify resources


Rollout


Determine strategy: who/where/when/how


51

Implementation


Implement & Conduct User
Acceptance Tests (
UATs
)



UATs

should involve a cross
-
section of users, not just IT staff


Design tests that touch on all the functionality of the system, across
the different areas of the institution that need to use it


Best to involve actual users to design & sign off on test cases


Test cases should be consistent with business, operational and
technical requirements used in the selection process


Typically created from the specifications document


Conduct tests in controlled environment, not a live system


Decide how UAT results will be dealt with and communicated back to
vendor (accept as is, require changes, other issues that surface, etc.)

52

Implementation


Data
Migration



Assume issues will come up during migration


this isn’t a bad
thing


Decide your switchover strategy


Which data will be migrated? (active vs. closed)


Manual vs. automated


Phased
vs

“big bang”


All data or subsets, by levels, regions or branches


Typical phases would include:


Transitioning existing core operations from old system to new


Incorporate systems & modules that were previously standalone


Initiate new modules or features


Bear in mind issues like fiscal year
-
end when timing transitions


Identify key business interruption risks and have plan to address


Track, prioritize and manage pending issues

53

Implementation


Phased vs. Big

Bang



Running parallel systems might seem less risky than an immediate
switchover, but it brings its own problems


Want to minimize period of having two systems running


Staff capacity to run two systems is limited and may result in
preference for old system


Reconciliation between two systems becomes a problem over
time, either because staff are getting lazy with 2
nd

system or two
systems use slightly different allocation or rounding methods


Best time to run parallel systems is during UAT


Customizations more likely to have errors than standard features


Once bugs worked out, best to switchover and force staff to use new
system


54

Implementation


Key Takeaways


Don’t let the team go before Implementation is complete


you may
discover issues that require more work


Develop and follow a detailed implementation plan



Invest in a thorough UAT process, involving a range of staff who
will use the system in a variety of ways. If part of the system
involves customer input, involve some customers as well.



Minimize running the old and new system in parallel any longer
than necessary.


55

Close the Project



The project might be closed, but the management of the system is
just beginning


Ease the transition


Comprehensive training


User guides


Solicit staff feedback


Optimize the system


Conduct periodic process reviews


Hardware assessments


Additional applications


Maintain the system


Develop a management plan


Updates

56

Management

and Evolution


Loan capital can be replaced with insurance, the loss of client data
(and goodwill) cannot


Ongoing Evaluation


Are workflows aligned with software?


Any new needs, or underutilized capabilities?


6 months, annually


Maintenance


Regular backup (daily, weekly, monthly, quarterly)


Off
-
site storage, recovery plans, regular updates & issue
resolution


Optimization


Keep looking for ways to improve the system


Further process streamlining, new report development, etc.

57

Management

and Evolution


IS Optimization
Inventory


Don’t forget to ask staff, managers and frontline users about their
ideas for increasing the benefit of the system


Training


Ongoing for ALL staff to create duplication in skill sets and greater
capacity, including local language documentation


Monitoring


Periodic employee work
-
flow reviews to ensure maximum productivity


Develop complete awareness of all the software’s functionality


Consider 3
rd

party applications to add value (e.g., report writer, financial
planning software)


Regular data, software and hardware upkeep


Regular archiving/backup


Current updates, patches, features


Renew license fees for continued vendor support


Consider additional hardware to enhance stability, efficiency or safety of
system (e.g., power stabilizers, back
-
up servers, A/C)


Forum sur les politiques réglementaires de la
microfinance en Afrique

Kigali, Rwanda

25


27 mars 2009




Thank you!

Any Questions?



Loretta Michaels, CGAP

Loretta.michaels@gmail.com



Advancing financial access for the world’s poor

www.cgap.org

www.microfinancegateway.org