Software Is Not a Sticking Plaster for Process Issues
Many companies rightly identify the need to acquire new ERP systems. There are many drivers for change, but common themes are always evident. For example, standardising cross departmental processes or increasing visibility into the organisation, often across multiple legal entities. Yet in my experience of dealing with many businesses across Europe on a weekly basis, it is alarming how many have expectations for software to magically resolve process issues.
I see this most with companies who are growing rapidly and have at the very least separate accounting and operational systems, often these businesses have a many more. In these situations, all information is arriving at ‘the gates of finance’ as I often term it. Finance teams have total control in what information gets posted to the ledgers, from what source and in what form. However, they also become the bottle neck of invoicing, data analysis and business planning as the sheer amount of data responsibility lies with this department. I argued in a previous article that this in itself is one of the biggest business risks for SMEs, however finance departments can be apprehensive of other teams having control over processes with posting impact.
In the first instance, I have witnessed how this nervousness leads to an increased focus during selection on how a new system might be able to handle mistakes and associated corrections. Often when this apprehension is investigated, I typically see that the business has a requirement for process improvement first and foremost. Separate systems mean the ramifications of mistakes can currently be lessened through corrections, before postings are made in the accounting platform. However, this engrains culture that ‘finance will sort it out’ and this attitude presents a large risk to the ROI of subsequent software purchases.
As this article is titled, software is not a sticking plaster for process issues. I’ve worked with many businesses to help them understand the collective responsibility that a modern, deeply interconnected ERP system needs. Selection and implementation of a new system relies on the mutual understanding of multiple departments, satisfying individual requirements, but remaining cognisant of the operational impacts on other areas.
So how can businesses adapt to both improve efficiencies and increase the chance of a successful implementation?
- Drive fiscal timelines and improve accuracy of transaction submissions.
- Undertake cross departmental process and responsibility mapping.
- Use ‘Outcome Based’ software selection
1) Drive fiscal timelines and improve accuracy of transaction submissions.
It is important to drive a culture of timely accuracy in an organisation. Not only does this increase discipline and work ethic, but fiscal timelines need to be adhered to for obvious reasons. In the first instance, delays or mistakes in transactions can reduce cashflow. Either invoices take longer to raise or have errors that need correction. Delays in submissions, or corrections cause delays in monthly reporting, meaning management have slower access to data to make decisions. At quarter and year ends, the pressure associated with statutory reporting requirements come to the fore. Equally important, the timely and accurate posting of records avoids wasted time and effort in the correction or further manipulation of data. As argued in a previous article, there are hidden business risks to wasted time and effort spent. Most notably there is the hidden financial cost associated with inefficiency, but other human factors such as stress or burnout can quickly come to the fore, compounding errors. Therefore, improvement of system processing, has benefits for an organisation that can be realised in the immediate and longer term.
2) Undertake cross departmental process and responsibility mapping.
Cross departmental process and responsibility mapping solves two key challenges in organisations. Firstly, it highlights ways to improve process efficiency, free from the bounds of departmental structures and without technological investment. Secondly and most importantly it improves an organisation’s readiness for change. This latter point, in my opinion, cannot be stressed enough. By considering processes across the breadth of the organisation, mutual improvements or solutions can be found to organisational processes. Interdisciplinary culture is fostered which is also vital for any subsequent ERP implementation and the associated change management. This has point has further validity when undertaking ERP and software selections. Teams will be used to working together and considering processes based on primary outcomes with the collective benefit to the business in mind.
3) Use ‘Outcome Based’ software selection.
Every process can be mapped in terms of its outcomes. Different software has different ways of achieving key process outcomes and focussing on an ‘outcome based’ selection, avoids discounting a software product for not matching current processes. I am wary of MoSCoW based selection, as so often I can see that the ideas and thoughts around ‘must have’ requirements merely reflect current inefficient process steps, rather than noting the business outcomes that are needed. This is reflected also with requirements denoted as ‘should have’. What remains documented as ‘could have’ often reflects and exhaustive wish list and blue-sky thinking.
For example, consider the following two MoSCoW statements “Take CRM bookings data and create a revenue forecast” vs “The business must be able to forecast revenue of its current and future planned activities”. Statement one places a heavy emphasis on the current process; statement two considers the business outcome. If process and responsibility mapping has been completed, as noted in (2) above, the business should already be thinking in terms of process outcomes, instead of individual departmental or process steps.
Conclusion:
The three major steps outlined above address main pain points in change management associated with software. Improving discipline and existing process ensures that unrealistic expectations are not placed on a new software selection, for correcting what are user or process mistakes. Cross department process and responsibility mapping fosters a cohesive awareness within businesses and yields a process designed for its efficiency, where departmental responsibility can be subsequently applied. Finally, an ‘outcome based’ selection avoids selecting and implementing products to bend to current systems and processes followed. It allows other software to show what might be more modern or relevant processes, or indeed simply allow the business to operate in a more flexible manner.
Therefore, software is not a sticking plaster for process issues, but with some careful analysis and change — business can exacerbate the ROI and benefits that new software can bring.