Should Technology inform social policy, or Social Policy Guide Technology

Bruce Meraviglia , Technology & Marketing Editor [ Microfinance Focus ]

The answer to the questions above is “Yes!”  Since the beginning of mankind’s invention of new technologies, and new ways of using those technologies, the debate as to whether social policy should guide (or constrain) the development of technology, or whether technology should be created independently of social policy, with the outcome then informing those who create social policy as to what is possible, has raged back and forth.  With the movement to create a Social Performance Management (SPM) standard gaining momentum, the issue of technology once again comes into play.

While the creation of an industry standard set of SPM reports and criteria is both worthwhile and highly desirable, a key question becomes what will be the role of technology in this new set of processes?  Any reporting standard, such as SPM, creates new processes that start with data collection, then analysis, reporting, and, finally, feedback for corrective actions or strategies.  As the amount of data for any reporting standard such as SPM will only increase over time, shouldn’t proper consideration be given at the beginning as to how this data will be collected, analyzed, and reported?  Shouldn’t there be considerations of how the data, and summarized information, is communicated to other organizations, and generally made available to those who have an interest in it?

The use of spreadsheet software (most notably Microsoft’s Excel spreadsheet application) is widely used in virtually every banking institution with any computer support for data analysis and reporting.  However, spreadsheets are not always the appropriate application for consolidating data from multiple organizations, providing suitable mechanisms for that data to be summarized, or making that data accessible to others.  Although the spreadsheet may be appropriate for local use within each MFI (and cost effective for use within the MFI), if we are going to focus not just on the performance of a single MFI, in the absence of any industry benchmarks, but rather the performance of a single MFI taken in context of how the entire industry is performing, either within a specific country, region, or globally, then we need to discuss a different type of application for this level of data organization, manipulation, and reporting.

In the traditional world of corporate-level computing, either for businesses or large banks, the standard approach to managing this type and quantity of information is the database application, in general, and the creation of a “data warehouse” construct within the database software.  The use of a data warehouse approach allows for the collection of large amounts of data, provides for tools and methodologies for analyzing the data, carving out subsets of the data into smaller “data marts” (e.g., the creation of a mini data warehouse specifically for those MFIs in India, while maintaining the ability to consider the same information from those MFIs in a global analysis of the larger MFI community), the ability to summarize or selectively report aspects of the information, and the ability to allow multiple users to work on the collected data.

The problem with discussing a generally accepted approach such as creating a data warehouse for SPM data breaks down into several areas that I have not heard discussed at any of the meetings I have attended here in the Washington, DC, area that have been jointly hosted by CGAP and the Imp-Act Consortium.  The questions that need to be addressed, from a technical perspective, are:

(1) Who will pay for the development of the necessary database software to manage the collected SPM data?

(2) Who will take the lead role in providing a “home” for the collected data (in terms of computer hardware, software, and global access), and making it available to those analysts who are interested in it?

(3) Who will pay for the ongoing salaries of the computer programmers needed to maintain and enhance the data warehouse application?

(4) How will the information be safeguarded against criminal attempts to access the data (if any) or potentially fraudulent modification of the data (such as occasionally happens on the publicly accessible Wikipedia application on the Internet)?

(5) Who will decide which individuals or organizations have valid access to the data, or will it be made available in both raw and summarized form to all?

(6) What form will the data be collected at the MFI-level, such as a spreadsheet, and how will that data be entered into the data warehouse so that the integrity of the data is maintained?

(7) What is the cycle time from when data is entered into the data warehouse before it is either available for analysis or reports are made available?

(8) How will the information gleaned from the collected data be used to improve the performance of the individual MFI?

(9) Who will “own” the collected data, and, potentially, profit from the reports and analyses created from it?

(10) What is the role of major technology companies such as Microsoft or IBM, or a an intermediary’s applications development group, such as the Grameen Foundation USA’s technology center in Seattle, Washington (USA), in this collection and analysis process?

While I’m in general agreement with the need for the creation of Social Performance Management-type of assessment, analysis, and reporting criteria, based upon the meetings that I’ve attended here in Washington, DC, I wonder if we aren’t moving a bit to fast to agree that this should be done without a careful consideration of how it can be accomplished, who will pay for it, and who will own it..

While we already have the MIX reporting some aspects of MFI performance data (but not of the proposed SPM type), and both the Imp-Act Consortium and CGAP cooperating in bringing these proposed standards about, I wonder, still, as to the “who” and “how” details necessary to bring SPM from theory to a tangibly beneficial system that will be worth using, and participating, in.