Building A Transparent MIS for Micro-Finance: Key Design and Implementation Lessons from The Indian Experience

Ramesh S Arunachalam[i]

Rural Finance Practitioner

Given below are a set of key lessons for design and implementation of an MIS, based on a decade of experiences in microfinance, especially in India. These lessons could be useful for effectively integrating technology and automating (upgrading) MIS in MFIs, especially, in a transparent manner.

Lesson # 1: Do not computerize until the microfinance model is reasonably stable.

Often times, nascent MFIs, which are experimenting with their basic and core processes, find themselves faced with the never ending task of (re) designing the MIS to perpetuity. For such MFIs and eternal pilot testers, automating the MIS, although not impossible, would be a very costly option. This is because of the significant down time associated with the MIS due to frequent changes to the core and basic processes. Having observed this in reality in an evolving Microfinance sector in India in the mid-late 1990s, it seems best to guard against this as it is not only affects the operations of the MFI but also impacts the vendor. Additionally, such frequent changes often results in loss of motivation for those working on the MIS and also makes the whole exercise prone to mistakes. However, this does not imply that flexibility cannot be a part of the MIS. Rather, it is to say that if an MFI is an eternal pilot testing mode with regard to its basic processes, it perhaps better to wait until there is a semblance of stability, before automating its MIS

Lesson # 2: There is no substitute for a comprehensive needs assessment through appropriate methods, prior to automating an MIS.

A complete needs assessment is very critical and the time spent on this aspect, while automating an MIS, is well worth the effort/cost. Use of appropriate techniques like PRAs and FGDs with field workers and other management/operational staff could provide very valuable data. Most importantly, it should enable matching/reconciling information needs with the decision making hierarchy within an MFI. Among other aspects, a proper needs assessment would provide detailed process maps and flows on various activities - with inputs, process descriptions and outputs and their sequential linkages. These are extremely valuable documents to have at the time of automating an MIS for Microfinance.

Lesson # 3: Keep MIS design simple and if required, re-engineer processes for simplicity and then build the MIS

While automating, it is important to ensure that the MIS design is kept as simple as possible. Among other things, best efforts must be made to see that no information must be entered in multiple (or even two) places and also that, all data going into the system must be cross-verified for utility and actual usage. Therefore, rationalisation of information flows (including possible re-engineering of business processes) and also organization structure/hierarchy is extremely critical. A modular structure for the MIS, where different elements are linked and share information is an attractive option. It affords significant flexibility, facilitates compartmentalization apart from synergistic benefits.

Lesson # 4: Build flexibility into the MIS, through an appropriate business rules layer and enabling generation of user definable reports (in real time)

The MIS design should also be flexible, to the extent possible and feasible. The best way to address this is by having a TRANSPARENT (separate) business rules module, with options for alternative methods of interest calculation, interest rates, loan installment repayment frequency, loan term and several other aspects including generating user defined reports. This can save significant time and effort for the institution as well as the vendor, especially, in the later years, when some of the elements, assumptions and activities in the core processes may have to be changed and/or new information and decision making needs may arise. It is important to recognize that for MFIs, like other organizations, it would be impossible to specify all information requirements, at any given point in time. Therefore, mechanisms that can provide flexibility like a user modifiable business rules module and user definable reports are very necessary requirements and are best implemented. A flexible report generator could play a very useful role here as the users can then choose parameters and generate the kind of report they require – which may sometimes be necessary with changes to the regulatory framework

Lesson # 5: Ensure compliance of MIS to best practices as well as prevalent regulatory framework. This will also enhance transparency of the MIS, which is much need today!

Six best practices aspects are very critical while automating an MIS for an MFI:

(a) Sequence of Client Repayment Appropriation: the sequence in which client repayments is being appropriated. This should always be as follows – fines (if applicable), penal interest (if applicable), interest overdue, interest due (if due on the date on which repayment comes in), principal overdue and principal. If principal is appropriated first, then, while portfolio quality would appear better, the yield on portfolio would reduce;

(b) Ageing of Past Due Loans: the method of calculating age of a past due loan, should be through the best practices method where age of past due loan = Date of calculating age – earliest unpaid over due (in days). Using the installment method of ageing requires adjustments to be made as this method understates age of past due loan after the loan term and overstates age of past due loan within the loan term;

(c) Asset Classification and PAR: while selecting past due loans for calculating Portfolio At Risk (PAR) of any age, the reference point is to choose every loan that has either fines or interest or principal over due. Technically, it is possible to have past due loans with ‘0’ principal over due and some interest/fines over due and hence, using only principal over due to determine aggregate loan outstanding of past due loans could actually under state risk in the portfolio. I had posted on this aspect earlier;

(d) Weekly Installments: in case of ageing with weekly/daily installments, define age categories based on number of installments skipped rather than in days. This is to ensure appropriate provisioning. For example, in a weekly payment model, < 30 days past due could actually be 4/5 installments skipped;

(e) Factoring Grace Periods: factor in unusually long grace periods or repayment moratoriums while calculating portfolio quality. For example, repayment in 46 installments over a 52 week period could mean that at any time, a client could have skipped 6 installments and still not be classified as a past due account; and

(f) Data Integrity for Financial Statements: ensure automatic integration of portfolio and accounting modules, in that data entered in one, for example, loan disbursement through the portfolio module, automatically gets reflected in the other, as loan outstanding under assets in the balance sheet.

Lesson # 6: Past data conversion must be looked into at the time of designing an automated MIS.

Migration of past data is very critical to continuity and it needs to be reviewed even at the design stage, so that the new database is designed so as to take care of various aspects with regard to past data. Using experienced professionals for data conversion is very critical. However difficult this process may be, the validation of the MIS using past data and matching of MIS outputs with audited statements from the past greatly enhances the robustness and credibility of the MIS. It also ensures smooth transition from one system to another and thereby, results in less disruption of operations

Lesson # 7: Maintenance of the automated MIS is serious business

Maintenance is an often ignored aspect and MFIs must be willing to pay for this aspect. The importance of negotiating a maintenance contract for the automated MIS at the design stage of the MIS itself should not be under estimated. The contract should clearly spell out what is maintenance and what is fresh programming work. Ambiguity here could result in misunderstanding with vendors and the system could fade away in due course of time…and literally remain unused…

---

[i] The author has over a decade of experience in designing and implementing MIS systems including ERPs and CBSs. The author does not have any MIS to sell to the micro-finance industry and therefore, has no conflict of interest in writing on this topic.