Automation of SACCOs - FSD Kenya

A manual of the solution needed to be provided. The manual would offer
the possibility to look up functionality when necessary and also give an
impression about system documentation quality.
The vendors were asked to provide a document illustrating the data
model of the proposed solution. This would enable the project team to
evaluate the logical data model of the solution and also to confirm that a
relational database is used.
In preparation for the software demonstrations, the project team developed a
standard vendor evaluation template, which included the relevant requirements
for a viable system, based on the consolidated SACCO requirements put together
previously. A standard approach to each of the demonstrations would facilitate
comparison of the solutions later on in the process. The template was filled in
during every demonstration. In case relevant topics were not covered during
the actual system presentation by the vendor, the project team would follow
up during a question and answer session subsequent to the demonstration,
as it was mandatory to gather the same information about all solutions for
comparison.
The project team requested live demonstration of typical SACCO processes,
such as opening an account, processing a loan application, posting an expense
into the general ledger, etc. to challenge the system. Finally, vendors were
requested to walk the project team through their premises, so that the team
could get an impression of the company and the support structure in place.
AUTOMATION OF SACCOS: ASSESSMENT OF POTENTIAL SOLUTIONS • 9
Subsequent to each demonstration, the project team would review the
completed template and translate the information into strengths and
weaknesses that had been observed. This information was consolidated once
all demonstrations had been held to facilitate comparing the solutions with
regard to strengths and weaknesses.
The consolidated information 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. Those features were collected
to form the “viable solution minimum” category, which consisted of all the
requirements that every viable solution needed to fulfil. Every feature above
and beyond these fundamental requirements was noted as a strength for the
particular solution.
A similar process was followed with regard to the solutions’ weaknesses.
Weaknesses that had been observed for all solutions were collected to form
the “common weaknesses” category, which included all requirements that
were not fulfilled by any of the solutions. This category would not assist in
making the final recommendation. A weakness for an individual solution was
noted if it could not meet the “viable solution minimum” defined earlier or if
some severe shortcoming had been observed. The consolidated table finally
enabled the project team to compare the solutions with regard to strengths
and weaknesses in particular requirement categories.