Step 1: Customising the software

The Phase 1 of the customization includes Conceptualization and Phase 2 is the Detailed Design Considerations are collated to form the requirements for the customisation and implementation strategy. There may be areas for development that will be identified and rolled out.

Step 2: Setting up the hardware

Setting up the computer hardware for a new system can be time-consuming, and it requires much anticipatory planning, especially in purchasing decisions. In addition to selecting and purchasing the computers, printers, power supplies, backup units, software, cabling, and other peripherals, plans should cover:

• Electricity supply, including grounded connections
• Backup power supplies
• Telephone connections
• Installation of network cabling
• Temperature, dust, and humidity control
• Remodeling of work areas, especially teller counters
• Server and terminal security and access
• Structural security against theft
• Fire extinguishers.

Step 3: Preparing and revising documentation

Good documentation can be invaluable in ensuring proper use of the system, especially in large, decentralized organizations or in organizations undergoing expansion. It can also serve as a training tool for new staff and assist staff in dealing appropriately with new situations. Documentation on policies and procedures will need to be revised to reflect changes introduced by the new system, and new documentation on the system will need to be developed

Step 4: Configuring the system

Beacon^TM uses configuration options to set up the system for an institution’s needs. Configuration options are accessible by a user registered at the level of system administrator. Less commonly used configuration options are enabled by special codes entered into a configuration file by a technician familiar with Beacon.

Configuration consists primarily of:

• Setting up the structure of the chart of accounts. This crucial task may require modifying the institution’s chart of accounts to match the operations of Beacon.
• Defining the financial products, each with myriad rules—such as minimum and maximum amounts, interest calculation methods, links between accounts, and treatment of delinquency for loans.
• Establishing numbering conventions for clients and loan and savings accounts.
• Establishing relationships among branches—for example, for sharing and consolidating information.

Step 5: Testing

The next step is to test the system with actual data. Historical information for the past several months on 50–100 accounts for each product type should be entered into the system. This testing phase serves two purposes.

First, it allows the development of a strategy for data conversion / migration or entry of initial data for all active accounts.

Second, it allows careful study of the system’s behaviour:

• Are repayment schedules, interest charges, penalties, and delinquencies being calculated?
• Does the system crash inexplicably?
• Does the network function adequately?
• Does the system allow correction of data entered in error?
• Is the system user-friendly, or are there urgent issues that need to be addressed?

Independent cross-check audit routines should be developed that verify that empty data fields, data outside minimum and maximum ranges, sequential numbering, duplicate account or client numbers, duplicate records, widows and orphans (records in a database table not matched by records in other database tables), and accuracy of interest, penalty, and delinquency calculations. Many errors occur in databases, as a result of software bugs, database corruption, and data entry errors. Without such an audit routine, data errors become frequent, undermining staff’s confidence in the system.

Step 6: Transferring the data

The first issue is simply volume. Introducing names and socioeconomic data on clients is time-consuming. The information may be computerized, but there are usually incompatibilities between the old and new MIS in the type of information required or the format in which it is stored. While it is often tempting to transfer incomplete data electronically and then enter the missing data manually, this approach requires more attention from a technician and can be costlier than simply assigning lower-cost data entry people to enter all the data manually.

Financial data are an even bigger problem. The data in most microfinance institutions are flawed, sometimes seriously. Installing a new MIS then becomes an exhaustive auditing exercise—not a bad thing, but it adds substantially to the cost of the MIS. Initial balances in the general ledger need to be matched with the detailed sub ledger balances for all savings and loan accounts. Financial data should be entered in small batches of fewer than 50 accounts. The totals for the batches need to be checked manually against hard copies from the old system and compared with computer-generated listings from the new system.

A third common issue, and the most serious source of problems during data transfer, is incompatibility in loan treatment between the old and new systems. The new MIS needs to treat a loan midway through repayment predictably—an institution can’t simply change its policies midway through a contractual arrangement. But the incompatibility is sometimes unresolvable. Institutions with fairly rapid loan turnover (say, less than six months) might be best off using the old system to track outstanding loans until they are repaid and entering only newly approved loans in the new portfolio package.

Predicting how long or how difficult data transfer will be is difficult, even with a careful initial assessment.

Beacon^TM has an automated process to migrate old data using excel based inputs that addresses all of the above issues seamlessly and our implementation experience aids us to speed this process up.

Step 7: Training

A full-featured MIS is complex, and its implementation requires big shifts in an institution’s operating procedures. So its installation must be coordinated with extensive training for all staff Training normally takes one to two weeks of the trainer’s time, depending on the system’s complexity and the number of staff to be trained.

Users should be divided into training groups, usually by department. The training for each group should focus on issues most relevant to its area of operation, but all users should receive a good overview of the system’s general operations. The duration of training varies, depending, again, on the system’s complexity and on the staff’s experience with similar systems. It is best to break training up into daily sessions of one to two hours.

Beacon^TM team has an extensive experience in training and our training curriculum includes the following:

• System setup, maintenance, and backup
• Opening and closing client accounts, and altering and correcting client information
• Savings and credit transactions
• Approving and disbursing loans
• Opening savings accounts
• Receiving payments and deposits
• Correcting transactions recorded in error
• General ledger transactions
• Use of specialized modules (accounts receivable, accounts payable, investments, payroll, fixed assets)
• Daily, monthly, and annual closings
• Statement and report generation
• Use of report writers
• Security and internal control procedures
• System restart and data recovery procedures.

Step 8: Running parallel operations

It is important to run Beacon^TM in parallel operation with the old one, to ensure that Beacon^TM runs reliably and that its calculations and processes are accurate and compatible with loan contracts.

During the parallel operation staff should enter as much data as feasible into each system and carefully compare the outputs. Any discrepancies should be evaluated and accounted for. Any errors or bugs in the new system should be carefully documented and corrected.

The parallel operation should generally continue for at least two months, so that nearly every client will have made at least one payment and the system will have gone through two month-end closings. Once the institution is satisfied that Beacon is performing well, the old system can be discontinued, but all printouts and data files should be carefully stored for future reference.