As technology and engineering zealots there is nothing we can't build. Seriously. It is all a question of time, resource and budget. And there's the rub. There comes a point in almost any business process where we hit those points of diminishing returns with technology. All those edge cases where the coincidence of a series of unfortunate events and utterly rare occurrences all align to undermine the beautiful solution. Sometimes the solution is nigh on impossible, or the number of permutations and outcomes to cater for so magnificent. The huge amount of effort required to analyse, test, develop, document, deploy and maintain just can't possibly be justified.
That is not a defeat. That's just economics. I often see this happen especially during business continuity and disaster recovery conversations. The doomsday scenarios are imagined but the solution's Recovery Time Objective remains 1 micro second and the Recovery Point Objective is absolutely no loss of data. When people calm down and realise that such a solution would require the bending of known laws of the universe and cost a significant fortune people start to become more reasonable. How about the call centre people answering the phone use paper and pencil should the system be catastrophically lost. Would that be reasonable? Allow the system 1 hour to be restored into service and have people input the paper-persisted records offline. That might work out a whole lot better!
The other one I often see is a straight through processing system with enormously convoluted compensating transactions and business rules to try and cover everything that could possibly happen with an application. Would it be OK to put the order into an exception bucket where people make judgement calls? Ring the customer back and confirm some details? The emphasis on this solution would be to make it re-entrant and idempotent in all the right places but it could cope with a great deal of edge cases - especially the ones you don't know about or could not imagine.
The important point is to know when to transition your thinking from pure-play technology to a "people and process" solution. In fact you should almost certainly factor this into any solution because you can't anticipate everything. Once the system is in production and you notice certain patterns developing in the "people and process", you can design a solution and put it on the work backlog alongside the demonstrable business case.
People and Process. Factor it in. Then factor it out. Iteratively. If you see what I mean.