A lot of you seem happy with old-school accounting software, despite major advances in technology. So how can you tell when it's time for a change?

1 Do you have a problem?

If it ain’t broke, don’t fix it? Well, up to a point. The trouble with financials systems is that you learn to tolerate their foibles and weaknesses. Your team probably have their favourite workarounds for the system they’ve been using for years – and, in any case, newly implemented systems can be flaky, the training is a hassle and migrating data a nightmare.

It’s usually only when something goes badly wrong that you’re prompted to act. But tolerating an old workhorse could be draining resources and preventing you from adding value – so it pays to keep testing it. “We have a steering group that monitors the performance of our financials systems,” says Wayne Smith, IT systems manager at Birmingham International Airport (BIA). “There came a point when we realised it was costing us time and money to keep maintaining the old system. It also had a poor image internally – so we took the decision to replace it.”

2 Ask your team.

The people with the clearest idea of how your old system could be slowing things down are your own team. “For us in the finance function, data extraction was the big problem,” says Jane Clarence, finance manager at BIA. “To produce reports, we were having to output the data, re-format it and insert it into Excel. We tried using an Excel add-in, and then our software provider suggested we buy a dedicated reporting and analysis tool. But we suddenly realised that the money we’d have to spend on that would go a fair way to buying a brand new system.” As Smith puts it, “Finance just wanted a system that made their life easier.”

Poor data management is a common complaint with older systems – especially if your business has moved on since it was originally installed. “We’d gone through a ‘lean processing’ project for the operational parts of the business, and we discovered that the financials system couldn’t keep up,” says Ian Cleary, FD at Industrial Power Units (IPU). “The financials had been set up in the late eighties – the business has changed a lot since then, and the data structure was all wrong. We realised there must be better ways of managing all that information.”

Although you can probably guess what your team thinks of your existing financial software, some FDs report positive experiences from using a more structured approach. “We issued a formal document that asked for ratings on 30 different parts of the system on a scale of one to five – and there were fours (poor) and fives (very poor) in 20 areas,” says Chris Lang, FD of Cambridge Regional College (CRE – see box, The FD’s View). “That wasn’t all down to the software; the processes we used were also weak in areas. But it gave us an all-round view of how things had to change.”

3 Ask the business.

Staff throughout your organisation ought to be able to interact with the finance department – and especially with the accounts data you manage. “Increasingly I’m seeing customers who want specific functionality that takes finance systems out into the business,” says David Pinches, director of Accounts and ERP at Sage. “They want financials that integrate with their other systems, and we estimate that up to 70 per cent of our mid-market implementations are now related to this kind of cross-organisation integration. People aren’t just looking to upgrade their financials, they’re looking to make finance part of the wider business and enable better strategic decision-making with more robust data.”

Of course, as FD you may be able to spot areas where there are problems that are invisible to operational users. “We’d ended up with 20,000 stock lines and 4,000 customers because users never knew how to remove them from the system – some of these hadn’t been used for a decade,” says Cleary. “When we did our big upgrade, we got them down to 4,500 stock lines and 1,000 customers – it cleaned up the whole system.”

That’s not to say that IPU’s users didn’t have a view on the roll-out, however. “I’d say 80 per cent of the people who wanted to use the data never used the system for processing. They were outside the core user base in finance,” says Cleary. “For them, getting reports meant referring to written instructions from someone in the finance team or just getting one of us to do it.” So, as part of their lean processing project, Cleary and his team held a series of informal meetings with users to get a handle on their day-to-day issues with the system.

At CRE, the users were brought in as soon as finance had identified the core problems. “Our initial research lead us to focus on three main areas: purchasing; student invoicing and credit control; and stocks, assets and goods receipting,” says Lang. “We invited in the key user departments in each area for workshop sessions with the finance team – it’s easy to pick up on general grumbles in the office, but we wanted to know exactly what was at the heart of each problem before we even thought of going to the software market and trying to identify solutions.”

4 Focus on processes, not software.

You could start with some fairly high-level aspirations for this evaluation project. John Lowery, director of finance and IT at Pennaf Housing Group, came to the conclusion that their existing systems would not support their vision: to be a “dynamic and flexible organisation”. “Our existing IT, both hardware and software, needed a complete review and rethink, which is what we embarked upon,” he says.

