When does an Excel spreadsheet system need to be replaced?

Excel is very powerful financial software. Financial modelling, reporting and analysis are just some of Excel’s strengths. It’s also readily available on nearly everyone’s computer.

So it’s no surprise that Excel is often the first software to which people turn to develop a new financial application, in businesses large and small. That is expedient and can be effective. But if Excel is used as the primary database or data warehouse, there is often a better alternative to which it is worth changing.

This is because Excel has significant limitations:

• Data storage is simplistic, so does not cater well for real-life situations where data is inter-related or in multiple dimensions
• A spreadsheet cannot be updated by more than one person simultaneously, and security is simplistic, so is not suitable for many multi-user situations
• There is nothing in-built for functions such as aggregation and multi-currency. Formulae need to be written, and it is easy to get these wrong or inconsistent. 
• It is also difficult to maintain links between spreadsheets, especially if some are being circulated for completion by other people.
• So it is difficult to make a spreadsheet system robust, and keep it robust as it evolves.  
• Data entry is often done manually or semi-manually, and is not subject to validation. So data entry is slow and prone to error. 
• There is no audit trail

As a result, many people know of situations where material errors have arisen from using spreadsheets, and occasions where spreadsheet systems have held the business back. Ringing a bell with you?

There comes a time when a spreadsheet system that stores data needs to be replaced by a more suitable database system. Excel can be retained for reporting and analysis purposes.

BENEFITS OF REPLACEMENT SYSTEMS

Replacement systems use a database to store data centrally and provide a number of standard facilities that automate the system:

• Data can be structured exactly as required
• Systems can automatically and reliably aggregate and consolidate departments, regions, divisions and companies
• Data entry facilities automate the load of data from source systems, which can then be done in more detail if required
• Multi-user systems allow simultaneous use by people in the same department or different parts of the business, with differing levels of access permissions
• Audit trails and other management controls are available

As a result, a replacement system can be far more reliable, quicker and more powerful than the spreadsheet system it replaces. Excel can still be used for reporting and analysis, so its strengths can be retained.

Here are some examples where Camwells has helped find and implement replacement systems, working with FTSE250 to smaller private businesses across different industries.
 

(1) GROUP CONSOLIDATION

This FTSE250 housebuilding group has devolved many of the finance functions to regional teams, whilst running a shared service centre for cash transactions.

The Group reporting function was entirely dependent on Excel, which resulted in a number of critical issues, including:

• The process for submission of reports and forecasts from regions was cumbersome and time-consuming for regional and Group staff alike
• Data entry lost the available detail, and there were examples of keying errors
• Where spreadsheets were linked, it was also difficult to control versions, so also prone to error

As a result Group reporting staff were spending most of the time running the spreadsheets rather than analysing the data, such as comparing regional performance. With additional regions being added as the business grew, the spreadsheet system was nearing breaking point.

The work carried out included:

• Understanding current reporting, forecasting and related processes, and opportunities for improvement, by talking to MDs, FDs and accounting staff at regional and Group level
• Producing an agreed specification that was then used to assess available software, principally through software demonstrations and “proof of concept”
• Selecting multi-dimensional software and configuring it to best represent the business, including the import of detailed information from the trading system
• Writing reports in Excel to take advantage of the improved data

The result is a more effective, quicker and more reliable system.

(2) BUDGETING AND FORECASTING

This quoted IT company had a budgeting and forecasting system consisting of a suite of complicated Excel spreadsheets which were sent out to relevant departments. The system had evolved over time so that the controller said “it was held together with sticking plaster”, in particular:

• Linking submitted spreadsheets and controlling versions was difficult and risked material error
• Finding correct versions to compare to actuals was difficult

Again a specification was agreed that would allow the entire budgeting process to be carried out in a centralised system, which would clearly handle different versions. Software was selected that would:

• Allow the company’s overall forecast financial position to be produced reliably at the press of a button, including balance sheet and cash flow projections
• Make the detail of each version easily available to authorised people to review forecasts and compare to actuals

(3) PROJECT ACCOUNTING

This quoted software house had a packaged software system for the basic accounting. But there was no module suitable for their project-based order processing, which involved the sale of their own software, buying in hardware and supplying various associated services.

This was controlled in an integrated suite of Excel spreadsheets. But as they had become so unwieldy and difficult for the order processing team to use, the manager was threatening to resign.

The spreadsheets were analysed and a specification agreed. Various software options were considered including:

