Automation of SACCOs - FSD Kenya

48 • AUTOMATION OF SACCOS: ASSESSMENT OF POTENTIAL SOLUTIONS
Chapter 7
ConCluSion
FSD Kenya commissioned the SACCO Automation project with the objective
to identify viable automation solutions for SACCOs. The focus was on
SACCOs offering FOSA as they are the first to be targeted by the upcoming
regulation under the SACCO Societies Act 2008. Information technology is
considered an important enabler of compliance with the new regulation.
More robust systems will enable SACCOs to manage their operations more
efficiently, manage growth, and generate reliable management information
reports for both SACCO executives and the forthcoming regulatory authority.
The solutions needed to meet the SACCOs business as well as technical
requirements, consider the constraints SACCOs are facing with regard for
instance, staff capacity and budget; and improve the quality and timeliness of
their management information.
To be in a position to recommend viable automation solutions, the
project team needed to understand the SACCOs’ business processes and
circumstances and translate them into system requirements. The project team
thus visited five SACCOs, each for two to three full working days, and captured
requirements across the complete SACCO operating model, including FOSA,
BOSA, accounting and finance, human resources, internal audit, and marketing
departments. In addition to gathering requirements from analysing SACCOs’
business processes, the project team analysed the anticipated regulatory
requirements to assess their impact on the selection of potential systems. It
needed to be understood how SACCOs would need to change their operations
in order to comply with the upcoming regulation and what role information
technology solutions would play in that process.
In choosing the sample SACCOs the project team paid attention to obtaining
a well balanced mix between different SACCO characteristics. The selection
needed to include urban and rural SACCOs, employer-based and farmer-based
SACCOs, as well as small and large SACCOs as it was assumed that, while
all SACCOs have many common core requirements, each also has unique
requirements corresponding to its segment and specific product offering.
This approach ensured that the project team captured a comprehensive set of
requirements that was likely to cover the needs of the approximately 200 FOSA
SACCOs and present a robust basis for the automation decision. The outcome
was a list of 190 functional and technical requirements. While the different
SACCO characteristics provided a range of requirements, they were not found
to be as relevant as initially assumed when selecting an application. Trends
such as diversification of SACCO membership as well as more sophisticated
and comprehensive customer requests amplify the convergence towards a
common set of requirements. For system selection, every SACCO will need to
consider each requirement and decide on its relevance as well as its priority in
their specific context. The requirements matrix developed by the project team
can serve as a useful tool.
Once a clear set of requirements had been developed, the next step was
to identify automation solutions available in the market and assess their
suitability. Several sources were reviewed to compile a list of vendors. After
having screened the solutions for minimum requirements, 26 of initially 46
vendors were invited to provide more details about the specific properties of
their offering through an RFI. Based on the responses, the project team finally
short-listed six vendors for the final round of in-depth screening which took
place in the form of system demonstrations. The final selection of vendors
was a mix of domestic Kenyan vendors with a deep knowledge of Kenyan
SACCOs and a strong presence in Kenya (Craft Silicon, Fintech), foreign vendors
that have developed microfinance or credit union applications and could
draw on significant international experience from their commercial banking
applications (Fern, Neptune, Temenos), as well as a local vendor who were
expected to provide more cost efficient solutions for those SACCOs which
cannot afford the high-end solutions (Amtech). The vendors were each given
one day to present their solution.
Consolidation of information gathered during the demonstrations proved
that some functionality was provided by all solutions, hence it could not be
considered as strength of a particular solution but rather as fundamental
functionality. This functionality was considered as “viable solution minimum”
and represented requirements every viable solution needed to fulfil. The
compiled list can support SACCOs in their acquisition decision.
Following the definition of minimum requirements on a viable system,
individual strengths and weaknesses could be noted. Every feature above
and beyond the minimum requirements was recorded as a strength for the
particular solution. A weakness was noted if a solution could not meet the
“viable solution minimum” or if some severe shortcoming had been observed.
In addition to individual shortcomings, some common weaknesses were
noted, i.e. some functionality was not offered by any of the solutions. While
it was considered important to log these, they would not assist in making the
final recommendation.
Apart from the solutions’ functionality and support structure, it was important
to understand the price level of the individual solutions. The project team
therefore asked the vendors to provide cost estimates for two standard SACCOs,
broken down into licence, implementation, training, and annual maintenance
cost. While the vendors would obviously need to study business requirements
case by case to quote an exact price, the cost estimates could serve as rough
indication and help to understand in which price category a solution falls.
Based on the findings, the project team provided recommendations on
appropriate ways to tackle automation by SACCOs preparing for regulation.
The project team identified theoretical strategic options that SACCOs could
choose from having made the automation decision. Analysis and evaluation
of the options proved that some are not particularly suitable in the SACCO
context, e.g. in-house development of a system or the acquisition of opensource
software. The project team came to the conclusion that the most viable