But at some point, you’ll need to get more specific. What does the finance function actually do for the business? Then, how are your business processes – both in the finance function and operationally – currently working? And how would you like them to look in an ideal world? Having interrogated both finance and business users, you ought to have enough information to map these out. And that map ought to give you a template for the request for information (RFI) document to go out to the software vendors.

“We mapped every process that interfaced with our financial system,” says BIA’s Smith. “That generated a two-inch thick document. The financial systems manager, the purchasing manager and I did a first pass of that to see what interfaces we’d need for different people in the organisation and therefore what functionality a new financials package would need. The processes dictated the functionality.”

5 The RFI.

It’s easy to become prescriptive in the RFI, particularly if you have half-decent technical knowledge. But it should explain to vendors what you want your new system to do, not how they should build it. Focus on function, not form.

“Our RFI wasn’t a hugely detailed technical specification, this was a slimmer document focused on our key areas,” says Lang. “For example, we only briefly touched on the nominal ledger. You expect core functions to be pretty standard technology. Where you do need to be clear is on how your business processes will be mapped onto the system.”

That’s not to say you shouldn’t be aware of the possibilities thrown up by technology. “When we started looking at what was out there, we realised how much things had moved on in the world of financial packages,” says BIA’s Clarence. Web-based systems, for example, could solve a range of the problems you’ve identified, from minimising user training to real-time update and reporting to ensuring that anyone who needs access to financial data can get it.

6 Meet the vendors.

“I don’t envy FDs buying new software,” says Sage’s Pinches. “Vendor evaluation is tough. We probably all do much the same thing at the basic level. And there’s only so much time to do your evaluation – you can’t spend your whole life benchmarking systems.”

But vendor evaluation shouldn’t be rushed. Begin by scoping out the market – visit web sites, trade shows and read up on the latest views in magazines. Get an idea of which vendors are likely to be interested in you as a customer, either by the size of your company, your sector or sophistication. “We went to Softworld, and that helped us cross a number of vendors off the list based on the features we’d specified,” says BIA’s Clarence. “Just chatting to the vendors on their stands gave us a good overview – it was a useful on-the-spot test of what they could offer.”

Then get the RFI out to the ones who look likely, then make an initial evaluation based on their replies. “If you can shortlist to two or three players through desk research, you can spend more time with them on site,” says Pinches. Most half-decent financial software installations will be a five- or six-figure sale. So they owe it to you to make a decent presentation – tailored to your particular needs – and to demonstrate their products to you and your users. “Do some workshops with the technical people from the software company, too,” says Pinches. “You’ll probably have been spending most of your time with salespeople up to then, but in these presentations, you want to get a good idea of exactly how this thing is going to work before you sign up.”

It’s at this stage that the technological capabilities of different systems might win you over. “We assessed a range of financials systems and Kypera came out top because of the level of integration and functionality between its products and our main systems,” says Lowery. “A key factor in the choice was that they were able to provide additional applications such as purchase invoice processing, web order processing and so on.”

7 Get customer references.

Most vendors will give you “happy” customer contacts. But they’re still valuable to you ahead of your final decision. Check out your peer companies in the same sector and find out what kinks and quirks crept into their installation process – even if they used a different vendor this may yield valuable insights. You can also check out user groups for particular products, either online or (particularly for the bigger vendors) at user events.

Then visit the reference sites, even – especially – if you’re down to your chosen supplier. Seeing how the FD, their team and the business at large makes use of the system “live” will give you clues that probably won’t emerge anywhere else in the process.

It’s not always easy. “There aren’t that many airports, and most of the larger ones are probably running ‘tier one’ systems from the big vendors,” says BIA’s Smith. “We were looking at ‘tier two’ software and since vendors are reluctant to offer reference sites that aren’t 100 per cent positive, we decided to limit that part of the process. But we did spend some time at a couple of the shortlisted vendors’ user group events, wandering around and chatting to customers informally to get the less rose-tinted view.”

8 Nothing beats experience.

Most of you will have done one or two major systems roll-outs on your way to the FD’s chair. But if you’re uncertain about any part of the process, get advice. Talk to more seasoned FDs – even hire your own, independent consultant for a few days to look over the tender process, the vendor feedback and the contracts.

And use your own people, too. “We had one chap in the team who’d used Access Accounts before, and his input was really useful,” says Clarence. Ultimately, the chances of delivering a successful systems implementation are greatly heightened by turning finance and business users into stakeholders and letting them drive your decisions.

FD's view: a model beauty parade

