You need to sharpen a pencil. It is not optional. The rules say you have to have a very sharp pencil. But why are you using a Swiss Army knife?
Good software will allow you to do virtually anything but it’s amazing how often businesses find the limits of what’s possible.
It is true, you may need to have a choice of knife blades depending on which pencil you’re sharpening and a screwdriver always comes in handy (with a choice of heads of course) and, although it is a very rare requirement, you may need one of those things to get stones out of horses hooves.
There’s no doubt that being able to face every possible scenario is better than simply being able to face the most common. A Swiss Army knife will do a great job and they look very cool – but they are complex, expensive and there’s a ton of moving parts that can go wrong.
This is the dilemma faced by P2P stakeholders when they look at approval rules. Good software will allow you to do virtually anything but it’s amazing how often businesses find the limits of what’s possible. Despite a determination to configure what is seen as best practice or even simply better practice, it can be very difficult to avoid configuring a new version of established practice and end up with a heavily over engineered purchasing approval process.
It not just that it’s difficult to move away from the accepted practices – there’s also an irrational fixation enjoyed by some, akin to a fetish, to automate everything. Now let’s be very clear here. Automation fetishism does not refer to a sexual obsession with cloud software – I’ve known some people in the P2P world who take their enthusiasm to extremes but they wouldn’t take it that far – (although I’d be delighted to be proved wrong on that one.) No, I’m referring to fetishism in the sense that automation is seen as an end in itself regardless of whether it delivers business efficiency. An automated process is seen as somehow better than a manual process because it doesn’t suffer from human error regardless of the potential for human error in configuration, testing and maintenance.
Automation fetishism does not refer to a sexual obsession with cloud software – I’ve known some people in the P2P world who take their enthusiasm to extremes but they wouldn’t take it that far – (although I’d be delighted to be proved wrong on that one.)
I have sympathy for those that specify approval requirements. Existing, established approval rules have been agreed by internal audit. In a regulated industry, approval requirements can be strict, even for the purchase of indirect goods and services. They are based on well-established precedents and it is harder to get these principles reviewed than it is to configure the software. More often than not, the underlying audit principles that govern P2P approvals were developed for a non-automated world. This doesn’t mean they are archaic but they were usually developed without a view of what is possible in today’s cloud-based automated environment.
But even if it’s deemed impractical to try to renegotiate difficult approval business process requirements, it is possible to take a step back and ask whether or not it makes sense to try to automate a set of rules that were not designed for an automated world. And you can go further. You can cherry-pick. You can question whether there is any point in automating business rules that are rarely encountered. Think even harder about it if the rules are especially difficult to automate. Consider alternatives to those rules that are rarely encountered AND difficult to configure and maintain.
There’s a common example of this. It’s a bit simplistic but it illustrates the point. Suppose there’s a simple approval rule that says all purchase requests up to $500,000 can be approved by a cost center manager and over that, the CFO approves. Does that mean the CFO has no approval limit? What if the constitution of the business gives the CFO a $10 million limit and the purchase request is for a value greater than that? Who is above the CFO? The chairman? What’s the chairman’s limit? How do you automate the approval of very high-value items?
My answer: This is simply not what P2P automation is designed to deal with so stop trying to use it for these sorts of circumstances. Very high level approvals should not be in the hands of a single person and would normally require board approval. Better to use a manual process with paper, pens and signatures.
There are many other real-world examples where it makes sense to simple stop trying to automate. Let’s say there’s a very rare combination of approvers such that it could be possible for someone to self-approve a modest value order. And suppose that this rare combination gave rise to the need for a complex configuration. Why not consider a non-technical control such as a retrospective report to catch when this rare approval event happens. It’s low risk, it’s rare – what’s the business benefit in automating?
Stop trying to automate everything . There are situations where it’s better to use a manual process with paper, pens and signatures.
Finally, put things into perspective. If an event happens very occasionally, consider some of the non-technical controls that are in place to mitigate other risks. What backups are in place for a total system failure for an extended period of time? What about controls that cover emergencies? Long term system downtime should be very rare indeed but emergencies in some businesses can occur regularly and it is absolutely appropriate to have pragmatic alternatives in place to safeguard health and safety or the successful operation of the business. Attempts to automate vary rare events – sometimes at considerable cost, need to be considered in the light of other circumstance where manual controls are acceptable.
In summary I would recommend a three step approach when looking at designing P2P approval processes:
Don’t be an automation obsessive. In the case of complex approvals, build a business case to justify the cost of configuring and maintaining compared to the business benefit.
You can’t ignore necessary controls, especially in highly regulated industries but you can put them into perspective. There are strong non-technical controls that can be used as alternatives to automation, especially for obscure or rare control events.
Above all, keep it simple. The point of P2P is to deliver control, compliance, and cost reduction. Complex processes can deliver tight control but can increase the cost of the process.
In short – when you need to sharpen a pencil, use a pencil sharpener.