One of the main reasons is that the individual buying the software is rarely the person using the software. The individual buying the software is doing so on behalf of one party (probably a CFO or similar) but then imposing it on some others (probably some junior staff). Two issues here: Number 1 – there are plenty of opportunities for misunderstanding what is genuinely needed and what really makes sense to use; Number 2 – this approach smacks of a planned economy in which a “ministry of enterprise software” decides what software works best for us, the users. We all know that planned economies tend to underperform market economies.
Another reason is because of the divergence between what Thingamy are calling “ERP” vs “BRP”, (also described well here) or “Easily Repeatable Processes” vs “Barely Repeatable Processes”. The argument here being that enterprise software may be quite good at automating drudge tasks like accounts payable, but that it struggles with something more fluid like strategic sourcing.
But on reflection, postulating a fundamental difference between ERP and BRP is something of an assumption.
Take brewing a cup of tea. Is this an “easily repeatable process” or an “barely repeatable process”? You’d hope that it is easily repeatable. You’d be surprised. I certainly was. I was once using an auditorium that was also being used by some students to learn process mapping. They had put up posters of their process maps for making a cup of tea on the walls. Each process was completely different. And the lecturer told me that as part of the course the students then have to try to make a cup of tea in front of the whole class by following their process map. Needless to say, they usually fail.
If it’s so hard to even define the process for making a cup of tea clearly, it should come as little surprise that the extensive process definition exercises associated with major enterprise software implementations end up delivering something that the users find themselves struggling with.