Strategic considerations for software implementation

Knowing what your over-arching priorities are before you start shopping will ensure you build an ecosystem of software that meets your needs, regardless of where that software is hosted. At a fundamental level, there is a need to establish what matters most – is it the user experience (be that internally, or for customers/clients in externally-facing solutions), reporting capabilities, security, compliance, or even simply cost? And what is your over-arching business, technology or data strategy? With so much choice available, taking the core objectives of the business as a starting point can be critical to selecting the right solutions. ICAEW’s 2023 research into the mid-tier software market shed some light on what firms cared about most when adopting software solutions which included easier integration and more accessible information about the software.

Perpetual licensing or subscriptions

There are two main options for software licenses – perpetual and subscription. Perpetual licenses are a one-off cost to access a specific version of the software indefinitely, sometimes including a fixed period of software updates. This can make costs easier to manage as perpetual licenses are usually treated as intangible assets on the Balance Sheet. However, functionality can quickly become outdated, and support and resolution of bugs may not be forthcoming after an initial period. Typically, perpetual licenses are not available for Software-as-a-service (SaaS) solutions hosted in the cloud.

Subscriptions are increasingly common for software, and particularly cloud-based applications. Monthly, annual or multi-year subscriptions can be purchased on a rolling or fixed term basis, giving greater flexibility. There is usually a lower upfront cost, and they are treated as an operating expense on the P&L, but in the longer term can sometimes result in a higher overall cost to the business. Further themes around licensing for SaaS solutions are explored in contractual considerations.

Off-the-shelf, customised or bespoke

Based on an understanding of the functionalities you require, it will be necessary to decide whether you want to purchase software that is designed to be used completely ‘out of the box’ – that is, everyone who has the software has the exact same experience – software that allows a level of customisation to suit specific business needs, or software that is completely designed from scratch to precisely deliver on business requirements. This is a strategic play, as off-the-shelf solutions typically require less maintenance and can be quicker to implement but afford less opportunities for a business to use its software to differentiate to competitors, and can pose more challenges when trying to integrate with business processes and other software applications. 

On the other hand, where bespoke solutions cannot be built in-house due to skill, cost and time limitations, the implication of allowing a third-party vendor to have complete control over the bespoke solution may mean challenges related to relying on the vendor for perpetual fixes, support and maintenance. Customisable software can provide a reasonable middle-ground, and it is increasingly the case that SaaS solutions can be customised to some degree, though it is important to be clear just how much customisation is possible prior to purchase.

Trajectory of the vendor and business

In the accounting technology space, there is a huge range of software solutions provided by a huge range of vendors. In recent years a number of startups have appeared; often they are more agile and responsive than larger, more established players, offering something unique in the market, and are more driven to win and retain custom, but with this comes the risk that they over-commit, lack the scale to provide sufficient support, are bought out and subsumed into another product, or simply go out of business. 

Commonly, software providers share their development roadmap to demonstrate to current and prospective customers that there is ongoing investment in the product, and a growing list of features in the pipeline. It is advisable to review historical features and establish whether they were delivered in line with expectations; this can be a good indicator of the trustworthiness of the development roadmap. It’s also important to evaluate if the software meets your functional requirements with what’s currently available or if there is too much reliance on a future development roadmap that may or may not realise.   

Choosing whether to go with a tried and tested solution, or a new entrant to the market, should be a conscious, risk-based decision, considering where the vendor is now, where they plan to be and their track record in achieving their ambitions. It should also reflect the size and trajectory of your own business – ensuring that you pick software not only suitable for where you are now, but where you expect to be in a few years’ time, will avoid having to go through the whole procurement process again when you outgrow the capabilities of the solution. Further software risks are explored in Managing software risks 

Best of breed vs all-in-one suite

When considering the implications of adopting any new software solution, it is useful to evaluate if your strategy leans towards a ‘best of breed’ or ‘all-in-one suite’ approach. 

Best of breed

‘Best of breed’ refers to software solutions or systems that have been developed and designed for a specialised function or niche. This is often considered an uncompromising approach, ensuring the best software for every function is part of the overall technology stack. It can give business unique advantages (as few will have the same software combination), and it can reduce business continuity risk as the dependency on any one piece of software is reduced (although tight integration may counteract this).

While ‘best of breed’ solutions are tailored to the business and can deliver an excellent array of capabilities, adopting this approach can mean a complex array of solutions that can be challenging to manage, maintain and integrate. At a contractual level you may be dealing with a dozen or more separate agreements, each with their own terms, and customer support for each solution would also be completely separate.

All-in-one suite 

