Looking for appropriate software (6)
------------------------------------
Things move fast on Afro-Nets.
I was about to contribute to 'Looking for appropriate software' and my
phone quit (and, with it, easy e-mail access) for ten days. The phone came
back and then both e-mail systems I use promptly conked out for about a
week.
Two weeks were enough for the 'Looking for appropriate software' thread to
peter out. But I hope I can make a final (or reviving) comment.
It has been my experience (developing vertical/programme-specific and
general, national/district-based health and health management information
systems in the Caribbean, Namibia and, currently, here in Eritrea) that
trying to employ an off-the-shelf package such as Quicken or its brethren
ends up being more trouble that it is worth.
Perhaps there will be a little savings in cost of the software packages.
But that will be offset by the need for training and manuals that must
include many work-arounds, "This field really means..." "Yes, it says
dollars, but really, you must enter the amount in Locurs," "Pay no
attention to the ZIP code field." "That little two space field which says
State must be used for the parish here. Here is a list of two letter codes
for parishes. Note that some of these abbreviations are not logical or
intuitive, but we had to make codes that would fit in the little space...."
If a system such as Steve Song is describing is to be a success for the
users, it must be very easy to use. Having to make excuses or exceptions
for the software's inadequacies to properly address the matter at hand does
not contribute to ease or simplicity of use.
And, as Eckhard Kleinau points out, it must accommodate a variety of
place/programme-specific issues - to which I might add the capacity to
track expenditures specifically related to government obligations/
expenditures separate from those assumed by a project, each of which is
likely to have a different chart of accounts and/or approach to
naming/numbering the accounts, and perhaps, the capacity to prepare reports
or analysis in one or more foreign currencies (with changing exchange
rates).
Spreadsheets come to mind for this sort of application because people tend
to think of spreadsheets to deal with financial figures and transactions.
Another contributer noted the fragility of spreadsheets, their size and the
difficulty of reviving them if they are corrupted.
Having developed complex systems using both spreadsheet and database
applications, I believe the former is not appropriate for the sort of
system Tanzania is looking at. A system using dBASE III+ developed by an
experienced programmer - an exercise of no more than a couple of months if
the Tanzanians and the project supporting this development know for sure
what they want to get out of it and have finalised the data they will
gather, record and report as inputs - would be the best solution.
Steve asks about "big accounting firms...UN, WHO, etc." having or being
interested in development of such a system. All those folks are using
close to state of the art - Pentium processors, Windows - stuff that is not
going to work on the modest hardware capacity available (and, thankfully
apparently to be used rather than being replaced with something more
current) in Tanzania (and lots of other spots of the world that have
largely been forgotten as systems are developed that do not accommodate the
very modest capacity available outside the capital cities).
Regards,
J.B. Clark
---
Jeremy B. Clark
c/o BASICS
P.O. Box 5815
Asmara, Eritrea
Office Phone: +291-1-127420
Fax: +291-1-126615
Home Phone/Fax: +291-1-181572
mailto:jeremy@clark.eol.punchdown.org
please cc to:jclark@eri.healthnet.org
--
Send mail for the `AFRO-NETS' conference to `afro-nets@usa.healthnet.org'.
Mail administrative requests to `majordomo@usa.healthnet.org'.
For additional assistance, send mail to: `owner-afro-nets@usa.healthnet.org'.