• Third party add-on module to existing accounting software
• Custom-written add-on module
• Complete replacement

The decision was taken to keep the existing accounting software, and get an add-on module custom written.

The end result was a system so good, when the business was acquired the system was used for the enlarged group. Unusually the acquired company personnel kept their jobs, from FD to junior clerk. Clearly a most welcome benefit!

(4) EXPENDITURE TRACKING

This privately-owned multinational was developing an offshore oilfield in Africa, which required cost records to be maintained and reported on a cash basis to the national government, alongside normal accruals accounting.

These cash records were being collected in Excel, but the use of multiple currencies and the reconciliation of cash and accruals figures was becoming increasingly difficult. One multi-currency accounting database was the objective, together with a sophisticated new purchasing system.

The management’s preference was for a cloud system that could be easily accessed from a variety of locations. After a specification was produced, various cloud options were assessed alongside the on-premise software commonly used in the oil and gas industry.

One multi-currency cloud accounting system was found that would provide the dual cash/accruals accounting more simply than with the on-premise option.

(5) ORDER PROCESSING

This corporate subsidiary was providing IT network systems where all the components were being bought-in on a “back to back” basis, alongside their own services.

Sales order, purchase orders and accounting records were on separate Excel spreadsheets, with no logical link between them. Growth in the business required additional personnel, which required a multi-user system.

The decision had been made to replace the spreadsheets with standard accounting software and a custom-written order processing system.  This now needed to be implemented, and internal people did not have the time and expertise.

The initial system was implemented on time for the start of the new accounting year, and then various improvements made to cater for changes in the business.

One key benefit of a proper database system was that purchases of equipment supplied to specific customers could be clearly identified. This allowed supplier rebates to be claimed, totaling some £600,000 per annum. This literally doubled the company’s profits.

As the MD said, “We couldn’t have done it without you.”



If you know of any similar situations that need to be resolved, do ring Chris Challis on 07836 774439.

Driving Business Performance

What should be on your dashboard?

If driving best business performance is your objective, Key Performance Indicators (KPIs) are a very useful way to focus attention on what really matters.

Your IT can help you in three ways:

1. Efficiently collect information required to calculate the KPI
2. Report the KPI, plus drill-down to further analysis, explanation and exceptions
3. Deliver these reports on a timely basis to people who need it, be it on a desktop, laptop or mobile device. Dashboards are a popular method.

But the IT is only a tool. It’s what you do with it that counts. And in this case, what are the right KPIs for your business?

In financial reporting, the term KPI tends to be used for key results such as revenue and profit. But the origin of the term is quite different. The idea is that KPIs are just that – key indicators of performance. Not just what has been achieved financially, but what's driving that achievement.

Firstly what drives business success? These are the business’s “Critical Success Factors”. Secondly how can the CFSs  be sensibly measured? These indicators can be both financial and non-financial, and can be termed Key Performance Drivers (KPDs).

Let’s take the example of an airline. If planes leave on time, then:

• Customers will be pleased, will want to use that airline again out of preference, and will recommend it to others
• Staff rostering, cleaning, catering and other aspects of the business can run efficiently, at minimum cost.

So a Critical Success Factor for an airline is that planes should leave on time. How that is measured is the KPD. Perhaps the percentage of planes leaving on time, say within 15 minutes late. Plus explanations for any leaving more than that time limit. By reporting daily, and perhaps more frequently, action can then be taken by management on a timely basis.

It’s therefore useful to think of KPIs in two main groups:

1. KPIs such as revenue and profit, which are the results reported on a periodic basis such as weekly or monthly
2. “Key Performance Drivers” (KPDs), often non-financial, which reflect what is happening in the business on a much more frequent basis. Management can then take timely action

By focusing on a restricted number of KPDs, which reflect the Critical Success Factors, management attention can be focused on what really matters. The IT tools can then make data collection and KPD reporting both practical and valuable.

In many businesses, a common complaint from management is that they get too much information. KPIs and KPDs provide the focus to allow reporting packs to be trimmed right down.

If you are not getting the right level of management information you need, when and how you want it, isn't it time this was reviewed?

A fresh and independent pair of eyes can make all the difference. Do call Chris Challis on 07836 774439 to discuss.

Cloud Computing - Implementation Process for SaaS - How Different from On-Premise?

We looked at how the selection process needs to be tweaked to choose a cloud SaaS (Software as a Service) solution, compared to traditional on-premise software.

