RSS feedsStruggling finance departments are often underpinned by a botched accounting software implementation, I wrote in the January issue of Best Practice. So how do you introduce a system that works?
Introducing a new accounting system is by definition a change project. But most of the time it is not treated as one because nobody is expected to get fired or roles to change. But by the time the new system is installed and running successfully, finance department staff will be working in radically different ways. That is, of course, what makes an implementation a change project.
The difficulty is that this is not necessarily why it began in the first place. As a consequence, people will carry on working in the way they always have and be unhappy because the system doesn’t do what they are used to, or how they expect.
The downside of not treating finance systems as a change project is that all the bells and whistles promised by the vendor are never flagged up to the people who might benefit from using them.
The secret is always to put process before system. An obvious and standard reason for a system upgrade is to improve the general level of controls, for instance. If a process change is introduced to increase controls at the same time as a new system, accounts staff and business managers cannot be blamed if they reject new procedures.
Similar, but not the same
An approach with a much better chance of success is to introduce the new control environment under the old system. Even if operating the new controls is clunky, staff will be used to them by the time the new system is phased in. And if the planning has gone well, they should be pleased the new control works better under the new system.
Here is a statement of the obvious: don’t under-spec or over-spec your new system. Consultants such as myself earn a useful living by fixing the problems generated by botched system integrations.
One of the most common messes that has to be sorted out is over-specifying. Whatever system you can think of, vendors will often try to install a heavier system than the company requires.
One IT director of a small growing company employing 40 people was given a quote for a well-known system where the consultant wanted to provide a quote without even visiting the business. On what grounds had the quote been prepared, other than wishful thinking? The conclusion is clear: system specifications have to be treated with a heap of caution.
What about under-specifying? When a company is growing quickly, or if the directors believe the business is about to take off, it seems sensible to plan and install an accounting system that is scaleable and will endure. But growth and business success is not guaranteed, and plans don’t always work out as expected, but you can hedge your system bets.
Given the uncertainty of any business plan, while aiming for maximum accounting system flexibility, you could minimise the investment by going for an Applications Service Provider (ASP) model, thereby transferring much of the risk away from the business.
Upgrade or improve
System upgrades can happen in tiny steps as well as big leaps. Before finance directors and their advisers go for the big upgrade they should ask themselves if they have squeezed every last bit of juice from the existing system. Finance departments should ask themselves whether the way of working has been completely aligned with the way the system was set up and designed.
All the features of the current system should be examined to ensure the finance department is not going through the hassle of upgrading for something it already has.
If the finance department does decide to go for an upgrade it has to decide how to proceed. One of the stranger conventions of system upgrade is the concept of parallel running. With parallel running, the new system is introduced alongside the existing system, both in operation at the same time. This allows the results of the new system to be compared with those of the old.
One of the major reasons for a system upgrade is because the finance department is dubious about the results emanating from the in-situ system and wants to be assured they are producing more accurate figures. So, if the old system and new system produce the same figures, does that increase or decrease your confidence in your decision to make that expensive and time-consuming switch? If the figures are different, do you assume the figures from the upgrade are right?
Another downside of parallel running is that the finance department does more work for seemingly no good reason.
Balancing act
The final point about system upgrade is to balance what the system is losing compared with what it is gaining. Trashing an old system in favour of a new one will, in all probability, be like throwing away decades of accumulated knowledge and experience.Not all will be lost, but a great deal of know-how on how to get it to work will have to be painfully relearned.
Go with the grain
Taking its proposed system upgrade seriously, a corporate began a process-mapping exercise to establish the right system for its needs.
Halfway through the process, an ERP provider made an offer that the FD thought was financially too good to turn down. The system didn't match the company's carefully mapped 'to be' process, but this was ignored because the price was right.
Once any company of any size has got a system that is functioning they should think very carefully before opting for untried and untested tools simply on the grounds of price.
And if you think that any company can make a system fit, think again.
Common error
One persistent fallacy around installing a new system is the idea that companies only achieve best practice and lowest cost from employing a common platform.
If a company is going through a period of transformation this won't work, particularly if the business is on the acquisition trail then the idea of one system needs to be placed on the back burner.
One multi-national had an Oracle-everywhere policy. This worked fine until it merged with a German company, which increased the enterprise value by 80%. The new acquisition had just installed a SAP system.
The Oracle-wide policy was reluctantly, but wisely stopped. If a company is in transformation mode, implementing a strategic system upgrade will end in tears and may cause system meltdown.
Peter Charles FCMA is a member of the Society of Turnaround Professionals and runs the consultancy firm PCL Ltd
For Charles’ first article on the finance function, go to bestpracticemagazine.co.uk/2208726
