1 / 59

Implementing Microfinance Information Systems Loretta Michaels Technology Consultant, CGAP

Implementing Microfinance Information Systems Loretta Michaels Technology Consultant, CGAP February 8, 2012. CGAP: Who we are. CGAP is an independent policy and research center dedicated to advancing financial access for the world's poor .

hanne
Download Presentation

Implementing Microfinance Information Systems Loretta Michaels Technology Consultant, CGAP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Implementing Microfinance Information Systems Loretta Michaels Technology Consultant, CGAP February 8, 2012

  2. 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: • 7locations: offices in Washington DC and Paris, with 5 regional representatives based in Abidjan, Dhaka, Moscow, Nairobi, and Ramallah • ~50 staff • ~70countries with CGAP activities • 150,000+ copies of CGAP publications distributed annually

  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

  4. Introduction Project Preparation Needs Analysis Selection Implementation

  5. Introduction Project Preparation Needs Analysis Selection Implementation

  6. 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

  7. What a good IS can – and cannot - do for an MFI’s sustainability NO YES • 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 • An IS is not a substitute for good business practices

  8. 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

  9. 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

  10. What’s Usually Included in an IS System? PLATFORM/INFRASTRUCTURE MANAGEMENT Archive management Backup and restore User/Password admin Configuration management Hardware management Network management BACK OFFICE ADMINISTRATION FINANCE & ACCOUNTING REPORTING Finance Accounting Operational reporting HR administration Budget mgmt Chart of accounts Regulatory authorities reporting Payroll management Treasury mgmt Sub-ledger updates Share mgmt Financial reporting Asset mgmt Accounting GL Management reporting PRODUCTS AND SERVICES TRANSFERS LOANS SAVINGS OTHERS Interbranch Payment card Savings account Individual loans FRONT OFFICE Interbank Check mgmt Current account Solidarity groups International Foreign exchange Overdraft account Collateral mgmt Batch Insurance Guarantor mgmt Term deposit Credit Scoring Group savings Planned savings Clients Customer Relationship Mgmt (CRM) Client information management Potential client information management DELIVERY CHANNELS Teller mgmt ATM POS Mobile Banking PDA

  11. Key Steps to Consider in Implementing IS • Project Preparation • Needs Analysis • Selection • Implementation • Management

  12. Introduction Project Preparation Needs Analysis Selection Implementation

  13. 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

  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 – FairFundExample • 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 • 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

  17. Project Preparation – Establish a Plan • Key Steps: • 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: Steering Committee and PMO membership Project goals and objectives Preliminary budget (hardware, software, implementation and maintenance) Risks and mitigating actions Change management/communication plans 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. Introduction Project Preparation Needs Analysis Selection 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: • 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. 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. Pass Book Customer Pass Book Deposit Slip Deposit Slip • Key questions to ask when starting out are whether process maps already exist and whether they reflect current reality

  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? • 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

  28. Needs Analysis – One simple mapping example Board • 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. Over 10,000? 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

  29. 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)

  30. Needs Analysis – Are new channels planned for the future? Mobile Banking Kiosk in market ATMs Regional, full-service branches Mobile Vans Satellite branch Agents

  31. 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

  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

  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 • 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

  36. 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

  37. 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

  38. Introduction Project Preparation Needs Analysis Selection Implementation

  39. 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

  40. 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.

  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 • 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

  44. 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

  45. 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

  46. 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)

  47. 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!

  48. Introduction Project Preparation Needs Analysis Selection Implementation

  49. 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

  50. 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

More Related