Here is a quick summary of a typical on-premise implementation process for a mid-market solution, and how this needs to be changed for SaaS. The same principles also apply to small and corporate systems, simply adjusting the level of work required.

Actually very little changes for a system of equivalent scope and complexity. For example it is still important to get the configuration right, to get reporting right, and to make sure users are sufficiently familiar with how to use the system.

In addition to overall project management and change management, the key steps are typically as follows:

.	STEP	CHANGE FOR SaaS
1	Project Initiation & Planning	No difference
2	Software Installation	Software already available online
3	Physical Design Preparation	Only if integration
4	Pilot/Prototype Design & Build e.g. Expand Reporting Requirements, Design Configuration Options, etc	Access Security & Disaster Recovery
5	Build Pilot System	No difference (except it's online)
6	Test The Pilot System	No difference
7	End-User Training	No difference
8	Build Live System	No difference
9	Data Conversion	No difference
10	Live Running	No difference
11	Continue To Develop Reports	No difference
12	Post-Implementation Review (After 3-6 Months) Carry Out Remedial Action	No difference

In practice, for larger systems the implementation may be phased, in which case much of the process is repeated for each phase.

If you would like to know what is involved in each stage, such as developing workflow and suitable security, or how the process needs to be adapted to apply to your specific situation, do contact me on +44(0)7836 774439, or by email at challisc @ camwells.co.uk (please remove gaps first). I look forward to talking to you.

Or do feel free to leave a comment ...

Cloud Computing - Selection Process for SaaS - How Different from On-Premise?

Much has been written about the pros and cons of cloud SaaS (Software-as-a-Service) compared to traditional “on-premise” computing. SaaS covers the likes of accounting, customer relationship management (CRM), Facebook and a multitude of other business and consumer applications.

Here’s our own summary of the benefits and risks of SaaS.

But relatively little has been written about how the process for selection of business software has changed with the availability of SAAS. How much has the process changed?

I’ve been involved in selection projects for many years from three perspectives:

• Leading projects in industry
• In a sales role in a reseller of accounting and business software (so I know the tricks of the trade!)
• In consultancy with PWC and Camwells advising clients

Many of these selections have been of mid-range systems, but also corporate systems and simple systems for small businesses. Some selections are now just for SaaS, some just for on-premise (where cloud provision is not adequate in one way or another), and some with an open mind as to the final solution. So ideally a methodology is needed that caters for selecting a SaaS and/or an on-premise solution.

Camwells has a selection process that does indeed cater for both.

Nonetheless every now and again it’s worth taking a look at what others are doing to see if the process can be improved, and now is the time to do so!

Firstly it’s worth looking at the software industry’s view on the process. BASDA (the Business Application Software Developers’ Association) is the clearest representative body in the UK and has published a recommended procurement process. There is no mention of either “cloud”, “SaaS” or equivalent concepts (I’ve been using SaaS ten years since early 2000), but the booklet sets out a basic process which includes two key aspects:

1. The replacement of the bulky "Invitation to Tender" with a shortened “Request for Information” (RFI). I prefer to call it a “Request for Proposal” (RFP), to emphasise that a commercial proposal is expected in response to the requirements.
2. Bringing forward the detailed product testing to the evaluation phase prior to purchase rather than after the system has been installed.

The second point actually makes their process adaptable to the selection of cloud SaaS systems. Another body representing UK software developers, Intellect, makes some key points in the implementation process section of their white paper “The business case for Software as a Service”:

1. Many SaaS products have a free-of-charge evaluation period, or a few users can be set up at minimal cost before any major commitment is made
2. Conversely not all on-premise software vendors will allow a free or low cost on-site evaluation, as software (and possibly hardware) needs to be installed on client’s premises to even do a small (“boardroom”) pilot. On-site installation is not needed with SaaS (assuming you have internet-enabled PCs), which also means saving time to start the evaluation
3. If the risk of failure is low, especially with smaller systems, a SaaS service can be used straight away
4. If the SaaS trial is unsatisfactory, it is quicker and cheaper to stop any further work with that supplier and consider other options
5. But Intellect also mentions that tasks such as evaluation of larger systems, data loading, user training etc are similar to on-premise

Other SaaS publications I’ve collected tend to focus on the pros and cons of SaaS, not on the selection process. Google searches across the globe didn’t identify much new and useful either.

So here is a quick summary of the Camwells selection process, and how it can flex for SaaS. The focus is on mid-range solutions, but the same basic process is equally valid for small and corporate systems.

This process is broadly consistent with BASDA’s process, but with a number of practical differences. For example, we’ve found that client management prefer to discuss and collectively sign off an internally-focused “User Requirements Specification” (URS). This is in a suitable format to be tweaked into the “Request for Proposal” (RFP) sent to suppliers, or can form the basis for evaluation of SaaS offerings.

The key steps are as follows:

.	STEP	FLEXING FOR SaaS
1	Project Initiation (Steering Committee etc)	No difference for SaaS
2	User Requirements Specification (Background, Objectives & Benefits, Scope & Interaction, Key/Special Requirements)	No difference for SaaS
3	Supplier Long List	No difference for SaaS
4	Request For Proposal (RFP)	Free/Lo-cost trials instead? Dependent on complexity, may still require supplier assistance
5	Assess Supplier Proposals	If send out RFP
6	Supplier Short List Demos	Useful in all but simplest cases to have supplier involved to bring system to life and help configure pilot
7	Supplier Finalist(s) Demo(s) if required
8	Preferred Supplier Assessment	Different issues
9	Enter into Contract	Different content of contract, probably non-negotiable

Here are also the key differences in the implementation process.

Cloud SaaS providers tend to market their systems as being more intuitive, easier to use and quicker to implement than on-premise systems. As explained above, there is truth in respect of timescales. But “ease of use” is worth taking with a pinch of salt - it really depends how well the system is written, and whether functionality has been limited. As with on-premise software, the key to the selection process is to see through the gloss and to ask the important questions to ensure the offering and supplier fits your needs, before you have committed your business and your reputation.

In conclusion

Selecting SaaS and on-premise software should follow the same basic process, though SaaS systems can be quicker in certain respects. The service nature of SaaS means different issues to consider, and a final contract that’s significantly different. Whether SaaS or on-premise, the key is to start with a professional "User Requirements Specification" that clearly sets out objectives, used both for selection and then for implementation.

If you would like to know what is involved in each stage, such as how to prepare for demos and evaluation, do contact me on +44(0)7836 774439, or by email at challisc @ camwells.co.uk (please remove gaps first). I look forward to talking to you.

Or do feel free to leave a comment ...

Cloud Computing – Hot Air or Business Reality?

Thanks to Microsoft for reminding me of a paper Ted Schadler of Forrester Research published back in 2008. In the thick of the global meltdown, he advised CFOs to take a close look at cloud computing for email, collaboration and enterprise applications.

The points are equally valid today, though Ted focused principally on benefits. So let’s look at both the pros and cons

Key Benefits

Ted mentioned three key benefits:

1. Speed: Accelerate a project roll-out

Cloud services (SaaS, PaaS & IaaS) are hosted remotely. Typically quicker to get through budget approval, and no need to wait for delivery of hardware etc. But for SaaS, which involves packaged software, don’t be fooled by statements that all you need to do is pay monthly fee and forget about help with set-up, project management, change management, training etc. These need to match those of an equivalent on-premise solution, whether you start with a pilot or a full-scale implementation. A requirements specification is also recommended, at least to establish which SaaS system(s) should be trialed.

2. Focus: Outsource non-core competencies to a service provider

Let the “specialists worry about the nuts and bolts so that you don’t have to” is a compelling argument, especially for small and medium-sized businesses that often struggle to do the basics in back-up, disaster recovery and general systems administration. It can help release IT staff for better things in larger organisations.

3. Funding: Pay as you go rather than pay up front.

This is also compelling for any application, but especially when the services offered would be completely unaffordable to run in-house. However less money up-front to the supplier reduces what they can spend on quality pre-sales work, and raises the risk of suppliers going out of business (compared to traditional package software houses) unless they are well funded.

Further benefits for Software as a Service (SaaS cloud)

Five more principal benefits can be added:

1. Functionality can be shared from any location with an internet connection, from any device with a compatible internet browser. This allows remote access from multiple sites, by mobile workers, and collaboration with third parties (including customers and suppliers)
2. Regular upgrades provide new functionality more quickly, without the hassle of installing them. However there are issues with upgrades in multi-tenant systems (see below).
3. Easy to increase usage when needed (but not so easy to reduce it)
4. Easier to pilot an application, and withdraw quickly if necessary at lower cost and embarrassment!
5. Better backup and disaster recovery than a typical on-premise installation, certainly for smaller  businesses

Cons, Pitfalls & Risks

Turning to the “cons”, this is my take from 10 years using SaaS systems for ecommerce, email, ebanking and other purposes. As Intellect says “While the SaaS model offers significant advantages over on-premise, I does carry potential risks that must also be considered”:

1. Top of my list is reliance on an internet connection. As Andy Scott says “Loss of Internet = loss of information systems. PERIOD.” At each place of use, it is a must to have at least two totally independent reasonably high-speed internet connections, either broadband + 4G, 2 different 4G services, or some other combination.
2. Top of most people’s concerns is security. "Security" covers a multitude of sins, from internet reliance (as above), user access, encryption, vendor staff, leavers/transferees, to back-up and disaster recovery. This all needs to be within compliance with the relevant Data Protection legislation (e.g. FSA). There may in fact be an improvement using SaaS by comparison to your existing on-premise solution, but needs a careful look.
   
3. Security is closely related to data ownership. What’s in the vendor’s contract? Do you have (or can you quickly get) your own data back-ups, and the ability to move to another service if and when you need to?
4. As mentioned above, upgrades are both an advantage and potentially a critical issue, depending on the SaaS vendor and how it operates. Issues exist around timing, testing, user procedures, training, etc
5. SaaS solutions can usually be configured, can often be integrated with other systems, but can rarely be customised as easily as on-premise solutions. What you see is what you get!
6. Contingency planning is vital. Any lack of a credible contingency plan for a business critical application needs careful consideration, depending on the circumstances.

Ever "positive but cautious"

The quality (and indeed acceptability) of a specific supplier and its offering for a specific application is fundamental to the success of your cloud adventure. There’s no escaping proper due diligence! Assuming the cloud is an acceptable approach for the specific application, given the available offerings, it’s a question of which cloud.

Upgrade or replace?

If you've been using financial software for a few years there will come a time when you will be invited to upgrade the software, either due to business expansion or to avoid losing support. Many people like to take the opportunity to review alternative software to cover various possibilities such as:

• FUNCTIONALITY: The business is likely to have changed. New types of business may have been added, the business may be much larger or smaller, and different personnel may have different preferences.
• MANAGEMENT INFORMATION: Reporting may not be fulfilling the business needs, especially for use on mobile devices
• EFFICIENCY: Different software may provide different functions for more efficient processing
• REMOTE ACCESS: Cloud-based software and hosting options have advanced significantly in recent years, and may provide a more practical solution where access is required from multiple locations
• SUPPORT: Problems with the effectiveness of support
• COST-EFFECTIVENESS: Suitable software solutions may be much cheaper than the existing solution, especially if support costs are currently expensive

Camwells can help you review the market, on a completely independent basis. Does it make sense to change, or is it best to upgrade the existing system?

A thorough review of requirements is needed. Even if internal staff have the skills, they rarely have the time. Camwells can provide both.

As an example, we helped an AIM-listed business review their accounting and order processing systems prior to a large anticipated increase in sales of a new product. We found that:

• The accounting modules were basically sound
• But the order processing modules had few other users, and the support company did not understand these modules. As a result there were major problems with the support service.
• Sales reporting was a major issue, for which no clear solution was available
• Whilst most requirements were fairly standard, the new product was a fuel additive that involved Fuel Duty. This meant special requirements for sales invoicing and tracking duty.

So:

• We compiled a User Requirements Specification to cover all the key business requirements, including reporting, special requirements and core requirements. Nothing important can be assumed to be available in alternative software.
• This document was issued to potential suppliers as a "Request for Proposal", including the incumbent supplier, alternative suppliers of the existing software, and suppliers of alternative software
• This was followed by discussions and software demonstrations with short-listed contenders
• A visit to the incumbent supplier made it clear they were not interested or capable of providing a suitable support service, and so were ruled out.
• A final choice needed to be made between a better supplier of the existing software, or making a change. Both required a significant investment.
• Whilst there were pros and cons, a decision was made to change systems. There was concern about longevity of the existing order processing modules given their low usage, and the alternative system was generally easier to use.
• In slightly different circumstances the existing system would have been retained.

The independent and thorough assessment of options by Camwells allowed the client company to move forward confidently, with support of all the key people involved.

If you would also find such an assessment useful, do call Chris Challis on 07836 774439.