Why Big Bang can be a big mistake

Posted by Pete Loughlin in Purchase to Pay 19 Apr 2016

The are some system implementations which require a big bang approach – when the system goes live, everyone flips from old world to new world at the same time.  There are risks of course and properly resourced post go live support is essential to iron out the teething problems but sometimes there is no choice. But just because this makes sense in some circumstance it doesn’t mean it makes sense in all cases and the naïve extrapolation of success in one implementation to another can be dangerous.

There is no fixed guide as to whether big bang or more gradual roll-out works best but when it comes to P2P, I’d stick my neck out and say big bang is a big mistake.

What makes P2P different from any other system implementation? There’s a simple answer – P2P isn’t a system implementation – it’s the implementation of a set of processes and controls, usually enabled and supported by technology but the technology is incidental. A P2P rollout could just as easily be the implementation of a paper based system. And this is the point. P2P implementation is more about change management than it is about system implementation. And change management is about, amongst many other things, respecting the individual perspective of every stakeholder. You can’t big bang respect.

Site LogoLet me play devil’s advocate with my own argument. Of course you can big bang a P2P implementation. It’s not rocket science. It’s a simple matter of defining policies and processes, training users, communicating a go-live date and bingo – big bang!

This is a completely valid argument in an organisation where one size fits all – like in no organisation I have ever seen. This argument often comes from the arrogant ivory towers that exist in finance and procurement cultures sometimes. It’s the same culture of arrogance that breeds sentiments like “Why can’t they just code their POs right first time” or “Don’t these people understand the difference between Opex and Capex?” and “They’ve attended the training – why do they keep getting it wrong?”

The answer to these question is often – they can’t code POs first time because of the arcane coding rules that are in place and they don’t understand the difference between Opex and Capex because they’re not accountants and yes, they attended the training but the same training was given to everyone by people who paid no attention to the individual circumstance of their trainees.

Perhaps I’m being a bit harsh on the big bangers. (Can you call them “big bangers”?) But many readers will recognise the picture I’m painting. To put it more diplomatically, if you take a one size fits all approach to P2P you will make some progress but only in the simplistic purchasing situations like stationery where the process is very straightforward. But as soon as you move toward less simplistic categories, the processes, procedures, controls, systems and training don’t fit and people revert to a non-compliant process.

There is another reason why a big bang approach might be preferred. Reverting from old world to new world across the board at the same time makes it easier for the central functions of Finance and Procurement who don’t have to deal with the complexity of dual cultures that exist in a phased rollout. But unless those complexities are extremely complex, this is simply designing a rollout around the convenience of Finance and Procurement rather than the business.

Because P2P is about persuading people to change, it’s important that it is rolled out with sympathy for people’s unique requirements. Often, their requirements are not as exceptional as they think but it’s important to respect their view that they are.

Pete Loughlin can be found on twitter @peteloughlin

Post a comment