Understanding your system requirements
Replacing your core finance administration systems is a big undertaking. Defining and closely managing the systems’ scope is key to a project’s success, and well understood requirements will help you to select the most appropriate system in the first place, or to prioritise the work for your in-house development teams.
However, in our system replacement projects we often found that the requirements had not been well documented, and there was a large piece of work required before we could even start on the implementation. So in our first post I will look at the types of information that you should gather and how you can prioritise your requirements, before you engage with a vendor selection process.
What do you sell?
All too often I’ve heard of situations where a shiny new system with whizzy screens and processes fails because it simply can’t support the products that the customer sells. You might think that all your products are “industry standard” but there’s a lot of variety across the finance industry. For example, within asset finance there is a huge variation from big ticket, small volume, highly sophisticated products to high-volume, asset-specific financing. Many software vendors are trying to work across many verticals and they may well not have all of the features that you expect. As you document your product features, it may help to pick out those that you think are industry standard as it will enable you to measure each vendor’s maturity in your particular market.
Identify the different types of contracts that you have with your end-customers, pull out the contract documentation and some representative agreements from your current system(s). If one of the objectives for your system replacement project is to offer new products, you’ll need to answer all these questions and more!
How are they priced, for example APR, and/or IRR and/or tax-based cash flows? If there’s a residual value, guaranteed minimum future value (GMFV) or balloon rental how is it determined?
What rental or repayment structures do you allow? Monthly, weekly, quarterly, up-front or one-off amounts, seasonal, etc.? Are the payments a fixed amount, or capital and interest? Are any payments based on usage? Do you have any interest free options (IFOs)? What happens if the contract isn’t repaid before the end of the IFO period?
How do you calculate interest? Is it a pre-calculated fixed amount or adjusted for early or late repayments? Is it a fixed rate, or linked to a variable rate such as LIBOR or SONIA?
In the case of asset finance, is there anything special about the assets being funded? What information do you need to capture about them – for example extras that affect the residual value? Do you use any internal or external classifications?
What are the end-customer’s options and/or obligations at the end of the contract?
How are the contracts classified and accounted for, for example as a mortgage, finance lease, operating lease, etc? Do you have multiple accounting standards (e.g. IFRS and local GAAP) that you need to apply?
What options do the end-customers have to end their contract early? How do you calculate early settlement fees, for instance outstanding balance plus penalty interest, etc?
What fees and charges do you apply, both up-front and in-life and how are fees calculated? Can fees be added to the amount financed?
What add on products do you offer, such as insurance or maintenance plans? How are they disclosed to the end-customer? How are they priced? How are payments passed on to the insurer or maintenance third party?
If you have broker, dealer or manufacturer commissions and/or subsidy schemes, how are these calculated? Are they paid up-front or throughout the contract? Are they dependent on the end customer’s repayments being up to date?
What types of securities do you require?
Do you do any white-labelling?
Having collated the contract documents and sample data, you can provide them (less any end-customer sensitive data) to your short-listed vendors for them to put into their system so that you can verify their product support and not just take their word for it.
What do you (want to) do?
So now you have some detailed information about the products you offer, you can turn to your business processes. How do (or will) your products get administered in your system(s), from inception to termination?
Every client we’ve worked with has slightly different business processes that have evolved around their often highly-customised systems. But if you’re in the market for an off-the-shelf system, you need to be prepared to adjust those business processes to fit the software. Not only will customising the software to fit your processes add considerable cost and risk to the project, there’s also likely to be an increased ongoing cost of ownership, to update your customisations to work with future releases.
To begin, compile a list of processes. As well as the end-customer and contract-specific processes, don’t forget the back office portfolio level processes too, such as risk management and month end accounting.
There is questionable benefit from documenting all your “As Is” processes in detail as they are likely to change to fit the new system. But knowing what initiates each process, any interactions with other systems in your IT landscape, the teams, any third parties and the hand-offs involved in the process, and what the expected outcome(s) are will be very helpful for the configuration, testing and change management for the new system. And once again it would be useful to identify any business processes that you believe are truly unique to you.
In the past, the chances are that most of these processes were initiated from an end-customer calling your call centre or operations team, but a likely objective for the new system is to enable customer self-service through a variety of Digital initiatives or at least provide a foundation to achieve this. Digital will be the subject of another post.
What else do you need to consider?
You may have other non-functional requirements of the new system. For example, it may need to comply with IT infrastructure constraints. For instance, if your strategy is to deploy your systems in Microsoft’s Azure cloud platform it would be preferable for the new system to run over a Microsoft SQL database, as opposed to Oracle, say.
The new system(s) will have to integrate with all the other systems in your estate, for example point of sale, CRM, group accounting systems and data warehouse. In our experience, system integration is one of the most complex aspects of an implementation project, and often the inputs and outputs of each integration are not well understood. The more you can understand your integration requirements and patterns at the start of the project, the better.
What do you really need the system to do?
By now you’ve compiled a very long list of product, process and other features that you need the system to do. However, the chances are, not all your requirements are going to be met straight out of the box by any vendor so by prioritising and phasing your feature requests you should be able to manage your scope and identify the vendors who have the best support for your critical requirements (for instance, which is more important to you, a variety of product support or process automation?). Deferring any customisations will also allow you to gain a better understanding of how your new system works in real life, which will most likely lead to you adapting and/or re-prioritising your requirements in future phases.
There are a variety of ways to prioritise requirements, for example see a list of requirements prioritization techniques you should know about. Whilst these techniques are primarily used for scheduling the development of new features (by your in-house team or your software vendor) there’s no reason they cannot also be used for prioritising your requirements when selecting a commercial software package. Personally, I prefer MoSCoW prioritisation:
Must Have – there's absolutely no way you could go live without this feature
Should have – this feature really should be in scope, but you could live without it for a short time
Could Have – this feature is preferred but certainly not necessary
Would Have or Won’t Have – if there was time and budget left you would have this feature but it’s likely that it won’t be delivered, so is more likely to be a suggestion for a future phase
We intend to discuss prioritisation and scope control in more detail in a future blog post, but for now it’s worth noting that the MoSCoW prioritisation can be used for the system selection and overall programme scope, and also for each phase – so a feature may be a Could Have for the first phase, but a Should Have, or even a Must Have, in a future phase.
Once you have used your preferred technique to prioritise all your documented requirements, you can then use this to assess the fit of each software vendor. In later posts we will delve deeper into vendor selection, and then scope management and implementation tasks.
How Finaptix can help
All of us at Finaptix have hands-on experience of understanding system requirements, from the start of the vendor selection process to the detailed implementation of the software. We can advise you on the overall process or perform detailed analysis of your products and business processes. Please contact us for more information.