Content on this page requires a newer version of Adobe Flash Player.

Get Adobe Flash player

What is Beacon
Features
Reporting Framework
Implementing Beacon
Phase I - Concept
Phase II - Design
Phase III - Implementation
Phase IV - Maintenance
Phase IV: System maintenance

Maintenance Support

Calls are received by CUSTOMER support group who take details of the problems being raised, together with the user’s name and telephone number (where applicable) and provide a detailed email to Paripoorna.

Following this depending on the criticality of the problem, CUSTOMER staff may call Paripoorna staff to indicate the problem. If possible the problem will be resolved during this initial call and the problem closed.

If resolution is not possible during the initial call Paripoorna support team will create a problem number (maintenance request ticket) which will be used to monitor the problem’s progress. The problem number is then passed to the CUSTOMER staff.

Paripoorna support staff will provide this support from Monday to Friday 09:00 to 18:00 IST time

This support is to follow the procedure detailed below: (CUSTOMER Team is referred here in as Client and Paripoorna team as the supplier.)

a) For each problem passed to the Supplier and entered onto the Problem Management System, the Supplier will update the status of the problem as it is progressed. The Client’s support team should receive status update information by telephone and/or e-mail on a regular basis from the supplier

b) The Client’s support staff and the reporting user will help prioritise problems that are entered into the Problem Management System (maintained by the supplier).

c) The levels used are as defined below:

    • Level 1 being any problem critically impacting the Client’s business
    • Level 2 being any problem seriously impacting a group of users
    • Level 3 being any problem seriously impacting a single user or any minor problem impacting a group of users
    • Level 4 being any minor problem impacting a single user
    • Level 5 being a request for information of a query only.

d) The target time for the Supplier to apply a fix, or provide a workaround, to a problem is detailed below and is dependent upon the category of the problem. All durations are measured from the time of the problem being notified to the supplier.

    • Level 1 problems within six hours of notification
    • Level 2 problems within one business day of notification
    • Level 3 problems within two business days of notification
    • Level 4 problems within three business days of notification
    • Level 5 problems within five business days of notification
    • For Level 1 and Level 2 problems the Supplier should continue working on the problem until resolution is achieved. The Client’s support team should be informed immediately of any priority 1 or 2 problems that will, or have, failed their SLA.
    • For Level 4 and Level 5 problems the Supplier should work on the problem based on available bandwidth to resolve the problem. The Client’s support team should be informed on a weekly basis of any priority 4 or 5 problems that will, or have, failed their SLA.

e) In the event that a permanent fix is not possible within the specified timescale, an acceptable workaround fix can be used to allow the user’s to continue to work on the system. In this situation a permanent fix to the problem will need to be supplied at the earliest agreed opportunity.

f) During the course of problem analysis, the Supplier may need to request further information from Client’s staff or user who reported the problem, or gain remote access to the system, or in extreme circumstances make a site visit. In the event that a site visit is required, the Supplier shall have the right to re-charge for the expenses incurred provided that prior written approval has been received from the Client.

g) In the event that resolution of a problem is not provided within the given time limit, the Client support team may escalate to the Supplier team management who will ensure that the problem is progressed.

h) At a management level, the duties of the Client Contact and the Supplier Contact will be at all times to monitor problems raised on the Problem Management System to ensure that service levels are met.

i) In the event that any member from the supplier team goes on a vacation / leave for more than one week (5 business days) the same will have to be communicated with the Client by the Supplier at least two calendar weeks in advance. A backup resource in the supplier team is made available for this period by the Supplier and communicated to the Client at least two calendar weeks in advance.
 

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:

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

BeaconTM 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:

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:

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.

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

BeaconTM team has an extensive experience in training and our training curriculum includes the following:

Step 8: Running parallel operations

It is important to run BeaconTM in parallel operation with the old one, to ensure that BeaconTM 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.