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.

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. This is for anyone who wants to understand whether SaaS is something they should be using in their business; or for anyone selling SaaS who wants to understand potential customers' anxieties

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? [...read more...]

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

We recently 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 ...

[...read more...]

Organising software demonstrations

Software demonstrations can be very impressive, by focusing on the software's strengths and glossing over weaknesses. Beware losing sight of the basics. Will the software actually handle your type of business and its core needs?

It's therefore important to:

1. Have a clear summary of requirements
2. Organise and control the meeting to see how well the software covers those core needs, and flush out any key weaknesses

Essentials

Whether you are changing systems, or trying to make better use of existing systems, it helps to have:

1. Senior management commitment and support
2. A clear vision of scope, benefits and requirements in a "User Requirements Specification"
3. Suitable software and support
4. Implementation experience

These and other key factors are detailed below.

Testing Testing

Custom-written software obviously needs to be tested. But what's needed for software packages?

It's easy to assume that a package will have been thoroughly tested. Sadly it is rare for packaged software to be bug-free for three main reasons:

1. It will be unlikely that the software will have been tested with your specific set of systems parameters.
2. For new versions of software, authors are dependent on end-user "beta" sites that are prepared to test software before general release. The extent and depth of testing is dependent on the organisations involved, and restricted by the time they have available.
3. Not all identified bugs will have been fixed. Are any significant to your business?

Examples of bugs that I've seen go live include:

• Payment generation routine that didn't work. Cheques had to be raised by hand, and the delay meant some supplies were put on stop.
• System set-up problem that resulted in changes being lost. Training sessions became farcical.

Therefore testing of at least the key functions is worthwhile. This also provides the opportunity to develop and test the associated manual procedures. Are instructions clear, concise and complete? Printing can be a problem - does it work as expected?

By collecting representative transactions during production of the User Requirements Specification, the suitability of the software to cover the range of business can be checked. This should include checking if and how to make changes, for example if a customer order has to be changed or corrected.

A testing plan that includes each process, such as product set-up and credit note production, helps to ensure the system will be fit for purpose once implemented.

Why prepare a URS?

Are you adding to a system, upgrading a system, or completely changing it?

The "User Requirements Specification" (URS) is a powerful document that can be used to:

• Set a vision for the system and the benefits anticipated
• Clarify scope and boundaries, and interactions with other systems
• Agree requirements between departments
• Assess software and suppliers, often as part of a tender document of some kind
• Ensure software demonstrations cover what's important
• Avoid risk of inappropriate purchases (and they do otherwise happen!)
• Steer implementation to achieve the benefits

It's common for key issues to be highlighted by preparing a URS, that would not otherwise have become apparent until too late.

Depending on the scope of the system, the document can be very short, or somewhat longer. It's a matter of being concise, but with sufficient detail to achieve its purpose. Aspects to cover include, inter alia:

• Business background and future
• Objectives and benefits
• Systems context, architecture and interactions
• Management information
• Functional requirements, highlighting core aspects and what may be different
• Transaction examples
• Sizing
• Existing systems, and any specific issues to address
• Technical preferences
• Supplier aspects

If you would like to discuss how to go about preparing a URS, do contact me.
Chris Challis
challisc @ camwells.co.uk
+44(0)1628 632914

Key Factors for Success

Are you adding to a system, upgrading a system or completely changing it? There are some key factors that are crucial for success.

Most factors apply equally to packaged and custom-written systems:

1. SENIOR MANAGEMENT SUPPORT AND COMMITMENT

There will be times in the project when business priorities clash. It's important for senior management to make their commitment to the systems project clear, given the benefits to be gained and any problems the new system will overcome.

2. PROJECT PLANNING

Doing the right things in the right order at the right time is critical to success. Experience counts.

Where can quick wins be made? Should the project be phased? How?

When in the financial year should changes be made? When do staff have time? When would it be impossible?

3. USER REQUIREMENTS SPECIFICATION

The "User Requirements Specification" document acts as the cornerstone for discussions with prospective suppliers and to steer subsequent implementation. It can be incorporated into a "Request for Proposal" or "Invitation to Tender".

Key aspects include:

• Benefits anticipated
• The "big picture" vision and scope
• Management information
• Key processes, including communication with customers, suppliers and between departments
• Other functionality and system management issues
• Transaction examples for software demonstrations and testing
• Detail where important

The selection of a package requires less detail than for custom-written systems. But with packages, it's still important not to take too much for granted.

A formal sign-off procedure by relevant managers helps ensure commitment to the project and its scope.

4. SELECTION OF SOFTWARE AND SUPPLIER

Software requires support, during implementation and on an ongoing basis. The supplier is therefore as important as the software, be this the author and/or reseller. Factors include:

• Is the software used in your type of business?
• Is the software appropriate for current business size, with scope for growth?
• Does the supplier have experience of your size and type of business?
• What range of support services do they provide?
• Financial strength?

Software demonstrations will tend to highlight the software's strengths. It is critical to use the User Requirements Specification to uncover any important weaknesses .

5. USE A "SOFTWARE AS A SERVICE" SYSTEM?

Traditionally packaged software was licensed to be hosted by the end-user. Increasingly there is the option for hosting to be outsourced, with access via a web browser. Some software is only available on a hosted basis.

Hosted software is usually, but not necessarily, sold on a subscription basis - "Software as a Service" (SaaS). Payment is made monthly, quarterly or annually.

Whilst there are some clear attractions of a SaaS approach, it is not always practical. There are also some important drawbacks which have become apparent through experience, which the SaaS providers obviously do not highlight!

As the use of SaaS is a key strategic decision, it's worth making it with your eyes open.

6. IMPLEMENTATION MANAGEMENT

Implementation requires dedicated time and experience. Meeting deadlines is crucial. Missing a deadline can mean missing a window of opportunity in the financial year, and a substantial delay.

There are many aspects to successful implementation. Three to highlight:

(a) Actions need to be allocated to individual people. Over the course of a project there will be leavers and joiners. This all needs to be co-ordinated.

(b) Any external organisations involved in the project need to be actively managed. Availability of their personnel can be critical.

(c) All software needs to be tested. Packaged software may not have been used in your configuration, and is rarely bug free. It's important to run through all key processes.

7. TRAINING

Software is only as good as it is used. In the case of packaged software, it is also only as good as it is configured.

Software is usually sold as "easy to use". So is a car easy to drive once you've got the hang of it - but this takes tuition, time and experience.

Training of end-users and one or more "super users" is therefore vital for success.

8. STANDING DATA MANAGEMENT

Systems all require standing data to function correctly, such as:

• Chart of accounts and analysis codes
• Customers and suppliers
• Product and/or project details
• User roles and access rights

If administration of these aspects is not addressed adequately, the system will fail to perform as expected.

9. BACKUP AND DISASTER RECOVERY

Financial systems tend to be mission critical. It is vital that backup and recovery arrangements, including disasters such as fire and flood, are adequately addressed. This includes periodic testing.

10. POST-IMPLEMENTATION REVIEW

Often overlooked, a post-implementation review is important to establish that anticipated benefits have been achieved, or what is still required to achieve them.

It also allows the experiences to be captured to aid future projects.

IN CONCLUSION

There are some key factors for success when changing financial systems. Overlooking any one of these can result in anticipated benefits not being achieved, or the systems failing completely.

If you would like to discuss any of these aspects with me, do contact me.

Chris Challis

challisc @ camwells.co.uk

+44(0)1628 632914