Forum sur les
politiques réglementaires
la
Implementing
Microfinance
Information de
Systems
microfinance en Afrique
Loretta Michaels
Technology Consultant, CGAP
February 8, 2012
Kigali, Rwanda
25 – 27 mars 2009
CGAP: Who we are
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
2
2
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
3
Introduction
Project Preparation
Needs Analysis
Selection
Implementation
4
Introduction
Project Preparation
Needs Analysis
Selection
Implementation
5
Why Are We Here?
 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
CGAP has released a technical guide to assist in implementation
of MFI Information Systems
* CGAP 2009
6
What a good IS can – and cannot - do for an
MFI’s sustainability
NO
 Focus on profitability
 Quality loans
 Provision for loan loss reserve
 Community accepted and
appropriate accounting
procedures
 Gathering and reporting of
accurate and timely information
YES
 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
An IS is not a substitute for good business practices
7
What are the key uses for IS?
 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
Important to view IS as an investment, not just a cost
8
Where does IS Implementation Fit Into Overall
Operations?
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
IS needs to be an enabler of - and be driven by - the organization’s
overall strategy
9
What’s Usually Included in an IS System?
BACK OFFICE
PLATFORM/INFRASTRUCTURE MANAGEMENT
Archive
management
Backup and
restore
ADMINISTRATION
HR administration
Payroll management
Share mgmt
User/Passwor Configuration
d admin
management
Hardware
management
FINANCE & ACCOUNTING
Finance
Network
management
REPORTING
Operational
reporting
Accounting
Budget mgmt
Chart of accounts
Treasury mgmt
Sub-ledger
updates
Asset mgmt
Accounting GL
Regulatory
authorities
reporting
Financial reporting
Management
reporting
FRONT OFFICE
PRODUCTS AND SERVICES
LOANS
Individual loans
Solidarity groups
Collateral mgmt
Guarantor mgmt
Credit Scoring
SAVINGS
Savings account
Current account
Overdraft account
Term deposit
Group savings
Planned savings
TRANSFERS
Interbranch
Interbank
International
Batch
OTHERS
Payment card
Check mgmt
Foreign exchange
Insurance
CLIENTS
Client information
management
Potential client information
management
Customer Relationship
Mgmt (CRM)
DELIVERY CHANNELS
Teller mgmt
ATM
POS
Mobile
Banking
PDA
10
Key Steps to Consider in Implementing IS
 Project Preparation
 Needs Analysis
 Selection
 Implementation
 Management
11
Introduction
Project Preparation
Needs Analysis
Selection
Implementation
12
Project Preparation – Do This First!
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
Need to develop a clear understanding of the problem (s) to be
addressed, expected outcomes, potential risks & resources needed
13
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
14
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
15
Project Preparation – Steering Committee &
PMO
Steering Committee




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
A cross-functional team ensures institution-wide acceptance and
that everyone’s needs are incorporated into the effort
16
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
17
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
18
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
19
Introduction
Project Preparation
Needs Analysis
Selection
Implementation
20
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!
21
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
22
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”
23
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
24
Needs Analysis – Resources for requirements
gathering
Type of Requirements
Tools
Responsible
Functionality Requirements –
existing products, processes,
channels
Business Process Mapping
Business owners, department
managers
Interviews with staff
PMO
Functionality Requirements –
new products, processes,
channels
Business Plan/strategy
documents
Business owners, department
managers
Interviews with management
PMO
Steering Committee
Operation Requirements
Operations manual
Business owners, department
managers
Internal audit manual
PMO
Technical Specifications
Interviews with staff and
management
Steering Committee
IT strategy
IT team
Technical environment
questionnaire
25
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.
Pass Book
Pass Book
Customer
Deposit Slip
Deposit Slip
Key questions to ask when starting out are whether process maps
already exist and whether they reflect current reality
26
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?
 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?
