A REALISTIC APPROACH TO SOFTWARE SELECTION FOR THE SMALLER ORGANISATION
If this isn't the type of information you were looking for, try going back to Accounts Software introduction. You may want to look at the Accounting Issues page if you are not familiar with the terminology. Some updating from original 1996 version.
Basics Allow yourself enough time for the process. Read this document through, and come up with a draft timetable. Then add time for slippage (sickness, holidays, staff changes etc.), and some more for luck!
1 What are you trying to achieve?
1.1 Look at our criteria (on Checklist), and decide how relevant they are. Look at reporting and analysis in particular.
1.2 Think about SORP issues if you are a registered charity. How do you want
to handle the more tricky areas - will you leave it all to the auditor at the
year-end? If not, here are some items to chew on:
i) Allocation of (eg) bank interest across Funds - is this significant, and do you want to do it within the accounts, or export it to a spreadsheet first?
ii) Is the SOFA of importance? Will you (or your auditor) be making so many year-end adjustments (eg via an ETB) that the SOFA produced by the accounts package won't help?
1.3 What are the problems with your current accounts system (manual or computerised)? Make sure you address these in the approach, but don't solely concentrate on them. You need a rounded view of where you are going as well as where you are coming from.
1.4 Compile your list of needs, and be clear what is essential, and what can be worked round.
2 How much can you afford?
2.1 Be realistic, but do view it as a relatively long-term investment, which can pay back repeatedly in years to come, by being able to use your finances better. Include future maintenance costs in the assessment.
2.2 Don't forget to look at initial and future training. Perhaps you can use an existing training budget here.
2.3 Check that the proposed software will run on your hardware adequately. This includes when importing or exporting data, which tends to require more memory. If you have to upgrade, cost this, and add in extra to allow room for growth and increasing expectations.
3 A standard, voluntary sector or bespoke package?
3.1 Software written specifically for the voluntary sector may meet your needs most effectively. But be aware of the smaller knowledge base and that the supplier is nearly always very small (and you may be reliant on their survival), as well as cost.
3.2 Bespoke software, written for your organisation, may appear to offer advantages. However, it is likely to be costly initially, be dangerous if the author is not totally professional, and make you even more reliant on individuals. It is rare that documentation (if there is any!) is adequate for future users.
4 What packages meet the requirements?
4.1 If there aren't any, reconsider the above!
4.2 Make sure you do a good search. Ask other similar organisations what they use, ask co-ordinating bodies, find a current computer magazine survey, re-visit the VolResource web site for updates..
5 Check them out
5.1 Arrange to see the packages in action, in a realistic setting (eg another volutnary organisation) if at all possible.
5.2 Think of difficult questions. Sales people will tend to reel off a list of features, and glibly say that they will meet your needs. Get them to tell, preferably show, you HOW they will actually do that, and have some examples to run through. Reporting and coding/analysis are the obvious tricky ones. If they can't do it themselves, as they aren't technical enough, get them to come back with the solution later.
6 Decide best fit
6.1 What fits your wish list best? Be prepared to compromise, but be clear what those compromises are, and why (and how you are going to cope with any rsulting complications).
7 Work out practicalities
7.1 Can you negotiate a charity discount? Be given extra time to pay? Will you in fact have the cash in the bank to pay the bill when needed?
7.2 Timing is vital (again). The obvious target is beginning of a new financial year, to start using the package in earnest ('go live'). However, this may be a bad idea - will you be able to cope with all the year-end sorting out at the same time? It also means that there is no fall-back if something goes wrong with your timetable, unless you completely re-think. The only real rule is go live at the beginning of a month, or perhaps a quarter if that is an important time period.
7.3 Parallel runs are strongly recommended, where you run both the new computerised system, and the old one (manual or whatever) at the same time, and compare results after a month or two. In practice, this level of sophistication rarely happens, but you do need to do some sort of dummy run, and get proof that your systems will work.
7.4 Who will install the package on to the machine(s). If you have a network, who will be responsible for this aspect? The package supplier may not know enough about networks, and your network consultant may have no idea how an accounts package needs to be set up. Get them to talk to each other (easier said than done)!
7.5 Who will set up the accounts structure? Who will enter initial data? Do you need the auditor's involvement to ensure the structure will meet their needs, and the opening data is correct? Design/adapt your paper systems to make data entry and referencing easy.