Dealing with issues of ‘legacy’ during ERP selection. How to equip your organisation for the future using outcome-based selection methods.
Abstract:
When companies come to market for new software, the term ‘legacy’ is most commonly used to define the current ‘as-is’ system landscape. It infers that the applications denoted as such are up for replacement and their functionalities be superseded by the new solutions being considered. However, the topic of ‘legacy’ often manifests itself during the selection process in a manner of different subtleties. These can have an adverse impact in choosing suitable replacement and ‘futureproof’ software, can increase the time and cost of a selection process, and ultimately add risk to the return on investment (ROI) of a future implementation project. In this article I posit that using an outcome-based approach to selection avoids many issues associated with ‘legacy’, and results in a more effective and successful tendering process.
Outcome based approaches to software selection focus on defined ‘outcomes’ of process not the method steps used. This approach allows a business to ensure new software is fit for purpose in meeting its stated goals but allows the business to be open minded about new processes. This is critical as most issues of legacy are often focused on, though not limited to, the method steps of a process.
Systems Legacy:
The functionality of incumbent systems represents the most immediate issue of legacy in a selection process and can often lead to unrealistic expectations of functionality. As an example, consider an organisation using a heavily customised application that is facing an upgrade/ reimplementation to move to the latest version. This organisation comes to market for a true cloud, multi tenanted solution to lower IT total cost of ownership and expects to acquire a solution without the need to customise as before. However, the vendor presenting the new software suggests they make use of a partner application to cover off the area of the customisation, rather than building this into the new software. Is this a weakness of the software vendor? It might be; depending on the type of software, the business need and the capabilities of competitor software being evaluated. Equally it might be that the previously customised process doesn’t necessarily fall under the remit of ERP process. I considered some of the reasons of unrealistic expectations in an earlier article. Thus, using outcome based selection, if some/all software vendors are proposing an alternative application solution/ the business can successfully consider these expectations as they haven’t restricted themselves to ensuring current process is replicated in the demonstrations of potential new software.
Whilst the above paragraph considers the issues with in-use customisations and the legacy system functionality afforded by these. Other issues of system legacy come with the functional gaps of incumbent software and the business challenges created by this. Often these gaps are covered by a myriad of spreadsheets which coined the often-used term of “spreadsheet hell”. Many of these challenges can be removed by ‘levelling up’ the software in use for instance automating revenue recognition processes, but sometimes companies are again surprised at the need for some spreadsheet processes to remain. Often spreadsheets are sometimes used to cover the gaps between a complex operational system and the financial accounting processes needed for the company. If the line of business system is “accounting aware” and producing common financial document types such as invoices or journals, then a CSV/ Spreadsheet method often continues to work in the new architecture. Improving this integration to be more directly connected in a phase 1.1 or 2 increases efficiency but it doesn’t change the fundamental design of the integration or original spreadsheet export.
Contrast this with a process where finance must use a spreadsheet to first manipulate the operational data to achieve the accounting entries needed by their accounting platform. Data manipulation might be as a result of location and employee for a transaction; the correct GL code, cost centre or revenue type needs to be tagged for reporting. In this example it would be easy for the organisation to come to market for a new ERP/ Accounting Platform to remove this manual spreadsheet effort. Yet this transformation process, wouldn’t necessarily be covered by the new ERP software. It might be that the organisation faces an integration challenge and not necessarily a functional gap of their current ERP. I addressed the topic of integration need and design in another article. Likewise, in similar vein to the customisation paragraph, outcome-based selection would focus on the successful transformation and delivery of data into an accounting platform to meet the business need. As a result, a middleware integration platform to be a viable option alongside ERP platforms with their own toolset for building point-to-point integrations. Further narrowing could be managed by considering the methods, as point-to-point design and middleware have different advantages, skill requirements and costs. Crucially however, outcome-based selection has allowed for two viable options to be considered, rather than biasing the selection in dictating that the spreadsheet transformation must be conducted within the new ERP application being evaluated.
Process Legacy:
Process legacy is closely related to the issues of systems legacy but considers off-system elements. Software might be ‘process orientated’, but process legacy considers the way in which a process is currently ‘executed’. A common example being the current individual or departmental responsibility for the conduct of a particular process. Equally common is the involvement of unstructured communication such as e-mail, voice calls or informal meetings, approval steps or other non-system driven processes. I consider approvals to be in this bracket, as whilst they might be configured in a system – that isn’t necessarily at the need of the application being used. Contrast this with a process that is driven by mandatory elements of the software. As such this latter element would be covered in ‘system legacy’ whilst approvals or configuration to behave a certain way is covered under ‘process legacy’.
Human nature is to initially greet change with trepidation and often cynicism. In an ERP selection process this emotive response can be misplaced, as with new applications there are often new ways of working. There are improvements to both system automation and changes in the supporting off system processes. ERP selection is a perfect time to consider all those supporting processes that do not contribute to the ‘making the boat go faster’ principle. Rather than expecting to have demonstrated a myriad of custom, multi layer workflows in the new software for example, consider how new supporting processes can wrap around the new standard processes of the software you are selecting. We know certain financial documents will need approval outcome-based selection can help us here too. If new software vendor proposes a more streamlined single point, single click approval based on standard design this is still a viable option to the outcome-based goal of the transaction needing approval. Of course, again to evaluate to a vendor of choice, you might need to consider how easy building custom workflows is between two applications. Again however, outcome-based selection has allowed you to consider viable options, possibly in this specific example avoided increasing capex spend on re-implementing complex workflows.
Mindset Legacy:
It could be argued that the previous two elements of legacy can transcend multiple organisations or businesses based on the career journey and experiences of the individuals involved. After all, if you have worked with multiple systems you are aware of different functional gaps. If you have worked with different organisational processes, change or suggested change might come more easily. I want to bring these two elements that concern the individual involved under the heading ‘mindset legacy’.
In short, even if the current organisation is using software or following certain processes, we will inevitably be influenced in part by our past experiences. This might be recent, or it might be more historic and based on point in time variables, dependencies or factors. It is important to note that I am not suggesting we simply discard our past experience in every selection process; far from it. However, as I posited at the start of the article, legacy disproportionately influences our view on how the method steps of a process should or could be executed, rather than the achievement of the desired overall business outcome.
‘Familiarity’ is a worthy synonym for mindset legacy. Based on past experiences, things become familiar to us as we are exposed to repeat experiences or processes. In the context of this article, we must be wary of this as it might lead us to favour a more disjointed process or workaround, merely because we are familiar and have mastered it previously. Our perception therefore might misjudge its suitability for a new business type, rather than the business type where the familiarity was first gained.
A common example has been the historical evolution of accounting systems vs accounting platforms. The prior systems ledger driven and placing heavy emphasis on journal ‘types’ to impact the GL codes for different business operations, often batch driven. The latter based more on the evolution of ‘ERP’ software uses operational documents and item-based processes to not only handle the operational process (e.g. timesheet approval), but also automated the ledger impact in the same instance. Familiarity of the process of transacting journals based on business operations in a successful past scenario might lead to expectations of seeing the same process executed under the new circumstances.
Familiarity brings a sense of ‘ease’ which whilst perceived at user level, might not benefit the business scalability in the same way. Considering an outcome based approach allows us to ensure the consideration of more efficient software. If we consider the outcome of “accurate cost accruals”; an accounting platform that highlights the ease and automation of a receipt record transacted by a non-finance user, is not discounted in favour of the summary cost accrual journal, uploaded or prepared through CSV. This ensures that the business has a higher chance of success in selecting the most appropriate business platform for continuing operations.
Conclusion:
In ERP selection processes there are many influences that guide our approach to, and evaluation of, different products. A good number of these influences are caused by different types of ‘legacy’. We must be mindful that our past individual experiences of both process and software will breed familiarity, which can risk contempt of more efficient or suited applications. Current processes and operational responsibilities might need to change to meet the changing demands of new software. Current functional ‘gaps’ in the current system might not be solved by a newer version of the same type of software; despite the guise of increased functional breadth/depth with increasing cost. We must first disregard our initial focus on ‘method steps’ and consider software outcomes, which will support the organisation going forward. Ultimately it is a forward looking ‘outcome-based’ approach that gives businesses the best chance of selecting most suitable ‘futureproof’ software.
