A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
Douglas Adams

Source-to-Pay solutions are getting easier by the day and soon they will be so easy that some vendors will be claiming their solutions are so simple that even a fool can use it error-free. But that’s really not the case. No solution is foolproof. Never will be.

Why? First of all, it’s impossible to predict every action a person could take. So, no matter how many situations you plan and check for, if there is even one you missed, and if the application is complex enough there will be at least one, no matter how unlikely that situation is (or how nonsensical it is), there will be at least one user who finds it and either crashes the application or generates a scenario that is nonsensical.

The alternative is to lock the application down to an enumerable finite set of inputs in each state and limit the allowable actions to those that will allow a smooth, predictable, transition to the next state without fail. But if the vendor chooses this route, the result will be a very limited application with very limited possibilities. And given that the real world is not limited to a small set of situations with always predictable solutions, this is not a very useful solution.

Secondly, never underestimate the application stupidity of a potential user. First of all, the user could be a new transfer from another department with no training and a very shallow understanding of Procurement. What a vendor would assume to be obvious to an average Procurement user would not be obvious to a new transfer. Secondly, not all users are Procurement users. For example, shop floor users might have access to initiate requisitions. And these workers might have limited computer knowledge. And then there’s management. And consultants.

Thirdly, the more a vendor tries to make a solution foolproof, the more they end up throwing in way too much unnecessary code. The more unnecessary code that is put into an application, the more errors that creep in. Errors multiply with code. Always. Doesn’t matter if the code compiles. Doesn’t matter if the code passes the boundary tests. All that matters is that there is more code with more paths and more state transitions to track, to the point where eventually there are too many paths to track and test and something breaks when a user goes down the wrong path.

The moral of the story? Don’t fall for any vendor who says their application is foolproof. And don’t look for a foolproof application, because it’s not about how easy the application is, it’s about how much value the application can generate. The best applications, while easy and logical for most of the functionality, will not be foolproof. Nowhere close. So, value first. Because, at the end of the day, the only user a foolproof solution is for is a fool.