My previous blog was asking whether we miss something significant in business processes because we focus a lot of attention on controls and control testing. I’d like to extend that thread a bit in this follow-on blog.
Of course it is important to have controls over parts of a process. The idea that a chain is only as strong as its weakest link is completely justified and necessary to manage.
But don’t we also need to consider that the chain is the right length? And that it connects A to B to C, and that there isn’t an unexpected branch from B to D, or sometimes a short-cut from A to C?
How sure are we of our business processes?
The basis for my thesis is: do we have enough focus and accountability on the ‘as-is’ or business as usual (BAU) processes that drive businesses?
And I’m not trying to reinvent Business Process Control / Mining here (is the process happening as planned), I’m drawing attention to a more formal, audited, process sign off approach (is it still the right process).
- There are existing processes that everyone hopefully follows – simple ones are easy to ‘see’ and know if they are fit and safe for purpose. But are we sure about complex ones, are they correct and safe?
- There are planned changes to process that fall within a change management programme and we can expect that in this case the resulting processes are reviewed and ‘signed off’
- But if we have a process, is it actually being followed faithfully during BAU use (designed process vs operating process)?
- Do BAU processes properly account for manual activities amongst automated processes and their impact on the overall process? Do they properly account for handovers from one IT system to another, and that impact on the overall process? Do they properly account for use of RPA and the impact on the overall process? How often are they checked for deviations from BAU?
- Processes can be compromised by cyberattacks
- External events can result in opaque process changes
As I was writing this I could feel my brain being pulled one level down into controls over parts of a process. But controls focus on a small ‘sub-process’ (one of the links in the chain) – it’s all they can pragmatically ‘see’ – and not the reason for the process existing. If some smaller aspect of the process is higher risk or more vulnerable, of course it requires strong controls. But that doesn’t mean the overall process can be assumed to be safe and operating as expected. Granular controls have no context to the overall process or reference to each other. And that’s the point of this blog. Think of the Swiss Cheese model of risk.
CFOs and their teams are the gatekeepers for the critical data required to generate forecasts and support senior leaders’ strategic plans and decisions. At the top of the four areas of technology that show the most promise for use in finance are automation and robotics, to improve processes in finance say McKinsey. So yes CFO’s can benefit from controls over RPA’s (a small chunk of process) and automation (un-pack that and find a plethora of smaller sub-processes) for efficiencies. But where is the assurance over the end to end BAU process, which is what delivers the substance for forecasts and strategy?
At SAP we tend to talk about 4 key ERP processes for the Intelligent Enterprise:
- Lead to Cash
- Design to Operate
- Source to Pay
- Recruit to Retire
Each of these are fundamental for an effective and efficient business. We propose standard and best practice versions of these. But they can be changed (list at the top) which can result in unexpected, hidden, costly, even fraudulent BAU variants. This can erode the accuracy of critical data, weaken the accuracy and reliability forecasts, and potentially derail corporate strategy execution.
Here’s an example I heard someone relate recently, for a new joiner who was busy relocating during onboarding. The HR system created their record without a new address (didn’t have one yet) and that’s fine. The employee did some business travel and submitted expenses – address not needed. ERP system created the person as an entity that can be paid – address not needed. Payment of expenses was blocked because the recipient did not have a valid address, and that’s fine too. Except it took several weeks to finally resolve how to pay the person. Depending on the person and the amount outstanding, that could have several consequences and from any perspective is not the best impression to make on a new employee. And in each step appropriate controls were in place. But the overall result (the overall new joiner process) was not a success. A telling question could be is the process design/transformation IT driven or business driven? Or both?
So maybe we need a more formalised assurance over business as usual processes cycle, focussing on the as-is processes operating in the business? And paradoxically I think this need is going to increase the more we automate processes.