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

Kigali, Rwanda25 – 27 mars 2009

Implementing Microfinance Information Systems

Loretta MichaelsTechnology Consultant, CGAP

February 8, 2012

22

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 reportingManagement

reporting

FINANCE & ACCOUNTINGADMINISTRATION

Finance AccountingChart of accounts

HR administrationPayroll

managementShare mgmt

Regulatory authorities reportingSub-ledger

updatesAccounting GL

Operational reporting

Budget mgmt

LOANS SAVINGS

Solidarity groupsSavings accountCurrent account

TRANSFERS

Collateral mgmt

Credit Scoring

Individual loans

Overdraft account Term deposit

Planned savings Group savings

Guarantor mgmt

OTHERSPRODUCTS AND SERVICES

PLATFORM/INFRASTRUCTURE MANAGEMENTArchive

managementBackup and

restoreConfiguration management

Hardware management

Network management

User/Password admin

InterbranchInterbank

InternationalBatch

Payment cardCheck mgmt

Foreign exchangeInsurance

Client information management

Customer Relationship Mgmt (CRM)

CLIENTSPotential client information

management

ATM MobileBankingPOSTeller mgmt PDA

DELIVERY CHANNELS

BA

CK

OFF

ICE

FRO

NT

OFF

ICE

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 ObjectivesDefine the business problemDefine goals & objectivesAssess risksAgree outcomes with top management

2.2 Secure Resources to Execute ProjectForm Steering CommitteeForm PMODevelop preliminary budget

2.3 Establish a PlanGather documentationDevelop Change Management PlanDraft 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 pointsDo 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 membership2) Project goals and objectives3) Preliminary budget (hardware, software, implementation

and maintenance)4) Risks and mitigating actions5) Change management/communication plans6) 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 RequirementsExisting products and processesNew products, processes and channelsOperational requirements and technical specificationsAdditional 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 ResponsibleFunctionality 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 requirements 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 SlipDeposit 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 VansSatellite branch

Kiosk in market

Mobile Banking

Agents

31

Needs Analysis – Don’t ignore operational 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 systemsNetwork 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 entryGrowth 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 DecentralizedDescription •All branches networked and

run from centralized server & dbase

•System that runs back-office activities at HQ, with field operations run manually or on local servers

Pros •Real-time, network-wide access to data•Streamlined system management from one location•Simpler, more robust contingency policies & measures•Simplified user management & profiles•Faster upgrades

•Less expensive•Doesn’t depend on reliable connectivity or electricity•Allows more flexibility for locally-driven solutions

Cons •More expensive•Requires reliable internet connection & bandwidth•Can be more expensive to support WAN•Requires skilled IT staff

•Longer time to collate system-wide data for settlement, 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 TenderDevelop short-list for further evaluationAttend demonstrations by short-listed biddersMake recommendation to steering committee

4.4 Negotiate contracts with sufficient leverage to ensure successful deliverySoftware licenseImplementation supportOngoing 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 – Software 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 – Some 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 migrationDesign switchover strategyIdentify key risksMigrate 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 communicationsTiming, LOE, resources, communications plan, PMO schedule, risks,

measurementHardware, system software, and infrastructure

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

Configuration and parameterizationInterface with vendor

CustomizationPrioritize, manage vendor deliverables, test scripts

Changes to business processesDocument, test, align, communicate

User acceptance testsDevelop test cases, conduct & measure

TrainingDevelop materials, determine formats, identify resources

RolloutDetermine 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 2nd 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 3rd 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, Rwanda25 – 27 mars 2009

Thank you!Any Questions?

Loretta Michaels, CGAPLoretta.michaels@gmail.com

Advancing financial access for the world’s poorwww.cgap.org

www.microfinancegateway.org