Chris Lang is the FD at Cambridge Regional College, one of the UK’s biggest further education institutions. He’s recently rolled out a new system from Symmetry via a
rigorous process for evaluating the college’s needs. “The college installed Sage in 1994/95, when it had a turnover of £13m. Now we’re a £29m business, and the finance system just hadn’t kept up.

“Our project started in 2002, when people in the finance function started to say the system was holding them back. There was no interface with other departments – except on paper. It was a huge burden in terms of time and effort. We’d take the numbers out of Sage, re-key them into Excel, tweak it after consulting with operational departments and then use spreadsheets to come up with management reports.

“I joined in February 2004. I twigged onto this problem fairly quickly, so we took guys from the team off-site for an afternoon, looking at the system module by module to see what problems it was creating and analysing our internal processes. Then we widened it to bring in user departments.

“Once we’d established what wasn’t working, we started to feed in ideas about functionality, stuff that I’d picked up from keeping an eye on the software market. So where we might have been discussing problems with paper-based processes, we started to think about screen-based solutions; where some jobs had been done on standalone systems, we started to float the idea of people working from a central system.

“Around that time we also wrote out what we thought the seven main risks of installing a new system would be – cost overruns, ignoring staff concerns, unproven technology... We kept that document with us at every stage to remind us to mitigate those risks at each decision point.

“By October 2004, we’d managed to pull together an RFI. The next step was finding an appropriate vendor. We looked at magazines and which companies had won awards. We went to Softworld – although we tried not to talk to too many people! More importantly, we talked to other FDs in our sector to get recommendations. That left us with a list of about 20 vendors, and we sent the RFI to all of them, along with a timetable.

“Ten took the RFI seriously; some even sent through lever-arch files full of supporting material, implementation methods, case studies and so on. We’d already decided on a scoring system: the RFI was framed with questions, so three of us scored the answers, then put together our ratings to create a ranking, one to ten.

“We also emailed all the customer references with another score-sheet based on costs, timing, support, functionality. We used that to re-jig our own rankings. In fact we weighted the scoring two-thirds to one-third in favour of the references. After that, we pulled out the top three as a shortlist.

“In February, we visited reference sites, which allowed us to get a more sophisticated view of how the systems worked. Then we invited each of the three vendors in for a two-day presentation. We gave them a list of five or six areas we planned to discuss, then brought in the finance staff or users who were involved in each process to quiz the vendor team. They also filled out evaluation forms which affected the overall scores.

“After all that, we had a big body of evidence to back up the decision. Symmetry had been second after the RFI, joint first after the references, but was a clear winner once they’d demo’d to staff. And with a rigorous selection process, we had masses of information to support the implementation, both about our own processes and how the system would work. We’d also asked the referees to give us the name of the consultant who’d run their project, so we knew exactly who to ask for.

“So the selection process really accelerated the implementation. My other big tip would be, talk to someone else who’s done a big systems roll-out if you’ve never done one before – and ideally in the same sector, so the processes will be familiar.”

The step-by-step approach

Having talked to FDs and financial software experts, we’ve identified five stages to procuring a new financial system. As Chris Lang points out, you’re looking to ask similar questions at each stage – and these should be geared to the running of your business, not some idea of technical requirements.

1) User feedback. This should help you understand what’s currently happening in your business and how finance, financial systems and other people in the company are all interacting.

2) Codifying processes. Formalising the user feedback and looking for opportunities to rationalise and update processes.

3) The all-important RFI. “This is the first time you think about vendors,” says Lang. A good RFI will help the vendor give whatever information you need more quickly. BASDA, the software industry body, has a free booklet on RFIs and selecting a reseller. Download it at www.basda.org or for a hard copy, try Access Accounting (0845 345 3300), which sponsored a print run.

4) References. Even supplier-selected reference sites will help you understand better how the technology will solve your own problems – and generate intelligence on the roll-out.

5) User feedback II. Expose shortlisted vendors and their technology to your team (the main users) and outside staff who are part of the processes you’re hoping to fix. Apart from anything, it’ll help ensure they buy in to the new package.

Where next...

www.access-accounts.com
www.kypera.com
www.sage.co.uk
www.symmetry.co.uk The software vendors chosen by our interviewees
www.basda.org The Business Application Software Developers Association has some useful guides
www.coda.com/evaluation CODA also produces an excellent guide to why you might need to upgrade and how to evaluate your requirements

Picture source

Tags: software, accounting system, vendor,

Real FD specials