A key aspect of any process mapping is to validate the processes
with the staff who actually do the work
27
Needs Analysis – One simple mapping
example
Board
Over
10,000?

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.
Exec
Dir
Region
Over
1,000?
HQ
Front
Office
MIS
Finance
A good process map doesn’t need to be complex, it just needs to
accurately reflect what happens at each step
28
Needs Analysis – What about future needs?
 Any functionalities anticipated for future
operations?
 What sort of growth plans do you have?
 Geographic expansion?
 New products and services?
 Any firm partnership plans that will
impact your needs?
Bear in mind tradeoffs between flexibility for future needs and costs
of building in that flexibility (e.g., modular platforms)
29
Needs Analysis – Are new channels planned
for the future?
Mobile Banking
Kiosk in
market
ATMs
Regional, fullservice branches
Mobile Vans
Satellite branch
Agents
30
Needs Analysis – Don’t ignore operational
requirements
Back-office, non-product related processes are just as important as
the main functional requirements:
 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
Want to make sure you can manage the system and get the
information you need WITHOUT vendor support
31
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)
32
Needs Analysis – Centralized vs Decentralized
Centralized
Decentralized
Description
•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 systemwide data for settlement,
analysis
•Harder to link to other
networks (ATM, mobile money)
More complex doesn’t always mean better – need to consider
system-wide environment and needs
33
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 payper-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
34
Needs Analysis – Other considerations
 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?
Be comprehensive about your needs but be flexible, know your
priorities, and keep tradeoffs in mind
35
Needs Analysis – Prioritization is critical to
success of the project
 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?
The more functions you deem essential, and the less you’re willing
to change some processes, the more the system will cost
36
Needs Analysis – Key Takeaways
 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
A good needs analysis takes time now but will save cost and time
later
37
Introduction
Project Preparation
Needs Analysis
Selection
Implementation
38
Selection
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
Don’t underestimate the value of a proper procurement process – be
clear and consistent about your methodology
39
Selection – The “typical” RFP
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
There’s no single standard RFP. Just remember: Garbage In,
Garbage Out.
40
Selection – A Fairfund Example from
Framework Document
Want to clarify all your needs with comments
41
Selection – A Fairfund Example from
Framework Document
Don’t be afraid to raise questions here or ask for suggested
solutions
42
Selection – Clearly articulate the RFP process
 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
Want to make sure the process is as transparent as possible
43
Selection – What do you want out of a vendor
demonstration?
 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)
Be as thorough as possible with a demo – you have to live with this
system for a long time
44
Selection – Software licensing
 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.
Be very clear about what you want and what you’ll get for your
money – sorting it out “later” is an expensive option
45
Selection – Some suggestions
 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)
46
Selection – Key takeaways
 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
The value & importance of a competitive process cannot be
overstated!
47
Introduction
Project Preparation
Needs Analysis
Selection
Implementation
48
Implementation
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
Time to transition the solution from a plan to a functioning system
49
Implementation – Develop Implementation Plan
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
 No two implementations are the same, even with the same system 50
Implementation – Implement & Conduct User
Acceptance Tests (UATs)
 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.)
 UATs should involve a cross-section of users, not just IT staff
51
Implementation – Data Migration
 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
 Assume issues will come up during migration – this isn’t a bad
thing
52
Implementation – Phased vs. Big Bang
 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
 Running parallel systems might seem less risky than an immediate
switchover, but it brings its own problems
53
Implementation – Key Takeaways
 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.
Don’t let the team go before Implementation is complete – you may
discover issues that require more work
54
Close the Project
 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
 The project might be closed, but the management of the system is
just beginning
55
Management and Evolution
 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.
Loan capital can be replaced with insurance, the loss of client data
(and goodwill) cannot
56
Management and Evolution – IS Optimization
Inventory
 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)
Don’t forget to ask staff, managers and frontline users about their
ideas for increasing the benefit of the system
57
Forum sur les politiques réglementaires de la
Thank you!
microfinance en Afrique
Any Questions?
Kigali,
RwandaCGAP
Loretta
Michaels,
Loretta.michaels@gmail.com
25 – 27 mars 2009
Advancing financial access for the world’s poor
www.cgap.org
www.microfinancegateway.org