‘All-in-one suite’ refers to an approach where solutions that can perform multiple functions are delivered in a single software package, an all-in-one solution. Adopting a single integrated solution can simplify implementation and management processes and help to standardise the use of technology across the business. Such solutions may be modular, still allowing a degree of flexibility in which components are implemented. Maintenance of the solution and database is also usually easier. Costs can be lower through simple economies of scale (adopting one larger piece of software rather than multiple smaller ones). However, this approach involves compromise; very few software suites are perfectly aligned to business requirements. The software can also become ‘sticky’ as it is tightly integrated to the business, making it harder to move away from the software should the need arise.

Integrations 

Most cloud software providers will support integrations with other software to some degree. It is worth understanding how flexible these integrations are: does the software provider make their APIs available on an ‘open source’ basis, or are they tightly controlled where only specific integrations are available, at the discretion of the vendor. Open APIs can mean more work for businesses to develop and support the integrations, potentially involving additional IT consultancy support which the business becomes dependent on, but can deliver a solution more suited to the businesses’ needs. More tightly controlled, pre-built integrations may mean higher quality, reliable, supported solutions, but may also cause problems if the vendor changes its integration strategy and decides to switch off integrations that you rely on – this can happen when one software provider is acquired by another that enforces exclusivity on the integrations.

There are also a range of third-party integration solutions available, such as Microsoft Power Automate, Zapier and Boomi, which have a range of ‘connectors’ available to build your own integrations – this can provide a lot of flexibility but comes at the risk of a more fragile ecosystem that can be prone to errors and issues with data quality. Regardless of the type of integrations used, testing them thoroughly is vital as integrations that appear to work on paper may not always deliver as expected. Depending on the nature of the agreement and application being used, it may also be possible to ask the software provider to integrate their service with a piece of software that you run. Ensure that there are specific, measurable targets set when making such agreements so that the integration is deemed a success by both parties and has been fully tested for interoperability. Once a software developer deems a project completed, it can be very difficult to acquire additional development time to fix bugs and provide future enhancements when the software is in the cloud. It’s also important to note that you may then be reliant on that software developer for the additional integration. It is also important to discuss the cost associated with additional integrations and customisation at the outset as prices may be hard to negotiate once you are locked in to an agreement.   

Make sure you understand the impact of software integration with common business applications, such as Microsoft Office, as these integrations can significantly enhance efficiency by reducing manual data transposition. However, a vulnerability in an application that has access to your email could also make your email vulnerable, so it’s vital to understand the specifics of what the integration does and the data it can access and impact.

Additionally, it’s worth noting that integrations create dependencies. Removing one application from an integrated stack may have unintended consequences on other applications. So, it is important to ensure nothing stops working if you choose to remove integrations between applications. 

It may be beneficial to consider a governance process over the APIs and integrations being used to avoid issues with data exposure, broken authentications and misconfigurations in the long-term.

A significant benefit of integration and the linking of software products is a seamless customer or client experience. For example, one-click invoice payment tools can deliver integration between accounting software, invoice generation and cash receipt. Open Banking can utilise direct bank feeds to automatically reconcile between bank accounts and ledgers when payments are received or made. 

Reporting and interrogation apps provide further tools to provide an enhanced service as integration of systems can allow integrated reporting. Note that while more organisations are choosing to rely on in-built reporting functionality and dashboards, it’s important to determine if the in-built reporting fits the organisation’s requirements. Where it doesn’t, you should evaluate if other options such as accessible APIs or data download capabilities are available to build your own reports.

An integrated software environment can also enhance security through centralised authentication across multiple applications, known as single sign-on (SSO), explored in Managing software risks. 

Migrations between platforms 

As with all industries, software providers will be very keen to win business and reluctant to lose it. The offer of free migration assistance when moving to their software is intended to help overcome the difficulties of moving platforms. Of course, in theory such difficulties can be avoided with an awareness of the terms when commencing an agreement or even requesting additional terms to consider the ability to migrate away from a solution, but this is not always practical.

In one example, it was cheaper for an organisation that was tied to a specific software platform to sign a one-year contract with a competitor they had no intention of using, purely because they offered migration support. After they used the new software to obtain the data, they were able to move to their desired target solution, one that gave them greater control of their data. 

We recommend simulating a migration exercise to or from a chosen software provider during a trial phase. Working through the process with a limited amount of data will help to determine whether it’s feasible to migrate larger volumes of data later. If it’s deemed likely that a migration would be necessary but would take a significant amount of time, (months, or even years), then commercially it would be advisable to sign a contract for at least that amount of time to reduce costs.